miniatyr|En enkel datahvelvmodell med to nav (blå), en lenke (grønn) og fire satellitter (gul)
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.
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).Super Charge your data warehouse, page 74 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»The next generation EDW 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.Super Charge your data warehouse, page 21 Datahvelv er laget for å muliggjøre parallell lasting så mye som mulig,Super Charge your data warehouse, page 76 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.
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. Begge teknikkene har utfordringer med tanke på å håndtere endringer i systemene som mater datavarehuset. 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. 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.The New Business Supermodel, glossary, page 75
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 virksomhetsetterretning, 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 standardA short intro to#datavault 2.0 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 virksomhetsetterretnings-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,Data Vault Series 1 – Data Vault Overview en oversikt over komponentene,Data Vault Series 2 – Data Vault Components en diskusjon om sluttdatoer og skjøter,Data Vault Series 3 – End Dates and Basic Joins lenketabeller,Data Vault Series 4 – Link tables, paragraph 2.3 og en artikkel om metoder for lasting.Data Vault Series 5 – Loading Practices
Et alternativt (og sjeldent brukt) navn på datahvelvmetoden er common foundational integration modeling architecture (CIMA).Data Warehousing for Dummies, page 83
I 2013 kom Data Vault 2.0A short intro to #datavault 2.0Data Vault 2.0 Being Announced 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.Super Charge your Data Warehouse, paragraph 5.20, page 110
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.Super Charge your data warehouse, page 61, why are business keys important 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:Data Vault Forum, Standards section, section 3.0 Hub Rules
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.Data Vault Forum, Standards section, section 3.0 Hub Rules
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.