VISOKA TEHNIČKA ŠKOLASTRUKOVNIH STUDIJA, NOVI BEOGRAD

SEMINARSKI RAD

PREDMET: INFORMACIONI SISTEMI

TEMA: ELEMENTI BAZE PODATAKA

Profesor: Studenti:
Dr. Miroslav Medenica Stefan Goranović 80/15
Marko Rajković 148/15
 SADRŽAJ:

1. UVOD…………………………………………………………………………2
2. TEORIJSKE OSNOVE………………………………………………………. 3
2.1. Osnovni pojmovi vezani uz baze podataka………………………………. 3
2.2. Ciljevi koji se nastoje postići korišćenjem baza podataka……………….. 4
2.3. Arhitektura baze podataka……………………………………………….. 5
2.4. Modeli baze podataka……………………………………………………..7
2.5. Jezici za rad sa bazama podataka………………………………………… 9
2.6. Poznati softverski paketi za rad sa bazama podataka…………………… 10
2.7. Životni ciklus baze podataka……………………………………………. 11
2.7.1. Analiza potreba…………………………………………..…………. 11
2.7.2. Modeliranje podataka………………………………………………..12
2.7.3. Implementacija…………………………………………………..….. 12
2.7.4. Testiranje…………………………………………………………….12
2.7.5. Održavanje……………………………………….…………………..12
3. ELEMENTI BAZE PODATAKA…………………………………………...13
3.1. Relacija………………………………………………………………….. 13
3.1.1. Vrste relacija…………………………………….………………….. 14
3.1.2. Kreiranje relacija između tabela…….………………………………15
3.1.3. Brisanje relacija između tabela…………….………………………. 17
3.2. Entitet…………………………………………………………………… 17
3.3. Atribut……………………………………………………………………18
3.4. Ključ…………………………………………………………………….. 19
3.4.1. Primarni ključ………………………………………………..………19
3.4.2. Strani ključ……………………………………………………….…. 20
3.5. Polje…………………………………………………………………….. 21
3.5.1. Podešavanje tipa i parametara polja………………………………. 21
3.6. Slog………………………………………………………………………24
4. ZAKLjUČAK………………………………………………………………. 26
LITERATURA………………………………………………………………… 27

1
 1. UVOD

Od samog početka korišćenja računara, obrada različitih vrsta podataka bila je jedan od
osnovnih zadataka. Podaci i informacije su postali pokretačka snaga modernog poslovanja na
Zapadu pa i u celom svetu. Kada želimo da imamo kvalitetne informacije o svim segmentima
našeg poslovnog ili čak privatnog života najbolje je da na određen način organizujemo sve
podatke koje mogu da nam pruže informacije koje su od velike važnosti u trenutku kada su nam
potrebne. Tada bi bilo najbolje da podaci za svaki pojedini element budu organizovani tako da se
mogu smestiti u tabele sa jednim zaglavljem. Može, a veoma često i mora da bude više tabela
koje bi obuhvatili sve segmente našeg interesovanja. Svi ti segmenti se neretko zbog svoje
prirode moraju organizovati u posebne tabele , a te tabele se mogu povezivati preko određenih
zajedničkih elemenata. Skup više tih tabela koje služe jednom zajedničkom cilju, zajedno sa
njihovim veznim elementima naziva se BAZOM PODATAKA. Njihov zajednički cilj se odnosi
na svođenje veoma brze i uspešne informacije o svim događajima koji se dešavaju unutar jedne
celine. Kada kucamo nešto u Wordu , vršimo neke tabelarne proračune u Exelu u više tabela
onda imamo dodira sa bazom podataka. To je u stvari pitanje organizacije naših podataka. Ako
ispisujemo datoteke u Wordu i smeštamo ih po određenim direktorijumima na neki način
organizujemo bazu podataka. U slučaju kada naša baza postane toliko komplikovana da nismo
više u stanju da jednostavno kontrolišemo tok i razvoj podataka potrebno je početi razmišljati o
sistemu za upravljanje bazom podataka.
Najranija poznata upotreba termina “baza podataka” potiče iz 1963. kada je održan
simpozijum pod naslovom “Razvoj i upravljanje računarsko centralizovanom bazom podataka”.
Baza podataka kao jedinstvena reč postala je uobičajena u Evropi u ranim 1970-im. Prvi sistemi
upravljanja bazom podataka razvijeni su 1960-ih. Začetnik u tom polju je Charles Bachman .
Njegovi rani radovi pokazuju da mu je bio cilj stvaranje delotvornije upotrebe novih uređaja sa
direktnim pristupom uskladištenim informacijama koji su postali dostupni . Do tada se obrada
podataka temeljila na bušenim karticama i magnetskoj traci, pa je tako serija obrada bila
dominantna aktivnost. Dva su se ključna modela podataka pojavila u to vreme: CODASYL je
razvio mrežni model baziran na Bachamanovim idejama, North American Rockwell je razvio
hijerarhijski model. Odosni model je predložio E.F. Codd 1970. godine. Oracle i DB2 su se
pojavili tek oko 1980.godine.
Za vreme 1980-ih godina istraživačka aktivnost se usredsredila na sisteme distributivnih
baza podataka i na aparate baza podataka, međutim taj je napredak imao mali učinak na tržište. U
1990-im godinama pažnja se prebacila na baze podataka orijentisane prema objektu. Tu je bilo
nekakvog uspeha gde je bilo potrebno rukovoditi komleksnijim podacima.
U 2000-im godinama nastale su XML baze podataka. Glavni cilj XML baza podataka je
uklanjanje tradicionalne podele između dokumenata i podataka, dopuštajući svim
organizacionim informacijskim resursima da se drže na jednom mestu bez obzira da li su visoko
struktuirani ili ne.

2
 2. TEORIJSKE OSNOVE

2.1. Osnovni pojmovi vezani uz baze podataka

Baze podataka predstavljaju viši nivo rada sa podacima u odnosu na klasične programske
jezike. Reč je o tehnologiji koja je nastala sa namerom da se uklone slabosti tradicionalne
“automatske obrade podataka” iz 60-tih i 70-tih godina 20. veka. Ta tehnologija osigurala je veću
produktivnost, kvalitet i pouzdanost u razvoju aplikacija koje se svode na skladištenje i
pretraživanje podataka u računaru. U svakoj delatnosti svakodnevno postoji potreba za
rukovanjem sa velikim brojem podataka. Da bi rad sa podacima bio efikasan, neophodno je da se
oni grupišu prema određenim kriterijumima. Grupisanjem srodnih podataka u oblike pogodne za
korišćenje nastaju baze podataka. 
Baza podataka je kolekcija podataka organizovanih za brzo pretraživanje i pristup, koja
zajedno sa sistemom za administraciju, organizovanje i memorisanje tih podataka, čini sistem
baze podataka. Iz ugla korisnika, podaci su na neki logički način povezani. Baza podataka je
skup međusobno povezanih podataka, skladištenih u spoljašnjoj memoriji računara. Podaci su
istovremeno dostupni raznim korisnicima i aplikacijskim programima. Ubacivanje, promena,
brisanje i čitanje podataka obavlja se posredstvom zajedničkog softvera. Korisnici i aplikacije pri
tome ne moraju da poznaju detalje fizičkog prikaza podataka, već se usredsređuju na logičku
strukturu baze.
Korisnici pristupaju bazi podataka prvenstveno preko upitnika. Korišćenjem ključnih reči i
svrstavanjem komandi korisnici mogu brzo da pronađu, preurede, grupišu i odaberu oblast u
mnogim zapisima koje treba vratiti ili pomoću kojih treba sastaviti izveštaje o posebnoj grupi
podataka u skladu s pravilima dotičnog sistema vođenja baze podataka.
Sistem za upravljanje bazom podataka (Data Base Management System - DBMS) je server
baze podataka. On oblikuje fizički prikaz baze u skladu sa traženom logičkom strukturom.
Takođe, on obavlja u ime klijenata sve operacije sa podacima. Dalje, on je u stanju da podrži
razne baze, od kojih svaka može imati svoju logičku strukturu u skladu sa istim modelom. Isto
tako, brine se za sigurnost podataka i automatizuje administrativne poslove sa bazom. Podaci u
bazi su logički organizovani u skladu sa nekim modelom podataka. Model podataka je skup
pravila koja određuju kako može da izgleda logička struktura baze. Model čini osnovu za
koncipiranje, projektovanje i implementaciju baze. Dosadašnji DBMS-i obično su podržavali
neki od sledećih modela:
 Relacijski model. Zasnovan na matematičkom pojmu relacije. I podaci i veze među
