Dimensió temps: Esquema d'estrella o floc de neu?

1 reply [Darrer article]
imatge de respinosamilla
Offline
Joined: 17/01/2010
Puntos: 234

 

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ó.

 

 

 

 

 

 

imatge de respinosamilla
Offline
Joined: 17/01/2010
Puntos: 234

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

  • Areas de datos para la carga de un Data WarehouseQuan dissenyem l'arquitectura d'un sistema de Data Warehouse ens hem de plantejar els diferents entorns pels quals han de passar les dades en el seu camí cap al seu Data mart o cub de destinació. Donada la quantitat de transformacions que s'han de realitzar, i que normalment el DWH, a més de complir la seva funció de suport als requeriments analítics, realitza una funció d'integració de dades que han de conformar l'Magatzem Corporatiu i que hauran de ser consultats també de la manera tradicional pels sistemes operacionals, és molt recomanable crear diferents àrees de dades en el camí entre els sistemes origen i les eines OLAP.

    Cadascuna d'aquestes àrees es distingirà per les funcions que realitza, de quina manera s'organitzen les dades en la mateixa, ia quin tipus de necessitat pot donar servei. L'àrea que es troba 'al final del camí' és important, però no serà l'única que emmagatzemi les dades que van a explotar les eines de reporting.

    Tampoc hi ha una convenció estàndard sobre el que abasta exactament cada àrea, i l'obligatorietat d'utilitzar cada una d'elles.  Cada projecte és un món, i influeixen molts factors com la complexitat, el volum d'informació del mateix, si realment es vol utilitzar el Data Warehouse com a magatzem corporatiu o Sistema Mestre de Dades, o si existeixen necessitats reals de suport al reporting operacional...

  • Des de fa un parell de mesos estic treballant en un projecte d'Analysis Services 2005. En l'actualidad m'ocupo del diseny d'indicadors de rendiment (KPI).

    En alguns indicadors surgeix la problemàtica que l'objetiu per definir varia segons l'atribut seleccionat a la dimensió Temps. Per exemple, imaginem-nos un indicador sobre les vendes: no es es mateix l'objetiu mensual de les vendes que el semestral, anual, etc.

    He llegit en certs forums que aconsellen la creació d'un nou grup de mesura per l'objetiu amb diferent granularitat. Si en l'anterior grup de mesura les vendes son diaries, crear un nou amb granularitat mensual. D'aquesta forma deuria crear vistes de la taula de fets que agrupi les vendes mensualment, anualment, etc, i després crear tants grups de mesura i kpi com vistes creades. No sembla ser una solució eficient.

    Un altra forma seria escriure una expresió MDX, que segons l'atribut temporal sel·leccionat variï l'objetiu.

    Voldria compartir aquesta inquietut amb vosaltres i que em poguesiu ajudar a resoldre aquest problema.

    Salutacions i gracies

    juanvi_perez@hotmail.com

  • Com les càrregues d'un Data warehouse es realitzen de manera periòdica, i a més és habitual la creació de taules agregades per millorar l'eficiència i temps de resposta dels nostres informes, un recurs d'optimització física que pot aportar grans millores és la utilització de vistes materialitzades.

    La vista materialitzada no és més que una vista, definida amb una sentència SQL, de la qual a més d'emmagatzemar la seva definició, s'emmagatzemen les dades que retorna, realitzant una càrrega inicial i després cada cert temps un refresc dels mateixos.

    Així, si tenim un Datawarehouse que s'actualitza diàriament, podríem utilitzar vistes materialitzades per anar actualitzant taules intermèdies que alimentin els nostres esquemes de DWH, o directament per implementar taules agregades que es refrescaran a partir de les nostres taules basi. 

    La creació d'aquest tipus de vistes no tan complexa com pot semblar, el més important és tenir clar cada quant temps volem actualitzar la informació de les vistes, i quin mètode de refresc utilitzar.

     

  • Les dimensions lentament canviants o SCD (Slowly Changing Dimensions) són dimensions en les quals les seves dades tendeixen a modificar-se a través del temps, ja sigui de forma ocasional o constant, o impliqui a un sol registre o la taula completa. Quan es produeixen aquests canvis, es pot optar per seguir alguna d'aquestes dues grans opcions:

  • 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 Dataprofiling amb SQL Server 2008 explico com s'utilitza aquesta nova Task de SSIS.

    Encara que aquest mètode sigui molt senzill, de vegades pot no ser suficient. Si es tracta un projecte de qualitat de dades pot interessar, per exemple, emmagatzemar un històric dels perfilats per poder avaluar com ha anat millorant la qualitat de les dades tractades.

    La millor manera de treballar amb dades històriques és utilitzant una base de dades i emmagatzemant aquestes dades en taules, sobre les quals es podran fer les consultes, informes i comparatives que calgui. Per aconseguir-ho l'únic que caldria és passar a taules les metadades que la tasca de perfilat ha emmagatzemat en el fitxer XML.