Tietojen mallinnus: tekniikat, tyypit ja tosielämän käyttötarkoitukset selitettynä

Etusivu » Python » Tietojen mallinnus: tekniikat, tyypit ja tosielämän käyttötarkoitukset selitettynä

Tietomallinnus on yksi niistä tieteenaloista, jotka hiljaa päättävät, onnistuvatko dataprojektisi vai epäonnistuvatko ne.Jokaisen analytiikkapaneelin, transaktiojärjestelmän tai BI-ratkaisun takana on datamalli, joka kuvaa, mitä dataa on olemassa, miten se yhdistyy toisiinsa ja miten sitä käytetään päivittäin. Kun malli on selkeä ja hyvin suunniteltu, kehitys helpottuu, raportit ovat luotettavia ja kaikki puhuvat samaa kieltä liiketoiminnasta.

Ytimessään datamalli on muodollinen, visuaalinen tapa kuvata liiketoimintatietoja: mitä entiteettejä on olemassa (asiakkaat, tuotteet, varastot, laskut…), mitkä ominaisuudet määrittelevät ne (nimi, osoite, kapasiteetti, hinta…) ja miten ne liittyvät toisiinsa. Erilaiset mallinnustekniikat ja mallityypit ovat kehittyneet vuosien varrella uusien tietokantateknologioiden, hallintatarpeiden ja nykyaikaisten analytiikan käyttötapausten, kuten liiketoimintatiedon (BI) ja tietovarastoinnin, ohjaamina.

Mikä on datamalli?

Tietomalli on abstrakti suunnitelma siitä, miten tieto on jäsennelty järjestelmän sisälläSe määrittelee dataelementit, niitä ohjaavat säännöt ja niitä yhdistävät suhteet jo kauan ennen kuin mitään todella toteutetaan tietokannassa tai sovelluksessa. Ajattele sitä arkkitehtuurisuunnitelmana, jota insinööri noudattaa ennen betonin valamista.

Käytännössä datamalli näyttää, miten dataa tallennetaan, yhdistetään, sitä käytetään ja päivitetään. tietokannan hallintajärjestelmässä. Symbolien, laatikoiden, viivojen ja tekstin avulla se antaa liiketoiminnan sidosryhmille, analyytikoille, arkkitehdeille ja kehittäjille yhteisen kuvan organisaatiolle tärkeistä tiedoista, jotta kaikki voivat pohtia niitä ja havaita ongelmia varhaisessa vaiheessa.

Yksi datamallin päätavoitteista on tehdä yksiselitteiseksi järjestelmässä käytettyjen ja tallennettujen tietojen tyypit., miten nämä tyypit ryhmittyvät, miten ne voidaan järjestää rakenteiksi ja mitä formaatteja ja attribuutteja ne sisältävät. Tämä sisältää avainten, rajoitusten, kardinaalisuuksien ja nimeämiskäytäntöjen määrittelyn, jotka myöhemmin ohjaavat teknistä toteutusta.

Tietomalleja ei luoda tyhjiössä, vaan ne perustuvat liiketoiminnan vaatimuksiin.Ennen mallinnuksen aloittamista kerätään sääntöjä ja tarpeita liiketoiminnan sidosryhmiltä ja loppukäyttäjiltä. Nämä säännöt muunnetaan sitten tietorakenteiksi, jotka muokkaavat uuden järjestelmän suunnittelua tai olemassa olevan järjestelmän kehitystä. Tässä mielessä tietomalli on hyvin samanlainen kuin tiekartta: se ei suorita mitään, mutta se kertoo, miten pääset pisteestä A pisteeseen B.

Hyvä datamallinnus perustuu standardoituihin skeemoihin ja formaaleihin tekniikoihinTämä standardointi tarjoaa johdonmukaisen ja ennustettavan tavan määritellä ja hallita tietoresursseja tiimien, osastojen ja jopa ulkoisten kumppaneiden välillä. Ihannetapauksessa malleista tulee eläviä dokumentteja, jotka kehittyvät organisaation muuttuessa, tukien prosessien parantamista ja ohjaten IT-arkkitehtuuripäätöksiä.

Mitä on datamallinnus?

