Datahvelvmodellering

Datahvelvmodellering, eller datahvelv, er en metode for datamodellering laget for å gi langsiktig historisk lagring av data som kommer fra ulike driftssystemer. Den håndterer utfordringer knyttet til revisjon, sporing av data, lastehastigheter og resiliens mot endringer, samt vektlegging på behovet for å spore hvor alle data i en database kom fra. Dette betyr at enhver rad i datahvelvet må ha tilhørende attributter for kildeoppføring og lastedato, hvilket muliggjør revisjon hvor man sporer verdiene tilbake til kilden. Konseptet ble publisert i 2000 av Dan Linstedt.

En enkel datahvelvmodell med to nav (blå), en lenke (grønn) og fire satellitter (gul)

Datahvelvmodellering gjør ikke forskjell mellom gode og dårlige data (hvor «dårlig» her vil si at dataene ikke er i tråd med etablerte definisjoner og forretningsregler). Dette kan oppsummeres med å si at et datahvelv lagrer «en enkelt versjon av faktaene» (også uttrykt av Dan Lindstedt som «alle dataene, hele tiden») i motsetning til praksisen med andre datavarehusmetoder hvor man lagrer «en enkelt versjon av sannheten» hvor data som ikke innordner seg til definisjonene blir fjernet eller «vasket».

Modelleringsmetoden er laget for å være motstandsdyktig mot endringer i forretningsmiljøet hvor dataene som lagres kommer fra ved å eksplisitt skille ut strukturell informasjon fra beskrivende attributter. Datahvelv er laget for å muliggjøre parallell lasting så mye som mulig, slik at veldig store implementasjoner kan skaleres opp uten behov for store redesign.

I motsetning til stjernemodellen (dimensjonsmodellering) og den klassiske relasjonsmodellen (tredje normalform, 3NF) er datahvelv og ankermodellering gode på å takle endringer som oppstår når et kildesystem byttes eller legges til, men anses som kompliserte teknikker og krever erfarne dataarkitekter. Både datahvelv og ankermodeller er entitetsbaserte modeller, men ankermodeller er en mer normalisert tilnærming.^{[trenger referanse]}

Hovedentitetene i et datahvelv er:

• Nav (hub): En unik liste av forretningsnøkler fra forretningsprosesser (eventuelt bruk hash-nøkler som surrogatnøkler i stedet for primærnøkler).
• Lenke (link): En unik liste av relasjoner mellom elementer. Integrerer forretningsnøklene innenfor og på tvers av kildesystem-grenser.
• Satellitt (satellite): Gir beskrivende (deskriptive) data. En mengde av deskriptorer som huser (inneholder) deltadrevne datasett.

Tilleggsentiteter som kan brukes for optimalisering av ytelse og i forretningshvelvet er:

• Øyeblikkstabell (point in time table) med øyeblikksbilder av et nav eller en lenke, samt dens barnesatellitt(er). Består dermed av enten nav–satellitt-nøkkelpar eller lenke–satellitt-nøkkelpar. Brukes for å gi raskere indre sammenføyninger ved spørringer for improviserte analyseformål
• Brotabell for nav–lenke-nøkkelpar. Brukes også for raskere indre sammenføyninger ved improviserte analyseformål.
• Forretningshvelv-objekter

Andre viktige konsepter er:

• Referansetabeller
• Spøkelsesoppføringer, for ekviskjøter mellom øyeblikkstabeller og nærliggende satellittabeller
• Nullnøkler (zero keys, ikke til å forveksle med NULL i SQL), brukes for ekviskjøter ved sammenføying av nav- og lenketabeller

Historie og filosofi

