Et datawarehouse er et enkelt dataregister, hvor en post fra flere datakilder er integreret med henblik på online forretningsanalytisk behandling (OLAP). Dette indebærer, at et datawarehouse skal opfylde kravene fra alle forretningsstadier i hele organisationen. Derfor er design af datawarehouse en enormt kompleks, langvarig og dermed fejlbehæftet proces. Desuden ændrer de forretningsanalytiske funktioner sig over tid, hvilket medfører ændringer i kravene til systemerne. Derfor er data warehouse- og OLAP-systemer dynamiske, og designprocessen er kontinuerlig.
Data warehouse-design tager en anden metode end view-materialisering i industrierne. Den ser datawarehouses som databasesystemer med særlige behov som f.eks. besvarelse af ledelsesrelaterede forespørgsler. Målet med designet bliver, hvordan posten fra flere datakilder skal udtrækkes, transformeres og indlæses (ETL) for at blive organiseret i en database som datawarehouse.
Der er to tilgange
- “top-down” tilgang
- “bottom-up” tilgang
Top-down designtilgang
I “Top-Down” designtilgangen beskrives et datawarehouse som et emneorienteret, tidsvariant, ikke-flygtigt og integreret datalager for hele virksomheden data fra forskellige kilder valideres, omformateres og gemmes i en normaliseret (op til 3NF) database som datawarehouse. Datawarehouse lagrer “atomare” oplysninger, dvs. data på det laveste granularitetsniveau, hvorfra der kan opbygges dimensionelle datamarts ved at udvælge de data, der er nødvendige for bestemte forretningsområder eller bestemte afdelinger. Der er tale om en datadrevet tilgang, idet oplysningerne først indsamles og integreres, og derefter formuleres fagområdernes forretningskrav til opbygning af datamarkeder. Fordelen ved denne metode er, at den understøtter en enkelt integreret datakilde. De datamarkeder, der er bygget ud fra den, vil således være konsistente, når de overlapper hinanden.
Fordelene ved top-down design
Data Marts indlæses fra datawarehouses.
Det er meget nemt at udvikle nye data Marts fra datawarehouses.
Ulemper ved top-down design
Denne teknik er ufleksibel i forhold til skiftende behov i afdelingerne.
Udgifterne til implementering af projektet er høje.
Bottom-Up Design Approach
I “Bottom-Up”-tilgangen beskrives et data warehouse som “en kopi af transaktionsdata specifical architecture for query and analysis,” term the star schema. I denne tilgang oprettes et datamart først for at skabe de nødvendige rapporterings- og analysefunktioner for bestemte forretningsprocesser (eller emner). Det er således nødvendigt at være en forretningsdrevet tilgang i modsætning til Inmons datadrevne tilgang.
Data Marts omfatter data med det laveste korn og, om nødvendigt, også aggregerede data. I stedet for en normaliseret database til datawarehouse tilpasses en denormaliseret dimensionsdatabase til at opfylde kravene til dataleveranceringen i datawarehouses. Hvis man ved hjælp af denne metode ønsker at anvende et sæt af datamarts som virksomhedens datawarehouse, skal datamarts opbygges med henblik på at overholde dimensioner, der definerer, at almindelige objekter repræsenteres ens i forskellige datamarts. De konforme dimensioner forbandt datamarts til at danne et datawarehouse, som generelt kaldes et virtuelt datawarehouse.
Førdelen ved “bottom-up”-designmetoden er, at den har hurtig ROI, da det tager langt mindre tid og kræfter at udvikle et datamart, et datawarehouse for et enkelt emne, end at udvikle et datawarehouse for hele virksomheden. Desuden er risikoen for fejl endnu mindre. Denne metode er i sagens natur inkrementel. Denne metode giver projektgruppen mulighed for at lære og vokse.
Fordele ved bottom-up design
Dokumenter kan genereres hurtigt.
Data warehouse kan udvides til at rumme nye forretningsenheder.
Det er blot at udvikle nye data marts’er og derefter integrere med andre data marts’er.
Ulemper ved bottom-up design
Den omvendte placering af datawarehouse og datamarts er omvendt i bottom-up tilgangens design.
Differentiering mellem Top-Down Design Approach og Bottom-Up Design Approach
| Top-Down Design Approach | Bottom-Up Design Approach |
|---|---|
| Det store problem opdeles i mindre delproblemer. | Løser det væsentlige problem på lavt niveau og integrerer dem i et højere problem. |
| I sagens natur arkitektonisk – ikke en sammenslutning af flere datamarts. | I sagens natur inkrementel; kan planlægge væsentlige datamarts først. |
| En enkelt, central opbevaring af oplysninger om indholdet. | Afdelingsoplysninger opbevares. |
| Centrale regler og kontrol. | Afdelingsbestemte regler og kontrol. |
| Det indeholder redundante oplysninger. | Redundans kan fjernes. |
| Det kan se hurtige resultater, hvis det gennemføres med gentagelser. | Mindre risiko for fiasko, gunstigt investeringsafkast og bevis for teknikker. |