podacima prikazuju se “pravougaonim” tabelama.
 Mrežni model. Baza je predočena usmerenim grafikonom. Čvorovi su tipovi zapisa, a
lukovi definišu veze medu tipovima zapisa.
 Hijerarhijski model. Specijalni slučaj mrežnog modela. Baza je predočena jednim
stablom ili skupom stabala. Čvorovi su tipovi zapisa, a hijerarhijski odnos “nadređeni-
podređeni” izražava veze među tipovima zapisa.

3
  Objektni model. Inspirisan je objektno-orijentisanim programskim jezicima. Baza je
skup trajno uskladištenih objekata koji se sastoje od svojih internih podataka i “metoda”
(operacija) za rukovanje sa tim podacima. Svaki objekt pripada nekoj klasi. Između klasa
se uspostavljaju veze nasleđivanja, agregacije, odnosno međusobnog korišćenja
operacija.
Hijerarhijski i mrežni model bili su u upotrebi u 60-tim i 70-tim godinama 20. veka. Od 80-tih
godina pa sve do današnjih dana preovladava relacijski model. Očekivani prelaz na objektni
model za sada se nije desio, tako da se današnje baze podataka uglavnom još uvek poistovećuju
sa relacijskim bazama.

2.2. Ciljevi koji se nastoje postići korišćenjem baza podataka

Baze podataka predstavljaju viši nivo rada sa podacima u odnosu na klasične programske
jezike. Taj viši nivo rada ogleda se u tome što tehnologija baza podataka nastoji (i u velikoj meri
uspeva) da ispuni sledeće ciljeve:
- Fizička nezavisnost podataka. Razdvaja se logička definicija baze od njene stvarne fizičke
građe. Znači, ako se fizička građa promeni (na primer, podaci se prepišu u druge datoteke na
drugim diskovima), to neće zahtevati promene u postojećim aplikacijama.
- Logička nezavisnost podataka. Razdvaja se globalna logička definicija cele baze podataka od
lokalne logičke definicije za jednu aplikaciju. Znači, ako se logička definicija promeni (na
primer, uvede se novi zapis ili veza), to neće zahtevati promene u postojećim aplikacijama.
Lokalna logička definicija obično se svodi na izdvajanje samo nekih elemenata iz globalne
definicije, uz neke jednostavne transformacije tih elemenata.
- Fleksibilnost pristupa podacima. U starijim mrežnim i hijerarhijskim bazama, staze
pristupanja podacima bile su unapred definisane, dakle korisnik je mogao pretraživati podatke
jedino onim redosledom koji je bio predviđen u vreme projektovanja i implementiranja baze.
Danas se zahteva da korisnik može slobodno da prebira po podacima, i po svom nahođenju da
uspostavlja veze među podacima. Ovom zahtevu zaista zadovoljavaju jedino relacijske baze.
- Istovremeni pristup do podataka. Baza mora da omogući da veći broj korisnika istovremeno
koristi iste podatke. Pri tome ti korisnici ne smeju da ometaju jedan drugoga, i svaki od njih treba
da ima utisak da sam radi sa bazom.
- Čuvanje integriteta. Nastoji se da se automatski sačuva korektnost i konzistencija podataka, i
to u situaciji kad postoje greške u aplikacijama, kao i konfliktne istovremene aktivnosti
korisnika.
- Mogućnost oporavka nakon kvara. Mora da postoji pouzdana zaštita baze u slučaju kvara
hardvera ili grešaka u radu sistemskog softvera.
- Zaštita od neovlašćenog korišćenja. Mora da postoji mogućnost da se korisnicima ograniče
prava korišćenja baze, dakle da se svakom korisniku regulišu ovlašćenja šta sme a šta ne sme da
radi sa podacima.

4
- Zadovoljavajuća brzina pristupa. Operacije sa podacima se moraju odvijati dovoljno brzo, u
skladu sa potrebama određene aplikacije. Na brzinu pristupa može se uticati izborom pogodnih
fizičkih struktura podataka kao i izborom pogodnih algoritama za pretraživanje.
- Mogućnost podešavanja i kontrole. Velika baza zahteva stalnu brigu: praćenje performansi,
menjanje parametara u fizičkoj građi, rutinsko skladištenje rezervnih kopija podataka, regulisanje
ovlašćenja korisnika. Takođe, svrha baze se vremenom menja, pa povremeno treba podesiti i
logičku strukturu. Ovakvi poslovi moraju se obavljati centralizovano. Odgovorna osoba zove se
administrator baze podataka. Administratoru moraju stajati na raspolaganju razni alati i
pomoćna sredstva.

2.3. Arhitektura baze podataka

Arhitektura najvećeg broja sistema baza podataka odgovara predlogu ANSI/SPARC
studijske grupe Američkog nacionalnog instituta za standarde, i poznata je kao ANSI arhitektura.
Ova arhitektura predstavljena je hijerarhijom apstrakcija, pri čemu svaki nivo hijerarhije
uključuje specifični način predstavljanja, prezentaciju objekata, odnosa među objektima i
operacija nad objektima. Hijerarhijska arhitektura omogućuje prirodnu dekompoziciju i efikasni
razvoj sistema za upravljanje bazama podataka.
Arhitektura baze podataka sastoji se od tri “sloja” i sučelja među slojevima, kao što je
prikazano na slici 2.1. Reč je o tri nivoa apstrakcije.
Najniži nivo ANSI arhitekture je unutrašnji nivo. On je najbliži fizičkoj reprezentaciji baze
podataka, koja u računarskom sistemu jedina zaista postoji. Zbog toga se unutrašnji nivo često i
zove “nivo fizičke baze podataka”. Fizički nivo se odnosi na fizički prikaz i raspored podataka
na jedinicama spoljne memorije. To je aspekt koji vide samo sistemski programeri (oni koji su
razvili DBMS). Sam fizički nivo može se dalje podeliti na više pod-nivoa apstrakcije, od sasvim
konkretnih staza i cilindara na disku, do već donekle apstraktnih pojmova datoteke i zapisa kakvi
se susreću u klasičnim programskim jezicima. Raspored skladištenja opisuje kako se elementi
logičke definicije baze preslikavaju na fizičke uređaje.
Sledeći nivo ANSI arhitekture je konceptualni (logički) i predstavlja način na koji se podaci
iz fizičke baze podataka predstavljaju korisniku u opštem slučaju. Globalni logički nivo se
odnosi na logičku strukturu cele baze. To je aspekt koji vidi projektant baze odnosno njen
administrator. Zapis logičke definicije naziva se šema (schema). Šema je tekst ili dijagram koji
definiše logičku strukturu baze, i u skladu je sa zadanim modelom. Dakle imenuju se i definišu
svi tipovi podataka i veze među tim tipovima, u skladu sa pravilima korišćenog modela. Takođe,
šema uvodi i ograničenja kojim se čuva integritet podataka.
Najviši nivo ANSI arhitekture je spoljašnji nivo koji predstavu o podacima iz baze
prilagođava potrebama specifičnih korisnika ili grupa korisnika.Lokalni logički nivo se odnosi
na logičku predstavu o delu baze koji koristi pojedina aplikacija.To je aspekt koji vidi korisnik ili
aplikacijski programer. Zapis jedne lokalne logičke definicije zove se pogled (engleski view) ili
pod-šema. To je tekst ili dijagram kojim se imenuju i definišu svi lokalni tipovi podataka i veze

