Degenerate dimension

Wat is een degenerate dimension?

Een degenerate dimension is een dimensie-attribuut dat in de feitentabel zelf blijft staan, zonder eigen dimensietabel ernaast. Het klassieke voorbeeld is een ordernummer, een factuurnummer of een transactie-id: een sleutel die elke feitrij aan een transactie toewijst, maar die zelf niets beschrijft.

De term komt uit de methode voor dimensioneel modelleren van Ralph Kimball. "Degenerate" slaat op wat er overblijft. Alle beschrijvende kolommen die je normaal in een dimensie zou steken, zitten al in de gewone dimensietabellen: klant, product, datum, verkoper. Wat rest is een identificatienummer met een hoge cardinaliteit en geen attributen van zichzelf. Zo'n sleutel krijgt geen aparte tabel, want er valt niets in te beschrijven.

In een model zie je zo'n kolom vaak gemarkeerd met de afkorting DD, van degenerate dimension.

Waarom hij in de feitentabel blijft

Je zou een dimensietabel voor het ordernummer kunnen bouwen, maar die zou enkel het nummer bevatten en verder niks. Dan dupliceer je de sleutel in twee tabellen zonder er een beschrijvende kolom aan toe te voegen. Dat is verspild werk en een extra join voor niets.

Toch gooi je het nummer niet weg, want het doet echt iets:

• Het groepeert alle feitrijen van dezelfde transactie. Eén verkooporder met vijf orderlijnen levert vijf rijen op in de feitentabel, allemaal met hetzelfde ordernummer. Zo weet je welke lijnen samen op een order stonden.

• Het laat je het aantal unieke transacties tellen. "Hoeveel orders draaiden we deze maand?" is een distinct count op het ordernummer, niet op de losse orderlijnen.

• Het geeft je een weg terug naar het bronsysteem. Zie je een verdachte lijn in een rapport, dan zoek je met dat ordernummer de originele order op in je ERP.

Voorbeeld: order_number op een verkoopfeit

Neem een feitentabel Verkoop op het niveau van één orderlijn, de granulariteit van het feit. Elke rij heeft sleutels naar de dimensies (KlantId, ProductId, DatumId, VerkoperId) en maten (aantal, bedrag, korting). Daarnaast staat er een kolom order_number.

Die order_number verwijst nergens naartoe. Er is geen dimensietabel Order met kolommen erachter, want alles wat een order beschrijft zit al in de gewone dimensies. Het nummer blijft dus in het feit staan als degenerate dimension. Een factuurnummer op een boekhoudfeit werkt net zo: één factuur met meerdere lijnen, één nummer dat die lijnen bij elkaar houdt.

Verschil met een gewone dimensie

Een gewone dimensie zoals Product heeft een eigen tabel vol beschrijvende kolommen: naam, categorie, merk, verpakking. De feitentabel bewaart enkel de ProductId en haalt de rest via de relatie op. Zo ziet een net ster-schema eruit.

Een degenerate dimension mist die tabel. Het is de sleutel zonder de beschrijving eromheen. Je gebruikt hem om te groeperen en te tellen, niet om op te filteren met leesbare labels. Merk je toch dat er attributen bij horen, bijvoorbeeld een orderstatus of een besteldatum die verschilt van de leverdatum, dan heb je eigenlijk een echte dimensie nodig en geen degenerate dimension.

Waar moet je op letten bij een degenerate dimension

Degenerate dimensions duiken vooral op bij transactie-feittabellen en bij een snapshot fact table, waar één document zoals een order, factuur of claim over meerdere lijnen loopt.

Twee dingen om in het oog te houden. Groeit een dimensietabel even snel als je feittabel, dan zit er wellicht een degenerate dimension verstopt die beter gewoon in het feit staat. En verzamel je meerdere losse vlaggen met weinig waarden, zoals een status, een ja-of-nee-indicator en een verkoopkanaal, dan horen die thuis in een junk dimension die ze samen bundelt, in plaats van als reeks aparte kolommen in je feit.