Tutorijal za projektovanje relacionih baza podataka

Student:Dragana Dudić 2043/2009

1. Kada kažemo baze podataka, mislimo na šta?

Pre nego što pređemo na projektovanje baza podataka zgodno je podsetiti se osnovnih pojmova vezanih za baze podataka i komponenti koje ih okružuju. Najprostije rečeno, baza podataka je skup međusobno povezanih podataka. Bez sistema za upravljanjem bazama podataka (SUBP), baze podataka ne bi imale popularnost koju imaju zadnjih nekoliko decenija. Zapravo, da nema SUBP-a, običan XML fajl bi bio pogodniji i jednostavniji za čuvanje, pristup i ažuriranje podataka od baze podataka. SUBP je softverski sistem koji omogućava efikasan rad sa podacima i održavanje konzistentnog stanja baze podataka. SUBP i baze podazaka zajedno čine sistem baza podataka. Od šezdesetih godina prošlog veka pa sve do danas, sistemi baza podataka su u stalnom razvoju.

Svaka generaciija SUBP-a se karakteriše različitom vrstom modela podataka Najpre se pojavio mrežni model podataka a ubrzo i hijerarhijski model podataka ali su oni danas ne koriste u velikoj meri. Model podataka koji se danas najviše koristi je relacioni model podataka. Kao alternativa relacionom modelu pojavili su se objektno-orjentisan i objektno-relacioni model ali nisu dosegli popularnost relacionog modela, stoga je akcenat na relacionim bazama podataka.

2. Želimo da projektujemo bazu podataka. Odakle početi?

Na prvi pogled projektovanje baze podataka se čini jednostavnim – odredimo na kakva pitanja treba baza podataka da da odgovor, organizujemo te podatke u tabele i gotovo. Deluje prilično prosto, zar ne? I ovo bi funkcionisalo ako se baza ne bi menjala. Ali bilo kakvo ažuriranje baze vrlo lako bi moglo da poremeti zavisnosti u bazi o kojima nismo ni razmišljali. Slično, ako bi smo proširivali funkcionalnost baze, morali bismo da menjamo

2

Slika 1

gomilu tabela u našoj bazi zbog potencijalno loše organizacije podataka koja je posledica neprojektovanja baze.

Hajde da ukratko pogledamo kako zapravo treba da izgleda projektovanje baze (Slika 1). Prvi korak je isti kao i u prethodnom pristupu – treba da odredimo šta korisnik očekuje od baze podataka. Ovo podrazumeva da odlučimo koje podatke treba čuvati u bazi podataka kao i da odredimo koje se operacije izvode češće od drugih. Ovaj korak se naziva analiza zahteva. Sledeći korak je konceptualno projektovanje baze i najčešće se realizuje uz pomoć ER modela ili nekog sličnog modela podataka. U ovom koraku prikupljene informacije iz analize zahteva se organizuju i koriste u opisivanju podataka koji će biti čuvani u bazi podataka kao i njihovih ograničenja. Nakon konceptualnog projektovanja baze podataka sledi logičko projektovanje baza podataka koje predstavlja naredni korak u projektovanju baza podataka. Zadatak logičkog projektovanja baze podataka je da ER shemu koja je rezultat konceptualnog projektovanja prevedemo u shemu relacione baze podataka. Ovako dobijena shema može da sadrži problematične relacije koje treba preraditi. Zato je četvrti korak u projektovanju baza podataka prerađivanje sheme i zasniva se na normalizaciji relacija. Na kraju ostaje još fizičko organizovanje podataka tako da performanse baze podataka budu što veće i ovo se izvršava u petom koraku, koraku fizičkog projektovanja baze podataka

3. Za početak... Prvi korak – analiza zahteva

Rekli smo da u analizi zahteva odgovaramo na potrebe korisnika. Dakle, treba da prikupimo podatke koji će nas usmeriti u daljem radu. Analiza zahteva se vrši u saradnji sa korisnikom i korisnik je taj koji treba da pruži što više podataka a naše je da ga usmerimo ka tome. Da bismo približili analizu zahteva, prođimo kroz jedan primer.

Recimo da vlasnik mašinske radionice traži od nas da napravimo bazu podataka koja bi pratila rad njegove radionice. Ako bi ovo bilo sve od informacija koje smo dobili od korisnika, ne bi znali da li on želi bazu podataka o osoblju u radionici ili možda o poslovanju radionice ili pak o proizvodima ove radionice. Zato se dalje informišemo o željama vlasnika fabrike. Npr. neka on želi da ima zabeležene podatke o proizvodima. Ovo i dalje nije dovoljno jer mi ne znamo čime se karakterišu proizvodi radionice, zato bismo tražili dodatne informacije od vlasnika. Tada bi nam vlasnik rekao da je svaki proizvod određen svojim brojem, materijalom, količinom materijala i nazivom kao i da svaka mašina proizvodi tačno jedan proizvod. Još je spomenuo da se za svaki proizvod zna vreme početka i završetka proizvodnje. S obzirom da proizvod zavisi od mašine i radnika, trebalo bi da tražimo i te podatke od vlasnika. Recimo da nam je rekao da svaki radnik upravlja svakom mašinom, da je za svaku mašinu poznat broj mašine, naziv i detalji o mašini (da li je prenosiva ili ne) a da za svakog radnika postoji podatak sa matičnim brojem, imenom i platom ali i koliko mu je vremena potrebno da izradi proizvod na nekoj mašini. Sada imamo sve potrebne podatke i možemo preći na drugi korak.

