PB2 Predavanja - v2009

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.
– marko.bajec@fri.uni-lj.si
http http://infolab.fri.uni-lj.si/marko
–
 Asistent - vaje
– As. dr. Aljaž Zrnec, univ. dipl. ing.
– aljaz.zrnec@fri.uni-lj.si
– http://baze.fri.uni-lj.si/
http
PODATKOVNE BAZE II
3. Letnik UNI, Informatika -2-
©Laboratorij za informatiko
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
Splošne informacije
 Priporočena literatura (nadaljevanje):
– [5] Raghu Ramakrishnan, Johannes Gehrke (2003).
Database Management Systems, Third Edition, McGraw-Hill
PODATKOVNE BAZE II
II
Vsebina predmeta...
 I. Načrtovanje podatkovnih baz
– 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
PODATKOVNE BAZE II
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

– O optimizaciji poizvedb
– Hevristična optimizacija poizvedb
– Stroškovna opredelitev operacij relacijske algebre
– Alternativne strategije izvedbe poizvedb
PODATKOVNE BAZE II
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
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 -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 -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 - 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
Shema pristopa po delih
Delitev poslovne domene
Okvirna
na področja, kreiranje
shema
osnovne sheme
Področje 1 Področje 2 ... Področje n
Področna Področna Področna

shema 1 shema 2 shema n
Končna
shema
PODATKOVNE BAZE
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
Trije nivoji načrtovanja – trije modeli
Konceptualni
Konceptualni
PM
i-CASE
PM
Odločitev o PB:
- Relacijska
- Hierarhična
- Objektna
Logični
Logični PM
PM
Fizični
Fizični PM
PM
(skripta)
(skripta)
Reverse Engineering
Podatkovna ODBC
baza
SUPB
PODATKOVNE BAZE
Konceptualno načrtovanje
 Konceptualno načrtovanje je opredelitev
podatkovnih potreb oz. zahtev poslovne domene
s pomočjo konceptualnega modela.
 Konceptualno načrtovanje preko konceptualnega
Model je poenostavitev realnosti, pri čemer
modela poskrbi za je abstrakcija realnosti poljubno natančna.
opis pomena podatkov,
potrebnih za poslovno domeno.
Pomembno je, da model prikazuje
pomembne elemente
 Konceptualnega načrtovanja in izpušča tiste, ki nas
ne moremo
ne zanimajo.
avtomatizirati, za njegovo izvedbo je odgovoren
analitik. Gre za prenos semantike
Modele v model.
razvijamo zato, da bi sisteme bolje
razumeli.
PODATKOVNE BAZE
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
Umestitev konceptualnega načrtovanja
svet mentalni model konceptualni model logični model PB
PODATKOVNE BAZE
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
Gradniki entitetnega modela
 Entitetni tip
 Atribut
 Razmerje
 Enolični identifikator
PODATKOVNE BAZE
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
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
Predstavitev entitetnega tipa
Ime
entitetnega
tipa
Ime entitetnega tipa
Prostor za atribute
PODATKOVNE BAZE
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
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
Atribut
 Kardinalnost atributa je minimalna in maksimalna
