Data Vault 2.0 methodology tar ikke bare modellering teknikk, men gir en hel metodikk for Alle Datavarehus Prosjekter. Indellient se Er Data Vault modellering som en svært levedyktig tilnærming for å møte behovene til datavarehus prosjekter, hvor både historisk sporing og revisjon er to viktige faktorer.

i mange år har business intelligence (BI) – prosjekter operert under en fossemodell. Det er definert av en lang strukket sekvens av hver fase som krever en uttømmende liste over forhåndskrav, en komplett datamodelldesign etterfulgt av kodifisering av alle harde og myke forretningsregler i ETL-prosesser. Visualiseringslaget er sekvensielt bygget og presentert for sluttbrukere for logg av-måneder eller år fra den opprinnelige startdatoen.

Ganske ofte ser vi også lag vedta en» redusert omfang » – versjon av waterfall som tar sikte på å bryte store BI-initiativer i mindre prosjekter. Selv om DETTE bidrar til å redusere total kompleksitet, er denne tilnærmingen, når DEN brukes PÅ BI, fortsatt ganske risikabelt på grunn av to primære bekymringer:

  • forretningskravene endrer seg nå raskere enn evnen til å levere;
  • og budsjettinnehavere er uvillige til å bruke på langsiktige prosjekter uten materialiserte kortsiktige resultater.

ovennevnte grunner er hvorfor vi har sett et skifte i prosjektmetodologier fra foss til den iterative, smidige tilnærmingen til agile-som gjenkjenner og gir noen svar på disse problemene.

innen dataanalysedomenet adresserer agile alene ikke de betydelige utfordringene vi møter på De mer detaljerte nivåene Av datavarehus eller BI-prosjekter. Disse inkluderer:

  • iterere over datamodellering
  • minimere refactoring
  • utforming AV ETL-eller ELT-rutiner som muliggjør rask respons på endringer i forretningslogikk eller nye tillegg av data
  • en tilnærming til å samle forretningskrav som vil være nært knyttet til inngangen som kreves for designbeslutninger

som svar på disse utfordringene, daniel linstedt, forfatter av bygningen skalerbart datalager med data vault 2.0, definerer en metodikk som fokuserer på å få mest mulig ut av smidig praksis med andre velprøvde disipliner og teknikker for å levere det som synes å være den mest iterative tilnærmingen TIL BI ennå.

Vi Presenterer Data Vault

I Motsetning til popular tro Er Data Vault (DV) Ikke bare en modelleringsteknikk, Det Er en hel metodikk for datavarehusprosjekter. Det binder sammen aspekter av agile, BEAM requirements gathering, CMMI, TQM, Six Sigma og Data Vault Modellering for å definere en tilnærming rettet mot å forbedre både hastigheten og kvaliteten PÅ BI-prosjekter. Jeg refererer til det som «guided missile approach» siden det fremmer både tilpasning og nøyaktighet.

DV omfatter også smidige metoder for ESTIMERING AV DW-prosjekt og smidig oppgavestørrelse for å bestemme den tradisjonelt oversett kompleksiteten eller arbeidsinnsatsen som er involvert i de vanlige dw-komponentene. På de lavere nivåene presenterer den også en veldig kortfattet og iterativ tilnærming til å takle vanlige tekniske leveranser (innen BI-verdenen) med nye eller endrede funksjonsforespørsler. Disse inkluderer gjennomtenkte, repeterbare, trinnvise og smidige prosesser for å utføre hyppige oppgaver.

disse oppgavene inkluderer (men er ikke begrenset til) å legge til dataattributter, skiver, nye kilder, utvidede kilder, historisk sporing, avskrivningskilder og kildestrukturendringer i både etl-og Modelleringsfasene.

DV-modellen, i et nøtteskall, er et lag som eksisterer mellom vanlig dimensjonsmodellering (OLAP, Star Schema) og Staging som gir skalering med voksende forretningsbehov og tjener til å bryte ned kompleksiteten til både modellering og ETL. Den består av huber( forretningsenheter), lenker (relasjoner) og satellitter (beskrivende attributter) som er modellert et sted mellom 3NF og star-skjemaet. Modellen er plassert inne i dataintegrasjonslaget i datalageret, ofte referert Til Som Raw Data Vault, og brukes effektivt i kombinasjon Med Kimballs modell.

Tips: hvis du er interessert i å forstå modellen og dens understrekende regler, foreslår jeg å ta en kopi av Dans bok nevnt ovenfor.

Datahvelv 2.0 Fordeler