4. Korak dalje... Drugi korak – konceptualno projektovanje

3

Konceptualno projektovanje podrazumeva kreiranje dijagrama modela entiteta i odnosa poznatijeg kao ER dijagram. Model entiteta i odnosa je najpopularniji konceptulani model za projektovanje baza podataka. Postoje mnoga proširenja ovog modela , ali o tome nešto kasnije.

Ovaj model opisuje podatke u bazi i kako su oni povezani i to kao entitete (u smislu skupa entiteta), atribute i veze. Pod entitetima podrazumevamo osobe, stvari, događaje, pojmove koji su od značaja za bazu. Svaki entitet je opisan svojim atributima, dok veza opisuje zavsinosti između entiteta. Svi ovi podaci su nam indirektno navedeni u analizi zahteva. Iz analize zahteva znamo:

Svaki radnik upravlja svakom mašinom koja je određena brojem mašine, nazivom i detaljima o mašini

Svaka mašina proizvodi proizvode koji su određeni brojem proizvoda, materijalom, vremenom izrade i radnikom koji ga je napravio

Svaki proizvod je napravio radnik koji je određen je jmbg-om, platom i imenom

Najčešće važi da su entiteti imenice, atributi pridevi a veze glagoli. Stoga su u slučaju baze podataka mašinske radionice entiteti mašina, proizvod i radnik. Atributi za entitet mašina su broj mašine, naziv i detalji o mašini, za entitet proizvod broj proizvoda, materijal, vreme izrade i radnik a za radnika id, plata i ime. Iz gore navedenih rečenica glagoli predstavljaju veze između odgovarajućih entiteta i to su upravlja, proizvodi i pravi. Za svaki entitet treba izabrati primarni ključ. Primarni ključ je najmanji skup atributa koji jednoznačno određuje entitet. Ako ima više ovakvih skupova, onda biramo jedan od njih. Zato je za entitet mašine primarni ključ broj mašine, za proizvode broj proizvoda a za radnika identifikacioni broj.

ER model je stekao popularnost zbog načina predstavljanja podataka tj. ER dijagrama. U ovom dijagramu entiteti se predstavljaju pravougaonikom, atributi elipsom a veze rombom. Npr. vezu upravlja između entiteta radnik i mašina bismo predstavili kao na Slici 2.

Slika 24.1 Veze

Veze se mogu klasifikovati prema kardinalnosti. Kardinalnost predstavlja broj pojavljivanja entiteta u vezi. Moguće kardinalnosti između entiteta A i B su:

1:1 – Entitet A je povezan sa najviše jednim entitetom B i suprotno. 1:N – Entitet A je povezan sa proizvoljnim brojem entiteta B a entitet B sa

najviše jednim entitetom A N:M. – Entitet A je povezan sa proizvoljnim brojem entiteta B i suprotno

4

Pogledajmo ponovo vezu upravlja. Iz analize zahteva znamo da svaki radnik može da upravlja svakom mašinom, pa je kardinalnost ove veze N:M i to se predstavlja kao na slici 3.

Slika 3

Pored kardinalnosti za veze je važno i participiranje (učešće) entiteta u vezi. Participiranje može biti totalno i parcijalno. Za participiranje kažemo da je totalno ako postojanje entiteta zahteva postojanje povezanog entiteta u određenoj vezi. U suprotnom je participiranje parcijalno. U bazi mašinske radionice su od značaja samo radnici koji rade na mašinama. S obzirom da Svi radnici rade na svim mašinama, obe veze su totalne. Kada bismo pod radnikom smatrali sve radnike mašinske radionice od čistačica do administrativnih radnika onda bi veza od radnika ka mašini bila parcijalna. Totalnu participaciju obeležavamo debljom linijom kao na slici 4.

Slika 4

Za mašinsku radionicu su sva participiranja su totalna. Još ćemo pomenuti da entitet može biti u relaciji sa samim sobom. Npr. ako bi radionica bila podeljena na odeljenja onda bi jedan radnik bio šef tog odeljenja i relacija radnik bi bila u relaciji je šef za sama sa sobom jer je šef takođe radnik i on kontroliše ostrale radnike (Slika 5)

Slika 54.2 Atributi

