Datavisning DATA VAULT

I de tidligere artikler, ble vi kjent med grunnleggende DATA VAULT, utvidelsen av DATA VAULT til en mer analysevennlig tilstand og opprettelsen av BUSINESS DATA VAULT. Det er på tide å fullføre serien med den tredje artikkelen.

Som jeg annonserte i forrige publikasjonen, vil denne artikkelen omhandle emnet BI, mer spesifikt forberedelsen av DATA VAULT som datakilde for BI. La oss se på hvordan vi kan opprette faktabord og dimensjoner og dermed lage et stjerneschema.

Da jeg begynte å studere engelskspråklige materialer om oppretting av datavarehus over DATA VAULT, fikk jeg følelsen av at prosessen var ganske kompleks. Siden artiklene har et betydelig volum, inneholder de henvisninger til endringer i formuleringene som har oppstått i metodikken Data Vault 2.0, og viktigheten av disse formuleringene blir også fremhevet.

Imidlertid, etter å ha dykket dypere inn i oversettelsen, ble det klart at prosessen ikke er så vanskelig. Men, kanskje vil du ha en annen mening.

Så, la oss komme til kjernen.

Dimensjonstabeller og faktabord i DATA VAULT

Den mest vanskelige informasjonen å forstå:

• Dimensjonstabeller bygges på informasjonen fra huber og deres satellitter;
• Faktabord bygges på informasjon fra linker og deres satellitter.

Og dette er åpenbart etter å ha lest artikkelen om grunnleggende DATA VAULT. Hubene lagrer unike nøkler til forretningsobjekter, deres satellitter er tilstandsattributtene til forretningsobjektene knyttet til tid; satellitter knyttet til linker som støtter transaksjoner, lagrer numeriske egenskaper ved disse transaksjonene.

Teorien slutter i prinsippet her.

Men, likevel, etter min mening, er det nødvendig å merke seg et par begreper som kan dukke opp i artikler om metodikken DATA VAULT:

• Raw Data Marts – vitrinene av "rå" data;
• Information Marts – informasjonsvitriner.

Begrepet "Raw Data Marts" refererer til vitrinene bygget over DATA VAULT-data ved å utføre relativt enkle JOIN-er. Tilnærmingen "Raw Data Marts" gjør det mulig å fleksibelt og raskt utvide prosjektet lagringsmessig med informasjon som er egnet for analyse. Denne tilnærmingen krever ikke komplekse datatransformasjoner og utførelsen av forretningsregler før dataene legges i vitrinene, men dataene i "Raw Data Marts" må være forståelige for forretningsbrukeren og tjene som grunnlag for videre transformasjon, for eksempel ved hjelp av BI-verktøy.

Begrepet “Information Marts” oppstod i metodologien Data Vault 2.0, og erstattet det gamle begrepet “Data Marts”. Denne endringen er forårsaket av en bevissthet om oppgaven å implementere datamodellen for rapportering som en transformasjon av data til informasjon. Skjemaet “Information Marts” skal først og fremst gi virksomheten beslutningsdyktig informasjon.

Selv om definisjonene er litt omstendelige, gjenspeiler de to enkle fakta:

1. Vitriner av typen “Raw Data Marts” bygges på rå (RAW) DATA VAULT, et lager som kun inneholder grunnleggende konsepter: HUBS, LINKS, SATELLITES;
2. Vitriner “Information Marts” bygges med bruk av elementene fra BUSINESS VAULT: PIT, BRIDGE.

Når vi ser på eksempler på lagring av informasjon om ansatte, kan vi si at en vitrine som viser nåværende (gyldig per i dag) telefonnummer til en ansatt – dette er en vitrine av typen “Raw Data Marts”. For å lage en slik vitrine brukes den forretningsmessige nøkkelen til den ansatte og funksjonen MAX(), brukt på attributtet for datoen for lasting inn i satellitten (MAX(SatLoadDate)). Når det kreves lagring av historien om endringer i attributtet i vitrinene – må man forstå fra hvilken til hvilken dato telefonen var gyldig, den primære nøkkelen i en slik tabell vil være en kompilasjon av forretningsnøkkelen og datoen for lasting inn i satellitten, og det legges også til et felt for sluttdatoen for gyldighetsperioden.

Opprettelsen av en vitrine som lagrer aktuell informasjon om hvert attributt fra flere satellitter som inngår i huben, for eksempel telefonnummer, adresse, navn, innebærer bruk av PIT-tabellen, gjennom hvilken det er enkelt å få tilgang til alle gyldighetsdatoer. Vitriner av denne typen tilhører “Information Marts”.

Begge tilnærmingene er aktuelle både for dimensjoner og fakta.

For å opprette vitringer som lagrer informasjon om flere linker og huber, kan det brukes tilgang til BRIDGE-tabeller.

Med denne artikkelen avslutter jeg syklusen om konseptet DATA VAULT, og jeg håper informasjonen jeg har delt vil være nyttig i implementeringen av deres prosjekter.

Som alltid, til slutt, noen nyttige lenker:

• Artikkel Kenta Grazianos arbeid, som inneholder detaljerte beskrivelser og modeller;

• Bok: “Building a Scalable Data Warehouse with DATA VAULT 2.0”;
• Artikkel “Grunnleggende om Data Vault”;
• Artikkel “Utviklingen av DATA VAULT og overgangen til BUSINESS DATA VAULT”.

Kilde: habr.com