Transcript bajecm.fri.uni

Podatkovne baze II
3. letnik, univerzitetni študij
smer INFORMATIKA
UNIVERZA V LJUBLJANI
Fakulteta za računalništvo in informatiko
Doc. dr. Marko Bajec
Gradivo, verzija 2.2
I
Splošne informacije...
 Predavatelj
– Doc. dr. Marko Bajec, univ. dipl. ing.
– [email protected]
– http://infolab.fri.uni-lj.si/marko
http
 Asistent - vaje
– As. dr. Aljaž Zrnec, univ. dipl. ing.
– [email protected]
– http://baze.fri.uni-lj.si/
http
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
-2-
Splošne informacije…
 Priporočena literatura
– [1] Thomas M. Connolly, Carolyn E. Begg (2005). Database
Systems, A Practical Approach to Design, Implementation
and Management, Fourth Edition, Addison-Wesley
– [2] Ramez Elmasri, Shamkant B. Navathe (2003).
Fundamentals of Database Systems, Fourth Edition, Addison
Wesley.
– [3] Tomaž Mohorič (1997). Načrtovanje relacijskih
podatkovnih baz, Založba Bi-TIM.
– [4] Peter Rob, Carlos Coronel (2005). Database Systems:
Design, Implementation and Management, Sixth Edition,
Addison Wesley.
Citiranje: glej [3,15-20] = glej v knjigi T. Mohorič, strani od 15 do 20.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
-3-
Splošne informacije
 Priporočena literatura (nadaljevanje):
– [5] Raghu Ramakrishnan, Johannes Gehrke (2003).
Database Management Systems, Third Edition, McGraw-Hill
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
-4-
II
Vsebina predmeta...
 I. Načrtovanje podatkovnih baz
–
–
–
–
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Pristopi k načrtovanju
Konceptualno načrtovanje
Metoda konceptualnega načrtovanja
Logično načrtovanje
Normalizacija
Metoda logičnega načrtovanja
Fizično načrtovanje
Metoda fizičnega načrtovanja
-5-
Vsebina predmeta
 II. Obvladovanje transakcij
–
–
–
–
Transakcije in njihove lastnosti
Nadzor sočasnosti
Obnova podatkov po nesrečah
Obvladovanje transakcij v porazdeljenih PB
 III. Evaluacija poizvedb
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
O optimizaciji poizvedb
Hevristična optimizacija poizvedb
Stroškovna opredelitev operacij relacijske algebre
Alternativne strategije izvedbe poizvedb
-6-
Povzeto po [1]
Poglavje 1
Načrtovanje podatkovnih baz







Pristopi k načrtovanju PB
Konceptualno načrtovanje
Metoda konceptualnega načrtovanja
Logično načrtovanje in normalizacija
Metoda logičnega načrtovanja
Fizično načrtovanje
Metoda fizičnega načrtovanja
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
-7-
Pristopi k načrtovanju PB
 Obstajata dva glavna pristopa k načrtovanju
podatkovne baze:
– Pristop od spodaj navzgor in
– Pristop od vrha navzdol.
 Podatkovne baze pogosto razvijamo po delih.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
-8-
Pristop od spodaj navzgor
 Pristop od spodaj navzgor:
– začne z atributi ter jih združuje v skupine
– Tak pristop predstavlja normalizacija
Normalizacija = identifikacija potrebnih atributov in njihovih
agregacij v normalizirane relacije na osnovi funkcionalnih
odvisnosti.
 Pristop od spodaj navzgor primeren za enostavne
podatkovne baze z majhnim številom atributov.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
-9-
Pristop z vrha navzdol
 Za večje baze primeren pristop z vrha navzdol.
– Na začetku podatkovni modeli z le nekaj osnovnih entitetnih
tipov in razmerij
– Korakoma razgradnja na pod-entitete, povezave in atribute
– Tak pristop predstavlja uporaba tehnike Entiteta – Razmerje
(E-R).
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 10 -
Pristop po delih
 V praksi najbolj uporabna strategija
 Načrtovanje razdelimo na več lažje obvladljivih
delov:
– Najprej kreiramo okvirno shemo z najpomembnejšimi
entitetnimi tipi in razmerji med njimi
– Shemo razdelimo na področja (jedra so identificirani
entitetni tipi)
– Za vsako področje so vključeni poznavalci področja
– Načrtovanje za posamezna področja lahko poteka vzporedno
– Posamezne sklope na koncu združimo v eno shemo
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 11 -
Shema pristopa po delih
Delitev poslovne domene
na področja, kreiranje
osnovne sheme
Področje 1
Področna
shema 1
Področje 2 ... Področje n
Področna
shema 2
Končna
shema
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
Okvirna
shema
- 12 -
Področna
shema n
Trije nivoji načrtovanja – trije modeli...
 Konceptualno načrtovanje – konceptualni oz.
semantični podatkovni model
 Logično načrtovanje – logični podatkovni
model
 Kreiranje fizične podatkovne baze – fizična
podatkovna baza oz. fizični podatkovni model
 Prehodi med modeli in avtomatizacija prehodov
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 13 -
Trije nivoji načrtovanja – trije modeli
Konceptualni
PM
Odločitev o PB:
-Relacijska
-Hierarhična
-Objektna
i-CASE
Logični PM
Fizični PM
(skripta)
Reverse Engineering
SUPB
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
Podatkovna
baza
- 14 -
ODBC
Konceptualno načrtovanje
 Konceptualno načrtovanje je opredelitev
podatkovnih potreb oz. zahtev poslovne domene
s pomočjo konceptualnega modela.
Model je poenostavitev
realnosti, pri čemer
 Konceptualno načrtovanje
preko konceptualnega
je abstrakcija realnosti poljubno natančna.
modela poskrbi za opis pomena podatkov,
potrebnih za poslovno
domeno.
Pomembno
je, da model prikazuje
pomembne elemente in izpušča tiste, ki nas
 Konceptualnega načrtovanja
ne moremo
ne zanimajo.
avtomatizirati, za njegovo izvedbo je odgovoren
Modele
razvijamo zato,
da bi sisteme bolje
analitik. Gre za prenos
semantike
v model.
razumeli.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 15 -
Pomen konceptualnega načrtovanja
 Je najbolj kritično – napake se prenašajo naprej
na naslednje modele.
 Zahteva sodelovanje uporabnikov. Uporabniki so
nosilci znanja o poslovni domeni, so poznavalci
semantike.
 Konceptualno načrtovanje mora upoštevati tudi
poslovna pravila.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 16 -
Umestitev konceptualnega načrtovanja
svet
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
mentalni model
konceptualni model
- 17 -
logični model
PB
Predstavitev konceptualnih modelov
 Najpogosteje uporabljana tehnika za predstavitev
konceptualnih podatkovnih modelov sta entitetni
model (model entiteta-razmerje) ter razredni
diagram. Obravnavali bomo prvega!
 Nazivi, ki se uporabljajo:
–
–
–
–
Konceptualni podatkovni model
Podatkovni model
Entitetni model
ER model
 Obstaja tudi razširjeni model entiteta razmerje
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 18 -
Gradniki entitetnega modela




Entitetni tip
Atribut
Razmerje
Enolični identifikator
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 19 -
Entitetni tip – entiteta...
 Entitete so posamezni primerki tipov objektov iz
poslovne domene: dogodki, predmeti, osebe,
pravila, dejstva
 O entitetah obstaja določena predstava o tem:
– kakšne lastnosti dejansko imajo
– kakšne lastnosti jim moramo določiti (morajo imeti), da bodo
izpolnjevale poslanstvo entitetnega modela
 Na osnovi predstave o tem in percepcije, lahko
entitete klasificiramo v entitetne tipe: vse
entitete, ki ustrezajo določeni predstavi,
pripadajo posameznemu entitetnemu tipu.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 20 -
Entitetni tip – entiteta
 Vsak trenutek pripada posameznemu
entitetnemu tipu množica entitet tega
entitetnega tipa, ki jo imenujemo entitetna
množica
 Entitetna množica je časovno spremenljiva:
entitete nastajajo, se spreminjajo in tudi izginjajo
(izstopajo iz množice).
 Entitetna množica je v nekem trenutku lahko tudi
prazna.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 21 -
Predstavitev entitetnega tipa
Ime
entitetnega
tipa
Ime entitetnega tipa
Prostor za atribute
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 22 -
Atribut...
 Entitete imajo določene lastnosti, posamezne
entitete (istega entitetnega tipa) se med seboj
razlikujejo po vrednosti njihovih lastnosti
 Entiteta ima praviloma veliko lastnosti, le del teh
lastnosti je zanimiv oz. pomemben za opazovano
poslovno domeno
 Lastnosti, ki so pomembne za opazovano
poslovno domeno, vključimo v konceptualni
model tako, da jih kot atribute določimo entiteti
(entitetnemu tipu)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 23 -
Atribut...
 Govorimo lahko o več vrstah lastnosti:
– Entitetna imena: naziv, ime, opis
– Prave entitetne lastnosti: višina, teža, cena, vrednost
– Lastnosti, ki jih določimo za potrebe poslovnih procesov,
poslovnih funkcij in poslovnih pravil: statusi
 Atribut določimo za tisto lastnost, ki je za
poslovno domeno pomembna
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 24 -
Atribut
 Kardinalnost atributa je minimalna in maksimalna
Glede na kardinalnost atributa ločimo:
–
–
–
–
Totalni atribut
Parcialni atribut
Enovrednostni atribut
Večvrednostni atribut
(1,n), kjer je n >= 1
(0,n), kjer je n >= 1
(m,1), kjer je m € {0,1}
(m,n), kjer je m € {0,1} in n>1
 Minimalna števnost 0 pomeni, da je atribut lahko
brez vrednosti (ni obvezen).
 Atribut pripada določenemu tipu: numerični,
znakovni,…
(1,1)
 Za večino tipov je potrebno
(1,3)
določiti tudi dolžino.
OSEBA
(1,1)
(0,n)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 25 -
EMŠO
Ime
Priimek
Vzdevek
Predstavitev atributa
(1,1)
(1,3)
OSEBA
(1,1)
(0,n)
EMŠO
Ime
Priimek
Vzdevek
OSEBA
EMŠO
Ime
Priimek
Vzdevek
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 26 -
Razmerja med entitetami
 Entitete niso svet zase, medsebojno se
povezujejo preko razmerij, povezav
 Razmerje ima določen pomen
 Predstavitev razmerja v modelu entiteta-razmerje
je povezava.
 Med opazovanim parom (v splošnem podmnožici)
entitet je lahko več razmerij: OSEBA, KRAJ –
stalno bivališče, začasno bivališče
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 27 -
Predstavitev razmerja...
OSEBA
OSEBA
živi
živi
Pomen razmerja
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 28 -
KRAJ
KRAJ
Predstavitev razmerja
OSEBA
OSEBA
živi v
ima
Vloga entitete v razmerju
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
KRAJ
živi
- 29 -
KRAJ
Kardinalnost razmerja...
 Kardinalnost (števnost) predstavlja število entitet
entitetnega tipa, ki so v razmerju glede na
pomen razmerja.
 Vsaka entiteta ima svojo kardinalnost v razmerju
– kardinalnost glede na vlogo. Entiteti OSEBA,
POŠTA:
– Ena (naključno izbrana) oseba ima stalno bivališče v enem
kraju
– V enem (naključno izbranem) kraju ima stalno bivališče več
oseb
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 30 -
Kardinalnost razmerja...
A
B
A
B
A
B
A
B
A
(n,m)
povezava
(p,r)
B
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 31 -
Kardinalnost razmerja
 Razmerji med entitetama OSEBA in POŠTA
Stalno prebivališče
POŠTA
OSEBA
Začasno prebivališče
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 32 -
Obveznost razmerja
 Obveznost pove, ali sta dve entiteti vedno v
razmerju ali lahko tudi nista v razmerju: obvezno,
neobvezno razmerje
 Obveznost lahko obravnavamo pod okriljem
števnosti, zaradi česar dodatno uvedemo
števnost 0
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 33 -
Razmerje tudi opisuje lastnost entitete
 Razmerje tudi opisuje lastnost entitete
 Primer: OSEBA, POŠTA
 Razmerje ima atributiven značaj
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 34 -
Enolični identifikator entitete...
 Enolični identifikator entitete je podmnožica
lastnosti entitete (atributov in razmerij – drugih
entitet), ki enolično razlikujejo posamezno
instanco entitete znotraj entitetne množice
 Z ozirom na to, ali tvorijo enolični identifikator
entitete le atributi entitete ali pa je v enoličnem
identifikatorju tudi kakšno razmerje, ločimo med
močnim entitetnim tipom in šibkim entitetnim
tipom
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 35 -
Enolični identifikator entitete
 Imamo lahko več enoličnih identifikatorjev,
vendar moramo enega izbrati – določiti
 Izbrani – določeni enolični identifikator je
podlaga za ključ v relacijskem modelu
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 36 -
Predstavitev enoličnega identifikatorja
(1,1)
(1,3)
OSEBA
(1,1)
(0,n)
EMŠO
Ime
Priimek
Vzdevek
OSEBA
EMŠO
Ime
Priimek
Vzdevek
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 37 -
Močni entitetni tip
 Enolični identifikator sestavljajo le atributi entitete
(identifikacijski atributi)
 {a1, … ak} je enolični identifikator entitete A, če
ustreza naslednjim pogojem:
a) a1, … ak so vsi totalni enovrednostni atributi, kar zagotavlja, da
imajo vsi identifikacijski atributi definirano natanko eno vrednost
(eno dimenzijo)
b) T: V1 x …x Vk  ET je totalna ali parcialna enovrednostna
funkcija, kar zagotavlja, da se vsak element kartezijskega
produkta vrednostnih množic, ki so območja identifikacijskih
atributov, preslika v največ eno entiteto tipa A
c) Je minimalna podmnožica, ne obstaja prava podmnožica, za
katero bi tudi veljal pogoj b)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 38 -
Šibki entitetni tip
 Enolični identifikator ni sestavljen le iz lastnih atributov,
temveč tudi iz razmerij oz. drugih entitet v razmerju oz.
njenih identifikatorjev.
 {a1, … ak}  IT1  ..  ITn je enolični identifikator
entitete A, če ustreza naslednjim pogojem:
a) a1, … ak so vsi totalni enovrednostni atributi, I pa identifikatorji
entitetnih tipov
b) T: V1 x …x Vkx ET1 x .. X ETn  ET je totalna ali parcialna
enovrednostna funkcija, kar zagotavlja, da se vsak element
kartezijskega produkta vrednostnih množic, ki so območja
identifikacijskih atributov, preslika v največ eno entiteto tipa A
c) Je minimalna podmnožica, ne obstaja prava podmnožica, za katero bi
tudi veljal pogoj b)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 39 -
Generalizacija in specializacija...
 Entitetni tip A s podtipoma B in C
 B in C pokrivata A totalno in ekskluzivno, če
velja: EB  EC = EA in EB  EC = {}
 B in C pokrivata A totalno in prekrivno, če velja:
EB  EC = EA in EB  EC ≠ {}
 B in C pokrivata A delno in ekskluzivno, če velja:
EB  EC  EA in EB  EC = {}
 B in C pokrivata A delno in prekrivno, če velja: EB
 EC  EA in EB  EC ≠ {}
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 40 -
Generalizacija in specializacija
OSEBA
MOŠKI
Totalno in
ekskluzivno
ŽENSKA
OSEBA
ŠTUDENT
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
Delno in
prekrivno
ŠPORTNIK
- 41 -
Metoda konceptualnega načrtovanja
 Možni koraki konceptualnega načrtovanja:
–
–
–
–
–
K1.1:
K1.2:
K1.3:
K1.4:
K1.5:
– K1.6:
– K1.7:
– K1.8:
– K1.9:
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Identificiraj entitetne tipe
Identificiraj povezave
Identificiraj in z entitetnimi tipi poveži atribute
Atributom določi domene
Določi kandidate za ključe; izmed kandidatov izberi
primarni ključ
Po potrebi uporabi elemente razširjenega diagrama
entiteta – razmerje
Preveri, če v modelu obstajajo odvečni elementi
Preveri, če model “zdrži” transkacije
Preveri model z uporabnikom
- 42 -
K1.1 – Identificiraj entitetne tipe...
 Na voljo različne tehnike
 Ena izmed tehnik je pregled uporabniških zahtev:
– Pregledamo vse omenjene samostalnike in fraze (npr.
profesor, predmet, izpit, rok, datum izpita,...)
– Pozorni smo na pomembne objekte (npr. ljudje, lokacije...)
– Skušamo ločiti objekte (npr. profesor, izpit,...) od
lastnosti objektov (ime, vpisna številka,...)
– Lastnosti objektov združujemo v entitetne tipe
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 43 -
K1.1 – Identificiraj entitetne tipe...
 Težave:
– Entitete niso vedno jasno predstavljene v dokumentaciji
 Uporaba primerov, analogij, sinonimov, homonimov
 Uporaba konkretnih imen oseb
– Ni vedno jasno, kaj je entitetni tip, kaj povezava in kaj
atribut (npr. izpit)
 Načrtovanje je subjektivne narave – možnih je
več (pravilnih) rešitev.
 Načrt zavisi od uporabnikove presoje in izkušenj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 44 -
K1.1 – Identificiraj entitetne tipe
 Entitetne tipe je potrebno dokumentirati
 Primer dokumentacije:
Naziv
entitetnega
tipa
Opis
Sinonim
Število entitet
Profesor
Predstavlja pedagoškega
delavca, ki je nosilec enega
ali več predmetov
Pedagoški
delavec
Vsaka katedra ima
enega ali več
profesorjev
Izpitni rok
Predstavlja datum, na
katerega je za nek predmet in
določeno ciljno skupino
(letnik, smer,...) razpisan
izpitni rok.
Rok, pisni
izpit,
kolokvij
Na leto se razpiše
okrog 300 pisnih
izpitov. Vsak predmet
mora imeti vsaj tri roke
letno
...
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 45 -
K1.2 – Identificiraj povezave...
 Ko smo identificirali entitetne tipe, skušamo
opredeliti vse povezave med njimi
 Uporabimo lahko podoben postopek kot v K1
(pregled uporabniških zahtev):
– Iščemo glagole (npr. profesor razpiše rok, študent
polaga izpit, študent izbere mentorja, študent se
vpiše v letnik,...)
– Zanimajo nas samo tiste povezave, ki so res potrebne
(očitne povezave ali povezave, ki nas ne zanimajo z vidika
hranjenja podatkov, so odveč)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 46 -
K1.2 – Identificiraj povezave...
 Postopek identifikacije povezav (nadaljevanje)
– Pozorni smo na povezave, ki niso binarne - povezujejo več
kot dve entiteti ali so rekurzivne.
Npr. študent opravi izpit za nek predmet pri
nekem profesorju.
Ali, pedagoški delavec ima asistenta, ki je tudi
pedagoški delavec.
– Preverimo, če smo zajeli vse povezave (načeloma lahko
preverimo za vsak par entitetnih tipov, če med njima obstaja
povezava) – postopek je lahko zelo potraten, zato ga ne
izvajamo vedno (preverjanje modela je stvar K8)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 47 -
K1.2 – Identificiraj povezave...
 Postopek identifikacije povezav (nadaljevanje)
– Povezavam določimo števnost
– Preverimo, če obstajajo kakšne dvoumne ali nepopolne
povezave (ang. chasm and fan tramps)
Primer dvoumne povezave
Profesor
je član
1..*
1..1
Katedra
Pr1
Pr2
Pr3
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
vključuje
1..1
1..*
Laboratorij
L1
K1
K2
- 48 -
L2
L3
K1.2 – Identificiraj povezave....
 Dvoumno povezavo odpravimo z
restrukturiranjem modela
Profesor
je član
1..*
1..1
Laboratorij
Pr1
Pr2
Pr3
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
vključuje
1..*
1.1
Katedra
K1
L1
L2
- 49 -
K2
K3
K1.2 – Identificiraj povezave...
Primer nepopolne povezave
Katedra
ima
1..1
1..*
Član
0..1
0..*
Oprema
K1
Čl1
O1
K2
Čl2
O2
K3
Čl3
O3
Kateri katedri pripada oprema O2?
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
je skrbnik
- 50 -
K1.2 – Identificiraj povezave...
 Tudi nepopolno povezavo odpravimo z
restrukturiranjem modela
Katedra
1..1
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
ima
1..1
1..*
Član
pripada
je skrbnik
0..1
0..*
Oprema
1..*
K1
Čl1
O1
K2
Čl2
O2
K3
Čl3
- 51 -
K1.2 – Identificiraj povezave
 Povezave je potrebno dokumentirati
 Primer dokumentacije:
Entitetni
tip
Števnost
Povezava
Števnost
Entitetni
tip
Član
1..*
1..1
Pripada
Je predstojnik
1..1
0..1
Katedra
Laboratorij
1..*
Sodi v
1..1
Katedra
...
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 52 -
K1.3 – Identificiraj atribute...
 Skušamo identificirati lastnosti entitet ter
povezav
 Uporabimo lahko tehniko proučevanja
uporabniških zahtev
– iščemo samostalnike, ki predstavljajo lastnosti, opisne
vrednosti ali identifikatorje objektov
 Korak določanja atributov entitetnih tipov je
relativno enostaven
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 53 -
K1.3 – Identificiraj atribute...
 Nekaj primerov, kjer je potrebna pazljivost:
– Enostavni in sestavljeni atributi (npr. naslov  ulica,
hišna številka, številka pošte, naziv pošte).
Kaj potrebuje uporabnik?
– Eno- in več-vrednostni atributi (npr. telefonska števila
 domača, v služni, mobilna...
– Izpeljani atributi (npr. skupna cena računa, starost
študenta,...)  pogosto ne kažemo v konceptualnih
modelih. Obravnavamo pri fizičnem načrtovanju.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 54 -
K1.3 – Identificiraj atribute...
 Dodatna priporočila:
– Če identificiramo atributi, ki navidez pripadajo več entitetam,
preverimo:
 Ali je možno združiti entitete (npr. asistent in profesor
združimo v pedagoški delavec);
 Če imajo entitete več skupnih vendar tudi svoje atribute,
razmislimo o uporabi generalizacije (npr. poleg entitetnega tipa
asistent in profesor uvedemo še entitetni tip pedagoški
delavec, ki prevzame vse skupne atribute.)
– Če identificiramo atribut, ki odraža povezavo (npr. atribut
katedra v entitetnem tipu Profesor predstavlja
povezavo z entiteto katedra):
 Če povezava obstaja, potem je atribut odveč
 Če povezava ne obstaja, jo je potrebno dodati ter atribut zbrisati
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 55 -
K1.3 – Identificiraj atribute
 Atribute je potrebno dokumentirati:
– Naziv atributa, opis, podatkovni tip, dolžina, sinonimi, ali je
atribut sestavljen (iz katerih atributov je sestavljen?), ali je
atribut izpeljan (iz katerih atributov je izpeljan?),...
 Primer dokumentacije:
Entitetni
tip
Atributi
Opis
Podatkovni
tip
Dolžina
...
Študent
VpisSt
Ime
Priimek
...
Vpisna številka študenta
Ime študenta
Priimek študenta
Number
Character
Character
8
20
20
...
...
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
...
- 56 -
K1.4 – Atributom določi domene...
 Domena je množica vrednosti, ki jih lahko
zavzamejo atributi, vključeni v to domeno.
 Domeni lahko določimo:
–
–
–
–
Seznam dovoljenih vrednosti
Minimalno in maksimalno vrednost
Podatkovni tip in dolžino
Dovoljene operacije nad atributom (še v raziskavi)
 Primeri domen:
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Barva  {bela, rumena, oranžna, rdeča}
Opis elementa  character 50
Starost  [0..120]
EMSO  number 13
- 57 -
K1.4 – Atributom določi domene
 Tudi domene dokumentiramo
 Zapišemo naziv domene ter lastnosti oz. pravila,
ki jih domena določa.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 58 -
K1.5 - Določi kandidate za ključe...
 Za vsak entitetni tip določimo kandidate za ključ
ter izberemo enega za primarni ključ.
 Kandidati za ključ so minimalne podmnožice
atributov, ki enolično identificirajo vsako entiteto.
 Če je kandidatov več, izberemo enega, ki je
primeren za primarni ključ.
Primer
Študent
EMŠO
VpisSt
DavcnaSt
Ime
Priimek
DtmRoj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 59 -
K1.5 - Določi kandidate za ključe...
 Nekaj priporočil za izbiro ključa, če je več
kandidatov:
– Kandidat z najmanj atributi;
– Kandidat, za katerega je najmanj verjetno, da se bodo
njegove vrednosti spreminjale;
– Kandidat z najmanjšo dolžino znakov (za alfanumerične
kandidate);
– Kandidat z najmanjšo maksimalno vrednostjo (za numerične
kandidate);
– Kandidat, ki ga je najlažje uporabiti s stališča uporabnika
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 60 -
K1.5 - Določi kandidate za ključe
 Dodatna priporočila:
– Imena navadno niso dober kandidat za ključ
– Bodi pozoren na šibke entitetne tipe (šibkim entitetam v
okviru konceptualnega načrtovanja ne moremo določiti
ključa)
 Tudi primarne in alternativne ključe je potrebno
dokumentirati.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 61 -
K1.6 – uporabi elemente EER diagrama...
 EER – razširjen ER diagram
 Elementi razširjenega ER diagrama so:
– Specializacija: ugotovljamo razlike med entitetami
doočenega tipa in entitetni tip razbiti na več specializiranih
entitet.
– Generalizacija: ugotavljamo skupne lastnosti entitet različnih
tipov in kreirati nov tip s skupnimi lastnostmi.
– Agregacija: modeliramo povezavo “je del” oziroma “ima”, s
katero določimo pripadnost tipa “del” tipu “celota”.
– Kompozicija: posebna vrsta agregacije z močnim lastništvom
 “del” ne more obstajati brez “celote”.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 62 -
K1.6 – uporabi elemente EER diagrama...
Primer specializacije
Znak za specializacijo/
generalizacijo.
Študent
Redni študent
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Lahko tudi:
Izredni študent
- 63 -
K1.6 – uporabi elemente EER diagrama...
Primer generalizacije
Pedagoški delavec
Profesor
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Asistent
- 64 -
K1.6 – uporabi elemente EER diagrama...
Primer agregacije
Navadna povezava
Znak za
agregacijo.
Študent
Študent
pripada
1..*
1..1
pripada
1..*
1..1
Indeks
Indeks
Agregacija povečuje semantiko modela
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 65 -
K1.6 – uporabi elemente EER diagrama...
Primer kompozicije
Navadna povezava
Znak za
kompozicijo.
Študent
Študent
pripada
1..*
1..1
pripada
1..*
1..1
Indeks
Indeks
Kompozicija povečuje semantiko modela
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 66 -
K1.6 – uporabi elemente EER diagrama
 Kdaj uporabiti elemente razširjenega ER
diagrama?
– Elementi razširjenega diagrama povečajo semantiko modela
vendar lahko negativno vplivajo na “berljivost” modela
– Berljivost, enostavnost modela naj bo vodilo pri odločanju o
uporabi naprednih modelirnih elementov (predvsem
agregacija in kompozicija)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 67 -
K1.7 - Preveri obstoj odvečnih elem....
 Preverimo, če v modelu obstajajo redundantni
elementi:
– Pregledamo povezava 1 – 1
– Odstranimo odvečne povezave
– Preverimo “časovni okvir”
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 68 -
K1.7 - Preveri obstoj odvečnih elem....
 Povezave 1 – 1
– Pri identifikaciji entitetnih tipov smo morda zajeli več tipov,
ki predstavljajo iste objekte (npr. Profesor, Pedagoški
delavec, Asistent)
– Če taki tipi obstajajo, jih je potrebno združiti
– Če so primarni ključi različni, izberemo enega
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Profesor
Pedagog
Asistent
EMŠO
DavcnaSt
Ime
Priimek
DtmRoj
EMŠO
DavcnaSt
Ime
Priimek
DtmRoj
EMŠO
DavcnaSt
Ime
Priimek
DtmRoj
- 69 -
K1.7 - Preveri obstoj odvečnih elem....
 Odstrani odvečne povezave
– Povezava je odvečna, če je možno priti do iste informacije
prek drugih povezav!
– Izdelati želimo minimalen podatkovni model  odvečne
povezave zato odstranimo.
– Zgolj pregledovanje poti med entitetnimi tipi ne zadošča
(povezave imajo lahko različen pomen)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 70 -
K1.7 - Preveri obstoj odvečnih elem....
 Ali je kakšna povezava odveč?
Profesor
je predstojnik
1..1
0..1
1..*
Katedra
1..1
pripada
1..*
je član
1..1
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 71 -
Laboratorij
K1.7 - Preveri obstoj odvečnih elem....
 Ali je kakšna povezava odveč?
Profesor
pripada
1..*
1..1
1..*
Katedra
1..1
pripada
1..*
je član
1..1
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 72 -
Laboratorij
K1.7 - Preveri obstoj odvečnih elem....
 Preveri časovni okvir
– Časovni okvir povezav je lahko pomemben
Oče
je poročen z
0..1
0..1
Mati
1..1
1..1
je oče
?
0..*
je mati
0..*
Otrok
– Kaj če ima oče otroka iz prejšnjega zakona?
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 73 -
K1.8 - Preveri če model zdrži transkacije...
 Preveriti moramo če model, ki smo ga dobili s
koraki od K1 do K7, podpira vse zahtevane
transakcije.
– Transakcije izvajamo ročno
– Če neke transkacije ne uspemo izvesti, je model pomanjkljiv
(manjka bodisi entitetni tip, povezava ali atribut)
 Možna dva pristopa:
– Preverjanje opisa transakcij
– Preverjanje transakcijskih poti
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 74 -
K1.8 - Preveri če model zdrži transkacije...
 Preverjanje opisa transakcij
– Vsako transakcijo opišemo;
– Preverimo, če model zajema vse entitetne tipe, povezave in
atribute, ki jih transakcija potrebuje.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 75 -
K1.8 - Preveri če model zdrži transkacije...
 Primer opisa transakcijskih zahtev
– Vnos podatkov:
 Vnesi podatke o študentih (npr. 24010637, Monika Jemec,...)
 Vnesi podatke o predmetih (npr. 70029, Razvoj IS, Letni,...)
 ...
– Urejanje in brisanje podatkov:
 Uredi/briši podatke o študentu
 Uredi/briši podatke o predmetih
 ...
– Poizvedbe
 Izpiši vse študente, ki so se vpisali v določen letnik, določene
smeri, določenega programa
 Izpiši vse predmete, ki jih je opravil določen študent
 ...
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 76 -
K1.8 - Preveri če model zdrži transkacije...
 Preverjanje transakcijskih poti
– Transakcije preverimo na modelu – pot transakcije narišemo
– Pristop načrtovalcu omogoča:
 Da identificira pomanjkljivosti modela (če pot za neko transkacijo ni
možna)
 Da identificira dele modela, ki so transakcijsko kritični
 Da odkrije odvečne dele modela (deli, ki jih ne potrebuje nobena
transakcija)
 Preverjanje transkacij je zamudno vendar
pomembno delo!!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 77 -
K1.8 - Preveri, če model zdrži transkacije
a)
b)
Izpiši vse predmete, ki jih je opravil določen študent
Izpiši vse študente, ki so se vpisali v določen letnik, določene smeri,
določenega programa
b
?
Prijava
ima
Program
1..1
progID
Smer
0..1
1..*
se predava na
1..*
se nanaša na
0..*
za
Rok
1..1
rokID
0..*
Predmet
1..1
0..*
1..1
je opravljal
Študent
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
predID
1..1
pripada
vpisSt
smerID
1..1
a
Izpit
0..*
stPol
- 78 -
0..*
iz
K1.9 – Preveri model z uporabnikom
 Na koncu model preverimo z uporabnikom
 Anomalije, pomanjkljivosti, napake,... lahko
