Komplement till databasdelen på 1E1601. Kursmaterial

Transkript

1 Komplement till databasdelen på 1E1601 Kursmaterial Våren 2004

2 Innehåll 1 Vad är nu detta? Relationsalgebrans divisionsoperator Tupelkalkyl Formell definition Ett problem Exempel Uppgifter Variationer i syntax Andra språk Annan matematisk notation QBE Frågeoptimering Behöver man verkligen optimera? Ekvivalenta uttryck (transformationsregler) Optimeringsalgoritmen Kommentar angående algoritmen Ett observandum Uppgifter Transaktioner, återhämtning och samtidighetskontroll Problem med parallella accesser till data Vad är återhämtning? Varför behövs det? Egenskaper hos en transaktion Möjliga lösningar på samtidighetsproblemen Serialiserbarhetsgrafer Deadlock Tidsstämplingsmetoder Optimistiska metoder Skuggning Återhämtning

3 1 Vad är nu detta? Under kursen 1E1601 utlovades ett komplement till kursen för att eleverna skall kunna tillgodogöra sig fortsättnings- och fördjupningskurser i databasteknik. Det här dokumentet definierar utvidgningen och är dessutom kursens enda kursmaterial utöver det på 1E1601 redan utdelade materialet. Kursboken är bra att ha som komplement till detta material. Du skall efter självstudier ha inhämtat kunskap om: 1. lite mer relationsalgebra (kvot), 2. tupelkalkyl, 3. frågespråket QBE (Query By Example), 4. optimering av frågor och 5. transaktionshantering Du kommer att kunna redovisa allt på en gång eller beta av moment för moment. All redovisning sker till kursledaren personligen 2 Relationsalgebrans divisionsoperator I relationsalgebran brukar man definiera en operator som avses motsvara en divisionsoperator. Det man får fram vid användning av operatorn kan alltså sägas vara kvoten mellan två tabeller. Divisionsoperatorn används i typiska för alla -frågeställningar. Vilka varor säljs av samtliga avdelningar på sjunde våningen? Vilka företag levererar alla sorters matvaror (som finns till försäljning på varuhuset)? Säljer sportavdelningen alla typer av cyklar? o.s.v. Eftersom operatorn oftast inte finns implementerad i frågespråken blir det svårt att formulera sådana frågor annat än i algebran, men de är av stort intresse eftersom för alla -frågor är vanliga. Oftast måste man formulera om sådana frågor till frågor med dubbel negation och bindningar över flera nivåer med hjälp av variabler. För vilka varor gäller det att det inte finns någon avdelning på sjunde våningen som inte säljer dem? För vilka företag gäller att det inte finns någon vara av typen matvaror som de inte levererar? Är det så att det inte finns någon vara av typen cykel som inte finns till föräljning på sportavdelningen? Den första av dessa tre frågor skulle kunna formuleras så här i SQL: 2

4 select varunr from vara as v where not exists (select * from avdelning as a where not exists (select * from försäljning where a.avd = avd and v.varunr = varunr and a.våning="7")) Uppgift 1 1a. Formulera den andra frågan: För vilka företag gäller att det inte finns någon vara av typen matvaror som de inte levererar? i SQL. 1b. Formulera den tredje frågan: Är det så att det inte finns någon vara av typen cykel som inte finns till föräljning på sportavdelningen? i SQL. Observera att det inte finns någon möjlighet att få sant eller falskt som svar på en fråga i SQL. Tänk igenom detta och motivera tolkningen av svaret på din fråga. I relationsalgebra kan vi få fram alla avdelningar på våning 7 med r 1 = Π avd ( σvåning=7 (avdelning) ) och par av varunummer och avdelningar på sjunde våningen med r 2 = Π varunr, avd ( σvåning=7 (avdelning försäljning) ) och alltså kan vi få fram svaret på frågan med det relationsalgebraiska uttrycket Π varunr, avd ( σvåning=7 (avdelning försäljning) ) Π avd ( σvåning=7 (avdelning) ) Resultatet är en relation med schemat (varunr) och om tabellerna r 1 respektive r 2 ser ut som i figur 1 och 2 kommer svaret att innehålla en tupel med värdet 137 i. avd sport leksaker Figur 1: avdelningar på 7:e våningen Hur fungerar det då? Man kan bena upp det i delar och faktiskt formulera en generell metod med hjälp av de grundläggande operatorerna. För att kunna göra det behövs ett par definitioner. Låt t[x] betyda den del av en tupel som har schemat X. Låt också r(r) och s(s) beteckna relationer och låt S R, d.v.s. att varje attribut i schemat S också är ett attribut i schemat R. Relationen r s är en relation med schemat R S, d.v.s. att schemat innehåller alla attribut i schemat R som inte finns i schemat S. En tupel t är en tupel i r s om följande gäller: 3

5 varunr avd 132 sport 133 sport 134 sport 135 sport 136 sport 137 sport 138 sport 139 sport 117 leksaker 121 leksaker 127 leksaker 131 leksaker 137 leksaker 140 leksaker Figur 2: varor som säljs av avdelningar på 7:e våningen 1. t är en tupel i Π R S (r) 2. för varje tupel t s i s, finns det en tupel t r i r där både a) t r [S] = t s [S] och b) t r [R S] = t Som redan påpekats kan detta uttryckas i de grundläggande relationsoperatorerna. Låt åter r(r) och s(s) beteckna relationer och låt S R. Då gäller: r s = Π R S (r) Π R S ((Π R S (r) s) Π R S,S (r)) Man kan bena ut formeln på följande sätt: Π R S (r) är alla tupler som uppfyller regel 1. Π R S,S (r) är bara ett sätt att ordna om attributen i r. Π R S (r) s är alla tupler enligt regel 1 hopparade med tuplerna i s och utgör mängden av tupler som skulle funnits i r om alla tupler i r skulle uppfyllt reglerna 2a och 2b. 4

6 Det betyder att Π R S ((Π R S (r) s) Π R S,S (r)) är de tupler i Π R S (r) som inte uppfyller villkoren i reglerna 2a och 2b och alltså måste bort ur Π R S (r). Alltså: r s = Π R S (r) Π R S ((Π R S (r) s) Π R S,S (r)). Uppgift 2 2a. Formulera den andra frågan: För vilka företag gäller att det inte finns någon vara av typen matvaror som de inte levererar? i relationsalgebra både med och utan -operatorn. 2b. Formulera den tredje frågan: Är det så att det inte finns någon vara av typen cykel som inte finns till föräljning på sportavdelningen? i relationsalgebra både med och utan -operatorn. Se kommentaren i uppgift 1.b. 5