Datamallinnus on prosessi, jossa kartoitetaan ja visualisoidaan, missä data sijaitsee ja miten se virtaa järjestelmässä.Tunnistat kaikki paikat, joihin sovellus, integraatio tai BI-alusta tallentaa tietoja, ja suunnittelet sitten, miten nämä tietojoukot yhdistyvät ja ovat vuorovaikutuksessa keskenään.

Tietomallinnus on kriittinen suunnitteluvaihe missä tahansa IT-projektissaRatkaisun ollessa vielä piirustuspöydällä tiimi määrittää, mitkä liiketoimintaongelmat on ratkaistava, mitä tietoja näiden ongelmien ratkaisemiseksi tarvitaan ja miten käyttäjät ja muut järjestelmät käyttävät näitä tietoja. Tämä ymmärrys muunnetaan sitten kaavioiksi, jotka kuvaavat, miten eri tietoryhmät liittyvät toisiinsa ja liikkuvat komponenttien välillä.

Datamallinnuksen tuloksena on yleensä yksi tai useampi kaavio (tai malli), jotka havainnollistavat, miten kukin dataryhmä liittyy muihin.Nämä voivat olla käsitteellisiä kaavioita yritysyleisölle, loogisia malleja, jotka esittävät rakenteita ja suhteita yksityiskohtaisemmin, tai fyysisiä malleja, jotka on sidottu suoraan tietokannan taulukoihin ja sarakkeisiin. Jokainen abstraktiotaso tarkentaa edellistä tasoa ja pääsee lähemmäksi toteutusta.

Dataa voidaan mallintaa useilla abstraktiotasoilla, erittäin korkean tason käsitteistä täysin yksityiskohtaisiin skeemoihinMallinnuksen elinkaari alkaa tyypillisesti sidosryhmien vaatimusten ymmärtämisellä, liiketoimintasääntöjen muuntamisella tietorakenteiksi ja näiden rakenteiden jalostamisella konkreettiseksi tietokantasuunnitelmaksi. Matkan varrella aukot, epäjohdonmukaisuudet tai puuttuvat tietoelementit tulevat näkyviin ja ne voidaan korjata ennen kuin niistä tulee tuotanto-ongelmia.

Koska vaatimukset kehittyvät, datamalleja tulisi käsitellä elävinä artefakteinaNiitä tarkastellaan uudelleen aina, kun uusia ominaisuuksia lisätään, integraatioita ilmestyy, määräykset muuttuvat tai uusia analytiikkatarpeita ilmenee. Jaettuja malleja voidaan jopa vaihtaa toimittajien ja kumppaneiden kanssa, jotta datan ymmärtäminen ja vaihtaminen organisaatioiden välillä voidaan yhdenmukaistaa.

Tärkeimmät datamallinnustekniikat ja mallityypit

Ajan myötä on syntynyt erilaisia ​​datamallinnustekniikoita, joista jokainen on optimoitu tiettyihin teknologioihin ja käyttötapauksiin.Varhaisista hierarkkisista tietokannoista nykyaikaisiin liiketoimintatiedon dimensionaalisiin ja assosiatiivisiin lähestymistapoihin jokainen tyyli tarjoaa erityisiä vahvuuksia ja kompromisseja joustavuuden, suorituskyvyn ja ymmärrettävyyden suhteen.

Alta löydät perusteellisen esittelyn tärkeimmistä datamallityypeistä, havainnollistettu konkreettisilla esimerkeillä, kuten autoliikkeillä, varastoilla ja BI-tähtikaavioilla, ja selitetty liiketoimintaystävällisellä kielellä, jotta sekä tekniset että ei-tekniset lukijat voivat seurata.

Hierarkkinen datamallinnus

Hierarkkinen datamalli järjestää tiedot puumaiseen rakenteeseen, jossa on yksi juuri ylhäällä ja useita lapsisolmujen tasoja sen alla. Jokaisella pääsolmulla voi olla useita lapsisolmuja, mutta jokaisella lapsella on täsmälleen yksi vanhempi, mikä johtaa tiukkaan yksi-moneen-suhdemalliin.

Tässä lähestymistavassa ihmissuhteet kulkevat yhtä polkua pitkin vanhemmasta lapseen.Ei ole olemassa käsitettä siitä, että tietueella olisi useita vanhempia. Osoittimet (tai linkit) yhdistävät vanhemmat lapsiinsa, ja näitä osoittimia käytetään tietojen käyttämiseen tai päivittämiseen. Koska jokainen tietue sijaitsee tietyssä paikassa puussa, sen sukulinjan päättely on yksinkertaista.

