Oppgave 1a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet.

Transkript

1 TDT445 Øving 4 Oppgave a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet. Nøkkel: Supernøkkel: Funksjonell avhengighet: Data i en database som kan unikt identifisere (et sett med) annen data. Kan bestå av et enkelt eller flere felt, som til sammen entydig bestemmer en rad i en tabell. Et attributt i en relasjon, bestemmes av en annen attributt. F.eks: Hvis vi har relasjonen XY, vil verdien av Y bestemmes av verdien til X. Dersom vi gjentar X, vil vi få resultatet Y om igjen. Oppgave b Forklar hva menes med tillukningen (eng: closure), X+, til en mengde attributter, X, med hensyn til en mengde funksjonelle avhengigheter. Lag en algoritme for a finne X+. En tillukning X+, vil si at vi samler alle attributtene som kan bestemmes ut ifra X. closure = x while( closure changes): if ( find a FD UV in F such that U closure ): closure = closure V Oppgave c Gitt F = {ae, acd, bc}. Beregn følgende tillukninger (eng: Closure): a+, ab+, e+ a+ a, e ab+ (a, e), (b, c) a, b, c, d, e e+ e Oppgave d Hvordan avgjør man om en mengde attributter er en supernøkkel for en tabell? Hvordan avgjør man om en supernøkkel også er en nøkkel? Dersom tillukningen av attributtene (closure) inneholder alle attributtene i tabellen, utgjør mengden med attributtene en supernøkkel. Dersom denne supernøkkelen ikke inneholder flere attributter, enn dem som er nødvendige for å definere alle attributtene i entiteten, er supernøkkelen en nøkkel.

2 Oppgave e Hvordan avgjør man om en dekomponering av en tabell (R) i to projeksjoner (R og R) har tapsløs-join-egenskapen? Dersom: ( R R ) R eller ( R R ) R Har oppdelingen i R og R tapløs-join-egenskapen. Oppgave f Gitt en tabell R(a, b, c, d) og funksjonelle avhengigheter F = {b c}. Under er det vist tre dekomponeringer av R. Finn ut hvilke dekomponeringer som har tapsløsjoin-egenskapen. I svaret må det gis en (kort) begrunnelse i hvert enkelt tilfelle.. R(a, b, c) og R(b, c, d). R(a, b, d) og R(b, c, d). R(a, b, d) og R(b, c) Oppgave Tapløs-join? Begrunnelse X (R R) = (b, c) R R (R R) = (b, c, d) = R (R R) = (b) = (b, c) = R Oppgave g Gi en definisjon av tredje normalform (NF). Tredje normalform: NF krever at relasjonen også er på NF. En relasjon R er på NF hvis alle (ikke trivielle) FD er i R på formen X Y (der Y er et attributt i R) tilfredsstiller minst ett av følgende to krav:. X er en supernøkkel i R. A er et nøkkelattributt i R Oppgave h Tabellen R(A B C D) er ikke på NF når de funksjonelle avhengighetene som gjelder er F = {A B, C D}. En mulig dekomponering av R er R(A B), R(C D) og R(A C). Er denne dekomponeringen en god løsning? Svaret må begrunnes. Her har dekomponeringen tapsløs-join-egenskapen! (R R) = (a) = (a, b) = R (R R) = (c) = (c, d) = R

3 Oppgave A PARTS file with Part# as the hash key includes records with the following Part# values: 69, 76, 469, 487, 5659, 8, 74, 75, 6, 48, 94, 475, 6975, 498, and 98. The file uses 8 buckets, numbered 7. Each bucket is one disk block and holds two records. Load these records into the file in the given order, using the hash function h(k) = K mod 8. Calculate the average number of block accesses for a random retrieval on Part#. h(k) = K mod 8 Bucket Part# 76, , , 6, , , 94, 6975 Vi har fått oppgitt at hver bucket kan holde records, dermed har vi fått overflow i bucket 4 og 7. Her må vi bruker overflow-chaining. ~ Block-access: *(/5) + */5 = (* + *) / 5 = 7/5

4 Oppgave Load the records of Oppgave into expandable hash files based on extendible hashing. Show the structure of the directory at each step, and the global and local depths. Use the hash function h(k) = K mod 8. Start with global depth and four blocks. h(k) = K mod 8 depth = blocks = 4 d = = 4 bucket adresser Bucket Rest Part# - 487, 5659, 8, , , 469, 75, 6, , 94, 498, 98 Siden vi har bucket size =, må vi splitte de bucket ene som har fått overflow. Vi kan se at bucket, og har overflow. Disse blir splittet, og får buckets med d*= Bucket d* Part# 487, , , , 6, , , 98 Vi har fortsatt overflow i bucket 4. Dermed må vi splitte igjen og får d*=4 Bucket d* Part# 487, , , , , , 98 4

