Tid: 9-13
Hjelpemidler: Ingen
Vekting ved sensur:
Oppgave 1 teller 40%, oppgave 2 teller 40% og oppgave 3 teller 20%. Totalt 100% av samlet karakter i emnet.
Innenfor hver oppgave teller deloppgavene likt.
Følgende tabeller blir brukt i et system for gjennomføring av nettauksjoner:
Primærnøkler er understreket og fremmednøkler er merket med en stjerne. Budfrist inneholder datoer. Minstepris og Beløp inneholder kronebeløp. ProdNr og KatNr inneholder heltall. Øvrige kolonner inneholder tekster.
Produkter er plassert i kategorier. Eksempel på et produkt kan være et konkret stuebord med 6 stoler, plassert i kategorien "Møbler". Et produkt lagt ut for salg har en budfrist og eventuelt en minstepris. Alle budfrister utløper kl. 24, så kun datoen blir lagret. Både selgere og budgivere må registrere seg med epost-adresse og et kallenavn. Kolonnen Produkt.Epost inneholder epost-adressen til selgeren. Om et bud blir det registrert hvilket produkt budet gjelder, epost-adressen til budgiveren og selve beløpet. En budgiver kan by flere ganger på det samme produktet, men kun det høyeste budet (av denne budgiveren på dette produktet) blir lagret. Kun bud registrert innen budfristen blir lagret.
Skriv SQL-kode for å vise navn og minstepris for alle produkter til salgs i kategorien "Møbler". Sorter utskriften stigende på minstepris. Merk at tabellen Produkt også inneholder produkter som allerede er solgt. Vi ønsker her kun produkter som har budfrist fram i tid. Tips: Date() gir dagens dato (i MS Access).
Skriv SQL-kode for å definere tabellen Bud. Sørg for at Beløp alltid blir fylt ut.
Skriv SQL-kode for å vise salgsprisen for hvert produkt, det vil si det høyeste budet som er registrert (før budfristen utløper). Ta med både produktnummer og navn i utskriften.
Skriv SQL-kode for å vise gjennomsnittlig salgspris for hver kategori. Tips: Bygg gjerne videre på besvarelsen til oppgave 1-c.
Anta produkt med produktnummer 5013 ligger ute for salg. Skriv SQL-kode for å registrere en ny bruker med epost ole.hansen@xyz.no og kallenavn oleh, og legge inn et bud på kr. 2500 av denne brukeren på dette produktet.
Universitetet i Utopia (UiU) skal videreutvikle informasjonssystemet sitt til å håndtere hybelhus.
Bare studenter som er tatt opp til et studium ved UiU kan søke om hybel. Det eksisterer allerede en database med opplysninger om studenter og studier:
Lag en begrepsmessig datamodell (et E/R-diagram) som tilsvarer denne tabellstrukturen. I oppgave 2-b skal du bygge videre på denne datamodellen.
UiU eier og driver et antall hybelhus lokalisert på forskjellige steder i hovedstaden. Hvert hybelhus har et unikt navn. Et hybelhus kan ha flere etasjer. Innen hver etasje i et hybelhus er hyblene nummerert fortløpende fra 1 og oppover. Hyblene er plassert i kostnadskategorier A til E, som hver har en månedspris og et depositum. Om hver hybel blir det lagret størrelse målt i kvadratmeter, antall rom, om det er muligheter for tilkobling til internett, om det er fellesdusj og felleskjøkken. For hybler med felleskjøkken skal man også lagre hvor mange man må dele kjøkken med. Noen hybler kan leies ut som par-hybler ved å åpne en skillevegg. For å kunne behandle slike hybler, må systemet lagre hvilke to hybler som "hører sammen".
Studentene kan søke om hybel samtidig som de søker opptak til studier, men kan også søke om hybel underveis i studietiden. Søknaden om hybel kan påføres ønske om et konkret hybelhus, eller en maksimumspris. Det er også mulig å føre opp inntil 5 andre studenter, i prioritert rekkefølge, som man gjerne vil dele hybelhus med.
Tildeling av hybler skjer i hovedsak to uker før studiestart. Studenter som får tilslag inngår da en leie¬avtale med UiU for en konkret hybel med avtalt varighet (fra 6 måneder opp til 5 år). Studenter som ikke får hybel blir overført til en venteliste. Studenter som søker underveis i studieåret blir automatisk lagt inn på denne ventelisten. Hvis studenter flytter ut i løpet av studieåret, får en av studentene på ventelisten tilbud om hybelen. De som har ventet lengst har førsteprioritet (med loddtrekning mellom de som har ventet like lenge).
Det er ønskelig at systemet tar vare på viktige datoer som gjelder hver student: når søknaden ble mottatt, når studenten (eventuelt) ble overført til venteliste, og når studenten (eventuelt) fikk tilbud om hybel.
Utvid E/R-modellen fra oppgave 2-a med informasjon om hybler, søknader, leieavtaler og ventelister.
Utfør logisk databasedesign basert på E/R-modellen i oppgave 2-b, dvs. oversett E/R-modellen til tabellstruktur. Ta bare med de ”nye” tabellene. Markér primærnøkler med strek og fremmednøkler med stjerne (*). Du skal ikke skrive SQL-kode eller bestemme datatyper.
Betrakt tabellen T(A,B,C,D,E), der de funksjonelle avhengighetene A → C og D → E gjelder. Bestem kandidatnøkkel og utfør normalisering til BCNF.
Betrakt tabellen Produkt beskrevet i oppgave 1. Gi et eksempel på tapt oppdatering (lost update) mot denne tabellen, gjerne ved å tegne en kjøreplan. Forklar deretter hvordan slike problemer kan unngås.
Forklar hva vi legger i begrepene rolle, systemrettighet og objektrettighet innen brukeradministrasjon. Skriv også SQL-kode for å tildele leserettighet på tabellen Produkt til brukeren Ole.