Conseil 32: Faire le travail lors de la phase d'extraction

Notre mission en tant que concepteurs d'entrepôt de données est de publier des données le plus efficacement. Cela signifie placer les données dans le format et le cadre qui est le plus facile à utiliser pour les utilisateurs finaux et les développeurs d'applications.

Dans l'arrière-salle de notre entrepôt de données, nous devons lutter contre nos tendances minimalistes naturelles lorsque nous préparons les données relatives à la consommation finale par les utilisateurs finaux et les développeurs d'applications. Dans de nombreux cas importants, nous devrions accepter:

• l'augmentation des processus d'alimentation
• l'augmentation des besoins de stockage

en échange de:

• schémas symétriques et prévisible que les utilisateurs comprennent
• la réduction de la complexité de l'application
• l'amélioration des performances des requêtes et des rapports

La réalisation de ces compromis devrait être un objectif évident pour l'architecte d'entrepôt de données. Un bon architecte d'entrepôt de données résistera à l'envie de déléguer les analyses supplémentaires et la manipulation de tables aux utilisateurs finaux et aux concepteurs d'applications. Méfiez-vous des vendeurs qui militent en faveur de schémas complexes! Mais bien sûr, ces compromis doivent être choisis judicieusement. Regardons une demi-douzaine de situations où nous faisons juste assez de travail au moment de l'extraction pour vraiment faire une différence. Nous allons aussi essayer de définir quelques limites, afin de savoir quand il ne faut pas trop en faire pour éviter de gâcher le résultat final. Nous allons commencer par quelques petits exemples puis nous étendrons progressivement notre périmètre.

Modélisation d'événements à travers plusieurs fuseaux horaires

Pratiquement toutes les mesures enregistrées dans nos entrepôts de données ont un ou plusieurs champs de type date-heure (ou timestamp). Parfois, ce sont de simples dates du calendrier, mais de plus en plus, nous enregistrons l'heure exacte à la minute ou à la seconde. En outre, la plupart de nos entreprises couvrent plusieurs fuseaux horaires, que ce soit aux États-Unis, en Europe, en Asie ou dans le monde. Dans ces cas, nous avons un dilemme. Soit nous standardisons l'ensemble de nos champs date-heure sur un seul fuseau horaire bien identifié, soit nous les standardisons sur l'heure locale exacte de l'événement. Si nous voulons convertir l'heure GMT en heure locale, peut-être que nous avons simplement besoin de déterminer quel est le fuseau horaire où la mesure a été prise, et d'appliquer un simple décalage. Malheureusement, cela ne fonctionne pas. En fait, cela échoue dramatiquement. Les règles concernant les fuseaux horaires internationaux sont horriblement compliquées. Il y a plus de 500 régions géographiques distinctes avec des règles distinctes de fuseau horaire. 

Morale de l'histoire: ne calculez pas les fuseaux horaires dans votre application. Il vaut mieux ajouter une clé étrangère date-heure supplémentaire dans chaque endroit où vous avez un horodatage existant, et d'enregistrer à la fois l'heure standard et l'heure locale. En d'autres termes, faites le travail au moment de l'extraction, pas au moment de la requête de l'utilisateur, et renoncez à un stockage de données minimal.

Dimension Calendrier riche

Toutes les tables de faits d'un schéma d'entrepôt de données devraient éviter d'avoir des champs de type date-heure et utiliser plutôt des clés étrangères aux valeurs entières qui se connectent à une dimension Calendrier enrichie. Cette recommandation n'est pas fondée sur une cohérence stupide de la conception décisionnelle, mais sur la reconnaissance que les calendriers sont compliqués et que les applications ont généralement besoin de beaucoup d'aide à la navigation. Par exemple, les champs SQL de type date-heure (ou timestamp) n'identifient pas le dernier jour du mois. L'utilisation d'une dimension Calendrier distincte de la date, permet d'identifier le dernier jour du mois grâce à un indicateur booléen, rendant ainsi les applications plus simples. Imaginez vous écrire une requête SQL simple sur un champs timestamp qui limiterait le résultat aux derniers jours de chaque mois. Voici un exemple où l'ajout du mécanisme d'une dimension Calendrier explicite simplifie les requêtes et accélère le traitement en évitant du SQL complexe.

Gérer la comptabilité avec plusieurs devises

La perspective de fuseaux horaires multiples discuté dans le premier exemple se produit souvent avec la question des transactions dans différentes devises. Encore une fois, nous avons deux points de vue égaux et légitimes. Si la transaction a eu lieu dans une monnaie donnée (par exemple, le Franc suisse), nous voulons évidemment garder cette information telle quelle. Mais si nous avons une multitude de devises, nous allons avoir du mal à additionner les résultats pour atteindre un total international. Encore une fois, nous prenons une approche similaire pour étendre chaque champs monétaire de notre entrepôt de données, afin d'obtenir deux champs: un pour la valeur de la monnaie locale et un autre pour la valeur de la monnaie de référence. Dans ce cas, nous devons aussi ajouter une dimension monétaire à chaque table de faits pour identifier sans ambiguïté la monnaie locale. L'emplacement de la transaction n'est pas un indicateur fiable du type de monnaie locale.

