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

Transkript

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

2 Normalisering Finn alle ikke-trivielle ti i FDer som gjelder for en relasjon R. FDer er integritetsregler; de begrenser hva som er lovlig innhold av tabellene. Pi Primærnøkler er FDer I tillegg kan det være andre FDer Finn hvilke kandidatnøkler som gjelder for R Finn de minste X hvor X + utgjør samtlige attributter i R For hver FD, avgjør om den bryter BCNF, deretter om den i såfall bryter 3NF, deretter om den i såfall bryter 2NF. Hvis det er ett eller flere brudd, f.eks. i FDen X A: Splitt R i to tabeller R 1 (X,A) og R 2 (X,Z) der XZ er attributtene i R minus A. Gjenta prosessen for hver av de nye tabellene.

3 1NF-BCNF: FDer For alle ikke-trivielle FDer X A i R: X er en supernøkkel i R eller A er et nøkkelattributt i R eller X K for noen kandidatnøkkel K i R 4NF: FDer og MVDer For alle ikke-trivielle MVDer X Y i R: X er en supernøkkel i R 3

4 Normalisering Finn alle ikke-trivielle MVDer og FDersomgjelderforen en relasjon R. MVDer er integritetsregler; de begrenser hva som er lovlig li innhold av tabellene. Ikke-trivielle MVDer oppstår typisk hvis R inneholder to mange-til-mange-relasjoner som burde vært atskilt i to tabeller Finn hvilke kandidatnøkler som gjelder for R (bruk FDene, beregn X + for attributter X fra R) For hver MVD, avgjør om den bryter 4NF. Hvis det er ett eller flere brudd, f.eks. i MVDen X Y: Splitt R i to tabeller R 1 (X,Y) og R 2 (X,Z) der XZ er attributtene i R minus Y. Gjenta prosessen for hver av de nye tabellene.

5 Eksempel Ansatt(ansattID, navn) Enhet(enhID, ansattid) Prosjektbemanning(prID, ansattid) Finansiering(prID, kilde) Men databasedesigneren var utrenet og lagde i stedenfor én tabell av Ansatt og Enhet (=device) Ansattinfo(ansattID, navn, enhid) og én tabell av Prosjektbemanning og Finansiering Prosjekt(prID, ansattid, kilde)

6 Ansatt(ansattID, navn) Enhet(enhID, ansattid) Ansattinfo(ansattID, navn, enhid)

7 Prosjektbemanning(prID, j g(p, ansattid)) Finansiering(prID, kilde) Prosjekt(prID, ansattid, kilde)

8 Relasjonsalgebratolkning av select-setningen 1. Ta det kartesiske produktet av relasjonene i from 2. Selekter ifølge betingelsen i where 3. Grupper i henhold til beskrivelsen i group by 4. Velg ut grupper ifølge betingelsen i having 5. Lag en liste av uttrykk for (utvidet) projeksjon og aggregering ifølge select 6. Fjern flerforekomster hvis select distinct 7. Sorter i henhold til order by

9 Eksempel select distinct navn from Ansatt a, Enhet e where a.ansattid = e.ansattid and e.enhid > 5;

10 Konfliktserialiserbarhet S 1 og S 2 er konfliktekvivalente hvis S 1 kan omformes til S 2 ved ombyttinger av nabooperasjoner som ikke er i konflikt med hverandre En eksekveringsplan er konfliktserialiserbar hvis den er konfliktekvivalent med en seriell eksekveringsplan Test for konfliktserialiserbarhet: S er konfliktserialiserbar i hvis og bare hvis presedensgrafen til S er asyklisk

11 View-serialiserbarhet S 1 og S 2 er view-ekvivalente hvis alle r l (A) har samme kilde i S 1 og S 2 En eksekveringsplan er view-serialiserbar hvis den er view-ekvivalent med en seriell eksekveringsplan Test for view-serialiserbarhet: En eksekveringsplan S er view-serialiserbar hvis og bare hvis dens polygraf kan gjøres asyklisk k ved å velge eksakt en av kantene i hvert kantpar den transaksjonen som skrev verdien

12 View- vs. konfliktserialiserbarhet Alle konfliktserialiserbare eksekveringsplaner er view- serialiserbare Ved å legge på et krav om begrenset skriving: En transaksjon får ikke lov til å skrive et dataelement uten først å ha lest det blir alle view-serialiserbare eksekveringsplaner konfliktserialiserbare

13 Vranglåser Kun for låsbaserte systemer Låser + låseregler brukes for å sikre serialiserbarhet Vi har en vranglås når to eller flere transaksjoner venter på hverandre Vranglåser løses opp ved å rulle tilbake en eller flere transaksjoner Man velger å tillate muligheten for at vranglås oppstår fordi det er for kostbart t å unngå det Jo flere restriksjoner, desto mindre throughput

14 2PL og vranglås T1 l 1 (A); Read(A); A A+100; Write(A); l 1 ( B); må vente på T2 T2 l 2 (B); Read(B); B B 2; Write(B); l 2 (A); må vente på T1 2PL (1+2 under) sikrer altså ikke mot vranglås 1: Ta lås lese og skrive fi frigi ilås 2: Etter første frigiving av lås kan ingen nye låser tas

15 Treprotokollen 1. En transaksjon kan sette sin første lås på en vilkårlig node i treet I praksis låses gjerne roten først 2. Senere kan transaksjonen bare sette lås på en node hvis den har låst foreldrenoden 3. En transaksjon kan når som helst slette en lås den har på en node 4. En transaksjon kan ikke sette lås på en node den tidligere har frigitt (selv om den fortsatt har lås på foreldrenoden)

16 Tidsstempling Når en transaksjon T starter, får den et tidsstempel, TS(T) Hvis T 1 starter før T 2 2, så skal vi ha TS(T 1 ) < TS(T 2 ) Serialiseringsrekkefølgen er bestemt av tidsstemplene Én tidsstemlingsprotokoll: Til hvert dataelement A i databasen må systemet holde rede på RT(A) Det høyeste tidsstempelet til transaksjoner som har lest A WT(A) Det høyeste tidsstempelet til transaksjoner som har skrevet A C(A) Commit-flagget til A: Sann hvis og bare hvis den siste transaksjonen som skrev A, er committet Tidsstempelserialiseringsprotokollen bruker disse til å avgjøre om en transaksjon som ønsker å lese eller skrive A, kan få gjøre dette eller om den må gi opp (rulle tilbake) fordi den ellers vil bryte serialiseringsrekkefølgen.

17 Valideringsprotokollen Valideringsprotokollen er en annen tidsstemplingsprotokoll: For hver aktiv transaksjon T lagres lesemengden, RS(T), og skrivemengden, WS(T), til T Utførelsen av T deles inn i tre faser: (i) Lesefasen, hvor RS(T) og WS(T) bygges opp (ii) valideringsfasen (iii) skrivefasen, hvor verdiene i WS(T) skrives Serialiseringsrekkefølgen er bestemt av tidspunktet for valideringsfasen. Under valideringsfasen kan T bli rullet tilbake fordi noen av de transaksjonene som allerede er gjennom valideringsfasen i og derfor skal serialiseres før T, men ikke har fullført skrivefasen, ellers kan komme til å skrive for sent.