5
među tim tipovima, opet u skladu sa pravilima korišćenog modela.Takođe, pogled zadaje
preslikavanje kojim se iz globalnih podataka i veza izvode lokalni.

Slika 2.1 - Arhitektura baze podataka1

Reprezentacija koja se nalazi na “srednjem”, konceptualnom nivou ANSI hijerarhije zove se

model podataka. Modelom podataka predstavlja se logička struktura svih podataka u bazi i skup
operacija koje korisnik može izvršiti nad tim podacima.To znači da se na konceptualnom nivou
mogu “videti” svi podaci iz fizičke baze podataka, samo što je njihova reprezentacija pogodnija
za korisnika od fizičke (na višem je nivou apstrakcije). Pojedini korisnici ili grupe korisnika
mogu imati svoj sopstveni specifičan način gledanja na model podataka (npr. iz razloga zaštite ili
udobnosti), pa se pogledi (podmodeli, spoljašnji nivo hijerarhije) nalaze iznad modela u
hijerarhiji apstrakcija. Isti podaci iz fizičke baze podataka (i sa konceptualnog nivoa), na ovom
nivou mogu se raznim korisnicima predstaviti na razne načine, dok se postojanje nekih podataka
može od nekih korisnika i sakriti. Zato postoji tačno jedan model podataka u sistemu, koji se
odnosi na celokupnost baze podataka, i veći broj spoljašnjih pogleda, od kojih se svaki sastoji od
apstraktne slike dela baze podataka. Na primer, baza podataka o studentima može da sadrži
podatke iz dosijea studenata, sa ličnim podacima i podacima o uspehu (predmetima, ocenama,
datumima polaganja, nagradama, kaznama) svakog studenta. Na konceptualnom nivou podaci
mogu biti predstavljeni tabelama DOSIJE, NASTAVNI PLAN, NAGRADE I KAZNE i
POLAGANJE. Na spoljašnjem nivou, korisnicima statističkih obrada ova baza podataka može se
predstaviti kao da sadrži samo podatke o uspehu (npr. u virtuelnoj tabeli USPEH PO
PREDMETIMA); ostali, lični podaci koji mogu da identifikuju studenta, skrivaju se od
statističkih aplikacija. Različitim podgrupama korisnika mogu odgovarati još apstraktnije
predstave o podacima, koje odgovaraju višim nivoima podmodela.

1
Izvor: http://jadran.izor.hr

6
Korisnik svoje zahteve za operacijama nad bazom podataka postavlja na konceptualnom ili
spoljašnjem nivou, i to interaktivno, na posebnom “jeziku podataka”, ili programski, kada je
jezik podataka ugnježden u neki programski jezik opšte namene (tzv. matični jezik).
Na nivou fizičke baze podataka – unutrašnjem nivou, model podataka predstavlja se specifičnim,
fizičkim strukturama podataka (datotekama sa sekvencijalnim, indeksnim ili direktnim
pristupom), i procedurama za fizičku realizaciju operacija koje korisnik zadaje na višem nivou.
Primarni cilj modela podataka u kontekstu baza podataka jeste da obezbedi formalni sistem za
predstavljanje podataka i manipulisanje podacima u bazi podataka.
Za stvaranje baze podataka potrebno je zadati samo šemu i poglede. DBMS tada automatski
generiše potrebni raspored skladištenja i fizičku bazu. Administrator može samo donekle uticati
na fizičku građu baze, podešavanjem njemu dostupnih parametara. Programi i korisnici ne
pristupaju direktno fizičkoj bazi, već dobijaju ili skladište podatke posredstvom DBMS-a.
Komunikacija programa odnosno korisnika sa DBMS-om obavlja se na lokalnom logičkom
nivou.

2.4. Modeli baze podataka

Model baze podataka se može posmatrati kao kolekcija sledeća tri skupa:
a) skup tipova objekata,
b) skup operacija nad objektima definisanih tipova,
c) skup pravila integriteta.
a) Skup tipova objekata čini strukturni deo modela. Tipovima objekata opisuju se entiteti
(objekti, stvari, lica, pojave, događaji od značaja koji se mogu jednoznačno identifikovati) koji
su relevantni za korisnike baze (objekat i entitet će se nadalje uglavnom upotrebljavati
sinonimno, osim ako se naglasi drugačije). Sami tipovi entiteta karakterišu se svojstvima.
Na primer, izdavačka baza podataka može da sadrži, između ostalih, tipove entiteta KNJIGA,
PISAC i IZDAVAČ, sa odgovarajućim svojstvima (slika 2.2).

Slika 2.2 - Tipovi entiteta izdavačke baze podataka2

2
Izvor: http://jadran.izor.hr

7
Značenje svojstava je uglavnom očigledno: svaka knjiga ima naslov i oblast kojoj pripada, uz
pisca se kao značajna svojstva navode njegovo ime, broj objavljenih naslova i država čiji je
državljanin, dok izdavača karakterišu njegov naziv, status (u funkciji broja izdatih naslova) i
država u kojoj je registrovan. Specifični model (npr. relacioni, mrežni, hijerarhijski) izabraće
specifičan način za opisivanje ovih tipova entiteta i njihovih svojstava.
b) Skup operacija čini manipulativni deo modela. Operacijama se zadaju upiti i radnje nad
entitetima, tj. pretraživanje i menjanje (ažuriranje) podataka o entitetima. Na primer, radnje nad
pojedinačnim entitetima mogu biti:
– registrovati novu knjigu,
– rashodovati knjigu,
– izmeniti državljanstvo pisca,
– izmeniti status izdavača.
Primer operacije kojom se zadaje upit nad pojedinačnim tipom entiteta može biti:
– štampati spisak knjiga iz zadate oblasti.
c) Skup pravila integriteta čini integritetni deo modela. Pravila integriteta definišu uslove
integriteta podataka u bazi podataka, tj. svojstva podataka ili odnosa među podacima, koji
moraju biti zadovoljeni da bi stanje baze bilo valjano.
Na primer, uslovi integriteta pridruženi pojedinačnim tipovima entiteta mogu biti:
– dva razna izdavača ne mogu imati isti naziv,
– pri promeni broja naslova pisca, novi broj naslova mora biti veći od prethodnog (starog).
Osim upita, radnji i uslova integriteta koji se odnose na pojedinačne tipove entiteta, kao u
prethodnim primerima, neki upiti i radnje mogu se odnositi na više tipova entiteta, kao na
primer:
– štampati spisak svih knjiga datog pisca,
– promeniti izdavača za datu knjigu.
I upiti i radnje ove vrste (nad više tipova entiteta) zadaju se nad odnosima među tipovima
entiteta. Na primer, IZDAVAŠTVO se može definisati kao odnos između tipova entiteta
IZDAVAČ i KNJIGA, dok se AUTOR može definisati kao odnos između tipova entiteta PISAC
i KNJIGA. Ti odnosi se mogu posmatrati i kao apstraktni tipovi entiteta u modelu (sa svojim
svojstvima). Svojstva odnosa IZDAVAŠTVO i AUTOR mogu se prikazati slikom 2.3.

Slika 2.3 - Tipovi odnosa izdavačke baze podataka3

3
Izvor: http://jadran.izor.hr

