Válasszon a lassan változó dimenziótípusok közül
A csillagséma-tervezés elmélete a gyakori SCD-típusokra utal. A leggyakoribbak az 1. és a 2. típus. A gyakorlatban a dimenziótáblák támogathatják az előzménykövetési módszerek kombinációját, például a 3. és a 6. típust. Ismerkedjünk meg az SCD-típusok különbségével.
1. típus SCD
Az 1. típusú SCD mindig a legújabb értékeket tükrözi, és a forrásadatok változásainak észlelésekor a dimenziótábla adatai felülíródnak. Ez a kialakítási módszer gyakori az olyan oszlopok esetében, amelyek kiegészítő értékeket tárolnak, például egy ügyfél e-mail-címét vagy telefonszámát. Amikor egy ügyfél e-mail-címe vagy telefonszáma megváltozik, a dimenziótábla frissíti az ügyfélsort az új értékekkel. Ez olyan, mintha az ügyfél mindig ezeket a kapcsolattartási adatokat. A kulcsmező( például a CustomerID) változatlan marad, így a ténytáblában lévő rekordok automatikusan hivatkoznak a frissített ügyfélrekordra.
2. típus SCD
A 2. típusú SCD támogatja a dimenziótagok verziószámozását. A forrásrendszer gyakran nem tárolja a verziókat, ezért az adattárház betöltési folyamata észleli és kezeli a dimenziótáblák változásait. Ebben az esetben a dimenziótáblának helyettesítő kulccsal kell megadnia a dimenziótag egy verziójára mutató egyedi hivatkozást. Olyan oszlopokat is tartalmaz, StartDate amelyek meghatározzák a verzió dátumtartományának érvényességét (például és EndDate) és esetleg egy jelzőoszlopot (például IsCurrent) a jelenlegi dimenziótagok egyszerű szűréséhez.
Az Adventure Works például értékesítőket rendel egy értékesítési régióhoz. Amikor egy értékesítő áthelyezi a régiót, létre kell hozni az értékesítő új verzióját annak érdekében, hogy a korábbi adatok továbbra is a korábbi régióhoz legyenek társítva. Az értékesítők által történő értékesítések pontos múltbeli elemzésének támogatásához a dimenziótáblának tárolnia kell az értékesítők és a hozzájuk tartozó régió(k) verzióit. A táblának tartalmaznia kell a kezdő és a záró dátum értékeit is az idő érvényességének meghatározásához. Az aktuális verziók üres befejezési dátumot (vagy 9999. 12. 31.) határozhatnak meg, ami azt jelzi, hogy a sor az aktuális verzió. A táblának helyettesítő kulcsot is meg kell határoznia, mert az üzleti kulcs (ebben az esetben az alkalmazott azonosítója) nem lesz egyedi.
Fontos tisztában lenni azzal, hogy ha a forrásadatok nem tárolnak verziókat, köztes rendszert (például adattárházat) kell használnia a változások észleléséhez és tárolásához. A táblabetöltési folyamatnak meg kell őriznie a meglévő adatokat, és észlelnie kell a módosításokat. Ha változás észlelhető, a táblabetöltési folyamatnak le kell járnia az aktuális verziót. Ezeket a módosításokat úgy rögzíti, hogy frissíti az EndDate értéket, és beszúr egy új verziót az StartDate előző EndDate értékből kiinduló értékkel. Emellett a kapcsolódó tényeknek időalapú kereséssel kell lekérniük a ténydátum szempontjából releváns dimenziókulcs-értéket.
Típus 3 SCD
A 3. típusú SCD támogatja a dimenziótagok két verziójának külön oszlopként való tárolását. A táblázat tartalmaz egy oszlopot egy tag aktuális értékéhez, valamint a tag eredeti vagy korábbi értékéhez. A 3. típus tehát további oszlopokat használ az előzmények egy kulcspéldányának nyomon követéséhez, ahelyett, hogy további sorokat tárol az egyes változások nyomon követéséhez, például egy 2. típusú SCD-ben.
Ez a nyomkövetési típus egy dimenziótábla egy vagy két oszlopához használható. Nem gyakori, hogy ugyanazt a táblát sokan használják. Gyakran használják az 1. vagy a 2. típustagokkal együtt.
Típus 6 SCD
A 6. típusú SCD az 1., a 2. és a 3. típust egyesíti. Amikor változás történik egy 2. típusú taggal, létre kell hoznia egy új sort a megfelelő StartDate és EndDate értékekkel. A 6. típusú kialakításban az aktuális értéket az entitás összes verziójában is tárolhatja, így könnyen jelentést készíthet az aktuális értékről vagy az előzményértékről.
Az értékesítési régió példáját használva felosztja a Régió oszlopot a következőre CurrentRegionHistoricalRegion: A CurrentRegion mindig a legújabb értéket jeleníti meg, a HistoricalRegion régió pedig az és EndDatea között érvényes régiótStartDate. Így ugyanahhoz az értékesítőhöz minden rekordban CurrentRegion a legújabb régió lenne kitöltve, miközben HistoricalRegion pontosan úgy működik, mint a 2. típusú SCD-példában szereplő régió mező.
