Fakulteta za računalništvo in informatiko Tržaška cesta 25 1000 Ljubljana

Podatkovne baze II, 2009/10

Teorija

[povzeto po prosojnicah za PB2 (prof. Marko Bajec)]

--za interno rabo--

Žiga Makuc

#zadnja posodobitev 22.6.2010

2/31

Poglavje 1

Načrtovanje podatkovnih baz 1. Pristopi k načrtovanju PB Podatkovne baze pogosto razvijamo po delih. Obstajajo trije glavni pristopi:

Pristop od spodaj navzgor Začne z atributi in jih združuje v skupine Tak pristop predstavlja 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.

Pristop od vrha navzdol. Primeren za večje baze Na začetku imamo podatkovni model z le nekaj osnovnimi entitetnimi tipi in razmerij Nato korakoma razgradimo model na pod-entitete, povezave in atribute Tak pristop predstavlja uporaba tehnike Entiteta – Razmerje (E-R).

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

Poznamo tri nivoje načrtovanja:

Konceptualno načrtovanje

Logično načrtovanje

Kreiranje fizične podatkovne baze Vmes so torej koraki prehodov med modeli in morebitna avtomatizacija prehodov.

2. Konceptualno načrtovanje

Slika 1: Konceptualno načrtovanje

Konceptualno načrtovanje je opredelitev podatkovnih potreb oz. zahtev poslovne domene. Konceptualno načrtovanje preko konceptualnega modela poskrbi za opis pomena podatkov, potrebnih za poslovno domeno. Konceptualnega načrtovanja ne moremo avtomatizirati, za njegovo izvedbo je odgovoren analitik. Gre za prenos semantike v model (poenostavitev realnosti, pri čemer je abstrakcija realnosti poljubno natančna). Je najbolj kritično – napake se prenašajo naprej na naslednje modele. Najpogosteje uporabljana tehnika za predstavitev konceptualnih podatkovnih modelov sta entitetni model (konceptualni podatkovni model/podatkovni model/entitetni model/ER model)

3/31

Konceptualni podatkovni model ima sledeče gradnike:

Entitetni tip Entitete so posamezni primerki tipov objektov iz poslovne domene: dogodki, predmeti, osebe,

pravila, dejstva Vse entitete, ki ustrezajo določeni predstavi, pripadajo posameznemu entitetnemu tipu Vsakemu entitetnemu tipu pripada množica entitet, ki ji pravimo entitetna množica Entitetna množica je časovno spremenljiva

Atribut Entitetni tipi imajo določene lastnosti, posamezne entitete se med seboj razlikujejo po vrednostih teh

lastnosti Lastnosti, ki so pomembne za opazovano poslovno domeno, vključimo v entitetni model kot 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 Osnovni, neosnovni, izpeljani

Minimalna števnost 0 pomeni, da je atribut lahko brez vrednosti (ni obvezen-not mandatory) Atribut pripada določenemu tipu: numerični, znakovni,… Za večino tipov je potrebno določiti tudi dolžino.

Razmerje Entitete niso svet zase, medsebojno se povezujejo preko razmerij/povezav, ki imajo določen pomen V ER modelu je predstavitev razmerja povezava Kardinalnost (števnost) predstavlja število entitet entitetnega tipa, ki so v razmerju glede na pomen

razmerja. Obveznost pove, ali sta dve entiteti vedno v razmerju ali lahko tudi nista v razmerju: obvezno,

neobvezno razmerje

Enolični identifikator 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 Imamo lahko več enoličnih identifikatorjev, vendar moramo enega izbrati – določiti; ta je podlaga za

ključ v relacijskem modelu Močni entitetni tip

Enolični identifikator sestavljajo le atributi entitete (identifikacijski atributi) Šibki entitetni tip

Enolični identifikator ni sestavljen le iz lastnih atributov, temveč tudi iz razmerij oz. drugih entitet v razmerju oz. njenih identifikatorjev

Pojem generalizacije in specializacije: Totalno in ekskluzivno

OSEBA = Moški ali Ženska (samo eno)

B in C pokrivata A, če velja: EB EC = EA in EB EC = {} Totalno in prekrivno

B in C pokrivata A, če velja: EB EC = EA in EB EC ≠ {} Delno in ekskluzivno

B in C pokrivata A, če velja: EB EC EA in EB EC = {} Delno in prekrivno

OSEBA = Študent ali Športnik (lahko tudi oboje)

B in C pokrivata A, če velja: EB EC EA in EB EC ≠ {}

4/31

3. Metoda konceptualnega načrtovanja Možni koraki konceptualnega načrtovanja:

K1.1: Identificiramo entitetne tipe

K1.2: Identificiramo povezave

K1.3: Identificiramo in z entitetnimi tipi povežemo atribute

K1.4: Atributom določimo domene

K1.5: Določimo kandidate za ključe; izmed kandidatov izberemo primarni ključ

K1.6: Po potrebi uporabimo elemente razširjenega diagrama entiteta – razmerje

K1.7: Preverimo, če v modelu obstajajo odvečni elementi

K1.8: Preverimo, če model “zdrži” transkacije

K1.9: Preverimo model z uporabnikom K1.1: Identificiramo entitetne tipe Na voljo je več različnih tehnik. 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 Načrtovanje je subjektivne narave (možnih je več pravilnih rešitev). Načrt zavisi od presoje in izkušenj. Entitetne tipe je nato potrebno dokumentirati(naziv,opis,število,...). K1.2 – Identificiramo povezave Ko smo identificirali entitetne tipe, skušamo opredeliti vse povezave med njimi. Podobno pregledamo uporabniške zahteve:

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 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) Povezavam nato določimo števnost. Potem pogledamo, da slučajno ne obstajajo dvoumne (npr. profesor je član katedre, ki pa vključuje laboratorij; z rekonstruiranjem se popravi na profesor je član laboratorija, ki pa je vsebovan v neki katedri) ali nepopolne povezave (npr. Katedra ima neke člane, ki pa so lahko ali pa niso skrbnik neke opreme; nato bi se pa vprašali kateri katedri pripada neka oprema-mogoče nobeni; tudi to se popravi z rekonstruiranjem-povežemo še katedro in opremo s povezavo). Tudi povezave je potrebno dokumentirati. K1.3 – Identificiramo atribute Skušamo identificirati lastnosti entitet ter povezav. Zopet lahko uporabimo tehniko proučevanja uporabniških zahtev. Nekaj primerov, pri katerih je potrebna pozornost:

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.

Poleg tega smo pozorni tudi na atribute, ki navidez pripadajo več entitetam (recimo profesor in asistent lahko združimo v pedagoški delavec). Tudi atribute je potrebno dokumentirati.

5/31