8
Redni broj mogao bi da označava da je dati pisac naveden kao prvi (drugi, treći, itd.) autor date
knjige.
Nad odnosima se mogu zadavati i uslovi integriteta, na primer:
– dva razna izdavača ne mogu u istoj godini izdati istu knjigu.
Najpoznatiji klasični modeli podataka su hijerarhijski, mrežni i relacioni model.
Za hijerarhijski i mrežni model karakteristično je da su nastali u procesu apstrakcije ili indukcije
iz postojećih implementacija SUBP, a ne kao apstraktni modeli. Sami mrežni i hijerarhijski
sistemi su pre relacioni i karakterišu se nižim nivoom apstrakcije nego relacioni sistemi, pre
svega slogovnom prirodom podataka i manipulisanja podacima. Sledeći primer pokazuje način
na koji se u hijerarhijskom, mrežnom i relacionom sistemu realizuju delovi odgovarajućih
modela. Neka među entitetima KNJIGA i IZDAVAČ postoji funkcionalni odnos, tj. neka važi da
jednu knjigu može da izdaje samo jedan izdavač, dok jedan izdavač može da izdaje veći broj
knjiga. Strukturni deo hijerarhijskog modela u ovom slučaju sastoji se od dva tipa entiteta –
KNJIGA i IZDAVAČ sa pripadnim svojstvima, i jednog tipa funkcionalne veze –
KNJIGA→IZDAVAČ (slika 2.4). U ovoj funkcionalnoj vezi tip entiteta IZDAVAČ je tzv.
roditeljski tip, a tip entiteta KNJIGA je tzv. tip deteta. Jedan tip deteta može imati najviše jedan
roditeljski tip.

Slika 2.4 - Funkcionalna veza u hijerarhijskom modelu4

2.5. Jezici za rad sa bazama podataka

Komunikacija korisnika odnosno aplikacijskog programa i DBMS-a odvija se pomoću posebnih
jezika.Ti jezici tradicionalno se dele na sledeće kategorije:
 Jezik za opis podataka (Data Description Language - DDL). Služi projektantu baze ili
administratoru u svrhu zapisivanja šeme ili pogleda. Dakle, tim jezikom se definišu
podaci i veze među podacima, i to na logičkom nivou. Postoji posebna varijanta jezika za
šemu, a posebna za poglede. Naredbe DDL obično podsećaju na naredbe za definisanje
složenih tipova podataka u jezicima poput COBOL, PL/I, C, Pascal.
 Jezik za manipulisanje podacima (Data Manipulation Language - DML). Služi
programeru za uspostavljanje veze između aplikacijskog programa i baze. Naredbe DML
omogućuju “manevrisanje” po bazi, te jednostavne operacije kao što su upis, promena,
brisanje ili čitanje zapisa. U nekim softverskim paketima, DML je zapravo biblioteka
4
Izvor: http://jadran.izor.hr

9
 potprograma: “naredba” u DML svodi se na poziv potprograma. U drugim paketima
zaista se radi o posebnom jeziku: programer tada piše program u kojem su izmešane
naredbe dva jezika, pa takav program treba prevoditi sa dva prevodioca (DML-
precompiler, obični compiler).
 Jezik za postavljanje upita (Query Language - QL). Služi neposrednom korisniku za
interaktivno pretraživanje baze. To je jezik koji podseća na govorni (engleski) jezik
Naredbe su neproceduralne, dakle takve da samo utvrđuju rezultat koji se želi dobiti, a ne
i postupak za dobijanje rezultata.
Ovakva podela na tri jezika danas je već prilično zastarela. Naime, kod relacijskih baza postoji
tendencija da se sva tri jezika objedine u jedan sveobuhvatni. Primer takvog integrisanog jezika
za relacijske baze je SQL: on služi za definisanje podataka, manipulisanje i pretraživanje.
Integrisani jezik se može koristiti interaktivno (preko on-line interpretera) ili se on može
pojavljivati uklopljen u aplikacijske programe. Gore spomenute vrste jezika nisu programski
jezici. Dakle ti jezici su nam nužni da bi se povezali sa bazom, no oni nam nisu dovoljni za
razvoj aplikacija koje će nešto raditi sa podacima iz baze.
Tradicionalni način razvoja aplikacija koje rade sa bazom je korišćenje klasičnih
programskih jezika (COBOL, PL/I, C, Pascal . . . ) sa ubačenim DML-naredbama. U 80-tim
godinama 20. veka bili su dosta popularni i tzv. jezici 4. generacije (4-th Generation Languages
- 4GL): reč je o jezicima koji su bili namenjeni isključivo za rad sa bazama, te su zato u tom
kontekstu bili produktivniji od klasičnih programskih jezika opšte namene.
Problem sa jezicima 4. generacije je bio u njihovoj nestandardnosti: svaki od njih je u pravilu bio
deo nekog određenog softverskog paketa za baze podataka, te se nije mogao koristiti izvan tog
paketa (baze).
U današnje vreme, aplikacije se najčešće razvijaju u standardnim objektno orijentisanim
programskim jezicima (Java, C++, Smalltalk...). Za interakcije sa bazom koriste se unapred
pripremljene klase objekata. Ovakva tehnika je dovoljno produktivna zbog korišćenja gotovih
klasa, a rezultujući program se lako doteruje, uklapa u veće sisteme ili prenosi sa jedne baze na
drugu.

2.6. Poznati softverski paketi za rad sa bazama podataka

Baze podataka se u pravilu realizuju korišćenjem nekog od proverenih softverskih paketa.
Tabela 1 daje pregled softvera koji u ovom trenutku predstavljaju tehnološki vrh i imaju značajan
udeo na svetskom tržištu. Gotovo svi današnji softverski paketi podržavaju relacijski model i
SQL. Svaki od njih sadrži svoj DBMS, uobičajene klijente (na primer interaktivni interpreter
SQL), te biblioteke i alate za razvoj aplikacija. Svaki paket isporučuje se u verzijama za razne
računarske platforme (operativne sisteme). Konkurencija među proizvođačima softvera za baze
podataka je izuzetno velika, tako da je poslednjih godina često dolazilo do njihovog nestanka,
spajanja ili preuzimanja. Lista relevantnih softverskih paketa zato je svake godine sve kraća.
Jedino osveženje predstavlja nedavna pojava public-domain softvera poput MySQL.

10
Tabela 1. Poznati softverski paketi za rad sa bazama podataka
Proizvođač Proizvod Operativni sistem Jezici
Linux, UNIX (razni),
MS Windows
IBM Corporation DB2 SQL, COBOL, Java...
NT/2000/XP, VMS,
MVS, VM, OS/400
MS Windows (razni),
Oracle Corporation Oracle Mac OS, UNIX (razni), SQL, Java i drugi
Linux i drugi
UNIX (razni), Linux,
IBM Corporation (pre:
Informix MS Windows SQL, Java i drugi
Informix Software Inc.)
NT/2000/XP
MS Windows
Microsoft MS SQL Server SQL, C++,...
NT/2000/XP
MS Windows (razni),
MySQL AB MySQL Mac OS, UNIX (razni), SQL, C, PHP,...
Linux
MS Windows NT/2000,
Sybase Inc. Sybase SQL Server OS/2, Mac, UNIX SQL, COBOL,...
(razni), UNIXWare
Hewlett Packard Co. Allbase/SQL UNIX (HP-UX) SQL, 4GL, C,...
MS Windows NT/2000,
Cincom Systems Inc. Supra VM, MVS, VMS, SQL, COBOL,...
UNIX (razni), Linux
Microsoft Corporation MS Access MS Windows (razni) Access, Basic, SQL

2.7.Životni ciklus baze podataka

Uvođenje baze podataka u neko preduzeće ili ustanovu predstavlja složeni zadatak koji
zahteva timski rad stručnjaka raznih profila. To je projekat koji se može podeliti u pet faza:
analiza potreba, modeliranje podataka, implementacija, testiranje i održavanje.

2.7.1. Analiza potreba

Proučavaju se tokovi informacija u preduzeću. Uočavaju se podaci koje treba skladištiti i
veze među njima. U velikim preduzećima, gde postoje razne grupe korisnika, pojaviće se razni
“pogledi” na podatke. Te poglede treba uskladiti tako da se eliminiše preopširnost i
nekonzistentnost. Na primer, treba u raznim pogledima prepoznati sinonime i homonime i
uskladiti terminologiju.
Analiza potreba takođe treba da obuhvati analizu transakcija (operacija) koje će se obavljati nad
bazom podataka, budući da to može isto imati uticaja na sadržaj i konačni oblik baze. Važno je
proceniti frekvenciju i opseg pojedinih transakcija kao i zahteve za performanse. Rezultat analize
je dokument (pisan neformalno u prirodnom jeziku) koji se zove specifikacija potreba.

