Dimensionell modellering

Dimensionsmodellering ( DM ) är en del av Business Dimensional Lifecycle -metodik som utvecklats av Ralph Kimball som inkluderar en uppsättning metoder, tekniker och koncept för användning i datalagerdesign . Tillvägagångssättet fokuserar på att identifiera de viktigaste affärsprocesserna inom en verksamhet och modellera och implementera dessa först innan ytterligare affärsprocesser läggs till, som en nedifrån-och-upp-strategi . Ett alternativt tillvägagångssätt från Inmon förespråkar en top-down design av modellen av all företagsdata med hjälp av verktyg som entity-relationship modeling ( ER).

Beskrivning

Dimensionell modellering använder alltid begreppen fakta (mått) och dimensioner (sammanhang). Fakta är vanligtvis (men inte alltid) numeriska värden som kan aggregeras, och dimensioner är grupper av hierarkier och deskriptorer som definierar fakta. Till exempel är försäljningssumman ett faktum; tidsstämpel, produkt, register#, butik#, etc. är delar av dimensioner. Dimensionsmodeller byggs efter affärsprocessområde, t.ex. butiksförsäljning, lager, reklamationer etc. Eftersom de olika affärsprocessområdena delar vissa men inte alla dimensioner, uppnås effektivitet i design, drift och konsekvens med anpassade dimensioner , dvs. kopia av den delade dimensionen över ämnesområden. ^{[ citat behövs ]}

Dimensionsmodellering involverar inte nödvändigtvis en relationsdatabas. Samma modelleringsmetod, på den logiska nivån, kan användas för alla fysiska former, såsom flerdimensionell databas eller till och med platta filer. Det är orienterat kring förståelighet och prestanda. ^{[ citat behövs ]}

Designmetod

Designa modellen

Den dimensionella modellen är byggd på ett stjärnliknande schema eller snöflingaschema , med dimensioner kring faktatabellen. För att bygga schemat används följande designmodell:

Välj affärsprocess
Deklarera säden
Identifiera måtten
Identifiera faktum

Välj affärsprocess

Processen med dimensionsmodellering bygger på en 4-stegs designmetod som hjälper till att säkerställa användbarheten av den dimensionella modellen och användningen av datalagret . Grunderna i designen bygger på själva affärsprocessen som datalagret ska täcka. Därför är det första steget i modellen att beskriva den affärsprocess som modellen bygger på. Det kan till exempel vara en försäljningssituation i en butik. För att beskriva affärsprocessen kan man välja att göra detta i klartext eller använda grundläggande Business Process Modeling Notation ( BPMN ) eller andra designguider som Unified Modeling Language ( UML ).

Deklarera säden

Efter att ha beskrivit affärsprocessen är nästa steg i designen att deklarera modellens kärna. Modellens kärna är den exakta beskrivningen av vad den dimensionella modellen ska fokusera på. Det kan till exempel vara "En enskild rad på en kundkupong från en butik". För att klargöra vad korn betyder bör du välja den centrala processen och beskriva den med en mening. Dessutom är kornet (satsen) det du ska bygga dina dimensioner och faktatabell av. Du kanske tycker att det är nödvändigt att gå tillbaka till det här steget för att ändra korgen på grund av ny information om vad din modell ska kunna leverera.

Identifiera måtten

Det tredje steget i designprocessen är att definiera modellens dimensioner. Måtten måste definieras inom kornet från det andra steget i 4-stegsprocessen. Dimensioner är grunden för faktatabellen och det är där data för faktatabellen samlas in. Typiskt är dimensioner substantiv som datum, butik, lager etc. Dessa dimensioner är där all data lagras. Till exempel kan datumdimensionen innehålla data som år, månad och veckodag.

Identifiera fakta

Efter att ha definierat dimensionerna är nästa steg i processen att göra nycklar till faktatabellen. Detta steg är att identifiera de numeriska fakta som kommer att fylla varje faktatabellrad. Detta steg är nära relaterat till affärsanvändarna av systemet, eftersom det är här de får tillgång till data som lagras i datalagret . Därför är de flesta raderna i faktatabellen numeriska, additiva siffror som kvantitet eller kostnad per enhet, etc.

Dimensionsnormalisering

Dimensionell normalisering eller snöflingning tar bort redundanta attribut, som är kända i de normala platt-denormaliserade dimensionerna. Dimensioner är strikt sammanfogade i underdimensioner.

Snowflaking har ett inflytande på datastrukturen som skiljer sig från många filosofier om datalager. En datatabell (fakta) omgiven av flera beskrivande (dimensions)tabeller

Utvecklare normaliserar ofta inte dimensioner på grund av flera skäl:

Normalisering gör datastrukturen mer komplex
Prestandan kan vara långsammare på grund av de många sammankopplingarna mellan borden
Utrymmesbesparingarna är minimala
Bitmappsindex kan inte användas
Frågeprestanda. 3NF-databaser lider av prestandaproblem när man aggregerar eller hämtar många dimensionella värden som kan kräva analys. Om du bara ska göra driftsrapporter kan du kanske klara dig med 3NF eftersom din driftanvändare kommer att leta efter mycket finkorniga data.

Det finns några argument för varför normalisering kan vara användbar. Det kan vara en fördel när en del av hierarkin är gemensam för mer än en dimension. Till exempel kan en geografisk dimension vara återanvändbar eftersom både kund- och leverantörsdimensionen använder den.

Fördelar med dimensionsmodellering

Fördelarna med dimensionsmodellen är följande:

Förstålighet. Jämfört med den normaliserade modellen är dimensionsmodellen lättare att förstå och mer intuitiv. I dimensionsmodeller grupperas information i sammanhängande affärskategorier eller dimensioner, vilket gör det lättare att läsa och tolka. Enkelheten tillåter också programvara att navigera i databaser effektivt. I normaliserade modeller är data uppdelad i många diskreta enheter och även en enkel affärsprocess kan resultera i dussintals tabeller sammanfogade på ett komplext sätt.
Frågeprestanda. Dimensionsmodeller är mer denormaliserade och optimerade för dataförfrågningar, medan normaliserade modeller försöker eliminera dataredundanser och är optimerade för transaktionsladdning och uppdatering. Det förutsägbara ramverket för en dimensionell modell tillåter databasen att göra starka antaganden om data som kan ha en positiv inverkan på prestanda. Varje dimension är en likvärdig ingångspunkt i faktatabellen, och denna symmetriska struktur möjliggör effektiv hantering av komplexa frågor. Frågeoptimering för stjärnanslutna databaser är enkel, förutsägbar och kontrollerbar.
Sträckbarhet. Dimensionsmodeller är skalbara och tar enkelt emot oväntade nya data. Befintliga tabeller kan ändras på plats antingen genom att helt enkelt lägga till nya datarader i tabellen eller genom att utföra SQL alter-tabellkommandon. Inga frågor eller applikationer som sitter ovanpå datalagret behöver omprogrammeras för att klara ändringar. Gamla frågor och applikationer fortsätter att köras utan att ge andra resultat. Men i normaliserade modeller bör varje modifiering övervägas noggrant, på grund av de komplexa beroenden mellan databastabeller.

Dimensionsmodeller, Hadoop och big data

Vi får fortfarande fördelarna med dimensionella modeller på Hadoop och liknande ramverk för big data . Vissa funktioner i Hadoop kräver dock att vi anpassar standardmetoden till dimensionsmodellering något. ^{[ citat behövs ]}

Hadoop -filsystemet är oföränderligt . Vi kan bara lägga till men inte uppdatera data. Som ett resultat kan vi bara lägga till poster till dimensionstabeller. Långsamt ändrade dimensioner på Hadoop blir standardbeteendet. För att få den senaste och mest aktuella posten i en dimensionstabell har vi tre alternativ. Först kan vi skapa en vy som hämtar den senaste posten med hjälp av fönsterfunktioner . För det andra kan vi ha en komprimeringstjänst som körs i bakgrunden som återskapar det senaste tillståndet. För det tredje kan vi lagra våra dimensionstabeller i föränderlig lagring, t.ex. HBase och federerade frågor över de två typerna av lagring.
Sättet data distribueras över HDFS gör det dyrt att sammanfoga data. I en distribuerad relationsdatabas ( MPP ) kan vi samlokalisera poster med samma primära och främmande nycklar på samma nod i ett kluster. Detta gör det relativt billigt att ansluta till väldigt stora bord. Ingen data behöver färdas över nätverket för att utföra anslutningen. Detta är väldigt annorlunda på Hadoop och HDFS. På HDFS är tabeller uppdelade i stora bitar och fördelade över noderna i vårt kluster. Vi har ingen kontroll över hur enskilda poster och deras nycklar sprids över klustret. Som ett resultat är kopplingar på Hadoop för två mycket stora tabeller ganska dyra eftersom data måste färdas över nätverket. Vi bör undvika anslutningar där det är möjligt. För en stor fakta- och dimensionstabell kan vi avnormalisera dimensionstabellen direkt till faktatabellen. För två mycket stora transaktionstabeller kan vi kapsla posterna för den underordnade tabellen inuti den överordnade tabellen och platta ut data vid körning.

Litteratur

Kimball, Ralph ; Margy Ross (2013). Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3:e upplagan). Wiley. ISBN 978-1-118-53080-1 .
Ralph Kimball (1997). "Ett dimensionellt modelleringsmanifest" . DBMS och Internetsystem . 10 (9).
Margy Ross (Kimball Group) (2005). "Identifiera affärsprocesser" . Kimball Group, Designtips (69). Arkiverad från originalet den 12 juni 2013.