Free Press

Dimensionaalinen mallinnus (DM) on osa Ralph Kimballin kehittämää Business Dimensional Lifecycle -metodologiaa, joka sisältää joukon menetelmiä, tekniikoita ja käsitteitä käytettäväksi tietovarastojen suunnittelussa. Lähestymistavassa keskitytään liiketoiminnan keskeisten liiketoimintaprosessien tunnistamiseen ja niiden mallintamiseen ja toteuttamiseen ensin ennen uusien liiketoimintaprosessien lisäämistä, eli alhaalta ylöspäin suuntautuvaan lähestymistapaan.

Mitkä ovat tietovaraston mallintamisen tavoitteet?

Rossin ja Kimballin asettamat tavoitteet ovat suoraviivaisia:

• tieto on helposti saatavilla
• tieto esitetään johdonmukaisesti
• sopeutuva ja vastaanottavainen muutoksille
• tieto esitetään oikea-aikaisesti
• tietovarantojen suojaaminen

.

• palvelevat arvovaltaisena ja luotettavana perustana paremmalle päätöksenteolle (yksi totuuden lähde Data Engineering -kielellä)
• VIP:ien on hyväksyttävä järjestelmäsi

Jos olet työskennellyt tai käyttänyt ETL-järjestelmää, olet varmasti huomannut, että tietojen yhdenmukaisuus saavutetaan vaatimustenmukaisilla toimenpiteillä, ETL-syklien tarjoama ajantasaisuus ja mukautuvuus riippuvat pitkälti myös ETL-suunnittelusta.

Miksi mallintaminen?

Tietoinsinöörinä tunnet SQL:n erittäin hyvin ja voit luultavasti kirjoittaa SQL-kyselyitä koko päivän. Et kuitenkaan voi olettaa, että tyypillinen loppukäyttäjä on asiantuntija SQL-kyselyjen kirjoittamisessa. Tavoitteenamme on siis rakentaa DW niin helposti, että analyytikot voivat kirjoittaa analyysikyselyitä nopeasti ja tehokkaasti.

Tekoja, joita et haluaisi analyytikkojesi tekevän:

• Tunnukseen perustuvat kyselyt
• Kaskadoituvat ulommat yhteenliitokset(edes sinä et haluaisi tehdä sitä)
• ryhmittäiset tai yhdistetyt useat alikyselyt
• rekursiiviset alikyselyt(käypäs vain katsomassa Hackerrank SQL:tä niin ymmärrät tuskan)
• Kyselyjen korrelointi:
• Joins ilman PK/FK: jopa minulle(1.5 vuoden DE-kokemus), sitä on vaikea visualisoida.

Mitä voisi ja pitäisi odottaa analyytikoilta:

• yksinkertaiset joinit
• sarakkeet, joissa on nimet ja kattava teksti
• yksinkertainen aggregaatio
• analyyttiset ikkunafunktiot
• DISTINCT

Huomaa, että edellä mainitut kohdat eivät ole helppoja, ja että järjestelmäsi pitäisi olla riittävän skaalautuva kaikenlaisiin kyselyihin.

OLTP-tietokannat muutetaan faktoiksi ja ulottuvuuksiksi edellä mainittujen tavoitteiden vuoksi.

Transaktiotietokannoista faktoihin siirtyminen

Useimmat yritykset mittaavat menestystään ja tehokkuuttaan mittaamalla tietyntyyppisiä tietoja. Nämä tiedot kuvaavat todellista liiketoimintaa ja edistymistä. Näitä tietoja kutsutaan faktoiksi.

OLTP-suuntautuneet tietokannat tallentavat transaktioita kerrallaan, ikään kuin tapahtumavirtaa, mutta keskitetysti transaktioiden ympärille. DW on erilainen. DW:n ei tarvitse tallentaa yksityiskohtia transaktiotasolla. DW:ssä on oltava faktoja liiketoiminnan eri kriteereistä. DW:n on aggregoitava (tai annettava analyytikoiden aggregoida) liiketoiminnan parantamiseen tarvittavat tiedot. Niinpä redundanssi on DW:ssä anteeksiantamaton synti.

Mitä ovat toimenpiteet ja miksi faktataulukot pitäisi täyttää niillä?

Tietovarastossa toimenpide on ominaisuus, josta voidaan tehdä laskelmia.

Toiminnallisista tietovarastoista saamiemme faktojen mukana on jonkin verran lisätietoa, joka tyypillisesti summataan analyysissä. Nämä ovat faktaa koskevia näkökohtia, joiden avulla analyytikko tai analyysia tarkasteleva johtohenkilö näkee faktan arvon.

Miksi sinun on ylläpidettävä johdonmukaista rakeisuutta?

Siten voit varmistaa, että järjestelmäsi voi laillisesti korreloida ja aggregoida eri faktoja.

Mutta aina ei ole mahdollista saada dataa atomitasolla. Tämän kuilun kuromiseksi umpeen on siis kaksi menetelmää:

• Periodiset tilannekuvatietotaulukot
• Accumulating Snapshot Fact Tables

Periodiset tilannekuvatietotietotaulukot

Nimensä mukaisesti ne kerätään säännöllisin väliajoin. Kaasun kulutus, tilintarkastus ja tarkastukset ovat joitakin tiedonkeruun tapauksia, joille on otettu käyttöön jaksoittaiset tilannekuvat.

Kertyvät tilannekuvatietotaulukot