11
2.7.2. Modeliranje podataka
Različiti pogledi na podatke, otkriveni u fazi analize, sintezuju se u jednu celinu - globalnu
šemu. Precizno se utvrđuju tipovi podataka. Šema se dalje doteruje (“normalizuje”) tako da
zadovolji neke zahteve kvaliteta. Takođe, šema se prilagođava ograničenjima koje postavlja
zadati model podataka, te se dodatno modifikuje da bi bolje mogla udovoljiti zahtevima na
performanse. Na kraju se iz šeme izvode pogledi (pod-šeme) za pojedine aplikacije (grupe
korisnika).

2.7.3. Implementacija
Na osnovu šeme i pod-šema, te uz pomoć dostupnog DBMS-a, fizički se realizuje baza
podataka na računaru. U DBMS-u obično postoje parametri kojima se može uticati na fizičku
organizaciju baze. Parametri se podešavaju tako da se osigura efikasan rad najvažnijih
transakcija. Razvija se skup programa koji realizuju pojedine transakcije te pokrivaju potrebe
raznih aplikacija. Baza se inicijalno puni podacima.

2.7.4. Testiranje
Korisnici eksperimentalno rade sa bazom i proveravaju da li ona zadovoljava svim
zahtevima. Nastoji se da se otkriju greške koje mogu da se potkradu u svakoj od faza razvoja:
dakle u analizi potreba, modeliranju podataka, implementaciji. Greške u ranijim fazama imaju
teže posledice. Na primer, greška u analizi potreba prouzrokovaće da transakcije možda korektno
rade, ali ne ono što korisnicima treba već nešto drugo. Dobro bi bilo kad bi se takvi propusti
otkrili pre implementacije. Zato se u novije vreme, pre prave implementacije, razvijaju približni
prototipovi baze podataka, pa se oni pokazuju korisnicima. Jeftinu izradu prototipova
omogućuju jezici 4. generacije i objektno-orijentisani jezici.

2.7.5. Održavanje
Odvija se u vreme kad je baza već ušla u redovnu upotrebu. Sastoji se od sledećeg:
- popravak grešaka koje nisu bile otkrivene u fazi testiranja;
- uvođenje promena zbog novih zahteva korisnika;
- podešavanje parametara u DBMS u svrhu poboljšavanja performansi
- održavanje zahteva da se stalno prati rad sa bazom, i to tako da to praćenje ne ometa korisnike.
Administratoru baze podataka prilikom održavanja treba da stoje na raspolaganju
odgovarajući alati (utility programi).

12
 3. ELEMENTI BAZE PODATAKA

Relativno niska fleksibilnost hijerarhijske i mrežne strukture baza podataka, koje zahtevaju
da elementi baze budu unapred specificirani (direktorijumi, indeksi…) uslovili su pojavu
fleksibilnijih struktura organizacije baze podataka, te se od 1970 godine zapažaju prve najave
relacionih baza podataka.
Osnovna karakteristika relacionih baza podataka je da su informacije podeljene u logičke
skupove podataka. Svaki logički skup podataka predstavlja tabelu baze podataka. Tabele su
osnovni objekti relacione baze podataka. Kad se podaci smeste u tabele, moguće je sa njima
obavljati razne operacije npr. prikazivanje, dodavanje, brisanje, pretraživanje i štampanje.
Postoji nekoliko značajnih razloga za raspodelu podataka u tabele u okviru baze podataka:
o Smanjuje se broj ponavljanja istih podataka u okviru baze.
o Ako je potrebna promena podataka u bazi ona se vrši samo na jednom mestu (u
tabeli).
o Svaka tabela u relacionoj bazi podataka predstavlja jedan objekat sa podacima
koji
predstavljaju logičku celinu (učenici, ocene, zaposleni...).
o Tabele mogu biti među sobom povezane što omogućava grupisanje, pretraživanje
i
dobijanje informacija u različitim oblicima.
o Lakše se i brže dolazi do potrebnih informacija.
Relacioni model je još uvek najpopularniji model podataka zbog svoje jednostavne strukture i
jednostavnog jezika baze podataka (SQL).
Elementi baze podataka su:
 relacija,
 entitet,
 atribut,
 ključ,
 polje i
 slog.

3.1. Relacija

Objekti međusobno mogu biti povezani različitim odnosima odnosno relacijama. Svaka
takva relacija može da poseduje posebna svojstva. Relacije se mogu iskoristiti kod pretraživanja
međusobno povezanih podataka, na primer, kod pretraživanja podataka o registrovanim vozilima
i njihovim vlasnicima.
Relacija je asocijacija postavljena između zajedničkih polja iz dve tabele. Relacije se
postavljaju da bi mogle efikasno da se koriste tabele i podaci u njima. Relacije su zapravo

13
uputstvo Microsoft Access-u kako da ponovo spoji podatke iz tablica.Tek nakon što su
postavljene relacije mogu se kreirati upiti, forme i izveštaji za prikazivanje podataka iz više
tabela odjednom.
Da bi se moglo npr. u jednoj formi prikazati podaci iz više tabela koje govore o istom predmetu
sva polja koja govore o istom predmetu moraju biti koordinirana. Ta koordinacija se postiže
pomoću relacija.
Relacija funkcioniše tako da spaja podatke iz ključnih polja (uobičajeno su to polja istog imena
u dve tabele). U većini slučajeva spojena polja su Primary key iz jedne tabele i foreign key iz
druge (foreign key je jedno ili više polja iz Tabele B na koje pokazuje Primary key polje ili
ostala polja iz Tabele A, podaci u foreign key-u moraju biti isti kao i u Primary key-u iako
njihova imena ne moraju biti ista)
U relacije se mogu stavljati samo podaci koji su posebni za određenu temu (to su
uglavnom AutoNumber polja koja su definisana kao Primary key). Polja koja se stavljaju u
relacije iz Tabele A moraju biti Primary key ili Indexi.
Relacija ima sledeća svojstva:
 Svaka relacija ima ime koje se razlikuje od imena svih ostalih relacija u šemi relacione
baze podataka.
 Svaka ćelija tabele (određena vrstom i kolonom) kojom je relacija predstavljena sadrži
samo jednu atomičnu (prostu) vrednost.
 Svi atributi jedne relacije imaju različito ime.
 Sve vrednosti jednog atributa su iz istog domena.
 Sve torke relacije su različite, tj. u relaciji ne postoje duple torke.
 Redosled atributa u relaciji nema značaja, i
 Redosled torki u relaciji teoretski nema značaja, ali praktično redosled torki u relaciji
može uticati na efikasnost pristupa torkama.

3.1.1. Vrste relacija

Kada jedan (one) KUPAC naruči robu, sigurno naručuje više (many) proizvoda. Ova relacija
se naziva one-to-many. Grafički se ova relacija prikazuje kao na slici 3.1.

14
 Slika 3.1. - “One to many” relacija5

Jedan (one) KUPAC može da ima više (many) NARUDžBI. Na gornjem primeru oznaka '1' na
liniji koja simbolizuje relaciju između dve tabele znači 'one', a oznaka '∞' znači 'many'.
Najprostija relacija između tabela je one-to-one. To znači da jedan rekord u jednoj tabeli
odgovara samo jednom rekordu u drugoj tabeli. Grafički se ova relacija prikazuje kao na slici
3.2.

Slika 3.2. - “One to one” relacija6

MS Access ne dozvoljava da relacija bude many-to-many. Takve relacije zahtevaju da se kreira

nova tabela. Primer za ovo je da jedan PROIZVOD može da se nalazi u više NARUDžBI, kao i
da jedna NARUDžBA može da sadrži više PROIZVODA (relacija many-to-many). Zbog toga je
potrebno da se kreira još jedna tabela STAVKANARUDžBE i da se time jedna relacija many-to-
many zameni sa dve relacije one-to-many,slika 3.3.

Slika 3.3 - “Many to many” relacija.7

