Datavalvmodellering

Enkel datavalvmodell med två nav (blå), en länk (grön) och fyra satelliter (gul)

Datavalvmodellering är en databasmodelleringsmetod som är utformad för att tillhandahålla långsiktig historisk lagring av data som kommer in från flera operativa system. Det är också en metod att titta på historisk data som handlar om frågor som revision, spårning av data, laddningshastighet och motståndskraft mot förändring samt betonar behovet av att spåra var all data i databasen kom ifrån. Detta innebär att varje rad i ett datavalv måste åtföljas av postkälla och laddningsdatumattribut, vilket gör det möjligt för en revisor att spåra värden tillbaka till källan. Den utvecklades av Daniel (Dan) Linstedt år 2000.

Datavalvmodellering gör ingen skillnad mellan bra och dålig data ("dålig" vilket betyder att den inte följer affärsreglerna). Detta sammanfattas i uttalandet att ett datavalv lagrar "en enda version av fakta" (även uttryckt av Dan Linstedt som "all data, hela tiden") i motsats till praxis i andra datalagermetoder för att lagra " en enda version av sanningen " där data som inte överensstämmer med definitionerna tas bort eller "rensas".

Modelleringsmetoden är utformad för att vara motståndskraftig mot förändringar i affärsmiljön där data som lagras kommer ifrån, genom att explicit separera strukturell information från beskrivande attribut. Datavault är designat för att möjliggöra parallell laddning så mycket som möjligt, så att mycket stora implementeringar kan skalas ut utan att behöva göra en större omdesign.

Historia och filosofi

Inom datalagermodellering finns det två välkända konkurrerande alternativ för att modellera lagret där data lagras. Antingen modellerar du enligt Ralph Kimball , med anpassade dimensioner och en företagsdatabuss , eller så modellerar du enligt Bill Inmon med databasen normaliserad ^{[ citat behövs ]} . Båda teknikerna har problem när de hanterar förändringar i systemen som matar datalagret [ ^{citat behövs ]} . För anpassade dimensioner måste du också rensa data (för att anpassa dem) och detta är oönskat i ett antal fall eftersom detta oundvikligen kommer att förlora information [ ^{citat behövs ]} . Datavalvet är utformat för att undvika eller minimera effekterna av dessa problem, genom att flytta dem till områden i datalagret som ligger utanför det historiska lagringsområdet (rengöring görs i datamartsen) och genom att separera de strukturella föremålen (företagsnycklar och associationer mellan affärsnycklarna) från de beskrivande attributen.

Dan Linstedt, skaparen av metoden, beskriver den resulterande databasen så här:

"Data Vault-modellen är en detaljorienterad, historisk spårning och unikt länkad uppsättning normaliserade tabeller som stöder ett eller flera funktionella affärsområden. Det är en hybridmetod som omfattar det bästa av rasen mellan 3:e normalform (3NF) och stjärnschema . Designen är flexibel, skalbar, konsekvent och anpassningsbar till företagets behov"

Data vaults filosofi är att all data är relevant data, även om den inte är i linje med etablerade definitioner och affärsregler. Om data inte överensstämmer med dessa definitioner och regler är det ett problem för verksamheten, inte datalagret. Fastställandet av att data är "fel" är en tolkning av data som härrör från en viss synvinkel som kanske inte är giltig för alla, eller vid varje tidpunkt. Därför måste datavalvet fånga all data och endast när data rapporteras eller extraheras från datavalvet tolkas data.

En annan fråga som datavalvet är ett svar på är att det i allt högre grad finns ett behov av fullständig granskningsbarhet och spårbarhet av all data i datalagret. På grund av Sarbanes-Oxleys krav i USA och liknande åtgärder i Europa är detta ett relevant ämne för många implementeringar av business intelligence, därför är fokus för alla implementeringar av datavalv fullständig spårbarhet och granskningsbarhet av all information.

