Free Press

Dimensionel modellering (DM) er en del af Business Dimensional Lifecycle-metodologien, der er udviklet af Ralph Kimball, og som omfatter et sæt metoder, teknikker og koncepter til brug i design af datawarehouse. Tilgangen fokuserer på at identificere de vigtigste forretningsprocesser inden for en virksomhed og modellering og implementering af disse først, før der tilføjes yderligere forretningsprocesser, en bottom-up tilgang.

Hvad er målene med datawarehouse-modellering?

De mål, som Ross og Kimball har opstillet, er ligetil:

• Make information easily accessible
• present information consistently
• presentable and receptive to change
• present information in a timely way
• protect information assets
• fungere som et autoritativt og troværdigt grundlag for forbedret beslutningstagning (single source of truth i Data Engineering-sprog)
• VIP’erne skal acceptere dit system

Hvis du har arbejdet på eller brugt et ETL-system, ville du have bemærket, at informationskonsistens opnås ved hjælp af overensstemmende foranstaltninger, at rettidighed opnås ved hjælp af ETL-cyklusser, og at tilpasningsevnen også i høj grad afhænger af ETL-designet.

Hvorfor modellering?

Som datatekniker kender du SQL meget godt og kan sandsynligvis skrive SQL-forespørgsler til hele dagen lang. Men du kan ikke antage, at den typiske slutbruger vil være ekspert i at skrive SQL-forespørgsler. Så vores mål er at bygge et DW så nemt for analytikere at skrive analyseforespørgsler hurtigt og effektivt.

Ting, som du ikke ønsker, at dine analytikere skal gøre:

• Søgninger baseret på ID
• Kaskaderende outer joins(selv du ville ikke ønske at gøre det)
• Grupperede eller joinede flere underspørgsmål
• Recursive underspørgsmål(besøg blot Hackerrank SQL, og du ville forstå smerten)
• Subquery korrelation: Hentning af data på tværs af flere kolonner i forskellige subqueries
• Joins uden PK/FK: selv for mig(1.5 års DE-erfaring), er det svært at visualisere.

Ting du kan og bør forvente af dine analytikere:

• simple joins
• kolonner med navne og omfattende tekst
• simpel aggregering
• analytiske vinduesfunktioner
• DISTINCT

Bemærk, at ovenstående punkter ikke er de nemme, og at dit system skal være skalerbart nok til alle disse typer forespørgsler.

OLTP-databaser omdannes til fakta og dimensioner på grund af ovennævnte mål.

Omdannelse fra transaktionsdatabaser til fakta

De fleste virksomheder måler deres succes og effektivitet ved at måle visse typer af data. Disse data indfanger reelle forretningsaktiviteter og fremskridt. Disse data kaldes fakta.

De OLTP-orienterede databaser registrerer transaktioner ad gangen, lidt ligesom event streaming, men centraliseret omkring transaktioner. DW er anderledes. DW behøver ikke at registrere detaljer på transaktionsniveau. DW har brug for at have fakta på tværs af forskellige kriterier i din virksomhed. DW skal aggregere (eller lade analytikere aggregere) de oplysninger, der er nødvendige for at forbedre forretningen. Og derfor er redundans en utilgivelig synd i DW.

Hvad er foranstaltninger, og hvorfor skal du fylde dine faktatabeller med dem?

I et datawarehouse er en foranstaltning en egenskab, som der kan foretages beregninger på.

De fakta, som vi udleder fra de operationelle datalagre, kommer med nogle ekstra data, som typisk summeres i vores analyse. Det er de aspekter af en kendsgerning, der gør det muligt for analytikeren eller lederen, der ser analysen, at se værdien i kendsgerningen.

Hvorfor skal du opretholde et konsistent korn?

Så du kan sikre, at dit system legitimt kan korrelere og aggregere på tværs af kendsgerninger.

Men det er ikke altid muligt at have data på atomart niveau. Så for at bygge bro over denne kløft er der to metoder:

• Periodiske snapshot-faktatabeller
• Akkumulerende snapshot-faktatabeller

Periodiske snapshot-faktatabeller

Som navnet antyder, indsamles de med regelmæssige tidsintervaller. Forbrug af gas, revision og inspektioner er nogle eksempler på dataindsamling, som har periodiske øjebliksbilleder aktiveret for dem.

Akkumulerende øjebliksbillede-faktatabeller