Harkitse esimerkkiä autoliikkeestäYlimmän tason solmu voisi edustaa ”Näytösaleja”. Jokaisella näyttelysalinoolulla olisi alisolmuja ”Autoille” ja ”Myyjille”, koska yhdessä näyttelytilassa voi olla useita autoja ja se voi työllistää useita myyjiä. Navigointi alkaisi aina näyttelytilasta ja liikkuisi alaspäin nähdäkseen, mitkä autot ja myyntihenkilöstö kuuluvat siihen.

Hierarkkiset mallit ovat loistavia, kun reaalimaailman rakenteesi on luonnostaan ​​puun muotoinen, kuten verkkosivustojen sivustokarttoja, organisaatiokaavioita, reseptien erittelyjä tai verkkokauppasivuston tuoteluokkia. Esimerkiksi "Kengät" voi olla pääluokka, jolla on alisolmuja, kuten "Naisten kengät" ja "Miesten kengät", ja lisää alisolmuja, kuten "Lenkkarit", "Korkokengät" tai "Saappaat".

Tällä tyylillä on joitakin selkeitä ominaisuuksia ja rajoituksiaSuhteet ovat ehdottoman yksi-moneen -periaatteita, eli juuresta mihin tahansa alitasolle on vain yksi polku, ja vanhemman poistaminen poistaa tyypillisesti kaikki sen alitasot automaattisesti. Tämä kaskadimainen poisto voi olla kätevää, mutta myös riskialtista, jos et ole varovainen hierarkian semantiikasta.

Verkkodatan mallinnus

Verkkodatamalli laajentaa hierarkkista lähestymistapaa sallimalla tietueilla useita vanhempiaPuhtaan puun sijaan lopputuloksena on graafimainen toisiinsa yhteydessä olevien tietueiden verkko, kuten... hallitut graafitietokannat, mikä helpottaa monimutkaisten tosielämän tilanteiden esittämistä.

Verkostomallissa on mahdollista muodostaa paljon enemmän suhdemallejaVoit käsitellä paitsi yksi-moneen-suhteita, myös yksi-yhteen- ja monta-moneen-suhteita. Solmut voivat olla yhteydessä toisiinsa useiden reittien kautta, mikä tarkoittaa, että samaan tietueeseen voi päästä useilla tavoilla rakenteessa navigoitaessa.

Kuvittele opiskelija, joka opiskelee tietojenkäsittelytieteen laitoksella, mutta jolla on myös lainausoikeus kirjastossa.Verkkomallissa kyseisellä ”Opiskelija”-tietueella voi olla kaksi päätietuetta: yksi ”Tietojenkäsittelytiedusteluosastolle” ja toinen ”Kirjastolle”. Tämä oli mahdotonta tiukassa hierarkkisessa puussa, jossa lapsella saattoi olla vain yksi vanhempi.

Verkkomallien taustalla olevat operaatiot toteutetaan usein käyttämällä ympyrälinkitettyjä listojaOhjelma seuraa listan "nykyistä sijaintia" ja liikkuu yhdistettyjen tietueiden läpi määriteltyjen suhteiden mukaisesti. Tämä tekee läpikäymisistä nopeita ja joustavia, koska samaan tietoon voi seurata useita mahdollisia reittejä.

Paremman kytkeytyvyyden ansiosta verkkomallit voivat esittää vivahteikkaampia, reaalimaailman suhteita., mutta niistä tulee myös monimutkaisempia ymmärtää ja hallita. Kaikkien linkkien suunnittelu ja ylläpito voi olla haastavaa, erityisesti suurten skeemojen ja kehittyvien liiketoimintasääntöjen tapauksessa.

Entiteetti-relaatio (ER) -tietojen mallinnus

Entiteetti-relaatiomalli on korkean tason visuaalinen tapa kuvata datavaatimuksia ER-kaavioiden avulla.Se on yksi käytetyimmistä tekniikoista käsitteelliseen ja loogiseen datamallinnukseen, erityisesti työskenneltäessä liiketoiminnan sidosryhmien kanssa, jotka tarvitsevat selkeän kuvan ilman teknistä sekamelskaa.