Innen datavarehus-modellering er det to velkjente konkurrerende alternativer for modellering av laget hvor dataene lagres. Enten modellerer man ifølge Ralph Kimball sin metode med konforme dimensjoner og en virksomhetsdatabuss, eller så modellerer man ifølge Bill Inmon sin metode med en normalisert database.^{[trenger referanse]} Begge teknikkene har utfordringer med tanke på å håndtere endringer i systemene som mater datavarehuset.^{[trenger referanse]} For konforme dimensjoner må man også vaske dataene (for å gjøre dem konforme), og dette er uønsket i mange tilfeller siden det er uunngåelig at informasjon mistes.^{[trenger referanse]} Datahvelv er laget for å unngå eller minimere innvirkningen av disse utfordringene ved å flytte dem til områder i datavarehuset som er utenfor de historiske lagringsområdene (vasking gjøres via datatorg) og ved å separere strukturelementene (forretningsnøkler og assosiasjoner mellom forretningsnøklene) fra de beskrivende attributtene.

Dan Linstedt, skaperen av datahvelvmetoden, har beskrevet resulterende datahvelv-databaser som en detaljeorientert, historisk sporbar og unikt lenket mengde av normaliserte tabeller som støtter en eller flere funksjonelle områrder eller i en forretning. Det er en hybrid tilnærming som gjør seg nytte av fordelene med tredje normalform (3NF) og stjernemodellen. Designet er fleksibelt, skalerbart, konsistent og adapterbart for behovene i en virksomhet.

Datahvelv-filosofien er at alle data er relevante data, selv om de ikke følger den etablerte definisjonen og forretningsreglene. Hvis data ikke er i samsvarer (er konforme) med disse definisjonene og reglene er det et problem for forretningen, ikke datavarehuset. Bestemmelsen av om data er «feil» er en tolkning av dataene som stammer fra et spesifikt synspunkt som ikke nødvendigvis er gyldig for alle eller for alle tidspunkt. Derfor må datahvelv fange alle data, og bare tolke dem når man rapporterer eller henter ut data.

En annen utfordring som datahvelv svarer på er økte behov for fullstendig revisjon og sporbarhet av alle data i et datavarehus. Sarbanes–Oxley-krav (SOX) i USA og lignende krav i Europa har gjort dette til et relevant tema for mange implementeringer av forretningsinnsikt, og et fokus ved alle datahvelv er derfor implementering av komplett sporbarhet og mulighet for revisjon av all informasjon.

Data Vault 2.0 er en ny spesifikasjon og en åpen standard som byger på tre grunnprinsipper:

• Metode, for eksempel Software Engineering Institute (SEI) sin kapabilitet-modenhets-modell-integrasjon (CMMI), eller Six Sigma, livssyklus for systemutvikling (SDLC), og så videre
• Arkitektur: Blant annet et innputtlag med landingssone bestående av et vedvarende landingssone (persistent staging area, PSA) , et presentasjonslag (datatorg eller informasjonstorg), og håndtering av datakvalitetstjenester og grunndatatjenester.
• Modell

Innenfor metoden er implementasjon av mønsterpraksis definert. Data Vault 2.0 har et fokus på å inkludere nye komponenter som stordata og NoSQL, og fokuserer også på ytelsen til den nåværende modellen. Den gamle dokumentasjonen (som er dokumentert «her» for det meste) har et større fokus på datahvelv-modelleringen. Den er dokumentert i boken Building a Scalable Data Warehouse with Data Vault 2.0 (2015) av Dan Linstedt og Michael Olschimke.

Det er nødvendig å utvikle spesifikasjonen for å inkludere nye komponenter, samt mønsterpraksis for å holde datavarehus og forretningsinnsikt-systemer oppdaterte i takt med behov og ønsker fra dagens forretninger.

Historie

I 1990-årene utviklet Dan Linstedt datahvelvmodellering som modelleringsmetode, og i 2000 ble den utgitt som offentlig eiendom. Gjennom 5 artikler i The Data Administration Newsletter beskev og forklarte han de grunnleggende reglene for datahvelv. Disse artiklene inneholder henholdsvis en generell oversikt, en oversikt over komponentene, en diskusjon om sluttdatoer og skjøter, lenketabeller, og en artikkel om metoder for lasting.

Et alternativt (og sjeldent brukt) navn på datahvelvmetoden er common foundational integration modeling architecture (CIMA).

I 2013 kom Data Vault 2.0 og har med oppdateringer som stordata, NoSQL, ustrukturert, semi-strukturert sømløs integrasjon, samt mønsterpraksis for metodikk, arkitektur og implementasjon.

