Upload
andjeo-gabriel
View
83
Download
10
Embed Size (px)
DESCRIPTION
Osnove baza podataka
Citation preview
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
1
BAZE PODATAKA
P R I N C I P I
Prof. dr Rade Tanjga
Banja Luka, mart 2013.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
2
1. Modeli podataka
Model podataka je matematička apstrakcija koja se koristi za projektovanje realnog sistema.
Modela podataka treba da omogući izgradnju odgovarajućeg informacionog sistema i njegove
baze podataka. U tom cilju model realnog sistema treba da obezbjedi informacije o:
statičkim osobinama,
ugraĎenim ograničenjima i
dinamičkim osobinama
realnog sistema.
Statičke osobine su relativno nezavisne od vremena. Rijetko se mijenjaju. Nose informacije o
strukturi buduće baze podataka.
Ograničenja govore o pravilima ponašanja i poslovanja u realnom sistemu. TakoĎe, ograničenja
govore o dozvoljenim i nedozvoljenim vrijednostima podataka i dozvoljenim i nedozvoljenim
odnosima izmeĎu podataka o komponentama stanja realnog sistema. Ta oraničenja treba da se
preslikaju u uslove integriteta buduće baze podataka. Uslovi integriteta su mehanizmi, koji
obezbjeĎuju da podaci o komponentama stanja realnog sistema, u bazi podataka, budu usaglašeni
sa ograničenjima realnog sistema.
Dinamičke osobine ukazuju na evolutivnu prirodu realnog sistema. Odslikavaju promjene u
realnom sistemu. Te promjene se reflektuju putem izmjene podataka o komponentama stanja
realnog sistema. Da bi baza podataka predstavljala što vjerniju sliku realnog sistema, moraju se
definisati operacije, koje će dovoditi sadrţaj baze podataka u saglasnost sa aktuelnim podacima o
komponentama stanja realnog sistema. Strukture nad skupom tih operacija predstavljaju
programe. Ti programi mijenjaju bazu podataka saglasno promjenama u realnom sistemu.
Primjer 1.1.
Podatke o komponentama stanja fakulteta, kao realnog sistema, predstavljaju:
broj upisanih studenata,
podaci o svakom studentu posebno,
podaci o nastavnicima,
podaci o nastavnom planu i programu i predmetima,
podaci o povjeravanju realizacije nastave iz pojedinih predmeta,
ocjene studenata iz pojedinih predmeta i slično.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
3
Definicija 1.1.:
Model podataka M je matematička apstrakcija, izraţena trojkom (S, I, O) gdje je S –
Strukturalna, I – integritetna a O – operacijska komponenta modela.
1.1. Srukturalna komponenta modela podataka
Strukturalna komponenta modela podataka sadrţi skup primitivnih koncepata i skup pravila za
izgradnju sloţenijih koncepata. Sloţeniji koncepti se grade od primitivnih.
Koncept je apstraktna predstava jedne klase dijelova realnog svijeta. Taj dio realnog svijeta moţe
biti:
skup sličnih subjekata ili neki konkretan subjekt,
skup sličnih objekata ili neki konkretan objekt,
skup sličnih dogaĎaja ili neki konkretan dogaĎaj,
zajednička osobina svih elemenata jednog skupa ili konkretna vrijednost osobine,
veza (relacija) izmeĎu dva skupa ili dva konkretna elementa nekih skupova.
U daljem tekstu će se realni subjekti, objekti i dogaĎaji nazivati činiocima ili entitetima.
Primtivni koncept je takav koncept koji se ne moţe dalje dekomponovati na koncepte.
Primjer 1.2.:
U graĎevinarstvu primitivne koncepte predstavljaju: pijesak, voda, cement, kreč. Od njih se
grade sloţeniji koncepti, kao što su: betonske grede, temelji, zidovi, kuće, gradovi i sl.
U modelima podataka, primitivne koncepte mogu predstavljati:
opis osobine skupa entiteta i
skup konkretnih vrijednosti te osobine.
Od njih se grade sloţeniji koncepti, kao što su: opis skupa činilaca, opisi njihovih veza i opis
baze podataka.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
4
Koncepti i pravila za njihovu izgradnju se koriste za izradu dvije vrste modela. Jedno su modeli
skupova entiteta. Izgradnja modela skupova entiteta se, najčešće, vrši navoĎenjem naziva skupa
i bitnih zajedničkih osobina elemenata skupa. Drugo su modeli konkretnih entiteta. Njihovi
modeli se grade navoĎenjem konkretnih vrijednosti zajedničkih osobina upotrebljenih za
izgradnju modela odgovarajućeg skupa entiteta, jer svaki entitet pripada nekom skupu entiteta.
Primjer 1.3.:
Na fakultetu, kao realnom sistemu, entiteta predstavljaju: skup studenata, skup predmeta, skup
nastavnika, skup učionica, i drugi. Jedan apstraktni model skupa studenata bi mogao biti:
Student (BRI, IME, PRZ, BPI)
gdje je Student naziv skupa, a BRI – broj indeksa, IME – ime studenta, PRZ – prezime studenta,
BPI – broj poloţenih ispita, predstavljaju opise zajedničkih osobina svih studenata.
Model jednog studenta, kao konkretnog entiteta fakulteta, sad bi mogao biti:
(159, Marko, Jovanović, 13)
Apstraktni model skupa predmeta bi mogao biti:
Predmet (OZP, NAP)
gdje OZP – oznaka predmeta i NAP – naziv predmeta predstavljaju opise zajedničkih osobina
svih predmeta.
Entiteti su u realnom sistemu meĎusobno povezani na razne načine. Da bi se u model statičkih
osobina realnog sistema ugradila informacija o tim vezama, uvode se relacije (veze) u skup
modela skupova entiteta, ili se relacije uvode izmeĎu modela samih entiteta. I za opisivanje tih
relacija se koristi notacija, slična notaciji za predstavljanje modela skupova entiteta i modela
konkretnih entiteta. Tako se dolazi do dvije vrste struktura. Jedno su strukture nad skupom
modela skupova entiteta, a drugo su strukture nad skupom modela samih entiteta realnog
sistema. Te strukture predstavljaju dva modela statičkih osobina realnog sistema definisana na
dva nivoa apstrakcije. Struktura nad skupom modela skupova entiteta je na višem nivou
apstrakcije od strukture nad skupom modela samih entiteta.
Primjer 1.4.:
Kao model relacije izmeĎu skupa studenata i skupa predmeta, moţe posluţiti sljedeća dvojka:
Sluša (Student, Predmet)
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
5
Taj je koncept na nivou apstrakcije modela skupova entiteta. Model veze izmeĎu konkretnog
studenta i predmeta bio bi:
((159, Marko, Jovanović, 13), (p1, Informatika)).
U vezi sa strukturalnom komponentom modela podataka, često se koriste dva pojma. To su
intenzija i ekstenzija. Pojam intenzije se koristi za definicioni opis nekog skupa. Intenzija
definiše skup navoĎenjem uslova koje njegovi elementi treba da zadovolje. Pojam ekstenzije se
odnosi na prikaz jedne od mogućih pojava skupa nabrajanjem elemenata. Intenzija je
generalizacija skupa ekstenzija. Definiše sve zajedničke osobine svojih ekstenzija.
Predstavljanje ekstenzije je samo detaljnija ilustracija modela statičke strukture realnog sistema.
Ona dopunjava, putem primjera ograničenog obima, rješenje definisano preko intenzionalnog
opisa statičke strukture.
Primjer 1.5.:
Model skupa entiteta i jedan skup modela konkretnih entiteta predstavljaju, redom, intenziju i
ekstenziju. Modela skupa entiteta opisuje osobine svakog skupa modela svojih eelemenata
(pojedinačnih entiteta).
Konkretno, model skupa entiteta Student, kao intenzija, opisuje osobine ekstenzijalnog modela
(159, Marko, Jovanović, 13), koji prezentuje realnog studenta Marka Jovanovića. Baza podataka
sadrţi skupove ovakvih modela realnih entiteta, a kardinalni broj svakog skupa modela odgovara
kardinalnom broju odgovarajućeg skupa realnih entiteta. Drugim riječima, baza podataka sadrţi
model svakog realnog entiteta.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
6
1.2. Integritetna komponenta modela podataka
Svaki sistem posjeduje skup pisanih i običajnih pravila ponašanja ili pravila poslovanja. Ta
pravila se izraţavaju putem:
ograničenja mogućih vrijednosti odreĎenih zajedničkih osobina nekog skupa entiteta,
ograničenja veza izmeĎu dva ili više konkretnih entiteta i
ograničenja odnosa izmeĎu realnog entiteta i njemu pridruţene vrijednosti zajedničke
osobine.
Primjer 1.6.:
U nekom trgovinskom preduzeću, moguća ograničenja su:
podatak o zalihi robe ne moţe imati negativnu vrijednost (ograničenje vrijednosti
osobine),
popust ne moţe biti manji od 0 i veći od 10% (ograničenje vrijednosti osobine),
otpremnica mora imati bar jednu stavkusa robom (ograničenje odnosa izmeĎu dva
entiteta),
sva roba na jednoj otpremnici mora biti iz istog skladišta (ograničenje veze izmeĎu dva
entiteta, otpremnice i skladišta),
svaka roba ima jedninstvenu identifikacionu oznaku, a jedna identifikaciona oznaka se
pridruţuje najviše jednoj robi (ograničenje odnosa izmeĎu realnog entiteta i vrijednosti
zajedničke osobine).
Na fakultetu, pravila ponašanja mogu diktirati sljedeća ograničenja:
ocjena je cijeli broj ne manji od 5 i ne veći od 10 (ograničenje vrijednosti osobine),
ocjena manja od 6 se ne evidentira (ograničenje vrijednosti osobine),
jedan student moţe imati najviše jednu ocjenu iz jednog predmeta (ograničenje veze
izmeĎu tri entiteta: student, ocjena, predmet),
jedan nastavnik moţe predavati više predmeta, a jedan predmet moţe izvoditi više
nastavnika (ograničenje veze izmeĎu dbva entiteta: nastavnik, predmet),
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
7
svaki student ima jedan broj indeksa, a jedan broj indeksa se dodjeljuje najviše jednom
studentu (ograničenje odnosa izmeĎu realnog entiteta i vrijednosti zajedničke osobine).
Fraza „jedan nastavnik moţe predavati više predmeta, a jedan predmet moţe izvoditi više
nastavnika“ predstavlja pravilo ponašanja u realnom sistemu, pa prema tome i ograničenje, ali ne
tako strogo kakvo bi bilo ograničenje „jedan nastavnik moţe predavati najviše jedan predmet“.
Baza podataka informacionog sistema treba da bude usaglašena sa pravilima ponašanja u
realnom sistemu. Zato se ograničenja, u postupku projektovanja baze podataka, izraţavaju putem
pogodne notacije, a zatim ugraĎuju u bazu podataka, prilikom njene realizacije. Ograničenja,
definisana u postupku projektovanja baze podataka, nazivaju se i uslovima integriteta baze
podataka. Uslovi integriteta baze podataka ograničavaju broj dozvoljenih sadrţaja baze podataka.
Primjer 1.7.:
Jedna od mogućih notacija za ograničenje vrijednosti neke osobine A na interval vrednosti [a1,
a2] je a1 A a2.
Notacija ( X(0,1):Y(1,N )) moţe se interpretirati na sljedeći način:
jedan realni entitet iz skupa X mora biti povezan sa najmanje jednim entitetom iz skupa
Y i
jedan realni entitet iz skupa Y moţe biti povezan sa najviše jednim entitetom iz skupa X.
Ova interpretacija relativno precizno opisuje uslove povezivanja entiteta iz dva skupa.
Ako su S, P i O osobine, tada se notacija SP O moţe upotrebiti u cilju iskazivanja pravila da
svakoj kombinaciji SP vrednosti odgovara najviše jedna O vrijednost.
Definicija 1.2.:
Za bazu podataka, čiji je sadrţaj u saglasnosti sa svim definisanim uslovima integriteta, kaţe se
da je konzistentna (neprotivrječna).
Primjer 1.8.:
Baza podataka, u koju su ugraĎena ograničenja iz primjera 1.7, je konzistentna, ako:
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
8
ne sadrţi a0 < a1 ili a3 > a2 vrijednost za osobinu A,
ne sadrţi podatke o entitetu x iz X, koji nije povezan sa podacima o bar jednom entitetu y
iz Y.
ne sadrţi podatke o vezi entiteta y iz Y sa više entiteta iz X i
ne sadrţi takvu kombinaciju SP vrijednost, koja je povezana sa više od jedne O
vrijednosti.
Skup koncepata i skup pravila strukturalne komponente i skup uslova integriteta se koriste za
definisanje modela statičke strukture realnog sistema. Na osnovi modela, definisanog putem
opisa skupova entiteta realnog sistema, gradi se baza podataka informacionog sistema. Baza
podataka se nalazi na medijumima eksternih memorijskih ureĎaja računarskog sistema. Sadrţi
dozvoljene podatke o stanju realnog sistema i podatke o dozvoljenim vezama izmeĎu entiteta
realnog sistema. Nedozvoljene vrijednosti osobina i nedozvoljene veze, isključuju se iz baze
podataka putem ograničenja. Svakom stanju realnog sistema odgovara jedna pojava baze
podataka. Pojava baze podataka odreĎena je trenutnim vrijednostima podataka i veza, izmeĎu tih
podataka.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
9
1.3. Operacijska komponenta modela podataka
Dinamiičke osobine realnog sistema opisuju se putem skupa operacija O. Operacija oO
izvršava se na pojavi baze podataka. Skup operacija O odgovara skupu naredbi takozvanog
jezika za manipulisanje podacima. Svaka operacija oO predstavlja funkciju u skupu stanja D =
{di/i=1,...,n}baze podataka, tj. o:DD. Pri tome, funkcija o ne mora biti definisana na cijelom
skupu D, jer rezultat njene primjene moţe dovesti do kolizije sa definisanim skupom
ograničenja. Tada se operacija o ne izvršava, proglašava se nedefinisanom.
Ne mijenja svaka operacija O pojavu baze podataka, ali mijenja njeno stanje. Naime, pored
podataka, baza podataka sadrţi i niz kontrolnih mehanizama ili indikatora. Vrijednosti ovih
indikatora i pojava baze podataka čine stanje baze podataka. Najkarakterističniji kontrolni
mehanizam predstavlja tzv. indikator tekućeg sloga (dalje: indikator aktuelnosti). Vrijednost
indikatora aktuelnosti često predstavlja adresa lokacije sloga, kojem se posljednje pristupilo. Taj
slog se naziva tekućim slogom.
Primjer 1.9.:
Posmatra se indeks-sekvencijalna datoteka i naredba tipa ČITAJ NAREDNI SLOG. Trenutno
stanje datoteke prije izvršenja naredbe, odreĎeno je podacima u datoteci (pojava) i sadrţajem
indikatora aktuelnosti. Indikator aktuelnosti sadrţi adresu sloga kojem se posljednje pristupilo.
Izvršenje operacije ne mijenja pojavu datoteke, ali mijenja sadrţaj indikatora aktuelnosti, a time i
stanje datoteka, jer sada adresa narednog sloga predstavlja sadrţaj indikatora aktuelnosti.
Kada se operacije izvrţavaju na bazi podataka, po pravilu se odnose na njen relativno mali dio.
Izbor relativno malog dijela baze podataka naziva se selekcijom. Na današnjem stepenu razvoja
računarske tehnike, pojam selekcije podrazumijeva prenos tog dijela baze podataka sa eksterne
na operativnu memoriju.
Operacija se najčešće sastoji iz dva dijela. U prvom se definiše aktivnost a u drugom selekcija.
Selekcija bira dio baze podataka na kojem treba da se izvrši aktivnost. U osnovi postoji pet
aktivnosti i to:
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
10
definisanje vrijednosti indikatora aktuelnosti, koje se naziva i definisanjem logičkog
mjesta u strukturi podataka,
čitanje podataka,
upis novih podataka,
brisanje postojećih podaka,
modifikacija postojećih podataka.
Selekcija dijela baze podataka moţe se vršiti uz pomoć:
logičkog mjesta u strukturi podataka (vrijednosti indikatora aktuelnosti),
odnosa izmeĎu podataka,
vrijednosti osobine.
Selekcija podataka putem vrijednosti indikatora aktuelnosti zahtijeva postojanje naredbi u okviru
jezika za manipulisanje podacima, koje će eksplicitno, ili implicitno uticati na vrijednost tog
indikatora.
Primjer 1.10.:
Naredba tipa POSTAVI INDIKATOR AKTUELNOSTI NA NAREDNI SLOG, eksplicitno
postavlja adresu lokacije narednog sloga u indikator aktuelnosti. Naredba ČITAJ NAREDNI
SLOG, prvo implicitno postavlja adresu lokacije narednog sloga u indikator aktuelnosti, a zatim
prenosi sam slog u radnu zonu korisnika.
Selekcija podataka se moţe vršiti i na osnovu njihove povezanosti sa drugim podacima.
Karakterističan primjer predstavlja slučaj kada su povezani podaci o dva entiteta realnog sistema.
Primjer 1.11.:
Neka su u bazi podataka podaci o svakom radniku povezani sa njegovim radnim mjestom putem
podataka o radnikovom resporeĎivanju na to radno mjesto. Radnik, Radno_Mjesto i
Je_RasporeĎen predstavljaju modele odgovarajućih skupova entiteta. Naredba ČITAJ
Radno_Mjesto ZA Radnik PUTEM Je_RasporeĎendovela bi do prenošenja podataka o radnom
mjestu onog radnika, čiji slog je tekući u skupu slogova o radnicima, u radnu zonu korisnika.
Prethodno je odgovarajućom naredbom, morala biti definisana potrebna vrijednost indikatora
aktuelnosti za skupslogova o radnicima.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
11
Ako bi ţeljeli dobiti podatke o radnim mjestima za sve radnike sa nekom karakterističnom
osobinom, na primjer, za sve čije zanimanje je «inţenjer», u slučaju selekcije podataka putem
njihovig odnosa u strukturi, bilo bi potrebni napisati čitav program.
Pojednostavljeno govoreći, taj program treba iterativno da:
prstupi slogu svakog radnika,
da provjeri da li zadovoljava treţenu osobinu,
u slučaju potvernog odgovora, da, putem podataka o njegovom rasporeĎivanju, pronaĎe
podatke o njegovom radnom mjestu.
Selekcija podataka na osnovu zadate vrijednosti osobine, naziva se i asocijativnim adresiranjem.
Naredbe jezika, koji koristeovakav postupak za izbor podataka imaju dio koji se naziva
kvalifikacionim izrazom, sa sljedećom osnovnom strukturom: (osobina, uslov, vrijednost).
Vrijednost (osobine) sluţi kao kriterijum za selekciju (izbor), a uslov predstavlja jedan od
znakova <, ≤, >, ≥, =, ≠. Kvalifikacioni izrazi se mogu povezivati logičkim operacijama.
Primjer 1.12.:
Neka je Radnik (MBR, IME, PRZ, GRĐ) model skupa radnika. Sloţeni kvalifikacioni izraz
«(IME = Marko) (GRĐ=1980)» doveo bi do prenošenja podataka o svim radnicima koji se
zovu Marko i roĎeni su 1980. godine u radnu zonu korisnika.
Jezici za manipulisanje podacima se razlikuju s obzirom na činjenicu da li jedna selekcija vrši
izbor podataka o najviše jednom entitetu ili vrši izbor podataka skupa entiteta sa nekom
zajedničkom osobinom. Ako selekcija vrši izvor podataka o najviše jednom entitetu praćenjem
nekog logičkog putua u strukturi podataka, jezici se nazivaju navigacionom. Za selekciju u
navigacionim jezicima je karakteristično korištenje indikatora aktuelnosti i veza podataka u
strukturi. Ovi jezici su proceduralni, u smislu da se putem njih mora saopštiti sistemu za
upravljanje bazom podataka ne samo šta se ţeli dobiti, već i kako to treba postići. Proceduralni
su, jer se za selekciju podataka mora napisatiprogram, koji, u opštem slučaju, sadrţi sve tri
osnovne programske strukture: sekvencu, selekciju i iteraciju, kako je to opisano u posljednjem
dijelu primjera 1.11. Pri tome treba naglasiti da selekcija podataka iz baze podataka i selekcija,
kao onovna programska struktura, predstavljaju različite pojmove sa istim nazivom.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
12
Ako se putem jedne operacije vrši, u opštem slučaju, izbor podataka o skupu entiteta sa istom
osobinom, jezik se naziva specifikacionim ili deklarativnim. Deklarativni jezici koriste
vrijednosti osobina za selekciju. Nazivaju se i neproceduralnim, jer se putem naredbi tog jezika
izraţava samo šta (koji podaci) se ţeli dobiti, ali ne i kako to treba postići. Kod deklarativnih
jezika, selekcija se specificira: navoĎenjem naziva modela skupova entiteta i kvalifikacionog
izraza (kao u primjeru 1.12).
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
13
1.4. Kratak pregled razvoja modela podataka
Tokom posljednjih tridesetak godina, razvijen je veći broj različitih modela podataka. Sudbina
tih modela podataka je bila različita. Neko od njih predstavljali su samo interesantan pokušaj ili
usputnu stanicu u razvoju drugih modela, a drugi su ostavili trajan trag kako u teoriji tako i u
praksi baza podataka. U modele podataka, koji spadaju u ovu drugu kategoriju, spadaju:
mreţni model podataka,
hijerarhijski model podataka,
relacioni model podataka,
model entiteta i poveznika,
funkcionalni model podataka,
model semantičkih hijetarhija,
semantički model podataka,
objektno orjentisani model podataka,
logički model podataka.
Mreţni i hijerarhijski model podataka su se pojavili u drugoj polovini šezdesetih godina. Već
početkom sedamdesetih godina ušli su u dnevnu upotrebu sistemi za upravljanje bazama
podataka (SUBP), zasnovani na ovim modelima podataka. MeĎutim, ti sistemi baza podataka
(SUBP plus sama baza podataka) predstavljali su odreĎeno razočarenje za korisnike. Nisu doveli
do očekivanog porasta produktivnosti ni programera ni krajnjih korisnika. Razlozi za to
razočarenje leţali su u:
nedovoljnom razdvajanju logičkih od fizičkih aspekata baze podataka,
kompleksnosti struktura podataka,
korištenju proceduralnog i navigacionog jezika.
Osnovni cilj definisanja i razvoja relacionog modela podataka, bio je eliminisanje baš tih
nedostataka. Od njegovog predstavljanja 1970. godine [11], za relacioni model stalno je rastao
interes prvo naučnika, a kasnije i korisnika. Taj interes je bio posljedica niza poţeljnih osobina, u
koje, izmeĎu ostalih, spadaju: formalno – matematička osnova, homogenost, dobro definisani
kriterijumi za ocjenu kvaliteta projekta baze podataka i, vjerovatno iznad svega, deklarativni
jezik za korištenje baze podataka. Taj jezik je zasnovan na matematičkoj logici, ali veoma dobro
prilagoĎen potrebama komforne i lake upotrebe. MeĎutim, relacioni, kao i svi drugi matematički
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
14
modeli podataka, ne poklanja dovoljno paţnje semantici (smislu i značenju) podataka. Strukture
podataka relacionog modela su semantički nedovoljno bogate, te je krajnjem korisniku teško da
ih poveţe sa konkretnim realnim sistemom.
Nedovoljna snaga relacionog modela za izraţavanje semantike, dovela je krajem sedamdesetih
godina do povećanja interesa naučnika za semantičke modele podataka. Taj interes je porastao
pojavom modela entiteta i poveznika [9], modela semantičkih hijerarhija [62] i semantičkog
modela podataka [29]. I sam rodonačelnik relacionog modela podataka, Codd, je u svom radu
[12] predloţio uvoĎenje novih koncepata za povećanje semantičke izraţajnosti relacionog
modela. Interes za semantičke modele podataka nastavio se i u osamdesetim godinama. Širenje
horizonta korištenja baza podataka vodi ka sve intenzivnijoj primjeni semantički bogatijih
modela podataka, naročito u oblastima inţenjerskog projektovanja, multimedija i baza znanja.
Osamdesete godine bile su obiljeţene intenzivnim širenjem SUBP zasnovanih na relacionom
modelu i istraţivanjima u oblasti objektno orijentisanih i logičkih modela podataka. Bez
pretenzija na strogost definicije, objektno orijentisani modeli se razvijaju na osnovama mreţnog
modela, semantičkih modela i objektno orijentisanih programskih jezika. Logički modeli se
mogu posmatrati kao dalja nadgradnja relacionog modela podataka konceptima programskog
jezika Prolog. Ta nadogradnja znači, prije svega, uvoĎenje dedukcije u baze podataka.
Prva polovina devedesetih godina je obiljeţena: dominacijom relacionih SUBP, pojavom SUBP,
zasnovanih na objektno orjentisanom modelu podataka, ali i uključivanjem pojedinih objektno
orijentisanih koncepata u relacione SUBP, ili čak kombinovanjem objektno orijentisanih
programskih jezika sa relacionim SUBP.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
15
2. Model entiteta i poveznika
Postoji više verzija modela podataka zasnovanih na entitetima i poveznicima. Najpoznatiju
verziju predstavlja Čenov model entiteta i poveznika [9]. Kako sam Čen kaţe, model je nastao
kao sinteza dobrih strana tri druga modela: mreţnog, relacionog i modela skupova entiteta [59].
Za geometrijsku prezentaciju koncepata modela koriste se grafovi i tabele. Intenzionalni dio
modela se prezentuje grafovima , a ekstenzionalni dio modela se prezentuje tabelama. Mada je
Čen u svom radu opisao sve tri komponente modela entiteta i poveznika, sam model je prije
svega namijenjen za projektovanje statičkog modela realnog sistema, zbog širokih mogućnosti za
izgradnju semantički bogatoh modela realnog sistema i zbog pogodne dijagramske tehnike za
geometrijsko prezentovanje tog modela. Za model podataka se kaţe da se semantički (smisaono)
bogat, ako se putem njegovih koncepata moţe izgraditi vjeran model praktično svakog realnog
sistema. Model entiteta i poveznika je posluţio i kao osnova za definisanje semantičkog modela
podataka, koji se intenzivno koristi u vještačkoj inteligenciji i za definisanje strukturalne
komponente objektno orijentisanog modela podataka.
Model entiteta i poveznika se, često, naziva i ER modelom podataka, a sreću se i drugi nazivi.
Jedan od njih je model podataka objekti – veze.
Ovdje se postavlja cilj da se ovlada metodama, tehnikama i konvencijama za transformisanje
slike realnog sistema, kakva egzistira u projektantovom intelektu, u intenzionalni i
ekstenzionalni opis statičke strukture tog realnog sistema.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
16
2.1. Strukturalna komponenta ER modela podataka
Osnovna ideja, na kojoj je zasnovan modela entiteta i poveznika, je da se realni svijet (ili njegov
dio, realni sistem) moţe opisati pomoću dva osnovna koncepta. To su entitet i poveznik. Entitet
(Latinski: ens, entis znači biće, bitnost) je „nešto“ što se moţe jednoznačno identifikovati. Entitet
se takoĎe opisuje kao „jedinica posmatranja“. Predstavlja termin, koji se moţe odnositi na svaki
realni subjekat, objekat, dogaĎaj, pojavu ili neki apstraktni pojam. Poveznik predstavlja vezu
izmeĎu dva ili više entiteta. Poveznik konstituišu povezani entiteti i opis njihove veze.
Primjer 2.1.:
Student Bojan Marković sa brojem indeksa 89034 je jedan entitet. Predmet Informatika je drugi
entitet. Polaganje ispita iz predmeta Informatika na dan 12.06.2005. godine je takoĎe jedan
entitet. MeĎutim, jedan mrav se moţe proglasiti entitetom, samo pod uslovom da smo u stanju
da ga jednoznačno identifikujemo meĎu drugim mravima, što je malo vjerovatno. Entitet bi
mogla biti neka kolonija mrava.
Jedan poveznik je „student Bojan Marković sluša predmet Informatika“, drugi je „student Bojan
Marković je poloţio predmet Informatika“. To su različiti poveznici izmeĎu dva ista entiteta. U
oba slučaja , entiteti su Bojan Marković i Informatika. Opisi njihove veze su: „sluša“ i „poloţio“.
Jedan poveznik izmeĎu tri entiteta je „student Bojan Marković je poloţio predmet Informatika na
ispitu od 12.06.2005. godine“ (treći entitet je ispit).
2.1.1. Entitet i skup (klasa) entiteta
Entiteti, koji egzistiraju kao predstave realnih subjekata, objekata, dogaĎaja u ljudskom intelektu
mogu se klasifikovati u skupove sličnih entiteta. Formalno, neka je e entitet, tada je skup entiteta
E = {EP(e)}, gdje je P(e) predikat čija istinitosna vrijednost ukazuje da li e pripada skupu E.
Ako e posjeduje osobinu P(e), tada e pripada E. Isti entitet e moţe pripadatai različitim
skupovima entiteta.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
17
Primjer 2.2.:
Ako je P(e) = „e je student“, onda skupu E pripadaju samo studenti, a ne i ostali ljudi. MeĎutim,
ako E` = {ee je ljudsko biće}, tom skupu pripadaju svi ljudi, ali ne i ostali sisari. Pri tome
studenti pripadaju i skupu E i skupu E`.
2.1.2. Intenzija ER modela podataka
Na nivou intenzije, koncepte ER modela podataka čine: tip entiteta i tip poveznika. Obiljeţje
predstavlja osnovni gradivi elemenat za konstituisanje ovih, sloţenihih koncepata.
2.1.2.1. Obilježje
Skupovi sličnih entiteta se nazivaju i klasama entiteta. Svi entiteti jedne klase posjeduju bar
jednu zajedničku osobinu, na osnovu koje su i svrstani u istu klasu. U opštem slučaju, broj
zajedničkih osobina entiteta jedne klase veći je od jedan. Ove osobine nazivaju se obilježjima
(atributima). Obiljeţja se označavaju velikim latiničnim slovima, skraćenim nazivom
(mnemonikom) ili punim nazivom. Velika latinična slova se koriste kada semantika obiljeţja nije
vaţna.
Primjer 2.3.:
Ako je je MATIČNI_BROJ_RADNIKA pun naziv obiljeţja, odgovarajući mnemonik bi mogao
biti MBR.
Obiljeţje, koje se dalje ne moţe dekomponovati, ili koje se u posmatranom slučaje dalje ne
dekomponuje na komponente, koje takoĎe predstavljaju obiljeţja, naziva se elementarnim
obilježjem. Skup, niz ili logički proizvod elementarnih obiljeţja predstavlja složeno obilježje.
Tom nizu obiljeţja moţe se pridruţiti neko ime.
Primjer 2.4.:
Obiljeţja NAZIV_PROIZVODA, BOJA_AUTOMOBILA, IME_ STANOVNIKA predstavljaju
elementarna obiljeţja različitih klasa entiteta. Sloţena obiljeţja predstavljaju, na primjer,
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
18
ADRESA = {MJESTO, ULICA, BROJ}, {IME, PREZIME, MJESTO}, ili DATUM_UPLATE
= {DAN, MJESEC, GODINA}.
Sloţena obiljeţja se, često označavaju slovima sa kraja abecede, na primjer X,Y,Z, a elementarna
slovima sa početka abecede A,B,C. Saglasno tome, sloţeno obiljeţje je X = (A1, A2, ..., Ak),
odnosno X = {A1, A2, ..., Ak}, gdje su Ai, 1≤ i ≤ k elementarna obiljeţja. Pri tome, sloţeno
obiljeţje X je jednom predstavljeno kao niz, a drugi put kao skup.
2.1.2.3. Domen
Svakom obiljeţju odgovara jedan skup svih mogućih vrijednosti koje to obiljeţje, u konkretnim
slučajevima, moţe imati. Taj skup vrijednosti se naziva domenom obilježja. Domen obiljeţja A
se obiljeţava sa dom(A). TakoĎe, domen moţe posjedovati i svoje, posebno ime. Isti domen se
moţe pridruţiti većem broju različitih obiljeţja.
Primjer 2.5.:
Za obiljeţje BOJA_AUTOMOBILA skup vrijednosti je
dom(BOJA_AUTOMOBILA) = {bijela, ţuta, crna, plava}.
Obiljeţjima IME_STRUDENTA i IME_NASTAVNIKA se moţe pridruţiti isti domen sa
nazivom IME. Taj domen sadrţi, kao svoje elemente, sva moguća lična imena.
U strukturama podataka, pojam domena se ne koristi u uobičajenom matematičkom smislu, kao
skup originala funkcije. Domen moţe predstavljati skup originala funkcije, ali i skup slika.
Pojam domena se koristi u smislu skupa iz kojeg semantički definicani objekti, kao što su tip
entiteta i obiljeţje, uzimaju vrijednosti.
2.1.2.3. Tip entiteta
Sa tačke gledišta zadataka informacionog sistema, nisu sva obiljeţja klase entiteta jednako
vaţna. Od obiljeţja, bitnih za realizaciju zadataka informacionog sistema, gradi se model realne
klase entiteta. Model klase entiteta naziva se tipom entiteta.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
19
Definicija 2.1.:
Izraz oblika N(A1, A2,..., An) predstavlja model skupa entiteta E={eP(e)} i naziva se tipom
entiteta, ako i samo ako N predstavlja ime skupa {eP(e)}, a A1,..., An obiljeţja entiteta skupa
{eP(e)}.
Kao i svaki model, tip entiteta predstavlja samo pribliţnu sliku klase entiteta realnog sistema.
Neki put se za prezentaciju klase entiteta, umjesto oznake za tip entiteta N(A1,..., An) koristi
samo naziv N. Pošto niz (A1,..., An) predstavlja sloţeno obiljeţje, tip entiteta N(A1,..., An)
predstavlja imenovano sloţeno obiljeţje. Naziv entiteta predstavlja semantičku komponentu tog
apstraktnog opisa klase realnih entiteta. On daje smisao nizu obiljeţja, koji iza njega slijedi.
Klasa entiteta posjeduje konačno mnogo osobina zajedničkih svim realnim entitetima. Neka je
{A1,..., Am}skup osobina klase entiteta E. Tada je skup obiljeţja {A1,..., An} odabranih za
izgradnju tipa entiteta kao model klase E, pravi ili nepravi podskup skupa obiljeţja {A1,..., Am}.
Primjer 2.6.:
Tip entiteta STUDENT (BROJ_INDEKSA, IME, PREZIME, NAZIV_FAKULTETA)
prezentuje sve studente jednog univerziteta.
2.1.2.4. Skup poveznika, uloga entiteta i tip poveznika
Skup poveznika R predstavlja relaciju, u matematičkom smislu, izmeĎu n ≥ (2) skupova entiteta,
R = {(e1,..., en)ei Ei, i=1,.., n}
Pri tome skupovi Ei ne moraju biti različiti. Svaka n-torka (e1,..., en) u R predstavlja jedan
poveznik. Svaki entitet ei u n-torki ima svoju ulogu. Ako se uloge ui entiteta ei u torki
eksplicitno navedu, redoslijed navoĎenja entiteta u torki postaje nevaţan.
Eksplicitno navoĎenje uloga posebno dobija na vaţnosti kada su u pitanju skupovi poveznika
izmeĎu entiteta, koji pripadaju istim skupovima entiteta. Treba, takoĎe, naglasiti i da izmeĎu dva
ista skupa entiteta moţe egzistirati više različitih skupova poveznika. U takvim slučajevima,
entiteti bar jednog od povezanih skupova imaju različite uloge u svakom od posmatranih
skupova poveznika. Ako poveznik povezuje entitete jednog skupa, naziva se rekurzivnim.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
20
Primjer 2.7.:
Posmatraju se skup entiteta Radnik i skup entiteta Radno_Mjesto. Neka je Makro elemenat u
skupu Radnik, a programenr u skupu Radno_Mjesto. Poveznik (Marko, programer) ima
semantiku „(radnik) je rasporeĎen na (radno mjesto)“.
Ako se u skup Radnik uvede relacija poretka sa semantikom „je rukovodilac“, tada ureĎeni par
(Ivan, Marko) nosi informaciju da je Ivan Markov rukovodilac. U paru (Ivan, Marko) oba
entiteta pripadaju istom skupu, ali u u povezniku imaju potpuno različite uloge. Te uloge u
posmatranom povezniku nisu eksplicitno navedene. Isti poveznik, sa eksplicitno navedenim
ulogama entiteta, bi bio (Ivan, rukovodilac), Marko (potčinjeni)).
Posmatra se skup entiteta Radnik i skup entiteta Projekat, pri čemu Komuna i Faktura
pripadaju skupu Projekat. Parovi (Marko (nosilac), Komuna) i (Marko (programer), Faktura)
predstavljaju različite poveznike izmeĎu ta dva skupa. U tim poveznicima su uloge entiteta
Marko eksplicitno navedene.
Definicija 2.2.:
Izraz oblika N(E1,..., En; B1,..., Bk) predstavlja model skupa poveznika R i naziva se tipom
poveznika, ako i samo ako N predstavlja naziv skupa poveznika R, E1,..., En su povezani skupovi
entiteta, a B1,..., Bk obiljeţja poveznika skupa R = {(e1,..., en)ei Ei, i=1,..., n}.
Primjer 2.8.
Tip poveznika RasporeĎen (Radnik, Radno_Mjesto, DATUM_RASP) predstavlja model skupa
poveznika oblika (radnik, radno_mjesto) proširenih navoĎenjem njihove zajedničke osobine –
datuma resporeĎivanja (radnika na radno mjesto).
Tip poveznika Rukovodi (Radnik, Radnik) je model rukovodne hijerarhije, čiji je jedan reprezent
par (Ivan, Marko) iz primjera 2.7.
Tipovi poveznika Rukovodi (Radnik, Projekat) i Radi (Radnik, Projekat) predstavljaju modele
odnosa izmeĎu radnika i projekata. Informacija o različitim ulogama entiteta iz skupa Radnik,
ugraĎena je u naziv tipa poveznika.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
21
2.1.3. Dijagrami tipova entiteta i poveznika
Model statičke strukture realnog sistema, realizovan putem ER modela podataka, po pravilu se
predstavlja uz pomoć takozvanik ER dijagrama. Tip entiteta se crta kao pravougaonik sa
upisanim nazivom (tipa entiteta). Tip poveznika se crta kao romb sa upisanim nazivom (tipa
poveznika). Ako tip poveznika R povezuje tipove entiteta E1,..., Ek tada se crta po jedan
neusmjereni poteg od romba R do geometrijske slike svakog od Ei.
Skupovi vrujednosti (domeni) se prikazuju kao ovalni sa upisanim nazivom domena i povezuju
orijentisanim potegom sa odgovarajućim tipom entiteta ili tipom poveznika. Orijentacija potega
je ka ovalu skupa vrijednosti. Naziv obiljeţja se upisuje na poteg domena, ako se nazivi obiljeţja
i domena razlikuju.
ER dijagrami se mogu crtati sa dva nivoa detaljnosti. To su: nivo detaljnosti naziva i nivo
detaljnosti obiljeţja. Nivo detaljnosti naziva daje pregledinije dijagrame, a nivo detaljnosti
obiljeţja daje dijagrame sa većom količinom informacija. Da bi se dobili dijagrami i sa dobrom
preglednošću i sa većom količinom informacija, dva nivoa detaljnosti crtanja dijagrama se
kombinuju. Na jednom dijagramu se predstavljaju tipovi entiteta i tipovi poveznika na nivou
detaljnosti naziva, a na nizu drugih dijagrama predstavlja se svaki entitet i tip poveznika sa
pripadajućim obiljeţjima i skupovima vrijednosti.
Primjer 2.9.:
Na slici 2.1 prikazana su dva tipa entiteta Radnik i Projekat. IzmeĎu ta dva tipa entiteta postoje
dva tipa poveznika Rad_Na_Projektu i Rukovodi. Entiteti tipa Radnik igraju dvije uloge u
poveznicima dva tipa. To su uloga saradnika na projektu i uloga rukovodioca projekta. Te uloge
su ispisane uz potege izmeĎu odgovarajućeg tipa poveznika i tipa entiteta Projekat.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
22
Радник
Рад_На_
Пројекту
Пројекат
Руководи
сарађује
руководи
Slika 2.1.
Na slici 2.2 su prikazana tri tipa entiteta Isporučilac, Dio, Proizvod izmeĎu kojih je definisan
jedan tip poveznika I_D_S, sa semantikom isporučilac (I) isporučuje dio (D) za ugradnju u
proizvod (P).
Производ ДиоИ_Д_С
Испоручилац
Slika 2.2.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
23
Саставница
Производ
уграђује се садржи
Slika 2.3.
Na slici 2.3 prikazan je tip entiteta Proizvod i tip poveznika Sastavnica. Svaka pojava tipa
poveznika Sastavnica sadrţi dva entiteta iz skupa Proizvod. Jedan ima ulogu proizvoda, a drugi
komponente, koja se u taj proizvod ugraĎuje. Ove uloge su na slici 2.3 označene, redom, kao
„sadrţi“ i „ugraĎuje se“. Drugim riječima, na slici 2.3 je, putem koncepata modela entiteta i
poveznika, predstavljen model sastavnice proizvoda.
Primjer 2.10.:
Na slici 2.4. su prikazani tipovi Radnik, Projekat i tip poveznika Rad_Na_Projektu sa
odgovarajućim domenima (skupovima vrijednosti). Obiljeţja DAZ (datum zaposlenja radnika) i
DAP (datup početka rada na projektu) dijele isti skup vrijednosti – domen sa imenom DATUM.
Радник ПројекатРад_На_
Пројекту
МБР ИМЕ ПРЗ ДАТУМ СПР НАП НАР ИЗН
ДАЗ ДАП
Slika 2.4.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
24
2.1.4. Ekstenzija ER modela podataka
Ekstenzionalne koncepte ER modela podataka čine: pojava tip entiteta, skup pojava tipa entiteta,
pojava tipa poveznika i skup pojava tipa poveznika. Podatak predstavlja primitivni koncept,
putem kojeg se komponuju sloţeniji koncepti.
2.1.4.1 Podatak
Entiteti i poveznici se opisuju putem skupova parova (obiljeţje, vrijednost). Obiljeţje predstavlja
semantičku komponentu te dvojke.
Definicija 2.3.:
Par (obiljeţje, vrijednost) predstavlja podatak o nekom entitetu ili povezniku, ako obiljeţje
predstavlja osobinu posmatranog entiteta ili poveznika, a vrijednost pripada domenu tog
obiljeţja.
Primjer 2.11.:
Ako se posmatra obiljeţje MATIČNI_BROJ_RADNIKA i jedna njegova vrijednost 110451,
tada 110451 predstavlja podatak o nekom radniku jedino ako se unaprijed zna da 110451
predstavlja vrijednost obiljeţja MATIČNI_BROJ_RADNIKA. U suprotnom 110451 ne
predstavlja podatak jer mu je smisao neodreĎen.
Broj 7 ne predstavlja podatak, jer mu je smisao neodreĎen. Moţe se interpretirati na više načina:
kao ocjena studenta, kao starost djeteta i slično.
Formalno, neka je E = {eii=1,..., m} klasa entiteta, a A jedno od obiljeţja te klase. Obiljeţje
A predstavlja funkciju A:Edom)A), tako da A(ei) predstavlja podatak o ei s obzirom na A.
Vrijednost elementarnog obiljeţja predstavlja elementarni podatak, a vrijednost sloţenog
obiljeţja predstavlja sloţeni podatak. Ako je X = {A1,..., Ak}, tada je dom(X)
dom(A1)*,...,*dom(Ak), tako da je (a1,..., ak) jedna vrijednost obiljeţja X, gdje je, za svako i, ai
dom(Ai).
Obiljeţje čije se vrijednosti dobijaju primjenom nekog algoritma na vrijednosti drugih obiljeţja
naziva se izvedenim obilježjem, a njegove vrijednosti izvedenim podacima.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
25
Primjer 2.12.:
Obiljeţje SREDNJA_OCJENA je izvedeno. Njegove vrijednosti se dobijaju sabiranjem
vrijednosti obiljeţja OCJENA za sve poloţene predmete i dijeljenjem tog zbira sa vrijednošću
obiljeţja BROJ_POLOŢENIH_ISPITA.
2.1.4.2. Pojava i skup pojava tipa entiteta
Svaka klasa entiteta predstavlja skup sličnih entiteta. Svakom entitetu posmatrane klase
odgovaraju konkretne vrijednosti obiljeţja klase entiteta. U okviru informacionog sistema, svaki
entitet se predstavlja modelom koji sadrţi konkretne vrijednosti onih obiljeţja, uz pomoć kojih je
opisana klasa entiteta. Uređenje podataka u modelu entiteta diktirano je uređenjem skupa
obilježja u tipu entiteta. Obiljeţjima u tipu entiteta odgovaraju vrijednosti tih obiljeţja (podaci) u
modelu entiteta istim redom.
Model jednog entiteta naziva se pojavom odgovarajućeg tipa entiteta. Tip entiteta i pojava
entiteta predstavljaju apstraktne opise konkretnih realnih entiteta. Tip entiteta predstavlja model
entiteta na višem nivou apstrakcije nego pojava tipa entiteta.
Formalno, za dati tip entiteta N (A1,..., An) skup funkcija
{Ai: Edom(Ai)i = 1,.., n}
jednoznačno odreĎuje funkciju
(A1,..., An):Edom(A1)x...xdom(An),
gdje se E klasa entiteta, a
dom(A1x...xdom(An) = {(a1,..., an)ai dom(Ai), i = 1,..., n}
Funkcija (A1,..., An) je definisana sa (A1,..., An)(e) = A1(e),..., An)), gdje je eE entitet. Drugim
riječima, (a1,..., an) predstavlja pojavu entiteta N(A1,..., An) ako je zadovoljena kvantifikatorska
formula
((a1,..., an)) = ( e E)( i {1,..., n}) (ai = Ai (e))
a skup P pojava tipa entiteta je
P = {(ai,..., an)| ((a1,..., an))}
UreĎenje podataka u n-torki (a1,..., an) je bitno, jer nosi informaciju o tome da je ai dom(Ai).
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
26
Primjer 2.13.:
Za tip entiteta Student iz primjera 2.6, moguće pojave predstavljaju sljedeće četvorke: (159,
Ivan, Babić, Elektrotehnički fakultet), i (432, Marija, Jovanović, Ekonomski fakultet).
2.1.4.3. Ključ tipa entiteta
Definicija pojma entiteta kao „jedinice posmatranja“ ukazuje na potrebu da se entiteti
posmatrane klase mogu razlikovati. To zahtijeva da i modeli dva entiteta budu različiti. Neka su
e1 i e2 entiteti klase E, a N(A1,..., An) tip entiteta, tada mora vaţiti
))(,...,())(,...,( 2111 eAAeAA nn . Znači, mora postojati neprazan skup obiljeţja X {A1,..., An}
takav da je X(e1) ≠ X(e2).
Definicija 2.4.:
Neka je },...,1|{ kipP i skup pojava entiteta N(A1,..., An), a p[X] restrikcija pojave p na
obiljeţje X. Obiljeţje X predstavlja ključ tipa entiteta N(A1,..., An) ako, za svaki skup P pojava
tipa entiteta N, vaţe sljedeća dva uslova:
10 ( pi, pj P)(pi ≠ pj pi [X] ≠ pj[X]
20 (X` X ( 1
0).
Ako X zadovoljava samo uslov 10, naziva se superključem tipa entiteta N. Uslov 1
0 ukazuje na
takozvanu jedinstvenost vrijednosti ključa. U skupu pojava jentiteta ne postoje dvije pojave sa
istom vrijednošću ključa. Uslov 20 je uslov takozvane minimalnosti ključa. Ključ ne posjeduje
suvišna obiljeţja.
Svaki tip entiteta posjeduje bar jedan ključ. Neka je X = {A1,..., An}. Tada uslov 10 trivijalno
vaţi. Ako vaţi i uslov 20, X predstavlja ključ tipa entiteta N(A1,..., An). Inače mora postojati
neprazan podskup skupa {A1,..., An) za koji vaţi 10 i 2
0. Ovo razmatrenje, ujedno, sugeriše i
jedan od mogućih postupaka za odreĎivanje ključa tipa entiteta.
Jedan tip entiteta moţe posjedovati više ključeva. Nazivaju se ekvivalentnim. Jedan od
ekvivalentnih ključeva se bira za primarni. U okviru notacije za tip entiteta sva obiljeţja jednog
ključa podvlače se jednom, kontinualnom linijom.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
27
Primjer 2.14.:
Tip entiteta Student (BROJ_INDEKSA, IME, PREZIME, ADRESA,
MATIČNI_BROJ_STANOVNIKA) posjeduje dva ključa. To su BROJ_INDEKSA i
MATIČNI_BROJ_STANOVNIKA. Ako je riječ o tipu entiteta, definisanom u projektu
fakultetskog informacionog sistema, obiljeţje BROJ_INDEKSA bi, najvjerovatnije, bilo
izabrano za primarni ključ.
2.1.4.4. Pojava tipa poveznika
Jedan tip poveznika predstavlja apstraktni model većeg broja različitih skupova torki sličnih
osobina definisanih nad istim domenima. Jedna torka predstavlja jednu pojavu tipa poveznika.
Ako je tip poveznika binaran, tada njegove pojave predstavljaju ureĎene trojke. Prvu
komponentu trojke predstavlja jedna pojava prvog tipa entiteta, drugu komponentu trojke
predstavlja jedna pojava drugog tipa entiteta. Treću komponentu predstavlja torka (b1,...,
bk)dom(B1)x...xdom(Bk). Pošto svaku pojavu tipa entiteta reprezentuje odgovarajuća vrijednost
ključa, dovoljno je da pojava tipa poveznika sadrţi vrijednosti primarnih ključeva povezanih
tipova entiteta umjesto kompletnih pojava tih tipova entiteta.
Saglasno rečenom, tip poveznika izmeĎu tipovaentiteta E1, ..., En moţe se predstaviti i kao
imenovani niz obiljeţja, u oznaci R(a1,..., Am), pri čemu vaţi K1,..., Kn {A1,..., Am}, gdje Ki,
i=1,..., n, predstavljaju primarne ključeve povezanih tipova entiteta.
Pri tome vaţi
{B1,..., Bk} = {A1,...., Am}\n
i
iK1
gdje je Bi\i=1,..., k} skup obiljeţja skupa poveznika R. Ovaj skup obiljeţja moţe biti prazan.
Opisani način predstavljanja tipa poveznika zahtijeva da se definiše i pojam ključa tipa
poveznika. Ključ K tipa poveznika R predstavlja pravi ili nepravi podskup unije primarnih
ključeva povezanih tipova entiteta, u oznaci
n
i
iKK1
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
28
Primjer 2.15.:
Ključ tipa poveznika Rad_Na_Projektu sa slike 2.4 je K={MBR, SPR}, a ključ tipa poveznika
RasporeĎen sa slike 2.5 je K={MBR}. Ključ tipa poveznika RasporeĎen je pravi podskup unije
ključeva povezanih tipova entiteta.
Primjer 2.16.:
Za tip poveznika
Ispit (BROJ_INDEKSA, IDBROJ_PREDMETA, OCJENA),
ključ predstavlja sloţeno obiljeţje{BROJ_INDEKSA, IDBROJ_PREDMETA}.
Tip poveznika Povjeravanje (IDBROJ_NASTAVNIKA, IDBROJ_PREDMETA) opisuje odnos
izmeĎu nastavnika i predmeta u realnom sistemu, gdje se nastavniku povjerava izvoĎenje
predavanja iz predmeta. Ako se za ključ tipa entiteta Povjeravanje odredi obiljeţje
IDBROJ_NASTAVNIKA, tada tip entiteta opisuje odnos, prema kojem se svakom nastavniku
povjerava samo jedan predmet. Ako se za ključ odredi IDBROJ_PREDMETA, tip entiteta
opisuje realnu situaciju u kojoj nastavu iz svakog predmeta izvodi samo jedan nastavnik.
Ako se pretpostavi da se istom nastavniku moţe povjeriti izvoĎenje nastave iz više predmeta, a
isti predmet moţe povjeriti većem broju nastavnika, tada sva obiljeţja tipa entiteta Povjeravanje
IDBROJ_NASTAVNIKA, IDBROJ_PREDMETA) predstavljaju ključ. Moţe se zaključiti da
semantika modela skupa pojava tipa poveznika značajno zavisi od odabranog ključa.
2.1.4.5. Predstavljanje ekstenzije ER modela
Ekstenzija modela entiteta i poveznika se predstavlja putem tabela, slično kao i u relacionom
modelu. Svakom tipu entiteta ili tipu poveznika odgovara jedna tabela sa svim njegovim
obiljeţjima u zaglavlju tabele i podacima o entitetima u kolonama tabele. Kolone predstavljaju
modele entiteta ili poveznika posmatranog skupa. Ove tabele se, redom, nazivaju relacijama
entiteta i relacijama poveznika.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
29
Primjer 2.17.:
Na slici 2.5 je prikazan dijagram entiteta i poveznika sa tipovima entiteta Radnik i Radno_mjesto
i tipom poveznika RasporeĎen. Obiljeţje MBR predstavlja ključ tipa poveznika RasporeĎen. Na
slici 2.6 prikazane su odgovarajuće relacije entiteta i relacija poveznika. Ključevi tipova entiteta i
poveznika su podvučeni. Treba zapaziti da, saglasno tabelama na slici 2.6, postoje nerasporeĎeni
radnici i radna mjesta na koja nije rasporeĎen nijedan radnik.
Радник Радно_МјестоРаспоређен
МБР ИМЕ ПРЗ НАЗ БРИ БРБ СПРГОД
Slika 2.5. Dijagram entiteta i povetnika: Radnik, Radno_Mjesto, RasporeĎen
81
01
50
88
МБР
Марко
Стојан
Јелена
Мира
ИМЕ
Јовановић
Симовић
Марковић
Сандић
ПРЗ
1960
1966
1975
1975
ГОД
Курир
Пројектант
Дактилограф
Програмер
НАЗ
1
3
3
5
БРИ
300
700
700
530
БРБ
НСС
ВСС
ССС
ВСС
СПР
81
01
88
МБР
Програмер
Програмер
Дактилограф
НАЗ
Радник Радно Мјесто Распоређен
Slika 2.6. Tabele entiteta i poveznika: Radnik, Radno_Mjesto, RasporeĎen
IzmeĎu obiljeţja i tipa entiteta nema jasne razlike, jer se imenovano sloţeno obiljeţje koristi za
predstavljanje tipa entiteta. Na prvi pogled teško je povući jasnu granicu i izmeĎu tipa entiteta i
tipa poveznika. MeĎutim, za povlačenje ove granice postoji pouzdan kriterijum. To je pitanje da
li postojanje pojave jednog tipa entiteta zavisi od postojanja pojave drugog. Ako torke relacije
mogu samostalno da egzistiraju, realcija predstavlja ekstenziju tipa entiteta, inače je riječ o tipu
poveznika.
Primjer 2.18.:
Tvrdnja da je granica izmeĎu pojma obiljeţja, tipa entiteta i tipa poveznika često nejasna, moţe
se ilustrovati na sljedeći način. Sa jedne tačke gledišta, Projekat i Projektant predstavljaju tipove
entiteta, a Rad_Na_Projetku tip poveznika. Sa druge tačke gledišta, Naručilac moţe predstavljati
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
30
tip entiteta, a Projekat tip poveznika (u smislu da projekat povezuje naručioca i projektanta). Sa
treće tačke gledišta, Rad_Na_Projektu moţe predstavljati tip entiteta sa ključem IDBRAK (čije
vrijednosti jednoznačno identifikuju aktivnosti na bilo kom projektu), obiljeţjem PROJEKTANT,
i obiljeţjem DATUM_POČETKA.
Ako se iz relacije entiteta Radnik na slici 2.6 ukloni torka (88, Mira, Sandić, 1975), tada torka
(88, Daktilograf) u relaciji poveznika RasporeĎen gubi svaki smisao, jer u relaciji Radnik ne
postoji pojava sa vrijednošću ključa MBR = 88. MeĎutim, ako se iz RasporeĎen relacije ukloni
ukloni torka (01, Programer), to ne znači da treba bilo šta mijenjati u relacijama Radnik,
Radno_Mjesto. Jednostavno, radnik sa MBR = 01 nije više rasporeĎen na radno mjesto
programera.
2.2. Integritetna komponenta ER modela
S obzirom da je model entiteta i poveznika prije svega namijenjen za predstavljanje
konceptualne šeme, posjeduje relativno dobre mogućnosti za definisanje ograničenja. U modelu
se ta ograničenja izraţavaju, uglavnom, eksplicitno. U ta ograničenja spadaju:
integritet domena,
kardinalnost tipa poveznika sa svojim brojnim varijantana i semantičkim interpretacijama,
slabi tip entiteta.
2.2.1. Integritet domena
Integritet domena predstavlja ograničenje, svojstveno praktično svim modelima podataka. U
opštem slučaju, integritet domena ili ograničenje domena je trojka (tip podatka, duţina podatka,
uslov). Tip i duţina podatka je standardno programsko – jezičko ograničenje i predstavlja
obavezni dio ograničenja domena. Tip podatka definiše vrstu znakova, putem kojih se izraţava
vrijednost obiljeţja. Duţina podatka se izraţava putem maksimalnog broja znakova, koji mogu
biti upotrebljeni za izraţavanje vrijednosti obiljeţja. Prema tome, tip i duţina podatka
ograničavaju vrijednosti obiljeţja na tip i broj znakova.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
31
Primjer 2.19.:
Jedno standardno ograničenje domena moţe predstavljati sljedeći skup tipova podataka sa
duţinama:
INTEGER (broj cifara),
REAL ((broj cifara ispredzareza, broj cifara iza zareza),
CHARACTER (broj znakova
LOGICAL (logička varijabla),
DATE .
Tip podataka „logical“ ukazuje da je riječ o logičkoj varijabli, koja uzima vrijednost iz skupa {T,
}.
Pridruţivanje dom(OCE) standardnog ograničenja INTEGER (2), ukazuje da vaţi
dom(OCE)={0,1,…, 99}.
Pridruţivanje dom(IME) standardnog ograničenja CHARACTER (10), ukazuje da dom(IME)
moţe pripadati bilo koji niz od 10 znakova.
Standardna ograničenja domena, često nisu dovoljno precizna. Zato se uvodi i uslov, kao treća,
opciona, komponenta ograničenja domena. Uslov moţe biti regularni izraz ili funkcija. Postoje
prosti i sloţeni regularni izrazi.
Prosti regularni izrazi se definišu s obzirom na neke konstante, koje moraju zadovoljiti
standardno ograničenje domena. Naka je k konstanta iz domena pridruţenog obiljeţju A, a
operator poreĎenja iz skupa {<,>,,,,=}. Tada proste regularne izraze predstavljaju (k) i (k1,
k2, …, kn). Izraz (k) ukazuje da sve vrijednosti pridruţene obiljeţju A moraju biti u relaciji sa
konstantom k. Izraz (k1, k2, …, kn) ukazuje da obiljeţje A smije uzimati vrijednosti iz skupa (k1,
k2, …, kn).
Sloţeni regularni izrazi se komponuju od drugih regularnih izraza (prostih ili sloţenih) njihovim
povezivanjem putem logičkig operatora , , .
Za izraţavanje ograničenja nad domenima nekih obiljeţja nisu dovoljni ni regularni izrazi. Tada
se koriste funkcije, čije argumente predstavljaju naka obiljeţja, ili se koriste algoritmi.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
32
Nula vrijednost predstavlja specijalno ograničenje domena. Putem tog ograničenja se specificira
da li obiljeţje moţe imati nedefinisanu vrijednost. Sama nula vrijednost ima, najčešće jedno od
sljedeća dva značenja:
postojeća, ali nepoznata vrijednost,
neprimjereno svojstvo.
Bitno je naglasiti da nula vrijednost ne predstavlja broj 0 već specijalnu vrijednost, čije značenje
se, najčešće, interpretira na jedan od dva navedena načina.
2.2.2. Kardinalnost (brojnost) tipa poveznika
Često se od modela realnog sistema i modela baze podataka informacionog sistema zahtijeva da
pruţi informaciju ne samo o vezama izmeĎu klasa entiteta već i o prirodi odnosa izmeĎu entiteta
povezanih klasa.
Primjer 2.23.:
U slučaju modela dijela realnog sistema prikazanog slikama 2.5 i 2.6, moţe se zahtijevati da već
apstraktni model na slici 2.5 ukaţe da:
jedan radnik moţe biti rasporeĎen na najviše jedno radno mjesto,
na jedno radno mjesto moţe biti rasporeĎeno više radnika,
na jedno (neko) radno mjesto ne mora biti rasporeĎen nijedan radnik.
U modelu realnog sistema, informacije o prirodi odnosa izmeĎu entiteta povezanih klasa daje
takozvani kardinalitet tipa poveznika R, odnosno kardinalitet odgovarajuće relacije R.
Kardinalitet relacije R, odnosno tipa poveznika R, se označava sa:
R(E1(a1, b1) : E2(a2, b2)).
Parametrima a i b se najčešće dodjeljuju sljedeće karakteristične vrijednosti:
parametru a dodjeljuje se vrijednost 0, ako se bar jedan elemenat skupa originala preslikava u
prazan skup, inače mu se dodjeljuje vrijednost 1,
parametru b se dodjeljuje vrijednost 1, ako kardinalitet slike svakog odiginala nije veći od 1,
inače mu se dodjeljuje vrijednost N (1<N) ili
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
33
M (M≤ E.
S obzirom na maksimalne vrijednosti kardinaliteta, tipovi poveznika mogu se podijeliti u tri
grupe i to: grupa M : N, grupa 1 : N i grupa 1 : 1.
2.2.3. Predstavljanje kardinaliteta tipa poveznika u ER dijagramu
U dijagramima entiteta i poveznika kardinalitet tipa poveznika se predstavlja navoĎenjem ili para
(a1, b1) i (a2, b2) ili samo maksimalnih vrijednosti b1 i b2 uz grafičku predstavu odgovarajućeg
tipa entiteta.
Postoje dva postupka navoĎenja kardinaliteta u ER dijagramima.
Kod jednog, par (a1, b1) se navodi na potegu uz tip entiteta E1, a par (a2, b2) se navodi na potegu
uz tip entiteta E2. Smisao ovog postupka je da se minimalna i maksimalna brojnost podskupova,
recimo, skupa entiteta E2 u koje se moţe preslikati jedan elemenat skupa entiteta E1, upisuje baš
uz tip entiteta E2.
Kod drugog postupka predstavljanja kardinaliteta, par (a1, b1) se navodi na potegu uz tip entiteta
E2, a par (a2, b2) se navodi na potegu uz tip entiteta E1. Semantika ovog postupka predstavljanja
je da se jedna pojava tipa entiteta E1 javlja, kao prva komponenta u skupu pojava tipa poveznika
minimalno a2 i maksimalno b2 puta, a da se jedna pojava tipa entiteta E2 javlja, kao druga
komponenta u skupu pojava tipa poveznika minimalno a1 i maksimalno b1 puta.
Na slici 2.7 prikazan je ER dijagram sa kardinalitetima tipova poveznika dobijenih upisivanjem
dvojki (ai, bi) uz tip entiteta Ei , dok je na slici 2.8 prikazan ER dijagram sa kardinalitetima
dobijenim upisivanjem dvojki (ai, bi) uz tip entiteta Ej.
U oba slučaja opisan je isti realni sistem u kojem:
radnik mora biti rasporeĎen na tačno jedno radno mjesto,
na jedno radno mjesto moţe biti rasporeĎeno više radnika, ali mogu postojati radna mjesta na
koja nije niko rasporeĎen.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
34
Радник Радно_МјестоРаспоређен
(0,N) (1,1)
Slika 2.7. Prikaz kardinaliteta (ai, bi) uz tip entiteta Ei
Радник Радно_МјестоРаспоређен
(1,1) (0,N)
Slika 2.8. Prikaz kardinaliteta (ai, bi) uz tip entiteta Ej
Treći način predstavljanja kardinaliteta je da se parovi (a, b) predstavljaju putem specijalnih
geometrijskih simbola. Minimalni kardinalitet a=0 se predstavlja putem isprekidanog potega
izmeĎu tipa entiteta i tipa poveznika, a a=1 se predstavlja punom linijom. Maksimalni
kardinalitet b=N se predstavlja račvanjem dijela potega uz geometrijsku predstavu tipa entiteta, a
b=1 potegom, koji nema račvu na svom kraju (slika 2.9).
Радник Радно_МјестоРаспоређен
Slika 2.9. Predstavljanje kardinaliteta geometrijskim simbolima.
2.3. Karakteristične strukture ER modela podataka
U narednom tekstu analizirana je semantika jednog broja karakterističnih struktura ER modela
podataka. S obzirom na mali broj osnovnih koncepata (tip entiteta i tip poveznika) i na krajnju
jednostavnodt njihove veze, osnovna paţnja u narednoj analizi poklonjena je semantici
kardinaliteta tipa poveznika. U analizi se polazi od karakteristične strukture, a zatim se
interpretira kakav treba da bude realni sistem, pa da posmatrana ER struktura bude vjeran model
nekog njegovog dijela. Pošto je opisano preslikavanje jedan na jedan, to znači da vaţi i obratno.
Na osnovu poznavanja karakteristika dijela realnog sistema, moţe se izabrati odgovarajuća ER
struktura, kao njegova vjerna slika.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
35
2.3.1. Strukture sa kardinalitetima grupe M : N
Slike 2.10 – 2.12 predstavljaju tri moguća slučaja kardinaliteta tipa M : N.
Na slici 2.10 predstavljena je situacija a1=0 i a2=0, što znači da ne mora svaki radnim biti bar na
jednom projektu i da mogu postojati projekti na kojima još, ili više, na radi ni jedan radnik.
Радник ПројекатРади
(0,M) (0,N)
Симовић
Марковић
Сандић
Николић
Воде
Заштита
Здравство
Екологија
(Сандић, Екологија)
(Сандић, Заштита)
(Николић, Здравство)
(Николић, Екологија)
Slika 2.10. Ograničenje a1=0 i a2=0
Na slici 2.11 predstavljena je situacija a1=1 i a2=0, što znači da ne mora svaki radnik raditi na bar
jednom projektu, ali na svakom projektu mora biti angaţovan bar jedan radnik. To znači da se
novi projekat ne moţe evidentirati, ako nije odreĎen bar jedan radnika da na njemu radi.
Радник ПројекатРади
(0,M) (1,N)
Симовић
Марковић
Сандић
Николић
Воде
Заштита
Здравство
Екологија
(Марковић, Воде)
(Сандић, Воде)
(Сандић, Заштита)
(Николић, Здравство)
(Николић, Екологија)
Slika 2.11. Ograničenje a1=1 i a2=0
Ako je a1=1 i a2=1, riječ je o realnom sistemu u kojem svaki radnik mora raditi na bar jednom
projektu i na svakom projektu mora biti angaţovan bar jedan radnik. Ekstenzija na slici 2.12
zadovoljava ovo ograničenje ali i ograničenja a1=0, a2=0 i a1=1, a2=0.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
36
Радник ПројекатРади
(1,M) (1,N)
Симовић
Марковић
Сандић
Николић
Воде
Заштита
Здравство
Екологија
(Марковић, Воде)
(Сандић, Воде)
(Сандић, Заштита)
(Николић, Здравство)
(Николић, Екологија)
(Симовић, Воде)
Slika 2.12. Ograničenje a1=1 i a2=1
2.3.2. Strukture sa kardinalitetima grupe N : 1
Ovaj slučaj, tj. b1=N, i b2=1 opisuje situaciju u realnom sistemu kada jedan entitetprve klase
moţe biti povezan sa jednim entitetom druge klase i kada jedan entitet druge klase moţe biti
povezan sa siše entiteta prve klase.
Slike 2.13 – 2.16 prikazuju četiri mogućnosti ovakvog povezivanja
Радник Радно_МјестоРаспоређен
(0,1) (0,N)
Симовић
Марковић
Сандић
Николић
Директор
Секретарица
Програмер
Пројектант
(Марковић, Секретарица)
(Сандић, Пројектант)
(Николић, Пројектант)
Slika 2.13.
Slika 2.13 prikazuje kardinalitet tipa poveznika R (E1(0,1):E2(0,N) što znači da svaki entitet
klase E1 moţe biti u vezi sa najviše jednim entitetom klase E2, dok svaki entitet klase E2 moţe
biti povezan sa više entiteta klase E1, ali ne mora svaki entitet klase E2 biti povezan sa bar jednim
entitetom klase E1.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
37
Радник Радно_МјестоРаспоређен
(1,1) (0,N)
Симовић
Марковић
Сандић
Николић
Директор
Секретарица
Програмер
Пројектант
(Симовић, Пројектант)
(Марковић, Секретарица)
(Сандић, Пројектант)
(Николић, Пројектант)
Slika 2.14.
Slika 2.14 prikazuje kardinalitet tipa poveznika R (E1(1,1):E2(0,N) što znači da svaki entitet
klase E1 mora biti povezan sa jednim i samo jednim entitetom druge klase, dok svaki entitet
klase E2 moţe biti povezan sa više entiteta klase E1, ali ne mora svaki entitet klase E2 biti
povezan sa bar jednim entitetom klase E1.
Радник Радно_МјестоРаспоређен
(0,1) (1,N)
Јовановић
Симовић
Марковић
Сандић
Николић
Директор
Секретарица
Програмер
Пројектант
(Јовановић, Директор)
(Симовић, Програмер)
(Марковић, Секретарица)
(Сандић, Пројектант)
(Николић, Пројектант)
Шаула
Slika 2.15.
Slika 2.15 prikazuje kardinalitet tipa poveznika R (E1(1,0):E2(1,N) što znači da su entiteti druge
klase egzistencijalno zavisni od entiteta prve klase, tako da je svaki entitet prve klase povezan da
najviše jednim entitetom druge klase, dok svaki entitet druge klase mora biti povezan sa bar
jednim entitetom prve klase.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
38
Радник Радно_МјестоРаспоређен
(1,1) (1,N)
Јовановић
Симовић
Марковић
Сандић
Николић
Директор
Секретарица
Програмер
Пројектант
(Јовановић, Директор)
(Симовић, Пројектант)
(Марковић, Секретарица)
(Сандић, Пројектант)
(Николић, Пројектант)
Шаула (Јовановић, Директор)
Slika 2.16.
Slika 2.16 prikazuje kardinalitet tipa poveznika R (E1(1,1):E2(1,N) što znači da svaki entitet
klase E1 mora biti u vezi sa jednim i samo jednim entitetom klase E2, dok svaki entitet klase E2
mora biti u vezi sa bar jednim entitetom klase E1.
2.3.3. Strukture sa kardinalitetima grupe 1 : 1
Slučaj b1=1 i b2=1 opisuje situaciju u realnom sistemu kada jedan entitet prve klase moţe biti
povezan sa jednim entitetom druge klase, a jedan entitet druge klase sa jednim entitetom prve
klase. Ova situacija se naziva jedan – prema – jedan i označava 1:1. U zavisnosti od vrijednosti
a1 i a2 moguća su tri slučaja kao na slikama 2.17-2.19.
Slika 2.17 prikazuje kardinalitet tipa poveznika R (E1(0,1):E2(0,1) što znači da svaki entitet jedne
klase moţe biti povezan sa sa najviše jednim entitetom druge klase.
Радник ОсигураникЈе
(0,1) (0,1)
Симовић
Марковић
Сандић
Николић
Полиса 4
Полиса 3
Полиса 2
Полиса 1
(Марковић, Полиса 3)
(Сандић, Полиса 1)
(Николић, Полиса 2)
Slika 2.17.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
39
Slika 2.18 prikazuje kardinalitet tipa poveznika R (E1(1,1):E2(0,1) što znači da svaki entitet prve
klase mora titi povezan sa jednim i samo jednim entitetom druge klase.
Радник ОсигураникЈе
(1,1) (0,1)
Марковић
Сандић
Николић
Полиса 4
Полиса 3
Полиса 2
Полиса 1
(Марковић, Полиса 3)
(Сандић, Полиса 1)
(Николић, Полиса 2)
Slika 2.18.
Slika 2.19 prikazuje kardinalitet tipa poveznika R (E1(1,1):E2(1,1) što znači da je svaki entitet
jedne klase povezan sa jednim i samo jednim entitetom druge klase.
Радник ОсигураникЈе
(1,1) (1,1)
Симовић
Марковић
Сандић
Николић
Полиса 4
Полиса 3
Полиса 2
Полиса 1
(Симовић, Полиса 4)
(Марковић, Полиса 3)
(Сандић, Полиса 1)
(Николић, Полиса 2)
Slika 2.19.
2.3.4. Rekuzivne veze
Rekurzivni tip poveznika predstavlja model relacije u jednom skupu, relacije koja povezuje
entitete jedne klase. Kardinaliteti ovog tipa mogu uzimati sve moguće vrijednosti (slike 2.20 i
2.21)
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
40
Радник Rukovodi
(0,N)
(0,1)
Симовић
Марковић
Сандић
Николић
(Сандић, Симовић)
(Николић, Марковић)
(Николић, Сандић)
Симовић
Марковић
Сандић
Николић
Slika 2.20.
Производ Саставница
(0,N)
(0,1)
Клип
Каросерија
Мотор
Голф 5
Пасат
Голг 5, Каросерија)
(Голф 5, Мотор)
(Мотор, Клип)
(Пасат, Каросерија)
(Пасат, Мотор)
Клип
Каросерија
Мотор
Голф 5
Пасат
Slika 2.21.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
41
2.3.5. Tip poveznika reda većeg od dva
Na slikama 222 – 2.24 prikazane su moguće situacije u slučaju da poveznik povezuje više od dva
entiteta
Студент ПрофесорИзвођење_
Наставе
(0,N)
(0,1)
Предмет
(0,N)
БРИ ПРЗ ОЗН ПРП
ОЗП НАЗ
Slika 2.22.
Студент ПрофесорИзвођење_
Наставе
(0,N)
(0,N)
Предмет
(0,N)
БРИ ПРЗ ОЗН ПРП
ОЗП НАЗ
Slika 2.23.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
42
Јовановић
Симовић
Марковић
Сандић
Студент
Унковић
Рашета
Стојановић
Лукић
Професор
(Сандић, Дизајн, Лукић)
(Марковић, Мултимедија, Лукић)
(Сандић, Математика, Стојановић)
(Сандић, Мултимедија, Лукић)
Извођење_Наставе
Дизајн
Мултимедија
Информатика
Математика
Предмет
(Симовић, Дизајн, Унковић)
Slika 2.24.
2.3.6. Slabi tip poveznika
2.4. Operacijska komponenta ER modela podataka
S obzirom na činjenicu da je ER model stekao popularnost kao osnova za razvoj logičkog
projektovanja baze podataka, ali ne i kao model na kojem bi bio zasnovan neki šire korišten
SUBP, ovdje se neće razmatrati operacijska komponenta ER modela.
2.5. Proširenja modela entiteta i poveznika
2.5.1. Potklasa i superklasa
2.5.1.1. Nasljeđivanje osobina
2.5.1.2. Specijalizacija
2.5.1.3. Generalizacija
2.5.1.4. Karakteristike IS_A hijerarhija
2.5.1.5. Cilj i efekti uvođenja IS_A hijerarhija
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
43
2.5.2. Kategorija i kategorizacija
2.5.3. Gerund
2.6. Heuristička uputstva za projektovanje modela realnog sistema putem ER modela
podataka
Model entiteta i poveznika je prije svega namijenjen za izgradnju pribliţne slike entiteta i
poveznika, koji egzistiraju u ljudskom intelektu, putem koncepata na nivou apstrakcije naziva
skupova sličnih entiteta i poveznika, uz eventualno navoĎenje njihovih zajedničkih osobina.
Osnovni preduslov za projektovanje modela statičke strukture realnog sistema predstavlja
precizno poznavanje tog realnog sistema. Precizno poznavanje realnog sistema znači
obezbjeĎenje informacija o parametrima, kao što su: njegova struktura, funkcije, ciljevi
poslovanja, pravila poslovanja i odnosi izmeĎu entiteta. Do tih saznanja se dolazi snimanjem
realnog sistema. Rezultati tog snimanja se, često, izraţavaju putem neformalnog, tekstualnog
opisa parametara realnog sistema. Zadatak projektovanja modela statičke strukture realnog
sistema se tada svodi na izradu ER dijagrama, prevoĎenjem navoda tog tekstualnog opisa u
koncepte ER modela podataka. Ovdje će se navesti neka heuristička uputstva za prevoĎenje
tekstualnog opisa u ER dijagrame.
Imenice ukazuju na potrebu uvoĎenja tipova entiteta.
Glagolski oblici ukazuju na potrebu uvoĎenja tipova poveznika, ili gerunda.
Fraze „bar jedan“, „najmanje jedan“, „više“ i slične, ukazuju na kardinalitete tipova
poveznika ili gerunda.
Postojanje različitih uloga entiteta jednog skupa u vezama sa entitetima drugih skupova,
ukazuje na potrebu uvoĎenja više tipova poveznika izmeĎu odgovarajućih tipova entiteta.
Veze između entiteta jednog skupa ukazuju na potrebu uvoĎenja rekurzivnog tipa poveznika.
Kod rekurzivnih veza je preporučljivo da se uloge entiteta eksplicitno navedu.
Vremensko prethođenje entiteta jednog skupa u odnosu na entitete nekog drugog skupa,
ukazuje na egzistencijalnu zavisnost entiteta drugog skupa od entiteta prvog skupa i potrebu
uvoĎenja minimalnog kardinaliteta a1=1.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
44
Potreba takvog selektivnog povezivanja entiteta tri ili više skupova, kod kojeg u vezi mogu
učestvovati samo entiteti, koji su već u nekakvoj drugoj vezi sa entitetima jednog (ili više)
drugih skupova, ukazuje na neophodnost korištenja gerunda, kao modela tih drugih veza.
Postojanje entiteta jednog skupa, sa specifičnim osobinama ili sa specifičnim vezama sa
entitetima drugih skupova, ukazuje na potrebu uvoĎenja takozvane IS_A hijerarhije, odnosno
hejerarhije superklase nad podklasama.
Postojanje entiteta sa istim ulogama, u okviru dva tarličita skupa entiteta, ukazuje na potrebu
uvoĎenja kategorije, odnosno objedinjavanje različitih tipova entiteta pod zajedničkim
nazivom kategorija.
Svako obiljeţje moţe pripadati samo jednom tipu entiteta ili samo jednom tipu poveznika
(tek u ekstenziji: pojave tipa poveznika nasljeĎuju ključeve povezanih pojava tipova entiteta,
pojave slabog tipa entiteta nasljeĎuju ključ pojave regularnog tipa entiteta, pojave potklase
nasljeĎuju ključ i osobine pojave superklase).
Tip entiteta ili tip poveznika sadrţi samo ona obiljeţja skupa entiteta ili skupa poveznika,
koja su bitna za realizaciju ciljeva postavljenih pred informacioni sistem.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
45
3. Koncepcija baze podataka i sistem za upravljanje bazom podataka
Da bi se stekla precizna predstava o bazama podataka, nije dovoljno samo definisati pojam baze
podataka. Potrebno je prvo baze podataka sagledati u kontekstu njihovog istorijskog razvoja.
Naime, vrijednosti svakog sistema, pa i baze podataka kao sistema se najbolje shvata ne samo na
osnovu poznavanja njega samog, već na osnovu činjenice da taj sistem predstavlja korak u
evoluciji rješavanja onih problema, koje prethodni sistemi nisu mogli da riješe.
Cilj ovog teksta je da kroz prikaz razvoja postupaka za organizovanje i upravljanje podacima i
putem analize prednosti i nedostataka svakog od razvojnih koraka, ukaţe na ideje i ciljeve baze
podataka, kao pristupa organizovanju podataka i na zadatke sistema za upravljanje bazama
podataka (SUBP). U tekstu se koristi pojam aplikacije u smislu skupa čije elemente čine
programi, strukture podataka i pravila za njihovo korištenje. Pri tome se podrazumijeva da je
aplikacija namijenjena za automatizovano praćenje ponašanja jednog dijela (na primjer, jedne
funkcije, kao što je prodaja) nekog realnog sistema.
3.1. O pojmu fizičke strukture podataka
U daljem tekstu često se koristi pojam fizičke strukture podataka. Fizička struktura podataka se
dobija kada se ekstenzionalni model realnog sistema ili samo jedne klase entiteta smjesti na
medijum memorijskog ureĎaja. Fizička struktura podataka zavisi od intenzionalnog modela,
tipova entiteta, tipova poveznika i njihovih obiljeţja, ali i od niza drugih parametara. U te
parametre spadaju:
definisane duţine vrijednosti obiljeţja,
postupci dodjele adresa lokacija memorijskog prostora pojavama tipova entiteta i poveznika,
postupci za memorisanje informacija o vezama izmeĎu pojava tipova entiteta i poveznika,
pomoćne strukture podataka, kao što su indeksi,
veličina fizičkih organizacionih jedinica podataka (blok, stranica),
raspodjela pojava tipova entiteta i poveznika po fizičkim organizacionim jedinicama
podataka,
karakteristike eksternog memorijskog ureĎaja i drugo.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
46
Postupci za dodjelu adresa i memorisanje veza, kao i eventualno, postojanje pomoćnih struktura
podataka odreĎuju organizaciju podataka. Ovi pojmovi su detaljno obraĎeni u literaturi, na
primjer[48].
3.2. Klasična organizacija datoteta
Automatska obrada podataka (AOP) kod koje su pojedine aplikacije jednog informacionog
sistema meĎusobno nezavisne i kod koje se za svaku aplikaciju kreiraju i odrţavaju posebne
datoteke sa svim potrebnim podacima, naziva se klasičnom. TakoĎe se klasičnim naziva i
odgovarajući pristup organizovanju podataka. Do druge polovine šezdesetih godina prošlog
vijeka to je predstavljalo i jedini poznat pristup organizovanju podataka informacionog sistema.
Ovaj se pristup sreće i danas. Ima svojih prednosti nad drugim pristupima, ali ima i ozbiljnih
nedostataka. Osnovna prednost klasičnog pristupa leţi u jednostavnodti projektovanja i
realizacije.
Informacioni sistem sa nepovezanim aplikacijama i posebnim datotekama za svaku aplikaciju,
vremenom dolazi u kontradikciju sa samim sobom, zbog neusaglašenosti podataka o istoj
komponenti stanja realnog sistema (objekta upravljanja) u različitim datotekama. Razlog za ovu
neusaglašenost predstavlja tzv. nekonzistentnost podataka, koja se ogleda u činjenici da ista
obiljeţja za iste entitete, imaju različite vrijednosti u datotekama različitih aplikacija. Pri tome,
svaka aplikacija, izolovano gledano, funkcioniše dobro. Objašnjenje ovog fenomena leţi u
nezavisnom razvoju pojedinih aplikacija i u vremenski neusaglašenom aţuriranju različitih
datoteka istim podacima. Uzrok ove pojave, svakako predstavlja redundantnost ili preopširnost
podataka.
Ozbiljan nedostatak klasične organizacije AOP predstavlja i čvrsta povezanost programa i
podataka. Svaki program sadrţi opis i logičke i fizičke strukture podataka datoteke koju koristi.
TakoĎe, procedure u programu zavise od fizičke strukture podataka.
U jednoj aplikaciji, istu datoteku moţe koristiti više programa i ako se zbog potreba jednog od
njih izmjeni logička ili fizička struktura te datoteke, moraju se mijenjati i svi drugi programi.
Ova činjenica vremenom dovodi do situacije kada se čak 80% programerskih resursa angaţuje
na odrţavanju (mijenjanju, kompiliranju i testiranju) postojećih programa. Posebno se često
mijenja logička struktura datoteke, kao posljedica izmjena pravila i uslova poskovanja u realnom
sistemu ili novih zahtijeva korisnika. Te promjene se reflektuju u potrebi dodavanja novih
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
47
obiljeţja ili ograničenja u logički opis zajedničke datoteke i do izmjene svih programa, koji se
koriste, bez obzira da li su izmjene strukture datoteke bitne za svaki od programa. Izmjene
fizičke strukture datoteke diktira potreba da se obezbjede uslovi za efikasnije izvršavanje jednog
od programa. Ta promjena ili povlači izmjene opisa datoteke i dijelova procedura, koji se bave
manipulisanjem podacima, u drugim programima, ili dovodi do potrebe da se vrši reorganizacija
datoteke za potrebe izvršavanja drugih programa.
Primjer 3.1..
Kao ilustracija zavisnosti programa i podataka moţe posluţiti i situacija, tipična za klasičnu
organizaciju podataka. Tu su karakteristične dvije vrste datoteka: takozvane matične i
transakcione datoteke. Matične datoteke sadrţe podatke o entitetima jedne klase, a transakcione
datoteke sadrţe podatke o dogaĎajima vezanim za entitete različitih klasa. Na početku obrade,
svaki slog transakcione datoteke proširuje se podacima iz svih potrebnih matičnih datoteka. Na
taj način se dobija datoteka, čiji tip entiteta sadrţi relativno velik broj obiljeţja. Ova datoteka
sluţi za davanje odgovora na veći broj informacionih zahtijeva, što znači da je koristi veći broj
programa. Izmjene logičke strukture jedne od matičnih datoteka, dovodi do izmjene strukture
proširene transakcione datoteke i do potrebe izmjene svih programa, koji ovu datoteku koriste.
3.3. Ideja baze podataka
Negativna iskustva klasične organizacije podataka i pokušaja da se do intergrisanog
informacionog sistema doĎe povezivanjem aplikacija, dovela je do definisanja novog pristupa za
realizaciju integrisanih informacionih sistema. Novi pristup je zasnovan na ideji da treba
integrisati podatke, a ne aplikacije. Rezultat integrisanja datoteka različitih aplikacija nazvan je
bazom podataka. Baza podataka nije predstavljala novu tehniku memorisanja podataka na
medijumima eksternih memorijskih ureĎaja, niti novu tehniku dodjela adresa lokacija slogovima,
već novi pristup upravljanju podacima.
Tri osnovna nedostatka klasične organizacije podataka predstavljaju:
nepovezanost aplikacija,
redundantnost podataka,
čvrsta povezanost programa i podataka.
Osnovne postavke koncepcije baze podataka su da se:
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
48
svi podaci jednog informacionog sistema integrišu u jednu fizičku strukturu – bazu podataka,
svi programi, pri obradi baze podataka, koriste standardizovanim softverskim rutinama,
takozvanim softverom za upravljanje bazom podataka (SUBP), koji preslikava fizičku
strukturu podataka na, programima poznatu, šemu baze podataka.
3.3.1. Fizička nezavisnost
Integracija podataka informacionog sistema u jednu fizičku strukturu podataka, moţe se shvatiti i
kao integracija podataka ranije nezavisno razvijenih datoteka za različite aplikacije. Pri tome,
nad skupom obiljeţja tipova entiteta datoteka, formira se takozvana šema kao struktura nad
skupom različitih tipova entiteta. Šema predstavlja apstraktni model realnog sistema i njegove
baze podataka. Idealni, ali i praktično nikad dostignuti cilj izgradnje šeme je da se svako
obiljeţje naĎe u samo jednom tipu entiteta, kako bi se izbjegla redundancija podataka.
Nad šemom se gradi odgovarajuća fizička struktura podataka, koja predstavlja samu bazu
podataka. Svaki program poznaje samo šemu i na osnovu nje, putem SUBP, koristi ili mijenja
stanje baze podataka. Pošto svi programi koriste istu šemu, fizička struktura baze podataka je
veoma kompleksna. Ovu kompleksnost nameće potreba različitih načina pristupa istim
podacimma za potrebe različitih programa.
Primjer 3.2.:
Za jedan program pojavama odreĎenog tipa entiteta treba pristupati saglasno rastućim
vrijednostima primarnog ključa, za potrebe drugog treba pristupiti grupama pojava istog tipa
entiteta saglasno vrijednostima nekog sekundarnog ključa, a za potrebe trećeg programa istim
pojavama treba pristupati direktno – transformacijom vrijednosti ključa u adresu. Da bi se to
postiglo, potrebno je kombinovati nekoliko vrsta organizacije podataka (u datom primjeru,
redom, spregnutu, indeksnu i rasutu).
Drugu dimenziju kompleksnosti fizičke strukture nameće potreba memorisanja veza (odnosa)
izmeĎu pojava različith tipova entiteta. SUBP ima zadatak da izoluje programe (i programere) od
kompleksnosti fizičke strukture podataka. MeĎutim, treba naglasiti da to SUBP ne radi
samostalno, već po prethodno specificiranim uputstvima. Ova uputstva radi takozvani
administrator baze podataka, jedan ili grupa visokostručnih ljudi, koji projektuju fizičku
strukturu baze podataka i brinu se o zaštiti baze podataka od neovlaštenog korištenja i od
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
49
uništenja. Administrator saopštava SUBP, putem specijalnih programa, uputstva vezana za
izgradnju strukture, za korištenje i aţuriranja baze podataka, što SUBP, na zahtjev korisničkih
programa, sprovodi. Kompleksnost projektovanja fizičke strukture baze podataka, njenog
generisanja i odrţavanja prenijeta je sa programera na administratora baze podataka, ali je
olakšano njeno korištenje i aţuriranje, što je ostalo u djelokrugu zadataka programera. Slika 3.1
daje grafički prikaz ove, osnovne, ideje koncepcije baze podataka.
Opisani pristup dovodi do niza poboljšanja u organizovanju i rukovanju podacima. To su:
smanjenje zavisnosti šeme i programa od fizičke strukture podataka,
smanjenje radundantnosti podataka,
poboljšanje konzistentnosti podataka,
zajedničko korištenje podataka od strane svih aplikacija.
Програм
#1
Програм
#2
Програм
#3
Шема
База података
СУБП
Slika 3.1. Koncepcija baze podataka
3.3.2. Logička nezavisnost
Ubrzo po uvoĎenju prvih baza podataka u upotrebu, postalo je očigledno da je potrebno
obezbijediti jedan dalji nivo nezavisnosti programa i podataka. Naime, šema se, u mnogim
slučajevima, pokazala veoma kompleksnom. TakoĎe, svaka promjena u šemi zahtijevala je
izmjene u svim programima. Pokazala se potreba za uvoĎenjem dva nivoa nezavisnosti programa
i podataka: nivoa logičke i nivoa fizičke nezavisnosti.
Logička nezavisnost znači da izmjene šeme ne smiju uticati na izmjene programa (naravno, pod
uslovom da se ne mijenjaju obiljeţja koja program baš koristi). Logička nezavisnost se postiţe
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
50
uvoĎenjem pojma podšeme. Podšema predstavlja pojam koji se odnosi na onaj dio šeme baze
podataka, koji je dovoljan za realizaciju zadataka jednog ili grupe programa.
Šema i podšema predstavljaju, redom, modele realnog sistema i jednog njegovog dijela. U
principu, ta dva modela se nalaze na istom nivou apstrakcije. Mada u odreĎenom smislu,
podšema moţe predstavljati model na višem nivou apstrakcije od šeme.
Naime, podšema sadrţi tipove entiteta koji se mogu konstruisati od obiljeţja različitih tipova
entiteta šeme. Dok tipovi entiteta šeme predstavljaju modele klasa entiteta realnog sistema,
tipovi entiteta podšeme mogu predstavljati model neke generalizacije klasa entiteta realnog
sistema, ili model neke kombinacije klasa entiteta.
Prema ovoj zamisli, svaki program koristi bazu podataka putem svoje podšeme. SUBP prevodi
zahtjev programa, definisan s obzirom na tipove entiteta podšeme, u analogan zahtjev, koji bi bio
definisan s obzirom na tipove entiteta u šemi. Dalje, SUBP prenosi iz baze podataka u operativnu
memoriju pojave tipova entiteta šeme i konstruiše od njih pojave tipova entiteta podšeme. Tek te
podatke SUBP prezentuje programu. Treba zapaziti da se pojam fizičke nezavisnosti odnosi na
činjenicu da izmjene u fizičkoj strukturi baze podataka ne smiju dovoditi do izmjene šeme,
podšeme i programa. Slika 3.2 ilustruje ideju realizacije logičke i fizičke nezavisnosti programa i
podataka.
Програм
#1
Програм
#2
Програм
#3Шема
База података
СУБП
...Програм
#n
Подшема
#1
Подшема
#2
Подшема
#m
Slika 3.2. Realizacija logičke i fizičke nezavisnosti programa i podataka
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
51
Primjer 3.3.:
Na slici 3.3. nacrtana je šema jedne male, hipotetičke univerzitetske baze podataka. Tip entiteta
Student sadrţi obiljeţja: broj indeksa (BRI), ime (IME), prezime (PRZ), broj poloţenih ispita
(BPU) i način stanovanja (NST). Tip entiteta Fakultet sadrţi obiljeţja: naziv fakulteta (NAF),
broj semestara (BRS), i ukupan broj studenata (BST). Tip entiteta Stan posjeduje obiljeţja:
oznaka stana (OZS), adresa (ADR), i kvalitet stanovanja (KST).
Студент
Студира
БРИ ИМЕ ПРЗ БРИ НСТ
Факултет Стан
Станује
НАФ ОЗСБРС БСТ АДР КСТ
(1,N) (1,1)
(1,N) (0,N)
Slika 3.3. Hipotetička univerzitetska baza podataka
Na slici 3.4. prikazane su dvije moguće podšeme sa slike 3.3. Treba zapaziti da izmeĎu tipova
entiteta šeme i podšema postoji odreĎena razlika. Tip entiteta Student_Fakultet podšeme #1,
konstruisan je od obiljeţja tipova entiteta Student i Fakultet iz šeme. Ključ tipa entiteta
Student_Fakultet je {BRI, NAF}. Tip entiteta Student u podšemi #2 sadrţi pravi podskup skupa
obiljeţja entiteta Student iz šeme.
Šema baze podataka se naziva i globalnom šemom u smislu da predstavlja model statičke
strukture kompletnog realnog sistema. Podšema se naziva i eksternom šemom. Opis fizičke
strukture baze podataka naziva se fizičkom šemom ili internom šemom.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
52
Студент
БРИ ИМЕ ПРЗ
Стан
Станује
ОЗС АДР КСТ
(1,1)
(0,N)
Студент_Факултет
БРИ ИМЕ ПРЗ БПИ НАФ
Подшема #1 Подшема #2
Slika 3.4. Prikaz mogućih podšema baze podataka
Šema i podšema baze podataka predstavljaju pojmove za čiji nivo apstrakcije je karakterističan
pojam obiljeţja. Na niţem nivou apstrakcije, za koji je karakterističan pojam podataka, javljaju
se redom, pojmovi globalnog pogleda i pogleda. Globalni pogled predstavlja logičku strukturu
podataka baze podataka. Pogled predstavlja takvu sliku baze podataka, kako je programer vidi na
osnovu podšeme. Globalni pogled predstavlja sliku baze podataka kako je zamišlja projektant
baze podataka.
Primjer 3.4.:
Slika 3.5 ilustruje odnos izmeĎu pojmova podšeme i pogleda. Pogled sa slike 3.5. bi odgovarao
viĎenju baze podataka, recimo, nekog referenta za studentski standard. Pogled koji bi odgovarao
podšemi #1 sa slike 3.4 odgovarao bi viĎenju baze podataka, recimo, nekog referenta za
studentska pitanja.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
53
Студент
БРИ ИМЕ ПРЗ
СтанСтанује
ОЗС АДР КСТ
(1,1) (0,N)
215
213
159
БРИ
Стојан
Јелена
Марко
ИМЕ
Симовић
Марковић
Јовановић
ПРЗ
215
213
159
БРИ
35
25
15
ОЗС
35
25
15
ОЗС
Милана Ракића 17
Саве Макаља 22
Краља Петра 1
АДР
4
3
5
КСТ
Slika 3.5. Ilustracija odnosa pojmova podšeme i pogleda
3.4. Uloga baze podataka u razvoju i korištenju informacionog sistema
Opisane karakteristike baze podataka predstavljaju osnovne ciljeve kojima treba teţiti pri njenoj
izgradnji. U kojoj će mjeri ti ciljevi biti dostignuti zavisi kako od znanja projektanata, tako i od
kvaliteta SUBP: Razvoj postupaka za organizovanje i upravljanje podacima imao je dva vaţna
efekta. To su povećanje produktivnosti programera i stvaranje preduslova za izgradnju
integralnih informacionih sistema. Prvi efekat ilustrovan je slikom 3.6, a drugi slokom 3.7.
МАШИНСКО
ПРОГРАМИРАЊЕ
УЛАЗНО-
ИЗЛАЗНЕ
РУТИНЕ
МЕТОДЕ
ПРИСТУПА
СИСТЕМИ ЗА
УПРАВЉАЊЕ
ДАТОТЕКАМА
СОФТВЕР ЗА
РУКОВАЊЕ
БАЗАМА
ПОДАТАКА
НАПОР ПОТРЕБАН ЗА ПИСАЊЕ
ДИЈЕЛА ПРОГРАМА ПОСВЕЋЕНОГ
УПРАВЉАЊУ ПОДАЦИМА
Slika 3.6. Ilustracija povećanja produktivnosti rada programera
Slika 3.6 sugeriše da je svaka nova etapa u razvoju programskih jezika i postupaka upravljanja
podacima donosila i smanjenje napora potrebnog za pisanje dijela programa posvećenog
upravljanju podacima. U fazi mašinskog programiranja, bilo je potrebno da se u program ugrade
i postupci za izgradnju fizičke strukture podataka i postupci za realizaciju razmjene podataka
izmeĎu eksternog memorijskog ureĎaja i operativne memorije.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
54
Pojava prvih operativnih sistema dovela je do upotrebe asemblerskih programskih jezika, a
smanjenje napora za pisanje dijela programa posvećenog upravljanju podacima je predstavljala
činjenica da su ti prvi operativni sistemi sadrţavali takoyvane ulazno – izlazne (U/I) rutine. U/I
rutine su gotovi programi za razmjenu podataka izmeĎu eksternog memorijskog ureĎaja i
operativne memorije, koje je trebalo samo uključiti u korisnički program.
Dalje smanjenje napora donosi pojava viših programskih jezika i metoda pristupa. Metode
pristupa su dijelovi operativnog sistema, koji brinu o fizičkoj strukturi podataka datoteke.
Omogućavaju da se u programu deklariše samo vrsta organizacije datoteke i da se u
proceduralnom dijelu programa inicira razmjena podataka datoteke i programa putem makro
poziva tipa READ i WRITE.
Sistemi za upravljanje datotekama donose gotove programe za često primjenjivane postupke
rada sa datotekama, ako što su: sortiranje, reorganizovanje strukture, prepisivanje sa jednog
medijuma na drugi i slično. Ti programi se pozivaju i specijalizuju putem naredbi komandnog
jezika operativnog sistema.
Baze podataka, sa mehanizmima za logičku i fizičku nezavisnost i specifikacionim jezicima za
manipulisanje podacima, dovode do daljeg smanjenja napora potrebnog za pisanje dijela
programa posvećenog upravljanju podacima.
Slika 3.7 ilustruje ideju izgradnje integrisanih informacionih sistema. Prema današnjem pristupu
projektovanju informacionih sistema, baza podataka predstavlja instrument njegove integracije,
te joj pripada centralno mjesto u strukturi informacionog sistema. Na nju se vezuju aplikacije
(podsistemi informacionog sistema) koji izvršavaju specifične zadatke putem svojih programa.
БАЗА
ПОДАТАКА
АПЛИКАЦИЈА #1 АПЛИКАЦИЈА #2
АПЛИКАЦИЈА #3АПЛИКАЦИЈА #n ...
Slika 3.7. Ilustracija koncepta integrisanog informacionog sistema
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
55
3.5. Sistem za upravljanje bazom podataka
Sistem za upravljanje bazom podataka je softverski proizvod koji omogućava efikasno:
formiranje, korištenje i mijenjanje baze podataka.
Da bi mogao da izvršava ove svoje zadatke, SUBP:
je zasnovan na nekom od modela podataka,
podrţava programske jezike za:
o definisanje strukture i uslova integriteta baze podataka,
o selekciju i izmjene (upis, brisanje i modifikacija) sadrţaja baze podataka,
posjeduje mehanizme za:
o upravljanje transakcijama,
o zaštitu od neovlaštenog pristupa podacima od strane korisnika,
o zaštitu baze podataka od uništenja,
o obezbjeĎenje efikasnog korištenja baze podataka,
o upravljanje distribuiranim dijelovima baze podataka.
Pošto je o modelima podataka bilo riječi u prethodnom tekstu, ovdje će se opisati ostale funkcije
SUBP.
3.5.1. Programski jezici i SUBP
Deklarisanje strukture baze podataka, po pravilu, se vrši putem posebnog jezika za definisanje
podataka. Postupci za kompleksna izračunavanja se pišu u nekom drugom programskom jeziku,
takozvanom jeziku domaćinu, a postupci selekcije i izmjene sadrţaja baze podataka se realizuju
putem naredbi jednog trećeg, takozvanog jezika za manipulisanje podacima. Naredbe
manipulacionog jezika se ugraĎuju u programe pisane u jeziku domaćinu. Razdvajanje
deklaracije strukture baze podataka od postupaka za selekciju, mijenjanje sadrţaja i
izračunavanja u posebne programe, posljedica je činjenice da su podaci u bazi podataka trajno
memorisani, te je njihovu intenzionalnu strukturu dovoljno opisati samo jednom, da bi se baza
podatakamogla višekratno koristiti i mijenjati.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
56
Kao što je već rečeno, šema baze podataka (intenzionalni opis baze podataka) se deklariše putem
jezika za opis podataka. Taj jezik predstavlja dio SUBP. Jezik za opis podataka predstavlja
notaciju za popis elemenata šeme baze podataka, putem koncepata nekog modela podataka.
Primjer 3.5.:
Korištenjem naredbi relacionog jezika podataka SQL i ne insistirajući na preciznoj sintaksi, opis
tipa entiteta Student iz šeme sa slike 3.3 imao bi sljedeći oblik:
CREATE TABLE Student
(BRI: integer NOT NULL,
IME: char(10), PRZ:char(10), BRI: integer, NST: char(10));
CREATE UNIQUE INDEX ON Student (BPI).
Prva linija ovog programskog koda ukazuje da SUBP treba da formira (praznu) tabelu sa
nazivom Student, u koju će se upisivati pojave odgovarajućeg tipa entiteta. Druga i treća linija
opisuju obiljeţja tipa entiteta sa naznakom da ih treba realizovati u obliku nizova karaktera
odreĎene duţine ili cijelih brojeva fiksne duţine. Četvrta linija ukazuje da SUBP treba da
formira i odrţava stablo pristupa (indeks) na osnovu vrednosti obiljeţja BRI, čime je fizička
organizacija skupa pojava tipa entiteta odreĎena kao indeksna. Fraze NOT NULL i UNIQUE
INDEX sluţe za deklarisanje ključa, a time jednog od uslova integriteta baze podataka.
Ostali tipovi entiteta i poveznika šeme iz primjera 3.3 bili bi opisani na sljedeći način:
CREATE TABLE Fakultet
(NAF: char(15) NOT NULL, BRS: integer, BST: integer);
CREATE UNIQUE INDEX ON Fakultet (NAF)
CREATE TABLE Stan
(OZS: integer NOT NULL, ADR: char(25), KST: integer);
CREATE UNIQUE INDEX ON Stan (OZS)
CREATE TABLE Stu_Fa
(BRI: integer NOT NULL, NAF: char(15) NOT NULL);
CREATE UNIQUE INDEX ON Stu_Fa (BRI, NAF)
CREATE TABLE Stu_Sta
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
57
(BRI: integer NOT NTLL, OZS: char(25) NOT NULL);
CREATE UNIQUE INDEX ON Stu_Sta (BRI).
Jezik za opis podataka se koristi za opis šeme baze podataka, pri njenom projektovanju ili pri
izmjeni projekta. Opisivanje podšema i pogleda se vrši ili u istom ili u nekom sličnom jeziku
podataka.
Primjer 3.6.:
Podšema iz primjera 3.3. bi, u SQL jeziku bila opisana na sljedeći način:
CREATE VIEW Student_Fakultet AS
SELECT BRI, IME, PRZ, BPI, NAF
FROM Student S, Stu_Fa F
WHERE S.BRI=F.BRI
Prva naredba ovog programa nalaţe SUBP da formira pogled pod nazivom Student_Fakultet.
Druga linija ukazuje na obiljeţja, čije vrijednosti treba da sadrţi, treća linija ukazuje kojim
tipovima entiteta ta obiljeţja pripadaju, a četvrta da se pojave tipa entiteta Student_Fakultet
dobijaju povezivanjem pojava tipa entiteta Student i tipa poveznika Stu_Fa sa istim BRI
vrijednostima.
Za definisanje operacija na bazi podataka koristi se poseban jezik, koji se naziva ili jezikom za
manipulisanje podacima ili upitnim jezikom. Taj jezik se koristi za izraţavanje naredbi za
selekciju dijela baze podataka i za mijenjanje sadrţaja baze podataka. Termin upitni jezik se
često koristi kao sinonim za termin jezik za manipulisanje podacima. Strogo govoreći, pojam
upita se odnosi samo na one naredbe, koje vrše selekciju dijela baze podataka, meĎutim, upitni
jezici su predviĎeni za interaktivni rad sa bazom podataka i, po pravilu, sadrţe kako naredbe za
selekciju, tako i naredbe za aţuriranje (mijenjanje sadrţaja) baze podataka.
Primjer 3.7.:
SQL jezik podataka relacionog modela posjeduje kako naredbe za definisanje podataka, tako i
naredbe za selekciju i manipulisanje podacima. Izbor svih studenata nekog fakulteta, koji se zovu
Ana, realizovao bi se putem programa:
SELECT*FROM Student_Fakultet
WHERE NAF ="Fakultet" AND IME ="Ana"
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
58
gdje * ukazuje da se traţe vrijednosti svih obiljeţja, definisanih pogledom Student_fakultet.
Upis podataka o novom studentu bi se vršio putem programa
INSERT INTO Student
VALUES (159, "Marko", "Jovanović", 0, "studentski dom").
Korištenje i aţuriranje baze podataka moţe se vršiti bilo u interaktivnom bilo u paketnom reţimu
obrade. Kada je riječ o interaktivnom reţimu postoje dvije mogućnosti. Jedna je da se program
piše "ad hoc", korištenjem naredbi upitnog jezika i da se te naredbe odmah interpretiraju, a druga
je mogućnost da postoji unaprijed napisan i preveden program, koji se po potrebi poziva i
izvršava. Programi ovog drugog tipa nazivaju se (interaktivnim) aplikativnim programima.
Razlog za postojanje aplikativnih programa ne leţi samo u činjenici da korisnici, često, nisu u
stanju da napišu program u upitnom jeziku, već i u činjenici da upitni jezici, najčešće, ne
posjeduju naredbe za kompleksnija izračunavanja. Isto tako, često je potrebno da program
sporovede neki dijalog sa korisnikom ili da rezultate selekcije prikaţe štampaču. Zbog toga se
aplikativni programi pišu u jeziku domaćinu.
Jezik domaćin je neki od proceduralnih programskih jezika treće generacije ili jezik četvrte
generacije. Naredbe jezika domaćina se koriste za izračunavanja, donošenje odluka, dijalog sa
korisnikom, za sve osim za stvarnu selekciju i mijenjanje sadrţaja baze podataka. Naredbe
manipulacionog jezika se ugraĎuju u program, pisan u jeziku domaćinu. Kooperativni rad
izmeĎu aplikativnog programa i naredbi manipulacionog jezika odvija se , u principu, na sljedeći
način: Aplikativni program posjeduje, u operativnoj memoriji, zonu sa lokalnim podacima. Sa
tim podacima aplikativni program manipuliše na uobičajen način. Kada se, pri izvršavanju
programa, naiĎe na zahtjev za selekciju podataka, podaci se, iz baze, prenose u zonu sa lokalnim
podacima. Rezultati izračunavanja se, po potrebi, iz zone sa lokalnim podacima, upisuju u bazu
podataka.
3.5.2. Upravljanje transakcijama
U opštem slučaju bazu podataka konkurentno koristi više različitih programa (Napomena:
konkurentno korištenje znači prividno istovremeno korištenje, pri čemu je prividna
istovremenost posljedica multiprogramskog rada računara.) Sam program moţe biti aplikativni
program, pisan u nekom jeziku domaćinu ili jednostavan interaktivni upit realizovan korištenjem
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
59
upitnog jezika. Različiti korisnici mogu inicirati i više različitih izvršenja istog programa. Jedno
izvršavanje svakog programa naziva se transakcijom.
Primjer 3.8.:
Svako izvršavanje svakog od programa iz primjera 3.7 predstavlja jednu transakciju.
Konkurentno korištenje baze podataka krije u sebi odreĎene opasnosti. Naime, ako jedna
transakcija učita neki podatak u svoj radni prostor, a druga ga, odmah nakon toga, u bazi
podataka izmijeni, prva transakcija će koristiti netačan podatak. Očigledno, neophodno je
spriječiti istovremeno korištenje istog podatka od strane dvije transakcije. Opisani problem se
rješava uvoĎenjem pojma zaključavanja dijela baze podataka. Zaključavanjem dijela baze
podataka, transakcija spriječava druge transakcije da pristupe tom dijelu baze podataka bilo u
cilju čitanja, bilo u cilju njegovog mijenjanja.
Dio baze podataka koji se podvrgava zaključavanju moţe biti:
skup pojava nekog tipa entiteta ili tipa poveznika,
odreĎeni broj pojava nekog tipa entiteta ili tipa poveznika,
jedna pojava nekog tipa entiteta ili tipa poveznika,
samo jedan dio neke pojave.
Različiti SUBP zaključavaju dijelove baze podataka različite veličine. U daljem tekstu će se
najmanji dio baze podataka, koji se moţe zaključati, nazivati objektom zaključavanja.
Primjer 3.9.:
Neka je A obiljeţje sa cjelobrojnim vrijednostima, a T1 i T2 transakcije., koje treba da učitaju A.
iz baze podataka u svoj radni prostor, povećaju mu vrijednost za 1 i upišu ga nazad u bazu
podataka. U tabeli 3.1. prikazan je jedan od mogućih redoslijeda izvršavanja instrukcija
transakcija T1 i T2, kao i vrijednosti obiljeţja A u bazi podataka i u radnim prostorima
transakcija T1 i T2. Iako su obe transakcija dodale po 1, vrijednost obiljeţja A je u bazi podataka
povećana samo za jedan umjesto za dva.
Rješenje ovog problema je da transakcija T1, prije čitanja sadrţaja obiljeţja A iz baze podataka,
izvrši njegovo zaključavanje i time spriječi transakciju T2 da ga i ona prenese u svoje radno
područje. Transakcija T2 će moći da pročita sadrţaj obiljeţja A tek kada ga transakcija T1
oslobodi.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
60
Tabela 3.1. Ilustracija konkurentnog korištenja baze podataka
A u bazi
podataka 3 3 3 3 4 4
T1 ČITAJ A POSTAVI
AA+1 PIŠI A
T2 ČITAJ A POSTAVI
AA+1 PIŠI A
A u radnom
području T1 3 3 4 4 4 4
A u radnom
području T2 3 3 4 4 4
Primjer 3.9 sugeriše da program, koji bazu podataka koristi konkurentno sa drugim programima,
pored naredbi za čitanje i pisanje u bazu podataka, treba da sadrţi i naredbe za zaključavanje
onih objekata kojima ţeli da pristupi, bilo u cilju čitanja bilo u cilju njihovog mijenjanja i da te
objekte prvo treba da zaključa, pa tek onda da im pristupa,a da otključavanje objekata mora
uslijediti tek nakon upisa u bazu podataka svih izmijenjenih ili novih objekata. Pri tome, nijedna
transakcija ne moţe da zaključa neki objekt, koji je već zaključala neka druga transakcija. Ako je
objekat već zaključan, tansakcija mora da čeka dok ga transakcija koja ga je zaključala ne
otključa.
Primjer 3.10.:
Pseudokod programa iz primjera 3.9, proširen naredbama za zaključavanje i otključavanje,
izgledao bi ovako:
ZAKLjUČAJ A
ČITAJ A
POSTAVI AA+1
UPIŠI A
OTKLjUČAJ A
Neka su T1 i T2 različita izvršenja ovog programa. Ako se transakcija T1 prva pokrene, a
obiljeţje A nije zaključano, T1 će ga zaključati. Transakcija T2 će moći da zaključa A tek kada
ga T1 odključa. Saglasno tome, nije teško utvrditi da će nakon završetka transakcije T2
vrijednost obiljeţja A u bazi podataka iznositi 5.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
61
Naţalost, uvoĎenjem mehanizama zaključavanja objekata, ne rješavaju se svi problemi
konkurentnog korištenja baze podataka. Naime, zaključavanje moţe dovesti do pojave dva nova
nepogodna fenomena. To su:
izgladnjavanje
uzajamno zaključavanje.
Izgladnjavanjem se naziva situacija u kojoj jedna transakcija praktično neograničeno dugo
vremena čeka da joj se omogući zaključavanje nekog objekta, jer SUBP stalno dodjeljuje pravo
zaključavanja tog objekta nekoj drugoj transakciji. Naziv ovog fenomena treba da ukaţe da neka
transakcija stalno traţi, a nikako ne dobija pravo da izvrši zaključavanje odreĎenog objekta.
Primjer 3.11.:
Ako bi, u prethodnom primjeru, tokom čekanja transakcije T2 na završetak transakcije T1, prvo
neka transakcija T3, a zatim, jedna nakon druge, transakcije T4, T5,... zatraţile i dobile pravo da
zaključaju obiljeţje A, transakcija T2 bi mogla čekati na pravo zaključavanja obiljeţja A veoma,
ako ne i neograničeno, dugo.
Jednostavan mehanizam izbjegavanja izgladnjavanja predstavlja uvoĎenje pravila da transakcije
stiču pravo na zaključavanje nekog objekta prema redoslijedu postavljanja zahtijeva za to
zaključavanje.
Mnogo ozbiljniji problem konkurentnog korištenja baze podataka predstavlja pojava uzajamnog
zaključavanja. Do uzajamnog zaključavanja dolazi kada svaka transakcija iz jednog skupa T od
dvije ili više transakcija čeka da zaključa neki objekat, koji je već zaključala neka druga
transakcija iz skupa T. Pošto je svaka transakcija iz T u stanju čekanja, ne moţe da otključa
objekat, koji neka druga transakcija ţeli da zaključa, tako da sve transakcije iz T ostaju u stanju
čekanja. To čekanje moţe trajati neograničeno dugo. Ovu situaciju ilustruje sljedeći primjer.
Primjer 3.12.:
Neka su T1 i T2 dvije transakcije. Sljedeće naredbe ovih transakcionih programa su bitne s tačke
gledišta pojave uzajamnog zaključavanja:
T1: ZAKLjUČAJ A ZAKLjUČAJ B OTKLjUČAJ A OTKLjUČAJ B
T2: ZAKLjUČAJ B ZAKLjUČAJ A OTKLjUČAJ B OTKLjUČAJ A.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
62
Ostale naredbe ovih programa su nebitne za dalja razmatranja fenomena uzajamnog
zaključavanja. Ako: izvršavanja T1 i T2 započnu pribliţno istovremeno, T1 zaključa A, a T2
zaključa B, doći će do uzajamnog zaključavanja. Transakcija T1 čeka da transakcija T2 otključa
B, dok transakcija T2 čeka da T1 otključa A.
Postoji više postupaka za borbu protiv uzajamnog zaključavanja. Ovdje će se prikazati tri takva
postupka. Prva dva sprečavaju pojavu fenomena uzajamnog zaključavanja, dok treći njegovu
pojavu detektuje i poništava.
Prema prvom postupku, svaka transakcija mora zahtijevati od SUBP dozvolu za sva
zaključavanja odjednom. Ako ih dobije, nastavlja sa radom, inače prelazi u stanje čekanja.
Kod drugog postupka se uvodi neko linearno ureĎenje u skup svih objekata, tako da transakcije
postavljaju svoje zahtjeve za zaključavanje tačno tim redoslijedom.
Primjer 3.13.:
Lako se da zaključiti da u slučaju primjene prvog postupka zaključavanja, transakcije T1 i T2 iz
primjera 3.12 neće doći u stanje uzajamnog zaključavanja, jer će SUBP dozvoliti transakciji T1
da zaključa i A i B.
Isto tako, ako se u linearnom ureĎenju, A nalazi ispred B, tada i transakcija T1 i transakcija T2
moraju prvo traţiti da zaključaju A. Ako T1 prva zaključa A, tada će transakcija T2 morati da
čeka da ga transakcija T1 otključa, te ponovo neće doći do uzajamnog zaključavanja.
U slučaj trećeg postupka se ništa ne preduzima da bi se pojava uzajamnog zaključavanja
spriječila. Umjesto toga, SUBP periodično provjerava da li je do uzajamnog zaključavanja došlo.
Ako otkrije pojavu uzajamnog zaključavanja, SUBP vraća bar jednu od transakcija iz skupa T na
početak i poništava sve promjene u bazi podataka, koje je ta transakcija izvršila.
3.5.3. Zaštita od neovlaštenog korištenja
SUBP mora posjedovati mehanizme za zaštitu baze podataka od neovlaštenog korištenja u
višekorisničkom radu. Da bi se ti mehanizmi mogli realizovati, uvode se pojmovi korisničkog
imena i korisničke lozinke. Korisničko ime i korisničku lozinku dodjeljuje administrator baze
podataka svakom korisniku u cilju njegovog identifikovanja i sticanja dozvole za rad. Tu
identifikaciju i davanje dozvole vrše operativni sistem i SUBP.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
63
Jadan od mehanizama za zaštitu od neovlaštenog korištenja, predstavlja podšema ili pogled.
Selektivnim prikazivanjem tipova entiteta šeme u podšemi i izostavljanjem odreĎenih
obiljeţjatipa entiteta šeme iz njegove slike u podšemi, izostavlja se informacijao njihovom
postojanju u šemi, tako da korisnik podšeme niti je svjestan postojanja tih tipova entiteta i
obiljeţja niti moţe da koristi odgovarajuće podatke. MeĎutim taj mehanizam nije dovoljno strog.
Zato se uvodi pojam privilegije. Privilegije se povezuju sa elementima intenzionalnog opisa baze
podataka, ili čak za elemente ekstenzije. Pod elementom intenzionalnog opisa baze podataka
podrazumijeva se: obiljeţje, tip entiteta, tip poveznika ili podšema, odnosno pogled. Kada je
riječ o elementima ekstenzije, riječ je o takvim podskupovima pojava tipova entiteta koji
posjeduju odreĎenu osobinu. Privilegije se definišu za svaki elemenat intenzionalnog opisa baze
podataka, a odnose se na dozvolu:
samo čitanja pojava,
čitanja i upisivanja novih pojava,
čitanja i modifikovanja postojećih pojava,
čitanja i brisanja postojećih pojava,
čitanja i modifikovanja pojava bez ograničenja.
Privilegije se još nazivaju i autorizacijom ili pravom pristupa. Podatke o privilegijama, SUBP
srţi u takozvanoj autorizacionoj tabeli. Autorizaciona tabela sadrţi trojke (korisnik, elemenat
intenzionalnog opisa, privilegija), čime se definiše šta odreĎeni korisnik smije da radi sa
pojavama posmatranog elementa intenzionalnog opisa baze podataka.
3.5.4. Zaštita od uništenja
Baza podataka moţe doći u nekorektno stanje iz mnogo razloga. U njih spadaju:
nekonzistentnost podataka, bilo zbog greške u definisanju, realizaciji ili izvršavanju uslova
integriteta,
greška u aplikativnom programu,
pogrešno unijeti podaci od strane korisnika,
greška SUBP ili operativnog sistema,
kvar računara,
greška izazvana kolebanjima u: električnom napajanju, temperaturi i vlaţnosti okoline,
prirodne katastrofe,
namjerna oštećenja.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
64
Ta zaštitu baze podataka od uništenja, pristupa se postupku oporavka baze podatka. Termin
oporavak se koristi za postupak poništavanja efekata neke otkrivene greške i prevoĎenje baze
podataka iz nekorektnog u korektno stanje. U tom cilju, SUBP posjeduje mehanizme za:
kopiranje baze podataka na rezervni medijum,
uvoĎenje žurnal datoteke, koja sadrţi sve promjene sadrţaja baze podataka tokom odreĎenog
intervala vremena,
oporavak baze podataka.
Pravljenje kopija korektnih stanja baze podataka se izvršava ili nakon odreĎenog broja promjena
sadrţaja baze podataka ili u odreĎenim periodima vremena. Pri tome se, uvijek, čuva samo
nekoliko posljednjih kopija.
Ključni mehanizam za zaštitu baze posdataka od uništenja je voĎenje ţurnal datoteke. Svaka
transakcija, koja je koristila bazu podataka, biljeţi se na ţurnal datoteku. Pri tome, obično se
evidentiraju sljedeći podaci: identifikacija inicijatora transakcije, tačno vrijeme iniciranja
transakcije, jedinstvena identifikacija transakcije i, za transakcije koje su dovele do izmjene
sadrţaja baze podataka, biljeţe se adrese lokacija svih podataka, kojima je pristupano, ako i
vrijednosti podataka prije i poslije izmjena. Vrijednosti podataka prije izmjene se nazivaju
prethodnom slikom, a vrijednosti podataka nakon izmjene naknadnom slikom.
Kada se utvrdi da je stanje baze podataka nekorektno, mehanizmi za oporavak baze podataka se
koriste za vraćanje baze podataka u korektno stanje. Postoje dva tipa postupaka za oporavak i to:
oporavak unaprijed,
oporavak unazad.
Oporavak unaprijed je takav postupak, kod kojeg se posljednja korektna kopija baze podataka
mijenja, saglasno izmjenama iz ţurnal datoteke, do stanja neposredno prije nastanka greške. Pri
tome, na kopiju se primjenjuju naknadne slike onih promjena, koje su nastale tokom pravljenja
kopije. Oporavak unaprijed se, obično, primjenjuje pri oštećenju većih dijelova baze podataka i,
tokom oporavka unaprijed, baza podataka se operativno ne koristi.
Oporavak unazad se koristi kada se neka transakcija, koja sadrţi niz izmjena sadrţaja baze
podataka, završi neuspješno. Oporavak unazad znači poništavanje svih izmjena, koje je
posmatrana transakcija izvršila nad bazom podataka. Pri tome se koriste odgovarajuće prethodne
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
65
slike ţurnal datoteke. Oporavak unazad se izvršava u reţimu operativnog korištenja baze
podataka.
3.5.5. Efikasnost
Pod efikasnim korištenjem baze podataka, na ovom mjestu će se smatrati kako brz razvoj i
implementacija programa za korištenje baze podataka, tako i brza selekcija i manipulisanje
sadrţajem baze podataka. Savremeni SUBP posjeduju odreĎene mehanizme za realizaciju tih
zadataka.
Za brz razvoj i implementaciju korisnicima stoje na raspolaganju:
neproceduralni jezici,
mehanizmi
o ograničenja,
o okidači,
o procedure baze podataka,
o nezavisnost programa i podataka.
Za obezbjeĎenje efikasne selekcije i manipulisanja sadrţajem baze podataka, savremeni SUBP
koriste:
optimizaciju upita,
metode pristupa,
različita rješenja zaključavanja.
3.5.5.1. Produktivnost razvoja i implementacije programa
Uticaj neproceduralnih jezika na ovom mjestu se neće razmatrati. Ovdje će paţnja biti posvećena
mehanizmima za povećanje produktivnosti rada programera.
Ograničenja su pasivni mehanizmi, koje SUBP koristi da spriječi dovoĎenje sadrţaja baze
podataka u koliziju sa pravilima ponašanja i poslovanja u realnom sistemu. Da bi SUBP mogao
da aktivira te mehanizme, uslovi integriteta, kao što su integritet domena, jedinstvena vrijednost
ključa, kardinalitet tipa poveznika, saopštavaju mu se putem naredbi jezika za opis podataka.
Ograničenja su pasivni mehanizmi jer se aktiviraju tek kada korisnik pokuša da unese podatke,
koji narušavaju uslove integriteta.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
66
Narvano, sva ograničenja se mogu ugraditi i u aplikativne programe, koji koriste bazu podataka.
MeĎutim, to rješenjeje mnogo lošije od onoga kada se ograničenja ugraĎuju u bazu podataka, iz
dva razloga. Prvi leţi u činjenici da sprovoĎenje uslova integriteta putem programa zanči da se
odgovornost za integritet baze podataka prenosi na programe (i programere). Na taj način se isti
zadatak višestruko ponavlja i uvijek ostaje nedoumica da li je baš svugdje korektno sproveden. U
takvim uslovima, o izmjenama uslova integriteta baze podataka nema ni smisla govoriti, jer be te
izmjene zahtijevale intervencije u velikom broju programa. Drugi rezlog je da se baza podataka
moţe koristiti kako putem aplikativnih programa tako i putem takozvanih "ad hoc" programa,
koji se interaktivno kreiraju i odmah izvršavaju. Ako se pretpostavi da je sprovoĎenje uslova
integriteta putem aplikativnih programa, koji se paţljivo pišu, prevode i optimiziraju, moguće, to
uopšte ne vaţi za "ad hoc" programe. Kada se saopšte SUBP, ograničenja postaju centralni
mehanizam, koji ne moţe da zaobiĎe nijedan program.
Primjer 3.14.:
Slika 3.8 ilustruje situaciju kada je SUBP saopšteno pravilo "u bazi podataka ne mogu postojati
podaci o narudţbini, ako ne postoje podaci o poslovnom partneru, koji je tu narudţbinu izvršio".
Ako program pokuša da izbriše podatke o nekom poslovnom partneru, koji ima evidentirane
narudţbine, SUBP će poslati programu poruku da to brisanje ne moţe da se izvrši.
ПРОГРАМ
БРИШИ пословног партнера
бриши не може
ОГРАНИЧЕЊЕ
Пословни_партнер
Наруџбине
Slika 3.8. Ilustracija primjene ograničenja (pravila) u bazi podataka
Okidač je programska procedura, povezana sa skupom pojava jednog tipa entiteta u bazi
podataka. Te procedure se aktiviraju putem odreĎenih dogaĎaja, kao što su:
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
67
upis nove pojave,
brisanje,
modifikacija postojeće pojave tipa entiteta.
Rad okidača je van kontrole programa, a njegovo izvršenje je obavezno. SUBP inicira izvršavnje
okudača, čim nastupi dogaĎaj koji ga aktivira. I okidači su centralni mehanizmi, koje ne moţe
zaobići nijedan program.
Primjer 3.15.:
Slika 3.9 ilustruje situaciju, kada je okidač napravljen tako da, kada se iz programa pokušaju
brisati podaci o jednom poslovnom partneru, okidač izbriše i podatke o svim njegovim
porudţbinama.
Okidači su aktivni mehanizmi, koji odrţavaju propisane odnose izmeĎu podataka o različitim
entitetima. Mijenjaju podatke o jednim entitetima, kada se mijenjaju podaci o drugim. Ni
njihovog postojanja korisnici baze podataka nisu svjesni.
ПРОГРАМ
БРИШИ пословног партнера
ОКИДАЧ
Пословни_партнер
Наруџбине
Slika 3.9. Ilustracija rada okidača
Za razliku od ograničenja i okidača, procedure baze podataka se ne sprovode automatski. To su
po pravilu kompleksni, prekompilirani i optimizirani programi. Čuvaju se centralno u bazi
podataka. Korisnički programi ih, po potrebi, pozivaju da bi ih primijenili na dio transakcije.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
68
Primjer 3.16.:
Na slici 3.10 prikazan je slučaj, kada program poziva proceduru baze podataka za izračunavanje
poreza. Ta procedura koristi podatke o zaposlenima i o poreskim stopama, da bi izračunala
porez.
ПРОГРАМ
ИЗРАЧУНАЈ порез
позив одговор
ПРОЦЕДУРА БАЗЕ ПОДАТАКА
Порези
Запослени
Slika 3.10. Ilustracija rada procedure
Okidači su namijenjeni za aktivno sprovoĎenje uslova integriteta baze podataka, a ograničenja za
pasivnu kontrolu. Procedure baze podataka obezbjeĎuju centralnu definiciju kompleksnih
programskih kodova. Sve to dovodi do:
povećanja produktivnosti programera najmanje za 30%,
neuporedivo bolje kontrole baze podataka, nego kada se ti mehanizmi ugraĎuju u programe
repetitivnim pisanjem istog koda.
Najveći efekat se postiţe u odrţavanju programa, jer je centralnim definisanjem mehanizama
smanjen obim programskog koda, a promjene u mehanizmima ne utiču na program.
Nazavisnost programa i podataka stvarno se realizuje u relacionim sistemama za upravljanje
bazom podataka. Mnoge izmjene baze podataka, kao što su dodavanje novog obiljeţja,
dodavanje novog tipa entiteta u šemu baze podataka, izmjena fizičke strukture baze podataka,
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
69
uopšte ne utiču na programe. Čak šta više, te izmjene se vrše dinamički, tokom izvršavanja
programa. TakoĎe, zbog tih izmjena, bazu podataka ne treba reorganizovati kopiranjem i
ponovnim punjenjem. Najveći efekti se postuţu u odrţavanju programa, jer je, zbog centralnog
definisanja mehanizama smanjen obim programskog koda, a izmjene u mehanizmima ne utiču na
programe.
3.5.5.2. Performanse korištenja baze podataka
Kao što je već rečeno, optimizator upita, metode pristupa i postupci zaključavanja značajno utiču
na performanse korištenja baze podataka.
Optimizator upita predstavlja suštinsku komponentu za obezbjeĎenje performantne obrade
realcione baze podataka. Potreba njegovog postojanja je posljedica deklarativnosti
manipulacionog jezika relacionog modela podataka. U tom jeziku, programer, preteţno koristeći
intenzionalni opis baze podataka, definiše koji dio baze podataka treba da se selektuje, a zadatak
je SUBP da, poznajući fizičku strukturu baze podataka, brojeve pojava tipova entiteta i
poveznika i raspodjelu vrijednosti obiljeţja odredi kako taj zahtjev treba da se, na efikasan način
izvrši.
Postoje tri osnovne vrste optimizatora i to:
sintaksni,
zasnovan na cijeni,
statistički.
Sintaksni optimizator upita je zasnovan na strukturi samog upita, definisanog putem naredbi
upitnog jezika. Tu strukturu odreĎuje sam programer. MeĎutim, sa logičke tačke gledišta isti
upit, moţe se izvršavati sa veoma različitim vremenima, u zavisnosti od redoslijeda navoĎenja
obiljeţja, operatora i uslova.Takvo rješenje optimizatora upita zahtijeva od programera da, u
stvari on, vodi računa o optimalnosti upita.
Optimizator zasnovan na cijeni koristi restriktivnost operatora poreĎenja i podatke o brojevima
pojava tipova entiteta i poveznika. Svaki operator poreĎenja ima svoju ocjenu restriktivnosti ("="
je restriktivnije od ""). Kombinovanjem ocjene restriktivnosti operatora sa brojevima pojava
tipovaentiteta i poveznika, na koje se operatori primjenjuju, dobija se cijena "plana izvršavanja"
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
70
upita.SUBP analizira više mogućih planova izvšavanja za dati upit, a realizuje najjeftiniji.Ovakvi
optimizatori upita daju dobre rezultate u praksi.
Statistički optimizator upita radi na sličnom principu kao i optimizator zasnovan na cijeni, ali
koristi još i histograme sa raspodjelom vrijednosti ključa za donošenje odluke o najboljem planu
izvršenja upita. Statistički optimizatori predstavljaju najbolje rješenje, ali je za njihovu primjenu
potrebno povremeno vršiti inoviranje histograma sa raspodjelom vrijednosti ključa.
Kada su metode pristupa u pitanju, SUBP ili koriste usluge upravljača datotekama operativnog
sistema ili imaju svoje metode pristupa. Svi relacioni SUBP podrţavaju:
serijsku organizaciju podataka (pile),
indeksnu organizaciju sa B - stablom,
a neki SUBP podrţavaju još i:
rasutu (hash).
indeks - sekvencijalnu organizacija.
Bitan uticaj na performanse korištenja baze podataka u višekorisničkom radu ostvaruje i veličina
objekta zaključavanja. Najbolje performanse se postiţu, kada se zaključavanje vrši na nivou
pojave tipa entiteta ili čak samo dijela pojave.
3.5.6. Distributivnost
Potreba efikasnog upravljanja i korištenja distribuirane baze podataka diktira potrebu postojanja
mehanizama, kao što su:
distribuirani riječnik,
dvofazni komit,
automatski replikator,
lokacijska transparentnost,
klijent /server arhitektura.
3.5.7. Arhitektura sistema baze podataka
Na slici 3.11 je nacrtana struktura odnosa sistema za upravljanje bazom podataka. Najvaţnije
dijelove ovog sistema predstavljaju:
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
71
procesor upitnog jezika,
procesor opisa šeme,
upravljač baze podataka,
riječnik.
Projekat šeme baze podataka, opisan putem takozvanog jezika za opis podataka, uvodi se u
procesor opisa šeme. Procesor opisa šeme je prevodilac (kompajler) jezika za opis podataka.
Rezultat prevoĎenja je interni opis baze podataka, smješten u riječnik. PrevoĎenje projekta šeme
u opis baze podataka se vrši relativno rijetko, jadanput na početku korištenja baze podataka i,
povremeno, prilikom rijetkih modifikacija projekta šeme baze podataka. U velikim
višekorisničkim bazama podataka, izmjena šeme je zadatak administratora baze podataka, kao i
poslovi izmjene podšema (pogleda), ili davanje privilegija (autorizacije) korisnicima za pristup
bazi podataka. Autorizaciona tabela se, takoĎe, smješta u riječnik.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
72
ПРОЦЕСОР УПИТНОГ
ЈЕЗИКА
ОПИСИ ТАБЕЛА
БАЗЕ ПОДАТАКА
АУТОРИЗАЦИОНЕ
ТАБЕЛЕ
ОПИС МЕНИЈА
ОПИСИ ФОРМИ
КАТАЛОГ
АПЛИКАЦИЈА
ПРОГРАМА
Р
Ј
Е
Ч
Н
И
К
ПРОЦЕСОР ОПИСА
ШЕМЕ
УПРАВЉАЧ БАЗЕ
ПОДАТАКА
ТАБЕЛЕ
КОНКУРЕНТНОГ
ПРИСТУПА
УПРАВЉАЧ
ДАТОТЕКАМА
AD HOC УПИТАПЛИКАТИВНИ
ПРОГРАМИ
ШЕМА БАЗЕ
ПОДАТАКА
ГЕНЕРАТОР
АПЛИКАЦИЈА
ЕДИТОР
ФОРМИ
БАЗА ПОДАТАКА
Slika 3.11. Arhitektura baze podataka
Na slici 3.11 je prikazan i procesor upita, u koji se uvode programi za manipulisanje podacima iz
dva izvora. Te izvore predstavljaju:
korisnički (ad hoc) upiti, koji se postavljaju direktno putem terminala ili nekog drugog
interaktivnog radnog mjesta,
aplikativni programi, koji sadrţe naredbe za selekciju i manipulisanje bazom podataka.
Prevodilac jezika domaćina ne predstavlja sastavni dio SUBP.
Zadaci upravljača baze podataka su da:
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
73
preuzima naredbe od procesora upitnog jezika i prevodi ih sa nivoa apstrakcije opisa
podšeme ili šeme u operacije na datotekama, odnosno fizičkoj strukturi baze podataka,
formira i odrţava specijalnu tabelu sa podacima o zaključavanju objakata,
vodi borbu protiv pojave izgladnjavanja transakcija i uzajamnog zaključavanja,
upravlja voĎenjem ţurnal datoteke,
detektuje razne anomalne situacije, kao što su narušavanje integriteta baze podataka ili
potreba njenog oporavka.
Kada je riječ o uslovima integriteta baze podataka, poţeljno je da jezik za opis podataka
posjeduje mogućnosti za eksplicitno definisanje ograničenja u opisu šeme baze podataka. Na taj
način, sprovoĎenje tih ograničenja, pa prema tome i odrţavanje baze podataka u konzistentnom
stanju, postaje zadatak SUBP.
Na slici 3.11 je prikazan i upravljač datotekama. On moţe biti ili sastavni dio SUBP, ili je riječ o
opštem upravljaču datotekama operativnog sistema. Njegov je zadatak da, na osnovu zahtjeva
upravljača bazom podataka, prenosi dijelove baze podataka u operativnu memoriju.
Riječnik podataka je baza podataka sa podacima o bazi podataka i njenim korisnicima.
Riječnikom, kao bazom podataka, takoĎe upravlja SUBP, tako da se moţe koristiti putem
upitnog jezika. Različiti SUBP posjeduju riječnike sa različitim mogućnostima. Analiza tih
mogućnosti izlazi izvan okvira ovog teksta. Na ovom mjestu će samo biti ukazano da riječnik
sadrţi podatke o:
logičkoj i fizičkoj (internoj) strukturi baze podataka,
pogledima,
korisnicima i njihovim pravima pristupa,
aplikativnim programima i njihovim komponentama (pod komponentama aplikativnog
programa smatraju se procedure, meniji, ekranske i štampane forme)
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
74
4. Relacioni model podataka
Jadan od prvih radova, posvećen modelu podataka, čiju osnovu čine relacije i njihova
prezenracija putem dvodimenzionalnih tabela, napisao je Kod (Codd, 11). Pored njega, zančajan
doprinos razvoju ovog modela dao je niz autora, kao Beri, Bernštajn, Fagin, Majer, Risanen,
Ulman i drugi. Motiv za definisanje realcionog modela podataka predstavljali su nedostaci,
uočeni pri korištenju do tada poznatih modela podataka, u koje su spadali hijerarhijski i mreţni
modeli podataka. Uočeni nedostaci posljedica su tri osnovna uzroka i to:
nepostojanje jasne granice izmeĎu logičkih i fizičkih aspekata baze podataka,
strukturalna kompleksnost,
navigacioni jezik za manipulisanje podacima.
4.1. Koncepcija relacionog modela podataka
Saglasno uočenim nedostacima, pri razvoju relacionog modela podataka postavljena su tri cilja:
Prvi i najvaţniji cilj bio je uvoĎenje jasne granice izmeĎu logičkih i fizičkih aspekata baze
podataka, kako u domenu projektovanja, tako i u domenu korištenja.
Drugi cilj je bio da se modelu da strukturalna jednostavnost i da se obezbjedi jednoobraznost
shvatanja i pogleda na podatke – kako programera tako i krajnjih korisnika.
Treći cilj je bio uvoĎenje deklarativnog jezika za definisanje i korištenje baze podataka. To je
značilo da jezik treba da posjeduje osobinu neproceduralnosti i mogućnost definisanja
operacija nad skupovima podataka, što dovodi do značajnog povećanja produktivnosti
programera, a predstavlja i preduslov za neposredno korištenje baze podataka od strane
krajnjih korisnika.
Nezavisnost
Pod nezavisnošću se podrazumijeva postizanje oštre i jasne granice izmeĎu logičkih i fizičkih
aspekata upravljanja bazom podataka. U dotadašnjim SUBP, opis podataka bio je preplavljen
informacijama o karakteristikama fizičke strukture podataka. U svaki aplikativni program bila je
ugraĎena informacija o fizičkoj strukturi, što je značilo da se izmjenom fizičke strukture moraju
mijenjati i svi programi.
Pojam fizičke strukture odnosi se na sve aspekte takozvane „interne prezentacije podataka“, kao i
mehanizme pristupa podacima. Spomenuti mehanizmi su:
raspodjela slogova po zonamabaze podataka,
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
75
fizički redoslijed i grupisanje slogova (po stranicama: u bazama podataka se jedinica
razmjene podataka izmeĎu operativne i eksterne memorije naziva stranicom),
algoritam transformacije ključa u adresu,
lanci slogova povezanih pokazivačima, indeksi (stabla traţenja),
hijerarhijski redoslijed slogova i slično.
Ključ za razumijevanje osnovne ideje relacionog modela leţi u razumijevanju pojma
nezavisnosti podataka, koja se postiţe potpunim razdvajanjem oblika u kojem se podaci
prezentuju programu ili korisniku (logički aspekt), od oblika u kojem se ti podaci memorišu u
bazi podataka (fizički aspekt).
Strukturalna jednostavnost
Da bi se obezbjedila strukturalna jednostavnost modela podataka, kao reprezent relacije je
usvojena dvodimenzionalna tabela, jer predstavlja lako razumljiv pojam i za programera i za
krajnjeg korisnika. Prilikom korištenja tabele kao reprezenta relacije, tabela nosi naziv relacije, a
red sa nazivima kolona (zaglsvnje tabele) predstavlja skup obiljeţja šeme realcije. Nazivi kolona
predstavljaju obiljeţja, a same kolone sadrţe elemente domena odgovarajućih obiljeţja.
МАФ
ЕКФ
ЕТФ
ПМФ
ФИЛ
ФАК
Машински факултет
Фкономски факултет
Електротехнички факултет
Природно математички факултет
Филозофски факултет
НАЗ
7
4
7
7
1
БРИП
Факултет
1436
1575
1718
2212
1418
1352
МБР
Иван
Лука
Бојан
Стеван
Вељко
Марко
ИМЕ
Јандрић
Лукић
Сандић
Милић
Тркуља
Иванић
ПРЗ
ЕТФ
ЕКФ
ЕТФ
ФИЛ
МАФ
ПМФ
ФАК
Студент
МАФ
ЕКФ
ЕТФ
ПМФ
ФИЛ
ФАК
Машински факултет
Фкономски факултет
Електротехнички факултет
Природно математички факултет
Филозофски факултет
НАЗ
7
4
7
7
1
БРИП
Факултет
1436
1575
1718
2212
1418
1352
МБР
Иван
Лука
Бојан
Стеван
Вељко
Марко
ИМЕ
Јандрић
Лукић
Сандић
Милић
Тркуља
Иванић
ПРЗ
ЕТФ
ЕКФ
ЕТФ
ФИЛ
МАФ
ПМФ
ФАК
Студент
Slika 4.1. Ilustracija relacione tabele
Na slici 4.1, FAK – je ključ za fakultet, NAZ – je naziv fakulteta, BRIP – je broj informatičkih
predmeta, MBR – je matični broj studenta (broj indeksa), IME – ime strudenta, PRZ – prezime
studenta.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
76
Kod ovakvog načina predstavljanja podataka na logičkom nivou, pojavljuje se problem
predstavljanja informacije o odnosima izmeĎu podataka u različitim tabelama. To je dovelo do
toga da se informacija o odnosima izmeĎu podataka predstavi unutar postojeće tabele ili putem
nve tabele.
4.2. Strukturalna komponenta relacionog modela podataka
Na nivou ekstenzije, koncepte realcionog modela predstavljaju: domen obiljeţja, relacija i pojava
baze podataka. Na nivou intenzije osnovne koncepte predstavljaju: obiljeţje, šema realcije i šema
baze podataka. Pri tome, primitivne koncepte predstavljaju samo elemenat domena i obiljeţje.
Svi ostali koncepti se izvode iz primitivnih, primjenom odreĎenih formalno – matemetičkih
pravila za:
R – vrijednost
restrikcija R vrijednosti
relacija,
šema realcije,
pojava nad šemom realcije,
ključ šeme relacije,
šema baze podataka,
pojava baze podataka.
4. 3. Integritetna komponenta relacionog modela podataka
Na osnovu sturkturalne komponente relacionog modela, slijedi da ograničenja predstavljaju
neophodan dio definicije šeme baze podataka. Koriste se pri formiranju i aţuriranju baze
podataka, u cilju odrţavanja sadrţaja baze podataka u saglasnosti sa uočenim odnosima izmeĎu
obiljeţja stanja realnog sistema.
Ograničenja se mogu klasifikovati kao:
ograničenja torki (torka predstavlja relaciju kao skup n – torki, pri čemu svaka komponenta
torke predstavlja vrijednost iz jednog skupa, takozvanog „domena obiljeţja“,
relaciona ograničenja (reguliše se lokalna konzistentnost – usaglašenost pojave sa
ograničenjima, difinisanim u šemi relacije),
meĎurelaciona ograničenja (regulišu globalnu usaglašenost baze podataka, kao pojave, sa
ograničenjima, definisanim u šemi baze podataka.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
77
MeĎutim, baza podataka je konzistentna, ako je i lokalno i globalno konziszenzna, tako da slijedi
da i relaciona ograničenja predstavljaju samo specijalan slučaj ograničenja baze podataka).
4. 4. Operacijska komponenta relacionog modela podataka
Operacijska komponenta modela podataka sluţi za opis dinamičkih karakteristika realnog
sistema, za razliku od strukturalne i integritetne komponente, koje sluţe za predstavljanje
statičke strukture realnog sistema, iskazane putem šeme baze podataka. Operacijskom
komponentom modela podataka se definiše jezik za izraţavanje upita nad bazom podataka i jezik
putem kojeg se vrši aţuriranje pojave baze podataka u cilju njenog usaglašavanja s tekućim
stanjem realnog sistema. Zbog toga se, često, operacijska komponenta naziva i dinamičkom
komponentom modela podataka. Operacijska komponenta sadrţi tri podkomponente:
upitni jetik,
jezik za ažuriranje podataka,
jezik za definiciju podataka.
Upitni jezik i jezik za aţuriranje podataka se jednim imenom nazivaju jezik za manipulaciju
podacima. Pomoću upitnog jezika i jezika za aţuriranje podataka se, u praksi, realizuju
informacioni zahtjevi svih korisnika informacionog sistema, tako da se ovi jezici pojavljuju u
formi:
nezavisnog, interaktivnog jezika,
jezika, ugraĎenog u jezik treće generacije,
jezika, ugraĎenog u jezik (odnosno, alat) četvrte generacije.
Jezik za definiciju podataka sluţi za realizaciju implementacione šeme baze podataka.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
78
5. Objektno – orijentisani modeli podataka
Tokom osamdesetih godina dvadesetog vijeka, došlo je do primjene računara u jednom broju
novih oblasti. U te nove oblasti spadaju:
računarom podrţano projektovanje u mašinstvu, elektrotehnici, arhitekturi, graĎevinrstvu i
informatici,
multimedijalni sistemi,
baze znanja.
Sve ove nove oblasti primjene zahtijevaju manipulisanje velikim količinama podataka i mogle bi
imati koristi od promjene SUBP. MeĎutim, priroda podataka u tim primjenama se teško uklapa u
relacione okvire. Na primjer, sistemi za računarom podrţano projektovanje treba da omoguće
izgradnju modela kompleksnih objekata i odrţavanje različitih verzija istog objekta.
Multimedijalni sistemi sadrţe tekstove varijabilne duţine, grafiku, slike, audio i video podatke,
što rezultuje u zahtjevu za efikasnijim memorisanjem i manipulisanjem nizovima velike i
promjenjive duţine. Konačno, sistemi zasnovani na znanju zahtijevaju semantički bogate
podatke i kompleksne operacije. Sve ove nove oblasti primjene stavljaju akcenat na još dva
zahtjeva. To su: produktivnost programera i performanse obrade.
Opisani zahtjevi doveli su do razvoja novog modela podataka, koji bi trebalo da ih zadovolji. Taj
novi model podataka nazvan je objektno – orijentisanim. Razvija se na idejama objektno –
orijentisanih programskih jezika i semantičkih modela podataka. Cijeli pristup se, često, naziva
objektno – orijentisana paradigma. Kada je riječ o objektno – orijentisanoj paradigmi, riječ je o
softverskom predstavljanju realnih entiteta putem parova (struktura podataka, ponašanje). Ti
parovi predstavljaju nedjeljivu cjelinu, a nazivaju se objektima. Pri tome, ponašanje se odnosi na
programsku realizaciju postupaka, putem kojih objekti mijenjaju stanje ili samo daju informaciju
o svom stanju. Stanje objekta je definisano strukturom podataka, putem koje je realni entitet
predstavljen.
Objektno – orijentisani model podataka je još u razvoju. Ne postoji opšte prihvaćen stav koji, od
meĎusobno različitih, objektno orijentisanih jezika treba da predstavlja osnovu za njegovu
operacijsku komponentu. Model nije unificiran, jer oslanjanje na različite programske jezike
dovodi do daljih razlika u verzijama modela podataka.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
79
Ovdje je cilj da se ukaţe na stanje razvoja objektno – orijentisanog modela podataka. Poglavlje
je podijeljeno u pet dijelova. U provm su nešto opširnije opisani zahtjevi novih oblasti primjena
u odnosu na baze podataka, kao i osnovni razlozi nepogodnosti relacionog modela podataka da
tim zahtjevima udovolji. Mada su strukturalna i operacijska komponenta kod objektno –
orijentisanog modela podataka meĎusobno čvrsto povezane, drugi, treći i četvrti dio poglavlja
posvećen je detaljnom opisu strukturalne komponente modela sa samo neophodnim refleksijama
na operacijsku komponentu. Peti dio posvećen je integritetnoj komponenti. Kao operacijska
komponenta, u šestom dijelu opisan je programski jezik C++. Konačno, sedmi dio posvećen je
komparaciji potencijala objektno – orijentisanog i stvarnih mogućnosti relacionog modela
podataka.
5.1. Nove oblasti primjene baza podataka
Računarom podrţano projektovanje, baze znanja i multimedijalni sistemi predstavljaju nove
oblasti primjene baza podataka. Redoslijed nabrajanja ovih oblasti primjene, ukazuje i na
redoslijed uvoĎenja odgovarajućih softverskih sistema u praksu. Softverski sistemi za računarom
podrţano projektovanje (Computer Aided Design (CAD), Computer Aided Sofrware
Engineering (CASE)) su se pojavili prvi, pa se ova analiza zahtjeva u odnosu na sisteme baza
podataka, preteţno, zasniva na potrebama tih sistema.
Softverski sistemi za računarom podržano projektovanje se koriste za rješavanje kompleksnih
zadataka inţenjerske prakse. u takve zadatke spadaju izrade projekata: mašinskih proizvoda,
proizvodnih linija, kompletnih fabrika, brodova, aviona, zgrada, mostova integrisanih kola velike
gustine, računara ili informacionih sistema. Inţenjersko projektovanje postavlja jedan broj novih
zahtjeva u odnosu na model podataka i sistem za upravljanje bazom podataka. Ti zahtjevi su
posljedica sljedećih specifičnosti primjeneračunara u inţenjerskom projektovanju:
Nehomogenost podataka: Projekti sadrţe heterogen skup objekata. Za te projektne objekte je
karakterističan veliki broj različitih tipova, svaki sa malim brojem pojava.
Nizovi promjenjive dužine i nizovi velike dužine: Digitalizovani crteţi, često, predstavljaju
sastavni dio projekta. U digitalizovanog+m obliku, cijelo crteţ je predstavljen kao veoma
dug niz bajtova, od kojih svaki nosi informaciju o nivou sivila jedne tačke, izuzezno malih
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
80
dimenzija, na crteţu. Pored toga, oni posjeduju i zapise promjenjive duţine sa tekstualnim
podacima.
Kompleksni objekti: Projektu, po pravilu, sadrţe kompleksne objekte, koji se mogu
rekurzivno dijeliti u manje objekte. Kompleksan objekat ima hijerarhijsku strukturu
podataka. Bez obzira na to, korisnik mora biti u stanju da manipuliše tim objektom kao da je
jedinstven.
Upravljanje verzijama: U projektima je neophodno voditi zapise o evoluciji rješenja.
Projektanti često eksperimentišu sa više verzija jednog objekta, prije nego što izaberu onu
koja najviše zadovoljava postavljene zahtjeve. U principu, jedan objekat moţe imati samo
jednu prethodnu verziju i više paralelnih narednih verzija. Svaka od narednih verzija se
naziva alternativom. Verzije jednog objekta formiraju strukturu stabla.
Evalucija šeme: Postoji više mogućih pogleda na isti objekat projektovanja. Na primjer,
jedan čip se moţe predstaviti na nivou logičkih kola, u cilju provjere logičke funkcionalnosti,
na nivou tranzistora (elemenata), u cilju analize brzine rada, ili na nivou šeme povezivanja, u
cilju provjere primjenjenih pravila projektovanja. Iako se prezentacije znatno razlikuju, ipak
je riječ samo o prezentacijama istog objekta. Te prezentacije se nazivaju ekvivalentnim
objektima. Prava svrha ekvivalentnih objekata je da uvedu ograničenja na bazu podataka.
Naime, ako se dio projekta izmijeniu jednoj prezentaciji, sistem treba ili da tu promjenu
sprovede i u drugim prezentacijama, ili da barem isti dio, u drugim prezentacijama, označi
kao nevaţeći.
Modularnost: Velika sloţenost projekta nameće potrebu paralelnog rada većeg broja
projektanata na njegovim dijelovima – modulima. Moduli projekta nisu meĎusobno
nezavisni. Pri tome, svaki modul smije da mijenja samo njegov projektant, a drugim
projektantima treba da budu poznate njegove ulazno izlazne karakteristike, da bi sa njima
povezali modul.
Dugačke transakcije: Transakcije u inţenjerskom projektovanju uz primjenu računara traju
veoma dugo. Projektant započinje transakciju, putem koje mijenja neki objekat i radi na
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
81
njemu nedjeljama, prije nego što, završivši transakciju, stavlja rezultate svog rada na uvid i
drugim korisnicima baze podataka.
Multimedijalne baze podataka.
U modernom informacionom sistemu, podaci uključuju ne samo tekstove i brojeve, već i slike,
grafiku i digitalizovane zvučne i video zapise. Takvi multimedijalni podaci se memorišu kao
nizovi bajtova promjenjive duţine, a dijelovi tih nizova su meĎusobno spregnuti, radi lakšeg
povezivanja tekstova, slika, zvuka i video zapisa.
Baze znanja.
Vještačka inteligencija i ekspertni sistemi predstavljaju informacije kao činjenice i pravila, koje
se mogu zajedno posmatrati kao baza znanja. U tipičnim primjenama vještačke inteligencije,
predstavljanje znanja zahtijeva strukture podataka sa bogatom semantikom. Operacije u bazi
znanja su kompleksnije nego u tradicionalnim bazama podataka. Na primjer, kada se ţeli dodati
neko novo pravilo, sistem mora provjeriti da li je ono suvišno ili u kontradikciji sa dotadašnjim
pravilima. Kompleksnost takvih provjera raste veoma brzo sa porastom baze znanja.
5.1.1. Ograničenja relacionog modela podataka
Relacioni sistemi za upravljanje bazama podataka nisu u stanju da zadovolje zahtjeve ovih novih
oblasti primjena računara. Za to postoje dva razloga. Jedan je posljedica činjenice da se, pri
projektovanju relacionih sistema za upravljanje bazama podataka, jednostavno nije vodilo računa
o tim novim oblastima primjene. Drugi razlog leţi u činjenici da sam relacioni model podataka
ne posjeduje mogućnost za efikasno zadovoljenje zahtjeva, koje postavljaju te nove oblasti
primjene.
Relacioni sistemi za upravljanje bazama podataka nisu razvijani tako da bi efikasno podrţavali:
Rad sa nehomogenim skupovima podataka, jer su projektovani za efikasno upravljanje
bazama podataka, kod kojih broj pojava (torki) daleko premašuje broj tipova entiteta (šema
relacija).
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
82
Intenzivne izmjene šeme baze podataka, jer su razvijani pod pretpostavkom da se šema baze
podataka rijetko mijenja, pa su u njih ugraĎeni i, relativno, skromni mehanizmi za izmjenu
šeme.
Upravljanje različitim verzijama jednog objekta. Modifikacijom se, u relacionoj bazi
podataka, gube prethodne vrijednosti odreĎenih podataka. Ne postoje ugraĎeni mehanizmi za
efikasno voĎenje evidencije o promjenama stanja objekata. S druge strane, to su prirodni
zahtjevi primjena, kao što su: planiranje, simulacija i podrška odlučivanju.
Upravljanje ekvivalentnim objektima, posebno kada je riječ o evidentiranju potrebe izmjene
jednog objekta, na osnovu izmjena u njemu ekvivalentnom objektu.
Upravljanje dugačkim transakcijama. Transakcija je takav niz akcija čitanja i pisanja u bazu
podataka, koji ostavlja bazu podataka u konzistentnom stanju. Nakon završetka transakcije,
sve promjene, koje je ona izazvalau bazi podataka, postaju vidljive odjednom, ili, ako je
došlo do bilo kakve neregularne situacije, upravljač transakcijama poništava sve promjene u
bazi podataka, kao da transakcija nije ni izvršavana. Upravljači transakcijama relacionih
sistema su razvijani za transakcije, koje kratko traju. Ako doĎe do pada sistema tokom
izvršavanja dugačke transakcije, putem koje se modifikuje neki projektantski objekat,
strategija rekonstrukcije stanja baze podatakana osnovu kopije nekog prethodnog stanja i
sadrţaja ţurnal datoteke, rezultovala bi u gubitku nedjelja rada, jer bi se rekonstrukcija baze
podataka izvršila saglasno stanju prije početka transakcije. Primjena računara u
projektovanju traţi od sistema za upravljanje bazom podataka da i parcijalni rezultati neke
transakcije budu vidljivi i da omogući takvu rekonstrukciju baze podataka da i parcijalni
rezultati projektantskih transakcija budu spašeni, a ne da rekonstrukcija znači vraćanje u
stanje nakon posljednje uspješno završene transakcije.
Mada jednostavan i zasnovan na strogim teorijskim osnovama, relacioni model nameće odreĎena
ograničenja na reprezentovanje realnih entiteta u bazama podataka. Organizovanjem podataka u
relacije (tabele), relacioni model pretpostavlja horizontalnu i vertikalnu homogenost podataka.
Horizontalno, svaka torka date relacije posjeduje istu definiciju za obiljeţja. Vertikalno, dato
obiljeţje uzima vrijednosti iz istog domena u svakoj torci. Pri tome, domeni su ograničeni na
primitivne tipove podataka, kao što su: cijeli i realni brojevi, karakteri i slično, ograničene
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
83
duţine. Svakoj torci odgovara samo jedna vrijednost iz domena svakog obiljeţja. Potreba da se
prezentacijama entiteta jedne klase pridruţi skup vrijednosti iz nekog domena, dovodi ili do
pojave većeg broja torki sa preteţno (ali ne potpuno) istim sadrţajem, ili do dekompozicije šeme
relacije, kao modela klase realnih entiteta, na nekoliko novih šema realcija. Broj torki sa
preteţno istim sadrţajem jednak je kardinalnom broju skupa vrijednosti iz domena, koje treba
pridruţiti jednom entitetu. Takvo predstavljanje podataka o entitetima dovodi do nepoţeljne
redundanse baza podataka.
Ako se šema relacije rastavi (dekomponuje) na više šema relacija, tada se kompleksan objekat
memoriše putem zapisa, rasutih po različitim relacijama. MeĎutim, za korisnika taj kompleksni
objekat i dalje predstavlja jednu logičku cjelinu i jedinicu posmatranja. Dekompozicija značajno
smanjuje performanske računarske obrade podataka, jer uvodi potrebu čestog korištenja
operatora prirodnog spajanja, u cilju rekonstruisanja kompleksnih objekata.
Dalje, realcioni model eksplicitno ne uključuje semantiku, kao dio prezentacije realnih entiteta.
Umjesto toga, aplikacioni programi interpretiraju semantiku podataka. Kad se primjeni
dekompozicija, ne samo što se smanjuje efikasnost obrade, već se povećava i vjerovatnoća
gubljenja semantike povezane sa podacima. S druge strane, jezik podataka relacionog modela se
ne moţe koristiti za izvoĎenje operacija, potrebnih u bazama znanja.
Moţe se zaključiti da relacioni model podataka, sam po sebi, nije pogodan za:
izgradnju struktura sa podacima promjenjive i velike duţine,
predstavljanje kompleksnih objekata,
izvršavanje operacija takve kompleksnosti, kakvu zahtijevaju primjene u bazama znanja.
Primjer 5.1.:
U relacionoj bazi podataka se, često, podaci o radniku nalaze u relacijama nad šemama Radnik,
Odjeljenje, Radno_Mjesto, Radnik_Projekat. U objektno orijentisanom sistemu, objekti realnog
svijeta predstavljeni su kao jedan objekat baza podataka. Jedan od osnovnih ciljeva objektno
orijentisanog modela podataka je da vjerno preslika objekat realnog svijeta u njegovu softversku
prezentaciju. Drugim riječima, Odjeljenje, Radno_Mjesto, Projekat mogu biti tipovi objekata
baze podataka, ako je to potrebno, ali Radnik postaje kompleksni tip objektat, a njegova pojava
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
84
sadrţi sve podatke o samom radniku, o odjeljenju u kojem radi, o radnom mjestu na koje je
rasporeĎen i o projektima na kojima je angaţovan.
Potreba intenzivne primjene operatora prirodnog spajanja za rekonstrukciju kompleksnih
objekata od torki, rasutih po raznim relacijama, pokazuje da relacioni sistemi nemaju
odgovarajuće performanse, za primjenu u novim oblastima. Zbog toga su, mnogi današnji
sistemi, namjenjeni za projektovanje, izgraĎeni na sistemu datoteka. Jedna studija pokazuje da
realizacija CAD sistema putem relacionog modela SUBP dovodi do petostrukog povećanja
vremena pretraţivanja podataka u poreĎenju sa implementacijom putem datoteka. MeĎutim,
izgradnja putem sistema datoteka dovodi do poznatih problema zavisnosti programa i podataka,
nekompatibilnosti i nekonzistentnosti podataka.
S druge strane, za relacione SUBP su razvijeni principi izgradnje čitavog niza vaţnih
mehanizama, kao što su:
neproceduralni jezik podataka,
automatska optimizacija upita,
uslovi integriteta,
upravljač transakcijama,
zaštita od neovlaštenog korištenja,
zaštita od uništenja,
distribucija baze podataka i distribucija njene obrade.
Iste ove mehanizme moraće da da koriste i objektno orijentisani SUBP. Relacioni sistemi će se i
dalje koristiti u oblastima gdje su zahtjevi u odnosu na tipove podataka i na koncepte za
izgradnju modela realnih entiteta primjereni mogućnostima modela. MeĎutim, za odreĎene
primjene relacioni SUBP su jednostavno nepogodni.
5.1.2. Porijeklo objektno orijentisanog modela podataka
Objektno orijentisani model podataka (dalje OOMP) je razvijan na drugi način u odnosu na
relacioni model podataka. Umjesto da se poĎe od jednostavne definicije i snaţnog matematičkog
aparata, razvoj OOMP je zasnovan na tradicijama:
objektno orijentisanih programskih jezika,
semantičkih modela podataka.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
85
Objektno orijentisani SUBP se razvijaju na tradicijama SUBP, zasnovanih na drugim modelima
podataka. Slika 5.1 pokazuje koji su koncepti iz raznih oblasti korišteni za razvoj objektno
orijentisanog modela podataka i SUBP.
Комплексни објекти
Идентитет објекта
Класе и методе
Инкапсулација
Насљеђивање
Агрегација
Специјализација
Трајно меморисање
података
Упитни језик
Вишекориснички рад
Управљање
трансакцијама
Објентно оријентисани
програмски језици
Семантички модел
податакаРелациони СУБП
Објектно оријентисани
модела података
Slika 5.1. Razvoj OOMP na tradiciji
Prva pojava objekta, kao koncepta, javlja se u Simuli, simulacionom jeziku razvijanom u ranim
sedamdesetim godinama. MeĎutim, interes za objektno orijentisane jezije počeo se pokazivati
tek nakom pojave Smalltalk [26]. Danas se pored Smalltalk intenzivno koriste objektni Pascal i
C++. Interes za primjenu objektno orijentisanih jezika je posljedica:
njihova sposobnost da efikasno koriste strukture sa praktično proizvoljnim tipovima
podataka,
postojanja bogatih biblioteka sa gotovim klasama,
mogućnosti ponovnog korištenja već promjerenog programskog koda.
Razlika izmeĎu objektno orijentisanog programskog jezika i objektno orijentisane baze
podatakaje da baza podatakapodrazumijeva postojanje permanentnomemorisanih objekata na
medijumu eksterne memorije, dok objekti u objektno orijentisanom programskom jeziku postoje
samo tokom izvršavanja programa. Dodavanje mogućnosti trajnog memorisanja podataka
programskom okruţenju, dovelo je do pojave objektno orijentisanih SUBP. Semantički modeli
podataka su druga od tri oblasti, koje su uticale na razvoj objektno orijentisanih modela
podataka. U semantičke modele podataka spadaju: prošireni ER model, funkcionalni model i
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
86
semantički model podataka. Semantički modeli podataka imaju dva moćna koncepta: agregacija
i specijalizacija.
Agregacija je postupak izgradnje sloţenih objekata - agregata, od objekata – komponenata.
Postoje dva slučaja sličnosti izmeĎu agregata i koncepata ER modela podataka. Prvi je kada se
agregacijom obiljeţja dobija tip entiteta – agregirani objekat. Drugi je slučaj kada se kombinuju
meĎusobno povezani tipovi entiteta u agregirani tip entiteta na višem nivou apstrakcije. Odnos
izmeĎu tipa entiteta – komponente i agregata se naziva vezom tipa „je dio“. Pojava agregata je
egzistencijalno zavisna od svojih komponenata. Na slici 5.2 je prikazana prezentacija agregata i
komponenata putem koncepata ER modela podataka. Treba naglasiti da i komponenta moţe
predstavljati agregat.
Agregacija je jedan od postupaka za predstavljanje hijerarhijskog odnosa izmeĎu entiteta
različitih realnih klasa.
MeĎutim, agregat je jedna cjelina, te je, sa te tačke gledišta, adekvatnija njegova geometrijska
prezentacija prema slici 5.3. U svakom slučaju agregat je apstraktni tip entiteta koji sadrţi
heterogene komponente.
Korištenjem termina relacionog modela podataka, pojam agregata moţe se objasniti na sljedeći
način: šema relacije, reprezent agregata ima obiljeţja, koja i sama mogu biti šema relacija, tako
da vrijednosti obiljeţja u torci mogu predstavljati torke nekih drugih relacija. Pojava šeme
relacije u ulozi obiljeţja neke druge šeme relacije, naziva se „ugljeţdavanjem“. Ugnjeţdavanje
moţe imati proizvoljnu dubinu.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
87
Агрегат
12Компонента nКомпонента2
(1,б) (1,б) (1,б)
Је_дио Је_дио...
Је_дио Је_дио...
(1,б) (1,б)
(а,б) (а,б) (а,б)
(а,б) (а,б)
1Компонента 2Компонента mКомпонента
Slika 5.2.
1Компонента12Компонента
3Компонента
mКомпонента 2
2Компонента
Агрегат
Slaka 5.3.
Specijalizacija je apstrakcija proširenog ER modela podataka. Suština je da se elementi neke
klase mogu specijalizovati i grupisati u potklase. Jedna potklasa nasljeĎuje sve osobine svojih
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
88
superklasa. Elementi potklase pripadaju i superklasi. Element potklase nasljeĎuje osobine
odgovarajućeg elementa člana superklase, ali posjeduju i svoje specifične osobine.
5.2. Osnovni koncepti objektno orijentisanog modela podataka
Objektno orijentisana paradigma donosi cijeli niz novih pojmova i mehanizama za predstavljanje
realnih entiteta. Ti pojmovi i mehanizmi predstavljaju koncepte objektno orijentisanog modela
podataka.
U nove pojmove i mehanizme spadaju:
objekat,
metoda,
poruka,
inkapsulacija (učaurenje),
klasa,
nasljeĎivanje,
identitet objekta.
Osnovni tipovi podataka
Svaki programski jezik podrţavaneki skup podataka. Kada je riječ o konvencionalnim
programskim jezicima, kao što je Pascal ili, kada je riječ o jezicima podataka mreţnog ili
relacionog sistema za upravljanje bazama podataka, oni podrţavaju osnovne tipove podataka,
kao što su: cijeli (integer) i realni (real) brojevi, karakteri (chr), datum (date), novac (money) i
logički podaci, koji uzimaju vrijednosti iz skupa {true, false}. TakoĎe, podrţavaju tipske
konstruktore za izgradnju sloţenijih tipova podataka, kao što su nizovi,liste, slogovi i skupovi.
Elementi domena, pridruţenog obiljeţju, predstavljaju je putem nekog od osnovnih tipova
podataka. Za svaki osnovni tip podataka, karakterističaj ne jedan broj operacija. Te operacije su
ugraĎene u razne programe.
Primjer 5.2.:
Elementi domena, pridruţenog obiljeţju IME, predrtavljaju se putem karaktera ili niza karaktera,
a elementi domena, pridruţenog obiljeţju KOL (količina materijala), predstavljaju se putem
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
89
cijelih ili realnih brojeva. Primjeri operacija nad ovim tipovima podataka su, redom: povezivanje
nizova karaktera, primjena aritmetičkih operacija na cijele ili realne brojeve.
Pojam objekta
Objekat je jedan od mogućih modela realnog entiteta. Taj model ima dvije komponente. To su:
stanje i ponašanje. Stanje objekta se prezentuje putem strukture nad skupom podataka o realnom
entitetu. Ponašanje objekata je skup procedura, koje se nazivaju metodama ili operacijama. Ti
programi sluţe za izmjenu stanja objekta (aţuriranje strukture podataka) ili samo za davanje
informacije o njegovom stanju. Bez insistiranja na preciznosti, metode se mogu posmatrati i kao
programi, koji opisuju ponašanje realnog entiteta.
Primjer 5.3.:
Ako je Janković Bojan programer sa platom od 750 KM, tada bi sljedeća semantički odreĎena
linearna struktura mogla predstavljati strukturalni dio odgovarajućeg objekta
((IME, Bojan), (PRZ, Janković), (ZAN, programer), (PLT, 750)
a skup
{zaposli, povećaj_platu, prikaži_platu, prikaži_podatke, penzioniši}
bi sadrţavao nazive metoda, koji se mogu primjeniti na tu strukturu podataka.
Definicija 5.1.:
Neka je U skup obiljeţja, a D={cijeli broj, realni broj, niz karaktera fiksne ili promjenjive
duţine, datum, novac,...} skup osnovnih tipova padataka. Tada vaţi:
10 Svaki elemenat svakog osnovnog skupa podataka je primitivni objekat.
20 Ako su X1,..., Xn različita obiljeţja u U, a o1,..., on objekti, tada je
o = ((X1, o1),..., (Xn, on))
jedan objekat – torka. Objekat oi je vrijednost obiljeţja Xi, u oznaci oi = o.Xi.
30 Ako su o1,..., on različiti objekti, tada je
o = {o1,..., on}
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
90
jedan objekat – skup i vaţi oi o.
Ova definicija ukazuje na veoma širok dijapazon mogućih struktura podataka objekta. Objekat
moţe imati tako jednostavnu strukturu, kakvu ima jedan cijeli broj, ili kompleksniju, kakva je
relaciona torka ili skup objekata, do veoma kompleksne strukture, kakva je struktura stabla nad
skupom objekata. Bitno je zapaziti da obiljeţja iz U mogu uzimati vrijednosti iz proizvoljnog
domena. Vrijednost obiljeţja moţe biti cijeli broj ili niz karaktera, ali i torka, skup, ili neka
kompleksna struktura podataka.
Primjer 5.4.:
Pošto broj 5 pripada skupu cijelih brojeva, broj 5 je jedan primitivni objekat. Slično, pošto „Ana“
pripada skupu nizova karaktera, i „Ana“ je primitivni objekat.
Objekat ((IME, Ana), (PRZ, Janković)) je objekat – torka, koji sadrţi dva primitivna objekta, a
objekat {((PRED, Marketing), (OCJ, 8), ((PRED, Informatika), (OCJ, 9))} je objekat skup.
Objekat
((IME_I_PRZ(IME, Ana), (PRZ, Janković)), (SEM, 2), (ISPIT, {((PRED, Marketing), (OCJ, 8)),
((PRED, Informatika), (OCJ, 9))})),
prezentuje realni entitet – skudenta Anu Janković, putem jednog sloţenog objekta – torke.
Objekat je sloţen jer sadrţi:
jedan objekat – torku tipa Ime_i_Prezime (koji, sa svoje strane sadrţi dva primitivna
objekta),
jedan primitivni objekat tipa cijeli broj (koji prezentuje upisani semestar),
jedan objekat – skup, čiji elementi, objekti – torke prezentuju poloţene predmete sa
ocjenama.
Na slici 5.4 ovaj je objekat prikazan kao struktura stabla nad skupom objekata. Pri tome, listovi
stabla sadrţe primitivne objekte, dok drugi čvorovi predstavljaju agregate. Agregati su samo
naznačeni putem svojih listova, mada i sami sadrţe podatke.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
91
Студент
)2,(СЕМПрезимеиИме __ Испит
),( АнаИМЕ ),( ЈанковићПРЗ1Испит
),( МаркПРЕД )8,(ОЦЈ ),( ИнфоПРЕД )9,(ОЦЈ
2Испит
Slika 5.4.
5.2.3. Poruka
Jedino metode pridruţene posmatranom objektu, imaju pravo da pristupaju njegovoj strukturi
podataka, bilo u cilju aţuriranja stanja objekta, ili samo davanja informacija o nekoj komponenti
njegovog stanja. Metode se pozivaju putem poruka. Poruka je zahtjev, upućen objektu, da izvrši
neku od svojih metoda. Objekti meĎusovno komuniciraju putem poruka.
Osnovni oblik poruke je (<prijemnik>, <naziv metode>). Dio poruke označen sa <prijemnik>,
predstavlja adresu objekta, koji treba da primi i protumači poruku. Ta adresa je ili identifikator
objekta, ili neki izraz, putem kojeg se objekat označava. Naime, svaki objekat ima jedan
identifikator, koji ga jednoznačno identifikuje. Drugi objekti se obraćaju posmatranom objektu
navoĎenjem tog identifikatora u okviru poruke. Za svaku poruku, koju objekat razumije, postoji
odgovarajuća metoda, koja izvršava poruku. Dio poruke označen sa <naziv metode>, ukazuje o
kojoj je metodi riječ. Na osnovu naziva, objekat poziva odgovarajuću metodu. Poruka moţe
sadrţavati i parametre, neophodne za izvršavanje metode. Objekat vraća pošiljaocu rezultat
izvršenja metode, pozvane porukom. Rezultat je obično drugi objekat. Na slici 5.5 je prokazan
princip komunikacije izmeĎu objekata. Objekat o1 prima poruku p4
1 i, da bi na nju odgovorio,
odlučuje da uputi poruku p2
1 objektu o2. Objekat o2, sa svoje strane, šalje poruku p3
1 objektu o3.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
92
објекат
о1
објекат
о2
12m 2
2m
32m4
2m
објекат
о3
13m 2
3m
33m4
3m
ijm - метода
41порука
12порука
13порука
mnпорука
11m 2
1m
31m4
1m
Slika 5.5.
Paradigma objekat/poruka pretpostavlja:
da svi podaci predstavljaju objekte,
da svaki objekat posjeduje skup metoda,
da su nazivi tih metoda poznati drugim objektima,
da svaki objekat odgovara samo na svoje poruke,
da objekti meĎusobno komuniciraju samo putem poruka.
Metoda je entitet sličan programskoj proceduri. Opisuje redoslijed akcija, koje se trebaju izvršiti
po prijemu poruke.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
93
5.2.4. Inkapsulacija (učaurenje)
Svaki objekat ima svoj privatni i javni dio. Privatni dio objekta čine: struktura podataka i skup
metoda za tu strukturu. Taj dio objekta se naziva i implementacija. Javni dio objekta čine:
identifikator i naziv metoda. To je njegov interfejs (sprega sa okolinim). Poruke pristupaju
interfejsu i specificiraju koje metode bi, na objektu, trebalo da se izvrše, ali ne i kako da se te
metode izvrše. Objekat, koji primi poruku, odreĎuje kako će se izvršiti traţena metoda. Na slici
5.6 ilustrovani su pojmovi privatnobi javnog dijela objekta.
идентификатор
назив_методе_1
назив_методе_2
... назив_методе_n
процедура_методе_1
процедура_методе_2
... процедура_методе_n
Структура података
објекат
интерфејс
јавни дио
објекта
приватни
дио објекта
Slika 5.6.
UvoĎenjem privatnog i javnog dijela objekta, uvodi se princip skrivanja informacija. To znači da
su detalji realizacije objekta skriveni od svih programa programa izvan objekta. Često se kaţe da
objekat inkalupsira podatke i programe. To znači da jedan objekat ne moţe da vidi unutrašnjost
«kapsule» drugog objekta, ali moţe da ga koristi, pozivajući, putem poruka, njegov programski
dio. To je slično pozivima procedura u konvencionalnim programskim jezicima. Inkapsulaciju
treba shvatiti i kao ograničenje da se svi pristupi objektima mogu vršiti jedino primjenom
njihovih metoda.
5.2.5. Klasa
Mnogi objekti u realnom svijetu posjeduju slične karakteristike i izvršavaju slične operacije. U
proizvodnom pogonu metalskog kompleksa, nalaze se glodalice, rendisaljke, bušilice. Iako je
svaki od ovih objekata različit, svi pripadaju klasi mašina za obradu metala rezanjem. Svi objekti
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
94
u klasi mašina za obradu metala rezanjem posjeduju zajednička obiljeţja (električni motor,
glavno breteni i sl.) i izvršavaju zajedničke operacije (obrada metala). Prema tome,
kategorizacijom jednog struga, kao člana klase mašina za obradu rezanjem, zna se nešto o
njegovim obiljeţjima i operacijama, čak i kada se ne poznaju njegove precizne funkcije.
Objektno orijentisani model podataka se ne svodi samo na pojam objekta. Osnovni pojam
objektno orijentisanog modela podataka je klasa. Klasa je dvojaka. Jedna komponenta je tip
objekta, koji nosi informaciju o strukturi podataka. Druga komponenta je kup metoda. To su
operacije, koje se primjenjuju na sve objekte, čija struktura je definisana putem tipa objekta.
Klasa je skup takvih objekata, koji imaju iste karakteristike (tip strukture i metode). Svaki
individualni objekat je pojava neke klase.
Definicija 5.2.:
Neka je U skup obiljeţja, X U, A U, a D = {cijeli broj, realan broj, niz karaktera fiksne ili
promjenjive duţine, datum, novac,...}skup osnovnih tipova podataka. Tada vaţi:
10 Dvojka (A, d) gdje je d D, je tip objekta.
20 Ako su T1,..., Tk tipovi objekata, tada je i ((X1, T1),..., (Xk, Tk)) tip objekta torka.
30 Ako je T tip objekta, tada je i {T} tip objekta skup. Objekat tipa {T} je skup objekata tipa T.
Komponenta tip objekta je dvojka (obiljeţje, tip podataka). Putem obiljeţja je definisana
semantika komponente tipa objekta. Tip podataka je domen obiljeţja, ali elementi tog domena
mogu biti veoma sloţeni. Elementi domena mogu uzimati vrijednosti iz skupa vrijednosti nekog
osnovnog tipa podataka, ali i iz skupa objekata tipa torka ili skup. Pošto su i elementi osnovnih
tipova podataka objekti, sa svojom strukturom i ponašanjem, dolazi se do zaključka da domen
predstavlja klasu. Domen se neki put naziva i interpretacijom. Interpretacija je skup, iz kojeg
neki semantički koncept uzima vrijednosti. Treba zapaziti da je definicija pojma tipa objekta
rekurzivna. Tip objekta se definiše kao struktura nad skupom tipova objekata.
Primjer 5.5.:
Tip objekta, pod nazivom TipArtikla se, koristeći uvedenu notaciju, moţe definisati na sljedeći
način
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
95
TipArtikla = ((NAZIV, Chr), (IDA, Int))
gdje je IDA identifikacioni broj artikla.
Nazivi domena obiljeţja pisani su velikim početnim slovima, da bi se ukazalo da je riječ o
tipovima, odnosno klasama.
Tip objekta StavkaNarudžbine je
StavkaNarudžbine = ((ARTIKAL, TipArtikla), (Količina, Int)).
U komponenti (ARTIKAL, TipArtikla) tipa objekta StavkaNarudžbine, ARTIKAL je obiljeţje, a
TipArtikla je klasa. Vrijednosti obiljeţja ARTIKAL su pojave klase TipArtikla.
Sada se moţe definisati tio objekta TipPorudžbine, kao
TipPorudžbine = ((BRP, Int), (SADRŽI, {StavkaNarudžbine}),
gdje je BRP broj porudţbine i gdje je obiljeţju SADRŽI pridruţen tip podatka – domen, čiji
elementi su skupovi objekata tipa StavkaNarudžbine. Kupci se mogu predstaviti putem sljedećeg
tipa objekta
TipKupca = ((NAZIV, Chr), (ADRESA, Chr), (STANjE_RAČ, Int), (PORUDžBINE,
{TipPorudžbine})).
Da bi se uspostavila veza izmeĎu narudţbina i kupaca, tip objekta TipPorudžbine se moţe
modifikovati na sljedeći način
TipPorudžbine = ((BRP, Int), KUPAC, TipKupca), (SADRŽI, {StavkaNarudžbine}).
Treba zapaziti da tip objekta TipKupca sadrţi, kao svoju komponentu, skup pojava klase
TipPorudžbine, a da tip objekta TipPorudžbine, kao svoju komponentu, sadrţijednu pojavu klase
TipKupca. Na slici 5.7 su prikazane dvije pojave klase Kupac, svaka sadrţi odreĎeni broj
odgovarajućih pojava klase Porudžbina.
Klasa se opisuje putem naredbi objektno orijentisanog jezika. To opisivanje klase se naziva
deklaracijom klase. U okviru deklaracije klase se navode:
nazivi njenih obiljeţja sa pripadajućim domenima,
nazivi metoda sa odgovarajućim programskim kodom.
Putem naziva obiljeţja i domena se definiše tip objekta, a nazivi obiljeţja i metode čine interfejs
klase.
Klasa je generator svojih pojava (objekata istog tipa). Skupu aktuelnih objekata odgovara pojam
ekstenzije u klasičnim modelima podataka.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
96
5.2.6. Apstraktni tipovi podataka
Apstraktni tipovi podataka predstavljaju poopštenje pojma osnovnog tipa podatka.
Koncepti:
inkapsulacije,
javnog i privatnog dijela,
poruke i metode,
u osnovi su vezani za pojam apstraktnih tipova podataka. U objektno orijentisanom pristupu, ovi
koncepti se realizuju putem klasa. Saglasno tome, i apstraktni tip podatka se moţe posmatrati
kao dvojka (s, m), gdje je s struktura a m skup metoda. MeĎutim, izmeĎu pojmova apstraktni tip
podatka i klasa, postoji i odreĎena razlika. Apstraktni tip podataka opisuje skup svih mogućih
objekata sa datom strukturom i datim ponašanjem. Taj skup moţe biti neograničen. Nasuprot
apstraktnom tipu podataka, klasa opisuje objekte svoje ekstenzije, koja sadrţi konačan broj
pojava klase.
5.2.7. Nasljeđivanje
Objekti nasljeĎuju osobine (tip strukture i metode) od svoje klase. MeĎutim, i klasa moţe
nasljeĎivati osobine drugih klasa. Klasa, koja nasljeĎuje osobine od druge klase, naziva se
potklasom. Klasa, čije osobine nasljeĎuje jadna ili više drugih klasa, naziva se superklasom. Za
potklasu se još sreće naziv potomak ili dijete, a za superklasu predak ili roditelj. Svaka klasa
nasljeĎuje svi ili samo dio osobina svoje superklase. NasljeĎene osobine nije potrebno ponovo
definisati u potklasi. MeĎutim, nove osobine se mogu dodati potklasama, ako je to potrebno.
Potklasa nasljeĎuje strukturu tako da sva obiljeţja superklase postaju obiljeţja potklase. Potklasa
nasljeĎuje metode, tako da njeni objekti mogu da koriste sve metode superklase. MeĎutim,
potklasa moţi imati i svoje metode, neke od metoda superklase mogu biti zabranjene za objekte
potklase, a neka od nasljeĎenih metoda se moţe i prilagoditi za potklasu. Pošto potklasa moţe
imati svoje potklase, dolazi se do pojma hijerarhije klasa. Hijerarhija klasa definiše „je podvrsta“
odnos izmeĎu klasa. Koncept nasljeĎivanja kaţe da osobine, definisane za neku klasu, mogu
nasljediti sve potklase te klase. To je slično konceptu specijalizacije u semantičkim modelima
podataka.
Korištenje klasa i nasljeĎivanja je veoma bitno za savremeno softversko inţenjerstvo. Ponovno
korištenje programa se postiţe kreiranjem novih klasa, zasnovanih na obiljeţjima i metodama
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
97
postojećih klasa. Tada treba samo da se specificira kako se nova potklasa razlikuje od svoje
superklase, a ne i da se definiše kompletno nova klasa. Nova klasa nasljeĎuje već provjerene
metode od svojih superklasa i te metode ne treba ponovo programirati.
5.2.8. Identitet objekta
U objektno orijentisanom modelu podataka, svakom objektu, osim primitivnom, pridruţuje se
jedinstven identifikator. Primitivnom objektu se identifikator ne pridruţuje, jer primitivni objekti
imaju jedinstvene vrijednosti, koje ih samodentifikuju. U svojstvu identifikatora se moţe koristiti
adresa memorijske lokacije, u koju je objekat smješten, ali postoje i druga rješenja. Vaţno je da
je identifikator nezavisan od bilo kojeg obiljeţjatipa objekta, pa i ključa. Na taj način se
omogućava aţuriranje svakog obiljeţja (promjena stanja) objekta bez opasnosti da se naruši
identitet objekta. Identifikator ostaje nepromjenjen dok se objekat ne izvriše iz baze podataka.
Identifikator se koristi kao referenca na objekat, kao surogat – zamjena za objekat. Identifikator
obezbjeĎuje jedinstvenost identiteta objekta, ali, ako je to memorijska adresa, nju korisnik ne
moţe poznavati. Postoje i druga rješenja za realizaciju identiteta objekta.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
98
Ispitna pitanja
1. Definišite model podataka.
2. Koje informacije model podataka mora obezbjediti?
3. Objasnite statičke osobine, ograničenja i dinamičke osobine realnih sistema.
4. Objasnite šta predstavlja, ukupno i pojedinačno, trojka (S, I, O).
5. Šta sadrţi strukturalna komponenta podataka?
6. Definišite pojam entitet u modeliranju podataka.
7. Kako se definiše koncept a kako primitivni koncept u modelima podataka? Navedite bar
jedan primjer nekog koncepta i primitivnog koncepta.
8. Šta je intenzije a šta ekstenzija?
9. Definišite integritetnu komponentu modela podataka.
10. Definišite pojavu baze podataka.
11. Objasnite operacijsku komponentu modela podataka.
12. Objasnite pojam indikatora tekućeg sloga.
13. Od čega se sastoji operacija?
14. Navedite bar dvije od pet aktivnosti operacije.
15. Kako se moţe vršiti selekcija?
16. Navedite bar tri modela podataka.
17. Definišite model entiteta i poveznika.
18. Šta sačinjava strukturalnu komponentu modela entiteta i poveznika?
19. Čime se predstavlja intenzija modela entiteta i poveznika?
20. Definišite pojam obiljeţje.
21. Objasnite ulogu pojma domen.
22. Objasnite pojmove tip entiteta i tip poveznika.
23. Nacrtajte i objasnite ulogu osnovnih gradivih elemenata u dijagramima entiteta i poveznika.
24. Objasnite ulogu ključa tipa entiteta.
25. Objasnite kardinalnost tipa poveznika.
26. Nacrtajte primjer dijagrama sa kardinalitetom grupe M:N.
27. Nacrtajte primjer dijagrama sa kardinalitetom grupe N:1.
28. Nacrtajte primjer dijagrama sa kardinalitetom grupe 1:1
29. Nacrtajte primjer dijagrama sa rekurzivnim vezama.
30. Nacrtajte primjer dijagrama sa tipom poveznika reda većeg od dva.
Rade Tanjga: Principi baza podataka
_____________________________________________________________________________________________
99
31. Objasnite pojam fizičke strukture podataka.
32. Navedite osnovne postavke koncepcije baze podataka.
33. Definišite fizičku nezavisnost.
34. Definišite logičku nezavisnost.
35. Objasnite ulogu SUBP.
36. Navedite tri vrste jezika koje koristi SUBP.
37. Definišite transakciju!
38. Koja je uloga zaključavanja beze podataka?
39. Kako se obezbjeĎuje zaštita od neovlaštenog korištenja baza podataka?
40. Šta je autorizaciona tabela?
41. Kako se obezbjeĎuje zaštita od uništenja baza podataka?
42. Nacrtajte i objasnite arhitekturu baze podataka.
43. Objasnite koncepciju relacionog modela podataka.
44. Koji su koncepti relacionog modela podataka na nivou ekstenzuje?
45. Koji su koncepti relacionog modela podataka na nivou intenzije?
46. Koje tri podkomponente sadrţi operacijska komponenta relacionog modela podataka?
47. Koje su oblasti primjene baza podataka dovele od razvoja objektno orijentisanog modela
podataka?
48. Odakle je porijeklo objektno orijentisanog modela podataka?
49. Navedite osnovne koncepte objektno orijentisanog modela podataka.
50. Od čega se sastoji i kako funkcioniše objekt?
51. Šta je poruka?
52. Šematski predstavite objekat sa javnim i privatnim dijelom.
53. Šta je inkapsulacija?
54. Kako se definiše klasa?
55. Šta je nasljeĎivanje?