Tietomallinnus – Osa 4: Lumihiutalemalli (Snowflake schema)

Jani Savolainen

Jatkan jälleen blogisarjaani tietomallintamisesta. Edellisessä postauksessani kuvasin tähtimallin keskeisiä elementtejä. (Tietomallinnus – Osa3: Tähtimalli (Star schema)). Tänään läpikäyn lumihiutalemallia (=Snowflake schema). Alla linkit muihin tietomallinnuksen blogisarjan blogeihin.

• Tietomallinnus – Osa 1: Intro
• Tietomallinnus – Osa 2: Kolmas normaalimuoto (OLTP)
• Tietomallinnus – Osa 3: Tähtimalli (Star schema)
• Tietomallinnus – Osa 4: Lumihiutalemalli (Snowflake schema)
• Tietomallinnus – Osa 5: Enterprise Data Warehouse BUS
• Tietomallinnus – Osa 6: Data Vault

Lumihiutalemallin (Snowflake schema) hyödyt

Lumihiutalemalli (Snowflake schema) on tietokantojen mallinnustapa, joka on erityisen hyödyllinen tietyissä tietovarasto- ja analytiikkasovelluksissa. Tässä on keskeisiä hyötyjä lumihiutalemallin käytöstä:

1. Tiedon normalisointi ja redundanssin vähentäminen

• Tietojen normalisointi: Lumihiutalemalli hyödyntää korkeamman asteen normalisointia, mikä tarkoittaa, että dimensioiden taulut on jaettu alidimensioihin. Tämä vähentää tietojen redundanssia ja parantaa tietojen eheyttä.
• Pienempi tietokantakoko: Koska tietojen redundanssi on minimoitu, tietokannan fyysinen koko on usein pienempi kuin tähtimallissa, mikä voi säästää tallennustilaa ja kustannuksia.

2. Parannettu tietojen eheys

• Tietojen eheys: Koska lumihiutalemallissa tiedot ovat normalisoituja, yhdenmukaisuuden varmistaminen on helpompaa. Tämä vähentää virheiden ja ristiriitaisten tietojen riskiä.
• Yksinkertaistettu tietojen hallinta: Normalisoidut taulut helpottavat tietojen päivittämistä ja ylläpitoa, koska tiedot ovat hajautettu useisiin liittyviin tauluihin.

3. Tehokkaampi tietojen hallinta ja kyselyiden tarkkuus

• Tarkemmat kyselyt: Lumihiutalemallin normalisointi mahdollistaa tarkemmat kyselyt, koska se tarjoaa yksityiskohtaisempaa tietoa dimensioista ja niiden alidimensioista.
• Tehokkaat liittymät: Vaikka lumihiutalemalli saattaa vaatia useampia liittymiä (joins), se hyötyy usein siitä, että liittymät ovat tarkempia ja hyödyntävät pienempiä tauluja, mikä voi joissakin tapauksissa parantaa suorituskykyä.

4. Joustavuus ja laajennettavuus

• Modulaarisuus: Lumihiutalemalli on modulaarinen ja helposti laajennettavissa uusilla dimensioilla ja alidimensioilla ilman suuria muutoksia olemassa olevaan rakenteeseen.
• Joustavuus: Normalisoidun rakenteen ansiosta lumihiutalemalli voi olla joustavampi käsiteltäessä monimutkaisia liiketoimintaprosesseja ja -sääntöjä.

5. Parempi analytiikka monimutkaisille tietorakenteille

• Monimutkaiset tietorakenteet: Lumihiutalemalli soveltuu hyvin tilanteisiin, joissa on tarpeen käsitellä monimutkaisia ja hierarkkisia tietorakenteita. Tämä mahdollistaa tarkemman analyysin ja raportoinnin.
• Hierarkkisten suhteiden hallinta: Lumihiutalemalli tukee hierarkkisten suhteiden ja monitasoisten dimensioiden mallintamista, mikä voi olla hyödyllistä monimutkaisissa liiketoimintaskenaarioissa.

Yhteenveto

Lumihiutalemallin käyttö tietokantojen mallinnuksessa tarjoaa etuja erityisesti tietojen normalisoinnin, eheyden, joustavuuden ja monimutkaisten tietorakenteiden hallinnan näkökulmasta. Vaikka se saattaa vaatia enemmän liittymiä kyselyissä verrattuna tähtimalliin, sen tarjoamat hyödyt tietojen hallinnassa ja analytiikassa voivat olla merkittäviä monissa käyttötapauksissa.

Lumihiutalemallin perusteet

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 tekniset 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