7 3 Tupelkalkyl Då vi använder relationsalgebra formulerar vi frågor genom att tillhandahålla den sekvens av operationer som ska ge svaret. Vi säger att relationsalgebran är imperativ eller procedurorienterad. I tupelkalkylen anger vi inte en kommandosekvens utan snarare beskriver vi det önskade svarets egenskaper. Tupelkalkylen kallas därför för deklarativ. En fråga i tupelkalkylen är alltid på formen: {t ψ(t)} vilket utläses som: alla t sådana att ψ(t) och betyder: alla tupler för vilka ψ är sant. Det är viktigt att förstå att ψ(t) innebär ett uttryck (en formel) där t ingår i deluttrycken och att ψ(t) inte är ett funktionsanrop i traditionell mening. Tupelkalkylen har definierats med några variationer i litteraturen. Den variation som används här kanske skiljer sig lite från andra men i slutet av detta avsnitt ges några varianter på notation. Märk dock att alla variationer handlar om enstaka detaljer i notation, inte i semantik. Här kommer t.a betyda attributet a i tupeln t och t avdelning har betydelsen t är en tupel i relationen avdelning. Frågan Vilka anställda arbetar på leksaksavdelningen? kan formuleras som: {t.namn t anställd t.avd = leksaker } Ofta kan det vara bekvämt och många gånger till och med nödvändigt att formulera frågorna så att man jämför svarets egenskaper med existerande tuplers. Med den tekniken kan man formulera frågan: {t ( s) (s anställd s.avd = leksaker t.namn = s.namn)} som måste läsas ut som: Mängden av tupler t sådana att det finns åtminstone en tupel s i relationen anställd för vilken s och t har samma värde på attributet namn, och värdet på attributet avd i s är leksaker. Märk här att s anställd betyder: s är en tupel i anställd och att tupeln t endast har attributet namn eftersom det är det enda attribut i t som det finns en definition för. Man kan formulera frågor med antingen och ( ) eller eller ( ). Frågan vilka jobbar på andra och tredje våningen? formuleras enklast med omskrivningen vilka jobbar på antingen andra eller tredje våningen?. I en sådan fråga måste vi, precis som i SQL, binda samman tupler från flera tabeller. {t ( r, s)(r avdelning s anställd t.namn = s.namn r.avd = s.avd (r.våning = 2 r.våning = 3))} 6

8 Så som frågan formulerats motsvarar den en kartesisk produkt i relationsalgebran och i SQL skulle motsvarande fråga formulerats select s.namn from avdelning r, anställd s where r.avd = s.avd and (r.våning=2 or r.våning=3) Man skulle också kunna formulera frågan genom en nästling i SQL select namn from anställd where avd in (select avd from avdelning where våning=2 or våning=3) Motsvarande formulering kan man också göra i tupelkalkylen, men då måste man binda ungefär på samma sätt som man gör i SQL med användande av exists : select s.namn from anställd s where exists (select * from avdelning where (våning=2 or våning=3) and s.avd = avd) där motsvarande tupelkalkyluttryck blir {t ( s)(s anställd t.namn = s.namn ( r)(r avdelning r.avd = s.avd (r.våning = 2 r.våning = 3)))} Lägg märke till att resultatet hela tiden blir mängden av de värden som kan bindas till t för varje uppsättning värden i relationerna anställd och avdelning för vilka formeln till höger om den vertikala linjen, d v s den del av formeln som motsvarar ψ(t) i tupelkalkylformeln {t ψ(t)}. 7

9 3.1 Formell definition Vi är färdiga för en formell definition. Som sagts i början är varje tupelkalkyluttryck ett uttryck på formen {t ψ(t)} där ψ är en formel och ψ(t) betyder att formeln innehåller variablen t. I vårt fall kommer det att betyda att t är den enda fria variabeln i ψ. Med fri menar vi en variabel som inte bundits med hjälp av någon kvantifierare. De enda kvantifierarna i tupelkalkylen är och, som betyder det finns respektive för alla. I uttrycket t anställd ( s)(s avdelning t.avd = s.avd) är t fri och s bunden, medan både s och t är fria i s avdelning t.avd = s.avd. En tupelkalkylformel byggs upp av atomer. En atom har en av följande former: s r där s är en tupelvariabel och r är en relation. s.x θ t.y där s och t är tupelvariabler, x är ett attribut i den relation för vilken s är definierad, y ett attribut i den relation för vilken t är definierad och θ en jämförelseoperator (<,, =,, >, ). Ett krav är naturligtvis att x och y är definierade för domäner vars värden kan jämföras med θ. s.x θ c (eller c θ s.x) där s är tupelvariabler, x är ett attribut i den relation för vilken s är definierad, θ en jämförelseoperator och c är en konstant ur samma domän som x. En mängd regler avgör vad som är en formel: En atom är en formel Om ψ är en formel så är ψ och (ψ) formler. Om ψ 1 och ψ 2 är formler så är ψ 1 ψ 2 och ψ 1 ψ 2 formler. Om ψ(t) är en formel (som alltså innehåller en fri variabel t) så är ( t)(ψ(t)) och ( t)(ψ(t)) formler. I tupelkalkylen såväl som i relationsalgebran finns det uttryck som uttrycker samma sak trots att de har olika utformning. 8

