Tags:    databaser Denne artikel vil beskrive for begynderen hvad et data warehouse er samt hvordan man kan bygge et datawarehouse. Aller først er en definition på sin plads: et data warehouse er ikke andet end en database der indeholder data, for eksempel en forretning. Det vil sige at har du en database tilknyttet din web side er det dit data warehouse. Det nemmeste at forestille sig omkring et data warehouse er - som ordet antyder det - at du går inde i et supermarked (warehouse) og på hylderne er der ikke mælk og konserves, men data. Man kan lave en yderligere opdeling af et data warehouse til flere data mart's. Et data mart er et udsnit af dit data warehouse, der indeholder data for et enkelt forretningsområde, fx. salg. For at illustrere det med et eksempel så har en bogbutik på nettet et stort data warehouse der indeholder alt deres data, lige fra hvem der er ansat i bogbutikken til hvornår "Peter Pan" bogen kommer hjem igen. Dette data warehouse kan nu deles op i flere data mart's. Eksempelvis kan man lave et data mart der udelukkende består af data (tabeller) der omhandler salg, et der udelukkende omhandler medarbejdere og så videre. Et data warehouse består af flere data marts! Et datamart/datawarehouse kan også deles op i to typer af databaser, en OLTP (On Line Transaction Processing) database eller en OLAP (On Line Analytical Processing) database. Og for at gøre forvirringen komplet kan en OLAP database deles op i yderligere to definitioner: en relationel database samt en multidimensionel database. Tabeller deles op i to kategorier "Facts og dimensions" (fakta og dimensioner).

Facts og dimensions
Man deler tabeller op i to kategorier, fact tabeller og dimensionstabeller. En fact tabel er en tabel der indeholder beregninger (Measures), dette kan fx. være en pris, et antal eller en vægtning. Kendetegnende for alle er at en beregning (measure) KUN findes på en fact tabel og omvendt hvis en tabel indeholder en beregning så er det en fact tabel. Det er kun en beregning (measure) hvis det giver mening at summere værdierne. Et eksempel på measures der giver mening at summere er priser og antal. Eksempler på hvad der ikke giver mening at summere, og derfor heller ikke beregninger (measures) er varenumre og nøgler. Dimensionerne er så de andre! Det vil sige at dimensioner er hvad vi måler vores measures ud fra, det er fx. farve, type, dato og genre. Reglen er: Er det ikke en fact tabel, så er det en dimensionstabel.

OLTP databasen.
OLTP databasen er altid relationel. En transaktionsbaseret database er typisk den slags en programmør vil lave (her skelner jeg mellem fx. c++ programmører og så de folk der modellerer databaser). Transaktions databaser skal være hurtige at indsætte data i hvilket gør at en programmør typisk vælger at have alle data i en enkelt tabel således den er komplet denormaliseret (dvs. ingen nøgler til andre tabeller, alt data findes i een tabel). Således vil en tabel over salg fra førnævnte bogbutik se ud som nedenstående:



Ovenstående er et meget simpelt eksempel på hvordan en transaktionstabel ser ud. I en sådan tabel kan man hurtigt indsætte en ny transaktion fra butikken når der bliver solgt noget nyt. Grunden til man holder det hele i så få tabeller som muligt er for at mindske det overhead (mangel på performance) der er ved at sende en SQL sætning af sted mod en database. Hvis man har fire eller fem tabeller der skal indsættes data i hver gang man sælger noget i butikken, har man ikke råd til at have dette overhead (måske kan en boghandel godt have råd til dette, men en forretning som fx. Bilka, hvor der er 40 kasselinier der registrerer salg på een gang, har ikke råd til dette overhead). Med mindre man er klar over normaliseringer og database design, har man en tendens til at lave en denormaliseret OLTP database (som ovenstående). Den er også rigtig god, og hurtig, til at indsætte data i, men det er (næsten) også det. man kan naturligvis også lave en "rigtig" normaliseret OLTP database. En sådan database vil man bygge efter normaliserings reglerne (der er i alt 5 normaliseringer). Tager vi igen udgangspunkt i ovenstående denormaliserede tabel har vi en mulighed for at normalisere "type" til en anden tabel og i stedet indsætte en nøgle i ovenstående tabel. Dette vil se således ud:



Som det nu ses har vi en nøgle på salgstabellen der refererer ned til en type tabel hvor der kun er to forekomster, nemlig "paperbag" eller "hardbag". Dette vil gøre vores database en lille smule mere overskuelig at kigge på, samtidig med at det er et bedre design. Problemet med at lave denne "normalisering" (det hedder det når man laver en nøgle og flytter teksten til en anden tabel) er at det tager lidt længere tid at indsætte data i denne struktur, da den indeholder nogle nøgler man skal sikre sig eksisterer i dimensionstabellerne.