Alternative tolkninger

Ifølge Dan Linstedt er datamodellen inspirert av eller laget etter mønster fra et forenklet syn på det menneskelige nervesystemet:

• Nav og navsatellitter ligner på nevroner
• Lenker er dendritter (vektorer av informasjon)
• Andre lenker er synapser (vektorer i den motsatte retningen).

Ved å bruke algoritmer for datautvinning kan lenkene skåres med rangering for konfidens og styrke. De kan opprettes og droppes i farten i henhold til læring om relasjoner som per nå ikke eksisterer. Modellen kan automatisk morfes (forvandles), adapteres og justeres etterhvert som den blir brukt og får matet nye strukturer.

En annen oppfatning er at en datahvelvmodell gir en ontologi (beskriver begrepene) av virksomheten med tanke på at den beskriver begrepene i domenet til virksomheten (navene) og relasjonene mellom dem (lenker), og legger til beskrivende attributter (satellitter) der det er nødvendig.

En annen måte å tenke på en datahvelvmodell er som en grafisk modell. Datahvelvmodellen gir faktisk en «grafbasert» modell med nav og relasjoner i en «relasjonsdatabaseverden». På denne måten kan utvikleren bruke SQL for å få grafbaserte relasjoner med svartid under sekundet.

Grunnleggende begreper

Datahvelv prøver å løse problemet med å håndtere endringer i miljøet ved å skille forretningsnøklene (som ikke muterer (endrer seg) så ofte, fordi de unikt identifiserer en forretningsentitet), og assosiasjonene mellom disse forretningsnøklene, fra de beskrivende attributtene til disse nøklene.

Forretningsnøklene og deres assosiasjoner er strukturelle attributter som danner skjelettet til datamodellen. Datahvelvmetoden har som et av sine hovedaksiomer (grunnsetninger) at ekte forretningsnøkler kun endres når virksomheten endres, og derfor er de mest stabile elementene man kan bruke til å utlede strukturen til en historisk database. Dersom man bruker disse nøklene som ryggraden i et datavarehus kan man organisere resten av dataene rundt dem. Dette betyr at valg av de riktige nøklene for navene er av største betydning for stabiliteten til modellen. Nøklene lagres i tabeller med noen få begrensninger på strukturen. Disse nøkkeltabellene kalles nav.

Nav

Nav inneholder en liste over unike forretningsnøkler med lav tilbøyelighet til endring. Nav inneholder også en surrogatnøkkel for hvert navelement, og metadata som beskriver opprinnelsen til forretningsnøkkelen. De beskrivende attributtene for informasjonen i navet (for eksempel beskrivelsen for nøkkelen, muligens på flere språk) lagres i strukturer som kalles satellittabeller som vil bli diskutert lenger nede.

Navet inneholder minst de følgende feltene:

• En surrogatnøkkel: Brukes til å koble de andre strukturene til denne tabellen.
• En forretningsnøkkel: Driveren av dette navet. Forretningsnøkkelen kan bestå av flere felter.
• Oppføringns kilde: Kan brukes for å se hvilket system som lastet inn hver forretningsnøkkel først.
• Det er valgfritt å ha med metadatafelter med informasjon om manuelle oppdateringer (bruker/tid) og uttrekksdato.

Et nav har ikke lov til å inneholde flere forretningsnøkler, bortsett fra når to systemer leverer samme forretningsnøkkel, men med kollisjoner som har forskjellige betydninger.

Nav skal normalt ha minst en satellitt.

Eksempel på nav

Følgende er et eksempel på en navtabell som inneholder biler, kalt «Car» (H_CAR). Den drivende nøkkelen her er kjøretøyets chassisnummer.

Feltnavn	Beskrivelse	Obligatorisk?	Kommentar
H_CAR_ID	Sekvens-ID og surrogatnøkkel for navet	Nei	Anbefalt, men valgfri
VEHICLE_ID_NR	Forretningsnøkkel som driver navet. Kan være mer enn ett felt for en sammensatt forretningsnøkkel	Ja
H_RSRC	Kilden til oppføringen for denne nøkkelen ved første lasting	Ja
LOAD_AUDIT_ID	En ID til en tabell med revisjonsinformasjon, eksempelvis lastetid, varighet på lastingen, antall linjer, og så videre	Nei

