Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Transkript

1 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010

2 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW... 4 Dårlige sider ved DW... 4 Arkitektur... 5 Database Management System... 5 Oracle... 6 Data Marts... 6 Design... 7 Dimensionality modeling... 7 Star schema... 8 Snowflake schema... 9 Starflake skema... 9 Side 2 af 9

3 Beskrivelse I forbindelse med undervisning I valgfaget Database for udviklere, er vi blevet stillet opgaven at fordybe os i et emne. Jeg har valgt at kigge på Data warehousing, da jeg finder fænomenet interessant. Jeg vil lave en gennemgang af Data warehouse(herefter refereret til som DW) generelt, med gode og dårlige sider ved DW for en virksomhed. Og jeg se på forskellene på Online Transaction Processing(herefter refereret til som OLTP). Jeg vil kigge på hvilken slags Database man skal vælge, og i den forbindelse vil jeg også kigge på Oracle som er en af de førende inden for DW. Jeg vil også kigge på Data Marts, som er en mindre del af et DW. Jeg vil se på design af DW, jeg vil kigge på de forskellige diagrammer, som man bruger til at lave databasen ud fra. Data warehouse Generelt DW er et begreb man bruger om en database hvor man gemmer gammelt data, som man ikke skal bruge i hverdagen, men skal bruge til at tage organisations beslutninger ud fra analyser. DW hed oprindeligt information warehouse, hvilket er et ret beskrivende navn, da det indeholder informationer der er statiske, og derved kan man til enhver tid få fat i informationerne. Sammenligning Hvis man ser på OLTP og DW, så er der kæmpe forskelle. DW indeholder gammelt data, hvor OLTP indeholder nuværende data. I OLTP kan man ændre i dataene, hvor i DW er det statisk data, for at man altid har det originale data. Det er forskelligt hvordan man opdeler dataene på, hvor man i OLTP, vil opdele dataene efter hvilken område dataene tilhører f.eks. regninger, ordre, varelager, osv., så vil man i DW dele op efter hvilken type det er f.eks. produkter, salg, kunder, osv.. I OLTP har man detaljeret data i sin database, hvorimod i DW har man ofte data der er en summering af data, for at spare plads, og fordi det er nemmere at analysere. I OLTP bruger man få enkle efterspørgsler der bliver gentaget ofte, hvor man i DW bruger man forskellige, alt afhængig af hvilke informationer man er ude efter. Man kan spørge efter f.eks. sidste års omsætning i et område, men det kunne også være at man vil vide, hvor meget en sælger i et område har omsat for i et bestemt kvartal. En DW database er optimeret til at kører få komplekse analyser, hvorimod man i OLTP optimere til at kører mange transaktioner. Man har i DW få brugere der har adgang til databasen, da den ikke er optimeret til at skulle udføre mange analyser, og for at undgå at den bliver belastet unødigt, for at undgå at brugerne får lange svar tider. Ved OLTP har mange brugere med adgang på forskellige niveauer. Side 3 af 9

4 Gode sider ved DW Der er mange fordele ved at lave et DW som virksomhed, for det første så er man sikker på at få den mængde tid og de penge man har ofret på projektet igen. Man vil hvis det bliver brugt rigtigt kunne spare tid i forbindelse med, gennem analyse af data vil man nemmere kunne tage beslutninger, som f.eks. skal reklameres mere i bestemte områder eller skal man tage andre metoder i brug. Man vil også kunne øge produktiviteten, ved hjælp af at få et samlet overblik over ens organisation. Ved at man får adgang til data fra alle afdelinger af virksomheden. Derved har man adgang til data, som tidligere kun var brugere fra de enkelte afdelinger der havde adgang til. Dårlige sider ved DW Når man implementere skal man have med i sine overvejelser, at det kræver mange resurser at trække data ud af en database, hvorefter at man skal have dataene sorteret, muligvis ændre formatet og man skal gemme dataene i DW databasen. Man kan bl.a. hente data fra en OLTP database, og der kommer dataene applikations orienteret, derfor kan der være formater der ikke passer sammen med data fra andre tabeller, der indeholder data, der i en DW database hører sammen. Der kan være problemer i de eksisterende systemer, som man så skal vælge enten at ændre eller tage højde for i DW databasen. Det kan bl.a. være at der i det eksisterende system er steder hvor man tillader null hvor man i DW skal bruge den information. I nogle tilfælde opdager man også, at der ikke bliver skrevet de informationer ind fra de gamle systemer som faktisk er nødvendige, til at lave de analyser som man har tænkt DW systemet til. Når man har implementeret DW, vil man ofte opdage at når brugerne får adgang til systemet, vil kravet til systemet stige, da brugerne finder ud af flere ting, som systemet kan gøre for dem. DW bliver ofte designet ud fra nogle modeller som gør at man får nogle meget store tabeller, som optager meget disk plads, det skaber et større krav til disk størrelse. Der er meget vedligehold ved en DW database, for når der sker ændringer systemet hvor dataene bliver hentet fra, så skal der tages højde for det i databasen. Side 4 af 9

