Quelle est la meilleure façon de modéliser des lignes de base, des projections ou des objectifs dans la modélisation dimensionnelle?

Question

Je suis en train de concevoir mon premier vrai modèle dimensionnel de schémas en étoile de style Kimball. J'ai passé à travers beaucoup de ses livres, et je suis à mi-chemin à travers Star Schema - La référence complète par Adamson (que je trouve beaucoup plus pratique et simple que les livres de Kimball). Je n'ai pas été capable de trouver une réponse à cette question. S'il vous plaît aider! Une référence à un article ou un livre serait bien. Dans la modélisation dimensionnelle, quelle est la façon canonique de modéliser la relation entre un fait et sa (es) base (s), projection (s) ou but (s) correspondante (s)? Par exemple, supposons que, pour l'entreprise A, en 2016, ses ventes réelles aient été de 1 million de dollars. C'est clairement un fait.

En outre, supposons qu'en 2014, la société a prévu des ventes de 1,2 million de dollars en 2016 et qu'en 2015, la société a prévu des ventes de 1,1 million de dollars en 2016.

Mais il s'avère que les projections 2014 (plus anciennes) sont celles sur lesquelles les ventes de 2016 doivent être mesurées. En d'autres termes, nous devons spécifier explicitement la relation entre les ventes réelles et leur estimation des ventes projetées. Donc, le «drill-across» ne fonctionnera pas, parce que nous ne sommes pas sûrs de savoir quelles projections sont les bonnes à comparer. Essentiellement, il semble qu'un fait doit être explicitement lié à un autre fait qui, selon la littérature, est verboten?

Alors, laquelle de ces implémentations est canoniquement la meilleure?

1. Créer fact_sales et fact_sales_projection (en même grain). Incluez sales_projection_key dans fact_sales, reliant essentiellement un fait à un fait (ce qui n'est pas une bonne idée).

2. Créer fact_sales et dim_sales_projection (au même grain), alors appelez les dimensions des projections, même si elles contiennent les mêmes numéros que les faits qu'ils soutiennent. Encore une fois incluez sales_project_key dans fact_sales, mais c'est OK maintenant, car sémantiquement, c'est une dimension.

3. il suffit de créer fact_sales avec une dimension appelée qui est Mode de vente soit « réelle » ou « projetée ». Incluez les ventes réelles et projetées dans la même table, avec une clé auto-jointe des enregistrements de ventes «réels» à leur bon enregistrement de ventes «projetées».

4. il suffit de créer fact_sales, mais ajouter des colonnes supplémentaires de fait qui contiennent les projections ainsi que les ventes réelles. Cela se traduira par une duplication considérable des données de projection, mais garantit que les données réelles sont conservées côte à côte avec la projection qui «compte».

Parmi ceux-ci, je suis sûr que # 3 est pas la meilleure solution. J'ai beaucoup hésité à savoir si # 1, # 2, ou # 4 est le meilleur, même si (pour moi) # 1 semble être une meilleure idée que # 2.

Toute contribution est appréciée.En outre, je ne suis pas tout à fait clair si ce type de questions est mieux pour le forum "Stack Overflow" ou le forum "Database Administrators"?

Answer 1

Je vous suggère de modéliser comme il se doit, avec des ventes et des projections dans leurs propres faits. Vous pouvez gérer le mappage impair de la projection de l'année à utiliser dans la requête. Kimball voudrait que vous modéliez des choses réelles.

S'il s'avère que 2014 n'est pas une année mais est plutôt un nom d'un ensemble de prévisions, il doit être modélisé comme tel afin que vous sélectionniez le nom du jeu de prévisions dans la requête.