OLAP databasen
Olap databasen er lavet med henblik på det modsatte af OLTP databasen, nemlig hurtigt at kunne hente en masse data ud fra databasen og analysere på det. Som tidligere skrevet deles OLAP databaser op i to typer, den relationelle OLAP database samt den multidimensionelle OLAP database. For at starte med den relationelle (som nok er den flest mennesker er bekendte med) består den af en række tabeller med forskellige kolonner. En relationel OLAP database bliver sjældent brugt da der er er mange nyere teknologier, der har forfinet OLAP metoderne og tilbyder mere fleksible OLAP metoder. For hurtigt at gennemgå den relationelle OLAP struktur, laver man den typisk på samme måde som en OLTP database, det vil sige denormaliseret (ingen ekstra tabeller til eksempelvis type). Dette gør også i denne situation at man vil kunne læse en masse data rimeligt hurtigt og præsentere det til brugeren som eksempelvis søjlediagrammer.

Den multidimensionelle OLAP database er en forholdsvis ny teknologi der primært bliver sendt på markedet af Microsoft, men andre firmaer som IBM og Oracle har også deres versioner af dette fænomen. Det er en komplet ny tankegang i forhold til den traditionelle relationelle tankegang hvor man deler sin database op i tabeller og tupler (rækker). Man arbejder nu i measures (beregninger) og dimensions (dimensioner) samt members og levels (medlemmer og niveauer). En multidimensionel OLAP database (faktisk kan en multidimensionel database kun være en OLAP database da det ikke er muligt at indsætte data i en OLAP database. I den traditionelle relationelle verden bruger man SQL (Structured Query Language) til at manipulere med data, i Multidimensionelle databaser bruger man et nyt sprog der hedder MDX (Multi Dimensional eXpression) til at manipulere med data. En multidimensionel database kaldes også for en kube database da man skal forestille sig det hele som en kubisk struktur (nok er det egentligt mere en form for kandis man skal forestille sig). I en kube henter man typisk aldrig en enkelt forekomst ud fra databasen, men man tager "skiver" af sin kube fx. kan man tage en skive der tager alt bogsalg i 2003. Det vil sige man laver det der hedder "slicing and dicing". Eksempelvis kan man forestille sig en kube hvor man (for at blive i vores lille bog butiks terminologi) har bog genren på Y-aksen, tidsdimensionen på X-aksen samt type dimensionen på Z-aksen. Hvis så man forestiller sig at man stikker en pind ind på y aksen af kuben(således den stikker tværs igennem kuben parallelt med Y-aksen), der hvor man har den eller de genrer man ønsker data for. Man stikker også en pind ind på X-aksen for den eller de perioder man ønsker at analysere data for. Man indsætter nu en sidste pind parallelt med Z-aksen, der viser den eller de typer man ønsker data for. Punktet (eller området er det nærmere) hvor alle disse pinde krydser hinanden er det data man får smidt tilbage. Et eksempel kan fx være at man ønsker at se data for genren 'Biografier', perioden skal være 2002, og typen skal være paperbags. Dette vil nu give os en masse data der lader os analysere på disse data.

Afslutning
Det er svært at beskrive en multidimensionel database samt den teknologi der er til rådighed ved brugen af et multidimensionelt miljø frem for en traditionelt relationelt miljø. Tidligere hvor man lavede aggregeringer i et relationelt miljø (man beregner fx, en avance på databaseniveau) laves disse nu automatisk af dit databasemiljø. Endvidere kan der specificeres forskellige hierarkier i en kube database. Det der typisk benyttes er et hierarki af år, måned og dag, hvor man kan folde sine år ud og vælge måneder, samt folde disse ud og vælge dage. Multidimensionelle data warehouse platforme er helt sikkert kommet for at revolutionere database verdenen. Der åbner sig nu nye muligheder man indtil fornyligt ikke havde turdet håbe på med hensyn til performanceoptimering samt en "naturlig" gruppering af data. Multidimensionelle databaser er helt sikkert værd at tage et kig på.


Hvad synes du om denne artikel? Giv din mening til kende ved at stemme via pilene til venstre og/eller lægge en kommentar herunder.

Del også gerne artiklen med dine Facebook venner:  

Karma barometer (30 dage)

IT jobs | Kontakt | Om Udvikleren.dk | Om karma | IT nyheds arkiv | Annoncering

X