EDW Fact Table pour l'enfant parent

Question

Je construis un EDW basé sur l'approche de Kimballs. J'ai une relation parent/enfant dans notre système source (commandes/postes individuels). La table de faits que j'ai est définie à la ligne article grain. Les entreprises aimeraient être en mesure de découper et de découper ces données en fonction d'attributs de niveau de commande supplémentaires (par exemple, méthode d'expédition, type de commande, etc.). Je prévois de créer une dimension de commande au lieu d'ajouter ces attributs directement à la table de faits. Je ne veux pas les ajouter directement à la table des faits car l'ajout de tous les attributs possibles rendra cette table de faits très large. Donc, la question est ... est-il correct de concevoir une dimension de commande qui a des attributs pour décrire la commande? Cette dimension n'aurait aucune mesure puisque toutes les mesures seront toujours dans la table de faits. Ce sont juste des données supplémentaires qui décrivent le fait.

Merci!

Answer 1

Ceci est un dillemma de modélisation dimensionnelle très commun.

Vous avez raison de ne pas les ajouter directement à la table de faits au niveau de la ligne de commande. Ce sont des attributs dimensionnels en ce sens qu'ils seront utilisés pour filtrer la table de faits lors de l'interrogation. Cependant, si vous les plongez tous dans une dimension d'ordre, vous obtiendrez probablement une très grande dimension, surtout si vous avez un numéro de commande à inclure, et toute analyse de choses comme le type de commande ou la méthode d'expédition devra passer par là. . Si vous modélisiez un fait de niveau de commande, le type de commande/la méthode de livraison seraient conservés dans des dimensions, éventuellement dans une dimension de détails de commande créée comme une dimension «indésirable» (mais c'est une autre question). L'approche recommandée par le groupe Kimball consiste à faire en sorte que le niveau de niveau de ligne de commande hérite des dimensions que vous auriez utilisées dans le niveau de commande, afin qu'elles soient directement disponibles pour l'analyse plutôt que d'avoir une dimension 'order' . Notez que le numéro de commande peut être une 'dimension dégénérée' dans la table de faits dans cette instance, car toutes les informations intéressantes sur la commande ont été capturées dans d'autres dimensions.

Le Groupe ont un article Kimball utile à ce sujet ici: dans laquelle

http://www.kimballgroup.com/2007/10/design-tip-95-patterns-to-avoid-when-modeling-headerline-item-transactions/

sont mis en évidence les failles de la dimension pour idée et l'approche recommandée décrite.