Tentamen i. Databasteknik

Transkript

1 Tentamen i Databasteknik Torsdagen den 10/ Tillåtna hjälpmedel: Allt tänkbart material Använd bara framsidan på varje blad Skriv max en uppgift per blad. Skriv tydligt. Motivera allt. Oläslig/obegriplig lösning ger 0 poäng. Betygsgränser (max poäng = 40 + max 10 bonuspoäng = 50poäng) : 3 27p 4 33p 5 39p Lycka till! Kjell

2 Kjell Lindqvist. (08) Databasteknik Sid 1 av 4 1. En fastighetsförvaltare som förvaltar ett stort antal hyresfastigheter vill skapa ett datoriserat system för att hålla reda på hyresgäster, fastigheternas adresser, lägenhetshyror och fastighetsägare. Följande termer är viktiga: Kundnr Unikt nummer för varje hyresgäst KundNamn Namnet på kontraktsinnehavaren (hyresgästen) Fastighetsnummer Unikt nummer för varje fastighet Lägenhetsnummer Unikt nummer, inom fastigheten, för en viss lägenhet Fastighetsadress Gatuadress för fastigheten Fastighetsort Den ort där fastigheten är belägen HyresStart Startdatum för en uthyrning HyresSlut Slutdatum för en uthyrning Hyra Månadshyra för en viss lägenhet ÄgarNamn Ägarens namn för en viss fastighet ÄgarAdress Fastighetsägarens gatuadress ÄgarOrt Orten för fastighetsägaren a. (2p) Utred vilka funktionella beroenden som finns i strukturen. b. (3p) En första ansats är att lägga alla termer i en enda tabell. Vilka problem kommer man att få med ett sådant register? Exemplifiera med specifika problem för den aktuella strukturen. c. (6p) Normalisera det föreslagna registrets struktur steg för steg till 1NF, 2NF, 3NF med motiv till varje åtgärd. 2 Tre transaktioner är sammanflätade enligt figuren nedan. Antag att tidsstämplarna blir TS(T 1 ) = 10, TS(T 2 ) = 20 och TS(T 3 ) = 30 Transaktion T1 Transaktion T2 Transaktion T3 Read(X) Read(Z) Write(X) Read(Y) Read(Y) Read(Y) Write(Y) Read(Z) Write(Y) Read(X) Write(Y) Write(Z) Write(X) Tid

3 Kjell Lindqvist. (08) Databasteknik Sid 2 av 4 Motivera noga och ge ett exempel på samtliga deluppgifter. a. (2p) Är operationsföljden serialiserbar? b. (3p) Vad händer om man använder implicit 2-faslåsning med Wound-wait protokoll? c. (1p) Kan man råka ut för utsvältning om man använder ett protokoll som undviker deadlock? 3 En indexstruktur kan skapas antingen för primärnyckeln (primärt index) i en relation eller för andra attribut (sekundärt index). Ett index kan vara tätt (dense) eller glest (sparse) beroende på omständigheterna. Man kan även välja att ha ett multinivåindex (index till index). a. (1p) I vilka av fallen: index till index, primärindex, ett sekundärindex och flera sekundära index kan man använda glesa index? b. (2p) Vilka för och nackdelar får man med sekundära index? c. (1p) Ofta väljer man att ha hash- eller B-trädsindex. I vilka fall är det ena att föredra framför det andra? d. (2p) På vilket sätt komplicerar dubbletter indexstrukturen? 4 Givet en relation R(X) i vilken det funktionella beroendet AB C gäller. ABC X och inget av attributen ABC ingår i någon kandidatnyckel. Ett sätt att säkerställa denna restriktion är att dela upp relationen i R 1 (X-C) och R 2 (ABC). Om uppdelningen inte görs måste det funktionella beroendet säkerställas på annat sätt. a. (2p) Visa med ett exempel att restriktionen inte upprätthålls utan uppdelningen men gör det om relationen delas upp. b. (1p) Hur skall man bära sig åt för att säkerställa restriktionen om man väljer att inte dela upp relationen? c. (1p) Vilka kan skälen vara till att man väljer att inte dela upp relationen? d. (1p) Om man specificerar attributet C i R(X) som NOT NULL så garanterar man att C alltid har ett värde för varje AB (inte säkert unikt). Hur skall detta garanteras då relationen delats upp?

