Løsningsforslag maskindatabasen på Ifi SQL og normalisering

Like dokumenter
Eksamensoppgaver. Og for all del: Vær kritiske til de løsningsforslagene vi presenterer! Vi påstår ikke at de er optimale.

Integritetsregler i SQL. Primærnøkler

Integritetsregler i SQL

Dagens tema: Oppdateringsanomalier Normalformer

INF1300 Introduksjon til databaser

Repetisjon: Normalformer og SQL

INF1300 Introduksjon til databaser

Oppdateringsanomalier Normalformer

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

Oppgave 1 1. Spørring: Resultattabell: 2. Spørring: Resultattabell: 3. Spørring:

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

Databaser: Relasjonsmodellen, del I

Miniverden og ER- modell

Integritetsregler i SQL

Relasjonsdatabasedesign

Databaser. Relasjonsmodellen 1 Læreboka: Kap. 2 Relasjonsmodellen Faglærere: Tore Mallaug, Kjell Toft Hansen

Oppdateringsanomalier. Normalformer. Institutt for informatikk INF

SQL Structured Query Language. Definere tabeller Skranker Fylle tabeller med data

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Normalisering. Hva er normalisering?

Normalisering. Hva er normalisering?

Oppgaver Oppgave a: Sett opp mulige relasjoner

EKSAMEN 6102 / 6102N DATABASER

1. Relasjonsmodellen Kommentarer til læreboka

IN2090 Databaser og datamodellering. Databasedesign og normalformer

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn

Relasjonsdatabasedesign

Relasjonsdatabaseteori

Workflow registrere faktura

Normalisering. Hva er normalisering?

Datamodellering og databaser SQL, del 2

UNIVERSITETET. Relasjonsdatabasedesign

For alle ikke-trivielle FDer X A i R: eller A er et nøkkelattributt i R eller X K for noen kandidatnøkkel K i R

God Databasedesign: På vei mot Normalformer

Relasjonsdatabasedesign

Datamodellering og databaser SQL, del 2

Datamodellering og databaser SQL, del 2

Normalformer or Normalisering 1NF, 2NF, 3NF, BCNF

Hva kjennetegner god relasjonsdatabasedesign? Eksempel: Grossistdatabase versjon 1

D: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.

Plenum: Nøkler, normalformer og funksjonelle avhengigheter

SQL: Integritetsregler, triggere og views

Eksamensoppgaver. Og for all del: Vær kritiske til de løsningsforslagene vi presenterer! Vi påstår ikke at de er optimale.

1. SQL datadefinisjon og manipulering

Dagens tema: Relasjonsmodellen (funksjonelle avhengigheter og nøkler, integritetsregler) Realisering: Fra ORM til relasjoner

Relasjonsdatabasedesign

Relasjonsdatabasedesign

Institutt for datateknikk. Fag TDT4145 Datamodellering og databasesystemer Løsningsforslag til øving 3: Algebra og SQL

Relasjonsdatabasedesign. Ekstramateriale: Normalformer utover 4NF (ikke pensum)

Løsning til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Relasjonsdatabasedesign

INF1300 SQL Structured Query Language del 1. Stoff som blir/ble forelest i oktober 2013

Normalformer utover 4NF (ikke pensum)

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

HØGSKOLEN I SØR-TRØNDELAG

INF1300 Introduksjon til databaser

SQL 3: Opprette tabeller, datainnsetting og utsnitt

UNIVERSITETET. triggere og views. Institutt for Informatikk. INF Arne Maus 1

Relasjonsdatabasedesign

INF1300 Introduksjon til databaser: SQL Structured Query Language. En første introduksjon Lysark til forelesning mandag 14.

EKSAMEN DATABASER

INF3100 Databasesystemer

Notater: INF1300. Veronika Heimsbakk 8. januar 2013

UNIVERSITETET I OSLO. Relasjonsmodellen. Relasjoner og funksjonelle avhengigheter. Institutt for Informatikk. INF Ellen Munthe-Kaas 1

Relasjonsdatabasedesign

UNIVERSITETET SQL-99. Institutt for Informatikk. INF Ellen Munthe-Kaas 1

INF1300 Introduksjon til databaser: SQL Structured Query Language. En første introduksjon Lysark til forelesning onsdag 22.

Databaser. - Normalisering -

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

Ekvivalente stier (Equivalence of Path, EOP) i storm

Løsningsforslag matoppskrifter modellering

UNIVERSITETET I OSLO. Oppskriftsbok. FDer og MVDer Relasjonsalgebra. Institutt for Informatikk. INF3100 Ellen Munthe-Kaas 1

Oppskriftsbok. FDer og MVDer - oversikt: se s. 3 Relasjonsalgebra - oversikt: se s. 45

HØGSKOLEN I SØR-TRØNDELAG

Løsningsforslag eksamen i IN

