Infotalk

Att stegvis konvertera ett datalager i 3NF till data vault

07 oktober Linus Hjorth

 

Introduktion - 3NF till DV?

Data vault identifieras alltmer som den bästa datamodelleringstekniken för datalager. Några av orsakerna till detta är:

- Flexibilitet: utöka ditt datalager utan att behöva gör kostsamma ombyggnationer

- Skalbarhet: data vault gifter sig väl med MPP/Big Data-teknologier

- Fungerar med databas-integritet: risken är stor att din 3NF-modell historisering inte går att implementera fysiskt. Det kan man med en data vault-modell.

Och så vidare. Om du vill läsa mer om data vaults fördelar föreslår jag att du söker vidare med länkarna längst ned i texten.

Datalager har funnits under många år nu, och de flesta är nog modellerade enligt tredje normalformen (3NF). Ni som vet lite om data vault känner till dess flexibilitet. Men är det så pass flexibelt att det går att gradvis förändra ett befintligt datalager, och under en tid ha en hybridmodell?
Nedan följer en fallstudie om ett sådant projekt.

Fallstudien

Denna studie beskriver hur en bank med ett befintligt 3NF datalager har börjat konverterat detta till data vault. Orsaken till att banken valde att göra konverteringen var att ett antal jobb där data från olika källor samsades var svåra att underhålla, och skapade problem vid omladdningar etc. En annan orsak var att man ville bygga ut datamodellen, och fann att data vault var en bättre lösning i denna situation. Datalagrets detaljnivå (Detail Data Store – DDS) består av cirka 30 tabeller. Data mart-nivån har ungefär 10 faktatabeller och 20 dimensioner (varav flera delas mellan olika stjärnor).

Data är fokuserat på interna strukturer och processer, och inte så mycket om specifika kunder (vissa processer är dock kopplade till olika kundsegment). Det man mäter mest är produktivitet, effektivitet, kostnader och arbetet med kundutveckling

De huvudsakliga subjekten (affärskoncepten) är anställd, intern organisation, kostnadsställe och kommunikationskanal. Och kopplat till detta ett antal mått såsom genomströmning i respektive kanal, antal heltidsanställda och bokad försäljning.

Befintlig datamodell

Innan jag beskriver de förändringar som är gjorda, behöver vi gå igenom den befintliga miljön i lite med detalj.

I det befintliga datalagret hare man använt surrogatnycklar skapade med sekvensnummer. Hanteringen av dessa har skett i separata surrogatnyckel-tabeller. Dessa har inte ingått i datamodellen, men som ni hör liknar dessa hubbar. En egenhet var att kombinationen surrogatnyckel och affärsnyckel har giltighetsintervall (Valid_from/to_Dt). Det fanns två orsaker till detta:

1. Om man såg att två eller fler affärsnycklar egentligen beskrev samma entitet, så kunde vi koppla dem till samma surrogatnyckel. Ett exempel skulle vara om en anställd slutar, och sedan återkommer, men får nytt anställningsnummer.

2. Om en affärsnyckel återanvänds, så skall den nya betydelsen (entiteten) kopplas till en ny surrogatnyckel.

Även om dessa situationer säkerligen har uppkommit under systemets levnad, så är det inget som har påverkat statistiken i någon markant utsträckning, om man har inte prioriterat att skapa rutiner kring detta.

Fig 1. Utdrag från den existerande datamodellen. Employee och Internal_Org är huvudsubjekten. Även om vi har separata surrogatnyckeltabeller, så uttrycker modellen att vi måste ha minst en rad I Employee för alla Employee_RK (t.ex. i Employement). Notera även att modelleringsverktyget kräver att hela PK sprids som FK (vilket ju är korrekt enligt de flesta databaser). Så Valid_from_Dt i barn-tabellerna markeras som FK, vilket de inte är I realiteten. Giltighetsintervallen hanteras lokalt I barn-tabellen.

