Conception de schéma d'entrepôt de données - comment améliorer le modèle de schéma

Je dois créer Data Warehouse pour agence de voyages. Je le fais pour la première fois. J'ai appris toutes les bases de l'étoile, du flocon de neige et du schéma de constellation et de la création de warhouses de données. Je voudrais demander ce qui pourrait être changé pour mieux et si cette conception est bonne dans l'ensemble.Conception de schéma d'entrepôt de données - comment améliorer le modèle de schéma

Voici mes dimensions hiérarchie:

Voici ce que j'ai achived pour l'instant (création de schéma dans MySQL Workbench):

Source

2017-04-02 anton86993

Pouvez-vous être plus précis sur les parties de ce que vous avez des difficultés avec? Est-ce que vos diagrammes montrent tous vos champs dans ces dims? Aussi je ne pense pas que le type de paiement devrait vraiment inclure l'année/mois/jour/heure/minute – Rich

Je ne suis pas un grand fan de sous-dimensions. Une fois que vous commencez à les introduire, la conception de la base de données ressemble rapidement à la norme [OLTP] (https://en.wikipedia.org/wiki/Online_transaction_processing).Cela supprime de nombreux avantages offerts par un schéma en étoile. Un exemple: les données via des outils de visualisation (comme [PowerBI] (https://powerbi.microsoft.com/en-us/), [QlikView] (http://www.qlik.com/fr-fr), etc.) préférez les tables de dimension plus plates, recommandées par [Kimball] (https://en.wikipedia.org/wiki/Dimensional_modeling). –

Je tiens à souligner que les deux premiers commentaires sont basés sur une version précédente de la question. – Rich

Voici une nouvelle réponse basée sur la question révisée. Il y a un certain nombre de choses que vous pourriez vouloir regarder pour cette conception. Voici quelques pointeurs mais pas une liste complète:

Quelle granularité votre dimension DimTime est-elle supposée être? Normalement vous avez une dimension de date à la granularité du jour/date, mais dans votre tableau cela ressemble à des semaines.
Vous pouvez créer une dimension d'heure différente si cela est important pour l'analyse des ventes ou des avis de satisfaction. Le fait de loyauté semble être un résumé du comportement des clients sur une période de temps - est-ce censé être des semaines? Si oui, vous pouvez opter pour une dimension supplémentaire au niveau de la semaine
Pourquoi le type de paiement contient-il des secondes du jour? Cela ne semble pas juste - les types de paiement ne sont pas à faire avec des secondes dans une journée. Peut-être est-ce votre dimension d'heure de la journée manquante, et le type de paiement doit être séparé?
La dimension du produit doit-elle avoir une hiérarchie régionale? Êtes-vous en train de dire qu'un produit est différent s'il se trouve dans une autre ville? Vous voudrez peut-être revoir cela.

Je suis sûr que d'autres suggestions pourraient être trouvées, bonne chance avec votre cours!

Source

2017-04-04 13:13:57 Rich

1. Nous voulions faire la date à partir de l'année, puis le trimestre, le mois, la semaine, puis le jour de la semaine sans heure de la journée; 2. Je suppose que c'est juste à des fins éducatives, pas pour la mise en œuvre dans la vie réelle, donc il ne doit pas être si détaillé :); 3. Je suppose que c'est bon. Nous voulions vérifier la fidélité des clients au jour le jour parce que c'est une agence de voyage .; 4. PaymentType n'a pas de secondes. Il a minutes puis PaymentId ou je ne comprends pas; 5. Dans mon pays, nous avons des voïvodies, donc je suppose que cela devrait s'appeler Province au lieu de Région, ai-je raison? – anton86993

1. Je suis d'accord, vous ne voulez pas l'heure du jour, mais il devrait au moins être «date». 4. Pourquoi des minutes du tout? Un type de paiement est un type de paiement - il n'a rien à voir avec les minutes, je pense! 5. Les produits ne sont pas du tout régionaux, c'est ce que je dis. Bonne chance avec vos études – Rich

Pour prendre DimClient comme Exemple. Vous avez une bonne clé de substitution là-dedans. Ensuite, vous devez remplir toutes les choses sur un client (y compris le clientID) et ensuite inclure le district, la ville, la région et le pays. Quand vous avez tout ce qu'il y a dedans, cette dimension est complète. Vous le liez dans votre table de faits par le ClientKey, vous devez donc mettre cette clé dans la table Fact comme une clé étrangère. Suivez un processus similaire avec vos autres dimensions, en remplissant à la fois les dimensions et les faits, et vous serez en bonne forme. Vous n'avez pas besoin de sous-dimen- sions pour refléter vos hiérarchies: les dimensions sont dénormalisées. Edit: La question était à l'origine assez différente, d'où la réponse ci-dessus qui était pertinente à sa forme originale.

Source

2017-04-02 14:09:33 Rich

Pourquoi devrais-je créer un schéma en étoile ici au lieu de flocon de neige? Notre conférencier nous a dit de le faire plus comme un schéma normalisé (flocon de neige). Pourquoi? – anton86993

Je ne sais pas pourquoi votre conférencier vous a dit de le faire, mais si vous voulez de bonnes notes, vous devriez probablement faire ce qu'ils ont dit! Si vous voulez faire un modèle dimensionnel dans le style Kimball, vous devriez éviter de faire du flocon de neige (normalisation) lorsque c'est possible, car cela réduit les avantages de faire les choses de façon dimensionnelle. Si vous voulez flocon de neige, faites des sous-dimensions, également avec des clés de substitution, et reliez-les avec des clés étrangères de vos dimensions, comme un modèle normalisé «normal». Vraiment heureux de vous aider si vous avez des questions spécifiques - il suffit de demander. – Rich

Dès que je rentre à la maison je vais le faire et montrer ici mes résultats :) – anton86993

Conception de schéma d'entrepôt de données - comment améliorer le modèle de schéma

Répondre

Questions connexes