Comment concevoir une table de dimension rétrécie pour les dates dans l'entrepôt dimensionnel et l'utiliser dans SSAS?

Je travaille dans une situation où nous passons d'un tas de tables de faits transactionnelles à une image plus compliquée avec des agrégats, des instantanés, etc. Dans le passé, il y avait quelques cas où datatables devaient être agrégées par mois, mais les développeurs précédents venaient de placer la key du premier jour du mois auquel ils appartenaient dans une colonne de la table des faits et la pointaient vers la dimension de date habituelle. Cela semble fonctionner, nous avons des hiérarchies jour / mois / année dans les cubes pour chaque dimension de date, et les users se débrouillent bien quand ils ont besoin de regarder les choses par mois.

Quand je lis – surtout le travail de Kimball, mais aussi d'autres guides – on suggère que nous devrions utiliser une «dimension rétrécie» dans ces cas. Le groupe Kimball le mentionne même spécifiquement en ce qui concerne la dimension du mois . Mais je ne trouve vraiment pas beaucoup d'informations sur leur mise en œuvre au-delà de cet article, et de brèves notes qui semblent en reformuler certaines parties.

Une de mes préoccupations particulières est que pour l'instant, les personnes utilisant nos cubes ont l'habitude d'avoir une dimension de date pour chaque type de date avec des hiérarchies année-mois-jour, et elles ne font que descendre au niveau du mois quand c'est nécessaire . Si cela doit aboutir à une dimension séparée avec une hiérarchie d'année-mois, il semble que ce soit un fouillis indésirable. Mais est-ce l'intention?

Les deux derniers paragraphes de l'article lié sont la seule chose que j'ai trouvée concernant la façon dont cela devrait fonctionner dans la couche de présentation, et je ne comprends pas ce qu'ils essaient de décrire. Il semble court quelques exemples pour expliquer comment cela devrait apparaître dans un cube. Normalement, je ne ferais que des essais et des erreurs, mais les timeouts sont très serrés. Alors…

Si je fais cela, quel est l'affichage prévu dans le cube? Aurais-je deux dimensions de date distinctes, dont une qui ne va qu'au mois?
Si ce qui précède est correct, y a-t-il vraiment beaucoup de points à cela, étant donné que les gens peuvent actuellement heureusement interroger les choses à un niveau mensuel sans cela? J'ai l'printing de manquer les avantages réels. Je peux voir que c'est plus sémantiquement correct (nous sums au niveau du mois, donc le premier jour du mois est hacky et montrera des attributes sans rapport), mais avec les users qui sont déjà habitués à cela, je ne suis pas convaincu que passer plus de time à ce sujet maintenant. Je peux voir qu'il pourrait mieux fonctionner étant donné que ce serait une dimension plus petite, mais nous n'avons pas de problèmes de performance tels quels. Est-ce que je manque quelque chose?
Si j'accomplis les changements, y a-t-il des astuces pour que la dimension rétrécie fonctionne dans le cube? Normalement, je peux faire des searchs en ligne jusqu'à ce que j'aborde les deux meilleures options, mais il n'y a vraiment pas grand-chose, et j'apprécierais d'entendre quelqu'un qui a déjà fait ça. Ne pas chercher quelque chose d'énorme, mais quelque chose soit écrit un peu plus techniquement que cet article ou un mini-exemple me permettrait probablement de me faire une idée plus claire de ce qui doit être fait et pourquoi. L'article de Kimball m'a particulièrement troublé lorsque j'ai discuté de la nécessité de joindre la dimension de base à la dimension rétrécie afin de voir les attributes.

Les deux premiers points sont les plus importants, parce que je saurais si je dois apporter des modifications à l'entrepôt de données et les faire si c'est le cas – je serais très heureux de pouvoir répondre à ces questions, même si vous ne pouvez pas couvrir le troisième point.

Ce n'est pas une réponse ni une réponse de Cognos. À titre de comparaison, je veux souligner comment les faits multi-grains sont modélisés dans d'autres outils.

http://www-01.ibm.com/support/knowledgecenter/SSWGNW_8.0.0/com.ibm.swg.im.cognos.ug_best.8.4.0.doc/ug_best_id1339multi-factmulti-grainquery.html%23multi-factmulti- grazzery

http://www.cognoise.com/index.php?topic=17992.0

Dans le premier lien:

La table mensuelle a une key de mois et est jointe au mois dans la table du calendar
La table quotidienne a une key de jour et est jointe à la même table de calendar
Ce que le lien ne montre pas, c'est que vous définissez les niveaux hiérarchiques en arrière-plan afin que l'outil sache automatiquement qu'il ne faut pas countr deux fois datatables de niveau mensuel
Le résultat est que l'outil sait automatiquement comment remonter les faits

Je ne suis pas un expert SSAS mais il semble qu'il ne supporte pas ce genre de fonctionnalité.

Si tel est le cas, il me semble qu'il ne sert à rien de modéliser correctement datatables. Par correctement je veux dire assigner un mois particulier à un fait qui est seulement défini au niveau mensuel.

Jusqu'à présent, je ne vois aucun problème à modéliser cela en assignant un jour particulier dans le mois. Si la table de faits est au même niveau (mensuel), nous soaps qu'une date dans le tableau représente un mois. À tout le less, vous pourriez vouloir mettre une contrainte de vérification qui assure que c'est le premier du mois, donc il n'y a pas d'ambiguïté.

Le résultat est lorsque vous observez des faits mensuels et quotidiens au niveau mensuel, tout est cohérent. Lorsque vous observez des faits mensuels et quotidiens à un niveau quotidien, vous voyez un gros morceau au début du mois. Si vous pouvez utiliser SSAS pour masquer la mesure à ce niveau .. problème résolu.