Programiranje baza podataka

Programiranje baza podataka Nikola Ajzenhamer 14. juli 2016. 1

Sadržaj 1 Reprezentacija podataka. Indeksi 3 1.1 Reprezentacija podataka............................... 3 1.1.1 Polja...................................... 3 1.1.2 Slogovi..................................... 4 1.1.3 Blokovi..................................... 9 1.2 Indeksi......................................... 10 1.2.1 Vrste indeksa.................................. 11 1.2.2 Duplikati ključeva............................... 13 1.2.3 Operacije ažuriranja indeksa........................ 14 1.2.4 Sekundarni indeksi.............................. 18 1.2.5 Indeksi u DB2................................. 19 2 B+ drveta 21 2.1 Uvod.......................................... 21 2.2 Unošenje........................................ 22 2.3 Brisanje......................................... 24 2.4 Performanse...................................... 25 3 Optimizacija 26 3.1 Uvod.......................................... 26 3.2 Faze obrade upita................................... 27 3.3 Transformacija izraza................................. 29 3.4 Saveti za pisanje optimizovanijih SQL upita.................... 31 3.5 Graf pristupnog puta. Procedure niskog nivoa................... 40 4 Oporavak baze podataka 42 4.1 Uvod.......................................... 42 4.2 Greške sistema i oporavak.............................. 43 4.3 Algoritmi oporavka baze podataka......................... 44 4.3.1 Postupak kod starijih realizacija RSUBP-a................. 44 4.3.2 Algoritam ARIES................................ 45 4.4 Greške medijuma i oporavak............................. 45 4.5 Dvofazni COMMIT.................................... 45 Literatura 47 2

1 Reprezentacija podataka. Indeksi 1.1 Reprezentacija podataka Atributi su reprezentovani poljima (fields). Polja su sekvence bajtova fiksne ili promenljive dužine. Polja se smeštaju u kolekcije fiksne ili promenljive dužine koje se nazivaju slogovi (records). Slogovi se skladište u fizičke blokove čiji dizajn zavisi od pristupnog puta, politike menjanja, mogućnosti sortiranje sloga, itd. Slogovi koji su pripadajući jedni drugima (bilo na osnovu neke veze (relation) ili opsega (extent)) skladište se zajedno i formiraju datoteku (file). Želimo da skladištimo imena, adrese, plate, datume, vremena, slike, zvukove, video zapise, itd. Dostupni nam su bitovi i bajtovi. Moramo da definišemo sekvencu bitova u okviru bajta (ili neprekidne kolekcije bajtova) koja ima određeno značenje. Naposletku, svi podaci su reprezentovani sekvencom bajtova (operacije na pojedinačnim bitovima su skuplje, čine skladištenje komplikovanijim, itd.). Element podataka može biti fiksne ili promenljive dužine. Pretpostavimo da je reč o fiksnim dužinama. 1.1.1 Polja Reprezentacija brojeva je jednostavna. Koristimo binarnu reprezentaciju koja omogućuje da hardver mašine može da izvrši aritmetičke operacije. Predstavljanje celih brojeva (integers) može biti: short: 2 bajta, long: 4 bajta, označeni (signed): prvi bit govori da li je broj pozitivan ili negativan, neoznačeni (unsigned): svi bitovi se koriste za označavanje pozitivnog broja. Kad su brojevi u pokretnom zarezu (reals) u pitanju, koristi se n bajtova za mantisu, i m za eksponent. Za reprezentaciju karaktera (char), razne kodne šeme su predlagane, a najpopularnija je ASCII. Postoje i nizovi karaktera fiksne dužine, tzv. niske (char(n)). Niske su nizovi karaktera, gde je svaki karakter kodiran prema kodnoj šemi. Niske koriste karaktere za dopunu (padding characters, označeni simbolom ) da ispune sva polja ukoliko je niska kraće dužine od n. Na primer, ako deklarišemo: CHAR(5) x; x = "cat"; onda će prva tri karaktera biti popunjena odgovarajućim karakterima, a preostala 2 će biti popunjena karakterima za dopunu: c a t 3

Postoje i niske promenljive dužine (varchar(n)). To su zapravo niske fiksne dužine, ali vrednost teksta ima veličinu koja može da varira. Razlikujemo dve vrste ovakvih niski: niske određene dužinom i vrednošću (n + x bajtova): 3 c a t Prvih x bajtova označava dužinu vrednosti teksta. NULL-terminirajuće niske (n + 1 bajt) c a t NULL Prvi bajtovi se koriste za vrednost teksta, a niska je završena NULL karakterom. Datum može biti predstavljen celim brojem brojem dana od 1. januara 1900, ili pomoću 8 karaktera, u formatu YYYYMMDD. Vreme može biti predstavljeno celim brojem brojem sekundi od ponoći, ili pomoću 6 karaktera, u formatu HHMMSS. Logičke vrednosti (boolean) TRUE i FALSE se predstavljaju svim jedinicama, odnosno nulama, redom u bajtu. Nabrojivi tipovi nam nude mogućnost formiranja konačnog skupa validnih vrednosti. Na primer, enum {Mon, Tue,..., Sun} days; može biti reprezentovano brojevima 1, 2,..., 7. Za neke tipove podataka je moguće uzimati manje od jednog bajta za reprezentovanje vrednosti, na primer, sve logičke vrednosti mogu stati u jedan bit, ili dani u 3 bita. Ipak, ovo je veoma često nepogodno zbog kompleksnih operacija koji su podložni greškama, te stoga treba voditi računa. Nekada se ovo radi kada je skladišni prostor mali. 1.1.2 Slogovi Slogovi su kolekcije srodnih vrednosti polja grupisana zajedno (tipične vrednosti su torke ili objekti). Na primer, slog Employee može imati polja name, gender, department, itd. Tip sloga se sastoji od imena i tipova polja. Na primer, name char(10), gender character, department char(3),... Slogovi mogu biti: 4