Lenker

Assosiasjoner eller transaksjoner mellom forretningsnøkler (som for eksempel relaterer navene for kunde og produkt med hverandre gjennom kjøpstransaksjonen) modelleres ved hjelp av koblingstabeller. Disse tabellene er i utgangspunktet mange-til-mange-skjøtetabeller med noen metadata.

Lenker kan lenke til andre lenker for å håndtere endringer i granularitet (for eksempel vil det å legge til en ny nøkkel i en databasetabell endre finheten til databasetabellen). Hvis man for eksempel har en assosiasjon mellom kunde og adresse kan man legge en referanse til en lenke mellom navene for produkt og transportselskap. Dette kan være en lenke som kalles «Delivery». Referering til en lenke i en annen lenke anses som en dårlig praksis, fordi det introduserer avhengigheter mellom lenker som gjør parallell lasting vanskeligere. Siden en lenke til en annen lenke er den samme som en ny lenke med navene fra den andre lenken, er den foretrukne løsningen i disse tilfellene å opprette koblingene uten å referere til andre lenker (se avsnittet om lastepraksis for mer informasjon).

Lenker kobler noen ganger nav til informasjon som ikke i seg selv er nok for å konstruere et nav. Dette skjer når en av forretningsnøklene som er tilknyttet lenken ikke er en «ekte» forretningsnøkkel. Ta for eksempel et bestillingsskjema med «ordrenummer» som nøkkel, og ordrelinjer som er tastet inn med et semi-tilfeldig tall for å gjøre dem unike, og kall dette «unikt nummer». Sistnevnte nøkkel er ikke en ekte forretningsnøkkel, og er derfor ikke noe nav. Man må imidlertid bruke den for å garantere riktig granularitet for lenken. I dette tilfellet er løsningen å ikke bruke et nav med surrogatnøkkel, men istedet å legge selve forretningsnøkkelen «unikt nummer» til i lenken. Dette gjøres bare når det ikke noensinne er noen mulighet for å bruke forretningsnøkkelen til en annen lenke eller som nøkkel for attributter i en satellitt. Denne konstruksjonen har blitt kalt en «lenke med trebein» av Dan Linstedt på hans (nå nedlagte) forum.

Lenker inneholder surrogatnøkler for navene som er lenket, sin egen surrogatnøkkel for lenken og metadata som beskriver opprinnelsen til assosiasjonen. De beskrivende attributtene for informasjonen om assosiasjonen (for eksempel tid, pris eller beløp) lagres i strukturer som kalles satellitttabeller som er omtalt lenger nede.

Eksempel på lenke

Følgende er et eksempel på en lenketabell mellom to nav for biler (H_CAR) og personer (H_PERSON). Koblingen heter «Driver» (L_DRIVER).

Feltnavn	Beskrivelse	Obligatorisk?	Kommentar
L_DRIVER_ID	Sekvens-ID eller surrogatnøkkel for lenken	Nei	Anbefalt, men valgfri
H_CAR_ID	Surrogatnøkkel for Car-navet, det første ankeret til lenken	Ja
H_PERSON_ID	Surrogatnøkkel for Person-navet, det andre ankeret til lenken	Ja
L_RSRC	Oppføringens kilde for denne assosiasjonen da den først ble lastet	Ja
LOAD_AUDIT_ID	En ID til en tabell med revisjonsinformasjon, eksempelvis lastetid, varighet på lastingen, antall linjer, og så videre	Nei

Satellitter

Navene og lenkene danner strukturen til modellen, men har ingen temporale attributter og har ingen beskrivende attributter. Disse er lagret i separate tabeller kalt satellitter. De består av metadata som knytter dem til deres overordnede nav eller lenke, metadata som beskriver opprinnelsen til assosiasjonen og attributtene, samt en tidslinje med start- og sluttdatoer for attributten. Mens navene og lenkene gir strukturen til modellen, gir satellittene «kjøttet» til modellen, ved å gi konteksten for forretningsprosessene som fanges opp i nav og lenker. Disse attributtene lagres både med hensyn til detaljene i saken og tidslinjen, og kan variere fra ganske komplekse (alle feltene som beskriver en klient sin komplette profil) til ganske enkle (en satellitt på en lenke med bare én gyldig indikator og én tidslinje).

