D E O I

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 1 str.

Teorija relacionih
baza podataka

3

P O G L A V L J E 1

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 3 str.

Osnovni pojmovi

Dakle, ta je to mitsko bie, poznato pod imenom relaciona baza podataka
(engl.

relational database

)? Ukratko, baza podatka je alatka koja omoguava
skladitee podataka i rad s ima, na efikasan i delotvoran nain. Efikasno
i delotvorno znai da su podaci zatieni od nenamernog gubea ili
oteea, da se za tu namenu ne koristi vie resursa (udskih ili raunar-
skih) nego to je zaista neophodno i da se podaci mogu uitavati u smislenim
oblicima unutar prihvativih ograniea performansi. Da bi se mogla kvali-
fikovati kao relaciona, baza podataka mora da realizuje relacioni model, to
je nain na koji se opisuje odreeni aspekt stvarnog sveta, u skladu s pravili-
ma koje je definisao dr E. F. Codd kasnih ezdestih godina.
Teorijski, softver za relacionu bazu podataka moe se napisati od nule,
ali u praksi ete uvek koristiti usluge odreenog sistema za upravae baza-
ma podataka (engl.

database management system

, DBMS). DBMS se pone-
kad naziva relacioni DBMS (RDBMS), ali tehniki gledano, da bi se jedan
DBMS kvalifikovao kao relacioni, morao bi da ispuni nekih 300 uslova, a ko-
liko ja znam, nijedan sistem koji postoji na tritu nije u potpunosti kvalifiko-
van. Dva sistema za upravae relacionim bazama podataka koje emo
razmatrati u ovoj kizi, jesu Microsoftov Jet i Microsoftov SQL Server.
Ve sam napomenula da je relaciona baza fizika realizacija relacionog
modela (modela podataka); vano je da razlikujete ta dva pojma. Kao to
ete saznati u drugom delu kige, dimenzionalni model moe se realizovati
i na relacionom DBMS-u, a ako brkate pojmovno (konceptualno) s fizikim,
biete potpuno zbueni. (Da,

ba tako

govori moje iskustvo.)

ta je to baza podataka?

Terminologija baza podataka gotovo je isto toliko neodreena koliko i izraz
objektno orijentisano programirae. Izraz baza podataka koristi se za
opisivae svaega, u opsegu od obine grupe podataka, do sloenog skupa
alatki, kao to je SQL Server, a i svega izmeu. Taj maak preciznosti ne

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 4 str.

4

Poglavlje 1 Osnovni pojmovi

mora obavezno da znai neto loe razlog je sama priroda jezika ali poto
nije ni naroito koristan za nae namene, pokuau da ovde budem precizni-
ja. Na slici 11 prikazane su veze izmeu izraza koje pomiemo u ovom
poglavu. Te izraze definiemo u ovom poglavu, a detano emo ih razmo-
triti u preostalom delu kige.

Slika 11

Terminologija relacionih baza podataka
ema baze
podataka
opisuje model
podataka koji se
uvaju u bazi
Baza podataka sadri
fiziki oblik
eme i podataka
Aplikacija se sastoji od obrazaca
i izvetaja s kojima radi korisnik aplikacije
Maina baze podataka nije
sastavni deo baze podataka
Sistem koji radi s bazom podataka
Model podataka
je konceptulani
opis prostora
problema
Prostor problema je neki dobro definisan deo stvarnog sveta

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 5 str.

ta je to baza podataka?

5

Iako se za relacione baze podataka ne mogu nai analogije u stvarnom
svetu, svrha veine baza podataka je da modeluju odreeni aspekt iz stvar-
nog ivota. Taj deli stvarnog sveta nazvau

prostor problema

(engl.

pro-
blem space

). Po samoj svojoj prirodi, prostor problema je zbrkan i sloen
kada ne bi bio takav, ne bi ni trebalo da pravite egov model. Meutim, za
uspeh projekta od kune je vanosti da sistem za koji projektujete bazu
podataka bude ogranien na tano definisan skup objekata i ihovih odnosa;
jedino na taj nain moi ete da donosite pravilne odluke o opsegu koji si-
stem treba da obuhvati.
Izraz

model podataka

(engl.

data model

) koristiu za pojmovni opis
prostora problema. Rad s relacionim modelom obuhvata definicije entiteta,
ihovih atributa (na primer, Kupac je entitet, koji moe imati atribute Pre-
zime i Adresa) i ograniea koja vae za atribute (kao to je, na primer, pra-
vilo da poe ImeKupca ne moe biti prazno). Kada radite s dimenzionalnim
modelom, definicija modela podataka obuhvata ienice i dimenzije, ali
time emo se baviti u drugom delu kige.
Model podataka takoe obuhvata opis veza ili odnosa izmeu pojedinih
entiteta, kao i ograniea koja vae za te veze. Na primer, rukovodilac grupe
ne moe imati vie od pet podreenih koji mu podnose izvetaje. Model
podataka nita ne govori o fizikoj strukturi sistema.
Definicija fizike strukture tabela i prikaza koji e biti napraveni
zove se

ema baze podataka

(engl.

database schema

) ili samo

ema

. To je
preslikavae pojmovnog modela u fiziki oblik, koji se moe realizovati po-
mou nekog DBMS-a. Imajte u vidu da je ema takoe konceptualni pojam,
a ne fiziki. ema nije nita drugo do model podataka izraen pomou ele-
menata koje

maina baze podataka

(engl.

database engine

) prepoznaje,
kao to su tabele, okidai i slina bia. Jedna od prednosti upotrebe maine
baze podataka jeste to to ne morate da se bavite fizikim oblikom baze
podataka; moete slobodno zanemariti B-stabla, vorove na nivou listova
stabla i druge fizike koncepte nieg nivoa.
Poto maini baze podataka objasnite kako elite da podaci izgledaju,
pomou SQL koda, ili u nekom interaktivnom okrueu, kao to je Micro-
softov Access, ili SQL Server Enterprise Manager, maina baze podataka
pravi nekoliko fizikih objekata (obino, ali ne uvek, negde na vrstom di-
sku) u koje ete kasnije smestiti podatke. Tu kombinaciju strukture i podata-
ka zvau

baza podataka

. Takva baza podataka sadri: fizike tabele u
kojima se uvaju podaci; definisane prikaze, upite i uskladitene procedure
koje omoguavaju uitavae podataka na razne naine; pravila ije poto-
vae obezbeuje maina baze podataka i time titi podatke.

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 6 str.

6

Poglavlje 1 Osnovni pojmovi

Izraz baza podataka

ne

odnosi se na

aplikaciju

