Informationsarkitektens bokhylla – del 9: Den bästa boken om dimensionsmodellering
Dimensionsmodellering är en viktig modelleringsteknik, för syftet att presentera data för analys och rapportering. Bästa guiden till ämnet är Ralph Kimballs bok, The Data Warehouse Toolkit – The Definitive Guide to Dimensional Modeling.
/Peter Tallungs, IRM 2023-08-24
Data Warehouse kräver mer än normaliserade modeller
De flesta lite större organisationer har ett Data Warehouse (svenska: Datalager). Det är en databas som samlar data för analys och rapportering. Där integrerar man data från olika källor, både historiska och aktuella data, och exponerar dessa i ett format som passar användare som gör rapporter och analyser. Då behöver vi ett annat dataformat än det som vi är vana vid i våra normaliserade modeller.
Två typer av it-applikationer
Datastrukturerna skiljer sig sålunda från de som gäller för våra vanliga operativa it-applikationer. Skillnaden grundar sig på att dataposter i ett Data Warehouse uppdateras och används i ett helt annat mönster.
Vi har vanligen två skilda typer av it-applikationer i en och samma verksamhet. Vi har de vanliga operativa systemen, det vill säga de vi använder när vi opererar den dagliga verksamheten. Där registrerar vi, ändrar, läser eller raderar en eller några få poster åt gången. Det kan vara kunder, offerter, ordrar eller allt annat som vår verksamhet hanterar. Vi gör en sådan transaktion åt gången. Vi kallar en sådan datahantering transaktionell.
Sedan har vi ofta en eller flera centrala it-applikationer avsedda för analys och rapportering. De är inte till för att operera verksamheten, det vill säga att där sker inte den dagliga registreringen av vad som händer. Där betraktar och analyserar vi i efterhand vad som hänt i stort. Till exempel hur försäljningen har förändrats över tid för olika produkt- och kundsegment.
Vanligen kallas hjärtat i den typen av systemlösningar för Data Warehouse. Det är en databas där vi samlar data från olika källor, dels de operativa systemen men ofta även referensdata från externa källor. Namnet Data Warehouse syftar på att det kan ses som ett lager av data för olika ändamål. Ofta kallas den typen av databehandling som det handlar om för Business Intelligence eller Decision Support (Beslutstöd).
I dessa sammanhang ser datahanteringen helt annorlunda ut än i de operativa systemen. Vi uppdaterar hela datamängden kanske en gång per dygn genom att vi laddar in data från de operativa applikationerna. Innehållet är sedan fryst till nästa uppdatering. Detta för att alla analyser och rapporter som görs under en dag ska grunda sig på exakt samma data, så att resultatet blir konsistent. Det innebär att vi som användare av dessa lösningar aldrig uppdaterar något utan bara läser data. Och då vanligen stora datamängder på en gång som vi enkelt vill kunna vända och vrida på för att analysera och förstå trender och samband.
Informationsmodellering i samband med ett Data Warehouse
Du kanske har samma bakgrund som jag gällande modellering av vanliga transaktionella system. Att då komma till Data Warehouse/Business Intelligence-utveckling är som att komma till en uppochnervänd värld.
Vi är vana vid att våra modeller ska vara normaliserade. Det gäller för de fysiska strukturerna i våra operativa applikationer och samma gäller för de konceptuella modeller vi gör för informationen i en verksamhet i stort. Det är själva grunden för hur vi gör våra modeller. Vi ser det som det naturliga sättet att betrakta företeelserna som hanteras i en verksamhet. Tydligt och naturligt. Ingen redundans. Allt ska finnas endast en gång, och där det naturligt hör hemma.
En konceptuell modell skiljer sig därmed inte så mycket från en fysisk, till sin grundläggande struktur. Fast detta gäller bara då det gäller transaktionssystem, som vi snart ska se. Ty i Data Warehouse-världen är det annorlunda.
Den konceptuella modellen är fortfarande normaliserad och i grunden samma som för de operativa systemen, i den mån handlar om samma data. Ty det är fortfarande ett mer naturligt sätt att betrakta information. Men den fysiska modellen är helt annorlunda, den är inte alls normaliserad. Det beror på att redundans inte är ett problem, eftersom ingen uppdatering av inladdat data ska ske. I stället är det viktigt att ha en struktur som gör det enkelt för användaren att vända och vrida på fakta, summera, borra sig ner, aggregera och jämföra. Och då är en annan struktur mer användbar.
Dimensionsmodellering
Det vanligaste och mest grundläggande sättet att modellera ett Data Warehouse är dimensionsmodellering. En sådan modell strukturerar data i ett antal så kallade stjärnor (Star Schemas), med en faktatabell i mitten som refererar till ett antal så kallade dimensionstabeller. Varje faktatabell innehåller fakta av en viss typ, det vill säga händelser i verksamheten som man håller reda på, som att en artikel såldes vid ett visst tillfälle eller att en student deltog på ett lektionstillfälle. Varje dimensionstabell håller reda på en viss dimension, det vill säga uppräknade värden för ett visst sätt att kategorisera fakta. Som alla tidpunkter på ett dygn, alla datum på ett år, alla kunder, alla produkter, alla kurstillfällen eller alla elever.
Andra ansatser
Det finns alternativ, eller snarare komplement, till dimensionsmodellering. Vanligaste är modelleringstekniken Data Vault, utvecklat av svensk-amerikanen Dan Lindstedt. Data Vault är ett tillvägagångsätt där man bygger upp strukturen ganska så mekaniskt efter ett antal regler. Detta utan att man behöver ta lika mycket hänsyn till hur data skall användas. Priset är dock att datastrukturen blir mycket mer komplicerad. Antalet tabeller att hantera växer kraftigt.
I de projekt jag deltagit i har vi kombinerat modelleringsansatserna på följande sätt. Först har vi gjort en konceptuell modell som varit normaliserad, och på formen av vad jag vill kalla en rik informationsmodell. Där har vi beskrivit all data som vi vill se, med normerade verksamhetstermer, definitioner och regler både i grafik och text. Den har blivit en manifestering av vår gemensamma förståelse av verksamhetens operativa logik i form av begrepp, benämningar, information och regler. Sedan har vi utifrån detta skapat dimensionsmodeller för hur data ska presenteras för användarna av vårt DW. I de fall där vi tycker att det haft en fördel har vi använt mönster hämtade från Data Vault. (När jag skriver ”först” och ”sedan”, menar jag det i bildlig mening. Arbetet har förstås varit iterativt, där modellerna har utvecklats kontinuerligt i takt med att vår gemensamma förståelse har vuxit.)
Då det gäller Data Warehouse-arkitektur i stort finns det många nya ansatser som helt eller delvis har gått vidare från idén om ett centralt Data Warehouse för en verksamhet. Vi har Data Lakes för lagring av ostrukturerat data. Vi har Data Mesh, Data Product och Data Fabrics som alla är idéer om ett mer decentraliserat ansvar för data, närmare källorna. Men detta förtar inte på något sätt värdet av dimensionsmodellering anser jag. Kunskapen om dimensionsmodellering är fortsatt en grund för hur data ska presenteras för analys och rapportering.
Ralph Kimball
Den som utvecklat dimensionsmodellering som metod är främst amerikanen Ralph Kimball. Efter en lång karriär (doktorerade på Stanford 1973, jobbade på det berömda Xerox Parc-labbet i Palo Alto, hade ledande positioner på företag som utvecklade användargränssnitt) kom han i början av åttiotalet av en slump att arbeta med relationsdatabaser hos Informix. Tio år senare, när vi kommer in på nittiotalet, börjar han konsulta och undervisa inom Data Warehouse-området. Mellan 1996 och 2013 har han tillsammans med olika medförfattare kommit ut med åtta böcker om Data Warehouse-design.
The Data Warehouse Toolkit
Den bok som tydligast och mest fullständigt beskriver dimensionsmodellering är The Data Warehouse Toolkit med undertiteln The Definite Guide to Dimensional Modeling som han skrivit tillsammans med Margy Ross. Boken är från 1996 och kom med sin tredje och senaste upplaga 2013.
Den ska inte förväxlas med andra böcker av honom med snarlika titlar som The Data Warehouse ETL Toolkit eller The Data Warehouse Lifecycle Toolkit. Dessa är mer inriktade på andra ämnen inom Data Warehouse-design.
Bokens innehåll
Chapter 1: Data Warehousing, Business Intelligence and Dimensional Modeling Primer
Här förklaras grunderna för DW/BI och dimensionsmodellering.
Chapter 2: Kimball Dimensional Modeling Techniques Overview
En översikt över alla enskilda modellmönster som ingår i dimensionsmodellering med referenser till var i boken de behandlas.
Större delen av den resterande boken, kapitel 3 till 16 beskriver dessa mönster från de mest basala till de mest avancerade, och det görs genom konkreta exempel från olika branscher.
Dessa kapitel är benämnda utifrån branscher eller verksamhetsområden. Vart och ett visar på exempel på modeller från just den typen av verksamhet. Samtidigt illustrerar dessa exempelmodeller vanliga modellmönster tillämpliga i alla branscher, från de mest grundläggande till de mest avancerade alltefter hur boken fortskrider. Utöver själva modelleringen tas frågor upp om DW-arkitektur och metodik. Du bör läsa kapitlen i ordning, åtminstone första gången.
Chapter 3. Retail Sales
Beskriver arbetssättet och de mest grundläggande modellmönstren, genom exempel från detaljhandel. Arbetssättet är de fyra stegen för att designa en stjärna: Välj verksamhetsprocess, bestäm finkornigheten, identifiera dimensionerna och identifiera fakta.
Arbetssättet beskrivs från grunden, både med praktiska exempel och teori, hur man tänker när man designar fakta- och dimensionstabeller, och förklarar grundläggande mönster som härledda fakta, icke-additiva fakta, vad en datumdimension är med aktuella och relativa datum, flaggor/indikatorer, hur man hanterar tid på dagen, tillplattade många-till-en-hierarkier, degenererade dimensioner, faktalösa faktatabeller, hur man designar nycklar, både naturliga nycklar och surrogatnycklar.
Man får också läsa om mer normaliserade dimensionsmodeller så kallade Snowflake Schemas som är något Kimball avråder från, samt så kallade utriggare och hur man undviker tusenfotingar, de vill säga överdrivet många dimensioner i en och samma stjärna.
Chapter 4: Inventory
Beskriver hur man kan ta fram en modell för en hel värdekedja, med exempel från lagerhantering. Varje steg i värdekedjan från tillverkningsorder, mottagning i lagret, inventering och leverans från lagret är händelser som var och en blir en egen faktatabell som får en egen stjärna. Man introducerar mönster som periodiska snapshots, semiadditiva fakta, samt ackumulerade snapshots.
Här beskrivs hur man med hjälp av alla gemensamma eller i varje fall konforma dimensioner kan integrera alla stjärnorna för en värdekedja till en gemensam modell. Detta blir fröet till det Kimball kallar för Enterprise Data Warehouse Bus Architecture och som är centralt för hur man utveckla Business Intelligence för en verksamhet bit för bit, med olika tekniker, av olika team och med olika prioriteringar och ändå få allt att hänga ihop.
Kapitlet behandlar vidare olika typer av konformitet mellan dimensioner och även konformitet mellan fakta.
Vi får också läsa om kopplingen till Datastyrning (Data Governance) och Förvaltningsansvar för data (Data Stewardship) samt hur man kan och bör arbeta med agila arbetssätt när man bygger Data Warehouse.
Chapter 5: Procurement
Ger ledning i den viktiga frågan om hur man kan väga mellan att ha en eller flera faktatabeller för det som i verksamheten är en och samma transaktion, fast data kommer från olika källsystem. Exempel som används är från inköpsverksamhet.
Här introducerar författarna det som är centrala mönster för att hantera en föränderlig verklighet, det vill säga att dimensioner behöver förändras med tiden. Det är en serie mönster som kallas kallas Slowly Changing Dimensions (SLCD) som går från det enklaste SLCD 0 (Ändra inte!) till det mest avancerade SLCD 7 (Håll både gamla och nya versioner av dimensioner parallellt!). Man tar även upp det som kallas Minidimensioner.
Chapter 6: Order Management
Här möter vi det som kallas Dimensional role playing, hur man kan behöva fler kopior av en och samma dimensionstabell. Det händer då en och samma dimensionstabell behöver representera fler än en dimension i en och samma stjärna, till exempel det vanliga fallet då vi har två olika datum att hålla reda på för samma fakta. Författarna använder exempel från orderhantering.
Här beskrivs också hur man hanterar speciella fall av dimensioner med en så kallade Junk dimension. Intressant ur Data Management-perspektiv är också det som kallas Audit Dimension, en speciell dimension för metadata.
Chapter 7: Accounting
Med hjälp av exempel från bokföringsdata får vi se hur man hanterar det som alltid är knepigt i informationsmodellering, hierarkier med variabla djup. Vi gör det med hjälp av bland annat så kallade bridge tables.
Chapter 8: Customer Relationship Management
Vi får möta hur man kan hantera namn och adresser samt kundsegmentering.
Chapter 9: Human Resource management
Nu är vi mogna för några mer avancerade exempel på modeller, denna gång med från personalhantering.
Chapter 10: Financial Services
Med exempel från finansverksamhet diskuterar författarna om hur man balanserar antalet dimensioner så det varken är onödigt många eller ett litet antal som då var och en blir onödigt komplicerade.
Chapter 11: Telecommunications
Här ges råd om hur man genomför en designgranskning av en modell (Design Review)
Chapter 12: Transportation
Här tar man upp hur man kan hantera en situation där man har fakta om samma typ av händelser fast från olika källor men där fakta har olika granularitet. Samt hur man hanterar en situation där man har datum och tid från olika tidszoner. Exemplen kommer från transportbranschen.
Chapter 13: Education
Mer om ackumulerade snapshots och faktalösa faktatabeller. Samt det speciella men vanliga problemet att hålla räkning på att en viss typ av händelse inte har inträffat. Exempel från utbildningsverksamhet.
Chapter 14: Healthcare
Här visas hur man kan hantera det som är vanligt inom sjukvården, dimensioner med ett mycket stort antal värden.
Chapter 15: Electronic Commerce
Här visas hur man tar hand om de klickströmmar som representerar kunders beteende på en webbplats.
Chapter 16: Insurance
Författarna delger en lista med vanliga misstag då det gäller dimensionsmodellering och hur man undviker dem.
Chapter 17: Kimball DW/BI Lifecycle Overview
Handlar inte specifikt om modellering utan ger en översikt över Kimballs metodik för arbetet runt Data Warehouse som helhet. Det är något som beskrivs närmare i hans andra böcker.
Chapter 18: Dimensional Modeling Process and tasks
Här beskrivs arbetssättet för dimensionsmodellering, det vill säga hur man kan gå till väga och vilka arbets-stegen är.
Chapter 19: ETL Subsystems and Techniques
Beskriver ETL-systemet för ett Data Warehouse. ETL står för Extract, Transform, Load, det vill säga det hela system som utför den dagliga processen att extrahera data från källsystem, transformera dessa för att passa in i den struktur som du har i ditt Data Warehouse samt ladda in det.
Chapter 20: ETL System Design and Development Process and Tasks
Beskriver hur processen för att utveckla sitt ETL-system kan gå till.
Chapter 21: Big data Analytics
Här beskrivs hur man kan hantera det som kallas ”Big Data” det vill säga ostrukturerat rådata ofta infångat från maskiner eller sensorer av olika slag.
Varför ska jag läsa boken?
För att den beskriver en viktig modelleringsteknik, grunden för all modellering då det gäller DW/BI, pedagogisk och uttömmande, med många praktiska exempel från olika områden.
Det är den bästa boken om dimensionsmodellering som jag ser det. Det var min ingång till området samtidigt som jag fick stöd av mer erfarna kollegor. Jag har många gånger återvänt till de olika kapitlen och därigenom fått ledning till hur jag skulle tänka om och lösa ett specifikt modelleringsproblem. Boken är intressant också för den som endast gör normaliserade modeller. Många mönster är användbara även där. Inte minst får man en nyttig distans till det vanliga sättet att modellera.
