Universitetet: ER-diagram

Transkript

1 Databaser Design och programmering Fortsättning på relationsmodellen: Normalisering funktionella beroenden normalformer informationsbevarande relationsschemauppdelning Varför normalisera? Metod att skydda oss från dum design Lagra samma data flera ggr i onödan Inte kunna lagra viss information Otydlig betydelse av en tupel som kan komma från otydlig betydelse av entitetsinstans Universitetet: ER-diagram e- f- läsperiod betyg år kurskod e-post poäng n kurs pnr reg. lösen på n n konto student m ansv. av hålls av e- f- institution adress jobbar på anställd driver tel.nr. n n tjänsterum anst.nr projekt budget tidsplan Relationsmodell Universitetet Student (pnr, e-, f-, epost, konto, lösen) Kurs (, kurskod, läsår, period, poäng, kursansv, institution) Anställd (f-, e-, anstnummer, rum, telefon, institution) Institution (, adress) Projekt(institution,, tidsplan, budget) RegistreradPå (studentpnr, kursnr, läsår, betyg) Relationen kurs (exempel) Problem med kurs Kurskod År Namn Läsperiod Poäng Kursansvarig Ansv Inst 732G Databaser vt2 7.5 Eva Ragnemalm IDA 729G Databaser ht2 7.5 Eva Ragnemalm IDA 732G Databaser vt2 7.5 Eva Ragnemalm IDA 732G Databaser vt2 7.5 Magnus Ingmarson IDA HIBB Databaser Vt 5 Magnus Ingmarson IDA Samma, poäng och institution återkommer: redundans Tar plats. Uppdateringsanomali Insättningsanomali Borttagningsanomali Otydlig tolkning Hur undvika redundans?

2 Normalisering En metod att finna redundans Normaliserings-villkor: normalformer Begrepp: funktionella beroenden kom ihåg: nycklar och primattribut informationsbevarande relationsschemauppdelning :a Normalform Alla attribut ska vara atomära (odelbara) Relationsmodellen antar att alla attribut är odelbara. 2:a normalform, 3:e normalform, BCNF baseras på Funktionella beroenden i relationen. Funktionellt beroende X är en delmängd av attributen i en relation. Om X entydigt bestämmer värdet på ett attribut Y, kallas det att Y är funktionellt beroende av X eller att X bestämmer Y. X Y X kallas determinant i det funktionella beroendet. Exempel För nycklar finns alltid fb till alla attribut i hela relationen: ex: Student {pnr} {e-} {pnr} {f-} {pnr} {konto} {pnr} {epost} {pnr} {lösen} men även: {pnr} {pnr} {konto} {pnr,e-,f-,epost,konto,lösen} {epost} {pnr,e-,f-,epost,konto,lösen} Funktionella beroenden, forts Fullt funktionellt beroende Funktionella beroenden baseras på relationens semantik. Ett fb ska gälla i alla möjliga instanser av databasen OBS: Att det finns ett fb X Y betyder inte att det finns ett fb Y X Givet X Y. Om inget attribut kan tas bort ur X utan att vi förlorar det funktionella beroendet (dvs X är minimal), kallas det fullt funktionellt beroende, ffb ex: Kurs (, kurskod, läsår, period, poäng, kursansv, institution) {kurskod, läsår} {kursansv} {kurskod, läsår} {poäng} Ej för en kurs får inte ändra poäng hur som helst

3 Fullt funktionellt beroende, forts exemplet kurs {kurskod} {poäng} Ett attribut (poäng) är ej av nyckeln Andra i Kurs: {kurskod} {} {kurskod} {institution} OBS att verkligheten styr Andra normalformen - 2NF Definition: Ett relationsschema R är i 2NF om det är i :a normalform och varje icke-primattribut A i R är av varje kandidatnyckel i R. Fråga: Är alla attribut som inte är primattribut av alla kandidatnycklar? Exempel 2NF Exemplet kurs Relationen Student (pnr, e-, f-, epost, konto, lösen) Har : {pnr} {e-, f-, lösen} {konto} {e-, f-, lösen} {epost} {e-, f-, lösen} Kurs (, kurskod, läsår, period, poäng, kursansv, institution) {kurskod, läsår} {kursansv} {kurskod, läsår} {läsperiod} {kurskod} {poäng} {kurskod} {} {kurskod} {institution} Uppfyller ej 2NF Relationsschemauppdelning Lyft ut det/de problematiska funktionella beroendet/na till en egen tabell Exempel: Kurs (kurskod,, poäng, institution) KursÅr(kurskod, läsår, kursansv, läsperiod) informationsbevarande? Informationsbevarande relationsschemauppdelning Om vi delar upp en relation R i relationerna R och R2 så kallas uppdelningen informationsbevarande om R * R2 innehåller samma information som R. * = naturlig sammansättning Varken mer eller mindre naturlig sammansättning

