Data Warehousing Dag 1 formiddag Christian S Jensen

Data Warehousing Dag 1 - formiddag Christian S. Jensen og Torben Bach Pedersen Nykredit Center for Databaseforskning Aalborg Universitet www. cs. auc. dk/NDB © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001

Kursusindhold – torsdag • Introduktion n n Hvorfor Business Intelligence? Deltagerintroduktion og diskussion. • Multidimensionelle modelbegreber n n Præsentation Øvelser • Avancerede multidimensionelle begreber II n n Præsentation Øvelser © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 2

Business Intelligence oversigt • • Hvorfor Business Intelligence (BI)? Data analyse problemer Data Warehouse (DW) introduktion Analyseteknologier der bruger DW n OLAP Data mining Visualisering n Et godt DW er en forudsætning for at bruge disse teknologier n n © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 3

Hvad er Business Intelligence? • Sammensætning af teknologier n n n n Data Warehousing (DW) On-Line Analytical Processing(OLAP) Data Mining (DM) Data Visualisering (VIS) Decision Analysis (what-if) Customer Relationship Management (CRM) Vertikale løsninger sammensat af basisteknologierne • Buzzword compliant n Udvidelse/integration af ovenstående teknologier • Det modsatte af Artifical Intelligence (AI) n n AI systemer træffer beslutningen for brugerne BI systemer hjælper brugerne med at træffe den rigtige beslutning, baseret på de tilgængelige data © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 4

BI bliver stadig vigtigere • Meta Group: DW alene = $15 mia. i 2000 • Palo Alto Management Group: BI = $113 mia. i 2002 • Web udviklingen gør BI mere nødvendigt. n n Kunderne kommer ikke ”fysisk” i forretningen. Kunderne kan nemt skifte til andre. • Derfor n n n Kend dine kunder v. h. a. data og BI! Weblogs gør det muligt at analysere kundeadfærd mere detaljeret. Kombiner Webdata med traditionelle kundedata. • Næste skridt hedder Wireless Internet n n n Kunder er ”på” hele tiden. Man kender kundens position. Kombiner position med kundekendskab => store muligheder! © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 5

Dataanalyse problemer • De samme data findes i mange forskellige systemer n n Eksempel: kundedata i 14 systemer! Det samme begreb er defineret forskelligt • Data er rettet mod operationelle systemer (OLTP) n n Bogholderi, fakturering, o. s. v. Understøtter ikke analyser på tværs • Data har dårlig kvalitet n Manglende data, upræcise data, forskellig brugerpraksis • Data er ”ustabile” n n Data slettes i de operationelle systemer (6 måneder) Data rettes over tid - ingen historik © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 6

Data warehousing • Løsning: nyt analysemiljø (DW) hvor data er n n n Emneorienterede (versus funktionsorienterede) Integrerede (logisk som fysisk) Stabile (data slettes ikke, flere versioner ved rettelser) Tidsvariante (data kan altid henføres til tid) Understøtter ledelses-beslutninger (anderledes organisering) • Data fra de operationelle systemer n n n Udtrækkes Renses Transformeres Aggregeres Læses ind i DW • Et godt DW er en forudsætning for succesfuld brug af BI © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 7

DW begreber Eksisterende databaser og systemer (OLTP) Nye databaser og systemer (OLAP) Appl. DM DB OLAP Appl. DB DM Trans. DW Data Warehouse Appl. Data mining DM DB Visualisering Data Marts Appl. DB © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 8

OLAP • OLAP = On-Line Analytical Processing n n n Interaktiv analyse Eksplorativ opdagelse Kræver hurtige svartider • Data er organiseret som multidimensionelle terninger n n Terninger/kuber kan have et vilkårligt antal dimensioner Dimensioner har hierarkier, f. eks. dag-måned-år • OLAP operationer n n n Sammentælling/summering af data, f. eks. med SUM Startniveau, (Kvartal, Produkt) Roll Up: mindre detalje, Kvartal->År Drill Down : mere detalje, Kvartal->Måned Slice/Dice: selektering, År=1999 Drill Across: “join” på fælles dimensioner © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 9