Data Vault 2.0 är den nya specifikationen. Det är en öppen standard . Den nya specifikationen består av tre pelare: metodik (SEI/ CMMI , Six Sigma , SDLC , etc..), arkitekturen (bland annat ett indatalager (datasteg) och ett presentationslager (datamart), samt hantering av datakvalitet tjänster och masterdatatjänster), och modellen. Inom metodiken definieras implementeringen av bästa praxis. Data Vault 2.0 har fokus på att inkludera nya komponenter som big data , NoSQL - och fokuserar även på prestandan hos den befintliga modellen. Den gamla specifikationen (dokumenterad här för det mesta) är mycket fokuserad på datavalvmodellering. Det finns dokumenterat i boken: Building a Scalable Data Warehouse with Data Vault 2.0.

Det är nödvändigt att utveckla specifikationen för att inkludera de nya komponenterna, tillsammans med bästa praxis för att hålla EDW- och BI-systemen aktuella med behoven och önskemålen hos dagens företag.

Historia

Datavalvmodellering skapades ursprungligen av Dan Linstedt på 1990-talet och släpptes 2000 som en allmän egendomsmodelleringsmetod. I en serie om fem artiklar i The Data Administration Newsletter utökas och förklaras grundreglerna för Data Vault-metoden. Dessa innehåller en allmän översikt, en översikt över komponenterna, en diskussion om slutdatum och kopplingar, länktabeller och en artikel om laddningsmetoder.

Ett alternativt (och sällan använt) namn på metoden är "Common Foundational Integration Modeling Architecture."

Data Vault 2.0 har kommit på scenen från och med 2013 och presenterar Big Data, NoSQL, ostrukturerad, semistrukturerad sömlös integration, tillsammans med metodik, arkitektur och bästa praxis för implementering.

Alternativa tolkningar

Enligt Dan Linstedt är datamodellen inspirerad av (eller mönstrad av) en förenklad syn på neuroner, dendriter och synapser – där neuroner är associerade med nav och navsatelliter, länkar är dendriter (informationsvektorer) och andra länkar är synapser (vektorer i motsatt riktning). Genom att använda en datautvinningsuppsättning algoritmer kan länkar bedömas med förtroende och styrka . De kan skapas och släppas i farten i enlighet med lärande om relationer som för närvarande inte existerar. Modellen kan automatiskt modifieras, anpassas och justeras allt eftersom den används och matas med nya strukturer.

En annan uppfattning är att en datavalvmodell tillhandahåller en ontologi för företaget i den meningen att den beskriver termerna i företagets domän (hubbar) och relationerna mellan dem (länkar), och lägger till beskrivande attribut (satelliter) där det behövs.

Ett annat sätt att tänka på en datavalvmodell är som en grafisk modell . Datavalvmodellen ger faktiskt en "grafbaserad" modell med nav och relationer i en relationsdatabasvärld. På detta sätt kan utvecklaren använda SQL för att få fram grafbaserade relationer med svar på undersekund.

Grundläggande föreställningar

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

Affärsnycklarna och deras associationer är strukturella attribut som bildar skelettet i datamodellen. Datavalvmetoden har som ett av sina huvudaxiom att verkliga affärsnycklar bara förändras när verksamheten förändras och är därför de mest stabila elementen att härleda strukturen i en historisk databas ur. Om du använder dessa nycklar som ryggraden i ett datalager kan du organisera resten av data runt dem. Det betyder att valet av rätt nycklar för naven är av yttersta vikt för stabiliteten hos din modell. Nycklarna lagras i tabeller med några begränsningar på strukturen. Dessa nyckeltabeller kallas nav.

Hubs

Hub innehåller en lista med unika affärsnycklar med låg förändringsbenägenhet. Hubs innehåller också en surrogatnyckel för varje Hub-objekt och metadata som beskriver ursprunget för affärsnyckeln . De beskrivande attributen för informationen på navet (såsom beskrivningen för nyckeln, möjligen på flera språk) lagras i strukturer som kallas satellittabeller som kommer att diskuteras nedan.

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

en surrogatnyckel , som används för att koppla de andra strukturerna till denna tabell.
en affärsnyckel , drivrutinen för detta nav. Affärsnyckeln kan bestå av flera fält.
postkällan, som kan användas för att se vilket system som laddade varje affärsnyckel först.
valfritt kan du också ha metadatafält med information om manuella uppdateringar (användare/tid) och utvinningsdatum.

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

