Tietomallinnus – Lumihiutalemalli (Snowflake schema)
Jatkan jälleen blogisarjaani tietomallintamisesta. Edellisessä postauksessani kuvasin tähtimallin keskeisiä elementtejä. (Tietomallinnus – Tähtimalli (Star schema)). Tänään läpikäyn lumihiutalemallia (=Snowflake schema).
Lumihiutalemalli on eräs fyysisen tietomallintamisen menetelmä, jolla voidaan rakentaa tietovarastoja ja data martteja. Se on läheistä sukua tähtimallille ja hieman etäisempi esi-isä data vaultille.
Itse miellän lumihiutalemallin skeeman eräänlaiseksi OLTP-mallin ja tähtimallin välimuodoksi. Sillä kun on piirteitä sekä ei-toiminnallisia ominaisuuksia molemmista. Lumihiutalemallissa on enemmän tauluja sekä niiden välisiä liitoksia kuin tähtimallissa, toisin sanoen malli on normalisoidumpi kuin tähtimallissa mutta denormalisoidumpi kuin OLTP-mallissa: Siinä missä tähtimallissa kunkin faktataulun ympärille generoituu yksiulotteisia ”tähden sakaroita” eli dimensioita, lumihiutalemallissa normalisoidaan dimensiorakennetta niveltämällä tähtien sakaroihin ns. ”alidimensioita”, aivan kuten lumihiutaleen kiderakenteessa. Esimerkiksi; sen sijaan, että kasvattaisimme faktataulun viiteavainmäärää, luomme uuden alidimension jatkoksi tarkimman granulariteetin omaavalle dimensiolle, johon viittaamme tästä karkeamman granulariteetin dimensiosta. Tässä reunaehtona on, että dimensiot liittyvät loogisesti toisiinsa, kuten esim. Tuotedimensio ja Tuoteryhmädimensio. (Tuotteella on yksi Tuoteryhmä ja Tuoteryhmässä voi olla monta Tuotetta).
Lumihiutalemallin keskeiset sudenkuopat
– Erillisiä hierarkioita ei kannata yleensä purkaa lähinnä suorituskykynäkökulmasta omiksi lumihiutaleikseen, ellei tällä sitten saavuteta esimerkiksi konkreettista tilansäästöä tai esimerkiksi käytettävä BI-teknologiaratkaisu suosii ko. mallia.
– Lumihiutalemallissa taululiitosten määrä aina kasvaa ja komplisoi tietomallia sekä hidastaa SQL-kyselyitä konkreettisesti. Siksi se sopii vain tiettyihin käyttötapauksiin.
– Lumihiutalemallin ylläpitäminen voi ajan saatossa tulla kankeaksi ja työlääksi ETL-prosessin osalta, eritoten mikäli lähdejärjestelmien tietomallit elävät paljon.
Lumihiutalemallin hyödyt
– Tilansäästöt voivat olla merkittäviäkin tietyissä käyttötapauksissa.
– Eräs lumihiutalemallin eduista on ns. ”bridge”-tekniikka eli siltaus, jonka avulla voidaan purkaa monen suhde moneen -relaatio järkevästi siten, että meillä on faktataulu, johon kytketään dimensiotaulu siten, että alidimension ja dimension välille syntyy bridgetaulu, joka normalisoi monen suhde moneen -relaation viittaamalla yhtä aikaa dimensioon ja sen alidimensioon; näin atomisoiden dimensio-alidimensio -arvoparit. Esimerkiksi; mikäli meillä on Tuote joka voi kuulua moneen Tuoteryhmään ja Tuoteryhmä joka voi linkittyä moneen Tuotteeseen. Edelleen; bridgetauluun voidaan tuoda ns. ”weighting factor” -kenttä, joka pilkotaan alidimension esiintymien suhteessa per dimensio tietuetasolla murto-osaksi sadasta prosentista. Esimerkiksi; jos meillä on vaikkapa sairaalajärjestelmässä potilas, joka saa 3 diagnoosia ajanhetkellä t, on hänen diagnostinen weighting factorinsa 100% / 3 = 0,333… (desimaalilukuna). Tällöin voidaan laskea faktoja sekä dimension että alidimension suhteen, koska datan summautuvuus on grainin suhteen vakio (3 x 0,333… = 1).
Esimerkkimme lumihiutalemallista.
Oheisesta tietomallista voitaisiin kysellä varsin triviaalisti vaikkapa laskutustiedot potilaittain ja kohteittain tai vastaavasti summata vastaavat tiedot diagnooseittain. Mikäli sama tulos haluttaisiin saavuttaa tähtimallilla, voisi vaihtoehtona olla esim: 1) syventää granulariteettia ja linkittää diagnostinen dimensio suoraan faktan piiriin tai: 2) luoda diagnostisia filtterikenttiä potilasdimensioon, joka voisi toisaalta johtaa hankalasti ylläpidettävään tietomalliin, koska diagnoosit voivat elää ajan funktiona sekä edelleen: 3) luoda useampi faktataulu.
Yhteenveto
Lumihiutalemallilla voi olla paikkansa silloin kun tietomalli on todella kompleksinen tai datamäärä muutoin nousee tähtimallin kanssa ongelmaksi. Normalisoinnilla on kuitenkin hintansa, eritoten ylläpidettävyyden ja SQL-kyselyiden suorituskyvyn suhteen.
Haluatko keskustella tietomallintamisesta? Ote yhteyttä niin jutellaan.
Jani K. Savolainen
jani.savolainen@dbproservices.fi
0440353637
CEO & Chairman
DB Pro Services Oy