Vanligvis er attributtene gruppert i satellitter etter kildesystem. Imidlertid kan beskrivende attributter som størrelse, kostnad, hastighet, mengde eller farge endres med forskjellige hastigheter, slik at man også kan dele disse attributtene opp i forskjellige satellitter basert på deres endringshastighet.

Alle tabellene inneholder metadata, som minimalt beskriver minst kildesystemet og datoen da denne oppføringen ble gyldig, hvilket gir en fullstendig historisk oversikt over dataene etterhvert som de ankommer datavarehuset.

Eksempel på satellitt

Dette er et eksempel på en satellitt på drivere-koblingen mellom navene for biler og personer, kalt «Driver insurance» (S_DRIVER_INSURANCE). Denne satellitten inneholder attributter som er spesifikke for forsikringen av forholdet mellom bilen og personen som kjører den, for eksempel en indikator på om dette er den primære sjåføren, navnet på forsikringsselskapet for denne bilen og personen (kan også være et eget knutepunkt) og et sammendrag av antall ulykker med denne kombinasjonen av kjøretøy og sjåfør. Det er også inkludert en referanse til en oppslags - eller referansetabell kalt R_RISK_CATEGORY som inneholder kodene for risikokategorien der dette forholdet anses å falle.

Feltnavn	Beskrivelse	Obligatorisk?	Kommentar
S_DRIVER_INSURANCE_ID	Sekvens-ID og surrogatnøkkel for satellitten på lenken	Nei	Anbefalt, men valgfri
L_DRIVER_ID	(Surrogat) primærnøkkel for Driver-lenken, forelderen til satellitten	Ja
S_SEQ_NR	Ordnet- eller følge-nummer, for å håndheve unikheten hvis det er flere gyldige satellitter for en foreldrenøkkel	Nei(**)	D ette kan skje hvis, for eksempel, man har et nav COURSE og navnet til COURSE er en attributt, men på flere ulike språk
S_LDTS	Lastedato (startdato) for validiteten til denne kombinasjonen av attributt-verdier for foreldrenøkkelen L_DRIVER_ID	Ja
S_LEDTS	Laste-sluttdato (sluttdato) for validiteten til kombinasjonen av attributtverdier for foreldrenøkkelen L_DRIVER_ID	Nei
IND_PRIMARY_DRIVER	Indikator for om sjåføren er hoved-sjåføren for denne bilen	Nei (*)
INSURANCE_COMPANY	Navnet på forsikringsselskapet for dette kjøretøyet og denne sjåfæren	Nei (*)
NR_OF_ACCIDENTS	Antallet ulykker for denne sjåføren i denne bilen	Nei (*)
R_RISK_CATEGORY_CD	Risikokategorien for denne skåføren. Dette er en referanse til R_RISK_CATEGORY	Nei (*)
S_RSRC	Kildeoppføringen for denne informasjonen i denne satellitten da den opprinnelig ble lastet	Ja
LOAD_AUDIT_ID	En ID til en tabell med revisjonsinformasjon, eksempelvis lastetid, varighet på lastingen, antall linjer, og så videre	Nei

(*) minst en attributt er obligatorisk

(**) sekvensnummeret blir obligatorisk hvis det er nødvendig å håndheve unikheten for flere gyldige satellitter i samme nav eller lenke

Referansetabeller

Referansetabeller er en normal del av en sunn datahvelvmodell. De er der for å hindre redundant lagring av enkle referansedata som det refereres mye til. Mer formelt definerer Dan Linstedt referansedata som:

«Enhver informasjon som ansees som nødvendig for å løse beskrivelser fra koder, eller for å oversette nøkler på en konsistent måte. Mange av disse feltene er "deskriptive" i sin natur og beskriver en spesifikk tilstand for den andre enda viktigere informasjonen. Som sådan lever referansedata i separate tabeller fra de råe datahvelv-tabellene.»