Kun liiketoiminnan suorituskykymittari on monivaiheisen liiketoimintaprosessin loppuunsaattamisnopeus, saatat haluta kaapata koko prosessin jyvällä ja kirjata prosessin alun, loppuunsaattamisen ja niiden välissä olevat vaiheet. Tämä voi olla tapahtumarakeinen, mutta siinä on paljon toimenpiteitä välissä. Käytät siis kertyviä tilannekuvatietotaulukoita vastataksesi monimutkaisiin kysymyksiin liiketoimintatiedustelussa, jossa tosiseikkojen välillä kuluu aikaa. Yksi hyvä esimerkki olisi faktataulukon rivi kanavoileivän tilaamisestasi ja faktataulukon rivi pussin ojentamisesta auton ikkunan läpi McDonald’sin drive-thru-asemalla.

Faktojen paikantaminen dimensioiden avulla

Sinun ja analyytikkojesi on tiedettävä, miten faktoja voidaan kysyä ja suodattaa, jotta niistä voidaan johtaa liiketoimintatietoa. Tätä tarkoitusta palvelevat dimensiot.

Dimensioiden piirtäminen viite- ja raakametatiedoista

Dimensiot luodaan lähes aina sijaisavaimella; sijaisavaimeen viitataan luonnollisesti fakta-taulukon vieraan avaimen (tai -avainten) avulla. Haemme taulusta etsimällä ne ulottuvuudet, joista olemme kiinnostuneita. Kaikki muut faktojamme kuvaavat tiedot, kuten aikaleimat, asiakasagentit, myymälän sijainti, tuote ja asiakas, muutamme ulottuvuuksiksi.

Dimensiomallinnuksen kauneus on siinä, että faktoja ei määritellä ensisijaisilla avaimilla tai millään yksilöllisellä tunnisteella, vaan ne määritellään ulottuvuuksien yhdistelmällä. Tästä syntyy Star Schema.

On erittäin tärkeää, että ulottuvuuksissamme on yksikäsitteisyys. Kun joudumme tekemään tietokantoja koskevia kyselyjä, ulottuvuusyhdistelmien väliset kaksoiskappaleet johtavat katastrofiin. Jos se ei onnistu, lisää tai aggregoi ulottuvuuksia, jotta niistä tulee ainutlaatuisia.

Hierarkia ulottuvuuksissa

Harkitse seuraavia kahta kuvaa.

Analyytikon elämä on helppoa, jos asetat hänelle toisen ulottuvuustaulukon.

Toisen taulukon avulla sinulla on siis seuraava hierarkia:

Hierarkioita on kaikenlaisia – monihierarkioita, yksittäishierarkioita jne. En käsittele niitä tässä blogikirjoituksessa.

Yksi asia, jonka haluaisin huomauttaa, on se, että aikaulottuvuus on todellinen riesa. Sinun on huolehdittava maagisista päivistä, verokalenterista, aikavyöhykkeistä, sykleistä (voitto neljännesvuosittain -tyypeistä). Äläkä ole surkea tai liian luottavainen tässä asiassa, edes aikasarjatietokannat eivät auta sinua hierarkioissa, jos ETL:si on sekaisin. Kannattaa tutustua Outrigger-ulottuvuuksiin. On myös tilanteita, joissa yksi ulottuvuus on luonnollisesti riippuvainen toisesta. Tällaisessa tapauksessa suunnittelijat voivat laittaa vierasavaimen toisesta ulottuvuudesta toiseen. Tämä on niin sanottu outrigger-ulottuvuus. Kalenteriulottuvuuksissa tämä on hyvin yleistä.

Et voi käyttää outrigger-ulottuvuudessa eri jyvällä olevaa päivämäärää kuin faktataulussa käytettäviä päivämääriä. Et voi sallia aggregointia outrigger-ulottuvuuksien yli. Tarvittaessa voit peittää numeeriset arvot ulokkeessa tekstimuotoisilla etu- tai jälkiliitteillä tämän estämiseksi.

Hitaasti muuttuvat dimensiot

Niin paljon kuin haluaisinkin kirjoittaa siitä, olen silti sitä mieltä, että lukijoideni on parempi ymmärtää tämä käsite perusteellisesti tästä.

En käsittele Snowflake-ulottuvuuksia, mutta huomautan vain, että ne ovat edelleen käytössä OLAP-tietokannoissa.

Integroi Big Data ETL-järjestelmään

Käsittelet taulukkomuotoista Big Dataa siten, että se on hankittu jossakin tavallisessa Extract-vaiheessa. Sovellat siihen siis samoja vaiheita kuin Transformissa:

1. Datan puhdistus
2. Yksiköiden ja formaattien mukauttaminen
3. Duplikaation poistaminen
4. Restrukturointi
5. Staging

Yhteenveto

Haluin ymmärtää tietokantojen suunnittelun teoreettisia näkökohtia, mikä johti siihen, että luin Rossin ja Kimballin kirjan. Sitten tulin uteliaaksi vetämään eroja ja analogioita heidän menetelmissään ja nykypäivän johtavien datapohjaisten yritysten, kuten Netflixin, Airbnb:n, Uberin jne. menetelmissä.

Tässä etsinnässä voin reilusti sanoa, että dimensiomallinnuksen strukturoitu muoto on suositeltavampi kuin pelkkä hardcore ETL. Koska tällä tavoin poistat riippuvuuden sinusta, BI-tiimisi ei soita sinulle Slackiin luodaksesi uuden DAG:n jokaista toista oivallusta varten, vaan oikealla mallintamisella annat heille mahdollisuuden toimia ja tutkia vapaasti ilman sinun tarpeitasi.

Jätäthän palautetta siitä, miten voisin parantaa, olen varma, että tämä ei ollut parasta luettavaa. Kiitos ajastanne.

Footnotes

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross ja Kimball, kpl 2 ja kpl 18

Kimball/Ross s. 103-109