DT4300 Datavarehus og datagruvedri3

DT4300 Datavarehus og datagruvedri3 14/1 2014 Trond Aalberg 1 Dagens tema Datavarehus: hva og hvorfor, generell arkitektur, OLAP vs OLTP MulFdimensjonale data Datakube som logisk modell for datavarehus, dimensjoner og hierarkier, funksjonalitet og operasjoner Modellering Stjerneskjema, snøflakskjema Design og implementasjon MOLAP og ROLAP, indeksering 2 1

Data som strategisk informasjon Bedri3er har behov for informasjon for å ta strategiske avgjørelser, for å være konkurransedykfge og raskt kunne Flpasse seg endringer i markedet Eksplosiv vekst i mengden data som skapes og lagres, men også store endringer i teknologien som kan brukes for å lagre og prosessere data Fra 1990 og utover har det vært stor fokus på data og systemer som er retet mot beslutningstagere, markedsføring etc. (descision support, business intelligence, knowledge management, customer relafonship management) Datavarehus handler om hvordan vi kan samle inn data, modellere, lagre og gjøre data Flgjengelig for analysering 3 Datavarehus (Data Warehouse) Oppstod som begrep rundt 1990 med økt fokus på databaser og data som kunne brukes i analyser og beslutningsstøte Ingen fasit- definisjon, men kan beskrives som Database for beslutningsstøte som er separat fra en organisasjons operasjonelle database Konsoliderte, historiske data som kan brukes i analyser A data warehouse is a subject-oriented, integrated, timevariant, and nonvolatile collection of data in support of management s decision-making process. W. H. Inmon Eller som verb: Data Warehousing Prosessen å konstruere og bruke datavarehus 4 2

Subject- oriented Organisert rundt viktige emner/tema som kunder, produkter, salg Fokus på modellering og analyse av data for beslutningstagerne, IKKE daglige operasjoner eller transaksjoner Gir en enkel og konsistent oversikt over aspekter ved emnene, ved at data som er uvesentlige for beslutningene utelates. 5 Integrated Konstrueres ved å integrere data fra mange forskjellige kilder Relasjonsdatabaser, dokumenter, transaksjonsposter Data vaskes og det brukes teknikker/ metoder for å integrere dataene Sikre konsistens i navngiving, koding av verdier, måleenheter osv. Data konverteres når de flytes Fl et datavarehus 6 3

Time- Variant 7 Tidshorisonten for datavarehus er vesentlig lengre enn for et operasjonelt system En operasjonell database gir deg nåværende dataverdier Data i datavarehus gir deg informasjon i et historiske perpekfv (for eksempel de siste 5-10 år) VikFge datastrukturer i et datavarehus Har elementer av Fd, eksplisit eller implisit Selv om nøkkelatributene ikke bestandig inneholder FdsaTribuT(er) Non- volafle 8 Et fysisk separat lager av data som er transformert fra operasjonelle data Ingen operasjonelle oppdateringer F.eks. ingen endringer ved de daglige transaksjonene Ingen transaksjonshåndtering, recovery eller concurrency control Kun nødvendig med to operasjoner: LasFng av data og prosessering av data 4

OLAP og OLTP Vi sammenligner gjerne datavarehus <- > operasjonelle databaser OLAP <- > OLTP OLAP: online analyfcal processing OLTP: online transacfon processing 9 OLTP vs. OLAP OLTP OLAP users clerk, IT professional knowledge worker function day to day operations decision support DB design application-oriented subject-oriented data current, up-to-date detailed, flat relational isolated usage repetitive ad-hoc historical, summarized, multidimensional integrated, consolidated access read/write lots of scans index/hash on prim. key unit of work short, simple transaction complex query # records accessed tens millions #users thousands hundreds DB size 100MB-GB 100GB-TB metric transaction throughput query throughput, response 10 10 5