Referansetabeller blir referert til fra satellitter, men er aldri bundne med fysiske fremmednøkler. Det er ingen foreskrevet struktur for referansetabeller, og man skal bruke det som fungerer best i det spesifikke tilfellet, som kan være alt fra enkle oppslagstabeller til små datahvelv, eller til og med stjerner. De kan være historiske eller ikke ha noen historie, men det anbefales i så fall at man holder seg til de naturlige nøklene og ikke oppretter surrogatnøkler i det tilfellet. Normalt har datahvelv mange referansetabeller, akkurat som alle andre datavarehus.

Eksempel på referanse

Følgende er et eksempel på en referansetabell med risikokategorier for førere av kjøretøy. Den kan refereres til fra hvilken som helst satellitt i datahvelvet. For dette eksempelet refererer vi til den fra satellitt S_DRIVER_INSURANCE. Referansetabellen er R_RISK_CATEGORY.

Feltnavn	Beskrivelse	Obligatorisk?
R_RISK_KATEGORI _CD	Koden for risikokategorien	Ja
RISK_CATEGORY_DESC	Beskrivelse av risikokategori	Ingen (*)

( * ) minst en attributt er obligatorisk

Spøkelsesoppføringer

I datahvelv er en spøkelsesoppføring (ghost record) en oppføring (for eksempel en rad) som inneholder en spesiell plassholder for å vise at raden mangler en verdi, men uten å bruke SQL-nøkkelordet NULL. Dette gjør det mulig å effektivt spørre om indre sammenføyninger (inner joins). Spøkelsesoppføringer settes inn i satellittabeller når de opprettes. Når man kjører spørringer mot navtabell og satellittabell, eller navtabell og lenketabell, vil nav og lenker ikke inneholde spøkelsesoppføringene. Spøkelsesoppføringene er en viktig komponent i øyeblikkstabellene for å gjøre ekviskjøter (sammenføyninger hvor det kun brukes likhetstegn i JOIN-predikatet). Hvis ingen oppføring har kommet (sent ankommende data) vil det alltid refereres til spøkelsesoppføringen. Derfor brukes spøkelsesoppføringer til å fullføre ekviskjøter mellom øyeblikkstabeller og nærliggende satellittabeller.

Datahvelv sin bruk av begrepet må ikke forveksles med spøkelsesoppføringer i Microsoft SQL Server, hvor det refererer til oppføringer som har blitt slettet logisk fra en tabell (for eksempel ved å markere oppføringen ved å bruke en flaggkolonne), men fremdeles fysisk eksisterer i datalageret som spøkelsesoppføringer eller spøkelsesrader.

Nullnøkler

Nullnøkler brukes for gå kunne gjøre ekviskjøter for å sammenføye nav- og lenketabeller (og minner dermed om hvordan spøkelsesoppføringer brukes for øyeblikkstabeller). Nullnøkler fungerer som plassholdere når data ankommer uten forretningsnøkler. De manglende nøklene byttes da ut med for eksempel verdien -1.

Det finnes to typer nullnøkler: påkrevde og valgfrie. Dersom det lander flere forretningsnøkler som utgjør en arbeidsenhet kan noen av deltakerne i arbeidsenheten være valgfrie. Da kan samme metode brukes, og lenketabellen med arbeidsenheten inneholder derfor både de obligatoriske og valgfrie nullnøklene.

Forøvrig anbefaler Kimball på en lignende måte å substituere nullverdier for bruk i stjernemodeller, men denne bruken er til analyseformål og skiller seg dermed fra bruken i datahvelv. Den underliggende mekanikken med å utnytte ekviskjøter er likevel lik.

Lastepraksis

ETL-jobben for å oppdatere en datahvelvmodell er ganske rett frem (se Dan Lindsted sin artikkel Data Vault Series 5 – Loading Practices). Først må man laste inn alle navene og opprette surrogat-ID-er for eventuelt nye forretningsnøkler. Når dette er gjort kan man løse alle forretningsnøklene til surrogat-ID-er dersom man spør navet. Det andre steget er å løse koblingene mellom navene, og opprette surrogat-ID-er for eventuelle nye assosiasjoner. Samtidig kan man også opprette alle satellitter som er koblet til ulike nav, siden man kan løse nøkkelen til en surrogat-ID. Når man har opprettet alle de nye koblingene med surrogatnøklene, kan man legge til satellittene i alle lenkene.

