multilingual support

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

multilingual support

Tim Schiettekatte
Hello,

Since our information system is used globally we need multilingual support in our DWH to display information in the user's language. We manage this by storing multilingual values in all supported languages and filtering these values on the language id of the logged in user at runtime.

In our DWH we want to support this methodology by storing multilingual values for attributes and knots. Sixth normal form splits all attributes, anchors and relations into separate entities which does not allow an extra language_id column in attribute and knot tables to filter values on at runtime. What would be a good approach to support our multilingual requirements in Anchor modeling?

Regards,
Tim
Reply | Threaded
Open this post in threaded view
|

Re: multilingual support

roenbaeck
Administrator
Concurrency (having more than one valid value at a given time) can only be achieved by moving to CRT, concurrent-reliance-temporal Anchor Modeling. In CRT concurrency is managed through the concept of positors, which can be seen as information owners/agents/producers such that each one of them are entitled to having their own value at any point in time. This value may be the same as or different from that of other positors.

You can even set up your own hierarchy of positors, such that if your prioritized one doesn't have a value then you pick one from the default positor instead.

So, you need CRT with as many positors as you have languages.

Of course, there is also a way to do this in UNI, uni-temporal Anchor Modeling, but not as elegant. You can have multiple attributes and knots for the same value, for example HCO_HairColorEnglish and HFA_HaarfarbeGerman. Thanks to table elimination only the attributes of a single language will be accessed during query execution.

However, application logic will have to account for the different table names, so in order to simplify that, perhaps the attributes above would be named HCO_HairColorEN and HCO_HairColorDE instead.

Of the two approaches, I would recommend CRT.
Reply | Threaded
Open this post in threaded view
|

Re: multilingual support

Tim Schiettekatte
Hi Lars,

Using concurrency for the languages, 1 positor represents 1 language, sounds like the best option. This way the model stays clean and extendable for new languages without littering it with multilingual attribute names. Very nice.

What are the consequences if I alter my current anchor model from uni- to bitemporal? Could you explain or do you have an example how I can implement the positors for the languages?

Kind regards,
Tim