Volba mezi pomalu se měnícími typy dimenzí
Teorie návrhu hvězdicového schématu odkazuje na běžné typy SCD. Nejběžnější jsou typ 1 a typ 2. V praxi může tabulka dimenzí podporovat kombinaci metod sledování historie, včetně typu 3 a typu 6. Pojďme se seznámit s rozdílem v těchto typech SCD.
Typ 1 – SCD
ScD typu 1 vždy odráží nejnovější hodnoty a při zjištění změn zdrojových dat se přepíšou data tabulky dimenzí. Tento přístup k návrhu je běžný u sloupců, které ukládají doplňkové hodnoty, například e-mailovou adresu nebo telefonní číslo zákazníka. Když se změní e-mailová adresa zákazníka nebo telefonní číslo, tabulka dimenzí aktualizuje řádek zákazníka o nové hodnoty. Je to jako by zákazník měl vždy tyto kontaktní informace. Klíčové pole, například CustomerID, by zůstalo stejné, takže záznamy v tabulce faktů se automaticky propojí s aktualizovaným záznamem zákazníka.
Typ 2 – SCD
ScD typu 2 podporuje správu verzí členů dimenze. Zdrojový systém často neukládá verze, takže proces načítání datového skladu detekuje a spravuje změny v tabulce dimenzí. V tomto případě musí tabulka dimenzí použít náhradní klíč k poskytnutí jedinečného odkazu na verzi člena dimenze. Obsahuje také sloupce, které definují platnost rozsahu dat verze (například StartDate
a EndDate
) a případně sloupec příznaku (například IsCurrent
) pro snadné filtrování podle aktuálních členů dimenze.
Například Adventure Works přiřazuje prodejcům prodejní oblast. Když prodejce přemístí oblast, musí být vytvořena nová verze prodejce, aby se zajistilo, že historická fakta zůstanou přidružená k bývalé oblasti. Aby byla podpora přesné historické analýzy prodeje podle prodejce, musí tabulka dimenzí ukládat verze prodejců a jejich přidružených oblastí. Tabulka by také měla obsahovat hodnoty počátečního a koncového data pro definování doby platnosti. Aktuální verze můžou definovat prázdné koncové datum (nebo 12. 31. 9999), které označuje, že řádek je aktuální verzí. Tabulka musí také definovat náhradní klíč, protože obchodní klíč (v tomto případě ID zaměstnance) nebude jedinečný.
Je důležité vědět, že pokud zdrojová data neukládají verze, musíte k detekci a uložení změn použít zprostředkující systém (například datový sklad). Proces načtení tabulky musí zachovat existující data a detekovat změny. Po zjištění změny musí proces načtení tabulky vypršet aktuální verzi. Tyto změny zaznamenává aktualizací EndDate
hodnoty a vložením nové verze s StartDate
hodnotou začínající od předchozí EndDate
hodnoty. Související fakta také musí použít vyhledávání založené na čase k načtení hodnoty klíče dimenze relevantní pro datum faktu.
Typ 3 – SCD
ScD typu 3 podporuje ukládání dvou verzí členu dimenze jako samostatných sloupců. Tabulka obsahuje sloupec pro aktuální hodnotu člena a původní nebo předchozí hodnotu člena. Proto type 3 používá další sloupce ke sledování jedné klíčové instance historie, místo ukládání dalších řádků ke sledování každé změny, jako je scD typu 2.
Tento typ sledování lze použít pro jeden nebo dva sloupce v tabulce dimenzí. Není běžné ji používat pro mnoho členů stejné tabulky. Často se používá v kombinaci s členy Typu 1 nebo Type 2.
Typ 6 – SCD
ScD typu 6 kombinuje typ 1, 2 a 3. Když dojde ke změně člena typu 2, vytvoříte nový řádek s odpovídajícím startDate a EndDate. V návrhu typu 6 uložíte aktuální hodnotu také ve všech verzích této entity, abyste mohli snadno vykazovat aktuální hodnotu nebo historickou hodnotu.
Pomocí příkladu prodejní oblasti rozdělíte sloupec Region do CurrentRegion
a HistoricalRegion
. Vždy CurrentRegion
zobrazí nejnovější hodnotu a HistoricalRegion
zobrazí oblast, která byla platná mezi a StartDate
EndDate
. U stejného prodejce by tedy každý záznam měl vyplněnou nejnovější oblast CurrentRegion
, zatímco HistoricalRegion
v příkladu SCD typu 2 funguje přesně stejně jako pole oblasti.