Siden navene ikke er koblet til hverandre bortsett fra gjennom lenker kan man laste alle navene parallelt. Siden lenker ikke er festet direkte til hverandre kan alle koblingene også lastes parallelt. Siden satellitter bare kan festes til nav og lenker kan man også laste disse parallelt.

ETL-en er ganske rett frem, og egner seg til enkel automatisering eller bruk av maler. Problemer oppstår bare med lenker som relaterer til andre lenker, fordi løsing av forretningsnøklene i lenken bare fører til en annen lenke som også må løses. På grunn av ekvivalensen av denne situasjonen med en kobling til flere nav kan dette problemet unngås ved å remodellere slike tilfeller, og dette er faktisk den anbefalte praksisen.

Data slettes aldri fra datahvelvet med mindre man får en teknisk feil under lasting av data.

Datahvelv og dimensjonsmodellering

Det datahvelvmodellerte laget brukes vanligvis til å lagre data. Det er ikke optimalisert for spørringsytelse, og det er heller ikke lett å spørre ved bruk av kjente spørreverktøy som Cognos, Oracle Business Intelligence Suite Enterprise Edition, SAP Business Objects, Pentaho, med flere.^{[trenger referanse]} Siden disse sluttbruker-verktøyene forventer eller foretrekker at dataene leveres som en dimensjonsmodell vil en konvertering vanligvis være nødvendig.

For konverteringsformål kan navene og relaterte satellitter på disse navene betraktes som dimensjoner, og lenkene og relaterte satellitter på disse lenkene kan sees på som faktatabeller i en dimensjonsmodell. Dette gjør at man raskt kan prototype en dimensjonsmodell basert på en datahvelvmodell ved hjelp av visninger.

Merk at selv om det er relativt greit å flytte data fra en datahvelvmodell til en (renset) dimensjonsmodell, er det motsatte ikke like enkelt, ettersom at den denormaliserte naturen til faktatabeller i dimensjonsmodeller fundamentalt er forskjellige fra den tredje normalformen i datahvelvet.

Datahvelvmetodikk

Datahvelvmetodikken er basert på SEI/CMMI nivå 5 mønsterpraksis. Dette inkluderer flere komponenter av CMMI nivå 5, og kombinerer dem med mønsterpraksis fra Six Sigma, total kvalitetsledelse (TQM) og livssykel for systemutvikling (SDLC). Det er spesielt fokusert på Scott Ambler sin smidige metodikk for bygging og utrulling. Datahvelvprosjekter har en kort, omfangsstyrtutgivelsessyklus, og bør ha en produksjonsutgivelse hver 2-3 uke.^{[trenger referanse]}

Lag som bruker datahvelvmetodikken bør raskt tilpasse seg de repeterbare, konsistente og målbare prosjektene som forventes på CMMI nivå 5. Data som strømmer gjennom datavarehuset sitt datahvelvsystem vil begynne å følge livssykelen for total kvalitetsledelse (TQM) som lenge har manglet fra prosjekter innen forretningsinnsikt.

Se også

• Bill Inmon
• Blokkjede, en digital og distribuert hovedbok for transaksjoner som ikke kan endres uten at det oppdages
• Datamaske, en desentralisert og domeneorientert dataarkitektur med funksjonalitet for selvbetjening
• Datavarehus
• Kimball-livssykelen, en høynivå sekvens av oppgaver for å designe, utvikle og rulle ut et datavarehus eller forretningsinnsikt-system
• Nøkkelkollisjon

Litteratur