4 Kjell Lindqvist. (08) Databasteknik Sid 3 av 4 För nedanstående uppgift är en databas med följande databasstruktur given: Anställd ( ( namn ), lön, chef, avd ) ; Försäljning ( ( avd, varunr ), volym ) ; Leverantör ( ( företag ), adress ) ; Lager ( ( företag, avd, varunr ), volym ) ; Avdelning ( ( avd ), våning ) ; Vara ( ( varunr ), typ ) ; 5 Översätt till god svenska: a) (2p) CREATE VIEW tmp(namn, n)as SELECT chef, COUNT(*) FROM Anställd GROUP BY chef HAVING COUNT(*) > (SELECT COUNT(*) FROM Anställd) / (SELECT COUNT(*) FROM Avdelning) SELECT A.lön, T.n FROM tmp T, Anställd A WHERE T.namn = A.namn; b) (2p) A Π namn, våning, chef (anställd avdelning) B(v, c, n) våning, chef F count namn (A) C(n) (F Max n (B)) Π v, c (C Β) c. (2p) {t.företag Leverantör(t) ( w)( Vara(w) w.typ Cykel ( s)(lager(s) w.varunr = s.varunr t. företag = s. företag)))} d. (2p) {t Leverantör(ta) ( e)( i)(lager(teiv) ( g)(vara(ig) ( h)(vara(hg) h i Lager(tehj))))}

5 Kjell Lindqvist. (08) Databasteknik Sid 4 av 4 e. (2p) Avdelning Avd Våning _x G. _y G.P. Lager Företag Avd Varunr Volym Dagab _y >100 Conditions CNT.ALL._x = CNT.ALL._y f. (2p) VIEW tmp1(d IS LITERAL) <- Lager WHERE [företag = d] [avd]; VIEW tmp2 <- Avdelning [avd]; VIEW A <- Leverantör WHERE [tmp1(företag) CONTAINS tmp2][företag]; store A; print A;

6 Förslag till lösning på Tentamen i Databasteknik Lördagen den 10/3 2005

7 Kjell Lindqvist. (08) Databasteknik Sid 1 av 4 1 a) (Notera att en viss lägenhet i staden bestäms av LägNr, FastNr tillsammans.) Antag att varje fastighet har en ägare. Eftersom Ägarnamn inte behöver vara unikt, införs ett unikt ÄgarID. Då har vi: KundNr KundNamn FastNr FastAdr, FastOrt, ÄgarID ÄgarID ÄgarNamn, ÄgarAdr, ÄgarOrt LägNr, FastNr, HyrStart Hyra, HyrSlut, KundNr b) Insättnings-, uppdaterings- och borttagningsproblem. Specifika exempel är ett krav! c) U = { KundNr, KundNamn, FastNr, FastAdr, FastOrt, ÄgarID, ÄgarNamn, ÄgarAdr, ÄgarOrt, LägNr, HyrStart, Hyra, HyrSlut } (13 st) Till 1 NF { LägNr, FastNr, HyrStart }+ = U Ingen av dem finns på HL i något FD ==> Ingår i varje kand. nyckel och de ger U. Endast en kand. nyckel. 1 NF (( LägNr, FastNr, HyrStart ) KundNr, KundNamn, FastAdr, FastOrt, ÄgarID, ÄgarNamn, ÄgarAdr, ÄgarOrt, Hyra, HyrSlut ) Ett värde per fält, inga sammansatta attribut. Till 2 NF Bryt ut de attribut som endast beror av en del av kandidatnyckeln. { FastNr }+ = { FastNr, FastAdr, FastOrt, ÄgarID, ÄgarNamn, ÄgarAdr, ÄgarOrt } 2 NF (( FastNr ) FastAdr, FastOrt, ÄgarID, ÄgarNamn, ÄgarAdr, ÄgarOrt ) (( LägNr, FastNr, HyrStart ) KundNr, KundNamn, Hyra, HyrSlut ) Till 3 NF Bryt ut transitiva beroenden: ÄgarID ÄgarNamn, ÄgarAdr, ÄgarOrt och KundNr KundNamn 3 NF (( FastNr ) FastAdr, FastOrt, ÄgarID ) (( ÄgarID ) ÄgarNamn, ÄgarAdr, ÄgarOrt ) (( LägNr, FastNr, HyrStart ) KundNr, Hyra, HyrSlut ) (( KundNr ) KundNamn)