Pomenuli smo da atributima opisujuemo neke karakteristike entiteta i da ih označavamo elipsom. Atribut koji predstavlja primarni ključ se označava ili zvezdicom ili podvlačenjem. Npr. atribute veze radnik bismo predstavili kao na Slici 6.

5

Slika 6

Kao i entitet, i veza može da ima atribute koji opisuju samu vezu. Podsetimo se da je vlasnik radionice rekao da proizvodnja svakog proizvoda ima zabeleženo početno i završno vreme. Jasno je da su u pitanju atributi ali ih ne možemo dodeliti ni radniku ni mašini jer se odnose na oba entiteta. Zato ih dodajemo vezi pravi (Slika 7). Slična situacija je i sa vezom upravlja i atributom maš_vreme koji se odnosi na vreme koje je potrebno radniku na određenoj mašini.

Slika 74.3 Entiteti

Proučimo malo bolje entitete. Nisu svi entiteti isti. Naime, postoje entiteti koji zavise od drugog entiteta i takve entitete nazivamo slabim ili zavisnim entitetima. Ostale entitete nazivamo nezavisnim ili regularnim entitetima. Poznato je da svaki prijavljen radnik dobija zdravstveno osiguranje za svoju decu dok se školuju kao i za bračnog partnera pod odredjenim uslovima. Recimo da želimo da zabeležimo ko sve koristi zdravstveno osiguranje svakog radnika. Ali ako bi radnik prestao da radi u radionici, ovi podaci više ne bi bili od značaja. Dakle, osiguranik zavisi od radnika. Prirodno je da osiguranik ima atribute ime i godine, ali nije jedinstveno određen na ovaj način jer više radnika može imati sina Peru Perića od 16 godina. Ali bi bio jedinstveno određen imenom osiguranika i jmbg-om radnika. Dakle, slab entitet može biti jedinstveno određen uz pomoć nekih svojih atributa i primarnog ključa entiteta od kog zavisi. Samim tim kardinalnost ove veze može biti 1:1 ili 1:N i participiranje slabog entiteta mora biti totalno. Inače, slabe entitete obeležavamo duplim pravougaonikom (Slika 8).

6

Slika 8

Ako za neku podklasu entiteta treba definisati posebne atribute ili ako učestvuje u nekim dodatnim vezama tada definišemo podklase entiteta. Npr. entitet radnik može imati podklase stalno zapošljen radnik, na određeno zapošljen radnik i honorarno zapošljen radnik. Radnik koji je zapošljen na određeno ima dodatni atribut na koliko je meseci zapošljen dok za honorarno zapošljenog radnika je od značaja broj radnih sati. Ovakva klasifikacija se naziva specijalizacija dok se suprotan proces naziva generalizacija. Klasifikacija se označava uz pomoć trougla sa tekstom IS A kao na Slici 9.

Slika 9

Do sada smo definisali veze samo između entiteta. Ipak, ponekad je potrebno da se definiše veza između entiteta i neke već postojeće veze i tada se koristi agregacija. Obeležava se tako što se ta već postojeće veza okruži isprekidanim pravougaonikom.Proširivanjem ER dijagrama ovim vezama koje odražavaju hijerarhiju dobijamo prošireni ER dijagram (EER dijagram).Na slici 10 prikazan je ER dijagram za mašinsku radionicu.

7

Slika 10

Nakon konstrukcije ER dijagrama, prelazimo na treći korak.

5. Na pola puta... Treći korak – Logičko projektovanje

Logičko projektovanje podrazumeva prevođenje ER dijagrama u shemu relacione baze. Za svaki deo ER dijagrma postoji tačno definisano pravilo kako se prevodi u relacionu shemu (relaciju).

Nezavisni entitet se prevodi u relaciju sa istim imenom kao i entitet i koja sadrži sve atribute entiteta. Npr. entitet radnik prevodimo u relacju radnik sa atributima jmbg, ime i plata gde je jmbg primarni ključ ove relacije:

Radnik (jmbg*, ime, plata)

Zavisni entitet se prevodi u relaciju sa istim imenom kao i entitet a koja sadrži atribute entiteta i primarni ključ entiteta od kog zavisi. Primarni ključ je primarni ključ entiteta od kog zavisi sa primarnim ključem zavisnog entiteta. Primer je entitet osiguranici:

Osiguranici ((jmbg, ime)*, godine)

Veze se prevode u zavisnosti od kardinalnosti i participiranja. Ako je kardinalnost veze 1:1 a :

participarnje sa jedne strane totalno a sa druge parcijalno, onda se ta veza ne prevodi u posebnu relaciju već ključ parcijalne strane i atributi veze postaju

8

atributi relacije sa totalne strane. Knadidati za ključ su primarni ključevi oba entiteta

participirajne sa obe strane parcijalno, onda ta veza postaje posebna relacija sa atributima veze i ključevima entiteta koji predstavljaju i kandidata za kljul relacije

