Dimensió temps: Esquema d'estrella o floc de neu?
- Inicieu sessió o registreu-vos per enviar comentaris
Hola a tots:
Estic preparant el disseny d'un DW per utilitzar-lo amb Pentaho, i en revisar la definició de la dimensió temps m'han sorgit alguns dubtes. Us conte:
És un Dw per anàlisi de vendes. En el model tinc dues taules de fets, una per a les vendes, la granuralidad és a nivell de dia, client, producte, etc, i una altra taula de fets on es registra la informació de la previsió de vendes (aquesta taula té un nivell de granuralidad diferent, sent a nivell de mes i canal de client (que és un dels atributs de la dimensió client)). Les claus de la taula de fets no són per tant les claus de la taula de dimensions, sinó un component dins de la dimensió.

Model Logico Inicial
Tenint en compte això, em sorgeixen bastants dubtes sobre el millor disseny a triar per construir la base de dades:
1) En tenir les taules de fets en un nivell diferent de granuralidad, és necessari o recomanable passar les dimensions implicades a un esquema d'estrella perquè després funcionin correctament les consultes?.
2) Pot donar-se el cas que aspectes de disseny com aquest siguin condicionats per l'eina que utilitzarem posteriorment?. Per exemple, si es que vaig a utilitzar Pentaho, o Microstrategy, etc, pot donar-se el cas que el utilitzar una eina o una altra aquest determinant una forma de modelar en alguns aspectes concrets?. He llegit en algun bloc que per exemple, Microstrategy recomana passar-nos a un esquema de floc de neu (fins i tot els exemples que proporciona amb la seva plataforma, els Analytic Modules, estan construïts d'aquesta manera).
3) ¿Podríem generalitzar que per a un esquema senzill utilitzem sense problemes un esquema estrella total, però en el moment que compliquem el model amb més taules de fets i diferents granuralidades és millor passar-se a floc de neu?. Per seguir la metodologia de Kimball pel que fa a les dimensions conformades cal fer també això, i així poder abordar els models complexos amb múltiples taules de fets?.
Espero que em feu un cable, sobretot aquells que teniu experiència en la construcció de DW. És un tema que per mi és una mica confús (a més en els exemples sempre s'utilitzen esquemes en estrella senzills per il lustrar, que després no corresponen amb la realitat més complexa).
Per liar encara més la història, mirar com Microstrategy implementa la dimensió temps en els seus Analytic Modules, com us deia abans:

No és exactament un floc de neu i des de la data podem arribar al mes, al trimestre o l'any (és un graf ciclic).
En el Bloc la Mina Digital hi ha una interessant entrada sobre el dilema. El curiós és que no es decanta clarament per cap, tot i que dóna unes premisses que ens poden ser útils per la decisió.
Després de donar-li moltes voltes, rellegir en els llibres de referència i buscar informació, crec que ho he entès i una solució seria la següent:
La dimensió Temps tindria la següent estructura, incloent-hi tots els atributs habituals d'una dimensió temps:

Com anem a tenir una taula de fets a nivell de dia (nivell de granuralidad) i dues taules de fets a nivell mes (diferent nivell), necessitarem tenir una taula de dimensió per al mes. Per solucionar aquest problema, tenim dues opcions:
- Construcció d'una dimensió derivada o roll-up: creem un subconjunt de la dimensió original, portant-nos tots els atributs que afecten el nivell de granuralidad o nivells superiors (per exemple, per al mes, ens portem també el trimestre i l'any). És un subconjunt estricte de la dimensió temps. Tindria el següent aspecte:

Dimensió derivada per al mes a la dimensió Temps
- Normalitzar la dimensió i passar-la a floc de neu: aquesta seria l'altra opció. A la imatge següent, podeu veure com quedaria l'esquema en el cas de haguéssim decidit utilitzar aquesta solució. Com veieu, hem creat una dimensió per al mes (la qual hos fa falta per les taules de fets mensuals), ia més hem tret també fora els trimestres i anys (per al cas que en el futur hi hagués altres tipus d'anàlisi que el requerissin).

Model Lògic - Dimension Temps Normalitzada
Per al nostre cas, ens quedem amb l'opció 1, que és la recomanada per Kimball. Com veiem, hem creat un set o subconjunt de la dimensió temps, i tots els atributs tenen els mateixos noms tant en la dimensió original com en la dimensió derivada. Amb aquesta filosofia podem construir dimensions conformades que ens ajuden a implementar el concepte del data warehouse Bus. La tècnica la podem utilitzar per a qualsevol cas que tinguem un diferent nivell de granuralidad. També es podria utilitzar per al cas que tinguem un Datamart on ens portem la dimensió amb la mateixa estructura d'atributs, però limitant el nombre de valors (imaginar que tenim diversos canals de venda i per a una anàlisi concret, només ens portem a la dimensió derivada dels valors de clients d'un d'aquests canals).

Concepte de Dimensió Roll-up o derivada
Per a la construcció de la nova dimensió, podríem utilitzar una vista normal o una vista materialitzada.
Crec que amb això contesto als dubtes que plantegi. No cal passar al model normalitzat quan es planteja el problema de taules de fets amb diferent granuralidad, ia més el mètode descrit el podem utilitzar sempre que es plantegi un escenari similar.
Contingut relacionat

La tasca de Data Profile de SQL Server Information Services emmagatzema els resultats del perfilat en un document XML que es pot examinar amb el Data Profile Viewer. En l'article