Glede na kardinalnost atributa ločimo:
– Totalni atribut (1,n), kjer je n >= 1
– Parcialni atribut (0,n), kjer je n >= 1
– Enovrednostni atribut (m,1), kjer je m € {0,1}
– Večvrednostni atribut (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,…
 Za večino tipov je potrebno (1,1)
določiti tudi dolžino.
EMŠO
(1,3)
Ime
OSEBA (1,1)
Priimek
(0,n)
Vzdevek
PODATKOVNE BAZE
Predstavitev atributa
(1,1)
EMŠO
(1,3)
Ime
OSEBA (1,1)
Priimek
(0,n)
Vzdevek
OSEBA
EMŠO
Ime
Priimek
Vzdevek
PODATKOVNE BAZE
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
Predstavitev razmerja...
OSEBA živi KRAJ
živi
OSEBA KRAJ
Pomen razmerja
PODATKOVNE BAZE
Predstavitev razmerja
OSEBA živi KRAJ
živi v ima
OSEBA KRAJ
Vloga entitete v razmerju
PODATKOVNE BAZE
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
Kardinalnost razmerja...
A B
A
(n,m)
A B
povezava
A B
(p,r)
A B
PODATKOVNE BAZE
Kardinalnost razmerja
 Razmerji med entitetama OSEBA in POŠTA
Stalno prebivališče
OSEBA POŠTA
Začasno prebivališče
PODATKOVNE BAZE
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
Razmerje tudi opisuje lastnost entitete
 Razmerje tudi opisuje lastnost entitete
 Primer: OSEBA, POŠTA
 Razmerje ima atributiven značaj
PODATKOVNE BAZE
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
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
Predstavitev enoličnega identifikatorja
(1,1)
EMŠO
(1,3)
Ime
OSEBA (1,1)
Priimek
(0,n)
Vzdevek
OSEBA
EMŠO
Ime
Priimek
Vzdevek
PODATKOVNE BAZE
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
Š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
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
Generalizacija in specializacija
OSEBA
Totalno in
ekskluzivno
MOŠKI ŽENSKA
OSEBA
Delno in
prekrivno
ŠTUDENT ŠPORTNIK
PODATKOVNE BAZE
Metoda konceptualnega načrtovanja
 Možni koraki konceptualnega načrtovanja:
– K1.1: Identificiraj entitetne tipe
– K1.2: Identificiraj povezave
– K1.3: Identificiraj in z entitetnimi tipi poveži atribute
– K1.4: Atributom določi domene
– K1.5: Določi kandidate za ključe; izmed kandidatov izberi
primarni ključ
– K1.6: Po potrebi uporabi elemente razširjenega diagrama
entiteta – razmerje
– K1.7: Preveri, če v modelu obstajajo odvečni elementi
– K1.8: Preveri, če model “zdrži” transkacije
– K1.9: Preveri model z uporabnikom
PODATKOVNE BAZE II
3. Letnik UNI, Informatika - 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
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
K1.1 – Identificiraj entitetne tipe
 Entitetne tipe je potrebno dokumentirati
 Primer dokumentacije:
Naziv Opis Sinonim Število entitet

entitetnega
tipa
Profesor Predstavlja pedagoškega Pedagoški Vsaka katedra ima
delavca, ki je nosilec enega delavec enega ali več
ali več predmetov profesorjev
Izpitni rok Predstavlja datum, na Rok, pisni Na leto se razpiše
katerega je za nek predmet in izpit, okrog 300 pisnih
določeno ciljno skupino kolokvij izpitov. Vsak predmet
(letnik, smer,...) razpisan mora imeti vsaj tri roke
izpitni rok. letno
...
PODATKOVNE BAZE II
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
 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
 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
je član vključuje
Profesor 1..* 1..1
Katedra 1..1 1..*
Laboratorij
Pr1 L1
K1
Pr2 L2
K2
Pr3 L3
PODATKOVNE BAZE II
K1.2 – Identificiraj povezave....
 Dvoumno povezavo odpravimo z
restrukturiranjem modela
je član vključuje
Profesor Laboratorij Katedra
1..* 1..1 1..* 1.1
Pr1 K1
L1
Pr2 K2
L2
Pr3 K3
PODATKOVNE BAZE II
Primer nepopolne povezave
ima je skrbnik
Katedra 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
 Tudi nepopolno povezavo odpravimo z
restrukturiranjem modela
ima je skrbnik
Katedra 1..1 1..*
Član 0..1 0..*
Oprema
1..1 1..*
pripada
K1 Čl1 O1
K2 Čl2 O2
K3 Čl3
PODATKOVNE BAZE II
K1.2 – Identificiraj povezave
 Povezave je potrebno dokumentirati
Entitetni Števnost Povezava Števnost Entitetni
tip tip
Član 1..* Pripada 1..1 Katedra

1..1 Je predstojnik 0..1
Laboratorij 1..* Sodi v 1..1 Katedra

...
PODATKOVNE BAZE II
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
 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
 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
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?),...
Entitetni Atributi Opis Podatkovni Dolžina ...

tip tip
Študent VpisSt Vpisna številka študenta Number 8 ...
Ime Ime študenta Character 20
Priimek Priimek študenta Character 20
...
... ...
PODATKOVNE BAZE II
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:
– Barva  {bela, rumena, oranžna, rdeča}
– Opis elementa  character 50
– Starost  [0..120]
– EMSO  number 13
PODATKOVNE BAZE II
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
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
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
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
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
Primer specializacije Znak za specializacijo/
generalizacijo.
Študent Lahko tudi:
Redni študent Izredni študent
PODATKOVNE BAZE II
Primer generalizacije
Pedagoški delavec
Profesor Asistent
PODATKOVNE BAZE II
Primer agregacije
Navadna povezava
pripada
Znak za Študent Indeks
1..1 1..*
agregacijo.
pripada
Študent Indeks
1..1 1..*
Agregacija povečuje semantiko modela
PODATKOVNE BAZE II
Primer kompozicije
Navadna povezava
pripada
Znak za Študent Indeks
1..1 1..*
kompozicijo.
pripada
Študent Indeks
1..1 1..*
Kompozicija povečuje semantiko modela
PODATKOVNE BAZE II
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
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
 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
Profesor Pedagog Asistent

EMŠO EMŠO EMŠO
DavcnaSt DavcnaSt DavcnaSt
Ime Ime Ime
Priimek Priimek Priimek
DtmRoj DtmRoj DtmRoj
PODATKOVNE BAZE II
 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
 Ali je kakšna povezava odveč?
je predstojnik
Profesor Katedra
1..1 0..1
1..* 1..1
pripada
1..*
je član
1..1
Laboratorij
PODATKOVNE BAZE II
 Ali je kakšna povezava odveč?
pripada
Profesor Katedra
1..* 1..1
1..* 1..1
pripada
1..*
je član
1..1
Laboratorij
PODATKOVNE BAZE II
 Preveri časovni okvir
– Časovni okvir povezav je lahko pomemben
je poročen z
Oče Mati
0..1 0..1
1..1 1..1
je mati
?
0..*
je oče
Otrok
0..*
– Kaj če ima oče otroka iz prejšnjega zakona?

PODATKOVNE BAZE II
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
 Preverjanje opisa transakcij
– Vsako transakcijo opišemo;
– Preverimo, če model zajema vse entitetne tipe, povezave in
atribute, ki jih transakcija potrebuje.
PODATKOVNE BAZE II
 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
 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
K1.8 - Preveri, če model zdrži transkacije
a) Izpiši vse predmete, ki jih je opravil določen študent
b) Izpiši vse študente, ki so se vpisali v določen letnik, določene smeri,
določenega programa
ima
?
Program Smer
progID 1..1 0..1 smerID
b 1..*
se predava na
1..*
se nanaša na Rok za Predmet

Prijava 0..* 1..1 rokID 1..1 predID
0..*
0..*
1..1
pripada
1..1
je opravljal iz
Študent Izpit 0..*
vpisSt 1..1 0..* stPol

