Modellering av datavalv

Enkel modell för datavalv med två hubbar (blått), en länk (grönt) och fyra satelliter (gult)

Datavalv försöker lösa problemet med att hantera förändringar i omgivningen genom att separera affärsnycklarna (som inte förändras lika ofta, eftersom de unikt identifierar en affärsenhet) och associationerna mellan dessa affärsnycklar, från de beskrivande attributen för dessa nycklar.

Företagsnycklarna och deras associationer är strukturella attribut som utgör datamodellens skelett. Datavalvmetoden har som ett av sina viktigaste axiom att verkliga affärsnycklar endast förändras när verksamheten förändras och att de därför är de mest stabila elementen från vilka man kan härleda strukturen i en historisk databas. Om du använder dessa nycklar som grundstomme i ett datalager kan du organisera resten av uppgifterna runt dem. Detta innebär att valet av rätt nycklar för hubbarna är av största vikt för stabiliteten i din modell. Nycklarna lagras i tabeller med några få begränsningar på strukturen. Dessa nyckeltabeller kallas hubs.

HubsEdit

Hubs innehåller en lista över unika affärsnycklar med låg benägenhet att förändras. Hubs innehåller också en surrogatnyckel för varje Hub-objekt och metadata som beskriver affärsnyckelns ursprung. De beskrivande attributen för informationen om hubben (t.ex. beskrivningen för nyckeln, eventuellt på flera språk) lagras i strukturer som kallas satellittabeller, vilka kommer att diskuteras nedan.

Hubben innehåller minst följande fält:

• en surrogatnyckel, som används för att koppla de andra strukturerna till den här tabellen.
• en affärsnyckel, drivkraften för den här hubben. Affärsnyckeln kan bestå av flera fält.
• Rekordkällan, som kan användas för att se vilket system som laddade varje affärsnyckel först.
• Optionellt kan du också ha metadatafält med information om manuella uppdateringar (användare/tid) och uttagningsdatum.

En hubb får inte innehålla flera affärsnycklar, utom när två system levererar samma affärsnyckel men med kollisioner som har olika betydelser.

Hubbar ska normalt ha minst en satellit.

Hubb-exempelRedigera

Detta är ett exempel på en hubb-tabell som innehåller bilar, kallad ”Car” (H_CAR). Den drivande nyckeln är fordonets identifikationsnummer.

LinksEdit

Associationer eller transaktioner mellan affärsnycklar (som t.ex. kopplar samman hubbarna för kund och produkt med varandra genom inköpstransaktionen) modelleras med hjälp av länktabeller. Dessa tabeller är i princip många-till-många-hop-tabeller med vissa metadata.

Länkar kan länka till andra länkar för att hantera förändringar i granularitet (t.ex. genom att lägga till en ny nyckel i en databastabell kan man ändra kornstorleken i databastabellen). Om du till exempel har en koppling mellan kund och adress kan du lägga till en hänvisning till en länk mellan hubbarna för produkt och transportföretag. Detta skulle kunna vara en länk som heter ”Leverans”. Att referera en länk i en annan länk anses vara ett dåligt tillvägagångssätt, eftersom det introducerar beroenden mellan länkar som försvårar parallellinläsning. Eftersom en länk till en annan länk är detsamma som en ny länk med hubbarna från den andra länken är det i dessa fall att skapa länkarna utan att referera till andra länkar den bästa lösningen (se avsnittet om lastningspraxis för mer information).

Länkar länkar ibland hubbar till information som i sig själv inte räcker för att konstruera en hubb. Detta inträffar när en av de affärsnycklar som kopplas samman med länken inte är en riktig affärsnyckel. Som exempel kan man ta ett beställningsformulär med ”ordernummer” som nyckel, och beställningsrader som har ett halvt slumpmässigt nummer som nyckel för att göra dem unika. Låt oss säga ”unikt nummer”. Den sistnämnda nyckeln är inte en riktig affärsnyckel, så den är ingen hubb. Vi måste dock använda den för att garantera rätt granularitet för länken. I det här fallet använder vi inte en hubb med surrogatnyckel, utan lägger till själva företagsnyckeln ”unikt nummer” i länken. Detta görs endast när det inte finns någon möjlighet att någonsin använda företagsnyckeln för en annan länk eller som nyckel för attribut i en satellit. Denna konstruktion har kallats ”peg-legged link” av Dan Linstedt på hans (numera nedlagda) forum.

