1. No category

Datavarehus
Et datavarehus inneholder aggregerte data fra en eller flere databaser og
eventuelt andre datakilder. Datavarehuset blir brukt som grunnlag for å treffe
strategiske beslutninger. For eksempel kan en handelsbedrift studere utvikling i salg av ulike produkter over tid og tilpasse vareutvalget til kundene.
Vi ser på design og implementasjon av datavarehus, og forklarer SQL
analysefunksjoner for datavarehus. Vi avslutter med en kort gjennomgang
av datagruvedrift (data mining), som er en samling teknikker for å «oppdage
mønstre» i store datasett.
Beslutningsstøttesystemer
Se på følgende to utsagn:


12.05.2011 kjøpte Ola Hansen 3 enheter av varen Nisseskjegg.
Salg av Nisseskjegg gikk ned med 10 prosentpoeng fra 2010 til 2011.
Det første utsagnet beskriver et enkelt salg. Denne informasjonen er nødvendig for å få sendt ut en korrekt faktura til Ola Hansen. Det siste utsagnet
bygger på aggregerte salgsdata for de siste 2 årene, og er i første rekke av
interesse for ledelsen i bedriften.
Databasesystemer er virksomhetskritiske. En database inneholder
detaljert informasjon nødvendig for daglig drift av en virksomhet, og må bli
kontinuerlig oppdatert. En handelsbedrift registrerer data om hvert enkelt
salg, et bibliotek holder rede på hvert enkelt utlån, et universitet lagrer data
om hver avlagte eksamen for hver enkelt student. Databasene er nødvendige
for utførelse av rutinemessige oppgaver. Handelsbedriften skal sende ut
fakturaer, biblioteket skal purre på utlån som er utløpt, universitetet skal
skrive ut vitnemål.
For daglig drift av en virksomhet er det sjelden nødvendig å kjenne til
historiske data. For å gjennomføre et salg er det nå-prisen på varene som er
interessante, ikke prisen i fjor. Det er et typisk trekk ved operasjonelle databaser at de i liten grad inneholder historiske data. Når en vare får ny pris, blir
den gamle prisen overskrevet.
En virksomhet må løse sine daglige oppgaver så effektivt og godt som
mulig, men må samtidig se framover og hele tiden tilpasse seg sine omgivelser. Det er vesentlig å treffe fornuftige strategiske beslutninger.
Handelsbedriften utvider utvalget av de mest populære varekategoriene, universitetet avvikler studieprogrammer på fagområder med få studenter. Denne
typen av beslutninger krever tilgang på aggregerte og historiske data.
2
Disse to sidene av en virksomhet − den operasjonelle og den strategiske −
skaper et behov for to typer av informasjonssystemer:


OLTP (On-Line Transactional Processing) betegner systemer brukt i
daglig drift av virksomheten. De er karakterisert ved hyppige oppdateringer (transaksjoner) og relativt enkle søk. Data representerer som
regel nå-situasjonen. De tunge brukerne består ofte av kontorpersonell,
saksbehandlere, selgere og operatører. Det er viktig at systemene er tilgjengelige, ofte døgnet rundt (24/7-systemer), og kan utføre mange
transaksjoner hurtig (høy gjennomstrømning − throughput).
OLAP (On-Line Analytical Processing) betegner systemer for å analysere
en virksomhet, såkalte beslutningsstøttesystemer. Data er aggregert
over tid og blir i liten grad oppdatert. Systemene brukes i første rekke av
ledere og analytikere for å treffe strategiske beslutninger. Det er behov
for å ta ut statistikk basert på kompliserte ad hoc-spørringer mot slike
systemer.
Fordi OLAP-systemer genererer store datamengder og medfører kompliserte
og ressurskrevende spørringer har mange virksomheter sett behovet for å
skille ut disse oppgavene i et eget system − et datavarehus. På den måten kan
OLTP-databasene bli frigjort til å løse de daglige oppgavene på en mest mulig
effektiv måte.
Innholdet i et datavarehus blir i hovedsak hentet fra virksomhetens operasjonelle databaser, men det er også aktuelt å koble dette med data fra eksterne
datakilder, som for eksempel bakgrunnsdata om kunder. Data blir periodisk
aggregert og lastet opp i datavarehuset. Uttrekk fra datavarehuset blir deretter
importert i verktøy for analyse og rapportering, se Figur 1.
Datavarehus og beslutningsstøttesystemer er en viktig del av BI (business
intelligence). Vi kan si at BI er de prosessene som skal sette en virksomhet i
stand til å treffe gode strategiske valg. CRM (Customer Relationship Management) er et viktig område innen BI, og tar for seg metoder en virksomhet kan
bruke for å håndtere kundeforhold, ofte basert på data lagret i et datavarehus.
OLTP
Databaser
Eksterne
datakilder
Datavarehus
Figur 1. Datavarehus
OLAP-verktøy
for analyse og
rapportering
3
Design og implementasjon
Hobbykjeden AS
Tenk deg at Hobbyhuset vokser, og blir organisert som en kjede med butikker
i flere byer. En mulig datamodell for virksomhetens operasjonelle database er
vist i Figur 2.
Poststed
Kunde
PostNr
A4
Poststed A100
KNr
Fornavn
Etternavn
Adresse
Kjonn
Butikk
ButikkNr
I
AntallAnsatte I
Kvadratmeter I
Ordre
OrdreNr
OrdreDato
SendtDato
BetaltDato
I
A40
A40
A40
A1
I
DT
DT
DT
Ordrelinje
PrisPrEnhet MN
Antall
I
Lagervare
Antall I
Vare
Kategori
KatNr I
Navn A50
VNr
A10
Betegnelse A100
Pris
MN
Prishistorikk
Dato
DT
GammelPris MN
Figur 2. Datamodell for Hobbykjeden AS
Databasen lagrer antall ansatte og størrelse i kvadratmeter om hver butikk. En
ordre knyttes nå til en bestemt butikk, og butikkene får hvert sitt varelager.
Kjeden har imidlertid en sentral prispolitikk. Fysisk kan man tenke seg at
løsningen er realisert ved en sentral database, der butikkene kanskje har aksess
via web. Alternativt er det mulig å lage en distribuert databaseløsning der hver
butikk har ansvar for sine data. Vi tar ikke stilling til slike spørsmål her.
Datakuber
Ledelsen i Hobbykjeden ønsker å studere hvordan salget av forskjellige produkter utvikler seg over tid, både totalt og i de enkelte kjedebutikkene. Denne
typen av aggregerte data lar seg presentere i form av såkalte datakuber, se
Figur 3. Kuben i figuren har tre dimensjoner (eller akser): Butikk, Vare og
Tid. I skjæringspunktet mellom en bestemt butikk, en bestemt vare og et
bestemt tidspunkt er antall solgte enheter lagret.
4
Vare
Ti
d
B
u
t
i
k
k
B1
T2
B2
T1
V1
V2
Figur 3. Datakube for antall solgte enheter
Man kan opprette lignende datakuber for andre data, for eksempel solgt beløp
for de samme tre dimensjonene, eller antall ordrer fordelt på kunder, butikker
og tid. En datakube kan ha flere dimensjoner enn tre. De fleste av oss har
imidlertid problemer med å tenke i flere enn tre dimensjoner, så vi lar dette
ligge.
Informasjonen i datakuben kan konstrueres fra databasetabellene ved
følgende spørring:
SELECT ButikkNr, VNr, Dato,
SUM(Antall) AS AntallEnheter
FROM Ordre, Ordrelinje
WHERE Ordre.OrdreNr = Ordrelinje.OrdreNr
GROUP BY ButikkNr, VNr, Dato
Faktatabeller og dimensjonstabeller
Antall solgte enheter er kun ett eksempel på data som Hobbykjeden ønsker å
analysere. Hobbykjeden beslutter å bygge et datavarehus med følgende
tabeller:




Butikk(ButikkNr, PostNr, Poststed, Kvadratmeter, AntallAnsatte)
Vare(VNr, Betegnelse, KatNr, KatNavn)
Tid(Dato, Uke, Måned, År, Status)
Salg(ButikkNr*, VNr*, Dato*, Antall, Beløp)
Legg merke til at tabellen Salg har en sammensatt primærnøkkel, der hver
kolonne er en fremmednøkkel som refererer de øvrige tabellene. Salg er en
såkalt faktatabell, de tre øvrige er dimensjonstabeller.
5
En faktatabell inneholder kvantitative (numeriske) data om det man ønsker
å analysere, for eksempel salg. Hver enkelt faktatabell kan representere flere
datakuber. For eksempel inneholder tabellen Salg både datakuben i Figur 3,
og en tilsvarende datakube som viser solgt beløp pr. butikk pr. vare pr. dag.
Innholdet i faktatabeller blir typisk generert ved spørringer mot de operasjonelle databasetabellene ved gruppering og bruk av mengdefunksjoner.
Faktatabeller kan bli store. Eksempel på beregning av plassforbruk for å
holde aggregerte data for en 2-årsperiode i Hobbykjeden:
100 butikker×2000 varer×730 dager×5 attributter×8 byter/attributt≈5.8 GB
En dimensjonstabell inneholder attributter man gjerne grupperer på, og beskriver en av dimensjonene i en datakube. Tabellene svarer ofte til sentrale
entiteter i virksomheten, som for eksempel butikker, varer og kunder. Tid er
alltid én av dimensjonene. En rad i tabellen Tid representerer en enkelt dag.
Kolonnen Status inneholder en kode som for eksempel sier om dagen er en
feriedag. Merk at dimensjonstabellene over er denormaliserte. Det vil ofte
være tilfelle, og vi skal forklare hvorfor om litt.
Data i et datavarehus kan lagres i vanlige databasetabeller (relasjoner) som
vist over. Slike systemer blir referert til som ROLAP-systemer (Relational
OLAP). Det finnes også verktøy som representerer datakuber direkte i en
flerdimensjonal datastruktur. Slike verktøy kalles for MOLAP-systemer
(Multidimensional OLAP).
Stjerneskjema og snøflakskjema
Utforming av et datavarehus bør som for vanlige databasesystemer starte med
konstruksjon av en begrepsmessig datamodell. Datamodeller for datavarehus
følger ofte et såkalt stjerneskjema, se Figur 4. I midten av «stjernen» finner
vi faktaentiteten (Salg) med mange-til-en forhold ut mot dimensjonsentitetene.
6
Butikk
ButikkNr
AntallAnsatte
Kvadratmeter
PostNr
Poststed
I
I
I
A4
A100
Tid
Dato
Uke
Maaned
Aar
Status
DT
I
I
I
A1
Salg
Antall I
Belop MN
Vare
VNr
Betegnelse
KatNr
KatNavn
A10
A100
I
A40
Figur 4. Stjerneskjema
Merk at dimensjonsentitetene er denormalisert. For eksempel inneholder entiteten Vare både KatNr og KatNavn, og Butikk inneholder både PostNr og
Poststed. Det er to grunner til dette:


Datamodellen blir enklere å forstå for en sluttbruker fordi den har færre
tabeller. Spørringene blir enklere på grunn av færre koblinger.
Spørringene kan utføres mer effektivt på grunn av færre koblinger. For
ytterligere effektivitetsgevinst blir sammensatte primærnøkler ofte erstattet med konstruerte nøkler for å gi raskere koblinger.
Generelt er denormalisering uheldig på grunn av faren for inkonsistens. I et
datavarehus er dette momentet mindre viktig fordi data i hovedsak ikke blir
oppdatert (kun periodevis lastet opp). Vi har altså kontroll med redundansen.
Det kan likevel være situasjoner som tilsier at noen av dimensjonsentitetene bør normaliseres. Da får man et såkalt snøflakskjema, vist i Figur
5. Her er entitetene Poststed og Kategori trukket ut fra henholdsvis Butikk og
Vare.
7
Poststed
A4
PostNr
Poststed A100
Butikk
I
ButikkNr
AntallAnsatte I
Kvadratmeter I
Tid
Dato
Uke
Maaned
Kvartal
Aar
Status
DT
I
I
I
I
A1
Salg
Antall I
Belop MN
Vare
A10
VNr
Betegnelse A100
Kategori
I
KatNr
KatNavn A40
Figur 5. Snøflakskjema
Data i dimensjonstabeller lar seg ofte plassere i hierarkier, og disse hierarkiene
påvirker hvordan datavarehuset bør bygges opp. Betrakt Figur 6. Til venstre
har vi et geografisk hierarki: Et fylke består av mange byer og hver by består
av mange poststeder. Det kan være interessant å studere utvikling i salg langs
dette hierarkiet. Både butikker og kunder har tilknytning til et sted. Poststed,
by og fylke er dermed naturlige attributter å knytte til butikker og kunder. I
midten finner vi en tilsvarende oppdeling av tidsdimensjonen. Merk at en uke
kan spenne over to måneder, som er grunnen til at uke ikke er underordnet
måned. Til høyre ser vi hvordan varer er delt inn i kategorier. Ved å
kombinere hierarkinivåene fra dimensjonstabellene får vi et antall interessante
rapporter: Salg pr. kategori pr. by pr. måned, salg pr. vare i januar i en bestemt
by, og så videre.
År
Fylke
By
Poststed
Uke
Måned
Dag
Figur 6. Hierarkier: Sted, Tid, Vare
Kategori
Vare
8
Merk at datamodellen setter begrensninger på hva slags analyser som det er
mulig å gjøre. Hvis man velger å aggregere salg pr. dag, er det ikke mulig å
lage rapporter som viser hvordan salget varierer fra morgen til ettermiddag.
Man må i så fall forfine tidsdimensjonen, for eksempel ved å dele opp en dag
i hele timer. Omvendt så medfører økt detaljeringsnivå at datavarehuset tar
større plass på ytre lager.
Et datavarehus vokser ofte fram over tid. Kanskje starter man med å lage
et datavarehus spesielt for salgsavdelingen i en bedrift. Etter en stund oppstår
det behov for lignende funksjonalitet i andre avdelinger, som regnskap,
personal og produksjon. Alternativt kan man definere ett stort utviklingsprosjekt for å lage et datavarehus som dekker behovet til hele virksomheten.
Den første strategien kan vi kalle bottom-up og den siste for top-down.
Et mindre datavarehus, utviklet for en avgrenset del av virksomheten,
kalles for et datamarked. Med en bottom-up utviklingsstrategi vil datavarehuset bli til ved en «fletting» av mindre datamarkeder, mens ved en top-down
strategi blir datamarkedene definert ved «uttrekk» av virksomhetens samlede
datavarehus. Den første strategien kan medføre en del ekstraarbeid for å samordne begrepsbruken i uavhengige datamarkeder. Ulempen med en top-down
tilnærming ligger i kompleksiteten ved utvikling av «totalløsninger».
Opplasting av data
Arbeidet med å laste opp data i datavarehuset deles gjerne i tre faser og blir
referert til ved forkortelsen ETL=Extract-Transform-Load (eller Ekstrahere,
Transformere og Laste). Det finnes egne verktøy som letter dette arbeidet.
Ekstrahering innebærer å trekke ut data fra operasjonelle databaser og
eksterne datakilder, gjerne ved bruk av SQL. Data blir samlet i filer på et
midlertidig datalager. Ved første gangs etablering av datavarehuset blir alle
data lest. Ved seinere oppdateringer blir kun data som er endret trukket ut.
Transformasjon består av flere deloppgaver:


«Vasking» av data innebærer for eksempel å rette skrivefeil i navn og
adresser, rette opp ugyldige datoer, og fjerne inkonsistens mellom data
hentet fra forskjellige systemer. Etablering av datavarehus medfører ofte
at det blir oppdaget feil i de underliggende operasjonelle databasene, noe
som bidrar til økt datakvalitet (forutsatt at feilene blir rettet også i de
operasjonelle databasene).
Datakonvertering innebærer å samordne bruk av begreper, datatyper og
koder til en felles standard. Samme slags data kan være lagret ulikt i forskjellige operasjonelle databaser, for eksempel med hensyn på navn og
datatyper.
9

