@ViPserbia

@ViPserbia production

BAZE PODATAKA

-KNJIGA-
@ViPserbia

Sadrţaj
1. Uvod 5
1.1. Pojam baze 9
1.2. Istorijat baza 10
1.3. Neke od većih baza podataka 10
1.4. Neke od manjih baza podataka 11
2. Modeli – strukture podataka 14
2.1. Osnovne strukture podataka 14
2.2. Dodatna definisanja nad podacima 24
2.3. Definisanje baze 29
3. Relacione baze podataka 32
3.1. Programsko okruženje za upravljanje podacima 41
3.2. Projektovanje aplikativnih rešenja primenom relacionih baza 44
3.3. Projektovanje baze podataka 45
3.4. Projektovanje relacione baza podataka 46
3.5. Izrada dijagrama procesa 49
3.6. Izrada dijagrama funkcija 50
3.7. Izrada dijagrama toka podataka 52
3.8. Izrada matričnih dijagrama 53
3.9. Izrada dijagrama entiteta i relacija 54
4. Elementi relacione baze podataka 58
4.1. Tabele – Tables 60
4.2. Formulari – Forms 61
4.3. Upiti – Queries 63
4.4. Izveštaji – Reports 64
4.5. Spajanje relacija – spajanje tabela 65
4. 6. Ažuriranje – unos, ispravka, dodavanje 67
4. 7. Indeksi 68
4. 8. Ključevi 69
4. 9. Pretraživanja, sortiranja, selekcija 70
4.10. Makroi i primena VBA 70
5. Primena Microsoft Accessa u razvoju baze podataka 72
5.1. Uvodne informacije - uputstva 74
5.2. Primer razvoja aplikacije (poslovna praksa) 75
5.3. Pokretanje rada MS Accessa 76
5.4. Izrada tabela 76

2
@ViPserbia

5.4.1. Izrada tabela primenom »Design View« 83

5.4.2. Pregledanje i dodavanje podataka u tabelu 88
5.4.3. Izrada relacija izmeĎu tabela 91
5.5 Izrada i izvoĎenje upita 97
5.5.1. Upiti nad jednom tabelom 97
5.5.2. Upiti nad više tabela 105
5.6. Izrada forme za obuhvat podataka 110
5.6.1. Izrada forme nad jednom tabelom 110
5.7. Izrada i realizacija izveštaja 116
5.7.1. Izrada izveštaja nad jednom tabelom 116
5.8. Microsoft Access 2000 – dodatne mogućnosti 125
5.8.1. Switch board manager 125
5.8.2. Look Up – Combo box 141
5.8.3. Upotreba alata Expression builder 146
5.9. Upotreba Makroa 151
5.10. Primena VBA – Visual Basic for Applications 164
5.11. Pravljenje poštanskih nalepnica 152
5.12. Specifikacije za baze podataka u Microsoft Accessu 168
6. Rukovanje bazama podataka 171
7. Distribuirane baze podataka. 173
8. Rad u mreţi 177
9. Bezbednost baze 185
10. Zaštita integriteta baze 189
11. Nadzor nad radom baze 196
12. Kuda dalje 197
13. Prilog 1 – Primer Informacionog sistema biblioteke F@M-a 198
14. Prilog 2 – Primer baze podataka za Osnovnu školu Jovan Popović 212
15. Posebni izrazi koji se često koriste u bazama podataka 221
16. Literatura 225

3
@ViPserbia

Baze podataka

1. Uvod

Savremeni informacioni sistemi se sve češće pored opreme, mreţnih resursa i

ljudskog potencijala baziraju i na skupovima informacija, koji se najčešće nazivaju
bazom podataka i skupovima programskih modula koji omogućavaju pristup tim
podacima.
Ovi skupovi programskih modula se najčešće nazivaju sistemi za upravljanje
bazom podataka ili skraćeno SUBP.
Pri tome je osnovna namena SUBP da omogući svim korisnicima jednostavan i
efikasan pristup podacima, što je veoma sloţen zadatak, koji često zahteva veoma
kompleksan softverski sistem, te ne treba da čudi što je oblast baza podataka i
informacionih sistema poslednjih godina doţivela buran razvoj, kako u teorijskom,
tako i u praktičnom smislu.
Ako se pogleda dosadašnji razvoj sistema za upravljanje bazama podataka
(SUBP) slobodno se moţe reći da je tekao spiralnim tokom.
Svaki novi ciklus je počinjao naučno istraţivačkim radom koji se obično
konkretizovao u odreĎene metodologije. Nakon toga je sledila faza realizacije
SUBP-a i njegova eksploatacija. Faza eksploatacije je otkrivala i negativne
karakteristike koncepta i načina njegove realizacije što je opet uslovljavalo pojavu
sledećeg ciklusa u razvoju SUBP-a.
Informacioni sistem predstavlja model realnog sistema, a proces prevoĎenja
pojedinih koncepata realnog sistema u koncepte modela podataka naziva se
projektovanje.
Zbog toga je veoma bitno da je model podataka dovoljno semantički bogat da
bi mogao, na relativno lak način prihvatiti, ali isto tako i u sebe uključiti različite
koncepte realnog sistema.
Svaki model podataka se sastoji od objekata, operatora nad tim objektima i
ograničenja.
Osnovna karakteristika svakog SUBP-a je model podataka na kome se on
bazira.
Kada se analizira odreĎeni SUBP analizira se, u stvari, model podataka i način
njegove implementacije. Korišćenje odreĎenog modela podataka se susreće u fazi
dizajna i u fazi implementacije SUBP-a .
U fazi dizajna se koristi model podataka kao sredstvo za definisanje modela
informacionog sistema, koji se u fazi implementacije realizuje u modelu podataka
ugraĎenom u SUBP.

5
@ViPserbia

Veoma je vaţno pitanje da li su to dva različita tipa modela podataka ili ne.
Ukoliko se radi o istom tipu modela podataka tada se postavlja pitanje da li je on
dovoljno semantički bogat da bi se mogao koristiti u fazi dizajna i da li je u isto vreme
jednostavan da bi se, u fazi implementacije, mogao lako realizovati.
Ukoliko se u navedenim fazama radi sa različitim tipovima modela podataka
tada postoji problem njihovih semantičkih razlika i načina prevoĎenja jednog modela
u drugi. Ukoliko je semantička razlika značajna nije moguće izvršiti prevoĎenje
semantički bogatijeg u semantički siromašniji model.
Očigledno je da se korišćenje različitih modela podataka u različitim fazama
razvoja softvera svodi na efekte i mogućnosti onog koji je siromašniji.
Moderna obrada podataka se zasniva na dva osnovna koncepta:
a) Na konceptu baze podataka kao jedinstvenog skladišta svih informacija
potrebnih za opis jednog realnog sistema, iz koga onda svaki korisnik moţe da izvuče
one informacije koje su mu potrebne,
b) Na konceptu sistema za upravljanje bazom kao sloţenog softverskog proizvoda,
čiji je cilj da korisniku omogući lako i brzo rukovanje potrebnim podacima, ne
opterećujući ga pritom detaljima fizičke organizacije, zaštite, obezbeĎenja
konkurentnosti i drugim sloţenim administrativnim poslovima.
Najveći broj komercijalnih SUBP je zasnovan na hijerarhijskom, mreţnom,
relacionom ili objektno orijentisanom modelu podataka.
Prvi sistemi za upravljanje bazama podataka bili su hijerarhijskog tipa (sistem
IMS – information management system, firme IBM), mada u to vreme njihovi
projektanti nisu toga bili ni svesni. Pojam modela podataka, pa samim tim i
hijerarhijskog modela, uveden je tek kasnije.
Mreţni model se pojavio nešto kasnije u odnosu na hijerarhijski, dok je relacioni
model nešto noviji u odnosu na njih - prvi ga je predloţio Codd 1970. godine.
Poslednjih godina se počeo veoma intenzivno počeo primenjivati objektno orijentisani
model.
Prvi komercijalni relacioni SUBP pojavio se krajem sedamdesetih godina i od tada
praktično kompletan razvoj SUBP i najveći broj novih realizacija koristi relacioni
model podataka. Prvi eksperimentalni sistemi koji su koristili relacioni model
konstruisani su u firmi IBM.
Na trţištu je 80 –tih i 90- tih godina postojalo preko stotinu raznih relacionih
SUBP. Vcćina njih su koristili strukturni upitni jezik SQL - Structured Query
Language ili neku njegovu varijantu.
U tom periodu veoma značajnu ulogu u svetu baza podataka je imao Rdb/VMS
proizvod američke firme Digital Equipment Corporation, namenjen računarima tipa
VAX i mikroVAX pod operativnim sistemom VMS i predstavljao je sloţen, ali
veoma dobar sistem za upravljanje bazama podataka, koji je podrţavao sve osnovne
operacije relacionog modela.
6
@ViPserbia

Pošto se radilo o proizvodu iste firme, koja je proizvodila i hardver i sistemski

softver, bilo je realno očekivati dobre performanse. Uporedna merenja su pokazivala
da je u to vreme Rdb/VMS bio najbrţa relaciona baza na VAX računarima.

Sistem Rdb/VMS se sastojao od više komponenata, meĎu kojima su bili

interpreteri RDO (Relational Database Operator) i VAX SQL, preprocesor za više
programske jezike RDBPRE (Fortran, Cobol, Ada, BASIC) i RDML-Record Data
Management Language (C i Pascal), odnosno SQLPRE (za upitni jezik SQL, i jezike-
domaćine Fortran, Cobol, Pascal, C, PL/I), te usluţni program RMU (Record
Management Utility), koji je olakšavao rad administratoru baze.
Naravno, postojao je i sam sistem za upravljanje bazom u uţem smislu, koji se u
literaturi na engleskom jeziku obično nazivao data base engine. Ovaj deo Rdb/VMS
sistema je u izvesnom smislu predstavljao produţetak operativnog sistema, jer je
sadrţavao osnovne rutine za rad sa datotekama, relacijama, indeksima.
U stvari, bilo kakav rad sa Rdb/VMS bazom, bilo interaktivno, bilo preko
prevedenih aplikacionih programa, bez njega je bio nemoguć. Kasnije verzije
operativnog sistema VMS su bile isporučivane zajedno sa ovim softverom, što je
predstavljalo deo Digitalovih napora da se probije na trţištu informacionih softvera.
Rdb/VMS je takoĎe zahtevao korišćenje Digitalovog integrisanog rečnika
podataka, poznatog pod komercijalnim nazivom CDD (Common Data Dictionary).
Korišćenje CDD rečnika je bilo neophodno pri definisanju strukture baze, a i
kasnije, ukoliko su se koristili drugi softverski paketi, meĎu kojima su od poznatijih
bili FMS-File Management System, TDMS- Transaction Data Management System,
kao i DECforms, svi oni su bili namenjeni generisanju i korišćenju ekranskih formi za
unošenje i/ili prikazivanje podataka, ACMS (Application Control and Management
System), pomoću koga su se definisale višekorisničke aplikacije i upravljalo njihovim
radom, kao i sistemi za upravljanje bazama podataka zasnovanim na drugačijim
modelima (kao što je bio, recimo, DMS - Database Management system – Digitalov
sistem za upravljanje bazom podataka u mreţi).
CDD je predstavljao osnovno spremište struktura podataka, rečnik u kojem su se
čuvale definicije svih zapisa za sve ove pakete, i komunikacioni mehanizam preko
koga je jedan softverski paket mogao da koristi podatke, čija struktura je bila
definisana u nekom drugom paketu.
Za Rdb/VMS upitni jezik (koji je Digital ponegde stidljivo označavao kao RDML,
Relational Data Manipulation Language, a veoma često i sa RDO) moţe se reći da je
bio relacioni, jer su se, praktično, sve naredbe za manipulisanje podacima mogle
izdavati bilo u interaktivnom dijalogu, bilo ugraĎene u program pisan u nekom višem
programskom jeziku treće generacije (jezik-domaćin), kakvi su bili COBOL,
FORTRAN i slično.
Tako napisani programi su se najpre obraĎivali preprocesorom za odgovarajući
jezik, a zatim standardnim prevodiocem.

7
@ViPserbia

Kako je upitni jezik SQL kasnije vremenom postao standard u oblasti relacionih
baza podataka, to je Digital razvio i SQL interfejs za Rdb/VMS baze. Ovaj se softver,
pod komercijalnim nazivom VAX SQL, isporučivao zajedno sa Rdb/VMS softverom,
te je kupac imao na raspolaganju oba interfejsa i, shodno tome, imao mogućnost da
bira.

8
@ViPserbia

Pojam baze podataka

Pod bazom podataka se podrazumeva organizovan skup podataka koji se odnosi

na slične pojmove ili predmete i skup programskih modula koji omogućavaju pristup
tim podacima. Kako je već rečeno ovi moduli se nazivaju sistem za upravljanje
bazom podataka, skraćeno SUBP.
Naime dok se organizacija podataka u datoteke naziva klasičnim načinom
organizovanja podataka, organizacija podataka u takozvanoj integrisanoj formi se
naziva baza podataka.
Podaci u bazi podataka mogu biti organizovani po više različitih obeleţja po
kojima je kasnije primenom odgovarajućih mehanizama baze moguće vršiti
pretraţivanja i nalaţenje baš onih podataka koji su potrebni.
Rad sa bazom podataka se ne sastoji samo od definisanja strukture baze i
pisanja upita za izveštavanje i aţuriranje, već postoje i neki poslovi koji se moraju
obavljati periodično ili po potrebi:
 potrebno je dodeljivati prava pristupa pojedinim korisnicima baze, vršiti pe-
riodično kontrolu dodeljenih prava, a po potrebi, ukidati jednom dodeljena
prava korisnicima koji više ne rade;
 u redovnim vremenskim intervalima treba proveravati integritet podataka u
bazi;
 periodično se moraju vršiti radnje potrebne za eventualan oporavak u slučaju
otkaza: arhiviranje baze na traku, rezervne diskove, CD/ove i aktiviranje
dnevnika uspešno završenih transakcija;
 povremeno se moraju ispitivati performanse baze i po potrebi vršiti
podešavanja fizičkih parametara, kako bi se vreme odziva smanjilo na najmanju
moguću vrednost.

Da bi se što efikasnije i uspešnije obavljali ovi i slični poslovi, baza mora da

poseduje veći broj funkcija za upravljanje i administriranje bazom podataka.
Upravo za izvršenje tih funkcija, po pravilu, je potrebna posebna osoba, obzirom
da se radi o osetIjivim poslovima, koje je potrebno dobro poznavati, a to je delom i
pitanje organizacije posla, a ne samo sistema za upravljanje bazom podataka.
Nadalje, veoma često je potrebno dobro razraditi koncept transakcije kao logičke
jedinice pristupa bazi, zaključavanjem i drugim mehanizmima, koji omogućavaju
korektan i efikasan višekorisnički rad.

9
@ViPserbia

Istorijat baza podataka

Baze podataka su se razvile kao logičan nastavak datoteka – file – podataka

koje su veoma dugo korišćene u računarstvu, a i dan danas se koriste kao osnovne
jedinice u koje se smeštaju podaci raznih tipova – tekstualni, tabele, slike i.t.d. Prve
datoteke podataka su bile sekvencijalne – podaci su smeštani u nizu jedan za drugim,
a i pretraţivanje podataka se odvijalo na isti način.
Naime u početnim godinama primene računara podaci su bili smeštani na
kartice – bušene kartice, a kasnije na magnetne kasete i magnetne trake. Kao što je
poznato i jedan i drugi medij su sekvencijalnog tipa i da bi se došlo do podatka, koji
se nalazio na drugom kraju - strani trake ili kasete, bilo je neophodno premotati celu
traku odnosno kasetu.
Kasnije je došlo do razvoja ureĎaja kao što su disketa – floppi disc i diskova –
hard disc, CD koji su omogućavali direktniji pristup podacima. U skladu sa tim novim
mogućnostima korišćene su tzv. indeks-sekvencijalne i indeksne datoteke kod kojih je
primenom indeksa i odgovarajućih ključeva bilo moguće daleko brţe pretraţivanje
datoteka i nalaţenje potrebnih podataka.

Neke od većih baza podataka

Oracle
Oracle je vodeći sistem za upravljanje bazama podataka, prenosiv, distributivan
i otvoren, poseduje izvanredne mogućnosti i ima veoma visoke performanse,
omogućava rad sa veoma velikim bazama podataka. On je u svetu najrasprostranjeniji
DBMS – data base management system – sistem za rukovanje bazama podataka jer na
najbolji način zadovoljava i zahteve današnjih najzahtevnijih informacionih sistema.
On u sebi sadrţi podršku za najkompleksnije DSS – decision support systems –
sisteme za podršku odlučivanju preko najrigoroznijih OLTP – on-line transaction
processing aplikacija čak do aplikacija koje zahtevaju simultane DSS i OLTP pristupe
do istih kritičnih podataka, pa do vodeće primene u industriji zahvaljujući dobrim
performansama i mogućnostima koje Oracle pruţa korisnicima.
Ono što je posebno vaţno kod primene Oracle-a je činjenica da on omogućava
da korisnik moţe da integriše sve svoje računarske sisteme bez obzira pod kojim
operativnim sistemom da rade UNIX, XENIX, VMS, OS-2, MVS, a pored toga
omogućava meĎuoperativnost sa manjim bazama ili sa sličnim aplikativnim alatima.
Pored toga veoma je značajna činjenica da Oracle ima razvijene brojne SQL -
alate i CASE- Computer Aided Software Engineering-softver inţinjering pomoću
računara – alate koji omogućavaju korisnicima da na što lakši način mogu da rade pod
Oracle-om.

10
@ViPserbia

Ingres
Ingres je jedna od vodećih RDBMS – Relational Data Base Management
Systems – sistema za upravljanje relacionim bazama podataka, koji je posebno
pokazao svoje izvanredne mogućnosti primene pod UNIX operativnim sistemom.
Ingres se koristi u mnogim oblastima. Pomenućemo samo neke kao što su trgovina,
bolnice, farmacija, industrija, telekomunikacije, proizvodnja, inţenjerstvo, nauka,
obrazovanje, seizmika itd. Ingres baze podataka se koriste na većini vaţnijih UNIX
platformi od single-user – pojedinačnih korisnika na PC – personal computer – ličnim
računarima do main frames – glavnih - centralnih računara u velikim računskim
centrima.
Od 1980. godine, kada je osnovana kompanija, Ingres je prilagoĎen i podešen
za rad pod UNIX operativnim sistemom tako da je Ingres multi server arhitektura
izuzetno dobra za rad u modelu client-server – klijent server, koji je prihvaćen kao
standard u današnjem komercijalnom okruţenju. Ingres se takoĎe veoma lepo i
uspešno primenjuje kod VAX – VMS sistema, u klijent server arhitekturi, bez obzira
da li lokalno ili preko mreţe.

Informix
Informix – Informiks je takoĎe jedna od vodećih i u svetu često primenjivanih
baza podataka. Ovo je baza koja ima otvorenu arhitekturu koja kombinuje efikasnu
strukturu za transfer podataka, koristi snagu SQL-a – Structured Query Language –
jezik za strukturno programiranje - za manipulaciju podacima, za definisanje podataka
kao i za kontrolu podataka, a za povećanje brzine uzimanja podataka koristi
pogodnosti C-ISAM –a- Indexed Sequential Access Method for the C language –
indeks-sekvencijalni metod pristupa uz primenu C jezika.
Programiranje sa Informiksovim 4GL – Fourth Generation Programming
Language, programski jezik četvrte generacije je mnogo brţe i jednostavnije nego sa
drugim programskim jezicima.
To je neproceduralan jezik koji omogućava korisniku da veoma lako moţe da
kreira i najkompleksnije aplikacije. Pored toga i Informiks poseduje brojne pomoćne
alate koji korisniku olakšavaju pretraţivanja kao i druge manipulacije sa podacima
smeštenim u bazu. Nadalje Informiks nudi i svoje integrisano rešenje koje omogućava
korisniku da brzo razvije ţeljeni sistem

Neke od manjih baza podataka

dBase
Data Base ili skraćeno dBASE je verovatno najrasprostranjenija baza podataka
koja se u svojim različitim varijantama od dBASE, pa preko dBASE II, dBASE III pa

11
@ViPserbia

zatim Clippera gotovo ušetala u većinu ličnih računara koje su korisnici širom sveta
koristili u prvim fazama primene PC računara i baza podataka na njima, čak i u
varijantama kada su PC računari povezivani u raznovrsne mreţe. Postepeno je
izgubila dah u konkurenciji sa novodolazećim bazama i mogućnostima koje su one
nudile.
Ipak one će ostati u sećanju kao alati koje su mnogi korisnici koristili u raznim
fazama svoga rada sa bazama podataka i preko kojih su upoznali osnovne principe i
pravila u radu sa bazama.

Visual Fox pro

Fox pro baza je nastala razvojem Fox base, da bi danas prerasla u bazu koja se
kao standard koristi u Visual studio okruţenju kao Visual Fox pro baza podataka.
Ova baza podataka je pored dBASE verovatno baza podataka koja je godinama
bila najprisutnija u PC okruţenju, a koja je i danas u svojoj Visual Fox pro varijanti
najprisutnija baza podataka u PC računarima koju korisnici PC računara širom sveta
koriste za svoje potrebe.
Ova baza je na veoma pogodan način prilagoĎena Windows okruţenju i kao
takva je uspela da prevaziĎe mnoge konkurentske baze tog nivoa. Visual Fox pro
danas poseduje mnoge elemente koji omogućavaju korisniku da na brz i efikasan
način moţe načiniti ţeljenu bazu i prateće ulazno-izlazne ekrane i izveštaje i da je za
veoma kratko vreme uvede u neposrednu primenu.

ZIM
Jedna od baza podataka koja je u periodu 1990-tih godina bila veoma
rasprostranjena na našim prostorima pa i u celom svetu bila je ZIM baza podataka.
Ova baza je zbog svojih veoma malih zahteva u pogledu hardverskih resursa recimo u
odnosu na Oracle, kao i zbog svoje veoma dobre transportabilnosti sa manjih na veće
računarske sisteme bila veoma dobro prihvaćena od strane brojnih korisnika.
Obzirom da je to ipak bila 4GL baza podataka, ona je bila sa svim
pogodnostima koje nude takve baze, a imala je i sopstveni ER modeler – Entity
Relationship data modeler – modeler za definisanje relacija izmeĎu entiteta u bazi,
koji je omogućavao otvoren pristup u razvoju aplikacija, povećavao produktivnost u
razvoju aplikacija i obezbeĎivao jednostruko uniformno okruţenje u svim fazama
razvoja aplikacija.
Ono što je davalo posebnu prednost ovoj bazi podataka bila je činjenica da ste
mogli i najsloţeniju aplikaciju baze razviti na jednom PC-u, recimo pod DOS-om –
disc operating system, a zatim je preneti na veliki recimo VAX sistem, koji je radio
pod VMS-om – Vax operating system, i da ta aplikacija lepo radi kao da je razvijena
na samom VAX-u.

12
@ViPserbia

Progress
Progress je takoĎe jedna od baza podataka koja je veoma prisutna na našim
prostorima. Kao i ZIM i ova baza je zahtevala relativno skromne hardverske resurse i
imala mogućnost veoma lakog transportovanja sa jedne računarske opreme ili
operativnog sistema na druge. Zbog toga je i bila rado primenjivana kod onih firmi
koje su se bavile razvojem aplikacija za druge korisnike, jer im je na taj način bio
olakšan prenos i instalacija jednom razvijenih programskih paketa – aplikacija na
različite platforme koje su bile prisutne kod različitih korisnika.
Ovo je takoĎe baza zasnovana na visokorazvijenom i potpuno proceduralom
4GL jeziku četvrte generacije, koja poseduje veoma veliku brzinu u radu, veoma
veliku efikasnost, već pomenutu prenosivost, mogućnost veoma dobrog rada u raznim
varijantama mreţa i pod različitim operativnim sistemima. Pored toga ova baza
podataka obezbeĎuje i veoma visok integritet podataka kao i sigurnost u radu.

13
@ViPserbia

2. MODELI – STRUKTURE PODATAKA

Projektovanje automatizovanih informacionih sistema predstavlja kompleksan

poduhvat. Jedan od takvih je projektovanje strukture ili organizacije podataka.

Efikasnost obrade podataka se moţe posredno odreĎivati putem takvih

kriterijuma kao što su:
 vreme potrebno da se pronaĎe traţeni podatak,
 memorijski prostor potreban za smeštaj strukture podataka (danas sve manje bitan)
 kompleksnost algoritama za formiranje, korišćenje i ažuriranje strukture podataka.

Pošto se isti skup podataka moţe urediti na više načina, prilikom projektovanja
se obično postavlja pitanje izbora strukture koja će omogućiti, efikasniju obradu.
U operativnoj kao i u eksternim memorijama grade se, u principu, isti tipovi
strukture podataka, ali se za njihovu izgradnju koriste različiti postupci. Za izgradnju
strukture podataka u operativnoj memoriji, biraju se postupci koji dozvoljavaju
efikasno korišćenje memorijskog prostora. Pri izgradnji struktura podataka na
eksternim memorijama, osnovni cilj predstavlja minimizacija broja pristupa ureĎaju
pri traţenju odreĎenog podatka.

2.1. Osnovne strukture podataka

Kao što je poznato osnovni zadatak automatizovanih informacionih sistema je

prikupljanje, obrada i prezentiranje podataka o entitetima raznih klasa. Pri tome klase
entiteta mogu da predstavljaju:
- klase objekata, kao što su proizvodi, zgrade ili organizacije,
- klase dogaĎaja, kao što su uplata, ulaz robe, materijala
- klasa raznih pojmova i pojava.

Svaka klasa entiteta ima odreĎene osobine kao što su naziv, boja, vrednost,
trajanje i slično. Ove osobine se nazivaju obeleţjima. Sa tačke gledišta zadataka
informacionog sistema, nisu sva obeleţja klase entiteta jednako vaţna.
Od obeleţja, bitnih za realizaciju zadataka informacionog sistema, gradi se
odgovarajući model klase entiteta.
Svakom od obeleţja odgovara jedan skup svih mogućih vrednosti koje to
obeleţje, u konkretnim slučajevima, moţe imati. Obeleţje boja uzima vrednosti iz
skupa {bela, ţuta, crna, plava, ...}.
Obzirom da, u opštem slučaju, obeleţje uzima pojedine vrednosti iz datog
skupa sa različitim verovatnoćama, obeleţje se moţe smatrati slučajnom veličinom. U

14
@ViPserbia

tom slučaju se vrednosti, koje obeleţje uzima, nazivaju njegovim konkretnim

vrednostima.
Postoje obeleţja, koje se dalje ne mogu dekomponovati i ona se nazivaju
elementarnim obeleţjima.
Naziv proizvoda, boja automobila, ime stanovnika, predstavljaju elementarna
obeleţja različitih klasa entiteta.
Sa druge strane ako imamo niz elementarnih obeleţja ili logički proizvod
elementarnih obeleţja tada se kaţe da on predstavlja sloţeno obeleţje.
Sloţena obeleţja predstavljaju na primer adresa stanovnika (mesto,ZIP kod,
ulica, broj)
Pri tome konkretizacija elementarnog obeleţja predstavlja elementarni podatak,
a konkretizacija sloţenog obeleţja predstavlja sloţeni podatak.
Ona obeleţja čije se vrednosti dobijaju primenom nekog algoritma na vrednosti
drugih obeleţja nazivaju se izvedenim obeleţjem, a njihove vrednosti izvedenim
podacima. (iznos je proizvod količine i cene i on predstavlja izvedeno obeleţje)

Ona elementarna ili sloţena obeleţja čije vrednosti jednoznačno identifikuju

pojave jednog tipa sloga, nazivaju se ključem ili pak primarnim ključem.
Razna sortiranja odreĎenog skupa pojava odreĎenog tipa sloga u datoteci se
najčešće izvršavaju u saglasnosti sa vrednostima primarnog ključa.
Za razliku od primarnog sekundarni ključ predstavlja ono obeleţje kod koga se
ista vrednost javlja kao elemenat većeg broja pojava istog tipa sloga.

Kada se govori o bazama podataka onda je uz njih pojmovno najčešće vezano

traţenje ili pretraţivanje baze, a pojam traţenja pojave sloga u datoteci i pojam
pretraţivanja datoteke su veoma blisko povezani za pojmove primarnog i
sekundarnog ključa.
Naime traţenje se vrši uz pomoć vrednosti primarnog ključa, pa se kao rezultat
traţenja moţe dobiti najviše jedna pojava sloga, dok se pretraţivanje vrši na osnovu
vrednosti sekundarnog ključa, pa se kao rezultat pretraţivanja moţe dobiti veći broj
pojava datog sloga.
Pri tome treba imati na umu da i traţenje i pretraţivanje mogu biti bezuspešni,
tj. rezultat tih aktivnosti moţe biti samo konstatacija da u datoteci ne postoji pojava
sloga sa posmatranom vrednošću ključa. Vrednost ključa sa kojom se vrši traţenje ili
pretraţivanje naziva se argumentom traţenja ili pretraţivanja.
Sledeći pojam koji je veoma prisutan kada su u pitanju datoteke ili baze
podataka je aţuriranje. Aţuriranje predstavlja skup aktivnosti koje imaju zadatak da
podatke u datoteci ili bazi dovedu u saglasnost sa stvarnim stanjem obeleţja entiteta.
Pod pojmom aţuriranja se podrazumeva sledeći skup aktivnosti: upisivanje
novih pojava sloga u datoteku - bazu, zatim modifikacija onih obeleţja koja nisu

15
@ViPserbia

ključna u postojećoj pojavi sloga kao i brisanje postojećih pojava sloga i njihovih
veza ukoliko je to dozvoljeno, tj. ukoliko se ne narušava integritet baze.
U nastavku ćemo dati neke od osnovnih pojmova koji se odnose na strukture
podataka. Tako naprimer skup S moţe predstavljati skup obeleţja, skup slogova
različitog tipa, skup podataka, skup pojava slogova istog tipa, skup pojava slogova
različitog tipa.
Često se u skupove podataka uvode razne relacija Ri (i=1,2, ...,), a kao
rezultantna relacija se moţe pojaviti unija, presek ili neka druga forma relacija Ri.
Tako se naprimer unija R relacija R1 i R2 se definiše kao R = R1UR2.
Relacija se mogu predstavlja spiskom ureĎenih parova, a kao prikaz relacija se
moţe se koristiti matrica aij sa vrstama ai i kolonama matrice aj (i,j = 1,2...,N)
Zatim se kao jedan od mogućih načina grafičkog predstavljanja strukture
podataka koristi usmereni graf tj. na taj način se moţe nacrtati neka struktura.
Usmerani graf G predstavlja par (S,p), gde je S skup svih elemenata, a P skup
svih potega strukture dok se elementi skupa S predstavljaju se pravougaonicima sa
upisanim nazivom elementa, a usmereni potezi strelicama.
Na slici 2.1 je dat primer jedne takve moguće strukture podataka.

S1

S2 S3

S4 S5 S6 S7

Slika 2.1 Struktura podataka - usmereni graf

Strukture podataka se mogu klasifikovati uz pomoć više kriterija, a za

projektovanje informacionih sistema vaţni su sledeći kriterijumi:

-dozvoljeni broj neposrednih prethodnika i sledbenika nekog elementa strukture

-priroda elemenata skupa

Obzirom na prvi kriterijum, u osnovi se razlikuju linearne, hijerarhijske i

mreţne strukture, sa odreĎenim varijetetima.
Vezano za drugi kriterij, u osnovi se razlikuju logičke strukture obeleţja,
logičke strukture podataka i fizičke strukture podataka, kao i njihovi varijeteti

16
@ViPserbia

Linearne strukture podataka se obično nazivaju se listama ili lancima. Pri tome
je struktura liste veoma jednostavna jer svaki elemenat liste moţe imati samo jednog
prethodnika i jednog sledbenika. Na slici 2.2 je prikazana jedna takva otvorena lista, a
na slici 2.3 zatvorena lista

S1 S2 S3

Slika 2.2 Otvorena lista

S1 S2 S3

S6 S5 S4

Slika 2.3 Zatvorena lista

Hijerarhijska struktura - model podataka podrazumeva hijerarhijsku strukturu

podataka koja ima oblik stabla. Na prvom nivou je koren stabla odnosno osnovni
element stabla, a zatim se odvajaju pojedine grane stabla.
Model hijerarhijske baze podataka (kao podskup mreţnog modela) je tip baze
podataka orijentisan još uvek na pojmu "slog". Pri tome ovaj model dozvoljava da se
slogovi organizuju (grupišu) u skupove (setove). Vlasnik skupa se naziva "roditelj"
(parent), a član skupa se naziva "dete" (child).
Veze izmeĎu setova se realizuju sa takozvanim "poveznim listama" (linked
list). Slika 2.4 ukazuje na strukture hijerarhijske šeme koja ima u organizacionom
smislu strukturu "drveta". To znači da je postojao "prethodni" (previous) i "sledeći"
(next) slog u setu:
Hijerarhijske baze podataka su organizovane u relaciji "jedan prema jedan"
(1:1) i "jedan prema više" (1:M).

17
@ViPserbia

S1

S2 S3

S4 S5

Slika 2.4 Nepotpuna nekompletna hijerarhijska struktura

U zavisnosti od ključa nadreĎenog segmenta ili grane moţe da zavisi jedan, ili
više podreĎenih segmenata, a moţe se desiti da ne postoji ni jedan podreĎeni segment.
Pri tome treba imati na umu da su segmenti – grane stabla na niţem nivou u
podreĎenom odnosu tj. podreĎeni segmentima odnosno granama stabla na višem
nivou.
Hijerarhijske strukture se nazivaju i strukturama tipa stablo. Svaki elemenat
strukture naziva se čvorom stabla. Pri tome čvor, kome odgovara nula kolona,
odnosno, čvor, u koji ne dolazi ni jedan poteg, naziva se koren stabla. Čvor, kome
odgovara nula vrsta, odnosno, čvor iz koga ne polazi nijedan poteg, naziva se listom.
Svaki čvor predstavlja koren jednog podstabla.
MeĎu čvorovima stabla postoji hijerarhija nivoa. Koren predstavlja čvor prvog
nivoa hijerarhije. Proizvoljan čvor se nalazi se na k-tom nivou hijerarhije (k < (l, 2,...
,h), gde je h broj nivoa hijerarhije stabla, ako se nalazi na kraju puta duţine k-l, a put
počinje u korenu stabla. Duţina puta se meri brojem potega izmeĎu dva posmatrana
čvora. Broj nivoa hijerarhije h naziva se visinom stabla. Visinu stabla h predstavlja
broj, koji je za jedan veći od duţine puta izmeĎu korena i najudaljenijeg lista.
Za stablo se kaţe da je puno, ako se svi listovi nalaze na istom odstojanju od
korena, odnosno, ako, od korena, svakom listu odgovara put duţine h-1. Za stablo se
kaţe da je kompletno, ako svi njegovi čvorovi, koji ne predstavljaju listove, imaju
svih n odlaznih potega.
Stablo na slici 2.1 je kompletno i puno, dok je stablo na slici 2.5 kompletno, ali
nije puno, a stablo na slici 2.4 je nekompletno i nepotpuno.
Za pojmove punog i kompletnog stabla vezan je i pojam kapaciteta stabla. Pod
kapacitetom stabla K podrazumeva se broj elemenata koji se mogu smestiti u čvorove
kompletnog punog stabla reda n i visine h. Kapacitet čvora k predstavlja broj
elemenata koji se moţe smestiti u čvor.

18
@ViPserbia

S1

S2 S3

S4 S5 S6

Slika 2.5 Nepotpuna kompletna hijerarhijska struktura

Broj čvorova kompletnog punog stabla C iznosi

K = (nh – 1)/(n-1) k
Za datu vrednost C, visina punog kompletnog stabla red n iznosi:
h = logn ( l+ (n-l) C).
Za stablo se kaţe da je balansirano, ako za svaki čvor vaţi da se broj čvorova u
svakom njegovom podstablu ne razlikuje za više od jedan.

Primer: Setovi slogova jedne poslovne organizacije su:

 Odelenje knjigovodstva
o Slogovi (zaposleni)
 Jovanović
 Petrović
 Kukoč
 Odelenje marketinga
o Slogovi (zaposleni)
 Ugren

 Odelenje za informacioni sistem (IS)

o Slogovi (zaposleni)
 Radaković
 Nešić

Napomenimo ovde da su se još ranih 60-tih godina pojavile prve ideje o razvoju
posebnih softvera za upravljanje bazama podataka. Poznati teoretičar toga doba
Charles W. Bachman (General Electric Co.) razvio je tehniku dijagrama preko kojih
je stvarao takozvane programske strukturne dijagrame (PSD-program structure
diagrams). Ove tehnike su značajno poboljšale metodologiju analize informacionih

19
@ViPserbia

sistema. Bachmannov dijagram je grafička prezentacija uglavnom malih delova

programa pomoću limitiranog skupa grafičkih simbola.

BAZA PODATAKA

SET-1 SET-2 SET-3

Odelenje knjigovodstva Odelenje marketinga Odelenje za IS

Jovanović Petrović Kukoč Ugren Radaković Nešić

Slika 2.6 Hijerarhijska struktura - primer

Rezultat toga jeste da su se pojavili IDS (Integrated Data Store) softveri

opremljeni sa mogućnošću realizacije šeme podataka (data scheme) i ţurnaliziranja
(logging). Ovaj softver je radio na GE računarima i mogao je da koristi samo jednu
datoteku kao bazu podataka, a sve generacije tabela sa podacima morale su ručno da
se kodiraju (progameri su pisali rutine za navigaciju kroz bazu podataka).
Jedan od korisnika ovog softvera je bila poznata hemijska kompanija za
proizvodnju guma BF Goodrich Chemical Co. i oni su preradili ovaj softver i kao
rezultat toga pojavio se IDMS (Integrated Data Managmenet System). Jedna od
najvećih multinacionalnih kompanija u oblasti informatičke tehnologije IBM
(international Business Machine Corp.) je 1968. uvela svoj IMS (Information
Management System) sistem koji je podrţavao hijerarhijsku organizaciju baze
podataka za svoje računare IBM/360 generacije.
Pored ovoga razvili su i alat DL/1 (Data Language One) za potrebe navigacije
kroz takvu bazu. IBM je za potrebe američkih avio kompanija razvio i podvarijantu
svog rešenja pod komercijalnim nazivom SABRE. Nešto kasnije, 1973. godine
pojavila se Cullinane Corp. (kasnije nazvana Cullinet Software Inc.) koja je počela da
plasira inoviranu verziju Goodrichevog IDMS softvera i zahvaljujući tome postali su
u to vreme jedna od najvećih kompanija u oblasti softvera. Ova kompanija se kasnije
restruktuirala u danas poznatu kompaniju CA-Computer Asscociate. Imali su i tzv.
preprocesore realizovane u COBOL okruţenju. Pored ovih kompanija, na trţištu su
bili prisutni i Honeywell sa svojim rešenjima (IMS), Univac (kasnije Unisys) sa DMS
1100, TOTAL/SUPRA (Cincom) i Digital VAX DBMS.
Zbog komplikovane navigacije ove baze su bile veoma kompleksne i traţile su
dobro osposobljeno projektantsko/programersko osoblje. Lanci (poveznice) su lako
pucali i takve baze je bilo jako teško oporavljati u slučajevima havarija.

20
@ViPserbia

Na kraju moţemo reći za hijerahijski tip baze podataka :

- sastoji se od slogova koji su povezani (link),
- veze mogu biti jednostruke i dvostruke i poveznice imaju svoj kraj,
- kako smo već pomenuli govori se o relaciji "roditelj-dete",

Ove baze funkcionišu na osnovu hardverskih adresa zapisa (slogova) tako da se

u poveznicama (link) nalazila fizička adresa sloga odnosno relativna adresa u odnosu
na prvi slog u setu. ICL (International Computer Limited) se pojavio sa specijalnim
hardverom (ugraĎeni mikroprocesori u glave za pisanje/čitanje na diskovima za brzo
pretraţivanje fizičkih adresa podataka.

Matematički opisano, hijerarhijski model podataka je baziran na skupu sa

strukturom "drveta". Pri tome, "drvo" je takva struktura u kojoj je slog tako definisan
da je pored korisnikovih podataka obavezno sadrţao i dva dodatna elementa (polja):
- koren (root) odnosno slog sadrţi polje "gospodar" (master field),
- ključ za pristup (key field) koji identifikuje vrstu, lokaciju i/ili redosled
slogova u subordinaciji,
- svaki slog ima samo JEDNOG roditelja a svaki roditelj moţe da ima jedno
ili više dece,
- prednost ovakve organizacije: brzina i efikasnost za odreĎene aplikacije
hijerarhijski orijentisane,
- problem: kako je organizacija podataka unapred definisana mora se svaka
relacija eksplicitno kreirati u bazi podataka,
- hijerarhijska organizacija je podskup mreţne organizacije baze podataka

Mrežne strukture podataka

Ono što je posebno značajno kod ove strukture je da svaki elemenat skupa
moţe imati više direktnih prethodnika i više direktnih sledbenika
Mreţni model podataka se zasniva na mreţi podataka koji su tako povezani da
ne postoje ni nadreĎeni niti podreĎeni segmenti baze.
Ovakva struktura je mnogo sloţenija u odnosu na hijerarhijsku strukturu.
Mreţna struktura se moţe dobiti i odgovarajućom kombinacijom hijerarhijkih
struktura.
Pored toga ona značajno smanjuje dupliranje nekih podataka u odnosu na
hijerarhijsku strukturu i značajno smanjuje vreme potrebno za pronalaţenje nekih
podataka.
Hijerarhijska i mreţna struktura podataka mogu zadovoljiti kada su veze
izmeĎu podataka malobrojne ili pak jednostavne. MeĎutim u slučajevima sloţenijih

21
@ViPserbia

veza predstavljanje meĎusobnih odnosa takvim strukturama postaje veoma oteţano. U

tom slučaju se koriste takozvane relacione strukture odnosno modeli podataka.

Relacioni model podataka

1970. godine E.F. Kod (E.F.Codd - u to vreme je bio član IBM-ove istraţivačke
laboratorije u San Hozeu (San Hose, California) je publikovao sada već klasični rad
"A Relational model of Data for Large Shared Data Banks" – Relacioni model
podataka za velike distribuirane baze podataka. Pojava relacionog modela je bila
uslovljena dobro poznatim negativnim karakteristikama hijerarhijskog i mreţnog
modela. U delu koji se odnosi na objekte, relacioni model je relativno siromašan jer
raspolaţe objektima relacija, atribut, kandidat za ključ, primarni ključ i strani ključ.
Veze izmeĎu relacija se uspostavljaju na osnovu stranih ključeva ili uvoĎenjem
asocijativnih relacija. Najznačajnija ograničenja relacionog modela su ograničenja
integriteta entiteta i ograničenja referencijalnog integriteta. U nekim realizacijama
SUBP-a definiše se odreĎeni skup integriteta atributa (na domen, na opseg vrednosti i
slično).
Uopšteno relacioni sistem se moţe opisati kao grupa slobodno povezanih
struktura podataka koje zajedno daju potrebne informacije o nekom subjektu. Naime
u većini slučajeva je besvrsishodno drţati baš sve informacije o nekom subjektu u
jednoj datoteci ili tabeli ili zapisu. Ove informacije se grupišu u odreĎene logičke
celine i smeštaju u posebne datoteke ili tabele, a relacije se koriste za povezivanje
ovih srodnih grupa podataka.

Poseban problem je pitanje očuvanja referencijalnog integriteta. On se u

mnogim SUBP-ima razrešava na nivou samog aplikativnog koda. Ukoliko je i
ugraĎen, tada se troše veliki sistemski resursi za njegovo očuvanje pa ga je potrebno
veoma paţljivo i umereno koristiti. Najmoćniji deo relacionog modela su operatori
koji se baziraju na relacionoj algebri od kojih su svakako najvaţniji restrikcija,
projekcija i spajanje. Odmah nakon prvih naučnih radova o relacionom modelu
krenulo se u realizaciju relacionih jezika koji su trebali u konkretnoj sintaksnoj formi
realizovati neke ili pak sve relacione operatore. Jedan od prvih je Čemberlenov (D.D.
Chamberlin) SEQUL (Structured English Query Language) koji je kroz razradu IBM-
ovog Sistema R uobličen u SOL – struktuirani jezik za upite. Mada je relaciono
kompletan on ima nedostatak ortogonalnosti.
Isto tako, Kod navodi da i promovisani ANSI standard (1986) više štiti
postojeće implementacije ovog jezika nego što predstavlja zaista solidnu osnovu za
budućnost. SOL je jezik za definisanje, manipulisanje i kontrolu podataka u relacionoj
bazi. Zbog njegovih osobina mnogi ga proizvodači dopunjuju svojim operatorima.
Loše karakteristike SOL-a u radu sa ekranskim formama i izveštajima se nadopunjuju

22
@ViPserbia

njegovim ekstenzijama u tim pravcima, što opet dovodi do daljeg odstupanja od

standarda. Nimalo ne umanjujući pozitivne karakteristike relacionog modela, mora se
reći da u prvim fazama primene nije predstavljao baš idealno sredstvo za fazu dizajna
informacionog sistema jer je nametao obavezu stroge primene teorije normalizacije.
Produkcione brzine relacionoh baza podataka su u prvim fazama razvoja
relacionih baza bile znatno ispod brzine hijerarhijskih i mreţnih. Ukoliko bi striktno
primenjivali pravila za ocenu relacionog softvera tada bi u toj fazi razvoja njihov broj
bio sveden na minimum dok su se ostali morali okarakterisati kao pseudorelacioni
softveri.
Kao što se relacioni model javio kao odgovor na nedostatke mreţnog i
hijerarhijskog modela tako se Entity Relationship model of data base – entitet
relaciona baza podataka je razvijena uvoĎenjem tzv. elementa relacije izmeĎu entiteta
u bazi podataka. 1976 Peter Chen je na MIT- u je uveo pojam Entity-Relationship
data model – model podataka u kome postoje relacije izmeĎu entiteta. Neki autori
nazivaju ovaj model i postrelacionim Taj model grafički predstavlja osnovne
karakteristike strukture aplikacije baze podataka. Ovakav način predstavljanja
podataka je veoma jednostavan, koncizan i gotovo da sam objašnjava kakve su
interakcije izmeĎu pojedinih entiteta baze. Prvobitna upotreba E-R modela podataka
se svodila na fazu dizajniranja informacionog sistema zbog velikog broja koncepata
koji poseduje.
Svi koncepti relacionog modela (relacijom se u E-R modelu naziva tip entiteta)
su i dalje zadrţani ali je pridodat i skup novih.

E-R model
Kao što se relacioni model javio kao odgovor na nedostatke mreţnog i
hijerarhijskog modela, tako se Čenov (P.P.Chen) E-R model (Entity-Relationship
Model) javio kao odgovor na nedostatke relacionog modela. Neki autori oval model
nazivaju i postrelacionim. Prvobitna upotreba E-R modela podataka se svodila na fazu
dizajniranja informacionog sistema, zbog velikog broja koncepata koji poseduje i, u to
vreme, nepostojanja realizovanih operatora u nekom od SUBP-a. Svi koncepti
relacionog modela (relacija se u E-R modelu zove tip entiteta) su i dalje zadţani i
pridodat im je skup novih:
Slab tip entiteta - tip objekta koji je identifikaciono i/ili egzistencijalno zavisan
od drugog tipa objekta pri čemu ta zavisnost moţe biti i zavisnost prethoĎenja.
Tip veze - Objekat preko koga se uspostavlja veza izmeĎu tipova entiteta.
Ukoliko se radi o vezi izmeĎu pojava jednog tipa entiteta tada govorimo o
refleksivnoj vezi.
Mešoviti tip objekta (agregacija) - objekat preko koga se uspostavlja veza
izmeĎu tipova entiteta, pri čemu se on dalje moţe povezivati sa drugim tipovima
entiteta preko veza

23
@ViPserbia

Uloga - Predstavlja ulogu koju objekat ima u vezi. Ukoliko se za navedenu

ulogu ne postavi neki uslov tada govorimo o sinonimu.
Generalizacija ili specijalizacija – je koncept kojim se realizuje odnos
podtipova i nadtipova objekata pri čemu vaţi pravilo nasleĎivanja osobina (atributa)
od nadtipa ka podtipovima,
Kardinalnost - Koncept koji predstavlja ograničenje na osnovu minimalnog i
maksimalnog broja veza jednog tipa entiteta sa drugim u konkretnoj vezi.
Ovako definisan skup objekata ukazuje da se radi o semantički bogatom
modelu podataka koji je upravo zbog toga našao visok stepen upotrebe. Ukoliko se u
fazi dizajna poštuje mali skup neophodnih pravila, model podataka će bitl u 3NF ili u
BCNF.

2.2 Dodatna definisanja nad podacima

Logičke strukture obeležja

Kada se u skup obeleţja jedne klase entiteta uvede relacija strogog poretka tako
da svako obeleţje moţe imati najviše jednog neposrednog prethodnika i najviše
jednog neposrednog sledbenika, dobija se linearna struktura obeleţja. Ta linearna
struktura obeleţja naziva se tipom sloga.
UvoĎenjem relacija u skup slogova različitog tipa ponovo se dobija logička
struktura obeleţja.
Logička struktura obeleţja definisana nad skupom slogova različitog tipa,
karakteristična je za baze podataka. Logičke strukture obeleţja baza podataka mogu
biti linearne, hijerarhijske, mreţne ili relacione. Tip sloga predstavlja logičku
strukturu obeleţja datoteke. Datoteci najčešće odgovara linearna logička struktura
obeleţja definisana nad skupom elementarnih obeleţja.
Svakom tipu sloga, kao linearnoj strukturi obeleţja, odgovara skup pojava
sloga. Svaka pojava sloga predstavlja jednu linearnu strukturu podataka. UreĎenje
podataka u pojavi sloga definisano je ureĎenjem obeleţja u tipu sloga. Kada se u skup
pojava, sloga jednog tipa, uvede relacija strogog poretka dobija se logička struktura
podataka datoteke. Logička struktura podataka datoteke je najčešće linearna, a dobija
se ureĎivanjem pojava sloga jednog tipa saglasno rastućim ili opadajućim
vrednostima ključa.
Logičke strukture podataka u bazama podataka se definišu uvoĎenjem relacija u
skup pojava slogova različitog tipa. Pored relacija izmeĎu pojava slogova različitog
tipa, koje diktira logička struktura slogova različitog tipa, skup pojava slogova
snabdevaju i relacije izmeĎu pojava sloga.

24
@ViPserbia

Pošto logička struktura obeleţja ne poseduje informaciju o ureĎenju pojava

sloga jednog tipa bez obzira na broj pojava sloga, jednoj logičkoj strukturi obeleţja
odgovara veći broj logičkih struktura podataka. MeĎutim, preslikavanje logičke
strukture podataka na logičku strukturu obeleţja je jednoznačno.

Definisanje fizičke strukture podataka

Kada se podaci i veze logičke strukture podataka smeste na magnetni medij

nekog memorijskog ureĎaja (traka, disketa, disk, CD), dobija se fizička struktura
podataka. Pri tome se, za predstavljanje podataka, umesto prirodne koristi binarna
azbuka. Pored podataka, koje sadrţi logička struktura podataka, fizička struktura
podataka se proširuje i podacima, svojstvenim postupcima memorisanja na
konkretnom mediju, podacima koji opisuju odreĎene osobine pojava slogova (na
primer: duţina pojave sloga izraţena brojem znakova prirodne azbuke, pripadnost
tipu sloga i slično). TakoĎe, postoje različiti postupci za predstavljanje veza logičke
strukture podataka,

Istoj logičkoj strukturi podataka moţe odgovarati više fizičkih struktura

podataka, ali je preslikavanje fizičke na logičku strukturu podataka jednoznačno.
Podaci i veze logičke strukture podataka, smešteni na medij memorijskog
ureĎaja i prošireni nizom elemenata svojstvenih postupcima za memorisanje podataka
i veza na konkretnom ureĎaju, predstavljaju fizičku strukturu podataka.
Smeštanje podataka i veza u lokacije na memorijskom mediju predstavlja
zadatak operativnog sistema, odnosno njegovog dela koji se naziva sistemom za
upravljanje podacima.
U cilju povećanja efikasnosti kasnije obrade podataka, sistem za upravljanje
podacima snabdeva fizičku strukturu podataka nizom dodatnih podataka.
Specifičnosti smeštanja podataka u lokacije na memorijskom prostoru i dodatni
podaci su takoĎe elementi fizičkih struktura podataka.

Definisanje formata sloga

Za predstavljanje pojave sloga S, kao elementa fizičke strukture podataka,

koristi se takozvana linearna struktura prema datoj slici 2.7. Struktura na slici
predstavlja opšti oblik formata sloga gde k(S) predstavlja vrednost ključa, p(S)
konkretizaciju neključnih obeleţja sloga, u(S) vrednost pokazivača, a s(S) status
sloga. Dok se k(S) i p(S) dobijaju preslikavanjem logičke na fizičku strukturu
podataka, u(S) i s(S) predstavljaju moguća proširenja sloga svojstvena fizičkoj
strukturi podataka.

25
@ViPserbia

k(S) p(S) u(S) s(S)

Slika 2.7 Opšti format sloga

Načini memorisanja veza logičke strukture podataka

Veze (relacije) logičke strukture podataka mogu se fizički realizovati na više

načina. Tu su pre svega u pitanju fizičko pozicioniranje, pokazivači, adresar
(directory-datoteka u kojoj su memorisane veze pojava sloga iz druge datoteke),
dvodimenzionalne binarne matrice i drugo.
Fizičko pozicioniranje predstavlja veoma efikasno sredstvo, za memorisanje
linearnih struktura podataka. U fizički susedne lokacije memorijskog prostora
smeštaju se logički, susedni slogovi. Fizička susednost nosi informaciju o vezama
logičke strukture podataka. Fizičko pozicioniranje predstavlja jedinstven postupak
kada se smeštaju podaci jednog sloga na memorijski medij, a često se koristi i za
fizičku realizaciju linearnih struktura slogova.
Za predstavljanje kompleksnih logičkih struktura, u datotekama i bazama
podataka najčešće se koriste pokazivači. Pokazivači se memorišu ili uz slog, kada
predstavljaju integralni deo sloga, ili u posebnoj datoteci-adresaru. U oba slučaja
obezbeĎuju informaciju o adresi (ili adresama) lokacija sa slogovima koji su u
logičkoj vezi sa posmatranim slogom. Ta informacija moţe biti data kao mašinska
adresa, relativna adresa ili simbolička adresa, odnosno vrednost ključa.
Pokazivači u obliku mašinske adrese obezbeĎuju najbrţu obradu, ali imaju
nedostatak da su veoma nefleksibilni u odnosu na promene fizičke strukture podataka.
Izmena ureĎaja ili rasporeda slogova na memorijskom medijumu zahteva i izmene
pokazivača.
Pokazivači u obliku relativne adrese sadrţe redni broj lokacije dela
memorijskog prostora dodeljenog datoteci. Pretvaranje relativne u mašinsku adresu
predstavlja zadatak jednog algoritma. Promene adrese u fizlčkoj strukturi podataka
dovode samo do izmene tog algoritma, ali ne i do izmene samih pokazivača i1i
aplikativnlh programa.
Primena simboličkih adresa kao pokazivača predstavlja veoma fleksibilno, ali
relativno sporo rešenje. Numerički ključ se transformiše u adresu uz pomoć neke
formule. Nenumerički ključ se prvo mora pretvoriti u numerički ili zahteva postojanje
tabela sa parovima (ključ, adresa).

26
@ViPserbia

Definisanje pojma bloka podataka

Blokiranje predstavlja postupak grupisanja slogova pre upisivanja na medij

eksternog memorijskog ureĎaja. Takva grupa odreĎenog broja slogova naziva se
blokom. Blokiranje poboljšava iskorišćenje memorijskog prostora i povećava
efektivnu brzinu razmene podataka izmeĎu operativne i eksterne memorije.
Često, blokiranje povećava i efikasnost obrade podataka, jer smanjuje broj
ulazno-izlaznih operacija neophodnih za obradu datoteke. Blok sadrţi jedan ili više
slogova. Broj slogova u jednom bloku naziva se faktorom blokiranja. Faktor
blokiranja f se definiše u postupku projektovanja datoteke, a moţe imati konstantnu ili
promenljivu vrednost.
Moţe se vršiti i kompresija podataka u slogu, izostavljanjem nepopunjenih
pozicija u pojedinim poljima, dobijaju se slogovi promenljive duţine.
Kombinovanjem konstantnog i promenljivog faktora blokiranja sa slogovima
konstantne i promenljive duţine, dobijaju se četiri moguće vrste blokova. To su:
- blokovi sa konstantnim faktorom blokiranja i konstantnom duţinom slogova
- blokovi sa konstantnim faktorom blokiranja i promenljivom duţinom slogova
- blokovi sa promenljivim faktoram blokiranja i konstantnom duţinom slogova
- blokovi sa promenljivim faktorom blokiranja i promenljivom duţinom slogova.
Prilikom razmene podataka izmeĎu operativne memorije i eksterne memorije, u
operativnu memoriju se uvek prenosi ceo blok. Ova činjenica ograničava veličinu
bloka, odnosno, nameće potrebu da se pri izboru veličine bloka vodi računa o zauzeću
operativne memorije.
Pojam bloka se odnosi na niz od N sukcesivnih slogova smeštenih na nekoj
lokaciji na memorijskom mediju. Ta lokacija se sastoji od N podlokacija. Pošto, po
definiciji, svaka podlokacija predstavlja lokaciju, u nastavku će se za lokaciju sa N
podlokacija koristiti naziv fizički blok, a za podlokacije će se koristiti naziv lokacije.
Fizički blok poseduje adresu na memorijskom prostoru. Ta adresa moţe biti mašinska
ili relativna.
Kada je reč o jedinici magnetnog diska, mašinska adresa moţe imati oblik
(C,T,S), gde je C broj cilindara T broj staze - traga na cilindru, a S broj sektora na
stazi. Kada je reč o jedinici magnetne trake, adresa se moţe shvatiti kao redni broj
fizičkog bloka od početka medija, mada se bloku na traci nikad ne pristupa na osnovu
adrese. Relativna adresa predstavlja redni broj fizičkog bloka od početka
memorijskog prostora dodeljenog datoteci.

Upisivanje podataka na magnetni disk

Upisivanje blokova na magnetni disk se moţe vršiti uz pomoć jednog od dva

meĎusobno različita postupka. To su takozvani sektorski i programabilni postupak.

27
@ViPserbia

Kod sektorskog postupka sve staze na aktivnim površinama ploče diska su podeljene
na odreĎeni broj sektora. Broj sektora varira od ureĎaja do ureĎaja. Obično
predstavlja neki stepen broja 2, koji jc veći od 1, a moţe biti manji ili jednak 128.
Blokovi sa jednim ili više slogova memorišu se tako što se nakon početka
sektora ostavi jedan mali meĎusektorski razmak, a zatim se upisuje blok na stazu.
Ukoliko je blok duţi od kapaciteta soktora, njegovo se momorisanje nastavlja u
narednim scktorima, ali se nakon svakog početka sektora ostavlja mali razmak.
Svaki novi blok se počinje memorisati od meĎusektorskog razmaka novog sektora.
Ukoliko se za memorisanje jednog bloka upotrebi samo deo nekog sektora, ostatak
sektora ostaje prazan. Na slici 2.8 je prikazan upis podataka na magnetni disk. U
slučaju promenljivog faktora blokiranja ili slogova promenljive duţine, kod primene
sektorskog postupka upisa podataka na disk koriste se reči za opis bloka i reči za opis
sloga.
Naziv programabilan potiče od činjenice da se razmaci, izmeĎu fizičkih
blokova sa podacima, generišu programskim putem, kao i od činjenice da se uz svaki
blok memorišu informacije o njegovom sadrţaju. O memorisanju razmaka i dodatnih
informacija brine operativni sistem.
Traţenje bloka na stazi moţe se vršiti ili uz pomoć adrese, odnosno rednog
broja bloka, u kojem se slog nalazi ili uz pomoć vrednosti argumenta traţenja. Ako se
traţenje vrši na osnovu adrese, u operativnu memoriju se prenosi samo sadrţaj
lokacije svakog bloka. Tek kada se adresa bloka u lokaciji pokaţe jcdnakom adresi
traţenog bloka, u operativnu memoriju se prenosi i sadrţaj date lokacije.

N TRAG – STAZA

SEKTOR
n TRAG – STAZA
MEĐUSEKTORSKI
RAZMAK
0 TRAG - STAZA
SEKTOR

Slika 2.8 Upis podataka na magnetni disk

28
@ViPserbia

Ako se traţenje vrši na osnovu vrednosti argumenta traţenja, u operativnu

memoriju se prenosi sadrţaj ključa date lokacije. Ukoliko je vrednost argumenta
traţenja veća od vrednosti ključa u datoj lokaciji, učitava se sadrţaj lokacije narednog
bloka. Tek kada vrednost argumenta traţenja postane manja ili jednaka sadrţaju
ključa date lokacije, u operativnu memoriju se prenosi i odgovarajući sadrţaj područja
podataka, jer se traţeni slog moţe nalaziti samo u tom bloku.

Fizička organizacija baze podataka

Performanse baze se uglavnom mere vremenom odziva na upite ili, što je

uobičajeno kod višekorisničkih SUBP, brojem uspešno završenih transakcija u
jedinici vremena.
Najvaţniji faktor koji utiče na performanse je fizička organizacija baze. S druge
strane, relacione baze i relacioni model podataka u celini su poznati po tome što su
kod njih (relativno) uspešno razdvojeni logički koncepti (i strukture podataka) od
fizičkih. Uprkos tome, pitanje fizičke organizacije (i performansi) i kod njih je veoma
bitno, moţda i u većoj meri nego kod baza zasnovanih na drugim modelima
podataka, za koje se ionako smatra da postiţu bolje performanse.

Definisanje baze u nekim SUBP

Moţda će izgledati čudno zašto se ovde bavimo definisanjem baze, kad je o tome
već ranije nešto rečeno. U početnom delu, meĎutim, namerno su preskočene sve
naredbe koje se odnose na fizičku organizaciju podataka. Sada ćemo se vratiti na te
naredbe (DEFINE DATABASE, odnosno CREATE SCHEMA) i ukratko ćemo
pokazati šta se sve moţe specificirati prilikom definisanja baze.
Pre svega, pojedini SUBP daju mogućnost projektantu da svoju bazu drţi u jednoj
ili više datoteka, koje se mogu nalaziti na različitim fizičkim jedinicama eksterne
memorije (najčešće su to diskovi). Osnovni razlozi za deljenje baze na više fizičkih
datoteka su dvojaki: prvo, na taj način se povećava raspoloţivi prostor za smeštaj
baze, i drugo, poboljšavaju se performanse sistema, jer se ulazno-izlazne operacije
kojima se pristupa bazi raspodeljuju na različite diskove i disk kontrolere, pa je vreme
čekanja kraće.
Prilikom definisanja baze, mogu se naprimer zadati sledeći parametri fizičke
organizacije:
. lokacija (ALLOCATION) i prostor rezervisan za bazu (EXTENT), kao i veličina
stranice u blokovima (PAGE SIZE);
. dozvoljeni prostor za širenje baze (za koji se navode MINIMUM i MAXIMUM broj
stranica, kao i PERCENT GROWTH);

29
@ViPserbia

. lokacija (SNAPSHOT – snimak, ALLOCATION) i veličina datoteke snimka

(SNAPSHOT EXTENT);
. broj i veličina bafera za privremeno čuvanje podataka (BUFFER SIZE, NUMBER
OF BUFFERS);
. najveći broj korisnika koji će istovremeno pristupati bazi.
Ukoliko korisnik koji kreira bazu ne definiše drugačije, ovi će parametri dobiti
neke podrazumevane (default) vrednosti (za male i srednje baze vrednosti tih
parametara uglavnom su zadovoljavajuće). Ako i kada se ukaţe potreba, naredbom
CHANGE DATABASE mogu se promeniti vrednosti nekih od pomenutih
parametara, pa i nekih drugih, kao što je aktiviranje dnevnika završenih transakcija.
TakoĎe se moţe deaktivirati datoteka snimka, čime se dobija reţijsko vreme
potrebno za njeno aţuriranje, ali se istovremeno i povećava mogućnost konflikta
zaključavanja pri višekorisničkom radu, jer će tada sve transakcije čitati svoje podatke
neposredno iz baze. Koje je rešenje bolje, najbolje je utvrditi eksperimentalno.
Ukoliko se radi o bazi sa više desetina relacija i sa ukupnom količinom podataka koja
prelazi desetak megabajta, korisno je razmotriti mogućnosti i prednosti definisanja
baze sa više fizičkih datoteka (multifile database).

Naprimer ako je u pitanju Rdb baza, za takvu bazu je potrebno prilikom

definisanja, definisati jednu ili više zona smeštanja, storage areas, čime se kreiraju
osnovna datoteka tipa .RDB, koja sadrţi podatke o strukturi i lokaciji podataka kao i
posebne datoteke tipa .RDA, koje sadrţe samo podatke. Za multifile bazu potrebno je
da se prilikom definisanja baze definiše bar jedna zona smeštaja, a kasnije naredbom
CHANGE DATABASE odnosno ALTER SCHEMA (SQL), mogu se definisati i
druge.
Ukoliko je baza definisana kao single-file, naredba CHANGE DATABASE,
odnosno ALTER SCHEMA, se ne mogu iskoristiti da se baza prevede u multifile
bazu; za to se moraju koristiti naredbe EXPORT i IMPORT.
Zona smeštanja se naprimer definiše iskazom DEFINE/CREATE STORAGE
AREA, unutar naredbe DEFINE DATABASE (RDO), ili CREATE SCHEMA (SQL).
Svaka zona smeštanja dobija poseban naziv, koji se kasnije moţe iskoristiti za
definisanje fizičkog smeštanja pojedinih relacija/tabela i indeksa. Ovim se iskazom
mogu odrediti veličine sledećih parametara:

- nazivi, lokacije i veličine datoteka u kojima će biti smešteni delovi baze (FILE-
NAME, ALLOCATION, EXTENT);
- veličina stranica i način popunjavanja stranica (PAGE SIZE, PAGE FORMAT), koji
moţe biti UNIFORM (ako stranice sadrţe podatke iz samo jedne relacije) ili
MIXED (ako stranice mogu da sadrţe podatke iz više od jedne relacije) ;

30
@ViPserbia

- granične vrednosti popunjenosti za stranice čiji je format definisan kao MIXED

(THRESHOLDS);
- parametre datoteke snimka koja odgovara .RDA datoteci, pošto svaka datoteka u
multifile bazi moţe da poseduje sopstvenu datoteku snimka.

Da bi se odredilo kako će relacije/tabele biti raspodeljene po fizičkim datotekama,

potrebno je izdati naredbu DEFINE/CREATE STORAGE MAP. Ovom naredbom se
za svaku relaciju navodi naziv jedne ili više zona gde će biti smeštena, pri čemu se
moţe zahtevati smeštanje prema vrednostima podataka u jednoj ili više kolona, ili
smeštanje u skladu sa jednim od indeksa definisanim nad dotičnom relacijom/tabelom
(naravno, naziv indeksa se mora navesti). Na ovaj način projektant baze moţe da
optimizira fizički raspored podataka, prilagoĎavajući ga najšešće korišćenim
pristupnim putevima, tj. najčešće korišćenim upitima. Treba imati u vidu da se
algoritam smeštanja prema vrednostima polja/kolona koristi samo pri smeštanju
podataka naredbama STORE (RDO), ili INSERT (SQL); n-torke u kojima su
vrednosti kasnije promenjene naredbama MODIFY ili UPDATE, neće biti
premeštene. Najzad, naredbom CREATE STORAGE MAP moţe se zahtevati da se
podaci iz neke relacije čuvaju na disku u komprimovanom (šifrovanom) obliku. Na taj
način se, u prvom redu, štedi prostor na disku, a smanjuje se i mogućnost da neko
neovlašćeno lice pročita podatke gledajući sadrţaj datoteke na disku, meĎutim
povećava se rad samog procesora, koji mora da izvrši dekompresiju podataka pre
korišćenja, odnosno kompresiju podataka pre no što se smeste na disk.
Naredba DEFINE/CREATE STORAGE MAP moţe se koristiti samo dok je
relacija/tabela o kojoj se radi prazna, inače će SUBP javiti grešku. Najbolje je koristiti
ovu naredbu odmah po definisanju odgovarajuće relacije, dok u nju još nisu uneti
podaci.

31
@ViPserbia

3. RELACIONE BAZE PODATAKA

Istorijski gledano, kako je već pomenuto u uvodnom delu, tokom 60-tih i 70-tih
godina implementirani su prvi softveri za rukovanje (upravljanje) bazama podataka,
koje su bile zasnovane na hijerarhijskim i mreţnim modelima podataka i kada su se
koristile takozvane flat datoteke. U praksi se pokazalo da je ovakva organizacija
podataka bila nefleksibilna zbog toga što su strukture podataka bile veoma stroge i
bilo je mnogo teškoća da se sa aplikativnim programima izvršavaju rutinske obrade.

Kasnih 70-ih godina se pojavio relacioni model podataka koga su u početku

koristili istraţivači u akademskim krugovima, a kasnije je bio primenjen i za
komercijalne svrhe u proizvodima DB2 i Oracle. Oracle je u stvari bio prva
kompanija koja je implementirala ANSI SQL standarde i na taj način stekla
kompetitivnu prednost na svetskom trţištu. Kasnije su se pojavili i drugi kao Sybase,
MS SQL Server i Access.

Relacioni model podataka operiše sa podacima izmeĎu kojih postoje

odgovarajuće relacije tako da se govori da izmeĎu tabela sa podacima postoji
relaciona veza. Fizička implementacija relacionog modela podataka je u osnovi
zasnovana na primeni tabela. Svaka tabela se sastoji od odgovarajućeg broja kolona
koje se nazivaju polja - fields. Podaci smešteni u istoj koloni moraju biti istog tipa
podataka kao što su znak - character, broj - number ili datum - date. Red - row u tabeli
ili skup vrednosti svih kolona tabele u jednom istom redu se naziva slog - record.
Različite tabele mogu imati različiti broj kolona. Ova osobina se koristi da se
eksplicitno navede relacija izmeĎu dve tabele. Vrednosti koje se pojavljuju u koloni A
tabele X mogu se deliti od strane druge tabele Y.

Potrebno je da korisnik Accessa kao i drugih softvera za upravljanje bazama

podataka upozna osnovnu metodologiju dizajna - projektovanja baza podataka, koja
je u osnovi veoma slična, pri čemu se polazi od definisanja i izrade osnovnih
elemenata baze, a ozbiljnije razlike izmeĎu pojedinih SUBP se javljaju u
mogućnostima i kapacitetima baze kao i u raspoloţivim razvojnim alatima.
Radi jednostavnije ilustracije u nastavku su data dva primera tabela u relacionoj
bazi podataka na primeru jedne male banke.

32
@ViPserbia

Tabela klijenata: KLIJENTI Table

KlijentID Ime_i_Prezime Adresa Mesto Drzava Post_Broj
Number Character Character Character Character Character
1001 Jovan Jovanović Vase Stajića 3 Novi Sad SCG 21000
1002 Petar Petrović Stevana Sremca 23 Zrenjanin SCG 23000
1003 ĐorĎe Arsenijević Humska 23 Beograd SCG 11000
1004 Ana Bodor Petefi Šandora 3 Subotica SCG 24000

Tabela računa: RACUNI Table

KlijentID Broj_Racuna Vrsta_Stednje Dat_Otvaranja Saldo
Number Number Character Date Number
1001 9987 Čekovi 10/12/1999 4000.00
1001 9980 Štrednja 10/12/1999 2000.00
1002 8811 Štednja 01/05/1992 1000.00
1003 4422 Čekovi 12/01/1999 6000.00
1003 4433 Čekovi 12/01/1999 9000.00
1004 3322 Štednja 08/22/1999 500.00
1004 1122 Čekovi 11/13/1998 800.00

Tabela "Klijenti" ima 6 kolona (KlijentID=identitet-šifra klijenta,

Ime_i_Prezime, Adresa, Mesto, Drzava i Post_Broj) i 4 reda (ili sloga) sa podacima.

Tabela "Racuni" ima 5 kolona (KlijentID, Broj_Racuna, Vrsta_Stednje,

Dat_Otvaranja i Saldo) sa 7 redova podataka.

Svaka od ovih kolona zadovoljava jedan od tri tipa podataka. Tip podataka
jedne kolone označen je i vrednošću podatka koji se moţe smestiti u takvu kolonu.
 Number - mogu se smeštati samo brojevi (celi i decimalni)
 Character - mogu se smeštati brojevi, slova, znakovi punktuacije (u Access-u
se ovakav tip podataka naziva tekst)
 Date - mogu se smeštati samo podaci oblika datuma i vremena .

Kod nekih baza podataka implementirane su druge vrste tipova podataka kao
naprimer bit-mape slika (Images), ali ovi i napred navedeni su najtipičniji u upotrebi.

33
@ViPserbia

Treba zapaziti da ove dve tabele dele istu kolonu "KlijentiID" tako da pojave
ove kolone imaju iste vrednosti i u jednoj i u drugoj tabeli. To znači da postoji relacija
koja dozvoljava da klijent pod imenom Jovan Jovanović ima tekući račun sa
čekovima (Čekovi) i račun za štednju (Štednja), a da su oba otvorena istoga dana: 1.
XII 1999.
Za ovakve relacije koristi se i specijalno ime relacije pod nazivom "sastavnice"
(Master/Detail). U relacijama tipa sastavnica, jedan slog iz matične datoteke (kao npr.
klijent sa šifrom KlijentID= 1001 odnosno imenom Ime_i_Prezime=Jovan Jovanović)
moţe imati više slogova u datoteci sa detaljima (u ovom slučaju su to dva računa)
dodeljena jednom slogu iz glavne matične datoteke - tabele.
Moguće je da u ovakvim relacijama tipa "sastavnica" postoji slog u matičnoj
tabeli, a da taj slog nema detalje. MeĎutim, nemoguće je da se pojavi slog u datoteci
"detalji" koji nema odgovarajuću relaciju sa matičnom datotekom. Na primer, moţete
imati klijente u tabeli "Klijent" a da nemate nikakve informacije o računima takvog
klijenta. Medjutim, bilo kakva informacija o računu MORA biti asocirana jednom
klijentu u tabeli "Klijent"- klijenata.
U svrhu obezbeĎenja egzistencije relacija izmeĎu tabela, svaka tabela MORA
imati i jednu kolonu koja se naziva "Ključ" (indeks tabele, key) koja se koristi kao
jedinstveni (unikatni) identifikator reda odnosno sloga u tabelama. U navedenim
tabelama kolona-ključ se nikada ne moţe duplicirati. U primeru datom primeru to je
kolona "KlijentID" za tabelu "Klijent" odnosno kolona "Broj_Racuna" je ključ za
tabelu "Racuni".

Kako smo ranije napomenuli relacione baze podataka svoje funkcionisanje

zasnivaju na teoriji relacione algebre. Ova algebra se sastoji od formalnih struktura
kao što su skupovi i operatori nad skupovima. Relaciona algebra je formalni sistem za
manipulaciju sa relacijama:
 Operandi ove algebre su relacije
 Operacije ove algebre uključuju uobičajeni skup operacija (jer i same
relacije su skupovi n-torki) a osnovne operacije su:
o selekcija (selection)
o projekcija (projection)
o sastavnica (join)

Za skup operacija nad relacijama, svi operandi moraju imati istu šemu, a
rezultat mora takoĎe imati istu šemu.

34
@ViPserbia

 R1 U R2 (unija skupa R1 i R2) je relacija koja sadrţi sve n-torke koje se

nalaze i u skupu R1 i u skupu R2
 R1 ∩ R2 (presek skupa R1 i R2) je relacija koja sadrţi sve n-torke koje se
pojavljuju samo u R1 i R2 skupovima.
 R1 - R2 (razlika skupova R1 i R2) je relacija koja sadrţi sve n-torke skupa R1,
a koje nisu sadrţane u skupu R2

Selekcija

Selekcija n-torke iz relacije R1 čiji atributi zadovoljavaju kriterijum koji se

izraţava preko predikata P se moţe iskazati kao:
R2 = select(R1,P)

To znači da se iz skupa R1 kreira nova relacija R2 koja sadrţi sve one n-torke
iz R1 koji zadovoljavaju (iskaz je istinit) kriterijum (predikat) P. Predikat moţe biti
bilo koji Bool-ov izraz: "manje od" <, "veće od" >, "jednako ili veće od" >=, "jednako
ili manje od" =<, "jednako" = kao i "nije jednako" !=).

Primer: Treba odabrati personalne računare koji se nalaze u kancelariji za

oznakom 633: select(Radna stanica,Soba="633")

Ime Soba Memorija Procesor Monitor

Popovic 633 1,4GB Pentium IV kolor 19
Pavlov 633 0,5GB Pentium III kolor 15
Jovanov 633 2GB Pentium IV kolor 17

Projekcija

Projekcija je izbor podskupa kolona u relaciji i odbacivanja ostatka kolona.

R2 = project(R1,D1,D2,...Dn)

To znači, da se iz n-torki skupa R1 kreira relacija R2 koja sadrţi samo domene

imena ili konstanti D1,D2,..Dn.

Primer: Iz tabele "Server" treba odabrati kolone "Name"- ime i "Status"

project (Server,Name,Status)

35
@ViPserbia

Ime Status
Asus aktivan
Intel aktivan
Intel neaktivan
Asus aktivan
Asus aktivan

Sastavnica

Sastavnica kombinuje atribute dve relacije u jednu.

R3 = join(R1,D1,R2,D2)

Svakoj relaciji R1 i R2 dodeljuju se domeni D1 i D2 respektivno. Tada se

sastavnica posmatra kao skup svih mogućih parova n-torki ovih dveju relacija i ako su
vrednosti izabranih domena jednaki tada je rezultat n-torka koja sadrţi sve atribute
oba skupa uz izbacivanje duplikata iz domena D2!

Polazeći od ove tri osnovne operacije, u implementaciji se koriste generisane

operacije nad skupovima kao što su:

 sortiranje (sort)
 mešanje (merge)
 kopiranje (copy)
 ubacivanje (insert)
 brisanje/odbacivanje) (delete/remove)
 rad sa indeksima (mogu biti jedinstveni, sa duplikatima, kombinovani
odnosno sloţeni, strani ključevi)
 ugnjeţdene petlje

Krajnji korisnik relacionu bazu podataka vidi kao skup mnogo tabela koje su
povezane sa nekom relacijom:
- tabela je vertikalno izdeljena na "kolone" a horizontalno na "redove"
- n kolona
- m redova
- presek kolone i reda predstavlja "polje"

Primer:

36
@ViPserbia

Zaposleni
Ime i prezime zaposlenog Godina roĎenja Zanimanje
Jovan Jovanović 1961. dipl. ekonomista
…
Petrović Petar 1950. dipl.inţ.elektrotehnike
…
Ţivković Ţivko 1978. auto-mehaničar

Naziv tabele u bazi podataka:

ZAPOSLENI
Ime kolone:
Godina roĎenja
Red:
Petrović Petar 1950. dipl.inţ.elektrotehnike
Polje:
1978.

Da bi se eliminisala redundantnost podataka, posebna oblast pri projektovanju

baze podataka je normalizacija (prva, druga, treća, četvrta i peta) forme podataka.

Pravila normalizacije
Normalizacija je formalizovani postupak za grupisanje atributa podataka u
tabele i tabela u baze podataka. Ciljevi normalizacije sadrţe sledeće:
- Eliminisanje dupliranih informacija u tabelama,
- PrilagoĎavanje budućim izmenama u strukturi tabela,
- Umanjivanje uticaja strukturnih izmena baze podataka na korisničke aplikacije
koje pristupaju podacima.
Proces normalizacije se sprovodi u pet koraka.
Prva normalna forma

Prva normalne forma zahteva da tabele budu ravne i da ne sadrţe duplirane

grupe.

Druga normalna forma

Druga normalna forma zahteva da podaci u svim kolonama koje nisu deo ključa
budu potpuno zavisni od primarnog ključa i svakog elementa primarnog ključa kada
je on sloţeni primarni ključ. Potpuno zavisni znači da je vrednost podataka u svakoj
koloni koja nije deo ključa zapisa, na jedinstven način odreĎena vrednošću primarnog

37
@ViPserbia

ključa. Ova normalna forma uklanja veći deo nepotrebnih (redudantnih) podataka,
kojih verovatno ima u prvoj normalnoj formi.

Treća normalna forma

Zahteva da sve kolone koje nisu deo ključa tabele budu zavisne od primarnog
ključa tabele i nezavisne jedna od druge. Tabele moraju da odgovaraju prvoj i drugoj
normalnoj formi da bi bile sposobne za treću normalnu formu.

Četvrta normalna forma

Zahteva da se nezavisni entiteti podataka ne čuvaju u istoj tabeli kada prema

njima postoje relacije više-prema-više.

Peta normalna forma

Zahteva da mora postojati mogućnost da se tačno rekonstruiše originalna tabela

pomoću tabela u koje je ona rastavljena. Peta normalna forma zahteva da tabele
poštuju pravila treće normalne forme, a kada postoje relacije tipa više-prema-više i
pravilo četvrte normalne forme.

Smatra se da je idejni tvorac koncepta relacione baze podataka koja je danas

najčešće zastupljena E. F. Codd. U nastavku su data osnovna sistematizovana pravila.
Ova sistematizovana pravila, koja je postavio E.F. Codd, su danas implementirana na
osnovu ANSI SQL-99 standarda (sa njegovim pravilima i proširenjima nastalim kao
rezultat prakse).

Karakteristike relacione baze podataka

 Osnovni termini i definicije

- Pojam "baza podataka" ima mnogostruke interpretacije a ovde je
jednostavno to skup odrţivih podataka.
- Relaciona baza podataka je ona u kojoj se podaci sastoje od skupa
tabela u relaciji sa nekom drugom tabelom preko zajedničkih
vrednosti.
- Dve najvaţnije karakteristike relacione baze podataka su: a) podaci su
smešteni u tabelama i b) postojanje relacija meĎu tabelama.
- Tabele se još nazivaju entitetima ili relacijama i to su skupovi redova
i kolona.
- Red (drugačije se još nazivaju slog ili n-torka) reprezentuje konkretan
skup informacija jedne pojave naprimer entiteta "Potrošač"

38
@ViPserbia

- Kolona (drugačije se još nazivaju polje ili atribut) reprezentuje

karakteristike jedne pojave odnosno entiteta naprimer "Ime
potrošača", "Poreski broj obveznika", itd.
- Relacija je logička veza (spojnica) izmeĎu dve tabele.
- Sistem za upravljanje relacionom bazom podataka (RDBMS) koristi
sistem zadovoljavanja kriterijuma za odabir vrednosti iz više tabela.
- Prezentacija podataka kao tabele je logička konstrukcija i ona je u
potpunosti nezavisna od toga gde se podaci fizički nalaze na nekom
mediju (naprimer disku).

 Stanje trţišta u odnosu na relacione baze podataka

- Iako je IBM kompanija prva započela kasnih 70-tih godina realizaciju
Coddovog koncepta, Oracle je prvi objavio komercijalnu relacionu
bazu podataka (1979. godine). Oracle je danas prisutan na trţištu sa
verzijom Oracle 9i, a na pomolu je i noviji model
- IBM je isporučio svoj prvi proizvod "SQL/DS-Data System" tokom
1982. godine
- Microsoft je objavio SQL Server 6.0 tokom 1995. godine
- kasnije su se pojavili i drugi porizvoĎači sa svojim rešenjima kao što
su IBM DB/2, Sybase Sql Server, Informix-SQl, CA Ingres, Centrua
SQLBase, Borlandov Database Engine, Interbase, mySQL (za Unix
platforme), PostgreSQL (za Unix platformu)

 Coddova pravila u teoriji relacione baze podataka:

- relaciona baza podataka je zasnovana na matematičkoj teoriji
relacione algebre
- izvorni koncept modela je izradio dr E.F. Codd 1970. i objavio je taj
model u svom poznatom članku " ‘A Relational Model of Data for
Large Shared Data Banks’
- kasnije, Codd objavljuje za ovaj model 12 pravila poznatih pod
imenom Coddova pravila koja moraju biti zadovoljena da bi se neka
baza podataka posmatrala kao realciona baza podataka
- u praksi se mnogi softveri koji podrţavaju rad sa bazama podataka ne
mogu posmatrati kao relacione baze ako strogo ne zadovoljavaju
ovih 12 pravila
- Pravilo 1: Podaci se prikazuju kao tabele
- Pravilo 2: Podacima se pristupa na logički način (a ne preko fizičkih
adresa zapisa)

39
@ViPserbia

- Pravilo 3: Podaci sa tzv. zapisom "Null" (podatak bez konkretne

vrednosti je zapis u polju tabele ali postoji rezervisan prostor)
posmatraju se kao "nepoznata vrednost"
- Pravilo 4: Baza podataka je samo-opisujuća:
 pored korisnikovih podataka, relaciona baza podataka sadrţi
podatke i o samoj sebi
 postoje dva tipa tabela: korisnikove tabele koje sadrţe radne
podatke i sistemske tabele koje sadrţe podatke o strukturi baze
podataka
 metapodaci su podaci koji opisiju strukturu same baze podataka
uključujući i definicije objekata (tabele, indeksi, memorisane
procedure, paketi, funkcije, itd.) i njihove meĎuveze,
 skup sistemskih tabela se još označava i kao sistemski katalog
ili rečnik podataka
 sistemskim tabelama se pristupa na isti način kao i
korisnikovim podacima
- Pravilo 5: Koristi se samo jedan jezik u komunikaciji sa sistemom za
upravljanje bazama podataka (to je SQL jezik - neproceduralni i
deklarativni koji ima tri podskupa: data modification – modifikacija
podataka (INSERT, DELETE, SELECT, UPDATE), data definition –
definicija podataka (CREATE, DROP, ALTER) i data administration
– administraciju podataka (GRANT, REVOKE, DENY, BACKUP,
RESTORE, ROLLBACK, COMMIT)
- Pravilo 6: ObezbeĎenje alternativnih mogućnosti uvida u podatke
preko "pogleda" (view) (rezultat nije tabela fizički upisana u bazu
podataka nego tabela smeštena u privremeni radni prostor baze
podataka) - virtuelne tabele
- Pravilo 7: podrška relacionim operacijama odnosno operacijama
baziranim na skupovima (union, intersection, division, difference)
- Pravilo 8: Fizička nezavisnost podataka
- Pravilo 9: Logička nezavisnost podataka
- Pravilo 10: Integritet podataka je funkcija baze podataka (koja nije
sastavni deo aplikativnog sistema!)
 konzistentnost i sigurnost podataka
 3 tipa integriteta podataka: entitetni integritet, domenski
integritet i referencijalni integeritet
 deklarativni integirtet podataka preko "ograničenja"
(constraint)
 proceduralni integritet preko samog programskog koda
(memorisane procedure i okidači (trigger))

40
@ViPserbia

- Pravilo 11: Podrška distribuiranim operacijama

 podaci mogu biti smešteni centralno ili distribuirano
 moguće su sastavnice mešanjem podataka iz tabela smeštenih
na raznim serverima (distribuirani upiti) ili iz raznih relacionih
baza podataka (heterogeni upiti)
 integritet podataka mora biti očuvan bez obzira na broj kopija
podataka (replication)
 fizičke veze se realizuju preko takozvanih linkova baze
podataka
- Pravilo 12: Integritet podataka ne moţe biti srušen ni pod kakvim
okolnostima!

41
@ViPserbia

3.1. Programsko okruženje za upravljanje podacima

Podaci se organizuju za potrebe nekog korisnika. Razvoj informatičke

tehnologije ide u smeru da ponuĎač softvera u okviru svog sistema za upravljanje
bazama podataka nudi komponente koje omogućavaju korisniku da na efikasan i
svrsishodan način doĎe do podataka potrebnih za poslovanje. Na sledećoj šemi je dat
prikaz osnovne strukture svakog sistema za upravljanje podacima.

 Obuka - Edukacija
Da bi bilo koji sistem za upravljanje podacima mogao da se napravi,
neophodna je obuka osoblja za upotrebu takvog sistema.

KORISNIK

SISTEM ZA UPRAVLJANJE
BAZOM PODATAKA

Edukacija Pretraţivanje i Programski Aplikativni Baza Usluţni

aţuriranje jezik sistem podataka programi

 Pretraţivanje i aţuriranje podataka:

Svaki sistem za upravljanje podataka mora imati ugraĎene efikasne
mehanizme za:
- upisivanje novog podatka (insert)
- aţuriranje postojećeg podatka (update)
- za pronalaţenje (za upit) podatka (select)
- za brisanje nepotrebnog podatka (delete)
Kod brisanja postoje dve mogućnosti:
 postojanje referencijalnog integriteta podataka
 nepostojanje referencijalnog integriteta podataka

42
@ViPserbia

 Programski jezik
Programski jezik treba da omogući korisniku da model poslovnih funkcija
transformiše u program koji će sa svojim interfejsom (preko aplikativnih
sistema) omogućiti korisniku pristup podacima.
Danas je na trţištu prisutno nekoliko standardnih programskih jezika:
- C (sa svojim dijalektima) (kompajlerskog tipa)
- Borlandov Delphi ko (kompajlerskog tipa)
- Microsoftov VisualBasic (pseudointerpretativnog i/ili
kompajlerskog topa)
- COBOL sa preprocesorima za pristup podacima
(kompajlerskog tipa)
- ADA (kompajlerskog tipa)
- Java (pseudointerpretatorskog tipa)
- XML (Extented Mark-Up Language) (nije programski jezik u
pravom smislu ali omogućava upravljanje interfejsima za
obuhva podataka)
- SQL (Structured Query Language) (nije pravi programski
jezik)
- i niz specifičnih drugih jezika

 Aplikativni sistemi
o Aplikativni sistemi su programske celine napravljene po meri
korisnika a na osnovu prihvaćenog glavnog odnosno izvoĎačkog
projekta informacionog podsistema.
o Aplikativni sistemi se realizuju sa konkretnim programskim jezikom
primenjenim nad konkretnom fizičkom i logičkom bazom podataka.

 Baza podataka
o Sistem za kreiranje fizičke organizacije baze podataka za smeštaj
podataka (fizička organizacija podataka)
o Sistem za kreiranje logičke organizacije baze podataka (tabele,
relacije, indeksi)
o Sistem za administraciju i nadzor logičke organizacije podataka
o Skup alata za projektante baze podataka:
- Rečnik podataka
- Dijagrami za kontrolu projekata (upravljanje vremenom
realizacije projekata)
- Dijagrami poslovnih funkcija
- Dijagrami poslovnih procesa

43
@ViPserbia

- Dijagrami matrice proces-funkcija

- Dijagrami entiteti-relacije
- Dijagrami modula
- Dijagrami toka dokumenata
- Dijagrami obrada
- ...
o Sistem za dinamički oporavak baze podataka u slučaju neuspešno
izvedene transakcije (rollback i forward recovery procedure)
o Sistem za ţurnaliziranje

 Usluţni programi sluţe za administraciju

o Sistem za instalaciju softvera za upravljanje bazama podataka
o Sistem odrţavanja "zakrpa" u softveru (patches)
o Sistem nadzora rada i podešavanja performantnosti
o Pristup i sigurnost pristupa (korisnički nalozi i lozinke)
o Praćenje povrede pristupa preko "audit" sistema
o Sistem za brza pretraţivanja (QBE-QueryByExample) od strane
krajnjeg korisnika
o Arhiviranje, zaštita i oporavak podataka
- dnevno, mesečno ili periodično arhiviranje
- trajna arhiviranja
- procedure za oporavak

44
@ViPserbia

3.2. Projektovanje aplikativnih rešenja primenom relacionih baza podataka

Slobodno se moţe reći da se moderna obrada podataka zasniva na dva osnovna

koncepta:
1. na konceptu baze podataka kao jedinstvenog skladišta svih informacija
potrebnih za opis jednog realnog sistema, iz koga svaki korisnik moţe da
izvuče one informacije koje su mu potrebne, i
2. na konceptu sistema za upravljanje bazom podataka kao sloţenog softverskog
proizvoda, čiji je cilj da korisniku omogući lako i brzo rukovanje potrebnim
podacima. Korisnici se pri tome ne opterećuju detaljima vezanim za fizičku
organizaciju, zaštitu, obezbeĎenje konkurentnosti i druge sloţene
administrativne poslovima.

Svi sistemi za upravljanje bazama podataka omogućavaju:

1. unošenje podataka,
2. ureĎivanje podataka,
3. pregled podataka i
4. štampanje podataka i informacija koje su sadržane u više tabela
podeljenih po redovima i kolonama.

Tri osnovne principijelne karakteristike izdvajaju sistem za upravljanje

relacionom bazom podataka – RDBMS (Relational Database Management System)
od aplikacija sa primenom radnih tabela:
1. Svi RDBMS su projektovani da efikasno rade sa veoma velikom količinom
podataka;
2. RDBMS lako povezuju dve ili više tabela, tako da korisnicima deluje kao da je
to jedna tabela
3. RDBMS minimizuju dupliranje informacija
U osnovi sam postupak projektovanja sistema relacione baze podataka se
sastoji od 10 osnovnih koraka a to su:
1. Identifikacija objekata koje sistem baze podataka predstavlja;
2. Otkrivanje veza izmeĎu objekata (ukoliko postoji više objekata);
3. OdreĎivanje značajnih svojstava i ponašanja objekata;
4. Ustanovljavanje kako svojstva objekata utiču jedna na druge;

45
@ViPserbia

5. Izrada uvodnog rečnika podataka koji bi pomogao u definiciji tabela koje čine
osnovu baze podataka;
6. OdreĎivanje relacija izmeĎu tabela baze podataka na osnovu veza izmeĎu
objekata koje se nalaze u njima i ove informacije svakako treba uključiti u
rečnik podataka;
7. Uspostavljanje tipova aţuriranja i transakcija koje prave i menjaju podatke u
tabelama uključujući i sve neophodne zahteve u vezi sa integritetom podataka;
8. OdreĎivanje načina korišćenja indeksa kako bi se ubrzalo kreiranje upita, s tim
da se izrazito ne uspori dodavanje podataka u tabele ili da se dodatno ne
zauzme veliki prostor na disku;
9. ObezbeĎivanje zaštite podataka – odreĎivanje ko moţe da pristupi i menja
podatke u svakoj tabeli i da promeni strukturu tabela;
10.Dokumentovanje dizajna baze podataka kao jedne celine, pisanje procedura za
odrţavanje baze podataka uključujući i one za izradu rezervne kopije datoteke i
restauraciju.
Posebno treba imati na umu da u postupku projektovanja svaki korak zavisi od
prethodnog.
Kao što je već pomenuto teorija projektovanja relacione baze podataka
utemeljena je na grani matematike koja se naziva Teorija skupova, zajedno sa velikim
udelom kombinatorike i nešto malo statističke metodologije. Skup pravila i simbola
pomoću kojih se relacione baze podataka definišu naziva se relaciona algebra.

3.3 Projektovanje baze podataka

Projektovanje baze podataka obuhvata sve aktivnosti počevši od definisanja

svih zahteva od strane korisnika buduće baze pa do kompletne izrade i provere baze.
Na osnovu definisanih zahteva korisnika i odabira ţeljenog alata, mora se izvršiti
logičko oblikovanje baze kao i definisanje i opis svih podataka i odnosa izmeĎu
podataka u bazi. Zatim sledi dizajniranje baze, a to podrazumeva da se moraju

46
@ViPserbia

definisati logički modeli podataka i kako će ti podaci biti smešteni na računarskoj

opremi (lokalno ili distribuirano), a zatim da li će biti korišćeni u mreţnom radu ili
lokalnom
Prilikom projektovanja baze mora se poći od realnog sistema za koji se
projektuje baza. Potrebno je izvršiti adekvatnu analizu tog sistema, definisati
hijerarhiju tokova, a zatim i definisati tokove podataka od ulaznih do izlaznih. Pri
tome se uvek moraju imati na umu zahtevi korisnika i celokupan rad i primenu baze
prilagoditi tim zahtevima. Za većinu korisnika je potrebno obezbediti takvu bazu koja
će omogućiti da se unesu raspoloţivi podaci uz mogućnost redovnog aţuriranja tih
podataka i da se omogući da se ti podaci mogu pretraţivati po odreĎenim
kriterijumima definisanim od strane samih korisnika.
Pored toga je potrebno da korisnici mogu selektovane podatke dobijene
pretraţivanjem videti na ekranu u ţeljenim formama koje se često razlikuju od
korisnika do korisnika, kao i da ti podaci mogu biti sačuvani ili pak odštampani po
ţelji korisnika. Kriterijumi po kojima se moţe vršiti pretraţivanje će svakako zavisiti
od vrste podataka u bazi, od samih korisnika kao i od specifičnosti pojedinih poslova
za koje se baza koristi.

3.4 Projektovanje relacione baze podataka

Projektovanje informacionih sistema svodi se na sledeće:

- donošenje odluke o projektovanju informacionog sistema realizovanog uz
pomoć informatičke tehnologije,
- konstituisanje projektnog tima,
- analiza poslovnih procesa i funkcija:
o izrada idejnog, glavnog i izvoĎačkog projekta,
o snimanje toka dokumentacije (ulazna i izlazna dokumenta poslovnog
procesa),
o intervjuisanje profesionalaca-učesnika u poslovnom procesu koji
opisuje tehnologiju rada u njegovom domenu,
o planiranje rokova okončanja projekata,
o verifikacija i usvajanje idejnog, glavnog i izvoĎačkog projekta
- dizajn poslovnih procesa i funkcija,
- realizacija i implementacija
- izrada uputstava za rad i obuka
- eksplaotacija
- usavršavanje(otklanjanje grešaka, podešavanje performansi)

47
@ViPserbia

Informacioni sistem je model realnog sistema u kome deluje pa se postupak

projektovanja informacionog sistema svodi na neku vrstu modeliranja realnog
sistema. Za modeliranje su nam neophodni alati:
- modeli podataka: sluţe kao sredstvo za prikazivanje objekata realnog
sistema, njihovih atributa i njihovih meĎusobnih veza preko tzv. logičke
organizacije baze podataka. Modeli podataka daju statičke karakteristike
sistema, a
- modeli procesa: sluţe kao sredstvo za opisivanje dinamike sistema, dejstva
ulaza na stanje sistema i izlazne transformacije, preko programa nad
definisanim modelom podataka.

Modeli podataka i modeli procesa podleţu apstrakcijama. Modeli podataka sa

aspekta apstrakcije se kreiraju po principima:
- Klasifikacija (tipizacija) i uzorkovanje tako da se skup sličnih objekata u
realnom sistemu predstavlja jednom klasom objekata. Na primer skup {Ana,
Petar, Zoran, Dušan, Maja} čine klasu STUDENT. Odnosno, svaki objekat
iz ovog posmatranog skupa je tip objekta STUDENT
- Generalizacija i specijalizacija: To je apstrakcija u kojoj se skup sličnih
tipova objekata predstavlja opštijim generičkim tipom. Pod sličnim tipom
obejkata ovde se misli na tipove objekata koji imaju jedan broj zajedničkih
(istih) atributa sa drugim objektima operacijama. Na primer, skup tipova
objekata {Student, Radnik, Dete, Penzioner} mogu se generalizovati u tip
objekta GRAĐANIN. Inverzni postupak generalizaciji je specijalizacija. Tip
objekta GRADJANIN se specijalizuje u podtipove STUDENT, RADNIK,
DETE i PENZIONER.
- Agregacija i dekompozicija: Agregacija je apstrakcija u kojoj se skup tipova
objekata i njihovih veza tretira kao jedinstveni agregirani tip objekta. Na
primer, tipovi objekata Student, Predmet, Profesor se agregiraju u tip
objekta Prijava čiji atributi su na primer "Ocena" i "Datum_polaganja".
Postupak inverzan agreagciji je dekompozicija. Sam objekat se u sistemu
moţe tretirati kao najniţi nivo asptrakcije, kao agregacija njegovih atributa.

Modeli podataka se primenjuju u svim fazama razvoja informacionog sistema:

- u fazi planiranja razvoja (idejni projekat) definiše se globalni model
podataka koristeći odgovarajuće generičke modele i grubo date podmodele
za pojedine osnovne funkcije sistema. Ovaj model sadrţi samo najznačajnije
objekte i veze i samo osnovne atribute objekata, koji su neophodni da bi
definicija objekata i veza bila sjajna.
- u fazi detaljne specifikacije zahteva razraĎuju se detaljni podmodeli za sve
obuhvaćene podsisteme i funkcije u njima i oni se integrišu u jedinstveni

48
@ViPserbia

model podataka sistema. Ovde se definišu svi atributi objekata i sva pravila
integriteta podataka.
- u fazi projektovanja i implementacije sistema, model podataka je osnova za
projektovanje baze podataka i aplikacije. Iz modela objekti-veze se
formalno i automatizovano (uz pomoć softverskih alata) mogu definisati
logička struktura baze podataka i programi za odrţavanje baze podataka.
- u fazi operativnog rada sistema, model podataka implementiran kao rečnik
baze podataka je osnova za odrţavanje sistema (izmene koje se zahtevaju).

Ova objašnjenja idu ka tome da se danas sistematizuju postupci projektovanja

relacione baze podataka. Većina današnjih softverskih alata namenjenih projektovanju
relacionih baza podataka sadrţe komponente koje omogućavaju brzo i efikasno
(ispravno) generisanje programa za odrţavanje baze podataka:

 Konceptualni model funkcija

Suština ovog koraka je da se ispitaju, utvrde, pronaĎu informacije o
poslovnim funkcijama tokom analize:
- poslovne funkcije
o hijerarhija poslovnih funkcija
o dekompozicija do nivoa elementarnih funkcija
o detalji o funkcijama kao što su učestalost pojave, odgovor na
funkciju, ko je "roditelj" funkcije, da li je funkcija zajednička sa još
nekom ili ne, ko okida – aktivira obavljanje funkcije
o definisanje entiteta i atributa (korišćenje entiteta se obavlja npr. preko
SQL jezika: Create, Retrieve, Update, Delete i Archive a korišćenje
atributa moţe da se obavlja npr. preko SQL jezika: Insert, Retrieve,
Update, Nullify, Archive i druge
o definisanje ulaza i izlaza funkcije
o učestalost korišćenja funkcije
- model matrice.

 Implementacija funkcija
Poslovne funkcije se transformišu u programske module pa se poslovne
funkcije implementiraju kao:
- forme za obuhvat podataka (obrasci, maske,...) na ekranu terminala,
- izveštaji koji se mogu štampati ili ne,
- zasebne programske jedinice kojima se obraĎuju podaci (sprovodi se proces
vezan za konkretnu pojavu funkcije) ili
- uputstva za obavljanje funkcije.

49
@ViPserbia

Osnovna suština projektovanja relacionih baza podataka jeste da se preko

modela kroz prototip doĎe do relacija izmeĎu varijabila funkcija i da se to pretoči u
programske module.

Smatra se da današnji alati za projektovanje relacionih baza podataka treba da

imaju sledeće softverske komponente:
- upravljanje projektima (project management),
- izrada dijagrama procesa,
- izrada modela entiteta i relacija,
- izrada dijagrama funkcija,
- izrada dijagrama toka podataka i
- izrada matričnog dijagrama.

3.5 Izrada dijagrama procesa

Kod izrade dijagrama procesa najčešće se koristi opisivanje rečima. Pored toga,
navodi se startna tačka procesa (okidač) i finalni proizvod procesa (rezultat),

Primer:
Dijagram baznog (osnovnog) procesa ima nekoliko komponenti:
- korake procesa (svaka aktivnost unutar baznog procesa); diskretan "komadić
- delić" posla koji se obavlja,
- prenošenja kontrola unutar procesa iskazanih kao koraci (tok procesa),
- gde se smeštaju materijali ili podaci ("magacin-skladište") sa periodom
vremena,
- identifikacija i definisanje dogaĎaja (okidači i rezulati procesa),
- definisanje i opis organizacione jedinice u čijoj je nadleţnosti proces
- kreiranje sirove verzije modela i
- verifikacija modela procesa.

Polja u tabeli se koriste za smeštanje jedinica informacija. Imena pojedinih

polja mogu sadrţavati slova engleskog alfabeta, brojeve i donju crticu (_) i ne
mogu sadrţavati prazna mesta. Polja mogu biti znakovna, numerička,
datumska, logička ili MEMO polja.

Dakle, sa odgovarajućim skupom simbola koje nudi konkretan alat opisuje se

proces. Često konkretni alati nude i mogućnost korišćenja video i audio zapisa o
procesu, animacije itd. tako da se u nekom vremenu na ovaj način obavlja
sistematično opisivanje realnog sistema koje predstavlja tekuće i buduće znanje o
poslovnom sistemu.

50
@ViPserbia

"Da"
DogaĎaj Uslov? Tok
"Ne"

Sačini Korak "x"

Izveštaj procesa "a"

Organizaciona
jedinica "i"

Magacin

Kako ovakav model za izradu dijagrama procesa nije dovoljan onda se ide na
izradu dijagrama funkcija.

3.6 Izrada dijagrama funkcija

Poslovna funkcija je nešto što radi posao ili što treba da se uradi, odnosno,
identifikuje se, definiše i opisuje misija i ciljevi posla. Jedan proces moţe imati na
stotine a ponekad i na hiljade funkcija (npr. proizvodnja aviona).

Poslovne funkcije se dekomponuju u iterativnom postupku da bi se dobila

hijerarhija funkcija. Za svaki nivo hijerarhije koja je strukture stabla ("koren" 
"roditelj"  "dete") obavlja se detaljno specificiranje funkcije. U opisu funkcije
navode se strateški nivo, portfelji, ključni indikatori za performanse, kritični faktori
uspešnosti funkcije. Dakle, u postupku dekompozicije funkcije:
- prikupljaju se informacije o funkciji,
- pravi se spisak kandidata za funkciju,
- pronalazi se funkcija koja je "na vrhu",
- u iterativnom postupku se dekomponuje funkcija do elementarnog nivoa
(atomskog nivoa).
Sa odreĎenim skupom grafičkih simbola i operacija mogu se definisati u
rečniku relacione baze podataka dijagrami funkcija.

51
@ViPserbia

Primer:

ADMIN (naziv - mnemonik funkcije)

Podrţati upravljanje proizvodnjom
i klijente-korisnike proizvoda

***
ADM1
Obraditi i promovisati proizvode na
zalihama i pruţiti usluge klijentima

ADM2
Kontrolisati zalihe proizvoda

***
ADM3
Identifikovati akcije prema nelikvidnim
klijentima

ADM4
Arhivirati transakcije

*** - nastavak dekompozicije funkcija

Kućica za ADM4 funkciju označava da se radi o "opštoj, zajedničkoj" funkciji.

Na kraju moţemo reći da detaljna analiza funkcija obuhvata:

- referenciranje funkcije u modelu (ADMi, i=1,2,3,..),
- definisanje funkcije (kao glagol, jasno i nedvosmisleno uz upotrebu imena
koja ukazuju na entitete i relacije: proizvod, klijent, ...),
- opis funkcije (detaljni tekstualni opis funkcije koji se ne stavlja na dijagram
već je deo rečnika baze podataka, a u tom opisu se navode pravila izvoĎenja
funkcija: sekvencijalna, iterativna, uslovljena, ...). Potrebno je navesti i
dokumentaciju na kojoj se bazira funkcija (interni akt poslovne organizacije,
zakonski akt, ...). Potrebno je navesti i mehanizme kako se funkcija menja,
- učestalost (treba proceniti koliko često se funkcija izvodi u nekom periodu
vremena a ako je potrebno, navesti u kojoj organizacionoj jedinici se
obavlja),
- potreban odgovor (identifikovati traţene odgovore na informacioni zahtev i
kada se traţe: tokom dana, tokom noći, u jednom trenutku npr. u 13 sati,...).

52
@ViPserbia

Pored toga navodi se da li je funkcija "u realnom vremenu" (on-line) ili se

realizuje u tzv. "paketnom radu" (batch),
- unakrsna referenca upotrebe funkcije (navodi se spisak svih organizacionih
jedinica gde se koristi opisana funkcija),
- dogaĎaji (šta okida-aktivira početak funkcije i da li funkcija kada se završi
okida start neke druge funkcije).

3.7 Izrada dijagrama toka podataka

Ovaj dijagram omogućava više-nivooski (višeslojni) pogled na domen

poslovanja pri čemu se prikazuju aktivnosti i podaci zajedno sa tokom kolanja
podataka izmeĎu aktivnosti. Dakle, dijagram toka podataka iskazuje model toka
podataka tj. kako informacije kruţe u poslovanju. Ovaj model takoĎe podleţe
dekompoziciji i uspostavljanju komunikacije izmeĎu pojedinih aktivnosti.

Primer mogućih grafičkih simbola:

Poslovna funkcija:
1 "Rent-a-car" Aktivnost "Rent-a-car" koja transformiše
podatke unutar poslovanja
Uradi procenu najma
automobila i procenu
prihoda preduzeću

Tok podataka:

ime-klijenta Strelica pokazuje smer kretanja podataka unutar

poslovanja i njenog ambijenta

Izvor/Cilj podataka:

KLIJENT Izvor podataka ili cilj podataka koji se nalazi

izvan poslovanja (to moţe biti neka druga
funkcija, neki drugi realni svet, neki drugi
objekat)

Memorija za podatke:

D1 POTROŠAČ Podaci koje poslovanje čuva za buduću

upotrebu

53
@ViPserbia

Primer:

KLIJENT "zahtevam..." KATALOG

"odgovaram..." "gledam..."
1 "Rent-a-car"
"dovozim auto.." "zahtevam..."

VOZILO "trebujem..." "generišem..." RAČUN

3.8 Izrada matričnog dijagrama

Matrica ranga 2 je matrica kojom se poslovne funkcije preslikavaju (mapiraju)

na entitete. Tamo gde se pojavljuje ukrštanje reda "poslovna funkcija" i kolone
"entitet" tu imamo postojanje "relacije". Na taj način se veoma brzo dobija uvid u to
šta treba da proglasimo entitetima u smislu relacionog modela (u fizičkoj
implementaciji to su tabele).
Detaljnije govoreći, prisutne su dve matrice: matrica "funkcija/entitet" i matrica
"funkcija/atribut".
U svakoj ćeliji matrice "funkcija/entitet" navodi se akcija (C-create, R-retrieve,
U-update, D-delete i/ili A-arhive). Na primer:
Entitet Stavka Klijent Zaposleni
najma
Elementarna
funkcija
RENTA2 CRUD CRUD R
RENTA3 RU RU
RENTA3.1 R

U svakoj ćeliji matrice "funkcija/atribut" navodi se akcija nad atributom (I-

insert, R-retrieve, U-update, N-nullify i/ili A-arhive). Na primer:
Atribut "Stavka najma" "Stavka najma" "Stavka najma"
Redni broj stavke Period najma Dnevni trošak
Elementarna
funkcija
RENTA2 IR IRU IRUN
RENTA3 R R RU
RENTA3.1

54
@ViPserbia

U zavisnosti od proizvoĎača softvera mogući su i drugi tipovi matrica. Na

primer,
- matrica "funkcija/korisnikova uloga-rola",
- matrica "funkcija/organizaciona jedinica",
- matrica "organizaciona jedinica/entitet",
- ...

3.9. Izrada dijagrama entiteta i relacija

Ovo je najvaţniji deo projektovanja relacionih baza podataka jer preko

ovakvog modela se obavlja povezivanje logičke i fizičke organizacije baze podataka.
Komponente dijagrama su:
- entitet
- relacija
- atribut i
- jedinstveni identifikator entiteta (indeksi, ključevi,...)

Entitet je stvar, predmet sa nekim značajem, koja opisuje suštinu odnosno ono
što moramo znati o toj stvari, odnosno mesto gde čuvamo informaciju o toj stvari.
Primer: "Student", "Predmet", "Knjiga".

Svaki entitet ima svoj skup identifikacija kojim se on opisuje (atributi).

Identifikuju se samo atributi od značaja a ne svi mogući atributi entiteta.

IzmeĎu entiteta se uspostavljaju asocijacije (relacije) tako da je relacija jedan

ureĎen par i svaki kraj relacije se imenuje:
- "Student" sluša "Predmet"
- "Predmet" koristi "Knjigu"
- "Knjigu" je uzeo "Student"
- "Predmet" slušaju "Studenti"

Relacija moţe biti opcionalna (pod nekim uslovima se moţe pojaviti). Relacija
u smislu skupova ima svoju kardinalnost (broj elementa skupa): 1:1; 1:M ili M:M
(M=mnogo).

Da bi se jedna pojava nekog entiteta razlikovala od druge, uvodi se jedinstveni

identifikator. Za identifikatore se koristi:
- jedan atribut ili grupa atributa,
- jedna ili više relacija i/ili

55
@ViPserbia

- kombinacija atributa i relacija.

Primer:

VIDEO KASETA KORISNIK

- # Identifikator kasete - # Identifikator korisnika
- Naslov - Prezime i ime
- Trajanje - Adresa (mesto, ulica i kućni broj)
- Opis - Telefon
- Starosna klasifikacija
- Cena
- Status:"Zauzeto"/"Slobodno"
- Reţiser
- Godina snimanja
- Tip filma:Akcioni/Horor/...

Entiteti: VIDEO KASETA i KORISNIK

Atributi: Video_Kaseta.Naslov, Korisnik.Telefon, ...
Relacija: "1:M": Jedan KORISNIK moţe da iznajmi jednu ili više "VIDEO
KASETA".

56
@ViPserbia

4. Elementi relacionih baza podataka

Relaciona baza podataka, a posebno ona koja se razvija u Accessu u osnovi
moţe da se sastoji od sledećih elemenata: tabele, upiti, maske i izveštaji; a moţe
sadrţati: Data Access strane, makroe i/ili VBA module (Visual Basic for Application
- programski jezik za programiranje operacija u Office aplikacijama).U principu
moţemo reći da u osnovne elemente novijih baza podataka spadaju radne tabele, upiti,
formulari i izveštaji, a u osnovne aktivnosti koje se izvršavaju kod korišćenja baze
spadaju aţuriranje - odrţavanje baze podataka koje obuhvata unos novih podataka,
izmenu ili brisanje postojećih podataka, zatim pretraţivanje baze podataka koje
obuhvata pretraţivanje po definisanim kriterijumima.

Pored toga obezbeĎuje se i dobijanje različitih pregleda podataka na ekranu kao

i mogućnost štampanja odgovarajućih izveštaja ili pak arhiviranja na nekom od
medija za kasniju upotrebu ili za neke druge namene. Pri tome treba imati na umu da
je skup podataka u bazi kao i njihove meĎusobne veze u stvari slika stanja nekog
realnog sistema u datom trenutku i da verovatno sadrţi odreĎene informacije o
prošlosti, sadašnjosti i budućnosti tog sistema.

Kao što je već rečeno baza podataka se moţe definisati i kao skup
odgovarajućih entiteta koji odgovaraju stvarnim elementima, dogaĎajima ili
konceptima realnog sistema za koji je baza načinjena. Ovi entiteti su u bazi povezani
odreĎenim meĎusobnim vezama. Entiteti i veze izmeĎu njih su opisani takozvanim
atributima. Veoma je vaţno kako su definisani modeli podataka u bazi jer oni imaju
veoma vaţnu ulogu u svim fazama baze, počev od analize zahteva korisnika pa do
kreiranja baze, puštanaja u rad do redovne primene baze u praksi.
U praksi je kao što smo pomenuliu drugom poglavlju tokom primene raznih
vrsta skupova podataka i njihovih meĎusobnih veza bio prisutan i veliki broj različitih
tehnika modeliranja podataka. Dok je klasični pristup koji se odnosio na kreiranje
klasičnih datoteka podataka bio više vezan za načine obrade koji su se primenjivali
nad tim podacima, a manje na same podatke, noviji model podataka koji je omogućio
mnogo bolju i efikasniju realizaciju baza podataka je zasnovan na primeni relacija tj.
veza izmeĎu entiteta i to je takozvani Entity – relationship model. Primenom ovakvog
modela je obezbeĎen mnogo veći stepen nezavisnosti podataka od programa koji ih
koriste tj. omogućeno je, da kada korisnik ima formiran skup podatka na takav način,
da posle moţe na tim podacima graditi veoma različite aplikacije i praviti veoma
različita programska rešenja.

57
@ViPserbia

Pored entiteta i veza meĎu njima kao elementi baze se pojavljuju i atributi koji
im se pojedinačno dodeljuju. Oni zajedno čine osnovni koncept modela entitet-veza.
Pre svega definišimo entitet – to je jedan od objekata nekog realnog sistema koji se
preko njega mogu lako definisati i identifikovati. Veza izmeĎu entiteta je ono što u
stvari povezuje jedan entitet sa drugim u pojmovnom ili funkcionalnom smislu. Veze
mogu biti parcijalne pojedinačne ili sveukupne odnosno totalne. Veza je totalna ako
svaki entitet tog tipa ima bar po jednu vezu , a ako nema tada je veza parcijalna. Što
se tiče atributa oni označavaju neke od karakterističnih odlika entiteta ili veze.
Nadalje veoma je vaţno i ovom prilikom napomenuti da izmeĎu entiteta mogu
postojati različiti stepeni veza tako na primer postoji veze tipa 1:1 – jedan prema
jedan, zatim 1: N – jedan prema više i N : N – više prema više kada se entitetu jednog
tipa pridruţuje više entiteta drugog tipa i obrnuto. Jednom definisane relacije postaju
osnova za realizaciju same baze. Da bi se definisani model podataka mogao
realizovati u formi realne baze neophodno je da se definišu relacije izmeĎu podataka
koji su prisutni u sistemu. Zatim je potrebno te podatke grupisati u odreĎene logičke
celine. Prilikom prevoĎenja modela entiteta i veza u relacije tj. prevoĎenja u relacioni
model potrebno je da se vodi računa o sledećim osnovnim pravilima:

a) Svi entiteti koji su definisani u modelu podataka će postati relacije, a

atributi entiteta će postati ujedno i atributi relacija dok će identifikator
entiteta postati primarni ključ relacije.
b) Entitet podtip će postati relacija, a njegovi atributi će postati atributi
relacije dok će primarni ključ relacije će postati identifikator nadreĎenog
entiteta.
c) Veza izmeĎu entiteta podtipa i nadreĎenog entiteta neće postati posebna
relacija.

Postoje i druga pravila koja se odnose na različite stepene relacija i koja se

moraju primenjivati u zavisnosti od stepena relacije.
Jednom definisani model podataka se moţe koristiti za razne primene i u
različitim sredinama. Moţe se desiti da se za neku primenu definisani model podataka
mora proširiti novim entitetima i novim vezama izmeĎu entiteta. Tada će se nakon
izvršene analize i utvrĎivanja novih entiteta i veza morati definisati i odgovarajući
atributi, a model podataka će dobiti odgovarajuću novu varijantu koja će se
nesmetano moći koristiti i u novom aplikativnom okruţenju.
Kod razvoja aplikacija vezanih za odreĎenu bazu podataka potrebno je izvesti
odgovarajuće aktivnosti počevši od realizacije same baze podataka na nekoj
računarskoj osnovi do programiranja i testiranja načinjenih programa. Definisani
modeli podataka i relacija predstavljaju dobru osnovu za izradu aplikacije. Realizacija
aplikacije predstavlja skup programa i procedura kojima se generišu informacije koje

58
@ViPserbia

korisnici ţele i kojima se aţurira baza podataka. Kao prvo javlja se zahtev da se kreira
ţeljeni skup podataka i da se on i fizički realizira na računarskoj podlozi. Kod novijih
baza podataka ovaj postupak se svodi na kreiranje odgovarajućih tabela podataka.

4.1. Tabele – tables

Radi lakšeg razumevanja moţe se reći da tabele odgovaraju datotekama u
klasičnim aplikacijama i u njima se čuvaju podaci date baze. Svaka tabela se sastoji
od kolona i redova, dok se presek kolone i reda naziva polje. Polja u tabeli se koriste
za smeštanje jedinica informacija. Imena pojedinih polja mogu sadrţavati slova
engleskog alfabeta, brojeve i donju crticu (_) i ne mogu sadrţavati prazna mesta. Polja
mogu biti znakovna, numerička, datumska, logička ili MEMO polja. Pojedino polje
moţe dakle biti sledećeg tipa: tekst, broj, datum/vreme, logičko polje, memo polje
(polje u koga se moţe uneti tekst proizvoljne veličine do cca 65 K), polje za unos
brojeva u novčanom formatu, posebno polje u kome se automatski po započetom
unosu sloga inkrementira broj (polje AutoNumber), hiperlink polje (pokazivač na
adresu na Internetu), OLE objekt polje (polje sa objektom povezanim iz drugog
programa) i Look Up polje (polje čiji prikazani sadrţaj se nalazi u drugoj tabeli).

Znakovna polja mogu sadrţati bilo koji znak sa tastature, dok numerička polja
sadrţe samo numeričke vrednosti, znakove + i – kao i decimalnu tačku. Datumska
polja sadrţe datum. Kod većine baza je obezbeĎena automatska kontrola datuma.
Logička polja sadrţe elemente Bulove algebre tj. logičko Da (T-True-istina) , logičko
Ne (F- False – laţ), Y- yes – da, N – no- ne. Što se tiče MEMO polja ona su
predviĎena da se u njih mogu smestiti tekstualne informacije.
Što se tiče vrednosti memorijskih podataka oni mogu biti konstante i biće u tom
slučaju posmatrane kao da su slova, a mogu biti karakteri, numerici ili pak prazna
polja. Pored toga vrednosti memorijskih podataka mogu biti i promenljive i sluţe
kako za smeštanje polaznih podataka tako i za smeštanje meĎurezultata. Pored toga
memorijske promenljive se mogu definisati i kao nizovi koji sadrţe odgovarajući broj
elemenata. Za davanje naredbi za izvoĎenje odgovarajućih operacija nad podacima
koriste se odgovarajući simboli koji se nazivaju operatori i preko njih se definišu
odgovarajuće operacije koje će se izvoditi kao naprimer sabiranje, oduzimanje,
mnoţenje, deljenje itd.Operatori mogu biti aritmetički, logički, string kao i relacioni
operatori.

Pri kreiranju baze podataka veoma je bitno dobro definisati tip polja, jer su
brzina rada, organizovanost podataka i veličina same baze u direknoj vezi sa ispravno
definisanim tipom polja. Naprimer za datum tipa 01/05/2004 tip polja ćemo postaviti
na Date/Time (datum/vreme); za isključivo numeričke vrednosti postavljamo tip polja

59
@ViPserbia

na Number; za kombinovani alfanumerički unos tip polja postavljamo na Text kod

koga se predviĎa maksimalni broj karaktera u unosu, itd.

Slika 4.1 Primer jedne tabele u Accessu

Baza podataka moţe da sadrţi više tabela koje se preko relacija meĎusobno
povezuju. Npr. čitaoce ćemo drţati u jednoj tabeli, knjige u drugoj, a
iznajmljivanja/vraćanja knjiga u trećoj. Relacije se uspostavljaju samo meĎu
istovetnim podacima, a najčešće izmeĎu šifara (npr. šifru čitalaca u tabeli
čitaoci_osnovni_podaci i šifru čitalaca u tabeli izdavanje_knjiga valja meĎusobno
povezati relacijom jedan prema više - jedan čitalac moţe uzeti više knjiga, ali se jedna
knjiga ne moţe nalaziti kod više čitalaca istovremeno). Na ovaj način se izbegava
višestruki unos podataka za čitaoca pri svakoj njegovoj poseti biblioteci, a mogućnost
grešaka pri unosu adrese ili naziva čitaoca je praktično anulirana.

4.2 Formulari – forms - ekranske forme maske za unos podataka ili za

ažuriranje podataka

Mnogi dobro uraĎeni programski paketi, koji se odnose na baze podataka, neće
vredeti mnogo za korisnike ako su ekranske forme i meniji za rad sa bazom loše
dizajnirani odnosno ako ih je teško koristiti u svakodnevnom radu. Kada je dobro
organizovan i dizajniran sistem menija on značajno olakšava korisniku rad sa bazom.
Nekada je (sa ranijim bazama) tj. kod klasičnog programiranja sistema menija izmena
u nekom delu povlačila za sobom izmenu celog programa vezanog za menije.

60
@ViPserbia

Zbog toga se vremenom prešlo na sistem gde se struktura stabla menija čuvala
u datoteci i zatim se ona koristila za kreiranje menija tako da bi program klizio po
stablu po svim nivoima i gde bi se birala opcija za dati posao, a čije bi se ime takoĎe
nalazilo u datoteci menija. Forma je u stvari samo "pogled" na tabelu u čoveku
prihvatljivijem izgledu.

Slika 4.2 Primer jedne forme u Accessu

Nad formiranom tabelom koja sadrţi naprimer podatke o nekom čitaocu

formira se maska za unos koja ima izgled papirnog obrasca - kartice, te operater -
korisnik ne mora da poznaje rad sa Accessom, nego samo koristi elektronske obrasce
(maske) i unosi podatke primenom miša i pomoću tastature, baš kao što je to ranije
činio olovkom ili u klasičnim programima.

Veoma je značajna činjenica da forma za unos podataka moţe sadrţati slike,

komandne tastere (pritiskom na koje moţe da se aktivira neka komanda kao što je
naprimer štampanje trenutne kartice ili prelaz na drugu formu), moţe sadrţati
odreĎena logička polja ili pak moţe sadrţavati odreĎenu podformu itd.

Forma takoĎe ne mora da sadrţi niti jedno polje za unos ili prikaz podataka.
Ona jednostavno moţe biti kreirani pozdravni ekran vza datu aplikaciju sa prigodnim
tekstom i slikom, koji se posle isteka definisanog vremenskog intervala sam zatvara.

61
@ViPserbia

Takve forme mogu uzeti oblik pozdravne slike koja se pojavljuje prilikom starta
nekog većeg programa, kao što se to često dogaĎa u programima paketa Microsoft
Office.

4.3. Upiti – queries

Osnovni upiti, sortiranje, selekcija, sloţene selekcije su najčešće aktivnosti koje

se primenjuju od strane većine korisnika prilikom korišćenja neke baze podataka.
Naime jedna od najvaţnijih dobrih osobina baza podataka jeste mogućnost da se brzo
i jednostavno pristupi ţeljenim podacima. Upiti se mogu koristiti i za aţuriranje
podataka u tabelama, ali taj deo će biti analiziran kasnije. Kada se koriste za biranje
odreĎenih grupa podataka moraju se definisati odgovarajući kriterijumi po kojima će
se podaci selektirati i grupisati radi prezentiranja korisniku.

U stvari moţemo reći da su upiti posebni pregledi kojima se postavlja neki upit
nad tabelom i koji izdvajaju podatke za pregled na ekranu ili štampanje putem
izveštaja. Naprimer ukoliko ţelimo pregled svih narudţbina ostvarenih posle meseca
januara u kriterijum za upit se moţe upisati >31.01.2000.

Sem izdvajanja podataka postoje i posebni upiti koji mogu kreirati tabelu
koristeći drugu tabelu ili više drugih tabela nad kojom je postavljen upit, odnosno
mogu brisati podatke iz postojeće tabele takoĎe po nekom kriterijumu.

Veoma često se podaci nalaze u različitim tabelama podataka i tada je potrebno

da se obezbedi selekcija i grupisanje podataka iz svih tih tabela u saglasnosti sa
definisanim kriterijumima. Upiti znači mogu filtirati podatke ne samo iz jedne tabele
već se to moţe činiti iz više tabela ili čak iz jednog ili više drugih upita. TakoĎe mogu
istovremeno filtrirati podatke po više kriterijuma.

4.4 Izveštaji – reports

Izveštaj je grupa podataka koji su meĎusobno povezani na odgovarajući način.
Oni sluţe da se korisniku baze mogu predstaviti potrebni podaci. Izveštaji mogu biti
usmereni na ekran, na štampač ili u neku posebnu datoteku na neki poseban medij za
kasniju upotrebu. Dobijanje izveštaja se ostvaruje primenom nekog od potrebnih
programa ili primenom odgovarajućih generatora izveštaja kakve uglavnom poseduju
novije baze podataka u svom asortimanu. MeĎutim ukoliko korisnik nije zadovoljan
postojećom formom izveštaja koji su ponuĎeni od strane proizvoĎača baze programer
moţe iskoristiti dobijene podatke u selektovanoj formi i u nekom od drugih
programskih alata napraviti izveštaj po ţelji korisnika.

62
@ViPserbia

Podaci prikazani u izveštaju mogu biti izvedeni iz tabela ili iz upita (filtrirani
podaci). Dizajniranje izveštaja je veoma slično dizajniranju formi, ali se priprema za
selekciju podataka i generisanje izveštaja radi na sličan način i kao priprema upita.

Slika 4.3 Primer jednog upita u Accessu

Slika 4.4 Primer jednog izveštaja u Accessu

63
@ViPserbia

4.5. Spajanje relacija - spajanje tabela

Veoma često je potrebno obezbediti odgovarajuće preglede podataka koji se

nalaze u nekoliko različitih tabela podataka. MeĎutim povezivanje takvih tabela u
jednu novu tabelu je moguće samo ako te tabele sadrţe zajednička polja. Ova polja su
neophodna da bi se moglo izvršiti povezivanje i nazivaju se ključna polja. Neophodno
je obezbediti da ova ključna polja imaju jednoznačne vrednosti bar u jednoj od tabela.
Pri tome je neophodno da ova ključna polja na pravi način tj. nedvosmisleno
obezbede identifikaciju datog zapisa u tabeli.
Za veze odnosno moguće relacije izmeĎu tabela postoji više mogućnosti kao
što su naprimer veza jedan prema jedan, jedan prema više, više prema jedan ili pak
više prema više.

Slika 4.5: Primer šeme "entieti-relacije" realizovane za potrebe aplikacije na Famu:

64
@ViPserbia

Slika 4.6: Primer šeme "entieti-relacije" realizovane za potrebe aplikacije na Famu:

65
@ViPserbia

4.6. Ažuriranje - unos, ispravka,brisanje, dodavanje novih podataka

Unos
Da bi se mogli unositi podaci u bazu podataka, a posebno kada to čini veći broj
korisnika poţeljno je ili bolje rečeno potrebno je da se naprave odgovarajuće ekranske
forme na kojima će se lepo kreirati ţeljeni oblik dokumenta za unos sa svim poljima
koja korisnik treba da unosi. Pri tome se definišu tipovi podataka, odgovarajuće
duţine polja, kao i odgovarajuće kontrole koje će obezbediti da korisnici sa što manje
grešaka ili propusta unose potrebne podatke. Većina savremenih baza ima gotove
odreĎene forme ekrana za unos koji se mogu u takvoj ili donekle izmenjenoj i po ţelji
korisnika prilagoĎenoj formi koristiti.

Ispravka
Ukoliko je prilikom unosa korisnik napravio grešku i pogrešno uneo neki
podatak ili neki njegov deo ili su pak odreĎeni podatak ili grupa podataka u bazi
tokom vremena i promena koje ono nosi sobom postali nevaţeći ili neadekvatni tada
je potrebno obezbediti mogućnost njihove ispravke delimične ili potpune ili pak
kompletnog brisanja nekog podatka. Zavisno od programera koji realizuje aplikaciju
na datoj bazi ove izmene ili ispravke se realizuju uglavnom primenom ekranskog
formulara za unos pri čemu se vrši ili unosi samo ispravka ili se pak unosi ceo
podatak iznova koji će prilikom aţuriranja prebrisati postojeći podatak koji je
neispravan.
Pri tome treba imati na umu da se ne mogu sve ispravke vršiti na takav način
jer postoje u različitim bazama podataka i različite grupe podataka koje podleţu
raznim propisima i dok je kod jednih podataka dozvoljeno da se nesmetano
neispravan podatak zameni ispravnim kod grugih se mora ispoštovati odgovarajuća
procedura. Veoma često je u takvim slučajevima potrebno da i neispravan i ispravan
podatak ostanu u bazi kao evidencija o promenama u bazi ali sam krajnji korisnik
kada pristupi bazi će dobiti na uvid samo poslednji ispravljeni podatak.

Brisanje
Kako je pomenuto u prethodnom pasusu ponekad je potrebno obrisati neki
podatak u celini jer više nije vaţeći ili je bio ceo pogrešno unesen. Tada se primenjuje
opcija brisanja koja omogućava korisniku da trajno izbriše neki podatak iz baze.
Postoje takoĎe i podaci u bazama podataka za koje nije dozvoljeno brisanje jer neki
podaci predstavljaju hronologiju ili istoriju nekih promena ili kretanja i ako bi se ti
podaci izbrisali izgubio bi se tok promena.
Sa druge strane postoje naprimer grupe knjigovodstvenih i drugih podataka
koje se nikako ne smiju brisati i moraju ostati uvek u evidenciji sa svim mogućim
greškama i ispravkama koje su unošene i za koje mora da postoji validna podloga –

66
@ViPserbia

dokument na osnovu čega se izvode. U suprotnom bi se omogućila manipulacija

podacima koja nije dozvoljena niti po zakonu o knjigovodstvu niti po drugim
zakonskim propisima.

Dodavanje novih podataka

Baza podataka je u većini slučajeva podloţana promenama ili zbog
svakodnevnih promena vezanih za podatke koji se nalaze u bazama recimo baza
kupaca, dobavljača, roba, knjiga itd. koje se sakodnevno moraju dopunjavati novima
ili se pak u nekim bazama sa protokom vremena pojavljuju nove grupe podataka koje
je potrebno uneti. Kao i kod prvobitnih unosa podataka u polaznu bazu i ovde se
koriste ekranske forme za unos podataka koje omogućavaju korisnicima da mogu da
unose i te nove podatke ili grupe podataka.

Ubacivanje novih polja u bazu

Ma koliko se kreatori baze trudili da prilikom kreiranja baze obuhvate sve
potrebne podatke i polja koja će biti potrebna korisniku u eksploataciji baze uvek
postoji mogućnost ili da je prevideo neko polje ili da se u toku eksploatacije baze
pojavi potreba za ubacivanjem dodatnih polja. Dok je to kod ranijih baza ponekad
predstavljalo problem i zahtevalo ozbiljnije zahvate u aplikaciji, današnje baze
odnosno alati baza omogućavaju da se ubacivanje jednog ili više novih polja u bazu
mogu izvoditi bez ikakvih problema. Na taj način je omogućen nesmetan razvoj baza
u kladu sa ţeljama, zahtevima ili pak razvojem potreba ili obima poslovanja pojedinih
korisnika.

4.7. Indeksi
Indeksi predstavljaju odgovarajuće pomoćne strukture koje imaju zadatak da
ubrzaju pristup podacima u bazi. Definisanje indeksa se vrši odgovarajućim
naredbama što naravno zavisi od baze koja se koristi. Prilikom definisanja indeksa
potrebno je navesti sledeće: naziv relacije, naziv polja nad kojim treba definisati
indeks, odnosno za više njih ako se nad više polja definiše indeks, zatim je potrebno
definisati dozvolu ili zabranu postojanja polja sa jednakim vrednostima podataka tj.
mogućih duplikata. Ukoliko duplikati nisu dozvoljeni, a to je obično slučaj kada
kombinacija polja predstavlja primarni ključ relacije, tada recimo nijedno od polja
komponenata ne sme sadrţavati nula vrednosti.
Indeksi se naprimer u nekim SUBP mogu definisati na dva načina: kao SORTED
ili kao HASHED. U prvom slučaju indeks je struktura poznata kao hijerarhijska -
stablo, pri čemu se u samom indeksu, uz lokaciju zapisa odreĎene n-torke, dupliraju
neki podaci iz polja/kolona nad kojima je indeks definisan. U drugom slučaju indeks
je takozvana hash-tablica, kod koje se lokacija zapisa n-torke izračunava na osnovu
vrednosti podataka u njoj; vreme pristupa trebalo bi da bude relativno konstantno,

67
@ViPserbia

dakle nezavisno od vrednosti podataka u n-torci.

Nasuprot tome, kod indeksa u obliku stabla moţe se desiti da se neki zapis
pronaĎe već na najvišem, prvom nivou stabla, a neki drugi na najniţem nivou stabla
(dobro projektovana stabla obično imaju jednocifren broj nivoa, čak i za vrlo veliki
broj n-torki). Indeksi u obliku stabla, imaju još jednu prednost: kod upita za koje je
potrebna vrednost podataka samo iz onih polja/kolona nad kojima je indeks definisan,
dovoljno je pročitati indeks, dok se samim n-torkama ne mora uopšte pristupiti. Kod
indeksa u obliku hash-tablice, podaci iz n-torki uvek se moraju čitati.
Za standardni SORTED indeks moţe se predvideti i veličina čvora u bajtima,
procenat popunjenosti i način korišćenja indeksa. Naime, ako je namena indeksa u
prvom redu brţi pristup pri pretraţivanju, onda je bolje da stranice indeksa budu u
potpunosti popunjene: broj stranica biće manji, pa će biti manji i srednji broj stranica
koje treba pretraţiti. S druge strane, ukoliko indeks valja koristiti pri aţuriranju, onda
je bolje da stranice imaju i slobodnog prostora, jer će prilikom dodavanja novih n-
torki broj prepakivanja indeksnih stranica biti manji.
Ukoliko je baza raspodeljena na više fizičkih datoteka (multifileschema), iskazom
STORE... moţe se zahtevati da indeks bude u jednoj ili više zona (storage area), kao i
da se raspodela po zonama vrši bilo po slučajnom redosledu, bilo ravnomerno po
svim raspoloţivim zonama.
Treba primetiti da neke baze dozvoljavaju da se nad istim poljem/kolonom, ili
kombinacijom polja/kolona, definiše i SORTED i HASHED indeks, budući da je prvi
efikasniji kod upita kod kojih se traţi opseg vrednosti nekih podataka, a drugi ima
prednost kod upita koji zahtevaju tačno slaganje nekih podataka. Reţijsko vreme
potrebno za odrţavanje dva indeksa, meĎutim, veće je nego za odrţavanje samo
jednog, pa i tu valja proceniti šta se više isplati.

4.8. Ključevi

Ključevi su karakteristični podaci u svakom pojedinačnom redu neke

transakcije ili stavke koji su nedvosmisleno vezani za odreĎenog kupca – šifra kupca,
robu – šifra robe, dobavljača – šifra dobavljača, dokumenta – šifra ili broj dokumenta
i preko kojih se cela transakcija moţe direktno dovesti u vezu sa datim kupcem,
robom, dobavljačem ili dokumentom. UvoĎenje ključa je bilo prisutno i kod
konvencionalnih – klasičnih datoteka iz istih razloga, a sa prelaskom na baze
podataka kao viših integrisanih oblika klasičnih datoteka je dobilo još više na zbačaju.
Mogu se koristiti jedan ili više ključeva, pri čemu ako ih je više onda je jedan
primarni, a ostali su sekundarni. Kod selekcionisanja, grupisanja i pretraţivanja
podataka kjučevi nalaze svoju punu primenu jer su oni pored drugih kriterijuma koje
korisnici postave jedan od osnovnih elemenata po kojima se vrši selekcija i sortiranje.

68
@ViPserbia

4.9. Pretraživanja, sortiranja, selekcija

Mada je ovaj segment delimično spomenut u okviru upita zbog njegove

vaţnosti daćemo neka dodatna objašnjenja. Baze podataka su i dobile svoju punu
vrednost u odnosu na druga klasičnija rešenja baš zbog činjenice da su omogućile laka
i jednostavna pretraţivanja, sortiranja i selekcije podataka po različitim i često veoma
sloţenim kriterijumima, od kojih poneki nisu ni bili predviĎeni u fazi kreiranja baze,
nego su se naknadno pojavili kao neminovnost i potreba u datom trenutku vremena ili
poslovanja neke firme ili institucije. Lepota u primeni baza podataka je baš u činjenici
da se kod većine baza mogu obezbeĎivati najrazličitiji pregledi na osnovu
odgovarajućih pretraţivanja, selekcija ili sortiranja podataka u bazi, po odgovarajućim
kriterijumima koje korisnici mogu kombinovati od slučaja do slučaja prema trenutnim
potrebama ili zahtevima posla.

4.10 Makroi i VBA

Makroi i moduli načinjeni primenom VBA – Visual Basic for Applications

visual basic za aplikacije - predstavljaju dve dodatne mogućnosti koje se mogu
koristiti prilikom izrade aplikacija u nekim bazama kao i kod primene Accessa.

Slika 4.7 Primer pozivanja VBA u Accessu

Naime često se javlja potreba za korišćenjem grupisanih naredbi koje su

obuhvaćene pojedinim modulima ili pak za formiranje funkcija koje ne postoje u

69
@ViPserbia

datoj bazi ili se pak grupe funkcija moraju vezati u jedan sloţeniji sklop, te se za
razvijanje i automatizovanje baze podataka mora pristupiti pisanju programa.
Makroima se iz konačnog skupa funkcija i naredbi automatizuje rad baze; meĎutim,
njihovo korišćenje se u novijim aplikacijama sve više izbegava, jer se puna sloboda i
funkcionalnost ostvaruju primenom VBA. Makroi, zapravo, postoje uglavnom zbog
kompatibilnosti sa prethodnim verzijama Accessa i drugih baza.

70
@ViPserbia

5. Razvoj aplikacija primenom Microsoft Access-a

Microsoft Access je program za rad sa bazama podataka firme Microsoft.
Microsoft Access se pojavljivao u raznim modelima od kojih su u poslednje vreme
aktuelni Access97, Access2000, Access2002, Access2003, sa više desetina miliona
prodatih kopija. Access 2003 je ovog časa najnovija varijanta i dolazi u paketu sa
Microsoft Office XP Professional

Iako je u početnim verzijama bio prilično nesavršen, program je danas

prerastao u ozbiljan paket za razvoj aplikacija kod kojih je osnova baza podataka. Dok
se nekada programirala svaka operacija nad bazom, u Accessu je danas većina stvari
automatizovana i uz oslanjanje na odreĎene alate operativnog sistema do gotove,
jednostavne baze, se često dolazi koristeći isključivo rad sa mišem i primenom raznih
pomoćnih alatki (čarobnjak – wizard) bez napisane gotovo ijedne linije programskog
koda.

Napomena:
Namena ovog uputstva za primenu Accessa je da se studenti Fakulteta za
menaţdment uvedu u osnove rada sa Microsoft Access softverom za rad i upravljanje
sa relacionom bazom podataka. Osnovni razlog je njegova rasprostranjenost na
trţištu, jednostavnost razvoja baze podataka, jednostavnost rada i odrţavanja.
MeĎutim ono što je najvaţnije je da primena nekih od ovde navedenih principa
vaţi za sve relacione baze podataka bez obzira na to ko su njihovi proizvoĎači, takoĎe
način definisanja i postavljanja aplikacije u bilo kojoj od tih baza je gotovo identičan.
Razlika je više izraţena u pojedinim dodatnim alatima, wizardima, Cases – kejsovima
koji se dobijaju uz pojedine baze pa je aplikacije nešto teţe ili lakše projektovati I
kreirati. Bitno je da se studenti osposobe i nauče da naprave sami pojedine aplikacije
u bazi, da uoče najvaţnije stvari o kojima se mora voditi računa pri takvom radu, da
nauče o čemu moraju voditi računa u mreţnom ili distribuiranom radu ili pak nadzoru
ili zaštiti baze, a svaki od njih će na svom budućem radnom mestu gde budu radili
imati prilike da se iz dokumentacije upozna detaljnije sa specifičnostima pojedinih
baza koje se budu koristile u njihovim preduzećima.

1) Ovo uputstvo za rad je bazirano na Help funkcijama koje su ugraĎene u

Microsoft Access 2000 softveru kao deo Microsoft Office 2000 paketa.
2) Uputstvo je namenjeno za potrebe obučavanja studenata, a dato je na
primeru projekta voĎenja biblioteke Fakulteta za menadţment u Novom
Sadu (kao jedno od mogućih rešenja).
3) Sva imena i informacije koja su u ovom uputsvu upotrebljena su
hipotetička.

71
@ViPserbia

5.1. Uvodne informacije - uputstva

Ovo uputstvo je predviĎeno za rad sa Microsoft-ovim Accessom iz paketa

Office 2000. Microsoft Access će se nadalje u tekstu označavati kao Access jer se
aplikacije mogu razvijati na veoma sličan način i u Accessu 2003 kao i u Accessu 97.
U ovom uputstvu će biti prikazan rad sa tabelama, formama, izveštajima i
upitima.
Tokom instalacije Accessa, obično se instaliraju se i primeri koji se isporučuju
uz dati tip Accessa kao naprimer Northwind uz Access 97 ili pak Sweet Lil’s uz
Access 2000 tako da se i ovaj primer moţe koristiti za usavršavanje rada sa
Accessom. Primer biblioteke se u ovom uputstvu koristi kao osnova za razvoj jedne
jednostavne baze podataka.
Pretpostavka je da su studenti koji će koristiti ova uputstva već familijarni u
radu sa operativnim sistemima koje Microsoft isporučuje trţištu kao što su Windows
'95, Windows '98, Windows NT / 2000 ili Windows XP. U okviru toga znanja
očekuje se i poznavanje rada sa tastaturom i mišem. Pretpostavka je da studenti
korisnici poznaju i rad sa disketom, kao i da znaju da koriste Windows Explorer
(pronalaţenje datoteka, kopiranje, brisanje, izradu posebnih fascikli za svoje potrebe
[folder], minimiziranje i maksimiziranje prozora te njegovo zatvaranje, startovanje
programa bilo sa radne površine Windowsa preko odgovarajućih ikona ili preko Start
 Programs menija, ...).

Danas je kod nas najšire rasprostranjena upotreba Access 2000, mada su i

Access 2002 odnosno 2003 sve više u upotrebi.

Većina današnjih arhitektura odnosno organizacija podataka u bazama

podataka su relacionog tipa i nudi se ceo dijapazon softvera za upravljanje relacionim
bazama podataka, a tu spada i Access. On je namenjen za mala pa i srednja preduzeća.

U nastavku je dat primer razvoja jedne baze podataka sa pratećim detaljima o

tome kako se izraĎuju tabele, forme, izveštaji i upiti, a to se sve preko raznih
mogućnosti koje nudi Access moţe upakovati u jednu poslovnu aplikaciju.

72
@ViPserbia

5.2 Primer razvoja aplikacije (iz poslovne prakse)

U ovom poglavlju dat je jedan primer iz poslovne prakse koji će omogućiti da

se na osnovu njega prati rad kroz ovo uputstvo. Kod svake poslovne organizacije,
sprovode se postupci analize posla, definišu se odgovarajuće strukture baze podataka,
a sve to se pod jednim zbirnim nazivom naziva "Sistem analiza". U teoriji se danas
koriste i drugi nazivi tehnika projektovanja informacionih sistema poslovnih
organizacija. Sistem analitičar ima zadatak da prikuplja informacije o tome kako se
odvijaju poslovni procesi odnosno aktivnosti i na osnovu takvih informacija da
formira model podataka. Preko modela podataka se izačunava, procenjuje kapacitet
memorije (diskova), Preko modela podataka, programer bez podataka će formirati
tabele u bazi podataka i one se onda koriste u aplikaciji da bi se zadovoljio zahtev za
informacijama koji je postavljen od strane korisnika aplikacije, odnosno predstavnika
poslovne funkcije.

Razmotrimo kao primer rad jedne male banke. Pretpostavimo da banka ima
nekoliko klijenata koji otvaraju i rade sa jednim ili više računa. Za svakog klijenta se
čuvaju podaci o imenu, adresi i mestu sedišta odnosno stanovanja. Jednom klijentu se
pridruţuje jedinstveni identifikator KlijentID koji po nalogu progamera moţe da se
generiše i mašinski (računarski). Ovaj identifikator je potreban da bude jedinstven jer
se moţe desiti da u banci se pojave dva klijenta sa istim imenom i prezimenom.

Sličnim postupkom, svim računima se dodeljuje pripadajući vlasnik preko

jedinstvenog identifikatora vlasnika, a svaki račun dobija svoj jedinstveni
identifikator tj. broj tekućeg računa odnosno broj partije preko koje klijent banke
realizuje svoje finansijske transakcije. Tip računa opredeljuje i vrstu transakcije sa
računom jer otplata stambenog kredita nije isto što i štednja po viĎenju. Dali smo
primere tabela za klijente i račune ("Klijenti" i "Racuni"). One će nam biti podloga za
razvoj jedne poslovne - bankarske aplikacije.

U bilo kojoj aplikaciji za rad sa bazom podataka, koriste se termini obuhvata

podataka: upis novog, aţuriranje postojećeg, brisanje postojećeg i uvid u stanje sloga
u tabeli baze podataka uz eventualno štampanje. Da bi se obuhvat podataka realizovao
koriste se forme za obuhvat podataka. Da biste dobili podatke izvučene iz tabela sa
takozvanim filterima i / ili da ih štampate potrebno je koristiti mehanizme izrade upita
(query) i izrade izveštaja (report).
Ovde će biti pokazan primer kako se pravi jedna forma za svaku tabelu, kako se
pravi upit za svaku tabelu i kako se prave izveštaji za svaku od navedenh tabela.
U nastavku, ćemo početi od toga kako se polazi od takozvane prazne (odnosno
nove) baze podataka uz pomoć MS Access-a 2000.

73
@ViPserbia

5.3. Pokretanje rada Microsoft Access 2000

Postoje razni načini navigacije kroz Windows da se aktivira pristup MS
Access-u. Prikazane su neki od mogućnosti. Pristup Access-u preko radne površine
Windowsa (desktop):

Slika 5.1 Primer pozivanja Accessa

Napomenimo da je izgled radne površine različit od raznih vlasnika personalnih

računara.
Aranţmani menija zavise od toga kako je instaliran Microsoft Office 2000
paket, a zavise i od tipa personalnog računara odnosno verzije Windowsa. Druga
mogućnost je da se preko dugmeta "StartProgramsAccess" doĎe do startovanja
rada u Access-u. Pogledaćemo sledeći primer:

74
@ViPserbia

Slika 5.2. Primer pozivanja Accessa - StartProgramsAccess

ili

Slika 5.3. Primer pozivanja Accessa iz menija Offisa

75
@ViPserbia

Čim je Access pokrenut, pojave se inicijalni ekrani na kojima se biraju obrasci

rada (template):

Slika 5.4. Primer a menija za pozivanje odgovarajućih template iz menija Accessa

Kod pokretanja rada sa Access-om, mogu se koristiti i unapred definisani
obrasci (template) za izradu sopstvene baze podataka, pri čemu se spretniji programeri
mogu pozabaviti i modifikacijama tako generisanih baza podataka odnosno njenih
sadrţaja (tabele, forme, izveštaji, upiti).

Slika 5.5. Primer b menija za pozivanje odgovarajućih template iz menija Accessa

76
@ViPserbia

Slika 5.6. Primer menija za izbor odgovarajućih template iz menija Accessa

Od ovog početnog ekrana, korisnik Accessa moţe početi sa formiranjem nove

baze podataka (bilo da je ona prazna - BLANK ili je zasnovana na nekom od
postojećih modela - obrazaca.

Kada se započinje novi projekat onda je poţeljno da se započne sa izradom

"prazne" baze podataka. Nakon toga se tako formirana baza svaki put "poziva"
(otvara) da bi se u njoj vršile modifikacije (ako je u pitanju odrţavanje baze podataka)
ili da bi se koristila za potrebe poslovanja. Ako je korisnik ranije kreirao bazu
podataka i kreira novu sa istim imenom biće upozoren da moţe prebrisati postojeću.

Potrebno je proći sve ove korake pa izabrati kreiranje nove, prazne baze
podataka (new, blank) kao što je prikazano na napred datim slikama.
Zatim je potrebno izabrati Blank Database i kliknuti na OK dugme te nastaviti
sa praćenjem ekrana koji slede odnosno uneti polje ime baze podataka File Name kao
bankdb.mdb i kliknuti na dugme Create:

77
@ViPserbia

Slika 5.7. Primer za izbor banka baze – bankdb.mdb iz menija baza Accessa

bankdb je ime konkretne baze podataka a .mdb je rezervisano ime ekstenzije

naziva datoteke kojom Microsoft obeleţava Access-ove baze podataka. Postoje
sintaksna pravila u dodeli naziva baze podataka kao što su makismalna duţina naziva
datoteke, zabrana korišćenja nekih specijalnih simbola kao što su znak praznine
(space), znakovi punktuacije (, . ? itd.). Pored toga, preporučuje se da naziv baze
podataka odraţava i sadrţaj baze podataka. U zavisnosti od verzija instaliranog
Access-a moţe se pojaviti jedan od sledećih ekrana:

MS Access '97

Slika 5.8. Primer menija za rad sa bazom u Accessu 97

ili

78
@ViPserbia

MS Access 2000

Slika 5.9. Primer menija za rad sa bazom u Accessu 2000

Na ovim glavnim ekranima se preko odgovarajućeg menija nude dve

mogućnosti, ukoliko se nalazite na objektu "Table" u glavnom ekranu Access-a.
Meniji su veoma slični Word-u i Exel-u

Meniji uključuju sledeće:

 File - Stavke ovog menija su funkcije Open, Close, Create new, Save i Print baze
podataka i njenog sadrţaja. U ovom meniju je i funkcija Exit za izlazak iz Access-a.
 Edit - Funkcije su Cut, Copy, Paste, Delete
 View - Uvid (upit) u razne objekte baze podataka (tabele, upiti, forme izveštaji)
 Insert - Insert nove tabele, upita, forme, izveštaja itd.
 Tools - Skup alata kao što su overa pravopisa, izrada relacija izmeĎu tabela,
obavljanje analize performansi baze podataka i izveštavanje o sadrţaju baze podataka
(aplikativni deo, a ne deo o podacima).
 Window – Korisnik se moţe prikoključivati na različite baze podataka koje su u
isto vreme otvorene.
 Help - Ukoliko korisniku nešto nije jasno moţe koristiti pomoć o Access-u – Help
(u zavisnosti od instaliranog Access-a to moţe biti ili na maternjem jeziku ili na
engleskom)

79
@ViPserbia

Glavni tab u glavnom prozoru uključuje sledeće:

 Tables - Prikazi skupa svih tabela sačuvanih u bazi podataka

 Queries - Prikazi skupa svih upita sačuvanih u bazi podataka
 Forms - Prikazi skupa svih formi sačuvanih u bazi podataka
 Reports - Prikazi skupa svih izveštaja sačuvanih u bazi podataka
 Macros - Prikazi skupa svih privatnih (koje ste vi napravili) makroa (kratki
programi koji su pisani internim makro jezikom Access-a), a sačuvani u bazi podataka
 Modules - Prikazi skupa svih sopstvenih modula (pisanih u VBA-Visual Basic for
Applications
jeziku), a koji su sačuvani u bazi podataka.

U MS Access 2000 ovi tabovi se pojavljuju na levoj strani glavnog ekrana koji
se pojavljuje kao default. MS Access 2000 ima mogućnosti da radi i sa Web Pages
(Web stranicama) i sa Favorites, ali ove mogućnosti nisu ovde obuhvaćene. Ovde će
biti obuhvaćene sledeće teme:

* Tables (tabele)
* Queries (upite)
* Forms (forme za obuhvat podataka) i
* Reports (izveštaji).

U nastavku je dat kratak pregled aktivnosti za početak rada sa Microsoft Access-om:

1. Koristi se dugme "Start" u donjem levom uglu trake za poslove (task bar)
Windowsa na sledeći način Programs  MS Office  Microsoft
Access
2. Napraviti novu bazu izborom Blank Database i dodeliti ime datoteke u koju će
biti smeštena nova baza podataka (ne mora se kucati i ekstenzija .mdb). Klikom
na Ok tipku -dugme obavljeno je kreiranje baze podataka.
3. Za otvaranje postojećih baza podataka koristi se funkcija Open an Existing
Database a ukoliko imate dopunsku poruku More Files... (ima još ... - zahtev
za više fajlova - datoteka) onda kliknite na OK dugme. Navigacionim
pomagalima dolazi se do ţeljenih baza podataka. Za napuštanje Access-a
koristi se funkcija File i odabirom stavke Exit.

80
@ViPserbia

5.4 Izrada tabela

Tabele su glavne jedinice za smeštanje odnosno pamćenje podataka u Access-u.

Tabele se sastoje od jedne ili više kolona (ili polja) pri čemu jedna kolona u jednoj
tabeli moţe da bude relacija sa nekom kolonom u drugoj tabeli (ili tabelama).
Iz razvijenog primera se zaključuje da imamo dve tabele koje bi trebale da budu
dovoljne da se smeste podaci o klijentima mini banke Klijenti i podaci o njihovim
računima (ako ih imaju) Računi. Sada ćemo objasniti korak-po-korak kako se prave
ove dve tabele u Access-u.
Najjednostavniji način za izradu tabela u Access-u je upotreba takozvanog
čarobnjaka (wizard) koji vode korisnika Access-a, predlaţući mu imena za tabele i
kolone. Drugi način izrade tabela jeste upotreba
funkcije Design View kojom se "pešački" definišu kolone (polja) u tabeli i njihovi
tipovi podataka.
Iako se čini da je sa čarobnjacima brţi način formiranja tabela, korisnik
(pogotovo ako je iskusniji) ima slabiju kontrolu nad imenima kolona i tipovima
podataka. Ovde ćemo opisati "pešački" način izrade tabele pomoću funkcije Design
View. Studentima se preporučuje da sami više eksperimentišu sa čarobnjakom Create
Table.

5.4.1. Izrada tabele korišćenjem "Design View"

Da bi se moglo doći do funkcije Design View, mora se doći do taba Tables

(videti mogući izgled ekrana na sledećoj slici):
1. Duplim klikom na "Create Table in Designe View" i klikom na dugme Ok
pojaviće se sledeći ekran:

Slika 5.10. Primer izbora opcije Design View u meniju za rad sa tabelama

81
@ViPserbia

2. Sledi ekran sa nazivima specijalnih kolona Field Name (Ime polja), Data Type
(Tip podataka) i Description (opis) za svaku kolonu (polje) u tabeli koju ćemo
sada kreirati. Polje KlijentID se kreira kao što je prikazano:

Slika 5.11. Primer rada sa tabelama u meniju Design View u Accessu 2000

Treba napomenuti da Access nudi podrazumevano (default) ime tabele Table1.

Ono se moţe promeniti odmah ili kasnije (pokazaćemo kako).

Popunićemo informacije za preostale kolone u skladu sa sledećim opisom:

Field Name Data Type Description

KlijentID Number Jedinstveni identifikator klijenta minibanke BLUE HILLS
Ime_i_Prezime Text Ime i prezime klijenta
Adresa Text Adresa klijenta
Mesto Text Mesto stanovanja klijenta
Drzava Text Drţava stanovanja klijenta
Post_Broj Text Poštanski broj mesta stanovanja klijenta

Slika 5.12. Primer definisanja polja za tabelu Klijenata

Finalna kreacija u DesignView funkciji je prikazana na sledećem ekranu - slici:

82
@ViPserbia

Slika 5.13. Primer popunjenih – definisanih polja u tabeli Klijenata

3. Sada kada imamo definisana sva polja tabele, odreĎujemo primarni ključ (indeks)
Primary Key i to prvo desnim klikom na polje KlijentID, a zatim u padajućem meniju
odaberemo Primary Key kao što je pokazano na sledećoj slici.

Slika 5.14. Primer definisanja primarnog ključa u tabeli Klijenata

83
@ViPserbia

Posle ovoga se u imenu ove kolone sa leve strane pojavljuje simbol malog
ključića. Da biste izbacili definiciju primarnog indeksa, treba opet ponoviti proceduru
te isključiti Primary key. Dobro je znati da sa F6 funkcijskom tipkom moţe prelaziti
iz FiledName u detalje definisanja obeleţja (svojstava) te kolone.

4. Konačan korak postupka je da se tabela sačuva, a to se radi tako što se u

padajućem meniju File izabere stavka Save. U dijalogu sa korisnikom Access nudi
ime tabele koju korisnik ţeli sačuvati pri čemu da podestimo Access uvek nudi nešto
kao Table1, Table2, itd. Korisnik jednostavno prbriše ponuĎeno ime sa imenom koje
smo definisali u projektu male banke: Klijenti te klikom na dugme Ok potvrdi upis
definicije tabele u bazu podataka bankdb.mdb.

KLIJENTI

Slika 5.15. Primer – primena funkcije Save na tabelu KLIJENTI

Vratimo se ponovo na glavni meni Access-a u funkcijski meni File i odabirom

funkcije Close (zatvori) odabrali smo da se zatvori DesignView za tabele i pogledajmo
efekat koji je pokazan na sledećoj slici:

Slika 5.16. Primer – izbor tabele KLIJENTI u osnovnom meniju baze

84
@ViPserbia

Treba zapaziti da je veoma bitno da se pri definisanju naziva polja (kolona)

odrede jasna imena polja i tabela koja na neki način odraţavaju njihov sadrţaj. Na
primer, na šta vas naziv polja BK upućuje, na Broj Klijenta ili Broj kontejnera?
U Access-u se mogu koristiti imena polja maksimalne duţine 64 znakova. a ona
mogu sadrţati i znak "prazno". MeĎutim, znakove "prazno" u nazivima polja i
tabela bi trebalo izbegavati (ovo je praksa pokazala). Moţe se koristiti i donja crtu
(underscore) karakter radi lakše čitljivosti naziva polja i tabela odnosno kao znak za
razdvajanje kao naprimer Sifra_Korisnika ili Ime_i_Prezime itd (naravno, uz
izbegavanje znaka "prazno").

U sledećoj tabeli su dati neki primeri različitih označavanja imena polja:

Opis Loše Dobro

Jedinstveni identifikator CustomerID ili
CID
korisnika Customer_ID
Opis proizvoda PDESC ProductDescription
Kućni telefon zaposlenog Employee_home_telephone_number HomePhone
Račun u banci BA# AccountNumber
Naslov knjige Tit Book_Title
Slika naslovne strane Pic Cover_Picture

Slika 5.17. Primeri označavanja imena polja

Primer - Izrada tabele

Sada ćemo kao primer napraviti tabelu računa pod nazivom Racuni koristeći
iste korake kao kada smo kreirali tabelu Klijenti.

1. Kliknite na dugme New i odaberite Design View u dijalog prozoru koji se pojavio i
potom kliknite na dugme Ok.

2. Pojaviće se prozor "Table Design View" (koji je ranije opisan). Popunićemo Field
Name, Data Type i Description za svaku kolonu (polje) tabele Accounts kako je to
pokazano u tabeli na slici 5.18.

3. Na sledećoj slici 5.19. je prikazan finalni rezultat novo kreirane tabele

popunjene na napred navedeni način.

85
 @ViPserbia

Field Name Data Type Description

Naziv polja Tip podataka Opis
KlijentID Number Jedinstveni identifikator korisnika (klijenta)
Broj_Racuna Number Jedinstveni identifikator bankovnog računa (broj partije)
Vrsta_Stednje Text Tip računa (Čekovi, štednja, kredit, itd.)
Dat_Otvaranja Date Datum otvaranja računa
Trenutni saldo računa u tekućoj valuti zemlje (npr. CSD -
Saldo Number
meĎunarodna oznaka za dinar drţavne zajednice SCG)

Slika 5.18. Primeri popunjavanaja polja tabele

Slika 5.19. Primeri popunjavanaja polja tabele – Design View

4. Definisaćemo primarni ključ u tabeli Racuni. Na polju Broj_Racuna desnim

klikom odaberaćemo iz padajućeg menija Primary Key.

5. Sačuvaćemo ovako kreiranu novu tabelu pod imenom Racuni (preko File
menija i izborom funkcije Save). Popunićemo ime tabele sa Racuni i potom kliknuti
na dugme Ok.

86
@ViPserbia

5.4.3. Pregledanje i dodavanje podataka u tabelu

Podaci u formiranim tabelama se mogu dodavati, brisati ili modifikovatgi upotrebom

ekrana u takozvanom spreadsheet obliku. U nastavku ćemo pokazati kako se to
realizuje. Jednostavno kliknućemo na ime tabele i na taj način kao da smo dozvali
Open dugme. Na sledećoj slici je prikazano kako to izgleda a tabela izgleda kao neka
tablica (spreadsheet) po kojoj se moţe šetati:

Slika 5.20. Primer - spreadsheet izgled tabele

Zapazimo da imamo specijalnu traku Record u donjem delu porzora kojom

pratimo, navigiramo kroz tabelu. Ovde se vidi koliko maksimalno ima slogova
(odrednica "of n"), a broj ukazuje na trenutnu vidljivu poziciju u otvorenoj tabeli.
Kako je tabela otvorena prvi put onda je normalno da je ona prazna i da je KlijentId
generisan kao 0. Da bi dodali podatke u tabelu, jednostavno kucamo vrednosti svakog
polja i sa tipkom Tab krećemo se unutar reda, a primenom tipke strelice kao , ,
itd. krećemo se izmeĎu slogova u tabeli. Unećemo odreĎene vrednosti i odmah videti
efekte:

87
@ViPserbia

KlijentID Ime_i_Prezime Adresa Mesto Drzava Post_Broj

Number Character Character Character Character Character
1001 Jovan Jovanović Vase Stajića 3 Novi Sad SCG 21000
1002 Petar Petrović Stevana Sremca 23 Zrenjanin SCG 23000
1003 ĐorĎe Arsenijević Humska 23 Beograd SCG 11000
1004 Ana Bodor Petefi Šandora 3 Subotica SCG 24000

Slika 5.21. Primer - izgled tabele Klijenti

Slika 5.22. Primer - izgled tabele Klijenti – Design View

Sačuvaćemo unete podatke funkcijom Save u padajućem meniju File.

Osim prethodno pomenute navigacije, postoji i specijalna samogovoreća navigaciona
traka:

Slika 5.23. Primer - izgled navigacione trake

88
@ViPserbia

Za modifikaciju postojećih podataka, moraćemo navigirati do sloga koji

menjamo. Za brisanje sloga moramo doći do tog sloga, a onda u padajućem meniju
Edit odabrati funkciju Delete.

Zatvorićemo svaku promenu u tabeli i vratiti se na glavni ekran Access-a.

(padajući meni File, a potom aktivirati funkciju Close.

Kao primer otvorićemo tabelu računa Racuni i dodati podatke o računima

prikazanim ranije u tabelama. Pri tome moramo biti paţljivi da tačno unosimo
podatke (uključujući i voĎenje računa o tome da li su slova mala ili velika), a naročito
kod vrste računa jer Savings nije isto što i SAVINGS. Kada unosimo datume godinu
ćemo kucati sa 4 cifre. Access prikazuje samo 2 cifre što je po defaultu –
podrazumevano, ali se kao opcija Access-a ovo moţe menjati). Pri tome se u tabeli
sačuvaju sve 4 cifre godine. Kada smo sve uneli onda ćemo sačuvati podatke unete u
tabelu računa Accounts.

Slika 5.24. Primer - izgled tabele Racuni

Prema tome do sada smo naučili

- da pravimo tabele, i
- da unosimo podatke, menjamo sadrţaje i eventualno brišemo podatke u tabeli.
U nastavku ćemo da vidimo kako se prave upiti i izveštaji primenom Access-
ovih čarobnjaka

89
@ViPserbia

5.5 Izrada relacija izmeĎu tabela

Treba imati na umu da je glavna karakteristika svih relacionih baza podataka

postojanje relacija izmeĎu pojedinih tabela. U maloj banci, koju smo uzeli za primer,
tabela Customers je u relaciji sa tabelom Accounts strogom vezom izmeĎu polja
CustomerID u obe tabele. U Access-u postoji posebna alatka kojom se uspostavljaju
relacije izmeĎu tabela korišćenjem ekrana Relationships. Pri tome treba imati na umu
da Access sve informacije koje navedemo u dijagramu entiteta i realcija (E-R
dijagrami) koristi kod izrade izveštaja, formi i upita i da će čak traţiti da koristimo
delove dijagrama. U traci alata koje nam Access nudi, odaberaćemo funkciju
Relationships da bi smo pozvali ţeljeni alat:

Slika 5.25. Primer – izbor podmenija za definisanje relacija

90
@ViPserbia

Slika 5.26. Ekran podmenija za definisanje relacija

Da bi smo napravili dijagram moramo imati spisak tabela i odabirom korak-po-

korak uspostavljati relacije preko primarnih ključeva. Desnim klikom na bilo koji deo
ekrana Relationships odaberaćemo Show Tables... opciju za prikaz svih tabela koje
imamo u bazi podataka:

Slika 5.27. Meni za izbor prikazivanja tabela

Kada se pojavi dijalog kutijica Show Table osvetlićemo (odabrati) obe kreirane
tabele i pritisnuti dugme Add:

91
@ViPserbia

Slika 5.28. Meni za izbor odgovarajuće tabele

Posle toga ćemo klikom na dugme Close zatvoriti kutijicu za dijalog. Ekran
Relationship će imati izgled kao na sledećoj slici:

Slika 5.29. Primer - izbor odgovarajućih tabela koje ţelimo povezati

Da bi smo povezali ove dve tabele Klijenti i Racuni i na taj način formirali
relacije, kliknućemo na polje KlijentID u tabeli Klijenti i prevući preko polja

92
@ViPserbia

KlijentID u tabeli Racuni. OslobaĎanjem miša dijalog kutijica Edit Relationships će

izgledati kao na sledećoj slici:

Slika 5.30. Primer - izbor odgovarajućih tabela koje ţelimo povezati

Access će učiniti sve što je najbolje da definiše tip relacije (u većini slučajeva
to su relacije 1:M  One-to-Many). U ovom slučaju, Access zna da je KlijentID
primarni ključ tabele Klijenti i na taj način smo izabrali stranu tabele "1" ("One").
Povezivanjem sa drugom stranom u tabeli Racuni izabrali smo stranu "više" ("Many")
tako da imamo relaciju 1:M odnosno za jednog korisnika moţemo imati M otvorenih
računa, uzimajući u obzir i slučaj da nema otvorene račune.

Osim relacije 1:M postoje još dve relacije 1:1 ("jedan prema jedan") ili M:M
("mnogo-prema-mnogo"). Treba napomenuti da se relacija M:M postupkom
normalizacije na naprimer takozvanu 3 normalnu formu eliminiše, a na taj način se
kontroliše i redundancija u bazi podataka.

Sledeći korak je da overimo ili obezbedimo mogućnost očuvanja

referencijalnog integriteta podataka "Enforce Referential Integrity". Ova opcija uvodi
ograničenja takva da slogovi tabele Racuni ne mogu biti formirani bez ispravno
formiranih slogova u tabeli Klijenti, a sa druge strane Access će sprečiti bilo kakvo
brisanje sloga u tabeli Klijenti, ako taj slog ima neku relaciju sa postojećim slogovima
u tabeli Racuni. Brisanje je moguće samo ako korisnik, to potvrdi na upozorenje
Accessa. Ovde ćemo kliknuti na dugme Create i na taj način je okončana izrada
relacije. Ekran Relationships bi trebalo da se ponovo pojavi, ali sa ubačenom
relacijom izmeĎu dve tabele kao što je to prikazano na sledećoj slici:

93
@ViPserbia

Slika 5.31. Primer - izgled povezanih tabela koje smo ţeleli povezati

Treba uočiti da simbol "1" (ukazuju na stranu "One"), a simbol beskonačnosti

∞ (ukazuje na stranu "Many") u relaciji 1:M. Na kraju je potrebno zatvoriti ovaj ekran
relacije i odabrati dugme Yes da bi sačuvali promene u obrascu Relationships.

Ako se kojim slučajem ne pojavi slika relacija na napred prikazani način to

znači da ste negde pogrešili u definisanju relacije. Da bi se to poprevilo osvetlite
veznu liniju i pritisnite tipku delete pa obrišite loše formiranu relaciju. Tada se vratite
na tab za tabele, pogledajte u Design view i proverite da li je polje KlijentID kreirano
kao ključ tabele Klijenti. Ako to nije slučaj, izvršite korekciju i ponovite aktivnost sa
ekranom za relacije Relationships pa napravite relaciju.

Na kraju ćemo rezimirati preĎenu temu. Ukratko moţemo reći da izrada nove
tabele zahteva da se obave sledeće aktivnosti:

1. Kliknite na Tables tab na glavnom ekranu Access-a

2. Kliknite na dugme New
3. Odaberite funkciju Design View i kliknite na dugme OK
4. Popunite imena kolona, tip podataka i opis kolona (ova kolona nije obavezujuća) za
svaku kolonu nvoe tabele
5. Odredite i obeleţite primarni ključ desnim klikom na polje u tabeli koje postaje
primarni ključ i onda iz padajućeg menija izaberite funkciju Primary Key.
6. Sačuvajte tabelu izborom funkcije Save u padajućem meniju File.

94
@ViPserbia

7. Zatvorite novo formiranu tabelu izborom funkcije Close u padajućem meniju File.

Ako ţelimo da promenimo opis postojeće tabele (naprimer da se doda, promeni

ili obriše polje potrebno je da uradimo sledeće):

1. Kliknite na Tables tab na Access-ovom glavnom ekranu

2. Osvetlite ime tabele koja se modifikuje i kliknite mišem na dugme Design view.
3. Napravite potrebne promene u definicijama kolona tabele ili dodajte novu ili
obrišite postojeću.
4. Sačuvajte tabelu izborom funkcije Save u padajućem meniju File.
5. Zatvorite novo formiranu tabelu izborom funkcije Close u padajućem meniju File.

Za dodavanje, brisanje ili izmenu podataka u postojećoj tabeli potrebno je

sledeće:

1. Kliknite na Tables tab na Access-ovom glavnom ekranu

2. Osvetlite ime tabele koja se modifikuje i kliknite mišem na dugme Open.
3. Napravite potrebne promene u podacima.
4. Sačuvajte tabelu izbor funkcije Save u padajućem meniju File.
5. Zatvorite novo formiranu tabelu izborom funkcije Close u padajućem meniju File

Izrada ili editovanje relacija izmeĎu tabela:

1. Dozovite padajući meni Tools i odaberite funkciju Relationships.

2. Za prikaz spiska tabela, desnim klikom pozovite poseban dijalog kutijicu i daberite
Add Tables
3. Za izradu nove relacije, prevucite preko polja ključa iz jedne tabele u drugu tabelu i
otpustite nad asociranim poljem druge tabele.
4. Da biste editovali postojeću relaciju, dvostrukim klikom preko relacione linije
pozovite potreban dijalog.
5. Da biste obrisali postojeću relaciju, kliknite na relacionu liniju i pritiskom na tipku
Delete će te obaviti brisanje uz prethodno upozorenje od strane softvera baze.

95
@ViPserbia

5.5. Izrada i izvoĎenje upita

Upiti omogućavaju pristup podacima smeštenim u tabelama i njihov prikaz na

ekranu ili štampaču. Pomoću upita se moţe pristupati jednoj tabeli ali se upiti mogu
praviti i nad više tabela. Primeri upita vezani za bazu podataka formiranu iz ovog
našeg primera (mala banka) bi mogli biti:
 Koji klijenti ţive u naprimer SCG (drţavna zajednica Srbije i Crne Gore)
 Koji računi imaju saldo manji od 500 Din
Prikazaćemo u nastavku kako se koristi odgovarajući Access-ov čarobnjak za
izradu upita nad jednom i više tabela.

5.5.1 Upiti nad jednom tabelom

Upiti nad jednom tabelom su korisni da se izvuku pogledi na podatke u tabeli

tako:
 da se prikazuju samo neke kolone u izlazu upita
 da se obavi sortiranje slogova odabrane kolone za sort odreĎenim redosledom
 da se obave odreĎene statistike nad slogovima kao naprimer izračunavanje zbira
vrednosti podataka u koloni ili prebrojavanje slogova u tabeli, ili
 filtriranje slogova tako da se vide samo oni slogovi koji zadovoljavaju neki
postavljeni kriterijum kao naprimer prikaz korisnika mini banke koji ţive u DZSCG
(SCG).
Kao i kod tabela, kreiranje upita moţe biti realizovano ili funkcijom Design
view ili odgovarajućim čarobnjakom Access-ovog segmenta za upite - Query. U
primeru koji sledi, koristićemo čarobnjak da bismo napravili upit. U Access-ovom
glavnom ekranu dolazimo do taba Queries kao što je to prikazano na sledećoj slici:

Slika 5.32. Primer - izgled menija Accessa povezanih tabela

96
@ViPserbia

Za izradu novog upita, kliknite na dugme New. Pojavljuje se meni sistem za

upite i tada treba odabrati čarobnjaka Simple Query i kliknuti na dugme OK (kao
što je pokazano na sledećoj slici):

Slika 5.33. Primer - izgled menija za izbor načina rada pri izredi upita

Prvi korak u Simple Query čarobnjaku jeste da se navede tabela nad kojom se
pravi upit i koje kolone (polja) će biti prikazane kao rezultat upita (izlaz upita). Tri
glavne sekcije ovoga su:

1. Tables/Queries - Odaberite iz spiska tabela onu koja vas zanima za kreiranje

upita.
2. Available Fields – Ovde je dat spisak raspoloţivih kolona odabrane tabele
3. Selected Fields – Ovde su data odabrana polja koja će se prikazati.

Naprimer odaberite tabelu preko padajućeg menija Tables/Queries pod

nazivom Klijent. Zapazite da se odmah posle toga pojavljuje i spisak raspoloţivih
polja (Available fields) koja pripadaju tabeli Klijenti. Na slici 5.34. je dat grafički
prikaz opisanog postupka.
Na levoj strani imate spisak raspoloţivih polja Available fields te preselite polja
Ime_i_Prezime, Adresa, Mesto i Drzava u zonu odabranih polja Selected Fields na
desnu stranu. To se radi tako da se označi odabrano polje i klikom na dugme ga
preseljavate.

97
@ViPserbia

Slika 5.34. Primer - izgled menija za izbor polja pri izradi upita

Ovo ponavljate za svako navedeno polje tabele koje ţelite da prenesete. Kada
ste ovo uradili, čarobnjak vam daje stanje kao što je pokazano na sledećoj slici:

Slika 5.35. Primer - izgled menija sa izabranim poljima za upit

98
@ViPserbia

Klikom na dugme Next se preseljavaju sva polja i nakon toga se dolazi do

poslednje tačke Simple Query čarobnjaka. Na kraju: upitu treba dati ime. Neka to
bude u ovom slučaju na primer qryklijenti.

Slika 5.36. Primer - izgled menija za definisanje imena upita

Opisanim postupkom, čarobnjak će napraviti novi upit sa nekom od opcija:

 Open the query to view information - ovo znači da će čarobnjak izvesti upit i
prikazati traţene podatke koji se nalaze u odabranim kolonoma,
 Modify the query design - čarobnjak će vas prebaciti na Design View i ovde će
vam biti dozvoljeno da modifikujete upit.

U ovom primeru, odaberite Open the query to view information – otvorite upit
da biste pogledali informacije i kliknite na dugme Finish. Kada se upit izvede,
dobijate samo ime korisnika, adresu, mesto i drţavu, ali se svi redovi pojavljuju kao
što se to pokazano na sledećoj slici:

99
@ViPserbia

Slika 5.37. Primer - izgled upita klijenti

Zatvorite ovaj upit preko menija File i odabirom funkcije Close. Nakon toga
dobijate standardni glavni ekran Access-a odnosno treba da se pojavi Queries tab. Pri
tome će se na Query tabu pojaviti novi upit qryklijent.

U sledećem primeru ćemo promeniti upit qryklijent tako da se prikaţu polja

(kolone) o korisnicima odreĎenih drţava. Da bi se ovo ostvarilo, koristićemo Query
Design View.
Pomoću funkcije Design view otvorite upit qryklijent, a zatim markirajte ime
upita klikom na njegovo ime i posle toga kliknite na dugme Design. Funkcija Design
view će vam omogućiti da dobijete ekran kao što je pokazano na slici 5.38.
Funkcija Query Design view ima dve glavne sekcije. U prvoj (gornjoj) sekciji,
pojavljue se spisak tabela (ili samo jedna tabela-u zavisnosti od toga šta je ranije
kreirano) zajedno sa pripadajućim kolonama tabele koje su na raspolaganju. U drugoj
sekciji se pojavljuju samo odabrane kolone (polja) koja se ţele dobiti sa upitom.

100
@ViPserbia

Slika 5.38. Primer - izgled upita klijenti – design view

Svako polje ima nekoliko opcija koje moţete pridruţiti polju:

 Field - Ime polja u tabeli

 Table - Tabela iz koje je došlo polje
 Sort - Redosled po kome će se sortirati imenovano polje (Ascending 
Rastući, Descending  Opadajući ili Not Sorted  Nesortirano)
 Show – Izbor da li da se polja u izlazu upita prikaţu ili ne
 Criteria - Označava koji kriterijum (filter) je postavljen za slogove za kreiranje
prikaza izlaza iz upita.

Pretpostavimo da u ovom primeru ţelimo da filtriramo samo slogove o onim

korisnicima koji ţive u drţavi sa oznakom DZSCG (SCG). Pri tome, ţelimo da
sortiramo sve slogove koji se odnose na polje po nazivima gradova: polje Mesto. Za
sortiranje polja Mesto, dovoljno je kliknuti u zonu Sort od polja Mesto. Odaberite iz
padajućeg menija opciju - tip Ascending (rastući abecedni redosled). Kao rezultat ćete
dobiti ekran kakav je prikazan na sledećoj slici:

101
@ViPserbia

Slika 5.39. Primer - izgled upita po mestima klijenata – design view

Da bismo napravili filter za prikaz klijenata mini banke Klijenti koji ţive u
drţavi DZSCG, potrebno je kliknuti na područje Criteria polja Drzava i otkucati
uslov = 'SCG'

Slika 5.40. Primer - izgled upita po drţavama klijenata – filtar SCG – design view

102
@ViPserbia

Uslov ='SCG' će kazati Access-u da se prikazuju samo oni slogovi čija

vrednost polja Drzava je ispunila jednakost tj. da je jednaka 'SCG'. Sada se moţe
izvesti ovaj upit tako da u padajućem meniju Query odaberete komandu Run. Izlaz
upita bi trebao da izgleda kao na sledećoj slici:

Slika 5.41. Primer - izgled rezultata upita po drţavama klijenata – filtar SCG

Na kraju treba sačuvati upit, zatvoriti aktivnosti i vratiti se na glavni ekran

Access-a.
U svrhu veţbanja, moţete koristiti čarobnjaka Simple Query i napraviti upit u
tabelu Racuni da biste prikazali sledeće kolone (polja) Broj racuna (broj računa), Tip
racuna (tip računa) i Saldo (saldo).

1. U glavnom ekranu Access-a treba kliknuti na tab Queries a zatim na dugme

New.
2. Odaberite opciju Simple Query wizard i posle toga kliknite na dugme OK.
3. Kada se nalazite u podmeniju Table/Queries: odaberite iz padajućeg menija
tabelu Racuni. Zatim preselite polja Broj racuna, Tip racuna i Saldo preko Selected
zone i kliknite na dugme Next.
4. Na sledećem podmeniju, bićete pitani da li ţelite da izaberete detaljni (detail) ili
sumarni (summary) upit. Odaberite detaljni upit i kliknite na dugme Next.

103
@ViPserbia

5. Ovom novom upitu moţete dati ime: QryRacuni i zatim kliknite na dugme
Finish.
Kao rezultat ćete dobiti izgled izlaza iz ovakvog upita otprilike kao na sledećoj
slici:

Slika 5.41. Primer - izgled rezultata upita po tipovima računa

Zatvorite upit preko padajućeg menija File odabirom funkcije Close. U

sledećem delu veţbe, promenićemo upit tako da se izlaz upita sortira po broju računa i
da se pokaţu samo oni računi koji imaju Vrstu štednje (Štednja).

1. Na glavnom Access ekranu pozovite tab Queries i obeleţite ranije napravljen upit
QryRacuni a zatim treba kliknuti na dugme Design.
2. Promenite redosled sortiranja za polje Broj racuna, tako da se prikazuje u
rastućem redosledu (Ascending).
3. Pored toga moţete dodati sledeći uslov za kriterijum Criteria: polje Vrsta racuna
treba da zadovolji uslov = 'Štednja'

104
@ViPserbia

Slika 5.42. Primer - izgled upita – Design view po tipu računa - Štednja

4. Upit izvodite tako da u padajućem meniju Query odaberete komandu Run. Izlaz bi
trebao da izgleda poput primera prikazanog na sledećoj slici:

Slika 5.43. Primer - izgled rezultata upita po tipu računa - Štednja

5. Na kraju, moţete sačuvati i zatvoriti upit i vratiti se na glavni ekran Access-a.

105
@ViPserbia

5.5.3. Upiti nad više tabela

Do sada smo kreirali upite koji se sprovode nad jednom tabelom. Sada ćemo
preći na prikazivanje mogućnosti da se upiti prave tako da se u njih uvlače podaci iz
više tabela. Na primer, pretpostavimo da neki menadţer ţeli da vidi listu svih
klijenata kao i koje tipove računa banka ospluţuje. Očigledno je da se upit pravi od
dve tabele Klijenti i Racuni. Kod takvih upita, Access će iskoristiti relacije
uspostavljene u takvim tabelama i dovesti vas do rešenja kako će se prikupiti podaci
za potrebe ţeljenog upita.
Pre nego što nastavimo sa radom napravimo 1:M (jedan-prema-više) relaciju
izmeĎu tabela Klijenti i Racuni koje su prethodno kreirane i na na;in koji smo opisali
u segmentu o kreiranju relacija.
Pre započinjanja procesa stvaranja upita nad više tabela, izabrane tabele se
moraju "osvetliti" u podmeniju Query, a zatim se klikne na dugme New da bi se
kreirao ţeljeni upit. Odaberite opciju čarobnjaka - "Simple Query Wizard" kao što
smo to činili ranije. Kada se čarobnjak odazove odaberite polje KlijentID i polje
Ime_i_Prezime iz tabele Klijenti, a zatim se prebacite na Tables/Queries i odaberite u
tabeli Racuni polja KlijentID, Tip racuna i Saldo. Rezultat ovakvog postupka bi
trebao da dovede pojave ekrana poput onoga prikazanog na sledećoj slici:

Slika 5.45. Meni za izbor odgovarajućih polja iz tabela za upit

106
@ViPserbia

Za nastavak postupka kreiranja upita kliknite na dugme Next. U sledećem

koraku čarobnjaka, pojaviće se opcija koja treba da obezbedi odgovarajuće nivoe u
kategoriji Summary (finalni prikaz). Za potrebe ove veţbe, ostavite podrazumevanu
opciju "Detail ..." kao što je prikazano na sledećoj slici i tada za nastavak kliknite na
dugme Next.

Slika 5.46. Meni za izbor detaljnog ili zbirnog upita

Na kraju, imenujmo upit kao naprimer "qryKlijentRacun" i kliknimo na dugme

Finish. Efekti izrade upita nad više tabela bi trebali da se pojave na ekranu i izgledaju
kao na sledećoj slici:

Slika 5.47. Rezultat upita nad više tabela

107
@ViPserbia

Kao što smo pokazali kod upita nad jednom tabelom, moţete i upite nad više
tabela da menjate tako da im dodajete dopunske filtere odnosno uslove za odabir
podataka koji će se prikazivati (preko alata Design view) (naprimer ţelimo prikazati
sve informacije za klijente koji imaju kao drţavu oznaku 'SCG').

Na kraju ćemo kao primer napraviti upit koji će se zvati "qryZbirni". Upit spaja
tabelu Klijenti (uključujući polja KlijentID i Ime_i_Prezime) sa tabelom Racuni
(uključujući samo polje salda ). U drugom koraku čarobnjaka, kliknite na opciju
Summary (umesto na Details) a potom kliknite na dugme "Summary Options...".
Isključite sve kućice u opcijama "Summary option" kao što su Sum (zbir), AVG
(prosek), Min i Max kao što je pokazano na sledećoj slici:

Slika 5.48. Meni za izbor odgovarajućeg upita

Rezultat stvorenog upita bi trebao da izgleda poput ekrana na slici 5.49.

U ovoj sekciji, prikazali smo osnovne korakei za izradu i izvoĎenje upita. Pri
tome, se moţe koristiti čarobnjak za izradu upita da bi se napravili jednostavni upiti
kojima se pristupa jednoj tabeli. Pored toga, moguće je modifikovati upit da bi se
ostvarilo sortiranje po nekoj koloni tabele ili da se filtriraju slogovi u tabeli.

Napravićemo na kraju kratak pregled postupka kreiranja upita uz pomoć

čarobnjaka:
1. Iz Access-ovog glavnog ekrana kliknite na tab Queries. Potom kliknite na
dugme New.
2. Iz taba Queries (upiti) na glavnom ekranu Access-a, kliknite na dugme New i
odaberite opciju čarobnjaka kojom kreirate upit nad jednom tabelom Simple Query.

108
@ViPserbia

Slika 5.49. Rezultat ostvarenog zbirnog upita nad dve tabele

Postavite se ispod Table/Queries: odaberite odgovarajuću tabelu nad kojom

pravite upit, a tada obeleţite polja u tabeli koja će se pojavljivati kao izlaz upita. Ako
pravite upit nad više tabela tada opet u Table/Queries potrebno je da odaberete da se
prikaţu dopunske tabele i odaberete potrebna polja tih tabela koja učestvuju u upitu.
3. Ako tabela sadrţi numerička polja, tada se mogu prikazivati ili detaljne ili
sumarne (zbirne) informacije kao rezultat upita (uključujući i funkcije kao SUM,
AVG, MIN i MAX).
4. Konačno, dajte ime novom upitu i kliknite na dugme Finish.

Često je korisno napraviti upit koga moţete da iskoristite u formi i/ili izveštaju.

109
@ViPserbia

5.6. Izrada forme i obuhvat podataka primenom forme

Forme za obuhvat podataka su glavno sredstvo za unos podataka i njihovih

promena u tabele u bazi podataka. U prethodnom tekstu, opisivali smo kako se dodaju
podaci u tabele upotrebom tabelarnog prikaza podataka u samoj tabeli. Forme za
obuhvat podataka nude bolje mogućnosti za izradu jednostavnog korisničkog
interfejsa jer će na njima pored polja za unos podataka biti i prateće oznake, a i druge
informacije koje su od koristi u radu (user-friendly interface)

MS Access softver omogućava nekoliko različitih načina izrade formi za

obuhvat podataka. One uključuju kreiranje formi manuelno (ručno) preko Design
View funkcije kao i preko niza čarobnjaka koji vas vode kroz proces kreiranja forme.
U ovom delu ćemo govoriti o osnovnim koracima prilikom izrade forme pomoću
čarobnjaka.
5.6.1. Izrada forme nad jednom tabelom upotrebom čarobnjaka
U ovom primeru ćemo napraviti jednu jednostavnu formu za unos podataka za
potrebe tabele klijenata mini banke Klijenti. Da bi započeli ovaj proces, na glavnom
ekranu Access-a treba kliknuti na tab Forms. Kao i kod drugih komponenti u Access-
u, postoje dugmići za kreiranje nove forme poput New, otvaranje potojeće forme
poput Open i dugme za modifikaciju postojeće forme Design. U ovom primeru za
potrebe veţbe, sada kliknite na dugme New da biste napravili novu formu.
Otvara se kućica za dijalog New Form sa nekoliko opcija za kreiranje nove
forme. U ovom priručniku sada izaberite čarobnjaka Form wizard. Na dnu kućice za
dijalog postoji podsetnik da zadate ime tabele ili upita koje koristite u novoj formi. U
ovom slučaju izaberite tabelu Klijenti (dobićete ekran poput onoga koji je prikazan na
sledećoj slici), a potom kliknite na dugme OK.

Klijenti

Slika 5.50. Meni za izbor načina izrade forme

110
@ViPserbia

U narednom koraku čarobnjaka Form wizard, treba da specificirate polja tabele

Klijenti koja će se pojavljivati na formi. Pretpostavimo da u ovom slučaju ţelimo da
se pojave sva polja. Preselite sva raspoloţiva polja sa strane Available Fields na
stranu Selected Fields kao što se to moţe videti na sledećoj slici. Posle toga kliknite
na dugme Next.

Slika 5.51. Meni za izbor polja prilikom kreiranja forme

Forme mogu biti napravljene sa različitim obrascima (šablonima) ili različitim

aranţmanima oznaka uz polja na ekranu.
 Columnar - Smeštaju se oznake na levu stranu svakog polja na formu. To je
veoma slično kao kada pravite papirnu formu izgleda tabele. Ovakav obrazac je
podesan za posmatranje podataka iz odreĎenog sloga u ţeljenom trenutku.
 Tabular - Smešta oznake polja na vrh ekrana a ispod toga se prikazuju svi
podaci te se koriste klizači "gore-dole" ili "levo-desno" za pomeranje ekrana da bi se
videli podaci koji prevazilaze gabarite ekrana. Ovaj tip kreiranja je sličan tabelarnom
prikazu kao što se dobija u naprimer Exel knjigama, a pogodan je za prikaz više
slogova istovremeno.
 Datasheet - Podaci se pojavljuju na isti način kao kada ih posmatrate ili
dodajete u tabelu.

111
@ViPserbia

 Justified (poravnato) - Smeštaju se oznake polja iznad svakog polja, a

proporcionalno su razmeštene po formi. Ovaj obrazac je pogodan za posmatranje
jednog sloga u odreĎenom trenutku nešto kao i kod Columnar šablona.
Za potrebe ovog primera, treba da izaberete obrazac Columnar kao što je
prikazano na sledećoj slici i kliknete na dugme Next.

Slika 5.52. Meni za izbor načina prikazivanja polja u formi

Access ima nekoliko primera za prikaz stilova kojima se odreĎuje kako će se

forma pojavljivati na ekranu, uključujući takve elemente kao što su fontovi, boje i
pozadine koje će se koristiti u formi. U ovom primeru izaberite stil Standard kao što
se to vidi na saledećoj slici a zatim kliknite na dugme Next.

Slika 5.53. Meni za izbor stila prilikom kreiranja forme

112
@ViPserbia

Kao finalni korak, treba dati ime formi: frmKlijentObuhvatPodataka, a potom

kliknuti na dugme Finish kao što je pokazano na sledećoj slici:

Slika 5.54. Meni za definisanja imena forme

Nova forma će biti napravljena sa čarobnjakom, a potom otvorena. Kao

rezultat treba da se pojavi ekran poput onoga koji je prikazan na sledećoj slici:

Slika 5.55. Izgled kreirane forme

113
@ViPserbia

Za navigaciju kroz polja u slogu treba koristiti tipku "Tab" (/) koja se vidi
na formi. Za kretanje kroz tabelu preko forme (da biste videli slogove), koristi se
navigaciona traka koja je smeštena pri dnu forme (u podnoţju forme).:

Slika 5.56. Izgled navigacione trake za kretanje kroz tabelu preko forme

Dugmad za navigaciju mogu da obave sledeće funkcije:

- Idi na prvi slog.

- Idi na prethodni slog.
- Idi na sledeći slog.
- Idi na poslednji slog.
- ProĎi poslednji slog i stvori uslove za unos novog sloga.

Na kraju treba zatvoriti formu i vratiti se na glavni ekran Access-a (potrebno je

da pozovete padajući meni File i unutar njega da odaberete funkciju Close).

Za otvaranje forme u bilo kom trenutku, dovoljno je samo da je odaberete

(osvetlite) preko odgovarajućeg imena koje se vidi na tabu Forms u glavnom ekranu
Access-a, a potom kliknite na dugme Open da biste otvorili formu.

Za veţbu, ćemo kreirati formu za obuhvat podataka iz tabele računa Racuni

koja je napravljena ranije i napunjena sa inicijalnim podacima za veţbanje.
1. Na glavnom ekranu Access-a kliknite na tab Forms, a potom na dugme New da
biste kreirali novu formu.
2. Odaberite čarobnjaka Form wizard i odaberite tabelu Klijenti a onda kliknite
na dugme OK.
3. Odaberite sva raspoloţiva polja ove tabele za prikaz na formi i kliknite na
dugme Next.
4. Odaberite obrazac Tabular pa kliknite na dugme Next.
5. Odaberite stil Standard pa kliknite na dugme Next.
6. Dajte formi ime naprimer: frmRacuniObuhvatPodataka. Potom kliknite na
dugme Finish da biste kreirali, sačuvali i pogledali novu formu.

Rezultat nove forme je prikazan na sledećoj slici:

114
@ViPserbia

Slika 5.57. Izgled nove forme za obuhvat podataka

Zatvorite ovu formu i vratite se na glavni ekran Access-a izborom funkcije

Close u padajućem meniju File.

Na kraju ćemo dati osnovne korake pri izradi jednostavne forme za obuhvat
podataka nad jednom tabelom, a to su:

1. Izaberite tabelu i čarobnjaka za forme.

2. Navedite sa kojim poljima (kolonama) ćete raditi na formi.
3. Navedite obrazac forme koji ţelite koristiti.
4. Navedite stil (fontovi, boje, itd.) za odabrani obrazac.
5. Sačuvajte, izradite i izvedite novu formu.

Na ovaj način smo obuhvatili osnovne korake koji se moraju proći da bi se

kreirala forma za obuhvat podataka. Access vam nudi niz čarobnjaka koji su
prilagoĎeni za tipične vrste jednostavnih formi sa minimalnom količinom rada. Za
napredniji rad nad formama trebalo bi da se fokusirate na funkciju Design View
ukoliko ţelite da promenite izgled forme odnosno da biste dodali ili izbacili polja i
oznake polja iz jednom već kreirane forme.

115
@ViPserbia

5.7. Kreiranje izveštaja

Izveštaji su slični upitima jer kao i oni pretraţuju i pronalaze podatke iz jedne
ili više tabela i kao rezultat prikazuju takve podatke. MeĎutim, za razliku od upita,
izveštaji omogućavaju formatiranje izlaza sa mogućnošću izbora fontova, boja,
pozadine kao i niza drugih mogućnosti. Izveštaji se često štampaju na papiru radije
nego da se gledaju na ekranu. U ovom segmentu ćemo pokriti oblast kreiranja
jednostavnijih izveštaja i to upotrebom odgovarajućeg čarobnjaka.

5.7.1. Kreiranje izveštaja nad jednom tabelom upotrebom čarobnjaka

U ovom primeru ćemo napraviti jednostavan izveštaj upotrebom jedne tabele.

Pri tome ćemo koristiti mogućnost Access-a da upotrebimo čarobnjaka za izveštaje.
Kao što smo radili kod kreiranja upita i formi, opet počinjemo od glavnog ekrana
Access-a gde biramo tab za izveštaje Reports. Za izradu novog izveštaja kliknite na
dugme New. Posle toga se pokreće dijalog New Report i dobijate ekran poput onoga
koji je prikazan na sledećoj slici. Odaberite zatim čarobnjaka Report wizard, a potom
odaberite tabelu za koju pravite izveštaj Klijenti. Za nastavak postupka kliknite na
dugme OK.

Klijenti

Slika 5.58. Izgled menija za izbor načina kreiranja izveštaja

U narednom koraku čarobnjaka Report wizard, treba da navedemo polja iz

tabele Klijenti koja će se pojavljivati na izveštaju. U ovom slučaju pretpostavimo da
ţelimo da se pojave sva polja. Preselite sva polja sa strane raspoloţivih Available
Fields na stranu odabranih polja Selected Fields, a zatim kliknite na dugme OK I
dobićete ekran kao na sledećoj slici.

116
@ViPserbia

Slika 5.59. Izgled menija za izbor polja kod kreiranja izveštaja

Sada imamo mogućnost da dodajemo i nivoe grupisanja u izveštaju primenom

opcije Grouping Levels. To je mogućnost kojom se grupišu slogovi u tabeli po jednoj
vrednosti za dato polje koje je odabrano kao vodilja. Pri tome se takva vrednost moţe
pojaviti samo jednom, a zatim se reĎaju slogovi koji zadovoljavaju taj kriterijum. U
našem slučaju, nećemo za sada koristiti ovu mogućnost tako da ćemo jednostavno
kliknuti na dugme Next.

Slika 5.60. Izgled menija koji omogućava grupiranje nivoa u izveštaju

117
@ViPserbia

U sledećem koraku, imamo mogućnost da izvršimo sortiranje po nekom polju

(koloni) kao i da specificiramo redosled sortiranja odabranog polja u izveštaju. U
ovom našem primeru ćemo sortirati slogove po polju KlijentID. Da bi realizovali
ovakvu ţelju, treba u padajućem meniju liste na broj 1 odabrati polje KlijentID, a
zatim treba kliknuti na dugme Next (dobićemo ekran kao što je pokazano na sledećoj
slici).

Slika 5.61. Izgled menija za izbor varijante sortiranja u izveštaju

U narednom koraku čarobnjaka se navode šabloni (obrasci) izveštaja. Postoje

tri opcije:
 Columnar - Postavlja oznake polja na levu stranu od pozicije polja. Ovo je
najsličnije papirnoj formi.
 Tabular - Postavlja oznake polja na vrh izveštaja, a ispod toga se smeštaju
(reĎaju) slogovi. Ovo je najsličnije prikazu podataka u Exel-ovim izveštajima.
 Justified - Smeštaju se oznake polja za svako polje i onda se takvo reĎanje širi u
izveštaju.
Generalno, izveštaji se prave u tabelarnom obrascu. Za ovaj primer, odaberite obrazac
Tabular, postavite orijentaciju Orientation stranice na Landscape ("pejzaţ") tako da
sva polja stanu na stranicu i da se proporcionalno rasporede. Na sledećoj slici je
prikazan efekat odabira, a zatim pritisnite na dugme Next za nastavak.

118
@ViPserbia

Slika 5.62. Izgled menija za izbor oblika i orjentacije izveštaja

U sledećem koraku se bira stil izveštaja. Za potrebe ovog primera, odaberite stil
Corporate, a zatim kliknite na dugme Next za nastavak.

Slika 5.63. Izgled menija za izbor stila izveštaja

119
@ViPserbia

Na kraju, dajte ime izveštaju - naprimer: rptKlijenti, a zatim kliknite na dugme

Finish da biste kreirali, sačuvali i prikazali izveštaj.

Slika 5.64. Izgled menija za definisanje imena izveštaja

Izlaz iz izveštaja je prikazan na sledećoj slici. Treba primetiti da na nekim

ekranima, poslednje polje, poštanski broj Zip ne moţe da se prikaţe bez skroliranja
(klizanja) na desno.

Slika 5.65 Izgled izveštaja rptKlijenti

120
@ViPserbia

Kada je izveštaj prikazan, on, pored toga što moţe biti posmatran na ekranu,
moţe biti odštampan ili moţe biti prenet u Microsoft Word ili Microsoft Excel
okruţenje. Dugmići koji se vide na gornjem delu ekrana imaju sledeće značenje:

Štampaj izveštaj

Zumiraj u odreĎeni region izveštaja

Prikaţi izveštaj sa jednom stranicom, dve ili više stranica

Zumiraj + ili - unutar izveštaja

Prenesi izveštaj u MS Word

Zatvori izveštaj

Zatvorite izveštaj i vratite se na glavni ekran Access-a, a zatim iz padajućeg

menija File odaberite funkciju Close pa pritisnite na dugme Close.
U nastavku ćemo kao veţbu napraviti izveštaj koji pokazuje sve informacije o
računima mini-banke.
1. Preko glavnog ekrana Access-a odnosno taba za izveštaje Reports pritisnite
dugme New.
2. Pozovite čarobnjaka za izradu izveštaja Report wizard, odaberite tabelu Racuni i
pritisnite dugme OK.
3. Odaberite sva polja tabele Racuni i prebacite ih u stranu Selected Fields a zatim
pristinite dugme Next.
4. Grupišite izveštaj preko identifikacije klijenta KlijentID tako što ćete pritisnuti na
polje KlijentID a potom pritisnite na dugme . (Slika 5.66)
Nakon toga pritisnite dugme Next.
- Izaberite da sortni pojam u izveštaju bude polje broj računa klijenta
Broj_Racuna.
- Treba primetiti da se pojavljuje jedno novo dugme koje se naziva Summary
Options (sumarne opcije). (Slika 5.67)
- Pritisnite na to dugme Summary Options.
- Odaberite da vam za sumiranje bude polje salda Saldo a potom odaberite opciju
sabiranja pojedinih iznosa u saldo Sum.. (Slika 5.68)
- Izborom ovakvog rada odnosno opcija dobićete podatke detalja Detail i podatke
sabiranja Summary. .. (Slika 5.68)
- Nakon toga kliknite na polje OK.

121
@ViPserbia

- Nastavite rad sa pritiskom na dugme Next.

Slika 5.66 Izgled menija za izbor opcije grupiranja u izveštaju

Slika 5.67 Izgled menija za izbor opcije sumiranja u izveštaju

122
@ViPserbia

Slika 5.68 Izgled menija za izbor opcije sumiranja i detalja u izveštaju

5. Odaberite da vam obrazac za izgled izveštaja bude Block layout, a zatim kliknite
na dugme Next.
6. Odaberite stil Corporate i kliknite na dugme Next.
7. Na kraju, dajte ime izveštaju AccountsReport i pritisnite na dugme Finish a potom
okončajte kreiranje, sačuvajte listu i generišite izveštaj.

Slika 5.69 Izgled izveštaja kreiranog na prethodno opisani način

123
@ViPserbia

Treba zapaziti da je grupisanje podataka (opcija Grouping) na nivou polja

KlijentID,a da se sabiranje iznosa obavlja u zbirni saldo preko funkcije Sum. Zatvorite
izveštaj tako što ćete se vratiti na glavni ekran Access-a pozivom padajućeg menija
File, a zatim izabrati funkciju Close.

Kao što je pokazano prilikom uveţbavanja izrade izveštaja, postojali su mnogi

načini da se naprave izveštaji za prikaz sumarnih, sortiranih i formatiranih podataka.
Dalje učenje o izveštajima će pokazati kako se mogu modifikovati obrasci upotrebom
funkcije Design View. Potrebno je više veţbati i raditi sa čarobnjacima za izradu
izveštaja da bi se mogli napraviti izveštaje raznih stilova i tipova.

124
@ViPserbia

5.8. Microsoft Access 2000 – dodatne mogućnosti

5.8.1 Switchboard Manager
Funkcija: Za izradu panela za izbor funkcija aplikativnog softvera (interfejs prema
korisniku)

Slika 5.70 Izgled menija za izbor Switch board managera

Pri generisanju Switchboard panela, prvi put Access upozori projektanta-programera

da menadţer ne moţe da pronaĎe odgovarajuće definicije u bazi i postavlja pitanje da
li da se nastavi (Yes) ili ne (No): U ovom primeru ćemo odgovoriti  YES

Slika 5.71 Izgled menija za odluku o kreiranju Switch board managera

125
@ViPserbia

Slika 5.72 Izgled menija za odluku o kreiranju Switch board managera

Slika 5.73 Izgled menija za definisanje imena novog Switch board managera

Slika 5.74 Izgled menija za definisanje komande pri kreiranju Switch board
managera

126
@ViPserbia

Srediti "Text", odabrati "Command" i odabrati "Switchoboar" objekat (forma,

izveštaja, izlaz iz aplikacije):

Slika 5.75. Izgled menija za definisanje pojedinih elemenata pri kreiranju Switch
board managera

Access generiše odgovarajuću formu "Switchboard" i tabelu "Switchboard Items".

Podrazumeva se (default) da na formi ima maksimalno 8 stavki.

SwitchboardID ItemNumber ItemText Command Argument

1 0 GLAVNI MENI Default

1 1 Obuhvat podataka o klijentima 2 frmCustomers

1 2 Obuhvat podataka o partijama 2 frmAccounts

1 3 Izveštaj o partijama - sve, po abecedi 4 rptCustomers-qry

imena klijenta

1 10 Izlaz iz aplikacije 6

Slika 5.76. Sadrţaj Switchboard Items tabele

127
@ViPserbia

Slika 5.77. Primer izgleda panela za izbor poslova minibanka.mdb:

Broj stavki na formi "Switchboard" se moţe menjati i traţi se minimalmo

reprogramiranje.
Koristimo Design View funkciju da promenimo VBA kod za formu Switchboard:

Klikom dozvati "CODE"

odn. VBA editor!

Slika 5.78. Primer izbora – pozivanja VBA editora za potrebe Switchboarda

128
@ViPserbia

Umesto 8 stavite npr. 10 i zatvorite prozor

VBA editora odn. vratite se u formu!

Slika 5.79. Primer VBA koda za potrebe Switchboarda

Na formi treba dodati još dva reda:

129
@ViPserbia

Slika 5.80. Izgled Switchboarda sa 10 stavki

Za ova dva reda dodata na formi moraju se prilagoditi odgovarajuće Properties-i -

osobine:
 Za dugme

Slika 5.81. Izgled komandnog menija za opciju – stavku broj 9

130
@ViPserbia

 Za tekst pored dugmeta

Slika 5.82. Izgled komandnog menija za opciju – stavku broj 9

odnosno "Option10" i "OptionLabel10" za poslednju dodatu stavku.

U Switchboard Items tabeli moţete i manuelno dodavati stvake umesto sa

Siwtchobaord Manager-om pri čemu treba da znate nuemričke oznake pojedinih
komandi:

OpenFormAdd =2
OpenFormBrowse = 3
OpenReport =4
ExitApplication = 6
RunMacro =7
RunCode =8
OpenPage =9

131
@ViPserbia

Slika 5.83. Podešavanje prve forme kod startovanja pristupa bazi podataka

Slika 5.84. Podešavanje kompresije baze podataka pri izlasku iz Access-a

132
@ViPserbia

Slika 5.85. Meni za izbor opcija

Slika 5.86. Meni za definisanje pojedinih opcija

133
@ViPserbia

Slika 5.87. Meni za postavljanje dugmeta za štampu (ekran/štampač)

Postupak je sledeći: U Toolbox odabrati alat CommandButton (obeleţeno sa krugom),

Slika 5.88. Meni za izbor menija odgovarajućih alata

134
@ViPserbia

Slika 5.89. Meni za definisanje grupe akcija i pojedinačne akcije

a zatim stisnuti dugme Next i odabrati izveštaj u Reports tabu - meniju za

izveštaje koji koristite za prikaz podataka:

Slika 5.90. Izbor izveštaja koji će biti pozvan aktiviranjem taba

Posle pritiska na dugme Next odabrati simbol na dugmetu:

135
@ViPserbia

Slika 5.91. Meni za definisanje teksta ili slike na tabu - dugmetu

Posle klika na Next promeniti tekst u naprimer MyPreviwerButton i kliknuti na

dugme Finish:

Slika 5.92. Meni za definisanje imena – naziva dugmeta

Potrebno je potom desnim klikom na dugmetu podesiti Properties:

136
@ViPserbia

Slika 5.93 Meni a za izbor osobina - properties dugmeta

137
@ViPserbia

Slika 5.94. Meni b za definisanje osobina dugmeta

Slika 5.95. Meni c za definisanje osobina dugmeta

138
@ViPserbia

Odlaskom na dogaĎaj "On Click" potrebno je još podesiti VBA kod tako da
naša rutina obezbedi prikaz onih podataka koji su u tekućoj formi, a ne prikaz svih
podataka u tabeli.

Generisan VBA kod koji treba promeniti:

Private Sub MyPreviewerButton_Click()

On Error GoTo Err_MyPreviewerButton_Click
Dim stDocName As String
stDocName = "rptCustomers-qry"
DoCmd.OpenReport stDocName, acPreview
Exit_MyPreviewerButton_Click:
Exit Sub
Err_MyPreviewerButton_Click:
MsgBox Err.Description
Resume Exit_MyPreviewerButton_Click
End Sub

Modifikovan VBA kod:

Private Sub MyPreviewerButton_Click()

On Error GoTo Err_ MyPreviewerButton_Click
If IsNull(Me![AccountID]) Then
MsgBox "Pre pregleda podataka mora se uneti NEKI podatak."
Else
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, ,
acMenuVer70
DoCmd.OpenReport "rptCustomers-qry", acPreview, , "[AccountId] = " &
[AccountId]
End If
Exit_MyPreviewerButton_Click:
Exit Sub
Err_MyPreviewerButton_Click:
MsgBox Err.Description
Resume Exit_ MyPreviewerButton_Click
End Sub

139
@ViPserbia

Rezultat pritiska na ovako definisano dugme je prikazan na sledećoj slici:

Slika 5.96. Izveštaj kao rezultat aktiviranja na prethodni način definisanog dugmeta

140
@ViPserbia

5.8.2 Look Up / Combo Box

Access nudi mogućnost da se na jednostavan način bez potrebe programiranja

koristi mogućnost da se tokom obuhvata podataka preko neke forme dozivaju podaci
iz raznih tabela na osnovu "slovne senzitivnosti". Ako se podatak ne pronaĎe u takvoj
tabeli onda se naprimer dvo-klikom aktivira dogaĎaj (event procedure) nad
odgovarajućim poljem forme. Dvo-klik treba da omogući poziv spoljne
korespondentne forme za unos podataka u odgovarajuću tabelu (bez napuštanja
glavne forme).

Ovo se sve realizuje pomoću Look Up (kod kreiranja tabele koja je u relaciji sa
nekom drugom tabelom) i modifikacijom LookUp-a izborom Combo box-a.

Kao primer uzećemo evidenciju knjiga sa odgovarajućim opisom tblKnjige:

Slika 5.97. Meni za definisanje tabele Knjige

141
@ViPserbia

Pretpostavimo ţelimo naprimer da kod šifre autora knjige ID_Autora doradimo

Look Up na sledeći način:

Slika 5.98. Meni za definisanje Combo Box u tabeli Knjige

SQL SELECT rečenica je napravljena pomoću integrisanog Access-ovog buildera:

Slika 5.99. Meni za pozivanje SQL naredbe u okviru Combo Box

Pre tabele tblKnjige, treba da se kreira posebna tabela tblAutori tj. tabela autora
knjiga:

142
@ViPserbia

Slika 5.100. Meni za definisanje tabele autora

IzmeĎu tabela tblAutori i tblKnjige postoji relacija takva da je primarni ključ u

tabeli tblAutori ID_Autora u relaciji sa stranim (foreign) ključem u tabeli tblKnjige
ID_Autora. Sada je potrebno da napravimo formu nad tabelom tblAutori:

Slika 5.101. Meni za definisanje forme za tabelu autora

Posle toga je potrebno da napravimo formu nad tabelom tblKnjige:

143
@ViPserbia

Slika 5.102. Meni za definisanje forme za tabelu knjige

Zahvaljujući Look Up odnosno Combo Box mogućnostima, čarobnjak (wizard)

za izradu forme je automatski napravio polje ID_Autora sa padajućim menijem "drop
down" (padajući meni za izbor podataka).

Slika 5.103. Meni - a za definisanje osobina polja ID_Autora

Ako pogledamo Properties – osobine polja ID_Autora videćemo da se u row

source javlja jedna SQL SELECT rečenica koja je kreirana u fazi izrade tabele
tblKnjige. Pored toga navodimo da ţelimo da vidimo drugu kolonu (column count)
(tj. ime i prezime autora) i da se prva kolona ne vidi (0 cm) a druga se vidi (4 cm).
Pored toga, obratite paţnju da je na ON DBL CLICK ubačena jedna procedura
dogaĎaja (event procedure):
144
@ViPserbia

Slika 5.103. Meni – b za definisanje osobina polja ID_Autora

Detalji o toj proceduri su sledeći:

Private Sub Id_Autora_DblClick(Cancel As Integer)

On Error GoTo Err_Id_Autora_DblClick
Dim lngId_Autora As Long

If IsNull(Me![Id_Autora]) Then
Me![Id_Autora].Text = ""
Else
lngId_Autora = Me![Id_Autora]
Me![Id_Autora] = Null
End If
DoCmd.OpenForm "frmAutori", , , , , acDialog, "GotoNew"
Me![Id_Autora].Requery
If lngId_Autora <> 0 Then Me![Id_Autora] = lngId_Autora

Exit_Id_Autora_DblClick:
Exit Sub

Err_Id_Autora_DblClick:
MsgBox Err.Description
Resume Exit_Id_Autora_DblClick
End Sub

145
@ViPserbia

5.8.3. Upotreba alata "Expression Builder"

U okviru dosadašnjeg izlaganja smo pokrili osnovne informacije o kreiranju

baze podataka i njenih objekata pomoću alata poznatog pod imenom Microsoft
Access. Ti objekti su tabele, upiti za pretraţivanje podataka, forme za obuhvat
podataka i izveštaji za prikaz podataka ili sumarni izveštaji na ekranu i / ili na hartiji
(štampani izveštaji). Pored toga smo objasnili izradu glavnog menija – Switch board
kao i Look Up opcije. U nastavku ćemo dati opis primene alata za primenu funkcija
Expression Builder

Expression Builder ima tri sekcije (obeleţeno sa 1,2 i 3):

Slika 5.103. Meni – b za definisanje osobina polja ID_Autora

1 Kućica za izraz: O gornjem delu sekcije za builder nalazi se kućica gde se

smešta izraz koji formirate uz pomoć Access-ovog alata builder. Pod izrazom se
podrazumeva bilo koja kombinacija matematičkih ili logičkih operatora, konstanti,
funkcija, imena polja iz tabela, formi ili upita, kontrole i svojstva (property) pri čemu
se izraz podvrgava oceni kao jedna vrednost. Primenjenim izrazima se mogu
obavljati izračunavanja, manipualcije sa znakovima (karakterima) ili testiranja
podataka. Donji deo sekcije ovog alata omogućava kreiranje elemanta izraza, a oni se
onda prenose u kućicu za formiranje izraza. Ukoliko dobro poznajete semantiku i
sintaksu Access-ovih programskih mogućnosti onda moţete direktno ukucavati sve
što je potrebno da se formira ţeljeni izraz neposredno u kućici za izraz.

2 Dugmići za operator: U srednjem delu sekcije builder alata se nalaze

dugmići koji su poznati pod opštim imenom operatori (znak ili simbol kojim se
obeleţava vrsta izračunavanja, koje će se obaviti unutar formiranog izraza. Postoje
matematički, logički operatori, operatori poreĎenja i operatori referenci). Ako
kliknete na neki od tih dugmića, Expression Builder prenosi operator na mesto gde se
zatekao kursor u kućici za izraz.

146
@ViPserbia

3 Elementi izraza: U niţem delu sekcije builder-a se nalaze tri kućice:

 Leva kućica sadrţi fasciklu u kojoj je lista tabela, upita, formi i izveštaja kao
objekata baze u kojoj se trenutno nalazite. Zatim sledi deo sa ugraĎenim
funkcijama (built-in) a onda dolazi deo sa funkcijama koje je napravio i
definisao sam korisnik (user-defined), potom konstante (vrednost koja nije
izračunata i prema tome se ne menja tokom rada. Na primer broj 210 ili tekst
"Kvartalni bilans". Napomena: Izraz ili vrednost koja proizilazi iz izraza nije
konstanta u Access-ovoj terminologiji), operatori i opšti (zajednički) izrazi.
 Srednja kućica sadrţi specifične elemente ili kategorije elemenata iz fascikle u
levoj kućici. Na primer, ako kliknete na ugraĎene funkcije (Built-In) u levoj
kućici, u srednjoj kućici se prikazuje spisak kategorija svih Microsoft Access-
ovih funkcija.
 Desna kućica daje spisak vrednosti bilo kojeg izabranog elementa, koga ste
izabrali u levoj i srednoj kućici. Na primer, ako ste kliknuli u ugraĎene funkcije
(built-in) u levoj kućici, a dobijete kategorije funkcija u srednjoj kućici onda u
levoj kućici dobijate spisak svih ugraĎenih funkcija odabrane kategorije.
 Napomena: Ako upotrebom ovog alata prenosite identifikatore koji su
reference polja u nekoj tabeli, ili kontrole, ili svojstva tada se obrazuje posebna
sintaksa. Na primer Forms![Orders]![OrderID] označava identifikator sa
vrednošću OrderID koja se dobija preko kontrole u formi Orders.

Primer

Pretpostavimo da u okviru aplikativnog softvera napravljenog za trgovine treba da

se napravi popisna lista nakon obavljenog popisa i da se vidi da li postoji manjak,
višak ili kakvo je stanje robe u magacinu u odnosu na stanje koje je evidentirano u
bazi – knjigovodstveno stanje.

Jedno od mogućih rešenja jeste da se izveštaj modifikuje ubacivanjem

odgovorajuće kućice za tekst (text-box) koje će imati radni naslov STANJE.

Najpre se iz menija Toolbox odabere alat "Text-Box":

Slika 5.104. Meni za izbor ţeljenog alata - u ovom slučaju Text box

147
@ViPserbia

Zatim se prenese na odgovarajući deo izveštaja, a potom se u unbound polju obavi

formiranje izraza koji će biti ugnjeţdeni (If-Then-Else struktura):

=IIF(([tblKol]-[rptKol])=0;"Ok!";IIF(([tblKol]-[rptKol])>0;"MANJAK";"VIŠAK"))

Koristimo Expression Builder:

Slika 5.104. Meni za definisanje odgovarajućeg funkcijskog izraza

Nakon izvršene modifikacije dobićemo izgled izveštaja u Design View u

obliku koji je prikazan na sledećoj slici.

148
@ViPserbia

Ovde se
klikanjem doziva
Expression
Builder

Slika 5.105. Meni izveštaja - report u Design View obliku za definisanje

odgovarajućeg funkcijskog izraza

Na na sledećoj slici je dat izveštaj koji je nastao kao rezultat ovakvog rada:

149
@ViPserbia

Lista artikala posle popisa

Šifra Artikla Nazivartikla JedinicaMere Kol Zatečeno stanje Razlika u popisu STANJE
1 tastatura kom 12 100 -88 VISAK
2 zvucnici kol 15 20 -5 VISAK

3 kablovi kom 200 10 190 MANJAK

4 disketa kol 300 5 295 MANJAK

5 olovke kol 20 20 0 Ok!

6 podloge za mis kom 333 333 0 Ok!

7 kucista kom 100 100 0 Ok!

8 stolovi kom 10 0 10 MANJAK

9 monitori kom 30 30 0 Ok!

10 tft-screen kom 25 20 5 MANJAK

11 hard diskovi kom 70 70 0 Ok!

12 maticne ploce kom 20 VISAK

13 zvucne kartice kom 25 VISAK

14 telefoni kom 50 VISAK

15 stampaci laser kom 130 VISAK

16 stampaci ink-jet kom 70 VISAK

17 toneri laser kom 80 VISAK

18 toneri ink-jet kom 35 VISAK

5. jun 2004 Page 1 of 2

150
@ViPserbia

5.9. Upotreba Makroa

Vaţno je napomenuti da za svako malo pa i srednje preduzeće Access kao alat

daje dovoljno dobre performanse i da nisu potrebne posebne specijalnosti. Ukoliko je
potrebno, mogu se primeniti odreĎeni matematički izrazi i funkcije zahvaljujući
upotrebi alata koji nudi Access pod nazivom Expression builder, zatim odreĎeni
makroi koje nudi Access kao gotove skupove naredbi kao i programske mogućnosti
Microsoft Access baza podataka (.mdb) koje su prisutne i koriste se pod nazivom
VBA - Visual Basic for Applications.

U nastavku su dati samo neki primeri načina primene makroa i VBA

Kao i sve druge funkcije vezane za objekte Accessa 2000, potrebno je

pozicionirati se na odgovarajući tab radi iskorišćenja mogućnosti rada sa makroima:

Slika 5.106. Meni za izbor opcije Makroi - Macro

Makroi se prave klikom na dugme New (ako je nov) ili desnim klikom na
makro koji se redizajnira kao što je pokazano na sledećim slikama.

151
@ViPserbia

Slika 5.107. Meni za definisanje Makroa - efekat klika na dugme NEW

Slika 5.108. Meni - Efekat desnog klika na odabrani makro macLOAD

152
@ViPserbia

Makroi su skupovi naredbi - instrukcija - akcija, koje se mogu koristiti za

potrebe automatizacije opštih poslova, najčešće u takozvanom paketnom (batch, a ne
on-line) radu. Grupisanjem makroa koje nudi Access 2000, moţe se sprovoditi
nekoliko poslova odjednom. Akcija je osnovni gradivni blok bilo kog makroa
odnosno isntrukcija koja se kombinuje sa nekom drugom akcijom radi automatizacije
poslova. Ponekad se pozivaju i komande preko makro jezika. To je slučaj na primer,
ako ţelimo da otvorimo (ranije napravljenu) formu ili da štampamo (ranije
napravljen) izveštaj. Pored toga, moţe se napraviti jedno komandno dugme na formi,
pomoću koga se doziva odgovarajući makro napravljen za štampu izveštaja

Slika 5.109. Meni za definisanje akcije i odreĎenog makroa

1. Kada se ţeli kreirati makro, unosi se akcija (postoji ograničen skup akcija
koje nudi Access 2000) (OpenReport).
2. Za tu akciju potrebno je navesti argumente akcije naprimer ime izveštaja
(Invoice) i mesto prikaza izveštaja (Print)

Makro moţe biti komponovan u sekvenci više akcija ili se moţe koristiti grupa
makroa koje je korisnik sam napravio. Moguće je koristiti uslovne izraze (naprimer
If...Then...Else ili Select Case naredbe). Ako je uslov zadovoljen obavlja se jedna ili
više operacija a ako nije operacija (-e) se preskače. Na sledećoj slici je dat prikaz
jedne serije akcija koje Microsoft Access izvodi svaki put kada se aktivira makro.

153
@ViPserbia

Slika 5.110. Meni - prikaz serije akcija koje izvodi odreĎeni makro

Na primer, ako ţelite da se nekoliko makroa, koji su nekoj relaciji sprovedu

odjednom. Neka je makro imenovan kao Buttons, a da su nanizana tri makroa
Employes, Products i Reps. Sva tri makroa izvode otvaranje odgovarajuće forme, a
makro Products izvodi još i dopunsku akciju MoveSize:

Slika 5.111. Meni - prikaz serije Makroa koji se izvode odjednom

Ukoliko koristite uslovljene akcije, onda na raspolaganju stoje neke akcije

ugraĎene u Accessu 2000 pri čemu se navodi kriterijum (uslov) grananja akcija.
Uslovi sluţe za grananje odnosno kontrolu toka rada makroa. Uslov je logički izraz
(ispunjen - TRUE ili nije ispunjen - FALSE odnosno YES/NO). Izraz moţe biti bilo
kakva kombinacija matematičkih ili logičkih operatora, konstanti, funkcija, imena
polja iz tabela i/ili formi, kontrola odnosno osobina (property) koje se sve ocenjuju
kao JEDNA vrednost i kao takva dobija se rezultat TRUE/FALSE ili YES/NO. Sledi
kratak prikaz jedne uslovljene akcije (IsNull) tako da makro "Review Products" radi
akciju MsgBox i StopMacro ako se pronaĎu šifre dobavljača koje nisu vrednosti nula:

154
@ViPserbia

Slika 5.112. Meni - prikaz uslovljenog aktiviranja Makroa

Microsoft Access 2000 u svom asortimanu nudi sledeće akcije:

Slika 5.113. Meni - prikaz Microsoft Access 2000 raspoloţivih akcija

155
@ViPserbia

Primer

Fakultet za menadţment ţeli da sačuva evidenciju o studentima koji su uradili

seminarske radove, diplomske radove i postdiplomske radove (magistarski i doktorski
radovi, specijalističke studije). Potrebno je u organizacionom smislu definisati ko šta
radi:

1. Operater: Mentor ili drugi zaposleni na F@M-u pomoću Exel obrasca

SpisakRadova.xlt formira listu. Operater moţe dati Exel knjizi bilo koje ime.
Operater dostavlja datoteku sa spiskom radova administratoru (disketa, CD, e-
mail, memory-stick,...).

2. Administrator: Svaka osoba koja je zaduţena za centralno prikupljanje

spiskova i aktiviranje Access-ovog makroa za punjenje tabele u bazi
SpisakRadova.mdb.

3. Administrator primljenu listu mora preimenovati u PuniListu.xls. Ako ţeli,

moţe u arhivske svrhe čuvati spiskove onako kako ih je formirao operater. To
znači da je ime Exel knjige PuniListu.xls rezervisano.

4. Baza podataka sa spiskom radova se nalazi u fascikli (folder) pod nazivom

C:\SpisakRadova. Ovo je obavezno ime jer je makro podešen na putanju čitanja
liste za punjenje na C:\SpisakRadova\PuniListu.xls.

5. Sve ostale akcije nad podacima administrator obavlja preko Access-ovog

menija (switchboard), koji se pojavljuje kod otvaranja baze podataka:

Dakle, obuhvat podataka je zamišljen i organizovan tako da svi asistenti

odnosno mentori grupa obavljaju obuhvat podataka baziran na upotrebi Exel šablona
(template) pod nazivom SpisakRadova.XLT. Dostavljanjem obuhvaćenih podataka na
nekom medijumu, administrator po aktiviranju odgovarajuće baze obavi SAMO
JEDNOM punjenje baze.

156
@ViPserbia

Slika 5.114. Meni - prikaz osnovnog menija za izbor posla

157
@ViPserbia

Slika 5.115. Prikaz - Izgled dela Exel-ovog šablona

Podaci se pomoću makroa macLoad prebacuju iz Exel knjige PuniListu.xls u

tabelu tblSpisakRadova

Columns
Name Type Size
RadoviID Long Integer 4
F1-Redni broj spiska Long Integer 4
F2-Smer Text 50
F3-Godina studiranja Text 50
F4-Predmet Text 50
F5-Tip rada Text 50
F6-Autor Text 120
F7-Naslov Text 50
F8-Mentor Text 50
F9-Školska godina Text 50
F10-Ocena Number 4
F20-Komentar Memo -

158
@ViPserbia

Primer Exel knjige PuniListu.xls (osloboĎeno od nepotrebnih informtivnih

poruka koje se javljaju u šablonu):

Slika 5.116. Prikaz – Primer Exel knjige PuniListu.xls

159
@ViPserbia

Slika 5.115. Prikaz – Makro koji olakšava rad macLoad

Obratite paţnju da se u TransferSpreadheet akciji forsira putanja Exel-ove

knjige PuniListu.xls jer se time ţeli izbeći da administrator pogreši.

160
@ViPserbia

5.10. Primena VBA (Visual Basic for Application )

Visual Basic je programski jezik orijentisan na upravljanje dogaĎajima (event
procedure). U primeni uz Access pored toga što zamenjuje i makroe VBA se koristi
uglavnom u sledećim situacijama:

 Kada se želi da upravljanje bazom kao i održavanje baze podataka bude

lakše: Kako su makroi posebni objekti, izdvojeni iz formi i izveštaja, iako ih koriste,
baza podataka moţe sadrţavati mnogo makroa koji odgovaraju na odreĎene dogaĎaje
u formama ili izveštajima, ali to je mnogo teţe u domenu odrţavanja. Nasuprot tome,
VBA je programski jezik orjentisan upravo na pisanje procedura za upravljanje
dogaĎajima, a na njima su zasnovane mnoge funkcije unutar forme ili izveštaja. Ako
premestite formu ili izveštaj iz jedne baze u drugu, zajedno će se preseliti i njima
pridruţene procedure za upravljanje dogaĎajima.
 Upotreba ugraĎenih funkcija ili izrada sopstvenih funkcija: Access sadrţi u
svojoj okolini mnogo ugraĎenih funkcija kao što je naprimer IPmt funkcija, kojom se
moţe recimo izračunavati plaćanje po osnovu kamate. Pored toga ove funkcije moţete
koristiti da obave kalulacije i bez toga da kreirate komplikovane izraze. S druge
strane, pomoću VBA moţete kreirati sopstvene funkcije ili da izvršavaju
izračunavanja koja prevazilaze mogućnosti ugraĎenih funkcija ili da zamene
kompleksne izraze. Nadalje moţete koristiti funkcije i u samim izrazima tako da su
opšte primenljive uz navoĎenje parametarskih listi sa vraćenom vrednošću.
 Opsluživanje poruka o greškama: Ako se ponekad pojavi nešto neočekivano
dok korisnik koristi bazu podataka, Access prikazuje poruku o grešci. MeĎutim,
greška moţe biti prilično misteriozna za korisnika, a naročito za one koji nisu
familijarni sa Access-om. Pomoću VBA se prave procedure koje detektuju grešku i
kada se ona pojavi prikazuje se odreĎena poruka koju sam programer osmisli i
predloţi akciju koju korisnik treba da preduzme.
 Kreiranje ili manipulisanje sa objektima U većini slučajeva, pronaći ćete da
je najlakše kreirati i menjati objekte preko mogućnosti koja se nudi u funkciji Design
view (kod tabela, formi, upita, izveštaja ili makroa). U nekim situacijama, meĎutim,
mogli bi poţeleti da manipulišete sa definicijom objekta u samom programskom
kodu. VBA vam dozvoljava da radite sve manipulacije sa svim objektima
raspoloţivim za javnu upotrebu od strane programera, a stoje na raspolganju u samoj
bazi podataka.
 IzvoĎenje akcija na sistemskom nivou Moţete da izvodite naprimer RunApp
akciju u makrou kojom dozivate neku aplikaciju baziranu na Microsoft Windows-u ili
MS DOS-u iz vaše sopstvene aplikacije, ali makro ne omogućava da izlazite iz Acces-
a i da se potom ponovo vraćate u bazu podataka. Korišćenjem VBA uvek moţete

161
@ViPserbia

overiti i proveriti da li neka datoteka postoji u sistemu ili ne, a to se radi uz pomoć
Automation ili dynamic data exchange (DDE) postupaka koje omogućavaju
komunikaciju sa svim Windows orijentisanim aplikacijama kao što su Microsoft
Excel, ili da pozivate funkcije iz Windows dynamic-link libraries (DLLs) biblioteka
(naprimer kalendar).
 Manipulacija slogovima u jednom trenutku: Moţete koristiti VBA za obradu
slogova "korak-po-korak" u jednom trenutku (naprimer za takozvane paketne obrade
(batch processing)) i da obavite operacije nad jednim slogom. Sa druge strane, makroi
rade sa svim slogovima bez izuzetka u jednom trenutku.
 Prenos argumenata u vaše VBA procedure: Moţete postaviti argumente za
potrebe makro akcija (u donjem delu Macro prozora) kod kreiranja makroa, ali ne
moţete ih menjati tokom izvoĎenja makroa. Ta vrsta ograničenja ne postoji, ako
koristite VBA, jer moţete napraviti procedure u koje prenosite spisak argumenata
(varijabli), a kao rezultat dobijate povratnu akciju procedure.

U nastavku su date dve slike. Na prvoj se prikazuje kako se doziva VBA

okruţenje, a na drugoj se daje primer sadrţine. VBA omogućava da tokom rada sa
bazom podataka uključite i tzv. debugger (komponenta kojom se prati izvoĎenej
programa korak-po-korak tako da se prave prekidne tačke ili se program zasutavlja na
mestu greške npr. u sintaksi i sl.). Detalji rada sa VBA komponentom su sadrţani u
posebnom predmetu.

Slika 5.116. Način pozivanja VBA okruţenja

162
@ViPserbia

Slika 5.117. Primer koji pokazuje sadrţinu VBA okruţenja

Ovim izlaganjem se ne završava zadatak studenata, nego oni treba da dalje

izučavaju i stiču šira znanja o Access-u i osposobljavaju se za rad sa drugim
mogućnostima Access-a od kojih su mnoge objašnjene u okviru Access-ovog Help-a.

163
@ViPserbia

5.11. Pravljenje poštanskih nalepnica

U okviru ovog segmenta ćemo opisati postupak izrade poštanskih nalepnica

primenom Accessa i njegovih čarobnjaka koji su se pokazali veoma pogodnim za ovu
namenu.
Pretpostavimo da ţelite da pošaljete neke informacije ili čestitke svojim
poslovnim partnerima. Umesto da se na svaku kovertu kucaju kompletni adresni
podaci poslovnih partnera, oni se primenom odgovarajućeg čarobnjaka mogu pozivati
iz Access baze poslovnih partnera i štampati na nalepnice ţeljenog oblika i veličine i
tako odštampani zalepiti na koverte. Na taj način se obezbeĎuje mnogo veća
efikasnost u radu, kao i veća tačnost. Pored toga obezbeĎena je i mogućnost
sortiranja u skladu sa ţeljama ili pak zahtevima korisnika.

U Accessu 2000 komplet poštanskih nalepnica je samo vrsta izveštaja čiji

izgled odgovara nalepnicama. Izveštaj u vidu poštanskih nalepnica uzima imena i
poštanske adrese iz baze podataka, sortira ih zadatim redosledom i priprema ih za
format nalepnica koji izaberete. Pomoćna alatka Label Wizard vas vodi kroz postupak
pravljenja izveštaja sa poštanskim nalepnicama.
Izveštaj koji će posluţiti kao poštanska nalepnica dizajniran je kao poštanska
nalepnica (sa odgovarajućim tipom slova, rasporedom i redosledom sortiranja), ali
nema imena i adrese koje bi se štampale na nalepnicama za koverte. Ti podaci se i
dalje nalaze u tabeli poslovnih partnera koja se aţurira u skladu sa potrebama
svakodnevnog posla u preduzeću. Svaki put kada se koristi izveštaj sa poštanskim
nalepnicama, Access uzima najnovije podatke iz baze podataka. Postojeći dizajn
izveštaja biće sačuvan i moţe ponovo da se koristi, ali su podaci uvek aţurni.
U ovom primeru ćemo pokazati kako da uz pomoć čarobnjaka Label napravite i
štampate nalepnice sortirane po poštanskim brojevima. Stavite nalepnice u štampač i
sada ćemo videti kako ih pripremite.
Postupak je sledeći:
- U prozoru Database mora da bude prikazana lista izveštaja.
- Na paleti alatki prozora Database pritisnite dugme New.
Otvara se okvir za dijalog New Report.
- Iz liste sa desne strane okvira za dijalog New Report izaberite Label Wizard.
- Otvorite padajuću listu New Report pritiskom na dugme sa strelicom i izaberite na
primer tabelu vaših poslovnih partnera ili moţemo izabrati i našu kreiranu tabelu
Klijenti.
@ViPserbia

Tabela Klijenti sadrţi sve informacije o poslovnim partnerima, uključujući imena

i adrese.
- Pritisnite OK.
Otvara se prvi okvir za dijalog čarobnjaka Label i vi sad moţete da izvršite
izbor odgovarajuće nalepnice. Ako nijedna nalepnica sa liste ne odgovara vašim
potrebama, sami definšite dimenzije prema nalepnicama koje koristite.
Access ima obimnu biblioteku standardnih formata nalepnica sortiranih po
proizvoĎaču i dimenzijama u engleskim jedinicama mere (inčima) ili jedinicama
metričkog sistema (milimetrima) za štampače koji koriste pojedinačne listove papira
ili beskonačnu štampu.
Kada utvrdite koji format nalepnica je za vas najprikladniji
- U okviru sa listom Filter By Manufacturer izaberite nalepnicu po proizvoĎaču
- Za jedinicu mere izaberite English ili cm po ţelji.
- Pod Product number izaberite red koji odgovara tipu nalepnice koji ste odabrali.
- Pritisnite Next.

Otvara se drugi okvir za dijalog čarobnjaka Label koji vam omogućava

detaljnije doterivanje nalepnice. Tak onbaprime za nalepnice koje pravite moţete da
izaberete bilo koji tip slova, koji je instaliran na vašem računaru i bilo koju boju koju
podrţava štampač. Izbor tipa slova moţe da zavisi od vrste štampača. Na primer, neki
štampači podrţavaju za više veličina slova isti font ili više atributa formatiranja
(polucrno ili kurziv) od drugih štampača.
Dalje doterivanje se moţe ostvariti u pogledu teksta. Da bi poštanske nalepnice
imale poseban i lep izgled i da bi na najbolji način odrazile imidţ preduzeća, moţda
moţete koristiti kurzivni font Century Gothic Light veličine 9 tačaka.
- U drugom okviru za dijalog čarobnjaka Label, iz liste Font Name izaberite Century
Gothic light.
Pretpostavimo da kao poruku ţelite da dodate reč Informaciju. Reč Informacija
u okviru sa primerom se ispisuje se fontom Century Gothic light.
- Iz liste Font Size izaberite 9.
Veličina slova reči Informacija u okviru sa primerom se menja u 9 tačaka.
- Potvrdite polje Italic.
Reč Informacija se ispisuje kurzivom.
- Pritisnite Next.

165
@ViPserbia

Otvara se treći okvir za dijalog čarobnjaka Label, koji vam omogućava

odreĎivanje rasporeda elemenata nalepnice.
Iz tabele Klijenti moţete da izaberete bilo koje polje i da ga stavite na
čarobnjakov prototip nalepnice onako kako vi ţelite da odgovarajuća informacija
bude odštampana. Pretpostavimo da ţelite da koristite raspored podataka u tri reda sa
punim imenom kupca i standardnom adresom u dva reda. Takav raspored tada
primenjujete na nalepnicu. Osenčena traka pokazuje koji red treba da popunite na
nalepnici.
Pored toga moţete da izaberete naziv polja i zatim pritisnete na Add.
- U trećem okviru za dijalog čarobnjaka Label, iz liste Available Fields sa dva pritiska
na taster miša izaberite FirstName.
Polje FirstName se dodaje prvom redu prototipa nalepnice i na kraju polja se
pojavljuje kursor.
- Pritisnite razmaknicu.
Iza polja FirstName na nalepnici se pojavljuje prazno mesto.
- U listi Available Fields, pritisnite dva puta last Name.
Polje lastName dodaje se iza polja FirstName u prvom redu nalepnice, sa
jednim razmakom izmeĎu dva polja.
Ako pogrešite, izaberite red na prototipu nalepnice i pritisnite taster Backspace
da biste unetu vrednost uklonili.
- Na kraju prvog reda nalepnice pritisnite Enter.
Kursor i osenčena traka premeštaju se u drugi red prototipa nalepnice.
- U drugom redu dodajte polje Ulica i pritisnite Enter.
- U trećem redu dodajte polja Mesto i Poštanski broj.
Unesite zarez i razmak od jednog mesta izmeĎu polja Mesto i razmak izmeĎu
polja Mesto i Poštanski broj. Pritisnite Enter.
- U četvrtom redu dodajte polje Country.
- Pritisnite Next. Pojavljuje se četvrti okvir za dijalog čarobnjaka label.

Sortiranje nalepnica prema poljima

Tabelu Klijenti moţete da sortirate prema bilo kom polju. Moguće je sortiranje
i prema više polja. Na primer, moţete da sortirate po prezimenu a zatim po imenu da
biste dobili sve nalepnice sa prezimenima sortiranim abecednim redosledom i na

166
@ViPserbia

kojima su sva ista prezimena sortirana abecednim redosledom po imenu.

Da biste grupisali sva pisma čije su adrese u istom regionu, nalepnice sortirajte
po poštanskim brojevima.
- U četvrtom okviru za dijalog čarobnjaka label, iz liste Available Fields pritisnite dva
puta Poštanski broj.
Listi Sort By dodaje se polje Poštanski broj.
- Pritisnite Next.

Pojavljuje se poslednji okvir za dijalog čarobnjaka label. Access 2000 predlaţe

naziv labels Klijenti za izveštaj sa poštanskim nalepnicama i daje vam mogućnost da
vidite kako će nalepnice izgledati kada se odštampaju ili da ih izmenite.
Sada ćemo videti kako da snimite izveštaj i štampate nalepnice kad god vam
trebaju.
- U poslednjem okviru za dijalog label izaberite opciju See the labels as they will look
printed i pritisnite Finish.
Izveštaj sa poštanskim nalepnicama se snima kao labels Klijenti i otvara se u
prikazu Print Preview.
Ukoliko ţelite da odštampate taj izveštaj:
- Na paleti alatki Print Preview pritisnite dugme Print.
Access štampa izveštaj labels Klijenti direktno na kompletu nalepnica koje ste
ubacili u štampač.
Kada se završi štampanje:
- U prozoru Report pritisnite dugme Close da biste zatvorili izveštaj.

167
@ViPserbia

5.12. Specifikacije za baze podataka u Microsoft Access-u

Atribut Vrednosti maksimuma

Veličina baze u Microsoft Access-u (.mdb 2 GB - prostor potreban za sistemske objekte
datoteka) ugraĎene po definiciji u .mdb bazu.
Broj objekata u bazi podataka 32.768
Moduli (uključujući forme i izveštaje sa 1.000
svojstvom HasModule postavljen na True)
Broj znakova u imenovanju bilo kog objekta MS 64
Access-a
Broj znakova u lozinci 14
Broj znakova u imenu korisnika ili imenu grupe 20
Broj konkurentnih korisnika nad jednom bazom 255
podataka

Specifikacije za tabele u Microsoft Access-u

Atribut Vrednosti maksimuma

Broj znakova u imenovanju tabele 64
Broj znakova u imenovanju kolone (polja) 64
Broj polja u jednoj tabeli 255
Broj otvorenih tabela istovremeno 2048; stvarni broj moţe biti i manji zato što postoje
tabele koje Microsoft Access otvara za svoje potrebe
(interno)
Veličina tabele 2 GB - prostor potreban za sistemske objekte ugraĎene
po definiciji u .mdb bazu.
Broj znakova u polju tipa Text 255
Broj znakova u polju tipa Memo 65.535 kada se podaci unose preko korisničkog
interfejsa; 1 GB memorisanih znakova ako se oni
unose preko programiranog interfejsa
Veličina polja OLE objekta (npr. JPG,...) 1 GB
Broj indeksa (ključeva) po jednoj tabeli 32
Broj polja u jednom indeksu 10

168
@ViPserbia

Broj znakova u poruci za validaciju unosa 255

Broj znakova u pravilima za validaciju 2,048
Broj znakova u opisu tabele ili opisu polja 255
Broj znakova u slogu (isključena su Memo 2,000
i OLE objektna polja)
Broj znakova u postavkama svojstava 255
polja (field property)

Specifikacije za upite u Microsoft Access-u

Atribut Vrednosti maksimuma

Broj prisilnih relacija 32 po jednoj tabeli minus broj indeksa koje su nad tabelom sa
poljima ili kombinacijama polja a koje nisu uvučene u
relacije
Broj tabela koje učestvuju u upitu 32
Broj polja koja učestvuju u jednom 255
skupu slogova
Veličina skupa slogova 1 GB
Ograničenje sorta 255 znakova u jednom ili više polja
Broj nivoa u ugnjeţdenim upitima 50
Broj znakova u ćeliji u rešetki za 1.024
izradu upita
Broj znakova za parametar u 255
parametrizovanom upitu
Broj AND uslova u WHERE ili 99
HAVING klauzuli SQL upita
Broj znakova u SQL naredbi pribliţno 64.000

169
@ViPserbia

Specifikacije za izveštaje i forme u Microsoft Access-u

Atribut Vrednosti maksimuma

Broj znakova u labeli (nalepnici) 2.048
Broj znakova u tekstualnoj kućici (text box) 65.535
Širina forme ili izveštaja 55.87 cm (22 in.)
Visina sekcije ( Section height ) 55.87 cm (22 in.)
Visina svih sekcija + zaglavlja sekcija (u Design view funkciji) 508 cm (200 in.)
Broj nivoa u ugnjeţdenim formama ili izveštajima 7
Broj polja ili izraza koje moţete da sortirate ili grupišete u 10
jednom izveštaju
Broj zaglavlja (header) i podnoţja (footer) u izveštaju 1 header/footer po izveštaju;
1 header/footer po stranici;
10 header-a/footer-a po grupi
Broj štampanih stranica koje se mogu generisati po jednom 65.536
izveštaju
Broj kontrola i sekcija koje se mogu dodati u toku ţivotnog 754
veka forme ili izveštaja - report
Broj karaktera u SQL naredbi koje sluţe kao osobine 32,750
Recordsource ili Rowsource forme, izveštaja-reporta, ili
kontrole (oboje .mdb i .adp)

Specifikacije za makroe u Microsoft Access-u

Atribut Maksimum
Broj akcija u makrou 999
Broj znakova u uslovu 255
Broj znakova u komentaru 255
Broj znakova u argumentu akcije 255

170
@ViPserbia

6. Rukovanje bazama podataka

Ova oblast je vrlo vaţna sama za sebe i mnoge tehnike su bile razvijene u te
svrhe počevši od vrlo jednostavnih podrutina do celih sistema za rukovanje bazom
podataka. Obzirom da se pod bazom podataka podrazumeva skup tabela koje se
odnose na istu oblast, u tom slučaju na primer tabele o ličnim podacima radnika,
plaćanjima, radu i efikasnosti itd. mogu formirati bazu podataka radnika. Takva baza
podataka ima daleko veće zahteve sa aspekta obrade podataka nego pojedine tabele
pošto upit ili unos nekog podatka mogu zahtevati nalaţenje uporednih elemenata u
nekoliko raznih tabela simultano. Organizacija i rukovanje bazom podataka u on line
reţimu rada je svakako jedna od kritičnih oblasti u celokupnoj postavci bilo koje baze
podataka..
U izboru najadekvatnijih oblika u rukovanju bazom podataka moraju biti uzeta
u obzir sledeća ključna pitanja:
- raspoloţivost memorijskog medija
- lakoća i efikasnost programiranja
- način korišćenja baze podataka,
- frekvencija pristupa,
- zahtevano vreme odgovora,
- frekvencija i obim aţuriranja itd.
- cena programiranja i korišćenja, plus cena baza podataka
- sigurnost koja podrazumeva odrţavanje integriteta baza podataka, autorizaciju
pristupa, zaštitu od dupliciranja itd.
Projektant prema tome ima veoma teţak zadatak u traţenju najboljeg rešenja
uzimajući u obzir sve ove faktore. Pored toga analiza moţe značajno varirati od
jednog slučaja do drugog.

Do pojave PC računara baze su uglavnom bile smeštene na centralnim – host

računarima. MeĎutim sa uvoĎenjem PC-a u svakodnevno poslovanje i baze su se
počele koristiti na PC opremi. Obrada baza podataka u PC i PC/LAN mreţama se
pokazala veoma pogodnom za segmente ili odelenja velikih firmi. Naime niska cena u
poreĎenju na prethodne i visoka raspoloţivost ovih sistema su im davali značajnu
prednost u odnosu na host rešenja. Izrada aplikacija na PC opremi je bila takoĎe brţa,
jednostavnija i jeftinija. Iako se obrade na hostu mogu izvršiti brţe nego na PC
računaru zbog veće raspoloţivosti PC računara svakom pojedinom korisniku je bilo
brţe da obradu izvrši kod sebe na PC- u nego da čeka raspoloţiv slobodan termin na
host-u.

171
@ViPserbia

Male korisničke, na PC-u bazirane baze, podataka su prerastale u PC-LAN

bazirane baze podataka. Ove baze i brzina pristupa i obrade su bile zadovoljavajuće
sem ako su u pitanju bile veoma velike baze podataka ili pak kada je trebalo povezati
nekoliko takvih mreţa kada se kao problem javljala redundantnost podataka,
dupliciranje ili povećana neispravnost zbog unosa od strane mnogo različitih
korisnika i nejedinstvene kontrole unosa.
Pored toga kod različitih upita i pretraţivanja dešava se da pojedini korisnici ne
poznajući dobro način rada sa bazama podataka blokiraju ili prenose često velike
blokove podataka usporavajući ili ometajući značajno rad ostalih korisnika.

172
@ViPserbia

7. Distribuirne baze podataka

Sa razvojem mreţa javila se potreba da se baze podataka mogu koristiti od

strane korisnika koji su se nalazili na raznim često i veoma udaljenim lokacijama.
MeĎutim dok su se baze podataka u početku nalazile na jednom mestu u glavnom,
odnosno centralnom računaru, kasnije sa daljim razvojem računarskih mreţa i mreţne
distribucije - podele računarskih resursa, javila se potreba da se i baze podataka
raspodele – distribuiraju na više lokacija odnosno na nekoliko različitih računarskih
resursa.
Tako su razvijene takozvane distribuirane baze podataka koje su smeštene
ponekad i na par stotina računara sa pojedinim segmentima baze pri čemu korisnik
koji koristi bazu ima utisak da su svi ti podaci smešteni na jednom mestu.

Distribuirane baze podataka su uvedene prevashodno zbog:

 Povećane raspoloţivosti podataka
 Korisnik moţe pristupiti podacima lokalno ili nekom udaljenom
čvorištu preko tzv. "poveznice baze podataka" (data base link),

Ovakav tip organizovanja baza podataka je sve više u porastu zahvaljujući

ubrzanom razvoju brze komunikacione infrastrukture.

Autor teorije relacionih baza podataka C. J. Codd je koncipirao i 12 pravila za

distribuirane baze podataka koje se sve više danas implementiraju od strane
proizvoĎača softvera za upravljanje bazama podataka:

Pravilo 1:
Nezavisnost lokalnog sedišta baze podataka: Svako sedište u sistemu DDB –
Distributed Data Base – distribuirane baze podataka bi trebalo da funkcioniše
nezavisno i da se pri tome poštuju i očuvaju vitalne funkcije upravljanja bazom
podataka:
- bezbednost,
- kontrola konkurentnosti pristupa podacima
- arhiviranje
- oporavak podataka

Pravilo 2:
Nezavisnost centralnog sedišta baze podataka: Svako sedište u sistemu
distribuiranih baza podataka funkcioniše nezavisno u odnosu na centralno sedište i u
odnosu na sva udaljena sedišta.

173
@ViPserbia

Napomena: Sva sedišta bi trebala da imaju iste mogućnosti, čak i ako neko
sedište ne moţe da zadovolji sve te mogućnosti u jednom trenutku.

Pravilo 3:
Nezavisnost pri greškama bilo koje vrste: Softver za upravljanje bazama
podataka bi trebalo da bude neosteljiv na greške čvora ili čvorišta tako da ostatak
čvorišta i softver za upravljanje distribuiranim bazama podataka (DDBM) kao celina
moţe da nastavi sa radom.
Napomena: Na sličan način DDBMS – Distributed Data Base Management
System bi trebalo da nastavi sa radom i kada se dodaju nova čvorišta.

Pravilo 4:
Transparentnost lokacije: Korisnici ne bi trebalo da imaju nikakvo saznanje o
lokaciji podataka prilikom pretraţivanja.

Pravilo 5:
Transparentnost fragmentacije: Korisnik ne bi trebalo da niti da ima ikakvo
saznanje o fragmentaciji (iscepkanosti) distribuirane baze podataka. Korisnik moţe
pretraţivati podatke bez potrebe da zna da li su oni fragmentirani unutar distribuirane
baze podatka.

Pravilo 6:
Transaparentnost replikacije: Korisnik bi trebalo da bude u mogućnosti da
koristi distribuiranu bazu podataka bez saznanja da li su ili ne podaci replicirani
unutar sistema baze podataka.

Pravilo 7:
Obrada distribuiranih upita: Trebalo bi da postoji mogućnost upita da se izvede
u bilo kom čvorištu sistema za upravljanje distribuiranom bazom podataka koja sadrţi
relevantne podatke traţene preko upita. Nekoliko čvorišta moţe učestvovati u
odgovoru na korisnikov upit a da pri tome korisnik ne mora da zna gde je pronaĎen
podatak (u slučaju zadovoljavanja kriterijuma u selekciji podatka).

Pravilo 8:
Distribuirana obrada transakcija: Transakcijom se moţe pristupiti i menjati
podatak na nekoliko različitih sedišta unutar sistema distribuirane baze podataka bez
saznanja i učešća korisnika tokom izvoĎenja transakcije.

174
@ViPserbia

Pravilo 9:
Nezavisnost hardvera: Distribuirana baza podataka i njoj pridruţeni sistem za
upravljanje distribuiranom bazom podataka bi trebalo da se implementira na bilo
kojoj pogodnoj paltformi tj. na bilo kom računarskom sistemu sa odgovorajućim
hardverskim resursima bez obzira na to koja kompanija je proizvela računar.
Naţalost jedan broj današnjih sistema distribuiranih baza podataka još uvek ne
zadovoljavaju ovaj cilj, tj. ovo pravilo.

Pravilo 10:
Nezavisnost operativnih sistema: Distribuirana baza podataka i njoj pridruţeni
sistem za upravljanje distribuiranom bazom podataka bi trebali da budu sposobni da
se implementiraju na bilo kom pogodnom operativnom sistemu tj. operativni sistem bi
trebalo da bude sposoban za opsluţivanje različitih i mnogobrojnih korisnika.
Napomena: Danas, ovaj uslov zadovoljavaju Windows 2000 i XP i različiti
varijeteti Unixa (uključujući i Linux).

Pravilo 11:
Mreţna nezavisnost: Distribuirana baza podataka i njoj pridruţeni sistem za
upravljanje distribuiranom bazom podataka bi trebali da budu sposobni da se
implementiraju na bilo kojoj pogodnoj mreţnoj platformi.
Napomena: U današnje vreme to su uglavnom sistemi za upravljanje
distribuiranom bazom podataka koji se izvode na Windows 2000 ili XP operativnim
sistetima, na raznim varijantama Unixa (preko Ethernet mreţe) i na Novell mreţama.

Pravilo 12:
Nezavisnost baze podataka: Dizajn distribuirane baze podataka bi trebala da
pokaţe sposobnost da bude podrţana sa zadovoljavajućim performansama i sa
sofisticiranim alatima koje obezbeĎuju proizvoĎači softvera za upravljanje
distribuiranim bazama podataka.

ProizvoĎači softvera i hardvera se dovijaju na razne načine da pronaĎu

optimalne algoritme za brzo i efikasno pretraţivanje podataka u sistemu upravljanja
distribuiranom bazom podataka odnosno pronalaţenje algoritama za izbegavanje
konflikata i zaglavljenih (deadlock) situacija.

Distribuirane baze podataka su najosetljivije na pitanju pojave otkaza u nekom

od hardverskih resursa.

Pri dizajnu distribuirane baze podataka polazi se od toga kao da je ona

centralno smeštena u jednoj bazi a preko mehanizama replikacije i paralelizma

175
@ViPserbia

(proširenje Coddovih 12 pravila) se u implementaciji obavlja distribucija. Paralelizam

jednostavno znači da se u sistemu distribuirane baze podataka definišu strateške
tabele na raznim lokacijama i svaka promena u tabeli na jednoj lokaciji se paralelno
obavlja u istim tabelama na drugim lokacijama. Replikacija podataka omogućava
raspoloţivost podataka u slučajevima havarija a paralelizam omogućava bolju
performantnost distribuirane baze podataka.

Primer:
Kompanija
"Turistička organizacija"

Sistem za distribuiranu obradu u rezervaciji karata

Klijent Klijent Klijent Klijent

Kontroler toka
rada
Menadžer
transakcijama

Menadžer Menadžer Menadžer Menadžer

resursima resursima resursima resursima

Letovi Hoteli Vozila Korisnici

CS 347 Lecture 2 3

Sedište baze podataka

London HongKong Beč Pariz

Slika 7.1. Primer sistema sa distribuiranom bazom podataka

Ovakva organizacija baze podataka ima smisla kod multinacionalnih ili

transnacionalnih kompanija sa sedištima na nekoliko kontinenata.

Podrazumeva se da se u ovakvoj koncepciji primenjuje tehnika replikacije i

paralelizma.

176
@ViPserbia

Zahvaljujući Internetu, pojavila se mogućnost i n-slojne (n-tier) arhitekture

dizajna baze podataka pa se opet razmišlja o napuštanju tehnologije distribuiranih
baza podataka.

177
@ViPserbia

8. Rad u mreţi

Savremeni način poslovanja podrazumeva da se rad informacionih sistema u

većini slučajeva odvija na mreţama računara, a to automatski podrazumeva da i same
baze kao nosioci informacionih podataka moraju da rade u mreţi. Većina baza
podataka poseduje ovu mogućnost, a one baze kod kojih nije na vreme razvijena ta
opcija su nestale sa trţišta. Pri tome su kod rada u mreţi prisutne dve osnovne
varijante.
U jednoj varijanti baza podataka je smeštena na jednom – centralnom računaru
tj. na njegovim hardverskim resursima, a korisnici, koji mogu biti rasporeĎeni bilo
gde u računarskoj mreţi, pristupaju tim podacima i u zavisnosti od nivoa dozvole
korišćenja baze izvode razne manipulacije sa podacima u bazi počevši od
pretraţivanja baze pa do aţuriranja pojedinih podataka ili pak celih segmenata baze.
U drugoj varijanti baza je rasporeĎena na nekoliko različitih računara i njihovih
hardverskih resursa na raznim segmentima mreţe i takva varijanta baze se naziva
distribuirana baza podataka.
Već kod prvih mreţa koje su bile namenjene za širu upotrebu pojavio se zahtev
da se koriste baze podataka. Tako naprimer kod nas su za manji broj računara bile
veoma široko rasprostranjene mreţe sa operativnim sistemima tipa Novell, Unix,
Xenix i na njima su veoma dobro funkcionisale pa čak i danas funkcionišu neke od
baza podataka kao što su Clipper, Fox pro, ZIM, Progress itd. U većim mreţama sa
većim brojem računara bile su korišćene, a i danas se koriste baze podataka kao što su
Oracle, Ingres, Informix itd.

Rad u mreži - primena

Tradicionalna 2-slojna arhitektura ili klijent-server arhitektura ima svoje

slabosti. Zbog intenzivne interakcije izmeĎu klijenata i servera dolazi do
preopterećenja komunikacija. Kompanije su zbog toga bile primorane da koriste
skupe iznajmljene veze sa širokim opsegom prenosa podataka. Pored toga, poseban
problem je bio odrţavanje aplikativnog sistema koji je morao imati svoju sliku i na
svakom klijentu: Poznata je priča o Oracle-ovoj aplikaciji Application (obuhvatala je
standardno poslovanje svake kompanije: knjigovodstvo, zalihe, fakture, kadrovi,
zarade itd.) koja se u toku godine menjala i do četiri puta pa su ekipe jedne kanadske
čeličane koja je imala oko 60 lokacija morale četiri puta godišnje da obilaze lokaciju i
rade instalaciju dopune ove aplikacije na klijentima (ukupno oko 650 klijenata)!

178
@ViPserbia

Osim toga, softverska arhitektura u klijent-server (2-slojnoj) arhitekturi je nepodesna

za elektronsko poslovanje.

Pojavila se nova filozofija za rad sa bazama podataka u mreţi posredstvom

Internet (Web) infrastrukture koja je pruţala veću fleksibilnost: n-slojna (u početku 3-
slojna arhitektura). Ovakav rad podrazumeva da se funkcionalnost aplikacije deli u tri
sloja koji su meĎusobno nezavisni, a na taj način se omogućava lakša integracija
poslovanja u okviru elektronskog poslovanja:

Sloj 1: Prezentaciona logika aplikacije (odnosi se na tzv. Web servere na

prednjem kraju (front-end))

Sloj 2: Poslovna logika aplikacije (odnosi se na servere opšte namene)

Sloj 3: Upravljanje bazom podataka (odnosi se na servere koji su domaćini baze

podataka ili Web server na zadnjem kraju (back-end)).

Osnovna ideja uvoĎenja ove tehnologije je značajno smanjenje troškova

potrebnog hardvera za realizaciju uz povećanje performantnosti korišćenjem brzih
komunikacionih linija sa naglaskom na upotrebu Internet infrastrukture (smanjenje
troškova najma iznajmljenih vodova). Pored toga, uvoĎenjem ovakve tehnologije
trebalo je da se omogući bezbednost pristupa podacima (autentifikacija, autorizacija i
kriptovanje pristupa) i transakciona obrada (rad u realnom vremenu) unutar Interneta i
Intraneta. Dopunski zahtev je bio i interoperabilnost raznorodnih proizvoĎača
hardvera i softvera.

U nastavku je dat pregled današnje situacije na trţištu n-slojne arhitekture:

Većina ponuĎača se u početku više orijentisala na Javu kao programski jezik i

platformu za razvoj n-slojne arhitekture.

 Klijent strana:
- Java VM (Virtual Machine) sa pratećim Javinim komponentama koje
omogućavaju Servlet korisničkog interfejsa i Servlet servera
- HTTP protokol osposobljen sa pratećim Web Internet pretraţivačem (Netscape
Navigator, Microsoft Internet browser, Sun-ova HotJava, Opera, …),
- Preko Ethernet mreţe (TCP/IP protokolom) (LAN ili Internet ili po pozivu
(dial-up)) se uspostavlja komunikacija sa serverom,

179
@ViPserbia

 Server strana (komponente) realizovane na raznim paltformama operativnih

sistema (UNIX, Sun Solaris, Windows 2000 ili XP, AS/400, Digital-VMS,
IBM-MVS, Linux-Red Hat ili SuSe ili Mandrake). Serveri imaju instaliran JDK
(Java Development Kit 2.1) za podršku ove tehnologije
- Web server (Apache, Orion Web server, Microsoft IIS, Java 2 Enterprise
Edition, Sun Java Web server,…)
- Servlet server (neki navedeni proizvoĎači Web server softvera uključuju i ovu
komponentu),
- Servleti za korisnički interfejs (pišu ga sami korisnici),
- Aplikativni softver za pristup bazi podataka (pišu ga sami korisnici),

 Baza podataka
- Tehnologija relacionih baza podataka (centralizovane ili distribuirane) (Oracle,
Microsoft SQL, Sybase, Ingres, Informix, IBM DB/2, MySQL, PostgreSQL
(RDBMS),
- Tehnologija objektno orijentisanih baza podataka (OODBS – Object Oriented
Data Base System).

Prednosti n-slojne arhitekture:

Iako su otklonjeni problemi 2-slojne arhitekture, ova tehnologija stvara i svoje

probleme, ali su oni još uvek takvi da ih prednosti umanjuju.

 Potpuno razdvajanje kontrole korisnikovog interfejsa i prezentacije podataka od

aplikativne logike. Ovo razdvajanje omogućava da puno klijenata ima
mogućnost pristupa raznim apliakcijama smeštenim na serveru bez narušavanja
performansi. Aplikativni kod nije smešten na klijentu što omogućava
centralizovanu kontrolu izmene aplikativne logike.
 Redefinisanje strategije smeštanja podataka bez uticaja na klijenta odnosno
klijent i ne zna način logičkog i fizičkog organizovanja baze podataka
(RDBMS i/ili OODBS). Ovo obezbeĎuje budućnost n-slojnoj arhitketuri jer
neće biti pod uticajem prelaska kompanije sa RDBMS na OODBS tehnologiju
organizovanja podataka.
 U dobro dizajniranom informacionom sistemu, klijent će još uvek pristupati
preko dobrog i stabilnog interfejsa sa ugnjeţdenim i nevidljivim delovima o
smeštanju podataka.
 Poslovne objekte i memorisanje podataka bi trebalo što više obuhvatiti na
jednom fizičkom mestu, na jednom serveru. To omogućava da se
preopterećenje mreţe umanji zbog eventualnih kompleksnih zahteva za

180
@ViPserbia

podacima od strane klijenta. Bolje rečeno, klijent dobije samo rezultate koji su
mu potrebni o poslovnom objektu unutar poslovne funkcije.
 Za razliku od 2-slojnog modela, gde se podacima pristupalo kao javno
dostupnim, poslovni objekti mogu da se smeste unutar aplikativne logike i da se
proglase "servisom" (uslugom) unutar mreţe. Na primer, identifikacioni broj
moţe se proveravati po modulu 10 ili 11, a kalkulacija ne mora biti uraĎena na
serveru nego na klijentu kao standardni servis tog klijenta.
 Serveri su osetljivi delovi sistema tako da autorizacija mora biti maksimalno
pouzdana i pojednostavljena prilikom naleta na stotine klijenata. Takvi
algoritmi i rešenja već postoje na trţištu.
 Upotreba jeftinih servera u grozdu (cluster) omogućava da se dinamički
balansira preopterećenje servera.
 Najvaţnija i najkorisnija pogodnost n-slojne arhitekture jeste jednostavna
izmena komponenti aplikativne logike na strani servera bez prenošenja izmene
klijentu. To je bila noćna mora onog dela kompanije koja se bavila razvojem i
odrţavanjem klijent-server modela.

Moguće šeme prikaza n-slojne arhitekture:

Dvoslojna arhitektura

Sloj 1: Sloj 2: Server obavlja sve

KLIJENT SERVER operacije

M
REŢ
A
Baza podataka

Slika 8.1. Primer dvoslojne arhitekture

181
@ViPserbia

3-slojna arhitektura

Sloj 1: Sloj 2: Sloj 3:

KLIJENT Server Server baze Aplikativni server
front-end prebacuje obradu
back-end
na sloj 3

Baza podataka

Slika 8.2. Primer troslojne arhitekture

n-slojna arhitektura

Optimizirano za Programira se Upravlja i

isporuku Web (kodira) za podešava DBA
stranice specifičnu
namenu poslovne
funkcije

Slika 8.3. Primer n - slojne arhitekture

n – slojna arhitektura

Odvajanje klijenta od servera je pruţalo programerima veliku

pomoć jer oni više nisu bili vezani za resurse jedne mašine kod
izvršavanja njihovih zadataka - poslova.

182
@ViPserbia

Resursi i implementacija su mogli biti pomereni na računar koji je

na najbolji način mogao da ostvari postavljeni zadatak. U stvari
aplikacije sa bazama podataka su rasle u svojoj kompleksnosti pa je
postalo više nego očigledno da će biti potrebne višestruke klase servera.
Relacione baze podataka su uvele mogućnost da izvrše obradu tako da je
administrator baze mogao da ugradi pravila integriteta i zaštite.
Aktivatori i memorisane procedure su počeli da izgledaju kao mali
programi u punom smislu reči.

U isto vreme je postalo očigledno da su baze podataka zahtevale

više obrade nego što je to striktno bilo potrebno sa aspekta integriteta
podataka. One su uvele pravila poslovanja: jedinice obrade ili algoritme
koji predstavljaju odreĎeni koncept vaţnosti za organizacije koje koriste
baze podataka. Pošto su poslovna pravila postala široko prihvaćena
potrebno ih je jednom ugraditi na centralni upravljački server. Pošto ona
nisu direktno vezana za integritet podataka ponekad nije jasno da li bi
ona trebala biti implementirana u relacione baze podataka primenom
odgovarajućih alata i jezika orijentisanih prema podacima.

Podaci su smešteni na jedan ili više servera podataka. Samo oni

programi koji su potrebni za pristup podacima i odrţavanje integriteta
baze se implementiraju na ovom sloju. Ovo uključuje SQL sistem za
upite i rukovanje transakcijama za komercijalne softvere kao i za
aktiviranje i memorisanje procedura napisanih za administratore baza
podataka

MeĎutim nasuprot modelu Klijent – server ova aktiviranja i

memorisanja su ograničena na aspekte upravljanja integritetom podataka
koji se nalaze u ovom sloju. Poslovna pravila su pomerena na nivo
aplikacione logike, ponekad preferisane kao poslovni servis ili srednji
nivo.

Pohranjene procedure u bazi podataka se ponekad koriste za

implementaciju i pojačanje poslovnih pravila. Dok ovo moţe da vodi
poboljšanju performansi, pristup ne ide u korak sa osnovnim konceptom
n-slojne arhitekture gde se niz za podatke n-tog sloja striktno čuva za
podatke.

Izraz n-ti sloj dolazi od činjenice da je aplikacioni logički sloj-nivo

podeljen na dalje logičke nivoe namenjene jednom ili drugom zadatku –
poslu. Aplikacioni nivo je veoma retko homogen.

183
@ViPserbia

Neki programeri vide podelu nivoa kao tri nivoa dok drugi vide
razne klase aplikacionih logika kao individualne nivoe.

Podela zadataka u tri ili više nivoa donosi sledeće pogodnosti:

- Podela prezentacije prema funkciji.

- Sposobnost optimizacije svakog nivoa kao nezavisne celine radi
poboljšanja performansi.
- Neograničen paralelalizam u vreme razvoja
- Sposobnost za izbor odgovarajuće platforme za svaki pojedini posao
zadatak

184
@ViPserbia

9. Bezbednost baze

Bezbednost baze je jedan od veoma vaţnih elemenata o kojima se mora voditi

računa prilikom eksploatacije neke baze. Pre nego što se neka baza preda korisnicima
na korišćenje mora se definisati primenom odgovarajućih identifikacionih metoda koji
korisnici će imati prava pristupa pojedinim podacima ili grupama podataka u smislu
dobijanja potrebnih podataka i pregleda, kao i koji korisnici će imati prava pristupa
bazi i pojedinim podacima ili grupama podataka u smislu mogućnosti da menjaju
bazu ili neke parametre, relacije ili polja u bazi.
Bezbednost sa aspekta prava pristupa

Kada neki korisnik kreira bazu, programski paket baze mu dodeljuje sva prava
manipulacije i kontrole nad tom bazom, a ista prava dobijaju i svi ostali korisnici
sistema. U realnim situacijama, meĎutim, svi korisnici nemaju i ne treba da imaju ista
prava pristupa bazi. U tom cilju, baza pruţa izdiferencirane metode dodeljivanja i
provere prava pristupa, na nivou baze, relacija i pogleda, za svakog korisnika
posebno.

Vrste prava pristupa

Kako je već pomenuto prava pristupa dodeljuju se preko liste prava pristupa
(Access Control List), u kojoj se za celu bazu, kao i za objekte u njoj, navodi ko im
sme pristupiti i kakve radnje sme da radi. Sličan pristup problemima bezbednosti
primenjen je obično i u samim operativnim sistemima gde se razlikuje tri vrste prava
pristupa:
 kontrolna prava, koja se odnose na mogućnost dodele drugih prava pristupa, u
početku ih ima vlasnik baze, koji ga sebi ne moţe uskratiti;
 definiciona prava, koja se odnose na pravo kreiranja novih objekata i menjanja
postojećih objekata u bazi, tj. na manipulaciju podacima u metabazi, i
 manipulaciona prava, kojima se dozvoljava manipulisanje podacima u bazi.

U tabeli 9.1 je prikazan primer raspoloţivog prava pristupa podacima u bazi

podataka, implementiran preko lista prava pristupa.

185
@ViPserbia

manipulaciona READ SELECT

WRITE INSERT
MODIFY UPDATE
ERASE DELETE
definiciona DEFINE CREATETAB
CHANGE ALTER
DELETE DROP
SHOW SHOW
kontrolna CONTROL DBCTRL
ADMINISTRATOR DBADM
OPERATOR OPERATOR

Tabela 9.1 Primer dodele prava

Prava pristupa se definišu posebno za celu bazu, a posebno za relacije i

poglede u njoj. Prilikom svakog pristupa bazi, baza najpre proverava da li korisnik
uopšte ima odgovarajuća prava da pristupi bazi, pa tek zatim i prava koja se odnose na
konkretnu relaciju/tabelu ili pogled. Pri tome, da bi se vršilo aţuriranje podataka u
nekoj relaciji/tabeli potrebno je imati pravo čitanja podataka iz nje (READ/SELECT),
a to pravo morate imati i ako ţelite da aţurirate definicije objekata u bazi.
Posebno, pravo pristupa nekom pogledu (query – upit) ne podrazumeva i pravo da
se pristupi baznoj relaciji/tabeli nad kojom je pogled definisan. Problemi mogu nastati
ukoliko takav korisnik ima pravo DEFINE, jer on tada moţe sam sebi da kreira
pogled kakav ţeli. Stoga pravo DEFINE treba da bude uskraćeno svim korisnicima,
osim projektantima baze i, eventualno, administratoru.
Korisnik koji je kreirao bazu moţe ostalim korisnicima da dodeli ili ukine sva
prava. Ovo vaţi i za njega samog, sa izuzetkom prava CONTROL/DBCTRL, koje se
moţe ukinuti samo uz pravo BYPASS, i pravo READ/SELECT, koje se ne moţe
ukinuti.

Dodeljivanje prava pristupa

Prava pristupa dodeljuju se korisnicima koji se mogu identifikovati (i

klasifikovati) na nekoliko načina.
Najpre, OPS – operativni sistem korisnike prepoznaje po korisničkom
identifikatoru, User Identification Code - UIC, koje moţe biti alfanumerički ili čisto
numerički.

Grupe korisnika mogu dobiti od upravnika sistema grupni identifitor, recimo

SEKRETARICE, PROGRAMERI i slično. Posebni sistemski identifikatori mogu da

186
@ViPserbia

posluţe podjednako dobro za istu namenu. Mogući sistemski identifikatori su:

BATCH, NETWORK, INTERACTIVE, LOCAL, DIAL-UP, REMOTE i oni
uglavnom zavise od načina pristupa računarskom sistemu.
Za svakog korisnika ili grupu korisnika sa odgovarajućim identifikatorom, mogu
se definisati dozvoljena prava pristupa. Ona se pamte u ACL listi – autentifikaciono
kontrolna lista – Autentification Control List, koju SUBP ispituje prilikom svakog
pristupa bazi. Redosled navoĎenja identifikatora pojedinih korisnika, pritom, moţe
biti veoma značajan. Naime, prilikom odreĎivanja da li neki korisnik ima prava da
izvrši traţenu operaciju, SUBP ispituje listu prava pristupa od početka prema kraju,
sve dok ne naĎe prvi identifikator koji odgovara identifikatoru korisnika.
Tako, recimo, ako grupa [10,*] ima sva prava i nalazi se na početku liste, a
korisnik [10,03] nema definiciona prava i nalazi se u listi iza grupnog. identifikatora,
SUBP će mu, ipak, dozvoliti sve, jer njegova stavka u listi neće nikada biti pročitana.
TakoĎe, ako grupa ima manja prava nego neki njen član kao pojedinačni korisnik, a
stavka za grupu se nalazi ispred njegove stavke u ACL listi, na njega će se
primenjivati grupna prava. Posebno se mora paziti ako neki korisnik ima lična ili
grupna prava po osnovu UIC koda – User Identification Code – kod za identifikaciju
korisnika, a pripada grupi sa posebnim identifikatorom, koja opet ima sopstvena
prava.
Uglavnom, moţe se reći da korisnici sa manjim pravima treba da budu što bliţe
vrhu liste, a korisnici sa većim pravima što bliţe dnu liste. TakoĎe, specifični
korisnici treba da budu pre grupnih korisnika, kako bi odgovarajuća ograničenja imala
efekta.

Definisanje prava pristupa – primer

Za dodeljivanje prava pojedinim korisnicima sluţi - naredba DEFINE

PROTECTION, čija sintaksa izgleda ovako:

DEFINE PROTECTION FOR tip-objekta naziv-objekta poloţaj vrednost-poloţaja

IDENTIFIER korisnički-id
ACCESS lista-prava-pristupa, a pojedini parametri imaju sledeće značenje:

 tip-objekta moţe biti DATABASE, RELATION ili VIEW;

 naziv objekta je stvarni naziv baze, relacije ili pogleda;

 poloţaj moţe biti AFTER ili POSITION; ako se ovaj podatak ne navede, SUBP
smešta novododatu stavku na sam vrh ACL liste.

187
@ViPserbia

 vrednost-poloţaja moţe biti redni broj ili korisnički-id;

Naredbom CHANGE PROTECTION mogu se promeniti prava pristupa za jednog

korisnika ili celu grupu.
Naredbom DELETE PROTECTION moţe se ukinuti pravo pristupa nekom
korisniku. Posebno je vaţno da se ukloni pravo ALL koje neki SUBP, po kreiranju
baze, dodeljuju korisniku čiji je UIC (*, *] - dakle, sva prava svim korisnicima.
Najzad, naredbom SHOW PROTECTION moţe se saznati kolika su ovlašćenja
dodeljena pojedinim korisnicima.
Naredba SHOW PRIVILEGES ima sličnu funkciju, ali umesto prikazivanja prava
za sve korisnike, prikazuje isključivo prava pristupa koja ima pojedini korisnik baze.

Za dodelu prava pristupa SQL koristi listu prava pristupa (ACL), jednako kao i
neki drugi SUBP. Za dodavanje novih prava pristupa koristi se naredba GRANT, čija
je sintaksa:

GRANT spisak-prava ON spisak-objekata

TO spisak-korisnika [opis-mesta];
Moguća prava pristupa ekvivalentna su odgovarajućim pravima koja poznaju
većina SUBP. Pravo ALL obuhvata sva moguća prava, a korisnik PUBLIC
ekvivalentan je svim korisnicima, dakle stavki čiji je identifikator u ACL listi (*,*].
Prava pristupa mogu se definisati posebno za šemu, a posebno za tabele (relacije) i
poglede u okviru šeme ,korisnik mora imati potrebno pravo i za šemu i za tabelu inače
će mu pristup biti uskraćen. Za identifikaciju korisnika sluţi UIC identifikator,
generalni ili sistemski identifikator. Nova stavka se moţe staviti u listu bilo na zadato
mesto (POSITION..), ili posle odreĎenog identifikatora (AFTER...), a ako se mesto
ne navede, SQL stavlja novu stavku na sam početak ACL liste.
Za uklanjanje pojedinih prava nadleţna je naredba REVOKE, kojom se mogu
uskratiti samo neka prava (ako se eksplicitno navedu) ili sva prava (ako se briše
kompletna stavka iz ACL liste, REVOKE ENTRY ON ...), za pojedine objekte ili
celu šemu, korisniku koji se identifikuje bilo mestom, bilo identifikatorom.
Pravo DBCTRL- Data Base Control, koje dozvoljava korisniku da drugima
dodeljuje i menja prava pristupa, slično je, ali ne i sasvim ekvivalentno standardnom
SQL pravu GRANT OPTION. U standardnim implementacijama SQL-a korisnik sa
GRANT OPTION pravom moţe drugim korisnicima da dodeljuje samo ona prava
koja sam ima; dok u nekim SUBP, korisnik sa CONTROL, odnosno DBCTRL
pravom moţe, sebi i drugima, dodeljivati sva moguća prava pristupa bazi.

188
@ViPserbia

10. Zaštita integriteta baze

Pod pojmom integriteta neke baze podataka se podrazumeva neophodnost da
podaci smešteni u bazi budu ispravni, zatim da budu potpuni u meri u kojoj je to
moguće, da budu zaštićeni od neovlašćenih delovanja izvana ili iznutra kao i da se
obezbedi potreban nivo tajnosti. Da bi se zaštitio integritet baze potrebno je da se
obezbedi meĎusobna usaglašenost i povezanost podataka koji se nalaze u bazi. Da bi
se ostvario recimo logički integritet podataka koriste se odgovarajuća ograničenja
koja sprečavaju pojavu i prisustvo nekih podataka u bazi koji bi u logičkom smislu
odstupali od zadatih parametara.
Što se tiče zaštite integriteta baze ona se odnosi pre svega na mogući oporavak
u slučaju neke nezgode, nestanak struje naprimer i slično, kada se javlja potreba za
delimičnim ili potpunim rekonstruisanjem baze, zatim mogućeg konkurentnog
pristupa od strane više korisnika istovremeno, kao i na bezbednost pojedinih podataka
pa i čitave baze od mogućih destruktivnih uticaja, i na kraju zaštita ispravnosti i
konzistentnosti podataka u bazi.
Kao jedna od veoma dobrih mera u zaštiti integriteta baze je primena
takozvanih transakcija što podrazumeva jednu logičku jedinicu posla koja se ili
izvršava u celini ili se uopšte ne izvršava. Naime za integritet baze bi bilo veoma loše
ako bi se zbog odreĎenih smetnji pola podataka u jednoj transakciji unelo u bazu a
recimo druga polovina ne. Pored toga se koriste i druge operacije nad transakcijom
koje omogućavaju da se svi podaci vezani za datum transakcije prethodno logički
provere pre nego što se pokrene akcija aktiviranja te transakcije.
Bilo bi veoma nezgodno da se pola transakcije obavi, a tek onda ustanovi da
neki podaci u drugom delu transakcije nisu adekvatni i da se ne mogu uključiti u
bazu. Pored toga koriste se mehanizmi poznati kao voĎenje dnevnika prethodnog
stanja koji predstavlja jednu od osnova za primenu transakcije kao osnovne jedinice
za pristup nekoj bazi.

Pod integritetom baze se takoĎe podrazumeva meĎusobna usaglašenost i

povezanost podataka u bazi, tamo gde postoji eksplicitno izraţena potreba za
očuvanjem te usaglašenosti, odnosno povezanosti. TakoĎe se pod integritetom baze
podrazumeva obezbeĎenje logičkog i fizičkog integriteta. Osnovni mehanizam
očuvanja logičkog integriteta podataka jesu ograničenja i logika aplikacionih
programa. Osnovna zaštita fizičkog integriteta podataka se moţe ostvariti primenom
mehanizma poznatog kao voĎenje dnevnika prethodnog stanja (before-image
journaling), koji predstavlja osnovu za implementaciju transakcija kao osnovnih
jedinica pristupa bazi.
Pomenućemo još neke mehanizme zaštite fizičkog integriteta podataka:
@ViPserbia

arhiviranje, import i eksport operacije, te voĎenje dnevnika završenih transakcija.

Arhiviranje i dnevnik završenih transakcija

Kao i za sve druge datoteke na bilo kom računarskom sistemu, potrebno je peri-
odično arhiviranje datoteke baze podataka na neku drugu jedinicu masovne memorije
najčešće je to druga jedinica magnetnog diska, (pre je to bila magnetna traka).
Operacija arhiviranja se vrši periodično, a pre svega sa ciljem da se sačuva kopija
datoteka za slučaj oštećenja glavne jedinice spoljn memorije: diska. Pošto se obično
radilo o povremenim situacijama, a ne o svakodnevnom radu, brzina pristupa
arhiviranim podacima nije bila od primarnog značaja, pa je čak i traka bila sasvim
prihvatljiv medij.
Arhiviranje, se u većini operativnih sistema vršilo i vrši naprimer naredbom
BACKUP; pa ako doĎe do oštećenja podataka u bazi, recimo prilikom kvara nekog
fizičkog ureĎaja, baza se moţe lako obnoviti iz arhivirane verzije, ponovo naredbom
BACKUP. Sve izmene koje su učinjene nakon poslednjeg arhiviranja, meĎutim biće
izgubljene.
Kao zaštita u takvim slučajevima, u mnogim SUBP je implementiran takozvani
after-image journaling mehanizam. Ovaj postupak se zasniva na tome što se u
posebnu privremenu datoteku upisuju sve izmene koje su nastale kao posledica
uspešno okončanih transakcija i to neposredno pre okončanja odgovarajuće
transakcije (podsetimo se da su izmene već upisane u bazu i samo se obeleţavaju kao
vaţeće, a stari podaci iz privremene datoteke se brišu). Kao predostroţnost za slučaj
da doĎe do oštećenja baze - narušavanja konsistentnosti podataka, tada se relativno
lako mogao izvršiti oporavak baze.
Gotovo da i ne treba naglašavati da je neophodno da privremena datoteka ne
bude na istom fizičkom disku na kojem se nalazila i baza, inače je pouzdanost ovakve
zaštite bila ništavna. Posle oštećenja, najpre treba da se arhivirane datoteke
restauriraju, ali na drugi disk (ili pak na originalni, ukoliko - i kada – se moţe vratiti u
radno stanje). Za to ponovo moţe da posluţi naredba BACKUP:
Tokom procesa rekonstrukcije svaka transakcija koja se uspešno ponovi je
obeleţena u after-image datoteci. Samo one transakcije koje nisu bile unete u after-
image journal ne budu sačuvane, a takvih je obično bio mali broj jer samo one
transakcije koje su u toku u trenutku kada je došlo do kvara sistema (jer se izmene
prvo unose u after-image journal, pa tek onda u bazu).
Jedna od dodatnih mogućnosti je izbor potpunog ili inkrementalnog arhiviranja, tj.
da li će se vršiti arhiviranje cele baze ili samo onih delova koji su izmenjeni od
trenutka poslednjeg arhiviranja. Druga je mogućnost da se arhiviranje baze obavlja u
prisustvu aktivnih korisnika, bez prekidanja rada sa bazom. Sve transakcije koje su u
toku u trenutku započinjanja arhiviranja mogu se neometano završiti, ali nije
dozvoljeno započinjanje novih. Kada baza dostigne mirno stanje, u kome više nema

190
@ViPserbia

otvorenih transakcija, počinje postupak arhiviranjia, tokom koga bazi mogu pristupati
drugi korisnici.
SUBP moţe da arhivira i dnevnik završenih transakcija i na taj način se štedi
prostor na disku. Postoji i mogućnost da se arhiviranje dnevnika obavlja periodično, u
zadatim vremenskim intervalima, čime se prostor koji dnevnik zauzima na disku
odrţava u zadatim granicama.
Baza se restaurira iz arhivirane kopije odgovarajućom naredbom RESTORE; pri
čemu se mogu promeniti vrednosti nekih parametara; takoĎe, mogu se aţurirati
definicije struktura podataka u rečniku podataka, na osnovu strukture zapisane u bazi.

Ako se baza poziva preko naziva datoteke, a ne preko naziva CDD putanje – Code
Data Definition , bilo koja naredba kojom se menja struktura baze neće promeniti
odgovarajuće definicije u rečniku podataka, pa postoji opasnost da pristup preko
nekog drugog softvera ne bude moguć. Da bi se aţurirale definicije strukture baze u
rečniku podataka, potrebno je izdati odgovarajuću naredbu kojom se definicije
objekata kopiraju u rečnik podataka.
Ova se naredba se ne moţe izdati dok je baza čija se definicija kopira aktivna, već
ili pre pozivanja, ili posle zatvaranja baze. Korisnik mora imati dozvolu za aţuriranje
za CDD katalog. Po izvršavanju ove naredbe navedena baza postaje aktivna, iako nije
eksplicitno aktivirana.

Razmena podataka
Većina korisničkih interfejsa prema bazama poseduju dva para naredbi čiji je
cilj obezbeĎivanje i olakšavanje razmene podataka izmeĎu različitih verzija istoga
SUBP. Pri tome, naprimer naredbe BACKUP i RESTORE sluţe za razmenu podataka
sa jednog računarskog sistema na drugi. Jedan od tih sistema moţe da radi i pod
operativnim sistemom koji sluţi za upravljanje procesima, po mogućnosti u realnom
vremenu, a da je drugi operativni sistem, da se tako izrazimo, opšte namene. Pored
ovih preporučuje se da se koriste i naredbe EXPORT i IMPORT, sa sličnom
namenom, ali sa više mogućnosti.
Naredba EXPORT formira kopiju baze u komprimovanom obliku. Kopija
dobijena na taj način moţe se iskoristiti za prestruktuiranje, tj. promenu fizičkih
parametara baze (čak i onih koji se ne mogu menjati naprimer standardnim naredbama
za promenu baze kao što su CHANGE DATABASE, odnosno ALTER SCHEMA),
pretvaranje single-file baze u multifile bazu, ili za prenos baze sa jednog računarskog
sistema na drugi itd.

191
@ViPserbia

Transakcije i zaštita integriteta podataka

Osnovni aspekti zaštite podataka jesu oporavak u slučaju nezgode, arbitraţa pri
konkurentnom pristupu bazi od strane više korisnika, bezbednost pojedinih podataka i
čitave baze, te zaštita integriteta - ispravnosti i konzistentnosti podataka u bazi.
Transakcija je logička jedinica posla, pristup bazi koji ima atomski karakter - ili
se izvršava u celosti, ili se ne izvršava uopšte. Naime, ukoliko se upis, brisanje ili
izmena podataka uspešno završi, podaci bi trebalo da budu aţurirani. Sa druge strane,
ukoliko iz bilo kojeg razloga doĎe do greške, baza bi trebalo da bude vraćna u
prvobitno stanje, ono koje je postojalo pre početka pristupa bazi od strane dotičnog
korisnika.
Razlog za postojanje transakcija jeste opasnost od grešaka do kojih moţe doći bilo
usled neispravno zadatih upita od strane jednog korisnika, bilo usled konkurentnog
pristupa podacima od strane više korisnika, bilo usled otkaza softvera ili hardvera u
toku aţuriranja podataka.
Stoga su gotovo u sve relacione SUBP ugraĎene naredbe COMMIT (naredba za
izvršenje) i ROLLBACK (naredba za vraćanje u nazad). Naredbom COMMIT
korisnik obaveštava SUBP da je upit korektan i da sve izmene treba da se zaista
izvrše, tj. da se podaci u bazi aţuriraju. Ukoliko doĎe do neke greške, ili ako korisnik
primeti da upit nije bio korektno postavljen, naredbom ROLLBACK sve izmene se
poništavaju i sadrţaj baze se dovodi u stanje u kojem se nalazio pre početka
transakcije. Kako se ovo izvodi? Sistem ne samo da izvršava naredbe, već ih i pamti u
sklopu posebnih datoteka - dnevnika izvršenih aktivnosti (log ili journal); u slučaju
da doĎe do ROLLBACK naredbe, na osnovu podataka iz tih datoteka baza se vraća u
prvobitno stanje.
Fizički, transakcije su podrţane putem mehanizma poznatog kao before-image
journaling. Postupak se odvija u dva koraka: prilikom svake izmene podataka u bazi,
najpre se u posebnu datoteku (koja se zove run-unit journal, RUJ, a vodi se za svakog
korisnika posebno) upisuje prethodno stanje svih izmenjenih podataka. Zatim se nove
vrednosti podataka upisuju direktno u bazu. Postupak se ponavlja za svaku izmenu
izvršenu tokom tekuće transakcije. Pošto se sve izmene unesu, naredbom COMMIT
korisnik obaveštava SUBP da ţeIi da izmene ostanu za stalno u bazi.
Ukoliko sistem nije otkrio nikakvu grešku (naprimer dupliranje neke n-torke, ili
narušavanje nekih), po naredbi COMMIT prethodno stanje podataka se briše iz .RUJ
datoteke, a u bazi ostaje novo stanje. Transakcija se tek tada smatra uspešno
okončanom. Ukoliko sistem detektuje grešku, transakcija ostaje otvorena: u bazi se
nalaze izmenjeni podaci, ali je i .RUJ datoteka otvorena i sadrţi prethodno stanje. U
tom slučaju SUBP obaveštava korisnika, čija je duţnost da izda naredbu ROLLBACK
i da poništi efekte neispravne transakcije. Kada se transakcija poništi (korisnik je

192
@ViPserbia

izdao naredbu ROLLBACK), svi podaci izmenjeni tokom transakcije vraćaju se u

prvobitno stanje (transakcija se "odvrti unazad" , otuda termin roll back).
Na ovaj način je obezbeĎeno da se sve operacije unutar jedne transakcije ili izvrše
ili ne izvrše. Iz praktičnih razloga, da bi se smanjio broj U/I operacija u slučaju
višekorisničkog rada i zbog zauzeća prostora na disku, poţeljno je da transakcije budu
što je moguće kraće. _
Postavlja se pitanje da li se postupak moţe obrnuti, tako da se u run-unit
journal upisuju izmene, a da stanje u bazi ostane nepromenjeno sve do naredbe
COMMIT? Na prvi pogled redosled operacija nema značaja, meĎutim nije tako.
Naime, direktno upisivanje izmena u bazu obezbeĎuje korektnost podataka u bazi u
slučaju da do otkaza doĎe u intervalu izmeĎu izdavanja naredbe COMMIT i njenog
okončanja. Za izvršenje COMMIT naredbe potrebno je, naime, samo izbrisati podatke
iz run-unit journal datoteke, bez pristupa samoj bazi. U suprotnom, ako bi se izmene
unosile u bazu tek naredbom COMMIT, bilo bi potrebno znatno više vremena (pa je
verovatnoća otkaza veća), a postojala bi i opasnost da se tek tada detektuje
narušavanje nekog ograničenja. Najzad, realno je očekivati da će se većina transakcija
uspešno završiti, pa je upotrebljeni način brţi, iz čisto statističkih razloga.
U nekim SUBP before-image journaling postupak se vodi automatski i korisnik na
njega moţe da utiče utoliko što moţe da promeni katalog u koji će biti smeštena .RUJ
datoteka. Tačna lokacija ove datoteke moţe se menjati predefinisanjem logičkog
naziva na nivou operativnog sistema, uz pomoć odgovarajuće naredbe posle čega će
run-unit journal datoteka biti smeštena u katalog čije ime se zada tom naredbom.
Gotovo da nije ni potrebno pominjati da je za efikasan rad mehanizma transakcija
u slučaju otkaza sistema dobro da run-unit journal datoteka ne bude na istoj
memorijskoj jedinici na kojoj i baza.
Inače, transakcija se započinje eksplicitnom naredbom, a završava sa COMMIT ili
ROLLBACK. većina SUBP, predviĎa postojanje transakcija različitih vrsta: jednih
koje se obraćaju bazi samo u cilju čitanja (READONLY), i drugih koje mogu vršiti i
aţuriranje podataka (READ-WRITE). Vrsta transakcije se mora naznačiti prilikom
njenog započinjanja. Ukoliko se transakcija ne započne eksplicitnom naredbom,
SUBP automatski startuje transakciju za upisivanje pri naredbama DEFINE,
CHANGE, DELETE ili STORE, a transakciju za čitanje u ostalim slučajevima. Bez
obzira na to ko je započeo transakciju, na kraju se mora naći naredba COMMIT ili
ROLLBACK.
Transakcija za čitanje je tesno povezana sa datotekom snimka (snapshot file).
Naime, transakcije tipa READ-ONLY ne obraćaju se samoj bazi, već njenoj slici -
delu relacije koji se po potrebi prekopira u .SNP datoteku. Na taj način se poboljšava
brzina odziva: pošto je datoteka kraća, pretraţivanje je brţe, a snimak se ne
zaključava te se prava pristupa ne proveravaju. Kako nema opasnosti od konflikta oko
zaključavanja izmeĎu transakcije koja čita snimak i transakcije koja aţurira podatke u

193
@ViPserbia

bazi, vreme odziva je kraće, i to za obe transakcije. Naravno, ne moţe baš sve biti
idealno, uvek postoji opasnost da podaci u datoteci snimka nisu sasvim ispravni:
moţda su stvarni podaci u bazi izmenjeni, a izmene još nisu unete u datoteku snimka.
Ukoliko takav rizik nije prihvatljiv, mora se specificirati transakcija za upisivanje,
koja pristupa direktno bazi a ne snimku, ako ţelimo da čitamo samo podatke iz baze.

Problemi konkuretnosti

Posebni problemi nastaju kada dva ili više korisnika pokušaju da istovremeno
pristupe podacima u bazi. Ako se tom prilikom vrši samo čitanje podataka sa obe
strane, sve je u redu; ali ako bilo koji upit ima za cilj aţuriranje podataka, moţe doći
do problema. Postoji više mogućih scenarija u kojima dolazi do greške, do stanja u
kome su sve transakcije okončane, a podaci u bazi su ipak u nekonsistentnom stanju;
navešćemo tri karakterističcna slučcaja:

1. Recimo da dva korisnika, A i B, istovremeno aţuriraju podatke. Korisnik A pročita

podatak, zatim korisnik B pročita taj isti podatak, onda mu A izmeni vrednost, pa mu
zatim B, na osnovu prethodno pročitane vrednosti, takoĎe izmeni vrednost. Rezultat:
izmena koju je napravio A nije ostala u bazi (the lost update problem, problem
neuspelog aţuriranja).

2. Recimo da A čita ili aţurira podatke, dok ih B istovremeno aţurira. Najpre B izmeni
podatak, A ga zatim pročita, a onda B-ova transakcija propadne i podatak dobije
prethodnu vrednost ili pak B izmeni podatak, zatim ga i A izmeni, a onda B-ova
transakcija propadne i podatak dobije vrednost koju je
imao pre no što su ga menjali i A i B. Rezultat: izmena koju vrši A zavisi od uspeha
transakcije u okviru koje radi B (the uncommitted dependency problem, problem
zavisnosti od druge transakcije).

3. Moguća je i situacija u kojoj A vrši neku zbirnu analizu podataka, dok B istovremeno
aţurira podatke u istoj relaciji: tako A moţe da urašuna u zbir neki podatak, koji
potom B izmeni. Rezultat: iako je B-ova transakcija uspešno završena, zbir koji je
izračunao A nije više ispravan (the inconsistent analysis problem, problem
nekonsistentne analize).
Naravno, stvari mogu biti još sloţenije kada više korisnika pristupa bazi.
Da bi se osigurao integritet baze i korektnost aplikacija pri višekorisničkom radu,
pored transakcije uvodi se i zaključavanje pojedinih podataka. Ukoliko jedan korisnik
ţeli da izmeni podatak u odreĎenoj vrsti ili celoj tabeli, za vreme njegove transakcije
svim ostalim korisnicima moţe biti uskraćen pristup vrsti ili tabeli čiji se sadrţaj
menja. Naravno, stvari nisu postavljene na principu sve ili ništa, već postoji relativno

194
@ViPserbia

sloţen mehanizam zaključavanja kojim se osigurava kako integritet podataka u bazi,

tako i efikasan pristup sa najmanje čekanja.

Nivoi zaključavanja

Postoje tri načina (ili nivoa) zaključavanja: deljivi (sharedlock), zaštićeni

(protected lock) i ekskluzivno zaključavanje (exclusive lock). Postaviti ekskluzivni
lokot na neku relaciju znači sprečiti sve ostale korisnike da joj pristupe, nezavisno od
toga šta ţele da rade, za sve vreme izvršavanja transakcije; postaviti zaštićeni lokot
znači sprečiti ostale korisnike da upisuju podatke u zaključanu relaciju, ali im je
pristup dozvoljen ako imaju nameru samo da čitaju podatke. Najzad, deljivi lokot
omogućava ostalim korisnicima i da pišu, i da čitaju podatke iz zaključane relacije.
Jasno je da će postavljanje lokota višeg reda sprečiti pristup drugim korisnicima,
ali je zato izvršavanje takve transakcije brţe, budući da se u tom slučaju zaključavanje
vrši na višem nivou, te je manje reţijsko vreme tokom kojeg SUBP odreĎuje ko ima
preče pravo pristupa relaciji, delu relacije ili indeksu. Dakle, verovatnoća kolizije je
veća, ali je vreme kraće, pa se ne moţe odreĎeno reći koju je vrstu lokota bolje
koristiti. Naravno, ima situacija kada izbora nema, bez obzira na eventualne
posledice.
Nekiu proizvoĎači SUBP recimo preporučuju da se upisivanje veće količine
podataka (pod tim se podrazumeva programsko unošenje podataka iz neke druge baze
ili datoteke) vrši primenom naredbe EXCLUSIVE WRITE, naredba za ekskluzivno
upisivanje transakcija, jer je na taj način upis brţi, neće se vršiti upisivanje u datoteku
snimka, te nema opasnosti da drugi korisnici pokvare te podatke.
Na početku transakcije moţe se navesti i podatak o tome da li je transakcija (tj.
korisnik) spremna da čeka, ukoliko su podaci kojima treba da pristupi već zaključani
od strane drugih korisnika. Ukoliko se za stanje-čekanja stavi naredba za čekanje -
WAIT (što se inače podrazumeva, ako se ništa ne stavi), transakcija koja ne moţe da
pristupi nekom zapisu usled istovremenog pristupa transakcije sa lokotom višeg reda
moraće da sačeka da se ţeljena lokacija oslobodi.

195
@ViPserbia

11. Nadzor nad radom baze

Nadzor nad radom baze je neophodan jer u toku rada sa bazom posebno od
strane velikog broja korisnika koji recimo pune bazu ili vrţe aţuriranja u bazi. Naime
u takvom radu moţe doći do pojave neţeljnih podataka u bazi, pojave dupliranja,
pojave takozvanog smeća koje je potrebno u odreĎenim periodima vremena
pregledati, eliminisati, očistiti bazu, ako je potrebno izvršiti odreĎenu regeneraciju ili
pak restauraciju baze ili pek ponekad je potrebno leiminisati neke konfliktne situacije.
U firmama u kojima se koriste velike baze podataka obično postoje osobe čiji
je osnovni zadatak da pored odgovarajućih programskih alata koje sadrţi većina
modernih baza i koji brinu o zaštiti i integritetu baze i oni vode posebnu brigu o bazi
dodeljuju prava pristupa i korišćenja odreĎenih podataka u bazi pa do napred
pomenutih operacija nad bazom u cilju obezbeĎenja njenog besprekornog
funkcionisanja.

Naprimer u nekim SUBP se odgovarajućom naredbom aktivira monitorski

proces (naprimer MONITOR START) koji nadzire rad baze podataka. Monitor se
zaustavlja odgovarajućom naredbom (naprimer MONITOR STOP), pri čemu se
aktivnim korisnicima baze moţe dopustiti da neometano završe rad, ili se pak nasilno
prekida rad drugih korisnika, bez zaustavljanja njihovih procesa, a moţe i da se
prekida rad drugih korisnika i zaustavljaju njihovi procesi.
Spisak trenutno aktivnih korisnika baze moţe se dobiti odgvarajućom naredbom
(naprimer SHOW USERS ), dok naprimer naredba SHOW SYSTEM prikazuje sve
aktivne baze u datom cluster čvoru. Naredbom SHOW MONITOR moţe se takoĎe
dobiti informacija o trenutnim korisnicima svih baza u sistemu.

196
@ViPserbia

Kuda dalje – Budući razvoj

Sa sve većim i brţim razvojem informacionih sistema, sa njihovom

distribucijom na velike prostore i veoma razuĎene računarske resurse, kao i sa sve
većom primenom Interneta kao najveće svetske računarske mreţe stiče se utisak da je
stvarna budućnost baza podataka u njihovoj distribuciji na širokoj sklali računarske
podloge i mogućnošću korišćenja od strane veoma velikog broja korisnika iz
najudaljenijih krajeva sveta.
Normalno da će poslovne baze podataka iako distribuirane u većoj ili manjoj
meri biti pristupačne samo uţem krugu korisnika i to onih koji imaju dozvolu za
pristup odgovarajućoj grupi podataka.Ipak će najveće svetske baze podataka kao i
Internet postati opšte dobro koje će moći da koriste i da im pristupaju korisnici iz
celog sveta i to je najveća vrednost informatizacije sveta ili to moţemo nazvati
informatičkom revolucijom ili pak epohom informatičkog društva.
Naime učinjen je mogućim pristup brojnim informacijama relevantnim za
društvo kao celinu, ali i dostupnim svim ljudima na svetu i deci i starijima,
domaćicama i penzionerima, radnicima i naučnicima i zato moţemo reći iskreno
hvala svim onim pionirima koji su u poslednijh pedesetak godina dali svoj manji ili
veći doprinos razvoju kako baza podataka tako i informatizaciji čovečanstva.

197
@ViPserbia

13. Prilog 1 - PRIMER PROJEKTA INFORMACIONOG SISTEMA

BIBLIOTEKE F@M - a

Za potrebe Fakulteta zahtevano je da se na osnovu idejnog-izvoĎačkog projekta

za biblioteku realizuje podsistem evidentiranja podataka o literaturi.

Bilo je neophodno da se obave intervjui sa zaposlenima koji rade na tim

poslovima da bi se upoznalo sa tehnologijom procesa rada u segmentu Fakulteta za
menadţment koji se odnosi na biblioteku. Procenjeno je da će se evidentirati oko
5000 knjiga-naslova.

Na osnovu intervjua predloţen je idejno-izvoĎački projekat na osnovu koga je

realizovano aplikativno rešenje kao deo ukupnog sadašnjeg i budućeg informacionog
sistema Fakulteta za menadţment. Aplikativno rešenje se odnosi na formiranje i
korišćenje baze podataka o literaturi.

 Aplikativno rešenje je realizovano alatima Microsoft Access 2000 (kao deo

MS Office 2000 Professional softvera).
 Aplikativno rešenje je isporučeno u izvornom kodu (source code) da bi svi
zaposleni na tim poslovima mogli po potrebi da sprovode izmene u
realizovanom rešenju.
 Posle okončanja ovoga projekta odnosno završetka aplikativnog rešenja,
izvršena je obuka zaposlenih koji operativno koriste aplikativno rešenje uz
prateću dokumentaciju, Pored obuke osposobljen je jedan od zaposlenih na
budućim poslovima odrţavanja aplikativnog rešenja u smislu daljne
nadgradnje (projektovanje i programiranje modaliteta koji se u praksi
pokaţu potrebnim).
 U nastavku će biti prikazani izgledi nekih ekrana (formi) i izveštaja. Forme
sluţe za obuhvat podataka. Navigacija kroz forme je realizovana sistemom
menija. Obuhvat podataka podrazumeva da se nad jednom pojavom jednog
podatka iz entiteta mogu obavljati funkcije insert (novo evidentiranje),
update (izmena postojećeg stanja), select/query (pronalaţenje po nekom
kriterijumu) i print (prikaz podatka na ekranu i/ili u štampanoj formi na
hartiji). Funkcija delete (brisanje) nije blokirana, nego je zbog takozvanog
referencijalnog integriteta uspostavljenog na nivou cele MS Access baze,
operateru odnosno zaposlenom koji koristi aplikativno rešenje prepušteno da
na osnovu profesionalnog stava potvrdi ili opozove brisanje.

198
@ViPserbia

 Pristup bazi podataka je ograničen samo na one koji znaju pristupnu

lozinku.
 Tokom obuke je prezentiran način arhiviranja (backup) podataka na neki
medij (naprimer diskete, drugi računar u mreţi, CD-RW).

1. Ulazna dokumentacija na osnovu koje je formirana baza podataka o

literaturi nije postojala tako da je predviĎeno da se direktnim uvidom u
podatke na samoj knjizi omogući kasnije evidentiranje i štampanje
"kartona knjige".

2. Revers je dokument čija forma isto nije definisana u dokumentaciji, ali je

iskazana potreba za takvim dokumentom u aplikativnom rešenju pa je bilo
potrebno da se dizajnira forma. To je dokument kojim se evidentiraju sva
zaduţenja studenata, nastavnog osobolja i drugih lica koja imaju odobrenje
za pristup biblioteci. Potrebno je bilo predvideti takav sistem rada da ako se
ne obavi povraćaj litearture na vreme studentska sluţba i operater u
biblioteci dobiju odgovarajuću.

3. Izlaznu dokumentaciju čine raznorazni izveštaji: abecedne liste po

naslovima, autorima, izdavačima ili liste po godinama izdavanja i po
lokacijama-policama smeštaja literature. Ovi izveštaji se generišu iz
agregiranih podataka smeštenih u bazu podataka.

4. Aplikativnim rešenjem je predviĎeno i pronalaţenje literature po nekom

kriterijumu i filtriranje takvih podataka dobijenih iz postavljenog
kriterijuma.

Logički model je postavljen na osnovi E-R modela relacione baze podataka.

Identifikovani su sledeći entiteti sa pripadajućim atributima:

1 AUTORI
1. Identifikacija autora AutoNum * Primarni indeks
2. Prezime i ime Char
3. e-mail Char
4. Biografija Memo

2 OBLASTI
1. Identifikacija oblasti AutoNum * Primarni indeks
2. Opis oblasti Char

199
@ViPserbia

3 IZDAVAČI
1. Identifikacija izdavača AutoNum * Primarni indeks
2. Naziv izdavača Char
3. Adresa uzdavača (mesto,ulica i broj) Char
4. Telefoni Char
5. Dosije izdavača

4 JEZICI
1. Identifikacija jezika AutoNum * Primarni
indeks
2. Naziv jezika Char

5 REVERSI
1. Identifikacija zaduţenja AutoNum * Primarni indeks
2. Prezime i ime duţnika Char
3. Opis zaduţenja Char
4. Datum početka zaduţenja Date()
5. Datum završetka zaduţenja Date()
6. Odobrio revers (ime i prezime) Char
7. Poništio revers (ime i prezime) Char
8. Status zaduţenja Yes/No
6 KNJIGE
1. Identifikacija knjige AutoNum * Primarni indeks
2. Autor Num ** Strani ključ
3. Naslov Char
4. Kratak sadrţaj Memo
5. Izdavač Num ** Strani ključ
6. Godina izdavanja Date()
7. Oblast Num ** Strani ključ
8. Jezik Num ** Strani ključ
9. ISBN oznaka Char
10. Lokacija (orman-polisa) Char
11. Identifikacija reversa Num ** Strani ključ
12. Slika naslovne strane OLE objekat (.BMP format slike)
13. Broj stranica Num
14. Sadrţaj knjige Memo
15. Tip literature Num ** Strani ključ
16. Status knjige(foto-kopija) Yes/No

200
@ViPserbia

Slika 13.1 Oosnovni meni informacionog sistema studentske sluţbe

Slika 13.2 Meni poslova biblioteke

201
@ViPserbia

Slika 13.3. E-R dijagram relacija i entieta

Slika 13.4 Spisak tabela u projektu sa definicijama tabela i prikazom delimičnog

sadrţaja

202
@ViPserbia

Slika 13.5 Spisak - tabela autora –design view

Slika 13.6 Spisak - tabela autora – tabelarni – spead sheet view

203
@ViPserbia

Slika 13.7 Spisak - tabela izdavača –design view

Slika 13.8 Spisak - tabela izdavača tabelarni – spead sheet view

204
@ViPserbia

Slika 13.9 Spisak - tabela jezici–design view

Slika 13.10 Spisak - tabela jezici tabelarni – spead sheet view

205
@ViPserbia

Slika 13.11 Spisak tabela knjige –design view

Slika 13.12 Spisak tabela knjige tabelarni – spead sheet view

206
@ViPserbia

Slika 13.13 Spisak tabela oblasti –design view

Slika 13.14 Spisak tabela oblasti tabelarni – spead sheet view

207
@ViPserbia

Slika 13.15 Spisak - tabela reversi oblasti –design view

Slika 13.16 Spisak - tabela reversi tabelarni – spead sheet view

208
@ViPserbia

Slika 13.17 Forma za obuhvat podataka o knjigama

Slika 13.18 Forma za obuhvat podataka o oblastima

209
@ViPserbia

Slika 13.19 Forma za obuhvat podataka o jezicima

Slika 13.20 Primeri izveštaja – karton knjige

210
@ViPserbia

Slika 13.21 Primer izveštaja - Spisak literature po naslovima

Slika 13.23 Primer izveštaja - Spisak literature po autorima

211
@ViPserbia

14. Prilog 2 Primer baze podataka za osnovnu

školu Jovan Popović
U okviru ovog primera je data baza sa kompletnom evidencijom svih
učenika, profesora, predmeta i evidencija uspeha učenika po predmetima, kao i
evidencija o nagradama i kaznama

Slika 14.1 Glavni meni

212
@ViPserbia

Slika 14.2 Pomoćni meni za izveštaje

Slika 14.3 Dijagram entiteta i relacija

213
@ViPserbia

Prikaz tabela u dizajnerskom prozoru

Slika 14.4 Prikaz tabele Nastavnik

Slika 14.5 Prikaz tabele Učenici

214
@ViPserbia

Slika 14.6 Prikaz tabele Predmeti

Slika 14.7 Prikaz tabele za dnevni unos ocena, opravdanih i

neopravdanih časova, nagrada i kazni

215
@ViPserbia

Prikaz formi za obuhvat podataka

Slika 14.8 Prikaz forme za obuhvat podataka o
nastavnom osoblju

Slika 14.9 Prikaz forme za obuhvat podataka o učenicima

216
@ViPserbia

Slika 14.10 Prikaz forme za obuhvat podataka o

nastavnim predmetima

Slika 14.11 Prikaz forme za obuhvat podataka

o ocenama, opravdanim i neopravdanim časovima,nagradama i kaznama

217
@ViPserbia

Prikaz upita dizajnerskom prozoru

Slika 14.12 Prikaz upita o kaznama i nagradama za učenike

Slika 14.13 Prikaz upita o profesorima i predmetima koje predaju

218
@ViPserbia

Slika 14.14 Prikaz upita o srednjim ocenama za učenike

pojedinačno

Prikaz izveštaja
Slika 14.15 Prikaz izveštaja o srednjim ocenama
grupisanim po učenicima

219
@ViPserbia

Slika 14.16 Prikaz izveštaja o nagradama i kaznama

Slika 14.17 Prikaz izveštaja o nastavnicima i predmetima

koje predaju

220
@ViPserbia

15. Posebni izrazi koji se koriste u bazama podataka

ACL Access Control List Kontrolna lista pristupa

Adresa Address Numerička vrednost
lokacije u memoriji
Aktivan Active Aplikacija koja se
trenutno izvršava
Aplikacija Applications Softverski proizvod
nastao programiranjem
Aţurirati Update Dopunjavanje ili izmena
vrednosti podataka
Baza podataka Data Base Skup elemenata baze i
softvera za upravljanje
bazom podataka
CDD Code Data Definition Definicija koda podataka
Bit Bit (Binary Digit) Najmanji deo binarne
informacije
Datoteka File Logički skup podataka –
ekvivalentan tabelama
DB Data Base Baza podataka
DBADM Data Base Administrator Administrator baze
DBCTRL Data Base Control Kontrola baze
DDBMS Dstributed Data Base Sistem za upravljanje
Management System distribuiranim bazama
podataka
Dokument Document Programski objekat koga
kreira projektant a ne
aplikacija
Dţoker Wildcard Znak ili znakovi koji
zamenjuju jedan ili više
bilo kojih znakova
Elemenat Data entity Vrednost koja se nalazi u
nekoj ćeliji podataka
Funkcija Function Podprogram za proračun
odreĎene vrednosti
Grupa Group Više zapisa koji se
sakupljaju u istu
kategoriju
Indeks Index Odgovarajuća vrednost u

221
@ViPserbia

tabeli za traţenje
Integritet Data Integrity Pravila koja obezbeĎuju
podataka tačnost i čitljivost
podataka
Izraz Expression Skup vrednosti, funkcija,
promenljivih i operatora
koji vraćaju rezultat
Klijent Client Računar ili aplikacija koji
komuniciraju sa serverom
Ključ Key Polje koje identifikuje
odreĎeni zapis
Komanda Command Naredba - instrukcija
Komandno Command Button Objakat koji aktivira neku
dugme akciju ako se na njega
klikne
LAN Local Area Network Lokalna mreţa
Makro Macro Skup nekoliko naredbi
koje reaguju na dogaĎaje
Meni Menu Skup mogućih izbora
Niz String Podaci koji imaju
tekstualni sadrţaj, mogu
sadrţavati i brojeve
Normalna Normal Form Skup od pet pravila za
forma projektovanje baza
Objekat u bazi Data Base Object Komponenta u bazi
podataka podataka
Obrazac Form Korisnički definisan
prozor u Accessu
off-line off-line autonoman, nezavisan rad
Okvir sa Tool box Skup komandih dugmadi
alatima koja pozivaju alate
Okvir za text Text box Okvir za ubacivanje teksta
OLE Object Linking and Tehnika koja omogućava
Embedding ubacivanje i povezivanje
objekata
on-line on-line neprekidna veza u radu
Operativni Operating system Programi koji prevode
sistem osnovne naredbe u jezik
koji računar razume

222
@ViPserbia

OODBMS Object Oriented Data Base Objektno orijentisan

Management System sistem za upravljanje
bazama podataka
OODBMS Object Oriented Data Base Objektno orijentisana
baza podataka
Osnovne tabele Base Tables Osnovne – stalne tabele
na osnovu kojih se kreira
upit
Paket Batch Niz iskaza koji se
obraĎuju kao jedan paket
Podmeni Submenu Niţi njivo izbornih
mogućnosti
Podprocedura Subprocedure Pomoćna procedura koja
se poziva glavnom
procedurom
Polje Field Naziv za kolonu u kojoj se
nalaze vrednosti atributa
Prevuci i pusti Drag and drop Postupak za premeštanje
mišem na drugu lokaciju
Primarni ključ Primary key Kolona ili više kolona
koje na jedinstven način
identifikuju neki slog
Procedura Procedure Skup iskaza koji se
izvršavaju kao celina
Promenljiva Variable Naziv koji predstavlja
odreĎen broj, slovo ili niz
RDBMS Relational Data Base Sistem za upravljanje
Managemnet System relacionim bazama
podataka
Referentni Referential integrity Pravila za utvrĎivanje
integritet odnosa izmeĎu primarnih
i stranih ključeva
RUJ Run Unit Journal Radni ţurnal - pregled
Server Server Računar koji svoje resurse
i usluge daje računarima
klijentima
SNP Snapshot Snimak
Stavka Item Ime elementa u tabeli

223
@ViPserbia

Strani ključ Foreign key Kolona ili skup kolona

čije vrednosti odgovaraju
primarnom ključu u nekoj
tabeli sa kojom se spajaju
Stranica Page Blok od 2 kilobajta koji
sadrţi zapise neke tabele
SUBP DBMS - Data Base Sistem za upravljanje
Managemnet System bazama podataka
Svojstvo Property Osnovna karakteristika
nekog objekta
SQL Simple Query Language Jednostavan jezik za upite
Tabela Table Objekat baze podataka
koji se sastoji iz redova i
kolona
Transakcija Transaction Jedinstven skup operacija
potrebnih za postizanje
ţeljenog rezultata
Traţenje Seek Pronalaţenje ţeljenog
zapisa u bazi ili datoteci
Upit Query Poseban zahtev za
dobijanje potrebnih
podataka iz baze
Višekorisnički Multiuser system Ovaj sistem omogućava
sistem istovremeno korišćenje
resursa ili baze od strane
više korisnika
Zapis Record Jedan elemenat tabele u
relacionoj bazi podataka

224
@ViPserbia

16. LITERATURA:

1. Access '97 tutorial

2. Access 2000 tutorial
3. Access 2002 tutorial
4. Access 2003 tutorial
5. Kao dopunski izvori informacija su posluţili:
- Operating and user manuals - Radni i korisnički manuali za
razne baze
- internet izvori čije su adrese date u nastavku:
- http://mis.bus.sfu.ca/tutorials/MSAccess/tutorials.html
- http://www.bcschools.net/staff/AccessHelp.htm
- http://www.jmu.edu/computing/tutorials/microsoft/access/
-
http://cisnet.baruch.cuny.edu/holowczak/classes/2200/access/accessall
.html
- http://cru.cahe.wsu.edu/training/Access97/
- http://isds.bus.lsu.edu/cvoc/learn/introit/access/
- http://www.fgcu.edu/support/office2000/access/begin.html
-
http://www.customguide.com/access_tutorial/access_tutorial_2000_de
mo.htm
- http://www.oit.duke.edu/ats/training/docs/access1/

225