8 Kjell Lindqvist. (08) Databasteknik Sid 2 av 4 2 a. Nej den är inte serialiserbar. T1 i konflikt med T2 med R(X) och W(X) T2 i konflikt med T3 med R(Z) och W(Z) T3 i konflikt med T1 med R(Y) och W(Y) b. Flera olika lösningar möjliga. Vi kan få den logiska följden T1, T2, T3. c. Ja det kan man. tex Timeout under olyckliga omständigheter. Antag att det startar många transaktioner som använder dataobjekt och att de behöver samma dataobjekt. Även en optimistisk metod kan förorsaka utsvältning. 3 a. Ett glest index kan användas på allt som är sorterat. Om vi har ett glest index på primärnyckeln så går det inte på ett sekundärt index. Index till ett sorterat index går bra oavsett om det är ett index till ett index, primärt index eller ett sekundärt index. b. Fördelar: Sökningen blir snabbare om vi söker på ett fält som är kort i förhållande till posten och det finns förhållandevis många värden för det aktuella fältet. Optimeraren kan se till att inte så stora datamängder behöver hanteras. Nackdelar: Optimeraren kan sysselsättas med fel saker. Uppdatering krånglig. Det tar plats. c. Om man behöver hitta nästa/föregående eller räkna upp i ordning eller selektera poster med villkor som t ex x>3 så välj B-träd annars Hash (även för villkor som t ex x=3. d. Även om vi har en sorterad fil så behöver inte posterna ligga i samma block. Alternativt så måste posterna flyttas så att dubbletter ligger på samma block. I båda fallen blir det merarbete. 4 a. Antag schemat KABC med K som nyckel. Med en enda relation kan man ha: K A B C k1 a b c1 k2 a b c2 men om man delar upp relationen i två delar: K A B k1 a b k2 a b A B C a b c1 så måste FDet vara bevarat. b. Genom att definiera en trigger som utför kontrollen. c. Begränsningar i aktuellt DBMS avseende antal relationer. I aktuellt filsystem avseende antal öppna filer. Prestanda vid sökning: naturlig join över de två relationerna ingår i många sökningar och vi får långa svarstider.

9 Kjell Lindqvist. (08) Databasteknik Sid 3 av 4 d. Definiera AB som nyckel i R(X-C) och C som NO T NULL i S(ABC). 5. a) SQL Vad tjänar och hur många underlydande har de chefer som har fler underlydande än det finns anställda i "medel" på avdelningarna? (Lite suspekt medelvärde, men...) 5 b) RA På vilken våning har flest anställda samma chef, och vad heter chefen? 5 c) TK Vilka företag levererar alla varunr av typen cykel? 5 d) DK Vilka företag levererar minst två olika varunr av samma typ till någon avdelning? 5 e) QBE De våningar där antalet rader i Lager gällande leveranser från Dagab i mer än 100 enheter, partitionerade på våning, råkar bli samma som antalet avdelningar på något godtyckligt våningsplan i Varuhuset. Se förklaring nedan. 5 f) SAL Vilka företag levererar till alla avdelningar? 5 e) QBE-förklaring: AVDELNING LAGER - tupler med Dagab och volym > 100 Avd Vån Företag Avd Varunr Volym Mat 1 Dagab Mat Husgeråd 2 Dagab Mat TV 3 Dagab Mat Skor 3 Dagab Husgeråd Dagab Husgeråd För _x:s vidkommande grupperar vi på våning och räknar avd i Avdelning. ALL spelar ingen roll eftersom _x är ensam primärnyckel och saknar dubbletter. Resultatet (som aldrig plockas ut) är CNT.ALL._x nedan:

10 Kjell Lindqvist. (08) Databasteknik Sid 4 av 4 CNT.ALL._x CNT.ALL._y Vån Antal Vån Antal För _y:s vidkommande grupperar vi på på våning och räknar avd. Nu spelar ALL. roll(!) eftersom _y i Lager inte är unik. Följdaktligen CNT.ALL._y ovan: Eftersom det saknas krav på att våningarna vi jämför ska vara lika (i våning står G. för _x resp. G.P. för _y utan någon sammanbindande variabel). Resultat våning 2 eftersom antalet 2 är det enda antalet som förekommer både i CNT.ALL._x och CNT.ALL._y (även om det är för olika våningar).