364
UTFORSKA vad vi kan och gör
UTFORSKA vad vi kan och gör

Stäng

Kompetensområden

Kontakta mig

Vill du veta mer och ta reda på hur vi kan hjälpa just dig? Lämna dina kontaktuppgifter

Valdation:
* Förnamn:
* Efternamn:
Företag:
Tel:
* Email:
Land:
* Meddelande:
Successfully sent!
Could not send the mail, try again later!
KAFFE ELLER TÉ? Vi kan väl ses över en kopp.

Blogg maj 25, 2016

Därför ogillar jag SCD2

När man bygger ett datalager måste man ta ett designmässigt beslut gällande hur dimensionerna ska byggas upp. Hur ska man hantera det som kallas Slowly Changing Dimensions (SCD), det vill säga att dimensionsmedlemmar förändras över tid: kunder flyttar, leverantörer blir uppköpta och produkter klassas om?

BI-gurun Ralph Kimball beskriver i sin bok ”The Data Warehouse Toolkit” åtta olika SCD-varianter. De två vanligaste är SCD1, att man helt enkelt skriver över värden när de ändras och SCD2, att man skapar en ny rad vid förändringar. Förutom att det finns många olika varianter kan man dessutom välja att hantera olika attribut på olika sätt, till exempel kanske namnet är SCD1 och status är SCD2.

Rätt implementerad SCD-hantering är väldigt kraftfull och tillför ofta information som inte längre kan fås fram från källsystemen. Men det finns en hel del problem och svårigheter att ta hänsyn till. 

Svårt att implementera/svårt att förstå

Det är ofta svårt att fråga slutanvändarna hur de vill att lösningen ska se ut eftersom att de har svårt att visualisera hur det kommer att bli och att förutse vilka implikationer olika beslut får för lösningen. Beskriver man SCD2 kan man ofta hamna i att de vill att allt ska SCD2-hanteras och det är sällan en bra lösning. 

Ju mer komplex lösning man har desto svårare blir det både att utveckla och underhålla, samt att förstå för slutanvändarna. Min erfarenhet är att de flesta buggar som uppstår i BI-lösningar beror på felaktig SCD-implementering, och då särskilt om man försöker sig på komplexa varianter.

När sker ändringen?

Även de bästa källsystem har datakvalitetsbrister, och det är väldigt svårt för ett BI-system att veta om en förändring i datat beror på att man har rättat data som tidigare varit felaktigt eller om det är en faktisk förändring. Oavsett om kunden flyttade till en ny stad eller om den första informationen var felaktig/felstavad så kommer detta att resultera i att en ny rad skapas.

Även när en förändring är korrekt är det inte helt självklart att man vet när den inträffade. Om inte källan kan skicka med information om när det nya värdet ska gälla ifrån används ofta inladdningsdatum. Om vi till exempel vill följa försäljning baserat på kundansvarig, och kundansvarig är ett attribut på kunden och något som förändras över tiden, så måste källan först uppdateras och sedan slår ändringen igenom vid nästa inläsning till datalagret. Ofta laddar man bara om datalagret varje natt, vilket innebär en viss tidsförskjutning. Och dessutom kan man nästan utgå från att förändringen inte gjordes i källan exakt i samma sekund som användarna vill att förändringen ska ske. Ofta är det så att det är först när de tittar på sina rapporter som de ser att något är felklassificerat och rättar till det i källan.

Men även om källan kan skicka med ett datum för när förändringen ska börja gälla uppstår problem. Om förändringen inträffade vid en tidpunkt som redan har passerats måste inte bara dimensionen uppdateras, utan även all fakta som är kopplad till den dimensionen. Är tidpunkten långt tillbaka i tiden kan det här innebära att väldigt mycket data måste laddas om. Och här återkommer vi till att det både är svårt att implementera och svårt att förstå.

Att använda rätt dimensionsmedlem

Även när alla förändringar är korrekta och inte beror på bristande datakvalitet och att det tydligt framgår när de börjar gälla finns det svårigheter.

Anta att vi har ett attribut ”status” på kunden och att detta SCD2-hanteras, och att vi sedan också har en faktatabell som anger kundaktiveringar/inaktiveringar. Ska faktaraden som anger att en kund har inaktiverats kopplas till dimensionsraden med status ”aktiv” eller ”inaktiv”? Stämmer tidsstämpeln för faktaraden med tidsstämpel för dimensionsförändringen?

Ibland kanske inte faktat har något klockslag, till exempel kanske det bara finns fakturadatum, ska man då välja den första dimensionsmedlemmen denna dag eller den sista?

Anta att man följer upp försäljning på konsult per kostnadsställe och att konsulterna ofta byter kostnadsställe. Kanske har man en rapport som visar en rad per konsult och kostnadsställe, och då är det rimligt att man väljer det kostnadsställe som var giltigt i slutet av månaden. Om man sen tittar på data på dagsnivå och summerar upp till månad kommer man att få en annan fördelning, vilket kan vara svårt att förstå. Lägg sedan även till svårigheten med att veta när förändringen skedde och ska slå igenom.

Jag säger inte att man aldrig ska använda SCD2 (eller andra ännu mer komplexa SCD-varianter), men jag tycker verkligen att man ska reflektera över var och när det behövs. Har man historiktabeller som visar allt som har lästs in från källsystemen kan dessa kanske inte användas i rapportering, men de finns tillgängliga för att felsöka och förklara förändringar som har skett.

Veronika Mattsson, Business Intelligence Consultant, Enfo

Läs även min namne, Veronika Astervalls blogginlägg som också handlar om SCD: http://www.enfo.se/Articles/Blog-Posts/Svenska/Fatta-ratt-beslut-om-historik-for-att-arbeta-effektivt-med-framtida-beslutsfattande