Free Press

Dimensionell modellering (DM) är en del av Business Dimensional Lifecycle-metodologin som utvecklats av Ralph Kimball och som innehåller en uppsättning metoder, tekniker och begrepp som kan användas vid utformning av datalager. Metoden fokuserar på att identifiera de viktigaste affärsprocesserna inom en verksamhet och modellera och implementera dessa först innan man lägger till ytterligare affärsprocesser, en bottom-up-metod.

Vad är målen för modellering av datalager?

De mål som Ross och Kimball fastställer är enkla:

• Göra information lättillgänglig
• Presentera information på ett konsekvent sätt
• Anpassningsbar och mottaglig för förändringar
• Presentera information i rätt tid
• Skydda informationstillgångar

.

• fungera som en auktoritativ och pålitlig grund för förbättrat beslutsfattande (en enda sanningskälla på datateknikspråk)
• VIP:erna måste acceptera ditt system

Om du har arbetat med eller använt ett ETL-system, har du säkert lagt märke till att informationskonsistens uppnås med hjälp av överensstämmande åtgärder, att tidsenlighet tillhandahålls av ETL-cykler och att anpassningsförmågan också till stor del beror på ETL-utformningen.

Varför modellering?

Som dataingenjör känner du till SQL mycket väl och kan förmodligen skriva SQL-förfrågningar för hela dagen. Men du kan inte anta att den typiska slutanvändaren är expert på att skriva SQL-förfrågningar. Så vårt mål är att bygga en DW så lätt för analytiker att skriva analysfrågor snabbt och effektivt.

Saker som du inte vill att dina analytiker ska göra:

• Förfrågningar baserade på ID
• Kascading outer joins(inte ens du vill göra det)
• Grupperade eller sammanfogade multipla delförfrågningar
• Rekursiva delförfrågningar(besök bara Hackerrank SQL så förstår du hur jobbigt det är)
• Subquery correlation: Hämta data över flera kolumner i olika underfrågor
• Joins utan PK/FK: även för mig(1.5 års erfarenhet av DE) är det svårt att visualisera.

Saker som du kan och bör förvänta dig av dina analytiker:

• Enkla föreningar
• kolumner med namn och omfattande text
• Enkla aggregeringar
• analytiska fönsterfunktioner
• DISTINCT

Anmärkningar: Ovanstående punkter är inte enkla och ditt system bör vara tillräckligt skalbart för alla dessa typer av förfrågningar.

OLTP-databaserna omvandlas till fakta och dimensioner på grund av de ovan nämnda målen.

Övergången från transaktionsdatabaser till fakta

De flesta företag mäter sin framgång och effektivitet genom att mäta vissa typer av data. Dessa data fångar verkliga affärsverksamheter och framsteg. Dessa data kallas för fakta.

De OLTP-orienterade databaserna registrerar transaktioner i taget, ungefär som event streaming men centraliserat kring transaktioner. DW är annorlunda. DW behöver inte registrera detaljer på transaktionsnivå. DW behöver ha fakta över olika kriterier för din verksamhet. DW måste sammanställa (eller låta analytiker sammanställa) den information som behövs för att förbättra verksamheten. Därför är redundans en oförlåtlig synd i DW.

Vad är åtgärder och varför ska du fylla dina faktatabeller med dem?

I ett datalager är en åtgärd en egenskap som det går att göra beräkningar på.

De fakta som vi hämtar från de operativa datalagren kommer med en del ytterligare data som vanligtvis summeras i vår analys. Dessa är de aspekter av ett faktum som gör det möjligt för analytikern, eller den chef som tittar på analysen, att se värdet i fakta.

Varför måste du upprätthålla ett konsekvent korn?

För att du ska kunna se till att ditt system på ett legitimt sätt kan korrelera och aggregera över fakta.

Men det är inte alltid möjligt att ha data på atomära nivåer. Så för att överbrygga detta gap finns det två metoder:

• Periodic Snapshot Fact Tables
• Accumulating Snapshot Fact Tables

Periodic Snapshot Fact Tables

Som namnet antyder samlas de in med jämna tidsintervall. Gasförbrukning, revision och inspektioner är några exempel på datainsamling som har periodiska ögonblicksbilder aktiverade för dem.

Ackumulerande ögonblicksbildsfakta tabeller

