3. När behöver vi INTE data vault
There are times when a Data Vault is not necessary, nor even warranted for building. Those times
might include some of the following reasons:
You are building a single-business-unit focused answer set
You do not need an enterprise view
You do not need an auditable historical data store (as you have all the data in a single source system,
backed up forever)
You do not have a number of external systems to integrate (3 or more?)
You are running a columnar data store, Key=Value store, NoSQL store, or denormalized store (like
Netezza)
4. Varför behöver vi DV (eller liknande)
Alternativ: designa i 3NF eller som stjärnor direkt.
Uppenbara problem:
• 3NF har komplicerade ”kaskader” av PK/FK som är
svårhanterliga när man försöker historisera
• Stjärnor är ett helvete att bygga om när granularitetsändringar
krävs.
5. Kort sagt behandlar Data vault ett datalagers
tre kärnfrågor:
• förmåga att stödja spårbarhet och revisioner i
enlighet med organisationens och myndigheters
krav.
• förmåga att lätt anpassas till nya affärsmodeller,
nya datakällor och nya regler.
• förmåga att stödja integrerad
företagsinformation och undvika att skapa
informationssilos.
Ett stockholmskt
företag som
specialiserar sig i
implementering av DV
samt kurser i ämnet:
7. Var passar Data Vault i en DW-miljö
filer
DB staging
Enterprise
Data
Warehouse:
inget
raderas, allt
historiseras
övrigt
T.ex. DV
8. DVi ekosystemetav modelleringstekniker
3NF, bra för operativa
databaser
DV, bra för enterprise
data warehouse.
Alternativ: anchor (6NF),
IIW…
Dimensionell (stjärna),
bra för OLAP
Observera att DV är
bara en av många
olika möjligheter.
10. Hur ser det ut då?
3 typer av tabeller:
• Hub, lista på unika verksamhetsnycklar
• Link, associationer eller relationer
• Satellit, deskriptiva attribut
kund
adress
produkt
pris
order Avsändare
Totalbelop
link
Order status
11. Hur man ska tänka visuellt
3NF och Star Schema: Data Vault
Data Vault uniquely separates the Business Keys (Hubs) from the Associations
(Links) and both of these from the Details that describe them and provide
context (Satellites).
hub
hub
lnk
sat
Primär nyckel
FK
attribut
19. ETL blir lätt och snabb!
Stora nyheten här är att laddningarna kan käras parallellt;
Också rätt så simpel ETL kod för varje steg.
ALLA ALLA LÄNKAR LÄNKARS SAT
HUBAR OCH ALLA SAT EV LÄNKAR TILL
FÖRST TILL HUBAR ANDRA LÄNKAR
20. Laddningsmönster HUB
Hubkolumner
• Hubens löpnummer-id, genererars vid laddning
• “Business Key”-värde, från källsystemet. Normalt en sträng.
• Load_Date (datum och tid)
• Record_Source (namn på källsystemet, också sträng)
Laddning
• Select Distinct <list of business Keys>
• Add timestamp and record_source
• Insert into Hub if the value does not exist
21. Laddningsmönster SAT
Satellitkolumner
• Hub eller Link löpnummer-id
• Load_Date
• End_date
• Record_Source
Optional Columns
• Attribut (minst en, oftast fler – mätetal, strängar och datum)
Laddning
• Select <list of attributes> from the source
• Add timestamp and record_source
• Lookup för att ta fram HUB_id eller LNK_id
• Jämför med poster som redan finns i SAT. Vid förändring, skapa ny post
(samt evt pensionera den gamla)
22. Laddningsmönster LÄNK
Länkkolumner
• Löpnummer-id
• Load_Date
• Record_Source (generally a string)
• Minst två löpnummer-id:n från hubar eller andra länkar. Dessa kan
modelleras som FK.
Laddning
• Select <Distinct list of business Key combinations> from source
• Add timestamp and record_source
• Lookup löpnummer-id:n från relaterade Hubar eller Länkar
• Insert into Link if the value does not exist
23. Se DV som ett modelleringsperspektiv
(av många)
Shu – ”embrace the rule”. Följ DV-reglerna slaviskt. Var fundamentalist!
Ha – ”break the rule”. Var flexibel och lyhörd. Verksamhetskrav leder dig
kanske till briljanta lösningar där vissa delar är ej DV-konforma
Ri – ”be the rule”. Du är mästare. DV för dig är ett språk som du talar
flytande, och kan tom skämta på.
Källa: Roland Damhofs Blogg