OLAP eksempel • 5, 5 millioner clicks n Alligevel er der hurtig svartid © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 10

Data Mining • Data mining er automatisk vidensopdagelse • Klassificering n Inddel data ind i foruddefinerede klasser • Forudsigelse n Forudsig/estimer ukendt værdi baseret på lignende tilfælde • Sammenligning n Finder ligheder/forskelle imellem klasse og konstrastklasse • Gruppering n Inddel data i grupper så ligheden indenfor de enkelte grupper er størst mulig og ligheden mellem grupperne er mindst mulig • Sammenhænge n n Finder sammenhænge/afhængigheder mellem data Regler: A -> B (c%, s%): hvis A optræder, optræder B med konfidens c og støtte s © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 11

Data Mining Eksempler • Walmart: USAs (og verdens) største supermarkedskæde n n n Har DW med alle kassetransaktioner for de sidste 2 år (70 TB!) Bruger BI (bl. a. mining) intensivt for at opnå forretningsfordele Analyse af sammenhænge indenfor kassebon’er u u n Opdagelse: Øl og bleer ofte på samme bon Mænd køber bleer med hjem, og skal ”lige ha’ en bajer med” Stil de dyre øl ved siden af bleerne Stil øl et stykke væk fra bleerne, med chips og videofilm imellem! Walmarts leverandører bruger DW til at optimere varelevering u u Leverandøren stiller selv varen op på hylden Leverandøren får først betaling når varen bliver solgt • Weblog mining n n n Hvad er sammenhængen mellem tid på dagen og requests? Hvilke brugergrupper tilgår mit websted? Hvor mange requests får mit websted om en måned? © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 12

Visualisering • Grafisk fremstilling af komplekst resultat • “Manuel” (synsbaseret) vidensopdagelse • Grafiske virkemidler fremmer overblik og forståelse n n n Farve Størrelser Form • Visualisering gør det muligt at forstå høj-dimensionelle sammenhænge n 3 dimensioner + størrelse + farve = 5 dimensioner © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 13

Visualisering eksempel 14

Opsummering • • Hvorfor Business Intelligence? Data analyse problemer Data Warehouse (DW) introduktion Analyseteknologier der bruger DW n n n OLAP Data mining Visualisering • BI kan give din virksomhed store fordele n n Et godt DW er en forudsætning for BI Men, et DW er et middel snarere end et mål…det er først når det bliver brugt flittigt at man får succes © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 15

Deltagerdiskussion • Hver deltager bedes kort præsentere n n Sig selv Deres baggrund mht. data warehousing Deres firmas tekniske DW arkitektur Hvad man vil bruge DW og BI til © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 16

Kursusindhold – torsdag • Introduktion n n Hvorfor Business Intelligence? Deltagerintroduktion og diskussion. • Multidimensionelle modelbegreber n n Præsentation Øvelser • Avancerede multidimensionelle begreber II n n Præsentation Øvelser © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 17

Begreber oversigt 1 • • • Motivation Kuber Dimensioner Facts Measures Data warehouse forespørgsler Relationelt design Redundans Styrker og svagheder ved den multidimensionelle model © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 18

Begreber oversigt 2 • Kube design metode 1) 2) 3) 4) • Eksempel n • Vælg mart/forretningsproces Vælg granularitet Vælg dimensioner Vælg measures Supermarked mart Øvelse n Gentag eksemplet på clickstreams © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 19

Hvorfor en ny model? • Vi kender E/R - og OO modellering • Alle typer af data er “lige” • E/R og OO models: mange formål n n Fleksible Generelle • Ingen forskel på: n n Hvad der er vigtigt Hvad der bare beskriver det vigtige • ER/OO modeller er store n n 50 -1000 entiteter/relationer/klasser Bliver nemt uoverskuelige • ER/OO modeller implementeres i RDBMS n n Normaliserede databaser spreder information Når man analyserer data skal informationen samles igen © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 20

Den multidimensionelle model • Et formål n Data analyse • Bedre til det formål n n Mindre fleksibel Egner sig ikke til OLTP systemer • Mere indbygget “mening” n n Hvad er vigtigt Hvad beskriver det vigtige Hvad ønsker vi at optimere Automatiske aggregeringer giver nemme forespørgsler © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 21