11 Hvorfor et eget datavarehus Høy ytelse for begge system DBMS: kan Flpasses ytelsesmessig for OLTP: aksess, indeksering, concurrency, recovery, normalisert for å unngå redundans etc. DW: Flpasset OLAP, komplekse queries, konsoliderte data, flerdimensjonale views Forskjellige data og forskjellige funksjoner Data som mangler: beslutningsstøte krever data som typisk ikke er direkte Flgjengelig i den operasjonelle databasen Innsamlet og bearbeidet: beslutningsstøte krever data som er aggregert og generalisert fra flere kilder Data kvalitet: data fra flere kilder er o3e inkonsistente, og bruker verdier og koder som må samordnes (Men det kommer flere og flere systemer som gjør OLAP mulig mot operasjonelle relasjonsdatabaser) Generell arkitektur og prosesser (mulf- Fer) Andre kilder OLAP verktøy Operasjonelle DBs Ekstraher Transformer Last opp Legg til DATAVAREHUS Bruk Analyser Spørringer Rapporter Datagruvedrift OLAP verktøy Data marts Datakilder Datalagring Prosessering 12 6

AlternaFv illustrasjon 13 Tre modeller Enterprise varehus Inneholder data om alle emner som dekker hele virksomheten Data mart Hver mart (marked) er et subset av virksomhetens totale varehus, og inneholder bare det som er av interesse for en subgruppe, underavdeling etc Virtuelle varehus Verktøy som gir deg datavarehus data/funksjonalitet på toppen av operasjonelle data Kan være begrenset hva som kan gjøres 14 7

Ekstrahering, Transformering og LasFng (ETL) 15 Dataekstrahering Hente data fra forskjellige kilder Datavasking Oppdage feil og rete hvis det er mulig Datatransformering Konverter Fl formater som datavarehuset er basert på InnlasFng Sorter, summer, konsolider, beregn utsnit, sjekk dataintegritet, indekser og parfsjoner Oppdater Sørg for at oppdateringer i operasjonelle data integreres i datavarehuset periodiske Datakube Datavarehus og OLAP systemer er basert på en flerdimensjonal datamodell fokus på data og dimensjoner for aspekter ved dataene øker forståelsen av hvordan data brukes i analyser og er Flpasset de operasjoner og ytelseskrav som trengs i komplekse analysespørring Modellen ser data i et n- dimensjonalt rom Kalles datakube (data cube) Eller hyperkube (hypercube) 16 8

Datakuben med dimensjonene: region, produkt, Fd region produkt tid 17 Data i n- dimensjoner En flerdimensjonal datamodell er typisk organisert rundt et sentralt tema, f.eks. SALG (salgstall) Hvor dimensjonene er atributer ved salg som vi er interessert i å analysere salgstall i kontekst av Tid, produkt, avdeling, sted Hvor mange produkter er solgt per måned, hvor mye har hver avdeling solgt for etc. For hver dimensjon kan vi ha egne tabeller med mer detaljer f.eks. om produktet (navn, merke, type) 18 9

Noen eksempler 19 Fra 2- D Fl n- D De fleste som har jobbet med regneark er vant Fl 2- dimensjonal presentasjon av data IntuiFvt måte å presentere f.eks. salgstall for av forskjellige produkter over Fd 21 10

Legge Fl en tredje dimensjon Hvis vi i Fllegg er interessert i hvordan salgstallene er distribuert over forskjellige utsalgssteder må vi legge Fl en tredje dimensjon Da blir det vanskelig å presentere det i 2D, men fortsat innenfor det vi kan se for oss i hodet Kan for eksempel vises som en serie 2- D tabeller 22 Flere dimensjoner 23 3- dimensjonale data kan også visualiseres som en 3- D kubestruktur Hver celle et punkt i et koordinatsystem med tre akser En 4de dimensjon kan visualiseres med en slik kube for hver dimensjonsenhet Men der stopper vel våre muligheter Fl å presentere dete grafisk ;- ) 11

NeT av cuboids Slike datakuber kalles o3e cuboids (rektangulær boks) I praksis har vi behov for å dynamisk kunne velge hvilke dimensjoner vi er interessert i å analysere En overordnet kube av n- dimensjoner kan brukes Fl å generere forskjellige cuboids basert på subset av dimensjoner - > 2 n cuboids for n dimensjoner 24 NeT av cuboids Økende grad av summering av data 25 12

Modellering Den tradisjonelle ER modelleringen som brukes i utvikling av databaser er best egnet for OLTP I modellering av datavarehus tenker vi lit annerledes Selv om vi fortsat bruker tabeller og nøkler i modelleringen Vanlige modeller for flerdimensjonale data Stjerne skjema (star schema) Snøflak skjema (snow flake schema) Fakta sammensflling (fact constellafon) (Alle er i praksis basert på samme prinsipp) 26 Stjerneskjema En sentral fakta- tabell med verdiene (målingene) vi er interessert i Egne tabeller rundt for hver dimensjon Faktatabellen har også nøkler Fl dimensjonstabellen Egentlig en ganske lejorståelig modell ;- ) Danner et slags stjernemønster derav navnet 27 13