participiranje sa obe strane totalno, onda se formira samo jedna relacija za oba entiteta i vezu. Atributi relacije su atributi oba entiteta i veze a ključevi entiteta su kandidat za ključ relacije.

Ako je kardinalnost veze 1:N a: participiranje sa strane N totalno, onda se ta veza ne prevodi u posebnu relaciju

već se atributi veze i entiteta sa strane 1 dodaju kao atributi relaciji koja odgovara entitetu sa strane N. Primer:Proizvod (br_proizvoda*, naziv, materijal, količina, br_mašine)

participiranje sa strane N parcijalno , onda ta veza postaje posebna relacija. Atributi relacije su atributi veze i ključevi entiteta koji učestvuju u vezi a kandidat za ključ je ključ entiteta sa strane N.

Ako je kardinalnost veze M:N onda se veza uvek predstavlja novom relacijom. Atributi su atributi veze i ključevi entiteta koji učestvuju u vezi a primarni ključ se formira od svih ključnih atributa. Primer:

Pravi ( (jmbg, br_proizvoda)*, poč_vreme, zavr_vreme)

Kada sve ovo uzmemo u obzir, relacione sheme za mašinsku radionicu su:

Radnik (jmbg*, ime, plata)Mašina (br_mašine*, naziv, detalji)Proizvod ( br_proizvoda*, br_mašine, naziv, materijal, količina )Pravi ( (jmbg, br_proizvoda)*, poč_vreme, zavr_vreme)Upravlja ( (jmbg, br_mašine)*, maš_vreme)

6. Skoro da smo završili... Četvrti korak – prerađivanje sheme

Prerađivanje sheme se sastoji iz normalizacije relacija dobijenih logičkim projektovanjem. Prostije rečeno, kada dobijemo relacije na osnovu ER dijagrama treba da proverimo da li su bar u 3NF i ako ima nekih koje nisu treba da ih dekomponujemo do relacija u 3NF ako ne i do BCNF. Od dekompozicije relacija na osnovu normalnih formi dobijamo oslobađanje relacija od dupliranih podataka i smanjivanje slučajnih gubitaka podataka i grešaka u bazi. Za početak ćemo objasniti četiri normalne forme – prvu, drugu, treću i BCNF (Boyce-Codd Normal Form).

Za relaciju kažemo da je u prvoj normalnoj formi (1NF) ako svi njeni atributi imaju samo atomske (nedeljive) vrednosti. Praktično, svaka relacija po svojoj definiciji zadovoljava 1NF jer je atomičnost promenljiva od slučaja do slučaja. Npr. u nekim slučajevima bi datum bio atomična vrednost dok u nekom drugom slučaju ne bi i tada bi ga podelili na

9

dan, mesec i godinu. Sve zavisi od potrebe. Zato ćemo pod atomskim vrednostima smatrati sve koje nisu liste ili skupovi.

Da bi relacija bila u 2NF treba da bude u 1NF i da atributi koji ne pripadaju ključu u potpunosti funkcionalno zavise od primarnog ključa tj. atributa koji ga čine. Funkcionalna zavisnost od primarnog ključa znači da svaka vrednost atributa koji nije ključ je jedinstveno određena vrednošću primarnog ključa. Funkcionalna zavisnost se označava strelicom →. Ako relacija nije u 2NF, onda je dekompozicijom relacije dovodimo do 2NF tako što pravimo novu relaciju na osnovu svake suvišne funkcionalne zavisnosti. Nove relacije kreiramo na osnovu svih atributa iz funkcionalne zavisnosti s tim što desna strana predstavlja primarni ključ. Pritom se iz početne relacije eliminišu se desne strane suvušnih funkcionalnih zavisnosti. Recimo da imamo relaciju maš_radionica:

maš_radionica (br_mašine*, naziv_mašine, detalji_mašine, br_proizvoda*, naziv_proizvoda, materijal, količina, jmbg*, ime_radnika, plata, maš_vreme)

Ova relacija je u 1NF. Recimo da važe funkcionalne zavisnosti:

FZ1 br_mašine → naziv_mašine, detalji_mašine, FZ2 br_proizvoda → naziv_proizvoda, materijal, količinaFZ3 jmbg → ime_radnika, plataFZ4 materijal → količina

Relacija maš_radionica nije u 2NF jer zbog funkcionalnih zavisnosti FZ1, FZ2. FZ3 je narušena potpuna zavisnost atributa od primarnog ključa, jer se atributi koji čine ključ javljaju u ovim funkcionalnim zavisnostima sa leve strane. Stoga ćemo izvršiti dekompozicije prema ovim funkcionalnim zavisnostima.

mašina (br_mašine*, naziv_mašine, detalji_mašine)proizvod (br_proizvoda*, naziv_proizvoda, materijal, količina)radnik (jmbg*, ime_radnika, plata)

Iz početne relacije eliminišemo desne strane funkcionalnih zavisnosti FZ1, FZ2 i FZ3:

maš_radionica2 (br_mašine*, jmbg*,br_proizvoda*, maš_vreme)

Relacija je u 3NF ako je u 2NF i ako atributi koji ne pripadaju ključu ne zavise tranzitivno od atributa ključa. Prostije rečeno, ne ključni atributi treba da zavise od ključa i da budu međusobno nezavisni. Ako relacija nije u 3NF onda je dekompozicijom dovodimo do 3NF slično kao za 2NF. Proverimo da li su dobijene relacije u 3NF. Relacije radnik, mašina i maš_radionica2 jesu jer u njima nema tranzitivnih zavisnosti dok relacija proizvod nije jer br_mašine tranzitivno pokazuje na atribut količina preko atributa materijal (FZ4) pa se vrši dekompozicija prema funkcionalnoj zavisnosti FZ4 i brišemo atribute sa desne strane iz relacije mašina i tako dobijamo relacije:

10

proizvod2 (br_proizvoda*, naziv_proizvoda, materijal)namirnice (materijal*, količina)

Sada su sve relacije u 3NF. Relacija je prilično u zadovoljavajućem stanju kada je u 3NF mada se mogu javiti još neke anomalije baze podataka koji se eliminišu BCNF normalizacijom. Potreba za BCNF normalizacijom se javlja kada u relaciji ima ciše kandidata za ključ. Za relaciju kažemo da je u BCNF ako su sve leve strane funkcionalnih zavisnosti kandidati za primarni ključ. Sve dobijene relacije su u BCNF. Ako ne bi bile izvršili bismo dekompoziciju kao i do sad.

Ali treba voditi računa pri dekompoziciji jer nisu sve dekompozicije dobre. Za dekompoziciju kažemo da je dobra ako važi da su zajednički atributi dekomponovanih relacija u bar jednoj relaciji ključ i da sve početne funkcionalne zavisnosti i dalje važe ili se mogu izvesti iz postojećih funkcionalnih zavisnosti. Ako dekompozicija nije dobra onda je ne treba izvoditi.

S obzirom da znamo da normalizujemo relaciju, sada možemo preći na prerađivanje sheme. Već je rečeno da se prerađivanje sheme sastoji u proveri da li su dobijene relacije u 3NF ili u BCNF. Proučavajući relacije dobijene logičkim projektovanjem moćemo redom uočiti sledeće funkcionalne zavisnosti:

br_mašine → naziv_mašine, detalji_mašinebr_proizvoda → br_mašine, naziv_proizvoda, materijal, količinajmbg → ime_radnika, platajmbg, br_proizvoda → poč_vreme, zavr_vremejmbg, br_mašine → maš_vreme

Neključni atributi zavise samo od primarnog ključa odgovarajuće relacije, tako da nema neključnih funkcionalnih zavisnosti pa samim tim ni tranzitivnih zavisnosti i sve leve strane su kandidati za ključ. Stoga su sve relacije u BCNF i nema potrebe za prerađivanjem sheme.

7. Za kraj... Peti korak - fizičko projektovanje baze

Ostalo je jos da se odlučimo za način predstavljanja podataka na disku ali prvo da se podsetimo osnovnih pojmova vezanih za disk – spoljašnju memoriju. Dakle, spoljašna memorija se sastoji od stranica koje su fiksne dužine i svaka stranica ima svoju adresu. U okviru jedne stranice smešta se više zapisa. Za svaki zapis je poznata adresa zapisa koja se sastoji od adrese stranice i pomaka unutar nje i razlikujemo ih prema vrednosti primarnog ključa. Vraćamo se na temu, zašto je uopšte bitna fizička organizacija?Fizička organizacija je vrlo važna jer je vreme pristupa disku mnogo veće od vremena pristupa unutrašnjoj memoriji i stoga se moraju izabrati odgovarajuće strukture podataka za predstavljanje svake relacije.U fizičkom smislu, baza podataka je skup datoteki gde se

11

svaka relacija prikazuje jednom datotekom a svaka n - torka relacije jednim zapisom u datoteci. Osnovne operacije nad datotekom su:

ubaciti novi zapis obrisati postojeći zapis ažurirati postojeći zapis naći zapis (zapise) u kojima zadati podaci imaju zadate vrednosti.

Sve operacije sa bazom se svode na osnovne operacije sa datotekom.Datoteke se mogu podeliti prema metodi adresiranja zapisa tj načinu fizičke organizacije zapisa i to na: sekvencijalne datoteke, indeksne datoteke i direktne datoteke.

7.1 Sekvencijalna organizacija