10 Några sådana ekvivalenser är: 3.2 Ett problem Uttryck ( t)(ψ(t)) ( t)(ψ(t)) är ekvivalent med ( t)( ψ(t)) ( t)( ψ(t)) ψ 1 ψ 2 ( ψ 1 ψ 2 ) ψ 1 ψ 2 ( ψ 1 ψ 2 ) ( t)(ψ 1 (t) ψ 2 (t)) ( t)(ψ 1 (t) ψ 2 (t)) ( t)(ψ 1 (t) ψ 2 (t)) ( t)(ψ 1 (t) ψ 2 (t)) ( t)( ψ 1 (t) ψ 2 (t)) ( t)( ψ 1 (t) ψ 2 (t)) ( t)( ψ 1 (t) ψ 2 (t)) ( t)( ψ 1 (t) ψ 2 (t)) I tupelkalkylen kan man göra bort sig och i princip generera oändliga relationer. Antag t.ex. att vi skriver ett uttryck som {t (t anställd)}. Det finns oändligt många tupler som inte ligger i tabellen anställd. De flesta av alla dessa tupler är totalt ointressanta och det är klart att man vill undvika sådana effekter. De enda uttryck som kan drabbas i ett normalt tupelkalkyluttryck är de som börjar med en allkvantifiator ( ). Det betyder att man måste skriva om dem så att de blir säkra. I praktiken betyder det att man inte kan formulera uttryck av typen för alla avdelningar på andra våningen rakt på sak utan man måste ta en omväg. {t ( s)(s avdelning s.våning = 2 t.avd = s.avd)} är alltså fel. ( s)(s avdelning) betyder att alla tupler s måste vara tupler i avdelning. Det finns oändligt många tupler som inte är tupler i avdelning och alltså kommer uttrycket alltid vara falskt. Att det förekommer mera i det sammansatta uttrycket spelar ingen roll eftersom det endast är konjunktioner ( ) och varje deluttryck måste vara sant för att hela uttrycket ska bli sant. Man måste i stället låta formeln ge true för alla tupler men genrera bindningar endast för de som är intressanta! Det korrekta uttrycket blir: {t ( s)( (s avdelning) (s avdelning (s.våning 2 t.avd = s.avd))}, d.v.s. det som står inom parenteserna ger värdet true för alla tupler som inte finns i tabellen avdelning, för alla tupler i tabellen avdelning som inte har värdet 2 på våning samt slutligen för alla tupler vi är intresserade av och endast för dessa binds värden till t. 9

11 3.3 Exempel De uppgifter som gavs för relationsalgebra och SQL på grundkursen (1E1601) och deras lösning i tupelkalkyl inte alla kan besvaras då tupelkalkylen i sin standarddefinition inte har aggregerande funktioner (det går att definiera en utvidgning), men märk att man kan få svar på frågor med max - och min - problematik: 1. Vilka anställda arbetar på leksaksavdelningen? {t.namn t anställd t.avd = leksaker} eller {t ( u)(u anställd u.avd = leksaker t.namn = u.namn} 2. Vilka varor säljs på andra våningen? {t.varunr t försäljning ( u)(u avdelning t.avd = u.avd u.våning = 2)} 3. Vilka varor säljs inte av någon avdelning på andra våningen? {w.varunr w vara ( t, u)(t försäljning u avdelning w.varunr = t.varunr t.avd = u.avd u.våning = 2)} 4. Vilka varor säljs av alla avdelningar på andra våningen? {w.varunr w vara ( t)(t försäljning ( u)(u avdelning w.varunr = t.varunr t.avd = u.avd u.våning = 2))} 5. Vilka varor säljs av minst två avdelningar på andra våningen? {s.varunr s försäljning ( t, u, v)(t försäljning u avdelning v avdelning s.varunr = t.varunr s.avd = u.avd t.avd = v.avd u.avd v.avd u.våning = 2 v.våning = 2)} 6. Hur mycket tjänar Anderssons chef? {t.namn t anställd ( u)(u anställd t.namn = u.chef u.namn = Andersson )} 7. Vilka anställda tjänar mer än sin chef? {t.namn t anställd ( u)(u anställd t.chef = u.namn t.lön > u.lön)} 8. På vilka avdelningar tjänar alla anställda mindre än sina chefer? {t.avd t avdelning ( u, v)(u anställd v anställd t.avd = u.avd v.namn = u.chef u.lön > v.lön)} 9. Vilka anställda tjänar lika mycket som sin chef? {t.namn t anställd ( u)(u anställd t.chef = u.namn t.lön = u.lön)} 10. På vilka avdelningar är medellönen större än 10000? Kan inte besvaras med standard tupelkalkyl. 10

12 11. Vilka chefer har mer än 10 anställda under sig, och vilken lön har dessa chefer? Kan inte besvaras med standard tupelkalkyl. 12. Vilka anställda på skoavdelningen har mer än i lön, och vad heter deras närmaste chef? {t.namn, t.chef t anställd t.avd = skor t.lön > 10000} 13. Vilka anställda tjänar mer än någon på skoavdelningen? Här har frågan givits tolkningen Vilka tjänar mer än den som tjänar mest på skoavdelningen? {t.namn t anställd ( u)( (u anställd) (u anställd (u.avd skor t.lön > u.lön)))} 14. Vilka företag levererar pennor? {t.företag t lager ( v)(v vara t.varunr = v.varunr v.typ = penna )} 15. Vilka företag levererar inte pennor? {t.företag t leverantör ( u, v)(u lager v vara t.företag = u.företag u.varunr = v.varunr v.typ = penna ))} 11

13 3.4 Uppgifter Formulera tupelkalkyluttryck för följande frågor (alla kan besvaras): 1. Hur stor är maxlönen för anställda på andra eller tredje våningen? 2. Vilka företag levererar varor som endast säljs på avdelningen för skor? 3. På vilka våningar finns det avdelningar som säljer mer än 100 enheter av någon artikel av typen damsko? 4. Finns det någon avdelning som säljer alla på aktuell våning förekommande artiklar? I så fall vilken? 5. Vilka företag levererar mer än en typ av vara till någon avdelning på tredje våningen? 6. Vilka avdelningar säljer varor som även säljs av andra avdelningar? 7. Vilka företag levererar skor till minst två avdelningar? 8. Vilka varor levereras av endast en leverantör? 9. Finns det något företag som levererar alla i databasen förekommande artiklar? I så fall, vad har det för namn? 10. Vilka avdelningar säljer varor som även säljs av andra avdelningar på samma våning? 12

14 3.5 Variationer i syntax Än en gång bör påpekas att de variationer som finns är rent syntaktiska och att semantiken överensstämmer med den här givna. Jag har använt t r för att beteckna t är en tupel i relationen r. I många framställningar skriver man r(t) för samma sak. Jag har skrivit ( s, t)(ψ(s, t)) för att beteckna Det ska finnas åtminstone ett s och ett t så att ψ blir sann. I många framställningar får man inte skriva ihop två sådana utsagor utan måste skriva antingen ( s)( t)(ψ(s, t)) eller till och med ( s)(( t)(ψ(s, t))), d.v.s. nästla frågan. I vissa framställningar skriver man ( s r)(ψ(s)) eller s r(ψ(s)) för det som jag skrivit som ( s)(s r ψ(s)). Det är OK, men man får problem med syntaxen för allkvantifiering om man inte inför implikation ( ). Det är lite vågat eftersom det inte är 100% ekvivalent med logisk implikation, men är man försiktig kan man använda det. Då skulle alltså exempel 13 kunna skrivas {t.namn t anställd ( u anställd)(u.avd = skor t.lön > u.lön)} Slutligen kan man finna notationer där det vi skrivit t.a, d.v.s attributet a i tupeln t, i stället skriver t[a]. 4 Andra språk 4.1 Annan matematisk notation Domänkalkyl Tupelkalkylen fokuserar på tupler och alla variabler är tupelvariabler. Man kommer åt tuplernas delar med antingen punktnotation (t.a) eller indexnotation (t[a]). Om man istället fokuserar på tuplernas delar, attributen, får man en notation som fokuserar på värdedomänerna. Denna notation kallas för domänkalkyl. Den är i uttrycksfullhet helt ekvivalent med tupelkalkylen och väldigt lik denna. En tupel bildas av uppräkningen av de variabler som representerar attributvärdena. Så betyder då { a,b,c,d a,b,c,d anställd d = sport } mängden av alla anställda på sportavdelningen och { a,b,c,d a,b,c,d anställd b > 20000} de anställda som tjänar mer än (per månad??). Vill man ha ut endast en del av informationen, t.ex. namnen på de anställda måste man deklarera alla variabler som inte förekommer till vänster om det vertikala strecket, d.v.s. precis 13

15 som i tupelkalkylen är det bara dessa, de till vänster om det vertikala strecket, som får vara fria variabler. Så får man namnen på de som tjänar mer än 20000: { a ( b,c,d)( a,b,c,d anställd b > 20000)}. En formell definition kommer i allt väsentligt likna tupelkalkylens och utelämnas därför. Däremot kan man ge alla exempelfrågorna i domänkalkyl också. Exempel 1. Vilka anställda arbetar på leksaksavdelningen? { a ( b,c,d)( a,b,c,d anställd d = leksaker )} 2. Vilka varor säljs på andra våningen? { b ( a,c,d)( a,b,c försäljning a,d avdelning d = 2)} Lägg märke till att matchningen sker genom att variabeln a förekommer i båda tupeldefinitionerna! Man kan naturligtvis ordna matchningen genom ett villkor att två variabler ska vara lika: { b ( a,c,d,e)( a,b,c försäljning d,e avdelning a = d e = 2)} 3. Vilka varor säljs inte av någon avdelning på andra våningen? { a ( b)( a,b vara ( c,d,e)( c,a,d försäljning c,e avdelning e = 2))} 4. Vilka varor säljs av alla avdelningar på andra våningen? { p ( q)( p,q vara ( r,s)( r,p,s försäljning ( t)( r,t avdelning t = 2)))} 5. Vilka varor säljs av minst två avdelningar på andra våningen? { q ( p,r,s,t,u,v)( p,q,r försäljning s,q,t försäljning p,u avdelning s,v avdelning p s u = 2 v = 2)} 6. Hur mycket tjänar Anderssons chef? { q ( p,r,s,t,u,v)( p,q,r,s anställd t,u,p,v anställd t = Andersson )} 7. Vilka anställda tjänar mer än sin chef? { p ( q,r,s,t,u,v)( p,q,r,s anställd r,t,u,v anställd q > t)} 8. På vilka avdelningar tjänar alla anställda mindre än sina chefer? { p ( q)( p,q avdelning ( r,s,t,u,v,w)( r,s,t,p anställd t,u,v,w anställd s >= u))} 9. Vilka anställda tjänar lika mycket som sin chef? { p ( q,r,s,t,u,v)( p,q,r,s anställd r,t,u,v anställd q = t)} 14

16 10. På vilka avdelningar är medellönen större än 10000? Kan inte besvaras med standard domänkalkyl. 11. Vilka chefer har mer än 10 anställda under sig, och vilken lön har dessa chefer? Kan inte besvaras med standard domänkalkyl. 12. Vilka anställda på skoavdelningen har mer än i lön, och vad heter deras närmaste chef? { p,r ( p,s)( p,q,r,s anställd s = skor q > 10000)} 13. Vilka anställda tjänar mer än någon på skoavdelningen? Här har frågan givits tolkningen Vilka tjänar mer än den som tjänar mest på skoavdelningen? { p ( q,r,s)( p,q,r,s anställd ( u)( t,v,w)( ( t,u,v,w anställd) ( t,u,v,w anställd (w skor q > u))))} 14. Vilka företag levererar pennor? { p ( q,r,s,t)( p,q,r,s lager r,t vara t = penna )} 15. Vilka företag levererar inte pennor? { p ( u)( pu leverantör ( q,r,s,t)( p,q,r,s lager r,t vara t = penna ))} 4.2 QBE Query by example (QBE) är ett språk som bygger på domänkalkylen utökad med aggregat. Utökningen är inte matematiskt stringent utan präglas mest av praktiska hänsyn. Det som gör språket intressant är att man har ett grafiskt gränssnitt med en tabellmodell som stämmer väl med relationsmodellen. Man får en mängd tomma tabeller att delvis fylla i med villkor. Sedan fyller systemet i tabellerna med värden som stämmer med den ställda frågan. Man behöver inte existenskvantifiera, men kan å andra sidan inte allkvantifiera. Variabler kan ha namn med fler än ett tecken och inleds med _ (understrykning/underscore). Funktioner och kommandon avslutas med punkt, t.ex. betyder P. att värdet ska skrivas ut. En egenhet är negationer som kan gälla en hel tabell eller enstaka värden/variabler. Koppling mellan tabellerna sker genom variablerna eller genom att man anger villkor i en speciell ruta ( condition ). Det bästa är att ge några kommenterade exempel. De anställda på sportavdelningen får man fram genom anställd namn lön chef avd P. sport medan man får fram de anställda som tjänar mer än med 15

17 anställd namn lön chef avd P. _a condition _a > Namnen på de av de anställda på sportavdelningen som tjänar mer än får man med anställd namn lön chef avd P. _a sport condition _a > Hur ser svaret ut då? Ja det varierar mellan systemen. I vissa system får man den eller de tabeller man använder för att ställa frågorna ifyllda med värden i den kolumn eller de kolumner som man skrivit P. i. I de systemen kan man tvingas tillverka svarstabeller för att hysa svaret om svaret motsvarar en projektion ur en join. I andra system får man automatiskt en svarstabell. 16

18 Ytterligare några regler: Villkor som ställs i olika tabeller räknas som om det stod och ( ) mellan dem. Villkor som ställs på olika rader i samma tabell räknas som om det stod eller ( ) mellan dem. Detta kan brytas genom att explicit ange olika variabler på olika rader och koppla samman dem i condition -boxen med hjälp av and. På samma sätt kan man få eller mellan villkor i olika tabeller. Exempel De ursprungligen givna exemplen löses så: 1. Vilka anställda arbetar på leksaksavdelningen? anställd namn lön chef avd P. leksaker 2. Vilka varor säljs på andra våningen? försäljning avd varunr volym _x P. avdelning avd våning _x 2 3. Vilka varor säljs inte av någon avdelning på andra våningen? försäljning avd varunr volym _x _y avdelning avd våning _x 2 vara varunr typ P._y Lägg märke till att negationen är global och inte går att göra lokal som i domänkalkylen. Det betyder att det finns flera sätt att formulera frågan. Följande är ekvivalent med det ovan: 17

19 försäljning avd varunr volym _x _y avdelning avd våning _x 2 vara varunr typ och även P._y försäljning avd varunr volym _x _y avdelning avd våning _x 2 vara varunr typ condition _y _z P._z 4. Vilka varor säljs av alla avdelningar på andra våningen? Den här frågan måste man besvara genom att räkna antalet avdelningar per vara på andra våningen och jämföra med antalet avdelningar på samma våning. Funktionen G. motsvarar GROUP BY i SQL och CNT. motsvarar COUNT. försäljning avd varunr volym _a P.G. avdelning avd våning condition _a 2 _n 2 CNT._a = CNT._n 18

20 5. Vilka varor säljs av minst två avdelningar på andra våningen? försäljning avd varunr volym _p _r P._q _s avdelning avd våning condition _p 2 _r 2 _p _r and _q = _s Märk hur man här brutit den inbyggda villkorshanteringen med hjälp av villkoren i condition -boxen. 6. Hur mycket tjänar Anderssons chef? anställd namn lön chef avd condition _p = _q Andersson _q P. _p 7. Vilka anställda tjänar mer än sin chef? anställd namn lön chef avd condition P. _q _r _s _q > _t and _r = _s _t 19

21 8. På vilka avdelningar tjänar alla anställda mindre än sina chefer? anställd namn lön chef avd _d _a _b _c _e avdelning avd våning P._c condition _a > _e and _b = _d 9. Vilka anställda tjänar lika mycket som sin chef? anställd namn lön chef avd condition P. _q _r _s _q = _t and _r = _s _t 10. På vilka avdelningar är medellönen större än 10000? Här introduceras två nya funktioner. AVG. är en direkt motsvarighet till AVG i SQL, d.v.s. en medeltalsfunktion. ALL. ser till att alla värden räknas normalt tas inte hänsyn till dubletter. anställd namn lön chef avd condition AVG.ALL._a > AVG.ALL._a _r P.G. 20

22 11. Vilka chefer har mer än 10 anställda under sig, och vilken lön har dessa chefer? Här behövs en speciell resultattabell. Alla system som inte skapar resultattabeller automatiskt har någon metod för att definiera egna tabeller. anställd namn lön chef avd CNT.ALL._p _r _s G._q resultat P._q P._s condition _q = _r and CNT.ALL._p > Vilka anställda på skoavdelningen har mer än i lön, och vad heter deras närmaste chef? anställd namn lön chef avd condition _a > P. _a P. skor 13. Vilka anställda tjänar mer än någon på skoavdelningen? anställd namn lön chef avd condition _b > MAX._a MAX._a P. _b 14. Vilka företag levererar pennor? skor lager företag avd varunr volym P. _a vara varunr typ _a penna 21

23 15. Vilka företag levererar inte pennor? lager företag avd varunr volym _b vara varunr typ _a penna _a leverantör företag adress P._b Aggregering i QBE I exemplen har jag använt en del aggregat. Dessutom har jag använt ett prefix (ALL.). I QBE finns samma aggregat som i SQL. De heter AVG. (average), SUM., CNT. (count), MAX. och MIN. De skiljer sig lite från SQL eftersom AVG., SUM. och CNT. appliceras på unika värden i den kolumn de arbetar på (som om man använt DISTINCT i SQL). För att få dessa aggregat att beakta alla värden använder man prefixet ALL. som i exempel 11. Man kan använda ALL. med MAX. och MIN. också men det har naturligtvis ingen effekt. Observera att ALL. i QBE inte har något med ALL i SQL att göra. Negation i QBE Negation ( ) var ursprungligen avsett att kunna modellera både EXISTS och NOT EXISTS (som de definierats i SQL) men ingen implementation stöder detta. De flesta implementationerna följer IBMs QMF-implementation av QBE där man gjort negation till ett globalt begrepp. Det gör att QBE i alla implementationer som jag sett inte är relationellt komplett, d.v.s. inte kan uttrycka alla typer av frågor. Frågor av typen Vilka varutyper säljs av alla avdelningar på plan två? kan inte säkert besvaras. QBEs spridning QBE har inte varit vanligt. Det har funnits i olika implementationer i DB2 (IBM, QMF), MIMER (svensk!) och Paradox (endast på PC). En svaghet är att det inte finns någon standard. Det gör att man får ganska olika bild av språket i olika böcker. Bilden jag har givit följer i stort Elmasri, Navathe: Fundamentals of Database Systems. Idag börjar QBE bli mer populärt med spridningen av grafiska verktyg. Sålunda finns det i MS Access och andra liknande verktyg men i en ganska egen tappning. 22

24 Uppgifter Besvara följande frågor i QBE. Det är samma frågor som på laboration Vad är genomsnittslönen för alla anställda på varuhuset? 2. Vad är maxlönen för anställda som arbetar på andra eller tredje våningen? 3. Vilka företag levererar varor som endast säljs på avdelningen för skor? 4. Vilken är den totala volymen av artiklar av typ tekopp som säljs på avdelningen porslin? 5. Vilken är den totala lönesumman för de anställda som arbetar på avdelningar som har leveranser från Dagab? 6. På vilka våningar finns det avdelningar som säljer sammanlagt mer än 100 enheter av artiklar av typen damsko? 7. Vilka avdelningar har en högre genomsnittslön än hela företagets genomsnitt? 8. Vilken/vilka avdelning/-ar har det största utbudet av varor? 9. Finns det något företag som levererar alla i databasen förekommande artiklar? I så fall, vad har det för namn? 10. Vilka företag levererar mer än en typ av vara till någon avdelning på 3:e våningen? 5 Frågeoptimering En viktig del av ett relationsdatabassystem är att man ska kunna ställa frågor i stort sett hur som helst. Om frågan är korrekt formulerad ska svaret genereras lika fort oavsett om formuleringen är smart eller ganska dum. Det ställer höga krav på optimering av ställda frågor. Det i sin tur kräver noggrann analys av frågan och det måste gå fort. Så här går hanteringen av frågan till 23

25 fråga lexikal analys syntaxkontroll semantisk kontroll frågan på internt format optimering (hitta rimlig strategi) kodgenerering frågan i körbar kod exekvering svaret (om det finns ett svar) Den lexikala analysen överför teckenströmmen till en s.k. token -ström, en ström av betydelsebärande enheter ungefär som orden i språk. Dessa skickas vidare till syntaxanalysen, som talar om ifall den ställda frågan följer alla regler för hur en fråga får sättas ihop. Sedan (eller oftast samtidigt) kontrolleras som den syntaktiskt korrekta frågan betyder något vettigt finns relationerna?, har de de använda attributen?, har attributen rätt typ?, o.s.v. Då har frågan förts över på ett format som kan sparas för vidare bearbetning. Vyer sparas på detta format för att kunna användas på ett sätt som tillåter optimering Sedan kommer optimeringen som vi ska uppehålla oss vid ett tag. Kodgenerering och exekvering går i stort sett till på samma sätt som vid kompilering av program skrivna i vanliga programspråk. Det som gör den stora skillnaden är att man dels sparar frågor i ett internformat, dels att man optimerar så att alla frågor som är ekvivalenta exekverar på ett jämförbart sätt. För att illustrera optimeringen kommer jag att använda relationsalgebra. Det är ett bra sätt att visa hur man bygger upp och transformerar beräkningstrategier. De kommer att byggas som trädstrukturer och manipuleras med trädstrukturtransformationer. 24

26 5.1 Behöver man verkligen optimera? Jämför t.ex. formuleringen av frågan Vilka firmor levererar sportskor till sportavdelningen? I SQL kan man formulera frågan så: select företag from lager L, vara V where L.varunr = V.varunr and and L.avd = sport V.typ = sportskor vilket motsvarar följande relationsalgebraiska uttryck: Π företag ( σlager.varunr=vara.varunr lager.avd= sport vara.typ= sportskor (lager vara) ). För att beräkna hur kostsamt det är att beräkna svaret på frågan, för en jämförelse mellan olika strategier, antar jag att lager har tupler och vara 600. Antag också att beräkningen sker stegvis enligt 1. tmp 1 lager vara 2. tmp 2 σ lager.varunr=vara.varunr lager.avd= sport vara.typ= sportskor (tmp 1 ) 3. res Π företag (tmp 2 ) I steg 1 kommer varje tupel i lager paras ihop med varje tupel i vara. Det kommer att bli tupler som har en längd på 102 byte vardera. Det är för mycket för att hålla i exekverbart minne. Det krävs någon form av mellanlagring av storleksordningen 600 MB. I steg 2 kommer de tuplerna filtreras och om det blir 50 tupler kvar kan vi behålla dem i primärminnet för att i steg 3 projicera ut kanske 3 värden som kommer bli vårt resultat. Medvetet har jag gjort en värsta fall -uppskattning. Enligt denna kommer vi ha gjort läsningar eller skrivningar till/från sekundärminnet. Låt oss stuva om frågan så att den motsvarar följande relationsalgebrauttryck: Π företag ( Πföretag, varunr ( σavd= sport (lager) ) Π varunr ( σtyp= sportskor (vara) )) Låt oss också bortse för ett ögonblick från det faktum att vi endast tittar på delar av tupler och alltså inte slösar med utrymme. Man kan gruppera delar av beräkningarna så att man utför projektion och selektion samtidigt och därtill som ett slags filter vid själva inläsningen. Om beräkningen går till så: 1. tmp 1 Π varunr (σ typ= sportskor (vara)) ger 50 tupler som kan behållas i minnet. Alltså ingen mellanlagring! 25

27 2. Π företag, varunr (σ avd= sport (lager)) görs på samma sätt, men vi sparar ingenting annat i minnet än företagsnamnet d.v.s. utför den yttersta projektionen och det endast om varunumret finns bland de 50 som vi behållit i primärminnet och företagsnamnet inte redan sparats. Den senare strategin som inte var möjlig i det första fallet kommer att kräva läsningar och tre skrivningar (av resultatet). Skillnaden mellan de två strategierna är att vi sluppit lagra undan sex millioner poster och därmed sluppit läsa in dem igen! Att spara tolv millioner av de tyngsta operationerna är en rejäl vinst! Tar vi dessutom med i räkningen att vi bara läser in delar av tuplerna och endast sparar en lista med heltal i primärminnet, blir vinsten ännu mer uppenbar. Så visst skall man optimera. Frågan är: Hur kommer vi från den först formulerade frågan till den sista formuleringen? Först ska vi titta på ekvivalenta uttryck och sedan på en algoritm för enkel optimering. Algoritmen tar bara hänsyn till minimering av dataflöde medan riktiga optimeringsalgoritmer även tar med kostnader för alla ingående operationer. 5.2 Ekvivalenta uttryck (transformationsregler) Ett stort antal transformationsregler används för att transformera de evalueringsstrategier som genereras till så effektiva strategier som möjligt. Ett uttryck som överförts till en form som inte går att förbättra kallas en kanonisk form. Jag kommer inte att använda den sortens resonemang eftersom det kräver en insyn i alla optimerarens detaljer och eftersom en form kan vara kanonisk i ett avseende utan att vara det i ett annat. De vanligaste transformationsreglerna är 1. Kaskadering av σ. σ c1 c 2 c 3...(R) σ c1 (σ c2 (σ c3 (... (R)))) 2. Kommutativitet hos σ. σ c1 (σ c2 (R)) σ c2 (σ c1 (R)) 3. Kaskader av Π. Π Lista1 (Π Lista2 (Π Lista3 (... (R)))) Π Lista1 (R) 4. Kommutering av σ och Π. Π Lista (σ c (R)) σ c (Π Lista (R)) om c opererar endast på de attribut som finns i listan Lista. 5. Kommutativitet hos (eller ). R c S S c R 6. Kommutativitet hos σ och (eller ). Om attributen i villkoret c för selektionen endast kommer från R så: σ c (R S) σ c (R) S. 7. Kommutativitet hos Π och (eller ). Om L r är attribut i R och L s är attribut i S och L = L r L s, så Π L (R c S) Π Lr (R) c ΠL s (S). Om joinvillkoret c innehåller attribut som inte finns i L så behövs en slutlig projektion (d.v.s. om L L r L s ) Π L (R c S) Π L (Π Lr (R) c Π Ls (S)). 26

28 8. Mängdoperationers kommutativitet. och är kommutativa, men är det inte. 9. Associativitet hos vissa operatorer. Om ϕ {,,, } så (R ϕ S) ϕ T R ϕ (S ϕ T ). 10. σ och Π kommuterar med mängdoperatorerna så att om ϕ {,,,, } så gäller både σ c (R ϕ S) σ c (R) ϕ σ c (S) där c resp. c är de delar av c som avser R resp. S och Π L (R c S) Π L (R) c Π L (S) där L resp. L betecknar de attribut i L som finns i R resp. S. 11. De Morgans lag: (c 1 c 2 ) ( c 1 ) ( c 2 ) och (c 1 c 2 ) ( c 1 ) ( c 2 ) 27

29 5.3 Optimeringsalgoritmen Det finns ett stort antal optimeringsalgoritmer som var och en antingen fokuserar på någon speciell egenskap som är intressant i någon viss tillämpning. De stora databasmotorerna däremot är generella och tillhandahåller antingen anpassningsbara optimerare eller kostnadsbaserade eller dataflödesminimerande optimerare eller möjligen någon lämplig kompromiss. De dataflödesminimerande optimerarna kallas ofta heuristiska (genomsökande) då de oftast skapar en (liten) mängd strategier av vilka den mest gynsamma väljs. Terminologin är lite tveksam eftersom strikt kostnadsbaserade optimerare gör likadant (skapar en (liten) mängd strategier av vilka den minst kostsamma väljs). I de kostnadsbaserade optimerarna tilldelas olika operationer olika kostnad baserat på storleken på relationer, vilka index som finns att tillgå och deras effektivitet, m.m. Den algoritm vi ska titta lite på är heuristisk och enkel men effektiv. Den arbetar i ett litet antal steg och går ut på som redan påpekats minimering av dataflöde. a) Bygg det initiala evalueringsträdet. b) Skala bort alla projektioner utom den yttersta. Det fungerar eftersom reglerna om projektionsoperatorns kommutativitet (4, 7 och 10) samt regeln om kaskadering av projektioner (3) tillåter oss att senare återskapa och införa projektioner. c) Dela upp alla konjunktiva selektioner i kaskader av selektioner (regel 1). d) För ner alla selektioner så långt som möjligt i trädet med hjälp av reglerna 2, 4, 6 och 10. e) Inför projektioner så att endast de nödvändiga attributen förs vidare (de attribut som krävs för varje operation). Börja vid den yttersta projektionen och använd reglerna 10, 4, 7 och10. f) Gör om kartesisk produkt med efterföljande selektion (σ står direkt ovanför i trädet) till join med joinvillkor eller (helst) naturlig join. 28

