Data Warehousing Dag 1 - formiddag

Præsentationer af emnet: "Data Warehousing Dag 1 - formiddag"— Præsentationens transcript:

1 Data Warehousing Dag 1 - formiddag
Christian S. Jensen og Torben Bach Pedersen Nykredit Center for Databaseforskning Aalborg Universitet © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

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

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

4 Hvad er Business Intelligence?
Sammensætning af teknologier 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 Udvidelse/integration af ovenstående teknologier Det modsatte af Artifical Intelligence (AI) 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 oktober 2001

5 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. Kunderne kommer ikke ”fysisk” i forretningen. Kunderne kan nemt skifte til andre. Derfor 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 Kunder er ”på” hele tiden. Man kender kundens position. Kombiner position med kundekendskab => store muligheder! © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

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

7 Data warehousing Løsning: nyt analysemiljø (DW) hvor data er
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 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 oktober 2001

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

9 OLAP OLAP = On-Line Analytical Processing
Interaktiv analyse Eksplorativ opdagelse Kræver hurtige svartider Data er organiseret som multidimensionelle terninger Terninger/kuber kan have et vilkårligt antal dimensioner Dimensioner har hierarkier, f.eks. dag-måned-år OLAP operationer 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 oktober 2001

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

11 Data Mining Data mining er automatisk vidensopdagelse Klassificering
Inddel data ind i foruddefinerede klasser Forudsigelse Forudsig/estimer ukendt værdi baseret på lignende tilfælde Sammenligning Finder ligheder/forskelle imellem klasse og konstrastklasse Gruppering Inddel data i grupper så ligheden indenfor de enkelte grupper er størst mulig og ligheden mellem grupperne er mindst mulig Sammenhænge 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 oktober 2001

12 Data Mining Eksempler Walmart: USAs (og verdens) største supermarkedskæde Har DW med alle kassetransaktioner for de sidste 2 år (70TB!) Bruger BI (bl.a. mining) intensivt for at opnå forretningsfordele Analyse af sammenhænge indenfor kassebon’er 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 Leverandøren stiller selv varen op på hylden Leverandøren får først betaling når varen bliver solgt Weblog mining 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 oktober 2001

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

14 Visualisering eksempel

15 Opsummering Hvorfor Business Intelligence? Data analyse problemer
Data Warehouse (DW) introduktion Analyseteknologier der bruger DW OLAP Data mining Visualisering BI kan give din virksomhed store fordele 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 oktober 2001

16 Deltagerdiskussion Hver deltager bedes kort præsentere 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 oktober 2001

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

18 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 oktober 2001

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

20 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 Fleksible Generelle Ingen forskel på: Hvad der er vigtigt Hvad der bare beskriver det vigtige ER/OO modeller er store entiteter/relationer/klasser Bliver nemt uoverskuelige ER/OO modeller implementeres i RDBMS Normaliserede databaser spreder information Når man analyserer data skal informationen samles igen © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

21 Den multidimensionelle model
Et formål Data analyse Bedre til det formål Mindre fleksibel Egner sig ikke til OLTP systemer Mere indbygget “mening” 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 oktober 2001

22 Den multidimensionelle model
Data er inddelt i: Facts Dimensioner Facts er det vigtige: et salg Facts har measures som kan aggregeres: salgspris Dimensioner beskriver facts Et salg har dimensionerne Produkt, Butik og Tid Facts “bor” i en multidimensionel kube (terning) Tænk på et array fra programmeringssprog Mål for dimensionel modellering: 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 oktober 2001

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

24 Kuber En “kube” kan have mange dimensioner!
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 dimensioner Men kun 2-3 dimensioner kan ses ad gangen Dimensionalitet reduceres af forespørgsler ved projektion/aggregering En kube består af celler 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 oktober 2001

25 Dimensioner Dimensioner er kernen i multidimensionelle databaser
Andre typer databaser har ikke støtte for dimensioner Dimensioner bruges til Selektion af data Gruppering af data på det rette detaljeringsniveau Dimensioner består af dimensionsværdier Produktdimension har værdierne ”Minimælk”, ”Letmælk”, … Tidsdimensionen har værdierne ”1/1/2001”, ”2/1/2001”,… Dimensionsværdier kan have en ordning 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 oktober 2001

26 Dimensioner Dimensioner har hierarkier med niveauer
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 Simpel, ikke-hierarkisk information Dag har Hverdag som attribut Dimensioner bør indeholde megen information Tidsdimensioner kan indeholde ferie, dag før ferie, årstid, vejr,… Gode dimensioner har eller flere attributter/niveauer © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

27 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 oktober 2001

28 Facts Facts repræsenterer emnet for den ønskede analyse
Det ”vigtige” i forretningen som man ønsker at analysere Et fact identificeres oftest via dets dimensionsværdier Et fact er en ikke-tom celle Nogle modeller giver facts en eksplicit identitet (se PJD artikel) Generelt skal et fact: 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 oktober 2001

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

30 Granularitet Granularitet af facts er vigtig
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 Betydning for skalerbarhed Ofte er granulariteten den enkelte forretningstransaktion 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 Undtagen måske for store clickstreams o.l. © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

31 Measures Measures repræsenterer de fact-egenskaber som brugerne ønsker at studere og optimere Eksempel: samlet salgspris Et measure har to komponenter 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 Nogle få har ikke (se PJD artikel) © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

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

33 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 Navigeringsforespørgsler undersøger én dimension Aggregeringsforespørgsler sammentæller fact data © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

34 Dokumentation af model
Ingen veldefineret standard Multidimensional Domain Structure (MDS) diagrammer Se separat slide Foreslået af Thomsen Viser strukturen af dimensioner og kuber Vores egen notation 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 oktober 2001

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

36 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 oktober 2001

37 Relationelt design Kuben implementeres ofte i et RDBMS
Relational OLAP (ROLAP) Relationel teknologi valgt til DW på grund af: Skalerbarhed Fleksibilitet Samspil/kompatibilitet med den øvrige IT infrastruktur Fact-tabel(ler) gemmer facts 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 Heltalsnøgle (surrogatnøgle) Flere typer af dimensionstabeller © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

38 Relationelt design En helt denormaliseret tabel Stjerneskemaer
Dimensionsværdier gentages for hvert fact Dårligt: ufleksibelt, pladsforbrug, dårlig performance, opdateringer Stjerneskemaer En fact-tabel Denormaliserede dimensionstabeller En kolonne pr. niveau/attribut Snowflaking 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 oktober 2001

39 Stjerneskema eksempel

40 Snowflaking eksempel

41 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

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

43 Redundans i DW Kun meget lidt redundans i fact-tabeller
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 Stjerneskema dimensionstabeller har redundante værdier i de højere niveauer Redundans problemer? Inkonsistent data: den centrale load proces hjælper med dette Opdateringstid: DW optimeret for forespørgsler, ikke opdateringer Pladsforbrug: dimensionstabeller bruger typisk <5% af DW plads Altså: kontrolleret redundans er godt Til en vis grænse… © Christian S. Jensen, Torben Bach Pedersen - Nouhauz oktober 2001

44 Heltalsnøgler Brug altid ”dumme” heltalsnøgler i DW dimensioner
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 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 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 oktober 2001

45 Styrker og svagheder For den ”klassiske” multidimensionelle model
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 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 oktober 2001

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

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

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

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

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

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

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

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

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

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

56 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 oktober 2001