5 Oppgave 4 Load the records of Oppgave into an expandable hash file based on linear hashing. Start with one block using the hash function h = K mod, and show how the file grows and how the hash function changes as the records are inserted. Assume that blocks are split whenever an overflow occurs, and show the value of n at each stage. Records som skal fylles inn: 69, 76, 469, 487, 5659, 8, 74, 75, 6, 48, 94, 475, 6975, 498, 98 n n n n n n n n

6 n n n n

7 76 69 n n n n

8 n n

9 Oppgave 5a Assume we are to create a B+-tree-index for a student database with students. The primary key for a student is student number, an integer using 4 bytes representation. Assume a block identifier to be 4 bytes. On the leaf level there is a pointer to the block where the student record is. This pointer is a block identifier as well. Assume a block to be 496 bytes. How many blocks will exist at the different levels of the B+-tree? Explain the assumptions that you make. Hver index vil da være på 8 bytes (4 byte studentnummer + 4 byte pointer). Vi antar, med empiri, at blokkene vil være tilnærmet / utfylt. Da vil vi få plass til /*496/8=4 indeksposter pr blokk. Det vil si at vi trenger. / 4 = blokker på nederste nivå. Da får vi plass til alle 587 indekspostene i den ene øverste blokken. Oppgave 5b If you are to insert student in the student database, how many disk accesses do you get? Explain the assumptions you make? Vi antar at ingen av blokkene ligger i buffer. Dersom vi skal legge til student nr.. i databasen, må først rotblokken leses for å finne ut hvilken løvnode som må endres. + Deretter må løvnoden leses og skrives. 4+5 Tilslutt må datalagringsblokken leses og skrives for å oppdatere B+-treet. Dermed har vi i alt 5 diskaksesser. Oppgave 5c If you are to find and update a leaf level record of the B+-tree, how long time does it take? Assume reasonable disk access timing and describe these assumptions. Antar at vi har en 7rpm disk. Da er rotasjonstiden ca 4.7ms 4ms. Antar at de andre operasjonene summerer til 4ms. Tre diskaksesser summerer seg til *8ms = 4ms for hele oppdateringen. 9

10 Oppgave 5d Assume there is space for records in each block in a B+-tree. Assume the B+tree to initially be empty. Show the B+-tree after each insertion of records with the following keys:, 9,, 8,,, 7,

11 Oppgave 6 A file of 496 block is to be sorted with an available buffer space of 64 blocks. How many passes will be needed in the merge phase of the external sort-merge algorithm? 496 blokker 64 blokkers buffer Antall merge sort kjøringer: 496/64 = 64 Antall faser som trengs: log 64- (64) = log 6 (64) =.8 Vi trenger to merge faser. Oppgave 7a Assume an SQL statement. SELECT * FROM Employee WHERE Lname > T% ; Assume % of the records to fulfill the condition. Assume there are 48 records in the Employee table. Calculate how many I/Os that are necessary using the various access paths: The records are stored in a heap file where each block contains records. 4.8 poster poster pr heap 4.8/ = 4 Oppgave 7b The records are stored in a sorted file (sorted on Lname) where each block contains records. % av 4.*4 =.4 Oppgave 7c The records are stored (clustered) in a B+tree where each leaf level block contains records. The B+-tree s search key is Lname. A record at index level needs 5% of the storage compared with an Employee record. 4.8 / = 54 løvnivåblokker. * 54 = 54 Siden hver indekspost kan inneholde 5% av employee record, kan en indekspost inneholde 886 poster. Dette betyr at vi har to blokker på nivå, og en blokk på nivå. Dermed trengs det ekstra I/O for å komme frem til løvnivåblokkene 54 + = 56

12 Oppgave 7d The records are stored in a heap file where each block contains records. In addition there is a B+-tree index on Lname. Assume this index at the leaf level to contain 5% of the storage compared with the heap file.. * 4.8 =.48 blokker 4.8 / = 54 løvnivåblokker Vi må søke igjennom % av den returnerte indeksen.. *.5 * 54 = 4 blokker Til sammen trenger vi = 55 I/Os