30 Exempel 1. Det ursprungliga exemplet ( Π företag σlager.varunr=vara.varunr lager.avd= sport vara.typ= sportskor (lager vara) ) a) skulle ge upphov till följande initiala evalueringsträd: svar Π företag σ lager.varunr=vara.varunr lager.avd= sport vara.typ= sportskor lager vara Med de föreslagna stegen i optimeringsalgoritmen får vi (steg för steg) b) ingen skillnad: svar Π företag σ lager.varunr=vara.varunr lager.avd= sport vara.typ= sportskor lager vara 29

31 c) (jag bortser i det här steget och nästa från den yttersta projektionen) svar σ lager.varunr=vara.varunr σ lager.avd= sport σ vara.typ= sportskor lager vara d) svar σ lager.varunr=vara.varunr σ lager.avd= sport σ vara.typ= sportskor lager vara 30

32 e) Här dels återinför jag den yttersta projektionen, dels utför jag optimeringssteget svar Π varunr σ lager.varunr=vara.varunr Π företag, varunr Π varunr σ avd= sport σ typ= sportskor lager vara f) och till slut: svar Π varunr Π företag, varunr Π varunr σ avd= sport σ typ= sportskor lager vara Märk väl att vi kommit fram till det i ursprungsexemplet omstuvade uttrycket som alltså inte var taget ur luften ty om vi överför trädet till ett relationsalgebraiskt uttryck får vi Π företag (Π företag, varunr (σ avd= sport (lager)) Π varunr (σ typ= sportskor (vara))). 31