Hub bör normalt ha minst en satellit.

Exempel på nav

Detta är ett exempel på en navtabell som innehåller bilar, kallad "Car" (H_CAR). Környckeln är fordonets identifieringsnummer .

Fält namn	Beskrivning	Obligatorisk?	Kommentar
H_CAR_ID	Sekvens-ID och surrogatnyckel för navet	Nej	Rekommenderas men valfritt
VEHICLE_ID_NR	Affärsnyckeln som driver detta nav. Kan vara mer än ett fält för en sammansatt affärsnyckel	Ja
H_RSRC	Inspelningskällan för denna nyckel när den först laddades	Ja
LOAD_AUDIT_ID	Ett ID i en tabell med granskningsinformation, såsom laddningstid, laddningslängd, antal rader, etc.	Nej

Länkar

Associationer eller transaktioner mellan affärsnycklar (som t.ex. relaterar till hubbar för kund och produkt med varandra genom köptransaktionen) modelleras med hjälp av länktabeller. Dessa tabeller är i grunden många-till-många kopplingstabeller, med viss metadata.

Länkar kan länka till andra länkar för att hantera förändringar i granularitet (till exempel att lägga till en ny nyckel till en databastabell skulle ändra databastabellens kornstorlek). Om du till exempel har en koppling mellan kund och adress kan du lägga till en hänvisning till en länk mellan nav för produkt och transportföretag. Detta kan vara en länk som heter "Leverans". Att hänvisa till en länk i en annan länk anses vara en dålig praxis, eftersom det introducerar beroenden mellan länkar som gör parallellladdning svårare. Eftersom en länk till en annan länk är detsamma som en ny länk med nav från den andra länken, är i dessa fall att skapa länkarna utan att referera till andra länkar den föredragna lösningen (se avsnittet om laddningsmetoder för mer information).

Länkar länkar ibland hubbar till information som i sig inte räcker för att konstruera en hub. Detta inträffar när en av affärsnycklarna som är kopplade till länken inte är en riktig affärsnyckel. Som ett exempel, ta ett beställningsformulär med "ordernummer" som nyckel, och beställningsrader som är knappade med ett semislumpmässigt nummer för att göra dem unika. Låt oss säga, "unikt nummer". Den senare nyckeln är inte en riktig affärsnyckel, så den är ingen nav. Vi behöver dock använda den för att garantera korrekt granularitet för länken. I det här fallet använder vi inte ett nav med surrogatnyckel, utan lägger till själva affärsnyckeln "unikt nummer" i länken. Detta görs endast när det inte finns någon möjlighet att någonsin använda affärsnyckeln för en annan länk eller som nyckel för attribut i en satellit. Den här konstruktionen har kallats en "pinnbenslänk" av Dan Linstedt på hans (nu nedlagda) forum.

Länkar innehåller surrogatnycklarna för de nav som är länkade, deras egen surrogatnyckel för länken och metadata som beskriver föreningens ursprung. De beskrivande attributen för informationen om föreningen (såsom tid, pris eller belopp) lagras i strukturer som kallas satellittabeller som diskuteras nedan.

Länkexempel

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

Fält namn	Beskrivning	Obligatorisk?	Kommentar
L_DRIVER_ID	Sekvens-ID och surrogatnyckel för länken	Nej	Rekommenderas men valfritt
H_CAR_ID	surrogatnyckel för bilnavet, länkens första ankare	Ja
H_PERSON_ID	surrogatnyckel för personnavet, länkens andra ankare	Ja
L_RSRC	Registerkällan för denna association när den laddades första gången	Ja
LOAD_AUDIT_ID	Ett ID i en tabell med granskningsinformation, såsom laddningstid, laddningslängd, antal rader, etc.	Nej

Satelliter

