Surrogaatsleutels; een goed idee?
Binnen datawarehouse architecturen kennen wij al tientallen jaren het concept van surrogaatsleutels. Bij Ă©Ă©n van onze klanten was er een discussie over het wel of niet toepassen van surrogaatsleutels in het data lakehouse. In deze blog deel ik de discussie, de argumenten van beide kanten en onze voorlopige conclusie.
Maar eerst, wat zijn surrogaatÂsleutels?
Surrogaatsleutels zijn kunstmatig, door het systeem, gegenereerde waarden die gebruikt worden om elke rij in een tabel uniek te identificeren. Surrogaatsleutels komen binnen het data lakehouse het meest voor in dimensionale modellen (ofwel de “gouden laag”).
Binnen een dimensionaal model acteren surrogaatsleutels als alternatief voor de natuurlijke sleutel binnen een dimensie tabel. Een surrogaatsleutel is een oplopend getal voor elke nieuwe rij die door het systeem wordt toegevoegd. Een voorbeeld:
CustomerKey | CustomerID | CustomerName |
---|---|---|
1 | CUS-00A1 | John Doolittle |
2 | CUS-00A3 | Alexa Smith |
Binnen het dimensionaal model wordt betekenis gegeven aan bepaalde surrogaatsleutel-waarden. Zo is de waarde -1 vaak gereserveerd voor de onbekende waarde.
CustomerKey | CustomerID | CustomerName |
---|---|---|
-1 | Unknown | Unknown |
1 | CUS-00A1 | John Doolittle |
2 | CUS-00A3 | Alexa Smith |
Surrogaatsleutels spelen een belangrijke rol in de verschillende type dimensies die worden onderkend. Een voorbeeld is type 2 waar de historie van een wijziging wordt bijgehouden met behoud van de uniekheid van elke rij.
CustomerKey | CustomerID | CustomerName | MaritalStatus | EffStartDate | EffEndDate |
---|---|---|---|---|---|
-1 | Unknown | Unknown | U | 1-1-1900 | 1-1-3000 |
1 | CUS-00A1 | John Doolittle | Y | 1-1-1900 | 1-1-3000 |
2 | CUS-00A3 | Alexa Smith | N | 1-1-1900 | 1-2-2023 |
3 | CUS-00A3 | Alexa Smith | Y | 2-2-2023 | 1-1-3000 |
Klinkt goed, wat was de discussie?
De surrogaatsleutel is een concept dat binnen dimensioneel modelleren is toegepast ten tijde van relationele database-systemen. EĂ©n van de grootste voordelen van surrogaatsleutels binnen relationele databases, is de verbetering in snelheid. Elke dimensie met een surrogaatsleutel bevat een clustered index op de sleutel waardoor joins vanuit de feitentabellen met dimensies sneller zijn. Echter, binnen een data lakehouse architectuur is het concept van clustered indexen (vooralsnog) niet bekend.
Als projectteam onderkenden wij de volgende voor- en nadelen van een surrogaatsleutel binnen ons data lakehouse:
Enkele nadelen:
- Moeilijk leesbaar: Vanuit menselijk perspectief is een surrogaatsleutel betekenisloos. Ad-hoc analyse en probleemanalyse is uitdagender omdat het een extra join naar de dimensie tabel vereist om de data te kunnen begrijpen.
- Complexer: Met de introductie van surrogaatsleutels wordt het data platform complexer om te onderhouden.
Enkele voordelen:
- Ondersteuning verschillende type dimensies: De verschillende type dimensies, zoals type 2, worden goed ondersteund door elke rij uniek te houden.
- Snelheid (voor sommige applicaties): Surrogaatsleutels zijn van het type integer die goed te comprimeren zijn in applicaties zoals Power BI (lees ook onze 6 tips voor een goede start met Power BI).
Onze conclusie was een compromis.
We onderkenden de vele joins die nodig zijn en dat daardoor ad-hoc analyse langer duurden. We zagen ook dat Power BI modellen een factor 5 groter werden bij het weglaten van surrogaatsleutels in feitentabellen.
We hebben ervoor gekozen om zowel de natuurlijke als de surrogaatsleutels op te nemen in de feitentabellen binnen de “gouden laag”. Met de surrogaatsleutels werden onze Power BI modellen niet onnodig groot. Door de aanwezigheid van de natuurlijke sleutels werden de ad-hoc analyses in de gouden laag simpeler doordat men direct over de oorspronkelijke data beschikt zonder eerste een join te moeten leggen.
We zijn benieuwd naar jullie ervaringen met surrogaatsleutels.