K1.4 – Atributom določimo 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). Tudi domene je potrebno dokumentirati. K1.5 – Določimo 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. 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,

Imena navadno niso dober kandidat za ključ,

Pazimo na šibke entitetne tipe,... Tud primarne ključe je potrebno dokumentirati. K1.6 – Uporabimo elemente EER diagrama EER predstavlja razširjeni ER diagram. Elementi razširjenega ER diagrama so:

Specializacija: ugotovljamo razlike med entitetami doočenega tipa in poiskusimo razbiti entitetni tip na več specializiranih entitet (študent: redni, izredni)

Generalizacija: ugotavljamo skupne lastnosti entitet različnih tipov in kreiramo nov tip s skupnimi lastnostmi (pedagoški delavec: profesor, asistent)

Agregacija: modeliramo povezavo “je del” oziroma “ima”, s katero določimo pripadnost tipa “del” tipu “celota” (Študent – Indeks)

Kompozicija: posebna vrsta agregacije z močnim lastništvom “del” ne more obstajati brez “celote” (Študent – Indeks)

Elementi EER diagrama povečajo semantiko (pomen) modela vendar lahko negativno vplivajo na “berljivost” modela. K1.7 – Preverimo obstoj odvečnih elementov Preverimo sledeče stvari:

Pregledamo povezave 1:1, če taki tipi obstajajo, jih je potrebno združiti (če so primarni ključi različni, izberemo enega)

Odstranimo odvečne povezave, to je takrat, ko je možno priti do iste informacije preko druge povezave, izdelati pa želimo minimalni podatkovni model

K1.8 – Preverimo če model zdrži transkacije V tem koraku preverimo, če model, ki smo ga dobili s koraki K1.1 do K1.7 zdrži transakcije. Transakcije izvajamo ročno. Obstajata dva pristopa:

Preverjanje opisa transakcij Vsako transakcijo opišemo Preverimo, če model zajema vse entitetne tipe, povezave in atribute, ki jih transakcija potrebuje.

Preverjanje transakcijskih poti Transakcije preverimo na modelu – pot transakcije narišemo S tem lahko identificiramo pomankljivosti modela, odkrijevmo odvečne dele,...

Preverjanje transakcij je zamudno delo, vendar je zelo pomembno! K1.9 – Preverimo model z uporabnikom Na koncu preverimo model še z uporabnikom. Vsakršne napake ali odstopanja lahko vodijo v ponovitev prejšnih korakov. V mnogih podjetjih mora uporabnik podpisati, da je model ustrezen.

6/31

4. Logično načrtovanje in normalizacija

Slika 2: Logično načrtovanje

Logično modeliranje podatkovne baze nastopi za konceptualnim modeliranjem. Ta jezik je razumljiv ciljnemu SUPB. Prehod iz konceptualnega v logični model je navadno avtomatiziran s strani CASE orodij.

Slika 3: Primer prehoda iz relacijske baze v Oraclov SUPB

PONOVITEV: Funkcijske odvisnosti so sredstvo, s katerim lahko v relacijskem modelu povemo, katere vrednosti relacij so veljavne in katere sploh ne morejo obstajati. Poznamo več vrst odvisnosti:

Funkcionalne odvisnosti,

Večvrednostne odvisnosti,

Stične odvisnosti. Predpostavimo, da obstaja relacijska shema R z množico atributov, katere podmnožici sta X in Y. V relacijski shemi R velja X Y (X funkcionalno določa Y oziroma Y je funkcionalno odvisen od X), če v nobeni relaciji, ki pripada shemi R, ne obstajata dve n-terici, ki bi se ujemali v vrednostih atributov X in se ne bi ujemali v vrednostih atributov Y. 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. 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:

X A1 A2 ... An

ne obstaja X’, ki bi bila prava podmnožica od X in ki bi tudi funkcionalno določala A1 A2 ... An

Poznamo več vrst ključev: – Kandidat za ključ, – Primarni ključ, – Super ključ, – Tuji ključ.

Kandidat za ključ je vsaka podmnožica atributov relacije, ki relacijo enolično določa. Primarni ključ je tisti kandidat za ključ, ki ga izberemo za shranjevanje relacij v fizični podatkovni bazi. Super ključ 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.

7/31

1. 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; redundanca povečuje verjetnost pravilnega razumevanja informacije).

Prednosti uporabe podatkovnih baz, ki jih sestavljajo množice primernih relacij, so:

Enostavnejši dostop do podatkov ter vzdrževanje podatkov,

Večja učinkovitost,

Boljša izraba diskovnih kapacitet.

Osnovni cilj načrtovanja relacijske podatkovne baze je grupirati atribute v relacije tako, da bo čim manj redundance med podatki. S tem povečamo učinkovitost, ter zmanjšamo potrebe po diskovnih kapacitetah (zmanjšamo stroške). 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 Če dodamo podatke o novih članih za neko organizacijsko enoto moramo vpisati tudi vse podrobnosti

o organizacijski enoti. Če dodamo podatke o novi organizacijski enoti, ki še nima nobenega člana, moramo v vsa polja, ki

člane opisujejo, vpisati null.

Anomalije pri brisanju n-teric iz relacije Če brišemo neke n-terice, ki predstavlja zadnjega člana v neki organizacijski enoti, izgubimo tudi

podatke o tej organizacijski enoti

Anomalije pri spreminjanju n-teric Če želimo spremeniti vrednost nekega atributa določene organizacijske enote (npr. naslov), moramo

popraviti vse n-terice, v katerih takšna vrednost atributa nastopa Postopku preoblikovanja relacij v obliko, pri kateri do ažurnih anomalij ne more priti, pravimo normalizacija. Obstaja več normalnih oblik:

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),

ima definiran primarni ključ in določene funkcionalne odvisnosti. Koraki:

odstranimo ponavljajoče atribute, določimo funkcionalne odvisnosti, določimo primarni ključ.

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). 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.

8/31

3NO – tretja normalna oblika Relacija je v tretji normalni obliki, če:

je v drugi normalni obliki in 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.

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.

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. Osnovne normalne oblike (1NO, 2NO, 3NO) v večini primerov ne zadoščajo, zato uporabimo razširjeno normalizacijo. Razširjena normalizacija zajema BCNO, 4NO, 5NO. PONOVITEV: Cel nabor funkcionalnih odvisnosti v relacijski shemi je lahko zelo velik, zato je smiselno določiti podmnožico odvisnosti, ki dobro odraža celoto. Podmnožico pa lahko določimo s pomočjo pravil sklepanja. Množico vseh funkcionalnih odvisnosti, ki jo je moč pridobiti na osnovi množice X, imenujemo zaprtje X, označimo pa z X+. 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:

Refleksivnost

če B A, potem A B

Razširitev če A B, potem A,C B,C