Naven och länkarna bildar modellens struktur, men har inga tidsmässiga attribut och har inga beskrivande attribut. Dessa lagras i separata tabeller som kallas satelliter . Dessa består av metadata som länkar dem till deras överordnade nav eller länk, metadata som beskriver ursprunget för associationen och attributen, samt en tidslinje med start- och slutdatum för attributet. Där hubbar och länkar ger modellens struktur, ger satelliterna modellens "kött", sammanhanget för de affärsprocesser som fångas i hubbar och länkar. Dessa attribut lagras både med avseende på detaljerna i ärendet såväl som 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 giltig indikator och en tidslinje).

Vanligtvis är attributen grupperade i satelliter efter källsystem. Men beskrivande attribut som storlek, kostnad, hastighet, mängd eller färg kan ändras i olika takt, så du kan också dela upp dessa attribut i olika satelliter baserat på deras förändringshastighet.

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

Satellit exempel

Detta är ett exempel på en satellit på förarlänken mellan naven för bilar och personer, kallad "Förarförsäkring" (S_DRIVER_INSURANCE). Denna satellit innehåller attribut som är specifika för försäkringen av förhållandet mellan bilen och personen som kör den, till exempel 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 nav) och en sammanfattning av antalet olyckor med denna kombination av fordon och förare. Dessutom ingår en hänvisning till en uppslags- eller referenstabell kallad R_RISK_CATEGORY som innehåller koderna för den riskkategori i vilken detta förhållande bedöms falla.

Fält namn	Beskrivning	Obligatorisk?	Kommentar
S_DRIVER_INSURANCE_ID	Sekvens-ID och surrogatnyckel för satelliten på länken	Nej	Rekommenderas men valfritt
L_DRIVER_ID	(surrogat) primärnyckel för förarlänken, satellitens förälder	Ja
S_SEQ_NR	Beställnings- eller sekvensnummer, för att framtvinga unikhet om det finns flera giltiga satelliter för en överordnad nyckel	Nej(**)	Detta kan hända om du till exempel har en navKURS och namnet på kursen är ett attribut men på flera olika språk.
S_LDTS	Laddningsdatum (startdatum) för giltigheten av denna kombination av attributvärden för överordnad nyckel L_DRIVER_ID	Ja
S_LEDTS	Ladda slutdatum (slutdatum) för giltigheten av denna kombination av attributvärden för överordnad nyckel L_DRIVER_ID	Nej
IND_PRIMARY_DRIVER	Indikator om föraren är den primära föraren för denna bil	Nej (*)
FÖRSÄKRINGSBOLAG	Namnet på försäkringsbolaget för detta fordon och denna förare	Nej (*)
NR_OF_ACCIDENTS	Antalet olyckor av denna förare i detta fordon	Nej (*)
R_RISK_CATEGORY_CD	Riskkategorin för föraren. Detta är en referens till R_RISK_CATEGORY	Nej (*)
S_RSRC	Uppteckningskällan för informationen i denna satellit när den först laddades	Ja
LOAD_AUDIT_ID	Ett ID i en tabell med granskningsinformation, såsom laddningstid, laddningslängd, antal rader, etc.	Nej

(*) minst ett attribut är obligatoriskt. (**) sekvensnummer blir obligatoriskt om det behövs för att framtvinga unikhet för flera giltiga satelliter på samma nav eller länk.

Referenstabeller

Referenstabeller är en normal del av en hälsosam datavalvsmodell. De är till för att förhindra redundant lagring av enkla referensdata som refereras mycket. Mer formellt definierar Dan Linstedt referensdata enligt följande:

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

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 sakna historik, men det rekommenderas att du håller dig till de naturliga nycklarna och inte skapar surrogatnycklar i så fall. Normalt har datavalv många referenstabeller, precis som alla andra Data Warehouse.

Referensexempel

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 närvarande refererar vi till det från satelliten S_DRIVER_INSURANCE. Referenstabellen är R_RISK_CATEGORY.

Fält namn	Beskrivning	Obligatorisk?
R_RISK_CATEGORY_CD	Koden för riskkategorin	Ja
RISK_CATEGORY_DESC	En beskrivning av riskkategorin	Nej (*)

(*) minst ett attribut är obligatoriskt.