Kod sekvencijalne organizacije se zapravo radi o odsustvu bilo kakve organiziacije u datoteci. Zapisi se ubacuju u datoteku redom. Iako pogodna za ubacivanje i brisanje zapisa, pretraga nije jača strana ove organizacije. Traženje zapisa sa odgovarajućom vrednošću ključa zahteva čitanje svih podataka iz datoteke redom tj. u proseku pola datoteke za uspešno i cela za neuspešno, što nije pogodno za velike datoteke. U slučaju da je datoteka sortirana situacija je nešto bolja jer se ne mora pretražiti cela datoteka da bi zaključili da traženi zapis ne postoji. Prednost ove organizacije je jednostavnost i ekonomičnost u zauzimanju memorijskog prostora.

7.2 Direktne datoteke

Kod direktne organizacije nema sortiranja datoteke, redosled zapisa je nebitan i ključ služi za određivanje adrese. Preciznije, uz pomoć heš funkcije h(k) se vrši transformacija vrednosti ključa k da bi se dobila adresa zapisa. Heš funkcija treba da je jednostavna a da pritom ne preslikava dva različita ključa u istu adresu tj. ne treba da dođe do kolizije. U praksi je gotovo nemoguće naći ovakvu funkciju. Za heš funkciju se najčešće uzima moduo tj. h(k) = k mod M. Najmanji broj kolizija se dobija kada je M prost broj malo veći od raspoloživog adresnog prostora. Kao funkcija transformacije se još koristi i metoda kvadriranja ključa i uzimanja nekoliko centralnih cifara za vrednost funkcije. Ali šta kada dođe do kolizije? U slučaju kolizije generalno se primenjuju dve tehnike. Prva podrazumeva da kada dobijemo dupliranu adresu primenjujemo neku novu funkciju r(k) sve dok ne dobijemo slobodnu adresu. Najjednostavnija funkcija r(k) je ri+1(k) = ri(k) gde je r1(k) = h(k) + 1. Druga tehnika se sastoji od ulančavanja zapisa (povezanim listama) za koje je dobijena ista adresa. Za smeštanje ulančanih adresa može se rezervisati i dodatni memorijski prostor da ne bi došlo do dodatnih kolizija.Pretraživanje se vrši tako što se proveri da li se na adresi koja je vrednost funkcije h(k) nalazi traženi zapis. Ako ne, primenjuje se izabrana tehnika rešavanja kolizije dok se ne pronađe traženi zapis ili ustanovi da ga nema. Ove datoteke su posebno pogodne za pretraživanje po jednakosti ali ne i po opsegu. Takođe, pretraga cele datoteke podataka je sporija nego kod ostalih tipova datoteka

12

Ažuriranje direktnih datoteka je jednostavno jer se promenjeni zapis upisuje na istu memorijsku lokaciju. Pri brisanju moramo biti pažljivi ako je za rešavanje kolizije korišćeno ulančavanje.Prednost direktne datoteke je brz pristup a mana je neekonomičnost jer se često javljaju prazne lokacije u memoriji.

7.3 Indeksne datoteke

U indeksnoj organizaciji pored datoteke podataka postoji i mala pomoćna datoteka koja se naziva indeks (indeksna datoteka) i sastoji se od ključeva i njihovih adresa. Postoje dva tipa indeksa – grupisani i negrupisani. Kada je datoteka organizovana tako da poredak zapisa odgovara poretku indeksa kažemo da se radi o grupisanim indeksima. U suprotnom za indekse kažemo da su negrupisani. Jedna datoteka može imati jedan grupisani indeks i više negrupisanih.Indeksnu datoteku je potrebno brzo pretraživati pa je najefikasnije da se organizuje kao direktna datoteka. Za poboljšanje performansi možemo uvesti više indeksa i tada je pretraživanje efikasnije ali se problemi javljaju kod ažuriranja, ubacivanja i izbacivanja zapisa jer se mora izvršiti korekcija i u svim indeksima. Indeksi koji olakšavaju pristup na osnovu primarnog ključa se nazivaju primarni indeksi dok su ostali sekundarni indeksi. Najčešće korišćena varijanta datoteke sa indeksom je indeks-sekvencijalna datoteka ali se koristi i indeks-direktna datoteka.

7.3.1 Indeks-sekvencijalna datoteka

Kod indeks-sekvencijalne organizacije sortiranu datoteku sa podacima delimo na blokove sa jednakim brojem zapisa. U indeksnu datoteku se smešta najveći ključ iz svakog bloka zajedno sa adresom ključa (retki indeks). Pretraživanje počinje traženjem indeksa koji je jednak ili veći od traženog. Kada se pronađe takav ključ onda se preko adrese ključa pristupa odgovarajućem bloku. Optimalna vrednost za k je gde je n ukupan broj zapisa u datoteci podataka. Kada je broj blokova veliki, pretraživanje je neefikasno pa se tada može formirati nova indeksna datoteka koja će da indeksira staru indeksnu datoteku i ovaj indeks se naziva sporedan indeks. Problem sa indeksnim datotekama je unošenje novih zapisa jer se može desiti da u bloku nema mesta. Jedno rešenje je pomeranje zapisa da bi se napravilo mesta za nov zapis što ima za posledicu pomeranje indeksa a to je skupo i nepraktično. Drugo rešenje je smeštanje zapisa u posebno izdvojen prostor ali se tada umanjuju performanse pretraživanja. Slični problemi se mogu javiti i pri izbacivanju zapisa iz datoteke. Kod ažuriranja ne sme se menjati vrednost ključa jer bi se time promenio položaj zapisa u sortiranom redosledu.

