1. No category

Øving 5: Transaksjonshåndtering, logging og normalisering
Lars Kirkholt Melhus
Oppgave 1
a) ACID
Atomic
En transaksjon er en minste enhet. Alle ledd i transaksjonen må gå feilfritt for at transaksjonen skal
gjennomføres. Hvis ikke forblir databasen uendret, slik den var før transaksjonen.
Consistency
En transaksjon holder databasens tilstand konsistent, ved at nøkler, referanser, verdier og constraints
er gyldige. Under operasjonene i transaksjonen kan godt tilstanden være inkonsistent, men
tilstanden før og etter er garantert konsistent.
Isolation
Transaksjoner er uvitende om andre transaksjoner. Transaksjoner som utføres i parallell påvirker
ikke hverandre.
Durability
Når en transaksjon er gjennomført skal databasens nye tilstand holde (til en annen transaksjon
begynner).
b) Tofaselåsing
Om databasesystemet kjører tofaselåsing vil det si at når en transaksjon utføres deles tiden i to:
Først et intervall hvor låser tildeles og ingen frigjøres, deretter en periode hvor låser kun frigjøres.
Denne strategien garanterer serialiserbarhet, som igjen garanterer korrekt utførelse.
Oppgave 2
Har historiene S1 til S6. For å avgjøre om de er serialiserbare kan man skjekke at presedensgrafen
ikke inneholder sykler. En transaksjon Ti må skje før transaksjon Tj dersom RAW, WAR eller WAW.
S1: w2(X); w1(X); r3(X); r1(X); w2(Y); c1; r3(Y); r3(Z), c3; r2(X); c2;
S2: r3(Z); r3(Y), w2(Y); r2(Z); w2(X); w1(X); c2; r1(X); c1; r3(X); c3;
S3: r3(Z); w2(X); w2(Y); r1(X); r3(X); r2(Z), c2; r3(Y), c3; w1(X); c1;
S4: r2(Z); w2(X); w2(Y), c2; w1(X); r1(X); c1; r3(X); r3(Z); r3(Y); c3;
S5: r1(X); r2(X); w2(X); w2(Y); c2; w1(X); r3(Z); w1(Y); c1; r3(Y); r3(X); c3;
S6: r2(X); w2(X), r1(X); r2(Y); w1(Y); c1; r2(Z); w2(Z); c2;
a) Serialiserbarhet
Som grafene viser er S1, S3, S4 og S6 serialiserbare.
b) Recovery-egenskaper
(strict, cascadeless, recoverable, ingen av delene)
S1 og S6 er ingen av delene.
S2 er cascadeless.
S3 er recoverable, siden alle transaksjoner venter med å committe til transaksjoner som endret data
relevant for transaksjonen committer først.
S4 og S5 er strict, siden objekter som leses eller skrives av en transaksjon ikke røres av andre
transaksjoner før den første transaksjonen har committet.
Oppgave 3
Exercise 16.6
Isolasjon- og aksessnivåer i SQL
1. READ UNCOMMITTED
Dirty read er mulig, da databasesystemet tillater å lese data som ikke er committed av en
annen transaksjon, er det ingen garantier for at de ikke er oppdaterte.
Unrepeatable read er mulig, siden poster som leses ikke blir låst.
Phantom problem kan forekomme.
Eksempel på transaksjon som går bra på dette isolasjonsnivået er å finne statistikk av en stor
datamengde, da du ikke forventer at resultatet blir veldig feil fordi du kan gå glipp av
uncommitted forandringer underveis.
2. READ COMMITTED
Dirty read er ikke mulig, siden transaksjonene bare får lest ting som er committed.
Unrepeatable read er mulig, siden verdier som leses godt kan bli forandret av andre
transaksjoner.
Phantom problem kan forekomme.
Samme eksempel som over.
3. REPEATABLE READ
Dirty read er ikke mulig, siden transaksjonen låser alle felter den leser.
Unrepeatable read er ikke et problem, av samme grunn som over.
Phantom problem kan forekomme.
Alle transaksjoner som ikke skriver til databasen er trygge å kjøre her.
4. SERIALIZABLE
Dirty read er ikke mulig.
Unrepeatable read er ikke mulig.
Phantom problem kan ikke forekomme.
Alle transaksjoner går greit på dette isolasjonsnivået.
Aksessnivået til transaksjoner kan settes til READ ONLY eller READ WRITE. Ved å sette for
eksempel REPEATABLE READ READ ONLY er du sikker på konsistens, siden isolasjonsnivået er
trygt ved kun lesetilgang.
Excercise 18.1
1. Databasesystemets recovery manager sikrer at transaksjoner er «atomic» og «durable».
Dersom en transaksjon ikke committet sørger systemet for å «angre» alle operasonene
transaksjonen fikk gjort, slik at transaksjonen kan ses på som atomisk. Dersom systemet
krasjer har recovery manageren ansvar for å få databasen i en konsistent tilstand.
2. Forskjellen mellom «stable storage» og disk er at stable storage garanterer å overleve
systemfeil. I realiteten er dette tull, siden stable storage gjerne også er disklagring, men med
mange kopier på forskjellige steder for å minimere sannsynlighet for datatap. Logg er typisk
lagret på stable storage.
3. «System crash» kan for eksempel være softwarefeil som får datamaskinen til å krasje.
«Media failure» vil si at disken er fysisk ødelagt, «korrupt».
4. WAL står for Write Ahead Log, og går ut på at loggen for hva som gjøres med databasen
oppdateres før endringene faktisk utføres. På denne måten sikrer systemet seg mot datatap,
som kunne oppstått mellom oppdatering av databasen og skriving til loggen.
5. «Steal»: Dersom en pågående (uncommitted) transaksjon S er ferdig med en frame i minne
(den er unpinned) kan en annen transaksjon stjele framen hvis databasesystemet tillater å
skrive data forandret av S før S er ferdig.
«Force»: Når en transaksjon er ferdig (committed) kan databasesystemet tvinge alle
endringer til å skrives til disk. En «no-force»-policy blir da det motsatte, at endringer utført
av S ikke nødvendigvis skrives med en gang S er committed.
Exercise 18.3
1. Agoritmen ARIES tar hånd om å gjenopprette databasen i en konsistent tilstand gjennom tre
faser:
Analysis: Finner ut hvilke data som ikke har blitt skrevet til databasen og aktive
transaksjoner idet systemet krasjet.
Redo: Starter et sted i loggen og utfører alle sørringer på nytt opp til det punktet hvor
systemet krasjet.
Undo: Angre (abort) transaksjoner som ikke ble korrekt utført (uncommitted).
2. Gitt historikken på bildet over, ARIES-algoritmen vil gjøre følgende under restart:
a) I analysefasen identifiseres T1 som aktiv transaksjon. Alt de andre transaksjonene gjorde
før restart identifiseres som «dirty», dvs at T1 skriver P5 og T3 skriver P3.
b) Under redo-fasen gjøres alle operasjoner om igjen fra checkpoint fram til krasj. P3
skrives til disk siden det blir gjort av A2, som blir committed.
c) Under undo-fasen angres alle endringer gjort av T1 og T3, dvs skriving av P3 og P5.
Exercise 19.2
Har gitt relasjonen R (A, B, C, D) med avhengighetene: A → B, BC → E og ED → A.
1. C og D er nøkler i R, de har ingen inn-piler. En må vite en av A, B og E for å bestemme alle,
så alternativene blir CDA, CDB eller CDE.
2. R er i 3NF siden A → B, BD → E og ED → A alle inneholder deler av nøkkelen på
høyresiden.
3. R er ikke i BCNF, siden det krever at alle avhengigheter er enten trivielle eller er på formen
superkey → felt. En superkey er en nøkkel som definerer alle andre feltene i relasjonen, dvs
enten CDA, CDB eller CDE. Ingen av FD-ene for R oppfyller dette kravet.
Exercise 19.5
Har en relasjon R(A, B, C, D, E, F, G, H, I), ser på oppdelinger R1 – R5.
1. R1(A, C, B, D, E) : A → B, C → D
Nøkkelen her er ACE. Avhengighetene oppfyller ikke kravet til 3NF, siden verken B eller D
er en del av nøkkelen. Alle feltene er atomiske, R er på 1NF.
Dekomponering til BCNF: Algoritmen er enkel; Så
lenge det finnes avhengigheter X → A som ikke
oppfyller BCNF, del opp i R – A og XA. Først
«fjerner» vi A → B, og lager AB og ACED (R – B).
Videre det samme med C → D som gir ACE og CD.
AB, ACE og CD er R på BCNF.
2. R2(A, B, F) : AC → E, B → F
Nøkkel er AB. R2 er på 1NF. Dekomponering til BCNF gir BF, AB.
3. R3(A, D) : D → G, G → H
Nøkkel er AD, relasjonen er allerede på BCNF.
4. R4(D, C, H, G) : A → I, I → A
Nøkkel er DCHG, igjen er relasjonen ferdig på BCNF.
5. R5(A, I, C, E) : Ø
Her må alle feltene være nøkkel, siden det ikke finnes avhengigheter. R5 er på BCNF.
Exercise 19.6
Har relasjonen S (A, B, C) med følgende data:
A
B
C
1
2
3
4
2
3
5
3
3
1. a) A → B holder, siden alle A-verdier er unike.
b) BC → A holder ikke, siden (2,3) for B og C gir både 1 og 4 for A
c) B → C holder, B lik 2 eller 3 gir C lik 3.
2. Andre avhengigheter som holder over S:
AC → B
AB → C
Exercise 19.10
Har relasjonen R (A, B, C, D).
1. B → C, D → A. Oppdeling: BC og AD
Nøkkelkandidater: AB
Oppdelingen fungerer dårlig siden man taper informasjon ved join. Dvs, en join mellom BC
og AD blir mye mer enn den opprinnelige relasjonen ABCD.
2. AB → C, C → A, C → D. Oppdeling: ACD og BC
Nøkkelkandidater: BC eller BA.
Oppdelingen er tapsfri, siden ACD ∩ BC = C, og C er nøkkel i den første relasjonen ACD.
Den inneholder derimot ikke avhengigheten AB → C, siden det er C som er nøkkel i ACD.
3. A → BC, C → AD. Oppdeling: ABC, AD
Nøkkelkandidater: A eller C.
Relasjonen er allerede på BCNF, siden både C og A fungerer som superkey.
Oppdelingen er lossless, siden ABC ∩ AD = A, men avhengigheten C → AD mistes og det
er liten vits i å dele opp relasjonen som allerede var på BCNF.
4. A → B, B → C, C → D. Oppdeling: AB og ACD
Nøkkelkandidater: A.
Relasjonen er verken på BCNF eller 3NF, når vi har C → D og ACD. Kravet for 3NF er at
enten C er en superkey, eller at D er en del av en nøkkel, som ikke oppfylles.
Igjen, lossless oppdeling, men avhengigheten B → C mistes og det er ikke på 3NF.
5. A → B, B → C, C → D. Oppdeling: AB, AD, CD
Nøkkelkanidater: A.
Oppdelingen er lossless; (AB ∩ AD) ∩ CD = B ∩ CD = C ∩ CD = C, men tar ikke vare på
avhengigheten B → C. En bedre oppdeling (også BCNF) er AB, BC, CD.