Laddningsmetoder

ETL för uppdatering av en datavalvmodell är ganska enkel (se Data Vault Series 5 – Loading Practices ) . Först måste du ladda alla hubbar och skapa surrogat-ID:n för alla nya affärsnycklar. Efter att ha gjort det kan du nu lösa alla affärsnycklar till surrogat-ID:n om du frågar navet. Det andra steget är att lösa länkarna mellan hubbar och skapa surrogat-ID för eventuella nya föreningar. Samtidigt kan du också skapa alla satelliter som är kopplade till hubbar, eftersom du kan lösa nyckeln till ett surrogat-ID. När du har skapat alla nya länkar med deras surrogatnycklar kan du lägga till satelliterna till alla länkarna.

Eftersom naven inte är förenade med varandra förutom genom länkar kan du ladda alla nav parallellt. Eftersom länkar inte är kopplade direkt till varandra kan du ladda alla länkar parallellt också. Eftersom satelliter endast kan kopplas till hubbar och länkar kan du även ladda dessa parallellt.

ETL är ganska enkel och lämpar sig för enkel automatisering eller mall. Problem uppstår bara med länkar som hänför sig till andra länkar, eftersom att lösa affärsnycklarna i länken bara leder till en annan länk som också måste lösas. På grund av att denna situation är likvärdig med en länk till flera nav, kan denna svårighet undvikas genom att göra om sådana fall och detta är faktiskt den rekommenderade praxisen.

Data raderas aldrig från datavalvet, såvida du inte har ett tekniskt fel när du laddar data.

Datavalv och dimensionsmodellering

Det datavalvsmodellerade lagret används normalt för att lagra data. Det är inte optimerat för frågeprestanda, och det är inte heller lätt att fråga med de välkända frågeverktygen som Cognos , Oracle Business Intelligence Suite Enterprise Edition , SAP Business Objects , Pentaho et al. ^{[ citat behövs ]} Eftersom dessa slutanvändarberäkningsverktyg förväntar sig eller föredrar att deras data ska finnas i en dimensionell modell , är en konvertering vanligtvis nödvändig.

För detta ändamål kan hubbar och relaterade satelliter på dessa hubbar betraktas som dimensioner och länkarna och relaterade satelliter på dessa länkar kan ses som faktatabeller i en dimensionell modell. Detta gör att du snabbt kan prototypera en dimensionsmodell ur en datavalvsmodell med hjälp av vyer.

Observera att även om det är relativt enkelt att flytta data från en datavalvsmodell till en (rensad) dimensionsmodell, är det omvända inte lika lätt, med tanke på den denormaliserade karaktären hos dimensionsmodellens faktatabeller, som är fundamentalt annorlunda än den tredje normala formen av datavalv.

Datavalvmetodik

Datavalvets metodik är baserad på SEI / CMMI nivå 5 bästa praxis. Den innehåller flera komponenter i CMMI Level 5 och kombinerar dem med bästa praxis från Six Sigma , TQM och SDLC. Speciellt fokuserar den på Scott Amblers agila metodik för utbyggnad och driftsättning. Datavalvprojekt har en kort, omfattningskontrollerad releasecykel och bör bestå av en produktionsrelease varannan till var tredje vecka.

Team som använder datavalvmetoden bör lätt anpassa sig till de repeterbara, konsekventa och mätbara projekt som förväntas på CMMI nivå 5. Data som flödar genom EDW datavalvsystemet kommer att börja följa TQM (total quality management) livscykel som har länge saknats i BI-projekt (business intelligence).

Verktyg

Några exempel på verktyg är: ^{[ förtydligande behövs ]}

Se även

Citat

Källor

