Samenvatting/aantekeningen Sterren en Dimensies
Data Vault: manier om datawarehouses te modelleren en bouwen. Ontwikkeld in 2002. Alle
bronsystemen schrijven (door middel van een ETL) data naar de Data vault. Het DWH schrijft deze
vervolgend door (ETL) naar multidimensionale databases, olaps en sterren. Een datavault is:
Genormaliseerd
Flexibele en aanpasbaar per bedrijf
Snelle, paralelle dataverwerking
Gemaakt door Dan Linstedt
De data vault bestaat uit:
HUBS: Bedrijfsentiteiten
LINKS: relaties tussen bedrijfsentiteiten
SATTELITES: eigenschappen van HUBS en LINKS
HUBS bevatten:
Surrogate key (sequalnumber) die ‘meaningles’ is
Business key (bedrijfssleutel die herkenbaar is voor het bedrijf zoals artikelID)
LDTS (Loaddate Timestamp) Wanneer is de record naar de datavault geschreven
Record Source (Welke brondatabase komt het record vandaan)
LINKS worden gemaakt wanneer:
Een Foreign Key to Primary Key reference bestaat
Veel op veel relatie bestaat
Als er een transactie is (HUB artikel en HUB Klant en HUB Verkoper LINK Verkoop)
LINKS bevatten:
Surrogate Key (sequalnumber) die ‘meaningles’ is
HUB 1 Surrogate key
HUB 2 Surrogate key
HUB N Surrogate key
LDTS
Recourdsource
SATTELITES bevatten:
HUB/LINK sequalnumber --PK
LDTS --PK
EDTS (Enddate Timestamp)
Recordsource
Attribuut 1
Attribuut 2
Attribuut N
Stappen voor modelleren:
1. Wat zijn de entiteiten HUBS
2. Relaties tussen de HUBS LINKS
3. Eigenschappen van al deze HUBS en LINKS SATTELITES
4. Business Keys staan altijd in HUBS
, 5. SATTELITES zijn maar aan één HUB/LINK gekoppeld LINKS zijn verbonden met HUBS of andere
links. 6. Er kunnen SATTELITES naar LINKS wijzen maar HUBS kunnen niet direct aan elkaar verbonden
zijn.
OLTP: On-Line Transaction Processing OLAP: On-Line Analytical Processing
Kleine transacties Bulk load
Veel kleine queries Weinig grote queries en tabelscans
Standaard lijsten Ad-hoc
Data op detaillevel Samengevoegde data (gemiddelde/aggregate)
Veel gebruikers Weinig gebruikers
Routine werk Analysten en managers
Kritiek voor bedrijfsprocessen Kan regelmatig offline (buiten gebruik) zijn
Moeilijk aanpasbaar Flexibel
Waterval ontwikkelmethode Incrementeel ontwikkelmethode
Een feitentabel bestaat uit FK’s (naar dimensies) en measures (wat wil je meten). Dimensies worden
gevonden door ‘w’-vragen te stellen:
- Wat? Product
- Waar? Winkel
- Wanneer tijd
- Aan wie? Klant
- Welke omstandigheden/waarom? Promotie
Bij dimensies hoeft geen ruimte te worden bespaard. Dit moet wel bij de feitentabel omdat deze met
iedere kolom in de dimensie 10 of 100x groter kan worden als er 1 extra optie in een dimensie wordt
gezet.
ETL Extract, Transfer, Load. In de ETL wordt data opgeschoond, gecorrigeerd en in de ster geladen.
Wanneer data uit de bron komt wordt deze meteen in het DWH gezet.
De datavault bevat álle data uit de bronnen + De bron en geschiedenis. Een dwh kan vaak gemaakt
worden zonder de entiteiten van het bedrijf te weten en het bedrijf te raadplegen. De etl van de
bron naar de dwh kan bijna volledig geautomatiseerd worden. Onderhoud aan de ETL is voor
rekening van de IT, Bedrijfsregels en informatiebehoefte wordt bepaald door het bedrijf.
Normale dimensies hebben minimaal 1 hiërarchie en bevatten sleutels die als een fk naar de pk in de
feitentabel wijzen.
Causale dimensies hebben geen hiërarchie. In een causale dimensie is ook een record opgenomen
waarbij de dimensie geen deel uitmaakt van de resultaten in de feitentabel (bij geen promotie
bijvoorbeeld). De promotiekey maakt geen (Kimball) of wel (van der lek) deel uit van de PK in de
feitentabel.
Soms is het makkelijk om een monsterdimensie in een dwh op te splitsen in een mini-dimensie
waarbij gegevens worden opgenomen die vaak in groepen veranderen (NAW-gegevens). In de
monster dimensie wordt dan een sleutel opgenomen die naar de mini-dimensie wijst. In de
feitentabel gebeurt dit ook. Deze komt niet uit de PK van de monsterdimensie of de feitentabel.
Data Vault: manier om datawarehouses te modelleren en bouwen. Ontwikkeld in 2002. Alle
bronsystemen schrijven (door middel van een ETL) data naar de Data vault. Het DWH schrijft deze
vervolgend door (ETL) naar multidimensionale databases, olaps en sterren. Een datavault is:
Genormaliseerd
Flexibele en aanpasbaar per bedrijf
Snelle, paralelle dataverwerking
Gemaakt door Dan Linstedt
De data vault bestaat uit:
HUBS: Bedrijfsentiteiten
LINKS: relaties tussen bedrijfsentiteiten
SATTELITES: eigenschappen van HUBS en LINKS
HUBS bevatten:
Surrogate key (sequalnumber) die ‘meaningles’ is
Business key (bedrijfssleutel die herkenbaar is voor het bedrijf zoals artikelID)
LDTS (Loaddate Timestamp) Wanneer is de record naar de datavault geschreven
Record Source (Welke brondatabase komt het record vandaan)
LINKS worden gemaakt wanneer:
Een Foreign Key to Primary Key reference bestaat
Veel op veel relatie bestaat
Als er een transactie is (HUB artikel en HUB Klant en HUB Verkoper LINK Verkoop)
LINKS bevatten:
Surrogate Key (sequalnumber) die ‘meaningles’ is
HUB 1 Surrogate key
HUB 2 Surrogate key
HUB N Surrogate key
LDTS
Recourdsource
SATTELITES bevatten:
HUB/LINK sequalnumber --PK
LDTS --PK
EDTS (Enddate Timestamp)
Recordsource
Attribuut 1
Attribuut 2
Attribuut N
Stappen voor modelleren:
1. Wat zijn de entiteiten HUBS
2. Relaties tussen de HUBS LINKS
3. Eigenschappen van al deze HUBS en LINKS SATTELITES
4. Business Keys staan altijd in HUBS
, 5. SATTELITES zijn maar aan één HUB/LINK gekoppeld LINKS zijn verbonden met HUBS of andere
links. 6. Er kunnen SATTELITES naar LINKS wijzen maar HUBS kunnen niet direct aan elkaar verbonden
zijn.
OLTP: On-Line Transaction Processing OLAP: On-Line Analytical Processing
Kleine transacties Bulk load
Veel kleine queries Weinig grote queries en tabelscans
Standaard lijsten Ad-hoc
Data op detaillevel Samengevoegde data (gemiddelde/aggregate)
Veel gebruikers Weinig gebruikers
Routine werk Analysten en managers
Kritiek voor bedrijfsprocessen Kan regelmatig offline (buiten gebruik) zijn
Moeilijk aanpasbaar Flexibel
Waterval ontwikkelmethode Incrementeel ontwikkelmethode
Een feitentabel bestaat uit FK’s (naar dimensies) en measures (wat wil je meten). Dimensies worden
gevonden door ‘w’-vragen te stellen:
- Wat? Product
- Waar? Winkel
- Wanneer tijd
- Aan wie? Klant
- Welke omstandigheden/waarom? Promotie
Bij dimensies hoeft geen ruimte te worden bespaard. Dit moet wel bij de feitentabel omdat deze met
iedere kolom in de dimensie 10 of 100x groter kan worden als er 1 extra optie in een dimensie wordt
gezet.
ETL Extract, Transfer, Load. In de ETL wordt data opgeschoond, gecorrigeerd en in de ster geladen.
Wanneer data uit de bron komt wordt deze meteen in het DWH gezet.
De datavault bevat álle data uit de bronnen + De bron en geschiedenis. Een dwh kan vaak gemaakt
worden zonder de entiteiten van het bedrijf te weten en het bedrijf te raadplegen. De etl van de
bron naar de dwh kan bijna volledig geautomatiseerd worden. Onderhoud aan de ETL is voor
rekening van de IT, Bedrijfsregels en informatiebehoefte wordt bepaald door het bedrijf.
Normale dimensies hebben minimaal 1 hiërarchie en bevatten sleutels die als een fk naar de pk in de
feitentabel wijzen.
Causale dimensies hebben geen hiërarchie. In een causale dimensie is ook een record opgenomen
waarbij de dimensie geen deel uitmaakt van de resultaten in de feitentabel (bij geen promotie
bijvoorbeeld). De promotiekey maakt geen (Kimball) of wel (van der lek) deel uit van de PK in de
feitentabel.
Soms is het makkelijk om een monsterdimensie in een dwh op te splitsen in een mini-dimensie
waarbij gegevens worden opgenomen die vaak in groepen veranderen (NAW-gegevens). In de
monster dimensie wordt dan een sleutel opgenomen die naar de mini-dimensie wijst. In de
feitentabel gebeurt dit ook. Deze komt niet uit de PK van de monsterdimensie of de feitentabel.