a
PODATKOVNE BAZE II
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
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.
PODATKOVNE BAZE
Podpora orodij CASE
Konceptualni
Konceptualni
PM
i-CASE
PM
Odločitev o PB:
- Relacijska
- Hierarhična
- Objektna
Logični
Logični PM
PM Logično načrtovanje
Fizični
Fizični PM
PM
(skripta)
(skripta)
Reverse Engineering
Podatkovna ODBC
baza
SUPB
PODATKOVNE BAZE
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
ANALIZA NAČRTOVANJE
Konceptualni model Relacijski model
Entitetni tip Relacija / Tabela
Atribut Atribut / Stolpec
Enolični identifikator Ključ
Povezava 1:n Tuji ključ
PODATKOVNE BAZE
Povezava m:n 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
 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
 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
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
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
Ponovitev
Ključi relacije...
 Ker je relacija množica n-teric, so v njej vse n-
terice 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
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
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
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
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
Račun Šifra artikla Količina
Primarni ključ v tabeli Račun 15/05 A10 1
15/05 X12 1
Tuji ključ v tabeli Račun  kaže na primarni ključ v tabeli Artikel
PODATKOVNE BAZE
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:
 I. normalna oblika,
 II. normalna oblika,
 III. normalna oblika
 IV. poslovna normalna oblika
 Boyce Coddova normalna oblika
 IV. normalna oblika
 V. normalna oblika
PODATKOVNE BAZE
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
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
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
Primer
 Relacija StaffBranch ima odvečne podatke.
Atribut z odvečnimi (ponavljajočimi) podatki
PODATKOVNE BAZE
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
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
Anomalije pri brisanju
– Če iz relacije zbrišemo n-terico, ki predstavlja zadnjega člana
v neki organizacijski enoti, zgubimo tudi podatke o tej
organizacijski enoti.
PODATKOVNE BAZE
Anomalije pri spreminjanju
– Č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
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
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
Primer – relacija v nenormalizirani obliki
Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) )
Skupina ponavljajočih se atributov.
VŠ priimek ime pošta kraj šifra predmeta naziv ocena

64010632 Bratina Simon 4100 Kranj 20020 IS 10
20021 TPO 8
20033 IPI 8
64016209 Bizjak Tadeja 2250 Ptuj 20060 E1 9
20033 IPI 6
PODATKOVNE BAZE
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
Primer – pretvorba v 1NO
20021 TPO 8
20033 IPI 8
20033 IPI 6

64010632 Bratina Simon 4100 Kranj 20021 TPO 8
64010632 Bratina Simon 4100 Kranj 20033 IPI 8
64016209 Bizjak Tadeja 2250 Ptuj 20033 IPI 6
PODATKOVNE BAZE
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
!
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
64010632 Bratina Simon 4100 Kranj 20021 TPO 8
64010632 Bratina Simon 4100 Kranj 20033 IPI 8
64016209 Bizjak Tadeja 2250 Ptuj 20033 IPI 6
VŠ priimek ime pošta kraj VŠ šifra predmeta ocena

64010632 Bratina Simon 4100 Kranj 64010632 20020 10
64016209 Bizjak Tadeja 2250 Ptuj 64010632 20021 8
64010632 20033 8
šifra predmeta naziv 64016209 20060 9
20020 IS 64016209 20033 6
20021 TPO
20033 IPI
20060 E1
PODATKOVNE BAZE
3. letnik UNI, Informatika 20033 - 109
IPI -
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
!
Študent( VŠ, priimek, ime, pošta, kraj)

Relacijo razbijemo
Študent( VŠ, priimek, ime, #pošta)

Pošta(pošta, kraj)
PODATKOVNE BAZE
VŠ priimek ime pošta kraj

64010632 Bratina Simon 4100 Kranj
64016209 Bizjak Tadeja 2250 Ptuj
VŠ priimek ime pošta pošta kraj

64010632 Bratina Simon 4100 4100 Kranj
64016209 Bizjak Tadeja 2250 2250 Ptuj
PODATKOVNE BAZE
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
Primer – pretvorba v 4PNO...
Študent( VŠ, priimek, ime, #pošta, datum plačila šolnine, rok diplome)
Za izredne študenta Za redne študenta
Študent( VŠ, priimek, ime, #pošta)

Redni študent( #VŠ, rok diplome)
Izredni študent( #VŠ, datum plačila šolnine)
PODATKOVNE BAZE
Primer – pretvorba v 4PNO
VŠ Priimek Ime Datum plačila šolnine Rok diplome
64010632 Bratina Simon 15.3.2005
64016209 Bizjak Tadeja 19.4.2002
64010670 Berce Marjan 12.4.2004
64620010 Mele Silvana 1.4.2005
65120987 Leban Tibor 15.7.2005
VŠ Priimek Ime VŠ Datum plačila šolnine

64010632 Bratina Simon 64016209 19.4.2002
64016209 Bizjak Tadeja 64010670 12.4.2004
64010670 Berce Marjan
64620010 Mele Silvana VŠ Rok diplome
65120987 Leban Tibor 64010632 15.3.2005
64620010 1.4.2005
PODATKOVNE BAZE
3. letnik UNI, Informatika 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
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
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
Vaja
 Prva normalna oblika – odprava ponavljajočih
skupin

število točk, (datum izplačila, plača))

število točk, datum izplačila, plača)
PODATKOVNE BAZE
Vaja
 Prva normalna oblika – identifikacija
funkcionalnih odvisnosti
š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
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
Vaja
 Druga normalna oblika
številka pogodbe, število točk, datum izplačila, plača)
2NO
število točk)
Plača (#šifra delavca, datum izplačila, plača)
PODATKOVNE BAZE
Vaja
 Tretja normalna oblika !

š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
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
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
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
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.
Armstrongovi
aksiomi
X Y
PODATKOVNE BAZE II
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
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
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
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
 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
 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
Primer postopka od 1NO - BCNO...
Poročilo, ki je osnova
za pripravo relacij
PODATKOVNE BAZE II
Pretvorba v 1NO
Nenormalizirana
relacija
Relacija v 1NO
PODATKOVNE BAZE II
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
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
Odprava tranzitivnih odvisnosti  Pretvorba v 3NO
PropertyInspection( propertyNo, iDate, iTime, comments,

stafNo, sName, carReg )
Tranzitivna odvisnost
staffNo  sName

Staff( staffNo, sName )
stafNo, carReg )
PODATKOVNE BAZE II
3. Letnik UNI, Informatika Relacija- v138
3NO-
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

stafNo, carReg )
Fd1: propertyNo, iDate  iTime, comments, staffNo, carReg
Fd4: staffNo, iDate  carReg
Fd5: carReg, iDate, iTime  propertyNo, comments, staffNo
Fd6: staffNo, iDate, iTime  propertyNo, comments
PODATKOVNE BAZE II
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
Dekompozicija relacijev BCNO
StaffPropertyInspection 1NO
PropertyInspection Property 2NO
Staff PropertyInspect Property 3NO
Staff StaffCar Inspection Property BCNO
PODATKOVNE BAZE II
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
Večvrednostni
atributi
PODATKOVNE BAZE II
 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 Laboratorij Član Nosilec