koja se sastoji od obra-
zaca i izvetaja s kojima radi korisnik aplikacije, niti se odnosi na bilo koju
drugu vrstu softvera kao to je posredniki sloj ili Internet Information Ser-
ver ija je namena da povezuje eonu i pozadinsku komponentu sistema.
Izraz baza podataka takoe iskuuje mainu baze podataka. Prema tome,
Accessova .mdb datoteka je baza podataka, dok je Microsofov Jet maina
baze podataka. U stvari, .mdb datoteka moe da sadri i objekte aplikacije
na primer, obrasce i izvetaje ali to je tema koju emo razmotriti kasnije.
Da bih obuhvatila sve navedene komponente aplikaciju, bazu podataka
i mainu baze podataka, koristiu izraz

sistem koji radi s bazom podataka

(engl.

database system

). Sve softverske komponente i svi podaci koji su neop-
hodni za rad produkcionog sistema, ine sistem koji radi s bazom podataka.

Alatke za rad s bazama podataka

Iako je glavna tema ove kige projektovae a ne izrada baza podataka,
apstraktna teorija nije naroito korisna ako ne znate kako da je primenite; zato
emo u ovoj kizi mnogo govoriti o izradi relacionih baza podataka pomou
Microsoftovih alatki. Na raspolagau je veliki broj alatki te vrste, a izgleda da
Microsoft svaki as nudi neku novu; zato emo posvetiti malo vremena razma-
trau o emu se tu radi i gde sve to tano spada. Na slici 12 prikazane su
alatke koje emo razmatrati. Najlake je da o ima razmiate imajui na umu
ta nama kao projektantima treba da bismo sistem preslikali iz apstraktnog
modela u ivi produkcioni sistem; tako su i alatke grupisane na slici.

Maine baza podataka

Na najniem nivou nalaze se

maine baza podataka

(engl.

database engi-
nes

). Ponekad se nazivaju i pozadinske komponente (engl.

back ends

), ali
je to prilino loe, jer izraz pozadinska komponenta zapravo opisuje fiziku
arhitekturu, kao to emo videti u poglavu 13. Zadatak tih alatki je fiziko
manipulisae podacima smetae na disk i uitavae s ega na zahtev.
Razmotriemo dve meu ima: Jet i SQL Server. Moda vas iznenauje to
ovde ne pomiem Microsoftov Access. Tehniki gledano, Access je okru-
ee za razvoj eonog dela aplikacije, koje za skladitee podataka stan-
dardno koristi Jet ili SQL Server, a moe da koristi i bilo koju drugu mainu
baze podataka koja podrava standard ODBC. Access radi s podacima koji
se uvaju u .mdb datotekama pomou maine Jet, a SQL Server (ili drugu
ODBC mainu baze podataka) koristi kada radi s podacima u .adp datoteka-
ma. Access je oduvek koristio mainu Jet, koju Microsoft nije nudio kao
zasebnu komponentu do izdavaa Visual Basic a 3.

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 7 str.

Alatke za rad s bazama podataka

7

I Jet i SQL Server, mada veoma razliiti, izuzetne su alatke za skla-
ditee podataka i rad s ima. Razlikuju se po arhitekturi i problemima za
ije su reavanje projektovane. Microsoftov Jet je stona maina baze poda-
taka, nameena sistemima koji se po veliini mogu svrstati u opseg od malih
do sredih. (Molim vas da imate u vidu da to nikako ne znai da je maina
baze podataka Jet pogodna samo za trivijalne sisteme.) S druge strane, SQL
Server koristi arhitekturu klijent/server i nameen je sistemima u opsegu
od sredih do ogromnih, koji se potencijalno mogu smanjiti ili poveati za
hiade korisnika aplikacija od kune vanosti za kompaniju. MSDE (akro-
nim za

M

icro

s

oft

D

esktop

E

ngine) funkcionalno je ograniena verzija SQL
Servera nameena upotrebi u jednokorisnikom okrueu. Gledano iz
ugla projektanta, razlika izmeu MSDE-a i pune verzije SQL Servera
zanemariva je i neemo se baviti ome. U celoj ovoj kizi baviemo se
razlikama izmeu dve navedene maine baze podataka, a u poglavu 13 raz-
motraemo kompromise izmeu ihove dve arhitekture.

Slika 12

Alatke za rad s bazama podataka koje emo razmatrati u ovoj kizi
Microsoft Access
SQL Server Enterprise Manager
Okruee za definisae podataka Razvoj eonih komponenata
Microsoft Access
Visual Studio .NET
Analysis Manager
ADO.NET
ADO
DAO
Objektni model za pristupae podacima
Microsoft Jet
SQL Server
MSDE
Maina baze podataka

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 8 str.

8

Poglavlje 1 Osnovni pojmovi

NAPOMENA O YUKONU:

U vreme pisaa ove kige (prolee 2004. godine),
nova verzija SQL Servera, koja je imala radno ime Yukon, bila je u ranoj beta
fazi. Bilo je poznato da e Yukon doneti znaajnu novu funkcionalnost, ali se
nije znalo ta e to tano biti. Zbog te (razumive) nepoznanice, ograniila sam
primarni deo gradiva na mogunosti SQL Servera 2000, koji se jo uvek iroko
koristi. Mogunosti za koje se oekuju znaajne promene navela sam u napo-

menama kao to je ova.

Objektni modeli za pristupae podacima

Microsoftov Access, a u maoj meri i Visual Studio .NET, nude jednostavne
mehanizme za povezivae kontrola na obrascima direktno sa izvorom poda-
taka, ime se izbegava potreba da programer radi neposredno s mainom
baze podataka. Meutim, iz raznih razloga koje emo razmotriti, to nije
uvek ni mogue ni prikladno. U takvim sluajevima moraete da koristite

objektni model za pristupae podacima

(engl.

data access object mo-
del

) da biste s podacima radili pomou programskog koda.
Objektni model za pristupae podacima vrsta je lepka izmeu okru-
ea za programirae aplikacija i maine baze podataka; model stava na
raspolagae skup objekata, sa njihovim svojstvima i metodama koji se mogu
koristiti u programskom kodu. Budui da se ova kiga bavi projektovaem
vie nego realizovaem, neemo detano razmatrati razlike izmeu tih mo-
dela, ali smatram da je korisno da ih ovde ukratko pomenemo.
Microsoft (zasad) stava na raspolagae tri objektna modela za pristu-
pae podacima: Data Access Objects (DAO), koji postoji u dve varijante
(DAO/Jet i DAO/ODBCDirect), Microsoft ActiveX Data Objects (ADO) i
ADO.NET.
DAO, najstariji od svih, standardni je interfejs za mainu baze podataka
Jet. Bez obzira na tvrde Microsoftove slube za marketing, to je najefika-
sniji objektni model za rad s Jetovim bazama podataka u Accessu. ADO kori-
sti jednostavniju hijerarhiju objekata nego DAO jer se sastoji od samo etiri
primarna objekta i donosi nekoliko znaajnih proirea osnovnog modela
na primer, podrku za rad s nepovezanim i hijerarhijskim skupovima podata-
ka. Koristi se u Microsoftovom Accessu i u drugim softverskim proizvodima
koji podravaju upotrebu jezika VBA za rad sa svakom bazom podataka koja
podrava ODBC interfejs, kao to su to i Jet i SQL Server. ADO.NET je,
naravno, verzija modela ADO za rad unutar .NET Frameworka.

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 9 str.