3.1.2. Kreiranje relacija između tabela

Na kartici Alati (Tools), treba odabrati opciju Relation ships. Za prikaz tabela koje treba da
se povežu potrebno je kliknuti na alat na kartici Dizajn (Design), u grupi Alati (Tools).

5
Izvor:http://documentslide.com
6
Izvor:http://documentslide.com
7
Izvor:http://documentslide.com

15
Otvara se dijalog okvir Dodaj tablice (Add Tables) (slika 3.4) u kojem treba označiti i klikom na
dugme Dodaj (Add) dodati tabele koje se prikazuju u prozoru Relation ships.

Slika 3.4 - Dijaloški okvir Dodaj tablice (Add Tables)8

Relacija se može kreirati i metodom „uhvati-povuci–pusti“ (drag and drop,slika 3.5) tako da se:
 pozicionirati se na polje ID koje je primarni ključ tabele Kupci;
 pritisnuti levi taster miša, držati je i odvući do polja Kupac ID u tabeli Košarica na kojem
treba otpustiti taster;
 otvara se dijalog okvir Relations (slika 3.6);
 pritiskom na dugme Kreiraj (Create) kreira se relacija.

Slika 3.5 - Kreiranje veze između tablica Kupac i Dostava9

8
Izvor:http://www.itdesk.info/
9
Izvor: http://www.itdesk.info/

16
 Slika 3.6 - Dijalog okvir Odnosi (Relations)10

3.1.3. Brisanje relacija između tabela

Potrebno je označiti relaciju i:

 pritisnuti desni taster miša i iz brzog menija odabrati naredbu Izbriši (Delete), ili
 pritisnuti taster Delete na tastaturi.

3.2. Entitet

Entiteti su osnovni elementi o kojima se prikupljaju informacije i za koje se mogu odrediti

neke karakteristike, oni su objekti baze podataka, koji dele iste karakteristike. Primeri entiteta su
osoba, mesto, stvar, događaj ili bilo šta drugo što se može opisati nekim podacima; bilo šta za šta
ima smisla napraviti tabelu u kojoj bi svaki red predstavljao jednu karakteristiku tog entiteta, kao
što bi u tabeli osoba svaki red predstavljao jednu osobu.
Entiteti fizički predstavljaju tabele u bazi podataka. Svaki entitet je opisan atributima, npr. entitet
auto je opisan atributima: marka, naziv, motor, vrsta.... Ukoliko neki od atributa, sam za sebe
zahteva opis atributima, potrebno ga je definisati kao novi entitet. Isto važi i ako atribut može
istovremeno imati više vrednosti. Atributi fizički predstavljaju kolone u tabelama u bazi
podataka. 

3.3. Atribut
10
Izvor:http://www.itdesk.info/

17
 O entitetima se skupljaju informacije u vidu različitih karakteristika, kao na primer godište i
pol za osobe. U semantičkom modeliranju, takve karakteristike se nazivaju atributi, i oni služe za
detaljan opis entiteta. Ako su entiteti tabele, tada su atributi kolone u tabelama i njihova vrednost
opisuje karakteristiku entiteta.
Postoje dve vrste atributa: identifikatori i deskriptori.
Identifikator se koristi kako bi se karakteristika entiteta jedinstveno identifikovala, pa se još
naziva i ključnim atributom. Deskriptori se koriste kako bi se odredila vrednost atributa koji
mogu biti zajednički većem broju karakteristika entiteta, pa se još nazivaju i neključnim
atributima. Primeri ključnih atributa su OIB i šifra, dok su primeri neključnih atributa ime,
prezime, godište i pol. Atributi mogu biti jednostavni, što znači da se ne mogu podeliti na više
manjih atributa, poput atributa OIB, ili složeni, što znači da se mogu podeliti u više
jednostavnijih atributa, poput atributa datum rođenja, koji se može podeliti u dan, mesec i
godinu. Primer jednog složenog atributa je dat na slici 3.7.

Slika 3.7 - Primer složenog atributa11

Vršenje ovakve podele može biti korisno zbog statističke analize, ali je u nekim slučajevima
nepotrebno. Bitno je znati da se odredi šta su atributi kog entiteta. Kao primer može poslužiti
broj stanovnika u državi, što se zaista može staviti kao jedan od mnogih atributa entitetu osoba,
ali je zgodnije ako se entitetu osoba dodeli samo atribut država, dok atribut broj stanovnika u
državi se dodeli entitetu država. Atributi koji imaju višeznačne vrednosti treba da se klasifikuju
kao entiteti, tj. ako više od jedne vrednosti neključnog atributa odgovara jednoj vrednosti
ključnog atributa, neključni atribut treba da se odredi kao entitet, iako tada takav entitet možda
neće imati dodatnih neključnih atributa. Kao primer mogu da se uzmu filmovi i njima
pripadajući žanrovi; jednom filmu pripada više žanrova, ali tada se ne popisuju svi žanrovi
unutar jednog atributa, već se izrađuje novi entitet za žanrove, pa se povezuju entitet film i entitet
žanr.
Neki se atributi mogu izvesti pomoću drugih atributa, poput starosti, koja se može izvesti iz
datuma rođenja i trenutnog datuma. Takvi atributi nazivaju se izvedenim atributima i nisu nužno
uključeni u isti entitet kao atributi iz kojih su izvedeni.

11
Izvor: http://www.vps.ns.ac.rs

18
 Skup dozvoljenih vrednosti svakog atributa se naziva domen atributa (Di). Jedan domen
može da definiše više atributa ali obrnuto ne važi, jedan atribut ne može imati više domena. Null
vrednosti pripadaju svakom domenu, ali null vrednosti nisu poželjne. Kada su zadati atributi
onda su zadati i njihovi domeni.

Primeri atributa i domena:

 Atribut: Visina (cm)
D1: skup celih pozitivnih brojeva
 Atribut: NazivKnjige
D2: skup svih različitih naslova knjiga
 Atribut: Boja
D3: {“žut”,”crven”,”zelen”,”plav”}.

Pri projektovanju baze podataka, treba pažljivo birati atribute, u skladu sa potrebama.
Primer:
STUDENT (BrInd, Ime, Prezime, DatRođenja, Adresa, Telefon,...)
 DatumRođenja – sa namerom posedovanja podatka o starosti svakog studenta – dobar
izbor atributa (informacija se može izračunati),
 GodineStarosti – loš izbor atributa – zahtevalo bi se svakodnevno ažuriranje baze
podataka.
Atributi moraju da poseduju unikatnost,tj. nazivi atributa moraju da budu različiti. Atributi ne
mogu da uzimaju bilo koje vrednosti.

3.4. Ključ

3.4.1. Primarni ključ

U dizajnu relacionih baza podataka, jedinstveni ključ ili primarni ključ je kandidat za ključ
koji jedinstveno identifikuje svaku vrstu u tabeli. Jedinstveni ili primarni ključ može se sastojati
od jedne ili više kolona. Dve različite vrste u tabeli ne mogu imati istu vrednost u tim kolonama.
U zavisnosti od dizajna, tabela može imati proizvoljan broj jedinstvenih ključeva, ali i samo
jedan primarni ključ.
Primarni ključ omogućuje da svi slogovi u jednoj tabeli budu povezani sa zapisima u drugoj
tabeli. Ako tabela nije uređena na neki drugi način, primarni ključ određuje njeno uređenje.
Primarni ključ od više polja koristi se kada vrednost u polju koje bi trebalo da bude primarni
ključ nije jedinstvena. Prilikom povezivanja tabela najčešće se koristi zavisnost jedan prema više
(one to many). Ova zavisnost se koristi kada jednom slogu prve (primarne) tabele odgovara više
slogova u drugoj (sekundarnoj) tabeli. Kod ovakve zavisnosti primarna tabela mora imati
primarni ključ jedinstvene vrednosti.

