Datavalv forsøger at løse problemet med at håndtere ændringer i miljøet ved at adskille forretningsnøglerne (som ikke muterer så ofte, fordi de entydigt identificerer en forretningsenhed) og forbindelserne mellem disse forretningsnøgler, fra de beskrivende attributter for disse nøgler.
Der er tale om strukturelle attributter, som udgør datamodellens skelet. Datavoldmetoden har som et af sine vigtigste aksiomer, at reelle forretningsnøgler kun ændres, når forretningen ændrer sig, og at de derfor er de mest stabile elementer, hvorfra man kan udlede strukturen i en historisk database. Hvis man bruger disse nøgler som rygraden i et datawarehouse, kan man organisere resten af dataene omkring dem. Det betyder, at valget af de rigtige nøgler til knudepunkterne er af største betydning for stabiliteten af din model. Nøglerne gemmes i tabeller med nogle få begrænsninger på strukturen. Disse nøgletabeller kaldes hubs.
HubsRediger
Hubs indeholder en liste over unikke forretningsnøgler med lav tilbøjelighed til at ændre sig. Hubs indeholder også en surrogatnøgle for hvert Hub-element og metadata, der beskriver forretningsnøglens oprindelse. De beskrivende attributter for oplysningerne om Hub’en (f.eks. beskrivelsen for nøglen, eventuelt på flere sprog) gemmes i strukturer kaldet Satellittabeller, som vil blive behandlet nedenfor.
Hub’en indeholder mindst følgende felter:
- en surrogatnøgle, der bruges til at forbinde de andre strukturer til denne tabel.
- en forretningsnøgle, driveren for denne hub. Forretningsnøglen kan bestå af flere felter.
- den postkilde, som kan bruges til at se, hvilket system der først indlæste hver enkelt forretningsnøgle.
- Optionelt kan du også have metadatafelter med oplysninger om manuelle opdateringer (bruger/tid) og udtrækningsdato.
En hub må ikke indeholde flere forretningsnøgler, undtagen når to systemer leverer den samme forretningsnøgle, men med kollisioner, der har forskellige betydninger.
Hubs bør normalt have mindst én satellit.
Hub-eksempelRediger
Dette er et eksempel på en hub-tabelle, der indeholder biler, kaldet “Bil” (H_CAR). Kørselsnøglen er køretøjets identifikationsnummer.
| Feltnavn | Beskrivelse | Obligatorisk? | Kommentar |
|---|---|---|---|
| H_CAR_ID | Sekvens-id og surrogatnøgle for hubben | Nej | Anbefales, men er valgfri |
| VEHICLE_ID_NR | Den forretningsnøgle, der styrer denne hub. Kan være mere end ét felt for en sammensat forretningsnøgle | Ja | |
| H_RSRC | Postkilden for denne nøgle ved første indlæsning | Ja | |
| LOAD_AUDIT_ID | Et ID i en tabel med revisionsoplysninger, f.eks. indlæsningstidspunkt, indlæsningsvarighed, antal linjer osv. | Nej |
LinksEdit
Associationer eller transaktioner mellem forretningsnøgler (der f.eks. forbinder knudepunkterne for kunde og produkt med hinanden gennem købstransaktionen) modelleres ved hjælp af linktabeller. Disse tabeller er dybest set mange-til-mange-joint tabeller med nogle metadata.
Links kan linke til andre links for at håndtere ændringer i granularitet (f.eks. vil tilføjelse af en ny nøgle til en databasetabel ændre databasetabellens korn). Hvis du f.eks. har en association mellem kunde og adresse, kan du tilføje en henvisning til et link mellem knudepunkterne for produkt og transportfirma. Dette kunne være et link kaldet “Levering”. At henvise til et link i et andet link anses for at være en dårlig praksis, fordi det indfører afhængigheder mellem links, som gør parallelindlæsning vanskeligere. Da et link til et andet link er det samme som et nyt link med hubs fra det andet link, er det i disse tilfælde at foretrække at oprette links uden at henvise til andre links (se afsnittet om indlæsningspraksis for yderligere oplysninger).
Links linker nogle gange hubs til oplysninger, som ikke i sig selv er nok til at konstruere et hub. Dette sker, når en af de forretningsnøgler, der er tilknyttet af linket, ikke er en rigtig forretningsnøgle. Som eksempel kan man tage en bestillingsformular med “ordrenummer” som nøgle og bestillingslinjer, der er forsynet med et semi-randomnummer for at gøre dem unikke. Lad os sige, “unikt nummer”. Sidstnævnte nøgle er ikke en rigtig forretningsnøgle, så den er ikke en hub. Vi er dog nødt til at bruge den for at garantere den korrekte granularitet for linket. I dette tilfælde bruger vi ikke en hub med surrogatnøgle, men tilføjer selve forretningsnøglen “unikt nummer” til linket. Dette gøres kun, når der ikke er nogen mulighed for at bruge forretningsnøglen til et andet link eller som nøgle for attributter i en satellit. Denne konstruktion er blevet kaldt en “peg-legged link” af Dan Linstedt på hans (nu nedlagte) forum.
Links indeholder surrogatnøglerne for de hubs, der er forbundet, deres egen surrogatnøgle for linket og metadata, der beskriver oprindelsen af forbindelsen. De beskrivende attributter for oplysningerne om forbindelsen (f.eks. tid, pris eller beløb) gemmes i strukturer kaldet satellittabeller, som behandles nedenfor.
Link eksempelRediger
Dette er et eksempel på en linktabel mellem to hubs for biler (H_CAR) og personer (H_PERSON). Linket hedder “Chauffør” (L_DRIVER).
| Feltnavn | Beskrivelse | Obligatorisk? | Kommentar | |
|---|---|---|---|---|
| L_DRIVER_ID | Sekvens-ID og surrogatnøgle for Link | Nej | Anbefales, men er valgfri | |
| H_CAR_ID | Surrogatnøgle for bilnavnet, det første anker i linket | Ja | ||
| H_PERSON_ID | Surrogatnøgle for personnavnet, det andet anker i linket | Ja | ||
| L_RSRC | Rekordkilden for denne tilknytning, når den indlæses første gang | Ja | ||
| LOAD_AUDIT_ID | Et ID til en tabel med revisionsoplysninger, såsom indlæsningstidspunkt, varighed af indlæsning, antal linjer osv. | Nej |
SatellitesEdit
Hubs og links udgør modellens struktur, men har ingen tidsmæssige attributter og indeholder ingen beskrivende attributter. De er gemt i separate tabeller kaldet satellitter. Disse består af metadata, der knytter dem til deres overordnede hub eller link, metadata, der beskriver oprindelsen af forbindelsen og attributterne, samt en tidslinje med start- og slutdatoer for attributten. Hvor hubs og links udgør modellens struktur, udgør satellitterne modellens “kød”, dvs. konteksten for de forretningsprocesser, der er registreret i hubs og links. Disse attributter lagres både med hensyn til detaljerne i sagen og tidslinjen og kan spænde fra ganske komplekse (alle felter, der beskriver en klients komplette profil) til ganske enkle (en satellit på et link med kun en valid-indikator og en tidslinje).
Hvis attributterne er normalt grupperet i satellitter efter kildesystem. Men beskrivende attributter som f.eks. størrelse, omkostninger, hastighed, mængde eller farve kan ændre sig med forskellige hastigheder, så du kan også opdele disse attributter i forskellige satellitter baseret på deres ændringshastighed.
Alle tabellerne indeholder metadata, der som minimum beskriver mindst kildesystemet og den dato, hvor denne post blev gyldig, hvilket giver et komplet historisk overblik over dataene, når de kommer ind i datawarehouset.
Eksempel på satellitRediger
Dette er et eksempel på en satellit på driver-forbindelsen mellem knudepunkterne for biler og personer, kaldet “Driver insurance” (S_DRIVER_INSURANCE). Denne satellit indeholder attributter, der er specifikke for forsikringen af forholdet mellem bilen og den person, der kører den, f.eks. en indikator for, om denne er den primære fører, navnet på forsikringsselskabet for denne bil og person (kan også være en separat hub) og en oversigt over antallet af ulykker, der involverer denne kombination af køretøj og fører. Der er også en henvisning til en opslags- eller referencetabel kaldet R_RISK_CATEGORY, der indeholder koderne for den risikokategori, som denne relation anses for at falde ind under.
| Feltnavn | Beskrivelse | Obligatorisk? | Kommentar |
|---|---|---|---|
| S_DRIVER_INSURANCE_ID | Følge-ID og surrogatnøgle for satellitten på forbindelsen | Nej | Anbefales, men er valgfri |
| L_DRIVER_ID | (surrogat) primærnøgle for chaufførforbindelsen, satellitens overordnede | Ja | |
| S_SEQ_NR | Rækkefølge- eller sekvensnummer, for at håndhæve entydighed, hvis der er flere gyldige satellitter for en overordnet nøgle | Nej(**) | Det kan f.eks. ske, hvis du har en hub COURSE, og kursets navn er en attribut, men på flere forskellige sprog. |
| S_LDTS | Ladedato (startdato) for gyldigheden af denne kombination af attributværdier for overordnet nøgle L_DRIVER_ID | Ja | |
| S_LEDTS | Lad slutdato (enddate) for gyldigheden af denne kombination af attributværdier for overordnet nøgle L_DRIVER_ID | Nej | |
| IND_PRIMARY_DRIVER | Indikator for, om den føreren er den primære fører for denne bil | Nej (*) | |
| INSURANCE_COMPANY | Navnet på forsikringsselskabet for dette køretøj og denne fører | Nej (*) | |
| NR_OF_ACCIDENTS | Antal ulykker for denne fører i dette køretøj | Nej (*) | |
| R_R_RISK_CATEGORY_CD | Risikokategori for føreren. Dette er en henvisning til R_RISK_CATEGORY | Nej (*) | |
| S_RSRC | Rekordkilden for oplysningerne i denne satellit ved første indlæsning | Ja | |
| LOAD_AUDIT_ID | Et ID til en tabel med revisionsoplysninger, såsom indlæsningstidspunkt, varighed af indlæsning, antal linjer osv. | Nej |
(*) mindst én attribut er obligatorisk.(**) Sekvensnummeret bliver obligatorisk, hvis det er nødvendigt for at håndhæve entydighed for flere gyldige satellitter på samme hub eller link.
ReferencetabellerRediger
Referencetabeller er en normal del af en sund datavalvsmodel. De er der for at forhindre redundant lagring af simple referencedata, som der refereres meget til. Mere formelt definerer Dan Linstedt referencedata således:
Alle oplysninger, der anses for nødvendige for at opløse beskrivelser fra koder eller for at oversætte nøgler på (sic) en konsistent måde. Mange af disse felter er af “beskrivende” art og beskriver en specifik tilstand af de andre vigtigere oplysninger. Som sådan lever referencedata i separate tabeller fra de rå Data Vault-tabeller.
Referencetabeller refereres fra satellitter, men er aldrig bundet med fysiske fremmednøgler. Der er ingen foreskrevet struktur for referencetabeller: Brug det, der fungerer bedst i dit specifikke tilfælde, lige fra simple opslagstabeller til små datavalve eller endda stjerner. De kan være historiske eller ikke have nogen historik, men det anbefales, at du holder dig til de naturlige nøgler og ikke opretter surrogatnøgler i det tilfælde. Normalt har datavælvinger en masse referencetabeller, ligesom ethvert andet Data Warehouse.
ReferenceeksempelRediger
Dette er et eksempel på en referencetabel med risikokategorier for førere af køretøjer. Den kan refereres fra enhver satellit i dataværket. For nu refererer vi den fra satellit S_DRIVER_INSURANCE. Referencetabellen er R_RISK_CATEGORY.
| Feltnavn | Beskrivelse | Obligatorisk? |
|---|---|---|
| R_R_RISK_CATEGORY_CD | Koden for risikokategorien | Ja |
| RISK_CATEGORY_DESC | En beskrivelse af risikokategorien | Nej (*) |
(*) Mindst én attribut er obligatorisk.