• Linstedt, Dan (desember 2010). Super Charge your Data Warehouse. Dan Linstedt. ISBN 978-0-9866757-1-3. 
• Data Warehousing for Dummies, 2nd edition. John Wiley & Sons. februar 2009. ISBN 978-0-470-40747-9. 
• Ronald Damhof; Lidwine van As (25. august 2008). «The next generation EDW – Letting go of the idea of a single version of the truth» (PDF). Database Magazine (DB/M). Array Publications B.V. 
• Linstedt, Dan. «Data Vault Series 1 – Data Vault Overview». Data Vault Series. The Data Administration Newsletter. Besøkt 12. september 2011. 
• Linstedt, Dan. «Data Vault Series 2 – Data Vault Components». Data Vault Series. The Data Administration Newsletter. Besøkt 12. september 2011. 
• Linstedt, Dan. «Data Vault Series 3 – End Dates and Basic Joins». Data Vault Series. The Data Administration Newsletter. Besøkt 12. september 2011. 
• Linstedt, Dan. «Data Vault Series 4 – Link Tables». Data Vault Series. The Data Administration Newsletter. Besøkt 12. september 2011. 
• Linstedt, Dan. «Data Vault Series 5 – Loading Practices». Data Vault Series. The Data Administration Newsletter. Besøkt 12. september 2011. 
• Kunenborg, Ronald. «Data Vault Rules v1.0.8 Cheat Sheet» (PDF). Data Vault Rules. Grundsätzlich IT. Besøkt 26. september 2012. 
• Linstedt, Dan. «Data Vault Modeling Specification v1.0.9». Data Vault Forum. Dan Linstedt. Arkivert fra originalen 30. november 2012. Besøkt 26. september 2012. 
• Linstedt, Dan. «Data Vault Loading Specification v1.2». DanLinstedt.com. Dan Linstedt. Arkivert fra originalen 3. januar 2014. Besøkt 3. januar 2014. 
• Linstedt, Dan. «A short intro to #datavault 2.0». DanLinstedt.com. Dan Linstedt. Arkivert fra originalen 3. januar 2014. Besøkt 3. januar 2014. 
• Linstedt, Dan. «Data Vault 2.0 Being Announced». DanLinstedt.com. Dan Linstedt. Arkivert fra originalen 21. august 2012. Besøkt 3. januar 2014. 
• Ketelaars, M.W.A.M. (25. november 2005). «Datawarehouse-modelleren met Data Vault». Database Magazine (DB/M). Array Publications B.V. (7): 36–40. 
• Verhagen, K.; Vrijkorte, B. (10. juni 2008). «Relationeel versus Data Vault». Database Magazine (DB/M). Array Publications B.V. (4): 6–9. 
• Patrick Cuba: The Data Vault Guru. A Pragmatic Guide on Building a Data Vault. Selbstverlag, ohne Ort 2020, ISBN 979-86-9130808-6.
• John Giles: The Elephant in the Fridge. Guided Steps to Data Vault Success through Building Business-Centered Models. Technics, Basking Ridge 2019, ISBN 978-1-63462-489-3.
• Kent Graziano: Better Data Modeling. An Introduction to Agile Data Engineering Using Data Vault 2.0. Data Warrior, Houston 2015.
• Hans Hultgren: Modeling the Agile Data Warehouse with Data Vault. Brighton Hamilton, Denver u. a. 2012, ISBN 978-0-615-72308-2.
• Dirk Lerner: Data Vault für agile Data-Warehouse-Architekturen. In: Stephan Trahasch, Michael Zimmer (Hrsg.): Agile Business Intelligence. Theorie und Praxis. dpunkt.verlag, Heidelberg 2016, ISBN 978-3-86490-312-0, S. 83–98.
• Daniel Linstedt: Super Charge Your Data Warehouse. Invaluable Data Modeling Rules to Implement Your Data Vault. Linstedt, Saint Albans, Vermont 2011, ISBN 978-1-4637-7868-2.
• Daniel Linstedt, Michael Olschimke: Building a Scalable Data Warehouse with Data Vault 2.0. Morgan Kaufmann, Waltham, Massachusetts 2016, ISBN 978-0-12-802510-9.
• Dani Schnider, Claus Jordan u. a.: Data Warehouse Blueprints. Business Intelligence in der Praxis. Hanser, München 2016, ISBN 978-3-446-45075-2, S. 35–37, 161–173.