19
Jedinstveni ključ mora da jedinstveno identifikuje sve moguće vrste koje mogu da se jave u
tabeli, a ne samo trenutno postojeće. Primeri jedinstvenih ključeva su JMBG (koji identifikuje
osobu) ili ISBN (koji identifikuje knjigu). Ime i prezime ne predstavljaju jedinstveni ključ osobe
jer ne identifikuju osobu jedinstveno. Na slici 3.8. primarni ključ je polje ID kojem je kao tip
podatka dodeljen AutoNumber– što znači da prilikom unosa sistem sam generiše novi
jedinstveni ID (broj) za svaki novi zapis.

Slika 3.8 - Polje ID – primarni ključ tablice Kupci12

Primarni ključ je specijalni slučaj jedinstvenog ključa. Glavna razlika je što kod jedinstvenih
ključeva implicitno NOT NULL ograničenje nije automatski osigurano dok kod primarnih
ključeva jeste. Stoga vrednosti u kolonama jedinstvenog ključa mogu imati vrednost NULL. Još
jedna razlika je u tome da se primarni ključ definiše posebnom sintaksom.
Relacioni model, izražen relacionom algebrom i relacijskim računom ne pravi razliku između
primarnih ključeva i ostalih tipova ključeva. Primarni ključevi su dodati u standard SQL
prvenstveno da bi olakšali posao programerima.
Na jedinstvene ključeve kao i na primarne ključeve mogu da referenciraju strani ključevi.

3.4.2. Strani ključ

Strani ključ je polje u sekundarnoj tabeli sa kojim se vrši povezivanje i ne mora imati
jedinstvenu vrednost. U kontekstu relacionih baza podataka, strani ključ je referencijalno
ograničenje između dve tabele. Strani ključ identifikuje kolonu ili skup kolona u jednoj
(referencirajućoj) tabeli, koja referiše na kolonu ili skup kolona u drugoj (referenciranoj) tabeli.
Kolone u referencirajućoj tabeli moraju biti primarni ključ ili kandidat za ključ u referenciranoj
tabeli. Vrednosti referencirajućih kolona iz jednog reda moraju da se pojavljuju u tačno jednom
redu referencirane tabele.

12
Izvor: http://www.itdesk.info/

20
Stoga, red u referencirajućoj tabeli ne sme da sadrži vrednosti koje ne postoje u referenciranoj
tabeli (izuzev možda vrednosti NULL). Na ovaj način reference mogu da povezuju podatke iz
različitih tabela. Strani ključ predstavlja suštinski deo normalizacije baza podataka. Više redova
u referencirajućoj tabeli može da pokazuje na isti red u referenciranoj tabeli.
Referencirajuća i referencirana tabela mogu da budu ista tabela, to jest strani ključ može da
pokazuje na istu tabelu. Takav strani ključ je u SQL:2003 poznat kao samoreferencirajući ili
rekurzivni strani ključ.
Jedna tabela može da ima više stranih ključeva, i svaki strani ključ može da pokazuje na različitu
tabelu. O integritetu svakog stranog ključa se sistem baze podataka stara pojedinačno.
Neispravni odnosi strani ključ/primarni ključ ili neforsiranje sprovođenja tih odnosa često
predstavljaju uzrok mnogih problema pri modeliranju podataka.

3.5. Polje

Može se uopšteno reći da je podatak sve ono što opisuje odnosno aktuelizuje neku činjenicu,
događaj i njegove karakteristike. To znači da je podatak logičko-semantička jedinica koja još
uvek nije informacija, a koja se u smislu digitalne strukture u kompjuterskoj organizaciji
memorije naziva polje. Svako polje se identifikuje sa imenom (nazivom), obimom i vrstom.
Naziv i obim polja određuje sam korisnik , dok vrsta polja proizilazi iz samih karaktera znakova
koji ga čine.

3.5.1. Podešavanje tipa i parametara polja

Tekstualni tip polja (Text) - Sadrži do 255 karaktera teksta, ili onoliko koliko je zadato u polju
Field Lenght.
Tekstualni tip polja (Memo) - Sadrži do 65535 karaktera teksta.
Numerički tip polja (Numeric) - Sadrži broj, čiji opseg vrednosti zavisi od vrednosti koja je
zadata u polju Field Lenght:

Date/Time tip polja - Sadrži datum i vreme. Opseg vrednosti može da bude od 100. do 9999
godine.

21
Currency tip polja - Sadrži numeričku vrednost. Opseg vrednosti sadrži negativne i pozitivne
brojeve. Broj cifara sa leve strane decimalne tačke može da bude 15, a sa desne 4. U memoriji
zauzima 8 bajtova. Prilikom prikazivanja vrednosti, simbol za valutu je onaj koji je podešen u
Control Panel-u (sistemski parametar MS Windows-a). Verzija MS Accesss 2000 (i više verzije)
ima mogućnost da se podesi tip polja da bude Euro.
AutoNumber tip polja - AutoNumber je broj (Long Integer) koji se generiše automatski.
Postoje dva načina generisanja:
 Inkrementiranjem (najveća vrednost + 1)
 Generisanjem slučajnih brojeva
MS Access obezbeđuje da se vrednosti u polju koje je tipa AutoNumber budu jedinstveni.
Logički tip polja (Yes/No) - Ovaj tip polja može da sadrži samo dve vrednosti Yes ili No
(True/False, On/Off). U memoriji zauzima 1 bajt.
OLE object polje - Sadrži bilo koji dokument (MS Word, MS Excel, zvuk, grafika, video
snimak, ili neki drugi objekat). Polje ovog tipa sadrži putanju fajla u kojem se nalazi dokument
(Linked) ili sam dokument (Embeded).
Hyperlink polje - Polje ovog tipa sadrži Hyperlink adresu.
Lookup Wizard polje - Ako se izabere tip polja Lookup Wizard, MS Access će startovati
Wizard koji omogućava da se napravi relacija sa nekom drugom tabelom ili upitom (Query).
Kada se završi procedura koju zahteva Wizard, tip polja će biti promenjen u isti tip kao što ima
polje u tabeli sa kojim je napravljena relacija.

Parametri polja
U zavisnosti od izbora tipa podatka u donjem panelu Design View prozora prikazuje se
dodatna lista svojstava svrstanih u dve grupe (kartice): General i Lookup.
General kartica sadrži listu opštih svojstava polja. Broj i vrsta parametara polja zavise od tipa
podatka koji selektovano polje sadrži. Na primer, tip polja 'Text' ima jedne parametre, a tip
'Number' druge. Na sledećoj slici 3,9. su prikazani parametri za tip polja 'Text'.

Slika 3.9 - Parametri za tip polja Text13.

13
Izvor:http://documentslide.com

22
Ako se klikne levim tasterom miša na desnu ivicu polja koje sadrži vrednost parametra, desiće se
jedna od tri varijante:
1. Pojaviće se ikona , koja označava da postoji lista sa koje može da se izabere vrednost
parametra, slika 3.10.

Slika 3.10 - Parametri polja Text14.

2. Pojaviće se ikona , koja startuje Expression Builder koji može da se iskoristi za unos
vrednosti parametara.
3. Neće se pojaviti ikona, parametri moraju da se ukucaju korišćenjem tastature.

Osnovni parametri polja

Field Size - sadrži dužinu tekstualnog polja. Podrazumevani tip i dužina se podešavaju opcijama
u MS Access-u. Najčešće je to 50 karaktera za tekst a Long Integer za brojeve. Ukoliko je tip
polja Numeric, može se izabrati jedna od nabrojanih vrednosti.
Format - definiše poseban izgled tekstualnog polja, dok je za brojeve predloženo nekoliko
standardnih tipova (General Number, Currency, Fixed, Standard, Percent, Scientific), kao i za
Date/Time (General, Long, Medium, Short). Ovi formati u velikoj meri zavise od podešavanja u
Regional Settings servisu Control Panel-a.
Input Mask - omogućava da se prilikom unosa podataka koristi maska koja olakšava unos
podataka. Za kreiranje maske može se koristiti Input Mask Wizard.
Caption - tekst koji se prikazuje, umesto naziva polja, na formama, izveštajima, itd. Ukoliko se
ovde ne unese ništa, uzima se već postavljeno ime polja u Field Name. Na primer, ako se polje
zove 'ID', a Caption je 'Identifikacioni broj', onda će na datasheet-u tabele biti naziv polja
'Identifikacioni broj', a ne 'ID'.
Default Value - određuje vrednost koju polje dobija automatski prilikom kreiranja novog
rekorda. Korisnik kasnije može da promeni vrednost polja.