Tranzitivnost če A B in B C, potem A C,

pri čemer velja, da so A, B in C podmnožice atributov relacijske sheme R. 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.

BCNO – Boyce-Coddova normalna oblika BCNO je strožja od 3NO:

razširja omejitve na vse kandidate za ključ, zahteva, da je vsaka determinanta (atribut ali skupina atributov, ki funkcionalno določa nek

drug atribut ali skupino atributov) tudi kandidat za ključ. 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 BCNO odpravlja anomalije, ki so posledica funkcionalnih odvisnosti

9/31

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 1NO, ki ne dopuščajo večvrednostnih atributov. 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

zapišemo jih kot A −>> B

več-vrednostne odvisnosti delimo na trivialne in netrivialne.

MVD A −>> B v relacijski shemi R je trivialna, če:

o B A ali

o A B = R.

Če noben izmed pogojev ni izpolnjen, je MVD netrivialna (ta povzroča anomalije pri spreminjanju).

4NO – četrta normalna oblika Relacija je v četrti normalni obliki, če:

je v BCNO in ne vsebuje nobenih netrivialnih več-vrednostnih odvisnosti.

Kar pomeni, da za vsako X –>> Y velja, da je to trivialna odvisnost ali pa da je X superključ sheme R.

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.

Stična odvisnost (R1, R2,..., Rn) nad shemo R omejuje možna stanja r v shemi R. Omejitev določa, da mora imeti vsako legalno stanje r neizgubno stično dekompozicijo v R1, R2, …, Rn.

5NO – peta normalna oblika Relacija je v peti normalni obliki, če:

v njej ni nobenih stičnih odvisnosti.

Da ni stičnih odvinosti pomeni, če je za vsako v relaciji 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

5. Metoda logičnega načrtovanja Možni koraki logičnega načrtovanja:

K2.1: Za entitetne tipe kreiramo relacije

K2.2: Preverimo relacije z normalizacijo

K2.3: Preverimo relacije s pregledom uporabniških transakcij

K2.4: Preverimo omejitve integritete

K2.5: Preverimo model z uporabnikom

K2.6: Združimo lokalne modele v globalni model (opcijsko)

K2.7: Preverimo zmožnosti modela za razširitve K2.1 – Za entitetne tipe kreiramo relacije Namen je 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 je podprta s strani CASE orodij).

10/31

Lahko pa jo tudi pretvorimo ročno:

Močni entitetni tipi Za vsak močan entitetni tip kreiramo relacijo, ki vključuje vse enostavne atribute tega entitetnega

tipa. Namesto sestavljenih atributov vključimo njihove atribute, ki jih sestavljajo.

Šibki entitetni tipi Za vsak šibki entitetni tip kreiramo 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.

Povezave 1:* Za vsako povezavo 1:* prenesimo 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.

Obveznost na obeh straneh 1:1 povezave Entitetna tipa združimo v eno relacijo. Za primarni ključ izberemo 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č.

Rekurzivne povezave 1:1 Pri rekurzivnih povezavah tipa 1:1 upoštevamo pravila, ki izhajajo iz obveznosti povezav.

Obveznost na obeh straneh: rekurzivno povezavo predstavimo z eno relacijo in dvema kopijama primarnega ključa.

Obveznost na eni, neobveznost na drugi strani: kreiramo eno relacijo z dvema kopijama primarnega ključa ali kreiramo novo relacijo. Nova relacija naj ima samo dva atributa – kopiji primarnega ključa.

Neobveznost na obeh straneh: kreiramo novo relacijo. Nova relacija naj ima samo dva atributa – kopiji primarnega ključa.

Povezave med nadtipi in podtipi Identificiramo 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,...

Povezave *:* Kreiramo relacijo, ki predstavlja povezavo ter vse njene atribute. Primarne ključe entitetnih tipov,

ki sta povezana s tako povezavo, vključimo v novo relacijo kot tuji ključ. Tuji ključi bodo obenem tudi primarni ključi – samostojno ali v kombinaciji z drugimi atributi relacije.

Več-vrednostni atributi Za predstavitev več-vrednostnih atributov kreiramo novo relacijo. V novo relacijo vključimo 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.

11/31

K2.2 – Preverimo relacije z normalizacijo Namen tega koraka je preveriti, če so vse pridobljene relacije v ustrezni normalni obliki. S tem zagotovimo, da ni odvečnih podatkov, ter da imajo vse relacije minimalno število atributov. Sama prevedba konceptualnega modela v logični model nam navadno da relacije, ki ustrezajo 3NO. Če to ne drži, so v konceptualnem modelu ali v postopku prevedbe napake. Logični model ni dokončen, saj predstavlja le kako načrtovalec razume pomen in naravo podatkov. Specifične potrebe v zvezi z učinkovitostjo lahko zahtevajo drugačen fizični model. Normaliziran načrt je robusten in odporen na podatkovne anomalije. Današji računalniki so zelo zmogljivi, zato je včasih 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. K2.3 – Preverimo relacije z vidika transakcij Podobno kot konceptualni model preverimo tudi logični model z vidika podpore transakcij, ki jih uporabnik specificira. Če vseh transakcij ni moč izvesti ročno, smo pri pretvorbi naredili napako, ki jo je potrebno odpraviti. K2.4 – Preverimo 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. K2.5 – Preverimo model z uporabnikom Namen tega koraka je preveriti model z uporabnikom ter ugotoviti, če ustreza vsem uporabniškim zahtevam. Sam model lahko zajema več uporabniških pogledov. Pri pregledu lahko nastopa več uporabnikov, zato je za pregled celovitosti podatkovnega modela zelo dober način uporaba specifikacije podatkovnih tokov s pomočjo diagrama podatkovnih tokov. K2.6 – Združimo lokalne modele Namen tega koraka je združiti vse lokalne modele v en globalni model, ki predstavlja vse uporabniške vidike podatkovne baze. Pri združevanju lahko pride do prekrivanja in neskladnosti. Ta korak lahko preskočimo, če nismo zajeli več uporabniških vidikov. V nasprotnem primeru uporabimo naslednje korake:

K2.6.1: Lokalne modele združimo v globalni model

K2.6.2: Preverimo globalni model

K2.6.3: Globalni model preverimo z uporabniki

Pri tem pa pazimo na sledeča pravila:

Preverimo imena in vsebino relacij ter njihove kandidate za ključ,

Preverimo imena in vsebino povezav in tujih ključev,

Združimo relacije z lokalnih podatkovnih modelov,

Brez združevanja vključimo relacije, ki so unikatne v posameznih podatkovnih modelih,

Združimo povezave in tuje ključe z lokalnih podatkovnih modelov,

Brez združevanja vključimo povezave in tuje ključe, ki so unikatni v posameznih podatkovnih modelih,