projekta
– A −>> C LINF Mitja Mali Matej Mraz
LINF Matej Hribar Matej Mraz
LINF Mitja Mali Rok Lavbič
Med člani laboratorija in nosilci
projektov v laboratoriju ni nobene LINF Matej Hribar Rok Lavbič
povezave. Relacija realizira dve
povezavi tipa 1:*
PODATKOVNE BAZE II
 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
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
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 Laboratorij Nosilec

LINF Mitja Mali projekta
LINF Matej Hribar LINF Matej Mraz
LINF Rok Lavbič
PODATKOVNE BAZE II
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
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 R 1, R2,
…, Rn.
r = R1(r)  R2(r) ... Rn(r)
PODATKOVNE BAZE II
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
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
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
 Relacijo razbijemo v pod-relacije:
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
Metoda logičnega načrtovanja...
 Možni koraki logičnega načrtovanja:
– K2.1: Za entitetne tipe kreiraj relacije
– K2.2: Preveri relacije z normalizacijo
– K2.3: Preveri relacije s pregledom uporabniških transakcij
– K2.4: Preveri omejitve integritete
– K2.5: Preveri model z uporabnikom
– K2.6: Združi lokalne modele v globalni model (opcijsko)
– K2.7: Preveri zmožnosti modela za razširitve
PODATKOVNE BAZE II
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
 Ročna pretvorba: Enolični identifikator sestavljajo le atributi
– Močni entitetni tipi 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
Primer: močni in šibki entitetni tipi
Študent
EMŠO Predmet
VpisSt Izpit
Predmet
DavcnaSt 1..1 je opravil 0..* 0..* za 1..1
Datum Opis
Ime
Ocena StUr
Priimek
Letni
DtmRoj
Naslov
š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
 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
– 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
Primer: povezave 1:*
Študent
EMŠO
VpisSt Diploma
DavcnaSt 1..1 je opravil 1..* Datum
Ime
Ocena
Priimek
DtmRoj
Naslov