ER-kaaviossa ydinosakkeita ovat entiteetit, attribuutit ja suhteet.Entiteetit edustavat tosielämän asioita, joista yritys välittää (kuten ”Opiskelija”, ”Opettaja”, ”Kurssi” tai ”Osasto”). Määritteet tallentavat näiden entiteettien ominaisuudet (kuten opettajan tunnus, palkka, ikä), ja suhteet osoittavat, miten entiteetit ovat yhteydessä toisiinsa (esimerkiksi ”Opettaja työskentelee osastolla”).

Yksiköt piirretään yleensä suorakulmioina, attribuutit soikioina ja suhteet vinoneliöinä tai merkittyinä viivoina.Kardinaaliteetit (kuten yksi-moneen tai monta-moneen) osoittavat, kuinka monta esiintymää kutakin entiteetistä voidaan linkittää toisiinsa. Tämän merkintätavan avulla voit tallentaa monimutkaisia ​​sääntöjä kaavioon, joka on silti suhteellisen helppo lukea.

Tietoarkkitehdit käyttävät ER-työkaluja näiden mallien suunnitteluun ja tarkentamiseenMonissa tapauksissa ER-kaavioista tulee silta liiketoiminta-analyysin ja tietokannan toteutuksen välillä: kun ER-mallista on sovittu, se voidaan muuntaa systemaattisesti relaatiotaulukoiksi, avaimiksi ja rajoitteiksi.

Koska ER-mallinnus toimii suhteellisen korkealla abstraktiotasolla, se on erinomainen tapa validoida ymmärrystä sidosryhmien kanssa. Voit tarkastella kaaviota työpajoissa, kysyä, ovatko kaikki tarvittavat entiteetit ja suhteet läsnä, ja muokata suunnittelua ennen siirtymistä teknisempiin tasoihin.

Relaatiotietojen mallinnus

Relaatiomalli on useimpien perinteisten tietokantajärjestelmien selkärankaTässä data tallennetaan kaksiulotteisiin taulukoihin, jotka koostuvat riveistä ja sarakkeista, ja taulukoiden väliset suhteet ilmaistaan ​​avainten avulla, ei eksplisiittisten osoittimien avulla kuten hierarkkisissa tai verkostomalleissa.

Relaatiomallin jokaista taulukkoa kutsutaan usein "relaatioksi", vaikka käytännössä kuulet ihmisten kutsuvan niitä yksinkertaisesti taulukoiksi. Rivit tunnetaan tupleina ja ne edustavat yksittäisiä tietueita tai instansseja, kun taas sarakkeet ovat attribuutteja (tai kenttiä), jotka määrittelevät kullekin tietueelle tallennetut ominaisuudet.

Otetaanpa taas esimerkkinä autoliikeSinulla voi olla ”Myyjät”-taulukko, jossa on sarakkeita, kuten Myyjäntunnus ja Nimi, ja erillinen ”Autot”-taulukko, jossa on sarakkeita, kuten Autontunnus ja Tuotemerkki. Jokainen Myyjät-taulukon rivi edustaa todellista myyjää ja jokainen Autot-taulukon rivi edustaa todellista ajoneuvoa.

Ensisijaisilla avaimilla ja viiteavaimilla on ratkaiseva rooli relaatiomallissaEnsisijainen avain yksilöi taulukon jokaisen rivin (esim. Myyjäntunnus tai Autontunnus). Nämä avaimet voivat sitten näkyä viiteavaimina muissa taulukoissa edustamaan suhteita. Esimerkiksi ”Näyttelytilat”-taulukko voi sisältää sekä Myyjäntunnuksen että Autontunnuksen viiteavaimina, jotka linkittävät näyttelytilan siellä työskentelevään myyjään ja esillä olevaan autoon.

Ensisijaisten ja viiteavainten välinen yhteistyö mahdollistaa relaatiotietokantojen esittää monimutkaisia ​​liikesuhteiden verkkoja.Kun teet kyselyn tietokantaan, voit liittää taulukoita näillä avaimilla, mikä on hyväksi. SQL-tietoanalyysi ja rekonstruoida tosielämän assosiaatioita: mitkä autot on osoitettu mihinkin näyttelytilaan, kuka myyjä hoiti tietyn myynnin ja niin edelleen.