Relacioni model

9

Okruea za definisae podataka

Microsoftov Jet i SQL Server obavaju poslove fizikog manipulisaa poda-
cima umesto nas, a nama treba nain da im opiemo kako da strukturiraju
podatke. Microsoft nudi bezbroj metoda za tu namenu, ali ovde emo raz-
motriti samo tri: Access i SQL Server Enterprise Manager za relacione mo-
dele, i Analysis Manager za dimenzionalne modele. Postoje i druge alatke
koje pruaju sline mogunosti, ali najradije koristim navedene tri. Kada sa-
vladate principe, izabraete alatku koja je najpogodnija za posao koji treba
da obavite.
Strukturu baze podataka moete definisati i pomou SQL koda; opisau
kako se to radi, mada u uobiajenim okolnostima to ne preporuujem. Osim
kada je iz nekog razloga neophodno da izmenite strukturu podataka aplikaci-
je dok se ona izvrava (mada nisam pobornik te prakse ako ema baze poda-
taka nije stabilna, verovatno niste dobro razumeli domen problema),
interaktivne alatke su bre, lake i zabavnije za upotrebu.

Razvoj eone komponente aplikacije

Kada zavrite fiziku definiciju baze podataka, potrebne su vam alatke za iz-
radu obrazaca i izvetaja s kojima e korisnici raditi. Razmotriemo primere
upotrebe dve takve alatke: Access i Visual Studio .NET (konkretno, Visual
Basic .NET). U ovoj kategoriji takoe postoji bezbroj alatki za izradu eonih
komponenata, ali budui da su principi rada uvek isti, trebalo bi da budete u
stau da ono to iz ove kige nauite primenite na alatku za koju se oprede-
lite. U poglavu 10 ukratko emo razmotriti itae Weba, ali je sam HTML
izvan opsega ove kige.

Relacioni model

Relacioni model se zasniva na grupi matematikih principa izvedenih iz teo-
rije skupova i predikatne logike. Te principe je kasnih ezdesetih godina prvi
primenio na oblast modelovaa podataka dr E. F. Codd, tada istraiva u
kompaniji IBM, a egovi radovi prvi put su objaveni 1970. godine.

1

Pravila
relacionog modela definiu oblik u kojem se podaci predstavaju (struktura
podataka), nain na koji se podaci tite (integritet podataka) i operacije koje
se mogu izvravati nad podacima (manipulisae podacima).

1. Codd, E. F. A Relational Model of Data for Large Shared Data Banks, Communications
of the ACM, tom 13, broj. 6 (jun 1970).

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 10 str.

10

Poglavlje 1 Osnovni pojmovi

Relacioni model nije jedini model koji postoji za skladitee podataka i
rad s njima. Ostale mogunosti su hijerarhijski, mreni i objektni modeli po-
dataka. Svaki ima svoje pristalice i prua neosporne prednosti za odreene
vrste poslova. Meutim, zbog svoje efikasnosti i prilagodivosti, relacioni mo-
del je najpopularnija tehnika rada s bazama podataka i ega emo razmatrati
u ovoj kizi. I Jet i SQL Server realizuju relacioni model.
Razmotriemo i dimenzionalni model, to je specijalna vrsta relacione
eme za skladitee arhivskih podataka. Dimenzionalni model i egove
veze s relacionim modelom, detano emo obraditi u drugom delu kige.
Uopteno govorei, sistemi relacionih baza podataka imaju sledee odlike:

Svi podaci se konceptualno predstavaju organizovani u redove i
kolone; skup tako organizovanih podataka zove se

relacija

(engl.

relation

).

Sve vrednosti su

skalarne

. To znai da se na svakom mestu koje je
odreeno datim redom i kolonom, nalazi jedna i samo jedna vrednost.

Sve operacije obavaju se nad celom relacijom, a rezultat je takoe
cela relacija. Taj koncept je poznat kao

celovitost

(engl.

closure

).
Ako ste dosad radili s bazama Microsoftovog Accessa, prepoznali ste re-
laciju kao skup zapisa (engl.

recordset

) ili, u SQL Serverovoj terminolo-
giji, kao skup rezultata (engl.

result set

). Kada je formulisao relacioni
model, dr Codd je izabrao re relacija jer nije imala praktino nikakvo dru-
go znaee zavisno od konteksta, za razliku od, na primer, rei tabela.
Uvreeno je pogreno miee da se relacioni model tako zove zbog veza
(engl.

relationships

) koje uspostavamo izmeu tabela. Ime zapravo potie
od relacija na kojima se model zasniva.
Imajte u vidu to da model zahteva da podaci budu predstaveni u obliku
relacija samo na

konceptualnom

nivou; model ne propisuje fiziki oblik u ko-
jem se podaci uvaju. Razdvajae konceptualnog oblika od fizikog, mada
sada izgleda oigledno, bilo je velika inovacija pre 30 godina kada je pro-
gramirae baza podataka uglavnom znailo pisae mainskog koda za fizi-
ko manipulisae ureajima za skladitee podataka.
U stvari, relacijama nije ni potreban fiziki oblik. Odreena relacija moe
se preslikati u stvarnu, fiziku tabelu koja se uva na vrstom disku, ali moe
se sastojati i od kolona koje potiu iz gomile razliitih tabela, uz jo nekoliko
izraunatih kolona koje fiziki nigde ne postoje dodatih tek da stvar bude
sloenija. Relacija se moe nazvati relacijom ako su podaci organizovani u re-
dove i kolone i ako su vrednosti podataka iskuivo skalarne. Postojae rela-
cije potpuno je nezavisno od fizikog oblika podataka.

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 11 str.

Relaciona terminologija

11