Fig 1. Utdrag från den existerande datamodellen. Employee och Internal_Org är huvudsubjekten. Även om vi har separata surrogatnyckel-tabeller, så uttrycker modellen att vi måste ha minst en rad i Employee för alla Employee_RK (t.ex. i Employement). Notera även att modelleringsverktyget kräver att hela PK sprids som FK (vilket ju är korrekt enligt de flesta databaser). Så Valid_from_Dt i barn-tabellerna markeras som FK, vilket de inte är i realiteten. Giltighetsintervallen hanteras lokalt i barn-tabellen.

I princip alla tabeller I DDS har versionshantering (giltighetsintervall), med Valid from/to Date-kolumner. Varje rad har en tidsstämpel som markerar när raden senast uppdaterats, vilket i realiteten är antingen när raden skapas, eller när ett giltighetsintervall stängs. Hierarkier beskrivs via associations-objekt (Internal_Org_Assoc), som innehåller föräldra-barn-kombinationer. Andra relationer är implementerade som associationer (Employee_X_Internal_Org), eller som FK (Agent.Employee_RK).

Som andra datalager i 3NF så är modellen strikt sett inte sann. Som relationer (1-M t.ex.), hur beskrivs versionshantering i relationen? Säger 1-M att en Employee kan ha många Agent_RK, eller att versionshanteringen i Agent gör att det automatiskt blir M? Och som nämnts tidigare så är FK i sig inte sann, i praktiken migreras inte Valid_from_Dt, även om den ingår i föräldratabellens PK. För att läsa mer om just dessa problem, läs min artikel här.

Modellförändringar

Hubbar
Som nämnts ovan, hade vi surrogatnycklar i separata tabeller, på ett separata schema [surrogate]. Det första enkla och kosmetiska förändringen var att döpa om schemat till [Hub]. Nästa steg vara att ta bort versionshanteringen, då detta inte ingår i hubb-konceptet. Fall med M-M mellan affärsnyckel och surrogatnyckel över tid kan åtminstone delvis hanteras med same-as-links (SAL). Så vi konverterade giltighetskolumnerna till First_Seen_Dt and Last_Seen_Dt. Åtgärder:

- Lägga till hubbarna i datamodellen

- Skripta tabellförändringarna

- Uppdatera ETL-jobben som uppdaterar hubbarna

- Ta bort alla <timestamp between valid_from_dt and valid_to_dt> urvalskriterier från alla tabelluppslag-operationer som hämtar surrogatnycklar. Vilket förkommer i jobben som laddar länkar och satelliter.

Satelliter
Återigen, vi hade tur. Eftersom surrogatnycklarna sköttes separat, de tabeller som vi nu såg som satelliter krävde inga/små förändringar. I vissa fall la vi till ett suffix _Detail till satellit-tabellens namn, så att de tydligare skiljer sig från hubbarna:

  • [Surrogate].[Employee] -> [Hub].[Employee]
  • [DDS].[Employee] -> [DDS].[Employee_Detail]

En förändring gjordes dock. DDS.Employee laddades från dels en daglig fil, dels en månatlig (med släp minst 3 bankdagar). Tidigare hade vi krångliga rutiner för att sköta giltighetsintervallen beroende på när en anställd dök upp i vilken fil. Nu separerade vi detta så att månads-filen enbart laddar Employment. Eventuella giltighetsregler skjuts därmed upp till laddningen av data mart, vilket är mycket bättre. Det är klart enklare att skriva en fråga som hanterar detta, än att skruva på ett antal ladd-jobb för att få ihop det enhetligt.

Länkar
Som vi nämnde tidigare, så använde en del relationer s.k. associations-objekt. Vi valde att inte bryta giltighetsintervallen i länk-satelliter, då inga attribut fanns. Så inga förändringar krävdes, bara en ny klassificering. Vi hanterade tabeller med kanal-mått (ej i bild) på ett liknande sätt. Vi klassificerade dem helt enkelt för transaktionslänkar.

Hittills har vi inte transformerat någon FK-relation till länk, så vi kan inte dela med oss av erfarenheter kring just detta.

Fig 2. Data vault-modell (utdrag). Hubbar är tillagda I modellen. Det finns fortfarande objekt som ännu är kvar I 3NF, t.ex. Agent, som fortfarande har en FK från Employee. Men i den nya modellen kopplar vi till hubben istället, vilket blir mer korrekt.