Länkar innehåller surrogatnycklar för de hubbar som är länkade, en egen surrogatnyckel för länken och metadata som beskriver associationens ursprung. De beskrivande attributen för informationen om associationen (t.ex. tid, pris eller belopp) lagras i strukturer som kallas satellittabeller och som diskuteras nedan.

LänkexempelRedigera

Detta är ett exempel på en länktabell mellan två hubbar för bilar (H_CAR) och personer (H_PERSON). Länken heter ”Driver” (L_DRIVER).

SatellitesEdit

Hubbarna och länkarna utgör modellens struktur, men har inga tidsmässiga attribut och innehar inga beskrivande attribut. De lagras i separata tabeller som kallas satelliter. Dessa består av metadata som länkar dem till sin överordnade hubb eller länk, metadata som beskriver associationens och attributens ursprung samt en tidslinje med start- och slutdatum för attributet. Medan hubbarna och länkarna utgör modellens struktur, utgör satelliterna modellens ”kött”, kontexten för de affärsprocesser som fångas upp i hubbarna och länkarna. Dessa attribut lagras både med avseende på detaljerna i ärendet och tidslinjen och kan variera från ganska komplexa (alla fält som beskriver en klients fullständiga profil) till ganska enkla (en satellit på en länk med endast en giltighetsindikator och en tidslinje).

Oftast grupperas attributen i satelliter efter källsystem. Beskrivande attribut som storlek, kostnad, hastighet, mängd eller färg kan dock ändras i olika takt, så du kan också dela upp dessa attribut i olika satelliter baserat på deras ändringshastighet.

Alla tabeller innehåller metadata, som minimalt beskriver åtminstone källsystemet och det datum då denna post blev giltig, vilket ger en fullständig historisk bild av uppgifterna när de kommer in i datalagret.

SatellitexempelRedigera

Detta är ett exempel på en satellit på förarlänken mellan hubbarna för bilar och personer, kallad ”Driver insurance” (S_DRIVER_INSURANCE). Denna satellit innehåller attribut som är specifika för försäkringen av förhållandet mellan bilen och den person som kör den, t.ex. en indikator om detta är den primära föraren, namnet på försäkringsbolaget för denna bil och person (kan också vara en separat hubb) och en sammanfattning av antalet olyckor där denna kombination av fordon och förare är inblandad. Dessutom ingår en hänvisning till en uppslags- eller referenstabell kallad R_RISK_CATEGORY som innehåller koderna för den riskkategori som denna relation anses falla inom.

(*) minst ett attribut är obligatoriskt.(**) Sekvensnummer blir obligatoriskt om det behövs för att upprätthålla entydighet för flera giltiga satelliter på samma hubb eller länk.

ReferenstabellerRedigera

Referenstabeller är en normal del av en sund modell för datavalv. De finns där för att förhindra redundant lagring av enkla referensdata som refereras ofta. Mer formellt definierar Dan Linstedt referensdata på följande sätt:

Alla uppgifter som anses nödvändiga för att lösa upp beskrivningar från koder, eller för att översätta nycklar på ett (sic) konsekvent sätt. Många av dessa fält är ”beskrivande” till sin natur och beskriver ett specifikt tillstånd av annan viktigare information. Som sådan lever referensdata i separata tabeller från de råa tabellerna i Data Vault.

Referenstabeller refereras från satelliter, men är aldrig bundna med fysiska främmande nycklar. Det finns ingen föreskriven struktur för referenstabeller: använd det som fungerar bäst i ditt specifika fall, allt från enkla uppslagstabeller till små datavalv eller till och med stjärnor. De kan vara historiska eller inte ha någon historia, men det rekommenderas att du håller dig till de naturliga nycklarna och inte skapar surrogatnycklar i det fallet. Normalt har datavalv många referenstabeller, precis som alla andra datalager.

ReferensexempelRedigera

Detta är ett exempel på en referenstabell med riskkategorier för förare av fordon. Den kan refereras från vilken satellit som helst i datavalvet. För tillfället hänvisar vi till den från satelliten S_DRIVER_INSURANCE. Referenstabellen är R_RISK_CATEGORY.

(*) minst ett attribut är obligatoriskt.