4 Informationsbevarande relationsschemauppdelning, exempel Person(Pnr,Namn,Adress) med funktionella beroenden: Pnr Namn, Pnr Adress, inte Namn Adress pnr Adress Anna Ågatan Anna Rydsv.2 pnr Anna Anna Adress Anna Ågatan 3 Anna Rydsv.2 Exempel En firma som administrerar andrahandsuthyrning av lägenheter vill hålla reda på kontraktisinformationen. Man vill hålla reda på vem hyr vad (kund, kundnummer, lägenhetsnummer, lägenhetsadress) när (start och slutdatum) samt till vilken hyra (som är olika för varje lägenhet). De lagrar också information om vem som egentligen äger lägenheten. För tills vidare -kontrakt registreras slutdatum som null. Varje person antas bara hyra varje lägenhet en gång och kan bara hyra en lägenhet åt gången. En ägare kan dock låta firman hantera flera lägenheter. Möjlig relationsmodell: Kontrakt(kundNr, lghnr, knamn, lghadr, start, slut, hyra, ägarnr, änamn) :a normalform? 2:a normalform? Funktionella beroenden? Kontrakt(kundNr, lghnr, knamn, lghadr, start, slut, hyra, ägarnr, änamn) Fb, 5 och 6 visar kandidatnycklarna: {kundnr, lghnr}, {lghnr, start} samt {kundnr, start} Primattribut? kundnr, lghnr, start Det innebär att följande attribut är ickeprimattribut: knamn, lghadr, slut, hyra, ägarnr, änamn Dela upp relationen så att de problematiska beroendena får en egen relation. Kund(kundNr, knamn) Lgh(lghNr, lghadr, hyra, ägarnr, änamn) Hyra(kundNr, lghnr, start, slut) Är dessa i 2NF? Är informationen bevarad? 2NF?

5 Övning på informationsbevarande relationsschemauppdelning Kund Lgh Kund Lgh Start Slut Hyra Ägar Ägar nr Nr Namn Adr Nr Namn CR76 PG4 J.Kay Lagv CO40 T.Moe CR76 PG6 J.Kay Nyv null 3500 CO93 U.Sin CR56 PG4 A.Son Lagv null 3200 CO40 T.Moe CR56 PG35 A.Son Husg CO93 U.Sin CR56 PG6 A.Son Nyv CO93 U.Sin Tredje normalform - 3NF Definition: Ett relationsschema R är i 3NF om det är i 2NF och det för varje X A som finns i R, gäller något av följande villkor: a) X är en supernyckel för R b) A är ett primattribut i R Frågan för 3NF: För varje beroende: är X en supernyckel eller Y ett primattribut? Dela upp igen. Exempel (3NF) LghInfo(lghNr, lghadr, hyra, ägarnr) Ägare (ägarnr, änamn) Kund(kundNr, knamn) Hyra(kundNr, lghnr, start, slut) Är dessa i 3NF? Boyce-Codd normalform - BCNF Ett relationsschema R är i BCNF om det är i 3NF och för varje beroende X A som finns i R, X är en supernyckel för R. Dvs alla determinanter är antingen en kandidatnyckel eller innehåller en (hel). Frågan för BCNF: är varje determinant en supernyckel? Exempel (BCNF) 3NF/BCNF Frågan för BCNF: är varje determinant en supernyckel? LghInfo(lghNr, lghadr, hyra, ägarnr) Ägare (ägarnr, änamn) Kund(kundNr, knamn) Hyra(kundNr, lghnr, start, slut) Inte alltid möjligt att transformera ett schema till BCNF och behålla beroendena. 3NF har de flesta av BCNF s fördelar. Det är inte självklart att man måste uppfylla BCNF. OBS: 3NF tillåter någon sorts redundans som BCNF inte gör (funktionella beroenden mellan primattribut).

6 Ytterligare exempel Exempel på rapport Antag att uthyrningsfirman inspekterar varje lägenhet mellan uthyrningarna och noterar brister och problem. När inspektion ska göras rekvirerar man en bil som används under dagen. En bil kan dock användas av flera personer under samma dag, men en inspektör bokar samma bil hela dagen. En inspektör kan inspektera flera lägenheter under samma dag, men varje lägenhet inspekteras endast en gång en viss dag. Det finns alltså ett (eller flera) sådana rapportformulär per lägenhet. Lägenhetsnummer: PG4 Lägenhetsadress Studentv 8 Nollköping Inspektions datum Tid Kommentar Inspektör Nr Inspektör Namn BilNr Trasigt proslin SG37 Ann Beech ABC Fint SG4 David Ford DEF Mögel i badrum SG4 David Ford GHI987. Funktionella beroenden? Facit: lgh(lghnr, lghadr) personal(pnr, pnamn) inspektion(lghnr, idatum, itid, kommentar, pnr) personbil(pnr, idatum, bil)