Ingen äger Data vault men för att se till att utvecklingen och framdriften av Data vault sker på ett kontrollerat och koordinerat sätt finns ett golbalt standardiseringsorgan som har hand om Data vault.
Top of Minds sitter i den globala standardiseringskommittén och driver utvecklingen av Data vault.
Över ett dussin stora europeiska banker, flera stora telekomoperatörerna, många statliga myndigheter och organisationer och ett flertal stora retail- och tillverkningskoncerner. Internationellt sett estimeras antalet stora Data vault-installationer till 4- 500 st, och i exempelvis Nederländerna använder i princip samtliga pågående DWH-projekt Data vault. Jag tror att Sverige är på samma väg.
Nej. Men jag och resten av Top of Minds har lång erfarenhet av Data vault, och tekniken är som gjord för att utveckla återanvändbar kod inom ditt projekt. Det hjälper vi gärna till med att ta fram!
Här på Top of Minds hemsida finns en grundkurs i Data vault och vi har halvårsvisa seminarier som går igenom tekniken mer i detalj. Vi arbetar tillsammans med Genesee academy som håller kvartalsvisa certifieringar inom Data vault. Jag har massor med information att ge dig – ring mig!
Det kan man verkligen fråga sig. Om du inte har några problem har du ingenting att åtgärda. Varför peta på något som inte är trasigt?
Otvetydigt JA. Om du inte överväger Data vault struntar du effektivt i de senaste tio årens utveckling inom DataWarehouse.
Det är som att fråga varför du ska ha smör istället för bröd. Om du bara har bröd, eller Data vault, blir din macka torr och tråkig, och ditt datavaruhus har visserligen substans men inga effektiva rapporteringsmöjligheter. Har du bara smör, eller en Kimball-approach, har du kraftfulla rapporteringsmöjligheter och en läcker smak men väldigt lite substans, och förr eller senare kommer ditt datavaruhus smälta bort i solen. Data vault adresserar problematiken med att ha ett konsoliderat datavaruhus under dina rapportmarter, och Kimball adresserar problematiken med att få ut data från ditt lager på ett effektivt sätt för att stödja flera former av rapportering. Alla kök behöver både smör och bröd.
Data vault har en skiktad arkitektur. Därför får frågan två svar beroende på i vilket arkitekturellt skikt du jobbar.
1. Om du jobbar med att skapa ETL/SQL för att bygga en Data Mart/Star Schema från ditt Data vault skikt så är det inte så. Detta på grund av att Data vault lösningar modelleras enligt de affärsnycklar ert företag jobbar med. Det innebär att bygga, t ex en Kunddimension så kommer du endast hämta data från ”KundHuben” och dess satelliter. Vilket praktiskt innebär att man joinar ca 2-5 tabeller via en primärnyckel. Mycket snabbt och mycket effektivt. Faktatabeller byggs oftast utifrån Länkar(Links) där data gällande en interaktion mellan två eller flera ämnesområden lagras, precis som en faktatabell fungerar. Det innebär också få joinar med bra primärnycklar. Data vault design ger dig möjlighet att med en kirurgisk precision skapa ditt rapporteringsskikt.
2. Om du jobbar med att bygga rapporter och analystiska sql:er som rör sig över flera ämnesområden, t ex kund, avtal, produkt inom samma SQL så blir det många joins som vandrar över olika primärnycklar och byter index etc, det blir helt enkelt ganska tungt för optimizern i databasen att hantera.
Det är därför vi rekommenderar att man bygger ett rapporteringsskikt ovan Data vault skiktet, både för att skapa SQL prestanda för rapporter men också för att kunna hantera analysunika rapporteringsregler så långt upp i informationsflödet som möjligt och behålla informationen i Data vault skiktet så affärsgenerell som möjligt och därför återanvändbar i många olika analytiska applikationer.
Data vault fungerar utmärkt att hantera DW migreringar. Den grundläggande orsaken till detta är att Data vault design alltid utgår från företagets affärsnycklar. På detta sätt så kan man iterativt migerar över information från ett äldre Data Warehouse, en sorts affärsnyckel i taget.
Genom att lägga upp en migreringsstrategi som tar delmängder av ett existerande DW, t ex ett rapporteringsområde i taget, så kan man agilt hantera en migrering och minska riskerna genom en iterativ övergång och på det sättet snabbt skapa användbara implementationer.
Det finns färdiga tekniker för hur man ska gå tillväga för att ”översätta” ett Star Schema eller en model i 3NF till Data vault strukturer. Kontakta oss så hjälper vi er.