Den multidimensionelle model • Data er inddelt i: n n Facts Dimensioner • Facts er det vigtige: et salg • Facts har measures som kan aggregeres: salgspris • Dimensioner beskriver facts n Et salg har dimensionerne Produkt, Butik og Tid • Facts “bor” i en multidimensionel kube (terning) n Tænk på et array fra programmeringssprog • Mål for dimensionel modellering: n n n Omgiv facts med så meget kontekst (dimensioner) som muligt Hint: redundans kan være ok (på udvalgte steder) Men man skal ikke forsøge at modellere alle sammenhænge i data (modsat E/R og OO modellering!) © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 22

Kube eksempel Århus 10 Viborg 1997 5 200 1998 23 Beer Cola © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 23

Kuber • En “kube” kan have mange dimensioner! n n Mere end 3 - begrebet ”hyperkube” bruges nogle gange Principielt ingen grænse for antal dimensioner Typiske kuber har 4 -12 dimensioner Mulige performanceproblemer ved mere end 10 -15 dimensioner • Men kun 2 -3 dimensioner kan ses ad gangen n Dimensionalitet reduceres af forespørgsler ved projektion/aggregering • En kube består af celler n n n En given kombination af dimensionsværdier En celle kan være tom (ingen data for denne kombination) En spredt (sparse) kube har få udfyldte celler En tæt (dense) kube har mange udfyldte celler Kuber bliver mere spredte for mange/store dimensioner © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 24

Dimensioner • Dimensioner er kernen i multidimensionelle databaser n Andre typer databaser har ikke støtte for dimensioner • Dimensioner bruges til n n Selektion af data Gruppering af data på det rette detaljeringsniveau • Dimensioner består af dimensionsværdier n n Produktdimension har værdierne ”Minimælk”, ”Letmælk”, … Tidsdimensionen har værdierne ” 1/1/2001”, ” 2/1/2001”, … • Dimensionsværdier kan have en ordning n n n Bruges til at sammenligne kube data på tværs af værdier Eksempel: ”beregn procentuel salgsfremgang ift. sidste måned” Især brugt for tidsdimension © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 25

Dimensioner • Dimensioner har hierarkier med niveauer n n n Typisk 3 -5 niveauer (detaljeringsgrader) Dimensionsværdier er organiseret i træstruktur Produkt: Produkt->Type->Kategori Butik: Butik->Område->By->Amt Tid: Dag->Måned->Kvartal->År Dimensioner har et bundniveau samt en topniveau (ALL) • Niveauer kan have attributter n n Simpel, ikke-hierarkisk information Dag har Hverdag som attribut • Dimensioner bør indeholde megen information n n Tidsdimensioner kan indeholde ferie, dag før ferie, årstid, vejr, … Gode dimensioner har 50 -100 eller flere attributter/niveauer © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 26

Begreber oversigt • • • Motivation Kuber Dimensioner Facts Measures Data warehouse forespørgsler Relationelt design Redundans Styrker og svagheder ved den multidimensionelle model © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 27

Facts • Facts repræsenterer emnet for den ønskede analyse n Det ”vigtige” i forretningen som man ønsker at analysere • Et fact identificeres oftest via dets dimensionsværdier n n Et fact er en ikke-tom celle Nogle modeller giver facts en eksplicit identitet (se PJD artikel) • Generelt skal et fact: n n Være tilknyttet én dimensionsværdi i hver dimension Kun være tilknyttet dimensionsværdier i bundniveauerne Nogle modeller kræver ikke dette (se PJD artikel) Hvis dette ikke gælder kan der opstå problemer (senere i kursus) © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 28

Typer af facts • Hændelsesfact (transaktion) n Et fact for hver forretningsbegivenhed (salg) • ”Fact-løse” facts n n n Et fact pr. hændelse (kundekontakt) Ingen numeriske measures Registrerer at hændelse er sket for given dimensionskombination • Tilstandsfact n n Et fact for hver dimensionskombination for givne tidsintervaller Registrerer nuværende status (lagerbeholdning) • Kumulative tilstandsfacts n n Et fact for hver dimensionskombination for givne tidsintervaller Registrerer kumulativ status op til nu (salg i år til dato) • Hver type facts giver svar på forskellige spørgsmål n Ofte både hændelsesfacts og begge slags tilstandsfacts samtidigt © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 29