33 2. Låt oss se på ett annat exempel. Antag att det finns en databas Bok (ISBN, titel, förf, förl) Förläggare (Förl, adress, ort) Låntagare (Namn, adress, ort, kortnr) Lån (KortNr, ISBN, Datum) efter modellen Datum Låntagare Lån Bok Utges av Förläggare Man har skapat en vy med SQL-satsen create view xlån as select titel,förf,förl,lån.isbn,adress,ort,lån.kortnr,datum from Lån,Låntagare,Bok where Lån.kortnr = Låntagare.kortnr and Bok.ISBN = Lån.ISBN I relationsalgebra motsvarar detta Π f (σ g (Lån Låntagare Bok)) där f = titel,förf,förl,lån.isbn,adress,ort,lån.kortnr,datum och g = Lån.kortnr = Låntagare.kortnr Bok.ISBN = Lån.ISBN Vi vill veta vilka titlar som lånats ut före Vi låtsas att det angivna datumformatet fungerar som förväntat. Endast titlarna är intressanta. Det kan ske genom select titel from XLån where datum < ; eller 32

34 Π titel (σ datum< (xlån)) a) Vi får ett evalueringsträd enligt: svar Π titel σ datum< Π f σ g Bok Lån Låntagare Optimering enligt den angivna algoritmen ger 33