7.3.2 Indeks-direktna datoteka

Kod indeks-direktne organizacije zapisi u datoteci podataka mogu biti upisani u proizvoljnom redosledu. Sada se indeks (tzv. gusti indeks) dodaje svakom zapisu a

13

datoteka sa indeksima je sortirana po ključu. Kao i kod indeks-sekvencijalne datoteke mora se ažurirati indeks pri ubacivanju i izbacivanju zapisa. Ažuriranje vrednosti ključa je moguće ali zahteva jedno izbacivanje i ubacivanje u indeksu. U odnosu na indeks-sekvencijalnu organizaciju mana je veći indeks ali prednost je jednostavnije ubacivanje i izbacivanje zapisa jer datoteka podataka nije sortirana. Takođe, možemo proveriti da li postoji neka vrednost ključa bez čitanje datoteke podataka.

7.4 B-stabla

Indeksna datoteka je često velika, pogotovu kada se radi o gustom indeksu. Da bi pretraživanje indeksa bilo što efikasnije, indeksi se organizuju u B-stabla. B-stablo reda m je stablo za koje važi:

koren je ili list ili ima bar dva potomka svi unutrašnji čvorovi imaju bar ⌈m/2⌉ a najviše m potomaka listovi imaju najmanje ⌈m/2⌉-1 ključeva a najviše m – 1 ključ sve putanje od korena do listova imaju istu dužinu svaki unutrašnji čvor ima naizmenično podstabla i ključeve a počinje i završava se

podstablom. Ključevi su raspoređeni u rastućem redosledu i ima ih za jedan manje od potomaka. Svakom ključu je pridruženo podstablo sa desne strane. Ključevi u podstablu koje odgovara ključu k su veći ili jednaki ključu k.

svaki list sadrži parove ključeva i adresa zapisa koji su sortirani po ključevima, s tim što list ne mora biti potpuno popunjen. Jednom zapisu datoteke odgovara tačno jedan par ključ-adresa

Pretraživanje B-stabla se obavlja tako što se u trenutnom čvoru ispistuje da li postoji traženi ključ. Ako postoji, pretraga je završena. U suprotnom, prelazimo na pretragu u podstablu koje je pridruženo prvom ključu koji je veći od traženog. Ako takav ključ ne postoji onda pretragu nastavljamo u podstablu koje je pridrućeno najvećem podključu (tj. poslednjem podključu). Ovaj postupak se nastavlja dok ne dodjemo do nekog lista u kome onda tražimo zadati ključ.

Kod umetanja u B-stablo najpre pokušamo da ga umetnemo u odgovarajući list (koji pronađemo pretraživanjem) tako da ne pokvarimo poredak. Ako ima mesta u listu, ubacivanje je završeno. U suprotnom dolazi do preloma lista. Formira se rastući niz od m ključeva i ključevi od 1 do ⌈m/2⌉-1 se zadrže u starom listu, a preostali ključevi se prebace u novi list s tim što ključ ⌈m/2⌉ umetnemo u roditelja starog lista po ovom postupku. U slučaju da tokom postupka dođe do preloma korena, visina drveta će biti povećana za 1.

Slično je i sa izbacivanjem, dakle moramo voditi računa i korigovati sve potrebne vrednosti. Najpre pretragom nalazimo list koji sadrži traženi ključ i izbacujemo ga zajedno sa odgovarajućom adresom zapisa. Ako je to prvi zapis u listu, moramo korigovati vrednost ključa u roditeljskom čvoru, ako je to bila i jedina vrednost u listu onda taj list jednostavno isključujemo. U slučaju da se ključ nalazi u listu koje je prvi potomak, korekcija se vrši u nekom od predaka roditeljskog čvora. Pri isključivanju

14

listova vodimo računa o minimalnom broju listova. Ako nema dovoljno listova onda uzimamo list iz susednog čvora i to ako u tom čvoru ima bar jedan više list od minimalnog broja listova. Naravno, nakon toga izvršićemo potrebne korekcije u ključevima. U slučaju da je broj u oba susedna čvora minimalan odaberemo jedan od ta dva čvora i spojimo ga sa središnjim čvorom. Tako ćemo dobiti čvor sa 2*⌈m/2⌉ - 1 što je manje od m. Sada još ostaje da izbacimo vrednost ključa za čvor sa kojim smo spajali upravo opisanom procedurom. Posledice izbacivanja se mogu proširiti sve do korena što dovodi do spajanja potomaka korena i smanjivanja visine stabla za 1.