Eksempel 28 Merk Det som kjennetegner stjerneskjema er at hver dimensjon er representert med en tabell Som inneholder atributer for dimensjonen Ingen normalisering av dimensjonene I praksis kan dete føre Fl redundans Men dete er sjeldent et problem Dimensjonene utgjør en liten del av dataene (1-5%) Data o3e er vasket, transformert og skal ikke endres Gjør det enklere å skrive spørringer og gir bedre ytelse 29 14

Snøflak Er egentlig bare en utvidelse av stjerneskjema Hvor noen dimensjoner er normalisert I noen Flfeller kan det være en fordel å normalisere enkelte dimensjoner En annen fordel er at dimensjonens hierarkiske organisering blir mer eksplisit 30 Eksempel 31 15

Fakta- sammensflling 32 Datavarehus kan inneholder data om flere tema men hvor dimensjonene er felles for flere faktatabeller Når vi seter sammen flere stjerne eller snøflak- modeller som deler en eller flere dimensjoner får vi en fact constellafon modell Eller hvis vi vil ha et mer ambisiøst navn: Galaxy schema Eksempel 33 16

Konsept- hierarkier 34 I dataanalyser er vi o3e interessert i forskjellig granularitet ved dimensjonene For salgstall i relasjon Fl sted kan vi være interessert i land, by, distrikt, utsalgssted etc. Dimensjonene kan o3e sees som konsept- hierarkier Fra et toppnivå- konsept som summerer alle verdiene for denne dimensjonen, Fl det mest spesifikke nivået hvor data er på sit mest detaljerte Gir yterligere kompleksitet Fl kubemodellen siden vi i praksis ønsker varierende aggregering av verdier innen dimensjonene Konsepthierarkier Mange er implisit git i dimensjonstabellen Andre kan generes automafsk ved å klassifisere og gruppere dimensjoner eller atributer Kan være strikte hierarkier, eller netverk Det vikfgste er at de er ordnet i en rekkefølge 35 17

Eksempler 36 Hierarkier er en essensielle Slike hierarkier gir oss en vikfg funksjonalitet Muligheten Fl å definere grad av summering/aggregering av data Eller umorske detaljer ved dataene Fokus på effekfviteten ved slike operasjoner i impelementasjonen av datavarehus 37 18

Kategorisering og beregninger 38 Forskjellige data gir grunnlag for forskjellige beregninger For salgstall er eksempelvis behov for å summere når vi går oppover i et konsepthierarki Et punkt i kuben kan defineres med et set av dimensjon- verdi par Men verdiene (measures) vi er interessert er noe vi o3e må beregne Forskjellige beregninger Distribuerende aggregering vi kan stykke opp beregningen på delse5 og får samme resultat som ved å u8øre beregning på hele se5et F.eks. sum(), count(), min(), max() Algebraisk aggregering Vi kan bruke en funksjon med M argumenter, men hvor hvert argument er distribuerende aggregering avg() - > sum()/count() HolisJsk En aggregerende funksjon som vi må u8øre på hele se5et for at det skal bli rikjg median(), rank(), mode() (mode er den verdien som forekommer o3est) 39 19

Typiske OLAP operasjoner 40 Roll- up Roll- up betyr å bevege seg oppover et konsept- hierarki, eller foreta reduksjon av dimensjoner I praksis aggregering av data, vi går fra detaljerte data Fl mindre detaljert Drill- down er det motsate av roll- up Går et trinn ned I konsepthierarkiet eller inkluderer en dimensjon Fl Går fra overordnede data Fl mer spesifikke data Slice and Dice Slicing er å velge ut en dimensjon slik at vi får en subkube Dicing er å velge ut en subkube med to eller flere dimensjoner Pivot Er å rotere dataene slik at vi får et annet view hvor aksene er organisert annerledes 41 20