Ensisijaisten ja viiteavainten välinen yhteistyö mahdollistaa relaatiotietokantojen esittää monimutkaisia ​​liikesuhteiden verkkoja.Kun teet kyselyn tietokantaan, voit yhdistää taulukoita näillä avaimilla rekonstruoidaksesi reaalimaailman yhteyksiä: mitkä autot kuuluvat mihinkin näyttelytilaan, kuka myyjä hoiti tietyn myynnin ja niin edelleen.

Relaatiomalli on tehokas, hyvin ymmärretty ja kypsät teknologiat tukevat sitä vahvasti.Se loistaa, kun data on erittäin jäsenneltyä ja johdonmukaisuus on kriittistä. Se voi kuitenkin kohdata rajoituksia erittäin monimutkaisten objektien, multimediasisällön tai erittäin joustavien skeemojen kanssa, joissa rakenne muuttuu usein.

Objektiorientoitunut datamallinnus

Oliopohjainen datamallinnus tuo oliopohjaisen ohjelmoinnin käsitteitä datamaailmaanSen sijaan, että ajattelisit vain taulukoiden ja rivien kautta, mallinnat tietoa objekteina, jotka niputtavat dataa (attribuutteja) yhdessä käyttäytymisen (metodien) kanssa, peilaten nykyaikaisten sovellusten kirjoitustapaa.

Oliopohjaisessa mallissa jokainen objekti edustaa reaalimaailman oliotaAutoliikkeellä voi olla ”Asiakas”-objekti, jolla on attribuutteja, kuten nimi, osoite ja puhelinnumero, sekä metodeja näiden tietojen päivittämiseksi tai asiakkaan elinkaaren arvon laskemiseksi. Jokainen varsinainen asiakas on sitten Asiakas-luokan instanssi järjestelmässä.

Tämä mallinnustyyli voi voittaa useita tiukasti relaatiomallien rajoituksia, erityisesti käsiteltäessä monimutkaisia, sisäkkäisiä rakenteita tai multimediadataa, joka ei sovi hyvin yksitasoisiin taulukoihin. Objektitietokannat ja objektirelaatiokartoittajat (ORM) hyödyntävät tätä paradigmaa vähentääkseen koodin ja datan tallennuksen välistä "impedanssiepäsuhtaa".

Objektiorientoituneet mallit ovat yleisiä multimedia- ja edistyneissä sovellusskenaarioissa, joissa kuvien, videoiden tai sisäkkäisten dokumenttien tallentaminen yhtenäisiksi objekteiksi on luonnollisempaa kuin kaiken jakaminen lukuisiin relaatiotaulukoihin. Ne voivat kuitenkin monimutkaistaa kyselyitä, raportointia ja integrointia, jos et ole varovainen.

Koska objektimalli on usein hyvin lähellä kehittäjien ajattelutapaa, se voi nopeuttaa sovelluskehitystä. Kompromissina on se, että puhtaat objektitietokannat ovat vähemmän valtavirtaisia ​​kuin relaatiotietokannat, ja niiden integrointi laajempiin dataekosysteemeihin (erityisesti liiketoimintatiedon analysointiin) voi olla haastavampaa.

Dimensiotietojen mallinnus analytiikkaan ja liiketoimintatiedon analysointiin

Dimensiotietojen mallintaminen on ensisijainen lähestymistapa tietovarastoihin ja liiketoimintatiedon ratkaisuihinSen päätavoitteena on optimoida tietorakenteita nopeaa kyselyä, koontia ja raportointia varten, vaikka se merkitsisikin tiedon tarkoituksellista kopiointia tai denormalisointia.

Dimensiomallissa tiedot on järjestetty faktataulukoihin ja dimensiotaulukoihinFaktataulukot tallentavat määrällisiä, mitattavia tapahtumia (myynnit, klikkaukset, toimitukset, tapahtumat), kun taas dimensiotaulukot tarjoavat kuvailevia konteksteja (aika, tuote, asiakas, sijainti), joiden avulla voit tarkastella faktoja useista eri näkökulmista.

