Tietoholvissa yritetään ratkaista ongelman, joka liittyy ympäristön muutoksiin, erottelemalla toisistaan liiketoiminta-avainten avaimet (jotka eivät mutaatioita tapahdu yhtä usein, koska ne yksilöivät liiketoimintayksikön yksiselitteisesti) ja näiden liiketoiminta-avainten väliset assosiaatiot näiden avainten kuvailevista attribuuteista.
Toiminta-avaimet ja niiden assosiaatiot ovat rakenteellisia attribuutteja, jotka muodostavat tietomallin rungon. Tietoholvimenetelmän tärkeimpiä aksioomia on, että todelliset liiketoiminta-avaimet muuttuvat vain, kun liiketoiminta muuttuu, ja siksi ne ovat vakaimpia elementtejä, joista voidaan johtaa historiallisen tietokannan rakenne. Jos käytät näitä avaimia tietovaraston selkärankana, voit järjestää loput tiedot niiden ympärille. Tämä tarkoittaa, että oikeiden avainten valitseminen solmukohtiin on mallisi vakauden kannalta ensiarvoisen tärkeää. Avaimet tallennetaan taulukoihin, joiden rakenteelle on asetettu muutamia rajoituksia. Näitä avaintaulukoita kutsutaan hubeiksi.
HubsEdit
Hubit sisältävät luettelon ainutkertaisista liiketoiminta-avaimista, joiden muutosalttius on vähäinen. Hubit sisältävät myös sijaisavaimen kullekin Hub-elementille ja metatietoja, jotka kuvaavat liiketoiminta-avaimen alkuperää. Hubin tietoja kuvaavat attribuutit (kuten avaimen kuvaus, mahdollisesti useilla kielillä) tallennetaan rakenteisiin, joita kutsutaan Satelliitti-tauluiksi ja joita käsitellään jäljempänä.
Hub sisältää ainakin seuraavat kentät:
- surrogaattiavain, jota käytetään muiden rakenteiden liittämiseen tähän tauluun.
- liiketoiminta-avain, tämän hubin ajuri. Liiketoiminta-avain voi koostua useista kentistä.
- tietueiden lähde, jonka avulla voidaan nähdä, mikä järjestelmä latasi kunkin liiketoiminta-avaimen ensimmäisenä.
- valinnaisesti voi olla myös metatietokenttiä, joissa on tietoja manuaalisista päivityksistä (käyttäjä/aika) ja poimintapäivästä.
Keskittymässä ei saa olla useita liiketoiminta-avaimia, paitsi silloin, kun kaksi järjestelmää toimittaa saman liiketoiminta-avaimen, mutta eri merkityksiä sisältävillä törmäyksillä.
Keskittymissä tulisi yleensä olla vähintään yksi satelliitti.
Esimerkki keskittymästäTiedostoa muokataan
Tässä on esimerkki autoja sisältävästä keskittymästä-taulukosta nimeltä ”Auto” (H_CAR). Ajoavain on ajoneuvon tunnistenumero.
| Fieldname | Description | Mandatory? | Kommentti |
|---|---|---|---|
| H_CAR_ID | Keskittymän sekvenssitunnus ja sijaisavain | Ei | Suositeltava, mutta valinnainen |
| VEHICLE_ID_NR | Toiminta-avain, joka ohjaa tätä keskittymää. Voi olla useampi kuin yksi kenttä yhdistetylle liiketoiminta-avaimelle | Kyllä | |
| H_RSRC | Tietueen lähde tälle avaimelle, kun se ladataan ensimmäisen kerran | Kyllä | |
| LOAD_AUDIT_ID | Tunniste taulukkoon, jossa on auditointitietoja, kuten latausajankohdan, kuorman keston, rivien lukumäärän yms. osalta. | Ei |
LinkitEdit
Liiketoiminta-avainten väliset assosiaatiot tai transaktiot (jotka liittävät esimerkiksi asiakkaan ja tuotteen solmukohdat toisiinsa ostotapahtuman kautta) mallinnetaan linkkitaulujen avulla. Nämä taulukot ovat periaatteessa monesta moneen -liittymätaulukoita, joissa on jonkin verran metatietoa.
Linkit voivat linkittää toisiin linkkeihin, jotta voidaan käsitellä muutoksia rakeisuudessa (esimerkiksi uuden avaimen lisääminen tietokantatauluun muuttaisi tietokantataulun rakeisuutta). Jos sinulla on esimerkiksi assosiaatio asiakkaan ja osoitteen välillä, voit lisätä viittauksen linkkiin tuotteen ja kuljetusyrityksen solmupisteiden välillä. Tämä voisi olla linkki nimeltä ”Toimitus”. Linkin viittaamista toiseen linkkiin pidetään huonona käytäntönä, koska se tuo linkkien välille riippuvuuksia, jotka vaikeuttavat rinnakkaislatausta. Koska linkki toiseen linkkiin on sama kuin uusi linkki, jossa on toisen linkin solmukohdat, näissä tapauksissa linkkien luominen viittaamatta toisiin linkkeihin on suositeltavampi ratkaisu (katso lisätietoja kohdasta Latauskäytännöt).
Linkit linkittävät joskus solmukohtia tietoihin, jotka eivät yksinään riitä solmukohdan rakentamiseen. Tämä tapahtuu silloin, kun yksi linkin liittämistä liiketoiminta-avaimista ei ole todellinen liiketoiminta-avain. Esimerkkinä voidaan ottaa tilauslomake, jonka avaimena on ”tilausnumero”, ja tilausrivit, jotka on yhdistetty puoliksi satunnaisella numerolla, jotta ne olisivat yksilöllisiä. Sanotaan vaikka ”yksilöllinen numero”. Jälkimmäinen avain ei ole todellinen liiketoiminta-avain, joten se ei ole solmukohta. Meidän on kuitenkin käytettävä sitä, jotta voimme taata linkin oikean rakeisuuden. Tässä tapauksessa emme käytä sijaisavainta, vaan lisäämme linkkiin itse liiketoiminta-avaimen ”uniikki numero”. Näin tehdään vain silloin, kun ei ole mahdollista käyttää liiketoiminta-avainta toisessa linkissä tai satelliitin attribuuttien avaimena. Dan Linstedt on kutsunut tätä rakennetta ”peg-legged linkiksi” (nykyään lakkautetulla) foorumillaan.
Linkit sisältävät linkitettävien solmukohtien korvikeavaimet, linkin oman korvikeavaimen ja metatietoja, jotka kuvaavat assosiaation alkuperää. Assosiaation tietoja kuvaavat attribuutit (kuten aika, hinta tai määrä) tallennetaan rakenteisiin, joita kutsutaan satelliittitaulukoiksi ja joita käsitellään jäljempänä.
Linkki-esimerkkiMuokkaa
Tämä on esimerkki linkkitaulukosta kahden autoja (H_CAR) ja henkilöitä (H_PERSON) käsittelevän hubin välillä. Linkin nimi on ”Kuljettaja” (L_DRIVER).
| Fieldname | Description | Mandatory? | Kommentti |
|---|---|---|---|
| L_DRIVER_ID | Sekvenssin ID ja linkin sijaisavain | Ei | Suositeltava, mutta valinnainen |
| H_CAR_ID | auton solmukohdan sijaisavain, linkin ensimmäinen ankkuri | Kyllä | |
| H_PERSON_ID | surrogate key for the person hub, linkin toinen ankkuri | Kyllä | |
| L_RSRC | Tämän assosiaation tietueiden lähde, kun se ladataan ensimmäisen kerran | Kyllä | |
| LOAD_AUDIT_ID | Tunniste taulukkoon, jossa on tarkastustietoja, kuten latausaika, latauksen kesto, rivien määrä jne. | Ei |
SatelliititEdit
Keskukset ja linkit muodostavat mallin rakenteen, mutta niillä ei ole ajallisia attribuutteja eikä niillä ole kuvailevia attribuutteja. Ne tallennetaan erillisiin taulukoihin, joita kutsutaan satelliiteiksi. Nämä koostuvat metatiedoista, jotka yhdistävät ne emokeskukseensa tai -linkkiinsä, metatiedoista, jotka kuvaavat assosiaation ja attribuuttien alkuperää, sekä aikajanasta, jossa on attribuutin alku- ja loppupäivät. Keskukset ja linkit muodostavat mallin rakenteen, kun taas satelliitit muodostavat mallin ”lihan”, kontekstin liiketoimintaprosesseille, jotka on kuvattu keskuksiin ja linkkeihin. Nämä attribuutit tallennetaan sekä asian yksityiskohtien että aikajanan osalta, ja ne voivat vaihdella melko monimutkaisista (kaikki asiakkaan täydellistä profiilia kuvaavat kentät) melko yksinkertaisiin (linkin satelliitti, jossa on vain valid-indikaattori ja aikajana).
Yleensä attribuutit ryhmitellään satelliitteihin lähdejärjestelmän mukaan. Kuvailevat attribuutit, kuten koko, kustannukset, nopeus, määrä tai väri, voivat kuitenkin muuttua eri nopeuksilla, joten voit myös jakaa nämä attribuutit eri satelliitteihin niiden muutosnopeuden perusteella.
Kaikki taulukot sisältävät metatietoja, jotka kuvaavat vähintäänkin lähdejärjestelmän ja päivämäärän, jolloin kyseinen merkintä tuli voimaan, jolloin saadaan täydellinen historiallinen näkymä tiedoista, kun ne tulevat tietovarastoon.
SatelliittiesimerkkiMuokkaa
Tässä on esimerkki satelliitista, joka sijaitsee autojen ja henkilöiden solmupisteiden välisessä kuljettaja-linkissä nimellä ”Kuljettajan vakuutus” (S_DRIVER_INSURANCE). Tämä satelliitti sisältää attribuutteja, jotka liittyvät erityisesti auton ja sitä kuljettavan henkilön välisen suhteen vakuutukseen, esimerkiksi indikaattorin siitä, onko kyseessä ensisijainen kuljettaja, tämän auton ja henkilön vakuutusyhtiön nimen (voisi olla myös erillinen solmukohta) ja yhteenvedon onnettomuuksien määrästä, joissa on ollut osallisena tämä ajoneuvon ja kuljettajan yhdistelmä. Mukana on myös viittaus haku- tai vertailutaulukkoon nimeltä R_RISK_CATEGORY, joka sisältää sen riskiluokan koodit, johon tämän suhteen katsotaan kuuluvan.
| Fieldname | Description | Mandatory? | Kommentti |
|---|---|---|---|
| S_DRIVER_INSURANCE_ID | Sekvenssitunnus ja sijaisavain linkin satelliitille | Ei | Suositeltava, mutta valinnainen |
| L_DRIVER_ID | (sijaisavainta) primääriavain ajurilinkille, satelliitin vanhempi | Kyllä | |
| S_SEQ_NR | järjestys- tai järjestysnumero, jotta voidaan varmistaa yksikäsitteisyys, jos yhdelle vanhempiavaimelle on useita kelvollisia satelliitteja | Ei(**) | Näin voi tapahtua, jos käytössä on esimerkiksi solmupiste KURSSI (COURSE), ja kurssin nimi on attribuuttina, mutta se on kirjoitettu usealla eri kielellä. |
| S_LDTS | Latauspäivämäärä (aloituspäivämäärä) tämän attribuuttiarvojen yhdistelmän pätevyydelle vanhempiavaimen L_DRIVER_ID | Kyllä | |
| S_LEDTS | Load End Date (loppupäivämäärä) tämän attribuuttiarvojen yhdistelmän pätevyydelle vanhemman avaimen L_DRIVER_ID | No | |
| IND_PRIMARY_DRIVER | Indicator whether the kuljettaja on tämän auton ensisijainen kuljettaja | Ei (*) | |
| INSURANCE_COMPANY | Vakuutusyhtiön nimi tämän ajoneuvon ja tämän kuljettajan osalta | Ei (*) | |
| NR_OF_ACCIDENTS | Tämän kuljettajan tällä ajoneuvolla aiheuttamien onnettomuuksien määrä | Ei (*) | |
| R_RISK_CATEGORY_CD | Kuljettajan riskiluokka. Tämä on viittaus R_RISK_CATEGORY | Ei (*) | |
| S_RSRC | Tietolähde, josta tämän satelliitin tiedot ladataan ensimmäisen kerran | Kyllä | |
| LOAD_AUDIT_ID | Tunniste taulukkoon, jossa on tarkastustietoja, kuten latausaika, latauksen kesto, rivien määrä jne. | Ei |
(*) vähintään yksi attribuutti on pakollinen.(**) Järjestysnumerosta tulee pakollinen, jos sitä tarvitaan, jotta voidaan varmistaa yksikäsitteisyys useille kelvollisille satelliiteille samassa keskittimessä tai linkissä.
ViittaustaulukotMuokkaa
Viittaustaulukot ovat normaali osa tervettä tietovarastomallia. Niiden tarkoituksena on estää usein viitattujen yksinkertaisten viitetietojen päällekkäinen tallentaminen. Virallisemmin Dan Linstedt määrittelee viitetiedot seuraavasti:
Mikä tahansa tieto, jota pidetään tarpeellisena kuvausten ratkaisemiseksi koodeista tai avainten kääntämiseksi (sic) johdonmukaisella tavalla. Monet näistä kentistä ovat luonteeltaan ”kuvailevia” ja kuvaavat muiden tärkeämpien tietojen tiettyä tilaa. Sellaisenaan viitetiedot elävät Data Vaultin raakatauluista erillisissä taulukoissa.
Viitetauluihin viitataan Satelliiteista, mutta niitä ei koskaan sidota fyysisillä vierasavaimilla. Viittaustaulukoille ei ole määrättyä rakennetta: käytä sitä, mikä toimii parhaiten juuri sinun tapauksessasi, yksinkertaisista hakutaulukoista pieniin dataholveihin tai jopa tähtiin. Ne voivat olla historiallisia tai vailla historiaa, mutta on suositeltavaa pitäytyä luonnollisissa avaimissa eikä luoda sijaisavaimia. Tavallisesti tietovarastoissa on paljon viitetaulukoita, aivan kuten muissakin tietovarastoissa.
ViitetaulukkoesimerkkiEdit
Tämä on esimerkki viitetaulukosta, jossa on ajoneuvojen kuljettajien riskiluokat. Siihen voidaan viitata mistä tahansa tietovaraston satelliitista. Nyt viittaamme siihen satelliitista S_DRIVER_INSURANCE. Viittaustaulukko on R_RISK_CATEGORY.
| Fieldname | Description | Mandatory? |
|---|---|---|
| R_RISK_CATEGORY_CD | Riskiluokan koodi | Kyllä |
| RISK_CATEGORY_DESC | Riskiluokan kuvaus | Ei (*) |
(*) vähintään yksi attribuutti on pakollinen.