Data vault probeert het probleem van het omgaan met verandering in de omgeving op te lossen door de bedrijfssleutels (die niet zo vaak muteren, omdat zij een bedrijfseenheid op unieke wijze identificeren) en de associaties tussen deze bedrijfssleutels, te scheiden van de beschrijvende attributen van deze sleutels.
De bedrijfssleutels en hun associaties zijn structurele attributen, die het geraamte van het gegevensmodel vormen. De data vault methode heeft als een van haar belangrijkste axioma’s dat echte bedrijfssleutels alleen veranderen wanneer de business verandert en daarom de meest stabiele elementen zijn om de structuur van een historische database uit af te leiden. Als u deze sleutels gebruikt als de ruggengraat van een data warehouse, kunt u de rest van de gegevens daaromheen organiseren. Dit betekent dat de keuze van de juiste sleutels voor de hubs van het grootste belang is voor de stabiliteit van uw model. De sleutels worden opgeslagen in tabellen met een paar constraints op de structuur. Deze sleuteltabellen worden hubs genoemd.
HubsEdit
Hubs bevatten een lijst van unieke bedrijfssleutels die weinig geneigd zijn te veranderen. Hubs bevatten ook een surrogaatsleutel voor elk hub-item en metagegevens die de oorsprong van de bedrijfssleutel beschrijven. De beschrijvende attributen voor de informatie op de Hub (zoals de beschrijving voor de sleutel, mogelijk in meerdere talen) worden opgeslagen in structuren die Satellite-tabellen worden genoemd en die hieronder zullen worden besproken.
De Hub bevat ten minste de volgende velden:
- een surrogaatsleutel, gebruikt om de andere structuren met deze tabel te verbinden.
- een bedrijfssleutel, de drijfveer voor deze hub. De business key kan uit meerdere velden bestaan.
- de record source, die kan worden gebruikt om te zien welk systeem elke business key het eerst heeft geladen.
- optioneel kunt u ook metadata velden hebben met informatie over handmatige updates (gebruiker/tijd) en de extractiedatum.
Een hub mag niet meerdere bedrijfssleutels bevatten, behalve wanneer twee systemen dezelfde bedrijfssleutel leveren, maar met botsingen die verschillende betekenissen hebben.
Hubs moeten normaal gesproken ten minste één satelliet hebben.
Hub-voorbeeldEdit
Dit is een voorbeeld voor een hub-tabel met auto’s, genaamd “Auto” (H_CAR). De belangrijkste sleutel is het identificatienummer van het voertuig.
| Voornaam | Beschrijving | Verplicht? | Commentaar |
|---|---|---|---|
| H_CAR_ID | Sequence ID en surrogaatcode voor de hub | Nee | Aanbevolen maar optioneel |
| VEHICLE_ID_NR | De bedrijfssleutel die deze hub aanstuurt. Kan meer dan één veld zijn voor een samengestelde bedrijfssleutel | Ja | |
| H_RSRC | De recordbron van deze sleutel wanneer deze voor het eerst wordt geladen | Ja | |
| LOAD_AUDIT_ID | Een ID in een tabel met auditinformatie, zoals laadtijd, duur van de lading, aantal regels, enzovoort. | Nee |
LinksEdit
Associaties of transacties tussen bedrijfssleutels (die bijvoorbeeld de hubs voor klant en product met elkaar in verband brengen via de aankooptransactie) worden gemodelleerd met behulp van koppelingstabellen. Deze tabellen zijn in feite many-to-many join tabellen, met een aantal metadata.
Links kunnen linken naar andere links, om te gaan met veranderingen in granulariteit (bijvoorbeeld, het toevoegen van een nieuwe sleutel aan een database tabel zou de korrel van de database tabel te veranderen). Bijvoorbeeld, als u een associatie tussen klant en adres hebt, zou u een verwijzing naar een link tussen de hubs voor product en transportbedrijf kunnen toevoegen. Dit zou een link kunnen zijn met de naam “Levering”. Verwijzen naar een link in een andere link wordt beschouwd als een slechte praktijk, omdat het afhankelijkheden introduceert tussen links die parallel laden bemoeilijken. Aangezien een link naar een andere link hetzelfde is als een nieuwe link met de hubs van de andere link, verdient het in deze gevallen de voorkeur de links te creëren zonder naar andere links te verwijzen (zie het gedeelte over laadpraktijken voor meer informatie).
Links linken soms hubs naar informatie die op zichzelf niet voldoende is om een hub te construeren. Dit gebeurt wanneer een van de bedrijfssleutels die door de link worden geassocieerd, geen echte bedrijfssleutel is. Neem als voorbeeld een bestelbon met “bestelnummer” als sleutel, en bestelregels die zijn gecodeerd met een semi-willekeurig nummer om ze uniek te maken. Laten we zeggen, “uniek nummer”. Deze laatste sleutel is geen echte bedrijfssleutel, dus het is geen hub. We moeten hem echter wel gebruiken om de juiste granulariteit voor de link te garanderen. In dit geval gebruiken we geen hub met surrogaat sleutel, maar voegen we de bedrijfssleutel “uniek nummer” zelf toe aan de link. Dit wordt alleen gedaan wanneer er geen mogelijkheid is om de bedrijfssleutel ooit voor een andere koppeling te gebruiken of als sleutel voor attributen in een satelliet. Deze constructie is door Dan Linstedt op zijn (inmiddels ter ziele gegane) forum een “peg-legged link” genoemd.
Links bevatten de surrogaat sleutels voor de hubs die zijn gelinkt, hun eigen surrogaat sleutel voor de link en metadata die de oorsprong van de associatie beschrijven. De beschrijvende attributen voor de informatie over de associatie (zoals de tijd, de prijs of het bedrag) worden opgeslagen in structuren die satelliettabellen worden genoemd en die hieronder worden besproken.
Link-voorbeeldEdit
Dit is een voorbeeld voor een link-tabel tussen twee hubs voor auto’s (H_CAR) en personen (H_PERSON). De link heet “Driver” (L_DRIVER).
| Fieldname | Description | Mandatory? | Commentaar |
|---|---|---|---|
| L_DRIVER_ID | Sequence ID en surrogaatcode voor de link | Nee | Aanbevolen maar optioneel |
| H_CAR_ID | surrogaatcode voor de autokoppeling, het eerste anker van de link | Ja | |
| H_PERSON_ID | surrogaatsleutel voor de persoonsnaaf, het tweede anker van de link | Ja | |
| L_RSRC | De recordsource van deze associatie bij de eerste keer laden | Ja | |
| LOAD_AUDIT_ID | Een ID in een tabel met auditinformatie, zoals laadtijd, duur van de lading, aantal regels, enz. | Nee |
SatellitesEdit
De hubs en links vormen de structuur van het model, maar hebben geen temporele attributen en bevatten geen beschrijvende attributen. Deze zijn opgeslagen in afzonderlijke tabellen, satellieten genaamd. Deze bestaan uit metadata die hen verbinden met hun bovenliggende hub of link, metadata die de oorsprong van de associatie en de attributen beschrijven, alsmede een tijdlijn met begin- en einddata voor het attribuut. Waar de hubs en links de structuur van het model vormen, vormen de satellieten het “vlees” van het model, de context voor de bedrijfsprocessen die in de hubs en links zijn vervat. Deze attributen worden zowel met betrekking tot de details van de zaak als tot de tijdlijn opgeslagen en kunnen variëren van vrij complex (alle velden die een volledig profiel van een cliënt beschrijven) tot vrij eenvoudig (een satelliet op een link met alleen een geldigheidsindicator en een tijdlijn).
In de regel worden de attributen in satellieten gegroepeerd per bronsysteem. Beschrijvende attributen zoals grootte, kosten, snelheid, hoeveelheid of kleur kunnen echter met verschillende snelheden veranderen, zodat u deze attributen ook kunt opsplitsen in verschillende satellieten op basis van de snelheid waarmee ze veranderen.
Alle tabellen bevatten metadata, die minimaal het bronsysteem beschrijven en de datum waarop deze invoer geldig werd, zodat een volledig historisch beeld ontstaat van de gegevens zoals die het data warehouse binnenkomen.
SatellietvoorbeeldEdit
Dit is een voorbeeld voor een satelliet op de bestuurderslink tussen de hubs voor auto’s en personen, genaamd “Bestuurdersverzekering” (S_DRIVER_INSURANCE). Deze satelliet bevat attributen die specifiek zijn voor de verzekering van de relatie tussen de auto en de persoon die de auto bestuurt, bijvoorbeeld een indicator of dit de primaire bestuurder is, de naam van de verzekeringsmaatschappij voor deze auto en persoon (kan ook een aparte hub zijn) en een overzicht van het aantal ongevallen waarbij deze combinatie van voertuig en bestuurder betrokken is. Ook is een verwijzing opgenomen naar een opzoek- of verwijzingstabel met de naam R_RISK_CATEGORY, die de codes bevat voor de risicocategorie waarin deze relatie geacht wordt te vallen.
| Voornaam | Beschrijving | Verplicht? | Commentaar |
|---|---|---|---|
| S_DRIVER_INSURANCE_ID | Sequence ID en surrogaat sleutel voor de satelliet op de link | Nee | Aanbevolen maar optioneel |
| L_DRIVER_ID | (surrogaat) primaire sleutel voor de chauffeurslink, de ouder van de satelliet | Ja | |
| S_SEQ_NR | Orderings- of volgnummer, om uniciteit af te dwingen als er meerdere geldige satellieten voor één oudersleutel zijn | Nee(**) | Dit kan bijvoorbeeld gebeuren als u een hub COURSE hebt en de naam van de cursus een attribuut is, maar in meerdere verschillende talen. |
| S_LDTS | Load Date (begindatum) voor de geldigheid van deze combinatie van attribuutwaarden voor de parent key L_DRIVER_ID | Ja | |
| S_LEDTS | Load End Date (einddatum) voor de geldigheid van deze combinatie van attribuutwaarden voor de bovenliggende sleutel L_DRIVER_ID | Nee | |
| IND_PRIMARY_DRIVER | Indicator of de bestuurder de primaire bestuurder is voor deze auto | Nee (*) | |
| INSURANCE_COMPANY | De naam van de verzekeringsmaatschappij voor dit voertuig en deze bestuurder | Nee (*) | |
| NR_OF_ACCIDENTS | Het aantal ongevallen van deze bestuurder in dit voertuig | Nee (*) | |
| R_RISK_CATEGORY_CD | De risicocategorie voor de bestuurder. Dit is een verwijzing naar R_RISK_CATEGORY | Nee (*) | |
| S_RSRC | De recordbron van de informatie in deze satelliet bij de eerste keer laden | Ja | |
| LOAD_AUDIT_ID | Een ID in een tabel met auditinformatie, zoals laadtijd, duur van de lading, aantal regels, enz. | Nee |
(*) ten minste één attribuut is verplicht.(**) volgnummer wordt verplicht als het nodig is om uniciteit af te dwingen voor meerdere geldige satellieten op dezelfde hub of link.
ReferentietabellenEdit
Referentietabellen zijn een normaal onderdeel van een gezond data vault-model. Ze zijn er om redundante opslag van eenvoudige referentiegegevens waarnaar veel verwezen wordt te voorkomen. Meer formeel definieert Dan Linstedt referentiegegevens als volgt:
Alle informatie die nodig wordt geacht om beschrijvingen uit codes op te lossen, of om sleutels op (sic) een consistente manier te vertalen. Veel van deze velden zijn “beschrijvend” van aard en beschrijven een specifieke toestand van de andere, belangrijkere informatie. Als dusdanig staan referentiegegevens in aparte tabellen ten opzichte van de ruwe Data Vault-tabellen.
Referentietabellen worden vanuit satellieten geraadpleegd, maar zijn nooit gebonden aan fysieke foreign keys. Er is geen voorgeschreven structuur voor referentietabellen: gebruik wat in uw specifieke geval het beste werkt, gaande van eenvoudige opzoektabellen tot kleine gegevenskluizen of zelfs sterren. Ze kunnen historisch zijn of geen geschiedenis hebben, maar het is aan te bevelen om het bij de natuurlijke sleutels te houden en in dat geval geen surrogaatsleutels te maken. Normaal gesproken hebben data vaults veel referentietabellen, net als elk ander Data Warehouse.
ReferentievoorbeeldEdit
Dit is een voorbeeld van een referentietabel met risicocategorieën voor bestuurders van voertuigen. Er kan vanuit elke satelliet in de data vault naar worden verwezen. Voor nu verwijzen we er naar vanuit satelliet S_DRIVER_INSURANCE. De referentietabel is R_RISK_CATEGORY.
| Fieldname | Description | Mandatory? |
|---|---|---|
| R_RISK_CATEGORY_CD | De code voor de risicocategorie | Ja |
| RISK_CATEGORY_DESC | Een beschrijving van de risicocategorie | Nee (*) |
(*) ten minste één attribuut is verplicht.