Si vous gérez un entrepôt de données multinational, vous pourriez avoir à faire face au problème de la présentation du contenu de l'entrepôt de données dans un certain nombre de langues différentes. Quelles parties de l'entrepôt ont besoin d'être traduites? Où stockez-vous les différentes traductions? Comment faites-vous pour intégrer de plus en plus de langues?
Il y a beaucoup de problèmes de conception dans la construction d'un entrepôt de données véritablement multinational. Dans cet article, nous allons nous concentrer uniquement sur la façon de présenter les "éléments de langue interchangeables" pour les utilisateurs finaux, et nous ne traiterons les points suivants:
- les conversions de devises
- la ponctuation numérique
- les fuseaux horaires
- les formats d'adresses
- les formats de numéros de téléphone
Notre objectif sera de passer proprement parmi différentes langues, à la fois pour les requêtes ad-hoc et pour la visualisation de rapports standard. Nous tenons également à naviguer au travers d'un entrepôt de données multinational distribué qui a mis en place des dimensions conformes.
De toute évidence, la majeure partie de notre attention doit se concentrer sur nos dimensions. Les dimensions sont les dépositaires de la quasi-totalité du texte dans nos entrepôts de données. Les dimensions contiennent les libellés, les hiérarchies et les descripteurs de nos données. Les dimensions portent le contenu de nos interfaces utilisateur, et fournissent le contenu des lignes et en-têtes de colonnes dans tous nos rapports.
L'approche directe consiste à fournir une traduction 1-pour-1 de chaque dimension dans chaque langue prise en charge. En d'autres termes, si nous avons une dimension Produit initialement exprimée en anglais, et nous voulons une version française et une version allemande, on copie la dimension anglaise ligne par ligne et colonne par colonne, tout en préservant les clés et les indicateurs numériques, tout en traduisant chaque attribut textuel.
Mais nous devons être prudents. Afin de préserver les interfaces utilisateur et les résultats finaux de la version anglaise, les dimensions Produit françaises et allemandes devront également conserver:
- les relations 1-pour-1 et 1-à plusieurs
- les groupements logiques, à la fois pour les rapports ad-hoc et les rapports agrégés
Les relations explicites 1-pour-1 et 1-à plusieurs devraient certainement être appliquées dans un modèle entité-relation dans la zone de préparation des données. Cette partie est facile. Mais un problème se pose lorsqu'on fait les traductions pour s'assurer que deux attributs distincts Anglais ne finissent pas par être traduits par le même attribut français ou allemand. Par exemple, si les mots anglais "scarlet" et "crimson" ont tous deux été traduits par le mot allemand "rot", certains totaux de rapport seraient différents entre les versions anglaises et allemandes. Il nous faut donc une étape supplémentaire qui vérifie que nous n'avons pas introduits des traductions d'attributs anglais en double.
Le gros avantage de cette conception est l'évolutivité, puisque nous pouvons toujours ajouter une nouvelle langue sans modifier la structure des tables, et sans recharger la base de données.
Nous pouvons permettre à l'utilisateur français ou allemand de naviguer à travers un entrepôt de données distribué si nous répliquons les versions traduites des dimensions dans tous les datamarts. Quand un utilisateur français ou allemand exécute une requête, chaque datamart doit utiliser les bonnes dimensions traduites. Cela sera traité assez facilement par l'application française / allemande d'origine qui exécute la requête. Notez que chaque base de données distante doit prendre en charge "les dimensions remplaçables à chaud» qui permettent à cette dimension de changer en fonction des différentes langues demandées dans les requêtes. C'est facile dans un environnement relationnel mais peut être difficile dans un environnement OLAP.
Bien que nous ayons accompli beaucoup de choses avec cette conception, y compris une approche évolutive pour mettre en place un entrepôt de données multi-langue distribué, nous avons encore quelques problèmes non résolus:
- nous ne pouvons pas facilement maintenir les ordres de tri entre les différentes versions linguistiques d'un même rapport. Nous ne pouvons pas faire le tri des attributs traduits dans le même ordre que la langue d'origine. Si la préservation de l'ordre de tri est nécessaire, alors nous aurions besoin d'un dimension hybride comportant à la fois la langue d'origine et la seconde langue, de sorte que la requête SQL pourrait forcer le tri dans la langue d'origine, mais afficher les libellés de la seconde langue non triés. C'est compliqué et la dimension est deux fois plus grande, mais elle permettrait probablement de pouvoir travailler.
- Si la langue d'origine est l'anglais, nous constaterons probablement que presque tous les libellés traduits sont plus longs que la version anglaise. Ne me demandez pas pourquoi. Mais cela pose des problèmes de mise en forme des interfaces utilisateur ainsi que des rapports finaux.
- Enfin, si notre ensemble de langues s'étend au-delà de l'anglais et des principales langues européennes, alors même le jeu de caractères ASCII étendu à 8 bits ne sera pas suffisant. Tous les datamarts participants auraient besoin d'utiliser le jeu de caractères Unicode 16-bit.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #24: Designing Dimensional in a Multinational Data Warehouse", publié le 1juin 2001.
Aucun commentaire:
Enregistrer un commentaire