14
Izvor:http://documentslide.com

23
Validation Rule - sadrži pravila i ograničenja koja moraju da se poštuju prilikom unosa podataka.
Na primer, ako se unosi količina artikala koji su primljeni u magacin, logično je da vrednosti
moraju da budu veće od nule.
Validation Text - sadrži poruku koja će se prikazati korisniku prilikom unosa podataka ako naruši
pravila definisana u polju Validation Rule. Na primer: "Broj artikala mora biti veći od nule!'.
Required - ovo polje obavezno mora da sadrži vrednost. Nije moguće kreiranje novog rekorda
ako je ovo polje prazno.
Allow Zero Length - primenljivo za Text i Memo polja. Omogućava da sadržaj polja bude Space
karakter(i).
Indexed - svojstvo kojim se uključuje indeksiranje na određeno polje u cilju izbegavanja
dupliranja podataka i bržeg pretraživanja ili sortiranja po zadatom polju. Efekat indeksiranja se
može sagledati tek kod rada sa velikim tabelama (par hiljada slogova) i baza podataka sa više
ovakvih tabela, a ponuđene su tri opcije:
No - polje nije indeksirano,
Yes-Duplicates OK - polje je indeksirano, a duplikati vrednosti su dozvoljeni ili
Yes-No Duplicates - polje indeksirano, ali duplikati nisu dozvoljeni.
Kod polja koje predstavlja primarni ključ mora biti odabrano Yes-No Duplicates.
Unicode Compression - omogućava da polja koja su tipa Text, Memo i Hyperlink zauzimaju
manje memorijskog prostora. Ovo svojstvo je omogućeno iz razloga što Unicode Text zauzima
dvostruko veći memorijski prostor (1 znak zauzima 16 a ne 8 bita kao ASCII Text).
Lookup kartica sadrži svojstva u slučaju da se podatak u tekućem polju bira iz liste vrednosti.

3.6. Slog

Slog ili zapis čini više segmenata ili polja koji su zajedno dostupni za obradu u računarskom
sistemu. Sadržaj sloga se odnosi na jedan pojam, pojavu ili događaj. Strukturu sloga određuju:
broj, vrsta i dužina polja. Slogovi se grupišu u datoteke i zapisuju na medijumu za čuvanje
podataka. Datoteka sadrži, po nekom kriterijumu, srodne podatke. Obim datoteke je određen
brojem slogova.Veličina datoteke je određena obimom datoteke i dužinom slogova. Datoteka
može biti sastavljena i od različitih slogova. Razlika može biti u strukturi i broju polja.
Slog može biti :
-Matični slog se sastoji od fiksnih i relativno – fiksnih polja (stavki) tj.od nepromenjenih i retko
promenljivih stavki. Kada su broj i veličina stavki podataka u nekom slogu konstantni za sve
slogove (npr. za sve radnike, sve kupce, artikle i sl.) slog se tada naziva slog sa fiksnom težinom.
Njihova prednost je što su uvek iste veličine ,a sistem ne mora da vodi računa o tome koliko je
slog dug i gde on završava, a drugi počinje. Tako se uštedi na vremenu obrade.
- Slogovi sa varijabilnom dužinom su manje uobičajeni. Dužina slogova im varira zato što
variraju pojedinačne stavke podataka u svojoj dužini ili zato što se broj stavki podataka u nekom
slogu menja od slučaja do slučaja.

24
Identifikacija nekog sloga u memoriji vrši se u momentu upotrebe u toku obrade pomoću ključa
sloga. Ključ sloga vrši, dakle, identifikaciju sloga, razlikovanje jednog sloga od drugog u
memoriji sistema.
Slogovi iste vrste imaju isti broj polja koja se ne mogu razlikovati po strukturi, već samo po
sadržaju.
   Fizički slog ili blok je grupa slogova čiji se sadržaj prenosi sa periferijskog uređaja u
operativnu memoriju računara ili obratno pri jednom obraćanju centralnog procesora
periferijskom uređaju. Fizički slog je osnovna jedinica podataka koja se čita ili zapisuje jednom
ulazno-izlaznom operacijom računara. Jedan fizički slog može imati jedan ili više logičkih
slogova. Koeficijent grupisanja određuje broj logičkih slogova u jednom fizičkom slogu. Tri
logička sloga čine jedan fizički slog ili blok. Između fizičkih slogova postoji prazan prostor.
Kontrolni podaci fizičkog sloga zavise od operativnog sistema i svojstva medijuma.
Grupisanjem logičkih slogova u fizičke povećava se brzina izvršavanja programa i štedi se
memorijski prostor. U praksi koeficijent grupisanja je između 30 i 50.
Koeficijent iskorišćenja memorije  definiše se kao odnos logičkog i fizičkog sloga. Veći je ako
je veći koeficijent grupisanja.

25
 4. ZAKLjUČAK

Važnost baza podataka nalazi se u tome što uveliko olakšavaju organizovanje podataka
potrebnih za svakodnevno poslovanje. Baze podataka omogućuju preglednost i dostupnost
podataka koji se nalaze na jednom mestu što poslovanje čini jednostavnijim i kvalitetnijim.
Koristeći MS Access u poslovanju, preduzeća mogu u svakom trenutku imati uvid u podatke
vezane za obavljanje svakodnevnih zadataka organizujući ih i ostavljajući ih dostupnima, te su ih
preduzeća u stanju vrlo lako ispraviti ili nadopuniti. Velika prednost je i jednostavnost kreiranja
novih izveštaja, obrazaca, upita i slično. Preduzeća koja koriste MS Access u poslovanju imaju
određenu prednost, a kako je vreme novac, MS Access može poslovanje samo učiniti lakšim i
profitabilnijim što je i cilj svakog preduzeća.
Sistemi upravljanja bazom podataka obično se kategorišu prema modelu podataka koji
podržavaju : odnosni, orijentisani prema objektu, mrežni itd. Veliki deo internog inženjerstva
SUBP-a, ipak je nezavistan od modela podataka, te je zaokupljen upravljanjem faktorima poput
performansi, podudarnosti, integrititeta i obnove nakon hardverskih popusta . U ovim područjima
postoje velike razlike među proizvodima.
Naziv „baza podataka „ se strogo odnosi na zbirku zapisa , a na softver bi se trebalo odnositi kao
na sistem upravljanja bazom podataka ili SUBP. Mnogi administratori ipak koriste termin „ baza
podataka da pokriju oba značenja.
Mnogi profesionalci će smatrati da zbirka podataka stvara bazu podataka jedino ako ima
određena svojstva: na primer, ako se podacima upravlja kako bi osigurali svoj integritet i
kvalitet, ako omogućava zajednički pristup nekoj zajednici korisnika, ako ima šemu, ili ako
podržava upitni jezik. Ipak dogovorena definicija ovih svojstava ne postoji.

26
 LITERATURA:

[1]. Turban,E., McLean,E. Wetherbe,J. John Wiley & Sons, Inc.2002: „INFORMATION
TECHNOLOGY FOR MANAGEMENT“, 3rd edition, („Informaciona tehnologija za
menadžment“), Zavod za udžbenike i nastavna sredstva , 2003. Beograd
[2]. Stankić, R., Krsmanović, B:„Elektronsko poslovanje“, Fakultet spoljne trgovine.

Materijal sa interneta:

internet,Access 2007 Biblija John Walkenbach

www.znanje.org-Baze podataka_-_Kompletan prirucnik.
http://jadran.izor.hr
http://www.itdesk.info/
http://www.vps.ns.ac.rs
http://documentslide.com

27