Ett datalager är ett enda datalager där en post från flera datakällor integreras för analytisk bearbetning av affärsdata online (OLAP). Detta innebär att ett datalager måste uppfylla kraven från alla affärssteg inom hela organisationen. Utformningen av datalagret är således en oerhört komplex, långvarig och därmed felbenägen process. Dessutom förändras affärsanalytiska funktioner med tiden, vilket leder till att kraven på systemen förändras. Därför är datalager- och OLAP-system dynamiska, och designprocessen är kontinuerlig.
Datalagrets design tar en metod som skiljer sig från view-materialisering i branscherna. Den ser datalager som databassystem med särskilda behov, t.ex. att besvara förvaltningsrelaterade frågor. Målet för designen blir hur posten från flera datakällor ska extraheras, omvandlas och laddas (ETL) för att organiseras i en databas som datalager.
Det finns två tillvägagångssätt
- ”top-down” tillvägagångssätt
- ”bottom-up” tillvägagångssätt
Top-down Design Approach
I ”Top-Down” design tillvägagångssättet beskrivs ett datalager som ett ämnesorienterat, tidvariant, icke-flyktigt och integrerat datalagret för hela företaget data från olika källor valideras, omformateras och sparas i en normaliserad (upp till 3NF) databas som datalagret. I datalagret lagras ”atomär” information, dvs. data på lägsta granularitetsnivå, varifrån man kan bygga upp dimensionella datamarkörer genom att välja ut de data som behövs för specifika affärsområden eller avdelningar. Det är ett datadrivet tillvägagångssätt eftersom informationen först samlas in och integreras och sedan formuleras de olika ämnens verksamhetskrav för att bygga upp datamagasin. Fördelen med denna metod är att den stöder en enda integrerad datakälla. De datamarkörer som byggs från den kommer därför att vara konsekventa när de överlappar varandra.
Fördelar med top-down design
Data Marts laddas från datalager.
Det är mycket enkelt att utveckla nya data Marts från datalager.
Observering av data Marts från datalager är mycket enkelt.
Observering av data Marts
Den här tekniken är oflexibel för att möta förändrade behov på avdelningarna.
Kostnaden för att genomföra projektet är hög.
Bottom-Up Design Approach
I ”Bottom-Up”-metoden beskrivs ett datalager som ”en kopia av transaktionsdata-specifik arkitektur för förfrågning och analys”, termen stjärnschema. I detta tillvägagångssätt skapas först en datamart för att skapa nödvändiga rapporterings- och analysmöjligheter för särskilda affärsprocesser (eller ämnen). Det behövs alltså en affärsdriven metod till skillnad från Inmons datadrivna metod.
Data Marts omfattar data med lägsta kornstorlek och vid behov även aggregerade data. Istället för en normaliserad databas för datalagret anpassas en denormaliserad dimensionell databas för att uppfylla datalagrens krav på dataleveranserna. För att använda uppsättningen datamarkörer som företagets datalager bör datamarkörer byggas med hjälp av den här metoden med överensstämmande dimensioner i åtanke, vilket definierar att vanliga objekt representeras på samma sätt i olika datamarkörer. De överensstämmande dimensionerna kopplade samman datamarterna för att bilda ett datalager, som i allmänhet kallas ett virtuellt datalager.
Fördelen med ”bottom-up”-designmetoden är att den har en snabb avkastning på investeringen, eftersom det tar mycket mindre tid och ansträngning att utveckla en datamart, ett datalager för ett enskilt ämne, än att utveckla ett datalager som omfattar hela företaget. Risken för misslyckande är också ännu mindre. Den här metoden är i sig inkrementell. Med denna metod kan projektgruppen lära sig och växa.
Fördelar med bottom-up design
Dokument kan genereras snabbt.
Data warehouse kan utökas för att ta hänsyn till nya affärsenheter.
Det är bara att utveckla nya datamarts och sedan integrera med andra datamarts.
Nackdelar med bottom-up-design
Data warehouse- och data marts-platserna är omvända i designen med bottom-up-metoden.
Differentiera mellan Top-Down Design Approach och Bottom-Up Design Approach
| Top-Down Design Approach | Bottom-Up Design Approach |
|---|---|
| Fördelar det stora problemet i mindre delproblem. | Lösar de väsentliga problemen på låg nivå och integrerar dem i ett högre problem. |
| Insäkert arkitektoniskt uppbyggt – inte en förening av flera datamarkörer. | Insäkert inkrementellt; kan schemalägga väsentliga datamarkörer först. |
| En enda, central lagring av information om innehållet. | Avdelningsvis information lagras. |
| Centrala regler och kontroll. | Avdelningsvisa regler och kontroll. |
| Det innehåller redundant information. | Redundans kan tas bort. |
| Den kan ge snabba resultat om den genomförs med upprepningar. | Mindre risk för misslyckande, gynnsam avkastning på investeringar och bevis på tekniker. |
.