Data fra de operasjonelle databasene blir som regel koblet (denormalisert)
og aggregert før de blir lastet opp i datavarehuset.
Lasting av data innebærer å lese datafilene fra mellomlageret inn i datavarehuset, samt å bygge opp indekser i datavarehuset. Det blir gjerne brukt
spesielle indekseringsteknikker i datavarehus, for eksempel bitmap-indekser.
Fordi datavarehus er karakterisert ved få eller ingen oppdateringer, og
hyppige og kompliserte spørringer, vil man definere flere indekser på et datavarehus enn et operasjonelt databasesystem (man trenger ikke å ta hensyn til
ekstrajobben som ligger i at indeksene må bli oppdatert ved endringer i tabelldata). Som for ekstrahering skiller man mellom første gangs opplasting og
seinere oppdateringer.
Analyse og rapportering
Operasjoner på datakuber
En datakube er et velegnet «tankeverktøy» for visualisering av aggregerte data.
Det finnes også konkrete verktøy der brukeren kan utføre operasjoner på
datakuber i et grafisk brukergrensesnitt. Crystal Reports fra Business Objects
(www.sap.com) er et kjent produkt.
Figur 7 illustrerer to hyppig brukte teknikker for å hente ut data fra en
datakube:


Slicing innebærer å skjære ut en «skive» fra en datakube. I figuren blir
salgstall for en bestemt dag trukket ut. Merk at operasjonen går fra 3 til 2
dimensjoner (fra en kube til en matrise). Generelt fører slicing oss fra n til
n-1 dimensjoner.
Dicing innebærer å plukke ut en mindre datakube fra en større. I figuren
blir salgstall for noen butikker, noen vareslag og noen dager plukket ut.
Hierarkiene vist i Figur 6 er et nyttig utgangspunkt for rapportering fra
datavarehuset til Hobbykjeden. For å studere salgstall er det nyttig å kunne
utforske tallmaterialet på flere aggregeringsnivåer:


Rollup innebærer å aggregere data. Datakuben til venstre i Figur 7 viser
salget for hver enkelt vare (hver dag i hver butikk). Geografisk aggregering av butikkdimensjonen til fylker er et eksempel på rollup.
Drilldown er det motsatte av rollup og innebærer å forfine en av dimensjonene i en datakube, for eksempel ved å bryte ned hver dag i perioder
på hele timer.
10
Vare
Vare
Ti
d
B
u
t
i
k
k
B1
B1
ng
Dici
T2
T1
B2
V1 V2
Tid = T1
S lic
ing
T2
B2
B1
T1
V1
B2
V2
V1
V2
Figur 7. Slicing og dicing
SQL-konstruksjoner for datavarehus
Figur 8 viser mulig innhold for tabellen Salg. Antall rader er urealistisk lavt,
den beskriver kun to datoer, to varer og to butikker. Det er gjort for at det
skal være mulig å studere effekten av SQL analysefunksjoner.
Dato
15.05.2011
15.05.2011
15.05.2011
15.05.2011
16.05.2011
16.05.2011
16.05.2011
16.05.2011
VNr
10820
10820
10830
10830
10820
10820
10830
10830
ButikkNr
Antall
12
13
12
13
12
13
12
13
3
7
10
2
0
8
10
15
Figur 8. Eksempelinnhold for faktatabellen Salg
Ved å slå sammen data for de to dagene kan vi presentere informasjonen på
en kompakt måte med krysstabellen i Figur 9.
La oss prøve å produsere innholdet i krysstabellen ved hjelp av «vanlige»
SQL-spørringer.
SELECT ButikkNr, VNr, SUM(Antall) AS Samlet
FROM Salg
GROUP BY ButikkNr, VNr
11
Spørringen vil riktig nok ikke stille opp data som i Figur 9, men vil i prinsippet inneholde samme informasjon − bortsett fra raden/kolonnen med
totaler.
10820
10830
Totalt
12
3
20
23
13
15
17
32
Totalt
18
37
55
Figur 9. Krysstabell vare/butikk
Neste spørring produserer totaler pr. butikk, det svarer til de to første
verdiene i den nederste raden:
SELECT ButikkNr, SUM(Antall) AS Samlet
FROM Salg
GROUP BY ButikkNr
Ved å bytte ut ButikkNr med VNr får vi de to første verdiene i den summerte
kolonnen helt til høyre i Figur 9.
Samlet salg uavhengig av både butikk og vare («grand total») kan beregnes
slik:
SELECT SUM(Antall) AS Samlet
FROM Salg
Det er altså mulig å få ut informasjonen i krysstabellen ved hjelp av standard
gruppering og mengdefunksjoner, men teknikken er arbeidskrevende. Merk at
vi i dette eksemplet kun ser på sammenhengen mellom to dimensjoner, og
måtte skrive 22=4 SQL-spørringer. Utvider vi til tre dimensjoner måtte vi
skrevet 23=8 spørringer. Generelt må vi skrive 2n spørringer for å få med alle
subtotaler langs n dimensjoner.
I SQL:1999 ble det innført en konstruksjon for å lage krysstabeller med en
enkelt spørring:
SELECT ButikkNr, VNr, SUM(Antall) AS Samlet
FROM Salg
GROUP BY CUBE(ButikkNr, VNr)
Spørreresultatet er vist i Figur 10. Det eneste vi må gjøre er altså å legge til
nøkkelordene BY CUBE i grupperingen. Spørreresultatet svarer til Figur 9,
men er presentert på «vanlig» måte og ikke som en krysstabell. Radene med
nullmerker svarer til totaler. Raden med nullmerke i VNr og 12 i ButikkNr gir
altså samlet antall solgte enheter for butikk 12. Den nederste raden med null-
12
merker i begge kolonner viser grand total. Ved å tolke nullmerker som totaler
kan et visualiseringsverktøy presentere spørreresultatet som en krysstabell1.
ButikkNr
12
12
13
13
12
13
VNr
10820
10830
10820
10830
10820
10830
Samlet
3
20
15
17
23
32
18
37
55
Figur 10. Resultat av GROUP BY CUBE
Av og til er det ikke behov for å lage alle mulige subtotaler. Da kan vi i stedet
bruke BY ROLLUP i grupperingen:
SELECT Måned, ButikkNr, VNr, SUM(Antall) AS Samlet
FROM Salg
WHERE År = 2011
GROUP BY ROLLUP(Måned, ButikkNr, VNr)
Spørreresultatet viser totaler pr. måned, butikk og vare, pr. måned og butikk,
og pr. måned, men for eksempel ikke pr. vare, se Figur 11.
Måned
05.2011
05.2011
05.2011
05.2011
05.2011
05.2011
05.2011
ButikkNr
12
12
12
13
13
13
VNr
10820
10830
10820
10830
Samlet
3
20
23
15
17
32
55
Figur 11. Resultat av GROUP BY ROLLUP
1 Automatisk generering av krysstabeller er tilsynelatende problematisk hvis spørreresultatet også
inneholder «vanlige» nullmerker. Det finnes imidlertid SQL-konstruksjoner som gjør det mulig å avgjøre
hvordan et nullmerke i slike spørreresultater skal tolkes.
13
Access og MySQL støtter ikke GROUP BY CUBE og ROLLUP.
Datagruvedrift
Hvis man kjøper en bok på nettbokhandelen Amazon (www.amazon.com),
får man tips om andre bøker som kanskje er av interesse. Boktipsene er basert
på en analyse av handlekurvene til andre kunder. Hvis bøkene A og B ofte
blir kjøpt sammen, taler det for å anbefale bok B til en kunde som kjøper bok
A. Denne typen av handlekurv-analyse er et eksempel på datagruvedrift
(data mining).
Enkelt sagt går datagruvedrift ut på å finne «interessante mønstre» i store
databaser og datavarehus. Inndeling av kunder i segmenter, analyse av
markedstrender, målrettet markedsføring og lønnsomhetsanalyser er noen
eksempler på anvendelser av datagruvedrift. Slike analyser kan ha forskjellige
formål.



