Datahvelvmodellering

Fra Wikipedia, den frie encyklopedi
(Omdirigert fra «Datahvelv»)
En enkel datahvelvmodell med to nav (blå), en lenke (grønn) og fire satellitter (gul)

Datahvelvmodellering,[1][2][3] 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.

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).[4] 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»[5] 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.[6] Datahvelv er laget for å muliggjøre parallell lasting så mye som mulig,[7] 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.[8] Både datahvelv og ankermodeller er entitetsbaserte modeller,[9] men ankermodeller er en mer normalisert tilnærming.[trenger referanse]

Hovedentitetene i et datahvelv er:

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[rediger | rediger kilde]

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.[10]

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[når?] og en åpen standard[11] 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[rediger | rediger kilde]

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,[12] en oversikt over komponentene,[13] en diskusjon om sluttdatoer og skjøter,[14] lenketabeller,[15] og en artikkel om metoder for lasting.[16]

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

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

Alternative tolkninger[rediger | rediger kilde]

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

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.[20]

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[rediger | rediger kilde]

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.[21] Nøklene lagres i tabeller med noen få begrensninger på strukturen. Disse nøkkeltabellene kalles nav.

Nav[rediger | rediger kilde]

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:[22]

  • 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.[23]

Eksempel på nav[rediger | rediger kilde]

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[24]
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[rediger | rediger kilde]

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[rediger | rediger kilde]

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[rediger | rediger kilde]

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[rediger | rediger kilde]

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[rediger | rediger kilde]

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.»[25]

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.[26] Normalt har datahvelv mange referansetabeller, akkurat som alle andre datavarehus.

Eksempel på referanse[rediger | rediger kilde]

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[rediger | rediger kilde]

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).[27] 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.[27] Spøkelsesoppføringene er en viktig komponent i øyeblikkstabellene for å gjøre ekviskjøter (sammenføyninger hvor det kun brukes likhetstegn i JOIN-predikatet).[27] 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[28]), men fremdeles fysisk eksisterer i datalageret som spøkelsesoppføringer[29] eller spøkelsesrader.[30]

Nullnøkler[rediger | rediger kilde]

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.[27]

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.[27]

Forøvrig anbefaler Kimball på en lignende måte å substituere nullverdier for bruk i stjernemodeller,[31] 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.[27]

Lastepraksis[rediger | rediger kilde]

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.[32]

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

Datahvelv og dimensjonsmodellering[rediger | rediger kilde]

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[rediger | rediger kilde]

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å[rediger | rediger kilde]

  • 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

Referanser[rediger | rediger kilde]

  1. ^ «Distribusjon av datahvelv på Azure SQL Data Warehouse». azure.microsoft.com. Arkivert fra originalen 22. februar 2023. Besøkt 20. februar 2023. 
  2. ^ «Data Vault: Building a Scalable Data Warehouse Träningskurs». www.nobleprog.se. Besøkt 20. februar 2023. 
  3. ^ «Vad är datavalvmodellering och varför behöver vi det? - Dataintelligens.» (svensk). 20. august 2020. Besøkt 20. februar 2023. 
  4. ^ Super Charge your data warehouse, page 74
  5. ^ The next generation EDW
  6. ^ Super Charge your data warehouse, page 21
  7. ^ Super Charge your data warehouse, page 76
  8. ^ Porsby, Johan. «Rålager istället för ett strukturerat datalager». www.agero.se (svensk). Besøkt 22. februar 2023. 
  9. ^ Porsby, Johan. «Datamodeller för data warehouse». www.agero.se (svensk). Besøkt 22. februar 2023. 
  10. ^ The New Business Supermodel, glossary, page 75
  11. ^ A short intro to#datavault 2.0
  12. ^ Data Vault Series 1 – Data Vault Overview
  13. ^ Data Vault Series 2 – Data Vault Components
  14. ^ Data Vault Series 3 – End Dates and Basic Joins
  15. ^ Data Vault Series 4 – Link tables, paragraph 2.3
  16. ^ Data Vault Series 5 – Loading Practices
  17. ^ Data Warehousing for Dummies, page 83
  18. ^ A short intro to #datavault 2.0
  19. ^ Data Vault 2.0 Being Announced
  20. ^ Super Charge your Data Warehouse, paragraph 5.20, page 110
  21. ^ Super Charge your data warehouse, page 61, why are business keys important
  22. ^ Data Vault Forum, Standards section, section 3.0 Hub Rules
  23. ^ Data Vault Forum, Standards section, section 3.0 Hub Rules
  24. ^ Data Vault Modeling Specification v1.0.9
  25. ^ Super Charge your Data Warehouse, paragraph 8.0, page 146
  26. ^ Super Charge your Data Warehouse, paragraph 8.0, page 149
  27. ^ a b c d e f Data Vault Mysteries… Zero Keys & Ghost Records… | by Patrick Cuba | Snowflake | Medium
  28. ^ What is logical deletion and physical deletion? | by off.tokyo | Medium
  29. ^ SQL SERVER - What Are Ghost Records and How to Clean Them Up? - SQL Authority with Pinal Dave
  30. ^ The ghost cleanup task for SQL Server Databases
  31. ^ Becker, Bob (6. oktober 2010). «Design Tip #128 Selecting Default Values for Nulls». Kimball Group (engelsk). Besøkt 5. april 2023. 
  32. ^ Data Vault Series 5 – Loading Practices

Litteratur[rediger | rediger kilde]

Hentet fra «https://no.wikipedia.org/w/index.php?title=Datahvelvmodellering&oldid=24293264»