Når en indikator for forretningsresultater er en hastighed for færdiggørelse af en forretningsproces i flere trin, vil du måske gerne opsamle på kornet af hele processen og registrere starten, færdiggørelsen og de mellemliggende trin. Dette kan være transaktionskornede, men det har en masse foranstaltninger i mellem. Så du bruger akkumulerende snapshot-faktatabeller til at besvare komplekse spørgsmål i business intelligence, hvor der går tid mellem fakta. Et godt eksempel kunne være en række i faktabellen om din bestilling af en kyllingesandwich og en række i faktabellen om posen, der bliver udleveret gennem bilens vindue i McDonald’s drive-thru.

Lokalisering af fakta via dimensioner

Du og dine analytikere skal vide, hvordan de skal forespørge og filtrere fakta for at udlede business intelligence fra dem. Dette formål tjener dimensioner.

Tegning af dimensioner fra reference- og råmetadata

Dimensioner oprettes næsten altid med en surrogatnøgle; surrogatnøglen refereres naturligvis af den fremmede nøgle (eller nøgler) i faktabellen. Vi søger i tabellen ved at søge i de dimensioner, som vi er interesseret i. Alle de andre data, der beskriver vores fakta, f.eks. tidsstempler, kundeagenter, butikkens placering, produkt og kunde, er det, vi omdanner til dimensioner.

Det smukke ved dimensionel modellering er, at fakta ikke defineres af primærnøgler eller nogen form for unik identifikator, men i stedet defineres de af kombinationen af dimensioner. Dette giver anledning til Star Schema.

Det er meget vigtigt, at vi har en entydighed i vores dimensioner. Når vi kommer til forespørgsler på tværs af fakta, vil dubletter blandt dimensionskombinationer blive til en katastrofe. Hvis du ikke kan det, skal du tilføje eller aggregere dimensioner for at gøre dem unikke.

Hierarki i dimensioner

Tænk på de følgende to billeder.

En analytiker vil have et let liv, hvis du opstiller den anden dimensionstabel for ham/hende.

Så med den anden tabel har du følgende hierarki:

Der findes alle slags hierarkier – flere hierarkier, enkelt hierarki osv. Jeg behandler dem ikke i dette blogindlæg.

En ting, jeg gerne vil påpege, er, at tidsdimensionen er en rigtig plage i nakken. Du skal tage dig af de magiske dage, den skattemæssige kalender, tidszonerne, cyklusserne(overskud over kvartalstyper). Og lad være med at være elendig eller overmodig i dette, selv tidsseriedatabaser vil ikke hjælpe dig i hierarkier, hvis din ETL er rodet op. Du kan måske tage et kig på Outrigger dimensions. Der er også tilfælde, hvor en dimension naturligt er afhængig af en anden. I et sådant tilfælde kan designere sætte en fremmed nøgle fra den ene til den anden. Dette er det, der udgør en “outrigger-dimension”. I kalenderdimensioner er dette meget almindeligt.

Du kan ikke bruge en dato på et andet korn i en outrigger end de datoer, du bruger i faktabellen. Du kan ikke tillade aggregering over outrigger-dimensioner. Masker om nødvendigt numeriske værdier i outriggeren med tekstmæssige præfikser eller suffikser for at obstruere dette.

Slowly Changing Dimensions

Hvor meget jeg end gerne vil skrive om det, så tror jeg stadig, at det er bedre for mine læsere at forstå dette koncept grundigt herfra.

Jeg diskuterer ikke Snowflake-dimensioner, men blot for at påpege, at de stadig er i brug med OLAP-databaser.

Integrer dine Big Data i dit ETL-system

Du vil behandle dine tabulære Big Data som om de er blevet erhvervet gennem en af dine standard Extract-faser. Således vil du anvende de samme trin på det, som du gjorde i transform:

1. Data cleansing
2. Conforming units and formats
3. De-duplication
4. Restructuring
5. Staging

Summary

Jeg ønskede at forstå de teoretiske aspekter af databasedesign, hvilket fik mig til at læse bogen, Ross and Kimball. Derefter blev jeg nysgerrig efter at drage forskelle og analogier i deres metoder og de førende datadrevne virksomheder i dag som Netflix, Airbnb, Uber osv.

I denne søgen kan jeg retfærdigvis sige, at det strukturerede format af dimensionel modellering er at foretrække frem for blot en hardcore ETL. Fordi på denne måde fjerner du afhængigheden af dig, dit BI-team ringer dig ikke op på Slack for at oprette en ny DAG for hver anden indsigt, i stedet gør du med korrekt modellering dem i stand til at handle og udforske frit uden dit behov.

Lad gerne feedback på hvordan jeg kunne forbedre mig, jeg er sikker på at dette ikke var din bedste læsning. Tak for din tid.

Fodnoter

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

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

Ross og Kimball, kap 2 og kap 18

Kimball/Ross pp103-109