Forklare: Hvorfor øker salget av vare X i butikk A?
Bekrefte: Er det riktig at det er større sannsynlighet for at enslige kjøper
vare X enn at familier gjør det?
Utforske: Hvilke andre varer er det sannsynlig at en kunde som kjøper
vare X er interessert i?
Innenfor logikk skiller man mellom deduktive og induktive resonnementer.
Deduktive slutninger utleder nye fakta fra kjente fakta og slutningsregler.
Eksempel på regel: Hvis X er far til Y og Y er far til Z, så er X farfar til Z.
Hvis vi vet at Per er far til Ola, og Ola er far til Hans, så kan vi bruke regelen
for å utlede at Per er farfar til Hans. Induktive slutninger, derimot, utleder
generelle regler fra en faktasamling. Datagruvedrift bygger i stor grad på
induktive resonnementer. Vi vil nå kort beskrive tre metoder innen
datagruvedrift: assosiering, styrt klassifikasjon og ikke-styrt klassifikasjon.
Handlekurv-analysen referert over er et eksempel på assosiering, det vil si
at man utleder regler basert på forekomster i datamaterialet. La følgende
mengder stå for innholdet av handlekurvene til 6 kunder, der bokstavene A-H
står for varer, tenk for eksempel på boktitler:
{A,B,C,D}, {C,D,E}, {C}, {A,E,F}, {G}, {E,H}
Legg merke til at C forekommer i halvparten av kurvene, mens for eksempel
G kun forekommer 1 gang. Legg også merke til at i to av kurvene der C er
med, så er også D med. Med grunnlaget (support) for en vare X mener vi
andelen av kurver der X er med. Grunnlaget for C er 50 % (3 av 6), mens
14
grunnlaget for G er 17 % (1 av 6). Vi ønsker å identifisere regler av typen «en
kunde som kjøper X kjøper ofte også Y». Med konfidens (confidence) av en
regel XY mener vi andelen kurver der Y er med, valgt ut fra mengden av
kurver der X er med. Regelen CD har 67 % konfidens (2 av 3), mens CA
kun har 33 % konfidens (1 av 3).
Styrt klassifikasjon har som formål å plassere elementer i forhåndsdefinerte
klasser eller grupper. Operasjonen starter gjerne med manuell opplæring av
systemet. En bank vil ha regler som, basert på bakgrunnsdata om kjønn, alder
og inntekt, plasserer lånekunder i tre grupper med tanke på forventet risiko
for mislighold (lavrisiko, høyrisiko og middels risiko). Man velger først ut et
tilfeldig utplukk av eksisterende kunder, og gir disse riktig merkelapp, basert
på faktiske data om mislighold. Ut fra dette kan man automatisk lage regler
for å plassere nye kunder i «riktig» risikogruppe.
Ikke-styrt klassifikasjon, eller klyngedanning, innebærer at man automatisk etablerer et «naturlig» sett av klasser for et datasett, og deretter legger
elementer i datasettet inn i disse klassene. Betrakt følgende tallmengde:
{34, 2, 72, 38, 5, 29, 81, 80, 4, 39}
Tallene kan for eksempel representere beløpene som forskjellige kunder har
handlet for. Følgende er en naturlig inndeling i tre grupper basert på tallstørrelser:
{2, 4, 5}, {29, 34, 38, 39}, {72, 80, 81}
Inndelingen lar seg beregne ved en såkalt k-gjennomsnitt klyngealgoritme.
Ideen er å starte med en tilfeldig inndeling i tre grupper. Så beregner man
gjennomsnittet i hver gruppe, før hvert element blir omfordelt til den
gruppen den har kortest avstand til. Denne prosessen gjentas til ingen elementer blir omfordelt.
[Hobbs m.fl. 2004] og [Mundy m.fl. 2006] tar for seg metodikk og teknologi for datavarehus og datagruvedrift i henholdsvis SQL Server og Oracle
10g. Mange generelle lærebøker i databasesystemer har også egne kapitler om
stoffet, se for eksempel kapittel 25 og 26 i [Ramakrishnan 2002].