5 Arkitektur Figur 1: Eksempel på arkitektur Mange DW systemer er opbygget efter denne model. Hvor man henter alle informationer fra de forskellige databaser og filer, ved hjælp af det man kalder Load manager. Inde i warehouse bliver dataene gemt, enten som de bliver hentet med alle detaljer, eller som summeret data. For at man kan holde styr på hvor dataene kommer fra og hvad der er gjort ved dem, har man det der hedder metadata. Og til sidst har man End-user værktøjerne, som har forbindelse til Warehouse gennem Query manager, som udfører alle kommandoerne. Værktøjerne er det som brugerne af systemet bruger til at analysere data, lave rapporter eller data mining. I de fleste systemer der er også koblet et arkiv/back-up system på, så man ikke mister data hvis der sker fejl i systemet, og man har fjernet dataene fra det andet system man har kørende. Database Management System DBMS som det også bliver kaldt, er kort sagt en samling af programmer der styre alt i forbindelse med en database, lige fra oprettelse, til vedligeholdelse og brugen af databasen. Når man skal vælge hvilken database man skal bruge, skal man se på kravene som der bliver stillet i forbindelse med DW. Dataene skal hentes hurtigt ind, da man kun har korte tidspunkter hvor det er muligt at gøre det. Når man har hentet dataene skal de bearbejdes, de skal filtreres, tjekkes, format skal ændres, indekseres og metadata skal opdateres. Selvom det ikke er store komplekse operationer, så skal det helst kører så glat som muligt. Man skal derudover også sørge for at man beholder kvaliteten af dataene, også selvom de kommer fra dårlige kilder. Man skal også have med i sine overvejelser at databaserne stiger i størrelse, og at man med tiden vil få flere og flere brugere i systemet. DW skal også fungere i store netværk, hvor der skal holdes styr på hvor dataene bliver flyttet hen i forskellige subnet, så man kan tilgå flere DW s fra et sted. Side 5 af 9

6 I flere tilfælde er der en vis tid man skal gemme data før de kan slettes. F.eks. fakturaer og regninger. Det kan bl.a. være noget der skal bruges til skattevæsnet eller lignende. Man kan ved hjælp af parallelle databaser, klare nogle af de problemer som har med ydelsen at gøre. De kan dele operationer imellem sig, og derved udføre flere ting hurtigere og simultant. Der er to forskellige Symmetric Multi-Processing(SMP) og Massively Parallel Processing(MPP), SMP har et set tæt sammenbundne processorer og deler resten, hvor MPP har nogle et set processorer der er bundet løst sammen og har egen hukommelse og disk plads. Man bruger Relationelle databaser til DW, da de har hvad man har brug for. En af de relationelle DBMS er der er på markedet er Oracle, som jeg vil snakke om i det følgende afsnit. Oracle Oracle er en af de førende i Relationel DBMS, Relationel er kort sagt, at dataene er gemt i tabeller der har relationer til hinanden. F.eks. på figur 4, der kan man se at ProduktSalg hænger sammen med Ansatte ved at have ansatid og Ansatte har forbindelse til PostBy ved at have postnr. Oracle er en af de førende indenfor DW databaser, de har opnået det ved at fokusere på basis tingene ved Data Warehousing: ydelse, skalering og styring. Oracle har forstået at vejen frem er at DW s bliver større, med flere brugere og at folk forventer hurtige svar tider. For at efter komme kundernes efterspørgsler, tilbyder Oracle en væld af query udførelses teknikker og query optimering, for at få de hurtigste svar tider og de udnytter parallel hardware konfigurationer fuldt ud. Data Marts Data mart er en mindre del af et helt DW, man laver ofte Data Marts, for at kunne få implementeret DW, da man hurtigere kan lave et Data Mart, som man laver til en enkelt afdeling af en virksomhed, som kan blive taget i brug før hele systemet er færdigt. Når man laver Data Marts er det for at have små simple databaser, der er lette af styre. Men de bliver udbygget jo mere de bliver brugt, da brugerne finder flere ting som de skal kunne. Det gør også at de bliver langsommere. Man har oftest heller ikke detaljeret data i et Data Mart. Side 6 af 9