Diploma(Datum, #VpisSt, Ocena)
Prenos tujega ključa v smeri ena “proti mnogo”
PODATKOVNE BAZE II
Primer: povezave 1:1
Dekan Fakulteta
ID vodi
1..1 1..1 Fakulteta
Ime
Naziv
Priimek
Dekan(ID, Ime, Priimek, Naziv_fakultete)
Obveznost na obeh straneh:

entitetna tipa predstavimo z eno relacijo; izberemo ključ
PODATKOVNE BAZE II
Primer: povezave 1:1
oče
Profesor Fakulteta
ID je dekan
1..1 0..1 Fakulteta
Ime
Naziv
Priimek
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
– 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
Primer: rekurzivne povezave
je mentor
1..1
PDelavec
ID
Ime 0..*
Priimek
Naziv
PDelavec(ID, Ime, Priimek, Naziv, IDmentorja)

kreiramo relacijo z dvema kopijama primarnega ključa. Eden igra
vlogo primarnega drugi pa tujega ključa.
PODATKOVNE BAZE II
Primer: rekurzivne povezave
je mentor
1..1
PDelavec
ID
Ime 0..*
Priimek
Naziv
PDelavec(ID, Ime, Priimek, Naziv)

Mentor(#IDmentorja, #IDdelavca)
Rekurzivno povezavo pretvorimo v relacijo. Relacija za vsakega pedagoškega
delavca pove, kdo mu je (bil) mentor.
PODATKOVNE BAZE II
– 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
Primer: nadtipi, podtipi
PREVOZNO SREDSTVO
Registrska št.
Datum izdelave
Datum registracije
Moč motorja
Barva
Št. motorja
x Tip specializacije
OSEBNI AVTO TOVORNO VOZILO
Št. sedežev Nosilnost

Kilovati Tip
Vrsta motorja
Povprečna poraba
PODATKOVNE BAZE II
– 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
Primer: povezave *:*
Študent
EMŠO Predmet
VpisSt
Predmet
DavcnaSt 0..* je opravil 0..* Opis
Ime
StUr
Priimek
Letni
DtmRoj
Naslov

Predmet(Predmet, Opis, StUr, Letni)
Izpit(Datum, #VpisSt, #Predmet, Ocena)
PODATKOVNE BAZE II
K2.1 – Za entitetne tipe kreiraj relacije
– 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
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
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
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
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
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
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
K2.4 – Preveri omejitve integritete...
 V tem koraku preverimo pravila za zagotavljanje
celovitosti podatkov:
– Obveznost atributov
– Omejitve domen atributov
– Števnost
– Omejitve entitet (celovitost entitet)
– Omejitve povezav (celovitost povezav)
– Splošne omejitve
PODATKOVNE BAZE II
Primeri omejitev povezav
PODATKOVNE BAZE II
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
Povezava podatkovni model in DFD
DFD PM
PODATKOVNE BAZE II
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
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
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
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
Primer
Primer
uporabniškega
pogleda
PODATKOVNE BAZE II
Primer
Primer
globalnega
logičnega
podatkovnega
modela.
PODATKOVNE BAZE II
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
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
PODATKOVNE BAZE
Načrtovanje fizične podatkovne baze...
Konceptualni
Konceptualni
PM
i-CASE
PM
Odločitev o PB:
- Relacijska
- Hierarhična
- Objektna
Logični
Logični PM
PM
Fizični
Fizični PM
PM
(skripta)
(skripta)
Načrtovanje fizične PB
Reverse Engineering
Podatkovna ODBC
baza
SUPB
PODATKOVNE BAZE
Načrtovanje fizične podatkovne baze
 Fizično načrtovanje PB opredeljuje proces, s
katerim izdelamo opis implementacije PB na
sekundarnem pomnilnem mediju.
 Opisuje
– osnovne relacije,
– datotečno organizacijo,
– indekse za dosego učinkovitega dostopa do podatkov,
– povezane omejitve in
– varnostne mehanizme.
PODATKOVNE BAZE
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 – Analiziraj transakcije
 K4.2 – Izberi datotečno organizacijo
 K4.3 – Določi indekse
 K4.4 – Oceni velikost podatkovne baze
Koraka K1 in K2 se nanašata na izdelavo konceptualnega in

logičnega podatkovnega modela
PODATKOVNE BAZE II
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
K3 – Pretvorba v jezik za SUPB
 Namen koraka: iz logičnega modela izdelati
podatkovno shemo za ciljni SUPB.
 Poznati moramo funkcionalnosti ciljnega SUPB,
npr.:
– 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)?
PODATKOVNE BAZE II
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:
– Naziv relacije;
– Listo osnovnih atributov;
– Primarni ključ ter kjer smiselno alternativne in tuje ključe;
– Omejitve povezav.
PODATKOVNE BAZE II
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
Primer opisa osnovnih relacij z DBDL
PODATKOVNE BAZE II
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
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
Primer hranjenja izpeljanega atributa
PODATKOVNE BAZE II
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
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
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
 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
 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
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
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
Obrazec za podrobno analizo transakcij
PODATKOVNE BAZE II
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
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
 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
 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
 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
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
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
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
Primer pogleda
Pedagoški delavec Predmet
Pedagog <pk> Nosilec = Pedagog Predmet <pk>
Vrsta PD <fk> Smer <fk>
Laboratorij <fk> Nosilec <fk>
Ime Asistent = Pedagog Asistent <fk>
Priimek Naziv
Status <fk> StUr
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
Predavatelj
Naziv_predavatelja
PODATKOVNE BAZE II Stevilo_Predmetov
3. Letnik UNI, Informatika - 216 - 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
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
 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
 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
 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
Primer normaliziranega modela
PODATKOVNE BAZE II
Primeri relacij
PODATKOVNE BAZE II
K7.1 – Združevanje 1:1 povezav
Če podatke, ki so v različnih
relacijah obravnavamo skupaj,
je združitev primerna.
PODATKOVNE BAZE II
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
“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
“Lookup tabele”
PODATKOVNE BAZE II
K7.3 - Podvajanje tujih ključev
PODATKOVNE BAZE II
K7.4 - Podvajanje atributov v povez. *:*
PODATKOVNE BAZE II
K7.5 - Uvedba ponavljajočih skupin
PODATKOVNE BAZE II
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
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
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
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
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
Povzeto po [1]
Poglavje 2
Obvladovanje transakcij
 Transakcije in njihove lastnosti

 Nadzor sočasnosti
 Obnova podatkov po nesrečah
PODATKOVNE BAZE II
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
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
 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
Si; i=1 .. n ≈ konsistentna ali skladna stanja v podatkovni bazi
Med izvajanjem transakcije je lahko stanje v bazi neskladno!
T1 T2 T3 ..... Tn
S1 S2 S3 Sn
PODATKOVNE BAZE II
 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 rollback
T1 T2
S1 S2 S3
PODATKOVNE BAZE II
 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
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
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
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
Obvladovanje transakcij – arhitektura
 Komponente SUPB za obvladovanje transakcij,
nadzor sočasnosti in obnovitev podatkov:
Koordinira transakcije
v imenu uporabniških Realizira različne strategije
programov 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 Zagotavlja obnovitev podatkov
glavnim spominom. ob napakah in nesrečah...
PODATKOVNE BAZE II
P 3.2
Nadzor sočasnosti

 Namen nadzora sočasnosti
 Serializacija urnika transakcij
 Zaklepanje in časovno žigosanje
 Mrtve in žive zanke – detekcija in odprava
 Optimistične metode nadzora sočasnosti
PODATKOVNE BAZE II
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
 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
 Prepletanje operacij dveh transakcij…
T1 T2
t1
CPU
T1 T2 t2
CPU
CPU CPU t3
CPU
CPU CPU t4
I/O CPU
CPU CPU t5
I/O CPU
I/O CPU t6
I/O CPU
I/O CPU t7
I/O CPU
I/O CPU t8
CPU
t9
I/O I/O CPU
t10
CPU I/O CPU
t11
CPU CPU CPU
t12
I/O
t13
I/O
t14
CPU
t15
PODATKOVNE BAZE II
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
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
 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
 Nekonsistentna analiza
 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.
PODATKOVNE BAZE II
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
 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
 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
Primer
UA UB UC
Nezaporedni urnik Nezaporedni urnik Zaporedni urnik
PODATKOVNE BAZE II
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
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
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
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
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
konfliktnih - 263 -
©Laboratorij za informatiko operacijah ima vedno kakšno slepo pisanje.
3. Letnik UNI, Informatika
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
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
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
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
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
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
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
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

PODATKOVNE BAZE II
in obratno.
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
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
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
Reševanje izgubljenih sprememb z 2PL
PODATKOVNE BAZE II
Reševanje nepotrjenih podatkov z 2PL
PODATKOVNE BAZE II
Reševanje nekonsistentne analize z 2PL
PODATKOVNE BAZE II
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
Kaskadni preklic…
PODATKOVNE BAZE II
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 - 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
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
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
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
Mrtve zanke…
PODATKOVNE BAZE II
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
Č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
 Č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
 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
 Princip delovanja časovnega žigosanja
(nadaljevanje):
B) 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
 Sicer: ts(T) ≥ write_timestamp(x), s pisanjem nadaljujemo.
Nastavimo write_timestamp(x) = ts(T).
PODATKOVNE BAZE II
 Č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
 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)
 Če x že zapisana s strani mlajše transakcije