Preverimo, če morda manjkajo relacije, povezave in tuji ključi,

Preverimo tuje ključe,

Preverimo pravila za zagotavljanje celovitosti podatkov,

Narišemo globalni podatkovni model,

Ažuriramo dokumentacijo.

12/31

K2.7 – Preverimo 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, zato mora biti podatkovni model prilagodljiv. Popolnoma odprt sistem za rašziritve je težko doseči. Pravilo agilnega načrtovanja pravi: »Fool me once, shame on you, fool me twice, shame on me!«.

6. Fizično načrtovanje 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”.

Slika 4: Fizično načrtovanje

Fizično načrtovanje PB opredeljuje proces, s katerim izdelamo opis implementacije PB na sekundarnem pomnilnem mediju. Fizično načrtovanje opisuje :

osnovne relacije,

datotečno organizacijo,

indekse za dosego učinkovitega dostopa do podatkov,

povezane omejitve in

varnostne mehanizme.

7. Metode fizičnega načrtovanja Možni koraki načrtovanja fizične PB:

K3: Pretvorimo logični model v jezik za ciljni SUPB K3.1: Izdelamo načrt osnovnih relacij K3.2: Izdelamo načrt predstavitve izpeljanih atributov K3.3: Izdelamo načrt splošnih omejitev

K4: Izdelamo načrt datotečne organizacije ter indeksov K4.1: Analiziramo transakcije K4.2: Izberemo datotečno organizacijo K4.3: Določimo indekse K4.4: Ocenimo velikost podatkovne baze

K5: Izdelamo načrt uporabniških pogledov

K6: Izdelamo načrt varnostnih mehanizmov

K7: Preverimo smiselnost uvedbe nadzorovane redundance podatkov (denormalizacija) K3 – Pretvorba v jezik za SUPB Namen koraka je, da iz logičnega modela izdelamo podatkovno shemo za ciljni SUPB. Poznati moramo funkcionalnosti ciljnega SUPB (kako izdelati osnovne relacije, ali podpira obveznost podatkov, ali podpira domene, sprožilce,...). K3.1 – Izdelava osnovnih relacij Namen je 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 je smiselno tudi alternativne in tuje ključe,

Omejitve povezav.

13/31

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.

K3.2 – Predstavitev izpeljanih atributov Namen je določiti, kako bodo v SUPB predstavljeni izpeljani atributi. Za vsak izpeljani atribut velja, ali da:

je shranjen v podatkovni bazi, ali pa

se vsakokrat posebej izračuna in se ne hrani v podatkovni bazi.

Pri odločitvi, kako predstaviti izpeljane atribute, upoštevamo:

“strošek” shranjevanja in vzdrževanja skladnosti izpeljanih atributov z osnovnimi atributi, iz katerih je izpeljan,

“strošek” vsakokratnega izračunavanja izpeljanega atributa. Nato pa izberemo stroškovno ugodnejšo rešitev. K3.3 – Načrt splošnih omejitev Namen je izdelati načrt splošnih omejitev za ciljni SUPB. Med različnimi SUPB-ji obstajajo velike razlike kar se tiče podpore splošnih omejitev. K4 – Datotečna organizacija in indeksi Namen je izbrati optimalno datotečno organizacijo za shranjevanje osnovnih relacij ter potrebne indekse za doseganje ustrezne učinkovitosti. Ključnega pomena so uporabniške zahteve v zvezi z želeno/pričakovano učinkovitostjo transakcij. K4.1 – Analiza transakcij Namen je razumeti namen transakcij, ki bodo tekle na SUPB ter analizirati tiste, ki so najpomembnejše. Poskušamo 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).

Preverimo tudi:

Atribute, ki jih transakcije spreminjajo,

“Iskalne” pogoje v transakcijah...

Pogosto ne moremo pregledati vseh transakcij, zato pregledamo samo najpomembnejše. Pri tem si pomagamo z matriko transakcija/relacija, ki na pove katere relacije se v transakciji uporabljajo, ter diagram uporabe transakcij, ki nam pove katere transakcije se bodo najpogosteje izvajale. K4.2 – Izbira datotečne organizacije Namen je izbrati učinkovito datotečno organizacijo za vse osnovne relacije. Datotečne organizacije:

kopica,

hash,

metoda indeksiranega zaporednega dostopa (ISAM),

drevo B+-,

gruča.

Vsi SUPB-ji ne podpirajo vseh variant.

14/31

K4.3 – Izbira indeksov Namen je ugotoviti, ali lahko z dodatnimi indeksi povečamo učinkovitost sistema. Možen pristop:

Zapise pustimo neurejene ali

Izdelamo toliko sekundarnih indeksov (indeks po atributu, ki ni obenem tudi atribut, po katerem je urejena relacija), kolikor je potrebno.

Lahko pa pristopimo tudi na sledeč način:

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! Sekundarni indeksi so način, kako omogočiti učinkovito iskanje s pomočjo dodatnih ključev. Pri določanju sekundarnih indeksov upoštevamo sledeče:

Povečanje učinkovitosti (predvsem pri iskanju po PB),

Dodatno delo, ki ga mora sistem opravljati za vzdrževanje indeksov. Majhnih relacij ponavadi ne indeksiramo. Če datoteka ni urejena po primarnem ključu, potem kreiramo indeks na osnovi primarnega ključa. Izogibamo se indeksiranju atributov, ki se pogosto spreminjajo. K4.4 – Ocena velikosti podatkovne baze Namen je oceniti, koliko prostora v sekundarnem pomnilniku zahteva načrtovana podatkovna baza. Ocena je odvisna od:

velikosti in števila zapisov ter

ciljnega SUPB. K5 – Načrt uporabniških pogledov Namen je 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. K6 – Načrt varnostnih mehanizmov Namen je 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. K7 – Uvedba nadzorovane redundance Namen je 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. Pri tem pa se moramo zavedati, da je implementacija denormaliziranih relacij težja, hkrati pa velikokrat izgubimo na prilagodljivosti modela. Z denormalizacijo ponavadi pospešimo poizvedbe, vendar upočasnimo spreminjanje podatkov.

15/31

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) (npr. 4PNO 3NO). LookUp tabele so sestavljene 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 (v primeru, ko se do LookUp tabele pogosto dostopa, ko so uporabljene v kritičnih poizvedbah, ko je majhna verjetnost, da se bodo po vrednosti spreminjale). 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 povezavah 1:* 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.

K7.1 – Združevanje 1:1 povezav

Slika 5: Združevanje 1:1 povezav

K7.2 – Podvajanje neosnovnih atributov v povezavah 1:* za zmanjšanje potrebnih stikov

Slika 6: Podvajanje neosnovnih atributov