Starnet 42 Starnet- modellen er en måte å vise hvilke spørringer vi kan gjøre Mht. dimensjoner og konsepthierarkier Hver dimensjon er en akse, med punkter for konseptene i hierarkiet Aksene viser hva vi kan gjøre av drill- down eller drill- up Spørringer To retninger av egne språk for OLAP- spørringer Utvidelser Fl SQL OLAP SQL med en egen CUBE operator En generalisering av group by som aggregerer på dimensjoner og totalen Egne spørrespråk som MDX MulFDimensional expressions SELECT x, y, sum(v)! From FactTable GROUP BY CUBE(x, y)! SELECT! { [x].members, [x].[all x1] } ON COLUMNS,! { [y].members, [y].[all y1] } ON ROWS! FROM [TheCube]! WHERE ([Measures].[s])! Men det er også mange som fokuserer på grafiske grensensit og interakfve tabeller, grafer oa. 43 21

Implementasjoner 44 ROLAP RelaFonal OLAP servers Bruker relasjonsdatabaser som backend (eller utvidede relasjonsdatabaser) Implementerer aggregering og navigeringslogikken på toppen av dete Med opfmalisering retet mot OLAP EffekFv lagring av data, men mer krevende å opfmalisere MOLAP MulFdimensional OLAP servers Array- baserte flerdimensjonale datalagringssystemer BenyTer en datakube struktur internt Raks indeksering og effekfv forhåndsberegning Men siden kuber o3e har mange tomme celler er det lite effekfvt mht. lagringsplass ROLAP implementasjoner Fra flate tabeller Fl aggregerte data for en dimensjon (og et git nivå i hierarkiet) Kan genereres fra tabeller i relasjonsdatabaser Basert på stjerne- skjema Ved hjelp av group by SELECT levels, sum (measure)! FROM facttable joined with dimension table! WHERE some condition! GROUP BY levels! Generelt et Fdkrevende query siden vi bruker store deler av faktatabellen 45 22

Views 46 Er en teknikk for å opprete en virtuell tabell over eksisterende data med create VIEW En variant av denne hvor den nye tabellen lagres er MATERIALIZED VIEW Et slikt VIEW kan igjen brukes i andre aggregeringer Umordringen er å sete opp det opfmale setet av forhåndsberegnede aggregeringer og vedlikeholde ved nye lasfnger av data Indeksering EffekFve indekser Flpasset OLAP er et annet område som har hat mye fokus Gjelder både ROLAP og OLAP Faktatabeller har o3e mange indekser Typisk en for hver dimensjonstabell Og for dimensjoner som o3e brukes sammen StøTe for B- tree indekser finnes i de fleste databaser Løvnodene inneholder liste av ROWID For OLAP er det andre indekser som kan være mer effekfve fordi atributet som indekserer typisk har få disfnkte verdier 47 23

Bitmap indekser Vi trenger en bit for hver unik verdi som setes Fl 1 hvis verdien finnes ellers 0 Kolonnenen i bit- tabellen brukes Fl oppslag hvor plassen Fl en bit i sekvensen samsvarer med en ROWID Krever lite plass og er veldig effekfv ved få verdier 4 mulige verdier og 100.000 rader i faktatabellen = 4 x 100.000 bits Egnet for få verdier, men mindre effekfvt ved større antall verdier Direkte støte for boolske operasjoner AND, OR og NOT 48 Join indekser Rader som kan joines i to relasjoner registreres og dermed unngåes relafvt kostbare join- operasjoner Er best egnet for data som ikke oppdateres 49 24

Oppsummering LiT intro om datavarehus Vi har tat for oss forskjellige sider ved kube- modellen I praksis er kuben bare en metafor som forenkler forståelsen av flerdimensjonale data VikFg å få en grunnleggende forståelse av denne måten å modellere og organisere data på Er et fundament for utvikling og bruk av datavarehus 50 25

Oppgåve Suppose that a data warehouse for Big University consists of the following four dimensions: student, course, semester, and instructor, and two measures count and avg grade. When at the lowest conceptual level (e.g., for a given student, course, semester, and instructor combination), the avg grade measure stores the actual course grade of the student. At higher conceptual levels, avg grade stores the average grade for the given combination. Task: Draw a snowflake schema diagram for the data warehouse. 14

Mogleg løysing 15 Suppose that a data warehouse for Big University consists of the following four dimensions: student, course, semester, and instructor, and two measures count and avg grade. When at the lowest conceptual level (e.g., for a given student, course, semester, and instructor combination), the avg grade measure stores the actual course grade of the student. At higher conceptual levels, avg grade stores the average grade for the given combination.