Hvad er OLAP OLAP er en databaseteknologi, der er blevet optimeret til forespørgsler og rapportering i stedet for behandling af transaktioner. Kildedataene for OLAP er OLTP- databaser (Online Transactional Processing), der almindeligvis lagres i datalagre. OLAP- data afledes af disse historiske data og samles i strukturer, der giver muligvis for avancerede analyser. OLAP- data organiseres også hierarkisk og lagres i kuber i stedet for tabeller. Det er en avanceret teknologi, der bruger multidimensionelle strukturer for at give hurtig adgang til data, der skal analyseres. Denne organisering gør det let at få vist komplekse oversigter i en pivottabel eller et pivotdiagram, som f.eks. det samlede salg i et land eller en region, og detaljer for steder, hvor salgstallene er specielt høje eller lave. OLAP- databaser er beregnet til at gøre det hurtigere at hente data. OLAP- serveren, i modsætning til Microsoft Office Excel, udregner de summerede værdier, hvilket betyder, at færre data skal overføres til Microsoft Excel, når du opretter eller ændrer en rapport. Den fremgangsmåde gør, at du kan arbejde med meget større mængder kildedata end du kunne, hvis dataene var organiseret i en traditionel OLAP- database, hvor Microsoft Excel henter hver enkelt post og dernæst udregne de summerede værdier. OLAP- databaser indeholder to grundlæggende typer data: Mål, der er numeriske data, de egenskaber og gennemsnit, du bruger til at træffe informerede forretningsbeslutninger, og dimensioner, som er de kategorier, du bruger til at organisere de pågældende mål. OLAP- databaser gør det muligt at organisere data efter mange detaljeniveauer ved hjælp af de samme kategorier, du kender, så du kan analysere dataene. OLTP databasen. OLTP databasen er altid relationel. En transaktionsbaseret database er typisk den slags en programmør vil lave. 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 eller flere tabeler således den er komplet normaliseret dvs. med nøgler til andre tabeller, alt data findes i en eller flere tabeler. Således vil en tabel over salg for en 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 1
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 2
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. 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. Kube En datastruktur, der samler målene efter niveauerne og hierarkierne for hver af de dimensioner, du vil analysere. Kuber kombinerer flere dimensioner, f.eks. tid, sted og produktlinjer, med opsummerede data, f.eks. salg- eller lagertal. Kuber er ikke "kuber" i almen matematisk forstand, for de har ikke nødvendigvis lige sider. De er dog en velegnet metafor for et komplekst begreb. Mål Et sæt værdier i en kube, som er baseret på en kolonne i kubens faktatabel, og som typisk er numeriske værdier. Mål er de centrale værdier i kuben, som forbehandles, samles og analyseres. Almindelige eksempler er bl.a. salg, overskud, indtægter og omkostninger Medlem Et element i et hierarki, der repræsenterer en eller flere forekomster af data. Et medlem kan enten være entydigt eller ikke- entydigt. 2007 og 2008 repræsenterer f.eks. entydige medlemmer i årsniveauet af en tidsdimension, hvorimod Januar repræsenterer ikke- entydige 3
medlemmer i månedsniveauet, fordi der kan vpære mere end én Januar i tidsdimensionen, hvis den indeholder data for mere end ét år. Beregnet medlem Et medlem af en dimension, hvis værdi beregnes ved kørselstid ved hjælp af et udtryk. Værdier for beregnede medlemmer kan afledes fra andre medlemmers værdier. Det beregnede medlem Overskud kan f.eks. bestemmes ved at trække værdien af medlemmet Omkostninger fra værdien af medlemmet Salg. Dimension Et sæt med et eller flere organiserede hierarkier af niveauer i en kube, som en bruger forstår og bruger som grundlaget for dataanalyser. Et geografisk mål kan f.eks. omfatte niveauer for Land/område, Stat/provins og By. En tidsdimension kan også indeholde et hierarki med niveauer for år, kvartal, måned og dag. I en pivottabel eller et pivotdiagram bliver hvert hierarki et sæt felter, som du kan udvide og skjule for at skjule lavere eller højere niveauer. Hierarki En logisk træstruktur, der organiserer medlemmerne af en dimension, f.eks. at hvert medlem har ét overordnet medlem og ingen eller flere underordnede medlemmer. Et underordnet medlem er det medlem på niveauet under i et hierarki, der er direkte relateret til det aktuelle medlem. I et tidshierarki, der indeholder niveauerne Kvartal, Måned og Dag, er Januar f.eks. et underordnet medlem til Kvt1. Et overordnet medlem er et medlem på niveauet over i et hierarki, der er direkte relateret til det aktuelle medlem. Den overordnede værdi er som regel en konsolidering af værdierne for alle de tilhørende underordnede værdier. I et tidshierarki, er indeholder niveauerne Kvartal, Måned og Dag, er Kvt1 det overordnede niveau for Januar. Niveau I et hierarki kan data organiseres i lavere eller højere detaljeniveauer, f.eks. niveauerne År, Kvartal, Måned og Dag i et tidshierarki. 4
OLAP implementrings typer Multidimintional database server Er det "klassiske" form af OLAP og er undertiden benævnt som MOLAP hvilket M stå for multidimintional database. MOLAP gemmer data i en optimeret multi- dimensional array opbevaring, snarere end i en relationel database. Derfor kræver pre- beregning og lagring af oplysninger i kuben - operationen kendt som forarbejdning. Med MOLAP bliver data lagret i en multidimensional database. MOLAP Cubes bliver automatisk indekseret baseret på dimensionen og data bliver fundet ved at bruge offset adressering. For at finde en given værdi i en multidimensional database er det kun nødvendigt at bruge addition og multiplikation hvilket er meget hurtige operationer for en computer. MOLAP er bedst til meget tætte data hvor de fleste celler i en terning indeholder en værdi. Relationelle database server ROLAP: Arbejder direkte med relationelle databaser. De grunddata og størrelse tabeller gemmes som relationelle tabeller og nye borde er skabt til at holde den samlede information. Afhænger af en specialiseret skema design. ROLAP er egnet for data med en lav tæthedsgrad. De lagres i et traditionelt stjerne- eller snefnugskema. Data bliver hverken aggregeret eller manipuleret. Man kan bruge SQL for at tilgå dem. ROLAP giver automatisk alle de kendte fordele ved den relationale database såsom høj tilgængelighed, konsistente data, backup og recovery, parallel behandling, og job planlægning. 5
Hybrid Der er ingen klar aftale på tværs af branchen, hvad der forstås af "Hybrid OLAP", bortset fra at en database vil splitte data mellem relationelle og specialiserede lagre. For eksempel for nogle leverandører, en HOLAP database vil bruge relationelle tabeller til at holde større mængder detaljerede data, og bruge specialiserede lagre i mindst nogle aspekter af mindre mængder af mere- aggregat eller mindre detaljerede data. HOLAP er en blanding af de to teknologier, hvor detaildata bliver lagret i den relationale del og aggregeringerne i den multidimensionale del. Man kan så bore sig igennem fra den multidimensionale database til den relationale hvis man har brug for at få fat i detailværdierne. I dag understøtter mange produkter denne form for implementering. Fordele ved MOLAP Hurtig søgning ydeevne på grund af optimeret opbevaring, multidimensionale indeksering og caching.mindre i- disk størrelse af data i forhold til data lagret i relationel database på grund af kompression teknikker. Automatiseret opgørelse af højere aggregater af data.det er meget kompakt for lav dimension datasæt.array model giver naturlige indeksering. Effektiv data uddrag opnås gennem pre- strukturering af aggregerede data. Ulemper ved MOLAP Behandling trin (data belastning) kan være temmelig lang, især på store datamængder. Dette er normalt afhjælpes ved at gøre kun gradvist behandling, dvs behandling kun de data, som har ændret sig (oftest nye data) i stedet for oparbejdning hele datasættet. MOLAP værktøjer traditionelt har svært ved at forespørge modeller med dimensioner med meget høj kardinalitet (dvs. millioner medlemmer). Nogle MOLAP produkter har svært ved at opdatere og søgninger modeller med mere end ti dimensioner. Denne grænse er forskellig afhængig af kompleksitet og kardinaliteten af de dimensioner i spørgsmålet. Det afhænger også af det gemte nummer af fakta eller foranstaltninger. Andre MOLAP produkter kan håndtere hundreder af dimensioner. MOLAP tilgang indfører data redundans. Fordele ved ROLAP ROLAP anses for at være mere skalerbar i håndtering af store datamængder, især modeller med dimensioner med meget høj kardinalitet (dvs. millioner medlemmer). Med en bred vifte af data lastning værktøjer til rådighed, og evnen til at finjustere ETL - kode til de særlige data model, load tider er generelt meget kortere end med den automatiserede 6
MOLAP belastninger. De data gemmes i en standard relationsdatabase og kan tilgås af alle SQL rapportering værktøj (værktøjet behøver ikke at være en OLAP værktøj). ROLAP værktøjer er bedre til at håndtere non- aggregatable faktiske omstændigheder (f.eks tekstuelle beskrivelser). MOLAP værktøjer har tendens til at lide under langsom ydeevne, når forespørge disse elementer. Ved afkobling lagring af data fra multi- dimensional model, er det muligt for en vellykket model data, der ellers ikke ville passe ind i en streng dimensional model. Den ROLAP tilgang kan udnytte database tilladelse kontrol såsom række- sikkerhed på, hvor forespørgslen resultaterne er filtreret afhængigt preset kriterier, for eksempel, at en given bruger eller en gruppe af brugere ( SQL WHERE). Ulemper ved ROLAP Der er enighed i branchen at ROLAP værktøjer langsommere ydelse end MOLAP værktøje. Læsningen af samlede tabeller skal forvaltes af brugerdefineret ETL - kode. The ROLAP tools do not help with this task. Den ROLAP værktøjer ikke hjælpe med denne opgave. Det betyder yderligere udvikling tid og mere kode til at støtte. Når trin for at oprette samlede tabeller er sprunget, forespørgslen ydeevne derefter lider, fordi de større detaljerede tabeller skal spørges. Dette kan delvis afhjælpes ved at tilføje yderligere samlede tabeller, men det er stadig ikke praktisk muligt at skabe samlede tabeller for alle kombinationer af dimensioner / attributter. ROLAP bygger på det generelle formål database til at forespørge og caching, og derfor flere specielle teknikker ansat af MOLAP værktøj er ikke til rådighed (såsom særlige hierarkiske indeksering). Men moderne ROLAP værktøjer drage fordel af nyeste forbedringer i SQL sprog som CUBE og Rollup operatører, DB2 Cube Views, samt andre SQL OLAP udvidelser. Disse SQL forbedringer kan mindske fordelene ved MOLAP værktøjer. Da ROLAP værktøjer stole på SQL for alle de beregninger, de er ikke egnet, hvis modellen er for tung på beregninger, der ikke oversætte godt stykke ind i SQL. Eksempler på sådanne modeller inkluderer budgettering, tildelinger, regnskabsaflæggelse og andre scenarier. 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å. 7