16/31

K7.3 – Podvajanje tujih ključev v 1:* povezavah za zmanjšanje potrebnih stikov

Slika 7: Podvajanje tujih ključev

K7.4 – Podvajanje atributov v povezavah *:* za zmanjšanje potrebnih stikov

Slika 8: Podvajanje atributov v povezavah *:*

K7.5 – Uvedba ponavljajočih skupin atributov

Slika 9: Uvedba ponavljajočih skupin

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č osnovnimi relacijami.

17/31

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.

Slika 10: Razbitje relacij

Uporaba particioniranja prinaša številne prednosti:

boljša porazdelitev vnosa,

večja učinkovitosti (manj podatkov za obdelavo, paralelnost izvajanja,...),

boljša razpoložljivost,

boljša obnovljivost,

več možnosti za zagotavljanje varnosti. 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).

18/31

Poglavje 2

Obvladovanje transakcij

1. Transakcije in njihove lastnosti 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. Transakcija se lahko zaključi na dva načina:

Uspešno ali

Neuspešno

Če se je končala uspešno, jo potrdimo (commit), sicer razveljavimo (abort). Ob neuspešnem zaključku moramo podatkovno bazo vrniti v skladno stanje pred začetkom transakcije. Ko enkrat transakcijo potrdimo, je ni mogoče več razveljaviti (če smo naredili napako s potrditvijo, moramo za povrnitev v prejšnje stanje izvesti novo transakcijo, ki pa bo imela obraten učinek od tiste prejšnje). Če je bila transakcija zavrnjena, se lahko morda drugič izvede uspešno (odvisno od razloga za neuspešnost). 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. Lastnosti transakcij Vsaka transakcija naj bi zadoščala štirim lastnostim (ACID):

Atomarnost: transakcija predstavlja atomaren sklop operacij. Ali se izvede vse ali nič. To 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).

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.

Arhitektura SUPB SUPB ima sledeče komponente za obvladanje transakcij, nadzor sočasnosti ter obnovitev podatkov:

Slika 11: SUPB in vsebovane komponente

19/31

2. Nadzor sočasnosti Namen nadzora sočasnosti 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, je nadzor trivialen, v primeru, ko pa vsaj eden izmed uporabnikov piše, pa obstaja verjetnost konfliktov. V centraliziranem SUPB lahko zaradi sočasnosti dostopa pride do različnih problemov:

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

Če transakcije izvajamo zaporedno, se izognemo vsem problemom, vendar s tem izrazito znižamo učinkovitost. Serializacija urnika transakcij Pri nadzoru sočasnosti se pojavijo sledeče definicje:

Serializacija Je način, kako identificirati načine izvedbe transakcij, ki zagotovijo ohranitev skladnosti in celovitosti

podatkov

Urnik Je zaporedje operacij iz množice sočasnih transakcij, ki ohranja vrstni red operacij posameznih

transakcij

Zaporedni urnik Je urnik, v katerem so operacije posameznih transakcij izvedene zaporedoma, brez prepletanja z

operacijami iz drugih transakcij

Nezaporedni urnik Je urnik, v katerem se operacije ene transakcije prepletajo z operacijami iz drugih transakcij

Namen serializacije je, da najdemo nezaporedne urnike, ki omogočajo vzporedno izvajanje transakcij brez konfliktov. Dajo pa nam rezultat, kot če bi transakcije izvajali zaporedno. Vrstni red bralno/pisalnih operacij je pomemben.

Če dve transakciji bereta isti podatek, nista v konfliktu. Vrstni red ni pomemben.

Če dve transakciji bereta ali pišeta popolnoma ločene podatke, nista v konfliktu. Vrstni red ni pomemben.

Če neka transakcija podatek zapiše, druga pa ta isti podatek bere ali piše, je vrstni red pomemben.

Ali se da transakcije serializirati, preverimo s pomočjo usmerjenega grafa zaporedja G = (N, E); N-vozlišča, E-povezave Gradnja grafa:

Kreiramo vozlišče za vsako transakcijo

Kreiramo usmerjeno povezavo Ti Tj, če Tj bere vrednost, predhodno zapisano s Ti

Kreiramo usmerjeno povezavo Ti Tj, če Tj piše vrednost, ki je bila predhodno prebrana s Ti (tudi, če je vmes COMMIT)

Kreiramo 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! Poleg serializacije konfliktnih operacij, ki zagotavlja, da so konfliktne operacije izvedene tako, kot bi bile v zaporednem urniku, obstajajo še druge vrste serializacije kot naprimer serializacija vpogledov. Urnik je mogoče serializirati po vpogledih, če je ekvivalenten nekemu zaporednemu urniku. Vsak urnik, ki ga je mogoče serializirati po konfliktnih operacijah, je mogoče tudi serializirati po vpogledih. Obratno pa ne velja, namreč serializacija po konfliktnih operacijah je močnejša serializacija. Testiranje serializacije vpogledov je veliko težje od testiranja serializacije konfliktnih operacij (NP polni problem).

20/31

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. Urnik, ki omogoča obnovljivost, imenujemo obnovljiv urnik. Urnik je obnovljiv, če za vse transakcije, ki nastopajo v urniku, velja da če Tj bere neko podatkovno enoto, predhodno zapisano s Ti, potem mora biti Ti potrjena pred Tj (commit). Zaklepanje in časovno žigosanje 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

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 Zaklepanje in časovno žigosanje sta pesimistični metodi

Optimistične: izhajamo iz predpostavke, da je konfliktov malo, zato dovolimo vzporedno izvajanje, za konflikte pa preverimo na kocu izvedbe

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 pa je skupno, da mora transakcija preden podatek prebere, zahtevati deljeno zaklepanje (shared lock), pred pisanjem pa ekskluzivno zaklepanje (exclusive lock). Če ima transakcija deljeno zaklepanje, lahko podatek bere, ne more ga pa pisati. Če pa ima ekskluzivno pa lahko bere in piše. Deljeno zaklepanje ima lahko več transakcij hkrati, medtem ko ekskluzivno pa samo ena. 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: in je obstoječe zaklepanje deljeno, se odobri in 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).

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 je dvofazno zaklepanje (2PL – Two Phase Lock). Transakcija sledi 2PL protokolu, če se vsa zaklepanja v transakciji izvedejo pred prvim odklepanjem. 2PL protokol vsebuje:

fazo zasedanja: transakcija pridobiva 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 s 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 Če vse transakcije v urniku sledijo 2PL protokolu, je urnik možno serializirati. 2PL, ki onemogoča kaskadne preklice, zahteva, da se sprostitev preklicev izvede šele na koncu transakcije Poznamo dve vrsti 2PL:

Rigorozni 2PL: do konca transakcij zadržujemo vse sprostitve