När en indikator för affärsprestationer är en hastighet för att slutföra en affärsprocess i flera steg, kanske du vill fånga vid korn av hela processen och registrera starten, slutförandet och stegen däremellan. Detta kan vara transaktionsbaserat, men det finns många åtgärder däremellan. Du använder alltså ackumulerande ögonblicksbildsfaktatabeller för att besvara komplexa frågor inom business intelligence där det går tid mellan fakta. Ett bra exempel är en rad i en faktatabell där du beställer en kycklingsmörgås och en rad i en faktatabell där påsen lämnas ut genom bilfönstret vid McDonald’s drive-thru.

Lokalisering av fakta via dimensioner

Du och dina analytiker måste veta hur man frågar efter och filtrerar fakta för att få fram business intelligence från dem. Detta syfte uppnås med hjälp av dimensioner.

Dragning av dimensioner från referens- och råmetadata

Dimensioner skapas nästan alltid med en surrogatnyckel; surrogatnyckeln refereras naturligtvis av den främmande nyckeln (eller nycklarna) i faktatabellen. Vi söker i tabellen genom att söka i de dimensioner som vi är intresserade av. Alla andra data som beskriver våra fakta, t.ex. tidsstämplar, kundagenter, butikslokalisering, produkt och kund, är vad vi omvandlar till dimensioner.

Skönheten med dimensionell modellering är att fakta inte definieras av primärnycklar eller någon form av unik identifierare, i stället definieras de av kombinationen av dimensioner. Detta ger upphov till Star Schema.

Det är mycket viktigt att vi har en unikhet i våra dimensioner. När vi ska göra sökningar på fakta, kommer dubbletter bland dimensionskombinationer att bli en katastrof. Om du inte kan det, lägg till eller aggregera dimensioner för att göra dem unika.

Hierarki i dimensioner

Tänk på följande två bilder.

En analytiker kommer att ha ett enkelt liv om du ställer in den andra dimensionstabellen åt honom/henne.

Med den andra tabellen har du alltså följande hierarki:

Det finns alla sorters hierarkier – multipla hierarkier, enstaka hierarkier osv. Jag tar inte upp dem i det här blogginlägget.

En sak jag vill påpeka är att tidsdimensionen är en riktig plåga. Du måste ta hand om de magiska dagarna, skattekalendern, tidszonerna, cyklerna(vinst över kvartalstyper). Och var inte usel eller övermodig i detta, inte ens tidsseriedatabaser kommer att hjälpa dig i hierarkier om din ETL är strulig. Du kanske vill ta en titt på Outrigger dimensions. Det finns också tillfällen då en dimension är naturligt beroende av en annan. I sådana fall kan konstruktörerna lägga in en främmande nyckel från den ena till den andra. Detta är vad som utgör en ”outrigger-dimension”. I kalenderdimensioner är detta mycket vanligt.

Du kan inte använda ett datum vid en annan kornstorlek i en outrigger än de datum du använder i faktatabellen. Du kan inte tillåta aggregering över outrigger-dimensioner. Om det behövs kan du maskera numeriska värden i outrigger med textprefix eller suffix för att hindra detta.

Slowly Changing Dimensions

Och hur gärna jag än skulle vilja skriva om det, tror jag ändå att det är bättre för mina läsare att förstå det här begreppet grundligt härifrån.

Jag diskuterar inte Snowflake-dimensionerna, men bara för att påpeka att de fortfarande används med OLAP-databaser.

Integrera dina Big Data i ditt ETL-system

Du kommer att behandla dina tabulära Big Data som om de hade förvärvats genom en av dina vanliga Extract-faser. Du kommer alltså att tillämpa samma steg som du gjorde i transform:

1. Datarengöring
2. Konforma enheter och format
3. De-duplicering
4. Restrukturering
5. Staging

Sammanfattning

Jag ville förstå de teoretiska aspekterna av databasdesign, vilket ledde mig till att jag läste boken Ross och Kimball. Jag blev sedan nyfiken på att dra skillnader och analogier mellan deras metoder och de metoder som används av dagens ledande datadrivna företag som Netflix, Airbnb, Uber etc.

I denna strävan kan jag med fog säga att det strukturerade formatet med dimensionell modellering är att föredra framför bara en hardcore ETL. För på det här sättet tar du bort beroendet av dig, ditt BI-team ringer inte upp dig på Slack för att skapa en ny DAG för var och varannan insikt, istället, med korrekt modellering, gör du det möjligt för dem att agera och utforska fritt utan ditt behov.

Lämna gärna feedback på hur jag kan förbättra mig, jag är säker på att detta inte var din bästa läsning. Tack för din tid.

Fotnoter

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross och Kimball, kap 2 och kap 18

Kimball/Ross pp103-109