Datavarehus. Beslutningsstøttesystemer

Størrelse: px
Begynne med side:

Download "Datavarehus. Beslutningsstøttesystemer"

Transkript

1 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: kjøpte Ola Hansen 3 enheter av varen Nisseskjegg. Salg av Nisseskjegg gikk ned med 10 prosentpoeng fra 2010 til 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 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 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 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 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 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 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 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 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 ( 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 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 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 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 Totalt Totalt 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 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 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 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 13 Access og MySQL støtter ikke GROUP BY CUBE og ROLLUP. Datagruvedrift Hvis man kjøper en bok på nettbokhandelen Amazon ( 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 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].

Databearbeiding direkte i memory på LASR server nye muligheter? Trond Holmen, SAS Institute

Databearbeiding direkte i memory på LASR server nye muligheter? Trond Holmen, SAS Institute Databearbeiding direkte i memory på LASR server nye muligheter? Trond Holmen, SAS Institute Bakgrunn: Hvordan virker en tradisjonell database Store datamengder har tradisjonelt vært lagret på disk For

Detaljer

Spørringer mot flere tabeller

Spørringer mot flere tabeller Spørringer mot flere tabeller Kartesisk produkt / kryssprodukt/krysskobling Likekoblinger INNER JOIN syntaks Generelle koblinger Egenkoblinger Ytre koblinger Union, snitt og differanse Mer om gruppering

Detaljer

Bruk av data kan deles i data for transaksjonsbruk og data for analyse bruk:

Bruk av data kan deles i data for transaksjonsbruk og data for analyse bruk: Datavarehus Hva? Et datavarehus er en samling av data lagret slik at de egner seg for analyse f.eks. trendanalyse, konkurranseanalyse, kundeanalyse og annen form for markedsanalyse (mest vanlig bruk) analyse

Detaljer

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Relasjonsmodellen Tore Mallaug 2.9.2013 Lærestoffet er utviklet for faget Databaser 1. Relasjonsmodellen Resymé: Denne leksjonen gir en kort

Detaljer

Intelle har siden starten i i 1999. leverandør av av programvare for data- og og systemintegrasjon.

Intelle har siden starten i i 1999. leverandør av av programvare for data- og og systemintegrasjon. Intelle har siden starten i i 1999 vokst til til å å bli bli en en viktig leverandør av av programvare for for data- og og systemintegrasjon. 2 Intelle CRM Rapportering er en integrert rapporteringsløsning

Detaljer

Introduksjon til fagfeltet

Introduksjon til fagfeltet LC238D http://www.aitel.hist.no/fag/_dmdb/ Introduksjon til fagfeltet Datafiler side 2 Databasesystemer side 3-5 Databasearkitektur ANSI/SPARC side 6-7 Datamodeller side 8 Flerbruker databasesystem side

Detaljer

Databasedesign HVA? HVORDAN? E/R diagram. Begrepsmessig databasedesign. Logisk databasedesign. Fysisk databasedesign

Databasedesign HVA? HVORDAN? E/R diagram. Begrepsmessig databasedesign. Logisk databasedesign. Fysisk databasedesign Databasedesign HVA? Begrepsmessig databasedesign E/R diagram Logisk databasedesign HVORDAN? Fysisk databasedesign Databaser Leksjon 7: Logisk databasedesign - 1 Logisk databasedesign Fra E/R til tabellstruktur:

Detaljer

1. Innføring i bruk av MySQL Query Browser

1. Innføring i bruk av MySQL Query Browser Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Innføring i bruk av MySQL Query Browser Kjell Toft Hansen 28.02.2007 Lærestoffet er utviklet for faget LV338D Databaseadministrasjon 1. Innføring

Detaljer

Normalisering. Partielle avhengigheter Transitive avhengigheter Normalformer: 1NF, 2NF, 3NF, BCNF Normaliseringsstegene Denormalisering

Normalisering. Partielle avhengigheter Transitive avhengigheter Normalformer: 1NF, 2NF, 3NF, BCNF Normaliseringsstegene Denormalisering Normalisering Motivasjon Redundans Funksjonelle avhengigheter Determinanter Partielle avhengigheter Transitive avhengigheter Normalformer: 1NF, 2NF, 3NF, BCNF Normaliseringsstegene Denormalisering Pensum:

Detaljer

Databaser: Relasjonsmodellen, del I

Databaser: Relasjonsmodellen, del I LC238D http://www.aitel.hist.no/fag/_dmdb/ Databaser: Relasjonsmodellen, del I En relasjon er en matematisk mengde side 2 Egenskaper ved relasjoner side 3 Entitetsintegritet side 4-5 Referanseintegritet

Detaljer

EKSAMEN DATABASER

EKSAMEN DATABASER EKSAMEN 6102 DATABASER 30.05.2016 Tid: 4 timer (9-13) Målform: Sidetall: Hjelpemidler: Merknader: Vedlegg: Bokmål 7 (inkludert denne) Ingen Ingen Eksempeldata Sensuren finner du på StudentWeb. Vekting

Detaljer

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn EKSAMENSFORSIDE Skriftlig eksamen med tilsyn Emnekode: Emnenavn: DAT1000 Database 1 Dato: Tid fra / til: 13.05.2019 10.00 14.00 Ansvarlig faglærer: Bjørn Kristoffersen Campus: Fakultet: Bø Handelshøyskolen

Detaljer

Tabeller og enkle spørringer

Tabeller og enkle spørringer Tabeller og enkle spørringer Database, relasjonsdatabase Databasehåndteringssystem (DBHS) Databasesystem Tabell, kolonne, rad, datatype, verdi, primærnøkkel Utvalgsspørringer i SQL Velge ut rader Velge

Detaljer

EKSAMEN 6102 / 6102N DATABASER

EKSAMEN 6102 / 6102N DATABASER EKSAMEN 6102 / 6102N DATABASER 06.12.2016 Tid: 4 timer (10-14) Målform: Sidetall: Hjelpemidler: Merknader: Vedlegg: Bokmål / nynorsk 13 (inkludert denne) Ingen Ingen Eksempeltabeller Sensuren finner du

Detaljer

DT4300 Datavarehus og datagruvedri3

DT4300 Datavarehus og datagruvedri3 DT4300 Datavarehus og datagruvedri3 14/1 2014 Trond Aalberg 1 Dagens tema Datavarehus: hva og hvorfor, generell arkitektur, OLAP vs OLTP MulFdimensjonale data Datakube som logisk modell for datavarehus,

Detaljer

En lett innføring i foreninger (JOINs) i SQL

En lett innføring i foreninger (JOINs) i SQL En lett innføring i foreninger (JOINs) i SQL Noen ord om forening (JOIN)! 2 JOINs til gjennomgang! 3 1. INNER JOIN! 3 Eksempel på [INNER] JOIN! 4 NATURAL JOIN! 5 Eksempel på NATURAL JOIN! 5 2. LEFT [OUTER]

Detaljer

Avansert bruk av SQL. Avanserte spørringer Valguttrykk Spørring på spørring Unionspørringer Delspørringer, vekselvirkende delspørringer Kvantorer

Avansert bruk av SQL. Avanserte spørringer Valguttrykk Spørring på spørring Unionspørringer Delspørringer, vekselvirkende delspørringer Kvantorer Avansert bruk av SQL Avanserte spørringer Valguttrykk Spørring på spørring Unionspørringer Delspørringer, vekselvirkende delspørringer Kvantorer Begrensninger ved SQL Pensum: Kapittel 5 Databaser Leksjon

Detaljer

1. SQL spørringer mot flere tabeller

1. SQL spørringer mot flere tabeller 1. SQL spørringer mot flere tabeller Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag SQL spørringer mot flere tabeller Tore Mallaug 29.9.2008 Lærestoffet er utviklet for faget Databaser

Detaljer

1. SQL datadefinisjon og manipulering

1. SQL datadefinisjon og manipulering Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag SQL datadefinisjon og manipulering Tore Mallaug 7.10.2008 Lærestoffet er utviklet for faget Databaser 1. SQL datadefinisjon og manipulering

Detaljer

En kort presentasjon av

En kort presentasjon av En kort presentasjon av Axenna er leverandør av 100% Open Source Business Intelligence. Axenna Business Intelligence Server er satt sammen med de beste BIkomponentene fra de mest anerkjente Open Source

Detaljer

Høgskolen i Telemark EKSAMEN 6102 DATABASER 10.12.2015. Tid: 10-14. Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1

Høgskolen i Telemark EKSAMEN 6102 DATABASER 10.12.2015. Tid: 10-14. Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1 Høgskolen i Telemark EKSAMEN 6102 DATABASER 10.12.2015 Tid: 10-14 Målform: Sidetall: Hjelpemidler: Merknader: Bokmål/nynorsk 13 med forside Ingen Ingen Vedlegg: Eksempeldata til oppgave 1 Eksamensresultater

Detaljer

Oppgaver Oppgave a: Sett opp mulige relasjoner

Oppgaver Oppgave a: Sett opp mulige relasjoner Løsningsforslag til øving 4: Relasjonsmodellen Kjell Toft Hansen 18.09.2008 Opphavsrett: Forfatter og AITeL Lærestoffet er utviklet for faget LO151D Informatikk 1: databaser Oppgaver Oppgave a: Sett opp

Detaljer

INF1050 Klasseromsoppgave Uke 6

INF1050 Klasseromsoppgave Uke 6 INF1050 Klasseromsoppgave Uke 6 Løsningsforslag Mer avansert datamodellering med UML Oppgave 1 Her følger noen eksempler på opplysninger som brukeren ønsker å kunne trekke ut av informasjonssystemer. Foreslå

Detaljer

Definere relasjoner mellom ulike entiteter.

Definere relasjoner mellom ulike entiteter. Sammenligne ALL data Definere relasjoner mellom ulike entiteter. Kommuner tilhører fylker Måneder tilhører kvartaler og år Personer har kjønn og alder Semicolon 1 Underprosjekt av Semicolon I samarbeid

Detaljer

Datamodellering 101 En tenkt høgskoledatabase

Datamodellering 101 En tenkt høgskoledatabase Datamodellering 101 En tenkt høgskoledatabase Spesifikasjoner for databasen vi skal modellere: Oversikt over studenter med: Fullt navn Klasse Studium Avdeling Brukernavn Fødselsdag Adresse Telefonnummer

Detaljer

9-14. Tid: Målform: Sidetall: Hjelpemidler: Ingen. Merknader: Vedlegg: en lapp og. Avdeling

9-14. Tid: Målform: Sidetall: Hjelpemidler: Ingen. Merknader: Vedlegg: en lapp og. Avdeling Høgskolen i Telemark SLUTTPRØVE 5602 DATABASER 01.12.2009 Tid: Målform: Sidetall: Hjelpemidler: 9-14 Bokmål og nynorsk 17 (inkludert vedleggg og dennee forsiden) Ingen Merknader: Ingen Vedlegg: A: Eksempeldata

Detaljer

Gevinster ved å integrere SuperOffice og Agresso. Effektive integrasjons løsninger skaper nye muligheter.

Gevinster ved å integrere SuperOffice og Agresso. Effektive integrasjons løsninger skaper nye muligheter. Gevinster ved å integrere SuperOffice og Agresso. Effektive integrasjons løsninger skaper nye muligheter. Integrasjon. Etterspørselen etter integrasjonsløsninger er større enn noen gang. Behov for at ulike

Detaljer

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn EKSAMENSFORSIDE Skriftlig eksamen med tilsyn Emnekode: Emnenavn: 6102 Databaser Dato: Tid fra / til: 06.06.2017 10:00-14:00 Ansv. faglærer: Bjørn Kristoffersen Campus: Fakultet: Bø Handelshøyskolen Antall

Detaljer

Datakvalitet og Noark

Datakvalitet og Noark Datakvalitet og Noark IKA Hordaland 24.04.2017 thomas.sodring@hioa.no 1/17 Datakvalitet Datakvalitet som et eget forskningsfelt har eksistert siden 1970 tallet men det var etter 2000 tallet at flere og

Detaljer

Alle attributter har NULL som mulig verdi. mulige verdier for integer: NULL, 0, 1, 2, 3...

Alle attributter har NULL som mulig verdi. mulige verdier for integer: NULL, 0, 1, 2, 3... NULL verdier Alle attributter har NULL som mulig verdi mulige verdier for integer: NULL, 0, 1, 2, 3... Dog mulig å lage tabeller med attributter som forbyr NULL Ulik bruk: manglende informasjon («vet ikke

Detaljer

Høgskolen i Telemark EKSAMEN 6102 DATABASER Tid: Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1

Høgskolen i Telemark EKSAMEN 6102 DATABASER Tid: Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1 Høgskolen i Telemark EKSAMEN 6102 DATABASER 02.12.2014 Tid: 10-14 Målform: Sidetall: Hjelpemidler: Merknader: Bokmål/nynorsk 13 med forside Ingen Ingen Vedlegg: Eksempeldata til oppgave 1 Eksamensresultater

Detaljer

Del 1: ER-modellering og databaseteori

Del 1: ER-modellering og databaseteori Del 1: ER-modellering og databaseteori (a) ER-modellering Oppgavens del 1a er delt i tre deler. I første del skal det lages et ER-diagram for databasen til firmaet Sjokoladeland. Deretter skal det lages

Detaljer

ITGK - H2010, Matlab. Dagens tema : Teori - Databaser

ITGK - H2010, Matlab. Dagens tema : Teori - Databaser 1 ITGK - H2010, Matlab Dagens tema : Teori - Databaser 2 I dag Teori: Databaser Bok: 8.1 8.2 (8.1-8.4 i gamle bøker) Læringsmål Lære det grunnleggende om databaser Lære det grunnleggende om databasedesign

Detaljer

>>21 Datamodellering i MySQL Workbench

>>21 Datamodellering i MySQL Workbench 21 MYSQL WORKBENCH 207 >>21 Datamodellering i MySQL Workbench I dette kapittelet vil du lære hvordan man lager datamodeller i MySQL Workbench hvordan man overfører en modell til MySQL I tillegg til å være

Detaljer

Visma SuperOffice. Effektiviserer bedriftens salg og kundedialog

Visma SuperOffice. Effektiviserer bedriftens salg og kundedialog Visma SuperOffice Effektiviserer bedriftens salg og kundedialog Utvid Visma Business med en markedsledende CRM-løsning Et godt økonomisystem hjelper bedriften med å ha kontroll på kostnadene. Et godt verktøy

Detaljer

5602 DATABASER 02.12.2010. Bokmål/nynorsk. 17 (inkludert denne forsiden) Eksamensresultatene blir offentliggjort på Studentweb.

5602 DATABASER 02.12.2010. Bokmål/nynorsk. 17 (inkludert denne forsiden) Eksamensresultatene blir offentliggjort på Studentweb. Høgskolen i Telemark EKSAMEN 5602 DATABASER 02.12.2010 Tid: 9-14 Målform: Sidetall: Hjelpemidler: Merknader: Bokmål/nynorsk 17 (inkludert denne forsiden) Ingen Ingen Vedlegg: A: Eksempeldata og B: Svarark

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : INF3100/INF4100 Databasesystemer Eksamensdag : Onsdag 8. juni 2005 Tid for eksamen : 14.30 17.30 Oppgavesettet er på : 5 sider

Detaljer

INF 329: Web-Teknologier. Dataimplementasjon. Fra Kapittel 11 i «Designing Data-Intensive Web Applications» Presentasjonsdato: 17/10/2004

INF 329: Web-Teknologier. Dataimplementasjon. Fra Kapittel 11 i «Designing Data-Intensive Web Applications» Presentasjonsdato: 17/10/2004 INF 329: Web-Teknologier Dataimplementasjon Fra Kapittel 11 i «Designing Data-Intensive Web Applications» Presentasjonsdato: 17/10/2004 av: Dag Viggo Lokøen (dagvl@ii.uib.no) Kent Inge F. Simonsen (kentis@ii.uib.no)

Detaljer

Tilrettelegging av store datagrunnlag for analyse med SAS Scalable Performance Data Engine (SPDE) Steinar Helstrup 8.juni 2017

Tilrettelegging av store datagrunnlag for analyse med SAS Scalable Performance Data Engine (SPDE) Steinar Helstrup 8.juni 2017 Tilrettelegging av store datagrunnlag for analyse med SAS Scalable Performance Data Engine (SPDE) Steinar Helstrup 8.juni 2017 Agenda Bakgrunn Strukturering av datagrunnlag for analyse Last av datagrunnlag

Detaljer

EXCELERATOR KENNETH TORSTVEIT. Sensitivity: Internal

EXCELERATOR KENNETH TORSTVEIT. Sensitivity: Internal 1 EXCELERATOR KENNETH TORSTVEIT Hva er Excelerator? 2 Hva er Excelerator? Excel-tillegg (add-in) som kobles opp mot Unit4 Business World Kombinerer styrkene fra Unit4 Business World med fleksibiliteten

Detaljer

Det matematisk-naturvitenskapelige fakultet. Kontroller at oppgavesettet er komplett før du begynner å besvare det.

Det matematisk-naturvitenskapelige fakultet. Kontroller at oppgavesettet er komplett før du begynner å besvare det. UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : IN 212 - Databaseteori Eksamensdag : Onsdag 8. juni 1994 Tid for eksamen : 09.00-15.00 Oppgavesettet er på : 5 sider Vedlegg

Detaljer

SLUTTPRØVE 5602 DATABASER I 5.12.2008. 17 (inkludert vedlegg og denne forsida) Vedlegg: A: Eksempeldata og B: Svarark til oppgave 4

SLUTTPRØVE 5602 DATABASER I 5.12.2008. 17 (inkludert vedlegg og denne forsida) Vedlegg: A: Eksempeldata og B: Svarark til oppgave 4 Høgskolen i Telemark SLUTTPRØVE 5602 DATABASER I 5.12.2008 Tid: 9-14 Målform: Sidetal: Hjelpemiddel: Merknader: Bokmål og nynorsk 17 (inkludert vedlegg og denne forsida) Ingen Ingen Vedlegg: A: Eksempeldata

Detaljer

Oppsummering. Thomas Lohne Aanes Thomas Amble

Oppsummering. Thomas Lohne Aanes Thomas Amble Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt

Detaljer

Andre sett obligatoriske oppgaver i INF3100 V2013

Andre sett obligatoriske oppgaver i INF3100 V2013 Andre sett obligatoriske oppgaver i INF3100 V2013 Oppgavesettet skal i utgangspunktet løses av grupper på to og to studenter som leverer felles besvarelse. Vi godkjenner også individuelle besvarelser,

Detaljer

TDT4300 Datavarehus og datagruvedri3, Våren 2014

TDT4300 Datavarehus og datagruvedri3, Våren 2014 TDT4300 Datavarehus og datagruvedri3, Våren 2014 23/1 2014 Trond Aalberg 1 Dagens tema MulAdimensjonale data Dimensjoner og hierarkier revisited Fra modellering Al OLAP implementasjon Vi ser på eksempler

Detaljer

OM DATABASER DATABASESYSTEMER

OM DATABASER DATABASESYSTEMER OM DATABASER DATABASESYSTEMER Begrepet database brukes på flere måter, og det er ikke uvanlig å bruke det for å angi en total samling av data (i dette tilfellet lagrede opplysninger) uavhengig av hvordan

Detaljer

Integrasjon & Rapportering

Integrasjon & Rapportering Integrasjon & Rapportering Integrasjon. Etterspørselen etter integrasjonsløsninger er større enn noen gang. Behov for at ulike datasystemer fungerer sammen er satt i fokus. Keyforce leverer integrasjonsløsninger

Detaljer

En bedre måte å håndtere prosjekt, team, oppgaver og innhold

En bedre måte å håndtere prosjekt, team, oppgaver og innhold En bedre måte å håndtere prosjekt, team, oppgaver og innhold Bedre prosjekthå ndtering med metådåtå M-Files går langt utover bare enkel dokumenthåndtering. Den unike arkitekturen drevet av metadata lar

Detaljer

Hvordan databasesystemene kan hjelpe RAM-produsentene

Hvordan databasesystemene kan hjelpe RAM-produsentene Hvordan databasesystemene kan hjelpe RAM-produsentene Kreativ bruk av RAM i DBMSer Ragnar Normann Innhold Litt databasehistorie Litt UiO datahistorie Hvorfor (manglende) minnebruk i DBMSer er blitt et

Detaljer

1. Datamodellering. 1.1. Kommentarer til læreboka

1. Datamodellering. 1.1. Kommentarer til læreboka Tore Mallaug 20.10.2009 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for fagene LN323D Databaser 1. Datamodellering Resymé: Denne leksjonen viser et par eksempler på ER-modellering

Detaljer

Gerhard Skagestein: Systemutvikling fra kjernen og ut, fra skallet og inn.

Gerhard Skagestein: Systemutvikling fra kjernen og ut, fra skallet og inn. Gerhard Skagestein: Systemutvikling fra kjernen og ut, fra skallet og inn. Oppgaver til kapittel 5 - Datamodellering med UML Oppgave 6. Ugruppert og gruppert modell Et mindre bilutleiefirma ønsker å få

Detaljer

UiS-IKT Kompetanse 2010. Word 2007. Adresselister og fletting

UiS-IKT Kompetanse 2010. Word 2007. Adresselister og fletting UiS-IKT Kompetanse 2010 Adresselister og fletting Forord Om dette heftet Dette heftet inneholder nyttige tips og triks i Microsoft når du vil flette sammen standard dokumenter med en adresseliste. Forklaringene

Detaljer

Kunnskapsorganisasjon og gjenfinning 1. Relasjonsmodellen og -databaser

Kunnskapsorganisasjon og gjenfinning 1. Relasjonsmodellen og -databaser Kunnskapsorganisasjon og gjenfinning 1 Relasjonsmodellen og -databaser Tine L. Frost Relasjonsmodellen 17.09.2014 Dagens forelesning Pensum Berget, G. (2010). Relasjonsdatabaser og datamodellering (3.

Detaljer

Oppdatering av person/studentforekomster i FS mot folkeregisteret

Oppdatering av person/studentforekomster i FS mot folkeregisteret Oppdatering av person/studentforekomster i FS mot folkeregisteret Det forutsettes at tillatelse til oppdatering av FS mot folkeregisteret er innhentet og at man er registrert som kunde hos EVRY. Mal for

Detaljer

SQL og Mengdelære. Oracle, MySQL, Access, bruker forskjellige syntaks.

SQL og Mengdelære. Oracle, MySQL, Access, bruker forskjellige syntaks. SQL og Mengdelære Oracle, MySQL, Access, bruker forskjellige syntaks. Kan vi beskrive, hva SQL er og hva man kan gjøre med SQL, uavhengig av konkret syntaks!!! Hvilke universale formelle språk har vi til

Detaljer

Obligatorisk oppgave nr. 3 i INF1300 høsten 2009

Obligatorisk oppgave nr. 3 i INF1300 høsten 2009 Obligatorisk oppgave nr. 3 i INF1300 høsten 2009 Oppgaven er beregnet på å løses og leveres som et samarbeid mellom to studenter, men det er lov for dem som vil seg selv så vondt, å levere en individuell

Detaljer

Løsningsforslag maskindatabasen på Ifi SQL og normalisering

Løsningsforslag maskindatabasen på Ifi SQL og normalisering Løsningsforslag maskindatabasen på Ifi SQL og normalisering Oppgave 1 select prosjektid, ansattid, dato, timer from Prosjekttimer where status = 'merknad' order by prosjektid, ansattid; Oppgave 2 Fra primærnøkkelen

Detaljer

Det gjenstår nå kun å definere hva som skal være primærnøkkel i rolle rabellen.

Det gjenstår nå kun å definere hva som skal være primærnøkkel i rolle rabellen. Høgskolen i Østfold Databaser Datamodellering Noen temaer Rolf Henrik Bekkstrand 2008 Mange til mange Eksempel 1 Vi skal lage en datamodell for en database som skal representere filmer og skuespillere.

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO INF050/INF02 vår2005 Bokmål UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF 050 Systemutvikling INF02 Utvikling av datasystemer Eksamensdag: Onsdag 5. juni 2005 Tid for

Detaljer

TextureTool med SOSI-parser

TextureTool med SOSI-parser TextureTool med SOSI-parser Verktøy for teksturmapping og automatisk generering av 3D-modeller Hovedprosjekt 11E Erlend A. Lorentzen Jørn G. Nyegaard-Larsen 3DSU 2008/2009 Høgskolen i Sør-Trøndelag Avdeling

Detaljer

EKSAMEN DATABASER OG WEB Et maskinskrevet notat på maksimalt 2 A4-sider, satt med enkel linjeavstand og skriftstørrelse 12 (eller større).

EKSAMEN DATABASER OG WEB Et maskinskrevet notat på maksimalt 2 A4-sider, satt med enkel linjeavstand og skriftstørrelse 12 (eller større). EKSAMEN 6065 002 DATABASER OG WEB 11.05.2016 Tid: 4 timer (9-13) Målform: Sidetall: Hjelpemidler: Merknader: Vedlegg: Bokmål/Nynorsk 5 (inkludert denne) Et maskinskrevet notat på maksimalt 2 A4-sider,

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : INF3100/INF4100 Databasesystemer Eksamensdag : Tirsdag 8. juni 2004 Tid for eksamen : 09.00-12.00 Oppgavesettet er på : 5 sider

Detaljer

Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg. Prosjektnummer 2E

Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg. Prosjektnummer 2E Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg Prosjektnummer 2E 1. Innholdsfortegnelse 1. Innholdsfortegnelse 2 2. Norske Hus Boligsystem AS 3 3. Problemstillingen 3 4.

Detaljer

Databaser. - Normalisering -

Databaser. - Normalisering - Databaser - Normalisering - Innholdsfortegnelse 1. Normalisering... 2 1.1. Redundans... 2 1.2. Anomalier (uregelmessigheter etter oppdateringer i databasen)... 2 1.2.1. Innsettingsanomalier (Insertion

Detaljer

INF1300 Introduksjon til databaser

INF1300 Introduksjon til databaser INF1300 Introduksjon til databaser Data (transiente, persistente) DBMS databser informasjon interesseområdet informasjonsmodeller informasjonssystemer Transiente og persistente data Når vi programmerer,

Detaljer

Løsningsforslag til eksamen i IN2090 Databaser og datamodellering og INF1300 Introduksjon til databaser 6. desember :30 18:30 (4 timer)

Løsningsforslag til eksamen i IN2090 Databaser og datamodellering og INF1300 Introduksjon til databaser 6. desember :30 18:30 (4 timer) Løsningsforslag til eksamen i IN2090 Databaser og datamodellering og INF1300 Introduksjon til databaser 6. desember 2018 14:30 18:30 (4 timer) 1. Eksterne skranker (5%) I modellene nedenfor (ORM2) skal

Detaljer

INF130: Datahåndtering og analyse

INF130: Datahåndtering og analyse INF130: Datahåndtering og analyse Modellering 1.1 Temaer Kapittel 7 Modellering 2 Datamodellering med E/R Fasene i systemutvikling og databasedesign E/R (Entity/Relationship) Entitet Attributt Identifikator

Detaljer

Policy vedrørende informasjonskapsler og annen tilsvarende teknologi

Policy vedrørende informasjonskapsler og annen tilsvarende teknologi Policy vedrørende informasjonskapsler og annen tilsvarende teknologi 1. Hva omfavner denne policyen? Denne policyen dekker dine handlinger hva angår Tikkurila sine digitale tjenester. Policyen dekker ikke

Detaljer

IN3020 V2019 Obligatorisk oppgave nr. 1

IN3020 V2019 Obligatorisk oppgave nr. 1 IN3020 V2019 Obligatorisk oppgave nr. 1 Oppgavesettet skal løses og leveres individuelt. Gjennomføring og innlevering av oppgaven skal skje i henhold til gjeldende retningslinjer ved Institutt for informatikk,

Detaljer

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

Obligatorisk oppgave nr. 3 i INF1300 høsten 2008

Obligatorisk oppgave nr. 3 i INF1300 høsten 2008 Obligatorisk oppgave nr. 3 i INF1300 høsten 2008 Oppgaven er beregnet på å løses og leveres som et samarbeid mellom to studenter, men det er lov for dem som vil seg selv så vondt, å levere en individuell

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Innhold Forord Innledning Kapittel 1 Introduksjon til databaser og databasesystem

Innhold Forord Innledning Kapittel 1 Introduksjon til databaser og databasesystem Innhold Forord....................................................... 5 Innledning.................................................... 15 Databaser som basis i grunnopplæringen....................... 15

Detaljer

Hvorfor starte fra bunnen?

Hvorfor starte fra bunnen? Challenge us! Hvorfor starte fra bunnen? Rull ut BI4Dynamics på bare 1 dag! Installasjonsguiden bygger opp det komplette data warehouse på Microsoft SQL Server og ruller ut OLAP kuber i Microsoft Analysis

Detaljer

Dagens program. Kunnskapsorganisasjon og gjenfinning 1. Spørring mot databaser: SQL 2 - Spørring mot flere tabeller 12.11.2014

Dagens program. Kunnskapsorganisasjon og gjenfinning 1. Spørring mot databaser: SQL 2 - Spørring mot flere tabeller 12.11.2014 Kunnskapsorganisasjon og gjenfinning 1 Spørring mot databaser: SQL 2 - Spørring mot flere tabeller SQL 2 - flere tabeller 12.11.2014 Dagens program SQL oppgave 2 - løsningsforslag Spørring mot flere tabeller

Detaljer

Datavarehus hva er det?

Datavarehus hva er det? Datavarehus hva er det? Bill Inmon (ca. 1992): a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management's decision making process Ralph Kimball (ca. 1996):

Detaljer

Datamodellering med E/R

Datamodellering med E/R Datamodellering med E/R Fasene i systemutvikling og databasedesign E/R (Entity/Relationship) Entitet Attributt Identifikator Forhold og roller Kardinaliteter: 1:1, 1:M, M:N Oppløsing av mange-til-mange

Detaljer

Brukerveiledning. Gruppe 9

Brukerveiledning. Gruppe 9 Forord : I dette dokumentet vil du få presentert en brukerveiledning for databasesystemet som vi har laget for Nor daglig vare import. Dokumentet er illustrert med bilder, og i tillegg finnes det forklaringer

Detaljer

Oversikt Med ProHAB Kultur får man oversikt over alle lag og foreninger i en kommune eller organisasjon.

Oversikt Med ProHAB Kultur får man oversikt over alle lag og foreninger i en kommune eller organisasjon. ProHAB Kultur Lag og foreningsregister og tilskuddsmodul i ProHAB Administrasjonssystem eller selvstendig kulturprogram - Gir god oversikt over alle lag og organisasjoner - Er enkelt å lære - Gir forslag

Detaljer

Datamodellering og databaser http://www.aitel.hist.no/fag/_dmdb/ SQL, del 2

Datamodellering og databaser http://www.aitel.hist.no/fag/_dmdb/ SQL, del 2 http://www.aitel.hist.no/fag/_dmdb/ SQL, del 2 Eksempelbase side 2 Virtuelle tabeller (views) side 3-6 NULL-verdier side 7-14 UPDATE-setningen side 15-16 INSERT-setningen side 17 DELETE-setningen side

Detaljer

Databaser. Relasjonsmodellen 2 Læreboka: Kap. 2 Relasjonsmodellen

Databaser. Relasjonsmodellen 2 Læreboka: Kap. 2 Relasjonsmodellen Databaser Relasjonsmodellen 2 Læreboka: Kap. 2 Relasjonsmodellen Tema for dagen Hva er relasjonsalgebra? Seleksjon Projeksjon Produkt Indre forening Ytterforening Settoperasjoner: union, snitt, differanse

Detaljer

Første bestilling av kurs

Første bestilling av kurs DataPower Learning Online Første bestilling av kurs for bedriftskunder Versjon 2.x OKOKOK 1 Bestilling Finn aktuelt kurs For å finne det kurset du er på utkikk etter, kan du enten søke i søkefeltet eller

Detaljer

Oppgave 1 Datamodellering 25 %

Oppgave 1 Datamodellering 25 % Side 1 av 6 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap LØSNINGSFORSLAG TIL EKSAMENSOPPGAVE I FAG TDT4145 DATAMODELLERING OG DATABASESYSTEMER Eksamensdato:

Detaljer

Design, gjennomføring og viderebruk av risikoanalyser. Per Myrseth 7. november 2013

Design, gjennomføring og viderebruk av risikoanalyser. Per Myrseth 7. november 2013 Design, gjennomføring og viderebruk av risikoanalyser Per Myrseth Agenda Intro Design og gjennomføring Viderebruk av risikoanalyser Mulighetsrommet ved bruk av verktøystøtte og semantiske teknologier Oppsummering

Detaljer

FORORD...III KAPITTELOVERSIKT... VI INNHOLDSFORTEGNELSE...VII DEL I SQL OG RELASJONSDATABASER...1 1 INTRODUKSJON...

FORORD...III KAPITTELOVERSIKT... VI INNHOLDSFORTEGNELSE...VII DEL I SQL OG RELASJONSDATABASER...1 1 INTRODUKSJON... FORORD...III KAPITTELOVERSIKT... VI INNHOLDSFORTEGNELSE...VII DEL I SQL OG RELASJONSDATABASER...1 1 INTRODUKSJON... 3 1.1 DATABASESYSTEMER...3 1.1.1 Anvendelser...3 1.1.2 Oppgaver og arkitektur...4 1.1.3

Detaljer

Her er et eksempel på hvordan en konteringsmal brukes, under registrering av en telefonregning fra Telenor (Innkjøp > Leverandørfaktura):

Her er et eksempel på hvordan en konteringsmal brukes, under registrering av en telefonregning fra Telenor (Innkjøp > Leverandørfaktura): Konteringsmaler Konteringsmaler kan benyttes under bilagsregistrering og under registrering av leverandørfakturaer. De brukes for å forenkle konteringen av bilagene. Når du bruker en konteringsmal trenger

Detaljer

Sensorveiledning for IN2090 og INF desember :30 18:30 (4 timer)

Sensorveiledning for IN2090 og INF desember :30 18:30 (4 timer) Sensorveiledning for IN2090 og INF1300 6. desember 2018 14:30 18:30 (4 timer) 1. Eksterne skranker (5%) I modellene nedenfor (ORM2) skal du anta at alle begreper har en unik representasjon. Er plasseringen

Detaljer

7 tegn på at dere bør bytte forretningssystem

7 tegn på at dere bør bytte forretningssystem 7 tegn på at dere bør bytte forretningssystem Å bytte forretningssystem er en beslutning som modner over tid. En rekke problemstillinger har ført til at dere stiller kritiske spørsmål ved løsningen dere

Detaljer

2. Beskrivelse av mulige prosjektoppgaver

2. Beskrivelse av mulige prosjektoppgaver Avanserte databaser (øving 9, 10, 11 & 12) Tore Mallaug 25.01.2008 Opphavsrett:Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO326D Avanserte Databaser INNLEVERINGSFRISTER (Obligatorisk

Detaljer

Oppgave 3 - normalisering

Oppgave 3 - normalisering Oppgave 3 - normalisering Løsningsforslag Oppgave 3 - løsning 22.10.2014 Øvelsesoppgave 3 1. Normaliser logisk skjema fra oppgave 1 og 2 (Læringssenter) 2. Normaliser logisk skjema fra seminarøvelsen (Nøsteelskere)

Detaljer

HØGSKOLEN I SØR-TRØNDELAG

HØGSKOLEN I SØR-TRØNDELAG HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring - AITeL Kandidatnr: Eksamensdato: 21.mai 2007 Varighet: Fagnummer: Fagnavn: Klasse(r): Studiepoeng: 6 09.00 13.00 (4 timer) LN116D Programmering

Detaljer

SAS-forum 2013. BI Strategi og BICC

SAS-forum 2013. BI Strategi og BICC SAS-forum 2013 BI Strategi og BICC Tormod Kojen BN Bank ASA Agenda Kort om BN Bank Hvilke systemer har vi Modenhetsanalyse BI-strategi BICC 2 BN Bank BN Bank er en landsdekkende bank Innskudd fra kunder:

Detaljer

INF3100 V2016 Obligatorisk oppgave nr. 1

INF3100 V2016 Obligatorisk oppgave nr. 1 INF3100 V2016 Obligatorisk oppgave nr. 1 Oppgavesettet skal løses og leveres individuelt. Gjennomføring og innlevering av oppgaven skal skje i henhold til gjeldende retningslinjer ved Institutt for informatikk,

Detaljer

Datamodellering: ER-modeller ER = Enitity-Relationship del 1: Notasjon og oversetting av ulike ER-modeller til tilsvarende relasjonsmodeller

Datamodellering: ER-modeller ER = Enitity-Relationship del 1: Notasjon og oversetting av ulike ER-modeller til tilsvarende relasjonsmodeller LC238D http://www.aitel.hist.no/fag/_dmdb/ Datamodellering: ER-modeller ER = Enitity-Relationship del 1: Notasjon og oversetting av ulike ER-modeller til tilsvarende relasjonsmodeller ER-modellen, intro.

Detaljer

Miniverden og ER- modell

Miniverden og ER- modell TDT4145 Datamodellering og databasesystemer SQL- oppgave 1 Miniverden og ER- modell Vi tar utgangspunkt i en enkel modell for en pizza- restaurant, der følgende ER- diagram beskriver databasen: Relasjonsdatabase-

Detaljer

I denne veiledningen skal vi gå igjennom de forskjellige funksjonene som. For å gå til abonnementet ditt klikker du på den blå fanen "Abonnement":

I denne veiledningen skal vi gå igjennom de forskjellige funksjonene som. For å gå til abonnementet ditt klikker du på den blå fanen Abonnement: Administrere abonnementet I denne veiledningen skal vi gå igjennom de forskjellige funksjonene som er tilgjengelige for administrator av et abonnement på web. 1 Gå til abonnementet ditt For å gå til abonnementet

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Institutt for datateknikk og informatikk Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Roger Midtstraum: 995 72 420 Svein Erik Bratsberg: 995 39 963 Eksamensdato:

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : INF3100/INF4100 Databasesystemer Eksamensdag : Tirsdag 8. juni 2004 Tid for eksamen : 09.00-12.00 Oppgavesettet er på : 5 sider

Detaljer

EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER. Faglig kontakt under eksamen: Svein Erik Bratsberg og Roger Midtstraum

EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER. Faglig kontakt under eksamen: Svein Erik Bratsberg og Roger Midtstraum Side 1 av 5 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER Faglig kontakt under eksamen:

Detaljer

Oppgave: Finn navn og tittel på alle som har arbeidet på prosjektet «Vintersalg»

Oppgave: Finn navn og tittel på alle som har arbeidet på prosjektet «Vintersalg» Skjema Prosjekt(PId, Pnavn, KId, Pleder, StartDato) Ansatt(AId, Navn, Tittel, Fdato, Pnr, AnsDato) Timeliste(AId, Dato, PId, Timer) Kunde(KId, Knavn, Adresse) Oppgave: Finn navn og tittel på alle som har

Detaljer