vodijo v ponovitev korakov od K1 do K9.
 V mnogih podjetjih mora uporabnik podpisati
podatkovni model
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 79 -
Logično načrtovanje
 Logično modeliranje podatkovne baze nastopi za
konceptualnim modeliranjem.
 Osnova logičnega modela je jezik, ki je razumljiv
ciljnemu SUPB.
 Če izberemo relacijski SUPB, potem govorimo o
relacijskem modelu.
svet
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
mentalni model
konceptualni model
- 80 -
logični model
PB
Podpora orodij CASE
Konceptualni
PM
Odločitev o PB:
-Relacijska
-Hierarhična
-Objektna
Logični PM
i-CASE
Logično načrtovanje
Fizični PM
(skripta)
Reverse Engineering
SUPB
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
Podatkovna
baza
- 81 -
ODBC
Prehod iz konceptualnega v logični model
 Prehod iz konceptualnega v logični model je
navadno avtomatiziran s strani CASE orodij.
Primer:
vrsta baze: relacijska
SUPB: Oracle
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
ANALIZA
NAČRTOVANJE
Konceptualni model
Relacijski model
Entitetni tip
Relacija / Tabela
Atribut
Atribut / Stolpec
Enolični identifikator
Ključ
Povezava 1:n
Tuji ključ
Povezava m:n
- 82 -
Vmesna tabela
Ponovitev
Funkcionalne odvisnosti...
 Relacija je model nekega stanja v svetu  njena
vsebina ne more biti poljubna.
 Realne omejitve ne omogočajo, da bi bili odnosi
v svetu kakršnikoli; možna so le določena stanja.
 Odvisnosti so sredstvo, s katerim lahko v
relacijskem modelu povemo, katere vrednosti
relacij so veljavne in katere sploh ne morejo
obstajati.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 83 -
Funkcionalne odvisnosti...
 Poznamo več vrst odvisnosti:
– Funkcionalne odvisnosti (functional dependency)
– Večvrednostne odvisnosti (multivalued dependency)
– Stične odvisnosti (join dependency)
 Obravnavali bomo funkcionalne odvisnosti; ostale
bodo obravnavane v okviru postopka razširjene
normalizacije (PB2, drugi semester).
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 84 -
Funkcionalne odvisnosti...
 Predpostavimo, da obstaja relacijska shema R z
množico atributov, katere podmnožici sta X in Y.
 V relacijski shemi R velja X  Y (X funkcionalno
določa Y oziroma Y je funkcionalno odvisen od
X), če v nobeni relaciji, ki pripada shemi R, ne
obstajata dve n-terici, ki bi se ujemali v
vrednostih atributov X in se ne bi ujemali v
vrednostih atributov Y.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 85 -
Funkcionalne odvisnosti
 Množico funkcionalnih odvisnosti, ki veljajo med
atributi funkcionalne sheme R in v vseh njenih
relacijah, označimo s F
X  Y  F   r ( Sh(r) = R   t,  u (t  r in u  r in
t.X = u.X  t.Y = u.Y )
kjer
t.X, u.X, t.Y in u.Y označujejo vrednosti atributov X
oziroma Y v n-tericah t oziroma u.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 86 -
Primeri funkcionalnih odvisnosti
 Imamo relacijo s shemo
Izpit( VpŠt, Priimek, Ime, ŠifraPredmeta, Datum izpita,
OcenaPisno, OcenaUstno)
 z naslednjim pomenom:
Študent z vpisno številko VpŠt ter priimkom Priimek in
imenom Ime je na DatumIzpita opravljal izpit iz predmeta s
šifro ŠifraPredmeta. Dobil je oceno OcenaPisno in OcenaUstno.
 Funkcionalne odvisnosti relacijske sheme Izpit
so:
F  { VpŠt  (Priimek, Ime), (VpŠt, ŠifraPredmeta,
DatumIzpita)  (OcenaPisno, OcenaUstno) }
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 87 -
Ponovitev
Ključi relacije...
 Ker je relacija množica n-teric, so v njej vse nterice ločene med seboj.
 Za sklicevanje na posamezno n-terico ni potrebno
poznati vseh vrednosti atributov n-terice, če v
shemi nastopajo funkcionalne odvisnosti.
 Množici atributov, ki določajo vsako n-terico,
pravimo ključ relacije oziroma ključ relacijske
sheme.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 88 -
Ključi relacije...

Predpostavimo, da obstaja relacijska shema z
atributi A1 A2 ... An katere podmnožica je
množica atributov X.

Atributi X so ključ relacijske sheme oziroma
pripadajočih relacij, če sta izpolnjena naslednja
dva pogoja:
(1) X  A1 A2 ... An
(2) ne obstaja X’, ki bi bila prava podmnožica od X in ki bi tudi
funkcionalno določala A1 A2 ... An
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 89 -
Ključi relacije...
 Poznamo več vrst ključev:
–
–
–
–
Kandidat za ključ (a key candidate)
Primarni ključ (primary key)
Superključ (superkey)
Tuji ključ (foreign key)
 Kandidat za ključ je vsaka podmnožica atributov
relacije, ki relacijo enolično določa.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 90 -
Ključi relacije
 Primarni ključ je tisti kandidat za ključ, ki ga
izberemo za shranjevanje relacij v fizični
podatkovni bazi.
 Superključ je vsaka množica atributov, v kateri je
vsebovan ključ  ključ je podmnožica
superključa.
 Tuji ključ je množica atributov, v okviru ene
relacije, ki je enaka kandidatu za ključ neke
druge ali iste relacije.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 91 -
Primeri ključev
ARTIKEL
Šifra
Naziv
Zaloga
A10
Telovadni copati Nike
10
A12
Trenerka Bali
4
BC80
Moška jakna QuickSilver
1
X12
Ženska jakna QuickSilver
0
Primarni ključ v tabeli Artikel
RAČUN
Primarni ključ v tabeli Račun
Račun
Šifra artikla
Količina
15/05
A10
1
15/05
X12
1
Tuji ključ v tabeli Račun  kaže na primarni ključ v tabeli Artikel
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 92 -
Normalizacija...
 Kaj si bomo pogledali?
– Namen normalizacije.
– Uporaba normalizacije pri načrtovanju relacijske podatkovne
baze.
– Problemi zaradi redundance podatkov v osnovnih relacijah.
– Postopek normalizacije.
– Normalne oblike:







PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
I. normalna oblika,
II. normalna oblika,
III. normalna oblika
IV. poslovna normalna oblika
Boyce Coddova normalna oblika
IV. normalna oblika
V. normalna oblika
- 93 -
Namen normalizacije...
 Normalizacija je postopek, s katerem pridemo do
množice primernih relacij, ki ustrezajo potrebam
poslovne domene.
 Nekaj lastnosti primernih relacij:
– Relacije imajo minimalen nabor atributov  zgolj tiste, ki so
potrebni za pokritje potreb poslovnega sistema;
– Atributi, ki so logično povezani, so zajeti v isti relaciji;
– Med atributi relacij je minimalna redundanca  vsak atribut
(razen tujih ključev) je predstavljen samo enkrat.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 94 -
Namen normalizacije
 Prednosti uporabe podatkovnih baz, ki jih
sestavljajo množice primernih relacij, so:
– Enostavnejša dostop do podatkov ter vzdrževanje podatkov;
– Večja učinkovitost;
– Boljša izraba diskovnih kapacitet.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 95 -
Prednosti pravilnega načrtovanja
 Osnovni cilj načrtovanja relacijske podatkovne
baze je grupirati atribute v relacije tako, da bo
čim manj redundance med podatki.
 Potencialne koristi pravilnega načrtovanja so:
– Spremembe podatkov v podatkovni bazi dosežemo z
minimalnim številom operacij  večja učinkovitost; manj
možnosti za podatkovne nekonsistentnosti.
– Manjše potrebe po diskovnih kapacitetah za shranjevanje
osnovnih relacij  manjši stroški.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 96 -
Primer
 Relacija StaffBranch ima odvečne podatke.
Atribut z odvečnimi (ponavljajočimi) podatki
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 97 -
Ažurne anomalije
 Relacije, ki vsebujejo odvečne podatke lahko
povzročajo anomalije pri spreminjanju podatkov
 govorimo o ažurnih anomalijah.
 Poznamo več vrst anomalij:
– Anomalije pri dodajanju n-teric v relacijo
– Anomalije pri brisanju n-teric iz relacije
– Anomalije pri spreminjanju n-teric
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 98 -
Anomalije pri dodajanju
 Primeri anomalij:
– Če želimo dodati podatke o novih članih (staff) za neko
organizacijsko enoto (branch) moramo vpisati tudi vse
podrobnosti o organizacijski enoti.
– Če želimo dodati podatke o novi organizacijski enoti, ki še
nima nobenega člana, moramo v vsa polja , ki člane
opisujejo, vpisati Null.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 99 -
Anomalije pri brisanju
 Primeri anomalij:
– Če iz relacije zbrišemo n-terico, ki predstavlja zadnjega člana
v neki organizacijski enoti, zgubimo tudi podatke o tej
organizacijski enoti.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 100 -
Anomalije pri spreminjanju
 Primeri anomalij:
– Če želimo spremeniti vrednost nekega atributa določene
organizacijske enote (npr. naslov), moramo popraviti vse
n-terice, v katerih takšna vrednost atributa nastopa.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 101 -
Postopek normalizacije
 Postopku preoblikovanja relacij v obliko, pri
kateri do ažurnih anomalij ne more priti, pravimo
normalizacija.
 Obstaja več stopenj normalnih oblik. Obravnavali
bomo osnovne: 1NO, 2NO, 3NO, 4PNO in
razširjene, redke oblike: BCNO, 4NO, 5NO.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 102 -
1NO – prva normalna oblika
 Relacija je v prvi normalni obliki, če:
– Nima ponavljajočih atributov  ne obstajajo atributi ali
skupine atributov, ki bi imele več vrednosti pri isti vrednosti
ostalih atributov (na presečišču ene vrstice in enega stolpca
je več vrednosti)
– Ima definiran primarni ključ in določene funkcionalne
odvisnosti
 Koraki:
– Odstranimo ponavljajoče atribute
– Določimo funkcionalne odvisnosti
– Določimo primarni ključ
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 103 -
Primer – relacija v nenormalizirani obliki
Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) )
Skupina ponavljajočih se atributov.
VŠ
ime
pošta kraj
64010632 Bratina
Simon
4100
Kranj 20020
20021
20033
IS
TPO
IPI
10
8
8
64016209 Bizjak
Tadeja
2250
Ptuj
E1
IPI
9
6
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
priime
k
šifra predmeta naziv ocena
20060
20033
- 104 -
Primer – pretvorba v 1NO...
Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) )
Odpravimo ponavljajoče atribute
Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena )
Identificiramo funkcionalne odvisnosti
F  { VŠ  (priimek, ime, pošta, kraj), šifra predmeta 
naziv, pošta  kraj, (VŠ, šifra predmeta)  ocena }
Določimo primarni ključ
Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena )
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 105 -
Primer – pretvorba v 1NO
VŠ
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
priime
k
ime
pošta kraj
64010632 Bratina
Simon
4100
Kranj 20020
20021
20033
IS
TPO
IPI
10
8
8
64016209 Bizjak
Tadeja
2250
Ptuj
E1
IPI
9
6
VŠ
ime
pošta kraj
64010632 Bratina
Simon
4100
Kranj 20020
IS
10
64010632 Bratina
Simon
4100
Kranj 20021
TPO
8
64010632 Bratina
Simon
4100
Kranj 20033
IPI
8
64016209 Bizjak
Tadeja
2250
Ptuj
20060
E1
9
64016209 Bizjak
Tadeja
2250
Ptuj
20033
IPI
6
priime
k
- 106 -
šifra predmeta naziv ocena
20060
20033
šifra predmeta naziv ocena
2NO – druga normalna oblika
 Relacija je v drugi normalni obliki:
– Če je v prvi normalni obliki in
– Ne vsebuje parcialnih odvisnosti  noben atribut, ki ni del
ključa, ni funkcionalno odvisen le od dela primarnega ključa,
temveč od celotnega ključa
 Druga normalna oblika je odvisna predvsem od