Kuvittele taas autoliike, joka rakentaa tietovarastoaTietotaulukkoon voitaisiin tallentaa kaikki myyntitapahtumat, mukaan lukien mittarit, kuten määrä ja tuotto, kun taas dimensiotaulukot voisivat kuvata "Auto", "Näyttelytila" ja "Aika". "Auto"-dimensio sisältäisi ominaisuuksia, kuten malli ja tuotemerkki; "Näyttelytila"-dimensio sisältäisi hierarkioita, kuten osavaltio, kaupunki, katu ja näyttelytilan nimi.

Dimensiomallit usein kopioivat tarkoituksella joitakin tietoja eri taulukoiden välilläTämä redundanssi on tietoinen suunnitteluvalinta, jolla pyritään nopeuttamaan kyselyitä ja yksinkertaistamaan analyysiä BI-käyttäjille. Analyytikot voivat suodattaa, koota ja pivotoida ulottuvuusattribuuttien perusteella ilman, että heidän tarvitsee maksaa pitkälle normalisoitujen relaatiomallien suorituskykyrangaistusta.

Kaksi klassista fyysistä mallia dimensiomalleille ovat tähtimalli ja lumihiutalemalli., molempia käytetään laajalti BI-projekteissa. Niillä on sama analyyttinen ydin, mutta ne eroavat toisistaan ​​​​dimensioiden normalisoinnin suhteen.

Liiketoimintatiedon tietomallit: tähti ja lumihiutale

Liiketoimintatiedon maailmassa "tietomalleilla" tarkoitetaan usein raporttien taustalla olevaa tähti- tai lumihiutalekaavaa.Nämä skeemat määrittelevät, miten faktat ja ulottuvuudet linkittyvät toisiinsa, ja ne vaikuttavat voimakkaasti analytiikkatyökalujen suorituskykyyn, käytettävyyteen ja joustavuuteen.

Tähtikaavio pyörii keskeisen faktataulukon ympärillä joka sisältää analysoitavat mittarit alhaisimmalla hyödyllisellä yksityiskohtaisuustasolla (grain) sekä viiteavaimet, jotka linkittyvät ympäröiviin ulottuvuustaulukoihin. Kaikki ulottuvuudet ovat suoraan yhteydessä tietotaulukkoon muodostaen tähtimäisen muodon.

Tällä suunnittelulla on suuri etu: se yksinkertaistaa suodatusta ja aggregointiaKoska jokainen ulottuvuus on liitetty suoraan tietotaulukkoon, kyselyt ovat suoraviivaisia ​​ja työkalut voivat luoda SQL-kyselyitä helpommin. Sinulla voi esimerkiksi olla Myynti-tietotaulukko, joka on linkitetty suoraan Auto-, Asiakas-, Näyttelytila- ja Aika-ulotteisiin, jotka kaikki säteilevät ulospäin kuin tähtipisteet.

Kun olet tunnistanut analysoitavan tosiasian kannalta merkitykselliset ulottuvuudet, voit rakentaa dimensionaalisen mallin, joka vastaa todellisiin liiketoimintakysymyksiin: Mitä myynti on automerkin ja alueen mukaan? Miten tulokset kehittyvät ajan kuluessa? Mitkä myymälät suoriutuvat paremmin kuin muut, jos varasto on samanlainen?

Lumihiutalekaavio käyttää samoja käsitteellisiä rakennuspalikoita, mutta normalisoi ulottuvuudet useiksi toisiinsa liittyviksi taulukoiksi.Yhden "Sijainti"-ulottuvuuden sijaan, jossa on kaikki maantieteelliset tasot, voit jakaa sen "Maa", "Alue", "Kaupunki" ja niin edelleen osiin, jotka kukin tallennetaan omaan taulukkoonsa ja linkitetään normalisoidussa rakenteessa.

Lumihiutalemallit ovat monimutkaisempia kuin tähtimallit mutta noudattavat samaa analyyttistä logiikkaa. Niitä käytetään, kun ulottuvuusdata on suuri, jaettua tai se vaatii vahvempaa normalisointia redundanssin välttämiseksi. Esimerkiksi "Tuote"-ulottuvuus voidaan jakaa erillisiin taulukoihin "Tuote", "Tuotemerkki" ja "Kategoria", jotka kukin normalisoidaan ja yhdistetään avainten avulla.