Glavna prednost B-stabla nad ostalnim indeksnim strukturama je brzina pristupa podacima kao i jeftino održavanje (sem umetanja). Možemo da primetimo da se broj slojeva indeksa dinamički menja što je i prednost u odnosu na indeks-sekvencijalnu organizaciju tako da nema suvišne reorganizacije. Brzina pristupa podacima je skoro jednako brza kao kod direktne organizacije ali zato kod B-stabla imamo imamo očuvan sortirani redosled.

Pored B-stabla koriste se i dve njegove modifikacije B*-stabla i B+-stabla. B*-stablo je nastalo kao posledica skupog preloma listova kod umetanja . Ideja je da se prelom lista odloži što je više moguće. Inače, u odnosu na B-stabla, kod B*-stabla reda m

svaki unutrašnji čvor ima (2*m-1)/3 podstabala dok koren ima od 2 do 2⌊(2m -2)/3⌋+1

podstabala i kada treba izvršiti prelom lista, vrši se prelivanje kao kod izbacivanja iz B-stabla, ako je moguće. Veći deo operacija je identičan onim kod B-stabla, još se razlikuje izbacivanje iz B*-stabla jer se po potrebi vrši prelivanje 3 čvora u 2. Ovim dobijamo efikasnije operacije, manju visinu i bolju popunjenost B*-stabla u odnosu na B-stablo.

Varijanta B-stabla za indeks-sekvencijalnu organizaciju je B+-stablo. Razlika B+-stabla u odnosu na B-stablo je što se podaci skladište samo u listovima i to u ulančanoj listi prema poretku ključeva. U unutrašnjim čvorovima ima najviše m , a najmanje ⌊m /2⌋ podstabala dok u listovima ima najmanje ⌊m /2⌋ a najviše m ključeva. U odnosu na B-stablo bitno se razlikuje samo operacija pretraživanja jer je sada pristup sekvencijalan.

Sada smo upoznati sa različitim organizacijama podataka na disku. Svaka organizacija ima određene prednosti i mane u odnosu na ostale organizacije stoga treba u zavisnosti od konkretnog slučaja izabrati pravu. Prvo što treba ustanoviti jesu upiti za koje pretpostavljamo da će najviše biti korišćeni. Vratimo se na slučaj mašinske radionice. Na početku smo pomenuli da su nam od interesa radnici sa njihovim osnovnim podacima. Pretraživanje radnika se vrši prema matičnom broju koji je ključ za tabelu Radnik, stoga ćemo relaciju Radnik predstaviti direktnom datotekom da bi maksimalno ubrzali pretraživanje preko atributa jmbg.Svakodnevno vlasnik proverava određene radnike da li revnosno rade svoj posao tako što proveri koliko su proizvoda proizveli u toku tog dana. Ovo je takođe pretraživanje prema jmbg-u ali uključuje pretragu prema opsegu za početno i završno vreme. Zato se odlučujemo da relaciju Proizvodi predstavimo kao indeksnu datoteku sa indeksom (poč_vreme, zavr_vreme) organizovanim u B+ stablo.

15

Kada završimo sa najčešće izvršavanim pretraživanjima treba odrediti najčešće izvršavana ubacivanja i ažuriranja.U relaciju Proizvodi se vrlo često ubacuju novi zapisi jer proizvodnja jednog proizvoda ne traje dugo a radionica ima puno mašina. Idealno bi bilo kreirati indeks organizovan u B*stablo, ali nad relacijom Proizvodi već postoji B+ indeks odgovara i u ovom slučaju.Vreme koje radnik provede za mašinom se menja više puta dnevno. Da bi se ovo izvršilo treba prvo pronaći odgovarajućeg radnika i mašinu zato se i relacija Upravlja predstavlja direktnom datotekom.

U suštini, indeks kreiramo samo ako postoji stvarna potreba za njim i pokušavamo da što više upita ubrzamo jednim indeksom. Kandidati za indekse su oni koje bismo naveli u WHERE klauzuli upita. Kada tražimo konkretnu vrednost atributa onda je najbolje rešenje heš indeks tj. direktna datoteka. Ako se radi o opsegu vrednosti onda najviše odgovara B+-stablo. Ako je potreban indeks nad više atributa, treba voditi računa o redosledu atributa jer se prvo vrši sortiranje prema prvom navedenom atributu. Za ubacivanje novih zapisa je najpogodniji B* indeks ali odgovara bilo koja vrsta B-indeksa. Za relacije koje se često ažuriraju treba proveriti da li indeksi nad njima usporavaju ažuriranje. Ako indeks usporava ažuriranje onda ga ne treba praviti. Treba razmotriti denormalizaciju i dodatno deljenje relacija ako bi to poboljšalo performanse baze.

16

Literatura:[1] Ramakrishnan R., Gehrke J.: Database Management Systems, 2nd Edition. McGraw-Hill

17