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. nnholdet 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 B (business intelligence). Vi kan si at B 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 B, 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. Butikk ButikkNr AntallAnsatte Kvadratmeter Lagervare Antall Poststed PostNr A4 Poststed A100 Ordre OrdreNr OrdreDato DT SendtDato DT BetaltDato DT Ordrelinje PrisPrEnhet Antall Kunde KNr Fornavn A40 Etternavn A40 Adresse A40 Kjonn A1 MN Kategori KatNr Navn A50 Vare VNr Betegnelse Pris A10 A100 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. skjæringspunktet mellom en bestemt butikk, en bestemt vare og et bestemt tidspunkt er antall solgte enheter lagret.
4 B1 Tid Vare B u t i k k B2 V1 V2 T1 T2 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. nformasjonen 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. nnholdet 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. midten av «stjernen» finner vi faktaentiteten (Salg) med mange-til-en forhold ut mot dimensjonsentitetene.
6 Butikk ButikkNr AntallAnsatte Kvadratmeter PostNr Poststed A4 A100 Dato Uke Maaned Aar Status Tid DT A1 Antall Belop Salg MN Vare VNr Betegnelse KatNr KatNavn A10 A100 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. 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 PostNr A4 Poststed A100 Butikk ButikkNr AntallAnsatte Kvadratmeter Tid Dato DT Uke Maaned Kvartal Aar Status A1 Salg Antall Belop MN Vare VNr A10 Betegnelse A100 Kategori 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. 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. Fylke År By Uke Måned Kategori Poststed Dag Figur 6. Hierarkier: Sted, Tid, Vare 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. 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. 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 B1 Tid Vare Vare B u t i k k Dicing Slicing B1 B2 T2 V1 V2 T1 Tid = T1 B2 V1 V2 T2 T1 B1 B2 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 VNr ButikkNr Antall 15.05.2011 10820 12 3 15.05.2011 10820 13 7 15.05.2011 10830 12 10 15.05.2011 10830 13 2 16.05.2011 10820 12 0 16.05.2011 10820 13 8 16.05.2011 10830 12 10 16.05.2011 10830 13 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. 12 13 Totalt 10820 3 15 18 10830 20 17 37 Totalt 23 32 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 2 2 =4 SQL-spørringer. Utvider vi til tre dimensjoner måtte vi skrevet 2 3 =8 spørringer. Generelt må vi skrive 2 n spørringer for å få med alle subtotaler langs n dimensjoner. 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 krysstabell 1. ButikkNr VNr Samlet 12 10820 3 12 10830 20 13 10820 15 13 10830 17 12 23 13 32 10820 18 10830 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 ButikkNr VNr Samlet 05.2011 12 10820 3 05.2011 12 10830 20 05.2011 12 23 05.2011 13 10820 15 05.2011 13 10830 17 05.2011 13 32 05.2011 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. nndeling 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? nnenfor 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. nduktive 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. kke-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} nndelingen lar seg beregne ved en såkalt k-gjennomsnitt klyngealgoritme. deen 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].