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

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

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

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

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

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

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

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

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

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

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

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

Visualisering eksempel

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

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

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

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

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

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 50-1000 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 - 18.-19. oktober 2001

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

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

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

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 10-15 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 - 18.-19. oktober 2001

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

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 50-100 eller flere attributter/niveauer © Christian S. Jensen, Torben Bach Pedersen - Nouhauz - 18.-19. oktober 2001

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ø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 - 18.-19. oktober 2001

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