fiksnog ili promenljivog formata, i fiksne ili promenljive dužine. Pri fiksnom formatu i fiksnoj dužini sloga, najjednostavniji pristup je skladištenje svakog polja (u njegovoj definisanoj dužini) sekvencijalno. Na primer, gde je: (1) (2) (3) { }} { { }} { H A L V O R S E N M I F I (1) polje name char(10), (2) polje gender char, i (3) polje department char(3). Sheme sloga (record schema) sadrže tipove sloga i pomeraj (offset) svakog polja u okviru sloga. Sistem baze podataka održava informacije o shemama što se u suštini javlja, na primer, u CREATE TABLE za vezu atributa i njihovih tipova (shema sloga), redosleda atributa (polja), ograničenja poput ključeva i sl. Smeha se konsultuje kada se pristupa polju. Poravnanje podataka može biti četvorobajtno ili osmobajtno. Neke mašine zahtevaju (ili su efikasnije) ukoliko polja počinju na memorijskoj adresi koja je cetvorobajtno ili osmobajtno poravnana. Podaci mogu biti: skladišteni prema shemama sloga i poravnati kada se kopiraju u glavnu memoriju, ili skladišteni u poravnatoj formi, odnosno, svako polje se nalazi na adresi koja predstavlja umnožak broja za poravnanje, pa se zato mogu kopirati blok po blok u memoriju. Drugo rešenje je obično poželjnije, tj. veličine svih polja su zaokružena na sledeći umnožak broja za poravnanje. Neka u prethodnom primeru želimo da poravnamo podatke koristeći četvorobajtno poravnanje. Tada umesto (1) (2) (3) { }} { { }} { H A L V O R S E N M I F I 5

dobijamo (1) (2) (3) { }} { { }} { H A L V O R S E N M I F I Za slogove koji nisu polja obično postoje neke informacije, kao što su: sheme sloga, dužina sloga, vremenske oznake (timestamps), itd. Ove informacije se skladište u zaglavlju sloga (record header) koji zahteva dodatne bajtove za ove informacije. Neke od ovih informacija su jednake za sve slogove istog tipa, te stoga čuvaju samo pokazivač. Ipak, iako neke informacije mogu biti jednake za svaki slog (i izvodljive iz shema), ipak mogu biti čuvane u zaglavlju. Jedan od razloga je smanjivanje pristupa na sporijim memorijama. U slučaju prethodnog primera, imamo (p) (v) (1) (2) (3) { }} { { }} { { }} { { }} { H A L V O R S E N M I F I } {{ } zaglavlje sloga gde je: (p) pokazivač na sheme, i (v) vremenske oznake. Napomenimo da ukoliko želimo da imamo x-bajtno poravnanje, svako polje u zaglavlju sloga takođe mora biti na adresi umnoška od x. Razmotrimo sada slogove fiksne dužine i polja promenljive dužine. Ova kombinacija je pogodna za podatke (skladištene u polju) gde je veličina promenljiva. Na primer, tekstualne niske poput imena, adrese, itd. Grafički prikaz razlike između fiksne i promenljive deklaracije imena dat je sledećom slikom: H A L V O R S E N M I L L E R G A R C I A - M O L I N A S T E V E N S H A L V O R S E N M I L L E R G A R C I A - M O L I N A S T E V E N S Takođe, veliki podaci poput slika, zvučnog i video zapisa, i dr. su sigurno promenljive veličine jer, na primer, video zapis zavisi od dužine snimka, formata u kojem se enkodira, brzine 6

smenjivanja slika (frame rate), dubine boje, rezolucije i sl. Ukoliko je prosek veličine podataka manji, javlja se velika neiskorišćenost prostora kada se napravi veliko polje i fiksira se veličina tako da može da prihvati najveći element. Ako je jedno ili više polja u rekordu promenljive veličine, zaglavlje sloga mora sadržati dovoljno informacija tako da može da pronađe bilo koje polje. Počevši od početka, neophodno je dodati veličinu sloga u zaglavlje sloga, staviti sva polja fiksne veličine prvo, a zatim dodati pokazivače (pomeraje u odnosu na prvi bajt) ka poljima promenljive veličine u zaglavlju sloga. Na primeru sloga Employee koji sadrži polja name, gender, i department, imamo sledeće: ostale veličina pokazivač informacije sloga na name { }} { { }} { { }} { gender department name Slogovi mogu da sadrže promenljiv broj polja F. Na primer, kod reprezentovanja jedan-kaviše odnosa među objektima (na primer, skup dece), gde bismo u relacionom modelu imali povezani odnos. Drugi primer je kolekcijski tip kao tip atributa (na primer, skup brojeva telefona). Jedno od rešenja predlaže grupisanje svih pojava F-a i njihovo tretiranje kao polje promenljive dužine. Pri tome, dodajemo pokazivač ka prvom elementu (o f f set ). Ako je svako polje F dužine L bajtova, elementu i pristupamo izrazom of f set + ((i 1) L). Poslednji element se pronalazi tako što se poredi sa of f set -om narednog polja ili dužinom sloga. Neka u prethodnom primeru sa slogom Employee imamo dodatno polje projects: ostale veličina name* project* inf. sloga { }} {{ }} {{ }} {{ }} { gender department name pokazivači ka project-ima Drugo rešenje predlaže čuvanje particije sloga fiksne veličine iza zaglavlja i čuvanje particije sloga promenljive dužine na odvojenom bloku. Za svako polje promenljive dužine, u zaglavlju sloga čuva se pokazivač ka početku polja i dodatno polje koje može biti brojač vrednosti, ukupna dužina, ili adresa završetka. U skladu sa time, prethodni primer izgleda: 7

ostale veličina veličina broj name* project* inf. sloga name polja project* { }} {{ }} {{ }} {{ }} {{ }} {{ }} { x y gender department pokazivači ka project-ima dodatni prostor name Što se tiče prvog rešenja (slog promenljive dužine), prednost je ta da ima manje pristupa bloku (potencijalno ulazno-izlazne operacije sa diskom) koje ispituju sva polja. Nedostatak je da nasumičan pristup slogu zahteva čitanje svih zaglavlja. Takođe, premeštanje slogova je značajno komplikovanije. Sa druge strane se nalazi drugo rešenje koje za prednost ima olakšanu pretragu slogova. Naime, i-tom slogu se pristupa izrazom (i 1) RS, pri čemu je RS veličina sloga (record size). Takođe, pomeranje slogova je lakše. Međutim, da bismo pristupili celom slogu, moramo da pristupamo nekoliko blokova. Kompromis koji se nalaže jeste postojanje slogova fiksne dužine koji sadrže prvo nekoliko polja koja se ponavljaju, a zatim pokazivač ka prostoru gde se dodatna pojavljivanja mogu pronaći, kao i broj takvih (dodatnih) pojavljivanja. Naravno, slogovi ne moraju nužno biti nepromenljivog formata, tj. polja i njihov redosled može varirati tokom vremena izvršavanja. Slog u okviru sebe sadrži format (kažemo da se samo-opisuje) koristeći tagove: ime, tip, dužina (ova tri čine tzv. ulogu polja (role of field)), i vrednost. Slogovi promenljivog formata su korisni u informaciono-integrisanim aplikacijama, na primer, korišćenje XML i polustruktuiranih modela podataka, kao što su skladišta podataka (warehousing) i posredništvo (mediation), tj. korišćenje virtualnog skladišta podataka. Još jedna primena jeste kod slogova sa fleksibilnim shemama, na primer, kada atributi mogu da ne uzimaju nijednu vrednost (odnosno, dozvoljavanje NULL vrednosti). Primer koji ovo ilustruje jeste slog author sa tagovanim poljima: (1) (2) (3) (4) (5) (6) (7) (8) N S 6 Ullman T S 35 Database Systems: The Complete Book gde je: (1) kod za ime (name), (2) kod za tip niske (string), (3) dužina, 8

(4) vrednost, (5) kod za naslov knjige (title), (6) kod za tip niske, (7) dužina, i (8) vrednost. 1.1.3 Blokovi Slogovi koji predstavljaju torke relacije ili objekata opsega klase se čuvaju na disku u okviru bloka: zaglavlje bloka slog 1 slog 2... slog n Zaglavlje bloka je opciono i može da sadrži: identifikator bloka, adresar sa pomerajima (offsets) za svaki slog, vremenske oznake za vreme modifikacije i pristupnog vremena, informacije o relaciji kojoj torka pripada (ili, relacijama kojima pripada), veze ka ostalim blokovima, itd. Organizovanje datoteke može biti: neprekidnom alokacijom, povezanom alokacijom, klasterima, i indeksno. Naravno, postoje i različite kombinacije navedenih shema. Kod neprekidne alokacije, datoteka se čuva u neprekidnom bloku na disku (segmentu). Čitanje cele datoteke je jednostavno, ali ažuriranje datoteke je teško. U povezanoj alokaciji, svaki blok sadrži pokazivač ka narednom bloku. Na ovaj način je lako proširiti datoteku, ali je čitanje celog fajla ili nasumičnog bloka sporo. Klasteri predstavljaju kombinaciju prethodna dva metoda. Naime, unapred se zauzme segment (primarni deo), ali se navede da ga je moguće proširiti dodatnim segmentom (sekundarni deo) na koji će primarni deo pokazivati. Ovakvih, povezanih blokova može biti i više. Indeksna alokacija podrazumeva postojanje indeksnih blokova koji pokazuju na stvarne blokove datoteke. Postoje neka podešavanja prilikom čuvanja slogova u blokove. To su: razdvajanje slogova u okviru bloka, prošireni ili neprošireni prostor, klasterovanje (pomešani tipovi slogova), sekvenciranje, zaobilasci (indirection), i dr. Kod slogova fiksirane dužine nema potrebe za razdvajanjem slogova. Postoji specijalni marker koji služi za razdvajanje. U svakom zaglavlju sloga, kao i u zaglavlju bloka na disku treba 9

da se nađe dužina sloga (ili pomeraji). Neprošireni slogovi moraju da se nalaze u okviru jednog bloka na disku. Na primer, ukoliko imamo osam slogova (ne moraju da budu nužno iste širine, ali pretpostavimo da u ovom slučaju jesu), a u jednom bloku mogu da stanu najviše tri cela sloga, onda se može javiti situacija: slog 1 slog 2 slog 3 sl og 4 slog 5 slog 6 slog 7 s log 8... prekid prekid Međutim, na mestima označenim oznakom prekid", nije bilo dovoljno mesta u bloku za ceo slog, pa se zato ceo slog pomera u naredni blok: slog 1 slog 2 slog 3 slog 4 slog 5 slog 6... Prednosti ovog pristupa su jednostavno pronalaženje sloga i činjenica da je potrebno pristupiti samo jednom bloku da bismo pronašli slog. Međutim, jasno je da se javlja problem fragmentacije (problem neiskorišćenog prostora) u bloku, kao i to da je potrebno pristupiti mnoštvu blokova kako bismo dobili veći broj slogova. Prošireni slogovi mogu se proširiti (deliti) na dva ili više bloka. Osobina proširenosti" je obavezna ukoliko je veličina sloga veća od veličine bloka. Kod proširenih slogova, situacija sa prekidima je validna, s tim da je na mestima prekida neophodno voditi računa o dodatnim informacijama. Naime, prilikom deljenja sloga i skladištenja na dva bloka, u prvom bloku neophodno je čuvati indikator da je u pitanju particionisani slog i pokazivač na ostatak sloga. Takođe, u drugom bloku neophodno je čuvanje indikatora da je u pitanju nastavak sloga (a ne da je novi slog), kao i pokazivač na blok iza". Ovim je rešen problem fragmentacije čime se štedi na ukupnom broju blokova i na ukupnom broju pristupa disku prilikom dohvatanja većeg broja slogova. Ipak, za dohvatanje jednog sloga moguće je da treba pristupiti većem broju blokova. Takođe, zaglavlja slogova postaju kompleksnija jer je neophodno čuvati dodatne informacije o particionisanim poljima, broju particija, pokazivačima ka drugim particijama i sl. 1.2 Indeksi Indeks je struktura podataka koja nam pomaže da efikasno lociramo podatak na disku koristeći vrednost koja se naziva ključ: vrednost? slog vrednost 10

Indeksi takođe olakšavaju potpunu pretragu (full scan) relacije (ili opseg objekta klase) ukoliko slogovi nisu skladišteni u fizički neprekidnim blokovima. Indeksi (kao strukture podataka) su sekvencijalnog tipa, što pre svega znači da je pretraživanje u njima (na osnovu ključeva) sekvencijalno: K1 K2 K3 K4 K3... K1... K4... K2... sekvencijalna datoteka datoteka sa podacima Sekvencijalna datoteka je značajno manje veličine od datoteke sa podacima, te stoga može da stane u memoriju radi bržeg pretraživanja. U obe datoteke, ključevi su uređani na osnovu neke relacije od najmanjeg do najvećeg. 1.2.1 Vrste indeksa Postoje dve vrste indeksa: 1. gusti indeksi (dense index), i 2. retki indeksi (sparse index). Korišćenjem gustih indeksa svaki slog u datoteci sa podacima ima svoj odgovarajući slog u sekvencijalnoj datoteci (pretpostavimo da postoje tačno 2 sloga po bloku u datoteci sa podacima): gusti indeksi 20 30 40 50 60 70 datoteka sa podacima 30... 40... 50... 60... 80 11

Pomoću gustih indeksa možemo lakše da vidimo da li neki slog postoji (na primer, pošto indeks 75 na prethodnoj slici ne postoji u sekvencijalnoj datoteci, to znači da ne postoji ni u datoteci sa podacima). Ipak, gusti indeksi imaju veliki trošak održavanja. Sa druge strane, retki indeksi pokazuju na početak bloka, a ne na svaki slog pojedinačno: retki indeksi 30 50 70 datoteka sa podacima 30... 40... 50... 60... Kod retkih indeksa trošak održavanja je manji. Takođe, postoji rastavljanje na više nivoa koji ubrzavaju pretragu. Manji broj indeksa troši manje memorije. Međutim, ne možemo samo pretragom kroz sekvencijalnu datoteku utvrditi da li neki podatak postoji, već moramo i da prođemo kroz (barem jedan) blok. Demonstrirajmo rastavljanje na više nivoa na sledećem primeru: retki indeksi na dva nivoa datoteka sa podacima 90 170 250 30 50 70 30... 40... 50... 60... 70... 80... 12

U narednom delu ćemo se pozabaviti sledećim temama: duplikati ključ eva, brisanje i unošenje, i sekundarni indeksi. 1.2.2 Duplikati ključeva U nekim bazama podataka postoje uslovi za slogove koji imaju identične ključeve kao neki drugi slogovi. Kod gustih indeksa, implementacija može biti takva da se za svaki slog čuva poseban indeks. Druga implementacija bi bila da se za svaki različit ključ čuva tačno jedan indeks koji pokazuje na prvi slog koji ima taj ključ. prva implementacija druga implementacija 20 30 20 20 30 30... 30... Kod retkih indeksa može doći do problema. Jedna implementacija podrazumeva da svaki novi indeks pokazuje na početak narednog bloka. Pri tome, takvi indeksi za vrednost ključa imaju vrednost ključa prvog sloga u bloku. Problem koji se ovde javlja jeste pretraga slogova sa ključevima čiji indeks poǩazuje na naredni blok, iako se oni nalaze u prethodnom bloku (na narednoj slici, to su ključevi 20 i 30). Druga implementacija predlaže da vrednost svakog indeksa bude prvi novi ključ u bloku. Pitanje koje se ovde postavlja jeste da li treba preskočiti blokove koji sadrže slogove sa ključevima koje smo već indeksirali, ili ne (na narednoj slici, pitanje je da li treba da postoji poslednji indeks sa ključem 30). 13

prva implementacija druga implementacija 20 20 30 30 30 30... 30... 30... 30... 30... 30... 1.2.3 Operacije ažuriranja indeksa U narednom delu biće prikazane operacije ažuriranja nad retkim indeksima i gustim indeksima. Posmatrajmo primer na narednoj slici: retki indeksi 30 50 70 datoteka sa podacima 30... 40... 50... 60... Neka je operacija brisanje sloga sa ključem 40. Prvo treba ukloniti slog u datoteci sa podacima. S obzirom da ne postoji indeks sa ključem 40, operacija je završena. 14

Neka je sada potrebno obrisati slog sa ključem 30. U ovom slučaju, prvo treba obrisati slog u datoteci sa podacima, zatim pomeriti" slog sa ključem 40 na mesto obrisanog sloga, i konačno, promeniti indeks sa ključem 30 na indeks sa ključem 40. brisanje sloga 40 brisanje sloga 30 30 40 50 70 30... 50 70 40... 50... 50... 60... 60... Neka je sada potrebno obrisati oba sloga sa ključevima 30 i 40. Nakon njihovog uklanjanja iz datoteke sa podacima, briše se i indeks sa ključem 30 (pošto je ceo blok obrisan). Na njegovo mesto dolazi indeks sa ključem 50, a na mesto indeksa sa ključem 50 dolazi indeks sa ključem 70. Poslednji indeks se briše i odgovarajući pokazivači se ažuriraju. brisanje slogova 30 i 40 50 70 50... 60... Posmatrajmo sada primer sa gustim indeksima: gusti indeksi 20 30 40 datoteka sa podacima 30... 40... 15

Brisanje sloga 30 se vrši tako što se prvo obriše slog u datoteci sa podacima, pa se na njegovo mesto smešta slog sa ključem 40. Nakon toga, briše se indeks sa ključem 30, na njegovo mesto dolazi indeks sa ključem 40, a prethodni indeks sa ključem 40 se briše. 20 40 40... Prikažimo operaciju unosa u slučaju retkih indeksa. Neka imamo situaciju kao na narednoj slici: retki indeksi 30 40 60 datoteka sa podacima 30...... 40... 50... Ukoliko treba uneti slog sa ključem 34, operacija unosa se svodi na upisivanje sloga u slobodan prostor u datoteci. 30 40 60 30... 34... 40... 50... 16

Neka treba uneti slog sa ključem 15. Ovde je situacija nešto složenija. Prvo treba uneti slog 15 na mesto sloga 20. Zatim treba pomeriti slogove 20 i 30 za jedno mesto niže" u datoteci sa podacima. Na kraju, treba izmeniti indeks sa ključem 30 na ključ 20. Ovo je slučaj kada je reorganizacija datoteka i indeksa momentalna. Postoji i sledeća varijacija: prvo treba uneti novi blok i povezati ga sa ostatkom blokova, a zatim ažurirati indekse. retki indeksi 20 40 60 datoteka sa podacima 15... 30... 40... 50... Na kraju, prikažimo unos sloga sa ključem 25. U ovom slučaju dolazi do preplavljivanja blokova (block overflow). Naime, treba dodati novi blok koji će za prvi slog imati slog koji treba uneti (napomenimo da će se reorganizacija vršiti kasnije). Sada se novi blok povezuje sa prethodnim, što je prikazano na narednoj slici: retki indeksi 30 40 60 datoteka sa podacima 30...... 25...... 40... 50... 17

Unošenje novih slogova u slučaju gustih indeksa je slično, ali često može biti skuplje. Na narednoj slici je prikazan unos sloga sa ključem 15. Primetimo da se novi blokovi prave u obe datoteke. pre unosa posle unosa 20 15 15... 30 30... 20 30 30... 1.2.4 Sekundarni indeksi Slogovi sa sekundarnim ključevima ne moraju biti uređeni u datoteci sa podacima (najčešće i nisu). Zbog ove činjenice, nad ovakvom datotekom nema smisla koristiti direktno (tj. na najnižem nivou) retke ključeve. Gusti indeksi se prirodno nameću jer svaki indeks će pokazivati na neki slog na disku. Ipak, pošto su gusti indeksi sortirani, možemo koristiti retke indekse na višim nivoima kojima se obezbeđuje brzo pronalaženje slogova. retki indeksi na višem nivou 50 90... gusti indeksi na najnižem nivou 20 30 40 50 60 70... datoteka sa podacima 30... 50... 70... 80... 40... 100... 90... Postoji i kombinacija duplikata ključeva i sekundarnih indeksa. 18

Jedno rešenje bi bilo da za svaki slog postoji odgovarajući gusti indeks. Indeksi su sortirani po ključu, a slogovi nisu. Problem koji se ovde javlja jeste da imamo viška preko glave, i u smislu prostora na disku, i u smislu vremena pretrage. Drugo rešenje uključuje pojam kofe (bucket). Kofa je fajl u kojem se sekvencijalno nalaze (samo) pokazivači na sva pojavljivanja sloga sa istim ključem. Sada možemo imati indekse koji za svaki ključ čuvaju adresu prvog pojavljivanja ključa u kofi. Kofe imaju dobru primenu u upitima sa konjuktivnim ili disjunktivnim klauzulama 1. 1.2.5 Indeksi u DB2 U narednom delu ćemo posvetiti pažnju o indeksima orjentisanim ka radu sa bazama i tabelama u sistemu za upravljanje bazama podataka IBM DB2. Indeksi u DB2 predstavljaju glavni alat koji obezbeđuje adekvatne performanse ili poboljšava performanse. DB2 vodi računa o svim indeksima. Indeksi se automatski ažuriraju kada se vrednost ključa u redu ažurira. U naredbama za obradu podataka se ne referiše na indeks, već optimizator sâm odlučuje da li će koristiti indeks ili ne, i to u trenutku BIND-ovanja. Bilo koja kolona može biti korišćena kao polje pretrage upita bez da je indeksirana. Svaki indeks je napravljen nad naznačenim indeks kolonama (može ih biti jedna ili više). Takođe, svaki indeks se čuva u svom prostoru indeksa (IndexSpace). Može postojati više indeksa po tabeli kako bi se obezbedila raznovrsnost pretraga, odnosno upita. Indeksi su jedini koji osiguravaju jedinstvenost vrednosti u kolonama. Oni mogu minimizovati sortiranja. Struktura indeksa je predstavljena balansiranim B+ drvetom. U B+ drvetima pokazivači na podatke su usključivo u listovima. Svaki nivo (Index page entry), koji je koreni ili unutrašnji, sastoji se od para sledećih vrednosti: vrednost ključa, i pokazivač na niži nivo (level page) koji obuhvata te vrednosti. Svaki nivo koji je list (Leaf page entry) sastoji se od para sledećih vrednosti: vrednost ključa, i pokazivač na red tabele koji sadrži tu vrednost. Prednosti indeksa su: brže dohvatanje po određenom kriterijumu na koloni (kolonama), brže dohvatanje pri uklapanju (matching) kolona sa kolonama drugih tabela (tj. join), ukoliko je indeks jedinstven, onda se podstiče jedinstvenost vrednosti u okviru tabele. Nedostaci indeksa su: zauzeće dodatnog prostora za strukture indeksa, kao i troškovi održavanja svake strukture indeksa pri dodavanju ili brisanju reda iz tabele, i ažuriranju vrednosti 1 Za više informacija pogledati [2]. 19

indeks kolone u jednom redu ili više redova u tabeli. Indeksi se standardno grade nad kolonama koji ispunjavaju sledeće karakteristike: jedinstveni indeks je obavezan nad primarnim ključem svake tabele, indeksi su snažno preporučljivi za kolone koje predstavljaju strane ključeve, i kolone koje se često koriste u pretragama ili join operacijama sa malim procentom redova. Dodatne kolone nad kojima se razmatra građenje indeksa mogu biti: kolone koje moraju imati jedinstvene vrednosti, kolone nad kojima se često primenjuju agregatne funkcije (npr. COUNT, AVG, SUM), kolone koje se koriste za testiranje postojanja neke vrednosti, kolone koje se često zajedno koriste u WHERE klauzuli (nad njima se dobro primenjuju kompozitni indeksi, najviše radi izbegavanja održavanja više indeksa), i kolone koje se često koriste u ORDER BY, GROUP BY i DISTINCT klauzulama (radi izbegavanja sortiranja). Početnička greška koja se može desiti jeste kada postoji indeks koji se sagrađen nad kombinacijom kolona. Tada treba izbegavati postojanje drugog indeksa koji se građen nad prvom kolonom (ili nad prvih nekoliko kolona). Takođe, treba voditi računa o redosledu kolona. Tipičan primer je sledeći: neka imamo indekse Index(ime, prezime) i Index(prezime, ime). Ukoliko vršimo pretragu po imenima, jasno je da je drugi indeks u potpunosti neupotrebljiv. Naravno, ne treba uvek indeksirati. Neke od preporuka kada indeksi nisu poželjni jeste ukoliko kolone imaju nisku kardinalnost, iskrivljenu distribuciju vrednosti, veliki broj nepoznatih (NULL) vrednosti, ako se često ažuriraju, ako su duže od 40 bajtova, ili ako je tabela veoma mala (manja od 10 stranica). Za razliku od Oracle, u DB2 sistemu postoji mogućnost za klasterovani indeks. Na osnovu klasterovanog indeksa, moguće je podeliti tabelu na celine i distribuirati je na različite diskove. U nekim slučajevima može doći do značajnog minimizovanja ulazno-izlaznih operacija, kada skup redova koji dohvata neka aplikacija ne prelazi jedan ili nekoliko stranica podataka. 20

2 B+ drveta 2.1 Uvod B drveta su često korišćena struktura podataka za indekse. Ona su nesekvencijalna i najupotrebljivanija kada su balansirana (pristupa putevima iste dužine ka različitim slogovima). Prilagođena su za ubacivanja i brisanja. Sastoje se od blokova koji sadrže najviše n ključeva i n + 1 pokazivača. Posmatraćemo varijantu koja se naziva B+ drvo. Primer B+ drveta se nalazi na narednoj slici: koren 100 30 120 150 180 3 5 11 30 35 100 101 110 120 130 150 156 179 180 200 Pretraživanje u B+ drvetu je brzo. Nije potrebno da dubina bude velika. U komercijalnim sistemima se sreću dubine 3 ili 4. Duplikati u B+ drvetu nisu dopušteni. Čvorovi na poslednjem nivou su sortirani i na njemu se nalaze gusti indeksi (svaki ima svoj pokazivač na konkretan slog). Na višim nivoima je mešavina gustih i retkih. Primer unutrašnjeg čvora je dat na narednoj slici: 120 150 180 ključevi < 120 120 ključevi < 150 150 ključevi < 180 ključevi 180 Primer čvora lista je dat na narednoj slici: 21

unutrašnji čvor ili koren 120 130 neiskorišćen sledeći list u sekvenci slog sa ključem 120 slog sa ključem 130 Ne želimo da čvorovi budu previše prazni. Što se tiče broja pokazivača koji se koriste, važi sledeće: broj pokazivača unutrašnjih čvorova (ka deci čvorovima) je barem (n + 1)/2, i broj pokazivača listova (ka slogovima/blokovima) je barem (n + 1)/2. U B+ drvetu važe sledeća pravila: 1. Svi listovi se nalaze na istom najnižem nivou (balansirano drvo), 2. Pokazivači u listovima pokazuju ka slogovima, osim sekvencnih pokazivača" (to su oni koji pokazuju na naredni list), 3. Važi sledeća tabela koja govori o broju pokazivača/ključeva: najviše pokazivača najviše ključeva najmanje pokazivača ka podacima najmanje ključeva unutrašnji čvor n + 1 n (n + 1)/2 (n + 1)/2 1 list n + 1 n (n + 1)/2 (n + 1)/2 koren n + 1 n 2 2 1 2.2 Unošenje Prvo treba potražiti odgovarajući list za zadati ključ. Nadalje razlikujemo četiri slučaja (u primerima ispod svakog slučaja pretpostavljamo da je n = 3): 1. prost slučaj ukoliko list nije pun, onda možemo jednostavno da ubacimo par (ključ, pokazivač ka slogu). 2. list je pun u ovom slučaju, prvo treba pronaći vrednost umesto koje ubacujemo par (ključ, pokazivač ka slogu). Vrednosti koje su manje od unetog ključa se prebacuju u novi list (nijedan list ne sme imati manje ključeva od minimalnog broja). Novi list 22

koristi poslednje (neiskorišćeno) mesto za pokazivač ka narednom listu (tj. ka listu u kojem su se prethodno nalazile prebačene vrednosti). Na kraju, u čvor na nivou iznad treba dodati ključ sa pokazivačem ka novom listu. početno stanje stanje posle unosa ključa 7 100 100 30... 7 30... 3 5 11 30 35 3 5 7 11 30 35 3. pun unutrašnji čvor postupak je sličan kao u prethodnom slučaju, s time da je sada neophodno dodati novi unutrašni čvor (sa ključem iz susednog unutrašnjeg čvora) koji će imati pokazivače ka novom čvoru (i susednom čvoru, ukoliko ima potrebe). Takođe, u unutrašnjem čvoru koji je iznad novog čvora treba dodati par (ključ, pokazivač ka novom unutrašnjem čvoru). početno stanje stanje posle unosa ključa 160 100 100 160... 120 150 180... 120 150 180 150 156 179 180 200 150 156 179 160 179 180 200 4. pun koren ovo je najkomplikovaniji slučaj koji može da se javi. Analogan je prethodnim slučajevima, s time da treba povećati nivo drveta i napraviti novi koren. početno stanje 10 20 30 1 2 3 10 12 20 25 30 32 40 23

stanje posle unosa ključa 45 30 10 20 40 1 2 3 10 12 20 25 30 32 40 45 2.3 Brisanje Slično kao kod unošenja, prvo treba potražiti odgovarajući list za zadati ključ. Nadalje razlikujemo četiri slučaja (u primerima ispod svakog slučaja pretpostavljamo da je n = 4): 1. prost slučaj ukoliko brisanjem ključa iz lista ne remetimo ograničenja u B+ drvetu, onda možemo obrisati taj ključ. 2. pozajmljivanje ključeva ukoliko brisanjem ključa iz lista, broj ključeva u listu postane manji od minimalnog, onda treba premestiti jedan ključ iz susednog lista u list u kojem je došlo do brisanja, a zatim ažurirati odgovarajući unutrašnji čvor na nivou iznad. početno stanje stanje posle brisanja ključa 50 10 40 100 10 35 100... 10 20 30 35 40 50...... 10 20 30 35 40... 3. spajanje listova ukoliko brisanjem ključa narušimo minimalan broj, ali iz susednog lista ne možemo prebaciti ključ jer će tada u tom listu biti narušen minimalan broj, onda takva dva lista spajamo u jedan i brišemo odgovarajući ključ (i pokazivač) iz čvora na nivou iznad. početno stanje stanje posle brisanja ključa 50 20 40 100 20 100... 20 30 40 50...... 20 30 40... 24

4. spajanje ne-listova ovo predstavlja varijantu prethodnog slučaja u kojoj može doći do spajanja različitih čvorova, a ne samo listova. U ovom slučaju može doći do snižavanja nivoa drveta, ukoliko se spoje čvor i koren. U praksi, spajanje se često ne implementira zbog komplikovanosti i neisplativosti. Kasniji unosi u drvo mogu povratiti čvor nazad u minimalno stanje (tj. stanje u kojem on ne narušava ograničenja B+ drveta). Umesto ovoga koristi se sledeći kompromis: probaj da distribuiraš ključeve sa susedom; ukoliko je to nemoguće, ostavi ga takvog. Ako svi pristupi ka slogovima prolaze kroz B+ drvo, onda je moguće na mestima u listu postaviti oznaku ( grob") za obrisani slog. 2.4 Performanse B+ drvo se dobro adaptira na unošenje i brisanje, pri tome čuvajući balansiranost. Administrator baza podataka nema potrebe da brine o reorganizovanju. Operacije split i merge (deljenja i spajanja) nad čvorovima su veoma retke. Vreme za pristup slog je dominantno od strane traženja ključa (tj. obilaska od korena do lista). Primera radi, pretpostavimo da su blokovi veličine 4KB, ključevi veličine 4 bajtova, i pokazivači veličine 8 bajtova. Pitamo se koliko ključeva i pokazivača može stati u čvor? Treba pronaći najveću vrednost za n takva da je ispunjeno (4 n + 8 (n + 1))B 4096B. Odavde se dobija da je n = 340. Dakle, u čvor može stati 340 ključeva i 341 pokazivač, odnosno, 174 ključeva i 341 pokazivač ukoliko čvor nije list. Pretpostavimo da prosečan čvor ima 255 pokazivača. Odavde sledi da B+ drvo sa tri nivoa ima 255 2 = 65025 listova sa ukupno 255 3 16.6 miliona pokazivača ka slogovima. Takođe, ukoliko se blok korena čuva u glavnoj memoriji, svakom slogu može se pristupiti sa 2 + 1 ulazno-izlaznih operacija sa diskom. Ako su svih 256 unutrašnjih čvorova u glavnoj memoriji, onda pristup zahteva 1 + 1 ulazno-izlaznih operacija sa diskom (256 4K B = 1M B, što je poprilično izvodljivo). 25

3 Optimizacija 3.1 Uvod Optimizacija je nastala kao odgovor na problem biranja efikasne strategije za izračunavanje postavljenog upita. Ona predstavlja i izazov i mogućnost u relacionim bazama podataka. Izazov zato što je neophodna radi dostizanja prihvataljivih performansi sistema, a mogućnost jer ilustruje prednost relacionog pristupa (u odnosu na nerelacione). Za relacione izraze koji su na dovoljno visokom semantičkom nivou, optimizacija se izvodi na samom poětku obrade. Kada kažemo da je neki upit optimalni, mislimo da njegovo izračunavanje troši najmanji utrošak resursa (memorije, procesora, vreme čekanja itd.). Program za optimizaciju se naziva optimizator. Optimizacija je proces koji se vrši automatski, bez intervencije korisnika, odnosno, bez obzira na to da li korisnik želi da se vrši optimizacija ili ne. Ovo proizilazi iz činjenice da će optimizator bolje uraditi optimizaciju od korisnika relacionog sistema. Među razlozima veće efikasnosti automatske optimizacije mogu se uvrstati sledeći: dobar optimizator ima na raspolaganju statističke informacije iz sistemskog kataloga (na primer, broj vrednosti u svakom domenu, broj torki u svakom osnovnom relvaru, trenutni broj različitih vrednosti u svakom osnovnom relvaru, koliko puta se svaka vrednost javlja u svakom atributu, itd.), optimizator je program i prema samoj definiciji je strpljiviji od uobičajenog ljudskog korisnika. Optimizator je, u odnosu na čoveka, sposoban da pregleda stotine razliǐtih strategija pristupa za dati upit, u optimizator su uključene veštine, iskustvo i znanje najboljih" ljudskih programera. Posledica toga je da su te osobine svima na raspolaganju. Ako se statistika promeni, moguće je da treba promeniti statistiku, odnosno izvršiti reoptimizaciju. Reoptimizacija se vrši ponovnom obradom originalnih zahteva od strane optimizatora, što bi bio vrlo redak slučaj u slučaju ručne optimizacije od strane korisnika. Pokažimo jedan primer. Neka treba prikazati imena studenata koji su polagali ispit čija je identifikacija predmeta 101. Upit napisan na relacionom modelu je veoma jednostavan: ((Dosije JOIN Ispit) WHERE Id_predmeta(101)){IME} Neka baza sadrži 100 studenata i podatke o 10000 ispita od kojih se 50 odnosi na traženi predmet. Neka se Dosije i Ispit nalaze direktno na disku, svaki relvar u po jednoj datoteci sa jednom torkom u jednom slogu. Za kriterijum efikasnosti uzećemo broj čitanja i pisanja po disku, odnosno broj U/I operacija. Postoje dve strategije izračunavanja zadatog upita: direktna i sa optimizacijom. Direktna strategija ima naredne korake: 26

1. Izvršiti spajanje Dosije i Ispit (preko Indeks) za svakog od 100 studenata čita se 10000 ispita. Međurezultat se sastoji od 10000 spojenih torki koje se pišu natrag na disk (jer memorija nije dovoljno velika da ih primi), 2. Vrši se restrikcija rezultata u prethodnom koraku na torke koje sadrže identifikator predmeta 101 čita se ponovo 10000 torki sa diska i rezultat je 50 torki koje mogu da ostanu u memoriji, 3. Projektuju se rezultati iz prethodnog koraka preko IME najviše 50 torki ostaje u memoriji. Ova strategija vodi do rezultata od 1030000 U/I operacija. Strategija sa optimizacijom bi tekla na sledeći način: 1. Izvršiti restrikciju na torke koje sadrže identifikator predmeta 101 čita se 10000 ispita. Međurezultat se sastoji od 50 torki koje ostaju u memoriji, 2. Spojiti rezultate prethodnog koraka (preko Indeks) sa Dosije čita se 100 studenata. Dobijeni rezultat ima ponovo 50 torki koje ostaju u memoriji, 3. Projektuju se rezultati iz prethodnog koraka preko IME najviše 50 torki ostaje u memoriji. Ova strategija vodi do rezultata od 10100 U/I operacija. Rezultati su jasni razlika u dužini izvršavanja je takva da drugi pristup daje oko 100 puta brže izračunavanje. Naravno moguća su i dalja poboljšavanja (na primer, ukoliko se atributi indeksiraju). 3.2 Faze obrade upita U obradi upita se mogu identifikovati 4 osnovne faze: 1. Prevođenje upita na interni zapis, 2. Konverzija upita u kanonički oblik, 3. Izbor kandidata za procedure niskog nivoa, 4. Formiranje planova upita i izbor najjeftinijeg. U prvoj fazi, početni upit se prevodi u internu reprezentaciju koja je pogodnija za obradu u računaru. Obično se koristi drvo upita ili drvo apstraktne sintakse. Možemo izabrati pogodniji formalizam za predstavljanje upita, na primer, relacionu algebru. Neka je zadat upit iz prethodnog primera: ((Dosije JOIN Ispit) WHERE Id_predmeta(101)){IME} 27

Drvo upita izgleda: rezultat projekcija (IME) restrikcija (Id_predmeta = 101) spajanje (Ispit.Indeks = Dosije.Indeks) Ispit Dosije U drugoj fazi, optimizator obavlja operacije za koje postoji garancija da su dobre", bez obzira kakvi su podaci i koja je baza u pitanju. Na primer, SQL upit je moguće zapisati na više načina koje pre dalje obrade treba dovesti na ekvivalentan kanonički oblik koji je mnogo efikasniji. Za konverziju upita u kanonički oblik optimizator koristi različita pravila za transformaciju. Dva upita q1 i q2 su ekvivalentni ako i samo ako se, pri njihovom izvršavanju, u svim slučajevima dobija isti rezultat. Za podskup C datog skupa upita Q se kaže da je u kanoničkoj formi za Q ako i samo ako je svaki upit q Q ekvivalentan nekom upitu c C. U tom slučaju, upit c predstavlja kanonički oblik upita q. Posledica ove definicije jeste da sve korisne" osobine koje mogu da se primene na upit q važe i za upit c. Zbog toga je dovoljno da se razmatra manji skup upita C (umesto većeg Q) da bi se dobili različiti korisni" rezultati. U trećoj fazi, posle konverzije i predstavljanja u kanoničkom obliku, optimizator mora da odluči na koji način će izvršavati transformisani upit. Osnovna strategija je posmatranje izraza koji predstavlja upit kao niz operacija niskog nivoa (spajanje, projekcija, restrikcija, itd.) između kojih postoje određene zavisnosti (na primer, projekcija obično zahteva da ulazne torke budu sortirane što znači da rezultat prethodne operacije treba da bude sortiran). Optimizator razmatra postojanje indeksa, postojanje pristupnih puteva, fizičku distribuciju podataka, itd. Za svaku od operacija niskog nivoa optimizator ima na raspolaganju skup predefinisanih procedura za njihovu implementaciju. Svaka procedura ima pridruženu (parametrizovanu) formulu za određivanje cene koštanja, obično u zavisnosti od U/I operacija 28

na disku, CPU vremena, veličine međurezultata, itd. Na osnovu informacija iz kataloga o tekućem stanju baze i međusobnih zavisnosti operacija niskog nivoa, optimizator bira jednu ili više procedura za implementaciju svake od operacija niskog nivoa. U četvrtoj (i poslednjoj) fazi, formira se skup kandidata za plan upita između kojih se bira najbolji (tj. najjevtiniji). Svaki plan je kombinacija kandidata za implementaciju procedura za operacije niskog nivoa. Cena upita je jednaka zbiru cena pojedinačnih procedura. Problem je određivanje cene upita jer formule zavise od veličine relacija koje se obrađuju. Svi sem najjednostavnijh upita uključuju formiranje međurezultata pri izvršavanju tako da najveći deo parametara nije unapred poznat. Zbog toga optimizator pravi procene cene koštanja upita. U DB2 postoji alat Visual Explain koji nudi primer procene. Napomenimo da kroz fazu obrade upita prolaze i statički i dinamički SQL, s tim da dinamički može biti sporiji jer nije unapred sve poznato, pa je neophodno više puta da prolazi kroz obradu. 3.3 Transformacija izraza U narednom delu ćemo prikazati neke transformacije izraza koje uključuju određene operatore. Krenimo od restrikcije i projekcije. Izraz ekvivalentan je sa (A WHERE restrikcija1) WHERE restrikcija2 A WHERE restrikcija1 AND restrikcija2. Neka imamo skupove atributa {atributi1} i {atributi2}, za koje važi {atributi2} {atributi1}. Tada je izraz (A {atributi1}) {atributi2} ekvivalentan sa A {atributi2}. Restrikcija projekcije se može transformisati u projekciju restrikcije, tj. izraz ekvivalentan je sa (A {atributi}) WHERE restrikcija (A WHERE restrikcija) {atributi}. U opštem slučaju je dobro primeniti restrikciju pre projekcije jer se time smanjuje veličina ulaza u projekciju, čime se smanjuje veličina podataka koje treba sortirati radi eliminisanja duplikata. 29

Primena zakona distributivnosti za unarni operator f se kaže da je distributivan preko binarnog operatora ako i samo ako važi f (A B) f (A) f (B). Restrikcija je distributivna preko unije, preseka i razlike, uvek. Restrikcija je distributivna preko spajanja ako i samo ako se uslov restrikcije sastoji od najviše dva odvojena uslova restrikcije koja su spojena konjunkcijom (AND), jedan za svaki operand u spajanju. Projekcija je distributivna preko unije i preseka (ne i preko razlike), uvek. Projekcija je distributivna preko spajanja, tj. važi (A JOIN B) {C} (A {AC}) JOIN (B {BC}) ako i samo ako važi: AC je unija (a) atributa koji su zajednički sa A i B i (b) onih atributa C koji se pojavljuju samo u A, i BC je unija (a) atributa koji su zajednički sa A i B i (b) onih atributa C koji se pojavljuju samo u B. Primena zakona komutativnosti binarni operator je komutativan ako i samo ako važi A B B A. Unija, presek i spajanje su komutativni operatori. Razlika i deljenje nisu komutativni operatori. Posledica primene ovog zakona je ako upit uključuje spajanje dve relacije A i B, onda je moguće da se manja" relacija uzme za spoljašnju. Primena zakona idempotentnosti binarni operator je idempotentan ako i samo ako važi A A A. Unija, presek i spajanje su idempotentni operatori. Razlika i deljenje nisu idempotentni operatori. Osobina idempotencije može da bude korisna u transformaciji izraza. Skalarni izračunljivi izrazi optimizator mora da vodi računa i o transformacijama aritmetičkih izraza (na primer, komutacija, asocijacija, distribucija), jer na ovaj tip izraza može da se naiđe u kontekstu operatora extend i summarize. Logički izrazi na primer, izraz A>B AND B>3 može se, na osnovu tranzitivnosti operatora >, transformisati u izraz A>B AND B>3 AND A>3. 30

Opisana transformacija je korisna jer omogućuje dodatnu restrikciju na A pre izvođenja spajanja (sa >). Ideja izvođenja ranije restrikcije je pogodna i primenjuje je više komercijalnih proizvoda. Navedimo još jedan primer. Izraz može se transformisati u izraz A>B OR (C=D AND E<F) (A>B OR C=D) AND (A>B OR E<F). Takođe, svaki logički izraz se može transformisati u ekvivalentni izraz u konjuktivnoj normalnoj formi (KNF). KNF je izraz oblika C 1 AND C 2 AND... AND C n, pri čemu ni jedan od izraza C i ne sadrži konjunkciju (AND). Prednost KNF izraza je što je izraz tačan ako su svi konjunkti tačni, a netačan ako je bar jedan od njih netačan. Kako je konjunkcija komutativan operator, optimizator može da bira redosled izvršavanja konjukata idući od jednostavnijih ka složenijima. KNF je pogodan kod sistema sa paralelnom obradom. Semantičke transformacije U izrazu (SP JOIN S) {PRBR} spajanje se vrši uparivanjem spoljašnjeg ključa (sa jedne strane) i kandidata za ključ (sa druge strane). Odatle sledi da se svaka torka iz SP spaja sa nekom torkom iz S i da zbog toga svaka torka iz SP daje neko PRBR u krajnjem rezultatu. Odavde se vidi da nema potrebe za spajanjem i da izraz može biti uprošćen u SP {PRBR}. Ova transformacija, iako je značajna, retko se sreće kod komercijalnih sistema zbog složenosti. 3.4 Saveti za pisanje optimizovanijih SQL upita Preporuke koje se nalaze u ovom delu potiču od [6]. Pogledati originalne slajdove za više detalja o motivaciji za nastanak ovih saveta. Kroz jezik za obradu podataka (data manipulation language (DML)), korisnik DB2 baze podataka obezbeđuje odgovor na pitanje Šta?", tj. podatke koji su potrebni iz baze podataka, a koji zadovoljavaju određeni zahtev. DB2 potom koristi informacije iz DB2 kataloga da bi rešio pitanje Gde?" se podaci nalaze. DB2 optimizator je odgovoran za utvrđivanje svih bitnih odgovora na pitanje Kako?" da bi pristupio podacima efikasno. 31

Dakle, DB2 optimizator pri optimizaciji koristi: definicije objekata (object definitions), pristupne puteve (access path), sortiranja RID bazena" (RID pool sorts), predlozi za pristupne puteve (access path hint), sâm upitni jezik (SQL), i statistiku iz kataloga (catalog statistics). DB2 optimizator gleda na svaki predikat pojedinačno i dodeljuje informacije o predikatu. Ove informacije moguće je videti u novim Explain tabelama i korišćenjem IBM Data Studio alata. Kategorije predikata koje optimizator prepoznaje su: indeksabilni, ili neindeksabilni, stage 1, ili stage 2, odnosno, popravljivog efekta (sargeable 3 ), ili nepopravljivog efekta (non-sargeable), tip predikata (equal, in, between, range, subq, itd.), filter faktori, i oni koji se koristi prilikom join prerade (before, during, after). Stage 1 (DB2 upravljač podacima) je odgovoran za prevođenje podataka, koji su skladišteni u stranicama, u rezultat koji čini skup redova i kolona. Predikati koji su napisani na prilično jednosmeran način, često mogu biti izračunati uz relativno male troškove. Stage 1 predikati su oblika WHERE C1 OP:HV, gde je C1 kolona, OP operator, i :HV host promenljiva. Operator može biti: jednostavni operator (=, >, >=, <, <=, <>,!=,!>,!<, itd.), IN (...), BETWEEN, i LIKE, testiranje NULL vrednosti, tj. C1 IS NULL. Tip podatka i dužina C1 i :HV treba da se poklapaju u većini slučajeva. Predikati mogu biti spojeni bulovskim operatorima (AND, OR, i NOT). Negirani predikati se evaluiraju u stage 1, ali ne koriste odgovarajuće indeksno skeniranje u većini slučajeva. Funkcije AVG, SUM, i COUNT mogu biti izračunate iz lista ili stranice podataka u stage 1. MIN i MAX mogu biti zadovoljeni u stage 1 sa 1-fetch indeksnim skeniranjem. Kolone koje prethodne nekoreliranim podupitima, koji vraćaju jedinstvenu vrednost korišćenjem > ALL, > ANY, i > SOME, mogu biti evaluirane u stage 1. Neki podupiti mogu biti evaluirani u stage 1 nakon transformacije od strane optimizatora. Stage 2 (relacioni servisi podataka, RSP) barataju kompleksnijim predikatima, transformacijama podataka, i izračunavanja. Stage 2 predikati su mnogo skuplji za rešavanje od strane DB2 nego stage 1 zbog dodatne obrade i dodatnih putanja. Dodatno, RSP ne mogu da efektivno koriste indekse. Navedimo kratak pregled stage 2 predikata: predikat koji poredi različite tipove podataka, predikat sa artimetičkim i skalarnim funkcijama nad kolonama, predikat sa CASE klauzulom, predikat sa podupitom koji koristi IN, =ALL, =ANY, =SOME, i EXISTS 3 Za upit se kaže da je popravljivog efekta (sargeable) ukoliko indeksi mogu popraviti njegovu brzinu i efikasnost. Pogledati definiciju na www.techopedia.com. 32

(ovi tipovi predikata mogu biti transformisani u spajanja na osnovu nekog kriterijuma; ukoliko podupiti mogu biti izračunati kao IN (...), onda je evaluacija u stage 1), velika većina koreliranih podupita, predikat sa podupitom koji koristi EXISTS ili NOT EXISTS, i predikat koji poredi iste ili različite kolone u okviru iste tabele ili različitih tabela, na primer, WHERE C1 BETWEEN C2 AND C3. Slede saveti koje treba uzeti u obzir pri pisanju upita. 1. Eliminisati neke (ili sve) skalarne funkcije koje se primenjuju nad kolonama u predikatima. Na primer, upit SELECT EMPNO, LASTNAME FROM EMPLOYEE WHERE YEAR(HIREDATE) = 2005 treba transformisati u upit SELECT EMPNO, LASTNAME FROM EMPLOYEE WHERE HIREDATE BETWEEN '2005-01-01' AND '2005-12-31' Zbog čega se ovo radi? Primena izraza nad kolonama često sprečava upotrebu indeksa. 2. Eliminisati neke (ili sve) matematičke operacije nad kolonama u predikatima. Na primer, upit SELECT EMPNO, LASTNAME FROM EMPLOYEE WHERE SALARY * 1.1 > 50000.00 treba transformisati u upit SELECT EMPNO, LASTNAME FROM EMPLOYEE WHERE SALARY > 50000.00 / 1.1 3. Izbegavati upotrebu DISTINCT ukoliko je moguće. To je zato što DISTINCT automatski podrazumeva sortiranje. Ukoliko treba ukloniti duplikate iz rezultata, probati sa upotrebom ORDER BY koji će pokušati da iskoristi na bilo koji način povezane indekse radi eleminisanja sortiranja koje jedinstvenost zahteva. Takođe, može se pokušati sa transformisanjem upita korišćenjem kombinacije podupita sa IN ili EXISTS. Ovo će funkcionisati ukoliko tabela koja je uzrok duplikata (uzgred jedan-ka-više odnosu) ne sadrži podatke koje se dobijaju kao deo rezultata. Na primer, upit SELECT DISTINCT E.EMPNO, E.LASTNAME FROM EMP E, EMPPROJACT EPA WHERE E.EMNO = EPA.EMPNO 33