Løsningsskisse til eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Relasjonsdatabasedesign

INF1300 Introduksjon til databaser

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet. Løsningsforslag

Skisse til løsning av eksamensoppgave i TDT4145 Datamodellering og databasesystemer

INF1300 Introduksjon til databaser

Relasjonsdatabasedesign

HØGSKOLEN I SØR-TRØNDELAG

EKSAMEN. Kontroller at oppgavesettet er komplett før du begynner å besvare spørsmålene.

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

INF1300 Introduksjon til databaser: SQL Structured Query Language

Andre sett obligatoriske oppgaver i INF3100 V2009

Oppgave 1 (Opprett en database og en tabell)

EKSAMEN 6102 / 6102N DATABASER

Utvikling fra kjernen og ut

IN2090 Introduksjon til databaser

EKSAMENSFORSIDE Skriftlig eksamen med tilsyn

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

INF1300 Introduksjon til databaser

SQL: Datatyper m.m. Evgenij Thorstensen V18. Evgenij Thorstensen SQL: Datatyper m.m. V18 1 / 12

Relasjonsdatabasedesign

Utvikling fra kjernen og ut

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

Transkript:

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 has FDen (1) ansattid, prosjektid, dato timer, status, godkjennerid Fra oppgaveteksten has i tillegg FDen (2) prosjektid, dato, status godkjennerid Eneste kandidatnøkkel er primærnøkkelen: (ansattid, prosjektid, dato). (1) er på BCNF fordi venstresiden er en kandidatnøkkel og dermed en supernøkkel. (2) er på 2NF fordi venstresiden ikke er delmengde av kandidatnøkkelen. Den bryter 3NF fordi venstresiden ikke er en supernøkkel og høyresiden ikke er et nøkkelattributt. Totalt er derfor tabellen på 2NF. Den bryter 3NF. Oppgave 3 create table Detaljlinje ( leverandør varchar(30) references Leverandør(navn), fakturanr varchar(30), linjenr integer, antall integer not null, konto varchar(30), primary key (leverandør, fakturanr, linjenr, konto), foreign key (leverandør, fakturanr, linjenr) references Fakturalinje(leverandør, fakturanr, linjenr) ); 43

Man kan også vurdere om man skal ha med foreign key (leverandør, fakturanr) references Faktura(leverandør, fakturanr). Det kan godt stå 'not null' på nøkkelattributtene også, men dette påtvinges automatisk via primary key og er derfor ikke nødvendig å ha med. Oppgave 4 Fremmednøkkelen fra Fakturalinje til Faktura består av attributtene (leverandør, fakturanr). De tilsvarende attributtene i Faktura er dens primærnøkkel (denne heter også (leverandør, fakturanr).) Når det legges inn et nytt tuppel i Fakturalinje, må det sjekkes at det fins et tilhørende tuppel i Faktura (dvs. attributtverdier i Faktura-tuppelets primærnøkkel er likt verdiene i fremmednøkkelen i Fakturalinje-tuppelet). Det samme gjelder hvis et tuppel i Fakturalinje får endrede verdier i fremmednøkkelen. Når det fjernes et tuppel fra Faktura, må det sjekkes at det ikke fins tupler i Fakturalinje med tilsvarende verdier i fremmednøkkelen. Det samme gjelder hvis et tuppel i Faktura får endrede primærnøkkelverdier; da må de verdiene som ble overskrevet, ikke ha tilhørende tupler i Fakturalinje. Oppgave 5 select s.navn as navn, max(s.e-post) as e-post, sum(beløp) as totalbeløp from Leverandør s, Faktura f where s.navn = f.leverandør and f.leveringsdato > 2007 group by s.navn order by totalbeløp; (Noen DBMSer godtar at s.e-post brukes uaggregert i select fordi e-post er entydig for et gitt navn, men generelt skal det aggregeres over attributter i select som ikke forekommer i group by. Når vi vet at alle verdiene i s.epost vil være like for en gitt verdi i s.navn, kan vi i såfall få tak i s.e-post ved å si max(s.e-post).) Oppgave 6 Summer først opp beløpene som står implisitt i Fakturalinje for gitt faktura med leverandør x og fakturanummer y. Det som egentlig står, er antall og stykkpris, så beløpene må beregnes for hver fakturalinje. Siden dette ikke kan gjøres i argumentet til sum, må vi ha en egen beregning av disse før det summeres. 44