35 b) svar Π titel σ datum< σ g Bok Lån Låntagare 34

36 c) svar Π titel σ datum< σ Bok.ISBN=Lån.ISBN σ Lån.kortnr=Låntagare.kortnr Bok Lån Låntagare 35

37 d) svar Π titel σ Bok.ISBN=Lån.ISBN σ Lån.kortnr=Låntagare.kortnr Bok σ datum< Låntagare Lån 36

38 e) svar Π titel σ Bok.ISBN=Lån.ISBN Π isbn Π isbn, titel σ Lån.kortnr=Låntagare.kortnr Bok Π kortnr,isbn Π kortnr σ datum< Låntagare Lån 37

39 f) slutligen svar Π titel Π isbn Π isbn,titel Bok Π kortnr,isbn Π kortnr σ datum< Låntagare Lån 5.4 Kommentar angående algoritmen En riktig algoritm skulle ha upptäckt att grenen med låntagare inte behövs och kapat den. En riktig algoritm skulle ha vägt storlekar på de ingående relationerna också. Det ska till mycket för att få ett bra resultat, men med så enkla medel kan man komma ganska långt. Vad som behövs är alltså något som ser efter om alla grenar i trädet behövs och som roterar delträd om det visar sig minska resursåtgången. Men vi är nästan framme. 5.5 Ett observandum Observera att det inte spelar någon roll vilken binär relationsoperator man hanterar. I de givna exemplen har endast använts kartesisk produkt men med 38