ključa relacije. Relacija je avtomatsko v drugi
normalni obliki, če:
– Je njen primarni ključ sestavljen le iz enega atributa,
– Je njen primarni ključ sestavljen iz vseh atributov relacije ali
– Je njen primarni ključ sestavljen iz vseh razen enega atributa
relacije
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 107 -
Primer – pretvorba v 2NO...
!
Indeks( VŠ, šifra predmeta, priimek, ime, pošta, kraj, naziv, ocena )
!
Relacijo razbijemo
Študent( VŠ, priimek, ime, pošta, kraj)
Predmet( šifra predmeta, naziv)
Indeks( #VŠ, #šifra predmeta, ocena)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 108 -
Primer – pretvorba v 2NO
VŠ
priime
k
ime
pošta kraj
64010632 Bratina
Simon
4100
Kranj 20020
IS
10
64010632 Bratina
Simon
4100
Kranj 20021
TPO
8
64010632 Bratina
Simon
4100
Kranj 20033
IPI
8
64016209 Bizjak
Tadeja
2250
Ptuj
20060
E1
9
64016209 Bizjak
Tadeja
2250
Ptuj
20033
IPI
6
VŠ
ime
pošta kraj
VŠ
priime
k
šifra predmeta ocena
64010632 20020
10
64010632 20021
8
64010632 20033
8
šifra predmeta naziv
64016209 20060
9
20020
IS
64016209 20033
6
20021
TPO
20033
IPI
20060
E1
20033
- 109
IPI -
64010632 Bratina
Simon
4100
Kranj
64016209 Bizjak
Tadeja
2250
Ptuj
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
šifra predmeta naziv ocena
3NO – tretja normalna oblika
 Relacija je v tretji normalni obliki:
– Če je v drugi normalni obliki in
– Če ne vsebuje tranzitivnih funkcionalnih odvisnosti  med
atributi, ki niso del primarnega ključa, ni odvisnosti.
 Relacija je avtomatsko v tretji normalni obliki, če:
– Je njen ključ sestavljen iz vseh atributov relacije
– Je njen ključ sestavljen iz vseh razen enega atributa relacije.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 110 -
Primer – pretvorba v 3NO...
!
Študent( VŠ, priimek, ime, pošta, kraj)
Predmet( šifra predmeta, naziv)
Indeks( #VŠ, #šifra predmeta, ocena)
Relacijo razbijemo
Študent( VŠ, priimek, ime, #pošta)
Pošta(pošta, kraj)
Predmet( šifra predmeta, naziv)
Indeks( #VŠ, #šifra predmeta, ocena)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 111 -
Primer – pretvorba v 3NO
VŠ
VŠ
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
ime
pošta kraj
64010632 Bratina
Simon
4100
Kranj
64016209 Bizjak
Tadeja
2250
Ptuj
priime
k
priime
k
ime
pošta
64010632 Bratina
Simon
4100
64016209 Bizjak
Tadeja
2250
- 112 -
pošta kraj
4100
Kranj
2250
Ptuj
4PNO – četrta poslovna normalna oblika
 Relacija je v četrti poslovni normalni obliki, če:
– je v tretji normalni obliki in
– v relaciji ne obstajajo atributi, ki bi bili odvisni od vrednosti
primarnega ključa.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 113 -
Primer – pretvorba v 4PNO...
Študent( VŠ, priimek, ime, #pošta, datum plačila šolnine, rok diplome)
Za izredne študenta
Študent( VŠ, priimek, ime, #pošta)
Redni študent( #VŠ, rok diplome)
Izredni študent( #VŠ, datum plačila šolnine)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 114 -
Za redne študenta
Primer – pretvorba v 4PNO
VŠ
VŠ
Priimek
Ime
Datum plačila
šolnine
64010632 Bratina
Simon
64016209 Bizjak
Tadeja
19.4.2002
64010670 Berce
Marjan
12.4.2004
64620010 Mele
Silvana
1.4.2005
65120987 Leban
Tibor
15.7.2005
Priimek
Ime
VŠ
15.3.2005
Datum plačila
šolnine
64010632 Bratina
Simon
64016209 Bizjak
Tadeja
64010670 Berce
Marjan
64010670 12.4.2004
64620010 Mele
Silvana
VŠ
65120987 Leban
Tibor
64010632 15.3.2005
64016209 19.4.2002
Rok diplome
64620010 1.4.2005
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
Rok diplome
65120987
- 115 - 15.7.2005
Uporaba nenormaliziranih relacij...
 Včasih zavestno uporabljamo relacije, ki ne
ustrezajo najvišjim normalnim oblikam.
 Prve in druge normalne oblike nikoli ne kršimo.
 Višjim normalnim oblikam se včasih odrečemo na
račun doseganja boljše učinkovitosti.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 116 -
Uporaba nenormaliziranih relacij
 Primer:
– Rezultat (športnik, tekmovanje, čas prvega teka, čas
drugega teka, čas skupaj)
– Relacija ni v tretji normalni formi.
– Čas skupaj je izpeljan atribut  ni odvisen od ključa, temveč
je seštevek časov obeh tekov.
– Skupen čas računamo ob vpisu v bazo, zato izboljšamo
učinkovitost pri nadaljnji obdelavi podatkov.
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 117 -
Vaja
 Spodnjo relacijo pretvorite v 4PNO
Delavec ( šifra delavca, priimek, ime, podjetje, mesto, številka pogodbe,
število točk, (datum izplačila, plača))
Pomen relacije: delavec s šifro (šifra delavca), priimkom (priimek) ter
imenom (ime) je zaposlen v natanko enem podjetju (podjetje).
To podjetje se nahaja v natanko enem mestu (mesto). Vsi delavci imajo
sklenjene delovne pogodbe (številka pogodbe), s to razliko, da imajo vodilni
delavci sklenjene individualne pogodbe, ostali delavci pa kolektivne
pogodbe, na osnovi katerih so tudi točkovani (število točk).
V relaciji so zajeti tudi atributi, ki povedo, kakšne plače so prejemali
delavci (datum izplačila, plača)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 118 -
Vaja
 Prva normalna oblika – odprava ponavljajočih
skupin
Delavec ( šifra delavca, priimek, ime, podjetje, mesto, številka pogodbe,
število točk, (datum izplačila, plača))
Delavec ( šifra delavca, priimek, ime, podjetje, mesto, številka pogodbe,
število točk, datum izplačila, plača)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 119 -
Vaja
 Prva normalna oblika – identifikacija
funkcionalnih odvisnosti
Delavec ( šifra delavca, priimek, ime, podjetje, mesto, številka pogodbe,
število točk, datum izplačila, plača)
šifra delavca  priimek, ime, podjetje, mesto, številka pogodbe,
število točk
številka pogodbe  število točk
podjetje  mesto
šifra delavca, datum izplačila  plača
F  {šifra delavca  (priimek, ime, podjetje, mesto, številka pogodbe,
število točk), podjetje  mesto, številka pogodbe  število točk,
(šifra delavca, datum izplačila)  plača}
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 120 -
Vaja
 Prva normalna oblika – določitev ključa
F  {šifra delavca  (priimek, ime, podjetje, mesto, številka pogodbe,
število točk), podjetje  mesto, številka pogodbe  število točk,
(šifra delavca, datum izplačila)  plača}
Ključ = {šifra delavca ,datum izplačila}
1NO
Delavec ( šifra delavca, priimek, ime, podjetje, mesto,
številka pogodbe, število točk, datum izplačila, plača)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 121 -
Vaja
 Druga normalna oblika
Delavec ( šifra delavca, priimek, ime, podjetje, mesto,
številka pogodbe, število točk, datum izplačila, plača)
2NO
Delavec ( šifra delavca, priimek, ime, podjetje, mesto, številka pogodbe,
število točk)
Plača (#šifra delavca, datum izplačila, plača)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 122 -
Vaja
 Tretja normalna oblika
!
Delavec ( šifra delavca, priimek, ime, podjetje, mesto,
številka pogodbe, število točk)
3NO
!
Delavec (šifra delavca, priimek, ime, #podjetje, #številka pogodbe)
Podjetje (podjetje, mesto)
Pogodba (številka pogodbe, število točk)
Plača (#šifra delavca, datum izplačila, plača)
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
- 123 -
Razširjena normalizacija...
 Osnovne normalne oblike (1NO, 2NO in 3NO) v
večini primerov zadoščajo.
 Razširjena normalizacija zamišljena za
identifikacijo in odpravo redkih primerov, ki
povzročajo anomalije ter odvečnost podatkov.
 Razširjena normalizacija zajema:
– BCNO – Boyce-Coddova normalna oblika
– 4NO – četrta normalna oblika
– 5NO – peta normalna oblika
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 124 -
Določanje funkcionalnih odvisnosti
 Cel nabor funkcionalnih odvisnosti v relacijski
shemi je lahko zelo velik.
 Smiselno je določiti podmnožico odvisnosti, ki
dobro odraža celoto.
 Podmnožico lahko določimo s pomočjo pravil
sklepanja.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 125 -
Zaprtje množice X
 Za relacijo r določimo množico funkcionalnih
odvisnosti X, ki je manjša od množice vseh
funkcionalnih odvisnosti Y.
 Veljati mora, da vsaka odvisnost iz množice Y
sledi tudi iz množice X.
 Množico vseh funkcionalnih odvisnosti, ki jo je
moč pridobiti na osnovi množice X, imenujemo
zaprtje X, označimo pa z X+.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 126 -
Pravila sklepanja in Armstrongovi aksiomi
 Množico pravil sklepanja, s pomočjo katerih je
moč iz množice funkcionalnih odvisnosti X
pridobiti množico funkcionalnih odvisnosti Y,
imenujemo Armstrongovi aksiomi.
X
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Armstrongovi
aksiomi
- 127 -
Y
Opredelitev pravil sklepanja...
 Naj bodo A, B in C podmnožice atributov
relacijske sheme R. Armstrongovi aksiomi so:
– (1) Refleksivnost
 Če B  A, potem A  B
– (2) Razširitev
 Če A  B, potem A,C  B,C
– (3) Tranzitivnost
 Če A  B in B  C, potem A  C
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 128 -
Opredelitev pravil sklepanja...
 Iz osnovnih aksiomov izpeljemo dodatna pravila.
 Naj bo D dodatna podmnožica atributov
relacijske sheme R. Naj velja:
– (4) Samo-opredelitev (Self-determination)
 AA
– (5) Dekompozicija
 Če A  B,C, potem A  B in A  C
– (6) Združitev
 Če A  B in A  C, potem A  B,C
– (7) Psevdotranzitivnost ali kompozicija
 Če A  B in C  D potem A,C  B,D
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 129 -
Minimalno pokritje
 Množica funkcionalnih odvisnosti Y je pokrita z
množico funkcionalnih odvisnosti X, če je vsaka
funkcionalna odvisnost iz Y tudi v X+.
 Množica funkcionalnih odvisnosti X je minimalna,
če velja:
– Vsaka odvisnost v X ima na desni strani en sam atribut.
– Nobene odvisnosti A  B iz X ni moč zamenjati z odvisnostjo
C  B, kjer je C prava podmnožica od A, tako da bi še
vedno imeli množico odvisnosti, ki je ekvivalentna X.
– Nobene odvisnosti iz X ni moč odstraniti ter ohraniti tako
množico odvisnosti, ki je ekvivalentna X.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 130 -
BCNO - Boyce-Coddova normalna oblika...
 V primerjavi s 3NO vpelje BCNO dodatne
omejitve.
 Osnovne normalne oblike preverjajo parcialne in
tranzitivne odvisnosti glede na primarni ključ. Ne
preverjajo pa se odvisnosti glede na druge
kandidate za ključ.
 BCNO je strožja od 3NO:
– razširja omejitve na vse kandidate za ključ,
– zahteva, da je vsaka determinanta tudi kandidat za ključ.
Determinanta je atribut ali skupina atributov, ki funkcionalno določa nek drug
atribut ali skupino atributov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 131 -
BCNO - Boyce-Coddova normalna oblika...
 Relacija r s shemo R je v BCNO, če za vsako v
njej veljavno odvisnost X  Y velja vsaj eden
izmed naslednjih pogojev:
– X  Y je trivialna odvisnost
– X je nadključ sheme R
Trivialna odvisnost X  Y v shemi R je odvisnost, ki vedno velja,
ne glede na vsebino atributov v X in Y
 Ali je relacija v BCNO lahko preverimo tudi tako,
da pogledamo, če so vse determinante v relaciji
obenem tudi kandidati za ključ.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 132 -
BCNO - Boyce-Coddova normalna oblika...
 Kršenje BCNO se ne dogaja pogosto.
 Potencialne nevarnosti nastopijo v relacijah, ki:
– Vsebujejo dva ali več sestavljenih kandidatov za ključ;
– Kandidati za ključ se prekrivajo  imajo vsaj en atribut
skupen.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 133 -
Primer postopka od 1NO - BCNO...
Poročilo, ki je osnova
za pripravo relacij
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 134 -
Primer postopka od 1NO - BCNO...
Pretvorba v 1NO
Nenormalizirana
relacija
Relacija v 1NO
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 135 -
Primer postopka od 1NO - BCNO...
Funkcionalne odvisnosti
Identifikacija parcialne
odvisnosti
Ne gre za parcialno odvisnost,
saj ima determinanta še dodaten
atribut, ki ni del primarnega ključa.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 136 -
Primer postopka od 1NO - BCNO...
Odprava parcialnih odvisnosti  Pretvorba v 2NO
StaffPropertyInspection( propertyNo, iDate, iTime, pAddress,
comments, stafNo, sName, carReg )
Property( propertyNo, pAddress )
PropertyInspection( propertyNo, iDate, iTime, comments, stafNo,
sName, carReg )
Relacija v 2NO
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 137 -
Primer postopka od 1NO - BCNO...
Odprava tranzitivnih odvisnosti  Pretvorba v 3NO
Property( propertyNo, pAddress )
PropertyInspection( propertyNo, iDate, iTime, comments,
stafNo, sName, carReg )
Tranzitivna odvisnost
staffNo  sName
Property( propertyNo, pAddress )
Staff( staffNo, sName )
PropertyInspection( propertyNo, iDate, iTime, comments,
stafNo, carReg )
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Relacija- v138
3NO
-
Primer postopka od 1NO - BCNO...
Odprava determinant  Pretvorba v BCNO
Property ( propertyNo, pAddress )
Fd2: propertyNo  pAddress
Staff ( staffNo, sName )
Par (stafNo, iDate) ne predstavlja
kandidata za ključ!
Fd3: staffNo  sName
PropertyInspection( propertyNo, iDate, iTime, comments,
stafNo, carReg )
Fd1:
Fd4:
Fd5:
Fd6:
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
propertyNo, iDate  iTime, comments, staffNo, carReg
staffNo, iDate  carReg
carReg, iDate, iTime  propertyNo, comments, staffNo
staffNo, iDate, iTime  propertyNo, comments
- 139 -
Primer postopka od 1NO - BCNO...
Težave zaradi kršitve BCNO
 Če želimo spremeniti podatek, ki govori o tem, kateri avtomobil
je bil dodeljen osebi SG14 22. aprila 2003, moramo spremeniti
dve vrstici. Sicer dobimo nekonsistentno stanje v podatkovni
bazi!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 140 -
Primer postopka od 1NO - BCNO...
Dekompozicija relacijev BCNO
StaffPropertyInspection
PropertyInspection
Staff
Staff
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
PropertyInspect
StaffCar
Inspection
- 141 -
1NO
Property
2NO
Property
3NO
Property
BCNO
Več-vrednostne odvisnosti...
 BCNF odpravlja anomalije, ki so posledica
funkcionalnih odvisnosti.
 Obstajajo tudi več-vrednostne odvisnosti (MVD),
ki prav tako povzročajo anomalije oziroma
podatkovno redundanco.
 Razlog, da v relaciji lahko obstajajo MVD, je
predvsem posledica pravil 1NF, ki ne dopuščajo
večvrednostnih atributov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 142 -
Več-vrednostne odvisnosti...
Večvrednostni
atributi
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 143 -
Več-vrednostne odvisnosti...
 Več-vrednostna odvisnost:
– je odvisnost med atributi (na primer A, B in C) v relaciji, za
katero velja, da za vsako vrednost A obstaja množica
vrednosti za B in množica vrednosti za C, množici vrednosti
za B in C pa sta med seboj popolnoma neodvisni.
 Več-vrednostne odvisnosti med A, B in C
zapišemo takole:
–
–
A −>> B
A −>> C
Med člani laboratorija in nosilci
projektov v laboratoriju ni nobene
povezave. Relacija realizira dve
povezavi tipa 1:*
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Laboratorij
Član
Nosilec projekta
LINF
Mitja Mali
Matej Mraz
LINF
Matej Hribar
Matej Mraz
LINF
Mitja Mali
Rok Lavbič
LINF
Matej Hribar
Rok Lavbič
- 144 -
Več-vrednostne odvisnosti...
 Več-vrednostne odvisnosti delimo na trivialne in
netrivialne.
 MVD A −>> B v relacijski shemi R je trivialna,
če:
– B  A ali
– A  B = R.
 Če noben izmed pogojev ni izpolnjen, je MVD
netrivialna.
 Netrivialna MVD določa omejitev nad relacijo;
povzroča anomalije pri spreminjanju.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 145 -
4NO – četrta normalna oblika
 Relacija s shemo R je v 4NO, če velja:
– R je definirana kot relacija, ki ustreza pravilom BCNO in
– R ne vsebuje nobenih netrivialnih več-vrednostnih
odvisnosti.
Ali z drugimi besedami:
 Relacija je v 4NO, če je za vsako v njej veljavno
odvisnost X –>> Y izpolnjen vsaj eden izmed
naslednjih pogojev:
– X –>> Y je trivialna odvisnost
– X je superključ sheme R
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 146 -
Primer – pretvorba v 4NO
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Laboratorij
Član
Nosilec
projekta
LINF
Mitja Mali
Matej Mraz
LINF
Matej Hribar
Matej Mraz
LINF
Mitja Mali
Rok Lavbič
LINF
Matej Hribar
Rok Lavbič
Laboratorij
Član
LINF
Mitja Mali
LINF
Matej Hribar
- 147 -
Laboratorij
Nosilec
projekta
LINF
Matej Mraz
LINF
Rok Lavbič
Neizgubni stik
 Pri dekompoziciji relacije v podrelacije ne smemo
izgubiti podatkov!
 Obstajati mora neizgubni stik, to je stik, pri
katerem iz dekomponiranih relacij dobimo nazaj
osnovno relacijo, brez da bi se pri tem izgubila ali
dodala kakšna n-terica.
 Če relacijsko shemo R dekomponiramo v   {R1,
R2,..., Rn}, mora veljati enačba za neizgubni stik:
r = R1(r)  R2(r) ... Rn(r)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 148 -
Stične odvisnosti
 Stična odvisnost (R1, R2,..., Rn) nad shemo R
omejuje možna stanja r v shemi R.
 Omejitev določa, da mora imeti vsako legalno
stanje r neizgubno stično dekompozicijo v R1, R2,
…, Rn.
r = R1(r)  R2(r) ... Rn(r)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 149 -
5NO – peta normalna oblika
 Relacija s shemo R je v 5NO, če v njej ni nobenih
stičnih odvisnosti.
Ali z drugimi besedami:
 Relacija je v 5NO, če je za vsako v njej veljavno
odvisnost (R1, R2,..., Rn) izpolnjen vsaj eden
izmed naslednjih pogojev:
– (R1, R2,..., Rn) je trivialna odvisnost
– Vsak Ri, ki nastopa v stični odvisnosti, je superključ sheme R
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 150 -
Primer – pretvorba v 5NO...
Oprema, ki jo potrebujejo oddelki ter dobavitelji opreme
Oddelek
Oprema
Dobavitelj
L1
Tiskalnik
S1
L1
Tipkovnica
S2
Oddelki potrebujejo opremo. Opremo nabavljajo pri dobaviteljih.
Ko oddelek potrebuje neko opremo, jo lahko dobi od dobavitelja D,
če ta dobavlja tako opremo in če dobavlja temu oddelku (je že dobavil
vsaj en kos opreme temu oddelku).
Primer: v oddelku UI2 potrebujejo tiskalnik. Dobavitelj S2 dobavlja oddelku
UI2. Ker S2 obenem dobavlja tudi tiskalnike, lahko tiskalnik dobavi tudi
oddelku UI2.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 151 -
Primer – pretvorba v 5NO...
Oddelek
Oprema
Dobavitelj
1
L1
Tiskalnik
S1
2
L1
Tipkovnica
S2
3
UI2
Tiskalnik
S2
4
L1
Tiskalnik
S2
Če dodamo vrstico 3 (oddelek UI2 potrebuje tiskalnik. Dobavitelj za UI2
je S2, ki dobavlja tudi tiskalnike) moramo zaradi doslednosti dodati
tudi vrstico 4, v kateri zapišemo, da tudi za L1 lahko tiskalnik dobavi
dobavitelj S2 .
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 152 -
Primer – pretvorba v 5NO
 Relacijo razbijemo v pod-relacije:
Oddelek
Oprema
Dobavitelj
1
L1
Tiskalnik
S1
2
L1
Tipkovnica
S2
3
UI2
Tiskalnik
S2
4
L1
Tiskalnik
S2
Potrebe po opremi
Dobavitelji za opremo
Dobavitelji za oddelke
Oddelek
Oprema
Oprema
Dobavitelj
Oddelek
Dobavitelj
L1
Tiskalnik
Tiskalnik
S1
L1
S1
L1
Tipkovnica
Tipkovnica
S2
L1
S2
UI2
Tiskalnik
Tiskalnik
S2
UI2
S2
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 153 -
Metoda logičnega načrtovanja...
 Možni koraki logičnega načrtovanja:
–
–
–
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
K2.1:
K2.2:
K2.3:
K2.4:
K2.5:
K2.6:
K2.7:
Za entitetne tipe kreiraj relacije
Preveri relacije z normalizacijo
Preveri relacije s pregledom uporabniških transakcij
Preveri omejitve integritete
Preveri model z uporabnikom
Združi lokalne modele v globalni model (opcijsko)
Preveri zmožnosti modela za razširitve
- 154 -
K2.1 – Za entitetne tipe kreiraj relacije...
 Namen
– Izdelati relacije za logični model, ki bo predstavljal entitete,
povezave in atribute, ki smo jih identificirali v okviru
konceptualnega modeliranja.
 Ta korak je navadno avtomatiziran  pretvorba
iz konceptualnega v logični model je podprta s
strani številnih CASE orodij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 155 -
K2.1 – Za entitetne tipe kreiraj relacije...
 Ročna pretvorba:
– Močni entitetni tipi
Enolični identifikator sestavljajo le atributi
entitete (identifikacijski atributi)
 Za vsak močan entitetni tip kreiraj relacijo, ki vključuje vse
enostavne atribute tega entitetnega tipa. Namesto sestavljenih
atributov vključi njihove atribute, ki jih sestavljajo.
– Šibki entitetni tipi
 Za vsak šibki entitetni tip kreiraj relacijo, ki vključuje vse enostavne
atribute tega entitetnega tipa. Primarni ključ šibkega entitetnega
tipa je delno ali v celoti sestavljen iz atributov, ki so ključ v
entitetnih tipih, s katerimi je opazovani entitetni tip povezan. Da bi
lahko določili ključ, moramo najprej pretvoriti vse povezave.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 156 -
Primer: močni in šibki entitetni tipi
Študent
EMŠO
VpisSt
DavcnaSt
Ime
Priimek
DtmRoj
Naslov
Predmet
Izpit
1..1
je opravil
0..*
Datum
Ocena
0..*
za
1..1
Predmet
Opis
StUr
Letni
šibki entitetni tip
Sestavljene atribute
razbijemo
Študent(EMŠO, VpisSt, DavcnaSt, Ime, Priimek, DtmRoj, Ulica, Mesto)
Predmet(Predmet, Opis, StUr, Letni)
Izpit(Datum, #VpisSt, #Predmet, Ocena)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 157 -
K2.1 – Za entitetne tipe kreiraj relacije...
 Ročna pretvorba (nadaljevanje):
– Povezave 1:*
 Za vsako povezavo 1:* prenesi ključ entitetnega tipa, ki nastopa v
povezavi na strani 1 (oče) v entitetni tip, ki nastopa v povezavi na
strani * (otrok). Dobimo tuji ključ.
– Povezave 1:1
 Pri števnosti 1:1 ne moremo vedno enostavno določiti očeta in
otrok. Za odločitev, ali bomo entitetna tipa, ki sta povezana s
povezavo 1:1, povezali v eno relacijo ali ju predstavili z dvema,
preverimo predvsem, kako je z obveznostjo povezav. Možne
omejitve so: obveznost na obeh straneh, neobveznost na eni in
obveznost na drugi, neobveznost na obeh straneh.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 158 -
K2.1 – Za entitetne tipe kreiraj relacije...
 Ročna pretvorba (nadaljevanje):
– Povezave 1:1 (nadaljevanje...)
 Obveznost na obeh straneh 1:1 povezave
– Entitetna tipa združi v eno relacijo. Za primarni ključ izberi enega
izmed primarnih ključev originalnih entitetnih tipov.
 Obveznost na eni strani 1:1 povezave
– Entitetni tip, ki ni obvezen v povezavi, naj bo oče, entitetni tip z
obvezno povezavo pa naj bo otrok. Kopija primarnega ključa
entitetnega tipa očeta se prenese na entitetni tip otroka.
 Neobvezna povezava na obeh straneh 1:1 povezave
– V primerih, ko sta oba entitetna tipa neobvezna, je težko določiti
očeta in otroka povezave. Ko pridobimo dovolj podatkov, določimo
ključ.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 159 -
Primer: povezave 1:*
Študent
EMŠO
VpisSt
DavcnaSt
Ime
Priimek
DtmRoj
Naslov
Diploma
1..1
je opravil
1..*
Datum
Ocena
Študent(EMŠO, VpisSt, DavcnaSt, Ime, Priimek, DtmRoj, Ulica, Mesto)
Diploma(Datum, #VpisSt, Ocena)
Prenos tujega ključa v smeri ena “proti mnogo”
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 160 -
Primer: povezave 1:1
Dekan
ID
Ime
Priimek
Fakulteta
1..1
vodi
1..1
Fakulteta
Naziv
Dekan(ID, Ime, Priimek, Naziv_fakultete)
Obveznost na obeh straneh:
entitetna tipa predstavimo z eno relacijo; izberemo ključ
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 161 -
Primer: povezave 1:1
oče
Profesor
ID
Ime
Priimek
Fakulteta
1..1
je dekan
0..1
Fakulteta
Naziv
Fakulteta(Fakulteta, Naziv, #ID)
Profesor(ID, Ime, Priimek)
Obveznost na eni strani:
entitetni tip, ki igra vlogo očeta, dobi tuji ključ  primarni ključ
drugega entitetnega tipa v povezavi se prenese.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 162 -
K2.1 – Za entitetne tipe kreiraj relacije...
 Ročna pretvorba (nadaljevanje):
– Rekurzivne povezave 1:1
 Pri rekurzivnih povezavah tipa 1:1 upoštevaj pravila, ki izhajajo iz
obveznosti povezav.
– Obveznost na obeh straneh: rekurzivno povezavo predstavi z eno
relacijo in dvema kopijama primarnega ključa.
– Obveznost na eni, neobveznost na drugi strani: kreiraj eno relacijo
z dvema kopijama primarnega ključa ali kreiraj novo relacijo. Nova
relacija naj ima samo dva atributa – kopiji primarnega ključa.
– Neobveznost na obeh straneh: kreiraj novo relacijo. Nova relacija
naj ima samo dva atributa – kopiji primarnega ključa.
– Kopije primarnih ključev je v rekurzivnih povezavah potrebno
ustrezno poimenovati, da lahko ločimo med njimi!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 163 -
Primer: rekurzivne povezave
je mentor
1..1
PDelavec
ID
Ime
Priimek
Naziv
0..*
PDelavec(ID, Ime, Priimek, Naziv, IDmentorja)
Obveznost na eni strani:
kreiramo relacijo z dvema kopijama primarnega ključa. Eden igra
vlogo primarnega drugi pa tujega ključa.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 164 -
Primer: rekurzivne povezave
je mentor
1..1
PDelavec
ID
Ime
Priimek
Naziv
0..*
PDelavec(ID, Ime, Priimek, Naziv)
Mentor(#IDmentorja, #IDdelavca)
Obveznost na eni strani:
Rekurzivno povezavo pretvorimo v relacijo. Relacija za vsakega pedagoškega
delavca pove, kdo mu je (bil) mentor.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 165 -
K2.1 – Za entitetne tipe kreiraj relacije...
 Ročna pretvorba (nadaljevanje):
– Povezave med nadtipi in podtipi
 Identificiraj nadtipe kot očete ter podtipe kot otroke. Obstajajo
različne možnosti, kako takšne povezave predstaviti z relacijami.
 Izbira najbolj ustrezne opcije je odvisna od številnih faktorjev:
izključevanje, obveznost povezav, število entitet v povezavi....
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 166 -
Primer: nadtipi, podtipi
PREVOZNO SREDSTVO
Registrska št.
Datum izdelave
Datum registracije
Moč motorja
Barva
Št. motorja
x
OSEBNI AVTO
TOVORNO VOZILO
Št. sedežev
Kilovati
Vrsta motorja
Povprečna poraba
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Tip specializacije
Nosilnost
Tip
- 167 -
K2.1 – Za entitetne tipe kreiraj relacije...
 Ročna pretvorba (nadaljevanje):
– Povezave *:*
 Kreiraj relacijo, ki predstavlja povezavo ter vse njene atribute.
Primarne ključe entitetnih tipov, ki sta povezana s tako povezavo,
vključi v novo relacijo kot tuji ključ. Tuji ključi bodo obenem tudi
primarni ključi – samostojno ali v kombinaciji z drugimi atributi
relacije.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 168 -
Primer: povezave *:*
Študent
EMŠO
VpisSt
DavcnaSt
Ime
Priimek
DtmRoj
Naslov
Predmet
0..*
je opravil
0..*
Predmet
Opis
StUr
Letni
Študent(EMŠO, VpisSt, DavcnaSt, Ime, Priimek, DtmRoj, Ulica, Mesto)
Predmet(Predmet, Opis, StUr, Letni)
Izpit(Datum, #VpisSt, #Predmet, Ocena)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 169 -
K2.1 – Za entitetne tipe kreiraj relacije
 Ročna pretvorba (nadaljevanje):
– Več-vrednostni atributi
 Za predstavitev več-vrednostnih atributov kreiraj novo relacijo. V
novo relacijo vključi tudi ključ entitetnega tipa, iz katerega izhajajo
več-vrednostni atributi. V novi relaciji predstavlja tuji ključ.
Primarni ključ v novi relaciji je kombinacija tujega ključa in večvrednostnih atributov. Če več-vrednostni atributi sami predstavljajo
kandidata za ključ, potem ni potrebno, da primarni ključ zajema
tudi tuji ključ.
 Če je število vrednosti za večvrednostni atribut znano in ni veliko
(npr. je manjše d 5), lahko tak atribut predstavimo z več atributi v
relaciji. Za vsako vrednost svoj atribut.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 170 -
Primer: večvrednostni atributi…
Študent
VpisSt
Ime
Priimek
DtmRoj
Naslov
Telefon
Študent(VpisSt, Ime, Priimek, DtmRoj, Mesto, Ulica, GSM, StcTelefon)
Večvrednostni atribut:
Število vrednosti za Telefon je znano, zato za vsako določimo svoj atribut v
isti relaciji.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 171 -
Primer: večvrednostni atributi…
Konferenca
ID
Datum
NazivKonf
Kraj
Sponzor
Konferenca(ID, Datum, NazivKonf, Kraj)
Sponzor(Sponzor, Naziv)
SponzorKonference(#ID, #Sponzor)
Večvrednostni atribut:
Število vrednosti za atribut sponzor ni znano, zato kreiramo novi relaciji.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 172 -
K2.2 – Preveri relacije z normalizacijo...
 Namen tega koraka je preveriti, če so vse
pridobljene relacije v ustrezni normalni obliki. To
zagotavlja:
– Da imajo relacije minimalno, vendar zadostno število
atributov za potrebe problemske domene;
– Da ni odvečnih podatkov (razen za potrebe povezovanja)
 Prevedba konceptualnega modela v logični model
navadno da relacije, ki ustrezajo 3NO.
– Če to ne drži, so v konceptualnem modelu ali v postopku
prevedbe napake.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 173 -
K2.2 – Preveri relacije z normalizacijo...
 Včasih se zdi, da normalizirane relacije ne
omogočajo zadovoljive učinkovitosti podatkovne
baze.
 Upoštevati je potrebno:
– V normaliziranih relacijah so podatki organizirani v skladu s
funkcionalnimi odvisnostmi.
– Logični podatkovni model ni dokončen. Predstavlja le, kako
načrtovalec razume pomen in naravo podatkov, potrebnih za
obravnavano problemsko domeno; Specifične potrebe v
zvezi z učinkovitostjo lahko zahtevajo drugačen fizični
model.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 174 -
K2.2 – Preveri relacije z normalizacijo
 Upoštevati je potrebno (nadaljevanje):
– Normaliziran načrt je robusten in odporen na podatkovne
anomalije.
– Moderni računalniki so veliko zmogljivejši  včasih je
upravičeno uporabiti rešitve, ki omogočajo enostavnejšo
obdelavo na račun več procesiranja.
– Normalizacija načrtovalca prisili, da se natanko spozna z
vsakim atributom relacije.
– Z normalizacijo pridemo do fleksibilnega načrta, ki ga brez
težav razširimo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 175 -
K2.3 – Preveri relacije z vidika transakcij
 Podobno kot konceptualni model preverimo tudi
logični model z vidika podpore transakcij, ki jih
uporabnik specificira (glej K1.8).
 Če vseh transakcij ni moč izvesti ročno, smo pri
pretvorbi naredili napako, ki jo je potrebno
odpraviti.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 176 -
K2.4 – Preveri omejitve integritete...
 V tem koraku preverimo pravila za zagotavljanje
celovitosti podatkov:
–
–
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Obveznost atributov
Omejitve domen atributov
Števnost
Omejitve entitet (celovitost entitet)
Omejitve povezav (celovitost povezav)
Splošne omejitve
- 177 -
Primeri omejitev povezav
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 178 -
K2.5 – Preveri model z uporabnikom...
 Namen tega koraka je preveriti model z
uporabnikom ter ugotoviti, če ustreza vsem
uporabniškim zahtevam.
 Model lahko zajema več uporabniških pogledov.
Pri pregledu lahko nastopa več uporabnikov.
 Odličen način za pregled celovitosti
podatkovnega modela je specifikacija
podatkovnih tokov s pomočjo diagrama
podatkovnih tokov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 179 -
Povezava podatkovni model in DFD
DFD
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
PM
- 180 -
K2.6 – Združi lokalne modele...
 Namen tega koraka je združiti vse lokalne
modele v en globalni model, ki predstavlja vse
uporabniške vidike podatkovne baze.
 Čeprav so lokalni modeli preverjeni, lahko pri
njihovem združevanju pride do prekrivanja in
neskladnosti.
 Globalni model preverim podobno kot smo
preverjali lokalne modele.
 Če pri načrtovanju nismo zajeli več uporabniških
vidikov, lahko korak preskočimo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 181 -
K2.6 – Združi lokalne modele
 Pri združevanju lokalnih modelov uporabimo
naslednje korake:
– K2.6.1 – Lokalne modele združi v globalni model
– K2.6.2 – Preveri globalni model
– K2.6.3 – Globalni model preveri z uporabniki
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 182 -
Pravila združevanja lokalnih modelov...
 Pravila združevanja lokalnih modelov:
– Preveri imena in vsebino relacij ter njihove kandidate za
ključ.
– Preveri imena in vsebino povezav in tujih ključev.
– Združi relacije z lokalnih podatkovnih modelov
– Brez združevanja vključi relacije, ki so unikatne v
posameznih podatkovnih modelih.
– Združi povezave in tuje ključe z lokalnih podatkovnih
modelov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 183 -
Pravila združevanja lokalnih modelov
 Pravila združevanja lokalnih modelov
(nadaljevanje):
– Brez združevanja vključi povezave in tuje ključe, ki so
unikatni v posameznih podatkovnih modelih.
– Preveri, če morda manjkajo relacije, povezave in tuji ključi.
– Preveri tuje ključe.
– Preveri pravila za zagotavljanje celovitosti podatkov.
– Nariši globalni podatkovni model.
– Ažuriraj dokumentacijo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 184 -
Primer
Primer
uporabniškega
pogleda
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 185 -
Primer
Primer
globalnega
logičnega
podatkovnega
modela.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 186 -
K2.7 – Preveri možnosti za razširitve...
 V primeru, da so predvidene bodoče razširitve
sistema, moramo preveriti, če logični model take
razširitve podpira.
 Podatkovni model mora biti prilagodljiv;
omogočati mora razširitve skladno z novimi
zahtevami ter z minimalnim vplivom na obstoječe
uporabnike.
 Popolnoma odprt sistem za razširitve je težko
doseči.
 Pravilo agilnega načrtovanja:
– Fool me once, shame on you, fool me twice, shame on me!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 187 -
Načrtovanje fizične podatkovne baze...
 Načrtovanje fizične PB je korak, ki sledi
logičnemu načrtovanju.
 Logični načrt opredeljuje “kaj”, fizični načrt pa
“kako”.
 Vhod v načrtovanje fizične PB so:
– Logični podatkovni model,
– Relacijska shema
– dokumentacija
svet
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
mentalni model
konceptualni model
- 188 -
logični model
PB
Načrtovanje fizične podatkovne baze...
Konceptualni
PM
Odločitev o PB:
-Relacijska
-Hierarhična
-Objektna
i-CASE
Logični PM
Fizični PM
(skripta)
Načrtovanje fizične PB
Reverse Engineering
SUPB
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
Podatkovna
baza
- 189 -
ODBC
Načrtovanje fizične podatkovne baze
 Fizično načrtovanje PB opredeljuje proces, s
katerim izdelamo opis implementacije PB na
sekundarnem pomnilnem mediju.
 Opisuje
–
–
–
–
–
PODATKOVNE BAZE
3. letnik UNI, Informatika
©Laboratorij za informatiko
osnovne relacije,
datotečno organizacijo,
indekse za dosego učinkovitega dostopa do podatkov,
povezane omejitve in
varnostne mehanizme.
- 190 -
Metoda načrtovanja fizične PB...
 Možni koraki načrtovanja fizične PB:
– K3 – Pretvori logični model v jezik za ciljni SUPB
 K3.1 – Izdelaj načrt osnovnih relacij
 K3.2 – Izdelaj načrt predstavitve izpeljanih atributov
 K3.3 – Izdelaj načrt splošnih omejitev
– K4 – Izdelaj načrt datotečne organizacije ter indeksov




K4.1
K4.2
K4.3
K4.4
–
–
–
–
Analiziraj transakcije
Izberi datotečno organizacijo
Določi indekse
Oceni velikost podatkovne baze
Koraka K1 in K2 se nanašata na izdelavo konceptualnega in
logičnega podatkovnega modela
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 191 -
Metoda načrtovanja fizične PB...
 Možni koraki načrtovanja fizične PB
(nadaljevanje):
– K5 – Izdelaj načrt uporabniških pogledov
– K6 – Izdelaj načrt varnostnih mehanizmov
– K7 – Preveri smiselnost uvedbe nadzorovane redundance
podatkov (denormalizacija)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 192 -
K3 – Pretvorba v jezik za SUPB
 Namen koraka: iz logičnega modela izdelati
podatkovno shemo za ciljni SUPB.
 Poznati moramo funkcionalnosti ciljnega SUPB,
npr.:
–
–
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Kako izdelati osnovne relacije?
Ali ciljni SUPB podpira primarne, tuje in alternativne ključe?
Ali podpira obveznost podatkov (NOT NULL)?
Ali podpira domene?
Ali podpira pravila omejitve podatkov?
Ali podpira sprožilce (triggers) in bazne programe (stored
procedures)?
- 193 -
K3.1 – Izdelava osnovnih relacij...
 Namen: določiti, kako bodo osnovne relacije
predstavljene v ciljnem SUPB.
 Vir podatkov je podatkovni slovar, jezik za opis
pa DBDL (database definition language)
 Za vsako relacijo definiramo:
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Naziv relacije;
Listo osnovnih atributov;
Primarni ključ ter kjer smiselno alternativne in tuje ključe;
Omejitve povezav.
- 194 -
K3.1 – Izdelava osnovnih relacij
 V podatkovnem slovarju imamo za vsak atribut :
– Domeno, ki se sestoji iz podatkovnega tipa, dolžine in
omejitev domene;
– Morebitno privzeto vrednost;
– Podatek o obveznosti atributa;
– Podatek, ali je atribut izpeljan in če je, kako ga izračunamo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 195 -
Primer opisa osnovnih relacij z DBDL
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 196 -
K3.2 – Predstavitev izpeljanih atributov...
 Namen: določiti, kako bodo v SUPB predstavljeni
izpeljani atributi.
 Preuči logični podatkovni model in podatkovni
slovar; izdelaj seznam izpeljanih atributov.
 Za vsak izpeljani atribut določi:
– Atribut je shranjen v podatkovni bazi
– Atribut se vsakokrat posebej izračuna in se ne hrani v
podatkovni bazi.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 197 -
K3.2 – Predstavitev izpeljanih atributov...
 Pri odločitvi, kako predstaviti izpeljane atribute,
upoštevaj:
– “strošek” shranjevanja in vzdrževanja skladnosti izpeljanih
atributov z osnovnimi atributi, iz katerih je izpeljan;
– “strošek” vsakokratnega izračunavanja izpeljanega atributa.
 Izberi stroškovno ugodnejšo rešitev.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 198 -
Primer hranjenja izpeljanega atributa
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 199 -
K3.3 – Načrt splošnih omejitev
 Namen: izdelava načrta splošnih omejitev za
ciljni SUPB.
 Glede podpore splošnim omejitvam obstajajo
velike razlike med SUPB-ji.
 Primer splošne omejitve:
CONSTRAINT StaffNotHandlingTooMuch
CHECK (NOT EXISTS (SELECT staffNo
FROM PropertyForRent
GROUP BY staffNo
HAVING COUNT(*) > 100))
Pomen omejitve: nihče od zaposlenih ne sme skrbeti za več
kot 100 nepremičnin
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 200 -
K4 – Datotečna organizacija in indeksi
 Namen: izbrati optimalno datotečno organizacijo
za shranjevanje osnovnih relacij ter potrebne
indekse za doseganje ustrezne učinkovitosti.
 Načrtovalec mora dobro poznati, kakšne
strukture in organizacije SUPB podpira ter kako
deluje.
 Ključnega pomena so uporabniške zahteve v
zvezi z želeno/pričakovano učinkovitostjo
transakcij.
 Med SUPB-ji velike razlike.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 201 -
K4.1 – Analiza transakcij...
 Namen: razumeti namen transakcij, ki bodo tekle
na SUPB ter analizirati tiste, ki so
najpomembnejše.
 Poskušaj določiti kriterije učinkovitosti:
– Pogoste transakcije, ki imajo velik vpliv na učinkovitost;
– Transakcije, ki so kritičnega pomena za poslovanje;
– Pričakovana obdobja (v dnevu/ tednu), ko bo SUPB najbolj
obremenjen (peak load).
 Preveri tudi:
– Atribute, ki jih transakcije spreminjajo
– “Iskalne” pogoje v transakcijah...
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 202 -
K4.1 – Analiza transakcij...
 Pogosto ni moč analizirati vseh transakcij.
Pregledamo zgolj najpomembnejše.
 Za identifikacijo najpomembnejših transakcij
lahko uporabimo:
– Matriko transakcija/relacija, ki kaže, katere relacije se v
transakcijah uporabljajo.
– Diagram uporabe transakcij, ki kaže, katere transakcije bodo
potencialno zelo frekventno izvajane.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 203 -
K4.1 – Analiza transakcij...
 Možen pristop k obravnavi potencialno
problematičnih delov modela:
– Izdelamo matriko povezav transakcija/relacija,
– Ugotovimo, katere relacije se najpogosteje uporabljajo v
transakcijah,
– Analiziramo, kateri podatki se uporabljajo v transakcijah, ki
te relacije uporabljajo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 204 -
Primer matrike transakcija/relacija
Dodatno lahko zapišemo število
operacij na časovno enoto
F: Identify the total number of properties assigned to each member of staff at a given
branch.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 205 -
Primer diagrama uporabe transakcij
V specifikaciji zahtev je ocenjeno:
• 100.000 nepremičnin;
• 2.000 zaposlenih v 100 agencijah;
• Vsaka agencija ima od 1.000 do 3.000 nepremičnin
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 206 -
Obrazec za podrobno analizo transakcij
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 207 -
K4.2 – Izbira datotečne organizacije
 Namen: izbrati učinkovito datotečno organizacijo
za vse osnovne relacije.
 Datotečne organizacije:
– Kopica (Heap),
– Hash,
– Metoda indeksiranega zaporednega dostopa (Indexed
Sequential Access Method - ISAM),
– Drevo B+– Gruča (Cluster).
 Nekateri SUPB-ji ne podpirajo vseh datotečnih
organizacij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 208 -
K4.3 – Izbira indeksov...
 Namen: ugotoviti, ali lahko z dodatnimi indeksi
povečamo učinkovitost sistema.
 Možen pristop:
– Zapise pustimo neurejene.
– Izdelamo toliko sekundarnih indeksov, kolikor je potrebno.
Sekundarni indeks = indeks po atributu, ki ni obenem tudi atribut,
po katerem je urejena relacija
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 209 -
K4.3 – Izbira indeksov...
 Alternativni pristop
– Zapise uredimo po primarnem ključu ali po indeksu gruče. V
tem primeru kot atribut za sortiranje izberemo:
 Atribut, ki se največkrat uporablja za povezovanja ali
 Atribut, ki se najpogosteje uporablja za dostop do podatkov v
relaciji.
 Če je izbrani atribut za sortiranje primarni ključ, potem gre za
primarni indeks sicer za indeks gruče.
– Relacija ima lahko primarni indeks ali indeks gruče
Primarni indeks = indeks po primarnem ključu, po katerem je urejena relacija.
Vsak zapis ima svojo vrednost.
Indeks gruče = indeks po atributu, ki je obenem tudi atribut, po katerem je
urejena relacija, ni pa primarni ključ. Ključ ni unikaten!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 210 -
K4.3 – Izbira indeksov...
 Sekundarni indeksi so način, kako omogočiti
učinkovito iskanje s pomočjo dodatnih ključev.
 Pri določanju sekundarnih indeksov upoštevamo:
– Povečanje učinkovitosti (predvsem pri iskanju po PB)
– Dodatno delo, ki ga mora sistem opravljati za vzdrževanje
indeksov. To vključuje:
 Dodajanje zapisa v vsak sekundarni indeks, kadarkoli dodamo nek
zapis v osnovno relacijo
 Spreminjanje sekundarnega indeksa vsakokrat, ko se osnovna
relacija spremeni
 Povečanje porabe prostora v sekundarnem pomnilniku
 Povečanje časovnega obsega za optimizacijo poizvedb zaradi
preverjanja vseh sekundarnih indeksov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 211 -
K4.3 – Izbira indeksov...
 Nekaj smernic za uporabo sekundarnih indeksov:
– Ne indeksiraj majhnih relacij.
– Če datoteka ni urejena po primarnem ključu, potem kreiraj
indeks na osnovi primarnega ključa.
– Če je tuji ključ pogosto v uporabi, dodaj sekundarni indeks
na tuji ključ.
– Sekundarni indeks dodaj vsakemu atributu, ki se pogosto
uporablja kot sekundarni ključ.
– Sekundarne indekse dodaj atributom, ki nastopajo v pogojih
za selekcijo ali stik: ORDER BY; GROUP BY ali v drugih
operacijah, ki vključujejo sortiranje (npr. UNION ali
DISTINCT).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 212 -
K4.3 – Izbira indeksov
 Nekaj smernic za uporabo sekundarnih indeksov:
(nadaljevanje):
– Dodaj sekundarni indeks atributom, ki nastopajo v vgrajenih
funkcijah;
– Izogibaj se indeksiranju atributov, ki se pogosto spreminjajo.
– Izogibaj se indeksiranju atributov v relacijah, nad katerimi se
bodo pogosto izvajale poizvedbe, ki bodo vključevale večji
del zapisov.
– Izogibaj se indeksiranju atributov, ki so predstavljeni z
daljšimi stringi.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 213 -
K4.4 – Ocena velikosti podatkovne baze
 Namen: oceniti, koliko prostora v sekundarnem
pomnilniku zahteva načrtovana podatkovna baza.
 Ocena je odvisna
– od velikosti in števila zapisov ter
– od ciljnega SUPB.
 Primer: ocena velikosti podatkovne baze s
pomočjo orodja PowerDesigner.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 214 -
K5 – Načrt uporabniških pogledov
 Namen: izdelati načrt uporabniških pogledov, ki
so bili opredeljeni v okviru zajema uporabniških
zahtev.
 Uporabimo mehanizem pogledov (view).
 Pogled je navidezna relacija, ki fizično ne obstaja
v PB, temveč se vsakokratno kreira s pomočjo
poizvedbe.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 215 -
Primer pogleda
Pedagoški delavec
Pedagog
Vrsta PD
Laboratorij
Ime
Priimek
Status
<pk>
<fk>
<fk>
Predmet
Nosilec = Pedagog
Asistent = Pedagog
<fk>
Predmet
Smer
Nosilec
Asistent
Naziv
StUr
<pk>
<fk>
<fk>
<fk>
create or replace view OBREMENITEV as
Select PMET.PEDAGOG as Predavatelj,
(PDG.PRIIMEK + PDG.IME) as Naziv_predavatelja,
count(*) as Stevilo_Predmetov,
sum(PMET.STUR) as Stevilo_ur_tedensko
from PREDMET as PMET, PEDAGOŠKI DELAVEC as PDG
where PMET.NOSILEC = PDG.PEDAGOG
group by PMET.NOSILEC, (PDG.PRIIMEK + PDG.IME); Obremenitev
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 216 -
Predavatelj
Naziv_predavatelja
Stevilo_Predmetov
Stevilo_ur_tedensko
K6 – Načrt varnostnih mehanizmov
 Namen: izdelati načrt varnostnih mehanizmov
skladno z zahtevami naročnika.
 SUPB-ji tipično podpirajo dve vrsti varnosti:
– Sistemsko varnost: varnost dostopa in uporabe podatkovne
baze (navadno zagotovljeno s pomočjo uporabniških imen in
gesel);
– Podatkovno varnost: varnost uporabe podatkov – kdo lahko
uporablja določene relacije ter kako.
 Med SUPB-ji so velike razlike v mehanizmih, ki jih
imajo na voljo za dosego varnosti.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 217 -
K7 – Uvedba nadzorovane redundance...
 Namen: ugotoviti, ali je smiselno dopustiti
določeno mero redundance (denormalizacija) ter
tako izboljšati učinkovitost.
 Rezultat normalizacije je načrt, ki je po strukturi
konsistenten ter minimalen.
 Včasih normalizirane relacije ne dajo zadovoljive
učinkovitosti.
 Razmislimo, ali se zavoljo izboljšanja učinkovitosti
odpovemo določenim koristim, ki jih prinaša
normalizacija.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 218 -
K7 – Uvedba nadzorovane redundance...
 Upoštevamo tudi:
– Implementacija denormaliziranih relacij je težja;
– Z denormalizacijo velikokrat zgubimo na prilagodljivosti
modela;
– Denormalizacija navadno pospeši poizvedbe, vendar
upočasni spreminjanje podatkov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 219 -
K7 – Uvedba nadzorovane redundance...
 Denormalizacija:
– Denormaliacija se nanaša na dopolnitev relacijske sheme,
tako da eni ali več relacij znižamo stopnjo normalne oblike
(npr. 3NO  2NO).
– Nanaša se tudi na primere, ko dve normalizirani relaciji
združimo v eno, ki je še vedno normalizirana, vendar zaradi
združitve vsebuje več nedefiniranih vrednosti (NULL).
(4PNO  3NO).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 220 -
K7 – Uvedba nadzorovane redundance...
 Koraki denormalizacije:
– K7.1 – združevanje 1:1 povezav
– K7.2 – Podvajanje neosnovnih atributov v povezavah 1:* za
zmanjšanje potrebnih stikov.
– K7.3 – Podvajanje tujih ključev v 1:* povezavah za
zmanjšanje potrebnih stikov.
– K7.4 – Podvajanje atributov v *:* povezavah za zmanjšanje
potrebnih stikov.
– K7.5 – Uvedba ponavljajočih skupin atributov
– K7.6 – Kreiranje tabel, ki predstavljajo izvleček osnovne
tabele.
– K7.7 – Razbitje relacij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 221 -
Primer normaliziranega modela
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 222 -
Primeri relacij
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 223 -
K7.1 – Združevanje 1:1 povezav
Če podatke, ki so v različnih
relacijah obravnavamo skupaj,
je združitev primerna.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 224 -
K7.2 – Podvajanje neosnovnih atributov
Ko dostopamo do podatkov o nepremičninah, nas v večini
primerov zanima tudi ime lastnika (IName)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 225 -
“Lookup Tabele”...
LookUp tabele se sestoje zgolj iz šifre in naziva. Prednosti
uporabe LookUp tabel so mnoge. Vseeno obstajajo primeri,
ko je smiselno (LookUp tabele ukiniti in) podatke podvajati
v osnovnih relacijah. Taki primeri so:
•Ko se do LookUp tabele frekventno dostopa
•Ko so LookUp tabele uporabljene v kritičnih poizvedbah
•Ko je majhna verjetnost, da se bodo po vrednosti spreminjale
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 226 -
“Lookup tabele”
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 227 -
K7.3 - Podvajanje tujih ključev
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 228 -
K7.4 - Podvajanje atributov v povez. *:*
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 229 -
K7.5 - Uvedba ponavljajočih skupin
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 230 -
K7.6 – Uporaba izvlečkov
 Številne poizvedbe in poročila zahtevajo dostop
do več osnovnih relacij ter kompleksne povezave
med njimi.
 Z namenom izboljšanja učinkovitosti je v
določenih primerih smiselno uvesti novo
denormalizirano relacijo, ki vsebuje podatke z več
osnovnih relacij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 231 -
K7.7 – Razbitje relacij
 Za povečanje učinkovitosti nad relacijami z zelo
velikim številom n-teric uporabimo pristop, kjer
relacijo razbijemo na manjše dele - particije.
 Dva načina delitve sta:
– Horizontalni in
– Vertikalni.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 232 -
Prednosti razbitja relacije na particije
 Uporaba particioniranja prinaša številne
prednosti:
– Boljša porazdelitev vnosa (load balancing)
– Večja učinkovitosti (manj podatkov za obdelavo, paralelnost
izvajanja,...)
– Boljša razpoložljivost
– Boljša obnovljivost
– Več možnosti za zagotavljanje varnosti
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 233 -
Slabosti razbitja relacije na particije
 Particioniranje ima tudi slabosti:
– Kompleksnost (particije niso vedno transparentne za
uporabnike...)
– Slabša učinkovitost (pri poizvedbah, kjer je potrebno
poizvedovati po več particijah, je učinkovitost slabša)
– Podvajanje podatkov (pri vertikalnem particioniranju)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 234 -
Primer – particije v SUPB Oracle
CREATE TABLE ArchivedPropertyForRentPartition(
propertyNo VARCHAR2(5) NOT NULL,
street VARCHAR2(25) NOT NULL,
...
PRIMARY KEY (propertyNo),
FOREIGN KEY (ownerNo) REFERENCES PrivateOwner(ownerNo),
...
PARTITION BY HASH (branchNo) (
PARTITION b1 TABLESPACE TB01,
PARTITION b2 TABLESPACE TB02,
...
);
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 235 -
Povzeto po [1]
Poglavje 2
Obvladovanje transakcij
 Transakcije in njihove lastnosti
 Nadzor sočasnosti
 Obnova podatkov po nesrečah
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 236 -
P 3.1
Transakcije in njihove lastnosti
Kaj si bomo pogledali?
 Opredelitev transakcije
 Lastnosti transakcij
 Arhitektura SUPB – komponente povezane z nadzorom
sočasnosti ter obnovljivostjo podatkov
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 237 -
Opredelitev transakcije…
 Transakcija je operacija ali niz operacij, ki berejo
ali pišejo v podatkovno bazo in so izvedene s
strani enega uporabnika oziroma uporabniškega
programa.
 Transakcija je logična enota dela – lahko je cel
program ali samostojen ukaz (npr. INSERT ali
UPDATE)
 Izvedba uporabniškega programa je s stališča
podatkovne baze vidna kot ena ali več transakcij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 238 -
Opredelitev transakcije…
 Primeri transakcij
Staff( staffNo, fName, lName, position, sex, DOB, salary, branchNo)
PropertyForRent( propertyNo, street, city, postcode, type, rooms, rent,
ownerNo, staffNo, branchNo)
Povečanje plače za 10%
Brisanje zapisa v osnovni in povezani relaciji
Operacije nad
podatkovno bazo
Če ne izvedemo vseh sprememb
 baza v nekonsistentnem stanju
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 239 -
Opredelitev transakcije…
Si; i=1 .. n ≈ konsistentna ali skladna stanja v podatkovni bazi
Med izvajanjem transakcije je lahko stanje v bazi neskladno!
S1
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
T1
S2
T2
S3
- 240 -
T3
.....
Tn
Sn
Opredelitev transakcije…
 Transakcija se lahko zaključi na dva načina:
– Uspešno ali
– Neuspešno
 Če končana uspešno, jo potrdimo (commited),
sicer razveljavimo (aborted).
 Ob neuspešnem zaključku moramo podatkovno
bazo vrniti v skladno stanje pred začetkom
transakcije.
commit
S1
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
T1
S2
- 241 -
rollback
T2
S3
Opredelitev transakcije…
 Enkrat potrjene transakcije ni več moč
razveljaviti.
– Če smo s potrditvijo naredili napako, moramo za povrnitev v
prejšnje stanje izvesti novo transakcijo, ki ima obraten
učinek nad podatki v podatkovni bazi.
 Razveljavljene transakcije lahko ponovno
poženemo.
 Enkrat zavrnjena transakcija je drugič lahko
zaključena uspešno (odvisno od razloga za njeno
prvotno neuspešnost).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 242 -
Opredelitev transakcije
 SUPB se ne zaveda, kako so operacije logično
grupirane. Uporabljamo eksplicitne ukaze, ki to
povedo:
– Po ISO standardu uporabljamo ukaz BEGIN TRANSACTION
za začetek in COMMIT ali ROLLBACK za potrditev ali
razveljavitev transakcije.
– Če konstruktov za začetek in zaključek transakcije ne
uporabimo, SUPB privzame cel uporabniški program kot eno
transakcijo. Če se uspešno zaključi, izda implicitni COMMIT,
sicer ROLLBACK.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 243 -
Lastnosti transakcij…
 Vsaka transakcija naj bi zadoščala štirim
osnovnim lastnostim:
– Atomarnost: transakcija predstavlja atomaren sklop operacij.
Ali se izvede vse ali nič. Atomarnost mora zagotavljati SUPB.
– Konsistentnost: transakcija je sklop operacij, ki podatkovno
bazo privede iz enega konsistentnega stanja v drugo.
Zagotavljanje konsistentnosti je naloga SUPB (zagotavlja, da
omejitve nad podatki niso kršene…) in programerjev
(preprečuje vsebina neskladnosti).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 244 -
Lastnosti transakcij
 Osnovne lastnosti transakcije (nadaljevanje)*:
– Izolacija: transakcije se izvajajo neodvisno ena od druge 
delni rezultati transakcije ne smejo biti vidni drugim
transakcijam. Za izolacijo skrbi SUPB.
– Trajnost: učinek potrjene transakcije je trajen – če želimo
njen učinek razveljaviti, moramo to narediti z novo
transakcijo, ki z obratnimi operacijami podatkovno bazo
privede v prvotno stanje. Zagotavljanje trajnosti je naloga
SUPB.
*ACID – Atomicity, Consistency, Isolation and Durability
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 245 -
Obvladovanje transakcij – arhitektura
 Komponente SUPB za obvladovanje transakcij,
nadzor sočasnosti in obnovitev podatkov:
Koordinira transakcije
v imenu uporabniških
programov
Realizira različne strategije
za nadzor sočasnosti. Cilj:
maksimizirati sočasnost brez
da bi se transakcije med seboj
motile.
Skrbi za učinkovit
prenos podatkov
med diskom in
glavnim spominom.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Zagotavlja obnovitev podatkov
ob napakah in nesrečah...
- 246 -
P 3.2
Nadzor sočasnosti
Kaj si bomo pogledali?





PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Namen nadzora sočasnosti
Serializacija urnika transakcij
Zaklepanje in časovno žigosanje
Mrtve in žive zanke – detekcija in odprava
Optimistične metode nadzora sočasnosti
- 247 -
Zakaj sočasnost?…
 Eden od ciljev in prednosti PB je možnost
sočasnega dostopa s strani več uporabnikov do
skupnih podatkov.
 Če vsi uporabniki podatke le berejo – nadzor
sočasnosti trivialen;
 Če več uporabnikov sočasno dostopa do
podatkov in vsaj eden podatke tudi zapisuje –
možni konflikti.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 248 -
Zakaj sočasnost?…
 Za večino računalniških sistemov velja:
– imajo vhodno izhodne enote, ki znajo samostojno izvajati
I/O operacije.
– V času I/O operacij centralna procesorska enota CPU izvaja
druge operacije.
 Taki sistemi lahko izvajajo dve ali več transakcij
sočasno. Primer:
– Sistem začne z izvajanjem prve transakcije in jo izvaja vse
do prve I/O operacije. Ko naleti na I/O operacijo, jo začne
izvajati, CPU pa z izvajanjem operacij transakcije začasno
prekine. V tem času se začne izvajati druga transakcija. Ko
se I/O operacija prve zaključi, CPU začasno prekine z
izvajanjem druge in se vrne k prvi.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 249 -
Zakaj sočasnost?…
 Prepletanje operacij dveh transakcij…
t1
T1
T2
t2
CPU
CPU
t3
CPU
CPU
t4
CPU
CPU
t5
I/O
CPU
t6
I/O
CPU
t7
I/O
CPU
t8
I/O
t9
I/O
t10
CPU
t11
I/O
CPU
CPU
t12
t13
t14
t15
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 250 -
T1
T2
CPU
CPU
CPU
I/O
CPU
I/O
CPU
I/O
CPU
I/O
CPU
CPU
CPU
CPU
CPU
I/O
I/O
CPU
Problemi v zvezi z nadzorom sočasnosti…
 V centraliziranem SUPB zaradi sočasnosti dostopa
različni problemi:
– Izgubljene spremembe: uspešno izveden UPDATE se
razveljavi zaradi istočasno izvajane operacije s strani
drugega uporabnika.
– Uporaba nepotrjenih podatkov (dirty read): transakciji je
dovoljen vpogled v podatke druge transakcije, še preden je
ta potrjena.
– Neskladnost analize: transakcija prebere več vrednosti iz
podatkovne baze. Nekatere izmed njih se v času izvajanja
prve transakcije zaradi drugih transakcij spremenijo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 251 -
Primeri težav s sočasnostjo dostopa…
 Izgubljene spremembe
 T1 dvig $10 iz TRR, na katerem je začetno stanje $100.
 T2 depozit $100 na isti TRR.
 Po zaporedju T1, T2 končno stanje enako $190.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 252 -
Primeri težav s sočasnostjo dostopa…
 Uporaba nepotrjenih podatkov
 T3 dvig $10 iz TRR.
 T4 depozit $100 na isti TRR.
 Po zaporedju T3, T4 končno stanje enako $190. Če T4 preklicana, je
pravilno končno stanje $90.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 253 -
Primeri težav s sočasnostjo dostopa…
 Nekonsistentna analiza




PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Začetno stanje: balx=$100, baly=$50, balz=$25;
Seštevek je $175
T5 prenos $10 iz TRRx na TRRz.
T6 izračun skupnega stanja na računih TRRx, TRRy in TRRz.
- 254 -
Serializacija in obnovljivost…
 Če transakcije izvajamo zaporedno, se izognemo
vsem problemom. Problem: nizka učinkovitost.
 Kako v največji meri uporabiti paralelnost?
 Nekaj definicij:
 Serializacija:
– način, kako identificirati načine izvedbe transakcij, ki
zagotovijo ohranitev skladnosti in celovitosti podatkov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 255 -
Serializacija in obnovljivost…
 Urnik
– Zaporedje operacij iz množice sočasnih transakcij, ki ohranja
vrstni red operacij posameznih transakcij.
 Zaporedni urnik
– Urnik, v katerem so operacije posameznih transakcij
izvedene zaporedoma, brez prepletanja z operacijami iz
drugih transakcij.
 Nezaporedni urnik
– Urnik, v katerem se operacije ene transakcija prepletajo z
operacijami iz drugih transakcij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 256 -
Serializacija in obnovljivost…
 Namen serializacije:
– Najti nezaporedne urnike, ki omogočajo vzporedno izvajanje
transakcij brez konfliktov. Dajo rezultat, kot če bi transakcije
izvedel zaporedno.
 S serializacijo v urnikih spreminjamo vrstni red
bralno/pisalnih operacij. Vrstni red je pomemben:
– Če dve transakciji bereta isti podatek, nista v konfliktu.
Vrstni red nepomemben.
– Če dve transakciji bereta ali pišeta popolnoma ločene
podatke, nista v konfliktu. Vrstni red nepomemben.
– Če neka transakcija podatek zapiše, druga pa ta isti podatek
bere ali piše, je vrstni red pomemben.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 257 -
Primer
UA
Nezaporedni urnik
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
UB
Nezaporedni urnik
- 258 -
UC
Zaporedni urnik
Transakcije, ki jih ni moč serializirati…
 Preverjamo s pomočjo usmerjenega grafa
zaporedja
G = (N, E); N  vozlišča, E  povezave
 Gradnja grafa:
– Kreiraj vozlišče za vsako transakcijo
– Kreiraj usmerjeno povezavo Ti  Tj, če Tj bere vrednost,
predhodno zapisano s Ti
– Kreiraj usmerjeno povezavo Ti  Tj, če Tj piše vrednost, ki
je bila predhodno prebrana s Ti (tudi, če je vmes COMMIT)
– Kreiraj usmerjeno povezavo Ti  Tj, če Tj piše vrednost, ki
je bila predhodno zapisana s Ti (tudi, če je vmes COMMIT)
Če graf vsebuje cikel, potem serializacija urnika ni možna!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 259 -
Primer
 Imamo naslednjo situacijo:
– T9 prenese $100 iz TRRx na TRRy.
– T10 stanje na obeh računih poveča za 10%.
– Graf zaporedja vsebuje cikel, zato transakciji ni moč
serializirati.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 260 -
Vrste serializacij
 Predmet serializacije, ki smo jo obravnavali, so
bile konflikte operacije.
– Serializacija konfliktnih operacij (Conflict Serializibility)
zagotavlja, da so konfliktne operacije izvedene tako, kot bi
bile v zaporednem urniku.
 Obstajajo tudi druge vrste serializacije.
– Primer: serializacija vpogledov (View serializibility)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 261 -
Serializacija vpogledov...
 Urnika S1 in S2, ki ju sestavljajo operacije iz istih
n transakcij sta ekvivalentna po vpogledih, če
velja:
– Za vsak podatek x mora veljati:
 če Ti bere začetno vrednost x v urniku S1, mora isto veljati za S2
 če je zadnji vpis x izvedla transakcija Ti v S1, mora isto veljati za S2
– Za vsako branje x, ki ga izvede Ti v S1
 če je x bil zapisan s Tj, potem mora enako veljati tudi v S2
 Urnik je moč serializirati po vpogledih, če je
ekvivalenten nekemu zaporednemu urniku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 262 -
Serializacija vpogledov...
 Vsak urnik, ki ga je moč serializirati po konfliktnih
operacijah, je moč tudi serializirati po vpogledih.
 Obratno ne velja  serializacija po konfliktnih
operacijah je močnejša serializacija.
Urnik je moč serializirati po vpogledih, po konfliktih pa ne.
T11
T12
T13
Transakciji T12 in T13 ne zadoščati pravilu, ki pravi, da mora transakcija vsak podatek,
ki
ga zapiše, predhodno prebrati. Urnik, ki ga je moč serializirati po vpogledih ne pa po
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
- 263 konfliktnih
©Laboratorij za informatikooperacijah ima vedno kakšno slepo pisanje.
Testiranje serializacije vpogledov
 Testiranje serializacije vpogledov:
– veliko težje od testiranja serializacije konfliktnih operacij.
– velja za NP polni problem.
 Algoritem
– glej [1, 584-586]
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 264 -
Obnovljivost...
 Serializacija zagotavlja, da je urnik možno izvesti
tako, da stanje v podatkovni bazi ostane
konsistentno, pri predpostavki, da se vse
transakcije izvedejo uspešno.
 Kaj če pride do neuspešne izvedbe?
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 265 -
Obnovljivost
 Urnik lahko preverimo tudi v smislu, če omogoča
obnovljivost.
 Urnik, ki obnovljivost omogoča, imenujemo
obnovljiv urnik (Recoverable Schedule)
 Urnik je obnovljiv, če za vse transakcije, ki
nastopajo v urniku, velja:
– če Tj bere neko podatkovno enoto, predhodno zapisano s Ti,
potem mora biti Ti potrjena pred Tj (commit).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 266 -
Metode nadzora sočasnosti...
 Nadzor sočasnosti temelji na dveh osnovnih
metodah:
– Zaklepanje: zagotavlja, da je sočasno izvajanje enakovredno
zaporednemu izvajanju, pri čemer zaporedje ni določeno.
– Časovno žigosanje: zagotavlja, da je sočasno izvajanje
enakovredno zaporednemu izvajanju, pri čemer je zaporedje
določeno s časovnimi žigi.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 267 -
Metode nadzora sočasnosti
 Metode za nadzor sočasnosti delimo na:
– Pesimistične: v primeru, da bi lahko prišlo do konfliktov, se
izvajanje ene ali več transakcij zadrži in
– Optimistične: izhajamo iz predpostavke, da je konfliktov
malo, zato dovolimo vzporedno izvajanje, za konflikte pa
preverimo na kocu izvedbe.
 V nadaljevanju: zaklepanje in časovno žigosanje
(pesimistični metodi) ter primer optimistične
metode.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 268 -
Zaklepanje...
 Zaklepanje je postopek, ki ga uporabljamo za
nadzor sočasnega dostopa do podatkov.
– Ko ena transakcija dostopa do nekega podatka, zaklepanje
onemogoči, da bi ga istočasno uporabljale tudi druge kar bi
lahko pripeljalo do napačnih rezultatov.
 Obstaja več načinov izvedbe. Vsem je skupno
naslednje:
– Transakcija mora preden podatek prebere zahtevati deljeno
zaklepanje (shared lock) pred pisanjem pa ekskluzivno
zaklepanje (exclusive lock).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 269 -
Zaklepanje...
 Zrnatost zaklepanja:
– Zaklepanje se lahko nanaša na poljuben del podatkovne
baze (od polja do cele podatkovne baze). Imenovali bomo
“podatkovna enota”.
 Pomen deljenega in ekskluzivnega zaklepanja:
– Če ima transakcija deljeno zaklepanje nad neko podatkovno
enoto, lahko enoto prebere, ne sme pa vanjo pisati.
– Če ima transakcija ekskluzivno zaklepanje nad neko
podatkovno enoto, lahko enoto prebere in vanjo piše.
– Deljeno zaklepanje nad neko podatkovno enoto ima lahko
več transakcij, ekskluzivno pa samo ena.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 270 -
Zaklepanje...
 Postopek zaklepanja:
– Če transakcija želi dostopati do neke podatkovne enote,
mora pridobiti deljeno (samo za branje) ali ekskluzivno
zaklepanje (za branje in pisanje).
– Če enota ni že zaklenjena, se transakciji zaklepanje odobri.
– Če je enota že zaklenjena:
 če je obstoječe zaklepanje deljeno, se odobri
 če je obstoječe zaklepanje ekskluzivno, mora transakcija počakati,
da se sprosti.
– Ko transakcija enkrat pridobi zaklepanje, le-to velja, dokler
ga ne sprosti. To se lahko zgodi eksplicitno ali implicitno (ob
prekinitvi ali potrditvi transakcije).
Nekateri sistemi omogočajo prehajanje iz deljenega v ekskluzivno zaklepanje
- 271 in obratno.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Zaklepanje...
 Opisan postopek zaklepanja sam po sebi še ne
zagotavlja serializacije urnikov.
 Primer:
S=
{write_lock(T9, balx), read(T9, balx),
write(T9, balx), unlock(T9, balx),
write_lock(T10, balx), read(T10, balx),
write(T10, balx), unlock(T10, balx),
write_lock(T10, baly), read(T10, baly),
write(T10, baly), unlock(T10, baly),
commit(T10), write_lock(T9, baly),
read(T9, baly), write(T9, baly),
unlock(T9, baly), commit(T9) }
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 272 -
Dvofazno zaklepanje – 2PL...
 Da zagotovimo serializacijo, moramo upoštevati
dodaten protokol, ki natančno definira, kje v
transakcijah so postavljena zaklepanja in kje se
sprostijo.
 Eden najbolj znanih protokolov je dvofazno
zaklepanje (2PL – Two-phase locking).
 Transakcija sledi 2PL protokolu, če se vsa
zaklepanja v transakciji izvedejo pred prvim
odklepanjem.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 273 -
Dvofazno zaklepanje – 2PL...
 Po 2PL lahko vsako transakcijo razdelimo na
– fazo zasedanja: transakcija pridobija zaklepanja, vendar
nobenega ne sprosti in
– fazo sproščanja: transakcija sprošča zaklepanja, vendar ne
more več pridobiti novega zaklepanja.
 Protokol 2PL zahteva:
– Transakcija mora pred delom z podatkovno enoto pridobiti
zaklepanje
– Ko enkrat sprosti neko zaklepanje, ne more več pridobiti
novega.
– Če je dovoljeno nadgrajevanje zaklepanja (iz deljenega v
ekskluzivno, je to lahko izvedeno le v fazi zasedanja..
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 274 -
Reševanje izgubljenih sprememb z 2PL
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 275 -
Reševanje nepotrjenih podatkov z 2PL
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 276 -
Reševanje nekonsistentne analize z 2PL
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 277 -
Kaskadni preklic…
 Če vse transakcije v urniku sledijo 2PL protokolu,
je urnik moč serializirati.
 Pojavijo se lahko težave zaradi nepravilno
izvedenih preklicev zaklepanj.
– Ali lahko preklic zaklepanja neke podatkovne enote
naredimo takoj, ko je končana zadnja operacija, ki do te
enote dostopa?
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 278 -
Kaskadni preklic…
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 279 -
Kaskadni preklic
 Kaskadni preklici so nezaželeni.
 2PL, ki onemogoča kaskadne preklice, zahteva,
da se sprostitev preklicev izvede šele na koncu
transakcije.
– Rigorozni 2PL (Rigorous 2PL): do konca transakcij
zadržujemo vse sprostitve.
– Striktni 2PL (Strict 2PL): zadržujemo le ekskluzivna
zaklepanja.
 Večina DBMS-jev realizira rigorozni ali striktni
2PL.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 280
Urnike, ki sledijo rigoroznemu 2PL protokolu,
je vedno
moč serializirati.
Mrtve zanke…
 Mrtva zanka (dead lock): brezizhoden položaj, do
katerega pride, ko dve ali več transakcij čakajo
ena na drugo, da bodo sprostile zaklepanja.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 281 -
Mrtve zanke…
 Samo ena možnost, da razbijemo mrtvo zanko:
preklic ene ali več transakcij.
 Mrtva zanka oziroma njena detekcija in odprava
mora biti za uporabnika transparentna.
– SUPB sam razveljavi operacije, ki so bile narejene do točke
preklica transakcije in transakcijo ponovno starta.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 282 -
Mrtve zanke…
 Tehnike obravnave mrtvih zank:
– Prekinitev: po poteku določenega časa SUPB transakcijo
prekliče in ponovno zažene.
– Preprečitev: uporabimo časovne žige; dva algoritma:
 Wait-Die: samo starejše transakcije lahko čakajo na mlajše, sicer
transakcija prekinjena (die) in ponovno pognana z istim časovnim
žigom. Sčasoma postane starejša…
 Wound-Wait: simetrični pristop: samo mlajša transakcija lahko
čaka starejšo. Če starejša zahteva zaklepanje, ki ga drži mlajša, se
mlajša prekine (wounded).
– Detekcija in odprava: sestavimo graf WFG (wait-for graph),
ki nakazuje odvisnosti med transakcijami in omogoča
detekcijo mrtvih zank.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 283 -
Mrtve zanke…
 WFG je usmerjen graf G = (N, E), kjer N vozlišča,
E povezave.
 Postopek risanja WFG:
– Kreiraj vozlišče za vsako transakcijo
– Kreiraj direktno povezavo Ti  Tj, če Ti čaka na zaklepanje
podatkvne enote, ki je zaklenjena s strani Tj.
 Pojav mrtve zanke označuje cikel v grafu.
 SUPB periodično gradi graf in preverja obstoj
mrtve zanke.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 284 -
Mrtve zanke…
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 285 -
Mrtve zanke
 Ko je mrtva zanka detektirana, je potrebno eno
ali več transakcij prekiniti.
 Pomembno:
– Izbira transakcije za prekinitev: možni kriteriji: ‘starost’
transakcije, število sprememb, ki jih je transakcija naredila,
število sprememb, ki jih transakcija še mora opraviti.
– Koliko transakcije preklicati: namesto preklica cele
transakcije včasih mrtvo zanko moč rešiti s preklicom le dela
transakcije.
– Izogibanje stalno istim žrtvam: potrebno preprečiti, da ni
vedno izbrana ista transakcija. Podobno živi zanki (live lock)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 286 -
Časovno žigosanje…
 Časovni žig: enolični identifikator, ki ga SUPB
dodeli transakciji in pove relativni čas začetka
transakcije.
 Časovno žigosanje: protokol nadzora sočasnosti,
ki razvrsti transakcije tako, da so prve tiste, ki so
starejše.
– Alternativa zaklepanju pri reševanju sočasnega dostopa
– Če transakcija želi brati/pisati neko podatkovno enoto, se ji
to dovoli, če je bila zadnja sprememba nad to enoto
narejena s starejšo transakcijo. Sicer se restarta z novim
žigom.
– Ni zaklepanj  ni mrtvih zank
– Ni čakanja  če transakcija v konfliktu, se restarta.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 287 -
Časovno žigosanje…
 Časovni žig imajo tudi podatkovne enote
– Read_timestamp: časovni žig transakcije, ki je podatkovno
polje nazadnje prebrala,
– Write_timestamp: časovni žig transakcije, ki je v podatkovno
polje nazadnje pisala.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 288 -
Časovno žigosanje…
Princip delovanja časovnega žigosanja:

– Imamo transakcijo T s časovnim žigom ts(T)
A) T zažene operacijo read(x)


Če x že spremenjen s strani mlajše transakcije
ts(T) < write_timestamp(x)
potem moramo transakcijo prekiniti in ponovno pognati z novim
žigom.
Sicer: ts(T) ≥ write_timestamp(x), z branjem nadaljujemo.
Nastavimo read_timestamp(x) = max( ts(T), read_timestamp(x) ).
Problem je potencialna nekonsistentnost
z drugimi vrednostmi, ki jih je transakcija
že prebrala.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 289 -
Časovno žigosanje…

Princip delovanja časovnega žigosanja
(nadaljevanje):
B) T zažene operacijo write(x)



PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Če x že prebrana s strani mlajše transakcije
ts(T) < read_timestamp(x)
potem moramo transakcijo prekiniti in restartati z novim žigom.
Če x že zapisana s strani mlajše transakcije
ts(T) < write_timestamp(x)
potem moramo transakcijo prekiniti in restartati z novim žigom.
Sicer: ts(T) ≥ write_timestamp(x), s pisanjem nadaljujemo.
Nastavimo write_timestamp(x) = ts(T).
- 290 -
Časovno žigosanje…
 Časovno žigosanje po opisanem principu
imenujemo osnovna ureditev po časovnih žigih
(basic timestamp ordering)
 Osnovna ureditev po časovnih žigih:
– zagotavlja serializacijo konfliktnih operacij, vendar
– ne zagotavlja obnovljivosti urnika.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 291 -
Časovno žigosanje…
 Tomaževo pravilo pisanja – dodatno pravilo, ki
poveča stopnjo sočasnosti:
– Dodatno pravilo za pisanje: pisanje zavrni, če se nanaša na
neko zastarelo podatkovno enoto.
– T zažene operacijo write(x)
 Če x že prebrana s strani mlajše transakcije
ts(T) < read_timestamp(x)
potem moramo transakcijo prekiniti in restartati z novim žigom.
 Če x že zapisana s strani mlajše transakcije
ts(T) < write_timestamp(x)
potem transakcijo ignoriramo.
 Sicer: ts(T) ≥ write_timestamp(x), s pisanjem nadaljujemo.
Nastavimo write_timestamp(x) = ts(T).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 292 -
Časovno žigosanje…
 A) osnovna ureditev po časovnih žigih:
– Operacija write(balx) v T11, ki sledi operaciji write(x) v T12 bi
bila zavrnjena; T11 bi morali obnoviti in restartati z novim
žigom.
 B) upoštevajoč Tomovo pravilo pisanja
– Ne zahteva nobenega obnavljanja.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 293 -
Primer
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 294 -
Primerjava metod nadzora sočasnosti
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 295 -
Časovno žigosanje več verzij…
 Z verzioniranjem podatkov lahko povečamo
sočasnost.
 Osnovni protokol urejanja po časovnih žigih
– predpostavlja, da obstaja samo ena verzija podatkovne
enote  samo ena transakcija lahko do enote dostopa
naenkrat.
 Časovno žigosanje več verzij omogoča več
transakcijam istočasno brati/pisati različne verzije
iste podatkovne enote.
 Zagotavlja, da vsaka transakcija vidi konsistentno
množico verzij za vse enote, ki jih uporablja.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 296 -
Časovno žigosanje več verzij…
 Pri uporabi časovnega žigosanja več verzij vsaka
pisalna operacija kreira novo verzijo podatkovne
enote in zadrži staro.
 Ko transakcija poskuša podatek prebrati, SUPB
izbere tisto verzijo, ki zagotavlja serializacijo.
 Verzije brišemo takrat, ko jih ne potrebujemo
več.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 297 -
Časovno žigosanje več verzij…
 Postopek časovnega žigosanja več verzij:
– Predpostavimo, da za vsako podatkovno enoto x obstaja n
verzij: x1, x2,… xn.
– Za vsako verzijo i, sistem hrani tri vrednosti:
 Vrednost verzije xi
 Read_timestamp(xi)
 Write_timestamp(xi)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 298 -
Časovno žigosanje več verzij…
 Postopek časovnega žigosanja več verzij
(nadaljevanje):
– Naj bo ts(T) časovni žig trenutne transakcije.
– Protokol časovnega žigosanja več verzij sledi dvema
praviloma:
– (I) T zažene operacijo write(x)
 Če T želi pisati enoto x, moramo zagotoviti, da enota še ni bila
prebrana s strani mlajše transakcije Tj. Če T dovolimo pisanje, bi
morali zaradi serializacije zagotoviti, da Tj x še enkrat prebere. Ker
je x že prebrala, se to ne zgodi. Tako transakcijo prekinemo in
ponovno poženemo z novim žigom.
 Če T želi brati enoto x, mora prebrati zadnjo verzijo x, ki ima
časovni žig pisanja še manjši od žiga transakcije. Časovni žig
branja nastavimo na max(ts(T), read_timestamp(xj))
Pri takem protokolu branje vedno uspe.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 299 -
Časovno žigosanje več verzij
 Brisanje verzij:
– Verzije lahko brišemo
– Postopek:
 poiščemo najstarejšo transakcijo Tp
 poiščemo vse verzije x: x1, x2,…, xn za katere velja
write_timestamp(xi) < ts(Tp) ter zbrišemo vse razen najmlajše.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 300 -
Optimistične tehnike…
 Optimistične metode za nadzor sočasnosti
– temeljijo na predpostavki, da je konfliktov malo, zato je
vzporedno izvajanje dovoljeno brez kontrole, morebitne
konflikte pa preverimo na kocu izvedbe.
– Ob zaključku transakcije (commit) se preveri morebitne
konflikte. Če konflikt, se transakcija razveljavi.
– Omogočajo večjo stopnjo sočasnosti (pri predpostavki, da je
konfliktov malo)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 301 -
Optimistične tehnike…
 Protokoli, ki temeljijo na optimističnem pristopu,
imajo tipično tri faze:
– Faza branja: traja vse od začetka transakcije do tik pred
njeno potrditvijo (commit). Preberejo se vsi podatki, ki jih
transakcija potrebuje ter zapišejo v lokalne spremenljivke.
Vse spremembe se izvajajo nad lokalnimi podatki.
– Faza preverjanja: začne za fazo branja. Preveri se, ali je moč
spremembe, ki so vidne lokalno, aplicirati tudi v podatkovno
bazo.
 Za transakcije, ki zgolj berejo, še enkrat preverimo, če so prebrane
vrednosti še vedno iste. Če konfliktov ni, sledi potrditev, sicer
zavrnitev ter ponovni zagon transakcije.
 Za transakcije, ki podatke spreminjajo, moramo preveriti, če
spremembe ohranijo konsistentnost podatkovne baze.
– Faza pisanja: sledi fazi preverjanja. Če slednja uspešna, se
podatki zapišejo v podatkovno bazo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 302 -
Optimistične tehnike
 Izvedba faze preverjanja:
– Vsaka transakcija T ima dodeljene tri časovne žige: ob
začetku – start(T), ob preverjanju – validation(T) in ob
zaključku – finish(T).
– Preverjanje uspešno, če velja vsaj eden od pogojev:
 Vse transakcije S s starejšim žigom se morajo končati pred
začetkom T: finish(S) < start(T)
 Če T začne preden se starejša transakcija S konča, potem:
(a) množica podatkov, zapisanih s starejšo transakcijo, ne vključuje
tistih, ki jih je trenutna transakcija prebrala.
(b) starejša transakcija zaključi fazo pisanja preden mlajša začne s
fazo preverjanja: start(T) < finish(S) < validation(T).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 303 -
P 3.3
Transkacije v porazdeljenih sistemih
Kaj si bomo pogledali?
 Izvajanje transakcij v porazdeljenih sistemih
 Zagotavljanje sočasnosti v porazdeljenih sistemih



Centraliziran 2PL,
2PL s primarno kopijo,
Porazdeljen 2PL,

Večinsko zaklepanje
 Časovno žigosanje
 Detekcija mrtvih zank
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 304 -
Transakcije v porazdeljenih sistemih
 V SUPPB obvladovanje transakcij težje:
– Zahteva atomarnost globalnih transakcij in vsake od podtransakcij
 Lokalni SUPB-ji v porazdeljenih sistemih imajo
enake komponente kot v centralnih izvedbah.
 Dodatno na vsakem vozlišču:
– Globalna komponenta za koordiniranje transakcij (Global
Transaction Manager ali Transaction Coordinator): koordinira
izvajanje globalnih in lokalnih transakcij, ki so bile inicirane v
vozlišču.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 305 -
Postopek za izvedbo transakcije
 Transakcija pognana na vozlišču S1
– Koordinator transakcij na S1 razdeli transakcijo na pod-transakcije,
upoštevajoč podatke v globalnem sistemskem katalogu.
– Komponenta za podatkovno komunikacijo na S1 pošlje podtransakcije na ustrezna vozlišča.
– Poslane pod-transakcije prevzamejo lokalni koordinatorji transakcij.
– Rezultat se posreduje nazaj koordinatorju transakcij na vozlišču S1.
PODATKOVNE BAZE
Podiplomski študij
©Laboratorij za informatiko
- 306 -
Nadzor sočasnosti…
 Komponenta za nadzor sočasnosti (Concurrency
Control) zagotavlja
– ohranitev celovitosti in skladnosti podatkov po izvedbi
transakcij in
– Dokončanje vsake atomarne operacije.
 V SUPPB dober sistem za nadzor sočasnosti
zagotavlja še:
–
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Hitro odzivnost in obnovljivost v primeru napak,
Paralelnost delovanja,
Minimalni “overhead” v smislu procesiranja in shranjevanja
Zadovoljivo delovanje v mrežnem okolju
Minimalno število omejitev nad strukturo atomarnih operacij.
- 307 -
Nadzor sočasnosti v porazdeljenih sistemih...
 Razširjena serializacija:
– Če je urnik izvedbe transakcij na posameznih vozliščih moč
serializirati, potem je tudi globalni urnik (sestavljen iz vseh
urnikov vozlišč) moč serializirati, če velja, da so zaporedja na
vozliščih identična:
 Naj bo Ti na S1 označen kot Ti_1
 Za serializacijo globalnega urnika moramo zagotoviti, da če Ti_1 <
Tj_1 potem Ti_n < Tj_n, za vsako vozlišče Sn, na katerem imata Ti in
Tj pod-transakcije!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 308 -
Nadzor sočasnosti v porazdeljenih sistemih...
 Nadzor sočasnosti v porazdeljenih sistemih
temelji na dveh osnovnih pristopih (enako kot pri
centraliziranih sistemih):
– Zaklepanje: zagotavlja, da je sočasno izvajanje enakovredno
nekemu (poljubnemu) zaporednemu izvajanju.
– Dodeljevanje časovnih žigov: zagotavlja, da je sočasno
izvajanje enakovredno zaporednemu izvajanju, določenemu
s časovnimi žigi.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 309 -
Nadzor sočasnosti v porazdeljenih sistemih
 Če podatkovna baza
– centralizirana ali porazdeljena (vendar ne replicirana) in so
vse transakcije lokalne ali pa se izvajajo na enem strežniku,
potem protokoli iz centraliziranih sistemov zadoščajo. Sicer
so potrebni posebni protokoli.
 Pogledali bomo:
– Protokole zaklepanja: centraliziran 2PL, 2PL s primarno
kopijo, porazdeljen 2PL, večinsko zaklepanje
– Protokole s časovnim žigom
– Način identifikacije centraliziranih, hierarhičnih in
porazdeljenih mrtvih zank
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 310 -
Centraliziran 2PL…
 Vsi podatki o zaklepanju se vodijo na enem
vozlišču. Za dodajanje in sproščanje zaklepanj
obstaja centralni LM*.
 Postopek za transakcijo T pognano na vozlišču S1:
– TC1+ razdeli transakcijo na dele upoštevajoč podatke v
globalnem sistemskem katalogu. TC1 zadolžen za skladnost
PB.
– Če transakcija zajema spremembo replicirane podatkovne
enote, TC1 poskrbi, da se spremenijo vse kopije. TC1 zahteva
ekskluzivno zaklepanje vseh kopij, dokler ne izvede
spremembe. TC1 sam odloči, katero kopijo uporabi.
*LM
– Lock Manager
+TC – Transaction Coordinator
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 311 -
Centraliziran 2PL…
 Postopek za transakcijo T pognano na vozlišču S1
(nadaljevanje):
– Lokalni TM, vključeni v globalno transakcijo, zahtevajo in
sproščajo zaklepanja v centralnem TM (uporabljajo se
pravila navadnega 2PL).
– Centralni LM preveri, če je zahtevano zaklepanje
kompatibilno z obstoječimi:
 Če kompatibilno, zaklepanje izvede in obvesti vozlišče, iz katerega
je prišla zahteva
 Sicer zahtevo da v vrsto, dokler zaklepanje ni možno.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 312 -
Centraliziran 2PL
 Prednosti:
– Enostavna implementacija
– Detekcija mrtvih zank enako kot na navadnem SUPB (z
vsemi zaklepanji dela en sam LM)
– Relativno nizki stroški komunikacije
 Slabosti:
– Pot do centralnega LM lahko ozko grlo (vse zahteve gredo
na centralni LM)
– Nižja zanesljivost: odpoved centralnega mesta pomeni velik
problem
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 313 -
2PL s primarno kopijo…
 Odpravlja slabosti centraliziranega 2PL
 Ideja:
– Več LM, ki so porazdeljeni po več vozliščih
– Vsak LM je zadolžen za en segment podatkov
– Za vsako replicirano podatkovno enoto izberemo eno kopijo in
jo označimo kot primarno kopijo. LM, ki izvaja zaklepanja in
sproščanja primarne kopije, ni potrebno, da je nujno na istem
vozlišču kot primarna kopija.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 314 -
2PL s primarno kopijo…
 Protokol 2PL s primarno kopijo predstavlja
razširitev centraliziranega 2PL. Razlika s
centraliziranim 2PL:
– ko je potrebno nek podatek spremeniti, najprej poiščemo
lokacijo primarne kopije, da lahko pošljemo zahtevo za
zaklepanje ustreznemu LM.
– Ekskluzivno zaklepanje potrebno samo za primarno kopijo
– Ostale kopije spremenimo kasneje (zaželeno čim prej).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 315 -
2PL s primarno kopijo
 2PL s primarno kopijo uporaben v primerih:
– ko je replikacija selektivna,
– Spremembe niso pogoste,
– Vozlišča ne potrebujejo vedno zadnje verzije podatkov
 Slabosti:
– Težavno identificiranje mrtvih zank (zaradi več LM)
– Ni povsem distribuiran sistem (neko primarno kopijo lahko
zaklepa le en LM)  lahko omilimo, če določimo dodatna
vozlišča kot backup za podatke o zaklepanju.
 Prednost:
– Stroški komunikacije nižji ter učinkovitost večja kot pri
centraliziranemu 2PL (manj oddaljenega zaklepanja).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 316 -
Porazdeljen 2PL…
 Podobno kot 2PL s primarno kopijo poskuša
odpraviti težave centraliziranega 2PL.
 Ideja:
– LM so porazdeljeni po vseh vozliščih.
– Vsak LM odgovoren za zaklepanja in sproščanja podatkov na
vozlišču, kateremu pripada.
– Če podatki niso replicirani, gre za enak protokol kot 2PL s
primarno kopijo.
– Če podatki replicirani, se uporabi protokol kontrole
replikacije imenovan ROWA (Read-One-Write-All).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 317 -
Porazdeljen 2PL
 Delovanje ROWA:
– Katerakoli kopija neke podatkovne enote se lahko uporabi za
branje, vendar morajo biti vse enote ekskluzivno zaklenjene,
če eno spreminjamo.
 Prednosti:
– Zaklepanje se izvaja porazdeljeno (odpravimo slabosti
centraliziranega pristopa)
 Slabosti:
– Kompleksno identificiranje mrtvih zank
– Večji stroški komunikacije kot pri 2PL s primarno kopijo (vse
kopije moramo pri pisanju zakleniti)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 318 -
Večinsko zaklepanje…
 Predstavlja razširitev porazdeljenega 2PL, kjer se
izognemo potrebi po zaklepanju vseh kopij…
 Koncept:
– LM porazdeljeni po vseh vozliščih
– Vsak LM skrbi za lokalne podatke
– Če transakcija želi brati ali pisati podatkovno enoto, zapisano
na n mestih, mora poslati zahtevo za zaklepanje na več kot
pol vozlišč, kjer je enota shranjena.
– Transakcija ne more nadaljevati, dokler ni zaklenjena večina
kopij.
– Če v določenem času ne uspe pridobiti dovolj zaklepanj, se
transakcija prekine ter o tem obvesti vsa mesta, ki so
zaklepanja izvedla.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 319 -
Večinsko zaklepanje
 Koncept (nadaljevanje):
– Poljubno število transakcij ima lahko istočasno deljeno
zaklepanje nad večino podatkovnih enot, samo ena pa
ekskluzivno zaklepanje.
 Prednosti:
– Odprava slabosti centraliziranega pristopa
 Slabosti
– Kompleksnost protokola
– Kompleksnost identifikacije mrtvih zank
– Stroški zaklepanja in odklepanja
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 320 -
Časovno žigosanje...
 Cilj časovnega žigosanja:
– Transakcije urediti tako, da imajo starejše transakcije
prednost v primeru konflikta.
– V centraliziranih SUPB za dodeljevanje časovnih žigov
uporabimo sistemsko uro ali števec.
 V porazdeljenih sistemih:
– Časovno žigosanje globalno in lokalno
– Sistemska ura ali lokalni števec neustrezna za dodeljevanje
časovnih žigov – problem sinhronizacije
– Tipična rešitev: uporabimo združen niz
<lokalni žig, oznaka vozlišča>
– Uporablja se tudi med-vozliščna sinhronizacija
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 321 -
Časovno žigosanje
 Da preprečimo, da bi bolj zasedena vozlišča
generirala večje žige kot nezasedena:
– Vsako vozlišče v sporočilu, ki ga pošlje drugim vozliščem,
vključi še žig.
– Prejemnik primerja svoj žig s prejetim in če je prejeti žig
večji, svojega popravi tako, da postane večji od prejetega.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 322 -
Detekcija mrtvih zank v SUPPB...
 V porazdeljenih sistemih detekcija in odprava
mrtvih zank kompleksnejša.
 Možna poenostavitev: uporaba centraliziranega
LM.
 Primer:
– Imamo tri transakcije: T1, T2 in T3
 T1 pognana na S1, njen del pa tudi na S2
 T2 pognana na S2, njen del pa tudi na S3
 T3 pognana na S3, njen del pa tudi na S1
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 323 -
Detekcija mrtvih zank v SUPPB...
 Primer (nadaljevanje):
– Zaklepanja:
Čas
S1
S2
S3
t1
Read_lock(T1, x1)
Write_lock(T2, y2)
Read_lock(T3, z3)
t2
Write_lock(T1, y1)
Write_lock(T2, z2)
t3
Write_lock(T3, x1)
Write_lock(T1, y2)
Write_lock(T2, z3)
– Če konstruiramo WFG, dobimo
T3
T1
T1
S1
– Združeni WFG
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
T2
S2
T1
T3
S3
T2
T3 - 324
T2
Detekcija mrtvih zank v SUPPB...
 V SUPPB lokalni graf čakanja (WFG) ne zadošča –
potrebno sestaviti tudi globalni WFG, ki
predstavlja unijo lokalnih WFG.
 V porazdeljenih sistemih v uporabi trije pristopi
za detekcijo mrtvih zank:
– Centralizirana detekcija
– Hierarhična detekcija
– Porazdeljena detekcija
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 325 -
Detekcija mrtvih zank v SUPPB...
 Centralizirana detekcija:
– Določeno je eno vozlišče, ki je odgovorno za detekcijo
mrtvih zank (DDC – Dead Lock Coordinator)
– Naloga DDC je
 Konstruirati globalni WFG
 Preverjati obstoj zank v globalnem WFG
 V primeru zank izbrati transakcije, ki se prekinejo (rollback) in
ponovno poženejo.
– Za minimizacijo prometa po omrežju LM pošilja DDC-ju zgolj
spremembe v lokalnem WFG (dodane ali brisane povezave).
 Slabost:
– Nižja zanesljivost (če odpove vozlišče z DDC).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 326 -
Detekcija mrtvih zank v SUPPB...
 Hierarhična detekcija:
– Vozlišča urejena v hierarhijo
– Vsako vozlišče pošlje svoj WFG vozlišču, ki je nad njim v
hierarhiji
– Primer hierarhije za 8 vozlišč
Raven 4: globalna detekcija
mrtvih zank
Raven 3: detekcija mrtvih
zank štirih sosedov
Raven 2: detekcija mrtvih
zank dveh sosedov
Raven 1: lokalna detekcija
mrtvih zank
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 327 -
Detekcija mrtvih zank v SUPPB...
 Hierarhični detekcija (nadaljevanje)
– Prednost pred centraliziranim pristopom: manjša odvisnost
od centralnega vozlišča.
– Slabost je kompleksnost implementacije
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 328 -
Detekcija mrtvih zank v SUPPB...
 Porazdeljena detekcija:
– Obstajajo številni algoritmi za porazdeljeno detekcijo mrtvih
zank
– Primer algoritma:
 Lokalnemu WFG pridobi dodatno vozlišče Text, ki predstavlja del
transakcije, izvajane na nekem drugem vozlišču.
 Npr., če T1 na S1 požene del transakcije na S2, dodamo povezavo v
lokalni WFG, ki kaže iz T1 v Text.
T1 pognana na S1, njen del pa tudi na S2
T2 pognana na S2, njen del pa tudi na S3
- 329 T3 pognana na S3, njen del pa tudi na S1
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Detekcija mrtvih zank v SUPPB...
 Porazdeljena detekcija (nadaljevanje):
– Če na lokalnem WFG identificiran cikel, ki ne vključuje Text,
potem vozlišče in SUPPB v mrtvi zanki. Mrtvo zanko
odpravimo lokalno.
– Če na lokalnem WFG identificiran cikel, ki vključuje Text,
potem potencialno obstaja globalna mrtva zanka. Da
ugotovimo, če zanka obstaja, moramo združiti lokalna grafa.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 330 -
P 3.4
Obnova podatkov po nesrečah
Kaj si bomo pogledali?






PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Potreba po obnovljivosti
Transakcije in obnovljivost
Komponente SUPB za obvladovanje obnovljivosti
Tehnike obnovljivosti
Obnovljivost v porazdeljenih SUPB
Napredni transakcijski modeli
- 331 -
Kaj je obnova podatkov po nesreči?
 Proces vzpostavljanja podatkovne baze v zadnje
veljavno stanje, ki je veljalo pred nastopom
nesreče.
Nesreča
T1
T2
S1
S2
T3
T4
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 332 -
Potreba po obnovljivosti…
 Shranjevanje podatkov se običajno navezuje na
štiri različne tipe medijev za shranjevanje
podatkov, z naraščajočo stopnjo zanesljivosti:
– glavni pomnilnik (neobstojni pomnilnik): podatki v njem ne
preživijo sistemskih nesreč,
– magnetni disk (“online” obstojni pomnilnik): zaneslivejši in
cenejši od glavnega pomnilnika, vendar tudi počasnejši,
– magnetni trak (“offline” obstojni pomnilnik): še zaneslivejši
in cenejši od diska, vendar tudi počasnejši, omogoča samo
zaporedni dostop,
– optični disk: najzaneslivejši od vseh, še cenejši od traku,
hitrejši od traku, omogoča neposredni dostop do podatkov.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 333 -
Potreba po obnovljivosti…
 Obstaja več vrst nesreč, od katerih je potrebno
vsako obravnavati na drugačen način.
 Nesreča lahko prizidane podatke tako v glavnem,
kot v sekundarnem pomnilniku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 334 -
Potreba po obnovljivosti…
 Vzroki za nesreče:
– odpoved sistema: zaradi napak v strojni ali programski
opremi; posledica je izguba podatkov v glavnem pomnilniku,
– poškodbe medija: zaradi trka glave diska ob magnetno
površino postane medij neberljiv; posledica so neberljivi deli
sekundarnega pomnilnika,
– programska napaka v aplikaciji: zaradi logične napake v
programu, ki dostopa do podatkov v PB, pride do napak v
eni ali več transakcijah,
– neprevidnost: zaradi nenamernega uničenja podatkov s
strani administratorjev ali uporabnikov,
– sabotaža (namerno oviranje dela): zaradi namernega
popačenja ali uničenja podatkov, uničenja programske ali
strojne opreme.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 335 -
Potreba po obnovljivosti
 Ne glede na vrsto napake, vedno smo pri
nesrečah soočeni z dvema bistvenima
problemoma:
– izguba podatkov v glavnem pomnilniku (vključno s podatki v
medpomnilniku),
– izguba podatkov na sekundarnem pomnilniku.
 V nadaljevanju:
– pregled tehnik za lajšanje posledic nesreče in
– tehnike za obnavljanje po nesreči.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 336 -
Transakcije in obnovljivost…
 Transakcija predstavlja osnovno enoto
obnovljivosti.
 Za obnovljivost skrbi upravljavec za obnovljivost
(recovery manager), ki mora v primeru nesreče
zagotavljati dve od štirih lastnosti transakcij
(ACID):
– atomarnost in
– trajnost.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 337 -
Transakcije in obnovljivost…
 Naloga upravitelja obnovljivosti je, da pri
obnovitvi PB po nesreči zagotovi:
– da se vse spremembe, ki so bile v PB izvedene v okviru
posamične transakcije uveljavijo v celoti ali pa
– da se ne uveljavi nobena sprememba.
 Problem je kompleksen, ker pisanje v PB ne
predstavlja atomarne akcije  transakcija lahko
izvede COMMIT (uveljavitev sprememb), vendar
se spremembe v PB ne zabeležijo, ker enostavno
ne “dosežejo” PB (nastop nesreče).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 338 -
Transakcije in obnovljivost…
 Podatkovni vmesniki so področje v glavnem
pomnilniku, v katerega se pri prenašanju
podatkov iz/v sekundarnega pomnilnika podatki
pišejo ali iz njega berejo.
 Prenos vsebine podatkovnih vmesnikov v
sekundarni pomnilnik (trajne spremembe) se
sproži samo v primeru izvedbe posebnih ukazov:
– COMMIT ali
– avtomatično, ko postanejo podatkovni vmesniki polno
zasedeni (eksplicitno zapisovanje vsebine podatkovnih
vmesnikov v sekundarni pomnilnik označujemo kot prisilno
zapisovanje (force-writing)).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 339 -
Transakcije in obnovljivost…
 Če se nesreča pripeti med pisanjem v pod.
vmesnike ali med prenosom podatkov iz pod.
vmesnikov v sek. pomnilnik, mora upravitelj za
obnovljivost ugotoviti status transakcije, ki je
izvajala pisanje v času nesreče:
– če je transakcija izvedla ukaz COMMIT, mora upravitelj za
obnovljivost zaradi zagotavljanja lastnosti trajnosti zagotoviti
ponovno izvajanje transakcije (Rollforward ali Redo),
– če transakcija ni izvedla ukaza COMMIT, mora upravitelj za
obnovljivost zaradi zagotavljanja lastnosti atomarnosti izvesti
razveljavljanje posodobitev, ki jih je do tedaj transakcija
izvedla (Rollback ali Undo).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 340 -
Transakcije in obnovljivost…
 Če je potrebno razveljaviti samo eno transakcijo
govorimo o parcialnem razveljavljanju (partial
undo). Ta se izvaja tudi pri sočasnem dostopanju
do podatkov zaradi uporabe protokolov za nadzor
sočasnosti.
 Če je potrebno razveljaviti vse v času nesreče
aktivne transakcije, govorimo o globalni
razveljavitvi (global undo).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 341 -
PRIMER: uporaba UNDO/REDO
 Transakcije T1 do T6 se izvajajo sočasno, SUPB
začne delovati ob t0, nesreča pa nastopi ob tf:
 T2 in T3 izvedeta COMMIT in spremembe se
uveljavijo v PB.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 342 -
PRIMER: uporaba UNDO/REDO
 T1 in T6 ne izvedeta ukaza COMMIT do trenutka
nesreče, zato jih upravitelj za obnavljanje pri
ponovnem zagonu razveljavi (UNDO).
 Za T4 in T5 ni jasno, do katere mere so se njune
spremembe uveljavile v PB - ali je bila vsebina
podatkovnih vmesnikov zapisana v sekundarni
pomnilnik ali ne.
– Ker nimamo na razpolago nobene dodatne informacije o
stanju transakcij, je upravitelj za obnavljanje prisiljen
ponoviti (REDO) transakcije T2, T3, T4 in T5.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 343 -
Upravljanje z medpomnilnikom…
 Upravljalec z medpomnilnikom zadolžen za
upravljanje s pod. vmesniki, ki se uporabljajo za
prenos podatkov med glavnim in sek. pomn.:
– Branje podatkov iz sekundarnega pomnilnika v vmesnike,
dokler niso zapolnjeni in
– Uporaba strategije zamenjave, ki določa, kateri vmesniki se
zapišejo v PB z namenom sprostitve vmesnikov za branje
novih podatkov.
 Poznamo različne strategije zamenjave, npr.:
FIFO in LRU.
 Upravljalec medpomnilnika ne sme prebrati strani
iz diska, če se ta že nahaja v medpomnilniku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 344 -
Upravljanje z medpomnilnikom…
 Z vidika obnavljanja PB se pri zapisovanju strani
na disk, za katero skrbi upravitelj medpomnilnika,
uporablja naslednja terminologija:
– Steal policy: omogoča, da upravitelj medpomnilnika zapiše
vsebino podatkovnega vmesnika na disk preden transakcija
izda ukaz COMMIT (preden pinCount=0). Z drugimi
besedami, upravitelj transakciji “ukrade” stran. Alternativna
politika: no-steal.
– Force policy: zagotavlja, da se vse strani, ki jih transakcija
posodobi zapišejo na disk, takoj ko transakcija izda ukaz
COMMIT. Alternativna politika: no-force.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 345 -
Upravljanje z medpomnilnikom
 Z vidika implementacije je najpreprostejša
uporaba politik no-steal in force:
– no-steal: ni potrebno razveljavljati posodobitev ponesrečenih
transakcij v PB, ker se spremembe še niso zapisale na disk,
– force: ni potrebno ponoviti sprememb, ki so jih povzročile
uveljavljene transakcije, ki so se ponesrečile po izdaji ukaza
COMMIT, ker se spremembe zapišejo v PB takoj ob
COMMIT-u.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 346 -
Upravljanje z medpomnilnikom
 Po drugi strani:
– steal: se izogne potrebi po velikem medpomnilnem prostoru
za shranjevanje posodobljenih strani,
– no-force: ni potrebno izvajati večkratnega zapisovanja
posodobljene strani na disk s strani več transakcij.
 Zaradi omenjenih razlogov večina SUPB-jev
implementira steal, no-force politiko.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 347 -
Komponente SUPB za obnovljivost
 V okviru SUPB so za obnavljanje podatkov po
nesreči na voljo naslednje komponente:
– mehanizem za izdelavo varnostnih kopij, ki periodično kreira
kopije PB,
– dnevnik, ki hrani podatke o trenutnem stanju transakcij in
spremembah v PB,
– mehanizem za izvajanje kontrolnih točk, ki omogoča da se
posodobitve, ki jih izvajajo transakcije v PB, ohranijo
(zahteva po izpisu vseh datotečnih vmesnikov na disk),
– upravljalec za obnovljivost, komponenta SUPB, ki omogoča
obnoviti podatkovno bazo v zadnje konsistentno stanje, ki je
veljalo pred nastopom nesreče.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 348 -
Mehanizem za izdelavo varnostnih kopij…
 Mehanizem mora omogočati izdelavo varnostnih
kopij PB in dnevnika v določenih intervalih, ne da
bi pred tem bilo potrebno prekiniti delovanje PB .
 Kopijo PB se uporabi v primeru poškodb PB ali
njenega uničenja.
 Varnostna kopija se običajno hrani na
magnetnem traku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 349 -
Mehanizem za izdelavo varnostnih kopij
 Varnostna kopija je lahko:
– popolna kopija PB ali
– inkrementalna kopija, ki vsebuje samo spremembe izvedene
od zadnje popolne ali inkrementalne kopije PB.
PB
Popolna
kopija PB
zadnje
spremembe
PB
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 350 -
Inkrementalna
kopija
Dnevnik…
 V dnevnik se zapisujejo vse spremembe, ki jih
transakcije izvedejo v PB.
 Dnevnik lahko vsebuje naslednje podatke:
– transakcijske zapise, kjer je dnevniški zapis sestavljen iz:
 identifikatorja transakcije,
 tipa dnevniškega vpisa (začetek tr., insert, update, detele, abort,
commit),
 identifikator podatka, na katerega se nanaša operacija (operacije:
insert, delete, update) v okviru transakcije,
 predhodna vrednost podatka: vrednost podatka pred ažuriranjem
(samo za operacije update in delete),
 vrednost podatka po ažuriranju (samo za operacije insert in update),
 podatki potrebni za upravljanje dnevnika: kazalec na prejšnji in
naslednji dnevniški zapis, ki pripada določeni transakciji.
– zapise kontrolnih točk.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 351 -
Dnevnik…
 Primer segmenta dnevniške datoteke, ki
prikazuje tri sočasne transakcije T1, T2 in T3.
Stolpca pPtr in nPtr predstavljata kazalce na
predhodni in naslednji dnevniški vpis.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 352 -
Dnevnik…
 Zaradi pomembne vloge dnevnika pri
obnavljanju podatkov po nesrečah, je ta
podvojen ali celo potrojen.
 Včasih je bil dnevnik shranjen na magnetnem
traku (zanesljivejši in cenejši).
 Danes se pričakuje, da je SUPB pri manjših
nesrečah sposoben hitro obnoviti PB v stanje
pred nesrečo. To zahteva, da se dnevnik
hrani na disku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 353 -
Dnevnik…
 V okoljih, kjer se v dnevnike piše velika količina
podatkov (reda 10 GB), podatkov ni moč imeti
ves čas na razpolago - “online”.
 V dnevniku morajo biti na razpolago samo
podatki za hitro obnavljanje:
– manjše nesreče (npr.: razveljavitev transakcije, ki bi lahko
povzročila mrtvo zanko) – možno hitro obnavljanje.
– Večje napake (npr.: udarec glave diska v magnetno
površino) zahtevajo več časa za obnovitev in navadno večjo
količino podatkov iz dnevnika. V takih primerih prenos
podatkov iz magnetnega traku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 354 -
Dnevnik
 Realizacija dnevnika, ki podpira uporabo “offline”
sekundarnega pomnilnika (magnetni trak):
– na disku se vzdržujeta dve dnevniški datoteki, A in B
– V A se vpisujejo podatki, dokler ta ni 70% zasedena,
– Ko A doseže 70%, se izvede preklop na B in zapisi novih
transakcij se nato vpisujejo v B,
– transakcije, ki se do preklopa še niso zaključile, pišejo naprej
v A, dokler se ne zaključijo; A se zatem zapre,
– ko se A zapre, se prepiše na magnetni trak (offline
pomnilnik),
– ko je B 70% polna, se izvede preklop nazaj na A,
– …
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 355 -
Mehanizem za izvajanje kontrolnih točk…
 Podatki iz dnevnika se rabijo za obnovitev PB po
nesreči  pri obnavljanju ne vemo, koliko
dnevniških vpisov je potrebno prebrati, ne da bi
ponavljali transakcije, ki so se v PB že uspešno
uveljavile.
 Količino presežnega iskanja in procesiranja zaradi
pregledovanja dnevniških vpisov lahko omejimo z
uporabo kontrolnih točk.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 356 -
Mehanizem za izvajanje kontrolnih točk…
 Kontrolna točka: točka sinhronizacije med PB in
dnevnikom. Izvede se zahteva po izpisu vseh
podatkovnih vmesnikov na disk.
– Tako smo prepričani, da so bile transakcije, ki so bile
zaključene pred izpisom vmesnikov, zanesljivo uveljavljene
ali razveljavljene v PB na disku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 357 -
Mehanizem za izvajanje kontrolnih točk…
 Kontrolne točke se izvajajo po vnaprej določenem
urniku in vključujejo naslednje operacije:
– zapisovanje vseh dnevniških vpisov iz glavnega pomnilnika v
sekundarni pomnilnik (neposredno iz pomnilnika na disk!!!),
– zapisovanje posodobljenih blokov v podatkovnih vmesnikih v
sekundarni pomnilnik,
– zapisovanje zapisa kontrolne točke v dnevnik. Ta zapis
vključuje identifikatorje vseh transakcij, ki so bile v času
izvedbe kontrolne točke aktivne.
 Če se transakcije izvajajo zaporedno, potem je v
dnevniku potrebno poiskati zadnjo transakcijo, ki
se je pričela izvajati pred izvedbo zadnje
kontrolne točke.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 358 -
Mehanizem za izvajanje kontrolnih točk...
 Vse transakcije pred prej omenjeno tr. so že bile
uveljavljene (commited) in njihove spremembe
zapisane v PB v času izvedbe kontrolne točke.
 Zaradi tega je potrebno ponoviti samo
transakcijo, ki je bila aktivna v času izvedbe
kontrolne točke in vse transakcije, ki so ji sledile,
katerih zapisi se nahajajo v dnevniku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 359 -
Mehanizem za izvajanje kontrolnih točk...
 Če je transakcija aktivna v trenutku nastopa
nesreče, jo je potrebno razveljaviti.
 Če se transakcije izvajajo sočasno, je potrebno
ponoviti vse transakcije, ki so izdale ukaz commit
od zadnje kontrolne točke naprej in razveljaviti
vse transakcije, ki so bile aktivne v času nastopa
nesreče.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 360 -
UNDO in REDO s kontrolno točko
 Predpostavimo, da se je v času tc izvedla
kontrolna točka:
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 361 -
UNDO in REDO s kontrolno točko
 Spremembe transakcije T2 in T3 se zapišejo v
sekundarni pomnilnik.
 Upravitelju za obnavljanje ni potrebno ponoviti
izvajanje transakcij T2 in T3.
 Transakcije T4 in T5 je potrebno ponoviti, ker so
ukaz commit izdale po izvedbi kontrolne točke.
 Transakcije T1 in T6 pa je potrebno razveljaviti,
ker so bile v času nastopa nesreče aktivne.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 362 -
Mehanizem za izvajanje kontrolnih točk
 Na splošno velja, da je uporaba kontrolnih točk
relativno poceni operacija.
 Ponavadi je mogoče izvesti 3 do 4 kontrolne
točke na uro.
 Na ta način je možno zagotoviti, da bo potrebno
obnoviti samo podatke iz zadnjih 15-20 minut
obratovanja PB.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 363 -
Tehnike obnovljivosti…
 Uporaba posamezne procedure za obnavljanje
podatkov v PB po nesreči je odvisna od obsega
nastale škode. Razlikujemo dva primera:
 Obsežne poškodbe PB:
– vzrok: npr. diskovna nesreča.
– posledica nesreče: uničena podatkovna baza.
– podatke se obnovi z uporabo kopije PB in dnevnika; podatki
iz dnevnika služijo za ponovitev (redo) uveljavljenih
transakcij.
– ta način obnavljanja predvideva, da dnevnik ni bil
poškodovan; dnevnik naj se torej nahaja na disku, ki je
ločen od podatkovnih datotek.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 364 -
Tehnike obnovljivosti…
 Manjše poškodbe; PB ni fizično poškodovana:
– vzrok: odpoved sistema med izvajanjem transakcij.
– posledica nesreče: PB preide v neveljavno – nekonsistentno
stanje.
– transakcije, ki so se prekinile je potrebno razveljaviti, ker so
postavile PB v nekonsistentno stanje.
– lahko se tudi zgodi, da je nekatere transakcije potrebno
ponoviti, če njihove spremembe niso “dosegle”
sekundarnega pomnilnika.
– v tem primeru za obnavljanje ne potrebujemo kopije PB,
ampak zadostujejo predhodne in posodobljene vrednosti
podatkov, ki se nahajajo v dnevniških vpisih (glej primer
izseka iz dnevnika).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 365 -
Tehnike obnovljivosti…
 V nadaljevanju: predstavitev dveh tehnik za
obnavljanje PB po nesrečah, ki ne povzročijo
uničenja PB, ampak privedejo PB v
nekonsistentno stanje:
– odloženo ažuriranje in
– sprotno ažuriranje.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 366 -
Tehnike obnovljivosti…
 Tehnike obnovljivosti podatkov po nesrečah, ki
privedejo PB v nekonsistentno stanje:
– odloženo ažuriranje,
– sprotno ažuriranje in
– uporaba senčnih strani.
 Odloženo in sprotno ažuriranje se ločita po
načinu zapisovanja posodobljenih podatkov v PB,
obe pa uporabljata dnevnik.
 Senčne strani ne uporabljajo dnevnika.
 Obnovitvene tehnike morajo biti za uporabnika
transparentne!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 367 -
Odloženo ažuriranje…
 Pri protokolu za odloženo ažuriranje se podatki
(posodobljeni) ne zapisujejo neposredno v PB.
 Vsa ažuriranja v okviru transakcije se najprej
shranijo v dnevnik. Pri uspešnem zaključku
transakcije se izvede dejansko ažuriranje PB.
 V primeru nesreče:
– če se transakcija prekine, v PB ni potrebno razveljaviti
nobene spremembe, ker se te nahajajo samo v dnevniku,
– pred nesrečo uspešno zaključene transakcije je potrebno
ponoviti (redo), ker se njihova ažuriranja lahko še niso
dejansko zapisala v PB. V tem primeru se uporabi zapise
shranjene v dnevniku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 368 -
Odloženo ažuriranje…
 Uporaba dnevnika za obnavljanje podatkov v
primeru odloženega ažuriranja:
– Ob začetku transakcije vpis v dnevnik “transaction start”.
– Ob vsaki operaciji zapisovanja se v dnevnik vnese zapis,
razen stara vrednost ažuriranega podatka. Ažuriran podatek
se dejansko ne vpiše v podatkovni vmesnik ali PB.
– Preden transakcija izvede ukaz COMMIT, se v dnevnik vnese
zapis “transaction commit”, vsi pripadajoči dnevniški zapisi
se zapišejo na disk (dnevniško datoteko), sledi njeno
uveljavljanje  zapisi iz dnevnika se uporabijo za dejansko
posodabljanje podatkov v PB. SUPB nato zbriše transakcijo iz
liste aktivnih transakcij.
– Če se transakcija prekine, se njene dnevniške zapise ne
upošteva in zapisovanje v PB se ne izvede.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 369 -
Odloženo ažuriranje…
 Dnevniški zapisi določene transakcije se zapišejo
na disk, preden se njena ažuriranja dejansko
uveljavijo.
 Če se sistemska nesreča pripeti med ažuriranjem
podatkov v PB, ostanejo njeni dnevniški zapisi
ohranjeni in uveljavljanje (COMMIT) sprememb
se lahko ponovi kasneje.
 Pri obnavljanju je po nesreči v dnevniku potrebno
poiskati transakcije, ki so bile v času nesreče
aktivne  branje dnevniških zapisov v smeri
nazaj do zadnje kontrolne točke…
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 370 -
Odloženo ažuriranje…
 Obnavljanje po nesreči poteka na naslednji
način:
– Vsako transakcijo, za katero v dnevniku obstajata zapisa
“transaction start” in “transaction commit”, je potrebno
ponoviti:
 Uporabijo se dnevniški zapisi transakcije v takem vrstnem redu, kot
so bili dodani v dnevnik (dnevniški zapisi vsebujejo nove vrednosti
ažuriranih podatkov).
 Če je bilo zapisovanje ažuriranj transakcije izvedeno že pred
nesrečo, pisanje v PB nima nobenega učinka  s ponovnim
zapisovanje ažuriranega podatka v PB ne naredimo nobene škode.
 Metoda zagotavlja, da se v PB posodobi vsak podatek, ki pred
nesrečo ni bil pravilno posodobljen.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 371 -
Odloženo ažuriranje
– Za vsako transakcijo, za katero v dnevniku obstajata zapisa
“transaction start” in “transaction abort”, se ne izvede
ničesar. Ker do dejanskega zapisovanj podatkov v PB sploh
ne pride, transakcije ni potrebno razveljavljati (ROLLBACK).
 Med obnavljanjem lahko ponovno nastopi
nesreča zapisi iz dnevnika se ponovno
uporabijo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 372 -
Sprotno ažuriranje…
 Pri uporabi protokola sprotnega ažuriranja
transakcija izvaja neposredno spreminjanje
podatkov v PB še preden se uspešno zaključi.
 V primeru nesreče je poleg ponavljanja (redo)
uspešno zaključenih transakcij, potrebno
razveljaviti (rollback) vse transakcije, ki so bile
aktivne v času nesreče.
 V primeru sprotnega ažuriranja se za zaščito pred
sistemskimi nesrečami uporabi dnevnik.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 373 -
Sprotno ažuriranje…
 Način uporabe dnevnika pri sprotnem ažuriranju.
– Ob začetku transakcije se v dnevnik vnese zapis “transaction
start”.
– Pri zapisovanju podatka se v dnevnik vnese ustrezen
dnevniški zapis.
– Ko je dnevniški zapis vnesen, se posodobljen podatek zapiše
v podatkovni vmesnik (medpomnilnik).
– Dejansko posodabljanje PB se izvede ob prvem naslednjem
prenosu vsebine podatkovnih vmesnikov na disk.
– Ko transakcija izvede COMMIT, se v dnevnik doda zapis
“transaction commit”, transakcija pa se izbriše iz liste
aktivnih transakcij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 374 -
Sprotno ažuriranje…
 POMEMBNO: Pri ažuriranju se morajo zapisi
najprej vnesti v dnevnik, šele nato v PB 
“write-ahead log protocol”.
 V obratnem primeru, če bi se nesreča pojavila
pred zapisovanjem zapisa v dnevnik, upravljalec
za obnovljivost ne bi mogel razveljaviti oz.
uveljaviti operacije, ki jo definira dnevniški vpis.
 Z uporabo write-ahead log protokola upravljalec
obnovljivosti lahko predpostavi:
– Če v dnevniku ni zapisa “transaction commit”  transakcija
je bila v času nesreče aktivna in jo je pri obnavljanju
potrebno razveljaviti (undo).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 375 -
Sprotno ažuriranje…
 Če se transakcija prekine s strani aplikacije, se
dnevnik uporabi za razveljavitev sprememb v PB
(stare vrednosti posodobljenih zapisov).
 Transakcija lahko nad določenim podatkom
izvede več sprememb  spremembe se
razveljavijo v obratnem vrstnem redu.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 376 -
Sprotno ažuriranje
 Obnavljanje po nesreči poteka na naslednji
način:
– Vsako transakcijo, za katero v dnevniku obstajata zapisa
“transaction start” in “transaction commit”, se ponovi (redo)
z uporabo novih vrednosti ažurirarnih podatkov  korak je
potreben ker se določena pisanja v PB lahko niso izvedla.
– Vsako transakcijo, za katero v dnevniku obstaja le zapis
“transaction start” (brez “commit”), je potrebno razveljaviti
(undo):
 uporabijo se dnevniški zapisi in sicer stare vrednosti spremenjenih
podatkov,
 spremembe se razveljavljajo v obratnem vrstnem redu kot so bile
vnesene v dnevnik.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 377 -
Primerjava odloženega in sprotnega
ažuriranja
 Z vidika učinkovitosti:
– Odloženo ažuriranje je učinkovitejše, če se v povprečju
izvede več neuspešnih transakcij (ni potrebno spreminjati
PB).
– Sprotno ažuriranje je učinkovitejše, če se v povprečju izvede
več uspešnih transakcij (ni potrebno veliko popravljati
podatkov v PB).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 378 -
Uporaba senčnih strani…
 Obnavljanje s pomočjo senčnih strani temelji na
uporabi dveh “tabel strani”:
– tekoča tabela strani,
– senčna tabela strani.
Tekoča tabela strani
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Strani podatkovne baze
Senčna tabela strani
1
1
2
2
3
3
4
4
- 379 -
Uporaba senčnih strani…
 Princip delovanja:
– Strani glavnega pomnilnika, ki so bile ažurirane, se ne
zapisujejo neposredno v PB, ampak na nezasedene bloke na
disku.
– Če se transakcija zaključi uspešno, se omenjeni novi bloki na
disku vključijo v PB, namesto starih - neažuriranih.
– Na začetku transakcije sta obe tabeli identični. Tekoča tabela
strani se nahaja v glavnem pomnilniku, senčna pa na disku.
– V primeru nesreče, ko se izda ukaz Pozabi, se tekoča tabela
strani preprosto prepiše s senčno tabelo in v PB ni sledu o
ažuriranjih, ki so se v okviru transakcij izvedla.
– Po uspešnem zaključku transakcije se tekoča tabela strani
izpiše na prosto mesto na disku in postane senčna tabela
strani.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 380 -
Uporaba senčnih strani
 Prednosti uporabe senčni strani:
– vzdrževanje dnevnika odpade,
– obnavljanje podatkov je občutno hitrejše, ker ni potrebno
ponavljati ali razveljavljati operacij transakcij.
 Slabosti uporabe senčnih strani:
– razdrobljenost (fragmentacija) podatkov na disku,
– potreba po periodičnem “čiščenju” neuporabljenih strani na
disku  obnavljanje prostega prostora na disku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 381 -
Obnovljivost v porazdeljenih SUPB…
 Porazdeljena podatkovna baza (SUPPB) se sestoji iz logično
povezanih PB, ki so fizično porazdeljene na različnih lokacijah in
povezane z računalniškim omrežjem.
 V SUPPB se izvajajo porazdeljene transakcije, ki se
dekomponirajo v več pod-transakcij, ki se izvajajo na lokalnih
SUPB-jih.
 Atomarnost je potrebno zagotoviti na nivoju pod-transakcij in na
nivoju celotne porazdeljene transakcije.
pod-transakcija 1
Strežnik 2
Porazdeljena
transakcija
Strežnik 1
Strežnik 3
Komunikacijsko omrežje
pod-transakcija 2
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 382 -
Strežnik 5
Strežnik 4
Obnovljivost v porazdeljenih SUPB
 Predstavljene tehnike za obnavljanje podatkov
zagotavljajo atomarnost transakcij na ravni
lokalnih SUPB.
 Atomarnost porazdeljene transakcije je
zagotovljena tako da:
– se vse pod-transakcije uspešno izvedejo (vse izvedejo
COMMIT) ali
– pa se vse prekinejo (ROLLBACK).
 Dva protokola za porazdeljeno obnavljanje: dvo
in trifazno potrjevanje (2FC in 3FC).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 383 -
SUPPB odvisen od omrežja
 SUPPB je močno odvisen od sposobnosti
komunikacije med vsemi vozlišči.
 Če pride do komunikacijske okvare, se lahko
omrežje razdeli na dve ali več particij.
 V porazdeljenih sistemih oteženo ugotavljanje
izvora napake/nedelovanja; ne vemo, ali je
težava v povezavi ali v posameznem vozlišču…
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 384 -
2PC protokol…
 2PC = Two Phase Commit
 Dve fazi: volilna in odločitvena faza
– Koordinator vpraša vsa sodelujoča lokalna mesta, ali so
pripravljena potrditi svoje dele transakcije;
– Če neko mesto glasuje za prekinitev ali se ne odzove v
določenem času, koordinator sporoči vsem ostalim mestom,
da prekinejo svoje dele transakcije.
– Če vsa mesta glasujejo za potrditev transakcije, koordinator
vsem mestom naroči, da svoje dele transakcije potrdijo.
– Vsa sodelujoča mesta morajo spoštovati skupno odločitev.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 385 -
2PC protokol…
 Dodatna pravila:
– Če neko mesto glasuje za prekinitev transakcije, lahko to
naredi takoj.
– Če glasuje za potrditev, mora počakati, da koordinator
sporoči globalno sporočilo o potrditvi ali prekinitvi
transakcije.
– 2PC predvideva, da ima vsako mesto svoj lokalni dnevnik in
lahko zanesljivo izvede potrditev ali prekinitev transakcije.
– Če mesto ne uspe glasovati, se predvideva, da je glasovalo
za prekinitev.
– Če mesto s strani koordinatorja ne prejme ukaza za
glasovanje, lahko svoj del transakcije prekine.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 386 -
Commit
Primer: 2PC, mesto glasuje potrditev
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 387 -
Abort
Primer: 2PC, mesto glasuje prekinitev
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 388 -
2PC – protokol zaključevanja…
 Protokol zaključevanja se prične, če koordinator
ali sodelujoče mesto ne dobi predvidenega
sporočila v določenem času.
KOORDINATOR
 V procesu potrjevanja je
koordinator lahko v enem
izmed štirih stanj 
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 389 -
2PC – protokol zaključevanja…
 Protokol zaključevanja se pri koordinatorju lahko
prične, če pride do zakasnitve v stanju WAITING
ali DECIDED.
 Timeout v stanju WAITING:
– Koordinator čaka mesta, da sporočijo svoje glasove. Dokler
ne prejme vseh glasov, ne more zaključiti. Druga možnost je
globalna prekinitev transakcije.
 Timeout v stanju DECIDED:
– Koordinator čaka na odziv mest, da mu sporočijo, ali so
uspešno izvedle ukaz (potrditev/prekinitev). Po določenem
času pošlje globalno odločitev ponovno, in sicer mestom, ki
se še niso odzvala.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 390 -
2PC – protokol zaključevanja…
SODELUJOČE MESTO
 Najenostavnejši protokol zaključevanja je, da
mesto pustimo blokirano, dokler komunikacija s
koordinatorjem ni ponovno vzpostavljena.
 Druge možnosti:
– Timeout in INITIAL state
– Unilaterally abort transaction.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 391 -
2PC – protokol zaključevanja
 Timeout v stanju INITIAL:
– Mesto čaka na koordinatorjevo sporočilo PREPARE; če tega
ni, predpostavimo napako v stanju INITIAL. Mesto lahko
enostransko prekine transakcijo!
– Če kasneje prejme PREPARE sporočilo, ga bodisi ignorira ali
pošlje sporočilo o prekinitvi.
 Timeout v stanju PREPARED:
– Mesto čaka na sporočilo koordinatorja o globalni odločitvi.
Brez nadaljnjih informacij mesto blokirano.
– Lahko se posvetuje z drugimi mesti, ki morda že vedo,
kakšna je globalna odločitev  kooperativni protokol
zaključevanja.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 392 -
2PC protokol obnovitve podatkov…
 Akcije obnovitve podatkov odvisne od stanja, v
katerem se mesta oziroma koordinator nahajajo.
 Napaka koordinatorja:
– Napaka v stanju INITIAL: Procesa potrjevanja se še ni začel:
POP sproži proces potrjevanja.
– Napaka v stanju WAITING: Sporočilo PREPARE poslano. Ni
vseh odzivov, med prejetimi nobenega o prekinitvi. POP
ponovno požene proces potrjevanja.
– Napaka v stanju DECIDED: Globalna odločitev posredovana.
V primeru ponovnega zagona, če koordinator prejel vse
potrditve, lahko uspešno zaključi. Sicer požene protokol
zaključevanja.
POP – Protokol Obnovitve Podatkov
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 393 -
2PC protokol obnovitve podatkov
 Napaka mesta:
– Cilj: zagotoviti, da mesto v primeru ponovnega zagona
izvede iste akcije kot druga mesta ter omogočiti, da mesto
neodvisno izvede ponovni zagon.
– Napaka v stanju INITIAL: mesto še ni oddalo glasu  v
primeru obnove lahko transakcijo enostransko prekine, saj
koordinator ni mogel sprejeti odločitve o potrditvi.
– Napaka v stanju PREPARED: mesto poslalo svoj glas
koordinatorju Obnavljanje po protokolu zaključevanja.
– Napaka v stanju ABORTED/COMMITTED: mesto zaključilo
transakcijo. V primeru ponovnega zagona ni potrebna
nobena dodatna akcija.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 394 -
Protokol izvolitve novega koordinatorja…
 Če sodelujoča mesta detektirajo napako
koordinatorja (timeout), lahko izvolijo novega
koordinatorja.
 Možen protokol:
– Mesta so linearno oštevilčena. Koordinator ima številko 1,
mesto Si pa številko i.
– Mesta poznajo svojo označbo ter označbe drugih mest, med
katerimi nekatera morda ne delujejo.
– Po protokolu vsa delujoča mesta pošljejo sporočila vsem
mestom, ki imajo večjo označbo, po vrsti. Si, pošlje najprej
sporočilo Si+1, nato Si+2 itn. Če mesto Sk prejme sporočilo od
mesta z nižjo označbo, ve, da ne bo koordinator in preneha
s pošiljanjem sporočil.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 395 -
Protokol izvolitve novega koordinatorja
 Protokol učinkovit
– Večina mest preneha s pošiljanjem sporočil relativno kmalu.
– Sčasoma vsako mesto ve, ali obstaja delujoče mesto z nižjo
označbo. Če ne obstaja, pomeni, da mesto prevzema vlogo
koordinatorja.
– Če tudi novo izvoljeni koordinator “zmrzne” v procesu
potrjevanja, se protokol izvolitve novega koordinatorja
ponovno zažene.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 396 -
3PC protokol…
 2PC ne preprečuje blokiranja mesta.
– Primer: mesto glasuje za potrditev, vendar ne prejme
končne odločitve. Če se lahko pogovarja le z drugimi mesti,
ki tudi ne poznajo končne odločitve, je blokirano.
– Verjetnost, da pride do blokiranja, v praksi majhno  večina
sistemov uporablja 2PC.
 Alternativa uporaba protokola 3PC, ki preprečuje
blokiranje.
 3PC = Three Phase Protocol
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 397 -
3PC protokol…
 Preprečuje blokiranje v primeru odpovedi mest,
razen, če odpovedo vsa mesta.
 Komunikacijske napake lahko privedejo do
situacije, ko različna mesta sprejemajo različne
odločitve  ogrožena atomarnost transakcije.
 3PC zmanjša obdobje negotovosti za mesta, ki so
glasovala za potrditev in čakajo na globalno
odločitev!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 398 -
3PC protokol…
 3PC uvaja tretjo fazo PRE-COMMIT, ki nastopi
med glasovanjem in globalno odločitvijo.
 V primeru sprejema vseh glasov, koordinator
pošlje globalno pred-potrditveno sporočilo.
 Mesto, ki prejme globalno pred-potrditev, ve, da
so vsa ostala mesta glasovala za potrditev 
potrditev možna.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 399 -
3PC protokol…
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 400 -
Commit
Primer: 3PC, mesto glasuje potrditev
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 401 -
Protokol zaključevanja…
KOORDINATOR
 Timeout v stanju WAITING:
– Enako kot pri 2PC. Globalno zavrne transakcijo.
 Timeout v stanju PRE-COMMITTED:
– Vpiše commit zapis v dnevnik
– Pošlje globalno potrditveno sporočilo.
 Timeout v stanju DECIDED:
– Enako kot pri 2PC. Ponovno pošlje globalno odločitev
mestom, ki niso potrdila prejema.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 402 -
Protokol zaključevanja
SODELUJOČE MESTO
 Timeout v stanju INITIAL:
– Enako kot pri 2PC. Enostransko zavrne transakcijo.
 Timeout v stanju PREPARED:
– Po protokolu za izvolitev novega koordinatorja.
 Timeout v stanju PRE-COMMITTED:
– Po protokolu za izvolitev novega koordinatorja.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 403 -
3PC protokol obnovitve podatkov…
 Napaka koordinatorja:
– Napaka v stanju INITIAL: Potrjevanje še ni bilo pognano s
strani koordinatorja. POP požene proces potrjevanja.
– Napaka v stanju WAITING: mesta so morda izvolila novega
koordinatorja in zaključila transakcijo. Kontaktira druga
mesta, da ugotovi usodo transakcije.
– Napaka v stanju PRE-COMMITTED: podobno, kot pri stanju
WAITING; mesta so morda izvolila novega koordinatorja in
zaključila transakcijo. Ob restartu koordinator kontaktira
druga mesta, da ugotovi usodo transakcije.
– Napaka v stanju DECIDED: Koordinator mesta obvestil o
globalni odločitvi. Ob restartu, če prejel vsa potrdila, lahko
zaključi uspešno. Sicer požene protokol zaključevanja.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 404 -
3PC protokol obnovitve podatkov
 Napaka mesta:
– Napaka v stanju INITIAL: Mesto še ni glasovalo. V primeru
obnavljanja lahko enostransko zavrne transakcijo.
– Napaka v stanju PREPARED: Mesto je svoj glas že
posredovalo koordinatorju. V tem primeru mora kontaktirati
druga mesta, da ugotovi, usodo transakcije.
– Napaka v stanju PRE-COMMITTED: Mesto kontaktira druga
mesta, da ugotovi, usodo transakcije.
– Napaka v stanju ABORTED/COMMITTED: Mesto je svoj del
transakcije zaključilo. Dodatne akcije niso potrebne.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 405 -
3PC protokol zaključ. - nov koordinator
 Novo izvoljeni koordinator pošlje sporočilo
STATE-REQ vsem sodelujočim mestom, da
ugotovi, kako naprej.
 Pravila:
– Če neko mesto prekinilo transakcijo, potem je globalna
odločitev prekinitev;
– Če neko mesto potrdilo transakcijo, potem je globalna
odločitev potrditev;
– Če so vsa mesta negotova, potem je globalna odločitev
prekinitev;
– Če je neko mesto v PRE-COMMIT, potem je globalna
odločitev potrditev. De ne pride do blokiranja, pošli PRECOMMIT in po potrditvah še GLOBAL-COMMIT.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 406 -
Obnovljivost v ORACLE…
 Sistem ORACLE zagotavlja številne storitve za
izdelavo varnostnih kopij in obnavljanje ter s tem
zagotavljanje visoke ravni razpoložljivosti
podatkov.
 Najpomembnejše komponente za zagotavljanje
obnovljivosti v sistemu ORACLE:
– upravljalec obnovljivosti (Recovery Manager),
– obnavljanje instance PB (Instance Recovery),
– obnavljanje v določeno časovno točko (Point-in-time
recovery) in
– PB v pripravljenosti (Standby database).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 407 -
Obnovljivost v ORACLE…
 Upravljalec za obnovljivost:
– zagotavlja izdelavo varnostnih kopij PB in obnavljanje po
nesrečah:




izdelava varnostne kopije podatkovne datoteke na disk ali trak,
izdelava varnostne kopije arhiva dnevnika na disk ali trak,
restavriranje podatkovnih datotek z diska ali traku,
uporaba arhiviranih dnevnikov za izvedbo obnavljanja.
– podpira izdelavo inkrement. ali popolnih varnostnih kopij.
 Obnavljanje instance PB:
– pri ponovnem zagonu instance ORACLE detektira, da se je
zgodila nesreča in izvede obnavljanje PB s pomočjo dnevnika
(sistemske nesreče),
– podpira uporabo kontrolnih točk (parameter v datoteki
INIT.ORA).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 408 -
Obnovljivost v ORACLE…
 Obnavljanje v določeno časovno točko:
– obnavljanje PB po nesreči v stanje, ki je veljalo v določeni
časovni točki (primer: uporabnik je ponesreči zbrisal tabelo),
– razširitev možnosti na raven posamičnih logičnih skupin tabel
(tablespace).
 PB v pripravljenosti:
– ORACLE lahko vzdržuje PB v pripravljenosti uporaba pri
odpovedi primarne PB,
– PB v pripravljenosti se lahko vzdržuje na alternativni lokaciji,
kamor se pošiljajo tudi "redo" dnevniki  je skoraj
popolnoma sinhronizirana s primarno PB,
– PB v pripravljenosti je možno uporabljati za branje 
razbremenitev primarne PB.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 409 -
Napredni transakcijski modeli…
 Obravnavani protokoli za obvladovanje transakcij
so primerni za poslovne aplikacije, npr. bančni
sistemi, sistemi za rezervacije,…
 Značilnosti transakcij v poslovnih aplikacijah:
– uporaba preprostih podatkov: cela števila, decimalna števila,
kratki znakovni nizi in datumi;
– transakcije so kratkotrajne, običajno se končajo v manj kot
eni minuti ali nekaj sekundah.
 V zadnjem desetletju se pojavijo naprednejše
aplikacije, ki temeljijo na uporabi podatkovnih
baz (npr.: aplikacije za podporo načrtovanja:
CAD, CAM, CASE).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 410 -
Napredni transakcijski modeli…
 Posebnosti omenjenih aplikacij:
– Izdelovanje načrtov, ki vsebujejo več milijonov sestavnih
delov in več medsebojno odvisnih podsistemov.
– Načrt je dinamičen (se razvija skozi čas). Spremembe se
morajo odražati v vseh predstavitvah načrta, kar ni možno
vedno predvideti vnaprej.
– Spremembe so daljnosežne zaradi npr.: funkcionalnih
odvisnosti, toleranc… Ena sprememba lahko vpliva na veliko
število objektov.
– Ker obstaja več različic posamičnega elementa načrta, je
potrebno vzdrževati ustrezno različico  pojavi se potreba
po nadzoru različic oz. upravljanju s konfiguracijami.
– Načrtovanje izdelka lahko izvaja več sto ljudi, ki morajo
sodelovati in katerih delo je potrebno koordinirati.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 411 -
Napredni transakcijski modeli…
 Naštete lastnosti zahtevajo transakcije, ki:
– so kompleksne,
– dostopajo do velike količine podatkov,
– so dolgotrajne; čas izvajanja traja več ur, dni ali celo
mesecev.
 Potrebno je ugotoviti, ali so obstoječi protokoli za
obvladovanje transakcij sploh še primerni.
– uporaba obstoječih protokolov za upravljanje kompleksnih
transakcij je vprašljiva.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 412 -
Napredni transakcijski modeli…
 Protokole potrebno prilagoditi tako, da bodo kos
naslednjim problemom:
– Dolgotrajne transakcije so občutljivejše za nesreče. Take
transakcije je nesprejemljivo razveljaviti  razveljavitev
velikega števila operacij. Transakcijo se ne razveljavi, ampak
obnovi v stanje, ki je veljajo tik pred nesrečo.
– Dolgotrajne transakcije lahko zaklenejo veliko število
podatkov. Zaklepanja se ohranijo do zaključka transakcije,
kar je nesprejemljivo  omejevanje sočasnosti.
– Pri uporabi zaklepanja podatkov je verjetnost za nastop
mrtve zanke pri dolgotrajnih transakcijah višja.
– Sodelovanje med ljudmi je zagotovljeno z uporabo
podatkovnih enot v skupni rabi. Tradicionalni trans. protokoli
neprimerni  zahtevajo izolacijo nedokončanih trans.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 413 -
Napredni transakcijski modeli
 V nadaljevanju:
–
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Vgnezdeni transakcijski model
Sage
Večnivojski transakcijski model
Dinamično prestrukturiranje
Modeli delovnih tokov
- 414 -
Vgnezdeni transakcijski model…
 Vgnezdeni transakcijski model:
– Transakcija predstavlja zbirko povezanih podnalog ali
podtransakcij, od katerih lahko vsaka vsebuje še dodatne
podtransakcije (Moss).
– Obsežnejšo transakcijo se razbije  samo podtransakcije v
listih lahko izvajajo operacije nad podatkovno bazo.
Transakcije se morajo
– Primer - rezervacijski sistem:
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 415 -
potrjevati (commit)
“od spodaj navzgor”.
Naprimer: T3 in T4
morata potrditi
spremembe pred T2,
T2 pa pred T1.
Prekinitev transakcije
na določenem nivoju
ni potrebno da vpliva
na trans., ki je v teku
na višjem nivoju.
Vgnezdeni transakcijski model…
 Transakcija (starš) lahko izvede obnavljanje samega sebe:
– poizkusi ponoviti neuspešno/prekinjeno podtransakcijo,
– ignorira napako; v tem primeru se predvideva, da podtransakcija nima
vitalnega pomena za izvedbo celotne transakcije (npr. T6 v primeru),
– požene alternativno podtransakcijo (npr.: če rezervacija hotela ne uspe –
T5, se izvede rezervacija drugega hotela),
– prekinitev izvajanja (abort).
 Posodobitve transakcij na vmesnih nivojih so vidne samo
neposrednim staršem (posodobitve T3 so vidne samo T2).
 Potrditev (commit) podtransakcij pogojuje potrditev
nadrejene transakcije  zagotavljanje ACID podtransakcij
na višjih nivojih.
 Za zagotavljanje sočasnosti dostopa predlaga Moss
protokol, ki temelji na protokolu “strict 2PL”.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 416 -
Vgnezdeni transakcijski model
 Prednosti vgnezdenega modela:
– Modularnost: transakcijo se za potrebe sočasnosti in
obnovljivosti lahko dekomponira v več podtransakcij.
– “Finejša” razdrobljenost transakcije: prispeva k lažjemu
nadzoru sočasnosti in lažji obnovljivosti.
– Vzporednost znotraj transakcije: podtransakcije se lahko
izvajajo vzporedno.
– Obnavljanje znotraj transakcije: neuveljavljene
podtransakcije je mogoče prekiniti in razveljaviti ne da bi s
tem vplivali na druge podtransakcije.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 417 -
Sage…
 Saga: Zaporedje transakcij, ki se lahko prepleta z
drugimi transakcijami.
 Koncept temelji na uporabi transakcij s
kompenzacijskim učinkom, ki nevtralizirajo
operacije transakcij v sagi.
Vgnezdeni transakcijski model
SAGA
T1
T2
T3
T5
T4
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
T3
T4
T5
T6
C3
C4
C5
C6
T6
Transakcija s
kompenzacijskim
učinkom
- 418 -
Lastnosti sage:
• samo en nivo
gnezdenja,
• za vsako
podtransakcijo
obstaja
transakcija s
kompenzacijskim
učinkom na PB.
Sage
 SUPB zagotavlja, da se:
– izvedejo vse transakcije sage uspešno,
– ali pa se izvedejo transakcije s kompenzacijskim učinkom za
obnavljanje podatkov zaradi delne izvedbe.
 V primerjavi z navadnim transakcijskim modelom,
sage ne zahtevajo striktnega spoštovanja
lastnosti izolacije  sočasne transakcije imajo
dostop do delnih rezultatov sage, preden se ta
zaključi.
 Sage so uporabne, če so njene podtransakcije
relativno neodvisne in je možno opredeliti
transakcije s kompenzacijskim učinkom.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 419 -
Večnivojski transakcijski model…
 Pri ugnezdenem transakcijskem modelu se
transakcije potrjujejo “od spodaj navzgor” do
najvišjega nivoja – zaprto ugnezdenje.
 Zaprto ugnezdenje zagotavlja atomarnost na
najvišjem nivoju.
 Obstaja tudi t.i. odprto ugnezdenje, ki dovoljuje
vidnost delnih rezultatov podtransakcij navzven –
primer: sage.
 Specializacijo modela odprtega ugnezdenja
predstavlja več-nivojski transakcijski model 
uravnoteženo drevo podtransakcij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 420 -
Večnivojski transakcijski model…
 Vozlišča na istem nivoju predstavljajo operacije
istega nivoja abstrakcije SUPB-ja.
 Povezave predstavljajo implementacijo operacije
z zaporedjem operacij na naslednjem nižjem
nivoju.
 Nivoje n-nivojske transakcije označimo z L0 do Ln,
kjer je L0 najnižji nivo v drevesu, Ln pa koren
drevesa.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 421 -
Večnivojski transakcijski model…
 Tradicionalne ("flat") transakcije zagotavljajo
nekonfliktnost na nivoju L0.
 Več-nivojski transakcijski model temelji na
naslednjem konceptu:
– za dve operaciji na nivoju Li ni nujno, da sta konfliktni,
čeprav so njune implementacije na naslednjem - nižjem
nivoju Li-1 konfliktne.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 422 -
Večnivojski transakcijski model
 Z izkoriščanjem informacij o konfliktnosti operacij
določenega nivoja, lahko z večnivojskimi
transakcijami zagotovimo višjo raven sočasnosti
kot pri tradicionalnih transakcijah.
 Primer:
Urnik izvajanja transakcij T in T ni mogoče
7
8
serializirati. Lahko pa transakciji dekomponiramo
na podtransakcije z visokonivojskimi operacijami:
T7 :
T8 :
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
T71, ki poveča balx za 5
T72, ki odšteje 5 od baly
T81, ki poveča baly za 10
T82, ki odšteje 2 od balx
Ker sta seštevanje in odštevanje komutativna, se
lahko podtransakcije izvajajo v poljubnem vrstnem
- 423
redu.
Dinamično prestrukturiranje…
 Že na začetku poglavja o naprednih tr. modelih
smo omenili karakteristike načrtovalskih aplikacij:
– trajanje (nekaj ur do mesecev),
– interakcija z drugimi sočasnimi aktivnostmi itd.
 Za razreševanje omejitev, ki jih nalagajo lastnosti
običajnih transakcij (ACID), so bile predlagane
dve novi operaciji:
– razcep transakcije in
– spajanje transakcije.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 424 -
Dinamično prestrukturiranje…
 Pri razcepu se aktivno transakcijo razcepi na dve
serializabilni transakciji, med kateri se razdeli
začetne operacije in vire (npr.: zaklenjene
podatkovne enote).
 Novi transakciji se od točke razcepa naprej
izvajata neodvisno.
 Na ta način so lahko delni rezultati transakcije
vidni ostalim transakcijam, hkrati pa se pomen
originalne transakcije ohrani: če je originalna
transakcija ustrezala lastnostim ACID, bodo tudi
nove transakcije.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 425 -
Dinamično prestrukturiranje
 Spajanje transakcij ima nasproten učinek od
razcepa  operacije dveh ali več neodvisnih
tekočih transakcij se spoji v eno, kot da bi od
samega začetka tvorile eno transakcijo.
 Operacije razcepa in spajanja se lahko uporablja
za prenašanje virov med transakcijami 
potreba po sproščanju virov med transakcijami
odpade!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 426 -
Dinamično prestrukturiranje
 PREDNOSTI dinamičnega prestrukturiranja:
– prilagodljivo obnavljanje: del operacij transakcije se lahko
uveljavi (commit), ne da bi nanje vplivale kasnejše nesreče,
– znižana raven zahtevane izolacije: dovoljuje sproščanje virov
ob potrjevanju dela transakcije.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 427 -
Modeli delovnih tokov…
 Dosedanji napredni transakcijski modeli so bili
izdelani za dolgotrajne transakcije, z namenom
premostiti težave običajnih transakcij - še vedno
ostaja dvom o njihovi ustreznosti.
 Predlagani še kompleksnejši modeli, ki
predstavljajo kombinacijo odprto in zaprto
ugnezdenih transakcij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 428 -
Modeli delovnih tokov
 Ker omenjeni modeli komaj ustrezajo katerikoli
lastnosti ACID, se zanje uporablja pravilnejše
poimenovanje: modeli delovnih tokov 
kompleksne transakcije obravnavamo z vidika
samih delovnih tokov.
 Delovni tok vključuje koordinacijo več aktivnosti,
ki jih izvajajo različne entitete: ljudje ali
informacijska tehnologija (SUPB, aplikacije,
sistemi za elektronsko pošto).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 429 -
Povzeto po [1]
Poglavje 3
Optimizacija poizvedb




O optimizaciji poizvedb
Hevristična optimizacija poizvedb
Stroškovna opredelitev operacij relacijske algebre
Strategije izvedbe poizvedb
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 430 -
P 4.1
O optimizaciji poizvedb
Kaj si bomo pogledali?






PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Zakaj optimizacija poizvedb
Tehnike optimizacije
Procesiranje in optimizacija poizvedb
Beleženje statistike za potrebe optimizacije
Faze procesiranja poizvedb
Dinamična in statična optimizacija
- 431 -
Zakaj optimizacija
 Ko se pojavi relacijski model, časovna zahtevnost
poizvedovanja velika kritika.
 Kasneje se razvijejo številni algoritmi za izvajanje
kompleksnih poizvedb.
– Poizvedbo je moč izvesti na številne različne načine.
– Eden od ciljev optimizacije poizvedb je najti časovno
najučinkovitejši način.
 Mrežni in hierarhični ter relacijski sistemi
– V mrežnih in hierarhičnih sistemih za optimalnost skrbi
programer (proceduralno poizvedovanje kot del programa)
– V relacijskih programer pove samo KAJ in ne KAKO!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 432 -
Tehnike optimizacije
 Dve osnovni tehniki optimizacije (v praksi gre
navadno za kombinacijo):
– Na osnovi hevrističnih pravil, ki pravilno razvrstijo operacije
poizvedbe;
– Na osnovi primerjave relativnih stroškov različnih strategij in
izbiro tiste, ki predstavlja minimalno porabo sredstev.
 V centraliziranih SUPB predstavlja dostop do
sekundarnega pomnilnika največji “strošek”.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 433 -
Procesiranje in optimizacija poizvedb
 Procesiranje poizvedbe zajema aktivnosti v zvezi
z razčlenjevanjem, preverjanjem, optimizacijo in
izvedbo poizvedbe.
– Cilj: poizvedbo, zapisano v visoko-nivojskem jeziku, tipično
SQL, pretvoriti v pravilno in učinkovito strategijo izvedbe,
zapisano v nizko-nivojskem jeziku (implementacija relacijske
algebre) in izvedba te strategije.
 Optimizacija poizvedbe: izbira najučinkovitejše
izvedbene strategije za procesiranje poizvedbe.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 434 -
Dva pogleda na optimizacijo
 Z optimizacijo poizvedbe skušamo izbrati
transformacijo, ki minimizira porabo sredstev.
 Možnosti:
– A) Minimiziramo čas izvajanja poizvedbe ≈ celotni čas
poizvedbe je seštevek časov, potrebnih za izvedbo
posamezne operacije poizvedbe.
– B) Maksimalno uporabimo razpoložljiva sredstva, npr. z
vzporednim izvajanjem operacij ipd.
 Potrebujemo dodatne podatke, ki nam pomagajo
pri optimizaciji.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 435 -
Beleženje statistike
 Za izvajanje optimizacije potrebno poznati
različne podatke – statistika
– Statistika se nanaša na podatke o relacijah (npr.
kardinalnost), atributih (npr. število različnih vrednosti) in
indeksih (npr. višina indeksnega drevesa).
– Vzdrževanje točne in “sveže” statistike je pomembno a zelo
potratno… tipičen pristop – osveževanje statistike v nočnih
urah.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 436 -
Faze procesiranja poizvedb
 Procesiranje poizvedb se sestoji iz štirih faz:
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Dekompozicija (razčlenjevanje in preverjanje);
Optimizacija;
Generiranje kode;
Izvedba.
- 437 -
Dinamična in statična optimizacija…
 Dve možnosti, kdaj se izvedejo prve tri faze
procesiranja poizvedbe:
– Dinamično procesiranje: dekompozicija in optimizacija
vsakokrat, ko se požene poizvedba.
 Prednost: statistika je “sveža”
 Slabost: časovna potratnost zaradi vsakokratnega razčlenjevanja,
preverjanja in optimizacije pred izvedbo. Zaradi prevelike časovne
zahtevnosti, se včasih preveri samo nekaj strategij, kar lahko
privede do neoptimalne izbire…
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 438 -
Dinamična in statična optimizacija
 Dve možnosti, kdaj se izvedejo prve tri faze
procesiranja poizvedbe (nadaljevanje):
– Statično procesiranje: dekompozicija in optimizacija se za
določeno poizvedbo izvede samo enkrat.
 Prednost: ker se dekompozicija in optimizacija ne izvedejo, več
časa za preverjanje različnih strategij.
 Slabost: stara statistika. Reševanje – (I) reoptimizacija, ko sistem
zazna večje spremembe v statistiki; (II) optimizacija enkrat za
vsako sejo.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 439 -
Dekompozicija poizvedbe (DP)…
 Dekompozicija – prva faza procesiranja
poizvedbe.
– Cilj dekompozicije:
 pretvoriti poizvedbo iz visoko-nivojskega jezika v relacijsko algebro.
 Preveriti sintaktično in semantično pravilnost poizvedbe.
– Tipični koraki dekompozicije:





PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Analiza
Normalizacija
Semantična analiza
Poenostavitev
Reorganizacija poizvedbe
- 440 -
DP – analiza…
 Zajema leksikalno in sintaktično analizo –
podobno kot prevajalniki programskih jezikov.
 Dodatno preveri:
– Če so relacije in atributi poizvedbe zapisani v sistemskem
katalogu;
– Če so operacije poizvedbe primerne glede na tip objekta,
nad katerim se izvajajo.
 Primer
SELECT staffNumber
FROM Staff
WHERE position > 10;
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Ne obstaja v katalogu (staffNo)
Nekompatibilnost operacije in podatkovnega
tipa  position je tipa character
- 441 -
DP – analiza…
 Po leksikalnem in sintaktičnem preverjanju se
poizvedba pretvori v interni zapis, primernejši za
nadaljnjo obdelavo.
 Navadno gre za drevo poizvedbe, ki se zgradi v
naslednjih korakih:
– Za vsako osnovno relacijo poizvedbe kreiraj list drevesa.
– Za vsako vmesno relacijo, ki je rezultat operacij algebre,
kreiraj vozlišče drevesa.
– Rezultat poizvedbe naj bo koren drevesa.
– Zaporedje operacij za izvedbo naj gre od listov k korenu.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 442 -
DP – analiza
 Primer:
SELECT *
FROM Staff s, Branch b
WHERE s.branchNo = b.branchNo AND
(s.position = ‘Manager’ AND b.city = ‘London’);
Drevo relacijske algebre
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 443 -
DP – normalizacija…
 Zajema pretvorbo poizvedbe v normalizirano
obliko, ki jo je lažje obdelovati.
– Gre za pretvorbo predikatnega dela (WHERE).
 S pomočjo transformacijskih pravil se poizvedba
pretvori v eno izmed dveh možnih oblik:
– Konjunktivna normalna oblika: zaporedje konjunkcij,
povezanih z operatorjem AND ().
– Disjunktivna normalna oblika: zaporedje disjunkcij,
povezanih z operatorjem OR ().
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 444 -
DP – normalizacija
 Konjunktivna normalna oblika
– Vsaka konjunkcija vsebuje enega ali več izrazov, povezanih z
OR (). Konjunktivna selekcija zajema samo tiste n-terice, ki
zadoščajo vsem konjunkcijam.
– Primer
(position = ‘Manager’  salary > 20000)  branchNo = ‘B003’
 Disjunktivna normalna oblika
– Vsaka disjunkcija vsebuje enega ali več izrazov, povezanih z
AND (). Konjunktivna selekcija zajema unijo vseh n-teric, ki
zadoščajo posameznemu disjunktu.
– Primer
(position = ‘Manager’  branchNo = ‘B003’) 
(salary > 20000  branchNo = ‘B003’)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 445 -
DP – semantična analiza…
 Namen semantične analize je preprečiti
normalizirane poizvedbe, ki so napačno
formulirane ali kontradiktorne.
– Napačna formulacija: posamezne komponente ne prispevajo
k ciljnemu rezultatu.
– Kontradiktornost: predikatu ne zadošča nobena n-terica.
Npr. (position = ‘Manager’ AND position = ‘Assistant’).
 Kontradiktornost sistemi SUPB obravnavajo in
rešujejo na različne načine.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 446 -
DP – semantična analiza…
 Algoritmi za preverjanje semantične pravilnosti
obstajajo le za poizvedbe, ki ne vsebujejo
disjunkcij in negacij!
 Za preverjanje poizvedb, ki ne vsebujejo
disjunkcij in negacij, lahko uporabimo
– Graf povezav relacij za preverjanje napačnih formulacij in
– Graf povezav normaliziranih atributov za preverjanje
kontradikcij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 447 -
DP – semantična analiza…
 Postopek kreiranja grafa povezav relacij:
– Kreiraj vozlišče za vsako relacijo ter za rezultat.
– Kreiraj povezavo med vozlišči, ki predstavljajo relacije v
stiku.
– Kreiraj povezave med vozlišči, ki nastopajo kot izvor v
operacijah projekcije.
– Če graf ni povezan (obstajajo nepovezani deli), je poizvedba
napačno formulirana!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 448 -
Primer preverjanja semantične pravilnosti
 Imamo naslednjo poizvedbo
SELECT p.propertyNo, p.street
FROM Client c, Viewing v, PropertyForRent p
WHERE
c.clientNo = v.clientNo AND
c.maxRent >= 500 AND
c.prefType = ‘Flat’ AND
p.ownerNo = ‘CO93’;
 Ali obstajajo napačne formulacije?
Kaj v poizvedbi manjka?
v.propertyNo = p.propertyNo
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 449 -
DP – semantična analiza…
 Postopek kreiranja grafa povezav normaliziranih
atributov:
– Kreiraj vozlišče za vsako referenco na nek atribut ali konstanto 0.
– Kreiraj usmerjeno povezavo med vozlišči, ki predstavljajo stik.
– Za vsako selekcijo kreiraj usmerjeno povezavo med vozliščem, ki
predstavlja atribut selekcije, in vozliščem, ki predstavlja konstanto
0.
– Povezave a  b uteži z vrednostjo c, če gre za pogoj neenakosti
tipa a ≤ b+c
– Povezave 0  a uteži z vrednostjo -c, če gre za pogoj neenakosti
tipa a ≥ c
– Če graf vsebuje cikel z negativnim seštevkom uteži, potem je
poizvedba kontradiktorna.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 450 -
Primer preverjanja semantične pravilnosti
 Imamo naslednjo poizvedbo
SELECT p.propertyNo, p.street
FROM Client c, Viewing v, PropertyForRent p
WHERE
c.maxRent > 500 AND
c.clientNo = v.clientNo AND
v.propertyNo = p.propertyNo AND
c.prefType = ‘Flat’ AND
c.maxRent < 200;
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 451 -
DP – poenostavitev…
 Zajema
– detekcijo odvečnih kvalifikatorjev,
– odpravo ponavljajočih sklopov in
– transformacijo poizvedbe v semantično ekvivalentno, vendar
enostavnejšo in za računanje učinkovitejšo obliko!
 V tej fazi se upoštevajo omejitve dostopa,
definicije pogledov ter omejitve skladnosti, kar
včasih botruje pojavi redundance.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 452 -
DP – poenostavitev
 Če uporabnik nima vseh potrebnih pravic, se
poizvedba zavrne. Sicer se za transformacijo
uporabijo idempotentna pravila booleanove
algebre, npr.
p
p
p
p
p
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko





(p)  p
false  false
true  p
(¬p)  false
(p  q)  p
p
p
p
p
p





- 453 -
(p)  p
false  p
true  true
(¬p)  true
(p  q)  p
P 4.2
Hevristična optimizacija poizvedb
Kaj si bomo pogledali?
 Pravila transformacije relacijske algebre
 Primer uporabe transformacijskih pravil
 Strategije hevrističnega procesiranja
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 454 -
Hevristična optimizacija poizvedb
 Eden od pristopov optimizacije poizvedb je
uporaba hevrističnih pravil.
 S pomočjo hevrističnih pravil lahko nek izraz v
relacijski algebri r1 transformiramo v ekvivalenten
izraz r2, pri čemer je r2 učinkovitejši.
 Optimizacija je faza, ki
sledi fazi dekompozicije.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 455 -
Pravila transformacije relacijske algebre
 Optimizator pretvarja izraze relacijske algebre s
pomočjo transformacijskih pravil.
 Transformacijsko pravilo 1
– Konjunkcija operacij selekcije je enakovredna kaskadi
posameznih operacij selekcije.
pqr(R) = p(q(r(R)))
– Včasih imenujemo tudi kaskada selekcije
– Primer:
branchNo='B003'  salary>15000(Staff) =
branchNo='B003'(salary>15000(Staff))
nazaj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 456 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 2
– Komutativnost operacij selekcije.
p(q(R)) = q(p(R))
– Primer:
branchNo='B003'(salary>15000(Staff)) =
salary>15000(branchNo='B003'(Staff))
nazaj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 457 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 3
– Pri zaporedju operacij projekcij je pomembna samo zadnja
operacija.
Operacije se izvajajo od operatorja
LM … N(R) = L (R)
navzven, zato L (R) zadnja
– Primer:
lNamebranchNo, lName(Staff) = lName (Staff)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 458 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 4
– Komutativnost operacij selekcije in projekcije: Če predikat p
vključuje le attribute iz operacije projekcije, potem sta
operacije selekcije in projekcije komutativni.
Ai, …, Am(p(R)) = p(Ai, …, Am(R))
where p {A1, A2, …, Am}
– Primer:
fName, lName(lName='Beech'(Staff)) =
lName='Beech'(fName,lName(Staff))
nazaj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 459 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 5
– Komutativnost theta stika in kartezijskega produkta
R
p S = S
p R
RXS=SXR
– Pravilo velja tudi za stik Equijoin in naravni stik
– Primer:
Staff
staff.branchNo=branch.branchNo Branch =
Branch
staff.branchNo=branch.branchNo Staff
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 460 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 6
– Komutativnost selekcije in theta stika (ali kartezijskega
produkta): Če predikat v operaciji selekcije vključuje le
atribute ene relacije iz stika, potem operaciji selekcija in stik
(ali kartezijski produkt) komutirati:
p(R
r S) = (p(R))
r S
p(R X S) = (p(R)) X S, where p {A1, A2, …, An}
– Ali, če je predikat selekcije konjunkcija oblike (p  q), kjer se
p nanaša le atribute relacije R, q pa le na atribute relacije S,
potem operaciji selekcije in theta stika komutirati:
p  q(R
r S) = (p(R))
r (q(S))
p  q(R X S) = (p(R)) X (q(S))
nazaj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 461 -
Pravila transformacije relacijske algebre
 Primer za transformacijsko pravilo 6
position='Manager'  city='London'(Staff
Staff.branchNo=Branch.branchNo Branch) =
(position='Manager'(Staff))
Staff.branchNo=Branch.branchNo
(city='London' (Branch))
nazaj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 462 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 7
– Komutativnost projekcije in theta stika (ali kartezijskega
produkta): če je seznam atributov projekcije oblike
L = L1  L2, kjer L1 zajema le atribute relacije R, L2 pa
atribute relacije S, pogoj stika pa atribute L, potem operaciji
projekcije in theta stika komutirati.
L1L2(R
r S) = (L1(R))
r (L2(S))
– Primer:
position,city,branchNo(Staff
(position, branchNo(Staff))
Staff.branchNo=Branch.branchNo
Staff.branchNo=Branch.branchNo
city, branchNo (Branch))
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 463 -
Branch) =
(
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 7 (dodatek):
– Če pogoj stika vsebuje tudi atribute, ki jih ni v L (M = M1 
M2, kjer M1 vsebuje le atribute iz R, M2 pa le atribute iz S),
potem osnovno transformacijsko pravilo 7 velja, če vključimo
še dodatno projekcijo:
L1L2(R
r S) = L1L2 ( (L1M1(R))
r (L2M2(S)))
Dodatna projekcija
– Primer:
position, city(Staff
Staff.branchNo=Branch.branchNo Branch) =
position, city ((position, branchNo(Staff))
Staff.branchNo=Branch.branchNo
( city, branchNo (Branch)))
nazaj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 464 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 8
– Komutativnost operacij unija in presek.
RS=SR
RS=SR
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 465 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 9
– Komutativnost operacij selekcije in operacij množic (unija,
presek in razlika).
p(R  S) = p(S)  p(R)
p(R  S) = p(S)  p(R)
p(R ̶ S) = p(S) ̶ p(R)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 466 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 10
– Komutativnost projekcije in unije.
L(R  S) = L(S)  L(R)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 467 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 11
– Asociativnost theta stika (in kartezijskega produkta)
 Kartezijski produkt in naravni stik sta vedno asociativna
(R
S)
T=R
(S
T)
(R X S) X T = R X (S X T)
 Če pogoj stika q vsebuje le atribute iz S in T, potem je theta stik
asociativen
(R
p
S)
qr
T=R
pr
(S
q
T)
nazaj
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 468 -
Pravila transformacije relacijske algebre
 Primer za transformacijsko pravilo 11
(Staff
PropertyForRent)
ownerNo=Owner.ownerNo  staff.lName=Owner.lName Owner =
Staff.staffNo=PropertyForRent.staffNo
Staff
staff.staffNo=PropertyForRent.staffNo  staff.lName=lName
(PropertyForRent
ownerNo Owner)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 469 -
Pravila transformacije relacijske algebre
 Transformacijsko pravilo 12
– Asociativnost unije in preseka.
(R  S)  T = S  (R  T)
(R  S)  T = S  (R  T)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 470 -
Primer uporabe transformacijskih pravil…
 Primer poizvedbe:
– Za stranke, ki iščejo stanovanje, najdi nepremičnine, ki
ustrezajo lastnostim, ki so jih stranke podale.
SELECT p.propertyNo, p.street
FROM Client c, Viewing v, PropertyForRent p
WHERE c.prefType = ‘Flat’ AND
c.clientNo = v.clientNo AND
v.propertyNo = p.propertyNo AND
c.maxRent >= p.rent AND
c.prefType = p.type AND
p.ownerNo = ‘CO93’;
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 471 -
Primer uporabe transformacijskih pravil…
 SQL pretvorimo v relacijsko algebro
p.propertyNo, p.street(c.prefType=‘Flat’  c.clientNo = v.clientNo  v.propertyNo =
p.propertyNo  c.maxRent ≥ p.rent  c.prefType = p.type  p.ownerNo = ‘CO93’ ((cv)p))
 Poizvedbo lahko prikažemo kot
kanonično drevo relacijske
algebre:
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 472 -
Primer uporabe transformacijskih pravil…
 Za izboljšanje učinkovitosti izvedbe poizvedbe
uporabimo naslednja transformacijska pravila:
– Prvi korak:
 Uporabimo pravilo 1, da razbijemo selekcijo na individualne
operacije selekcije
 Uporabimo pravili 2 in 6, da spremenimo vrstni red operacij
selekcije ter zamenjamo selekcije in kartezijske produkte.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 473 -
Primer uporabe transformacijskih pravil…
Izhodišče
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Po prvem koraku
- 474 -
Primer uporabe transformacijskih pravil…
– Drugi korak:
 Selekcijo z equijoin predikatom in kartezijskim produktom lahko
zapišemo kot equijoin stik, kjer velja
R.a = S.b ( R  S ) = R
R.a = S.b
S
 Transformacijo uporabimo, kjer je možno
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 475 -
Primer uporabe transformacijskih pravil…
Po prvem koraku
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Po drugem koraku
- 476 -
Primer uporabe transformacijskih pravil…
– Tretji korak:
 Pravilo 11: da spremenimo vrstni red equijoin stikov, tako da so
bolj restriktivni na začetku.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 477 -
Primer uporabe transformacijskih pravil…
Po drugem koraku
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Po tretjem koraku
- 478 -
Primer uporabe transformacijskih pravil…
– Četrti korak:
 Uporabimo pravili 4 in 7, da projekcije premaknemo pred equijoin
stike in naredimo dodatno projekcijo (glej pravilo 7, dodatek).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 479 -
Primer uporabe transformacijskih pravil…
Po tretjem koraku
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Po četrtem koraku
- 480 -
Primer uporabe transformacijskih pravil…
 Za dodatno optimizacijo lahko operacijo selekcije
c.prefType = p.type poenostavimo na p.type =
‘Flat’, saj da je p.type = ‘Flat’ vemo že iz prvega
dela predikata SQL stavka.
– S takšno substitucijo se selekcija premakne po drevesu
navzdol.
– Končen rezultat je:
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 481 -
Primer uporabe transformacijskih pravil
Po četrtem koraku
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Po dodatnem koraku
- 482 -
Strategije hevrističnega procesiranja…
 Strategija 1:
– Operacije selekcije izvedi čim prej – selekcija zmanjša
kardinalnost relacije...
– Operacije selekcije nad isto relacijo naj bodo skupaj
– Uporabi transformacijska pravila 2, 4, 6 in 9
 Strategija 2
– Združi kartezijski produkt z operacijami selekcije, ki
predstavljajo obenem stični pogoj.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 483 -
Strategije hevrističnega procesiranja…
 Strategija 3:
– Uporabi asociativnost binarnih operacij in ponovno razporedi
liste drevesa, tako da bodo najbolj omejevalne selekcije
upoštevane na začetku. Relacije čim bolj zreduciramo
preden uporabimo binarne operacije.
– Podobno uporabimo asociativnost theta stika, da poizvedbo
reorganiziramo tako, da se ‘manjši’ stiki izvedejo najprej.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 484 -
Strategije hevrističnega procesiranja…
 Strategija 4:
– Z uporabo pravila 3 projekcije uredimo kaskadno, ter
uporabimo pravila 4, 7 in 10 v zvezi s komutativnostjo
projekcije in binarnih operacij, da projekcijo premaknemo
čim bližje listom drevesa.
– Projekcija zmanjša kardinalnost relacij, zato priporočljivo
izvesti na samem začetku.
– Projekcije nad istimi relacijami je dobro obdržati skupaj.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 485 -
Strategije hevrističnega procesiranja
 Strategija 5:
– Če se nek izraz pojavi večkrat v eni poizvedbi in rezultat, ki
ga ta izraz producira ni prevelik, potem delni rezultat shrani
za nadaljnjo uporabo.
– Smiselno le, če je rezultat dovolj majhen, da ga je moč
hraniti v primarnem pomnilniku.
– Če je potrebno rezultat hraniti v sekundarnem pomnilniku,
potem je potrebno izračunati, kaj več stane: branje iz
sekundarnega pomnilnika ali ponovni izračun izraza.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 486 -
P 4.3
Stroški operacij relacijske algebre
Kaj si bomo pogledali?
 Kako računamo stroške operacij relacijske algebre
 Primer za operacijo Selekcija
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 487 -
Implementacija operacij RA*
 SUPB navadno omogoča različne načine
implementacije operacij RA.
 Cilj optimizacije poizvedbe je izbrati
implementacijo, ki je časovno najbolj učinkovita.
 Za izračun časovne kompleksnosti se uporablja
formula…
– navadno se upošteva le čas dostopa in branja iz diska
(število blokov, ki jih potrebno prebrati).
 Večina izračunov temelji na kardinalnosti relacije.
*RA – Relacijska algebra
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 488 -
Statistika…
 Izračuni časovne kompleksnosti odvisen od
ažurnosti statističnih podatkov, ki jih SUPB hrani.
 Tipično hranimo naslednje podatke:
nTuples(R) – število n-teric v relaciji R
bFactor(R) – število n-teric v enem bloku
nBlocks(R) – število blokov, ki jih zasede relacija R
nBlocks(R) = [nTuples(R)/bFactor(R)]
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 489 -
Statistika…
 Tipični statistični podatki (nadaljevanje):
nDistinctA(R) – število različnih vrednost atributa A v relaciji R
minA(R), maxA(R) – minimalna in maksimalna možna vrednost
atributa A v relaciji R
SCA(R) – povprečno število n-teric, ki zadošča pogoju enakosti
nad atributom A v relaciji R.
– Pri predpostavki A enakomerno porazdeljen v R in vsaj ena
vrednost zadošča pogoju, potem:
SCA(R) =
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
1
; če A ključ
[nTuples(R)/nDistinctA(R)] ; sicer
- 490 -
Statistika
 Tipični statistični podatki (nadaljevanje):
nLevelsA(I) – število nivojev v indeksu I nad atributom A.
nLfBlocksA(I) – število blokov v listih indeksa I nad atributom
A.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 491 -
Primer za operacijo Selekcija…
 Selekcija
S = p(R)
– Deluje na enojni relaciji R; vrne relacijo, ki vsebuje samo
tiste n-terice iz relacije R, ki zadoščajo določenemu pogoju
p.
– Predikat p je lahko enostaven (primerjava atributa z neko
konstanto) ali kompleksen (več logično povezanih pogojev)
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 492 -
Primer za operacijo Selekcija
 Različni načini implementacije operacije selekcija.
Npr.:
–
–
–
–
–
–
–
–
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
Linearno iskanje (neurejena datoteka, brez indeksa).
Binarno iskanje (urejena datoteka, brez indeksa).
Enakost po hash polju.
Enakost po primarnem ključu.
Neenakost po primarnem ključu.
Enakost po gručnem (sekundarnem) indeksu.
Enakost po indeksu, ki ni gručni.
Enakost po sekundarnem, B+ indeksu.
- 493 -
Različne implementacije
 Tabela prikazuje ocene stroškov različnih
strategij implementacije operacije selekcija
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 494 -
P 4.4
Alternativne strategije izvedbe
Kaj si bomo pogledali?
 Primer dveh pristopov za izboljšanje učinkovitosti
poizvedb:
– Direkten prenos podatkov med operacijami
– Uporaba linearnih dreves
 Fizične operacije in strategije
 Zmanjševanje iskalnega prostora
 Semantična optimizacija
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 495 -
Iskalni prostor…
 Ključno za učinkovitost optimizacije poizvedb je:
– iskalni prostor: koliko različnih strategij imamo ter
– algoritem za iskanje najboljše strategije.
 Iskalni prostor je lahko zelo velik.
 Primer:
– Poizvedba Q, ki vključuje stik med relacijami R, S in T
– Možnih je 12 različnih vrstnih redov stika med relacijami
R
S
T
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
(S
(R
(R
T)
T)
S)
R
S
T
(T
(T
(S
S)
R)
R)
- 496 -
(S
(R
(R
T)
T)
S)
R
S
T
(T
(T
(S
S)
R)
R)
R
S
T
Iskalni prostor
 V splošnem je iskalni prostor lahko izjemno velik.
 Že pri stikih na voljo izjemno veliko možnosti:
npr. pri n relacijah možnih x = (2(n-1)!)/(n-1)!
različnih stikov.
– Če n = 4  x = 120
– Če n = 6  x = 30.240
– Če n = 10  x je več kot 176 bilijonov.
 Obstajajo metode, s pomočjo katerih zmanjšamo
iskalni prostor.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 497 -
Izboljšanje učinkovitosti poizvedb…
 Materializacija – izhod neke operacije se zapiše v
začasno relacijo na sekundarni medij za potrebe
naslednje operacije.
 Alternativen pristop: direkten prenos podatkov
med operacijami
– ni potrebe po začasnem shranjevanju in ponovnem branju.
 Imenujemo pipelining ali on-the-fly processing.
 Za realizacijo direktnega prenosa tipično kreiran
poseben proces ali nit v SUPB, ki ima na voljo
ustrezen del medpomnilnika.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 498 -
Izboljšanje učinkovitosti poizvedb…
 Drevesa relacijske algebre so tipično oblike,
imenovane levo-urejeno drevo – LD (left-deep
join tree).
– Ime pove, kako se operacije kombinirajo pri izvedbi
– Pri LDT so vmesni rezultati lahko le na levi strani drevesa
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 499 -
Izboljšanje učinkovitosti poizvedb…
 Obstajajo tudi druge vrste dreves relacijske
algebre:
Desno-urejeno linearno drevo
Navadno linearno drevo
Nelinearno drevo - grm
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 500 -
Izboljšanje učinkovitosti poizvedb
 Zakaj linearna drevesa?
– Pri linearnih drevesih so osnovne relacije vedno na eni
strani.
– Pomembno: ker moramo pregledati celotno notranjo
relacijo, da jo lahko staknemo z zunanjo relacijo, moramo
notranjo relacijo vedno materializirati.
– Levo-urejeno linearno drevo pripomore k učinkovitosti, saj
so notranje relacije vedno osnovne relacije. Za realizacijo se
običajno uporablja dinamično programiranje.
– Levo-urejeno linearno drevo močno zmanjša iskalni prostor –
samo nekaj možnih ureditev…
– Slabost: ne preverijo se vse možne
strategije…
zunanja
relacija
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 501 -
notranja
relacija
Fizične operacije in plan izvedbe…
 Fizična operacija – specifičen algoritem za
izvedbo logične operacije nad podatki, npr.
selekcija ali stik.
 Primer: logično operacijo stik izvedemo s fizično
operacijo sort-merge join.
 Če v drevesu relacijske algebre logične operacije
nadomestimo s fizičnimi, dobimo plan izvedbe
(query evaluation plan, access plan).
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 502 -
Fizične operacije in plan izvedbe
 Primer nadomestitve logičnih operacij s fizičnimi
a) Primer drevesa relacijske algebre;
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
b) pripadajoči plan izvedbe
- 503 -
Zmanjševanje iskalnega prostora…
 Iskalni prostor je lahko izjemno velik. Navadno
uporabljamo različne restrikcije, ki omogočajo
zmanjšanje iskalnega prostora.
 Restrikcija 1:
– Enostavne (unarne) operacije se procesirajo sproti: selekcije
takrat, ko je relacija brana prvič, projekcije pa nad
rezultatom vseh drugih operacij.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 504 -
Zmanjševanje iskalnega prostora…
 Restrikcija 2:
– Kartezijski produkti se nikoli ne izvedejo, razen če
je to eksplicitno zahtevano s poizvedbo.
SELECT p.propertyNo, p.street
FROM Client c, Viewing v, PropertyForRent p
WHERE c.clientNo = v.clientNo AND
v.propertyNo = p.propertyNo
Viewing
(Client
PropertyForRent)
Nesmiselna kombinacija: med Client in PropertyForRent
Ni direktne povezave, zato kartezijski produkt.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 505 -
Zmanjševanje iskalnega prostora
 Restrikcija 3:
– Notranji operand pri stiku je vedno osnovna in nikoli začasna
relacija.
– Restrikcija 3 zelo zmanjša iskalni prostor. Problem, ker veliko
kombinacij, ki so lahko boljše, izpuščenih.
– Običajno velja, da levo-uravnoteženo drevo pripelje do
strategije, ki je blizu optimalni.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 506 -
Semantična optimizacija…
 Gre za alternativen pristop k optimizaciji
– na osnovi omejitev, ki so določene v shemi podatkovne
baze, zmanjša iskalni prostor.
– Lahko se uporablja v kombinaciji z drugimi pristopi
optimizacije.
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 507 -
Semantična optimizacija…
 Primer 1:
– Omejitev pravi: zaposlen ne more nadzirati več kot 100
nepremičnin.
CREATE ASSERTION StaffNotHandlingTooMuch
CHECK (NOT EXISTS( SELECT stafNo
FROM PropertyForRent
GROUP BY staffNo
HAVING COUNT(*) > 100
– Poizvedba, s katero bi iskali zaposlene, ki nadzirajo več kot
100 nepremičnin, bi vrnila prazno množico. Optimizator
lahko to upošteva!
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 508 -
Semantična optimizacija
 Primer 2:
– Omejitev pravi: zaposlen na delovnem mestu “Maneger”
mora imeti več kot $20.000 letne plače.
CREATE ASSERTION ManagerSalary
CHECK (salary > 20000 AND position = ‘Manager’)
SELECT s.staffNo, fName, lName, propertyNo
Dodaten predikat lahko zelo
FROM Staff s, PropertyForRent p
uporaben, če ime relacija Staff
WHERE s.staffNo = p.staffNo AND
en sam indeks, in sicer B+ drevo
position = ‘Manager’;
po atributu salary.
lahko prepišemo v
SELECT s.staffNo, fName, lName, propertyNo Če tak indeks ne obstaja,
Dodaten predikat le poveča
FROM Staff s, PropertyForRent p
komplesnost poizvedbe!
WHERE s.staffNo = p.staffNo AND
salary > 20000 AND
position = ‘Manager’;
PODATKOVNE BAZE II
3. Letnik UNI, Informatika
©Laboratorij za informatiko
- 509 -