create view SumFakturalinje as select sum(pris) as linjepris from (select antall * stykkpris as pris from Fakturalinje where leverandør = x and fakturanr = y ); Sammenlign så totalbeløpet i Faktura med den beregnede summen fra Fakturalinje. select f.beløp - l.linjepris as diskrepanse from SumFakturalinje as l, Faktura f where f.leverandør = x and f. fakturanr = y and f.beløp - l.linjepris!= 0; Oppgave 7 En delleveranse fremkommer ved at det fins minst én faktura for vedkommende ordre. At ikke hele ordren er levert, er kjennetegnet ved at antallet enkeltvarer i fakturaene summerer seg til mindre enn antallet angitt i ordren. Så man kan rett og slett summere antall enheter og slik få en sjekksum som indikerer om ordren er komplett. Sjekksum for ordrene: create view OrdreSjekksum as select leverandør, ordrenr, sum(antall) as sjekksum from Ordrelinje group by leverandør, ordrenr; Sjekksum for leveransene: create view LeveranseSjekksum as select f.leverandør as leverandør, f.ordrenr as ordrenr, sum(antall) as sjekksum from Faktura f, Fakturalinje l where f.leverandør = l.leverandør and f.fakturanr = l.fakturanr group by f.leverandør, f.ordrenr; Svaret er ordre hvor disse er forskjellige: select o.leverandør, o.ordrenr from OrdreSjekksum o, LeveranseSjekksum d where o.leverandør = d.leverandør and o.ordrenr = d.ordrenr and o.sjekksum!= d.sjekksum; 45

Oppgave 8 La w være den aktuelle kontoen. Fakturaer som gjelder w, summerer seg opp slik: create view SumFaktura as select sum(beløp) as f-beløp from Faktura where konto = w and leveringsdato > 2007 ; Fra disse beløpene skal trekkes beløp vedrørende fakturalinjer som gjelder andre konti. Disse beløpene summerer seg til følgende: create view SumFakturalinjerAndre as select sum(beløp) as la-beløp from (select l.antall * l.stykkpris as beløp from Fakturalinje l, Faktura f where l.leverandør = f.leverandør and f.konto = w and f.leveringsdato > 2007 and l.konto is not null and l.konto!= w ); I tillegg til de fakturaene som gjelder w, kommer fakturalinjer hvor tilhørende (hoved-)faktura gjelder en annen konto, men hvor fakturalinjene gjelder w. Disse beløpene summerer seg til følgende: create view SumFakturalinjer as select sum(beløp) as l-beløp from (select l.antall * l.stykkpris as beløp from Fakturalinje l, Faktura f where l.leverandør = f.leverandør and f.leveringsdato > 2007 and f.konto!= w and l.konto = w ); 46

Til fratrekk fra beløp som stammer fra slike fakturalinjer, kommer fakturadetaljlinjer som gjelder andre konti: create view SumDetaljlinjerAndre as select sum(beløp) as da-beløp from (select d.antall * l.stykkpris as beløp from Detaljlinje d, Fakturalinje l, Faktura f where d.leverandør = l.leverandør and d.fakturanr = l.fakturanr and d.linjenr = l.linjenr and l.leverandør = f.leverandør and f.leveringsdato > 2007 and f.konto!= w and l.konto = w and d.konto!= w ); I tillegg kommer detaljlinjer hvor tilhørende faktura ikke gjelder w, en fakturalinje heller ikke gjelder w, men hvor detaljlinjen skal belastes w: create view SumDetaljlinjer as select sum(beløp) as d-beløp from (select d.antall * l.stykkpris as beløp from Detaljlinje d, Fakturalinje l, Faktura f where d.leverandør = l.leverandør and d.fakturanr = l.fakturanr and d.linjenr = l.linjenr and l.leverandør = f.leverandør and f.leveringsdato > 2007 and f. konto!= w and (l.konto is null or l.konto!= w ) and d.konto = w ); Det kan strengt tatt tenkes at en hovedfaktura som nevner w som konto, har en eller flere fakturalinjer som nevner en annen konto, og hvor detaljlinjer igjen nevner w som konto. Det burde riktignok være et krav at hovedkonto ikke får gjentas i detaljlinjer; i den grad det er fakturalinjer hvor noen deler skal belastes hovedkonto og noen andre konti, bør fakturalinjen heller gjenta hovedkonto (dvs. med en null-forekonst i attributtet konto), og med avvikende konti i detaljlinjene. Men vi kan jo ta slike beløp med for å være på den sikre siden. De fremkommer ved å gjøre følgende: 47

create view SumDetaljlinjer2 as select sum(beløp) as d-beløp2 from (select d.antall * l.stykkpris as beløp from Detaljlinje d, Fakturalinje l, Faktura f where d.leverandør = l.leverandør and d.fakturanr = l.fakturanr and d.linjenr = l.linjenr and l.leverandør = f.leverandør and f.leveringsdato > 2007 and f.konto = w and l.konto is not null and l.konto!= w and d.konto = w ); Totalt blir svaret: select (f.f-beløp - la.la-beløp + d2.d-beløp2 + l.l-beløp - da.da-beløp + d.d-beløp) as belastet from SumFaktura f, SumFakturalinjerAndre la, SumFakturalinjer l, SumDetaljlinjerAndre da, SumDetaljlinjer d, SumDetaljlinjer d2; 48