40 ekvivalensreglerna 8, 9 och 10 ser vi att algoritmen kommer att fungera med alla mängdoperatorer. T.ex. kommer frågan Vilka varor säljs inte av någon avdelning på andra våningen? som i SQL kan formuleras så: select varunr from vara where varunr not in (select varunr from försäljning, avdelning where försäljning.avd = avdelning.avd and avdelning.våning=2) som motsvarar Π varunr (vara) Π varunr ( σförsäljning.avd=avdelning.avd avdelning.våning=2 ( försäljning avdelning )) och efter optimering blir Π varunr (vara) Π varunr ( Πvarunr,avd (försäljning) Π avd ( σvåning=3 (avdelning) )) motsvarande select varunr from vara where varunr not in (select varunr from försäljning where avd in (select avd from avdelning where våning=2)) och optimeringen går till på samma sätt som i de övriga givna exemplen trots att en operator är. 39

41 5.6 Uppgifter För var och en av dessa uppgifter ska ett relationsalgebraiskt uttryck konstrueras som stämmer med den givna SQL-frågan. Uttrycken skall optimeras med den angivna agloritmen och dessutom ska finnas med en enkel analys av hur svaret kan tänkas skilja sig från en riktig optimerares arbete, d.v.s. vad du själv tycker borde ha åstadkommits utöver det nådda resultatet. Vi utgår från varuhusdatabasens schema (som vanligt): anställd (namn, lön, chef, avd) försäljning leverantör lager avdelning (avd, varunr, volym) (företag, adress) (företag, avd, varunr, volym) (avd, våning) vara (varunr, typ) Bry dig inte om vad uttrycken kan tänkas betyda. 1. create view alfa(a, b, c, d) as select a.namn, a.avd, av.avd, av.våning from anställd a, avdelning av; select a from alfa where b = c and d > 4 ; 2. create view C(namn) as select C.namn from anställd C, anställd B, avdelning A, vara V, lager L where B.chef = C.namn and B.avd <> C.avd and A.avd = B.avd and A.våning = 1 and L.varunr = V.varunr and L.avd = A.avd and V.typ = Cykel ; select C.namn from C, anställd where c.namn = anställd.namn and anställd.avd = fisk ; 3. create view tmp1(avd) as select A.avd from avdelning A, avdelning B where A.våning = B.våning and A.avd <> B.avd; create view tmp2 as select varunr from försäljning A, försäljning B where A.avd <> B.avd and A.avd in (select avd from tmp1) and B.avd in (select avd from tmp1); select V.typ from vara V, tmp2 X where V.varunr=X.varunr; 40