Linstedt, Dan (december 2010). Superladda ditt datalager . Dan Linstedt. ISBN 978-0-9866757-1-3 .
Thomas C. Hammergren; Alan R. Simon (februari 2009). Data Warehousing for Dummies, 2:a upplagan . John Wiley & Sons. ISBN 978-0-470-40747-9 .
Ronald Damhof; Lidwine van As (25 augusti 2008). "Nästa generation EDW – Att släppa tanken på en enda version av sanningen" ( PDF) . Databastidning (DB/M) . Array Publications BV
Linstedt, Dan. "Data Vault Series 1 – Data Vault Översikt" . Data Vault-serien . Dataförvaltningens nyhetsbrev . Hämtad 12 september 2011 .
Linstedt, Dan. "Data Vault Series 2 – Data Vault Components" . Data Vault-serien . Dataförvaltningens nyhetsbrev . Hämtad 12 september 2011 .
Linstedt, Dan. "Data Vault Series 3 – Slutdatum och grundläggande kopplingar" . Data Vault-serien . Dataförvaltningens nyhetsbrev . Hämtad 12 september 2011 .
Linstedt, Dan. "Data Vault Series 4 – Länktabeller" . Data Vault-serien . Dataförvaltningens nyhetsbrev . Hämtad 12 september 2011 .
Linstedt, Dan. "Data Vault Series 5 – Loading Practices" . Data Vault-serien . Dataförvaltningens nyhetsbrev . Hämtad 12 september 2011 .
Kunenborg, Ronald. "Data Vault Rules v1.0.8 Cheat Sheet" (PDF) . Regler för datavalv . Grundsätzlich IT . Hämtad 26 september 2012 . Fuskblad som återspeglar reglerna i v1.0.8 och ytterligare förtydligande från forumen om reglerna i v1.0.8.
Linstedt, Dan. "Data Vault Modeling Specification v1.0.9" . Data Vault Forum . Dan Linstedt . Hämtad 26 september 2012 .
Linstedt, Dan. "Data Vault Loading Specification v1.2" . DanLinstedt.com . Dan Linstedt . Hämtad 2014-01-03 .
Linstedt, Dan. "En kort introduktion till #datavault 2.0" . DanLinstedt.com . Dan Linstedt . Hämtad 2014-01-03 .
Linstedt, Dan. "Data Vault 2.0 tillkännages" . DanLinstedt.com . Dan Linstedt . Hämtad 2014-01-03 .

Holländska språkkällor

Ketelaars, MWAM (2005-11-25). "Datawarehouse-modeller med Data Vault". Databastidning (DB/M) . Array Publications BV (7): 36–40.
Verhagen, K.; Vrijkorte, B. (10 juni 2008). "Relationeel kontra Data Vault". Databastidning (DB/M) . Array Publications BV (4): 6–9.

Litteratur

Patrick Cuba: Data Vault Guru. En pragmatisk guide för att bygga ett datavalv. Selbstverlag, ohne Ort 2020, ISBN 979-86-9130808-6.
John Giles: Elefanten i kylen. Guidade steg för framgång i datavalv genom att bygga affärscentrerade modeller. Technics, Basking Ridge 2019, ISBN 978-1-63462-489-3.
Kent Graziano: Bättre datamodellering. En introduktion till agil datateknik med hjälp av Data Vault 2.0. Data Warrior, Houston 2015.
Hans Hultgren: Modellering av Agile Data Warehouse med Data Vault. Brighton Hamilton, Denver ua 2012, ISBN 978-0-615-72308-2.
Dirk Lerner: Data Vault für agile Data-Warehouse-Architekturen. I: Stephan Trahasch, Michael Zimmer (Hrsg.): Agile Business Intelligence. Teori och praxis. dpunkt.verlag, Heidelberg 2016, ISBN 978-3-86490-312-0, S. 83–98.
Daniel Linstedt: Superladda ditt datalager. Ovärderliga datamodelleringsregler för att implementera ditt datavalv. Linstedt, Saint Albans, Vermont 2011, ISBN 978-1-4637-7868-2.
Daniel Linstedt, Michael Olschimke: Att bygga ett skalbart datalager med Data Vault 2.0. Morgan Kaufmann, Waltham, Massachusetts 2016, ISBN 978-0-12-802510-9.
Dani Schnider, Claus Jordan ua: Data Warehouse Blueprints. Business Intelligence in der Praxis. Hanser, München 2016, ISBN 978-3-446-45075-2, S. 35–37, 161–173.

externa länkar