Fig 2. Data vault-modell (utdrag). Hubbar är tillagda i modellen. Det finns fortfarande objekt som ännu är kvar I 3NF, t.ex. Agent, som fortfarande har en FK från Employee. Men i den nya modellen kopplar vi till hubben istället, vilket blir mer korrekt.

Då vi inte har ytterligare attribut i relationen, och vi enbart behöver hålla koll på giltighetsperioder, bestämde vi oss för inte använda oss av länksatelliter. Vi kunde inte se framför oss att länkarna utseende skulle behöva ändras över tid, och detta gjort transformeringen enkel.

Nytt affärskoncept
Under denna förändring (och delvis driven av) så införde ett vi ett nytt affärskoncept, kostnadsställe (Cost_Centre). Det var en ganska enkelt att modellera enligt data vault: en hubb, två satelliter (en dagligt uppdaterad, en månatligen).

Sedan kopplade vi detta till Employee. Det speciella är att den är ”tvådimensionell” (just nu). Det är två källor som beskriver hur en anställda är kopplad till ett kostnadsställe, så vi gjort förenklingen att använda Source_System_Cd som del i länkens PK. Kan man göra så? Ja, om du frågar mig. Dels så är detta med att tillföra en extra kod-kolumn I en länks PK något som hittills inte beskrivits av data vault-världen, vilket för mig är konstigt. Jag har kallar denna konstruktion Multi Value Link (likt konceptet Multi Value Satellite). Läs LinkedIn-diskussion på ämnet här (medlemskap i gruppen "Data Vault Discussions" kan krävas).

Fig 3. Kostnadsställe tillagt. Employee_RK och Source_System_Cd är den styrande för versionshanteringen.

Fig 3. Kostnadsställe tillagt. Employee_RK och Source_System_Cd är den styrande för versionshanteringen.

Precis som med Employee_X_Internal_Org, så vi bestämde oss för enbart ah en länk, ingen länk-satellit, då det saknades attribut i övrigt.

Påverkan på data mart
De data som hämtas för data mart har i princip samma struktur som innan transformeringen av detalj-datalagret gjordes. Några mindre ändringar i form av namnbyte på tabeller förekom. Men då vi använder oss av ett metadatadrivet ETL-verktyg (SAS Data Integration Studio) behövde vi inte ändra jobben. Enbart generera om koden baserat på uppdaterat metadata.

Men, för att anpassa ett mart till det nya affärskonceptet kostnadsställe behövde vi förändra två ETL-jobb – men hur skulle man kunna undgå det?

Sammanfattning

Då den logiska modellen används i kommunikationen med affärsanvändare, ville vi inte förvirra dem med de ganska tekniska termerna Hubb, Länk och Satellit. Men vi har märkt upp dem i modellen med de vedertagna färgerna. Och istället för att lägga till tabell-typen i tabellnamnen, har vi lagt till dem i beskrivningen i tabellen metadata, vilket gör att dessa även finns tillgänglig i de fysiska tabellerna utökade attribut (label).

Vår erfarenhet visar på att det är enkelt att göra en gradvis transformering från 3NF till data vault i ett datalager. Vårt jobb förenklades avsevärt av att vi redan hade separata surrogatnyckel-tabeller – men jag tror att de flesta välkonstruerade 3NF-datalager har just sådana. Detta resulterade i att enbart mindre förändringar krävdes i modellen och ETL-jobb som laddade och läste från detalj-datalagret.

Länkar

Hans Hultgrens blogg om data vault: The Hans Blog

Learn Data Vault

Tack

till mina kollegor i Infotreks data vault-team: Saiam Mufti, Siavoush Mohammadi och Jonas Johansson.

Linus Hjorth

Linus Hjorth är Infotreks områdesansvarig för datalager. En specialist inom datalager-arkitektur som blir extra engagerad när affärskrav ska omvandlas till datamodeller.

Finns inga kommentarer för detta inlägg

Lämna en kommentar
  •  

    Send this to a friend