42 6 Transaktioner, återhämtning och samtidighetskontroll Eftersom en databas oftast används av mer än en person åt gången så finns i Data Dictionary data om olika användare, deras rättigheter att komma åt vissa data samt information om backuper, historik m.m. Allt detta har med säkerhet att göra. Vi måste tala om säkerhet ur olika aspekter. Dels har vi, naturligtvis, fysiskt skydd, dels skyddsmekanismer som skall se till att data hålls korrekta hela tiden, oavsett komplexitet vid transaktioner och systemkrascher och annat. Med en transaktion menar man en mängd arbete som skall utföras i sin helhet eller inte alls, dvs en mängd arbete som, när det en gång påbörjats måste slutföras. Om det påbörjade arbetet inte kan slutföras, måste databasen återställas till det tillstånd den befann sig i innan arbetet påbörjades. Man kan säga att en transaktion är ett antal databasoperationer som överför en databas från ett konsistent tillstånd till ett annat konsistent tillstånd. Antingen skall alla i transaktionen ingående operationer utföras eller skall ingen av dem utföras. Alltså måste man ha en metod för att backa om man utfört några av operationerna men inte kan fortsätta och alltså inte utföra alla. De man vill komma åt med transaktionsbegreppet är Samtidighet (concurrency) - parallellitet, d.v.s. flera användare vill åt samma data samtidigt. Vi skall se att det kan bli problem om kontroll inte finns. Reparation (recovery) - backa till ett garanterat korrekt tillstånd om ett fel inträffar. D.v.s. återhämta databasen till dess senaste konsistenta tillstånd. Commit signalerar att en transaktion avslutats på ett korrekt sätt och därmed att uppdateringar kan slutgiltigt verkställas. Rollback signalerar att något blivit fel under en transaktion och alla operationer måste göras ogjorda, d.v.s. transaktionen måste rullas tillbaka. Man har metoder för att signalera när transaktioner börjar (transaction begin) och slutar (transaction end), om man skall läsa (read) eller skriva (write) en post och om man vill göra partiell rollback (undo) och därmed förknippat redo. Varför behövs allt detta?? 41

43 6.1 Problem med parallella accesser till data Problem uppstår om många transaktioner sker samtidigt. Varje transaktion kan vara korrekt i sig, det är samtidigheten som utgör problemet. Man kan råka ut för att Uppdatering går förlorad (lost update problem). Beroende av transaktion som inte avslutats (temporary update problem). Inkonsistent analys (incorrect summary problem). Låt oss se på några olika transaktioner och exekvera dem samtidigt efter olika tidsskalor utan samtidighetskontroll Förlorad uppdatering Två till synes framgångsrika uppdateringar löper parallellt. Var för sig är de korrekta men samtidigheten och bristen på samtidighetskontroll gör att den ena uppdateringen annuleras av den andra. Detta illustreras av transaktionstabellen nedan. Om T 1 skulle utföras först och sedan T 2 (eller tvärtom) så skulle X ha värdet 190 efteråt. P.g.a. samtidigheten utan samtidighetskontroll blir värdet 90 en liten förskjutning i den relativa tidsskalan kunde det lika gärna ha blivit 200. T 1 tid T 2 X t 1 BEGIN-TRANSACTION 100 BEGIN-TRANSACTION t 2 read(x) 100 read(x) t 3 X := X X := X 10 t 4 write(x) 200 write(x) t 5 COMMIT 90 COMMIT t 6 90 Lösningen på problemet är att T 1 inte får se värdet på X förrän uppdateringen som T 2 gör är helt färdig (efter det att T 2 har signalerat COMMIT). Beroende av transaktion som inte avslutas Det här problemet uppstår då en transaktion tillåts se en annan transaktions resultat innan den andra transaktionen avslutats med COMMIT. Här har, av någon orsak (vilken är irrelevant i sammanhanget orsakerna kan vara många), transaktion T 4 gjort ROLLBACK och återställt alla värden till vad de var innan transaktionen påbörjades, medan transaktion T 3 redan hunnit läsa det uppdaterade värdet innan T 4 gör ROLLBACK. 42

44 T 3 tid T 4 X t 1 BEGIN-TRANSACTION 100 t 2 read(x) 100 t 3 X := X BEGIN-TRANSACTION t 4 write(x) 200 read(x) t X := X 10 t 6 ROLLBACK 100 write(x) t COMMIT t Problemet kan bara få sin lösning i att ingen får se en annan transaktions resultat förrän det blivit definitivt och stabilt. Inkonsistent analys Båda de föregående exemplen handlar om interferens mellan två transaktioner som var för sig uppdaterar databasen som får ett felaktigt innehåll. Men exemplet nedan visar att det kan bli fel även om en bara läser. T 5 tid T 6 X Y Z sum t 1 BEGIN-TRANSACTION BEGIN-TRANSACTION t 2 sum := read(x) t 3 read(x) X := X 10 t 4 sum := sum + X write(x) t 5 read(y) read(z) t 6 sum := sum + Y Z := Z + 10 t write(z) t COMMIT t 9 read(z) t 10 sum := sum + Z t t 11 COMMIT

45 6.2 Vad är återhämtning? Varför behövs det? Om man kan konstatera att en transaktion inte kommer att förlöpa väl, d.v.s. att vissa operationer i transaktionen kommer att utföras men inte andra så måste operationen avbrytas. Har någon operation utförts måste denna göras ögjordöch transaktioner som eventuellt använt de felaktiga värdena i posten göras om med aktuella värden. Vad kan gå fel? Mycket! Systemkrash, division med noll, trans. hittar inte alla data, läs- eller skrivfel vid access till sekundärminne, mängder av olika fel av teknisk art, en bankkund har inte tillräckligt på sitt konto för att kunna ta ut pengar, et.c. Dessutom tar operationer tid: read(x) = 1. Hitta adressen till X (blocket där X finns). 2. Kopiera blocket till primärminnet. 3. Kopiera objekt X till programvariabel. write(x) = 1. Hitta adressen till X (blocket där X finns). 2. Kopiera blocket till primärminnet (om det inte finns där redan). 3. Kopiera X från programvariabel till rätt plats i blocket. 4. Skriv blocket till rätt plats på sekundärminnet. Att på ett säkert sätt återföra databasen till ett tillstånd som är garanterat felfritt och sedan göra om de (avbrutna) transaktionerna kallas återhämtning. Det kräver att man tar komplett backup (s.k. checkpoint) då och då och dessutom håller reda på exakt vad som hänt eller avsågs hända fram till krasch eller nästa backup. En annan metod kan vara att ha data spridda i flera kopior över ett antal sekundärminnen kanske på olika datorer så att man alltid kan återskapa varje enskilt minne utgående från de övriga. Trots det kan man inte vara hundra procent säker så för att kunna utföra återhämtning, rollback, återstart m.m. på ett korrekt sätt finns alltid en s.k. logg. Det är en fil i vilken man hela tiden noggrannt antecknar allt som händer i DBMS. Varje transaktion bokförs med en unik identifierare. Varje dataobjekt har också en unik identifierare. Så fort ett värde skrivs på sekundärminnet så loggasbåde gamla och nya värdet. Varje anteckning i loggen har en tidsstämpel, varje operation en kod. Alltså kan man hitta poster på loggen med t.ex.: start, t_id, time write, t_id, time, obj_id, old_val, new_val read, t_id, time, obj_id commit, t_id, time end, t_id, time checkpoint, time rollback, t_id, time 44