Uslov da svi podaci od kojih se relacija sastoji budu skalarni, ponekad
moe navesti na pogrene zakuke. Pojam proste vrednosti subjektivan je
sam po sebi i zavisi od semantike modela podataka. Na primer, Ime osobe
moe biti prosta vrednost u jednom modelu, ali u nekom drugom okrueu
ta vrednost e moda biti podeena na elemente kao to su Funkcija,
Ime i Prezime, dok e tree okruee moda zahtevati i Oevo ime ili
Titulu. Nijedno od navedenih reea nije ni boe ni gore od drugog u ap-
solutnom smislu; sve zavisi od svrhe za koju e se podaci koristiti.
Princip celovitosti tj. da se i tabele i rezultati operacija nad ima pred-
stavaju u obliku relacija omoguava da se rezultati jedne operacije upo-
trebe kao ulazni podaci za drugu operaciju. Zahvaujui tome, i Jet i SQL
Server omoguavaju da rezultati jednog upita budu osnova za drugi upit. Ta
ienica prua projektantima baza podataka mogunost da operacije koje
su sloene ili se esto obavaju, izdvoje u zasebne celine koje se mogu pono-
vo izvriti gde god i kad god je to potrebno.
Na primer, napravili ste upit koji ste nazvali UpitPunoIme; on nado-
vezuje sve elemente od kojih se sastoji ime osobe da bi dobio izraunato
poe nazvano PunoIme. Moete zatim napraviti drugi upit iji je izvor poda-
taka UpitPunoIme i u kojem se izraunato poe PunoIme koristi na isti
nain kao da je u pitau poe koje postoji u izvornoj tabeli. Nema potrebe
da ponovo sastavate elemente imena.
Razume se, ovo je jednostavan primer i verovatno nije sasvim oigledna
neka znaajna prednost koju bi pozivae upita UpitPunoIme prualo nad
ponovnim sastavaem elemenata imena. Ali, kao to emo videti, jezik
SQL omoguava sastavae izuzetno sloenih upita, a kako raste sloenost
upita, tako postaju i sve vidljivije prednosti upotrebe postojeih upita kao
ulaznih podataka za nove.

Relaciona terminologija

Na slici 13 prikazana je relacija na kojoj su oznaena formalna imena os-
novnih komponenata. itaoci koji znaju neto o projektovau relacionih
baza podataka, prepoznae da relacija nije u normalnoj formi. To je sasvim u
redu; i dae se moe nazvati relacijom zato to su podaci razmeteni u redo-
ve i kolone, a sve vrednosti su skalarne.
Kao to smo ve naveli, cela struktura je

relacija

. Svaki red podataka
zove se

torka

(engl.

tuple

). Tehniki gledano, svaki red je zapravo n-torka
(npr. petorka, estorka itd.), ali se n- obino izostava. Ukupan broj torki u
relaciji odreuje

kardinalitet

(engl.

cardinality

) relacije. U primeru na

PBP

, June 2, 2006 12:35 pm
01_PBP.fm, 12 str.

12

Poglavlje 1 Osnovni pojmovi

slici, kardinalitet je 18. Svaka kolona torke zove se

atribut

ili

obeleje

(engl.

attribute

). Ukupan broj atributa odreuje

stepen

(engl.

degree

) rela-
cije. U primeru na slici, stepen relacije je 3.
Relacija je podeena na dva odeka:

zaglave

i

telo

. Torke ine telo re-
lacije dok se zaglave sastoji od ... zaglava. Obratite pau na to da se u rela-
cionoj notaciji natpis u zaglavu svakog atributa sastoji od dva dela, razdvojena
dvotakom na primer, UnitPrice:Currency. Prvi deo natpisa je ime atributa,
dok je drugi domen atributa.

Domen

(engl.

domain

) atributa je vrsta poda-
taka koje atribut predstava u ovom sluaju to su novani iznosi. Domen

nije

isto to i tip podataka. To pitae emo detano razmotriti u narednom ode-
ku. Specifikacija domena esto se izostava iz natpisa u zaglavu.
Telo relacije sastoji se od neureenog skupa jedne ili vie torki. Tu ima-
mo nekoliko vanih koncepata. Prvo, relacija nije ureena. Zamislite relaciju
kao papirnatu kesu (ili skupocenu kinesku vazu, ako ste pesniki raspoloeni)
u kojoj su torke nagomilane bez ikakvog posebnog redosleda. Redni brojevi
zapisa, uobiajen mehanizam za pristupae zapisima u nerelacionim bazama
podataka,

ne postoje u relacijama. Drugo, relacija bez ijedne torke (tzv. praz-
na relacija) takoe je relacija. Tree, relacija je skup. Svaki element skupa
se, po definiciji, moe nedvosmisleno identifikovati. Prema tome, da bi se
odreena tabela kvalifikovala kao relacija, svaki zapis mora da bude nedvo-
smisleno identifikovan i tabela ne sme da sadri duplirane zapise.
Slika 13 Komponente relacije
T
o
r
k
e
Atributi
Z
a
g
l
a
v

