Faits et dimensions (2)

jour le jour, par client et par produit requiert beaucoup trop de travail. La table Orders Forecast utilisera plus vraisemblablement les niveaux mois (month) et produit (product), avec un niveau clients (customer) éventuellement ajouté pour les grands comptes ou les entreprises ayant relativement peu de clients. La table OrderLineItems de la figure 1 possède des données susceptibles de se trouver à deux niveaux. Les valeurs OrderQuantity (quantité commandée) et OrderDollar (montant de la commande en dollars) se situent au niveau article (line-item), mais les données ShippingAmount (frais d’expédition) pourraient être générées au niveau de la table Orders (commandes).

Dans la figure 1, nous avons alloué les frais d’expédition au niveau article afin d’éviter de créer deux tables de faits. Une telle allocation constitue généralement une bonne solution tant que les utilisateurs métier prennent en charge les règles d’allocation. Dans certains cas, cette approche n’est, économiquement parlant, pas pertinente, et nous employons des tables de faits à deux niveaux de granularité pour décrire un processus métier donné. Une dernière petite remarque concernant les tables de faits : vous noterez que les données OrderNumber (numéro de commande) et LineItemNumber (numéro d’article) de la figure 1 ne sont pas des clés étrangères pour des dimensions distinctes. Leur finalité est de lier ensemble les lignes de chaque commande. Comme tous les attributs descriptifs d’une commande résident dans leurs dimensions respectives, OrderNumber et LineItemNumber deviennent des dimensions dégénérées (ou dimensions de faits dans Analysis Services).

Un bref examen des lignes de données de l’exemple de la figure 1 montre que la table de faits n’a pas de signification propre : elle n’a pas de contexte métier. Tout processus métier possède plusieurs entités ou objets relativement indépendants qui participent au processus. Dans la modélisation dimensionnelle, ces objets sont appelés dimensions et les propriétés d’une dimension sont appelées attributs. Ces derniers décrivent les membres de la dimension et fournissent un contexte métier étoffé pour les besoins de l’analyse. Par exemple, la dimension Product (produit) de la base de données AdventureWorks peut avoir plusieurs attributs autonomes tels que color (couleur), size (taille) et weight (poids).

La majorité des dimensions possèdent plusieurs attributs liés à d’autres sous une forme hiérarchique. La dimension Product peut avoir une hiérarchie dans laquelle les produits sont les membres d’un groupe et les groupes sont les membres d’une catégorie. La figure 2 illustre une dimension Product simplifiée et quelques exemples de lignes d’AdventureWorks Cycles.