potem transakcijo ignoriramo.
 Sicer: ts(T) ≥ write_timestamp(x), s pisanjem nadaljujemo.
Nastavimo write_timestamp(x) = ts(T).
PODATKOVNE BAZE II
 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
Primer
PODATKOVNE BAZE II
Primerjava metod nadzora sočasnosti
PODATKOVNE BAZE II
Č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
 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
 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
 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
Č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
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
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
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
P 3.3
Transkacije v porazdeljenih sistemih

 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
Transakcije v porazdeljenih sistemih
 V SUPPB obvladovanje transakcij težje:
– Zahteva atomarnost globalnih transakcij in vsake od pod-
transakcij
 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
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 pod-
transakcije na ustrezna vozlišča.
– Poslane pod-transakcije prevzamejo lokalni koordinatorji transakcij.
– Rezultat se posreduje nazaj koordinatorju transakcij na vozlišču S 1.
PODATKOVNE BAZE
Podiplomski študij - 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:
– 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.
PODATKOVNE BAZE II
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
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
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
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 S 1:
– 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
Centraliziran 2PL…
 Postopek za transakcijo T pognano na vozlišču S 1

(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
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
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
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
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
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
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
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
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
Č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
Č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
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
PODATKOVNE BAZE II
 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
T3 konstruiramo
T1 WFG,Tdobimo T2 T2 T3
1
S1 S2 S3
T1 T2
PODATKOVNE BAZE II
T3 -
- 324
©Laboratorij za informatiko – Združeni WFG
 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
 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
 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
 Hierarhični detekcija (nadaljevanje)
– Prednost pred centraliziranim pristopom: manjša odvisnost
od centralnega vozlišča.
– Slabost je kompleksnost implementacije
PODATKOVNE BAZE II
 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

PODATKOVNE BAZE II T2 pognana na S2, njen del pa tudi na S3
T3 pognana na S3, njen del pa tudi na S1
 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
P 3.4
Obnova podatkov po nesrečah

 Potreba po obnovljivosti
 Transakcije in obnovljivost
 Komponente SUPB za obvladovanje obnovljivosti
 Tehnike obnovljivosti
 Obnovljivost v porazdeljenih SUPB
 Napredni transakcijski modeli
PODATKOVNE BAZE II
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
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
 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
 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
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
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
 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
 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
 Č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
 Č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
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
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
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
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
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
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
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
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
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.
Popolna
PB kopija PB
zadnje
spremembe
Inkrementalna
kopija
PB
PODATKOVNE BAZE II
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
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
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
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
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
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
 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
 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
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
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
UNDO in REDO s kontrolno točko
 Predpostavimo, da se je v času tc izvedla

kontrolna točka:
PODATKOVNE BAZE II
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
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
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
 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
 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
 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
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
 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
 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
 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
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
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
 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
 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
 Č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
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
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
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 Strani podatkovne baze Senčna tabela strani
1 1
2 2
3 3
4 4
PODATKOVNE BAZE II
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
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
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 3
Strežnik 1 Komunikacijsko omrežje
pod-transakcija 2
PODATKOVNE BAZE II
3. Letnik UNI, Informatika - 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
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
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
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
Commit
Primer: 2PC, mesto glasuje potrditev
PODATKOVNE BAZE II
Abort
Primer: 2PC, mesto glasuje prekinitev
PODATKOVNE BAZE II
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
 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
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
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
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
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
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
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
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
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
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
3PC protokol…
PODATKOVNE BAZE II
Commit
Primer: 3PC, mesto glasuje potrditev
PODATKOVNE BAZE II
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
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
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
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
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 PRE-
COMMIT in po potrditvah še GLOBAL-COMMIT.
PODATKOVNE BAZE II
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
 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
 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
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
 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
 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
 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
Napredni transakcijski modeli
 V nadaljevanju:
– Vgnezdeni transakcijski model
– Sage
– Večnivojski transakcijski model
– Dinamično prestrukturiranje
– Modeli delovnih tokov
PODATKOVNE BAZE II
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.
– Primer - rezervacijski sistem: Transakcije se
morajo 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
PODATKOVNE BAZE II
- 415 - na trans., ki je v teku
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
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
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

Vgnezdeni transakcijski model SAGA
T1 T3 T4 T5 T6
T1 T3 T4 T5 T6 Lastnosti sage:
• samo en nivo
T2
T2
T5
T5
T6
T6
gnezdenja,
C3
C3
C4
C4
C5
C5
C6
C6 • za vsako
T3 T4
Transakcija s podtransakcijo
Transakcija s
kompenzacijskim
T3 T4
kompenzacijskim
učinkom obstaja
učinkom
transakcija s
PODATKOVNE BAZE II
kompenzacijskim
3. Letnik UNI, Informatika - 418 - 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
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
 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
 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
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:
T71, ki poveča balx za 5
T72, ki odšteje 5 od baly
T8:
T81, ki poveča baly za 10
T82, ki odšteje 2 od balx
PODATKOVNE BAZE II
Ker sta seštevanje in odštevanje komutativna, se
lahko podtransakcije izvajajo v poljubnem vrstnem
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
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
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
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
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
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
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
P 4.1
O optimizaciji poizvedb

 Zakaj optimizacija poizvedb
 Tehnike optimizacije
 Procesiranje in optimizacija poizvedb
 Beleženje statistike za potrebe optimizacije
 Faze procesiranja poizvedb
 Dinamična in statična optimizacija
PODATKOVNE BAZE II
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
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
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
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
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
Faze procesiranja poizvedb
 Procesiranje poizvedb se sestoji iz štirih faz:
– Dekompozicija (razčlenjevanje in preverjanje);
– Optimizacija;
– Generiranje kode;
– Izvedba.
PODATKOVNE BAZE II
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
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
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:

 Analiza
 Normalizacija
 Semantična analiza
 Poenostavitev
 Reorganizacija poizvedbe
PODATKOVNE BAZE II
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 Ne obstaja v katalogu (staffNo)
FROM Staff
Nekompatibilnost operacije in podatkovnega
WHERE position > 10; tipa  position je tipa character
PODATKOVNE BAZE II
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
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
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
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
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
 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
 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
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
 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
Primer preverjanja semantične pravilnosti
 Imamo naslednjo poizvedbo
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
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
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)  p
p  false  false p  false  p
p  true  p p  true  true
p  (¬p)  false p  (¬p)  true
p  (p  q)  p p  (p  q)  p
PODATKOVNE BAZE II
P 4.2
Hevristična optimizacija poizvedb

 Pravila transformacije relacijske algebre
 Primer uporabe transformacijskih pravil
 Strategije hevrističnega procesiranja
