Junk dimension

Wat is een junk dimension?

Een junk dimension is een kleine dimensietabel die een handvol losse vlaggen en statuscodes samenbrengt: ja/nee-velden, type-aanduidingen, kanaalcodes. Het gaat om kolommen met weinig verschillende waarden die nergens anders in je model een logische plek hebben. In plaats van voor elk van die velden een aparte minitabel te maken of ze los in je feitentabel te laten hangen, stop je ze samen in een tabel.

De term komt van Ralph Kimball, de grondlegger van het dimensioneel modelleren. "Junk" slaat op het karakter van de velden, kleine restjes context die overblijven, en niet op de kwaliteit van de data zelf. Kimball noemt dezelfde tabel in een schema ook wel een transaction profile dimension.

Elke voorkomende combinatie van die vlaggen krijgt een rij met een surrogaatsleutel. Je feitentabel verwijst dan met die ene sleutel naar de juiste rij, in plaats van tien losse vlagkolommen mee te slepen.

Waarom bouw je er een?

Je lost er twee problemen mee op tegelijk.

Je feitentabel blijft smal. Een feitentabel hoort sleutels en meetbare getallen te bevatten, geen rij losse ja/nee-kolommen. Tien vlagkolommen sleep je bij elke query mee. Ruil je ze in voor een sleutel naar een junk dimension, dan wordt de feitentabel korter en sneller.

Je vermijdt een zwerm minitabellen. Geef je elke vlag zijn eigen dimensietabel, dan hangt je feittabel plots aan twintig piepkleine dimensies en raken de relaties onbeheerbaar. Een junk dimension vangt die losse velden samen op, zodat je ster-schema overzichtelijk blijft.

Hoe bouw je een junk dimension?

De rij-inhoud is de kern. Je schrijft niet blind elke wiskundig mogelijke combinatie weg. Je neemt enkel de combinaties die echt in je brondata voorkomen. Kimball beschrijft twee werkwijzen.

• Volledige combinatie. Heb je maar een paar velden met elk weinig waarden, dan bouw je gewoon alle combinaties uit. Drie velden met 2, 3 en 3 waarden geven samen 18 rijen, klein genoeg om vooraf uit te schrijven.

• Enkel wat voorkomt. Heb je veel velden, dan explodeert dat aantal. Tien ja/nee-vlaggen geven al 1024 mogelijke combinaties, waarvan er in de praktijk misschien maar veertig echt gebeuren. Dan bouw je de tabel op uit de combinaties die je in de brondata terugvindt.

Die tweede aanpak vraagt bij elke lading een extra controle: duiken er nieuwe combinaties op, dan voeg je die als rij toe voor je de feiten wegschrijft.

Een voorbeeld met orders

Stel, je verkoopt online en aan elke order hangen drie kleine kenmerken: is het een cadeau (ja/nee), de betaalwijze (kaart, overschrijving, bij levering) en het kanaal (web, telefoon, winkel). Je maakt er een dimensie van, bijvoorbeeld OrderProfiel, met een surrogaatsleutel en die drie kolommen. Elke voorkomende combinatie krijgt een rij:

• 1 = geen cadeau, kaart, web

• 2 = cadeau, kaart, web

• 3 = geen cadeau, overschrijving, telefoon

In je feitentabel staat per order enkel nog OrderProfielId. Wil een rapport de omzet van cadeau-orders per kanaal, dan filter en groepeer je op de junk dimension, net zoals op elke andere dimensie.

Junk dimension versus degenerate dimension

Beide horen bij het opruimen van een data warehouse, maar ze doen iets anders. Een degenerate dimension is een sleutel die zonder eigen tabel in de feitentabel blijft staan, typisch een ordernummer of ticketnummer: uniek per rij, dus een aparte tabel zou niks toevoegen. Een junk dimension werkt net omgekeerd: velden met heel weinig waarden die zich juist goed laten samenbundelen in een kleine gedeelde tabel. Bijna-unieke identificatie blijft dus in het feit, laag-cardinale vlaggen verhuizen naar een junk dimension.