Granularitet • Granularitet af facts er vigtig n n Hvad betyder et enkelt fact? Detaljeringsniveau Angivet ved kombinationen af bundniveauer Eksempel: ”samlet salg pr. butik pr. dag pr. produkt” • Vigtigt for antallet af facts n Betydning for skalerbarhed • Ofte er granulariteten den enkelte forretningstransaktion n Eksempel: salg Men nogle gange er data aggregerede (samlet salg pr. produkt pr. dag pr. butik) Kan være nødvendigt af hensyn til skalerbarhed • Generelt kan transaktionsdetalje håndteres n Undtagen måske for store clickstreams o. l. © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 30

Measures • Measures repræsenterer de fact-egenskaber som brugerne ønsker at studere og optimere n Eksempel: samlet salgspris • Et measure har to komponenter n n Numerisk værdi: (salgspris) Aggregeringsformel (SUM): bruges til at aggregere/kombinere et antal measureværdier til én værdi Measure værdi bestemt af dimensionskombination Measure værdi giver mening på alle aggregeringsniveauer • De fleste multidimensionelle modeller har measures n Nogle få har ikke (se PJD artikel) © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 31

Typer af measures • Der findes tre typer af measures • Additive n n n Kan aggregeres over alle dimensioner Eksempel: salgspris Optræder tit i hændelsesfacts • Semi-additive n n n Kan ikke aggregeres over nogle dimensioner - typisk tid Eksempel: lagerbeholdning Optræder tit i tilstandsfacts • Non-additive n n n Kan ikke aggregeres over nogen dimensioner Eksempel: gennemsnitligt salgspris Optræder i alle typer facts © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 32

DW forespørgsler • • Aggregering af data, f. eks. med SUM Startniveau: (Kvartal, Produkt) Roll Up: mindre detalje, Kvartal->År Drill Down: mere detalje, Kvartal->Måned Slice/Dice: selektering, År=1999 Drill Across: “join” på fælles dimensioner Visualisering af kube Undtagelser, f. eks. ”forbrug 10% over budget” • Bemærk: kun to slags forespørgsler n n Navigeringsforespørgsler undersøger én dimension Aggregeringsforespørgsler sammentæller fact data © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 33

Dokumentation af model • Ingen veldefineret standard • Multidimensional Domain Structure (MDS) diagrammer n n n Se separat slide Foreslået af Thomsen Viser strukturen af dimensioner og kuber • Vores egen notation n Ses til højre Ligger tæt op ad artiklerne T niveau svarer til ALL • Modelleringsværktøjer og OLAP systemer har deres egen notation © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 34

Kimball dimensionsnotation Calendar Year Calendar Quarter • Granulariteten er en dag. • Der er en implicit ”top” værdi, som betyder ”alle dage” eller ”hele tidsaksen”. n Den fås ved at undlade at nævne dimensionen i en forespørgsel Calendar Month Day © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 35

Begreber oversigt • • • Motivation Kuber Dimensioner Facts Measures Data warehouse forespørgsler Relationelt design Redundans Styrker og svagheder ved den multidimensionelle model © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 36

Relationelt design • Kuben implementeres ofte i et RDBMS n Relational OLAP (ROLAP) • Relationel teknologi valgt til DW på grund af: n n n Skalerbarhed Fleksibilitet Samspil/kompatibilitet med den øvrige IT infrastruktur • Fact-tabel(ler) gemmer facts n n n En kolonne for hvert measure En kolonne for hver dimension (fremmednøgle til dimensionstabel) Kombinationen af dimensionsnøgler udgør fact-tabel nøglen • Dimensionstabeller gemmer dimensioner n n Heltalsnøgle (surrogatnøgle) Flere typer af dimensionstabeller © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 37