PODATKOVNE BAZE II
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
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
– Komutativnost operacij selekcije.
p(q(R)) = q(p(R))
– Primer:
branchNo='B003'(salary>15000(Staff)) = salary>15000(branchNo='B003'(Staff))
nazaj
PODATKOVNE BAZE II
– 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
– 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
– 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
– 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
 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
– 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 Staff.branchNo=Branch.branchNo Branch) =
(position, branchNo(Staff)) Staff.branchNo=Branch.branchNo (
city, branchNo (Branch))
PODATKOVNE BAZE II
 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
– Komutativnost operacij unija in presek.
RS=SR
RS=SR
PODATKOVNE BAZE II
– 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
– Komutativnost projekcije in unije.
L(R  S) = L(S)  L(R)
PODATKOVNE BAZE II
– 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
 Primer za transformacijsko pravilo 11
(Staff Staff.staffNo=PropertyForRent.staffNo PropertyForRent)
ownerNo=Owner.ownerNo  staff.lName=Owner.lName Owner =
Staff staff.staffNo=PropertyForRent.staffNo  staff.lName=lName
(PropertyForRent ownerNo Owner)
PODATKOVNE BAZE II
– Asociativnost unije in preseka.
(R  S)  T = S  (R  T)
(R  S)  T = S  (R  T)
PODATKOVNE BAZE II
Primer uporabe transformacijskih pravil…
 Primer poizvedbe:
– Za stranke, ki iščejo stanovanje, najdi nepremičnine, ki
ustrezajo lastnostim, ki so jih stranke podale.

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
 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
 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
Izhodišče Po prvem koraku
PODATKOVNE BAZE II
– 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
Po prvem koraku Po drugem koraku
PODATKOVNE BAZE II
– Tretji korak:
 Pravilo 11: da spremenimo vrstni red equijoin stikov, tako da so
bolj restriktivni na začetku.
PODATKOVNE BAZE II
Po drugem koraku Po tretjem koraku
PODATKOVNE BAZE II
– Četrti korak:
 Uporabimo pravili 4 in 7, da projekcije premaknemo pred equijoin
stike in naredimo dodatno projekcijo (glej pravilo 7, dodatek).
PODATKOVNE BAZE II
Po tretjem koraku Po četrtem koraku
PODATKOVNE BAZE II
 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
