Kimball Design Tip #2: Multiple Time Stamps

**scharly3** · 18/01/2012, 15h40

Bonjour bonjour,

Petite question théologique (et oui Kimball étant notre dieu ...)
Dans ce design Tip de Kimball http://www.kimballgroup.com/html/des...ltipleTime.pdf
il est dit (et aussi dans le data warehouse lifecycle toolkit ...) qu'il faut faire une vue par utilisation de la dimension date :

The single underlying Time dimension is "exposed" to the fact table through five views, which makes each instance of the Time dimension semantically independent, as they must be.

Doit-on prendre cela au sens strict et avoir 5 vues dans notre DSV (Niveau lisibilité ... ça me donne un peut envie de me crever un œil) ou alors peut-on considérer que d'utiliser 5 fois notre dimension temps dans notre cube dans notre "Dimension Usage" revient à avoir 5 "vues" sachant que dans ce cas là, notre DSV contiendra une seule dimension Temps qui sera lié à nos 5 champs?

Pas très clair sur ce coup là ...

**FrancoisJehl** · 18/01/2012, 16h21

Le truc c'est que les design tips de Kimball ~~ça se barre parfois dans le bullshit pour chef de projets~~ sont souvent intéressants mais parfois assez high level, donc pas forcément à appliquer tel le Coran la Bible ou que sais-je.
Effectivement, si on expose le DW bien fait, avec des tables nommées par des entités métiers, des noms de colonnes jolis à un User final, ça peut être sympa selon les outils frontaux et si ceux ci gèrent cela d'exposer les role playing via des vues. Mais ça dépendra de l'outil, du contexte. En fait les RPD dans SSAS jouent exactement le même rôle et infine disent la même chose: on expose la même Time Dimension en termes structurels mais avec un nom spécifique à l'instance qu'elle désigne.
Enfin moi je vois ça comme ça mais il y a surement d'autres avis

**scharly3** · 18/01/2012, 16h42

Merci de ta réponse !
C'est aussi mon avis, SSAS gère cela très bien ...
Après un des avantages de la méthode exposé par Kimball, est de pouvoir nommer les champs plus spécifiquement (DimDateDebut.Date et DimDateArrive.Date qui apparait de la même manière dans un TCD sous Excel ... cf Pièce jointe)

**FrancoisJehl** · 18/01/2012, 16h49

Oui. C'est pour ça qu'on finit souvent par dupliquer les .dim à cause de cette ##### d'inaptitude de SSAS à renommer les attributes des CubeDimensions. Cette demande est sur Connect (et sur la wishlist de

Chris Webb

) depuis le paléolithique et serait super simple à implémenter. Pour ceux qui connaissent les CubeDimensions définissent un libellé propre aux attributs dans le modèle objet de SSAS et... ça n'a jamais été fait.

https://connect.microsoft.com/SQLSer...ying-dimension

**scharly3** · 18/01/2012, 17h09

Publié par Microsoft le 18/08/2006 à 16:43
This is a good suggestion. We will consider it for the next release of SQL Server.

Ah et bien c'est bon alors ça sera dans la version 2008 de SQL serveur ! Euh ...

Merci pour toutes ces précisions !

**FrancoisJehl** · 18/01/2012, 17h52

Ah et tant qu'à citer Chris Webb encore une fois, et quitte à parler naming, juste une remarque (cf ton screenshot) je pense qu'on ne doit jamais nommer les dimensions DimMachin: on sait que ce sont des dimensions via les métadonnées de SSAS, donc c'est inutile et redondant de l'exposer à l'utilisateur (ce qui n'est pas le cas des tables SQL qui elles doivent être non ambiguëes et doivent s'appeller un truc comme Fact ou Dim).

Bon c'est juste pour rajouter des trucs un peu HS à cette discussion de best practises

The commonest example of bad practice that I see is having Analysis Services dimensions called “Dim Something” – “Dim Product”, “Dim Time”, “Dim Customer” and so on. Hands up who has a cube with dimensions named like this? OK, feel ashamed. Ask yourself, do your users want to go to the CEO with an Excel spreadsheet containing column headers like this? No, of course not, they want to see “Product”, “Time” and “Customer”. They know these things are dimensions already and the “Dim” bit is totally redundant.

http://cwebbbi.wordpress.com/2010/04...ysis-services/

**scharly3** · 18/01/2012, 18h09

Je suis absolument d'accord avec toi! Mais dans un monde parallèle ou la MOA prend les décisions qui nous incombent étrangement cela donne ... ça ! Drôles d'habitudes non ? J'en ai plein des comme ça si tu veux ! (Quand dans les spécifications fonctionnelle il est écrit : Faire une hiérarchie ... dans un cube ... avec tel et tel Dimensions ... c'est étrange non ?

)

N.B.: Rejeter la faute c'est mal

J'assume complétement d'avoir lâché l'affaire dans le combat VS Moa sur cette mission ! Fouettez moi svp!