7 Figur 2: Data marts På figur 2 ses, det samme som på arkitektur diagrammet, dog med data marts og med staging area, er en form for Load Manager, den henter dataene ind og rydder op i det, det hjælper Load manageren. Som man kan se har brugerne de forskellige værktøjer, som har kontakt til data marts. Der er flere grunde til at lave et Data Mart, man kan optimere et data mart til en afdeling, så brugerne får adgang til det de analysere oftest. Man kan giver mere struktureret data, som kan bruges til at opfylde Online Analytical Processing (Herefter refereret til som OLAP) værktøjers krav. Data marts bruger mindre data, så derfor kan ting som at hente, rensning, ændring af formater, og integration af data ske hurtigere. Det er billigere at implementere et Data mart i forhold til et virksomheds bredt DW. Der er også problemer i forbindelse med Data Marts, eftersom brugerne forventer hurtigere svar tider, men for at skaffe brugerne hurtige svar tider, laver man summerede tabeller, men det kræver meget at lave den slags tabeller. Og jo flere Data Marts man implementere i en virksomhed, jo mere besværligt bliver det at styre og koordinere Data Mart aktiviteterne centralt. For når dataene er kopieret til et Data Mart bliver dataene ændret, så de kan analysere dem på forskellige måder. Design I en OLTP database bruger man Entity-Relationship model, til at finde relationerne mellem tabellerne og finde redundante data, for at man kan få det lagt ud i tabeller for sig selv. Hvorimod en Dimensionality model(herefter refereret til som DM), går efter at lave en database der kan tilgås af flere forskellige værktøjer uden problemer, mulighed for at håndtere ændringer for at opfylde brugernes krav, den skal kunne udvides f.eks. med flere informationer, tilføjelse af flere tabeller eller opdeling af eksisterende tabeller. Dimensionality modeling Man bruger DM, til at mappe en DW database. At mappe en DW database er komplekst, da man ikke som med en almindelig database deler den op efter afdelinger, men netop skal samle det hele i en database. Side 7 af 9

8 DM er som Entity-Relationship model baseret på en række vigtige restriktioner. Alle DM er består af en tabel der består af en sammensat primær nøgle, som hedder fact table, derudover er der Dimension tables, der indeholder én ikke sammensat primær nøgle. Den sammensatte primær nøgle kommer fra to eller flere fremmed nøgler. Den struktur man får ud fra DM er en stjerne lignende diagram, som derfor kaldes Star Schema eller Star join. Figur 2, er et eksempel på et Star schema, hvor ProduktSalg er fact table og de andre er Dimension tables. Star schema Herunder en lille del af et helt DW, man vil ud fra dette skema kunne oprette et data mart. Figur 3: Star schema Som man kan se er Star Schema et denormaliseret, det vælger man at gøre, for at optimere query udførelserne, da det giver kortere svar tider hvis dataene er ligger unormaliseret. Dog tager det mere plads, da man har det samme data liggende flere gange. På ProduktSalg kan man se de forskellige fremmed nøgler markeret med {FK}, det er ud fra dem, man vil lave en primær nøgle i fact tabellen. Hvis man ser på Ansatte tabellen, så indeholder den postnr og by, som man i en OLTP database ville ligge i en tabel ved siden af, som gjort på figur 3. Side 8 af 9

9 Snowflake schema Herunder ses et uddrag af et Snowflake schema, det er fact tabellen og ansatte tabellen, jeg har taget udgangspunkt i. Figur 4: Snowflake schema Forskellen fra Star og Snowflake er at man normalisere dataene, så man laver tabeller til redundante data. Man vil i andre tilfælde kunne trække flere informationer ud, og derved får man flere tabeller koblet på, og derved vil det skabe et snefnug lignende billede. Starflake skema Starflake er en blanding af Star og Snowflake, man har nogle af tabellerne normaliseret og andre denormaliseret, det kan gøres fordi man vil optimere svar tider på bestemte områder, og minimere størrelsen af tabeller på andre områder. Side 9 af 9