her er en oversikt over noen viktige fordeler fra Data Vault 2.0-Tilnærmingen:

  • det forutsetter worst case scenario for datamodellering relasjoner. N: M relasjoner mellom forretningsobjekter for å eliminere behovet for oppdateringer hvis en 1: M blir Til En M: M. Dermed krever nesten ingen ekstra arbeid I Data Vault når graden av forholdet endres.
  • Den er designet for historisk sporing av alle aspekter av data – relasjoner og attributter, samt hvor dataene blir hentet fra over tid. Satellitter, som ligner dimensjoner, opererer på SAMME MÅTE SOM SCD Type 2.
  • Legger frem et sett med designprinsipper & strukturer for å øke historisk sporingsytelse i Hvelvet (PiT og Bridge). Data Vault-modellen er fleksibel nok til å ta i bruk disse strukturene når som helst i den iterative modelleringsprosessen og krever ikke avansert planlegging.
  • Designet for å logisk skille mellomrom som inneholder rå vs endrede data. Rådatahvelv er grunnlaget for data som kan revideres til kildesystemer, og forretningshvelvet gir et sted for avanserte brukere som trenger tilgang til data ett skritt ned fra informasjonsmart.
  • Skiller ut myke og harde forretningsregler i ulike deler av dataintegrasjonen. Dette håndhever gjenbruk av data på tvers av flere sluttbruk. For eksempel er rådata bare hentet en gang i Data Vault (mindre re-integrere i staging) og kan mates flere ganger til nedstrøms behov.
  • For hver agile-iterasjon er Data Vault-modellen, som lagrer all historisk sporing av data, lett utvidbar uten å måtte bekymre seg for å miste historiske data. Også historisk sporing lagres uavhengig av den dimensjonale modellen.
  • Data Vault 2.0 talsmenn hash nøkkel implementering av forretningsnøkler for å redusere oppslag og dermed øke lasting parallellisering. Dette resulterer i mindre sekvensielle lasteavhengigheter.
  • Rådatahvelvet er designet for å være fullstendig reviderbart.
  • som helhet er behandlingen involvert i Å gå fra Staging Til Star Schema & OLAP gjort mye mer jevnt & iterativ med Data Vault.
  • Det gir en veldig gjennomtenkt tilnærming til å kombinere data med flere forskjellige forretningsnøkler fra heterogene datakilder (et vanlig problem med å integrere data i lageret på tvers av flere kildesystemer). Forretningsnøkler er ikke alltid 1: 1 eller i samme format.
  • den»just in time» modellering mentalitet er en god match med smidig tilnærming.

Ulempene

mens Det er mange fordeler Med Data Vault, har Det også sine mangler, for eksempel:

  • Data Vault er i hovedsak et lag mellom information mart / star schema og staging. Det er noen ekstra overhead som følger med å utvikle dette laget både når det gjelder ETL-utvikling og modellering. Hvis prosjektet er i liten skala eller prosjektets levetid er kortvarig, kan det ikke være verdt å forfølge En Data Vault modell.
  • En av de viktigste drivende faktorene bak bruk Av Data Vault er for både revisjon og historiske sporingsformål. Hvis ingen av disse er viktige for deg eller din organisasjon, kan det være vanskelig å spise overhead som kreves for å introdusere et annet lag i modelleringen. Men når det gjelder langsiktige krav, kan det være en verdig investering på forhånd.
  • Data Vault representerer en nedbrutt tilnærming til relasjoner, forretningsnøkler og attributter, og derfor er antall tabeller som opprettes høyt sammenlignet med denormaliserte strukturer som star schema. Men vurder At Data Vault komplimenterer star schema, så denne sammenligningen er kun til kontrastformål. Av denne grunn kreves mange sammenføyninger for å vise data i DV.
  • NÅR du skriver dette – dv ressurser er begrenset. Komplekse prosjekter som bruker DV 2.0 er ikke utbredt informasjon.
  • modelleringsmetoden kan generelt være svært ukonvensjonell for de som har operert Under Kimball og (mindre) Inmons modeller.

Skal Du Forfølge Data Vault?

svaret avhenger av noen få variabler.

Vi ser På Data Vault modellering som en svært levedyktig tilnærming for å møte behovene til datavarehus prosjekter, hvor både historisk sporing og revisjon er to viktige faktorer.

I Tillegg, Hvis relasjoner på tvers av forretningsenheter stadig utvikler seg i dataene dine (eksempel 1:M Til M:M ), Forenkler Data Vault registreringen av disse relasjonene og lar deg fokusere mer på å levere reell verdi.

Hvis organisasjonen planlegger å lagre PII-data i lageret og er underlagt GDPR, HIPPA eller andre forskrifter, Hjelper Data Vault med datarevisjoner og sporbarhet.

Det vil være viktig å ta både fordelene og ulempene som er nevnt ovenfor for å hjelpe deg med å velge om En Data Vault-tilnærming er fordelaktig for din brukstilfelle.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.

lg