Striktni 2PL: zadržujemo le ekskluzivna zaklepanja

21/31

Mrtve in žive zanke – detekcija in odprava Mrtva zanka (dead lock) je brezizhoden položaj, do katerega pride, ko dve ali več transakcij čakajo ena na drugo, da bodo sprostile zaklepanja. Da se mrtva zanka prekine, je možno le to, da eno transakcijo prekličemo. Sama mrtva zanka, oziroma njena detekcija mora biti za uporabnika nevidna, za to pa poskrbi SUPB. Pri obravnavi mrtvih zank imamo več različnih tehnik:

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 je 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

WFG je usmerjen graf G = (N,E); N-vozlišče, E-povezave. Postopek risanja WFG:

Kreiramo vozlišče za vsako transakcijo

Kreiramo direktno povezavo Ti Tj, če Ti čaka na zaklepanje podatkvne enote, ki je zaklenjena s strani Tj. Če se v grafu pojavi cikel, je prišlo do mrtve zanke. Ko je mrtva zanka zaznana, je potrebno eno ali več transakcij prekiniti. Pri tem upoštevamo sledeče:

Izbira transakcije za prekinitev: možni kriteriji so ‘starost’ transakcije, število sprememb, ki jih je transakcija naredila, število sprememb, ki jih transakcija še mora opraviti

Koliko transakcije preklicati: namesto preklica cele transakcije je včasih mrtvo zanko mogoče rešiti s preklicom le enega dela transakcije

Izogibanje stalno istim žrtvam: potrebno je preprečiti, da ni vedno izbrana ista transakcija - podobno živi zanki (live lock)

Časovno žigosanje je protokol nadzora sočasnosti, ki razvrsti transakcije tako, da so prve tiste, ki so starejše. Časovni žig je enolični identifikator, ki ga SUPB dodeli transakciji in pove relativni čas začetka transakcije. Časovni žig imajo tudi podatkovne enote in sicer Read_timestamp (časovni žig transakcije, ki je podatkovno polje nazadnje prebrala), ter Write_timestamp (časovni žig transakcije, ki je v podatkovno polje nazadnje pisala). Poznamo osnovno ureditev po časovnih žigih, ki zagotavlja serializacijo konfliktnih operacij, vendar ne zagotavlja obnovljivosti urnika. Poleg tega poznamo nadgradnjo tej ureditvi, z upoštevanjem Tomaževega pravila pisanja. To je dodatno pravilo, ki poveča stopnjo sočasnosti. Dodatno pravilo za pisanje je takšno, da pisanje zavrne, če se nanaša na neko zastarelo podatkovno enoto. 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. Poleg pesimističnih metod obstajajo tudi optimistične metode za nadzor sočasnosti, ki pa 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 obstaja, se transakcija razveljavi. Omogočajo večjo stopnjo sočasnosti (pri predpostavki, da je konfliktov malo!).

22/31

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 se za fazo branja. Preveri se, ali je mogoče 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 je slednja uspešna, se podatki zapišejo v podatkovno bazo. Porazdeljeni sistemi Lokalni SUPB-ji v porazdeljenih sistemih imajo enake komponente kot v centralnih izvedbah. Poleg tega pa imajo na vsakem vozlišču še dodatno globalno komponento za koordiniranje transakcij, ki koordinira izvajanje globalnih in lokalnih transakcij, ki so bile inicirane v vozlišču. Nadzor sočasnosti v porazdeljenih sistemih temelji na dveh osnovnih pristopih, ki pa sta enaka kot pri lokalnih (zaklepanje ter žigosanje). Centraliziran 2PL Vsi podatki o zaklepanju se vodijo na enem vozlišču. Za dodajanje in sproščanje zaklepanj obstaja centralni LM (Lock Manager). Postopek za transakcijo T pognano na vozlišču S1:

TC1 (Transaction Coordinator) razdeli transakcijo na dele upoštevajoč podatke v globalnem sistemskem katalogu. TC1 je 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.

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.

Prednosti:

Enostavna implementacija

Detekcija mrtvih zank enako kot na navadnem SUPB (z vsemi zaklepanji dela en sam LM)

Relativno nizki stroški komunikacije Slabosti:

Na poti do centralnega LM se lahko pojavi ozko grlo (vse zahteve gredo na centralni LM)

Nižja zanesljivost: odpoved centralnega mesta pomeni velik problem

23/31

2PL s primarno kopijo 2PL s primarno kopijo odpravlja slabosti centraliziranega 2PL. Ideja je, da obstaja več LM-jev, ki so porazdeljeni po več vozliščih. Vsak LM je zadolžen za 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. 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 je potrebno samo za primarno kopijo

Ostale kopije spremenimo kasneje (zaželjeno čim prej) 2PL s primarno kopijo je primeren, ko je replikacija selektivna, spremembe niso pogoste, ter kadar vozlišča ne potrebujejo vedno zadnje verzije podatkov. Prednost:

Stroški komunikacije nižji ter učinkovitost večja kot pri centraliziranemu 2PL (manj oddaljenega zaklepanja) Slabosti:

Težavno je 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

Porazdeljen 2PL Tudi porazdeljen 2PL poskuša odpraviti težave centraliziranega 2PL. Ideja je, da so LM porazdeljeni po vseh vozliščlih. Vsak LM je tudi ogovoren 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 so replicirani, se uporabi protokol kontrole replikacije imenovan ROWA (Read-One-Write-All). ROWA deluje tako, da se lahko katerakoli kopija neke podatkovne enote uporabi za branje, vendar morajo biti vse enote ekskluzivno zaklenjene, če eno spreminjamo. Prednost:

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) Večinsko zaklepanje Predstavlja razširitev porazdeljenega 2PL. Koncept je tak, da so LM razporejeni po vseh vozliščih. Vsak LM skrbi za lokalne podatke. Če transakcija želi brati ali pisati v 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. Poljubno število transakcij ima lahko istočasno deljeno zaklepanje nad večino podatkovnih enot, samo ena pa ekskluzivno zaklepanje. Prednost:

Odprava slabosti centraliziranega pristopa Slabosti:

Kompleksnost protokola

Kompleksnost identifikacije mrtvih zank

Stroški zaklepanja in odklepanja

Časovno žigosanje Cilj časovnega žigosanja je, da transakcije uredimo 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 je časovno žigosanje globalno in lokalno. Sistemska ura ali lokalni števec sta 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. 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.

24/31

Mrtve in žive zanke – detekcija in odprava v porazdeljenih sistemih V porazdeljenih sistemih je detekcija in odprava mrtvih zank kompleksnejša. Poenostavi se lahko tako, da se uporabi centralizirani LM. V SUPPB lokalni graf čakanja (WFG) ne zadošča – potrebno sestaviti tudi globalni WFG, ki predstavlja unijo lokalnih WFG. V porazdeljenih sistemih so v uporabi trije pristopi za detekcijo mrtvih zank:

Centralizirana detekcija Določeno je eno vozlišče, ki je odgovorno za detekcijo mrtvih zank (DDC – Dead Lock Coordinator) Naloga DDC-ja je:

Konstruirati globalni WFG Preverjati obstoj zank v globalnem WFG V primeru zank izbrati transakcije, ki se prekinejo (rollback) in ponovno poženejo.

Slabosti je nižja zanesljivost (če odpove vozlišče z DDC)

Hierarhična detekcija Vozlišča so urejena v hierarhijo Vsako vozlišče pošlje svoj WFG vozlišču, ki je nad njim v hierarhiji Prednost pred centraliziranim pristopom je manjša odvisnost od centralnega vozlišča. Slabost je kompleksnost implementacije

Porazdeljena detekcija Obstajajo številni algoritmi za porazdeljeno detekcijo mrtvih zank Če je na lokalnem WFG identificiran cikel, ki ne vključuje Text, potem je vozlišče in SUPPB v mrtvi zanki.

Mrtvo zanko odpravimo lokalno. Če je 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.

3. Obnova podatkov po nesrečah Obnova podatkov je proces vzpostavljanja podatkovne baze v zadnje veljavno stanje, ki je veljalo pred nastopom nesreče. Podatke lahko shranjujemo na štirih različnih medijiih:

glavni pomnilnik (neobstojni pomnilnik): podatki v njem ne preživijo sistemskih nesreč

magnetni disk (“online” obstojni pomnilnik): zanesljivejši in cenejši od glavnega pomnilnika, vendar tudi počasnejši

magnetni trak (“offline” obstojni pomnilnik): še zanesljivejši in cenejši od diska, vendar tudi počasnejši, omogoča samo zaporedni dostop

optični disk: najzanesljivejši od vseh, še cenejši in hitrejši od traku ter omogoča neposredni dostop do podatkov

Obstaja več vzrokov 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

Ne glede na vzrok, lahko izgubimo podatke ali v glavnem pomnilniku ali pa tudi v sekundarnem pomnilniku. Za obnovljivost podatkov skrbi upravljalec za obnovljivost (recovery manager), ki mora v primeru nesreče zagotavljati atomarnost in trajnost. Upravljalec obnovljivosti mora po nesreči zagotoviti ali da se vse spremembe, ki so bile izvedene v okviru transakcije uveljavijo v celoti, ali pa da se ne uveljavi nobena sprememba. Podatkovni vmesniki omogočajo branje/pisanje iz/v sekundarega pomnilnika, prenos vsebine teh podatkovnih vmesnikov se pa v sekundarni pomnilnik izvede le ob COMMIT-u oziroma avtomatično, ko postanejo podatkovni vmesniki polno zasedeni (to eksplicitno zapisovanje označimo kot prisilno zapisovanje-force-writting).

25/31

Če se nesreča pripeti med pisanjem ali med prenosom podatkov iz podatkovnih vmesnikov v sekundarni pomnilnik, mora upravljalec 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).

Če razveljavimo samo eno transakcijo, govorimo o parcialnem razveljavljanju (partial undo) – ta je prisoten tudi pri protokolu za nadzor sočasnosti, če je pa potrebno razveljaviti vse pa o globalnem razveljavljanju (global undo). Upravljalec z medpomnilnikom je zadolžen za upravljanje s podatkovnimi vmesniki. Ko se vmesniki zapolnijo, obstajajo različne strategije zamenjave podatkov (recimo FIFO, LRU,...). Upravljalec medpomnilnika ne sme prebrati strani iz diska, če se ta že nahaja v medpomnilniku. 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 je 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.

Z vidika implementacije je najpreprostejša uporaba no-steal in force. S tem ni potrebno razveljaviti ponesrečenih transakcij v PB, ker se spremembe še niso zapisale na disk (no-steal), ter ni potrebno ponoviti sprememb, ki so jih povzročile uveljavljene transakcije, ki so se ponesrečile po COMMIT, saj se spremembe zapišejo takoj po tem (force). Večina SUPB-jev pa implementira steal in no-force politiko. S tem se izogne potrebi po velikem medpomnilniku (steal) ter ni potrebno izvajati večkratnega zapisovanja strani na disk s strani več transakcij (no-force). 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, ki je komponenta SUPB, ki omogoča obnovo podatkovne baze v zadnje konsistentno stanje, ki je veljalo pred nastopom nesreče

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. Varnostna kopija je lahko popolna kopija PB ali pa inkrementalna kopija, ki vsebuje samo spremembe izvedene od zadnje popolne ali inkrementalne kopije PB. Dnevnik V dnevnik se zapisujejo vse spremembe, ki jih transakcije izvedejo v PB. Zaradi pomembne vloge dnevnika pri obnavljanju podatkov po nesrečah, je ta podvojen ali celo potrojen. 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 (včasih je bil hranjen na magnetnem traku, ki je zanesljivejši ter cenejši, ampak počasnejši). V dnevnike se lahko piše velika količina podatkov, zato morajo biti v dnevniku na razpolago samo podatki za hitro obnavljanje. Torej za uporabo pri manjših nesrečah (recimo razveljavitev transakcije pri preprečitvi mrtve zanke), oz. pri večjih nesrečah (recimo udarec glave diska na magnetno površino), kjer je čas obnove daljši.

26/31

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

... 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 procesiranja zaradi pregledovanja dnevniških vpisov lahko omejimo z uporabo kontrolnih točk. Kontrolna točka je 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. Če se transakcije izvajajo sočasno, je potrebno ponoviti vse transakcije, ki so izdale ukaz COMMIT po zadnji kontrolni točki in razveljaviti vse transakcije, ki so bile aktivne v času nastopa nesreče. Uporaba kontrolnih točk je relativno poceni operacija in se izvaja približno 3-4 krat na uro. V primeru nesreče, je tako potrebno obnoviti podatke samo iz zadnjih 15-20 minut. Tehnike obnovljivosti Uporaba posamezne procedure za obnavljanje podatkov v PB po nesreči je odvisna od obsega nastale škode. Lahko pride do obsežnih ali manjših poškodb PB. Poznamo sledeče 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 ažuriranje Podatki se 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. Če se transakcija prekine, v PB ni potrebno razveljaviti nobene spremembe, ker se te nahajajo samo v dnevniku. Če so se transakcije uspešno zaključile pred nesrečo, jih je potrebno ponoviti (redo), saj se njihova ažuriranja še niso dejansko zapisala v PB. Uporaba dnevnika za obnavljanje podatkov v primeru odloženega ažuriranja:

Ob začetku transakcije se vpiše v dnevnik “transaction start”.

Ob vsaki operaciji zapisovanja se v dnevnik vnese zapis, razen podatek o stari vrednosti 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, nato 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 Vsako transakcijo, za katero v dnevniku obstajata zapisa “transaction start” in “transaction commit”, je potrebno ponoviti. 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. Odloženo ažuriranje je učinkovitejše, če se v povprečju izvede več neuspešnih transakcij (ni potrebno spreminjati PB).

27/31

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. 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

POMEMBNO: Pri ažuriranju se morajo zapisi najprej vnesti v dnevnik, šele nato v PB “write-ahead log protocol”. Če v dnevniku ni zapisa “transaction commit”, pomeni da je bila transakcija v času nesreče aktivna in jo je pri obnavljanju potrebno razveljaviti (undo). 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 morda niso izvedla). Vsako transakcijo, za katero v dnevniku obstaja le zapis “transaction start” (brez “commit”), je potrebno razveljaviti (undo). Sprotno ažuriranje je učinkovitejše, če se v povprečju izvede več uspešnih transakcij (ni potrebno veliko popravljati podatkov v PB). 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. 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

Prednosti uporabe senčnih 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:

fragmentacija (razdrobljenost) podatkov na disku,

potreba po periodičnem “čiščenju” neuporabljenih strani na disku (z namenom obnavljanja prostega prostora na disku).

28/31

4. 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. Atomarnost porazdeljene transakcije je zagotovljena tako da:

se vse pod-transakcije uspešno izvedejo (vse izvedejo COMMIT) ali

pa se vse prekinejo (ROLLBACK). SUPPB je močno odvisen od sposobnosti komunikacije med vsemi vozlišči (če pride do okvare, se lahko omrežje razdeli na dve ali več particij). V porazdeljenih sistemih je težko najti izvor napake (ne vemo ali je težava v povezavi ali vozlišču,...) 2PC protokol 2 Phase Commit protokol je sestavljen iz dveh faz in sicer iz volilne in odločitvene faze. Deluje po sledečem principu:

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 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 Protokol zaključevanja se prične, če koordinator ali sodelujoče mesto ne dobi predvidenega sporočila v določenem času. Koordinator je v času čakanja lahko v enem izmed štirih stanj: Initial, Waiting, Decided ali Completed. Protokol zaključevanja se pri koordinatorju lahko prične, če pride do zakasnitve 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.

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.

Slika 12: Stanja čakanja

29/31

Najenostavnejši protokol zaključevanja je, da mesto pustimo blokirano, dokler komunikacija s koordinatorjem ni ponovno vzpostavljena. V nasprotnem primeru lahko uporabimo sledeče:

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 je mesto

blokirano. Lahko se posvetuje z drugimi mesti, ki morda že vedo, kakšna je globalna odločitev kooperativni

protokol zaključevanja.

Slika 13: Stanja mesta

Akcije obnovitve podatkov odvisne od stanja, v katerem se mesta oziroma koordinator nahajajo. Pri koordinatorju lahko pride do napak v stanju INITIAL, WAITING, ter DECIDED. V mestu pa pri INITIAL, PREPARED ter ABORTED/COMMITED. Če sodelujoča mesta detektirajo napako koordinatorja (timeout), lahko izvolijo novega koordinatorja. 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 je v praksi majhno, zato večina sistemov uporablja 2PC. Alternativa pa je uporaba protokola 3PC, ki preprečuje blokiranje. 3PC protokol preprečuje blokiranje v primeru odpovedi mest, razen, če odpovedo vsa mesta. 3PC zmanjša obdobje negotovosti za mesta, ki so glasovala za potrditev in čakajo na globalno odločitev! 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, zato ve, da je potrditev možna.

Slika 14: Stanja 3PC

30/31

Pri koordinatorju lahko pride do:

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.

Pri sodelujočem mestu lahko pride do:

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.

Pri koordinatorju lahko pride do napak pri INITIAL, WAITING, PRE-COMMITTED, DECIDED. Pri mestu pa lahko pride do napak pri INITIAL, PREPARED, PRE-COMMITTED ter ABORTED/COMMITTED. Novo izvoljeni koordinator pošlje sporočilo STATE-REQ vsem sodelujočim mestom, da ugotovi, kako naprej. Pravila:

Če je neko mesto prekinilo transakcijo, potem je globalna odločitev prekinitev

Če je 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, se pošlje PRE-COMMIT in po potrditvah še GLOBAL-COMMIT

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 so:

upravljalec obnovljivosti (Recovery Manager) 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 inkrementalnih ali popolnih varnostnih kopij

obnavljanje instance PB (Instance Recovery) 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).

obnavljanje v določeno časovno točko (Point-in-time recovery) obnavlja 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 (Standby database) 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

(kopija je skoraj popolnoma sinhronizirana s primarno PB) PB v pripravljenosti je možno uporabljati za branje (razbremenitev primarne PB)

31/31

Napredni transakcijski modeli V zadnjem desetletju se pojavljajo naprednejše aplikacije, ki temeljijo na uporabi podatkovnih baz (npr.: aplikacije za podporo načrtovanja: CAD, CAM, CASE). Te aplikacije izdelujejo načrte, ki vsebujejo več miljonov sestavnih delov, ki so medsebojno povezani. Načrt je dinamičen (se spreminja skozi čas), te spremembe pa se morajo videti v vseh predstavitvah načrta. Načrtovanje izdelka lahko izvaja več sto ljudi, ki morajo sodelovati in biti ustrezno koordinirani. Vse te naštete lastnosti zahtevajo transakcije, ki so kompleksne, dostopajo do velike količine podatkov, ter so dolgotrajne (izvajajo se več ur, dni ali celo mesecev). Ugotoviti je potrebno, ali so obstoječi protokoli sploh še ustrezni za tako obvladovanje transakcij. Ti novi protokoli morajo biti kos sledečim 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 transakcijski protokoli so neprimerni, saj zahtevajo izolacijo nedokončanih transakcij

Poznamo več naprednih transakcijskih modelov:

Vgnezdeni transakcijski model N.A.

Sage N.A.

Večnivojski transakcijski model N.A.

Dinamično prestrukturiranje N.A.

Modeli delovnih tokov N.A.

Opomba: Protokola 2PC in 3PC nista preveč v podrobnosti razložena. Pri ostalih stvareh so pa tudi kakšne podrobnosti lahko izpuščene.

Poglavje 3

Optimizacija poizvedb

1. O optimizaciji poizvedb N.A.

2. Hevristična optimizacija poizvedb N.A.

3. Stroškovna opredelitev operacij relacijske algebre N.A.

4. Strategije izvedbe poizvedb N.A.