e
T
e
l
o
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 13 str.
Model podataka 13
Ako ste itali Accessovu ili SQL Serverovu dokumentaciju, moda se sad
pitate zato niste tamo nailazili na ove rei. To su formalni izrazi koji se kori-
ste u tehnikoj literaturi, ali ih Microsoft ne koristi. Ovde sam ih navela
samo zato da se ne biste obrukali na nekom prijemu (ili barem ne ako bude
re o n-torkama treeg stepena).
Naalost, Microsoftovi proizvodi ne samo to nisu usklaeni s formal-
nom terminologijom, nego nisu usklaeni ni meusobno. Izrazi koji se kori-
ste u dva Microsoftova proizvoda prikazani su u tabeli 11. U ovoj kizi
koristiu formalnu terminologiju.
Model podataka
Najapstraktniji nivo projektovanja baze podataka jeste model podataka,
to je konceptualni opis prostora problema. Modeli podataka sastoje se od
elemenata koji mogu biti entiteti, atributi, domeni i veze. U preostalom delu
ovog poglava pojedinano razmatram te elemente.
Entiteti
Teko je osmisliti preciznu formalnu definiciju entiteta (engl. entity), ali je
pojam relativno lako razumiv: entitet je sve o emu sistem treba da skladiti
podatke.
Kada ponete da projektujete model podataka, nee vam biti teko da
sastavite poetnu listu entiteta. Kada vi (ili vai klijenti) govorite o prostoru
problema, veina imenica i glagola kandidati su za entitete. Kupci kupuju
robu. Prodavci prodaju robu. Dobavai nam prodaju robu. Imenice Kup-
ci, Roba, Prodavci i Dobavai predstavljaju oigledne entitete.
Dogaaji predstaveni glagolima kupiti i prodati takoe su entiteti,
ali tu postoji nekoliko zamki. Prvo, glagol prodati predstava dva razliita
Tabela 11 Relaciona terminologija koja se koristi u proizvodima razmotrenim u ovoj
kizi
Formalna terminologija
Konceptualna Fizika Microsoft Access SQL Server
relacija tabela tabela ili skup zapisa tabela ili skup rezultata
atribut poe poe kolona
torka zapis zapis red
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 14 str.
14 Poglavlje 1 Osnovni pojmovi
dogaaja: prodaju robe kupcu (ProdavacKupac) i nabavae robe za pro-
daju (DobavaKompanija). U ovom primeru, razlika je sasvim oigledna,
ali je to zamka u koju se lako upada, naroito ako niste dobro prouili prostor
problema.
Druga zamka je suprotna prvoj: dva razliita glagola (kupuju u prvoj
reenici i prodaju u drugoj) opisuju zapravo isti dogaaj, tj. da je kupac ku-
pio odreenu robu. Ponavam, to nije uvek oigledno, osim kada dobro poz-
najete prostor problema. Ovaj problem se esto tee uoava od prvog. Ako
klijent koristi razliite izraze da bi opisao neto to vama na prvi pogled iz-
gleda kao isti dogaaj, on moda govori o razliitim vrstama dogaaja. Na
primer, ako je va klijent proizvoa konfekcije, rezultat dogaaja kupac
kupuje odelo i kupac naruuje odelo u oba sluaja je prodato odelo, ali u
prvom sluaju to moe biti kupovina ve gotovog konfekcijskog odela, dok se
u drugom sluaju radi o iveu odela po meri. To su dve vrlo razliite rade
koje se moraju modelovati na razliite naine.
Osim razgovora s klijentima na osnovu kojih ete sastaviti listu entiteta,
korisno je i da prouite dokumente koji postoje u prostoru problema. Obrasci
za unoee raznih podataka, izvetaji i pisana uputstva, dobri su izvori kandi-
data za entitete. Meutim, morate biti oprezni kada radite s dokumentima.
Pisani dokumenti mogu biti prilino zastareli tampani obrasci za unoee
podataka mogu biti poprilino skupi i esto ne prate promene poslovnih pra-
vila i postupaka. Ako naiete na entitet koji se ne pomie ni u jednom razgo-
voru, nemojte pretpostaviti da je klijent zaboravio da ga pomene. Verovatnije
je da taj entitet vie nije vaan organizaciji. Moraete sami da ispitate ta je
tano posredi.
Veina entiteta su modeli objekata ili dogaaja iz stvarnog ivota: kupci,
roba, prodajne ponude. To su konkretni entiteti. Entiteti mogu biti i mo-
deli apstraktnih koncepata. Najuobiajeniji primer apstraktnog entiteta
jeste entitet koji modeluje vezu ili odnos (engl. relationship) izmeu drugih
entiteta na primer, ienicu da je odreeni predstavnik kompanije odgo-
voran za odreenog klijenta, ili da odreeni student slua predavaa iz
odreenog predmeta.
Ponekad je dovono da modelujete samo ienicu da veza ili odnos po-
stoji. U drugim sluajevima moe biti potrebno da o toj vezi evidentirate i do-
datne podatke, kao to je datum uspostavanja veze, ili neku odliku te veze
(ili odnosa). Na primer, odnos izmeu pume i kojota je konkurentski, dok je
odnos izmeu pume i zeca takav da puma lovi zeca, to je korisno znati ako
planirate da izgradite zooloki vrt bez kaveza.
Postoje razliita miea o tome da li bi veze izmeu entiteta koje ne-
maju sopstvene atribute trebalo da se modeluju kao zasebni entiteti. Mislim
da se time nita ne dobija, a komplikuje se postupak izvoea eme iz
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 15 str.
Model podataka 15
modela podataka. Meutim, shvatae da su veze/odnosi izmeu entiteta
podjednako vani kao i sami entiteti, kuno je za projektovae kvalitetnog
modela podataka.
Atributi
Sistem koji projektujete morae da evidentira odreene ienice o svakom
entitetu. Kao to smo ve videli, te ienice su atributi entiteta. Na primer,
ako u svom sistemu imate entitet Kupac, verovatno e vam biti vano da zna-
te imena i adrese kupaca, a moda i njihova zanimaa. Ako modelujete do-
gaaj kao to je ZahtevZaServisirae, verovatno ete hteti da znate koji je
klijent u pitau, ko je zvao, kad je zvao i da li je problem reen. Svi navedeni
elementi su atributi.
Odreivae atributa koje ete ugraditi u svoj model jeste semantiki po-
stupak, to znai da odluke morate donositi na osnovu znaea podataka i
naina na koji e se oni koristiti. Pogledajmo est primer: adresu. Da li ete
adresu modelovati kao jedan entitet (Adresa) ili kao grupu vie entiteta (Ulica,
Broj, Grad, PotanskiBroj, Drava)? Veina projektanata (meu koje ubrajam
i sebe) obino automatski razbija adresu na grupu atributa zbog opteg princi-
pa da se lake radi sa strukturiranim podacima, ali to nije uvek tano, a svaka-
ko nije oigledno.
Kao primer, uzmimo lokalno udruee muziara amatera. Potrebno im
je da evidentiraju adrese svojih lanova kako bi mogli da tampaju nalepnice
za koverte. Poto je to jedina svrha za koje e se adrese koristiti, nema razlo-
ga da se adresa ikada tretira drugaije nego kao jedan blok od vie redova
teksta, koji se tampa na zahtev.
Ali ta je sa kompanijom koja se bavi prodajom robe u SAD putem Inter-
neta? Zbog obrauna poreza, kompaniji je potrebno da zna u kojoj saveznoj
dravi ivi svaki en kupac. Iako se podatak o saveznoj dravi moe izdvojiti
iz tekstualnog poa koje odgovara udrueu muziara, to nije lako; prema
tome, logino je da u ovom sluaju treba modelovati barem saveznu dravu
kao zaseban atribut. ta je sa ostalim delom adrese? Da li bi trebalo da ga ra-
zbijemo na vie atributa i koji bi to atributi bili? Moda biste pomislili da bi
odgovarao skup atributa {Kuni broj, Ulica, Grad, Savezna drava, Potanski
broj}? Meutim, moe zatrebati i broj stana, broj potanskog pretinca i APO
adresa. ta ete uraditi ako je u pitau usluna adresa koja pripada nekom
drugom? Poto svet postaje sve mai, ali ne mae sloen, ta e se desiti
kada dobijete prvog klijenta u inostranstvu? Domae adrese imaju prilino
standardizovan format, ali to ne vai za porudbine iz inostranstva.
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 16 str.
16 Poglavlje 1 Osnovni pojmovi
Ne samo to morate da znate cinu dravu i da tome prilagodite format
potanskog broja, nego ete moda morati da meate i redosled atributa.
Na primer, za razliku od SAD, u veem delu Evrope kuni broj se pie iza
imena ulice. To nije tako loe, lako ete se setiti toga kada budete unosili
podatke, ali koliko e vaih operatera znati da adresa 4/32 Griffen Avenue,
Bondi Beach, Australija, znai stan broj 4, u zgradi na broju 32?
Sutina u ovom sluaju nije to da je teko modelovati adresu (mada jeste),
nego da ne moete unapred odreivati kako ete modelovati odreenu vrstu
podataka. Sloen sistem koji razvijete za obradu meunarodnih porudbina,
bie potpuno neprikladan za udruee muziara.
Slikaru Matisu pripisuje se tvrda da je slika gotova tek kad joj se vie
nita ne moe ni dodati ni oduzeti. Projektovae entiteta pomalo je slino
tome. Kako znate da ste stigli u tu fazu? Naalost, odgovor glasi da u to nikad
ne moete biti potpuno sigurni (a ak i ako mislite da jeste, s vremenom ete
promeniti miee). Pri tekuem stau tehnologije, ne postoji nain da
projektujete strukturu baze podataka za koju se moe dokazati da je potpu-
no ispravna. Moete dokazati da u odreenoj strukturi ima propusta i grea-
ka, ali ne moete dokazati da ih u drugoj strukturi nema. To znai, otprilike,
da ne moete dokazati svoju nevinost. Kako se moe reiti taj problem?
Nema strogih pravila, ali postoji nekoliko strategija.
Prva strategija: Krenite od rezultata i nemojte praviti sloeniju
strukturu nego to je zaista potrebno. Na koja pitaa vaa baza podataka
mora davati odgovore? Poto je u naem prvom primeru, udrueu muzia-
ra, jedino pitae bilo: Na koju adresu treba poslati pismo za tu i tu osobu?,
model s jednim atributom za adresu bio je dovoan. U drugom primeru,
kompaniji koja prodaje robu putem Interneta, bio je potreban i odgovor na
pitae: U kojoj saveznoj dravi ivi ta i ta osoba?, pa nam je zato bila neop-
hodna drugaija struktura adrese da bismo doli do zahtevanog rezultata.
Razume se, morate voditi rauna i pokuati da obezbedite fleksibilnost
koja e pruiti odgovore, i to ne samo na pitaa koja korisnici postavaju sa-
da, ve i na ona koja moete predvideti da e se pojaviti u budunosti. Na
primer, kladila bih se da e u roku od godinu dana nakon putaa sistema u
redovnu upotrebu, udruee muziara zatraiti od vas da im sortirate adre-
se po potanskom broju da bi dobili koliinski popust.
Trebalo bi takoe da oekujete i pitaa koja bi korisnici postavili kada bi
znali da mogu da ih postave, naroito kada automatizujete postojei runi si-
stem. Zamislite da rukovodilac biblioteke eli da zna koliko je iz fonda od e-
tiri miliona kiga bilo objaveno u Novom Sadu pre 1900. godine. On ili
ona bi vam pokazali orman s kartotekom i poeleli vam dobru zabavu.
Meutim, u dobro projektovanom sistemu koji radi s bazom podataka, ta vr-
sta zahteva smatra se trivijalnim.
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 17 str.
Model podataka 17
Jedan od zatitnih znakova dobrih projektanata jeste temeitost i krea-
tivnost s kojima podstiu potencijalna pitaa. Neiskusni analitiari esto tvr-
de da korisnici ne znaju ta tano hoe. Naravno da ne znaju; va posao je da
im pomognete da otkriju ta zapravo ele.
Meutim, pri tome morate biti oprezni. Cena fleksibilnosti esto je
vei stepen sloenosti. Kao to smo videli na primeru adrese, to vie sec-
kate i usitavate podatke, vie ete imati posebnih sluajeva za obradu, a to
e vas dovesti do take kada predloeno reee poie da gubi smisao.
Tako stiemo do strategije broj dva: Otkrijte izuzetke. Ova strategija
ima dva aspekta. Prvo, morate identifikovati sve izuzetke, i drugo, sistem
morate projektovati tako da obrauje to vei broj izuzetaka, ali da pri tome
ne zbuuje korisnike. Kao ilustraciju ta tano znai ovaj princip, razmotri-
emo jo jedan primer: imena osoba.
Ako e namena sistema koji projektujete biti korespondencija, od ku-
ne je vanosti da imena osoba budu tano navedena. (Prikladan primer: svu
potu koju dobijam na kunu adresu, a primalac je gospodin R. M. Riordan,
uopte i ne otvaram.) Veina imena osoba prilino je jasna sama po sebi. Ako
je primalac gospoa Jelena K. Jovanovi, elementi imena su: Oslova-
vae, Ime, OevoIme i Prezime, zar ne? Pogreno. (Osetili ste da ima neka
zakoica, a?) Sigurnije je (i pravilnije po bontonu) koristiti UobiajenoIme
2
i Prezime. Dae, ta ete uraditi kad je primalac Sir James Peddington Smy-
the, Lord Dunstable? Peddington Smythe je u tom sluaju Prezime, ili je to
OevoIme? ta je onda Lord Dunstable? A peva Sting? Da li je to Uo-
biajenoIme ili Prezime? A ta e se desiti Umetniku Ranije Poznatom Pod
Imenom Prince? Da li vas to zaista zanima?
Poslede pitae nije tako besmisleno kao to se ini. Pismo iji je prima-
lac naveden kao Sir James Peddington Smythe, verovatno nee nikoga uvre-
diti. Ali ime pomenutog gospodina s plemikom titulom nije Sir Smythe; u
javnosti ga oslovavaju sa Sir James ili moda Lord Dunstable. Meutim, bu-
dimo realni, koliko vaih klijenata ima titulu lorda? Lokalno udruee mu-
ziara sigurno vam nee zahvaivati ako im napravite ekran nalik na onaj sa
slike 14.
Imajte u vidu da morate napraviti kompromis izmeu fleksibilnosti i
sloenosti. Mada je vano da obuhvatite to vei broj izuzetaka, potpuno je
razumno da neke od ih zanemarite jer su suvie malo verovatno da bi
opravdali cenu svog ukuivaa u sistem.
2. U nekim kulturama je uobiajeno da udi dobijaju dva, tri ili vie imena pri roeu. U
krtenici se navode sva imena, ali se u praksi koristi samo jedno, koje se zove uobiajeno ime
(engl. given name). (Prim. prev.)
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 18 str.
18 Poglavlje 1 Osnovni pojmovi
Razlikovae entiteta od atributa ponekad moe biti teko. Rei e vam
opet da je adresa dobar primer kao i da vaa odluka zavisi od prostora pro-
blema. Neki projektanti predlau upotrebu samo jednog entiteta za adresu
koji bi predstavao sve vrste adresa koje se uvaju u sistemu. Sa take gle-
dita praktine realizacije, to reee prua nesporne prednosti u pogledu
kapsuliraa i viekratne upotrebe koda. Meutim, sa take gledita struk-
ture baze podataka, imam odreene rezerve.
Na primer, malo je verovatno da e se adrese zaposlenih i kupaca koristi-
ti na isti nain i za iste namene. Verovatnije je da e se cirkularne poruke
zaposlenima slati putem interne e-pote nego putem klasine pote. Ako je
tako, za drugi sluaj pravila i zahtevi su drugaiji. Grozan ekran za unoee
podataka prikazan na slici 14, ili neto slino tome, moe biti sasvim prikla-
dan za adrese kupaca. Meutim, ako imate samo jedan entitet za adrese,
morate koristiti isti ekran i za adrese zaposlenih; malo je verovatno da je to
potrebno, a jo mae da e se svideti korisnicima.
Domeni
Moda se seate s poetka ovog poglava da se u zaglavu relacija nalaze pa-
rovi ImeAtributa:ImeDomena za svaki atribut. Reeno je da definicija dome-
na odreuje vrstu podataka koje predstava atribut. Tanije reeno, domen
(engl. domain) je skup svih prihvativih vrednosti koje atribut moe imati.
Slika 14 Previe sloen ekran za unoee adresa
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 19 str.
Model podataka 19
Domeni se esto brkaju s tipovima podataka; to su dva razliita pojma.
Tip podataka je fiziki pojam, dok je domen logiki pojam. Broj je tip po-
dataka; Starost je domen. I Ulica i Prezime mogu biti predstaveni
poima tekstualnog tipa, ali je oigledno da su u pitau razliite vrste
tekstualnih poa, koja pripadaju razliitim domenima.
Domen je ui pojam od tipa podataka jer definicija domena zahteva pre-
cizniji opis validnih podataka. Uzmite kao primer domen StrunaSprema,
koji predstava strunu spremu osobe. U emi baze podataka, taj atribut se
moe definisati kao Text, ali to ne moe biti bilo koji tekst, ve samo element
iz skupa {nia, sreda, via, visoka, magistratura, doktorat}.
Razume se, ne moete sve domene definisati pojedinanim navoeem
prihvativih vrednosti. Starost, na primer, sadri otprilike stotinak vrednosti
ako je u pitau starost osoba, ali to mogu biti desetine hiada razliitih vred-
nosti kada su u pitau muzejski eksponati. U takvim sluajevima, umesto u
obliku liste vrednosti, lake je definisati domen u obliku pravila koja utvru-
ju da li odreena vrednost pripada skupu prihvativih vrednosti. Na primer,
StarostOsobe moe se definisati kao celobrojna vrednost u opsegu od 0 do
120, dok bi StarostEksponata bila celobrojna vrednost vea od 0.
Moda ste sad pomislili da je domen kombinacija tipa podataka i pravila
za ispravnost podataka. Ako tako mislite, neete daleko stii. Pravila ispravno-
sti podataka iskuivo su deo integriteta podataka, a ne opisa podataka. Na
primer, pravilo ispravnosti za potanske brojeve odreuje da su prihvaivi
samo odreeni brojevi, dok je domen za potanske brojeve petocifreni broj.
Obratite pau na to da se u navedenim definicijama pomie vrsta
podataka koji se evidentiraju (znakovni ili numeriki). To puno podsea na tip
podataka, ali ipak nije tako. Tipovi podataka su, kao to je ve napomenuto,
fiziki pojam; oni se definiu i zadaju u obliku koji prepoznaje maina baze
podataka. Bilo bi pogreno definisati domen kao varchar(30) ili Long Integer
jer su to opisi specifini za odreenu mainu baze podataka (SQL Server).
Za svaka dva data domena, ako je mogue porediti atribute definisane u
tim domenima (pa prema tome, obavati i relacione operacije kao to je spa-
jae, to emo razmotriti u poglavu 5), kae se da su oni kompatibilni po
tipu (engl. type compatible). Na primer, dve relacije prikazane na slici 15
mogu se povezati putem atributa EmployeeID = SalespersonID (ifra zapo-
slenog = ifra prodavca). To moete uraditi npr. da biste dobili spisak faktura
koje je svaki zaposleni izdao. Domeni EmployeeID i SalespersonID kompa-
tibilni su po tipu. Meutim, ako pokuate da kombinujete te dve relacije pu-
tem atributa EmployeeID = OrderID (ifra zaposlenog = broj porudbine),
verovatno neete dobiti smislen rezultat, uprkos tome to su oba domena
definisana sa istim tipom podataka.
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 20 str.
20 Poglavlje 1 Osnovni pojmovi
Naalost, ni maina baze podataka Jet, niti SQL Server ne pruaju
ugraenu podrku za domene koja bi bila jaa od obine provere tipova
podataka. ak i za tipove podataka, nijedna maina baze podataka ne obava
striktnu proveru tipa: obe e mirno konvertovati podatke u pozadini. Na pri-
mer, ako koristite Microsoftov Access i u tabeli Employees definisali ste da
je EmployeeID tipa Long Integer, a u tabeli Invoices (fakture) atribut In-
voiceTotal (ukupan zbir) definisan je kao tip Currency, moete napraviti upit
koji povezuje te dve tabele kao EmployeeID = InvoiceTotal. Microsoftov Jet
e vam ubazno sastaviti spisak zaposlenih ije su ifre (EmployeeID) jed-
nake ukupnim zbirovima odreenih faktura. Ta dva atributa nisu kompati-
bilna po tipu, ali to Jet ne zna ili zanemaruje.
Zato biste se onda uopte petali s domenima? Zato to su oni, kao to
emo videti u treem delu kige, izuzetno korisne alatke pri projektovau
baza podataka. Da li su ta dva atributa meusobno zameivi? Postoje li
pravila koja vae u jednom, a ne vae u drugom domenu? To su vana pi-
taa kada projektujete model podataka, a analiza domena vam pomae da
naete odgovore.
Veze/odnosi izmeu entiteta
Osim atributa svakog entiteta, model podataka mora da definie i veze ili od-
nose koji postoje izmeu entiteta. Na pojmovnom nivou, veza ili odnos
(engl. relationship) jeste asocijacija izmeu entiteta. Reenica kupci kupu-
ju robu pokazuje da postoji veza izmeu entiteta Kupci i Roba. Entiteti iz-
meu kojih postoji veza ili odnos zovu se uesnici veze (engl. praticipants).
Slika 15 Relacije Employees (zaposleni) i Orders (porudbine)
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 21 str.
Model podataka 21
Broj uesnika odreuje stepen veze. (Stepen veze je slian, ali ne i jednak,
stepenu relacije, to je ukupan broj atributa.)
Velika veina veza izmeu entiteta je binarna, kao u primeru kupci
kupuju robu, ali to nije pravilo. Uobiajene su i ternarne veze, tj. one s tri
uesnika. Binarne veze zaposleni prodaju robu i kupci kupuju robu impli-
citno podrazumevaju postojae ternarne veze zaposleni prodaju robu kup-
cima. Meutim, navedene dve binarne veze ne omoguavaju nam da
saznamo koji su zaposleni koju robu prodali kojim kupcima; to se moe sazna-
ti samo pomou ternarne veze.
Specijalan sluaj binarne veze je entitet koju uestvuje u vezi sa samim
sobom. To se esto zove veza tipa sastavnice (engl. bill of materials relati-
onship) i najee se koristi za predstavae hijerarhijskih struktura. Uo-
biajen primer je odnos izmeu zaposlenih i nadreenih rukovodilaca. Svaki
zaposleni moe istovremeno i biti rukovodilac i imati sebi nadreenog ruko-
vodioca.
Veza ili odnos izmeu dva entiteta moe biti tipa jedan prema jedan,
jedan prema vie ili vie prema vie. Veze tipa jedan prema jedan su
retke, ali mogu biti korisne u nekim okolnostima.
Veze tipa jedan prema vie verovatno su najuobiajenija vrsta. Jedna
faktura se sastoji od vie artikala. Jedan prodavac izdaje vie faktura. U oba
primera imamo vezu tipa jedan prema vie.
Iako nisu toliko este kao veze tipa jedan prema vie, veze tipa vie
prema vie nisu neuobiajene i mogu se nai brojni primeri. Jedan kupac
kupuje vie artikala, a isti artikal moe kupiti vie kupaca. Vie studenata
slua predavaa jednog profesora, a isti student moe sluati predavaa
vie profesora. Veze tipa vie prema vie ne mogu se direktno predstaviti u
relacionom modelu, ali je ihov indirektan oblik vrlo jednostavan, kao to
emo videti u poglavu 3.
Uestvovae jednog entiteta u vezi moe biti delimino ili potpuno.
Ako entitet ne moe da postoji ukoliko ne uestvuje u nekoj vezi, uestvo-
vae je potpuno; u suprotnom, uestvovae je delimino. Na primer, poda-
ci o odreenom Prodavcu ne mogu logiki da postoje ako ne postoji
odgovarajui Zaposleni. Obrnuto nije tano. Poto zaposleni moe biti i
neto drugo osim prodavca, moe postojati zapis o Zaposlenom bez odgova-
rajueg zapisa meu Prodavcima. Prema tome, uestvovae Zaposlenog u
vezi je delimino, dok je uestvovae Prodavca potpuno.
Trik je u tome da tvrda o deliminom ili potpunom uestvovau bude
tana za sve instance (primerke) entiteta, u svim sluajevima. Na primer,
nije neuobiajeno da kompanija promeni dobavaa za odreeni artikal.
Ako je uestvovae entiteta Artikal u vezi dobavai dobavaju artikle de-
finisano kao potpuno, tekueg dobavaa neete moi da izbriete ako ne iz-
briete i sve podatke o artiklima koje vam on dobava.
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 22 str.
22 Poglavlje 1 Osnovni pojmovi
Dijagrami entiteta i veza
Model entiteta i veza, koji podatke opisuje izraene kao entitete, atribute i
veze, uveo je Peter Pin Shan Chen 1976. godine.
3
Istovremeno, predloio je
metodu predstavaa pomou dijagrama nazvanih Entity Relationship (E/
R) dijagrami, koja je postala iroko prihvaena. E/R dijagrami se sastoje od
pravougaonika, koji predstavaju entitete, elipsi, koje predstavaju atribute i
rombova, koji predstavaju veze izmeu entiteta (slika 16).
3. Peter Pin Shan Chen, The Entity Relationship Model Toward a Unified View of Da-
ta?, ACM TODS 1, broj 1 (mart 1976).
Slika 16 Primer E/R dijagrama
vie
nula ili jedan
nula ili vie
jedan
ifraZaposlenog MestoNaKomeIgra
FudbalskiTim
Zaposleni
igraju fudbal
Zaposleni
evidentiraju
porudbine
Porudbina
Zaposleni
BrojPorudbine
Kupac ifraProdavca
DatumPorudbine
ifraZaposlenog
Funkcija Ime
Prezime
PBP, June 2, 2006 12:35 pm
01_PBP.fm, 23 str.
Saetak 23
Priroda veza izmeu entiteta (jedan prema jedan, jedan prema vie
ili vie prema vie) predstava se na vie naina. Mnogi koriste simbole 1 i
M ili 1 i (simbol za beskonanost). Ja koristim oblik vranina kanda, pri-
kazan na slici 16, koji smatram izraajnijim.
Velika prednost E/R dijagrama jeste to to se lako crtaju i razumeju. Ja
obino crtam atribute na odvojenom dijagramu jer se mogu praviti dijagrami
sa razliitim nivoima detaa. Uglavnom, na dijagramu razmatramo ili entite-
te koji ine model i veze izmeu ih, ili atribute datog entiteta, ali retko raz-
matramo oba aspekta istovremeno.
Saetak
U ovom poglavu razmotrili smo komponente sistema koji radi s bazom
podataka i postavili osnovu za preostali deo gradiva u kizi. Poeli smo od
opisa prostora problema kao odreenog, precizno definisanog dela stvarnog
sveta. Konceptualni model podataka je opis prostora problema izraen po-
mou entiteta, atributa i domena u kojima su definisani. Fizika struktura
modela podataka je ema baze podataka, koja se realizuje u bazi podataka. I
najzad, maina baze podataka fiziki manipulie podacima na zahtev aplika-
cije sainjene od obrazaca i izvetaja s kojima korisnici rade.
U narednom poglavu, detanije emo prouiti strukturu baze podataka
dok budemo razmatrali principe normalizacije.