Relationelt design • En helt denormaliseret tabel n n Dimensionsværdier gentages for hvert fact Dårligt: ufleksibelt, pladsforbrug, dårlig performance, opdateringer • Stjerneskemaer n n n En fact-tabel Denormaliserede dimensionstabeller En kolonne pr. niveau/attribut • Snowflaking n n n Dimensioner er normaliserede En dimensionstabel pr. niveau Hver dimensionstabel har heltalsnøgle, niveaunavn og en kolonne pr. attribut • Kombinationer af stjerne/snowflaking muligt © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 38

Stjerneskema eksempel

Snowflaking eksempel

Stjerneskemaer • • • + + + • • - Simple og nemt overblik -> nem brug Relativt fleksible Fact-tabel er normaliseret Dimensionstabeller ofte relativt små Forespørgsler på stjerneskemaer “genkendt” af mange RDBMSer -> god performance Hierarkier ”gemt” i kolonnerne Dimensionstabeller er denormaliserede

Snowflaking • • • + + + - Hierarkier bliver gjort eksplicitte/synlige Fleksible Dimensionstabeller bruger mindre plads Sværere at bruge (forespørge) pga. mange joins Dårligere performance

Redundans i DW • Kun meget lidt redundans i fact-tabeller n n n Typisk ved data af hierarkisk karakter Eksempel: ordrehoved data kopieret til ordre linie facts Samme fact data (generelt) kun gemt i én fact-tabel • Redundans er mest i dimensionstabeller n Stjerneskema dimensionstabeller har redundante værdier i de højere niveauer • Redundans problemer? n n n Inkonsistent data: den centrale load proces hjælper med dette Opdateringstid: DW optimeret forespørgsler, ikke opdateringer Pladsforbrug: dimensionstabeller bruger typisk <5% af DW plads • Altså: kontrolleret redundans er godt n Til en vis grænse… © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 43

Heltalsnøgler • Brug altid ”dumme” heltalsnøgler i DW dimensioner n n n Brug ikke nøgler fra produktionssystemerne! Generer nøgler som 1, 2, 3, … efterhånden som de bruges Viden om hierarkier skal ligge i dimensionerne - ikke i programmer! • Mange fordele n n Pladsforbrug: 1, 2 eller 4 bytes alt efter dimensionsstørrelse Produktionsnøgler kan blive genbrugt - også uden dit vidende! Format for produktionsnøgler kan/vil ændre sig over tid Hver dimensionsrække kan findes i flere versioner (senere) • Det gælder også for datofelter n n n Fylder op til 8 bytes, med heltal fylder 100 års dage kun 2 bytes Kun nyttig hvis SQL datofunktioner bruges i stedet for Tidsdimension - men det er en dårlig ide Ikke-standard værdier (ikke endnu, ved ikke, osv. ) ikke muligt © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 44

Styrker og svagheder • For den ”klassiske” multidimensionelle model • Styrker n n n Det er nemt at lave forespørgsler, joins m. m. er prædefinerede Det er umuligt at ”tælle forkert” Træstruktur i hierarkier muliggør hurtige forespørgsler • Svagheder/begrænsninger n n n Mange-til-en relationer fra fact til dimensioner Mange-til-en relationer fra lavere til højere hierarkiniveauer Hierarkier har fast højde Hierarkier ændrer sig ikke? Nogle værktøjer kan håndtere nogle af disse ting • Senere beskrives teknikker til at håndtere begrænsninger © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 45

Opsummering • Motivation • Kuber • Dimensioner med hierarkier n Eksempler (tid, kunde, produkt) • Facts n Typer af facts • Measures n Typer af measures • DW Forespørgsler • Relationelt design n Stjerneskemaer, snowflaking, heltalsnøgler • Redundans n Stjerneskemaer i forhold til konventionel normalisering • Styrker og svagheder ved den multidimensionelle model © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 46

Oversigt • Kube design metode 1) 2) 3) 4) • Eksempel n • Vælg mart/forretningsproces Vælg granularitet Vælg dimensioner Vælg measures Supermarked mart Øvelse n Gentag eksemplet på clickstreams © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 47