Primer uporabe transformacijskih pravil
Po četrtem koraku Po dodatnem koraku
PODATKOVNE BAZE II
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
 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
 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
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
P 4.3
Stroški operacij relacijske algebre

 Kako računamo stroške operacij relacijske algebre
 Primer za operacijo Selekcija
PODATKOVNE BAZE II
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
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
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:
1 ; če A ključ
[nTuples(R)/nDistinctA(R)] ; sicer
SCA(R) =
PODATKOVNE BAZE II
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
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
Primer za operacijo Selekcija
 Različni načini implementacije operacije selekcija.
Npr.:
– 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.
PODATKOVNE BAZE II
Različne implementacije
 Tabela prikazuje ocene stroškov različnih
strategij implementacije operacije selekcija
PODATKOVNE BAZE II
P 4.4
Alternativne strategije izvedbe

 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
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) R (T S) (S T) R (T S) R
S (R T) S (T R) (R T) S (T R) S
T (R S) T (S R) (R S) T (S R) T
PODATKOVNE BAZE II
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
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
 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
 Obstajajo tudi druge vrste dreves relacijske
algebre:
Desno-urejeno linearno drevo
Navadno linearno drevo
Nelinearno drevo - grm
PODATKOVNE BAZE II
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
notranja
PODATKOVNE BAZE II
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
Fizične operacije in plan izvedbe
 Primer nadomestitve logičnih operacij s fizičnimi
a) Primer drevesa relacijske algebre; b) pripadajoči plan izvedbe
PODATKOVNE BAZE II
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
Zmanjševanje iskalnega prostora…
 Restrikcija 2:
– Kartezijski produkti se nikoli ne izvedejo, razen če
je to eksplicitno zahtevano s poizvedbo.

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
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
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
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
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
FROM Staff s, PropertyForRent p Dodaten predikat lahko zelo
WHERE s.staffNo = p.staffNo AND uporaben, če ime relacija Staff
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,

FROM Staff s, PropertyForRent p Dodaten predikat le poveča
komplesnost poizvedbe!
WHERE s.staffNo = p.staffNo AND
salary > 20000 AND
position = ‘Manager’;
PODATKOVNE BAZE II

PB2 Predavanja - v2009

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PB2 Predavanja - v2009

Uploaded by

Copyright:

Available Formats

Podatkovne baze II

3. letnik, univerzitetni študij

Gradivo, verzija 2.2

Citiranje: glej [3,15-20] = glej v knjigi T. Mohorič, strani od 15 do 20.

 II. Obvladovanje transakcij

 III. Evaluacija poizvedb

 Podatkovne baze pogosto razvijamo po delih.

Normalizacija = identifikacija potrebnih atributov in njihovih

 Pristop od spodaj navzgor primeren za enostavne

– Na začetku podatkovni modeli z le nekaj osnovnih entitetnih

Področje 1 Področje 2 ... Področje n

Področna Področna Področna

svet mentalni model konceptualni model logični model PB

Ime entitetnega tipa

OSEBA živi KRAJ

OSEBA živi KRAJ

Vloga entitete v razmerju

 Kardinalnost (števnost) predstavlja število entitet

Naziv Opis Sinonim Število entitet

Primer dvoumne povezave

Kateri katedri pripada oprema O2?

Član 1..* Pripada 1..1 Katedra

Laboratorij 1..* Sodi v 1..1 Katedra

Entitetni Atributi Opis Podatkovni Dolžina ...

Študent Lahko tudi:

Redni študent Izredni študent

Agregacija povečuje semantiko modela

Kompozicija povečuje semantiko modela

Profesor Pedagog Asistent

– Kaj če ima oče otroka iz prejšnjega zakona?

se nanaša na Rok za Predmet

vpisSt 1..1 0..* stPol

svet mentalni model konceptualni model logični model PB

Konceptualni model Relacijski model

Entitetni tip Relacija / Tabela

Atribut Atribut / Stolpec

Enolični identifikator Ključ

Povezava 1:n Tuji ključ

 V relacijski shemi R velja X  Y (X funkcionalno

 Atributi X so ključ relacijske sheme oziroma

 Kandidat za ključ je vsaka podmnožica atributov

Primarni ključ v tabeli Artikel

Tuji ključ v tabeli Račun  kaže na primarni ključ v tabeli Artikel

Atribut z odvečnimi (ponavljajočimi) podatki

 Obstaja več stopenj normalnih oblik. Obravnavali

Skupina ponavljajočih se atributov.

VŠ priimek ime pošta kraj šifra predmeta naziv ocena

Odpravimo ponavljajoče atribute

Identificiramo funkcionalne odvisnosti

F  { VŠ  (priimek, ime, pošta, kraj), šifra predmeta 

Določimo primarni ključ

VŠ priimek ime pošta kraj šifra predmeta naziv ocena

Študent( VŠ, priimek, ime, pošta, kraj)

VŠ priimek ime pošta kraj VŠ šifra predmeta ocena

Študent( VŠ, priimek, ime, pošta, kraj)

Študent( VŠ, priimek, ime, #pošta)

VŠ priimek ime pošta kraj

VŠ priimek ime pošta pošta kraj

Za izredne študenta Za redne študenta

Študent( VŠ, priimek, ime, #pošta)

VŠ Priimek Ime VŠ Datum plačila šolnine

Pomen relacije: delavec s šifro (šifra delavca), priimkom (priimek) ter

V relaciji so zajeti tudi atributi, ki povedo, kakšne plače so prejemali