I de foregÄende , lÊrte vi om grundlÊggende DATA VAULT, udvidelsen af DATA VAULT til en mere analyserbar tilstand og oprettelsen af BUSINESS DATA VAULT. Det er tid til at afslutte serien med den tredje artikel.
Som jeg annoncerede i den tidligere , vil denne artikel fokusere pÄ emnet BI, nÊrmere bestemt forberedelse af DATA VAULT som datakilde til BI. Lad os se pÄ, hvordan man opretter faktatabeller og dimensioner, og dermed skabe en stjerneschema.
Da jeg begyndte at studere engelsksprogede materialer om oprettelse af datavarehuse over DATA VAULT, fik jeg indtryk af, at processen var rimelig kompleks. Artiklerne er omfattende, og der henvises til Êndringer i formuleringer, der er opstÄet i Data Vault 2.0-metodologien, og betydningen af disse formuleringer understreges.
Men efter at have dykket ned i oversÊttelsen, blev det klart, at denne proces ikke er sÄ kompliceret. Men mÄske vil du have en anden mening.
SĂ„ lad os komme til sagen.
Dimensionstabeller og faktatabeller i DATA VAULT
Den mest udfordrende information at forstÄ:
- Dimensionstabeller bygges pÄ information fra hubs og deres satellitter;
- Faktatabeller bygges pÄ information fra links og deres satellitter.
Og det er Äbenlyst efter at have lÊst artiklen om . Hubs gemmer unikke nÞgler til forretningsobjekter, deres satellitter lagrer tilstandsattributter til forretningsobjekter knyttet til tid, satellitter knyttet til links, der understÞtter transaktioner, gemmer numeriske egenskaber ved disse transaktioner.
PĂ„ dette punkt afsluttes teorien.
Men alligevel er det for mig vigtigt at bemÊrke et par begreber, som du kan stÞde pÄ i artikler om DATA VAULT-metodologien:
- Raw Data Marts â vitriiner af "rĂ„" data;
- Information Marts â informationsvitriiner.
Begrebet "Raw Data Marts" refererer til vitriiner bygget over DATA VAULT-data ved at udfÞre ret enkle JOINs. Tilgangen til "Raw Data Marts" muliggÞr en fleksibel og hurtig udvidelse af projektlageret med information, der er velegnet til analyse. Denne tilgang indebÊrer ikke komplekse datatransformationer eller implementering af forretningsregler fÞr data placeres i vitriinen, men "Raw Data Marts" skal vÊre forstÄelige for forretningsbrugeren og tjene som grundlag for videre omformulering, for eksempel ved brug af BI-vÊrktÞjer.
Begrebet âInformation Martsâ opstod i Data Vault 2.0 metodologien, og det erstattede det gamle begreb âData Martsâ. Denne ĂŠndring skyldes anerkendelsen af opgaven med at implementere datamodellen for rapportering som en transformation af data til information. Schemaet âInformation Martsâ skal fĂžrst og fremmest sikre, at virksomheden fĂ„r beslutningsrelevant information.
De langtgÄende definitioner afspejler to enkle fakta:
- Vitriner af typen âRaw Data Martsâ er bygget pĂ„ det rĂ„ (RAW) DATA VAULT, et lager der kun indeholder grundlĂŠggende begreber: HUBS, LINKS, SATELLITES;
- Vitriner âInformation Martsâ bygger pĂ„ elementerne i BUSINESS VAULT: PIT, BRIDGE.
Hvis vi ser pĂ„ eksemplerne pĂ„ opbevaring af information om medarbejdere, kan vi sige, at en vitrine, der viser det aktuelle (gĂŠldende i dag) telefonnummer for medarbejderen â er en vitrine af typen âRaw Data Martsâ. For at danne en sĂ„dan vitrine bruges medarbejderens forretningsnĂžgle og funktionen MAX(), der anvendes pĂ„ attributten for indlĂŠsningsdatoen i satellitten (MAX(SatLoadDate)). NĂ„r det er nĂždvendigt at opbevare historikken for ĂŠndringer af attributten i vitringen â er det vigtigt at forstĂ„, fra hvilken dato til hvilken dato telefonen var aktuel; den primĂŠre nĂžgle i en sĂ„dan tabel vil vĂŠre en kompilation af forretningsnĂžglen og indlĂŠsningsdatoen i satellitten, og der tilfĂžjes ogsĂ„ et felt for slutdatoen for relevansperioden.
Oprettelse af en vitrine, der opbevarer den aktuelle information om hver attribut fra flere satellitter i hubben, sĂ„som telefonnummer, adresse, fulde navn, indebĂŠrer brug af PIT-tabellen, hvori det er let at fĂ„ alle aktualitetsdatoer. Vitriner af denne type betragtes som âInformation Martsâ.
Begge tilgange er relevante bÄde for dimensioner og fakta.
For at oprette vitriner, der opbevarer information om flere links og hubs, kan brugen af BRIDGE-tabeller vĂŠre nĂždvendig.
Med denne artikel afslutter jeg min serie om DATA VAULT-konceptet, og jeg hÄber, at den information, jeg har delt, vil vÊre nyttig i implementeringen af dine projekter.
Som altid, til slut, et par nyttige links:
- af Kenta Graziano, som udover en detaljeret beskrivelse indeholder modelleringsskemaer;
- Bog: âBuilding a Scalable Data Warehouse with DATA VAULT 2.0â;
- ;
- .
Kilde: habr.com