Harjoittajat vertailevat usein tähti- ja lumihiutalemalleja kriteerien, kuten suorituskyvyn, tallennustilan, ylläpidon vaivan ja helppokäyttöisyyden, perusteella.Tähtiskeemat ovat yleensä yksinkertaisuuden ja kyselynopeuden etuja, kun taas lumihiutaleet voivat säästää tallennustilaa ja vähentää ylläpitotarvetta silloin, kun ulottuvuushierarkiat ovat monimutkaisia ​​tai niitä käytetään uudelleen useissa tietotaulukoissa.

Tasaiset, puolistrukturoidut ja assosiatiiviset datamallit

Klassisten hierarkkisten, verkosto-, ER-, relaatio-, olio- ja dimensiomallien ulkopuolella, on olemassa useita muitakin tyylejä, jotka kannattaa tuntea, erityisesti nykyaikaisissa data-alustoissa ja integraatioskenaarioissa.

Tasainen datamalli on yksinkertaisin mahdollinen esitystapaKaikki tiedot tallennetaan yhteen taulukkoon, jossa on rivejä ja sarakkeita, ilman muita eksplisiittisiä suhteita tai rakennetta. Tietyn tietojoukon käyttämiseksi järjestelmän on ehkä luettava paljon taulukkoa, mikä tekee toiminnoista hitaita ja tehottomia tietomäärän kasvaessa.

Puolistrukturoitu malli on relationaalisen lähestymistavan joustavampi kehitysaskelPuolistrukturoidussa datassa datan ja skeeman välillä ei aina ole selkeää eroa. Joiltakin entiteeteiltä saattaa puuttua tiettyjä attribuutteja, kun taas toisilla voi olla lisäkenttiä, joita ei ole vertaisissaan, ja se on täysin hyväksyttävää.

Tämä joustavuus on tyypillistä esimerkiksi JSON-, XML- tai joissakin NoSQL-tietokannoissa.Attribuutti voi sisältää yksinkertaisen atomiarvon tai kokonaisen kokoelman, ja rakenne voi vaihdella tietueesta toiseen. Tämä on tehokasta käsiteltäessä kehittyviä tai heterogeenisiä tietolähteitä, mutta se monimutkaistaa tiukkaa validointia ja perinteisiä relaatiokyselyitä.

Assosiatiivinen datamalli ottaa vielä toisen näkökulman jakamalla datan "elementteihin" ja "linkkeihin"Kaikkea itsenäisesti esiintyvää käsitellään alkiona (tai elementtinä), kun taas alkioiden väliset suhteet tallennetaan linkkeinä (tai assosiaatioina). Jokaisella elementillä on nimi ja tunniste, kun taas jokaisella linkillä on oma tunnisteensa sekä attribuutit, jotka osoittavat lähteeseen, verbiin ja kohteeseen.

Tarkastellaan lausetta ”Jalkapallon MM-kisat järjestetään Lontoossa 30. toukokuuta 2022 alkaen”Assosiatiivinen malli voisi tallentaa yhden linkin, jossa lukee ”MM-kisat – järjestetään – Lontoossa”, jossa ”MM-kisat” on lähde, ”järjestetään” on verbi ja ”Lontoo” on kohde. Toinen linkki yhdistäisi ensimmäisen linkin lähteenä aloituspäivämäärään kohteena verbin ”mistä” avulla.

Tämä linkkiperustainen näkökulma voi olla hyvin ilmaisuvoimainen tietograafeille ja semanttisille suhteille.Sen sijaan, että piilottaisit suhteita taulukkoliitosten tai objektiviittausten sisään, käsittelet niitä ensiluokkaisina tietoelementteinä, joita voidaan kysellä, versioida ja analysoida itsenäisesti.

Käsitteellinen datamallinnus liiketoiminta-analyysiä varten

Käsitteellinen datamallinnus keskittyy liiketoimintakonseptien ja niiden välisten suhteiden tallentamiseen erittäin korkealla tasolla, murehtimatta teknisistä yksityiskohdista, kuten tietotyypeistä, indekseistä tai fyysisestä tallennuksesta. Se on erityisen hyödyllistä projektin alkuvaiheissa, kun vielä validoit laajuutta ja vaatimuksia.

