Waarom niet enkel Type 2?

Bij een Slowly Changing Dimension scenario wordt normaliter per veld bepaald of het een type 1, type 2 of type 3 veld betreft. Bij een type 1 wordt het record overschreven met de nieuwe waarde, bij een type 2 wordt er een nieuw record aangemaakt en bij een type 3 wordt de oude waarde als een extra kolom bewaard in de dimensie. Waarom zou je echter niet alles als type 2 behandelen?

Benadering als type 2
Alle mutaties die impact hebben op de dimensie worden behandeld als een type 2 wijziging. Om tegemoet te komen aan alle mogelijke rapportage-eisen biedt deze benadering veel voordelen. Door alle mutaties te behandelen als een type 2 kun je namelijk alles eenvoudig terugvinden en blijft de volledige historie beschikbaar.

In de dimensie worden een paar extra metavelden opgenomen om tegemoet te komen aan de rapportage-eisen:

• MetaPreviousID
• MetaNextID
• MetaCurrentID

Om bovenstaande te verduidelijken het onderstaande voorbeeld:

CompanyID	CompanyCode	Naam	Adres	MetaPreviousID	MetaNextID	MetaCurrentID	MetaStartDate	MetaEndDate	IsCurrent
1	100	KPN	AAA	1	2	3	2009-01-01	2009-01-05	0
2	100	KPN	BBB	1	3	3	2009-01-06	2009-01-12	0
3	100	KPN	CCC	2		3	2009-01-13	9999-12-31	1

Voor Company met code 100 zijn er door de tijd mutaties uitgevoerd op het adres. Het gevolg is geweest dat er twee nieuwe records zijn aangemaakt. Bij het bijwerken van de dimensie worden de previousid, nextid en currentid bijgewerkt. Door dit bij te houden kan op ieder gewenst moment de nieuwste versie van een record worden teruggevonden.

{module Easy Adsense Content}

Stel dat er een feit-record wordt aangemaakt op 2 januari 2009. Het bijhorende dimensierecord is het record met ID = 1. Het feit wordt nu gevuld met ID = 1 zodat er een relatie ontstaat tussen het feit en de dimensie. Wellicht is men in de rapportage helemaal niet geïnteresseerd in het oude adres “AAA” van deze Company. Normaal gesproken zou dit veld een Type 1 veld zijn waardoor steeds het adres wordt overschreven en het huidige adres wordt gerapporteerd. Dit vangen we nu op door een recursieve join te leggen op de dimensie. Met behulp van de MetaCurrentID kan eenvoudig de Actieve dimensie-rij worden teruggevonden. De SQL zou er ongeveer zo uitzien:

{geshi xml:lang=”tsql” lines=”false”}
SELECT    DC.Adres AS  ToenGeldigeAdres,
DC2.Adres AS CurrentAdres,
DC3.Adres AS VorigeAdres
FROM FactVerkopen AS FV
INNER JOIN DimCompany AS DC ON FV.CompanyID = DC.CompanyID
INNER JOIN DimCompany AS DC2 ON DC.MetaCurrentID = DC2.CompanyID
INNER JOIN DimCompany AS DC3 ON DC.MetaPreviousID = DC3.CompanyID{/geshi}

Zoals je ziet biedt dit alle mogelijke combinaties. Je kunt het adres achterhalen welke geldig was op het moment dat het feit binnenkwam, het huidige adres en het vorige adres (type 3).

Waarschijnlijk gebruiken de meeste mensen een Datamart bovenop het Datawarehouse die enkel de data bevat die interessant is om te rapporteren. De input voor de ETL om de Datamarts te vullen zijn waarschijnlijk Views. De views die als input dienen voor je Datamart bouw je op zo’n manier dat je enkel de informatie aanbiedt die interessant is voor de eindgebruiker. In bovenstaand voorbeeld zul je, indien de gebruikers niet geïnteresseerd zijn in de oude adres van de company, enkel de CurrentID tonen!

Voordelen:

• Volledige historie beschikbaar van een record
• Eenvoudige ETL, enkel inserts
• Nog niet na hoeven denken over history bij ETL-ontwikkeling, dit komt later
• Type 1, 2 en 3 ondersteuning
• Wat is mijn huidig geldige dimensierecord
• Wat was mijn vorige geldige dimensierecord
• Wat is mijn volgende geldige dimensierecord

Nadelen

• Extra opslag
• Extra join om current of previous te achterhalen
• CurrentID, NextID moet iedere keer worden bijgewerkt.

De voordelen wegen zwaarder dan de nadelen. Door een geclusterde index te gebruiken op de surrogatkey kunnen de joins snel worden gemaakt en kunnen de oude type 2 records snel worden bijgewerkt (bijvoorbeeld het updaten van de currentID).

 

Graag uw commentaar

{module Easy Adsense Content}