Kvalitetstänkande Utgångsläge Samtliga ER-diagram har överförts till scheman
Förbättra kvaliteten på relationsscheman Normalformler ger dugligare nycklar Hitta funktionella beroenden med hjälp av slutsatsdragning
videoid date movieid title genre length rating Acquired 115 1/25/98 101 The Thirty -Nine mystery 101 PG Steps 90987 2/5/97 450 Elizabeth costume drama 123 PG-13 145 12/31/95 145 Lady and the Tramp animated drama 93 G 8034 4/5/98 145 Lady and the Tramp animated drama 93 G 90988 4/5/98 450 Elizabeth costume drama 123 PG-13 90989 3/25/86 450 Elizabeth costume drama 123 PG-13 543 5/12/95 101 The Thirty -Nine mystery 101 R Steps 1243 4/29/91 123 Annie Hall romantic comedy 110 R Anomalier inträffar när data är inkonsistenta, t ex när data inte överensstämmer från den ena raden till den andra. Värderedundans gör att anomalier kan uppstå. Redundans = överflödighet; identiska data finns på två eller flera ställen Ändringsanomali (update anomaly) inträffar när värden i två skilda rader som bör vara lika inte är det.
videoid date movieid title genre length rating Acquired 115 1/25/98 101 The Thirty -Nine mystery 101 PG Steps 90987 2/5/97 450 Elizabeth costume drama 123 PG-13 145 12/31/95 145 Lady and the Tramp animated drama 93 G 8034 4/5/98 145 Lady and the Tramp animated drama 93 G 90988 4/5/98 450 Elizabeth costume drama 123 PG-13 90989 3/25/86 450 Elizabeth costume drama 123 PG-13 543 5/12/95 101 The Thirty -Nine mystery 101 R Steps 1243 4/29/91 123 Annie Hall romantic comedy 110 R 114 6/5/98 450 Elizabeth costume drama 110 R Anomalier inträffar när data inte överensstämmer Värderedundans medför att anomalier kan uppstå Deletion anomaly (borttagningsanomali) inträffar när raden (den rosa) med videoid = 1243 tas bort - information om movie försvinner när video tas bort Insertion anomaly (inmatningsanomali) orsakas genom inmatning av raden längst ner (den blåa) - längd och lämplig ålder (rating) överensstämmer inte med de gröna raderna
VideoMovie: FD2 (videoid, dateacquired, movieid, title, genre, length, rating) Värdet på movieid bestämmer värdena på title, length, rating. Värdena på de fyra attributen bestäms av värdet på movieid. Om attributvärdena title, length och rating har samma värde i två olika rader så är också attributvärdet på movieid lika. Det här kopplingsberoendet kallas för funktionellt beroende och förkortas FD (functional dependency) Exempel: movieid bestämmer värdena på title, genre, length, rating - varje rad (tuple) med movieid = 123 har samma värden på de andra attributen - FD2: movieid {title, genre, length, rating}
accountid lastname firstname street city state zipcode 101 Block Jane 123 Main St. Apopka FL 30458 102 Hamilton Cherry 3230 Dade St. Dade City FL 30555 103 Harrison Kate 103 Dodd Hall Apopka FL 30457 104 Breaux Carroll 76 Main St. Apopka FL 30457 106 Morehouse Anita 9501 Lafayette St. Houma LA 44099 111 Deaux Jane 123 Main St. Apopka FL 30458 201 Greaves Joseph 14325 N. Bankside St. Godfrey IL 43580 Kan vi i tabellen hitta funktionella beroenden? ex zipcode = 30458 street, city, state = zipcode = 30457 Customer: FD4 (accountid, lastname, firstname, street, city, state, zipcode) FD5 FD4: zipcode {city, state} FD5: {street, city, state} zipcode
Customer: (accountid, lastname, firstname, street, city, state, zipcode) FD6 Benämningen FD6 och pilfiguren hör ihop accountid är nyckel i Customer FD6: accountid {lastname, firstname, street, city, state, zipcode} Customer: (accountid, lastname, firstname, street, city, state, zipcode) FD7 En supernyckel är en samling attribut som bestämmer innehållet på de resterande attributen i schemat; det råder alltså ett funktionellt beroende
Funktionellt beroende FD används för att - bestämma nycklar - hitta orsaker till redundanser Hur funktionella beroenden fastställs - baseras på innehållets betydelse (semantik) - ytterligare beroenden kan härledas från de som redan upptäckts Nycklar och redundanser utgår ifrån upptäckta beroenden - samtliga fastställda funktionella beroenden -funktionella beroenden som härletts genom användning av sk slutsatsdragande regler (inference rules)
Grundläggande slutsatsdragande regler (inferensregler): Regel 1 Reflexivitet (återkastning), en attributmängd X bestämmer delmängden Y: If X Y, then X Y Regel 2 Augmentation (tillägg), en attributmängd Z kan läggas till på båda sidor X Y: If X Y, then XZ YZ Regel 3 Transitivitet, man kan följa kedjor av beroenden X to Y to Z: If X Y and Y Z, then X Z Armstrongs axiom: reglerna 1, 2 och 3 William W. Armstrong ("Bill") Department of Computing Alberta Canada
Tilläggsregler Regel 4 Decomposition (uppdelning) Avlägsna attributen Z från högersidan om X YZ: if X YZ, then X Y. Regel 5 Union (sammanslagning) Lägga samman två funktionella beroenden X Y and X Z om de har samma vänstersida Z: if X Y and X Z then X YZ Regel 6 Pseudo-transitivity Kombinationen av augmentation (tillägg) genom att lägga till W på båda sidor av X Y och transitivitet genom att gå från WX till WY och till Z: if X Y and WY Z, then WX Z. Genom att utnyttja slutsatsreglerna hittar man nya beroenden Closure: mängden av alla funktionella beroenden som kan härledas
Härleda fram FD7 genom att utgå ifrån FD6 Utgångspunkt FD6: accountid {lastname, firstname, street, city, state, zipcode} Det vi kommer fram till genom härledning (slutsatsdragning) FD7: {accountid, lastname} (firstname, street, city, state, zipcode} Använd den slutsatsdragande regeln nr 2 (augmentation) på FD6. Lägg till lastname på den vänstra sidan. Resultatet blir FD8 FD8: {accountid, lastname} (firstname, street, city, state, zipcode, lastname} Använd den slutsatsdragande regeln nr 4 (decomposition) på FD6. Ta bort LastName på den högra sidan FD7: {accountid, lastname} (firstname, street, city, state, zipcode}
Innehåller den här tabellen atomära värden? Vara Lastbilar Magnecyl Leverantör Volvo, Renault Astra Pris 100000 1 400000 10 Stad Torslanda, Trollhättan Folkmängd 80000 Nej, Volvo, Renault och, Trollhättan är inte atomära. Eftersom tabellen ovan innehåller icke-atomära värden (2 st) uppfyller den inte kravet för den första normalformen, 1NF. Tabellen innehåller sk repetitiva grupper. Tabellen nedan innehåller inga repetitiva grupper och uppfyller därför kraven för den första normalformen, 1NF Vara Leverantör Pris Stad Folkmängd Volvo 100000 Torslanda 80000 1 Lastbilar 400000 Magnecyl Astra 10
Attributet Folkmängd är funktionellt beroende attributet Stad Tabell: Inköp Vi skriver: Stad Folkmängd Vi hittar andra: Vara Leverantör Volvo Pris 100000 Stad Torslanda Folkmängd 80000 Vara, Leverantör Pris Leverantör Stad Leverantör Folkmängd Lastbilar Magnecyl Astra 1 400000 10 Resultat: Flera attribut styr andra attribut i tabellen ovan förutom nyckelattributet Vara, Leverantör Tabellen uppvisar och hög redundans: står på 2 ställen, på 2, på 3 och på 3. För att tabellen skall uppfylla kraven för den andra normalformen 2NF skall samtliga ickenyckelattribut styras av hela nyckelattributet och inte bara delar av detta. Samtidigt skall tabellen uppfylla kraven för 1NF. Vara och Leverantör är en unik identifierare. Den fungerar som primärnyckel, men samtidigt är Stad funktionellt beroende av Leverantör. Även Folkmängd är funktionellt beroende av Leverantör. Vi vill komma ifrån att vissa icke-nyckelattribut är funktionellt beroende av en del av primärnyckeln. När vi avlägsnar dessa delberoenden uppfylls den andra normalformen, 2NF
Vara Lastbilar Magnecyl Inköp Leverantör Volvo Astra Pris 10000 1 400000 10 Leverantör Leverantör Stad Volvo Torslanda Astra Folkmängd 80000 I tabellen Leverantör finns dessutom ett funktionellt beroende mellan attributen Stad och Folkmängd. Vi har följande två beroenden: Leverantör (Stad, Folkmängd) och Nyckelberoendet Leverantör (Stad, Folkmängd) och Stad Folkmängd Transitivt beroende Åtgärdas genom ytterligare tabelluppdelning
Det transitiva beroendet bryts genom att dela upp tabellen Leverantör i tabellerna: den nya tabellen för Leverantör och tabellen Stad: Leverantör Stad Stad Folkmängd Volvo Torslanda Torslanda 80000 Astra Vi har dessutom tabellen leverantör Vara Lastbilar Magnecyl Leverantör Volvo Astra Pris 10000 1 400000 10 Tabellerna uppfyller nu kraven för den tredje normalformen, 3NF
Bestämma nycklar utifrån funktionellt beroende: 1. Ta fram samtliga funktionella beroenden (closure) 2. Välj ut de funktionella beroenden som innehåller de attribut som har en superkey som vänstersida minimal superkey = kandidatnyckel 3. Om vänstersidan inte är en superkey så är den en nyckel (kandidatnyckel) 4. Mängden av attribut på vänstersidan är en nyckel om 1, 2 och 3 uppfylls Terminologi - nyckel: den mängd attribut som bestämmer övriga - nyckelattribut: attribut som utgör en del av nyckel - icke-nyckelattribut: attribut som inte utgör en del av nyckeln - primärnyckel: den nyckel som utvalts att identifiera de enskilda raderna - sekundärnyckel: den nyckel som inte utvalts; flera alternativ finns
Normalisering (normalization) är en metod för att dela upp relationstabeller så att de uppdelade tabellernas innehåll (semantik) blir klarare och tydligare. Resultatet efter normaliseringsförfarandet är att några få större tabeller blivit fler och mindre (färre antal attribut). Normaliseringen sker i steg Först uppnås den första normalformen 1NF, därefter den andra 2NF, den tredje 3NF osv 1NF, 2NF, 3NF står för att vissa kvalitetsmål uppnåtts
Direkt på 3NF Ett relationschema är i tredje normalformen (3NF) om för varje funktionellt beroende -den vänstra sidan (determinanten) är en superkey eller -den högra sidans attribut alla är nyckelattribut Ett funktionellt beroende uppfyller inte 3NF om -den vänstra sidan inte är en superkey och -den högra sidans attribut alla är icke-nyckelattribut Betrakta schemat för VideoMovie och de funktionella beroendena VideoMovie:(videoId, dateacquired, movieid, title, genre, length, rating) FD1: movieid title FD2: movieid {title, genre, length, rating} FD9: videoid (dateacquired, movieid} FD10: videoid movieid FD11: videoid (title, genre, length, rating} FD12: videoid (dateacquired, movieid, title, genre, length, rating} FD1, FD2 uppfyller inte 3NF (utan strider mot den) FD9, FD10, FD11, FD12 uppfyller 3NF eftersom videoid (vänstra sidan) är en nyckel
Avlägsna störningar i schemat genom uppdelning (decomposition) Betrakta schemat och 3NF störningarna VideoMovie:(videoId, dateacquired, movieid, title, genre, length, rating) Skapa ett nytt schema baserat på det funktionella beroendena FD1: movieid title FD2: movieid {title, genre, length, rating} Kan brytas ner antingen med FD1 eller FD2 bättre att använda det större FD. Välj FD2 Ta bort attributen på högersidan av det funktionella beroendet FD2: movieid {title, genre, length, rating} FD2: movieid Vänstersidan av det funktionella beroendet utses till en främmande nyckel i det ursprungliga schemat -movieid references Movie Nya scheman Video: (videoid, dateacquired, movieid references Movie) Movie: (movieid, title, genre, length, rating)