Tietomalli on kuvaus siitä, miten data on järjestetty tauluihin, sarakkeisiin ja niiden välisiin relaatioihin. Tällä sivulla tietomalli tarkoittaa datan tietomallia: tietokannan, tietovaraston ja Power BI -raportoinnin rakennetta. Rakennusalan tietomalli (BIM, Building Information Model) on eri asia, eikä siitä kerrota tässä.
Tämä sivu on aloituspiste koko aiheeseen. Se määrittelee käsitteen, käy läpi tietomallin kolme tasoa ja neljä osaa, vertaa yleisimmät mallityypit ja kertoo mistä tietomallinnus aloitetaan. Jokaisesta osasta on oma syväsivunsa, ja termit löytyvät selitettyinä datan mallinnuksen termistöstä.
Tietomalli on datan pohjapiirustus. Se määrittelee mitä käsitteitä data sisältää (asiakas, tuote, myynti), miten ne liittyvät toisiinsa ja miten ne tallennetaan. Sama data voidaan järjestää kymmenellä eri tavalla, ja järjestys ratkaisee kuinka nopeasti sitä voi kysellä, kuinka paljon se vie muistia ja kuinka moniselitteisiä vastauksia siitä saa.
Tietomallinnus on työ, jossa tuo järjestys päätetään. Se ei ole tekninen yksityiskohta vaan liiketoimintapäätös: malli määrää, mihin kysymyksiin dataa voi kysyä ilman erillistä kehitysprojektia.
Nämä kolme sekoitetaan jatkuvasti keskenään, vaikka ne ovat eri asioita. Tietomalli on rakenne eli suunnitelma. Tietokanta on ohjelmisto, joka tallentaa datan tuon rakenteen mukaisesti. Tietovarasto on käyttötarkoitus: raportointia varten koottu ja historioitu kokonaisuus, joka on toteutettu tietokantaan jonkin tietomallin mukaan.
Sama tietomalli voidaan toteuttaa SQL Serveriin, Fabriciin tai Power BI:n semanttiseen malliin, ja se on edelleen sama malli. Siksi mallia kannattaa suunnitella tuotteesta riippumatta, vaikka toteutus lopulta sidotaan yhteen alustaan.
Tietomalli kuvataan kolmella tarkkuustasolla. Kaikki kolme kuvaavat samaa dataa, mutta eri yleisölle.
| Taso | Vastaa kysymykseen | Sisältää | Yleisö |
|---|---|---|---|
| Käsitemalli (Conceptual) | Mistä liiketoiminta puhuu? | Käsitteet ja niiden suhteet: asiakas tilaa tuotteita. Ei tauluja, ei tietotyyppejä. | Liiketoiminta |
| Looginen malli (Logical) | Mihin tauluihin data jaetaan? | Taulut, sarakkeet, avaimet ja relaatioiden kardinaliteetit. Tuoteriippumaton. | Mallintaja |
| Fyysinen malli (Physical) | Miten se toteutetaan tässä tuotteessa? | Tietotyypit, indeksit, partitiot, pakkaus. Riippuu tuotteesta (SQL Server, Fabric, Power BI). | Toteuttaja |
Käytännössä useimmat BI-projektit hyppäävät suoraan loogiseen malliin. Se toimii niin kauan kuin käsitteet ovat kaikille selviä. Jos liiketoiminnalla ja IT:llä on eri käsitys siitä, mitä "asiakas" tarkoittaa, käsitemalli on nopein tapa löytää se erimielisyys ennen kuin se on koodattu tauluihin.
Analyyttinen tietomalli koostuu neljästä osasta. Jokaisella on oma tehtävänsä, ja jokaisesta on oma sivunsa.
Analyyttisessa käytössä vaihtoehtoja on käytännössä neljä. Ne eivät ole tasavertaisia.
| Malli | Rakenne | Milloin | Analytiikkakäytössä |
|---|---|---|---|
| Tähtimalli | Faktataulu keskellä, dimensiot suoraan sen ympärillä | Lähes aina analyyttisessä mallinnuksessa | Suositeltu oletus |
| Lumihiutalemalli | Dimensiot normalisoitu useaan tauluun | Tietovarastossa, jossa toisteisuutta halutaan välttää | Toimii, mutta litistä dimensiot ennen latausta |
| Litistetty yhden taulun malli | Kaikki sarakkeet yhdessä leveässä taulussa | Kertaluonteinen analyysi, pieni aineisto | Moninkertaisesti muistia, pahimmillaan 3× hitaampi kuin tähtimalli |
| Sekasikiömalli | Orgaanisesti kasvanut sekoitus kaikkea | Ei koskaan tarkoituksella | Moniselitteinen, tuottaa vääriä lukuja |
Erot eivät ole Power BI:n erikoisuus. Sama pätee tietovarastoissa ja analytiikkavälineissä yleisesti: huonosti rakennettu malli lukee enemmän dataa kuin kysymys vaatii, vie enemmän muistia ja laskee hitaammin riippumatta siitä, pyöriikö se Fabricissa, Snowflakessa, SQL Serverillä vai Power BI:ssä. Huono malli on huono kaikkialla — alusta vaihtaa vain sitä, kenen laskussa se näkyy.
Kun mallissa on useampi liiketoimintaprosessi — esimerkiksi myynti ja budjetti — niitä ei yhdistetä
liittämällä faktatauluja toisiinsa. Ne yhdistetään yhteisillä dimensioilla: sama
d_tuote ja sama d_aika palvelevat molempia faktatauluja.
Tämä on ainoa turvallinen tapa yhdistää tietomalleja. Faktataulujen suora relaatio tekee mallista moniselitteisen, jolloin Power BI joko kieltäytyy luomasta relaatiota tai laskee hiljaisesti väärin. Jos sama käsite on kahdessa mallissa eri nimillä ja eri avaimilla, työ alkaa avainten yhtenäistämisestä, ei relaatioiden piirtämisestä.
Järjestys on tärkeä. Jokainen askel rajaa seuraavaa, ja väärässä järjestyksessä tehty työ joudutaan tekemään uudelleen.
Myyntisumma, ei SLS_AMT_EUR.