Infotalk

Och så ytterligare en fördel med data vault jämfört med 3NF…

14 oktober Linus Hjorth

I data vaults två biblar (“Supercharge Your Data Warehouse” av Linstedt, och “Modelling the Agile Data Warehouse with Data Vault” av Hultgren) finns det ett antal exempel på fördelar med datamodellering enligt data vault, jämfört med modellering enligt tredje normalformen (3NF). Dessa är bl.a. (inte begränsade till):

  • Lagring av nycklar, relationer och attribut i separata objekt
  • Flexibilitet – tillägg i modellen görs med nya objekt, man ska inte behöva uppdatera befintliga

Utöver dessa vill jag poängtera ytterligare fördel! Och det är ett problem med 3NF som jag ofta stött på och behövt hantera i design på något sätt, och som jag inte sett i referenslitteraturen för data vault. Visserligen är detta nämnt av Linstedt i ”Data Vault Series 1”, men inte senare i hans bok "Supercharge...". Jag har inte heller sett något etablerat begrepp för detta, så jag kallar det i brist på annat för “nyckel-krockar”. Mer exakt handlar det om problem med sammansatta nycklar. Så vad handlar det om, och vad är problemet? Låt oss börja med ett enkelt exempel på modell i 3NF:

3NFSimple

Inga problem här. Någon blir anställd, förmodligen får hen en tjänst. En tjänst kan bara innehas av en anställd (i taget). Tjänsten är kategoriserad med en tjänstekod, kanske från en lista på giltiga koder. Den här konstruktionen fungerar för de flesta affärssystem, där fokus ligger på att den nu giltiga informationen är korrekt. Men hur gör vi om vi vill skapa historik? Detta sker oftast i en separat datalager-miljö. Den vanligaste tekniken är att lägga till datum eller tidsstämplar på varje rad, och att varje förändring genererar en ny rad. Det kan t.ex. se ut så här:

3NFValidDates

Du ser kanske vad som haltar i denna modell. Kolumnen Valid_from_date är en del av nyckeln i bägge tabeller. Den används för att göra nyckeln unik vid historisering. Men Valid_from_date från EMPLOYEE sprids inte som del av FK i POSITION. Många datalager-modeller ser ut så här, bl.a. lösningsmodellerna från SAS Institute. I dessa modeller väljer man att sprida enbart surrogatnyckeln, vilket i sig är klokt, man vill inte hålla på att uppdatera POSITION varje gång något attribut i EMPLOYEE ändras. Och det kan fungera bra. Men då denna konstruktion är oortodox är det viktigt att alla utvecklare och användare av datalagret helt förstår denna konstruktion. Bl.a. måste man alltid (åtminstone på föräldratabellen) använda ett filter på giltighetsdatumet – annars riskerar man dubbletter. Och rent konkret, modellen går inte att implementera fysiskt. De flesta databaser tillåter inte FK som inte sprids i sin helhet.

Så hur gör vi om vi vill hålla referensintegriteten i databasen? Först gör vi kolumnnamnen unika. Det kan vi göra genom att införa en namnkonvention där nyckel-kolumner ska innehålla en förkortning av tabellnamnet.

3NFValidDatesAcronym

Nu är modellen i 3NF, och integritet kan skapas i databasen om vi så önskar.

Men vad betyder relationen med denna konstruktion? Får vi tillgång till mer information genom att lägga till Emp_Valid_from_Date till POSITON? Eller med andra ord, är vi intresserade av att i POSITION veta om något av attributen i EMPLOYEE har förändrats? Är vi intresserad av vilken rad i EMPLOYEE som är giltig samtidigt som raden i POSITION? Dessa frågor leder till att vi behöver fatta ett designbeslut: om ny version skapas i föräldratabellen, ska vi skapa ny version även i barntabellen – eller inte? Båda alternativen är giltiga ur ett strikt modelleringsperspektiv.

  • Behålla referensen till den ursprungliga raden i EMPLOYEE. Då kommer vi kanske ha en giltig rad i POSITION som refererar en gammal rad i EMPLOYEE. Så om vi vill slå samman giltig information från båda tabeller så kan man inte använda den lagrade FK i join-villkoret.
  • Skapa en ny rad i POSITION, p.g.a. en ny FK (alla övriga attribut i POSITION kan vara oförändrade). Detta verkar ologiskt och skapar i högre utsträckning redundant data.

Båda alternativen skaver en smula. Och det blir än mer tydligt i fråga om relationstabeller (skapade för att hantera M-M-relationer).

Summan av kardemumman är att vi inte vill veta hur EMPLOYEE historiseras när vi befinner oss i POSITION, det ska skötas i EMPLOYEE ensamt. Ingen av koncepten ovan fungerar speciellt bra, de är work-arounds, och är inte lämpliga lösningar.

Så hur sköts detta i data vault?

Om du har någon kunskap om data vault så sitter du nog på svaret – att använda hubbar. Hubben är platsen som håller affärsnyckeln (tillsammans med datalagrets surrogatnyckel). Information i hubben versionshanteras inte. All information som relaterar till en anställd måste kopplas via hubben för anställd. Detta löser problemet med att ha sammansatta nycklar som ska spridas som FK, hubben har inga giltighetsdatum.

All historisering sker i satelliter kopplade till hubbar och länkar. Dessa satelliter får inte kopplas ihop direkt med andra tabeller än dess egen hubb eller länk.

Data Vault utan nyckelkroackar

Som synes, relationer innehåller inte giltighetsdatum. Informationen om när en anställd höll en viss position lagras i länkens satellit. Detta leder till en renare modell. Enklare att förstå, ladda, underhålla och ställa frågor mot.

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.

Kommentarer
  • Richard Carlsson
    2 år ago - Svara

    Hej Linus, I de lösningsmodeller från SAS som jag jobbat används cross tables, exempelvis CUSTOMER_X_EMPLOYEE. I ditt exempel skulle man kunna använda en tabell EMPLOYEE_X_POSITION för att se vad en anställd har haft för positioner över tid.

  • Linus Hjorth
    Linus Hjorth
    2 år ago - Svara

    Absolut helt rätt! :-)
    Cross reference tabeller används i modellering för att hantera M-M – relationer. Och det är ju just vad länkar är. Poängen här är att 3NF-modeller har 1-M – relationer, och att historisering inte tas om hand inom traditionell 3NF-modellering. Och här blir data vault en lösning. Men visst kan man ersäta alla 1-M med cross reference tabeller överallt utan att kalla det länkar…

Lämna en kommentar
  •  

    Send this to a friend