Eksempel: supermarked • Stock Keeping Units (SKUer) n En bestemt vare i en bestemt størrelse, emballage, osv. • Universal Product Codes (UPCs) n Identificerer SKUer på tværs af alle brancher • Kassesystem opsamler data • Butikker • Reklamer © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 48

DW design trin 1) Vælg forretningsproces/mart § Salg 2) Vælg granularitet forretningsprocessen § § § SKU pr. Butik pr. Reklame pr. Dag Fin granularitet er nødvendig Er individuelle transaktioner nødvendige/realistiske? 3) Vælg dimensionerne § Tid, Butik, Reklame, Produkt 4) Vælg measures n • Dollar_salg, styk_salg, dollar_omkostning, kunde_antal Modstå normalisering og bevar ”browsing” n Flade dimensionstabeller gør ”browsing” nem og hurtig © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 49

Supermarked dimensioner • Se separate slides • Tids dimension n Eksplicit tidsdimension er nødvendig (begivenheder, ferie, . . . ) • Produkt dimension n n Seks-niveau hierarki muliggør drill-down/roll-up Mange beskrivende attributter (ofte mere end 50) • Butik dimension n n Mange beskrivende attributter Tids dimension er en outrigger tabeller (først åbnet, . . ) • Reklame dimension n n Eksempel på en kausal dimension: er reklamer profitable Annoncer, rabatter, demonstrationer, kuponer (USA) u u Meget korreleret (kun 5000 kombinationer) Separate dimensioner? (størrelse&effektivitet vs. enkelthed&forståelse) © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 50

Supermarked measures • • • Dollar_salg Styk_salg Dollar_omkostning Alle additive over alle dimensioner Bruttoprofit n n Beregnet fra dollar_salg og dollar_omkostning Additive • Profitmargen n n Beregnet fra bruttoprofit og dollar_salg Non-additiv over alle dimensioner • Kunde_antal n n n Additiv over Tid, Reklame og Butik Non-additiv over Produkt Konklusion: semi-additiv © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 51

Database størrelse • Tids dimension: 2 år = 730 dage • Butiks dimension: 300 butikker rapporterer hver dag • Produkt dimension: 30, 000 produkter n Kun 3000 sælger på en given dag • Reklame dimension: 5000 kombinationer, n • • • Men et produkt er kun med i én kombination pr. dag Antal fact rækker: 730*3000*1 = 657, 000 Antal felter: 4 nøgler + 4 measures = 8 felter Total DB størrelse: 657, 000 * 8 felter* 4 bytes = 21 GB Lille database efter dagens standarder? Transaktionsniveau detalje er (oftest) muligt i dag n Afhængig af applikationen © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 52

Multidimensionelle begreber • Kube design metode 1) 2) 3) 4) • Eksempel n • Supermarked mart Øvelse n • Vælg mart/forretningsproces Vælg granularitet Vælg dimensioner Vælg measures Gentag eksemplet på clickstreams Udføres i grupperne © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 53

Weblogs • Se separat slide • Webloggen siger noget. n Dato/tid for page request n IP adresse og måske cookie ID for gæst n Det ønskede side objekt (en hel side eller et objekt på en side) n Request type (næsten altid “Get” eller “Submit”) n Kontekst for page request (referrer) n Browser type og version (Netscape eller Internet Explorer). • Men der er meget mere vi vil vide: n n n Hvem er gæsten? Hvor lang tid er de på siden? Identificering af hele sessioner © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 54

Øvelse: clickstream data mart • Lav et clickstream data mart • Find mindst 3 forskellige fact-tabeller n En af hver type (hændelse, tilstand, kumulativ tilstand) • Vælg granularitet af hver fact-tabel n n Argumenter for det konkrete valg Udregn størrelser • Beskriv 3 -4 dimensioner for en eller flere af fact-tabellerne n Husk niveauer og attributter • Beskriv mindst 3 forskellige measures n Et af hver type (additiv, semiadditiv, nonadditiv) • Dokumenter jeres design n Diagramform er valgfri © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 55

Opfølgning og diskussion • Mærk jer hvad i fik ud af øvelsen • Der er ikke noget ”rigtigt” svar • Kimball webhouse skemaer et godt eksempel © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18. -19. oktober 2001 56