La relation de données parent-enfant est l'une des structures fondamentales de base dans le monde des affaires. Une facture (le parent) a beaucoup de lignes d'articles (les enfants). D'autres exemples évidents en dehors des factures comprennent les commandes, les ordres de livraison, les polices d'assurance, et les tickets de caisses. Fondamentalement, tout document professionnel possédant des éléments qui se répètent est considéré comme une application parent-enfant, surtout quand ces éléments comportent des mesures numériques intéressantes comme des montants ou des unités physiques.
Les applications parent-enfant sont d'une extrême importance pour les entrepôts de données, car la plupart des documents de contrôle qui transfèrent de l'argent et des biens (ou des services) d'un endroit à un autre prend la forme parent-enfant.
Mais une source de données parent-enfant, comme les factures, pose un dilemme de conception. Certaines de ces données sont seulement disponibles au niveau de la société mère et certains ne sont disponibles qu'au niveau de l'enfant. Avons-nous besoin de deux tables de fait dans notre modèle dimensionnel ou pouvons-nous tout faire avec une seule? Et que faisons-nous avec les données qui sont disponibles uniquement au niveau de la société mère quand nous voulons descendre au niveau de l'enfant?
Imaginons une facture typique. La facture globale est créée par le vendeur pour notre entreprise et s'adresse à un client spécifique. Chaque ligne de la facture représente un produit différent vendu au client.
Le niveau parent comprend les données suivantes:
- date de la facture (dimension)
- vendeur (dimension)
- client (dimension)
- moyen de paiement (dimension)
- numéro de facture (dimension dégénérée)
- montant net total (fait additif)
- montant total des réductions (fait additif)
- montant total des frais de port (fait additif)
- montant total des taxes (fait additif)
- montant total de la facture (fait additif)
le niveau enfant comprend les données suivantes:
- produit (dimension)
- promotion (dimension)
- nombre d'unités (fait additif)
- prix unitaire du produit
- montant total de la ligne (nombre d'unités * prix unitaire) (fait additif)
- montant de la promotion
- montant total réel de la ligne (nombre d'unités * (prix unitaire - montant de la promotion)) (fait additif)
Mais notre conception est fausse. Nous ne pouvons pas analyser nos chiffres par produit! Si nous nous limitons à un produit spécifique, nous ne savons pas quoi faire avec les réductions, les frais de port, et les taxes qui sont définis au niveau de la facture. Dans ce cas, toutes les analyses par client, vendeur et promotion sont obligées d'omettre la dimension Produit.
Il n'y a qu'une seule façon de résoudre ce problème. Vous devez prendre les données au niveau des factures et les répartir jusqu'au niveau de la ligne de facture. Oui, il y a une certaine controverse en faisant cette attribution, et oui, vous devez prendre des décisions arbitraires, mais l'alternative est de ne pas pouvoir analyser votre entreprise en fonction de vos produits.
Nous allons remplacer les deux tables de fait avec une seule table de faits, dont le grain est l'élément de la ligne de facture. En d'autres termes, nous allons systématiquement descendre jusqu'au niveau enfant le plus atomique lorsque nous faisons une conception dimensionnelle de type parent-enfant.
Ainsi, notre table de faits aura les dimensions suivantes:
- date de la facture (dimension)
- vendeur (dimension)
- client (dimension)
- moyen de paiement (dimension)
- produit (dimension)
- promotion (dimension)
Que faisons-nous avec le numéro de la facture? C'est certainement une valeur unique, même au niveau de la ligne de facture, mais nous avons déjà "exposé" tout ce que nous savons au sujet de la facture dans nos quatre premières dimensions. Nous devons garder le numéro de facture dans la conception, mais nous n'avons pas besoin d'en faire une dimension distincte parce que cette dimension serait vide. Nous appelons ce type particulier de dimension une "dimension dégénérée".
- numéro de facture (dimension dégénérée)
Maintenant les faits pour la ligne de facture sont:
- nombre d'unités (fait additif)
- montant total de la ligne (nombre d'unités * prix unitaire) (fait additif)
- montant de la promotion
- montant total réel de la ligne (nombre d'unités * (prix unitaire - montant de la promotion)) (fait additif)
- montant de la réduction alloué (fait additif)
- montant des frais de port alloué (fait additif)
- montant des taxes alloué (fait additif)
Nous n'incluons pas les prix unitaires ou les remises parce que nous pouvons toujours diviser les montants par le nombre d'unités dans notre application de reporting pour obtenir ces quantités non-additives.
Nous pouvons récupérer instantanément les montants exacts au niveau de la facture simplement en additionnant toutes les lignes liées à un numéro de facture spécifique. Nous n'avons pas besoin de la table de fait Facture parce que ce n'est qu'une simple agrégation de la table de fait enfant Ligne de facture. Nous avons nullement compromis les totaux des factures en effectuant les allocations jusqu'à la ligne de facture.
Et, le meilleur, c'est que nous pouvons maintenant analyser notre activité au plus haut niveau, en analysant par produit, et en incluant les montants alloués pour obtenir une image fidèle de nos revenus nets.
Cette technique de descendre au niveau de la ligne et de construire qu'une seule table de faits est au cœur de la modélisation des entrepôts de données. C'est notre façon à nous de tenir la promesse que nous pouvons "analyser et découper les données de l'entreprise dans tous les sens".
.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #25: Designing Models for Parent-Child Applications", publié le 1juillet 2001.
Aucun commentaire:
Enregistrer un commentaire