Unités de mesure différentes dans un ensemble de produits

La plupart d'entre nous pensent que les mesures sur des ensembles de produits sont assez simples et n'ont pas les complications que les services financiers peuvent avoir, par exemple. Eh bien, passez du temps avec les personnes de la fabrication, de la distribution, et des magasins, tout le monde parle des mêmes produits. Seulement les personnes de la fabrication veulent tout voir en lots de chargement ou en palettes. Les personnes de la distribution veulent tout voir en lots d'expédition. Et enfin, les magasins veulent seulement voir les produits à l'unité. Alors qu'est-ce que vous mettez dans les différentes tables de faits pour que tout le monde soit heureux? La mauvaise réponse consiste à publier chaque fait dans son contexte d'unité de mesure locale et laisser aux applications la tâche de trouver les facteurs de conversion dans les tables de dimensions Produit! Oui, tout cela est possible en théorie, mais cette architecture impose un fardeau déraisonnable à la dernière étape du processus, là où les utilisateurs finaux et les développeurs d'applications travaillent. Au lieu de cela, présentez tous les faits mesurés dans une unité de mesure unique standard, puis, dans la table de faits, fournissez les facteurs de conversion pour toutes les autres unités de mesure souhaitées. De cette façon, les applications qui interrogent les données à partir de n'importe quel point de vue ont une manière cohérente de convertir toutes les valeurs numériques en fonction de la perspective spécifique de l'utilisateur final.

Conception d'une table de faits "Pertes & Profits" complète

Une table de faits de pertes & profits est très puissante car elle présente toutes les composantes des recettes et des coûts à (on l'espère) un faible niveau de granularité. Après avoir fourni ce niveau merveilleux de détail, les concepteurs compromettent parfois leur conception en omettant de fournir tous les niveaux intermédiaires de la P & L. Par exemple, le "bénéfice net" est calculé en soustrayant les coûts du chiffre d'affaires net. Ce bénéfice net devrait être un champ explicite dans les données, même si elle est égale à la somme algébrique des autres champs du même enregistrement. Il serait vraiment dommage que l'utilisateur ou le développeur de l'application s'embrouille à la dernière étape et calcule le bénéfice de manière incorrecte.

Produits hétérogènes

Dans les services financiers comme la banque et l'assurance, un conflit surgit souvent entre la nécessité de voir tous les types de comptes dans une seule vue "Ménage" du client, et pour afficher les attributs et les mesures détaillées de chaque type de compte. Dans une grande banque de détail, il peut y avoir 25 domaines d'activité et plus de 200 mesures spéciales associées aux différents types de comptes. Vous ne pouvez pas créer une table de faits géante et une table de dimension "Compte" géante qui peut accueillir tous les produits hétérogènes. La solution est de publier les données deux fois. Créez d'abord une table de faits de base comprenant seulement quatre ou cinq mesures, comme la balance, qui sont communs à tous les types de comptes. Ensuite, publiez les données une seconde fois, avec la table de faits et la dimension "Compte" étendue séparément pour chacun des 25 domaines d'activité. Même si cela peut sembler inutile, car la table de faits est publiée deux fois, cela simplifie les applications métiers.

Les agrégations en général

Les agrégations sont comme des index: ce sont des structures de données spécifiques destinés à améliorer les performances. Les agrégations sont une importante source de distraction dans le back office. Ils consomment des ressources, ajoutent de la complexité de dans les flux d'alimentation, et prennent beaucoup d'espace. MAIS, les agrégations demeurent l'outil le plus puissant dans l'arsenal du concepteur de l'entrepôt de données pour améliorer efficacement le rapport coût-performance.

La modélisation dimensionnelle en général

A présent, je l'espère, il est évident que le compromis le plus utilisé pour le bénéfice de l'utilisateur final est la pratique de la modélisation dimensionnelle. Un modèle dimensionnel est une version de la deuxième forme normale d'un modèle de troisième forme normale (ou plus). Regrouper des flocons de neige et autres structures complexes des modèles de forme normales supérieures dans des tables de dimensions plates typiques rend les conceptions simples, symétriques et compréhensibles. En outre, les fournisseurs de bases de données ont pu concentrer leurs algorithmes de traitement sur cette modélisation bien comprise afin de créer des modèles dimensionnels s'exécutant très vite. Contrairement aux autres techniques présentées dans cet article, l'approche du modèle dimensionnel peut être appliquée dans presque tous les domaines d'application horizontale et verticale.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #32: Doing the work at extract time", publié le 8 janvier 2002.