Ympäristöissä, kuten Pega ja vastaavat alustat, käsitteellinen datamalli alkaa tunnistamalla liiketoimintayksiköt ja niiden ominaisuudetEsimerkiksi kirjavarastoskenaariossa voit määrittää entiteetin ”Varasto”, jonka attribuutteja ovat esimerkiksi Nimi, Kaupunki ja Kapasiteetti. Lisäentiteetit, kuten ”Osoite” ja ”Varasto”, linkitetään ”Varastoon” kuvaamaan laitoksen sijaintia ja sen säilyttämiä kirjoja.

Tuloksena oleva kaavio visualisoi kyseiset yksiköt, niiden keskeiset ominaisuudet ja niiden väliset keskeiset suhteet.Sinun ei tarvitse mallintaa jokaista yksittäistä liiketoimintatuloksen saavuttamiseksi tarvittavaa datapistettä; tavoitteena on saada kokonaiskuva, jotta sidosryhmät voivat nähdä, puuttuuko jotain ilmeistä tai onko se esitetty väärin.

Kun tapaat liiketoiminnan sidosryhmiä, käsitteellisestä mallista tulee yhteinen viitekehys.Se auttaa ihmisiä visualisoimaan, miten heidän prosessinsa vastaavat dataa: mitkä yksiköt ovat mukana kussakin vaiheessa, mitä ominaisuuksia tarvitaan tapauksen loppuun saattamiseksi ja missä osastojen tai järjestelmien välillä on riippuvuuksia.

Riittävän ajan panostaminen konseptuaaliseen datasuunnitteluun alkuvaiheessa vähentää huomattavasti myöhemmän uudelleentyöstön riskiä.Jos projektin aikana huomaat, että kriittisiä datavaatimuksia on ymmärretty väärin tai jätetty huomiotta, saatat joutua tekemään uudelleen merkittäviä osia prosessien suunnittelusta, integraatioista ja käyttöliittymästä. Vankka käsitteellinen malli lieventää tätä riskiä paljastamalla väärinkäsitykset, kun muutokset ovat vielä edullisia.

Käsitteelliset mallit eivät tietenkään ole staattisiaProjektin edetessä ja tiimin oppiessa lisää malli voi (ja sen pitäisi) kehittyä. Tämä kehitys on merkki terveestä löytämisestä, ei epäonnistumisesta. Tärkeintä on säilyttää käsitteellinen malli elävänä dokumenttina, joka pitää projektikeskustelut ankkuroituina selkeän liiketoimintadatan ympärille.

Datamallit elävinä, strategisina resursseina

Kaikissa näissä tekniikoissa ja mallityypeissä on yhteinen teema: datamallit eivät ole vain teknisiä esineitä; ne ovat strategisia viestintätyökaluja.Olitpa sitten luonnostelemassa yksinkertaista ER-kaaviota tai ylläpitämässä rikasta BI-ulotteista kaavaa, koodaat datamuodossa sitä, miten organisaatio ymmärtää itsensä.

Hyvin rakennetut datamallit tukevat ydinliiketoimintaprosesseja, ohjaavat IT-arkkitehtuuria ja mahdollistavat luotettavan analytiikanNe tarjoavat jaetun sanaston liiketoiminta- ja teknologiatiimien välille, vähentävät epäselvyyksiä ja tekevät tulevista muutoksista vähemmän tuskallisia, koska muutosten vaikutukset voidaan jäljittää selkeästi määriteltyjen kokonaisuuksien ja suhteiden kautta.

Hierarkkisista puista ja verkkograafeista relaatiotaulukoihin, objektihierarkioihin, dimensionaalisiin tähtiin, tasaisiin rakenteisiin, puolistrukturoituihin formaatteihin ja assosiatiivisiin linkkeihinJokaisella mallinnustyylillä on omat vahvuutensa tietyissä käyttötapauksissa. Nykyaikaiset organisaatiot käyttävät harvoin vain yhtä; sen sijaan ne yhdistävät useita lähestymistapoja järjestelmissään ja data-alustoillaan.

Viime kädessä datamallinnuksen arvo piilee siinä, kuinka tehokkaasti se muuttaa epäsiistin reaalimaailman vaatimusten muotoon yhtenäisiksi ja helposti navigoitaviksi rakenteiksi.Kun datamallit tehdään tarkasti, mutta myös liiketoimintakäytännön mukaisesti, niistä tulee perustavanlaatuisia resursseja, jotka nopeuttavat kehitystä, parantavat datan laatua ja mahdollistavat päätöksenteon koko yrityksessä.