e>le~epod

ewezeq s

apeJ If0>1 ewa~sls

afUeAO~>lafoJd

Postupak projektovanja
U prvom i drugom delu ove knjige, razmotrili smo principe projektovanja
reladonih i dimenzionalnih baza podataka. Meclutil1l, struktura podataka
sa1110 je jedna od komponenata sistema kOji radi s bazom podataka izuzet
no vazna, naravno, ali ipak samo jedna od komponenata. PocinjuCi od ovog
dela knjige, bavi6emo se nekim od preostalih aspekata projektovanja sistema
kOji rade s bazama podataka.
U OV0111 delu knjige, objasni6emo veCinu aktivnosti koje se odvijc\iu to
kom analize i projektovanja sistema kOji radi s bazom podataka, meau koji
rna su definidja sistemskih parametara i radnih procesa, konceptualni
model baze podataka i sema baze podataka. Projektovanje korisnickog inter
fejsa, buduCi da.ie to slo;~ena tema, razrnobicemo \l cetvrtom delu knjige.
Razmotricemo samo postupak analiziranja i projektovanja sistema kOji
rade s bazama podataka; prakticna realizacija izlazi van opsega ove knjige.
Posto se analiza i projektovanje ne mogu obavljati nezavisno od c1rugih delo
va postupka, poce6emo kratkim opisom zivotnog ciklusa projekta.

Modeli iivotnog ciklusa

Nekad davno, sistemski analiticmi koristili su za postupak razvoja analogiju
poznatu kao model vodopada. Postoji viSe verzija tog modela. Prilicno jed
nostanla varijanta prikazana .ie na slid 9-1.
Po stupak zapoCinje sistemskom analizom, koja se ponekad naziva i ana
liza zahteva jer joj je cilj da utvrdi sta organizacija i budu6i korisnici zahte
vaju da sistem radio Nakon zavrSetka i odobrenja sistemske an alize , ceo
sistem se detaljno projektuje. Toj fazi sledi planiranje i procena troskova, a
zatim slede izrada, testiranje i uvoc1enje celog sistema u rec10vnu upotrebu.
Tako je harem u teoriji.

147

 Ovde se desava cudo

Slika 9-1 Model vodopada

Model vodopada je estetski dopadljiv. Svaka pojeclinacna aktivnost

zavrsava se i odobrava pre pocetka sledece, a model omoguCcwa visok stepen
kontrole nad troskovima, radom ucesnika i utroskom vremena. Ako projekat
napravljen po modelu vodopada zavrSite u predvidenom roku, vasi klijenti
ce vas verovatno obozavati.
Problem, lezi u tome sto stvamost gotovo nikad nije tako jednostavna i
uredena. Model polazi od pretpostavke da su sve infonnacije koje su neo
phodne za obavljanje odredenog posla poznate tokom njegovog obavljanja i
ne dopusta naknadnu pojavu novih informacija tokom postupka. Izuzev u vrlo
malim i jednostavl1im sistemima (one vrste koje mozete za sebe projektovati i
napraviti tokom duzeg vikenda), takav slucaj je veoma malo verovatan.
Model vodopada ne dozvoljava ni menjanje poslovnih zahteva tokom iz
rade projekta. Potpuno je nerealno pretpostaviti da ce sistem, koji ispunjava
poslovne zahteve na pocetku nekog projekta, ispunjavati te zahteve i posle
dye ili tIi godine rada. Neupotrebljiv sistem nece ocluseviti vase klijente, cak
i ako im ga isporucite ria vreme i be:::, prelwracenja trokova.
Medutim, imajte u vidu da su aktivnosti identifikovane u modelu vodo
pada potpuno ispravne. U stvari, ako izostavite bilo koju od njih, prizivate
katastrofu. Problem s modelom vodopada je njegova lineamost, tj. pretpo
stavka da se nikad ne treba vracati na odredenu fazu nakon njenog zavrsetka.

Kno resenje problema modela vodopada, smisljeno je vise alternati\nih

modela zivotnog ciklusa. Spiralni model omogucava vise iteracija modela
vodopada, pri cemu svaka mec1u njima prosirllje opseg prethodne itcracije

(slika 9-2).

Zavrsetak
projekta

Analiza

, ~

. Projektovanje

Pcoj,kt"""

OJ

r---'----;,

i
Planiranje i
I
i procena troskova I

//

Slika 9-2 Spira!ni mode!

Problem sa spiralnim 1110delom je slede6: kada se striktno primenjuje,

celokupan opseg projekta ne moze se razmatrati sve do pred sam haj razvo
.ia projekta, a postoji (sve samo ne zamerljiva) verovatnoCa cia ce kasnijc
iteracije uCiniti bespredmetnim ranije ulozen trud. Taj model 111i .ie oduvek
izgledao kao recept za prekoraCivanje budzeta i nerviranje projektanata.

Takva situacija je naroCito opasna pri projektovanju baza poc1ataka, gdc

prosirivanje opsega projekta moze da promeni semantiku podataka, sto zah
teva menjanje seme baze poc1ataka, a izmena seme moze clovesti c10 neoce
kivanih - i nepreclvidljivih - izmena u celom sistemu.
Model koji smatram najprikladnijim za slozene sisteme i kOji koristim u
svom radu, opisuje se kao inkrementni razvoj (engl. illcremental deuelop
ment) ili evolutivni razvoj (engl. evollltionary development), a prikazan je
na slici 9-3.

Pocetna
analiza

t
Projektovanje
strukture

Detaljno projektovanje

~
Slika 9-3 Model inkrementnog razvoja

U tom modelu, koji je u mnogim svojim aspektima samo varijanta spiral

nog modela, izvodi se pocetna analiza celog sistema, a ne samo jednog nje
govog dela. Tome sledi projektovanje strukture, takode celog sistema. Cilj
projektovanja strukture je da se utvrde komponente koje se mogu realizovati
manje ili vise nezavisno i da se opisu odnosi i zavisnosti izmedu till kompo
nenata. Fotom se obavlja detaljno projektovanje i izrada svake komponente
na osnovu modela koji je najprikladniji. U toj fazi koristim spiralni model
(slika 9-3) jer omogueava veeu fleksibilnost pri projektovanju i realizovanju.

Obmtite paznju n<1 to cIa spinda na sliei 9-:3 sacIrzi clodatan posao: inte
grisanje. Integrisanje pojedinacnih komponenata podra7.umeva se i 11 spiral
nom modell!, naravno, ali Jlloje iskllstvo pokazuje da je taj posao slozeniji
kada se primenjuje model inkrementnog razvoja. To je takode jedan oel l'a
zloga zbog kojih radije koristim spiralni model za razvoj kornponenata. Ako
detaljno projektovanje komponente odlozite do trenutka kada ona postaje
zaista neophodna, moCi cete da ugradite sve ono novo sto ste saznali tokom
integrisanja prethodnih komponenata ida, uz malo srece, izbegnete proble
me na koje ste mozda naiSli tokom integrisanja prethodnih komponenata.
Problem s modelom inkrementnog razvoja jeste to sto pretpostavlja da se
svaki slozen sistem moze razbiti na jasno razdvojene komponente, a to nije
uvek moguce u svim sistemima. Osim toga, posledica moze biti velika kolici
na "potpornog" koda. Pretpostavimo da ehan za unosenje podataka treba da
poziva COM komponentu koja pretrazuje podatke 0 kupcu i izvrsava
odredenu akciju ako pronade te podatke, ali tn komponenta jos nije napra
vljena. Razvojni tim mora 11 tom slucaju da napravi ,Jaznu" komponentu koja
omoguCava pozivanje buduce komponente bez izazivanja greske. Slozeni si
stemi mogu saddati znatne koliCine takvog "potpornog" koda.
Osim toga, uvek postoji mogucnost da spoljna komponenta ne bude ni
kad napravljena; mazda budzet projekta to nece dozvoliti ili cete naknadno
ustanoviti da to i nije tako dobra ideja. Ako ne vodite racuna 0 toj mogucno
sti, moze yam se desiti da distribuirate komponente cija je jedina svrha da
dmgim komponentama omoguci da rade. To uopste nije elegantno resenje,
a svakako nije l1dto sto biste voleli da objasnjavate programeru zaduzenom
za oddavanje sistema.
BuduCi da se analiza zahteva i projektovanje strukture obavljaju na
pocetku projekta, postoji rizik da oni zastare, sto je, podsetite se, jedan od
glavnih nedostataka modela vodopada. lz tog razloga, vazno je da vise puta
ponovite ta dva koraka - narocito analizu zahteva, posta je tu najveca verovat
noca naknadnih izmena - pre nego sto zapocnete detaljno projektovanje
svake komponente. Cesto je prijatno iznenadenje koliko ~e izmene zahteva
mogu lako realizovati menjanjem komponenata koje tek treba razviti, iIi cak
menjanjem redosleda kojim se komponente razvijaju, bez gubljenja vec ulo
zenog truda.
Ali llprkos rizicima, model inkrementnog razvoja ipak pruza viSe predno
sti. BucluCi da je "velika slika" sistema definisana na samom pocetku projekta,
smanjuje se verovatnoca gubljenja ranije ulozenog truda zbog pogresnih od
luka. BuduCi da se slozeni projekti razbijaju na manje komponente, lakse se
upravlja projektima pojedinacnih komponenata. Osim toga, razbijanjem si
stema na pojedinacne komponente, vrlo je verovatno da cete vec u ranim

fazama projekta 1ll0Ci dn obezbedite klijentu odredeni deo 05110\'ne fnnkcio

nalnosti. To omoguC(\\'1\
sistem pocne cla isplacuje nmLtc ulozen 11 c1ota
dasnji razvoj i obezbec1uje mehanizam da se povratne infonnac:ije
StiZll
ocl korisnik,\ sistema ugrade u daIji mel na razvoju sistema.

Postupak projektovanja baza podataka

Bez obzira na opsti model razvoja za kOji se opredelite, moracete da se bavi
te poslovima analize i projektovanja. Bilo da cete ih obavljati sekvencijalno
ili iterativno, je Ii predmet vase paznje ceo sistem iIi sa1110 jedna njegova
komponenta, da li koristitc formalne ili neformalne tehnike - te korake mo
rate da obavite barem jedanput u svakom projektu.

Definisanje sistemskih parametara

U idealnom slnCaju, svaki projekat bi poceo od jasne definicije onog sto zeli
te da postignete, zbog
to pokusavate da postignete i na osnovn cega ce
se procenjivati vas nspeh. Bnduei da za ve<Sinn projekata ta definicija nece
biti poznata pre pocetka, to je svrha prve faze postupka projektovanja. Cilje
vi projekta definisu "zasto" projekta. Na osnOVll toga, l110zete def'inisati "i;ta",
odnosno opseg projekta. Posto shvatite cilj i opseg projekta, mozete preCi na
odredivanje realisticnih kriterijnma za projektovanje, tj. na "kako". Sve nave
dene faze detaljno cemo prouciti u poglavljll 11,

Definisanje radnih procesa

Iako se prevashodno have skladistenjem i llCitavanjem podataka, veCina si
stema kOji rade s bazama podataka podrzava jedan iii viSe radnih procesa.
Korisniei ne unose podatke radi unosenja podataka, vee zato sto zele da te
podatke koriste na odredeni naCin. Razumevanje radnih procesa koje podaci
treba da podrze kljucno je za razumevanje semantike modela poclataka.
Radni procesi opisani su u poglavlju 12.

Izrada konceptualnog modela podataka

Vise oel obicne grupe struktura za tabele, konceptllalni model podataka de
finiSe na6n upotrebe podataka u celom sistemll. To obuhvata ne samo logic
ki model podataka, vee i opise naCina na koje radni procesi deluju na
podatke. Konceptualni model podataka razmatramo u poglavlju 13.

Priprema seme baze podataka

Sema haze podataka prc\'odi konceptualni model podataka u flzicki oblik.
SacIrzi opise tabela koje ce biti napntvljenc 11 sistemu i flzickll arhitektmu
podataka. Fizicke arhitekture i sellla haze poc1ataka detaljno Sll objasnjene 11
poglavlju 14.

Projektovanje korisnickog interfejsa

Bez obzira na to koliko su impresivne tehnicke performanse sistema kOji ste
napravili, ako je korisnicki interfejs nezgrapan, zbunjujuCi ili nmnetljiv, malo
je verovatno cla 6e projekat uspeti. Na kraju krajeva, za veCinu korisnika ko
risnicki interfejs jeste sistem. Dizajn korisnickog interfejsa objasnjen je II
cetVliom delu knjige.

~apomena 0

metodologijama i standardima
IJrojektovanja
Nisam veliki pristalica upotrebe fonnalnih spiskova poslova i postupaka ko
rak po korak pri projektovanju racunarskih sistema. Iskllstvo mi govori cIa
oni mogu da budu smetnja dobrom elizajnu jer se lako moze dogoditi cIa se
analiticar viSe posveti popunjavanju nekakvih "kuCica" nego razumevanjll
korisnikovih zahteva.
Mealltim, II velikim sistemima na kOjima radi vise analiticara i vise timov(l
programera, oCigledno je neophodno llspostaviti odrec1ene f(Jl'malne procedu
re radi upravljanja postupkom projektovanja. Postoji vise metodo)ogija za tu
namenu, a veCina ima i automatizovane alatke za podrsku. Necu iZllCitO pre
poruCiti nijednu oel njih. Pwo, zato sto opredeljivanje za jednu iii dmgu moze
preCi II "verski rat"; drugo, kao i pitanje imena promenljivih, samo post(~j(mje
odredene metodologije obicno je vaznije oel izabrane metodo]ogije.
Svesna sam da priprema projcktne dokurnentacije moze biti odbojan
posao, barem dok ga ne uradite prvih nekoliko puta. U poglavlju 14 na6 cete
opsti opis postupka.

Definisanje parametara

sistema
"Sistem se projektuje da bi radio
a ne sva/fta".
Robert Hall, razvojni inzenjer, North American Aviation
Kruzi prica da Bob Hall umalo nije dobio otkaz kada je ovu napomenu upu
tio potpredsedniku kompanije jer je ovaj po hiljaditi put pokusao da prosiri
opseg projekta. (U oblasti projektovanja sistema, kao i u svakoj drugoj, koris
no je znati skim tacno imate posla.) Bilo kako bilo, to ostaje jedna od najisti
nitijih napomena koje sam dosad cula u vezi s postupkom projektovanja
sistema. Ako zelite da projekat bude
morate biti u stanju da opiSete
sta pokusavate da postignete i da povucete prihvatljive graniee oko projekta.
Ako ne mozete reCi s razumnom izvesnoseu "uradiCemo to i to, a to ito nece
?nO uraditi", mogu Yam obeeati da eete zaista upasti u velike nevolje.
Postupak clefinisanja sastoji se ocl tri koraka:
1. Odredivanje eilja, ne samo sistema, vee projekta kao celine.
2. Utvrdivanje 1.1510va za projektovanje sistema; pored proeenjivanja
valjanosti kompromisa koje cete mozda morati da napravite tokom
projektovanja i izrade sistema, uslovi ce s]uziti i za procenjivanje nje
gove uspesnosti iii neuspesnosti.
3. Definisanje opsega sistema - sta cete uraditi, a !ita necete pokusati
da uradite.

155

Odredivanje ciljeva sistema

Trebalo bi da clefinisanje (iii ntvrclivanje) cilja i opsega sistema buc1e jeclno
stavno. Ponekac1, ako imate IIl1lOg0 srece, zaista jc tako. Ponekad je upotre
bljiva definieija cilja i opsega projekta sastavni cleo opisa projektnog zac1atka.
Cesce se desava da je njihovo definisanje slozen postupak u ko.1em cete mo
rati da kombinujete formalne tehnike analize, projektne kompromise i po
prilicnu koliCinll cliplomatije.
Cilj razvojnog projekta obi6no je najvazniji cinilac pri odredivanju i opse
sistema i projektnih uslova l1a osnovu kojih ce projekat biti procenjen. Cilj
projekta je, uostalom, razlog zbog kojeg se zapoCinje razvoj projekta. Razume
se, necete biti u stanju da donosite ispravne odluke ni 0 jednom drugom
aspektu projekta dok yam ne bude potpuno jasno !ita treba da postignete.
Nemojte brkati neilj projekta" s "projektnim zadatkom". VeCina projekata
pocinje opisom sistema koji treba razviti i navodenjem dodeljenog budzeta.
Vas zadatak je "automatizovanje postojeceg sistema za obradu porudzbina", a
imate na raspolaganju godinn dana i p01a miliona dolara dn to uradite. Me(1u
tim, "automatizovanje postojeceg sistema za obradu porudzbina" predstavlja
zadatak H ne cilj. Cilj je razlog, iii verovatnije viSe njih, zbog kOjih se pro
jekat pravi.
ReCi da treba odrecliti "eilr sistema, donekle upucuje na pogresan
zakljueak. Velika vecina sistema ima nmogo ciljeva, i opipljivih i neopipljivih,
a za njihovo otkrivanje mogu biti neophodne detektivske metode. Zbog eega
je potrebno automatizovanje sistema za obradu porudzbina? Da Ii zato da hi
se ubrzao postupak? Poboljsala taenost? Smanjili troskovi? Poboljsao utisak
kOji kompanija ostavlja na kupee? Da bi direktor izgledao pmnetnije? Ciljevi
sistema verovatno poclrazumevaju sve navedene razloge i jos clesetak drugih.
Naravno, ne predlazem da pocnete da ceprkate po privatnosti Ij'udi, niti
da zahtevate pristup poverljivim podacima kompanije, a i neki od tih ciljeva
spadaju II opstu mbli1.l1 "to se vas ne tiee". Nije neophodno da vi znate da di
rektor sluzbe "uskace u Intemet voz" zbog straha od kon1.l1rencije. Ali trebu
da znate racunicu prema kojoj, da bi se sistem isplatio, mora da smanji pro
secno vreme obrade porudzbine sa sadasnjih deset min uta na elva min uta.
Moze biti potrebno i da razumete neodreelene izraze koje koriste ljudi
sto se bave proclajom i marketingol1l, kao sto Sll "pozicioniranje proizvoda" i
"upravljanje korisnikovim ocekivanjima". Srecom, zbog toga nije potrebno
da se vratite 11 sk01u; dovoljno je da pitate svog Idijenta. BuduCi c1a te izraze
svako koristi s nesto drugaCijim znacenjem, ionako cete 1110rati da pitate.

Problem s takvim nejasnim c:iljevima jeste to !ito ih je cesto tesko prewsti

Jllerljive projektne llslo\'(;. Ponekacl uz malo pamctnog istrazivnnja nejasan
c:ilj moze postati jasan. "\Ja primer, c:ilj "pomoc pri Ilpravljanju korisnikovim
ocekivanjima" obicno je znak problema 11 komunikacijisklijentimH.se
moze lako prevesti u merljive uslove "potrebno je cia kupeu kazemo koliko
nam vremena treba da obradimo njegovu porudzbinu" - ili se mora oc1baciti.
Ako vas klijent ima problema s rokovima isporuke robe i pretpostavlja cIa
je razlog to sto prodavci pristaju na nemogllce datlllne isporuke samo cIa bi
napmvili promet, onda clirektan eilj sistema za obradll poruc1zbina jeste
upravljanje korisnikovim ocekivanjima. Na primer, II tom slucajll mozete
llgraditi ogranicenje koji111 odredujete minimalno vreme koje mora da prode
od datllma prijema porudzbine do obecanog datuma isporuke robe. MecIll
tim, al<o je llzrok problema kontrola kvaliteta tokol11 postllpka proizvoc1nje,
sistem za obradll porudzbina 11e moze da pomogne da se problem re5i i na
vama je da to predocite SV0111 klijentll. To l1e znaci da zbog toga nije vrec1no
ni zapoceti projekat; medutim, svi llcesnici moraju razumeti da sistem za
obradu porudzbina ne moze direktno da utice na taj lltvrdeni cilj.
Razume se, ne mogll se svi neopipljivi eiljevi tako lako prevesti U opiplji
ve. "Pozicioniranje" je jedan od takvih. ad vas se moze zahtevati da napravi
te \Veb lokaciju koja "pozieionira kompaniju na vodece mesto u bransi".
Vecina ovako definisanih ciljeva ne znaci zapravo niSta konkretno, iii ce smnH
cinjeniea da sistem postoji biti dovoljna za postizanje ciljeva. Lako mozete
odrediti 0 cemu se tacno radi; samo pitajte klijenta kako cete vi znati da Ii ste
postigli postavljeni cHj. Velika je verovatnoca da ce biti postignut i neopipljiv
eilj ako se postignu drugi eiljevi u vezi sa performansama i funkeionalnoscu
sistema. (Takode je velika verovatnoca da cete u tom slucaju imati priliku da
vidite mspolozene Ijude iz odeljenja za marketing kako SkakllCU od radosti.
Ja volim to da gledam, a vi?)
Jos jedna vrsta tvrdnje koju treba pazljivo razmotliti jeste eilj izrazen
uopstenim reCima kao sto su "poboljsati" i "smanjiti". "Poboljsati efikasnost" i
"povecati produktivnost" vrio su cesti i plilicno neodredeni ciljevi. Kako cete
znati cIa li ste ih postigli? Jedan od mojih klijenata mi je ispricao lepu (i gotovo
izvesno apokrifnu) prieu 0 tome koliko je vazna merljivost kada se definiSll
radna zaduzenja zaposlenih. (Projektni uslovi i radna zaduzenja Sll, na kraju
krajeva, slicni po na111en1.) Prema prici, tom coveku je, kao mladom prodavcu,
receno da mu je posao "da reklamira nasu robu i usluge". A onda je on otvOlio
vrata kancelarije i viknuo: "Svako treba da kllpuje nasu robu zato sto je stvarno
super". Siguma sam da to nije 0110 na sta je mislio njegov nadredelli.
U

Osim ako \ise eenite s\"oj S1111SaO za humor od iznosa na svom rac'unn u
band, tokol11 pocetne analize momeete dOl utvrdite stcpen do
se zahtcvCl
neko opste poboljsanje. Poboljsati efikasnost ;:;a koliko? Povceati produktiv
nost or! koliko IW lwliko? Tn postoji druga zamka koju treba izbeci. Sasvim je
u redu trvdnja da eiljevi treba da budu direktno merljivi, a "smanjiti vreme
potrebno za obraclu jedne porudzbine sa deset min uta l1a elva minuta" svaka
ko je bolje od "poboljsati eflkasnost". Mectutim, prva recenica podrazumeva
da vi znate koliko je vremena sada potrebno za obradu porudzbine, a Otkr1
vanje toga moze biti skupa vezba.
Cena istrazivanja cesto moze da premasi cenu greske koju biste naCinili
kada istrazivanja ne bi bilo. U nasem plimeru obrade porudzbina, verovatno
nije neophodno da posaljete tim analitieara sa stopericama da biste preeizno
utvrdili koliko je vremena potrebno za obmdu jedne porudzbine, mada sam
ito videla. Pre nekoliko godina, ucestvovala sam u projektu u kojem je jecIna
vladina sluzba potrosila $50.000 kako bi utvrcIila da Ii je opravdana kupovina
jeclnog primerka komercijalnog softvera za izradu dijagrama Cija je malopro
dajna cena bila $2.500. (Priznajem, na tu Cinjenicu sam ukazala samo jedan
put, a onda sam cutaIa dok nisam stigla do svoje banke. Ako me vladina
sluzba placa da radim nesto glupo, mora da je u pitanju specijalan oblik pov
racaja poreza.)
Resenje za prevodenje takvih uopstenih zahteva u upotrebljive projekt
ne uslove, nalazi se U osecaju za meru i u konceptu "dovoljno dobro". Ako
sudbina kompanije ili neCija karijera zavisi od kvaliteta novog raeunarskog si
stema, morate bib vrlo, vrlo sigurni u ono !ito radite. Ukoliko pravite manji
sistem kOji nece puno uticati na poslovanje kompanije, mozete sebi priustiti
vecu opustenost. Ako se vratimo na nas primer, verovatno je "dovoljno do
bro" da znate da u tekucem sistemu prosecna osoba moze cIa obradi otpri
like 2.5 porudzbina dnevno. Nije potrebno da sami detaljno istrazujete jer
vam taj podatak gotovo sigurno moze dati rukovodilac sluzbe; zbog toga ste i
pozvani. Sigurna sam da je preterano detaljno istrazivanje razlog zbog kojeg
americko ministarstvo odbrane placa $400 po odvijacu. (Pre nego sto pocne
te cia mi saljete uvredljive poruke, znajte da nisam nikad radila za njih.)
Uvek vredi pitati zbog cega je potrebno odredeno poboljsanje, Na pri
mer, moze biti zaostalog posla, a rukovocIilae mora odlueiti cia Ii da ubrza po
stupak iii da zaposli docIatno osoblje. Ako znate da ima zaostalog posh i
znate predviden obim povecanja prodaje (kao u nasem primeru obrade
rudzbina), mozete odrediti stepen poboIjsanja koji je zaista potreban.
Cifra do koje dodete moze se razlikovati od one koju yam je klijent prvo
bitno dao. Ukoliko vas klijent zeli cIa smanji vreme obrade na po!ovinu, mo
rate uraditi sve sto ie u vasoj moci da biste to postigli. Ali kad znate da je

sistemu zapravo ]Jotrebllo cla postigne samo 25-procentno Ul1Hllljenje,

imacete dovoljno slobodnih opcija za pogadanje ako bude potreimo da pra
vite kOl11promise iZl11edu zahtevanog ubrzanja obrade i lak06e upotrebe ili
pouzdanosti sistema.
Ljudi kOji se profesionalno bave racunarima cesto govore kako bi im
zivot bio laksi kada bi njihovi klijenti tacno znali sta zele. Vasi klijenti .:')U{jll
sta
jedino ne znaju kako da ttl potrebu prevedu tako da bude razumlji
va racunarskom sistemu. To je vas posao. Vasi ldijenti nece yam svesno i na
memo uputiti nerazumne zahteve, navesti vas na gresku, niti vas optuziti za
stvari za koje niste krivi. Ali, deo vaseg posla je da pomognete svojim klijen
tima pri donosenju odluke 0 tome sta predlozeni sistem kOji radi s bazom
podataka moze, a sta ne moze dn uradi. Nerazumno je ocekivati od njih da u
potpunosti poznaju mogucnosti i ogranicenja tehnologije.
Vmijacija na ovu temu je klijent kOji vam donese h11)U snimaka ekrana i
uzoraka izvestaja kOji se mogu ili ne mogu napraviti. To je slucaj kada yam
neko pokazuje resenje umesto problema. Potrebna je plilicna kolicina uzdr
zanosti da bi se shvatila logika na kojoj se zasniva takav "dizajn sistema", ada
pri tome ne date do znanja osobi koja je to uradila da je tupava, nestrucna ili
se prosto bavi stvarima koje ne poznaje.
Za takve situacije mogu yam samo predloziti da ispitate dubinu vode. Ako
vam se cini da klijent ne prihvata vasa pitanja kao dobronamerna, pokusc~ite
da
nesto u stilu: "Bicu yam od vece pomoCi ako bolje shvatim vase
poslovno okruzenje". Ako vas taj pristup ne odvede nikuda, moracete da na
pravite sistem onako kako vam je predstavljeno ili da odustanete od projekta
(naravno, svesna sam da to nije uvek moguce). Najbolje cemu se l110zete na
dati jeste da ispitate projekat kOji dobijete; ako pronadete neke sustinske ne
dostatke, predocite ih klijentu recenicom u stilu: "To ne 1110gU da uradim, ali
zato mogu da uradim to ili to. Sta bi najbolje odgovaralo vasim potrebama'?"
Postupal< utvrdivanja ciljeva opisan u prethodnim odeljcima nije speci
[jean za sisteme koji rade s bazama podataka. Od drugih racunarskih sistema
oni se prvenstveno razlikuju po tome !ito imaju, gotovo kao sporedni proiz
vod, odredeni skup podataka 0 organizaciji. Taj skup poclataka, bez obzira na
to da Ii u pitanju spisak pretplatnika Hi grupa racuna, moze imati izvesnu
vrednost i za
delove organizacije, izvan radnih procesa koje ti podaci
direktno podrZavaju.
Ovim ne
da kazem da svaki projekat treba smatrati prilikol1l za iz
radu riznice poclataka koje ce koristiti ceia organizacija. Zelim samo da na
pomcncm da
ispitati da Ii podaci kOji cine sastavni deo sistema imaju
vrednost i za druge delove organizacije Hi druge procese u istoj oblasti. Moz
da ce podaci koje vas sistem prikupIja lako moCi da se stave na raspolaganje
nekom drugom odeljenju organizacije, mada, iskreno receno, takve prilike
su znatno rede nego sto se misli.

N Cl primer, aka sistem Zit obraclu poruclzbina odrzClv<t listu kupaca a

odeljenju prodaje potrelma lista slanja da hi kupcima slali rcklamne bro
sure, l110ze biti korisl1o cla im ol11og11Cite pristup listi kupaca. Ako lle zbog
c1rugog razlog<l, deljenje liste kup<lca oslobodice nekog nesrecllog referenhl
closadnog posla prekucavanja tih imena i aclresa. Molim vas c1a imate u viclu
cia "omoguCiti pristup poc1acima" niposto niJe isto sto i ugraclivanje funkcio
nalnosti liste slanja u sistem za obraclu porudzbina - tu se kriju opasne
"azdaje".
Jedini razlog zbog kojeg uopste i predlazem da razmotrite to pitanje,
uprkos opasnostima zalazenja u megalomaniju, jeste to sto moze biti dovolj
na mm~j(l izmena strukture podataka da bi se oni iskoristili i za druge name
ne. Tu mogucnost razmotricemo detaljnije u poglavlju 12, a ovde samo
navodim jednostavan primer.
Kada sam govorila 0 prostim vrednostima, napomenula sam ela adresa
moze bib, u okviru semantike datog sistema, blok podataka kOji se stampa na
nalepnici za adresu. PreporuCila sam da u tom slucaju adresu obradujete hlo
jedan atribut. Medutim, ako ti podaci mogu biti kOlisni u nekoj dl1lgoj oblasti,
ali samo ako su atributi razdvojeni, onda .ie plihvatljivo da tekucem sistemu do
date malo dopunsko opterecenje da biste izbegli duplimnje podataka na dru
gom mestu.
Imajte u viclu cIa to c1oclatno opterecenje treba da bucle zaista malo i da
deljenje poc1ataka mora cia bude uistinu izvodljivo. Videla sam (i na svoju
sramotu, napravila) sisteme koji zahtevaju ul10senje celih kategorija podata
ka kOji nemaju nika1.ve direktne veze s tekueim radnim procesom, 5amo zato
sto u odredenom trenutku mogu biti nekome korisni. Euduei cIa se nesto
slicno moze neverovatno lako uraditi nenamerno, vodite racnna cia kada
plicate 0 "planiranju buduceg rasta" ne mislite zapravo na "dodavanje ne
potrebne nove funkcionalnosti".
Posto utvrdite pocetni skup ciljeva, mozete preCi na sledece aktivnosti u
postupku analize: utvrdivanje projektnih uslova i opsega projekta. Medutim,
nemojte pod od pogresne pretpostavke da se nakon odredivanja ciljevi pro
jekta viSe ne mogu menjati. Morate uvek biti spremni da ponovo razmotrite
ciljeve sistema tokom kasnijih faza projekta.
Za svaki projekat kOji traje vise oel nekoliko neclelja, postoji verovatnoca
da ce se poslovni zahtevi promeniti. Obim prodaje se znatno razlikuje oel
preelvidenog; spajanje kompanija moze cIa znaCi visak zaposlenih umesto
manjka; vise spoljnih dogadaja moze zahtevati pOl1ovno razmntnmje ciljeva
projekta. Tokom duzeg projekta, redovno ispitujtc zajedllo S klijentom da Ii
je doslo do radikalnib izmena.

Cak i II rclativl10 kratkotrajno])1 projektu, lllO;t.e se c]ogoditi da II kasnijim

projekta llstanovite c1a SI! neki ci1jevi pogresni ili neclostizni. Jeclan ocl
najozhiljnijih problema s k1asicnim mocle1om voclopac1a, seC-ate se,
to
cia se u njemu polazi oel pretpostavke c1a znate sve sto vam treba i kac1 vam
treba. U stvarnosti, svoje znanje 0 tome sta sistem treba cia radi dopunjava
cete tOk0111 celog projekta. Nova saznanja cesto ce zahtevati POllOVllO
divanje ciljeva sistema, cak i ako se to svodi samo na ispitivanje i zakljucak "ll
redu, to i to .i0s uvek vazi".
f~lZlmHl

~azvoj

projektnih uslova

Posto dovoljno dobro upoznate opipljive i neopipljive ciljeve projekta,

mozete poceti cia razvijate projektne uslove. Bucluci da stvari nisu nikad tako
jasno razdvojene jedne ocI cIrugih, u praksi cete odredivanje uslova zapoceti
vec u fazi definisanja ciljeva projekta. Da bismo mogli da nastavimo cIisku
siju, pretpostavicemo cIa ste vee sastavili spisak ciljeva projekta i da sada tre
ba da pripremite listu uslova na osnovu kOjih ce biti procenjena uspesnost iIi
neuspesnost sistema.
Projektni uslovi tesno su povezani s ciljevima projekta. AIm vam ciljevi
projekta llkazllju na to gde treba da stignete, projektni uslovi vam pokazllju
cIa Ii ste zaista tarno stigli. Trebalo bi da svi projektni uslovi za dati sistem di
rektno podrzavaju jedan iii vise ciljeva sistema. Ukoliko vam se 6ni da odre
deni vazni uslovi ne odgovaraju nijednom cilju, to je gotovo izvesno znak cIa
vas spisak ciljeva nije potpun.
Uparivanje svakog uslova s ciljem koji poddava nije zaista neophodno,
ali je korisna vdba, cak i za iskusne analitieare. Jec1na od najveCih opasnosti
u svakom projektu jeste da ne znate sta jos ne znate. To narocito vazi II sl11ca
jevima kada ste spoljni !consultant koji slabo poznaje (iIi uopste ne poznaje)
aktivnosti organizacije. Neupareni ciljevi i uslovi cIobar su pokazatelj da jos
ne znate sve sto bi trebalo da znate.
Projektni uslovi uglavnom imaju jedan od sledeca tri oblika:
Direktno merljivi zahtevi, npl'. "Odstampati izvestaj 0 starosti zaliha
za manje oel elva sata".
Uslovi kOji se odnose na racIno okruzenje, npr. "Sistem ce racliti II
postojecoj loka1noj mrezi",
Opste projektne strategije, npr. "Korisnicima obezbecliti P01110C
zavisnu od konteksta".

Konkretne kategorije uslova nisu preterano bitne, ali one kojc sam n<lvc
la koristan Sll pokazatelj koliko ste dobro upoznali sistem. Trebalo bi da "e6
na uslova pripada prvoj iIi drugoj kategoriji. Ako imate samo listu opstih
projektnih strategija, kladila bih se da niste sasvim dobro razumeli problem
kOji pokusavate da resite.

NAPOMENA: Bez obzlra na obl1k u kojem ste deflnisall uslove, kada ih ispu
nite. prekinite rad na projektu. Vas projekat je zavrsen. Izadite negde i zabavite
se. Ova preporuka nije bas tako trivijalna kao sto mozda zvuci. Navescu cest
primer: optimizovanje bloka koda. Da biste ispunili uslov zadat u projektu,
funkcija mora da izracuna odredenu vrednost za manje od 10 sekundi. Stigli ste
do 9 sekundi, ali ste sigurni u sledece: ako isprobate ono drugo resenje, uspe
cete da smanjite vreme izvrsavanja za polovinu. Nemojte to ciniti. III, ako bas
morate, uradite to u slobodno vreme. Ne smete nastaviti da radite nakon
ispunjavanja svlh projektnih uslova jer inace projekat nece nikad biti zavrsen.
Jedini moguci izuzetak od ovog pravila jesu razvojno-istrazivacki (RI) projekti,
ali takvi projekti ionako imaju drugacije ciljeve, pa prema tome i drugacije
uslove. Umesto "obaviti proracun za manje od 10 sekundi", verovatnije je da ce
projektni uslov u RI projektu bito nesto poput "odrediti optimalnu metodu za
izracunavanje toga i toga". Posto nikad ne mozete znati da Ii je odredeno resenje
zaista optimalno, nikad necete ispuniti uslov; prema tome, mozete istrazivati do
beskonacnosti iii dok vam ne ponestane novca. sta god se prvo desi.

Kada razvijate projektne uslove, vazno je da se pri tome ne opredelite za

odredeni dizajn iii arhitekturu. Mozda vee znate cIa eete koristiti Micro
softov Transaction Server da biste obezbedili skalabilnost sistema, ali to nije
projektni uslov vee odluka koja se tice arhitekture sistema. Projektni uslov je
to da sistem mora bib skalabilan tako da podrzi x istovremenih korisnika.
Kada niste sigurni, podsetite se da se pomoeu projektnog uslova odredu
je da Ii je projekat uspesno zavrsen. U OV0111 slucaju, zapitajte se: "Ako upot
rebimo Microsoftov Transaction Server, da Ii je nas sistem zavrsen"? Mozda,
ali Cinjenica da koristite Microsoftov Transaction Server nece vam to po
kazati. Medutim, odgovor na pitanje: "Ako obezbedimo skalabilnost za x ko
risnika, da Ii smo time zavrsili?" potvrdan je, pod uslovol11, da ste ispunili i
sve ostale uslove projekta.

Direktno merljivi uslovi

Vee sam navela vaznost identifikovanja objektivno merljivih ciljeva. Ako ste
ste imali uspeha u tom koraku, tome ee sasvim plirodno slediti mnogi projek
tni uslovi. Ako je cilj da se vreme potrebno za obradu smanji za .50 procenata

a sadusnje vreme abrade 10 minute), projektni uslm< je, oCiglec1llo, "obrada

treba eLl tmje Ilujvise 5 rnilluta"<
Ponekael je tesko razlikovuti Illerljive ciljeve oel clirektno merljivih uslo
va. Ne znam da li je to pitanje rnnogo vazno. Policija zn specifikacije \<as ne(-c
ubapsiti ako nesto navedete istovremeno i kao cilj i kao uslov. Meciutim,
mozda ce vas upozoriti ukoliko svaki merljiv cilj ne poelrzite s jednim iii vise
projektnih uslova.
Vodite racuna 0 tome da projektne uslove ne usitnite previSe. Moze 5e
dogoditi da je za zavrSetak odredenog procesa u roku od jednog minuta, pot
rebno da se dati upit izvrsi za manje od deset sekundi. Ali to je zapravo pi
tanje fizicke izvedbe, a zasael jos ne znate 0 projektu elovoljno da biste
donosili odluke koje se ticu tog segmenta.

Uslovi koji se odnose na radno okruzenje

Ve6na ogranicenja u vezi s radnim okruzenjem potice iz postojeceg raclnog
okruzenja i postojeCih sistema s kOjima cete morati ela komunicirate. Hela
tivno je malo verovatno da (-ete dobiti potpuno "prazan teren" na kojem cete
izgraditi sistem. U ve6ni slucajeva, vasi klijenti ce vee imati neko harclversko
i softversko okruzenje u kojem ocekuju ela ee raeliti i novi sistem.
Drugi glavni izvor uslova u vezi s radnim okruzenjem specifican je za si
steme koji rade s bazama poelataka: u pitanju je kolicina poelataka koju treba
obraeliti. Jedan od mOjih prvih poslovnih neuspeha kao nezavisnog konsul
tanta bila je priprema ponude za sistem evidentiranja prodaje, namenjen re
gionalnoj podruznici finne koja se bavi prodajom racunarske opreme na
veliko. N ak011 razgovora 0 njihovim zahtevima, poslala sam im POllUelU za
mali sistem koji bih napisala u Microsoftovom Aecessu 2.0, ela bi mi odgovo
rili da zele da prate prodaju u celoj kompaniji, u preko 500 regionalnih pod
ruzniea, s desetinama miliona do lara prom eta - sto bi ocigleelno bilo claleko
iznad Accessovih mogu(-nosti. Posta sam od pretpostavke ela zele da prate
senno prodaju te poelruznice. Ups, greska. (Nije ni potrebno naglasavati da
nisam dobila posao.)
Kada utvrdujete koliCine poelataka, treba ela razmotrite elva pitanja. Jed
no je sama kolicina poelataka, a elrugo je nacin povebwanja te koliCine. Bi
blioteka moze imati milione knjiga, ali dodaje sarno po nekoliko naslova
clnevno. Sistem za obraelu porudzbina moze cIa clodaje stotine novih zapisa
svakog dana, ali posto se zapisi arhiviraju kada se zavrsi obraela poruelzbine,
apsolutni broj zapisa nikad ne prelazi viSe od nekoliko hiljada. Jasno je da na
veelena elva naCina povecavanja koliCina zahtevaju drugaCije strategije pro
jektovanja sistema.

Podrzavanje potrebne kolicine podataka jedna od situacija u

jc
opravdano predimenzioniranje sistem,l. Kao opste pravi]o, predlazem cIa
planirate kapacitet koji jc za najnUl I~jc 10 procenata veCi od
vredno
sti koju vam je cIao klijcnt, a onda to zHokruzite nowise. Za manje sisteme,
poveeala bib tu vrednost na 20 do 2.5 procenata dodatnog kapHciteta.
Povecanje koliCine podataka manji je problem kadn se ionako radi s
kim kolicinama. Dobro projektovan klijentlserver sistem 1110ze dOl podrzi
100.000 zapisa S jednakom lakocom kao sto podrzava 10.000 zapisa. Ali, si
stem zasnovan na Accessu koji radi u lokalnoj mrezi, projektovan cIa podrZi
nekoliko hiljada zapisa pornocu Jeta, verovatno neee biti skalabilan za milion
zapisa, bez obzira na to koliko je dobro projektovan.
Drugi primarni izvor uslova radnog okruzenja
ukupan broj kori
snika koje sistem treba da podrzava. VeCina sistema ima vise kategorija kori
snika, a vi morate da za svaku od njih definiSete kOji su zahtevi. N a primer,
sistem za obradu pomdzbina imace korisnike ciji ce posao biti da unose po
mdzbine, razume se. Verovatno ce irnati i drugu grupu korisoika, koja ce
ispitivati stanje porudzbina i mozda menjati odredene podatke, dok ee treca
grupa korisnika praviti izvestaje na osnovu podataka iz cele baze podatuka.
Posto ce svakoj od tih
biti potrebno da sistem pruza drugaciju vrstu
podrske, to morate navesti u zasebnim projektnim uslovima.
Osim toga, morate praviti razliku izmedu korisnika koji su uspostavili
vezu sa sistemom i korisnika koji zaista nesto rade u njemu. Nn primer, masi
na baze podataka Jet ima ogranicenje da najvise 2,5.5 korisnika istovremeno
moze da uspostavi VeZll s bazom podataka. To znaci da 2,55 ljudi moze isto
vremeno da otvOli bazu podataka. To ne znaci i cla
Ijudi istovremeno moze
da azmira bazu podataka.

Opste projektne strategije

Neki projektni ciljevi ne preslikavaju se lako u veHeine koje se mogu izraziti
brojevima. Na primer, cilj tipa "poboljsati tacnost pri unosenju podataka"
izuzetno se tesko kvantifikuje jer je to situacija u kojoj bi cena utvrdivanja
broja gresaka verovatno poniStila prednost raspolaganja brojem kOji 01110
gucava merenje uspesnosti.
Nel110jte zanemarivati ovu Vl"stu ciljeva; 1110zete ih zadati u obliku pro
jektnih strategija umesto u obliku merljivih uslova. U tom slucaju, projektni
uslov bi mogao da bude "poboljsati tacnost pri unosenju podataka tako sto ce
ih korisnici birati sa odgovarajuce liste gde god je to izvodljivo", ili "smanjiti
greske pri odobravanju kredita ugradnjom odgovarajuCih provera kreditne
sposobnosti pre prihvatanja racuna u

Isto kao i za l11erljive projektne uslovc, nemojte biti pre\'isc specif'iclli i

pazite da nellamerno ne donesete bilo kakvu odluku koja S(c' bee fh.icke reali
zacije. U ovoj fazi jos ne projektujete sistem, vee samo definiSete lIs10ve na
osnovu kojih ce se procenjivati uspeh projekta. U navedenim primerima po
minjn se izrazi "gde god je izvodljivo" i ugradnja "odgovarajuCih provera";
detalji izvedbe odlozeni su za kasnije faze projekta !<ada sistemski zahte\~
budu bolje shvaceni.
Trebalo bi da izbegavate i "majCinske" receni<.:e. "Sistem se mora ponasa
ti prijateljski prema korisniku" lepo zvuci - na kraju krajeva, niko ne zeli da
radi sa sistemom koji se neprijateljski ponasa prema svojim korisnicima. To je
beskOlistal1 uslov. Meautim, moze se utvrditi da li je ispunjen uslov "Sistem
mora biti usklaaen sa specifikacijama navedenim u dokumentu 'Windows In
te'fjace Guidelines for Software Design". Da Ii sistem jeste iIi l1ije prijateljski
raspolozen prema korisnicima, cesto je pitanje za diskusiju. Projektni uslovi
koje definiSete treba da smanje mogucnost spora, a l1e da je poveeaju.

Odredivanje opsega sistema

Kada shvatite namene za koje projektujete odredeni sistem, imate osnovu Z<1
donosenje odluka 0 tome koja funkcionalnost logicki spada unutar opsega si
stema (a koja tamo ne pIipada). Kao i projektni uslovi, sve funkcije unutar
opsega sistema treba direktno da podrZ8vaju zadati cilj.
Pretpostavimo da je jedan od ciljeva projekta povecanje efikasnosti po
stupka obrade porudzbina. Stampanje racuna neposredno podrzava taj cilj i
nesporno spada u opseg predlozenog sistema. S druge strane, to nije tacno
za izradu kataloga proizvoda i zbog toga se ta funkcija nalazi izvan opsega si
stema. To vazi cak i ako katalog prave isti ljudi i on deli odredene podatke sa
sistemom za obradu pOludzbina.
Ponekad, kada imate puno prekIivanja u podacima izmedu osnovnih i
"dopunskih" ciljeva, korisno je da ponovo definiSete ciljeve sistema. U nave
denom plimeru, sistem bi mogao da se od "Sistema za obradu porudzbina"
promeni u "Podrska prodaji", a "Izrada kataloga proizvoda" postala bi onda
jedan od ciljeva projekta.
To moze biti i opasno. Nije preporucljivo da na osnovu zeljenog opsega
sistema definisete njegove ciljeve. To je kao da postavljate kociju ispred
konja. Iz licnog iskustva znam koliko izgleda privlacno da prosirite opseg si
stema kako bi obuhvatio neke 1ako izvod1jive iii zanimljive funkcije. Licno is
kustvo mi govori i koliko je neprijatno osecanje ako nemate dobar odgovor
kada vas korisnik pita: "A zasto bih ja to uopste pozeleo da uradim?"

Odlican primer takvog nacina razmiSIjanja nalazio se u starijim verzij<l

ma softvera Norton Utilities neophodnoj <llatki u vreme MS-DOS-a. Taj
program je pri zavrsetku prikazivao podatak 0 tome koliko je dugo mclio.
Nakon viSe godina proucavanja materije, jedino objasnjenje koje sam nasla ()
m:::1ogll zbog kojegje to radio bilo je "zato sto je to moglo da se napmvi".
Bojim se da to nije dovoljno dobar razlog. Pravilo propisllje cla ako funk
cija direktno ne podrZ<lva nijedan cilj, ona je izvan opsega sistema. Kao i
mnoga druga pravila, i ovo se moze prekrsiti, ali bi trebalo da to llcinite tek
posle pazljivog razmiSljanja, ukoliko ste ubecleni da postoji legitimna upotre
ba te funkcije. Meriti vreme potrebno da se odrecleni sof'tver uCita u memo
liju mozda jeste zanimljivo, ali tesko da ee biU i korisno.
Postoje situacije kada funkeija ima nespornll vrednost za korisnike i ta
vrednost premasllje eenu izvedbe. Dobar primer toga moze biti opisani pri
mer eilja izrade kataloga proizvoda.
Ali cak i u prilicno jasnim situaeijama kao sto je navedena, kada je 1110
guee prosirenje eiljeva sistema, verovatno je bezbednije da dodatne fllnkcije
navedete u opstoj kategoriji opsega "Dopunska fllnkeionalnost". Time jasno
pokazlljete da ta funkcionalnost nije apsolutno neophodna i da se lako moze
izostaviti iz sistema ako kasnije otkrijete da bi izvedba kostala
od oceki
vanog iZ11osa, ili zato sto vise nemate vrem.ena iIi niste pla6eni.
Druga situacija II kojoj moze biti potrebno Ja llgradite i funkcionalnost
koja ne podrZava direktno nijedan eilj sistema, jeste kada klijent insistira da
to llcinite. Vama moze biti savrseno jasno da stampanje telefonskog imenika
zaposlenih nema bas nikakve veze sa obradom porudzbina, ali ako nesto l<1i
jent zeli, mora to i dobiti. Mozete mll predociti da ta funkcionalnost ne po
drZava nijedan od postavljenih ciljeva, ali vas posao je da ispllnite zahteve
klijenta, ne da ih definisete.

Analiza troskova i dobitaka

Kao poslednji korak ove faze postllpka projektovanja, moze biti korisno da
obavite analizll troskova i dobitaka koje pruza definisana funkcionalnost. To
je narocito tacno ako se predlozeni sistem sastoji od viSe komponenata. Re
lativni odnosi troskovildobici pojedinih komponenata pomoCi ee yam
od
redite preporucljiv redosled izrade tih komponenata. Ukoliko razmisljate 0
prosirenju opsega projekta da biste uveli kategorijll "Dodatna fllnkcional
nost", analiza troskova i dobitaka moze poslllziti kao provera koneeptualne
ispravnosti sistema.
Ako Sll svi ostali llslovi jednaki, trebalo bi da prvo napravite komponente
s najviSim odnosom dobieiltroskovi. Ta strategija obezbeclllje najvise "mllzi
ke za ulozene pare" i omogueava da vee u ranim fazama projekta sistem po
cne da otplaeuje ulozena sredstva. To je naroCito tacno u projektima za koje

jc potrcbno dugo vreme nlz\'oja. Ako osnO\,l1U funkcionalnost ll10zctc hrzo

da obezbedite, time dobijate b'alitetnu osnovu za proccnjivnnje buduceg
razvoja i smanjlljete rizik cIa kasnije izrnene u poslovnom oknIzenju ueine si
stem neupotrebljivill1.
U slucaju cIa sistem 1110ze poceti da se otplacuje relativno ranG tokol1l
mzvoja, mozda ce se isplatiti i da ugradite neke od onih "zabavnih i zanillllji
vih, ali ne bas neophodnih" funkcija koje ste odbacili kada ste definisali op
seg sistema. Razume se, ponekad se javljaju i suprotne situacije. Klijenti
1110gu da ustanove da pocetna funkcionalnost sasvim dobro pokriva njihove
ciljeve i zato razvoj buduCih komponenata odlazu na neodredeno vrel11e.
Razume se, za analizu troskova i dobitaka takode vazi pravilo da cena
forl11alne analize ne treba da premasi cenu dobijanja trazenog odgovora na
dlllgi nacin. Analize troskova i dobitaka nisu teske, ali posta mogu zahtevati
mnogo vremena, oCigledno je da nema smisla potrositi dva dana za analizi
ranje sistema cije je pisanje bilo gotovo za jedan dan. U mnogim situaeijama,
neformalna analiza (inace poznata kao "unutrasnje osecanje") vise je nego
dovoljna.
Analiza troskova i dobitaka maze se napraviti na viSe nacina iako je
princip jednostavan. Proeenjeni dobitak od funkcije padeljen sa procenje
nom cenom izrade funkcije daje odredenu nume;'icku vrednost. Sto je ta
vrednot veca, veca je i relativna vrednost komponente u poreclenju s drugim
komponentama.
NAPOMENA: U ovoj fazi projekta, moze se pricati sam~ 0 procenjenim trosko
vima i procenjenim dobicima. Tacnu cenu izrade funkcije mozete znati same
nakon njene izrade, a koliko iznosi tacan dobitak saznacete tek kad ceo sistem
bude izvesno vreme u redovnoj upotrebi. Post-mortem analize su korisne za
poboljsavanje buducih procena, ali je to potpuno razlicita aktivnost.

Analiza troskova i dobitaka postaje zapetljana kada treba odrediti zajed

nicke jedinice mere. Svi troskovi se moraju meriti istim jedinieama, i svi do
bici se takocle moraju meriti istim jeclinieama, mada te dve merne jedinice
ne moraju biti iste. Na primer, mozete porediti cenu izrazenu kao ulozeno
vreme, s vrednostima izrazenim kao dobitak u noveu. Posto se rezultujuCi
odnos koristi za poredenje s drugim vrednostima izracunatim sa istim jedini
eama, rezultati su potpuno ispravni.
Proeenjena eena moze se obicno izraziti u radnim casovima iii kao nov
cani iznos, a u pOSlovl10m okruzenju uglavl10m se jednostavno prelazi s jed
ne od tih jedinica na drugu. Medutim, posto oba ta izraza imaju i vise clrugih
znacenja, moze biti bolje da se eene izrazavaju u nekoj izvedenoj vrednosti,

poput "jedinica ulozenog trucla". Time se izbeg,nu n10guCllost hrkanja ,lllali

ze troskovu i clobitaka sa iznosi11la navec1enil1l II ponneli za izradll projekta ili
s vremenskim pI1l110111 izracle projekta.
Oelredi\'anje zajec1nil:kih jedinica mere za dobitke llloze biti nesto teze.
Mozete proceniti cia
na primer, Hutomatizovanje oclrec1enog raclnog pro
cesa poboljsati eflkasnost za 20 procenata i smanjiti broj gresaka za ,50 pro
cenata. Poboljsanje efikasnosti za 20 procenata moze se prevesti u broj
Ilstec1enih radnih sati, a i iz toga, ako treba, i u nov(';ani iZl1os. Odrec1ivanje
vrednosti za povecal1u tacnost mozda nece biti tako jednostavno. Mozda
cete moGi da procenite troskove (izrazene u vremenskim iii u 110vca11im jedi
nicama) otkrivanja i ispravljanja gresaka, ali to nece pokazati druge
neopipljive, mada vrlo stvarne dobitke, kao sto je osecanje dobra uradenog
posla zbog tacno unete porudzbine.
U takvim situacijama, dobitke mozete proceniti na vise nHcina. Na pri
mer, dobitke mozete proceniti izrazene u obliku "ustedenih iznosa", "za
radenih iznosa" i "nematerijalnih dobitaka". Izracunajte zatim tri odnosa, po
jedan za svaku vrednost. Time poredenje postaje nesto slozenije - varna i
vasem klijentu moze postati teze da odredite da Ii bi funkcija s vrednostima
3/6/2 trebalo da ima viSi prioritet nad onom s vrednostima 6/2/3. U tom
slucaju, mozete na odredeni nacin normalizovati vrednosti da biste dosH do
jedne pracene troskova i dobitaka.
Mozete se opredeliti da saberete vrednosti iz svake kategorije dobitaka,
ukoliko su one pribliZno podjednako vazne. Razume se, pri tome sabirate ja
buke i pomorandze, ali je u ovoj fazi prihvatljivo da ih posmatrate !<ao voce.
Ponekad ce prosecna vrednost izgledati prikladnija.
N ajcesce se desava da kategorije nisu podjednako vazne u organizaciji.
U tom slucaju, svakoj kategoriji mozete dodeliti relativnu vrednost j zatim
mnoziti svaku kategoriju s tim koeficijentom vaznosti. Na primer, u vezi s ka
tegorijama navedenim u prethodnom odeljku, mozete odrediti da "ustedeni
iznosi" nisu bas toliko vazni, ali da "nematerijalni dobici" jesu, dok Sll "za
radeni iZl1osi" dvaput vazl1iji od "nematerijalnih dobitaka". Tako biste
"ustedenim iznosima" dodelili koeficijent 1, "nematerijalnil11 dobicima" koe
ficijent 2, a "zaradenim iznosima" koeficijent 4. Rezultati su prikazani u ta
beli 10-I.
Neretko se procene dobitaka lakse izrazavaju u relativnim, umesto u ap
solutnim iznosima. Na plimer cesto tesko dodeliti funkciji X nematerijalni
dobitak od 3. Ali se obicno moze reCi da
funkcija X verovatno doneh dva
put veci nematerijalni dobitak od funkcije Y, a funkcija Y i funkcija Z ce vero
vatno doneti jednake nematelijalne dobitke.

Tabela 10-1 Primer analize ponderisanih dobitaka

Funkcija 1

11

22

3,6

7,0'

Funkcija 2

11

32

3,6

10,6

Analize troskova i dobitaka mogu biti korisne za utvrdivanje predvidenih

dobitaka koje ce novi sisitem doneti. One omogucavaju jednostavno pore
denje relativnih vrednosti pojedinacnih komponenata, sto moze biti k011sno
pri odredivanju opsega projekta i vremenskog plana izrade projekata. Medu
tim, to su samo alatke Cija se upotreba zasniva na najboljim procenama, sto
znaCi da ne treba da ih tretirate kao apsolutno tacne vrednosti. Cak i ako
funkcija X ima odnos dobitka 12, a funkcija Y ima odnos 2, moze biti ipak bolje
(iii tehnicki neophodno) da prvo napravite funkciju Y.
Rezultati analize troskova i dobitaka moraju se uporediti s drugim cini
oeima, kao sto su zavisnosti unutar sistema. Osim toga, morate ih ponovo
razmotriti kad god se vase poznavanje sistema poboljsa. Ponovite proeene
pre nego sto pocnete rad na svakoj komponenti. Moze se dogoditi da zbog
iskustva koje ste stekli radeCi s troskovima i dobicima prethodnih kompo
nenata, drugaCije proeenjujete buduce komponente.

;azetak
U ovom poglavlju, razmotrili smo aktivnosti koje omogucavaju upoznavanje
sistema na pocetku projekta. Prvo morate odrediti eiljeve sistema, a zatim ih
prevesti u konkretne projektne uslove kOji se mogu upotrebiti za procenji
vanje uspeha ili neuspeha pro.1ekta. Momte takode odrediti opseg sistema
graniee onog sto hoee i sto nece biti uradeno u okviru projekta.
Te aktivnosti su neka vrsta nultog koraka - sivari ko.1e morate obaviti pre
pocetka projektovanja sistema. U sledecem poglavlju razmatramo prvi "pra
vi" korak postupka pro.1ektovanja, a to je deflnieija radnih procesa koje ce si
stem podrZavati.

Definisanje radnih procesa

1ako je veliki broj sistema koji rade s bazama podataka projektovan za jedno
stavno sldadiStenje i uCitavanje odredenih vrsta podataka, svrha veCine je po
moe pri obavljanju odredene aktivnosti ili viSe njih. Te aktivnosti su radni
procesi (engL work processes) koje ce sistem poddati. Radni proees je skup
jednog ili vise pojedinacnih poslova, a oni zajeclno cine aktivnost koja ima
odredenu vaznost za organizaeiju. "Obrada porudzbine" i "Pronalazenje
kupeevog broja telefona" primeri su radnih proeesa, ali veoma razliCitih ste
pena slozenosti.
Posao (engl. task) jeste pojedinacna akeija, tj. korak tokom odvijanja
radnog proeesa. N a primer, proees obrade porudzbine moze se sastojati od
poslova "Evidentiranje porudzbine", "Provera iznos<1 kredita odobrenog
kupeu", "Provera stanja zaliha" i "Dostava prodate robe". Medutim, proees
pronalazenja telefonskog broja odredenog kupea verovatno bi se sastojao od
samo jednog posla, npr. "Pronalazenje zapisa 0 kupeu" iIi, ako volite da zala
zite u detalje, "Pronalazenje zapisa 0 kupeu" i "Prikazivanje saddaja
pronadenog zapisa 0 kupeu".
Razlikovanje posla od proeesa ponekad moze biti tesko jer se ta razlika
uglavnom odreduje proizvoljno. To je slieno odredivanju sta predstavlja data
skalarna vrednost u modelu podataka - jedan atribut u jednom modelu
moze biti razbijen na vise atributa u nekom drugom modelu. Aktivnost koja
se u jednom sistemu tretira kao posao moze se u drugom sistemu tretirati
kao proees i razdvojiti na zasebne poslove s nizim l1ivool11 detalja. Slieno kao
u postupku modelovanja podataka, svoju odluku morate zasnovati na seman
tici prostora problema.
U nekim sistemima nije moguea analiza radnih procesa. Na primer, alat
ke za izradu ad hok izveStaja ne podrZavaju nijedan konkretan proces, vee
odredene V1~'Jte aktivnosti. U takvim slueajevima, pogodnije je da pravite ko
risnicka seenarija. To je objasnjeno na kraju ovog poglavlja.

171

Odredivanje tekucih radnih procesa

DeHnisanje opsega sistema zapravo je prvi komI-:: pri analiziranju poslovnih
procesll, buduCi cia vam ta definieija pokazuje koje procese treba da analizi
rate. Heclosled koji~11 razmatrate pojedine procese unutar opsega sistema
obicno je nevazan. Cak i kad oclredene komponente sistema planirate ili rea
lizujete pre dlllgih (inkrementni razvoj), trebalo bi cIa obavite barem povr5nu
analizu svih radnih procesa koje sistem treba da podrZi pre nego sto zapocne
te njegovu izradu. To vam omogueava da otkrijete zHvisnosti izmedu procesa
(ako ih ima) od kOjih moze zavisiti redosled kojim eete realizovati pojedine
komponente.

Razgovori s korisnicima
Posto identifikujete radne procese koji spadaju u opseg sistema, vas sledeCi
zadatak je ela utvrelite koje se sve radnje obavljaju u tekucem sistemu da hi
se ti proeesi izvrsili. U ovoj fazi ne treba previSe da brinete 0 tome 5ta od
toga posao, a sta je, mozda, zaseban radni proces koji zahteva dalju analizu.
Samo naaite nekoga ko vam moze reei "ovaj elokument elobijamo oel prodav
ca i prvo pogledamo da Ii je pravilno popunjen; ako jeste, p11stupamo dato
ted kupaca i..." Postavljc~jte mnogo pitanja i zapisujte sve sto saznatc. Osim
toga, nabavite kopije obrazaca iii izvestaja kOji se tokom procesa koriste kao
ulazni podaci iIi kOji nastaju kao rezultat procesa. Cilj vam je da shvatite sta
se dogada; zasad jos ne anaIizirate proces.
Uzgred, mnogi ljudi nazivaju ovu fazu analize "razgovori s korisnicima".
Licno vise volim izraz "analiza procesa" iIi neki elrugi neutralan izraz. Vrlo je
lako potceniti strah kOji racunari izazivaju kod ljudi, cak i koel onih koji se
sluze njima. Buduci da su mnogi ljudi jos uvek zabrinuti da ce ih racunari za
meniti, izraz "razgovor s korisnikom" lako moze biti pogresno shvacen kao
"sad cemo videti ko ce dobiti otkaz". To narocito vazi za velike organizadje,
u kOjima obicno nije moguce razgovarati sa svakim pojedinacno, a mnogim
ljudima moze biti nejasno ko ste vi i sta je je tacno vas zadatak.
Kad goel je moguce (a nije uvek), trebalo bi da pokusate da razgovaratc s
pojedinicima koji zaista obavljaju proces koji vas zanima, a ne s njihovim l'U
kovodiocem sluzbe iii neposrednim nadreaenim. Iskustvo mi kaze da su ru
kovodioci skloni prikazivanju idealne slike procesa za koje su odgovorni.
Ljueli koji svakoelnevno obavljaju oelredenu aktivnost najbolje ce vam opisati
probleme i smetnje koje i111aju. Naravno, treba da razgovarate is nadreae
nima, buduci da oni cesto najbolje znaju zasto se odreaeni poslovi obavljaju,
kao i posledice njihovog neobavljanja iii loseg obavljanja.

'1'oko111 razgovora, obave7l10 raz1110trite i svc iZllzctke do kojh 1110ZC doCi

tokom procesa. Ako, na primer, korisnik kazc "provcravamo da 1i je porudz
bin a pravilno popunjena", obavezno saznajte sta se desava ako pormlzhina
Ilije pravilno popunjena. Najverovatnije je sa1110 vracaju posiljaocu, ali ipa!.::
morate saznati mozcla li pokusavaju da sami naclu neclostajuce podatke; ako
to Cine, mozcla bi vas sistem mogao da im olaksa posao. U stvari, za svaku ak
tivnost koju korisnik obavlja, trebalo bi da ga pitate sta sve moze poCi naopa
ko i sta se radi u takvim slueajevima.
Posto se u ovoj knjizi bavimo prvenstveno sistemima kOji rade s bazama
podataka, trebalo bi cla posvetite posebnu paznju naCinima na koje se podaci
koriste tokom procesa. Koji se sve podaci koriste? Odakle potieu? U kom
obliku stizu? Sta se mdi bda neki nedostaju iIi nisu u ispravnom obliku? Od
govori na ova pitanja predstavljace sirov materijal za konceptualni model
podataka kOji razmatramo u sledecem poglavlju.
Mnogi radni procesi sastoje se od poslova koje obavljaju razliCiti izvrsi
oci. Trebalo bi da razgovarate sa svim ueesnicima procesa kad goclje to mo
guee. Ova preporuka odnosi se i na Ijude koji se bave poslovima naizgled
izvan opsega sistema. Uzmimo na primer vee pomenuti proces obrade poru
dzbine. Posao "Dostavljanje kupljene robe" moze biti zapravo "Proslecli
vanje porudzbine sluzbi za dostavu", a sta se s porudzbinom clogacla u sluzbi
za dostavu moze biti izvan opsega vaseg sistema. Ali i clalje je korisno da ra
zgovarate s Ijudima iz sluzbe za dostavu da bi yam oni potvrdili da dobijaju
sve potrebne podatke u upotrebljivom obliku.
Slieno tome, ako se u bilo kom trenutku procesa stampa oclrecleni iz
vestaj, trebalo bi da razgovarate sa osobom kojoj je taj izvestaj namenjen i da
saznate sta ona dalje radi s njim. Zaeudicete se koliko papira kruzi organizaci
jom bez jasno viclljivog razloga. (A mozda se i neeete zaeuditi.) IIi, sto je eesCi
slueaj, posto.ji razlog za postojanje izvestaja, ali izvestaj sadrZi neodgovarajuce
podatke; iii saddi odgovarajuee poclatke, ali u neodgovarajueem formatu, pa
se zato mirno ocllaze u arhivu i ne koristi se za ono za sta je bio napravljen.

Identifkovanje poslova
Kada zavrsite razgovore s Ijudima sto obavljaju poslove koje ce vas sistem po
ddati, trebalo bi da prilieno dobro razumete aktivnosti koje se odvijaju u te
kucem sistemu. Vas sledeCi komk je da te infonnacije pretoCite u niz poslova.
Sustina je u tome da identifikujete poslovna pravila koja vaze tokom procesa.
N a poeetku ovog poglavlja, ree "posao" dcfinisala sam kao pojeclinaenu
akciju. Sada mozemo preciznije definisati sta ree "pojedinaena" znaCi u
ovom kontekstu. Ree ima dva znaeenja: akcija ima jasan poeetak i kraj, i sva
poslovna pravila vaze pre poeetka posla i nakon zavrsetka posh Tokom
izvrsavanja posla, pravila se mogu privremeno prekrsiti.

Poslovno pravilo (engl. business rule) nije nista clrugo do ogranicenje

iii uslov (engl. constraint) koji v(lzi u clomenu problema, za razliku 0c111S]OV<1
koji se odnose, na primer, na oc1rec1eni tip podataka. Tako, izraz "datum clo
stave porudzbine ne moze
36. april" nije poslovno pravilo, posto zavisi
od domena datuma. (A ionako je to prilicno besmisleno pravilo.) Mec1utilll,
izraz "datum dostave porudzbine ne moze prethoditi datumu prijema
rudzbine" zavisi od clomena problema; to je funkcija naCina na koji organiza
cija posluje. Prerna tome, to jeste - ili barem moze biti - poslovno pravilo.
Uzgred, izraz "poslovno pravilo" kOlisti se cak i kad organizacija, tehnicki
gledano, nije poslovna organizacija. U bazi podataka koju pravite da biste
podrZali svoju zbirku starinskih zvona, takode vaze poslovna pravila.
Velika vecina poslovnih pravila odnosi se na nacine rada s podacima.
"Postanski broj kupca je obavezan podatak" i "datum fakturisanja mora biti
jednak datumu dostave iii veCi od njega" primeri su poslovnih pravila koja se
odnose na podatke. Druga pravila, npl'. "potrebno je izriCito odobrenje di
rektora prodaje kada porudzbina pl'emasuje iZlloS kredita odobrenog kupcu"
ne odnosi se direktno na vrednost nijednog podatka, mada uzrok primene
pravila moze biti vrednost odredenog podatka, kao 1.1 OVOI11 slucaju.
Nel110jte blinuti; utvrdivanje poslovnih pravila koja vaZe za odrec'teni rad
ni proces nije tako tesko kao sto mozda izgleda. Tome sluze sva ona pitanja
tipa "Kako ovo moze krenuti naopako i sta vi radite ako se to desi?" U ovo.1
hlZi ne morate previse brinuti 0 detaljima tih pravila. Detalji su sastavni deo
postupka izracle konceptualnog modela podataka, Cime cete se baviti kasnije.
Zasad treba samo da grupiSete aktivnosti koje ste dosad otkrili, na naCin koji
vam ol11ogucava da l'azunmo pretpostavite da ce poslovna pravila vaziti pre
pocetka akcije i nakon njenog zavrsetka.
Pogledajmo primer. Pretpostavimo da lista akcija potrebnih za obradu
jedne porudzbine sadzi sleclece poslove:

1. Provera da Ii je pl'avilno popunjen obrazac pomdzbine.

2. Ucitavanje datoteke kupaca ako je u pitanju postojeCi kupac.
3. Unosenje podataka za dostavu robe.
4. Unosenje poclataka 0 porudzbini.
5. Dodeljivanje nove sifre kupca ako je u pitanju nov kupac.
6. Utvrdivanje da li narucene robe ima na zalihama.
7. Utvrdivanje iznosa kl'edita odobrenog kupcu.
8. Preuzimanje porudzbine,
9. Pakovanje robe.
10. Priprema dokumenata za dostavu robe.

Prvo sto bi trebalo uociti na ovoj listi jeste ela Sll aktivnosti nm-eelene po
malo nasumicnim reclosleclom. To je sasvim u rec1u. Zasacl samo pokusavate
da nlzumete kako se aktivnosti oclvijaju
. . 1I tekueem sistemu. Kasnije
. edc
preCi na preCisCavanje procesa. Osim toga, Cini se cia stavke liste opisuju ra
zliCite nivoe detalja. To pitanje razmotrieemo malo kasnije. Zasacl eemo
samo identifikovati poslove.
Prva stavka na listi, "Provera da li je pravilno popunjen obrazac porudz
bine", ima jasan pocetak i kraj. Ta akcija se odvija pri prijemu nove porudz
bine, a zavrsava se kada je proveren ceo sadrZaj dokumenta. Posto mozemo
pretpostaviti da sva poslovna pravila vaze na pocetku procesa, u ovom sluca
ju nemamo problema. Ukoliko dokument kOji predstavlja porudzbinu nije
uskladen s poslovnim pravilima, biee odbacen. Po tome znamo da ako se
proces nastavi na sledeeem koraku, pravila ee i dalje vaziti. Dakle, stavka
broj 1 moze se opisati kao posao.
Jedino poslovno pravilo koje se odnosi na drugu stavku, "Ucitavanje da
toteke kupaca", jeste da osoba koja to cini mora imati pristup datoteci. Posto
eemo pretpostaviti da svako ko izvrsava ovaj proces ima pristup datoteci, to
nam ne govori da Ii je u pitanju posao. Akcija pocinje nakon zavrsene prove
re dokumenta porudzbine, ali posto se datoteka koristi i u kasnijim akcijama,
trenutak zavrSetka ove akcije nije poznat. Prema tome, to ne moze biti po
sao, vee samo jedan od koraka nekog posh
U stvari, datoteka kupaca se kOlisti u stavci 3 ("Unosenje podataka za do
stavu robe") i u stavci 5 ("Dodeljivanje nove sifre kupca"), sto je prva naznaka
da te stavke pripadaju istom poslu. Jasno je da se stavke od 2 do 5 mogu gru
pisati u jedan posao koji biste nazvali, na primer, "Evidentiranje porudzbine".
U ovom slucaju, stavka 4, "Unosenje podataka 0 porudzbini", sasvim je 06
gledno deo postupka evidentiranja porudzbine. Ipak, nemojte se iznenaditi
ako othijete da se neki poslovi odvijaju istovremeno. U rucnom sistemu,
neko lako moze da popunjava dva obrasca u isto vreme. Nebitna je cinjenica
da ti obrasci pripadaju logicki razlicitim poslovima.
Sada imamo nov posao koji se sastoji od cetiri koraka. PoCinje nakon pro
vere da Ii je izvorni dokument pravilno popunjen, a zavrSava se kada je cela
porudzbina evidentirana. Ali, postoji problem. Vas klijent ne dozvoljava da
kupci salju porudzbine koje premasuju iznos odobrenog kredita, a iznos kre
dita se ne proverava pre stavke 7, "Utvrc1ivanje iznosa kreclita odobrenog
kupcu", posle provere da Ii narucene robe ima na zalihama. Mec1utim, dok ne
bude potvrdeno da je porudZbina ispod granice maksimalnog kredita odobre
nog kupcu, ne mozete biti sigurni da Ii poslovna pravila i dalje vaze pre i posle
posla. Prema tome, stavka 7 je deo posla "Evidentiranje porudzbine".

Stavka (i, "Utvrciivanje da Ii namc'ene rohe ima na zalihama", logii:ki llC:'

pripacla poslll e\'ic1entinmia porucl~bille. Ona prerlstm'lja
posao koji
pocinje nakon zHvrsetka posla "Evidentimnje porudzbine" a zavrSHV<! kada
stigne potvrcla da na zalihamtl ima dovoljno robe za isporuku. Dakle. stnvka
6 je sama za sebe nov rosao. Nel1lojte reCi da vas nisam upozorila.
U situacijama slicnim opisal1oj, obavezno saznajte ;::.a.<fto na prvi pogled
izgleda cla se poslovi odvijaju neodgovarajuCim redosledom. Najcesce je to
samo pitanje pogodnosti, ali Sll povremeno te neuskladenosti rezultat opera
tivnih ogranicenja koja mogu llticati na procese II sistemu koji razvijate.
U mweclenom primeru, ako se prvo proveravCl da Ii ima dovoljno robe na
zalihama samo zato sto je to logisticki lakse proveriti, mozete promeniti re
dosled aktivl1osti. Ali, moze 5e dogoditi cia otkrijete llzajamni uticaj izmecill
procesa evidentiranja porudzbine i procesa proizvodnje robe koji zahteva da
5e stanje zaliha proverava odmah, a taj uticaj morate ugraditi II sistem kOji
projektujete.
Ako bismo kasnije otkrili cIa se porudzbina l1e moze prihvatiti ukoliko
nema dovolj110 robe na zalihama, posao "Utvrdivanje da Ii narucene robe
ima na zalihama" postao bi korak posla "Evidentiranje porudzbine". Kao sto
cemo videti u narednom ocleljku, premestanje aktivnosti iz jednog posla u
drugi i izmedu logickih nivoa prilicno je jedllostavno. Pri tome je kljncl10 da
identifikujete aktivnosti.
Analiza sleclece tri stavke 8, 9 i 10 zavisi od opsega sistema. Ukoliko
je dostava narucene robe cleo sistema kOji razvijate, te stavke treba pazljivo
razl11otriti. Ako se, sto je verovatnije, opseg sistema zavrsava !mel se obrade
n<1 porudzbina prosledi sluzbi za clostavu kupljene robe, te stavke se 1110gu
"zgusnuti" u jedan POSHO, ,,Isporuka porlldzbine".
Slucajno znamo da se U ovoj hlZi moze dogoditi vise stvmi i nem<l razloga
cIa zanemarimo tu informaciju. OciglecIno je cIa su preostale stavke poslovi.
Poslednja stavka na Iisti, "PIiprema dokumenata za dostavu robe", moze cak
biti ceo jedan radni proces. Ali, bucIuCi da se ti poslovi nalaze izvan opsega
projekta, navescemo ih kao korake cia bismo sacuvali ono sto zna1110 0 sistemu
i l1e6e1110 5e clalje baviti nji111a. Nasa izmenjena Iista poslova izgIeda ovako:
POSHO 1: Provera ela Ii je pravilno popunjen obrazac poruclzbine
IZllzetak: :"Jepotpuna pOllJdzbina se oclbacuje
POSHO 2: Evidentiranje poruelzbine
Korak 1: Ucitavanje datoteke kupaca
lzuzctak: Ako je clatoteka nedostupna, poruc!zbilla se
zadrzava
Korak 2: Unosenje poclataka za clostavu robe

Korak 3: Unoscnje podataka 0 poruc!zbini

Korak 4: Dodelji\anje llove sifre kllpea
Korak 5: Utvrdivanje iznosa kredita odobrenog kupcu
Izuzetak: Obavestiti direktora prodaje
POS<lO :3: Utvrdivanje da li narucene robe illla na zalihama
Izuzetak: Obavestiti direktora prodaje
Posao 4: Pros1ed.ivanje poruclzbine sluzbi za dostavu robe
Korak 1: Preuzimanje porudzbine
Korak 2: Pakovanje robe
Korak 3: Priprema dokumenata za dostavu robe
Tokom postupka organizovanja aktivll0sti u poslove i procese, gotovo si
gurno cete naiCi na stvari koje niste razumeli onako dobro bo sto ste mislili,
pa bi trebalo cla ponovo razgovarate s korisnicima kOji ce \lam pruziti potrebna
objasnjenja. U svakom slucaju, procese morate razmotriti zajedno s kOlisnici
mao Cesto se dogada sledece: bda korisnici vide proces u pisanom obliku, to
ih podstakne da yam pruze dodatne infonnacijc korake koje su zabormili cIa
yam opiSu, iii izuzetke 0 kOjima ste zaboravili cIa ih pitate.

~naliziranje

radnih procesa

Posto sada imate jasna saznanja 0 tome kako se stveu; mde u tekucem sistemu,
mozete razmobiti radne proeese da biste otkrili moguca poboljsanja. Kao sto
sam pomenula, u veCini organizacija postoji jaka inercija. To vazi podjednako i
za proeese i za rad s dokumentima. Uvodenje novog racunarskog sistema
pruza odlicnu priliku da se organizacija oslobodi dela starih navika.
Postoji staro pravilo efikasnosti koje propisuje da ne bi trebalo obradiva
ti nijedan dokument viSe od jedanput. Kao i mnoga druga pravila, ni 0'1'0 nije
uvek prakticno, ali nije neubiCajeno ustanoviti da se radni proces moze po
jednostaviti menjanjem redosleda poslova 11 njemu tako da se izbegne ra
zmena delova posla izmedu ucesnika u procesu iIi drugih procesa. Iz nekog
razloga, postupak tipa "ja uradim A i dam ga tebi, zatim ti uradis B i vratis ga
meni, a onda ja uradim C" te5ko je prepoznati kacla ste njegov neposreclni
ucesnik, ali postaje vidljiv cim se aktivnosti napiSu.
Da biste mogli da pravite til vrstu analiza, moraju yam biti veoma jasne
zayisnosti izmedu pojeclinih poslova. U svako111 procesu, neki poslovi zavise
od drugih pos10ya i moraju se obaviti tacno odredenim redosledom. Na pri
mer, sluzbi za dostavu robe ne mozete proslediti porudzbinu pre nego !ito je

e\'identirate, Redosled drugih poslova moze biti prilicno nezClvisHlI. ::\a

mer,
bas nmogo vazno cia Ii 11O\'om kupctl dodeljujete sihu pre ili posle
11110Senja podataka za clostavu robe.
Narocito je vazno da utvrdite zavisnosti izmeclu podataka. U l1eki111 po
slovima nash\ju novi podaei, kao sto su sifre kupaca, kOji se potom koriste It
drugim poslovima. Na pJimer, jedan moj klijent kOlistio je proces evidenti
ranja porudzbina sliean opisanom u prethodnom odeljku, s tom razlikom sto
je sluzba raeunovoclstva dodeljivala sifre kupaca i ispitivala iznos odobrenog
kredita umesto sluzbe prodaje, koja je bila odgovorna za obradu porudzbina,
Klijentov prvobitni raelni proces izgledao je ovako:
POSClO 1: Provera da Ii je pravilno popunjen obrazac porudzbine
Posao 2: EV:identiranje porudzbine
Korak 1: Ueitavanje elatoteke kupaca
Korak 2: Unosenje podat aka za elostavu robe
Korak 3: Unosenje podataka 0 porudzbini
POSC10 3: Provera kredita odobrenog kupcu
Korak 1: Ispitivanje kupeevih referenci
Korak 2: Utvrdivanje maksimalnog iZ110SH kredita
Korak 3: Dodeljivanje sifre kupca
Posao 4: Zavrsetak porudzbine
Korak 1: Utvrdivanje ela Ii narueene robe ima 11a zalihama
Korak 2: Prosledivanje porudzbine sluzbi uza dostavu robe
Posao 3 obavljala je sluzba racunovodstva, koja je vraeala porudzbinu
sluzbi proelaje samo ako je provera kupcevog kredita pokazala cia se porudz
bina moze prihvatiti. Problem s tim naCinom rada jeste, to sto Sll podaci 0 po
rudzbini vee uneti. To je znacilo ne samo nepotreban rad ako porudzbi11a 11ije
mogla ela se plihvati, vee i doelatan, naknadni mel, posto sn se te "mrtve" po
rudzbine morale povremeno uldanjati iz sistema, To je takode znacilo ela je
osoblje zaduzeno za unosenje podataka bilo na meti sporova izmedll slllzbe
racnovodstva i ljudi iz sluzbe prodaje, kOji su zeleli cIa njihove poruelzbine
bucIu evielentirane (i provizije isplaeene), Promena redosleda izvrsavanja po
slova tako da se provera kredita obavlja pre nego sto se porucIzbina prosledi
osoblju koje nnosi porudzbine u sistem, eliminisalo neefikasnost i sporove,
Osim utvrc1ivanja zavisnosti izmedu pojeelinih poslova, trebalo bi takode
da ispitate i111a Ii poslova koje viSe ne treba obavljati. Oni su retko kat! oci
gledni, ali ponekad, ako pratite poelatke kroz proces, naci cete podatke koji
se generiSu racIi upotrebe II nek0111 drugom poslu ili procesu, ali kome viSe

potrc:bni. Manic: je vc:rO\atno

ce ceo POStlO, ili cak sa1110 1 koraci
unutar posh biti nepotrebni. Vecina Ijudi je clovoljno pnrnctna (b
nepotreban posao, ali takav slucaj moze biti zaklonjen intc:rakcijama izmedll
procesa. Najuobii:ajeniji primer toga.ie izrada ncpotrebnih izvestaja.
Hazume sc, to nijc razlog da SV0111 klijentu namcccte sustinske izmenc
nacina poslovanja. Kao sto ne bib pre1'orucila ni
svojoj tetki Gertrudi ka
zete kako bi trebalo da promeni svoj naein zapisivanja mustri za pletenje koje
vam je zatrazila da organizujete na mennaru. U raclnim procesima retko cete
naiCi na ozbiljne neefikasnosti. Vas posao .ie da, gcle god mozete, pomognete
svojim klijentima da bolje obavljaju svoj 1'osao, a deo vasih obaveza je i ispiti
vanje radnih procesa.
niSll

aa

Dokumentovanje radnih procesa

Kao i u drugim delovima postupka projektovanja, vreme koje cete posvetiti
analiziranju radnih procesa i formalnost dokumentacije koju cete napraviti
treba da buchl srazmerni slozenosti sistema. Za jednostavan sistem ZH be
lezenje imena i telefonskih brojeva, mozda nece biti potrebno vise od jed
nocasovnog razgovora i nekoliko kratkih belezaka koje cete napraviti za
vlastitu I.lpotrebl.l.
Medl.ltim, ako niste istovremeno i klijent i projektant, preporucila bih
barem dva sastanka cak i za najjednostavnije projekte, Svrha drugog sastan
ka je da utvrdite da Ii ste dobro razumeli klijentove potrebe i da yam on
potvrdi da je ono sto ste shvatili i nameravate da uradite ispravno.
Slozeniji projekti mogu zahtevati vise sedmica razgovora s desetinama
Ijudi i srazmerno tome slozenu i formalnu dokumentaciju. Strukturirana Ii
sta poslova i koraka sliena onoj koja je navedena u ovom poglavlju moze biti
dovoljna za dokumentovanje jednostavnih procesa. Za slozenije proce5e vise
volim da upotrebim sliku.
Dok 5U E/R (Entity Relationship) dijagrami koji se koriste za dokumen
tovanje veza izmedu podataka prilicno dobro standardizovani u oblasti
projektovanja, dijagrami za radne procese nisu tako konsistentni. Tekuce
metodologije za izradu dijagrama obieno su tesno povezane sa odredenim
tehnikama analize i slede pomodne trendove.
Ako poznajete neku od tih metodologija i volite da je koristite, ne111<1 ra
zloga da je menjate. U ovom slucaju, vas cilj je da razumete infonnacije do
kOjih dodete i da ih prosledite drugima. UML, dijagrami tokova podataka i
clijagrami kvaliteta procesa korisne su alatke. Specifiene tehnike izrade clija
grama ocluvek su 111i izgledale kao prilicno besmislen razlog za zapoCinjanje
"verskog rata", mada se i to cesto dogada.

Ukoliko ne pOZl1<ljete nijednn f(lrll1Hlnu tehniku, lako 1110zete slllisliti

v\astitu. Potrebno vam je pet simbola koji ce predstadjati posao, dokul11cnt,
podatak, tacku donosenja odluke i dogac1aje, kao sto S11 poc:etna i zavrsna tac:
ka posh Simboli koje koristim U SV0111 radu prikazani su na slid 11-1.

Tacka
donosenja
odluke

Podatak )

Slika 11-1 Simboli za elemente radnih procesa

Ako je za obavljanje odredenog posla potreban relativno mali broj kora

ka, navodim ih unutar okvira kOji predstavlja taj posao. Ako ima previSe ko
raka da bi to bilo izvodljivo, svaki posao prosimjem u zaseban dijagram, na
kome svaki komk predstavljam jednim okvirom za posao. Ponekad, da bi
dijagram bio jasniji, koristim sencenje ili deblje linije kako bib istakla cla
oclredeni posao obavlja neka spoljasnja gmpa, kao kada racunovoclstvena
sluzba ispituje kOji je iznos kredita odobren novim kupcima.
Simbol za podatak moze da predstavlja jedan atribut - n<1 primer, sifru
kupea ili ceo entitet, kao sto je kupac viden kao celina. Kada se podatak ge
neriSe tokom odvijanja nekog posla, to mozete istaknuti pomocu senc:enja iIi
debljih linija Neki analiticari vole da pokazu i slueaj kada se podatak "trosi"
unutar nekog posla, tj. kada se podatak koristi unutar posla ali se kasnije ne
deli ni sa jednim drugim poslom tokom odvijanja procesa. Iskreno reeeno,
dosad nisam imala slucaj da mi je to hila korisna infonnacija i viSe volim da
ne pretrpavam dijagrame.
Posto izaherete simbole koje cete koristiti (toplo preporucujem simbole
koje mozete lako da nacrtate slobodnom rukom, umesto onih kOji imaju pre
vise strogo odredeno znacenje), potrcban yam je naein cla ih organizujete.
Zavisnost pokazujem pomocu strelica, a linijama koje se racvaju pokazujem
cla se poslovi mogu obavljati proizvoljnim redosledom. Otvorcn kruzic na Ji
niji pokazuje da posao nije ohavezan, isto kao na E/R dijagramu. Povezivanje
poslova unutar radnog procesa prikazano je na slid 11-2.

Slika 11-2 Povezivanje elemenata radnog procesa

Ako ustanovite da su vasi radni procesi previse slozeni da bi 5e mogli

predstaviti P0l110CU ove jednostavne tehnike, predlazem vam da pogledate
jednu od detaljnijih metodologija kOje cete naci U svakom dobrom prirucni
ku 0 projektovanju i analizi sistema. U bibliografiji je navedeno vise njih.

Korisnicki scenario
Alternativa formalnoj analizi radnih procesa jeste identifikovanje korisnic
kih scenarija. Korisnicki scenario sastoji se od dve komponente: skupa
od jednog iii viSe korisnickih profila kOji opisuju razne vrste korisnika
predlozenog sistema, i po jednog scenarija upotrebe za svaki korisnicki
prom, sto su narativni opisi naCina ua koje se ocehllje da korisnik upotreblja
va predlozeni sistem, tj. aktivnosti kOje se ocekuje da ce on iii ona obavljati.
lako se pomocu korisnickih scenarija mogu pribaviti iste informacije kao
pomocu analize radnih procesa, kOlisnicki scenariji su viSe usredsredeni na
naCine na kOje kOlisnici upotrebljavaju predlozeni sistem, a manje na speci
ficne korake transakcije. BuduCi da se viSe bave naCinol11 rada korisnika, po
nekad je tesko pripremiti korisnicki scenario koji ne bi zavisio od korisnickog
interfejsa sistema.
MedutiIl1, posto je namena metode da se utvrde korisnikovi ciljevi i oce
kivanja, korisnicki scenalio je narocito pogodan za sisteme koji treba da po
drze ved broj ad hok aktivnosti. Analiticaru omoguCava da se usredsredi na
vrste poslova koje korisnici treba da obavljaju, a cIa se pri tome ne "zaglibi" L1
mehanizme procesa koji jos nisu ni definisani.

I\' a primer, cuk i \TID jeclnostavan scenario, koji glasi: ,Trgonlcki putnici

ce koristiti sistcm da bi pmtili status poruc1zbina s\'ojih

klijcnata, od 11110SC
nja pormlzhine, do clostave
fakturisanja i uplata odgovarajuCih iZllosa",
tacno opisuje kako ce ta grupa korisnika koristiti sistem. Opi5 ne namccc ni
bkve odluke 0 detaljima funkcionisanja korisnickog interfejsa.
Hazvoj korisnickih scenarija i analize radnih procesa nisu me(tusobno
isldjucivi. Analize rac1nih
k01'isl1e su za razmatranje samih radnih
proeesa, dok ko1'isnicki scenariji opisuju nacine na koji ce pojecline g1'upe ko
risnika koristiti sistem. U vecini sistema, to su podjednako vazna pitanja.
Kada je projekat dovoljno
da opravdava napor, svakako je ko1'isno da
obavite obe vrste analiza, narocito zato sto se korisnicki scenariji obicno
1ll0gU izvesti na osnoVll informacija koje pribavite tokom analize radnih
cesa, bez dodatnih razgovora ili analiziranja.

;azetak
U OVOll1 poglavlju razmat1'ali smo nacine na koje mozete steci saznanja 0
aktivnostima koje predlozeni sistern t1'eba da podrZi. To se moze otkriti
moeu analize procesa S 1'azlicitim stepenima fo1'malnosti, izradom ko1'isl1i6
kih scenmija iIi kombinacijom te dye tehnike. U poglavlju 12, bavieemo se
izradom konceptualnog modela podataka, sto je ]ogicki opis nacina l1a koje
ce 5e podaci generisati, strukturi1'ati i koristiti u sistemu.

Konceptualni model
podataka
U ovoj fazi postupka projektovanja, trebalo bi da imate jasnu sliku onoga sto
treba da postignete. Definisali ste opseg projekta, odredili ste sImp projekt
nih uslova i analizirali ste radne procese. Vreme je da zapoenete izradu 1110
dela podataka.
Podsetite se da konceptualni model podataka sadrzi opis entiteta, njiho
ve atribute i veze izmedu njih. To nije sema baze podataka, koja opisuje
zieku strukturu tabela. Zasad jos ne znate kako se ona pravi. Da biste 1110gB
da napravite sernu, prethodno morate osmisliti korisnieki interfejs i odrediti
arhitekturu na osnovu koje
napraviti sistem.

Identifikovanje elemenata podataka

U ranijim fazama analize, prikupili ste iii ste sami napravili skup izvornih do
kumenta. Taj sImp se sastoji od dokumenata koje yam je prosledio klijent
uzorci obrazaca za unosenje podataka, plimeri izvestaja i tome slieno i do
kumentacije 0 radnim procesima koju ste vi pripremili. Prvi korak u
modela podataka jeste da pregledate te izvore informacija i da sastavite
spisak svih podataka s kOjima sistem treba da radio
Poenite od nekog radnog procesa. Nevazno je od kog cete krenuti, ali ja
obieno biram jedan od najvaznijih u projektu, buduci da se u vaznim
sima koristi i vecina entiteta. VeCina radnih procesa zapocinje kada se pojavi
odredena vrsta papirnog dokumenta, npr. kada prodavac preda popunjen
obrazac porudzbine sluzbeniku koji je zaduzen za unosenje porudzbina. Po
nekad radni proces zapoeinje zbog drugog dogadaja, kada je jedan od prvih
poslova najeesce popunjavanje papirnog obrasca. N astavljajuCi s nasim pri
merom obrade porudzbina iz poglavlja 11, obrazac porudzbine moze biti na
lik na onaj sa slike 12-1.

183

/',
"It.

.0'~::I. .~NORTHWINn

INVOICE

TUDt!tS

~Iat.t: 03-Hov-2004
/',\,w,

:,:I" ..'."!iI' h.

Ship TCC

.,\."

AJtedS FutterldS'te
Ooere St;, ~7

E:i! 10:

~fmd$ F\..1terklS'te

Chen: Str, 67

Berlin 1220'il

Berlin 1120g

O.;'!l1l'\any

Germany

ProlrotHl:

Pro:lwtttrne:

Quantity:

UllitPrlOO:

[iSOOlJlt:

Ex\endJdPrlre:

28

Rossie Sauerkral",t

15

$46BO

25 %

$013.00

39

Ch:;utreuse verte

21

$18DO

Z5~

$2$3.60

4Il

Spegesild

$12 DO

25%

$18DD

Subtotal:
ff1?iit,l:
lotal:

$814.50
$2g.4Il

$84H6

Slika 12-1 Vecina radnih procesa zapocinje kada se pojavi papirni dokument
nalik ovoj narudzbenici

Pronadite uzorak ovog prvog bloka podataka i zapisite sve podatke koje
on sadrzi. Nemojte jos razmiSljati 0 razvrstavanju elemenata podataka na
entitete iii atribute, samo ih zapiSite. Obavezno zabelezite grupe koje se
je
navljaju, ako ih ima, a treba ida identifikujete elemente podataka za
vasa analiza radnih procesa pokazala da nedostaju. Vasa pocetna Usta ele
menata podntaka moze biti sliena onoj nn slid 12-2.

S'a1e.!'tJI'I""
8111 r; tfl"'u-~
Si;i>T. tf/"'u-~

"i

ci!"

Si;i>lIta
tJl'/.,.[M"

fj.,,J,,.c
U<ICPl'lb.
{Jt~M4.c

Slika 12-2 Pocetna lista elemenata podataka na obrascu porudzbine

Posto sastavite liStll, mozete zapoceti izclvajanje entiteta, atrihllta i \-eza

izmec1u njih. Za SVakll stavku na listi, I1tvrclite cla 1i je 11 pitanjll objekat iii
cinjenica koja se odnosi na neki objekat. Objekti postaju entitieti a cinjenicC:'
postaju atributi entiteta. Hezultati te analize \-crovatno ce biti slicni onima
na slici 12-3.

0"af"" On!",
81ff T- A!!,w,
0"ip T- A!';""",

?+--

saM;'''''''
0"ip0,

O,.!.,.OaCe
Oac.Rf"r.!
PNcl.d

U'"tPNC'

O,.!",.Odaif

Cu..rt(Jl1(er

C,,,,;,a'\f;V,,,,,,
C"Cad;V"",.

A!';""",

~
81fft:"
0"Cred

0"ip!":"

C,t,r

tZ"CIt,r

0"Cac.IP",,;,f,'
C,"IfC,.,
P,dafC,!.

Oi.rG(J"l(t

Ed'If!.!PNC.
O,.!.,. T-taf

P,.,cl.d
;V""'.
0"lWftbr

? +-- CaCep",

tZc, P.,. U'lflt

U'lflt.Jo ;;. 0"c,d

------+ 0"lWftbr

Slika 12-3 Prva verzija definicije entiteta i atributa na osnovu obrasca

narudzbenice

Kao !ito vidite, stavke Bill To (adresa l1a koju se salje faktura) i Ship To
(adresa za dostavu robe) identifikovane su kao cinjenice koje se odnose na
dodatni entitet Customer (kupac). Medutim, nije odmah jasno da li te dve
adrese pripadaju samo entitetu Customer, samo entitetu Sales Order (po
rudzbina) ili oboma_ Isti princip vazi i za pridruzivanje elementa Unit Price
(jedinicna cena) elementu Order Detail (stavka porudzbine). Isto kao !ito je
tekuca prodajna cena artikla logicki razliCita od cena po kojim<l je taj artikal
ranije prodavan, tekuce adrese klijenta na koje se salju faktura i roba logicki
su razlicite oel adresa na koju su ova faktura i roba bili poslati.
Da Ii su aelrese za dostavu robe i fakture takode atributi entiteta Custo
mer, pitanje je procene na osnovu prirode sistema i njegovih korisnika. Ako
te atribute dodelite entitetu Customer, m06 cete da zadate podrazumevane

vreclnosti
se preuzimaju pri unosenju porudzbine, !ito smanjuje vreme
potrebno za taj posao i mogucl1ost cIa 5e pri unosenju poclataka pogresi.
:vlec!utim, time se uvodi dodatan posao odrZHvanja tih vreclnosti u enti
tetu Customer. Aleo klijenti organizaeije imaju vise adre5a na koje im 5e do
stavlja kupljena mba (na primer, u pitanju je lanae maloproclajnih objekata),
taj cloclatni posao moze biti obiman, pa je bolje da se acIresa za clostavu robe
unosi kao sastavni deo procesa evic1entiranja poruclzbine.
Ponekad je najbolje resenje nesto izmedu te dve krajnosti. Na primer,
entitetu Customer mozete doclati vise atributa za dostavnu adresu, ali da pri
tome ne zahtevate c1a ih korisnik sve popunjava. Ako za odreclenog kupca
postoji S<1mo jedna adresa, sistem moze da je upotrebi kao podrazumcvanu.
Ukoliko postoji viSe adresa, sistem moze da ponudi korisniku listu adresa sa
koje ce on izabrati odgovarajucu. IIi, mozete ugracliti uslovnll logiku koja ko
risniku predlaze poslednju upotrebljenu aclresu ali mu clozvoljava i da izabe
re drugu ako je potrebno.
Mozete razmotriti i resenje u kome se entitet Customer azurira u proce
su unosenja poruclzbine. Ako nema adrese, iii korisnik unese novu aclresu,
sistem moze da pita treba Ii je plidruziti zapisu 0 kupcu. Postoje problemi s
korisnickim interfejsom, ne s modelom podataka, ali su te dve oblasti pone
kacl tako tesno povezane da 5e ne mogu potpuno razdvojiti.
Elem.ent podataka Salesperson (proclavac) takocte upucuje na to da
negde postoji entitet Employee (zaposleni), ali posto jos ne znmno kako bi
trebalo da on izgleda, stavljamo znak pitanja. Postoji verovatnoca da ce i
drugi dokllmenti ili procesi koristiti taj entitet. Ako bude tako, 111oze1110 do
dati potrebne atribute. U suprotnom, mozete se opredeliti da ostavite Sales
person kao atribut entiteta Sales Order. Ne zaboravite da se ta vrsta odluke
mora uvek zasnivati na semantici sistema. Necete dobiti apsolutno nista ako
napravite ehan za unosenje podataka 0 zaposienima, s nadreclenima, slu
zbama i lokalnim telefonskim brojevima, ako se ti podaci koriste senno za pri
kazivanje imena prodavca na narudzbenici.
Product (altikal) identiflkovan je leao entitet, a grupa elemenata koja je
identifikovana na prvom dijagramu kao grupa koja se ponavlja (Product Imti
kal!, Unit Price Ijedinicna cena/, Quantity Ikolicinal i Discount Ipopust/), iclen
tifikovana je kao entitet Order Details (stavke poruclzbine). Za entitet Product
identifikovan je pocetni sImp atlibuta, verovatno na 05noVU nekog drugog
izvomog dokumenta, a sa ove liste identifikovani su entiteti Supplier (doba
vljac) i CategOlY (kategOlija mtikala), mada ni za njih nemamo dmgih detalja.
Posto entitete definiSemo na konceptualnom nivou, u ovoj fazi nas ne
zanima cla Ii se atributi poput Extended Price (iznos po stavci) entiteta Or
der Detail ili Units In Stock (kolicina na zalihama) entiteta Product, cuvaju
kao vrednosti iIi izracunavaju kaela zatreba. Ne znamo ni da Ii se zapravo
mogu izracunati. To cemo videti kasnije.

Zanimljiv element podataka je atlibut Ship Via (naCin clostave). Na nlllO

narudzbenicama nalaze se "kuCice" za
nacina clostave, s vred
nostima, 11a primer,
posiljka", Jicno preuzimanje" i "DEL". D,l li
su to entiteti iIi ahibuti?
(Ovo ste pogodili, zm ne'?) Koliko je
opcija? Ako ih ima vise od dve, model s jednim atlibutom nece odgovarati.
Koliko 511 stabilne opcije? Vrlo je verovatno da za dostavu robe organizacija
kOlisti usluge spoljasnjih kompanija. Da Ii je verovatno dOl ce organizacija me
njab davaoce tih usluga ili unajmiti nove? Koliko organizacija mora biti otvo
rena za ~ove metode dostave? Da Ii ce odustati od prodaje ako klijent zahteva
cIa mu Serpasi cIostave robu na vrh Mont
Ako nece odustati, vas
model mora da podrfi sve te opcije.
Modelovanje nacina dostave robe kao zasebnog entiteta omogucava da
se podaci menjaju i dodaju u svakom trenutku, ali po cenu vece slozenosti i
modela podataka i korisnickog interfejsa. Razlika moze bib samo u nekoliko
pritisaka na tastere, biranju stavke sa padajuce liste iIi pot'lrdivanju nekog
pol.1a pomocu miSa. Ali posledica tih nekoliko dodatnih pritisaka na tastere
moze biti nezgrapan i spor interfejs.
Ako kompanija nudi i specijalne naCine dostave robe, 1110rnte paz]jivo ra
zmohiti kako cete to podrfati. Moracete da hodate tankol11 linijom izmcclU
fleksibilnosti ko.1a je dovoljna za obradu svih razumnih mogucnosti i name
tanja nepotrebnog opterecenja kOlisnicima sistema. U ovom primel1l, na.1
bolje resenje 'lerovatno bi bilo doda'lanje neobaveznog atributa Posebna
uputstva, ali on mora biti podrzan i u moclelu podataka i u procesima sistema.
Te odluke mogu da na neoceki'lan na611 uticu na pravila koja 'laze u 5i
stemu. U OV0111 primeru, iako je jasno da orgnizacija mora da zna kako ce po
slati robu kupcu, to se viSe ne s'lodi na jednostavno biranje n<1ci11 <1 dosta'le. U
sistemu sada mora vaziti da ne mogu aba atributa, NaCin dosta'le i Posebna
upustva, biti prazna, sto je nesto slozenije pravilo koje se mora realizo'lati na
razlicitom ni'lou modela.
Ako je proces dosta'le robe sadrzan u definisanom opsegu sistema, po
smatranje NaCina dostave kao zasebnog entiteta moze biti dobra
pa
cak i oba'lezno - ali doda'lanje posebnih metoda za izuzetne slucaje'le moze
znacajno dodatno opteretiti sistem. N a osno'lu cega bi se un eli cletalji 0
odredenom nacinu dostave, ako on ne moze unapred biti poznat? Jec1no re
senje je da napravite opsti entitet dosta'le robe, sa atributima kOji postoje u
'leCini metoda kao sto su broj otprenmice i vreme izdavanja robe iii mozete
zadati poznate metode, a speci.1alne slucajeve osta'liti da budu to sto jesu
izuzeci koji se llloraju obradivati izvan sistema.
PIi tome postoji opasnost da preterano zakomplikujete sistem i da bez
potrebe opteretite njego'le kOlisnike. Izuzetno je lako da se odusevite funkci
onalnoscu koju
sistem biti u stanju da pruzi, previdajuCi pli tome dodatni
posao koji je za to neophodan, Da, obezbedi'lanje podrazume'lanih vrednosti

jcste korisl1o, pod /lslovom cia se one lako mogll odrZavati i da se to red()\"ll()
cini (najbolje kao dopunski rezultat nekog drugog posla). OmoguCiti rcecpcio
neru da odgovam na pitanja 0 dostavi robe jeste dobro, <1Ii da Ii .ie to vreclllo
napora kOji bi bio potreban za ul10senje podataka 0 doshlVi Z,\ biljadu poruclz
bina sa1110 da bi ti podaci bili na nlspolaganju petorici kupaca koji se mspituju?
OdluCivanje zahteva S8mo da razmislite 0 posledicama projekt11ih odlub
koje donosite. Ali na to se lako moze zaboraviti pli prvoj odusevljenoj pomisli
"Nije Ii ovo super? Ustedeee 11am onoliko vreme". Kada god unosite mlre
deni podatak negde u sistem, razmislite da Ii se on mozda moze upotrebiti i II
nekom drugom delu sistema, kao podrazumevana vrednost iIi kao uslov za
nesto. Ako ionako unosite podatke za dostavu robe, sto ih ne biste ucinili do
stupnim i recepciollem?
Osim toga, kad koristite odredeni poclatak, razmislite 0 tome gde ce se
on unositi i gde ce se odrzavati, Opste pravilo glasi da je uglavnom bolje da
korisnicima ponudite listu stavki za izbor nego polje za tekst. Ali, popunja
vaBje i oclrzavanje liste stavki ima svoju cenu, kao !ito je ima i izrada odgova
rajuceeg korisnickog interfejsa. Morate pazljivo razll10triti ,we navedene
cinjenice da biste cloneli ispravne odluke 0 modelu podataka.
Naravno, eilj yam je da nikad ne zahtevate da se bilo koji podatak uliosi
dva puta. Ali, po istom principu, ne mozete primoravati korisnike da pri
vremeno prekinu aktivnost kojom su se bavili, da bi uneli poc1atak kOji im je
neophodan da bi obavili posao kOji su zapoceli. 0 tom problemu bice viSe
reci u cetvrtom delu knjige, ali utvrdivanje gde sve nastaju novi podaci i gde
se olli koriste kljucan je prvi korak postupka.

L)efinisanje veza izmedu entiteta

Posto ste razmotlili we izvorne dokumente, dobili ste grub opis entitieta i
atributa u prostoru problema. Preostaju jos dva posla: uspostavljanjc veza
izmedu tih entitieta i razmatranje atributa i uslova svakog entiteta.
1ako teorijski mozete razmotriti prvo ntribute, smatram da.ie lakse poce
ti oeI veza izmedu entiteta jer ce ncke medu njima postati doc1atni entiteti, a
zbog drugih eete morati da dodate nove atribute entitetima koje ste vee
identifikovali.
Ako ste kao ja, nakon prve studije izvornih dokumenata, imate hrpu ruc
no napisanih beleski sa strelicamCl i zvrljotinama tipa "videti str. 12" koje
niko clrugi ne moze da desifmje. Dakle, prvi korak pri definisanju veza iz
medu entiteta jeste da dovedete u red svoje beJeske. Mozete zapoceti time
sto cete napraviti prvu skicu E/R dijagrama modela podataka. (Ako su vam
beleske zaista zbrkane i necitljive i brinete se da kroz tri sedmice cak ni vi

necete biti u stanju cla ill citate, mozetc napraviti i Iistc atrillllta koic stc
iclentinkovali za s\'<iki
Pocnite tako sto tete izabrati jedan
ohicno jedan od llaj\'<lzllijih u
sistemu, a zatim dodajte entitete koji su s njim l1a bilo
naClll po\'czani.
U Split mozete clefinisati i prirodu tih veza ("jedan prema jeclan", "jedan
ma viSe", "vise prema vise"), ili mozete sa1110 nacrtati liniju koja ce vas pod
setiti cIa postoji nekaha veza, koju cete detaljnije analizirati kasnije, .Ta
obicno anclliziram veze dok crtam dijagram, ali vama ce mozcla biti !aIde da
prvo postavite sve entitete i da ih zatim analizirate.
Prva verzija E/H dijagrama za primer obrade poruc1zbina prikazana je na
slid 12-4, To je jednostavan primer i dijagram sc lako cita. (Pretpostavite da
smo se opreclelili za resenje u kome je Salesperson samo atribllt entiteta Sa
les Order a ne entitet sam za sebe,) Ako raclite na sJozenom primeru, mozdn
cete morati da napravite viSe dijagrama kOji opisuju pojecline poclskupove
poclataka. U tom slllcajll korisno je da upotrebite neku vrstu (lutomntske po
drske za izradu clijagrama, U suprotnom, sinhronizovanje tih clijagnlma
moze se ispostaviti kao prilicno nezgodan posao.

Slika 12-4 Prva skica EjR dijagrama procesa obrade porudzbina

Posto pripremite prvu verziju E/R dijagramcl, mozete preCi na c1etaljniju

analizu veza izmeclu entiteta, Za svaku vezu treba cla oclredite sJedece:

Kardinalitet veze
Obaveznost svakog ucesnika
Atribute veze, ako ih ima
Uslove i ogranicenja veze, ako ih ima,

Slika 12-.'5 prikazujc E/E dijagram obrade porudzhill<l nakoll doteriYanja.

Nije obavezno
samo ako
postoje posebna
uputstva

Pre unosenja
porudzbine mora
biti odobren
kredit

Product
Category

Slika 12-5 E/R dijagram obrade porudzbina nakon podesavanja veza izmedu
entiteta

Kardinalitet veza izmedu entiteta

Mozda ste na prvoj skid dijagrama vee nacrtali i veze iZll1edu entiteta,
sto sam to ja ucinila na slici 12-4. Ako
vreme je da to sada uradite. Cak
i ako ste to vee umdili, korisno je da sada preispitate svo.je oclluke jer imate
potpuniju sliku celog modela.
Ukoliko negde otl<lijete vezu tipa "vise prema viSe", dodajte modelu spoj
ni entitet, koji na obe strane ima veze tipa "jeda11 prema vise". Posta je u 11a
sem mo.delu veza izmeciu entiteta Supplier i Product tipa
prema vlse ,
potreban nam je entitet Product Supplier da bismo je razdvo.jili. Obratite
znju 11a to. da je veza izrnedu entiteta Sales Order i Product takode tipa "vise
prema viSe", ali u tom slucaju entitet Order Detail
ulogu spojnag entiteta.

Obaveznost veza
Posto utvrdite vrste veza izmeau pojedinih entiteta, trebalo. bi da sacla za
svaku vezu odredite da Ii je obavezna za jeclno.g Hi za oba ucesnika. U nasem
pIimeru, veza
entiteta Customer (kupac) i Shipping Method (nacin
dostave) neobavezna je 11 oba smera tj. nije potrebno da za svakog kupca
bude odreden podrazumevani nacin dostave robe, a mogu postojati naCini
dostave koji se ne primenjllju ni za jednog kupca.

strane, veza izmec1u entiteta Product Category (katcgorija arti~

samo u jedn0l11 smeru. i\{oze postojati
kategorija artikala kojoj ne pripada
artikal, ali sV<lki artikal mora
padati
kategoriji artikaIa.
izmedu entiteta Sales Order (porudzbina) i Shipping Method jos je
slozenija. Posto moze postojati naCin c10stave kOji nije upotrebljen ni za jed~
nu poruc!zbinu, strana Sales Order veze nije obnvezna. Meclutim, strana
Shipping Method veze nije obavezna sal110 ako za poruc1zbinu vaze posebna
uputstva. To je vazan uslov kOji bi trebalo zabeleziti na dijagramu.
S

kab) i Product (artikal) obavezna

Atributi veza izmedu entiteta

U veeini situacija, vazna je sa1110 cl11Jenica da veza izmeau elva entiteta
postoji. Na primer, treba samo da znamo da je odreaeni Kupac poslao datu
Porudzbinu. Meautim, ponekad treba da znamo i c10datne cinjenice koje se
odnose na vezu izmeau entiteta na primer, kad je pocela i koliko je trajala.
Te Cinjenice su atributi same veze, a nc ucesnika II vezi.
Ako sama veza ima abibute, mora se modelovati kao entitet. U
prirneru obrade poruclzbina, jeclnom ocl dobavljaca (entitet Supplier) mom
mo da dodelimo status "najbolji dobavljac". Posto izmeau entiteta Product i
Supplier vee ima1110 spojni entitet, mozemo mu dodati nov atribut, Najbolji
dobavljac. Da nismo vee imali spojni entitet, morali bismo da c\oc1mno nov
entitet koji predstavlja atribute veze.

Dodatni uslovi koji se odnose na vezu izmedu entiteta

I najzad, treba da utvrdimo postoje Ii dodatni uslovi kOji bi morali cIa vaze za
vew izmedu entiteta. Koji je najmanji i najveCi broj zapisa kOji moze posto
jati na strani "vise" veze "jedan prema vise"? Da li postoje uslovi kOji mor,\jll
biti ispunjeni pre nego sto se dozvoli uspostavljanje veze? Postoje Ii uslovi
pod koji111a veza mora da postoji?
U nasem pJimeru, takav uslov pravilo da veza izmec1u entiteta
Order i Shipping Method nije obavezna samo ako su zadata posebna uput
stva.
takew uslov je pravilo da kupac ne moze da posalje poruc!zbinu
ako
kreditna kartica ne vazi. To pravilo je takoae napisano na dija
gramu. Ako ima puno takvih uslova iii su uslovi previSe slozeni da bi se mogli
izraziti kao jednostavne napomene na dijagramu, mozete ih clokumentovati
na nekom drugom mestu. Na dijagramu morate barem napomenuti
takvi
uslovi postoje.

Ponovno razmatranje entiteta

Posto ste poceli da sticete sliku entiteLl u sistell1u i veza izmedu njih, \TellW
cIa pocnete detaljnu analizu svih entiteta. Za svaki entitet, treba da utvrdi
te sledece:

Vezu izmectu entitetn i prostora problema

Radne procese ko.1i generisu, menjaju, kOliste i brisu dati entitet
Druge entitete na koje utice iIi ko.1i nn njega utiel!, iii od kOjih zavisi
Poslovna pravila i uslove kO.1i se odnose na taj entitet
Atribute entiteta.

Veza izmedu entiteta i prostora problema

Identifikovanje veza izmectu entiteta i prostora problema obieno je jedno
stavno. "Entitet Kupac modeluje flzicke osobe i organizacije koje kupuju
nase artikle". NajveCi problem ovde .ie, kao sto sam ustanovila, smisliti rece
nicu ko.1a nije beznadezna tautologija. "Entitet Zaposleni modelu.1e zaposle
ne u organizaciji" jedva vredi pomenuti.
Ako je veza modelovana k:ao entitet, stvmi se mogu zapetljati .ler ta.l enti
tet nece 1110Ci direktno da se poveze s prostorom problema. "Jedan dobavljac
moze dobavljati vise artikala, a svaki mtikal moze dobavljati neogranicen broj
dobavljaca. Entitet Product Supplier modeluje vezu, kao i status Na.1boljeg
dobavljaca za nekog od postojeCih dobavl.1aca od1'ectenog proizvoda.
Neke stvari u prostoru problema - najbolji primer verovatno entitet
Sales Order - t110deluju se pomocu jednog ili viSe logickih entiteta u modelu
podataka. Ja ih zovem kombinovani entiteti. Dokument porudzbine pred
stavljaju aba entiteta, Sales Order i Order Detail.
Ustanovila sam da je uglavnom bolje resenje da kombinovane entitete
predstavljam u dokumentaciji projekta kao jedan objekat. Na primer,
teti Sales Order i Order Detail predstavljaju porudzbinu koju je poslao ku
pac. Entitet Sales Order mocleluje samu poruclzbinu, dok entiteti Order
Detail predstavljaju stavke porudzbine za svaki kupljeni artikal".

Radni procesi koji uticu na entitet

lako ste mozda vee tokom analize radnih procesa koju ste ranije obavili na
veli gde se sve podaci koriste, korisno je da te informacije navedete i u doku
mentaciji 0 entitetima. To yam omogucava da ako kasnije bude potrebno da
izmenite strukturu nekog entiteta, np1'. da mu dodate atribut, imate na
nom mestu navedene sve procese na koje ta izmena moze uticati.

Idclltifikovanje
ncposrcdno cleluju nll oclredeni entitd ta
ko(\e je jednostavno. Identifikovanje procesa koji posrecino deluit! na cntitet
1ll0ZC zahtevati nesto viSe posla. 1\ a primer, mozda neee biti oCiglcclno cla
p05tupak 11110Senja porudzbine moze da izmeni poclraz1Il11evani naCin closta
ve robe odrec1enol11 kupeu, nih cia "Specijalni bonus" odrec1en za neku kate
goriju artikala maze da utice na procenat popusta, pa zbog toga i na ukupan
iznos porudzbine. A upravo to su vrste utieaja koje Sll noena mora programe
1'a zaduzenih za odrzavanje, ukoliko nisll detaljno dokumentovane.
Vecina analiticara doh1l11entuje te utic<~e tokom analize rndnih
sto je svakako korisno ako se menjaju procesi. Meautim, ponekad se uvode
izmene samog modela podataka, i to neposredno zbog promene poslovnog
okruzenja, iIi posredno - zato sto postojeCi proces zahteva izmene modela.
U tom slucaju je znatno jednostavnije da u dokumentaciji 0 entitetima po
trazite entitet kOji menjate nego cIa "prekopate" sve racIne procese da biste
njima pronasli sve one na koje ce llticati uveclena izmena.
UkljuCivanje informacija 0 rnclnim procesima u dokllmentaciju 0 entite
Kao i
tima zamislite kao neku v1'stu unakrsne referenee, sto zapravo i
svaki drugi sistem llnakrsnih 1'eferenci, uvodenje i odrzavanje m02e biti za
morno, ali - dllgorocno glecIano m07:e yam znatno olaksati zivot.

Interakcije izmedu entiteta

clijagrami su cudesne alatke, ali je kolicina informaeija kOjll mogu prika
zati ogranicena. Ako entiteti u vasem sistemu imaju slozene interakeije koje
se ne mogu tako lakoyredstaviti na dijagramu, vazno je da ih dokumentujete
U opisima entiteta. Cak i ako ste dijagra111u dodali kratke beleske 0 tome,
trebalo bi da detaljno opiSete svaku interakciju kOja nije razmnljiva na 05no
Vll

model podataka toliko slozen da zahteva vise dijagrama entlteta, a

odredeni entitet se pojavljuje na vise dijagrama, 1110ze biti korisno da II OpiSll
tog entiteta navedete sve entitete s kOjima je povezan. To je najcesce slucaj
vrednosti koriScene na vise mesta.
sa entitetima koji obezbeduju
Na primer, entitet Nacin oslovljavanja, kOji sadrZi stavke kao sto su "Gospo
din", "Gospocla", "Dr" i "Gospodica", 11102e se referencirati na c1esetak 111C
5ta u sistemu. Ako zatreba da izmenite taj entitet, korisno .ie cb na jednom
mestll imate navedene i sve entitete koji ga 1'eferenciraju.
E/R dijagrami uglavnom dovoljl1o dobro dokumentuju interakeije iz
medu entiteta. Jedino izuzetni slucajevi, kao sto je navedeni, zahtevaju clo
punske informacije.

Poslovna pravila i uslovi

SledeCi element dokumentacije koji je obavez,m za wald entitet jestc opis
uslova kOji se odnose na entitet. Svaki mlov u kome se pominje vise atributa,
npr. pravilo iz naseg primera: "Ne mogu biti prazna oba atributa NaCin do
stave i Posebna uputstva", mora takode biti dokumentovano.

Atributi
Poslednji element dokumentacije neophodan za entitete jeste spisak atribu
ta i njihovih domena. Kada sastavljate taj spisak, prenesite na njega spisak
atributa koje ste utvrdili na osnovu izvornih dokumenata, a zatim obavezno
dodajte spoljne kljuceve (ako ih ima) kOji su potrebni za ocuvanje
jalnog integriteta.
Proverite i da Ii svaki entitet ima barem jednog kadidata za Idjuc kOji se
moze upotrebiti za nedvosmisleno identifikovanje svakog primerka entiteta.
On ce postati primarni ldjuc
u semi baze podataka. Imajte u vidu da
plimarni kljucevi ne mogu sadrzati N uIl vrednosti. Iz tog razloga mozda
nece biti uvek moguce da kao kljuc upotrebite postojeCi atribut iIi kombina
ciju atributa. U tahim slucajevima, potreban vam je proizvoljan identifika
tor koji ce sistem automatski gcnerisati.
U nasem primeru, za entitet Customer verovatno je potreban neki takav
vestacki identifikator. Ako pretpostavimo da kupac moze biti firma ili fizicko
lice, pocetna lista atributa moze biti nalik na onu sa slike 12-6.

Customer Entity
CompanyName iii
..".--tCompanyName:Name
Individual Name bite Null~lndividuaIName:Name
Address1 :StreetAddress
Address2:StreetAddress
Suburb:Suburb
State:State
Country:Country
PostalCode: PostalCode

Slika 12-6 Spisak atributa entiteta Customer

Cak i ako zasad zanemarimo problem dupliranja imena osoba, i dalje

imamo problem. Ako je kupac fizicko lice, atribut Company Name (ime
kompanije) imace vrednost Null. Ako je kupac kompanija, atribut Individual
Name (ime osobe) imace vrednost Null. Nesto ceuvek imati vrec1nost Null.
To znaCi da ta polja ne mozemo upotrebiti kao kandidate za kljuc entiteta,

cak i ako pretpostuYimo cIa

saclrzaj neclvosmislcllo iclcntifikujc svaki
zapis, sto llije tacno.
To nas c1ovodi do sledeceg problema sa entitetom Customer. ImenCl 050
ba nisu jeclinstvena. U nasem primeru, cak ni kombinaeija
cltributa ne
garantuje jeclinstvenost jer se moze clogoditi da clve osobe imaju isto ime i
prezime i zive na istoj ac1resi. Podatak da se neko zove "Mihailo PetroviC:"
nije c1ovoljan da bi5te znali da je to, u 5tvari, Mihailo Petrovic, sin, koga ne
treba b1'kati s njegovim oeem, koji zivi u istoj kuci.
Nesporno je da su Mihailo Petrovic, otae i Mihailo Petrovic, sin, razliCite
osobe koje treba predstaviti razlicitim zapisima. Medutim, atributi koji bi ih
na jedinstven nacin identifikovali nisu deo nasih projektnih zaduzenja.
Mozete Ii zamisIiti da vas, bda nesto kupujete u bakalnici, neko pita skim
"Izvinite, gospodine, da Ii
s vama zivi neko od vase pOl'odke sa
istim i111enom i prezimenom kao vi? Taj podatak nam treba za nas racunarski
sistem". Ne bas najbolji odnos prema kupeu, zaista.
Srecom, postoji jednostavno resenje: sifra kupea (Customer Number).
Ukoliko organizacija nema vlastiti nacin dodeljivanja tih brojeva, i Jet i SQL
Server imaju mehanizam za automatsko generisanje tih vrednosti (tip poda
taka AutoNumber, odnosno Identity).
Medutim, ako koristite proizvaljan identifikatOl~ obavezno obezbeclite j
alternativan nacin identifikovanja. Ne bi bilo pozeljno cia doc1ete Ll situaciju
cia morate odbiti porudzbinu zato sto kupac zaboravio svoju sifru. Jedno je
pitati kupca, "Da Ii ste vi Mihailo Petrovic iz Valjeva ili Mihailo Petrovic iz
Novog Sada?", a nesto sasvim drugo zahtevati oel njega da ponovo clade
kada pronacle neki stari racun kOji ste mu izdali.
Entitet Customer takode je plimer drugog razloga upotrebe proizvoljnog
sistemskog identifikatora. Cak i ako mozemo pretpostaviti da je kombinadja
irnena i adrese dovoljno jedinstvena za nase namene, imacemo prevelik broj
polja koja treba kopirati na druga mesta. Imajte u viclu da se plimarni kljllc
jednog entiteta kOlisti i kao spoljni kljuc II entitetu kOji ga refereneim. Sasvim
je oCigledno da je znatno efikasnije kopirati jedan ahibut nego njih pet ili sest.

Analiza domena
Na slid 12-6, spisak atributa ima oblik Ime:Domen. Mnogi analiticari zane
maruju postojanje domena i atribute preclstavljaju c1irektno s njihovim tipo
vima podataka i uslovima. Ako zanemarite taj korak postupka,
11
velikom drustvu. To nece biti ispravno, ali te3ko da ce vam to iko zameriti.

U svom rac1u ipak obavljam analizc domena, sto i vc\l1~a prcporucujem,

zato 'ito one stecle vreme i pruzaju doclatnc informaeije. Sto se mene
sve sto je lakse i bolje smatnun dobrolll idejom. A clodatna prednost
po
sh je to sto je tehnieki ispravan.
Pogledajmo primer: Atributi CompanyName i IndiviclualNamc upu6ujll
na to da svoje vrednosti vuku iz domena Name.
Domen Name mozemo sada definisati na slecleCi naCin:
"Grupa od jedne iIi vise
pravilno napisanih, maksimalne dllzinc ocl
znakova. Dozvoljena Sll samo slova i znakovi interpunkcije tacka (.) i za
rez U."
Domen moramo definisati samo jedanpllt, a zatim se on maze koristiti
neogranicen broj puta u celom sistemu. Te uslove lllogli S1110 da zadamo po
jedinacno za svaki atribut, ali zasto bismo to radili? Osim toga, posto su atri
buti definisani u istom domenu, znamo da se mogn logicki porediti. To ne bi
obavezno bilo jasno da smo atribute definisali direktno.
Pronalazenje kupca sa istom vrednoscu u polju CompanyN ame kao i u
polju IndividualName mozda
najkorisnija stvar koju biste uraclili, ali je
barem izvodljivo. To ne vazi za poredenje i111ena kompanija sa siframa kupa
ca kOji mogu imati jednake strukture i uslove.
Tehnicka definicija domena glasi "skup vrednosti iz kojeg mogu poticati
vrec1nosti atribllta". To je konceptllHlno vrIo jasno, ali kako se prakticno c1efi
niSe do men? U sustini, morate odrec1iti slec1eca tri elementa:

1. Tip podataka u do menu

2. Uslove i ogranicenja
vrednosti koje Sll prihvatljive zu zadati
tip podataka
3. Ako je potrebno, formatiranje za podatke iz domena

Biranje tipa podataka

Prvi korak pri definisanjll domena
izbor osnovTlog tipa podataka kOjim
ce domen biti predstavljen 11 semi
podataka. Ovo je jedan od primera
kada .ie opravdano prekrsiti pravilo 0 razdvajanjll seme baze poclataka oc1
konceptualnog model a podataka.
Tip podataka sluzi kao skrae:eni opis opsega vrednosti. "Celobrojni"
c1omen, osim ako modellljete matematicki problem, ali su vrednosti u
menu "KoIiCina" gotovo izvesno celobrojne. Meciutim, ne bih preporncila da
zalazite preduboko u specificnosti
podataka koje podrzava odredena
masina baze podataka. U ovoj fazi, izbor masine baze podataka jos llvek
moze da se promeni.

"Tip poclataka" d0111ena moze bib i drugi domen. Mozda stc \C(: cleflnisa1i
opSti clomen Datum kOji oclreduje cIa, net primer, svi datumi LI sistemu moraju
bib jeclnaki ili veCi od .1.. januara 1900. godine i formatirani s cetvorocifrenom
goc1inom. Sasvim je prihvatljivo da atribut Datum prodaje definiSete kao "da
tum posle 23. oktobra 1982. godine (datum kad je pocela prodaja)".

Ogranicavanje opsega vrednosti

Posto odredite osnovni tip podataka u domenu, sledeCi korak je zadavanje
vrednosti iz opsega tog tipa podataka koje su prihvatljive u domenu. Pone
kad cete to najlakse uCiniti ako zadate pravilo: "koliCine moraju biti pozitivne
celobrojne vrednosti".
Ponekad je jednostav11ije da
listu prihvatljivih vrednosti u domenu.
mora biti jedna od sledeCih: Severozapadna, Seve roistocna,
Centralna, Juzna". U ovom primeru, gotovo je izvesno da cete morati da
ukljuCite domen kao entitet u model podataka. To je znatno lakse
da se
vrednosti rucno kucaju gde god se referenciraju, a osim toga, omogucava iz
mene prvobitnih vrednosti nakon uvodenja sistema u redovan rad.
Jedini moguCi izuzetak od ovog pravila jeste kada domen sadrZi vdo Inali
braj vrednosb koje se ne mogu promeniti. Primera radi, pretpostavimo da
1110delujete neb upitnik i da imate domen Odgovor kOji se sastoji od samo
dye vrednosti "Tacno" i "Netacno". Nema svrbe 11l0delovati te dye opcije
kao entitet. Domen ne 1110ze sadrzati druge vrednosti osim te dye, a gotovo
je izvesno da ce referenciranje tabele u aplikaciji biti komplikovanije nego
da korisnik direktno upise odgovor.
Entitete cete koristiti za modelovanje domena kOji se moraju definisati
pomocu vise od jednog atributa. Najbolji primer je domen Savezna drzava.
Ako morate podrZati vise zemalja, ne mozete utvrditi da li je data vrednost
za saveznu drzavu tacna ukoliko ne znate i zemlju na koju se podatak odnosi.
Na primer, ako kupac zivi u Australiji, "New South Wales" je ispravna
vrednost za saveznu drZavu, ali "Alabama" nije. U OV0111 slucaju, entitet kOji
predstavlja domen sastojao bi se od atributa Zemlja i Savezna drzava. Strogo
uzevsi, ovaj primer nije definicija domena, a modeluje se pomoc11 odgovara
juCih veza 11 E/R modelu. Medutim, ovu vrstu situacije najlakse zamisliti
kao neku vrstu kombinovanog domena i tretirati ga kao takvog.
Na kraju krajeva, sustina je u tome da se pojednostavi postupak identifi
kovanja uslova koji treba da vaze u sistemu, a krsenjem definicije domena za
domene koji se ponavljaju u modelu podataka stedi se vreme i smanjuje ve
rovatnoca greske.

U specillkaciji clomena morate takocte zachti cia Ii su za atrihute cJellllisa

ne u c10menu prilwatljive vreclnosti Nun, znakovni nizovi cluzine nub iIi jecl
no i clrugo. Korisno je da to izriCito cleklarisete u clefiniciji clomena, C'ak i kac1
opseg vreclnosti moclelujete pomoeu nekog sistemskog entiteta, kacla se pri
lwatljivost Null vrednosti moze oclrecliti na osnovu veze izmedu dva entiteta.
Analiziranje clomena i sastavljanje liste atributa za odredeni entitet tesno
su povezani, iterativni postupci. U praksi ce verovatno biti najefikasnije cla
domene definisete istovremeno dok pripremate listu atributa. Ako je za
odredeni atribut vee definisan domen, taj atribut mozete staviti na listu. Ako
domen nije definisan, mozete ga deflnisati dok imate primer pred sobom.
Tokom tog postupka, mozda eete ustanoviti da za neke atribute vaze do
datni uslovi, osim onih definisanih u domenu atributa. To je potpuno ispravno
i nije nimalo neuobicajeno. Na primer, mozda ste definisali domen Datum
dogadaja, kOji predstavlja datume na koje se mogu odigrati odredeni dogadaji.
Uslov za taj datum je da mora biti posle pocetka rada kompanije. U primeru
obrade porudzbina, Datum porudzbine i Datum dostave moraju biti clefinisa
ni u domenu Datum dogadaja. Atlibut Datum dostave mora biti i mlacli ocl
Datuma porudzbine. To je uslov kOji vazi za dati entitet i mora biti naveclen
kao takav u opisu tog entiteta.
Kada deflnisete uslove za domen (kao i dodatne uslove za atribute), tre
balo bi da budete sto precizniji, ali da to ne bude na .stetllllpotrcbUivosti. To
pitanje razmotricemo detaljnije u cetvrtom delu knjige, a zasad treba samo
da imate u vidu sledeee: sto preciznije definisete domen, vise eete pomoCi
korisnicima. Medutim, ako pri tome slucajno iskljuCite neke vreclnosti, ome
taeete korisnike, a mozda eak i uCiniti sistem neupotrebljivim.

Definisanje formata
Nije bas neophodno, ali je cesto korisno da zadate odgovarajuCi format za
podatke u domenu. Ako na jednom mestu zadate da se svi datumi moraju
prikazivati u formatu DD-MM-GGGG, nece biti potrebe da to ponavljate.

"ormalizovanje
Mozda vas iznenaduje to sto se u ovoj diskusiji 0 izradi modela podataka ni
gde ne pominje normalizovanje modela podataka. Iskustvo mi je pokazalo
sledece: ako pocnete od elemenata podataka koje organizujete u entitete, a
usput eliminisete grupe koje se ponavljaju i veze tipa "vise prema vise", ve
rovatno cete doCi do modela podataka koji je u trecoj normalnoj formi.

Ali, svakako necete pogrcsiti, narocito ako

s\e

0\'0

prilicna ])ovina za

Yas, ako ispitate usk1acienost s\'og moc1eb s normalnim formama. Ne zahora

vite, svaki entitet u modelu mom c1a zavisi "od kljuca, celog Idjuca i niceg
osim kljuca".

Sazetak
U ovom poglavlju razmotrili smo izradu konceptualnog modela podataka u
sistemu. Postupak pocinje ispitivanjem svih izvornih clokumenata racli
tifikovanja svih elemenata podataka koji se koriste u sistemu, i koji se zatim
organizuju u entitete. Potom se utvrduju veze izmedu entiteta a zatim se po
jedinacno analiziraju entiteti i njihovi atributi.
U sledecem poglavlju prelazimo na preslikavanje konceptualnog modela
u semu fizicke baze podataka koju cemo napraviti za izabranu masinu baze
podataka.

Serna baze podataka

U prethodnom poglavIju bavili smo se konceptualnim modelom podataka,
kOji definise logicku strukturu podataka. U OV0111 poglavlju prelazimo na
semu baze podataka, koja opisuje fizicku strukturu podataka. Ne zaboravite
da je sema baze podataka jos uvek logicka konstrukcija. Kada je zavrsite,
imacete opis fizicke strukture podataka izrazen prilicno apstraktnim elemen
tima, ali kOji odgovaraju fizicko111 obliku podataka. Stvarnim fizickim oblikom
podataka bavi se masina
podataka i nema potrebe da i vi to cinite.

Arhitekture sistema
Pre nego sto sacinite opis seme baze podataka, morate doneti nekoliko odlu
ka 0 arhitektmi koju vas sistem zahteva. Nazalost, u strucnoj literaturi izraz
"arhitektura" koristi se za opisivanje dva razliCita (mada povezana) modela.
Da bi stvari bile jasnije, jedan od tih 1110dela zvacu arhitektura koda a dru
gi arhitektura podataka. Ali imajte u vidu da su to moji nazivi, i cia je malo
verovatno cia cete na njih naiCi na drugol11 mestu.

Arhitekture koda
Ono sto ja zovem arhitektura koda, u strucnoj literaturi naziva se "aplikativni
model", "slojevita struktura" i "servisni model". Arhitektura koda opisuje
naCin na koji je program ski kod logicki strukturiran. Struktura koda se naj
vise tice izrade aplikacije i kao takva izlazi van opsega ove knjige. Meclutim,
posto od arhitekture koda moze zavisiti da Ii ce usiovi za integlitet podataka
biti realizovani u semi
podataka, ipak cemo je razmobiti u OV0111 pogIa
vIju, mada prilicno povrsno.
U los a stara vremena, sistemske arhitekture bile su monolitne: ogromni
blokovi koda s minimalnom strukturom. Ko god je imao tu nesrecu da je po
kusao da izmeni (iIi da samo sbvati) monolitni sistem bilo kog stepena sloze
nosti, vise nikad nece na isti nacin pogledati tanjir spageta. Da bi uveli malo

201

rectl

zbrku, programeri Sli poceli clet strukturiruju svoj k6c1 U z<lselme k0111
raznih oblika: potprograme, module ili objekte - 11 zllvisnosti oel 1110
gllcnosti programskog jezika. Problem s tim pristupom jeste to sto 1ll11esto
zamrsenih spageta, lako mozete napraviti torteline - nezmisnc manjc blo
kove kada kOji su na neki /latin povezani, ali SVclko mora
pagada na kOji.
Da bi magli da upravljaju tim savremenim testeninama, l1111agi projek
tanti organizuju kOl11ponente u usluge (engl. sel'vices), kaje se ponekad nazi
vaju "slojevi" i kaje obavljaju odrec1ene paslove na datam logickom nivau.
Pastoji bezbroj nacina organizovanja slajeva. Razmotricemo dva najuabica
jenija: troslojni i cetvorosIojni model.
II

Troslojni model
Troslojni model organizuje kOl11ponente u korisnicke usluge (eng!. IIser ser
vices), pasIovne usluge (engl. business services) i usluge podataka (engl. data
services). Komponente koda koje prikazuju podatke karisnicima i odgovarcl
ju na njihove akcije smestaju se u sloj ko1'isnickih usluga. Ceo korisnicki in
terfejs ugraduje se u taj sloj. Sloj poslovnih usluga stanl se 0 pastovanju
poslovnih pravila i proverava ispravnost podataka koje je korisnik lIneo.
Komponente iz slaja pos10vnih usluga rade u sadejstvu i sa slojem korisnic
kih usluga i sa slojem usluga podataka. Komponente koda u sloju usluga
podataka, koje komuniciraju samo sa slojem poslovnih usluga, odgovorne su
za odrzavanje podataka.
Troslojni model je jednastavan i razumljiv, ali sam ustanovila da je njegava
upotreba u praksi problematicna. Uvek se nade poneka vrsta funkcionalnosti
koja se ne uldapa nedvosmisleno ni 1..1 jedan odredeni sJoj. Na primer, recimo
da se odredeni podatak mora fonnatirati pre nego sto se p1'ikaze kOlisniku.
Telefonski broj maze da se euva u bazi podataka kao niz od deset eifaI'a, ali se
plikazuje 1..1 fonnatu (999)999-9999. Da Ii fonnatiranje podataka spada u nad
leznost sloja kOlisnickih usluga ili sloja usluga podataka? Postoje opravdani
razlozi za postavljanje te aktivnosti i u jeclan i u drugi sloj. SHeno tome, da Ii je
upravljanje transakcijama cleo poslovnih usluga iIi usluga podataka? Kacla
paenete da projektujete slozene sisteme u kOjima se koliste hije1'arhijske
stlllkture podataka, donosenje te vrste odluka moze postati "eupavo".
Ako ste uvek dosledni u on0111 sto radite, pretpastavljam cla je nevazno
gcle cete postaviti tu vrsta funkcija, ali je 1..Ipravo to taeka u kojoj model po
staje neupotrebljiv. Ukoliko morate postovati skup spoljnih konvencija - kao
sto je ,,Eormatiranjc podataka pripada sloju korisnickih usluga, a formiranje
hijerarhijskih slmpova podataka pripada sloju poslovnih usluga" slozenost
modela pocinje da potire prednosti koje pruza.

Cetvoroslojni model

Deljenje arhitekture koch na cetlri sloja umesto 11,1 tri e]illli11ise veCinu
b1eJ~la 'koji se pOjavljlljll 11 troslojnom modclll. Cct\'()]'os]ojni model,
cesto naziva "s]ojevita struktura", organizuje kOll1ponente kochl 1I sloj
snickog lnterfe.1sa, slo.1 lnterfejsa za podatke, slo.1 interrejsa za transakeije i
slo.1
za spoljasnji pristup (slika 13-1).

Komponenta

korisni6kog

interfejsa

Komponenta
interfejsa
za podatke

1
Komponenta
interfejsa
za podatke

Komponenta

interfejsa

za podatke

Komponenta

interfejsa za

transakcije

Komponenta
interfejsa za
transakcije

1
Komponenta interfejsa

za spoljasnji pristup

Komponenta interfejsa
za spoljasnji pristup

Masina baze podataka

Slika 13-1

model

Sloj korisnickog interfejsa odgovara sloju korisnickih usluga u trosloj

nom modelu. Sloj korisnickog interfejsa odgovoran je za komunieiranje s
ko1'isnikom, sto obuhvata sledece: p1'ikazivanje podataka ko1'isniku pomocu
objekata u prozolima; 1'eagovanje na promene stanja objekata u prozorima,
kao sto je promena dimenzija ob1'asca; prosledivanje drugim s]ojevima za
hteva koje je korisnik zadao.

S]oj interfejsa za podatke oc1govoran je za oclrZHvanje poclataka U 111e1110

riji (nasuprot trajnol11 euvanju vrcc1nosti poclntaka, Zit koje su zaduzeni sloj
interfejsa Zit spoljasnji pristup i m<lsina baze poc1ataka, kao sto CC1110 vicleti).
U t<~j sloj sc eksplicitno ugraduje veCina funkcija koje mogu bib sporne u
troslojnom modelu, kao !ito su formatiranje poclataka i formiranje virtuelnih
skupova zapisa. (Virtuelni sku]) ;:.apisa postoji S<1mo u memoriji; njegov
SadrZl\i se nigde ne euva trajno.)
U vecini slueajeva, komponenta iz sloja interfejsa za podatke tcsno jc
spregnuta sa odreaenom komponentom u sloju korisnickog interfejsa.
Meautim, jedna komponenta iz sloja interfejsa za podatke moze da podrZi
viSe komponenata iz sloja korisniekog interfejsa, kao sto je pIikazano na slici
13-1. Na primer, sistem moze cIa sadrZi obrazac Odrzavanje podataka 0 kup
cu, koji prikazuje podatke 0 pojeclinacnoll1 kupcu, i obrazac Pregled kupaca,
kOji prikazuje podatke 0 viSe kupaca istovremeno. BuduCi da oba obrasca
predstavljaju entitet Kupac~ l110gu da dele ist! programski k6d za formati
ranje i proveru ispravnosti SifreKupca, lito je hmkcija koja pripada sloju il1
terfejsa za podatke.
U fizickom obliku, komponenta korisnickog interfejsa obicno je obrazac
u Microsoftovom Visual Basicu iIi Accessu, a k6cl s njom pavezane kompo
nente iz interfejsa za podatke najcesce se smesta u madul klase obrasca.
Medutim, ako adredene procedure deli viSe obrazaca, njihov k6d se smesta
u eleljeni moelul.
Sloj interfejsa za podatke odgovoran je za proveru ispravnosti podataka,
ali ne i za poslovne procese. Na primer, programski k6d kOji obezbeduje ela
je vrednost SifreKupca zadata u poruelzbini poznata u sistemu, deo je sloja
interfejsa za podatke. Programski kOel koji obezbeduje odredeni niz dogada
ja, kao sto je sprecavanje da roba navedena u poruelzbini bude dostavljena
kupcu dok Il1U se ne odobri kreelit, pripada sloju interfejsa za transakcije.
Sloj interfejsa za transakcije koordinira upotrebu podataka u aplikaciji.
Komponente na tom nivou odgovorne su za sastavljanje i slanje up ita, pri
jem podataka koji stizu iz sloja interfejsa za spoljasnji pristup, izvrsavanje
poslovnih procesa, i obradu gresaka i krsenja pravila koje javlja sloj interfejsa
za spoljasnji pristup.
Sto se bee ponovnog koriScenja komponenata u aplikaciji, verovatnije je
da ce to biti komponente iz sloja interfejsa za transakcije nego komponente
iz sloja interfejsa za podatke. Komponente iz sloja interfejsa za transakcije
dobri su kandidati za realizovanje u obliku objekata i u Visual Basicu i u C#.
K a primer, objekat Kupac moze da stavi na raspolaganje metoclu Azurind
koju poziva vise komponenata iz sloja interfejsa za podatke. Imajte u vidu
dece: posto bi sloj interfejsa za podatke trebalo (barem u idealnom slucaju)

cia bude nezavisall od komponenata 11 slojl1 korisnickog interfejsa, vredl10sti

koje se <lzuriraju treba navesti pojeciinacJ1o. Drugim reCim,l, pozi\' bi imao
sledeCi oblik:
Kupac.Azuriraj

ImeKupca ...

Metoda Azurimj zatim sastavlja upit tip" UPDATE, koji prosleduje sloju
interfejsa za spoljasnji pristup na izvrsenje i obraduje greske do kojih pri
tome moze doci. Tn metoda otklanja poslediee greske, aim je to l110guce, iii
prosleduje gresku
lanca pozivanja do sloja korisnickog interfejsa koji
kazuje odgovarajucu poruku 0 gresci.
Sloj intrefejsa za spoljasnji pristup odgovoran je za komunieiranje iz
medu aplikacije i spoljasnjih izvora podataka. U sistemima koji rade s baza
ma podataka, komponente koda na tom nivou staraju se 0 komllniciranju s
masinom baze podataka. One izvrsavajl1 upite i proslecluju njihove rezultate
(iii poruke 0 greskama) nagore duz lanca pozivajuCih komponenata.
U idealnom slucaju, trebalo bi da procedure na tom nivou projektujete
tako da izoluju transakciju od specificnosti masine baze poclataka za koju se
opredelite. Teorijski, trebalo bi da buc1e mogllce da se aplikadja, prvobitno
projektovana da radi s masinom baze podataka Jet, prebaci na SQL
samo uz jeclnostavnu zamenu sloja interfejsa za spoljasnji pristup. U stvarno
sti, to je malo teze izvesti.
Imajte u viclu cIa je sloj interfejsa za transakcije odgovoran za sastavljanje
upita; sloj interfejsa za spoljasnji pristup samo izvrsava te upite. Zbog
sintaksnih razlika izmedu raznih "clijalekata" jezika SQL, prakticna izveciba
tih slojeva retko kad je tako jeclnostavna. Za sImp zapisa kOji se dobija kao re
zultat jednog llpita tipa TRANSFORM u masini baze poclataka Jet, potreb
no je viSe komandi kada se koristi SQL Server.
Ako mozete unapred predvideti sve upite koje ce aplikacija izvrsavati,
sintaksne probleme cete izbed tako sto cete upite ugracliti u sem1.l baze
podataka. U tom slucaju, parametarski upiti mogu hiti veoma korisni. Nema
potrebe da 11 tokll racla aplikacije formirate ceo SQL iskaz koji uCitava poclat
ke 0 kupcu cije je prezime Jovanovic unapred cleHnisanom upitu mozete
proslediti "Jovanovic" kao parameter, Cime pojednostavljujete arhitekturu
koda aplikacije a verovatno i poboljsavate performanse.
Nazalost, nije llvek moguce unapred predvideti sve moguce upite koji
biti potrebni, narocito ako korisnicima pruzate mogucllost izvrsavanja ad
hok upita. U tom slucaju je gotovo nemoguce potpuno izolovati sloj inter
fejsa za transakcije. (Dosacl nisam nasla POtPUllO resenje problema; ako vi
smislite, bicu yam veoma zahvalna ukoliko
podelite sa mno111.) A do tacla,
l110zda cete morati da napiSete malo dodatnog kocla koji ce se uslovno izvrsa
vati u komponentama sloja interfejsa za podatke.

ce

A1-::o vasa aplikacija trcba da podrzi SHmo jednu masinu

mozda ce yam se Ciniti da hi dobro
bilo cia spojitc sloj
transakcije i sloj interfejsa za
pristup da biste dobili jcdan
yam ne preporuclljem. hIm
izvesno vreme cia biste
sloj interfejsa za spoljasnji pristup, postupak nije tezak, a kada
napiSetc,

ustedeli ste stotine redova koch II c1rugim clelovima sistema. OS1111 toga,

posto napiSete komponentu koja komunicira, l1a primer, sa SQL Serve1'o111

2000 koristeCi ADO.NET, vise nikad necete morati da je piSetc p0I10VO.

Mozete je upotrebiti bez izmena u svakom clrugom sistemu koji

Jedini slucaj kada cete morati da napiSete novu komponentu u sloju inter

fejsa za spoljasnji pristup jeste kada se promeni masina baze podataka iii

objektni model.

Arhitekture koda i serna baze podataka

Arhitektura koda koju izabcrete utice na semll baze poclataka u dve oblasti:
izolovanje sloja interfejsa za spoljasnji pristup (iii sloja usluga za podatke,
ako koristite troslojni model) i provera ispravnosti podataka. Vee je bilo reei
o izolovanju sloja interfejsa za spoljasnji pristup od promene masine haze
podataka, koje se postize predvidanjem potrebnih upita i njihovim ugradiva
njem u semu baze podataka. Dodatna prednost tog resenja je poboljsavanje
perfornumsi, ponekad cak znacajno. Provera ispravnosti poc1ataka nesto je
zapetljanija. U poglavlju 19 detaljno cemo razmotriti 3ta" i "kako" u proveri
podataka. Ovde cemo se baviti sa "kada" i "gcle".
::-.Jeki projektanti smatraju da svu funkcionalnost koja se tice provere
ispravnosti podataka treba ugracliti u samu masinu baze poclataka. To rese
nje nije bas bez ikakvih prednosti: svi uslovi integriteta poclataka i poslovna
pravila realizuju se na jeclnom mestu,
se lako mogu Hzurirati. Nazalost,
to
nije ni bel'. nedostataka.
Prvo, neka se pravila pros to ne mogu realizovati na nivou masine baze
poclataka. Na primer, posto masina Jet ne poclrZava okidace, nemogucc je
obezbediti postovanje pravila koje zabranjuje menjanje vrednosti primarnog
kljuca nakon unosenja zapisa u baw. Cak i u SQL Serveru, koji pruza viSe
l11ogucnosti u toj oblasti, ne mozete realizovati bas svako pravilo direktno u
masini baze podataka.

NAPOMENA 0 YUKONU: SQL Server Yukon omogucava pisanje okidaca, pro

gramskog koda i uskladistenih procedura na bilo kom proceduralnom jeziku, 8to
ce ukloniti sve prepreke za realizovanje uslova na nivou samog servera.

Drugo, cekauje da
proslede masini haze podataka kako hi s('
onda proverila njihova ispravl1ost, moze
smanji upotreblji\'()st siste
ma. Opste pravilo glnsi
ispravnost podataka treba proveravati 6111 1h
risnik unese. U nekim slucajevima, to znaci da se ispravnost unetog podatlm
proverava 6m korisnik pritisne neki taster, npr. kada sprecavate llnosenje
slova u numericko polje. U drugim slucajevima, ispravnost poclataka treba
ela proveravate kaela korisnik iz tekueeg polja prec1e u clrugo ili kada dode u
poslednje od odredenog nizn polja, npr. kaan nameeete pravilo cIa Zeljeni
Dah~mDostave mora biti jednak DatumuPorudzbine ili mlac1i od njega.
Cak i u samostalnoj aplikaciji koja radi na lokalnoj masini, rezultat prosle
divanja skupa podataka masini baze podataka nakon svakog pritiska na taster
jesu katastrofalno
performanse. A ako podatke prosledujete preko lokal
ne mreze ili preko ne smem ni da pomislim mreze sirokog opsega iIi
tern eta udaljenoj masini baze podataka, perfonnanse ee biti toliko lose
ce
kOlisnicima biti bolje da predu na papirne kartoteke (sto ce mozda i uciniti).
Ukoliko se celokupna provera ispravnosti poclataka obavlja na serveru,
jedino resenje je cla se podaci proslede masini baze poclataka racli provere
ispravnosti tek nakon popunjavanja celog zapisa. Meclutim, 11 toj fazi, kori
snik je vee presao na drugi posao. Obavestenje 0 problemu kOji se oclnosi na
podatke unete pre clesetak milluta samo ometa i zbunjuje korisnika.
Da bi se sistem
odazivao i bio !ito upotrebljiviji, proveru isprnvnosti
podataka morate ugracliti u aplikaciju. Ako bazu podataka koristi samo jedn,\
aplikacija i ako su pravila za ispravnost podataka relativno stabilna, mozeIa
cete se oprecleliti cia proveru ispravnosti podatakn obavljate It potpltl1Osti na
nivou aplihlcije i cIa niStn od toga ne prepustite masini baze podataka. Time
se stecli trud, ali je to resenje prilicno opasno.
Ako se kasnije pojavi druga aplikacija koja mdi sa istom baZ0111 podataka,
niSta osim dobrih namem ne sprecava novu aplikaciju cla nenamerno narnsi
integritet baze poclataka, a svi znamo koji je put poplocan dobrim namera
ma. Cak i ako se baza podataka nece deliti s elrugom aplikacijom,
je
ostetiti korisnici kO.1i pristupaju podacima u n.1oj pomoeu ad hok alatld kao
sto su Access iIi SQL Server Enterprise Manager. Strog bezbednosni model
koji zabranjuje svaku izmenu podatnka osim preko aplikacije, moze cIa clo
prinese sprecavanju tahe sutuacije, ali po cenu prevelikog ogranicavanja
pristupa podacima, sto moze biti neprihvatljivo.
lz navedenih razloga, smatram da
najbolje resenje da se ispravnost
podataka proverava i u aplikaciji i u semi
podataka. Access to Cil1i auto
matski. Kada za odredeno polje definiSete pravilo ispravllosti podataka nn
nivou tabele, H zatim ga prevucete na vezan obrazac, obrazac nasleduje pra
vilo ispravnosti.

U verzijama Access,l pre 2000, ta moguenost je nazalost takodc do

bar primer problema dvostmke provere ispravnosti. Ako nakon postavljanja
polja n" vezan obrazac i70menite pravilo ispravllosti na nivou tabele, tc izme
nc se ne prenose i na obrazac. Access 2000 menja pravi]o, ali problem ostaje
II Visual Basicu. Ako se polje pojavIjuje na viSe obrazaca (n istoj ili 1I viSe clru
gih aplikacija), morate rucno izmeniti pravila ispravnosti u 5vakol11 obrascll
(ili taenije reeeno, u komponentama sloja interf(:~jsa 70n poclatke koje poclrza
vaju obrasce).
Da biste resili tnj problem, mozete lIeitavati pravila ispravnosti iz masine
baze podataka tokom rada aplikacije. Ta tehnika donekle opterecuje aplika
dju, ali ako se pravila ispravnosti eesto menjaju, lose posledice dodatnog op
tereeenja potire lakob azuriranja pravila na samo jednom mestu.
Ucitavanje pravila ispravnosti iz masine baze podataka moze se obaviti
pri pokretanjll aplikncije, pri otvaranju obrasca iii
azuriranja zapisa. Pre
porucujem vam da to einite pri otvaranju obrasca. Ako to raclite pri pokre
tanju aplikadje, mozete llcitati nepotrebne informacije koje se oclnose na
obrasce koje korisnik mozda neee otvoriti. Ukoliko to cinite pre svakog HZlI
riranja zapisa, mozete biti apsolutno sigurni u to da su pravila s kOjima raclite
potpuno azurna, ali to znaCi da ponovo ispitujete semu baze podataka za sva
ki zapis. Ali, buclimo renlni, moze Ii postojati sistem u kome se pravila isprav
nosti has tolilw eesto menjaju?
U iZllzetno malo verovatnom SluCajll cIa se pravilo promenilo izmeclu
trenlltka kada je korisnik otvorio obrazae i trenutka kacla je korisnik uneo
podatke kOji su uskladeni sa starim pmvilom, ali krse novo pravilo, problem
ee ionako otkriti 111a5ina baze podataka, pa neee biti uCinjena veca steta.
Osil11 toga, sama pomis<lo na petljanje sa sem0111 baze poclntaka dok ie sistem
It u7Jotrebi dovoljna je cIa imam nocne more.

Arhitekture podataka
Osim donosenja odluka 0 tome kako cete strukturirati program ski k6cl svog
sistema, morate se opredeliti i za odredenn arhitekturu podataka. Podsetite
se iz prvog pog1avlja cIa se sistern kOji radi s bazom podataka sastoji ocl viSe
zasebnih komponenata: same aplikacije, rnasine baze podataka i baze poc1a
taka (videti sliku 1-1). Na osnovu cetvoroslojnog modcla kocla, tu strukturll
1110ze1110 malo doterati, kao sto je prikazano na slid 13-2.

Komponenta
korisnickog

Komponenta
interlejsa za
podatke
Komponenta
interfejsa
za transakcije

Aplikacija

Komponenta interfejsa
za spoljasnji pristup

Slika 13-2 Sistem koji radi s bazom podataka sastoji se od sest odvojenih
slojeva

Pri odredivanju arhitekture podataka za aplikaciju, vi odlucujete

ce
svaki pojedinacni sloj "ziveti". Teorijski, svaki 510j (pa cak i svaka komponen
ta) moze da postoji na razlicitom racunaru i da konmnicira s drugima preko
odredene vrste mreze. U drugoj krajnosti, sve komponente rnogu cIa postoje
11<1 jeclnom, samostalnom racunaru. U stvarnosti, nekoliko manje iii viSe
standarcInih konfiguracija pokazale 5U 5e kao najefikasnije u veCini situacija;
razmotricemo ih pojedinacno.

Jednos/ojne arhitekture

Svako logicko grupisanje komponenata u arhitekturi podataka zO\'e se sloj

(eng!. tier). Naijednost01vnija arhitektura je jeelnoslojni sistem u komc Sll s\'e
komponente u istom logickom sloju, a najjec1nostavnija verzija jec1uoslojne
arhitekture poclataka jeste samostalni sistem.
U samostalnom sistemu, sve komponente nalaze se na jeclnom racunaru
i na raspolaganju su samo korisniku kOji se fizicki nalazi poreel tog racunara.
1ako taj racunar moze biti povezan u lokalnu mrezu iii sa 1nternetom, aplika
cija koja na njemu radi s bazom poelataka nije dostupna clrugim korisnicima.
BuduCi da se celokupna obrada odvija na lokalnom racunaru i svi podaci se
cuvaju lokalno, performanse su ogranicene samo snagom lokalnog racunara
- brzinom njegovog procesora i koliCinom memorije. Samostalni sistemi su
skloni trosenju velikih koliCina memorije, sto je jedan od razloga zbog kojeg
se traze clrugaCije konfiguracije.
VeCina samostalnih sistema koristi masinu baze podataka Jet, maela
Microsoft poclstice projektante da upotrebljavaju Microsft Data Engine
(MSDE), sto je samostalna verzija SQL Servera koja se clistribuira u okviru
paketa Microsoft Data Access Components (MDAC). 1zrada sistema kOji bi
radio sa SQL Serverom na samostalnom racunaru svakako jeste moguca, ali
iz razloga koji ce vam postati jasniji u nastavku ovog poglavlja, pitanje je da Ii
se takav sistem moze kvalifikovati kao jednoslojni.
Cesta varijanta jednoslojne arhitekture jeste baza podataka koja se nalazi
na umrezenom serveru, U tom modelu, baza poclataka (iii barem jedan njen
deo) fizicki je smestena na drugom racunaru u mrezi, ali se celokupna obra
da odvija na lokalnom racunaru.

NAPOMENA: Nemojte smestati i samu aplikaciju na mrezni disk, lako je to

teorijski mogu6e, svakako se ne preporucuje jer previse optere6uje mrezu.
Umesto toga, trebalo bi da aplikaciju postavite na lokalni racunar i da podaci
ma u mrezi pristupate putem povezanih tabela.

Podacima u bazi podataka koja je smeStena na neki racunar u mrezi - sto

je moguce samo ako se koristi masina baze podataka Jet, ne SQL Server
moze istovremeno pristupati vise korisnika. Maksimalan broj istovremenih
korisnika J etove baze podataka teorijski je 255. U stvarnosti, maksimum za
visi oel toga sta oni rade, a prvenstveno oel toga koliko je efikasan clizajn siste
ma. Razume se, dvadesetak Ijudi kOji unose podatke najvecom brzinom koju
im njihovi fini prstiCi omogucavaju, vise ce opteretiti sistem od pedesetak
korisnika koji pregledaju podatke 0 prodaji i razraduju stategije za pobolj
sanje prodaje odredenih artikala.

SmHnjivHllje optereeenja mreze neposrec1no utice na SCll1\l haze poc1ata

ka. lmajte II \'iclu to cla se cclokupna obrada oc1vija lla 10kal110111 racunaru; II
izvesnom smislu, racunar na kOji.ic smestena baza poclatakl tretim se otpri
like kao uclnljeni cvrsti disk Medutim, vreme ocIziva kroz mreZll obicno je
znatno cluze nego kac1a pristupate 10kalnol11 disku. Osim toga, nUeZa ima
ogranicenu propusnu moe, za koju se nadmecu svi korisnici sistema. Dalde,
potrebno je cIa smanjite koliCine podataka koje se razmenjuju unuta!' mreze.
To je takocle pitanje flzWke izvedbe sistema; ako se puno time bavite, precl
1azem vam da viSe informacija potrazite u izvori111a navedenim u bibliografiji
ove knjige.
Meclutim, dva aspekta seme baze podataka mogu neposredno da utiell
na performanse aplikacije u mrezi: mesto na kome su smesteni objekti baze
podataka i pravilna upotreba indeksa. Vee sam pomenula koliko je vazno da
se objekti korisnickog interfejsa na1aze na lokalnom racunaru. Osil11 toga,
moze biti kori5no da kopije podataka koji se ne menjaju cesto smestite na 10
kalne racunare korisnika.
]'\a primer, liste artikala s kojima organizacija posluje u veCini slucajeva
prilicno su stabilne, a cesto se referenciraju. Ako tabela artikala nije preveli
ka (nekoliko megabajta je prihvatljivo; gigabajt vec prevrSuje meru) moze
biti korisno da smestite njenu kopiju na raeunar svakog korisnika. U vecini
situacija to ce smanjiti saobracaj u mreZi i poboljsati perfonnanse. Moracete
da smislite neki mehanizam azuriranja lokalnih podataka kaela zatreba, ali to
nije tezak problem. Ako sistem realizovan pomocu Microsoftovog Acces
sa, replikovanje ce vrlo lepo obaviti taj posao.
Liste postanskih brojeva, opstina, drZava i podela na regije koje se kori
ste 11 organizaciji, takocle su dobli kandidati za smestanje na lokalne raeuna
re jer su takve liste obicno kratke i stabilne, a cesto se referenciraju. (Nema
nikakve svrhe s111estiti na lokalne racunare kopije tabele koju koristi samo
administrator sistema jedanput godiSnje.) S druge strane, porudzbenice, Ji
ste kupaca iii stuelenata obicno nisli pogodne za smestanje na lokalne racu
nare. Podaci u toj vrsti tabela cesto se menjaju, a deljenje najsvezije verzije s
drugim korisnicirna sustina je upotrebe umrezene baze podataka.
Drugi naCin na koji sema baze podataka moze da utice na performanse
aplikacije u mrezi jeste upotreba odgovarajuCih indeksa. Indeks mozete za
misliti kao neku vrstu mini tabele ciji se sadrzaj odrZava u zadatom redosle
du; zapis te "tabele" sadrii samo polja koja su neophodna cia bi 5e zapisi
izvorne tabele postavili u odredeni redosled, kao i "pokazivac" na stvarni za
pis (slika 13-3).

Product Name
Call1emilrt Pierro(

CarnaNon Tigers
Louisiana Fiel)' Hot Pepper Sauce
,Perth Pasties
1

Queso MallCl1ego La Pastora

Slika 13-3 Indeks je neka vrsta mini tabele, u kojoj su zapisi poredani
odredenim redosledom

Obratite paznJu na to da sam rec "pokazivac" upotrebila s prilicno

neodredenim znacenjem. Taj pokazivac nije isto sto i "pokazivac na blok u
memoriji", niti "pokazivac na objekat", sto su izrazi koji se cesto koriste u
programiranju. U stvari, fizicka izvedba modela uopste nije naHk modelu
kOji je ovde prikazan, ali je model ipak upotrebljiv. Ako zaista zelite cla sazna
te ruzne detalje, knjiga Microsoft Jet Database Engine Programmer IS Guide
dobra je polazna tacka.
Umesto da zapise iz izvome tabele fizicki recta zahtevanim redosledom,
5to bi u veCini slucajeva zahtevalo previse vremena, Jet sortira samo datoteku
indeksa. To je (najcesce) znatno brze i omogucava brzo i 1ako pristupanje ta
beli po
vrsta zahteva jer se za jednu tabelu moze odrZavati viSe indeksa.
U SQL Serveru 1110guca je upotreba speeijalne vrste indeksa kOji se zove
grupisani indeks (engl. clustered index); on odrectuje fizicki redosled
podataka. Tabela moze imati samo jedan grupisani ideks.
Indeksi su veoma vazni za performanse jer u mnogim slucajevima masi
na baze podataka moze da izvrsi zahtevanu operaciju koristeci samo indeks,
bez citanja izvome tabele. Time se cesto postize primetno poboljsanje per
formansi, cak i U samostalnim sistemima (jer je i za uCitavanje podataka sa
lokalnog diska potrebno vreme), au mreznom okruzenju poboljsanje per
fOl'mansi moze biti apsolutno neophoclno.
Primera radi, recimo da imate tabelu Kupci koja sadrZi 100.000 zapisa, a
svaki se sastoji od po 1..500 bajtova. Aplikacija treba da pronade odredeni za
pis, npr. za firmu Autodelovi Mitic, Cija jc sifra kupca AUTOMIT. Izvrsili bi
ste iskaz nalik na sledeCi:
SELECT * FROM Kupci WHERE

"AUTOMIT"

1\1\0 tabela llcma ni incleks, ni primami kljllc, m<tsina baze padataka Jet
mom da proCita svaki od onih 100.000 zapisa cia bi utvrclila koji I11cdu njima
ispulljavaju zadati uslav. To znaci da ce kroz mrezu yutovati najlllanje J50
megabajta podataka. Ako postoji
za kolonu SifraKupea, cksplieitllo
cleklarisan ili zato 5to je ta kolona primarni kljuc, masina baze podataka Jet
procitace samo taj indeks, !ito ce verovatno bib tek nekoliko kilobajta poda
taka, i zati111 brzo pronaCi trazeni zapis u izvornoj tabeli.
Poboljsanje perform ansi uslecl upotrebe incleksa maze biti iZllzetno veli
ko, ali razume se, ima svoju cenu. Oclrzavanje indeksa je doclatan posao i
opterecenje za masinu baze poclataka: kad god clodate iii azurirate neki zapis
u tabeli, masina baze podataka mora cla azurira i indekse za tll tabelu. Taj
cloclatan posao obiCno je zanemarljiv, ali ako za datu tabelu imate preveliki
broj incleksa, to moze cla pogorsa performanse. U ekstremnom sillcajll, vre
me potrebno za odrZavanje indeksa premasice vreme koje stedite njihovom
llpotrebom.
Dvoslojne arhitekture

U dvoslojnoj arhitekturi, baza podataka i masina baze poclataka smestene Sll

na udaljenom racllnaru, MOgll biti na istom racllnaru ili nel razlicitim racu
narima. Baza poclataka moze cak biti i fizicki raspodeljena na viSe raeunara,
ali logicki gledano, sistem ce i dalje biti dvoslojan. Ta arhitekllnl je moguca
samo kada se koristi SQL Server ili neki drugi server baza podataka, k<1o sto
je Oracle; nije moguca pomocll Microsftovog Jeta.
Na prvi pogled, razlika izmedu baze podataka smestene na udaljeni nlCU
nm i dvoslojnog sistema mozda ne izgleda tako velika. Microsoftov Jet ili SQL
Server na udaljenom racunaru 5to je to tako bitno? Jeste bitno jer se u
slucaju baze podataka smestenc II mrezi sva obrada obavlja na lokalnoj radnoj
stanici, clok se u dvoslojnom sistenlll obracla raspodeljuje na dva procesom.
Radna stanica je oclgovorna za neposredno komuniciranje s korisnikom, a
udaljeni raCllnar llpravlja pIistupom podacima. SQ L Server preuzima celo
kupan rad s podacima, sto podrazllmeva sve vrste manipulisanja podacima,
cije rezllltate zatim "servin" klijentskoj radnoj stanici. To je razlog zbog kojeg
su dvoslojni sistemi koji rade s bazama podataka poznatiji kao klijentlserver
sistemi.
Da biste bolje shvatili razliku izmeau llmrezene baze podataka i dvo
slojnog sistema, uzmite kao primer naredni SQL iskaz, kOji smo upotrebili u
objasnjenju vaznosti indcksa:
SELECT * FROM Kupci WHERE SifraKupca

"AUTOMIT"

Kada radite s bazom poclataka na umrezenolll racunaru, masina baze

poclataka Jet pretrazice indeks (pod pretpostavkom cIa indeks postoji),
pronaCi ce trazeni zapis i ueatace njegov sadrzaj, Kroz mrezu se proslecluje i
indeks i pronadelli zapis, U klijentlservcr sistemu, aplikaeija ce proslediti
iskaz SQL Serveru i dobice oct njega trazcni zapis. Kroz mrezu se prenosi
samo zapis. (Naravno, ono sto se zaista desava u obe opisane situacije znatno
je slozenije, ali ce ovaj jednostavan model posluziti svrsi.)
Pri zahtevima kao sto je navedeni, perfonnanse obe arhitekture bice do
voljno dobre da necete primetiti veliku razliku izmeau baze podataka na
umrezenom racunaru i klijent/server baze podataka. Meautim, kada su u pi
tanju slozeniji upiti i veliki broj korisnika, upotreba klijent/server sistema
znacajno poboljsava performanse i brzinu odziva sistema.
Osim srnanjenja saobracaja u mreZi, brzina odziva moze takode biti veca
II klijentlserver sistemu zato sto, dok
server zauzet izracunavanjenl rezul
tata komande koju je primio, radna stanica moze meliti nesto drugo, na pri
mer, obradivati clruge zahteve korisnika. Obrnuto je takode tacno. Dok je
radna stanica zauzeta obraclom korisnikovog zahteva (iIi ceka da kOlisnik
nesto uradi), server baze podataka je slobodan da prima i obracluje zahteve
sa clrugih radnih stanica. SQL Server je po mnogo cemu slozeniji od Jeta i
pruza vise moguenosti, ali brzina odziva sistema sustinski razlog zbog ko
jeg Idijent/server sistemi mogu da podrze znatno veCi broj istovremenih
risnika od baze podataka na umrezenom racunaru. Ovo je jos jec1an slucaj
kad je celina veea od prostog zbira svojih sastavnih delova,
Da bi upotreba klijentlserver sistema bila opravdana, morate prebaciti
sto veei deo obrade podataka na server, Dok je u slucaju baze podataka
smestenoj na umrezeni racunar ccsto opravdano da se upiti cuvaju na lokal
nom racunaru, u dvoslojnol11 klijentlserver sistemu preporucljivo je da oni
ostanu na serveru.
Ako se na SQL Server povezujete kroz Access, morate voditi racuna 0
komandama kOji se izvrsavaju lokalno. Na primer, iskaz SELECT koji sadrzi
funkciju koju definisao korisnik, izvrsava se lokalno u Accessu i ne pros le
duje se SQL Serveru jer SQL Server ne poddava Accessove funkcije u iska
zima SELECT (ne poddava ih ni Jet, pa se upit kOji sadrzi funkciju koju je
definisao korisnik ne moze izvrsiti iz Visual Basica, cak ni kad je taj upit
smesten u .rndb datoteci). Ako nametnete lokalno izvrsavanje, gubite sve
prednosti manipulisanja podacima u mHsini baze podataka.
Sto se prakticne izvedbe sistema tice, postoji vise drugih pitanja koja tre
ba razlllotriti pri izradi klijent/server baza podataka. Savetujcm vam da
proCitate jednu od l11nogih odlicnih knjiga iz te oblasti, od kojih su neke na
vedene 1.1 bibliografiji.

N-slojne arhitekture

Haspoclela obracle izme(lu elva sistema u clvoslojnol11 sistemu ll1oze, ako je

pravilno izvec1ena, znacajno poboljsati performanse aplikacije i brzinu
va. Haspoclela opterecenja na clodatne sisteme moze cia pruzi slicne predno
sti. Ako se vratimo na cetvoroslojnu arhitekturu prikazanu na slid 13-1,
obicno se komponente sloja interfejsa za transakcije i sloja interfejsa za
spoljasnji pristup postavljaju na dodatne fizicke sisteme.
Nazalost, izgJeda da pri tome sJozenost izvedbe raste eksponencija1nom
brzinom. Povezivanje komponenata, zastita podataka, uprav1janje procesima
sve to postaje neizmerno slozenije kada predete na tri ili viSe 10gickih slo
jev(1. Posto slozena struktura tilt sistema cesto zahteva dodatne selvere s raz
nim namenama i nazivima, kao sto je Microsoftov Transaction Smyer, ti
sistemi se obicno nazivaju "n-sJojni". (Izg1ec1a da su fiziCki slojevi po necemu
slicni bivsim muzevima brojanje prestaje pos1e treceg.)
S1'ecom, slozenost prakticne izvedbe je upravo to - problem prakticne iz
vedbe. Vas 1'azvojni tim ce se mozda oprecleliti da napravi novu kmijeru u ple
tenju kOl1)i od prnca , ali n-slojna arhitektura ne utice puno na stntktum baze
podataka. Morate svakako biti posebno strogi po pitanju jasnog razdvajanja 10
gickih nivoa u arhitektUli koda, ali trebalo bi da sema baze podataka koja do
bro radi u dvos1ojnol11 okruzenju bude upotrebljiva i u n-slojnom bez izmena.
Nepovezane arhitekture

Upotreba baze podataka na Internetu ili u intranetima u sustini je pose ban

oblik n-slojne a1'hitekture. DrugaCije su specificnosti tehnologija koje se pri
tome koriste - za razmenu podataka koristi se protokol HTTP, a kao kOli
snicki interfejs verovatniji Internet Explorer nego Access ali, u logickom
pogledu, arhitekture su veoma slicne.
Najvaznija razlika izmedu sistema kOji radi s bazom podataka kojoj pri
stupa putem Interneta i sistema koji radi u tradicionalnijem okruzenju jeste
Cinjenica da se na Internetu ne cuva tekuce stanje. Za 1'azliku od Internet
aplikacije, u tipicnom klijentlserver okruzenju aplikacija ce zahtevati od
korisnika da upise svoje ime i lozinku samo pri pokretanju, a zatim ce te
podatke koristiti kad god t1'eba da se poveze sa SQL Serverom. 1\akon uspo
stavljanja veze (pod pretpostavkom da su ko1'isnicko ime i lozinka prihva
ceni), selver obicno odrZava vezu dok traje sesija. Dok odrzava otvorenu
vezu, selver zna ko je kJijent, a kada ovaj p~saJje I~eki zahtev, selver 1110ze da
IllU posalje trazeni odgovor. Ceo taj "ja znam ko si ti" mehanizam zove se
stanje (eng!. state) i odrZava ga selver baze podataka.

0.lctlutim, kad,l Sc: bazi poc\ataka pristupa preko lnterneta, server haze
podataka \'iSe 11e oc1rzm<\ poclatke 0 stanju. Kad gm1 aplikacija posa)je zahtev
serveru haze poc1ataka, mora ponovo da t1spostavi \'CZU s njim i cIa P0l10VO
proslecli svoje identiflkacione podatke. Kada server baze podataka ohracli
primljeni zahtev, "zaboravlja" sve 0 aplikaciji koja je poslala.
Nekael su nepovezane arhitekture bile ogmnicene na Internet i intrane
te, ali posto sada tn arhitekturu namece ADO. NET, bez obzira na fizicku ar
hitekturu, post~~e sve teze izbeCi je.
U veCini okolnosti, mali dodatan posao ponovnog uspostavljanja veze pri
svak0111 110vom zahtevu vrlo malo utice na sistem koji radi s bazom podataka,
a svakako l1ema nikakav uticaj na semu baze podataka. Medutim, cinjenica
da se na Internetu ne cuva stanje, svakako utice na aplikaciju i zbog toga
moze zahtevati izmene seme baze podataka.
Vecina Internet aplikacija nastoje da budu laki klijenti (eng!. thin cli
ents). To znaci da aplikaeije obavljaju sto je moguce tllanji deo obrade na ldi
jentskoj strani, kojoj se obicno dodeljuju samo poslovi vezani za korisniCki
interfejs. Ali zamislite upit kOji ueitava veliki broj zapisa viSe nego sto moze
da se prikaze na jednom ekranu. U tradicionalnoj aplikaciji, skup rezultata bi
se u tom slucaju smestio u kes - na klijentskoj strani iii na selveru.
Meautim, u Internet aplikac.:iji, rezultati se ne mogu kesirati na ser
verskoj strani jer selver ne bi znao kuda da posalje sledecu grupu zapisa.
Ako se rezultati kesiraju na klijentskoj strani, komponente koje manipulisll
poc1acima (sloj interfejsa za transakcije i sloj interfejsa za spoljasnji pristup)
moraju se takoae nalaziti na klijentskoj strani, ate komponente svakako nisu
"lake". Cak su i prilicno "teske".
ActiveX Data Objects (ADO) i Netov Framework stavljaju na raspo
Iaganje mehanizam nazvan stranicenje (eng!. paging) za obradu takvih sluca
jeva, Stranicenje omogucava da zadate broj zapisa kOji zelite da ucitate iz
skupa rezultata. Slieno je odredbi TOP K standardnog SQL-ovog iskaza SEL
ECT, s tom razlikom sto imate mogucnost da zahtevate i "K zapisa iz sredine".
Na selverskoj strani, stranicenje izaziva ponovno izvrsavanje upita lmcl
god korisnik zatrazi novu stranicu. To nije problem kada upiti imaju prihva
tljivo vreme odziva. Pri slozenim upitima, kOji se relativno sporo izracuna
vaju, imate veliki problem. Aplikacija koja svog jedinog kOlisnika primomva
da ceka nekoliko minuta, jedva je prihvatljiva. Ali aplikacija koja primonlva
vise hiljada korisnika da cekaju nekoliko minuta kad god hoce da vide sle
deCih pet zapisa, zavrsice u korpi za otpatke, gde joj je i mesto.
Ako imatc problem sa slozenim upitom II nepovezanoj aplikaciji, postoji
nekoliko resenja. PIVO, koje je u veCini slucajeva i najpreporucljivije, jeste da
optimizujete upit "do daske". Upotrebite privremene tabele, denormaliznjte
podatke, uradite sve sto treba da biste vreme odziva smanjili na prihvatljiv
nivo.

Ako to nije izvodljivo, mozela cc vam jedinCl ll10gU(:llost biti (b nnpravitc

teskog klijenta (engl. fat client) tnko sto cde komponente koje direktno mCl
nipulisll podacima premestiti na ldijentskll stranll. Takva arhitektura 0l110gll
cava da kesirate rezultate upita l1a kli,ientskoj strani, c:ime zapravo dohijatc
okruzenje slic:no onome s bazom podataka na umrezenom racllllaru (uz 11('
koliko komplikaeija, ela se ne biste previse opustili).
Medutirn, teski klijenti 5U llglavnom pogoelniji Zit mel u Intranet okruze
nju nego lla Internetu, uprkos Microsoftovoj arhitekturi \Veb servisa. Mnogi
Ijudi imajll potpuno opravdan otpor prema prellzimanju komponenatn koda
sa Interneta, ali je manje verovatno da ce se tako oseenti kada se meli 0 javno
clostupnoj aplikaciji. Ako se to i desi, 1110zete se sa1110 nadati ela je saelrzaj kOji
nuelite clovoljllo vreclan da prevlaela otpor korisnika.

Komponente seme baze podataka

Posto zavrsite koneeptualni model poclataka i opredelite se za arhitekturu si
stema, imate veCinu informacija koje vam trebaju cla biste napravili semu
haze podataka. Sema baze podatnka je opis eleme;1ata poclataka koji 6e posto
.inti u bazi. Ako ste izbarali bilo sta drugo osim arhitekhIre samostalne haze
podataka, sema baze podataka deHnisace i mesto gde ce se nalaziti svaki
objekat.
. Ako vas sistem racli sa Aceessovom bazom poclataka, sema baze podata
ka saelrZace clefinieije svih tabela, llpita i veza izmedu tabe\a, ali i opise obra
zaca, izvestaja i komponenata koela koji se koriste u siste111u, iako su i oni
smesteni Ll .mdb datoteci. Ukoliko vas sistem racli sa SQL Serverovom ba
zom podataka, sema
podataka saclrzace deHnicije svih tabela, prikaza,
usklaeliStenih procedura i okiclaca u bazi poclataka.

Definisanje tabela i veza izmedu njih

Definieije fizickih tabela u semi baze poc1ataka, clirektno su izveclene iz kOI1
ceptualnog modela podataka. Entiteti postaju tabele a polja tabele postaju
atributi entiteta. U SV0111 vecem delu, to je jeclnostavan postupak nepos red
nog preslikavanja. Jedine oblasti koje zahtevaju vise paznje jesu uslovi, veze
izmeclu tabela j indeksi.

Us 10 vi

Kao sasta\'ni
postupka cleflnisanja konceptualnog Jl10dcla podataka, dcfl
nisali ste i uslove za entitete, atribute i clomene. Da Ii cete te uslm'e preslikati
11 semu haze podataku, zavisi
kao sto smo videli ocl izabrane arhitekture si
stema, Klto sto sarn vee pomenuJa, neki projektanti najradije realizuju we
uslove iskljucivo u sloju interfejsa za podatke i u sloju interfejs't za transakcije
cetvoroslojnog modela, odnosno u sloju poslovnih usluga, u troslojnom
modell!.
U veCini s]uc<\jeva, preporucujem vam da uslove realizujete na oba
nivoa. Pod pretpostavkom da se slazete sa I11nom i c1a ste se opredelili cIa tlS
love realizujete u samoj bazi podataka, deflnisacete ih kao sastavni deo seme
baze podataka, Healizovanje integriteta podataka detaljno smo razmotrili u
poglavlju 4, ali korisno je da to ovde ponovimo.
Vecina uslova za domene i atribute, u semi baze poclataka preslikaee se u
uslove za polja u Aeeessu najcesee kao pravila ispravnosti podataka. Access
takode podrZava odredbu CHECK koja se koristi na SQL Servern ako se
opredelite da bazu podataka napravite pomocu SQL-ovih komandi umesto
pomocll DAO objekata iIi Accessovog korisnickog interfejsa.
Uslovi koji vaze za entitete obicno postaju uslovi koji vaze za tabele, a
oni se takode mogu zadati kao pravila ispravnosti podataka iIi kao SQL-ovi
uslovi tipa CHECK. Uslov za integritet entiteta, prema kome svaki primerak
entiteta mom da se identifikuje na nedvosmislen nacin, mozete obezbecliti
tako sto cete definisati primarni kljuc za svaku tabelu.
Bez obzira Illt to da Ii bazu podataka clefiniSete za SQL Server ili za
masinu baze podataka Jet, moze se clogoditi da ustanovite kako se neld uslovi
definisani u konceptualnom modelu podataka ne mogu zadati kao sastavni
deo definicije tabele. Na SQL ServeI'u, ispunjavanje takvih uslova mozete
obezbediti pomocu okidaca, BuduCi da masina baze podataka Jet l1e podrza
va okidace, ispllnjavanje tih uslova l110rate obezbediti u koelu aplikacije.
Veze izmedu entiteta

NaCin modelovanja veza izmedu entiteta razmatrali smo 11 poglavljima 3 i

13. Prvi komk je uvek dodavanje jeclinstvenog identifikatorct iz prim arne re
lacije u spoljnll relaciju. U seme baze podataka, to znaci da se polja primm-
nog ldjuca iz primarne tabele dodaju spoljnoj tabeli.
Neki projektanti se na tome zaustavljaju jer vise vole cla se 0 ocuvanju
referencijalnog integriteta stara aplikaeija nego cIa to prepuste masini baze
poclataka. Kao i sve provere ispravnosti u vezi s bazom podataka, u svojim

aplikaeijam<l ja koristilll i jeclno i drugo: cla li jc refereneijalni integritct naru

sen provcravam \l aplikaciji, zbog npotrebljivosti, a takocle 11 masini haze
poclataka, zbog hezbeclnosti. Kada bih hila lllllskarac, pretpostadjam cia bih
nosila i kaiS i naramenic.:e.
Vee S1110 razmotrili vaznost indeksa za perfonnanse sistem,l. Svaka tabe
la treba da illla barem jedan incleks, kOji masina baze podataka pravi auto
matski ako deklariSete primarni kljuc. OSi111 toga, trebalo hi da napravite
indeks za svako polje iii kombinaciju polja koju cete koristiti za spajanje s
drugim tabelama. To obicno nije problem u tabeli koja p1'edstavlja primarnu
relaciju, posto su polja plltem kojih se uspostavlja veza primarni Idjucevi.
Meautim, mozda ee biti potrebno da deklarisete dodatne indekse za tabelu
koja predstavlja spoljnu relaciju ako polje ili polja p1'eko kojih se ta relacija
spaja s primarnom relaeijom ne cine ceo primarni kljue spoljne relacije.
Ako polja spoljnog kljuca ueestvuju u primarnom ldjucu ali to nije ceo
kljuc, definisem zaseban indeks za polje spoljnog kljuca. Na primer, t~bela
StavkePorudzbine obieno ima primarni kljuc oblika !BrojPorudzbine, Sifra
Artikla}. lako se u veCini slucajeva (dobro, u svim slucajevima koje mogu da
zamislim) incleks definisan za primarni kljuc moze upotrebiti za spajanje s
glavnom tabelom Porudzbine, verovatno bih ipak napravila pose ban indeks
za polje BrojPorudzbine samo da bih bila sigurna.
Trebalo bi cIa indeksirate i sva polja po kojima ce se sortirati podaci. Na
primer, lsite kupaca se obicno sortimju po imenu kupca i datumu poruclzbi
na, iako obieno nijedno oel tih polja ne lIcestvuje u primarnom kljucu, niti se
preko njega uspostavljaju veze s drugim tabelama. Indcksiranjem polja po
stupak sortiranja postaje laksi i efikasniji.
BuduCi cIa se sa indeksima lako moze preterati, budllite oprezni. Ne
zaboravite da je odrZavanje indeksa mali posao, ali koji se sa svakim novim in
deksom povecava. Svako polje po kojem se tabela cesto sortira treba indeksi
rati, ,ui zapise uvek mozete sortirati pOl11oeu SQL-ove odredbe OHDEH BY,
bez upotrebe inc1eksa.
U praksi, najveCi broj incleksa po tabeli zavisi najviSe od toga koliko se
cesto tabela aZUlira. (OdrZHvanje indeksa je potrebno samo kada se tabeli
doda nov zapis iIi se azurira sadrzaj indeksiranog polja.) Za tabelu bo sto je
Poruc1zbine, koju ee sistem azurirati manje iIi viSe redovno, ne bib odrZavala
viSe od 10 do 1.5 indeksa, ukljucujuCi i one za spajanje s drugim tabelama i
primarni Idjuc. S druge stnme, upotreba viSe indeksa moze biti opravdana za
tabelu Artikli koja se retko azurira, ali se koristi na puno naCina u celom si
stemu. Keto i uvek vasa odluka mora hili zaSlIovaml llH n<lcillu }Jet kOji ee se
podaci koristiti.

Prikazi i upiti
I Access i SQL SelYCr omoguc.avaju sklaclistcnje SQL-ovih iskaz<l SELECT.
Ti uskladisteni iskazi zo\'u se prikazi (engl. viuu.:s) II SQL Scrveru i upiti
(eng!. qlleries) u Accessu. (J a ell ill u ovoj knjizi nazivati upiti jer je to llohic<l
jeniji izraz.) U veCini sluCajeva, llpotreba usklac1istenog llpita br7.tl oel izvr
savanja iskaza SELECT sastavljenog po potrebi; to nije bas uvek tacno, ali
situacije u kOjima to ne va7.i toliko Sll retke cia se navedeno moze smatrati
opstim pravilol11.
Koje eete upite ukljuciti II semu baze podataka, oclredicete tako sto cete
u konceptualnom l110delu podataka potraziti slozene entitete. I majte u vidn
da je slozeni entitet logicki entitet kOji se zbog efikasnosti l110deluje p0l110ell
dve iIi viSe tabeIa. Trebalo bi cla u semu baze poclataka ukljuCite svaki upit
kOji denormalizuje slozeni entitet u vasel11 modelu. VeCina tih entiteta bice
tabele izmedu kOjih postoji veza tipa "jedan prema vise", kao iZl11edn tabela
Porudzbine i Stavke Porudzbine, ali se l110ze desiti i cla imate slozene entite
te s potklasama, izme(iu kojih postoje veze bpa "jedan prema jedan", pa i za
njih morate do dati upite da biste ih podrZali.
Korisnicima ee cesto trebati da pronadu odredene zapise u primarnim
entitetima sistema - na primer, datog kupea ili porudzbinu a to je druga
oblast u kojoj treba traziti upite kOji ce biti ugradeni u senm baze podataka.
Trebalo bi da sve te uobiCajene pretrage podrZite p0ll10ell parametarskih
upita koji korisnicima o11logucavajll da II vreme izvrSClvanja aplikacije zadaju
zapis kOji illl treba.
Ponekad ee bib potrebno da za isti entitet obezbedite vise upita tipa
"pronadi". Na primer, korisnikll l110ze da zatreba da pronacle poruclzbinll na
osnovu DatumaPorudzbine, SifreKupca iii BrojaPoruclzbine. Sve te opcije
treba podrzati pomocll zasebnog parametarskog upita.
S druge strane, korisnici nece pretrazivati bas sve tabele. U semi baze
podataka mozete imati tabelu koja sadrzi sve opstine u drzavi. Tal<ve refe
rentne tabele su izuzetno kOlisne, ali .Ie i izuzetno malo verovatno da ee kori
snici ikada traziti zapis 0 odredenoj opstini.
TrebaJo bi da takocle potrazite moguce upite i U obrascima i izvestajima
kOji se koriste u aplikaciji. Trebace yam upiti za povezivanje polja i upiti za re
ferentne podatke, kao sto su oni za prikazivanje pomOCtl padajuCih lista. Ako
U sistemu postoje zavisnosti izmedu obrazaca, trebace vam parametarski upiti
da biste i to podrzali. Primer
moze biti ohir za dijalog kOji se poziva jz
obrasca za unosenje porudzbina radi prikazivanja podataka 0 KUpCll.

U zavisnosti oel radnih procesa koje stc otkrih II sistemll, II selllll haze
poelatab llkljllcicete llpite (a na SQL Se\'eru mozda llskladistene procedure)
koje
izvrsavaju
.
. oclreciene akC:ije.
. Ako znate cla ce sistem reclovno arhivirati
stare poruclzbine ili azurirati cenovnike artikala, eflkasnije je da te aktivnosti
poclrzite pomocll upita iii uskladistenih procedura umesto cla potrebne ko
mancle ponovo formirate kad god zatreba.
Tokom izrade sistema, semu baze podataka verovatno cete dopuniti clo
datnim akc:ionim upitima. Za razliku od indeksa, posto upiti i uskladistene
procedure ne uvode nikakvo doclatno opterecenje sistema pri llpotrebi, ne
mojte se ustrucavati da ih dodate u semu baze podataka.
Imajte u vidu da razvoj sistema nije strogo lineman postupak. Dok izme
ne struktura tabela tokom izrade sistema mogll da budll llzrok problema
(a sto je vise oclmakao postupak razvoja, veCi ce biti i problemi), dodavanje
novih upita u semu trivijalan je posao koji treba ocekivati.

Zastita sistema
Posto dobro upoznate radne procese u sistemu i napravite konceptualni mo
del podataka, morate razmotriti administrativne zahteve sistema. Admini
strativni zahtevi ne moraju direktno uticati na semu baze podataka, ali su oni
poslovna pravila koja se ipak moraju poclrZati u verziji sistema koja ce uCi II
redovnu upotrebu.
Administrativni zahtevi su, II izvesnom smislu, "metazahtevi", po tome
sto se odnose na sam sistem a ne na prostor problema koji sistem modeluje.
Mogu se razvrstati u dye kategorije: bezbednosni zahtevi, kOji odreduju ko
moze da pristupa sistemu; zahtevi u pogledu raspolozivosti, koji odreduju
elemente kao sto su koliko cesto sistem mora biti dostupan (24 sata dnevno,
sedam dana u nedelji, iii samo u uobicajeno radno vreme, na primer) i kako
ce korisnici praviti rezervne kopije podataka. Posto je raspolozivost sistema
gotovo u potpunosti pitanje njegove fizicke izvedbe, ovde cemo razmotriti
samo probleme zastite sistema.
Razrada bezbednosne strategije moze biti slozen posao. Srecom, postup
ci su dobro dokumentovani za Access i masinu baze podataka Jet, kao i za
SQL Selver. Sto je jos veca sreca, posto je dizajn baze podataka odvojen od
njene prakticne izvedbe, tokom te faze postupka potrebno je da razmotrite
logicke bezbednosne mere, ana logickom nivou principi su jednostavni.

Nivoi zastite
Pno moratc utvrcliti kOji nivo zastite potreban. Imajte II vidll cla se 11 mom
slucaju radi 0 zastiti }loria/aka, a ne programskog koda sistema, sto pitanje
pmkticne izvedbe sistema. Najnizi ni\'o zastite je potpuno nezasticen sistem
koji dozvoljava plistup bazi podataka svakome, u svako doba. Takav sistem
oCigledno lako napraviti i administrirati jer ne treba da uradite nista posebno.
Me(tutim, ako podaci imaju bilo kakvll vrec1nost, izrac1a potpuno ne
zasticenog sistema predstavlja veliku nemarnost. To ipak moze biti opravda
no ako klijent u svojoj mrezi preduzima mere zastite pomocu kOjih moze
ograniciti pristup podacima. Nema potrebe da vi duplirate te mere zastite.
SledeCi nivo je zajednicki nivo zaStite (engl. share-level security) Na
tom nivou, doc1eljujete lozinku koja omogucava pristup celoj bazi podataka,
a svako ko zna tu lozinku moze da pristupa sistemu. Takva vrsta zastite ta
kode se lako pravi i aelministrira, a zahteva samo povremene izmene lozinki.
Zajeelnicki nivo zastite je dovoljan u mnogim situacijama.
Zastita na nivou pojedinacnog korisnika (engl. user-level security),
iako zahteva vise trucla za izradu i administriranje, omoguCava najdetaljniju
kontrolu nad bazom podataka. ZaStita na nivoll pojeelinacnog korisnika 01110
gucava administratoru sistema da svakom korisniku pojeclinacno clocleljuje
tacno odredena prava: "Mika 1110ze ela dod,~je i azurinl podatke entiteta
Kupci ali moze samo da gleda Porudzbine. Jelena i Mika mogu cla unose
nove i da azuriraju postojece podatke u entitetima Kupci i Poruclzbine. Ni
Mika, ni Je1ena ne mogu da briSu zapise iz tih entiteta".
U stvmi, nazvati taj mehanizam zastita na "nivo11 kOlisnika" p0111a1o navo
eli na pogresan zakljueak Bezbednosne plivilegije mogll se dodeljivati korisni
eima pojedinacno, ali se mogu clodeljivati i opstim kOlisnickim u10gama (engl.
roles) kojima se potom pridruzuju pojedinacni korisnici. To je efikasniji me
banizam za pIimenu zastitnih mera jer zahteva znatno manje administriranja.
U tom mode1u, morate najpre utvrditi kategorije korisnika - administra
tori sistema, operateri za unosenje porudzbina, referenti prodaje itd. - a za
tim treba ela oelredite bezbednosne privi1egije koje su neophodne svakoj
kategoriji (u1ozi) za svaki objekat u sistemu. Nije neophodno da dodeljujete
prava za same objekte koji predstav1jaju podatke; u stvari, bo1je je cia to ne
Cinite. Mozete oelrec1iti ela .Ie referentima prodaje potrebno da clodaju, Hzuri
raju i brisu zapise iz tabele Kupci, ali ne zelite ela oni bilo sta petljaju sa sa
mom tabelom. '\10zete im staviti na raspolaganje obrazac za odrzavanje
podataka u tabeli Kupei, ali im necete elozvoliti da pristupaju elirektno samoj
tabeli. Tako iskljucujete mogucnost ela oni nenamerno zaobi(tu oclreclenu
posebnu obradu koja se pokrece iz koela obrasca za oelrzavanje.

Cesto je potrclmo (b oclre(1enim korisnic:ima dozvolite cIa vide S,\1110 cleo

podataka. N,l primer, 1110zete clozvoliti s\1111a da vide sacIrzai polja 1111e i Broj
Lokala iz tabele Zaposleni, ali ('e sa1110 rukm'oc1ici 11106 cla vide saclrzaj polja
1znosPlate. Ili, l110zete doz\'oliti proc1avcima cia II tabeli Porudzbine vide
SClmo one koje su poslali njihovi klijenti, ali ne i tm1e porudzbine. Da biste
podrZali opisane sitlladje, mozete dodeliti privilegije za izvrsavanje odgova
raju6h upita i zabraniti direktan pristup tabelama koje su predmet tih upita.
Pracenje proteklih aktivnosti

Osim kontrolisanja ko sve ima pristup podacima, mozda ce biti potrebno da

znate i sta su korisnici radili. Zahtevi tog tipa mogu biti vrlo razliciti. Neke
organizacije zele da prate samo ko se prijavio u sistel11 i kada. Druge zahte
vaiu detaljnu eVidenciju ko je napravio izmene i kak'Ve. Trece pak zahtevaju
nesto izmedu te dve krajnosti.
Kako cete modelovati zahteve za pracenje proteklih aktivnosti zavisice
od prirode tih zahteva. Ako treba da pratite samo ko je sve koristio sistem,
verovatno ce biti dovoljan jedan entitet sa atributima ImeKorisnika, Vreme
PIijave i VremeOdjave. Dodajte nov zapis kada se korisnik prijavi u sistem i
azurirajte ga kada se on odjavi iz sistema.
Ponekad je potrebno da znate ko je dodao nov zapis. To mozete omogll
citi u primarnom entitetu pomocll jednog ili dva dodatna atributa: Dodao
Korisnik i, mozda, DatllmUpisa.
Pracenje brisanja moze biti slozenije. U relac.:ionoj bazi poclataka, irnate
nekoliko mogucnosti. Mozete potpuno zabraniti da kOlisnici briSu zapise i
urnesto toga dodati indikator Izbrisano i mozda jos atribute IzbrisaoKorisnik
i DatumBrisanja. To je korisna tehnika ako zelite da zapise kopirate II arhiv
sku datoteku pre nego sto ih uklonite iz baze podataka.
Druga mogucnost je da dozvolite brisanje ali da potrebne podatke upisu
u datoteku dnevnika (engl. log file ), na isti naCin kao sto biste pratili kOli
snike kOji se prijavljuju u sistem. Razume se, verovatno cete morati da dodate
nekoliko novih atributa. Na kraju krajeva, nema mnogo svrhe da znate da je
neko izbIisao zapis ako nemate nacin da rekonstruisete zapis kakav je biD.
Ukoliko je potrebno da znate sve detalje izmena, moraeete da upotrebi
te neku od tehnika pracenja izmena dimenzionalnih zapisa, opisanih u
poglavlju 8.
Ako nameravate da bilo koju od opisanih tehnika pracenja proteklih ak
tivnosti realizujete POlllOCU Jetove baze podataka, moraeele da sprecite ko
risnike da direktno pristupaju tabelarna jer bi im to omogucilo da zaobiclu
mere
Na SQL Serveru to nije potrebno, jer on poddava okidace
baze podataka, koji se ne mogu zaobici.

Bez obzira na naCin nn koji modelujete zahte\'(' za pracenje proteklih

aktivJ1osti, morate imati u yitIlI kako ce se ti podaci koristiti, ko ce ih koristiti
i 11 kojim okolnostima. Ocigledno je da morate ograniCiti pristup tabelama s
tim podacima. Moze biti neophodno i LIn projektl1 sistema dodate raclne 1'ro
cese koji omogucavaju pracenje proteklih aktivosti. Treba li omogllCiti admi
nistratorima sistema da poniSte naCinjene izmene i vrate staro stanje? Da Ii
su potrebni izveStaji 0 upotrebi sistema?
Prema mom iskushru, svrha veCine zahteva za pracenje proteklih aktiv
nosti jeste nekakav oblik osiguranja od nezgode, a podad kOji se pri tome
prikupljaju koriste se samo u izuzetnim okolnostima. Ako imate takav slncaj,
moze nece ni biti potrebno da dodajete nove radne procese za tu namenu.
Administratori sistema mogu bez problema da koriste Access na internkti
van nacin iIi SQL Serverov Enterp'ise Manager da bi rucno pregledali po
datke i prcduzeli potrebne akcije.

Sazetak
U OVOI11 poglnvlju, mzmotIili smo preslikavanje konceptualnog modela poda
taka u semu fizi6ke baze podataka. Prvo smo proucili dve arhitekture za
strukturiranje koda u sistemu - troslojni model i cetvoroslojni model- prven
shreno sa aspekta kako izbor arhitekture koda utice na semu baze poc1ataka.
05im toga, razmotrili smo nekoliko moguCih arhitektura podataka. U jed
noslojnom sistemu, aplikacija i podaci smesteni su na istom logickom racu
naru. Jednoslojna aplikacija moze raditi kao samostalna aplikncija, iii se poclaci
mogu nalaziti na nekom racunaru u mrezi, ali biti dostupni samo jednom ko
risniku. Mrezne aplikacije koje rade s 111asin0111 haze podataka Jet takode su
logicki jednoslojne, ali podacima moze plistupati vise kOlisnika istovemeno.
Dvoslojne, iii klijenllserver aplikacije mozete praviti P0ll10CU SQL Ser
vera. U toj logickoj arhitekturi, serverski racunar direktno manipuliSe poda
cima, dok klijent komul1icira s korisl1iko111. OSl1ovni principi clvoslojnih
aplikacija mogu se prosiriti na tri iii vise racunara da bi se dobilo ono sto
poznato kao n-slojna aplikacija.
Potom smo preSJi na preslikavanje konceptualnog l110clela podataka 11
semu baze podataka. To je obicno jednostavan po stupak jer je jeclini nov po
sao definisanje indeksa i upita koji ce se koristiti u bazi podataka. I najzacl,
obradili SIno posledice koje bezbednosni zahtevi mogu imati po semu baze
poclataka, a zatim smo ukratko pogleclali zastitne mere na logickom nivou.
U sledecem poglavlju, razmotriCemo ukratko neke probleme predsta
vljanja projekta sistema klijentu i razvojnom til11u.

Predstavljanje projekta

Ako sistem koji radi s bazom podataka ne pravite za lienu upotrebu, morate
biti u stanju da rezultate svog rada predstavite drugim ljudima. Obratite
paznju na to da sam upotrebila ree "predstaviti", a ne "dokumentovati". Kao
SCl';tavni deo predstavljanja projekta, moracete da napravite barem jedan do
kument, ali videla sam bas preveliki broj analiticara Cija se "dokllmentacija
projekta sistema" sastoji od recnika podataka, slika ekrana i uzoraka izvesta
.la, a tome nije pridruzeno niSta sto bi objasnilo kako su ti elementi medu
sobno povezani.
Sva dokumentacija ovog sveta nece posluziti nicemu ako je nerazllmljiva
i nepregledna. Kao sto ne mozete naueiti strani jezik samo citajuCi recnik za
taj jezik, tako ne mozete ni shvatiti projekat ako samo eitate tabele njegovih
podataka.
A sada, moje lieno misljenje: buduCi da je za ovaj posao apsolutno neop
hodna osnovna sposobnost izrazavanja u pisanoll1 obliku, ako imate izvesne
snl1mje po tom pitanju, nabavite dobru knjigu (neke od l110jih omiljenih na
vedene su u bibliografiji) iii se upiSite na neki kurs iz te oblasti. Gamntlljem
yam da je to dobro utroseno vreme. Ako je vase znanje gramatike manjkavo,
vasi klijenti ce se sigurno pitati sta .i0s niste razumeli kako bi trebalo. (Kraj
moje propovedi.)

Ciljne grupe i svrha

Poznavanje publike kojoj se obracate vazno .Ie za svako pisano delo, ali na
rocito za predstavljanje projekta sistema jer cete vrlo verovatno imati vise vr
sta Citalaca, s razlieitim zahtevima.
Morate razmotriti sta vi i vasi citaoci pokusavate da postignete. Primarni
cilj vasih klijenata jeste da od vas dobiju potvrdn da ste razumeli njihove
zahteve, a sekundarni cilj im je da im pfll7.ite osec:aj cia ce h11d11Ci sistem

225

osl':ariti postavljene ciljeve. Vasim klijentima nije potrebno (niti zcle) (la ra
zumeju detalje prakticne izvedbe sistema. Ali ako ce c10kmnent biti osnova
za razyoj, potrebno da razvojni tim Doci sve one skaklji\'e cletalje zhog ko
jih ce klijent prevrtati oeima.
Ponekad je najbolje resenje da pripremite vise dokumenata: jeclan za
klijenta i drugi, razlieit, namenjen razvojnom timu. To je narocito dobro
resenje ako koristite iterativni razvojni model jer se tesno poklapa s mode
10m. U takvim situacijama, pravim sledece dokumente:
Specifikaciju zahteva, namenjenu prvenstveno kIijentu, koja opisuje
moje razumevanje sistema, izrazeno (relativno) netehnickim termi
nima.
Specifikaciju arhitekture, koju ce Citati i klijent i razvojni tim, ali koja
je ipak namenjena prvenstveno ovom drugom. Taj dokument detalj
no opisuje veze i zaviSllosti izmedu k0111punenata.
Zasebnu tehnicku specifikaciju svake komponente, koju ce koristiti
razvojni tim.
Za jednostavnije sisteme, obicno je dovoljan sa1110 jedan dokument.
Obavezno razmotrite potrebe svake ciljne grupe i svakoj pruzite informacije
koje su joj potrebne, u obliku kOji ce lako razumeti.

truktura dokumenta
Ako organizacija za koju radite nema specificne standarde za dokumentaciju
koje cete rnorati da primenite, konacna struktura vaseg clokumenta zavisice
od njegovog opsega i vaseg licnog ukusa. Moze biti jednostavan iIi slozen ko
liko vi smatrate da treba; ne postoji standardizovan format. U OV0111 pogla
vlju dajem nekoliko opstih smemica, ali to einil11 uz pretpostavku da cete ih
prilagoditi svojim potrebama.
Ako ste sleclili moje preporuke za analizu sistema, ustanovicete cia se clo
kllment sastoji od nekoliko jasno definisanih odeljaka kOji 5e (ne sasvim slu
cajno) poklapajll s poglavljma iz treceg dela knjige. Verovatno cete cloclati i
neki Uvod iii Sazetak namenjen rukovodstvu.

Sazetak za rukovodstvo
U velikim organizacijama, razvojne projekte ccsto nadgleda komisija za raz
voj. Cak i za manje projckte, obicno neko iz rukovodstva ko nije neposrcdan
ucesnik projekta im<1 nadzornu ulogu iIi se stam 0 budzetu projekta. Ako
neko nadglecla vas projekat, korisno je da u dokumentaciju ukljueite oc1eljak
"Sazetak za rukovodstvo", direktno namenjen toj osobi.
Te osobe uglavnom nisu zainteresovane za detalje sistema, vee imaju ne
koliko specificnih pitanja na koja zele odgovore, a sto im efikasnije odgovori
te, to bolje. Rukovodstvo zahteva odgovore na pitanja sliena sledeCim:

Koje probleme predlozeni sistem resava?

Da li je to najbolje i najekonomicnije resenje?
Koja ste druga resenja razmatrali?
Koliko ce vremena biti potrebno za izradu sistema?
Koliko ce sve to kostati?
Koji su rizici?

Trebalo bi da odgovor na plVO pitanje bude jednostavan ako ste clobro

definisali ciljeve i opseg sistema. Ovde clovoljno da ih ponovo navedete.
Licno volim da sto detaljnije opisem sve sto je bilo razmtarano za ukljuci
vanje u sistem, ali ipak odbaceno. Ustanovila sam da je to dobra "polisa
osiguranja" od kasnijeg upiranja prstom.
Ako ste spoljni konsultant, mozda necete moCi da odgovorite na drugo i
trece pitanje 0 drugim resenjima. Ukoliko ipak imate te informacije, kori
S110 je da
kratak opis drugih resenja koja su mozda bila razmatrana,
kao i razloge zbog kojih su bila odbacena. Rukovodstvo time stice osecaj da je
i alternativnim resenjima bila posvecena duzna paznja.
Nastojte da vasi odgovori na drugo i trece pitanje budu sto kraci. Ako ste
vrlo detaljno razmatrali nabavku gotovih aplikacija, ali ste ih l1a kraju odbacili
u kOlist izrade namenskog resenja, verovatno ste detaljno llaveli uporedne
pravo
poclatke 0 cenama, funkcionalnostima, tehnickoj podrsci itd. Ovo
mesto za tu vrstu informacija: navedite ih u posebnom dodatku. Ceo Sazetak
za rukovodstvo ne bi trebalo da bude duzi od nekoliko stranica.
Odgovoranje na pitanja 0 rokovima i troskovima moze biti zapetljano, a
gotovo uvek plasi. Ali lakse je odgovoriti na njih ako razmislite sta nudite ru
kovodstvu. Ako razvijate jednostavan sistem, verovatno cete dosta dobro
znati sta cete odgovoriti na ta pitanja, na osnovu opsega sistema. Medutum,
ako je sistem opsezan i slozen, jos necete znati koliko dugo ce trajati razvoj,
niti koliko ce tacno kostati, ali to je u redu. Znacete sta je sledeCi komk, a to
je jedino za sta yam u ovoj fazi treba pristanak klijenta.

Ako
realno dn kazete nesto poput "zasml .ios llije mogllce proceniti
ukupno vreme iii troskove do potpunog uvo(lenja u reclovnu upotrebu, ali
ocekujemo da ce to biti nesto U opsegu ocl x do y. Meclutim, za zavrsetak na
reeIne f:lze bice potrebno samo .::;, a njen rezultat ce biti ...", trebalo bi (b to
bude prihvaceno. Postarajte se samo eIa 0110 sto sledi iza "rezultat ce biti ... "
bude realno izvodljivo i dovoljno korisno za organizaeiju. Prema mom isku
stvu, ljudi su vrlo nevoljni da plate za "dodatna istrazivanja".
Ustanovila sam i da je pravilna obrada poslednjeg pitanja, u vezi s rizici
ma, jedan od najefikasnijih nacina da obezbedite kredibilitet kod klijenta.
Posvetite izvesno vreme razmiSljanju 0 tome sta bi sve moglo luenuti naopa
ko. Postoje Ii tehnicki problemi kOji nisu reseni? Da Ii se stvari mogu oduziti
vise od ocekivanja? Cde? Zasto? Budite paranoicni.
A onda se vratite u stvamost i budite realisticni. Kolika je verovatnoca da
ee se te stvari zaista dogoditi? Da, maze se dogoditi da ceo vas razvojni tim
bude izbacen iz stroja zbog neocekivane epidemije kuge, ili da iznenadna po
plava uniSti prostOtije u kojima radite. Ali sve to nije mnogo verovatno. Ono
sto jeste verovatno jeste da ce tokom projekta ndfto krenuti naopako, a ruko
vodstvo zeli da zna da ste uzeli u obzir moguee probleme i pripremili odgo
varajuce pIa nove za takve slucajave. Ne morate da navedete bas sve, vee
mozda u nekoliko pasusa samo eIva iii tli najveca problema koji vas brinu, ali
vazno je da pokazete da ste uzeli u obzir odredene rizike i probleme.
Ako ste spoljni konsultant, preporucujem yam da ne zabasurite pitanje
svoje struenosti. OCigledno je da ce prvo pitanje onoga ko vas angazuje za
posao bib da Ii ga vi mozete obaviti. Sazetak za rukovodstvo verovatno nije
najbo1je mesto da navedete svoje struene reference, ali bi trebalo da obradi
te potencijalne rizike ukoliko posao ne bude dobro uraden. Detalji pregovo
ra po tom pitanju zavise iskljueivo od vas; ne mogu yam niSta preporuCiti u
vezi s time. Iskustvo mi je pokazalo da direktan razgovor na tu temu dopri
nosi uspostav1janju vaseg kredibiliteta kao pos1ovne osobe.

lpis sistema
Bez obzira na to da Ii ste ukljucili formalni Sazetak za rukovodstvo ili manje
strukturiran Uvod, prvi ode1jak "pravog" dokumeneta je Opis sistema. To je
jedini odeljak dokumenta u kome su sliene potrebe svih kategorija Citalaca
dokumenta. I razvojni tim i klijent treba da razumeju opSti opseg projekta.
Razlikovace se samo nivoi detalja.
Ako niste pripremili formalni Sazetak za rukovodstvo, trebalo bi da neke
od infonnacija koje bi inace bile u tom odeljku navedete u ode1jku Opisi si
stema. Cak i ako ste pripremili Sazetak za rukovodstvo, moze biti korisno da

ncke teme sHdn detaljnije rnzradite, Druga mogucnost jc cIa neka pitanja
kao sto su porcdenje alternativnih resenja iIi opis moguCib rizika budu to
liko opsezno opisana da opravdavaju zasebne odeljke,
Bez obzira na to da Ii cete u dokument ukljuCiti i ta pitanja, vas glavni cilj
u ovom odeljku jeste da pruzite "veliku sliku" sistema, sto bi trebalo da po
stignete opisivanjem parametara sistema, tj. navodenjem cilja i opsega siste
ma, projektnih uslova i mazda - kratkag pregleda radnih procesa,
Ne maze se reCi mnago toga 0 predstavljanju cilja i opsega sistema. Ako
ste ih razumeli, opisite ih izrazima koje vasa ciljna grupa moze da razume.
Ako ih niste razumeli, vratite se na njih i pokusajte da ih shvatite.
Ponovo, preporucujem yam da budete sto izricitiji 0 oblastima koje su is
kijucene iz opsega sistema, sto vazi i za one koje ce kasnije mozda ipak biti
realizovane. Navedite sve sto moze naknadno biti ukljuceno u sistem, cak i
ako ste se zasad opredelili da odredenu oblast iskljucite iz opsega sistema.
Posvetite izvesno vreme identifikovanju oblasti za koje vi mislite da bi se
mogle ukljuCiti u sistem, ali koje nisu ~ikad bile izricito razmatrane. Ovo je
mesto i vreme da se uverite da i vi i vas klijent radite sa istim pretpostavkama.
Ako ste pripremili analizu troskova i dobitaka sistema, trebalo bi da je
ukljucite u ovaj dokument, ali ne obavezno u ovaj odeljak. To je pitanje stila,
ali Hcno ne volim da u glavni dokument umecern stranice i stranice pune ta
bela. Dokument je znatno Citljiviji ako u glavni dokurnent ukljucite samo
sazete informacije mozda jednu iIi dye tabele - a ostatak srnestite u odgo
varauCi prilog dokumentu.
Isto vazi i za dokumentovanje ciljeva i opsega sistema. Mazda ste pripre
mili detaljnu analizu funkcionalnosti, s pozivanjem na ciljeve i podrSku, koja
je cak i normalizovana po vaznosti ciljeva. To je odlicna aIatka koja ce biti ko
risna tokom izrade celog projekta. Medutim, ako je tabela duza od jedne
stranice, pre spada u prilog nego u glavni tekst. U glavni dokument ukljucite
samo saZetu tabelu s tekstualnim opisom i uputite citaoca na odgovarajuci
prilog ako zeli vise detalja.

Radni procesi
Najbolji nacin da predstavite radne procese sistema zavisi od oblika u kome
ste ih vi zabelezili za sebe. Ako ste upotrebili hijerarhijski format, mozete ga
umetnuti u tekst. Ako ste pripremili dijagrame radnih procesa, kOlisno je da
i njih umetnete u dokument. Nemojte pri tome zaboraviti da dodate i obja
snjenje simbola koje ste koristili. U oba slucaja, obavezno objasnite 5ta pod
razumevate pod recima "proces", "posao" i "aktivnost" (iii drugim recima
koje koristite).

Bez obzira nn oblik 11 kome opisujete radne procese, dodajte i opis ohic
nim recima. Prvo, tekstualni opis je provera formalnog upisa. Zac'ucllljllCe je
koliko ('etc malih gresaka otkriti nn taj naCin.
Drugo, oc1 kljucne je vaznosti cia klijent ispita tac;nost opisa ndnih pro
cesa, a iskllstvo mi kaze da Ijudi hijerarhijske prikaze i dijagrame vise gledajll
nego stu ih zaista razumeju. Ako date i graficku i tekstualnll verziju, pocl
sticete Citaoce cia ih bolje razumeju, a oba oblika predstavljanja infonnncijel
doprinose boljem razumevanju i jednog i drugog.
Ako predlazete izrnene radnih procesa, dodajte i tekucu i nOVll verziju, i
istaknite izmene u tekstllalnoj verziji. RaZllme se, morate objasniti zbog cega
ce izmene koje predlazete poboljsati tok rada ili resiti odredene probleme.
Ukoliko dodate eksplicitno objasnjenje izmena koje prec1lazete, cesto cete
ustanoviti da ce k1ijent ukazati na nesto sto ste II p1'vobitnoj analizi prevideli.
Dokumentovanje radnih procesa jedna je od oblasti u kojoj se sukoblja
vaju potrebe raziicitih kategOlija vasih ciljnih gmpn. Razvojni tim ocekllje opi
se izrazene tehnickim jezikom: transakcije se potvrduju a objekti podataka
aZllriraju. S druge strane, k1ijenti ocekuju da proces bude opisan izrazima koje
oni kOliste. To mogu biti i racunarski izrazi, ali je verovatnije da neee biti.
Kada niste sigurni, budite bliZe klijentovoj stnmi. U praksi, verovatnije
je da ce za razvojni tim biti znatno manji napor da razumeju klijentove izraze
nego obrnuto. Ako bas l110rate da koristite tehnicke izraze, obavezno ih tac
no clefiniSite u dokumentu.
Nazalost, to je lakse reCi
uraditi. Kada se celo vreme bavite racuna
rima, !ako je zaboraviti da
od izraza iz te oblasti nisu llobicajeni i izvan
nje. Ja imam spisak izraza kao sto su "transakcija", pa cak i ,.polje" i obavljam
zavdnu proveru pre nego sto dokument clostavim klijentu. To nije tesko ura
diti pomocu funkcije za pronalazenje zadatih reCi u programu za obradu
sta. Zbunjeni klijenti rnalo kad su i s1'ecni klijenti.

.onceptualni model podataka

Kada zavrsite pocetnu analizu sistema, verovatno cete imati E/R clijagrame,
spisak domena kOji se kOliste u sistemu i nekoliko belezaka 0 uslovima za
podatke. Nije tesko organizovati te informacije U oblik u kame se mogll pred
staviti Idijentu. Analiza entiteta, mozda ilustrovana odgovarajllcim E/H clija
gramom za slozene entitete, odgovara kao oblik dokumentovanja modela.
Obicno prilazem analizu domena kao neku vrstu recnika u zasebnom odelj
ku, kOji se referencira iz samog modela.

On) .ie jedno ocl mesta gclc su stranicc i stmnice tabela \erovlltno neiz
beine. Ne 1110:l.e se izhec-i cinjenica da u pitanju izrazito tchnicka cliskmi
ja, ali i jeclna od onih koje klijcnt ne 1110Z(; da zaobicle. Mozcte se S<11110
nadati da ce postupak biti !ito bezbolniji za njegcl.
Prvo, koristite sto manje tehnickih izraza. "Tabela", "polje" i "zapis" ver
ovatno S1..1 neizbezni, ali je bolje izbegavati "entitet", "relacija" i "atribut".
Znam da su manje tehnicki izrazi i l1lanje precizni, ali su ipak dovoljno bliski.
Osim toga, obavezno definisite znacenje svakog izraza koji upotrebite (pri
eemu je pozeljno da korisnicima ne odrzite kratak kurs projektovanja baza
podataka).
U praksi, problem i nije tako tezal<. Posto objasnite da svaka tabela pred
stavlja neku "stvar", a polja su "delovi infonnacije", kl~ienti su obieno sprem
ni za dalja objasnjenja. Mozda ce vas poneko zapitati zasto telefonske
brojeve obradujete kao tekst ili postaviti 11eko slieno pitanje, ali na tak-va pi
tanja radije ocigovaram u nefol"ma1nom razgovoru.
Ako dokument ima dvostruku namenu, tj. sluzi i kao tehnieka specifika
cija, moracete da u njega ukljuCite sve tehnieke detalje kOji su potrebni raz
vojnom timu. Tu vrstu detalja pokusavam da predstavim odvojeno od
glavnih tabela, obieno kao podnaslov odeljka 0 entitetu. Klijenti tako vrlo
brzo shvate da nema potrebe da razumeju i "te sl:vari". U takvim situacijmna
obicno napominjem svojim klijentima da treba da pogledaju listu atributa
radi opsteg razumevanja, kao i analizu domena radi tacnosti, a ostatak
mogu da zanemare.
TeOlijski, trebalo bi da klijent prouCi i veze izmec1u entiteta, ali u praksi
mi se retko desavalo da klijenti uoee greske iIi neslaganja u toj oblasti, pa i to
samo bd smo zajedno proueavali model. To je ipak malo previse nepoznata
oblast za njih.
Bicete bolje srece ako zahtevate da korisniei ispitaju velicine polja i tipo
ve podataka u njima. lpak, i u toj oblasti, ako imate ozbiIjne dileme, bezbed
nije je da se sa odgovarajuCim ljudima dogovorite za sastanak na kome cete
zajednield resiti problem.
Lieno smatram da je to veoma zamorno - sati razglabanja tipa "Sta mi
slite, da Ii je 2S znakova zaista dovoljno za Prezime?" tesko moze biti ono sto
ja zovem dobrim provodom - ali posto je kljucno da te stvari budu ispravne,
cesto je neizbezno.
Druga mogucnost je da ukazete na elemente koji yam se cine problema
ticnim. Posto paznja ljudi opada kada moraju da pregledaju SO stranica s tabe
lama, ako ukazete na elemente za koje yam treba njihova potvrda, verovatno
cete dobiti bolje rezultate.

iema baze podataka

lnfcmnacije sadriane u semi baze p()(lat<lka kljucne su za razvojni tim, ali po
sto ona sadrii malo dodatnih informacija, za klijenta je prakticno bezvredna.
Ako ne pripremate zasebne dokumente, specifikacije tabela i upita navedite
u plilogu. Specifikacije arhitekture podataka i zastite mora da odobli klijent.
Dirnenzionalne baze podataka mogu biti izuzetak od pravila "sa1110 za
projektHnte". Kao sto smo videli II drugom delu knjige, modeli podataka za
dimenzionHlne baze zavise od produkcionih baza iz kOjih su izvedeni njihovi
podaci. Klijenti ce verovatno zeleti da obavezno potvrde izvore podataka, a
sigurno ce biti potrebno da im opisete kako ce podaci biti izvedeni, kao i uti
eaj kOji stavljanje dimenzionalne baze podataka u redoVllu upotrebu ima na
produkcioni sistem ili sisteme.
Bez obzira na vrstu sistema koji pravim, arhitektnm podataka obicno do
kumentujem pomocu kombinacije dijagrama i tekstualnog opisa. To je jos
jedan slucaj kada dva oblika predstavljanja informacija pojacavaju jedan dru
gog. Bezbednosni zahtevi mogu se dokumentovati pomocu jednostavnog
tekstuainog opisa, ali je ponekad hijerarhijska skica iIi slika kori5na ako je u
pitanju slozena bezbednosna stmktura.

~orisnicki

interfejs

Korisno je da pripremite skicu dokumcnta 0 korisnickom interfejsu koji cete

razmotriti zajedno s klijentom pre nego sto predete na projektovanje samog
interfejsa, koje je opisano u preostalom delu ove knjige. Medlltim, u malim
sistemima, praviti skicu dokumenta za tu namenu moze nepotrebno da
odiozi postupak projektovanja.
Cak i ako nemate nameru da formalno projektujete korisnicki interfejs,
cesto je korisno da pripremite nekoliko primera ekrana koje cete oznaciti sa
"UZORAK" ili "PRIMER". Takvi plimeri izgleda ekrana mogu pomoCi bu
ducim korisnicima da steknu sliku 0 radu prediozenog sistema. Ipak, budite
oprezni. Bez obzira na to koliko cesto isticete da su to samo uzorci izgleda
ekrana kOji u konacnoj verziji sistema mogu biti drugaciji, oni neizbezno for
miraju ocekivanja korisnika. Ako se konacna verzija sistema pl'evi.e razliku
je, sve vase dobre namere mozda su samo zamutile vodu.
Uticaj na ocekivanja korisnika obicno je problem samo ako funkcionalnost
za koju ste dali primer ekrana kasnije bude izbacena iz opsega sistema. lmala
sam korisnike kOji su ocekivali sve ekrane prikazane u prvobitnim zahtevima,

cak iako su kasnije \ideli i odoblili drugaCije specifikacijc koJisniC:kog

iz kojih su neki ekrani bili izbaceni. U takvim situacijarna, izbuccnc
navodirn U odeljku ,,IskJjucena fimkcionalnosf', iH ih opiSem u tckstu. Kratak
opis iskljucene funkcic)]}alnosti i razloga te odluke clodatna su ganmcija da sva
ko zna na cemu je.
Posto definiSete interfejs, treba ela ga predstavite korisnicima, Postoje
dva primarna nacina na koja mozete to obaviti: prototip interfejsa i specifi
kacija interfejsa. Ja gotovo uvek plipremim oba, makar samo zato sto mi je
izrada nefunkcionalnog prototipa najlakSi nacin da pripremim ilustracije na
osnovu kOjih eu strukturirati specifikaciju.

Prototip interfejsa
Ustanovila sam da je prototip interfejsa najbolja alatka za predstavljanje ko
risniekog interfejsa novog sistema. Mnogim korisnicima, narocito onim
puno iskustva s racunarima, tdko je da na osnovu grupe slika ekrana na pa
piru zamisle kako ee sistem izgledati i raditi. Ako im obezbedite prototip in
terfejsa, neee morati da se trude da to zamisle.
Prototipovi se mogu praviti u svim oblicima i veliCinama, i mogu se k01i
stiti za razne namene. Jedan od najjednostavnijih sastoji se od slika ckrana i s
njima povezanih menija (bez programskog koda) koji moeleluju tok rada ko
nacne verzije sistema. Jedini neophodan program ski k6d jeste onaj kOji pove
zuje ekrane. Sve kontrole su na svojim mestima, ali nisu povezane s podacima,
niti na bilo kOji
naein funkcionalne. S!icno tome, jedine komande menija
koje nesto rade jesu one koje prikazuju okvire za d~ialog. (To nije sasvim taeno.
Drugim menijima obicno pridmzujem prozore s porukama tipa "Ova koman
da ee raditi to ito. Ta funkcionalnost nije ugradena u prototip",)
J edini izuzetak od pravila "nema koda" jeste kada je saddaj ekrana odre
den vrednostima podataka, Recimo da ste napravili ehan za unosenje poda
taka 0 kupcu, ali saddaj ekrana zavisi od toga da Ii je kupac fizicko lice iii
firma. Mozete se opredeliti da vidljivost odredenih kontrola bude uslovljena
onim sto korisnik
iz gmpe opcija. Tu funkcionalnost morate obezbe
diti i u prototipu.
Prototip interfejsa obieno pravim pomoeu alatke za programiranje ceo
ne komponente koju ocekujem da ce biti upotrebljena i za izradu konacne
verzije sistema. BuduCi da radim s vise razvojnih okruzenja, na taj nacin iz
begavam sindrom "uh, zaboravila sam da u VB-u ne postoje padajuee liste s
vise kolona".
Medutim, upotreba razvojnog okruzenja je opasna. Posto pravite pro
totip, a ne sistem, prihvatljivo je da iskoristite razne vrste preCica koje inace
ne bi niposto bile prihvatljive u programskom kodu produkcione verzije. Ali,

tesko je oclupreti Se isku!ienju da prototip upotrehitc kao 05nOV1I za izradu

konacne vcrzije sistema.
Na haju l~mjeva, posto su svi ti ehani i meniji vec napravljeni, /':,11' ne hi
bilo gubljenje vremena cla ih ne iskoristite'? Pogrdno. Napravljeni su Slmo
prototifJovi tih ehana i menija. Ako prototip interfejsa upotrebite kao OS110
VlI za izradu konaene verzije sistema, rizikujete da nasledite i preeice koje
ste upotrebili, !ito ce vam se obavezno vratiti kao noena mom.
Zbog te opasnosti, neki projektanti preporueuju izradu prototipa inter
fejsa pomocll neke alatke za crtanje, a ne alatke za programiranje. Na pri
mer, Visio stavlja na raspolaganje ogranicenu podrsku za izradu interfejsa.
KOlistite alntku koja vam najvise odgovara. U mom slueaju, to su alatke
za progrmniranje s kOjima svakodnevno radim. U vase1l1 slucaju, to moze biti
neka alatka za crtanje iIi cak alatka za izradu prezentacija, kao sto je Micro
softov PowerPoint. (Imam klijenta kOji moje slike ehana "pobozno" prenosi
u PowerPoint za svoje interne prezentacije. Ekranima ne dodaje bas nista,
covek prosto voli PowerPoint.) Bitno je da vam bude potpuno jasno sta tac
no radite - u ovoj fazi samo dokllmentujete projekat, ne gradite sistem.

Specifikacija interfejsa
Mada je prototip interfejsa odlicna alatka pomoell koje korisnici stieo sliku
kako ce sistem raditi, njegova funkcionalnost je namerno ogranicena. Iz tog
razloga, on ne moze da zameni specifikaciju interfejsa. (Obmuta tvrdnja nije
tacna. Pazljivo napravljena specifikacija interfejsa moze da Heini prototip
sHvisnim.)
SHcno dokumentaciji rnodela podataka, specifikacija korisnickog inter
fejsa mora da sadrii tehnicke informacije koje klijent ne moze potpuno cla
izbegne. Iste preporuke vaze i u ovom sluCaju tehnicku terminologiju sve
dite na minimum; gde god je moguce, razdvojite tehnicki cleo ko.1i klijent
moze da zanemari od glavnog tela dokumenta.
Ako ste napravili prototip interfejsa, priprema specifikacije interfejsa
vrlo je jednostavna. Ja prilazem rastersku sliku svakog ekrana, tekstualni opis
njegove namene i obrade koja se iz njega pokrece, tabelarni spisak svih kon
trola i izvora podataka za svaku kontrolu (ako postoji). Ako niste napravili
prototip, ekrane morate opisati u nekom drugom obliku, ali peostali deo in
formacija ima isti oblik
U veCini sistema kOlisno je da prilozite i pregled toka rada. Ako sistem
treba da podrzi vise razliCitill raclnih procesa, trebalo bi dodate model redo
sleda ehana za svaki proces. To se radi jednostavno - oznacavanjem na dija
gramima radnih procesa.

Jpravljanje izmenama
Vasa clokumentacijll projekta verovatno c-e doziveti viSe izmena pre nego 'ito
dode u stabilno stanje. Kacla postane relativno stabilna, a svakako pre nego
!ito predete na slec1ec-u taw projekta, trebalo hi del za dokllment (ili grupu
clokumenata) llvedete upravljanje izmenama.
Imajte u vidu da "upravljanje izmenama" nije isto !ito i "zamrzavanje
specifikacije", koje.ie nerealno, cak i II najjednostavnijim sistemima. Ako pri
premite pIan za izmene, koje su neizbezne, dugorocno cete sebi znatno
olaksati zivot.
Upravljanje izmenama moguce je u viSe oblika. Obicno se odupirem
iskusenju da direktno menjam saclrZ<1j dokumenta; umesto toga, ustanovila
sam da .ie lakse da objavljujern beleske 0 izmenama ko.1e sluze kao prilozi
izvornom dokumentu. Ako su izmene veoma znac:ajne, ponekad.ie lakse na
pisati ceo dokument iz pocetka, iii odredene njegove clelove, ali to .ie malo
verovatna situacija.
Ukoliko mozete obezbediti centralnu lokaciju za glavnu specifikaciju,
mozda je opravdano menjati ili dodavati clemente direktno II dokument. To
se radi, na primer, pomocu alatki za reviziju teksta koje prostoje u programi
ma bo sto.ie Microsoftov \Vord, Dokument mozete potom postaviti na jav
ntl lokaciju 11 mrezi iii lla intranet.
Jeclini problem koji se pojavljuje kada dokument postavite na centralnu
lokacijll jeste kako obezbediti cia ljudi rade s tekllcom verzijol11 dokumenta a
ne s kopijmna koje su odstampali da bi na njima mogli da zvrlja.1u svoje napo
mene. Priznajem, i SaIn<l sam kIiva zbog Cinjenja tog "zlocina". Ccsto.

Sazetak
U ovom poglavlju navela sam nekoliko smernica za preclstavljanje projekta
sistema klijentu i razvojnom timu. Mozete ih smatrati misljenjem jednog
projektanta. Opisane strategije su se pokazale kao dobre u mom mdu, ali u
viSe oblasti koje sam opisala trebalo bi da te smernice prilagodite svom
naCinu rada i potrebama svojih klijenata.
lako se ovim poglavljem zavrsava treCi deo knjige, jos nis1110 zavrsili
proucavanje postupka projektovanja baza podataka. U cetvrtom deJu bavi
cemo se izuzetno vaznom komponentom aplikacije: kOlisnickim interfejsom.

esfa!Ja~u!
6o>l~!us!JO>l
afueJ\o~>lafoJd

Korisnicki interfejs
kao posrednik
Kada zavrsite poslove analize opisane u prethodnom delu ove knjige, trebalo
bi cIa dobro razumete sta sistem kOji projektujete treba da radio U cetvrtom
delu bavicemo 5e s nekoliko pitanja 0 kojima treba da vodite racuna kada
pravite korisnicki interfej5 sistema.
Ovo poglavlje poCinjemo razmatranjem opsteg pristupa projektovanju
korisnickog interfejsa i modela kOje treba da upoznate. 1z razumljivih razlo
ga, po tom pitanju mogu yam pruziti samo ogranicenu koliCinu informacija.
Da biste prosirili svoje znanje 0 pro.iektovm~u korisnickog interfejsa, pot
rebno je da prouCite i druge izvo1'e. U bibliografiji sam naveIa viSe odIicnih
knjiga, a sigurno cete naci i druge u knjizari kOja prodaje tehnicku literaturu.

Efikasan interfejs
U glavama korisnika, korisnicki interfejs jeste sistem; sve ostalo 5U stvari koje
oni sa zadovoljstvom zanemaruju. Dizajn korisnickog interfejsa je, prema to
me, kljucan za uspeh iIi neuspeh p1'Ojekta. Ako ga napravite kako treba, ko
risnici ee zaboraviti poneki propust u izvedbi sistema. Ako ga lose napravite,
bice sasvim nevazno koliko je efikasan vas programski k6d.
l1'On1j<:1 cele pIice je to sto ce r~alo ko plimeCivati dobar interfejs. Zaista
elegantni interfejsi su "nevidljivi". Cak i ako je interfejs los, mozda l1iko ni to
nece primetiti. KOlisnicki interfejsi mnogih racunarskib sistema, na1'OCito si
stema koji rade s bazama podataka, toliko Sll nezgrapni, da ee vas sistem biti
samo jos jedan ocl prosecnih, pomalo nametljivih sistema kakve Ijudi i ocekuju.
POl, ako niko nece niSta primetiti, zasto biste se oncla vi trucIili? A zasto
da ne? Na haju krajeva, to je posao kojim se bavite. Uz rizik da zvucim kao
vasa mama, ako se vee bavite projektovanjem racunarskih sistema, nije li 10
gicno da to radite najbolje lito umete?

239

Projektovanje efikasnih korisnickih interf'ejsa ;::.a/ztcu({ viSe posla l1ego

kada sc na hrzinu "skrpi" ceonH komponenta za rael s baZOlll podataka. Efl
kasni interfejsi mogll zahtevati i da ulozite vise trmla da histe ih napravili,
machl to ne mora cia bude uvek tako. Korist moze biti veoma velika, i to ne

oel vrste "vrlina je sama sebi nagmda".

Efikasan interfejs minimizuje vreme koje je korisnicima potrebno da si
stem savlad,~u i pocnu da
koriste. N akon uvodenja sistema u redovnu
llpotrebu, produktivnost korisnika bice veca ako ne moraju cia se bore da bi
sistemu nametnuli svoju volju. Vrlo je verovatno cIa Sll oba pitanja bila llvr
scena meclll ciljeve sistema. Ona svakako llticll na cuveni opsti lltisak 0 pro
jektantu.
Osim toga, efikasni interfejsi kOji se tesno poklapaju sa ocekivanjima ko
risnika i radnim procesima, minimizujll potrebe za spoljnom dokllmentaci
jom, koja je uvek skupa. Dok korisnici lllozda nece ni primecivati koliko je
cudesan vas korisnicki interfejs, nepogresivo ce uociti da vas sistem radi
znatl10 bolje od onog kOji je projektovala firma BaliNasBrigaZaKorisnike
d.o.o. A to moze da lltice na opliti utisak koji ste vi ostavili i koji ce neko uzeti
U obzir kada donosi odlukll 0 110V0111 projektll ili 0 povecanju plate.
Dakle, sta bi bio efikasan korisniCki interfejs? Po mom misljenju, to .ie
onaj koji pomaze korisnicima da obavljaju poslove za koje su zaduzeni, ali je
inace neprimetan. Efikasan interfejs niSta ne namece korisnicima. Nikada
ne primorava korisnika cIa igra po njegovim pravilima, vec sam igra po kori
snikovim pravilima. Efikasan interfejs l1e primorava korisnike da savladaju
gomile nezanimljivih stvari da bi mogli da ga koriste. I najzad, on se nikad l1e
ponasa na neocekivan nann.
U OVOI11 poglavljll razmotricemo navedena tri principa, ali cemo prvo
ukratko prouciti nekoliko modela 0 kOjima vredi da razmislite kaela projek
tujete korisnicki interfejs.

rIIodeli irlterfejsa
Alen Kuper (Alan Cooper), u svojoj cuvenoj kl1jizi About Face: The Essenti
als of User lnteiface Design, opisuje nacin na kOji korisnici razmiSljaju 0 si
stemu (i nacin na kOji sistem razmislja 0 korisnicima), izrazen pomocll tri
modela: mentalni model, prividni model i stvarni model. Ta tri razlicita naci
na razmiSljanja 0 sistcmima vazna su za donosenje odluka 0 korisnickolll
interfejsu aplikacije koju pravite.
Korisnikov mentalni model opisuje sta korisnik misli da se dogada. To
se cesto ne poklapa sa onim sto se zaista dogada, ali to je sasvim u redu. Na

primer, jn imam neki neodrec1eni oseeaj da moje tclo "trosi" hmnu da hi mi

obezbcdilo energiju, na isti nacin kao sto alltomobilski ll}otor "trosi"
Ja znam da su to potPll110 razliciti procesi,
111i to nije vaZno. Ivfonlm da
naspem gorivo II lllOj auto dOl bi on mogao cia radi, kao sto mora111 da llncsem
hranll II svoje telo dOl bi ono moglo da radio Moj mentalni model je saVfseno
prilagoden procesima koji me zanimaju.
Isto vazi i za racunarske sisteme.
obzira na to da Ii koristim pisacu
masinu ili program za obradu teksta> kada pritisnem taster, pojavljuje se od
govarajuci znak. Mentalni model je isti. Ono sto se zaista dogada, fazume se,
potpuno je drugacije. Ono sto se zaista dogada je stvarni model. Sve sto se
odigrava u pozadini i tice se pokretanja polugica iii izvrsavanja programskog
koda sastavni je deo prakticne izvedbe sistema. Korisnike ona ne zanima i ne
bi Ih trebalo primoravati da 0 njoj razmiSljaju.
Korisnicki interfejs je prividni model, koji se nalazi izmedu korisni
kovog mentalnog modela i stvarnog modeia na osnoVll kojegje radio projek
tant. To je, ako se tako moze
model procesa kako
sistem prikazuje
korisniku (iii kako ga korisnik vidi). Vas cilj pri projektovanju korisnickog in
terfejsa jeste da sakrijete sto viSe detalja stvarnog modela. Idealan korisnicki
interfejs potpuno se poklapa s korisnikovim mentalnim modelom. Nije uvek
moguce obezbediti tacno poklapanje s korisnikovim mentalnim modelom,
ali sto mu sc viSe priblizite, to bolje.
Ako vas racunari toliko zanimaju da Citate ovu knjigu, vas mentalni mo
del se ne poklapa s kOlisnikovim mentalnim modelom. Prema mom mental
nom modelu upotrebe program a za obradu teksta, kada pritisnem taster za
znak, u nekom delu RAM mcmorije smesta se odgovarajuca Unicode vred
nost. To nije mnogo blizu stvarnom modeln, ali nema ni mnogo veze s onim
sto misli prosecan kancelarijski sluzbenik.
Tn lezi velika opasnost pri projektovanju korisnickog interfejsa: cak i ako
se direktno ne bavite prakticnom izvedbom sistema, gotovo uvek cete 0
tome nesto znati. Morate razviti naCin da privremeno zaboravite sve sto zna
te 0 prakticnoj izvedbi sistema ili da nadete korisnika kOji eSe biti vase "za
morce" koje ce yam opisati svoj mentalni model.
Najbolje je da pomocu prototipa sistema ispitate nacine upotrebe siste
ma. Mada je to retko kad moguee, korisno je svako istrazivanje nacina upo
trebe sistema. Ako napravite prototip, nadite nekoliko korisnika i pnstite ih
da se "igraju" s njim. Pitajte ih sta misle da se dogada. Bieete iznenadeni od
govOlima. Ako niste napravili prototip, mozete se raspitati za slican sistel11, iIi
izvedite simulaciju na papim. Medutim, s ovom poslednjom tehnikom nisam
imala puno uspeha. Ustanovila sam da korisnike zbunjuje kada im pokazete
na papim i sliku interaktivnog ekrana i izvestaj.

Kada prikupite sto vecu

infi:mn<lcija, utvnlite gdc se stnlrni mo
del (ono 'ito se stvarno dogada) sukobljava s korisnikovim rncntalnim ll1odc
10m i nadite resenje za te oblasti. D,l Ii koristite pogresnu terminologijll'?
Uvck llpotebljavajte iste reci bo i korisnik. Da li korisnike primoravate da
misle 0 "Hzurinmju zapisa" kad oni zapravo zele da "menjaju
To
moze biti terminoloski problem iii problem u strukturi sistema. (Time cemo
se baviti u sledecem poglavljll.)

~ivoi

znanja korisnika
'\Ie mogu da zamislim da bi iko namemo zapoceo da pravi sistem kOji se ne bi
ponasao "plijateljski prema kodsniku". Mozda nacin upotrebe sistema nije
imao visok prioritet, ali niko ne bi namemo napravio sistem kOji zbunjuje ko
Iisnika i otezava mu rael. Problem je u tome sto, buduCi ela.ie "prijateljski
ma korisniku" jedan od onih
i dobronamernih izraza kOji ne znace
mnogo, preostaje yam ela sami smislite ad hok definiciju tog izraza.
Dve definicije izraza "prijateljski prema korisniku" koje se cesto
minju jesu ,,1ako se uci" i ,,1ako se koristi". Ako za trenutak zanemarimo pi
tanje sta je tacno ,,1ako", moramo se zapitati Jako za koga"? Sistem kOji ce
pocetnik lako savlac1ati ne mora obavezno i strucnjaku biti lak za upotrebu.
N ajbolje resenje je da razmotrite potrebe svakog nivoa korisnika i da za svaki
nivo pojedinacno obezbedite drugaciji oblik interfejsa.

Pocetnicki nivo
Svako je nekom trenutku poeetnik. Vrlo malo Ijuc1i ostaje na tom nivou s
poeetnickog nivoa prelaze na srec1nji iii zamenjuju vas sistem nekim drugim.
1z tog razloga, morate voditi racuna da ne ugrac1ite takvu podrsku za pocet
nike koja bi ometala naprednije korisnike.
Pocetnicima je potrebno da znaju !ita vas sistem radi pre nego sto pocnu
da uce kako se on koristi. Tu informaciju najbolje cete im predstaviti izvan
glavnog sistema. U jednostavnim sistemima, moze biti dovoljan uvoc1ni okvir
za dijalog koji opisuje sistem. (U tom slucaju obavezno obezbedite i 1110
gucnost trajnog iskljucivanja tog okvira za dijalog.) U slozenijim sistemima,
mozda ce biti prikladniji vodie kroz sistem.
Sistem za neposrednu pomoc
pogodan za pocetnike. Oni mozda ne
znaju da takav sistem postoji iii, ako znaju, ne znaju kako se koristi. 1pak, ima
1a sam izvesnog uspeha s neposrednim vodiCima kroz aplikaciju, tako sto sam

ll\'oclni okvir 7.<1 c1ijalog i II meni sistema za POlllOC postavila hipcryczu ka

VOCliClL Da bi bili ;r,aista korisni pocetnieima, ti vodici llloraju bib usredsrec1e
ni na opisivanje konkretnih poslova, Poc'etnici ne zele da znaju sta ;r,naci "Shl\'
ka menija"; 11jih zanima kako se izc1,~je rnclln za prodatu robtL
U

Srednji nivo
KOIisnici vecine sistema spadace u kategoriju "sa srednjim nivoo111 znanja",
Ta vrsta korisnika zna sta sistem radi, ali cesto zaboravlja detalje kako se
nesto radio To je gmpa za koju morate obezbediti podrsku neposredno u ko
risnickom interfejsu, 8recom, Microsoftovi standardi za \Vindowsov inter
fejs nude brojne alatke za P01110C toj kategoriji korisnika.
Dobra projektovan sistem menija jedna je od najboljih alatki za poclse
canje korisnika sa srednjim nivoom znanja na mogucnosti sistema. Brz
pregled stavki menija odmah ce ih podsetiti koje su sve [unkcije na raspo
laganju, a istovremeno ce im omoguCiti da zapocnu odgovarajuCi posao.
Odlican dmgi nivo podrske za korisnike sa srednjim nivoom znanja jeste
sis tern za neposrednu pomoc. Nazalost, pisanje sistema za neposrednu po
moc izlazi izvan okvira ove knjige. Mectutim, u tom kontekstu pomenucu da
ce veCina korisnika sa srednjim nivoom znanja koristiti indeks kao svoj pri
marni mehanizam za pristup informacijama u sistemu za pomoc. Zbog toga
preporucljivo da napravite sto detaljniji indeks.

Iskusni korisnici
Iskusni korisnici znaju sta treba da rade i kako da to urade. Njih najviSe zani
ma da posao urade brzo. Sto vise preCica ugradite u sistem, korisnici iz te
grupe bice srecniji. Iskustvo l11i pokazuje sledece: posto iskusni korisnici na
ginju ka upotrebi tastature, treba obavezno omoguCiti upotrebu sistema i
pomocu tastature ako nameravate da obezbedite podrsku i za tu grupu.
Iskusni kOlisnici takode cene mogucnost plilagodavanja mdnog okru
zenja SV0111 ukusu i potrebama. Posto pruzanje takve funkcionalnosti moze
biti skupa vezba, pazljivo razmotIite prednosti te funkcionalnosti pre nego sto
je ugradite. Ako se opredelite da omoguCite odreden nivo prilagodavanja in
terfejsa, l11akar to bilo sarno menjanje rasporeda prozora na eham], obavezno
ugradite mehanizam cuvanja izmena izmedu dye sesije. Nista ne moze iCi na
nerve tako kao kacl vas program plimorava da kad god ga pokrenete, morate
P0J10YO da sve razmestite kako vam treba.

(orisnik treba da bude taj koji komanduje

Neposredno iza stavke "prijateljski prema korisniku", na spisku Jepe ali bes
korisne tenninologije" nalazi
izraz "orijentisan prema korisniku". Stu to
tacna znaci? Za razliku ad izraza "prijateljski prema korisniku", ipak ima
znacenje, mada prilicno neodreaeno. Sistem je orijentisan prema korisnikll
ukoliko se uvek odaziva na korisnikove zahteve i nikad ne namece specifican
metod rada.
Taj plincip cete mozda najlakse razumeti pomoeu primera. Jedan 1110j
poznanik, projektant koga veoma postujem, opisao je svoj metod primora
vanja korisnika da podatke unose redosledom koji je najpogodniji za sistem.
On zakljucava sve kontrole na obrascu osim prve; kada kOlisnik unese podat
ke u tu kontrolu, on otkljucava drugu kontrolu, zatim trecu itd.
Ne samo sto je ta tehnika sve samo ne orijentisana prema korisniku, vee
na duzi rok daje pogresne rezultate. Zapravo me cudi to sto na kraCi rok cak
i izgleda da radi kako treba. Korisnici cesto imaju opravdane razloge sto ne
unose podatke unapred zadatim redosledom. Mozda je odredeni podatak
nepoznat, iIi prosto korisniku jos nije zgodno da ga unese.
Ako korisnike prisiljavate da nesto unesu, oni ee to i ciniti. Unosice sva
ko smece koje ce sistem prihvatiti. Posto ste ih prisilili da nesto unose, l1speli
ste samo da ih naljutite i da se pokazate kao nametljivi, a konaecm rezllltat je
da niste postigli niSta korisno. To pitanje cemo detaljnije razmotriti u pogla
vljl1 19, kada blldemo razmatrali integritet podataka.
Vestacko nametanje integriteta podataka plimami je nacin na kOji sistemi
koji rade s bazama podataka pokusavaju da prellzmu kontrolu od korisnika.
Drugi naCin je nellmerena primena modalnosti. Rezim rada (engl. mode) je
stanje sistema koje ogranicava sta kOlisnik sme da uradi. Klasicni rezimi rada
u sistemima kOji rade s bazama podataka jesu dodavanje novih podataka,
aZllriranje i prikazivanje postojeCih podataka. Sistem kOji zahteva od korisni
ka da se vrate II glavni meni kako bi mogli da pocnll da azuriraju odreaeni
zapis, smesno je neefikasan. Nije mnogo bolje ni zahtevati od njih da pre azu
riranja podataka izaberu odgovarajucu stavkll menija iIi pritisnu dugme.
Nazalost, mnogi projektanti standardno primenjuju tu vrstu modalnosti.
Mozda kao pogreSan pokllsaj zastite korisnika od nenamemih izrnena, iIi
zato sto je pre dvadesetak godina, upotreba stavki Add (Dodaj), Edit (Azuri
raj) i View (Prikazi) bila uobicajena, oni nastavljajll s tim modelom pod Win
dowsom, gde je neprikladan. Toplo yam preporucujem da llvek polazite od
pretpostavke da korisnici znaju sta rade. (Svesna sam da je ovo sokantan
predlog, ali verujte mL Sto je .ios vaznije, verujte njima.) Ako korisnik hoee
da izmeni sadrzaj zapisa, pustite ga da to uradi. Niko ne treba da trazi dozvo
lu da radi svoj posao.

se

Hazume se, ako korisnicimC1 dozvolite toliku "loboelu, morate im

zbecliti i sigurnosne mreze. Nije tesko llapraviti viSe nivoa poniStavanja naci
njenih izmena. tvIozete cak i napmviti opciju menija "Vratiti staro shmje" da
biste korisniku omoguCiIi cla ponisti sve izmene tekuceg zapisa.
Na osnovu iste teOJije, ne voHm ni cla zelhtevam oel korisnika cia potvrde
izmene pre nego !ito zapis snime u bazu poclataka, mada U oclredenim situaci
jama to moze biti opravclano. Cela ideja "snimanja podataka u bazu" tuc1a
veCini korisnika. Imajte u vidu korisnikov mentalni model. Upravo su izmeni
Ii podatke, a vi ih sada pitate zele Ii da ih izmene.
Ta vrsta poruka 0 potvrdivanju izmena jos je jedan plimer nametljivosti
bez
naroeite svrhe. Kada shvate 5ta "snimiti podatke" zapravo znaci,
posto veCina Ijudi stekne naviku da uvek bira "OK" kad god se pojavi okvir
za dijalog sa zahtevom da potvrde izmenu, taj okvir za dijalog nije narocito
koristan.
U nekoliko retkih slucajeva kada sam ugradila poruke za potvrdivanje iz
mena (obicno na izriCit zahtev klijenta), ugradila sam i mehanizam za njiho
vo isldjucivanje (obicno u okviru za dijalog Properties).
Medutim, neke opsezne izmene ne mogu se poniStiti, iii barem ne na
jednostavan naein. Nenamerna izmena sadrzaja polja u zapisu lako se moze
ispraviti. Ali to nije moguee ako ko1'isnik slucajno izbriSe sve zapise iz tabele.
Ukoliko korisnicima clozvolite da rade stvari koje smatrate zaista opasnim,
najbolje je da im obezbedite i naCin da poniSte tu akciju. Ako to nije izvo
dljivo, svakako zahtevajte da potvrde akciju.
Odredite sa1110 razumnu definiciju "zaista opasnog" i pruzite korisnici
ma upotrebljive informacije 0 posledicama njihovih akcija. Poruka sa slike
15-1 samo ce ih zaplasiti.

Slika 15-1 Ovo je spektakularno beskorisna poruka

Znatno je bolja poruka prikazana na slid 15-2. Mozda nije izuzetna, ali
bolja. Ne samo sto objasnjava situaciju recima koje korisnik razume, vee
mu i pl1Jza opdje drugacije od obicnog 0 K i Cancel (koje prose can korisnik
tumaCi kao "Ja sam idiot", odnosno "Ja sam idiot. Prihvatite moje najiskreni
je izvinjenje".)

You have changed the name of the customer. Since other iterns in the system,
such as Sales Orders, rely on the custorner name to maintain their links, this may
cause some items to get lost,
You have the following options:
Clicking this button will return the customer name to its original value,
Clicking this button will change the customer's narne in all other
records that referenoe it. This operation might take some time.
Clicking this button will change the customer name, but not
any other records that might reference it.

Slika 15-2 Ova poruka objasnjava posledice korisnikovih akcija i nudi vise
opcija

"inimizovanje umnog napora

qudsko pamcenje nije narocito dobro, sto je jedan od razloga zbog koji11 ko
ristimo racunare. 1z toga sledi da dobar interfejs ne zahteva od kOlisnika da
pamte vise stvari nego !ito je zaista potrehno. Razume se, oni ce morati da
nauce (i zapamte) !ita vas sistem radio Morace da zapamte i odredene stvari 0
nacinu upotrebe sistema. Ali trebalo bi da, kad god je to moguce, minimizuje
te koliCinu informacija koje korisnici treba da zapamte.
Jedno od re!ienja je da interfejs projektujete u skladu s Windowsovim
standardima i konvencijama za korisnicki interfejs. Dokument vVindows In
terface Guidelines for Software Design opisuje jedan skup konvencija. Retko
kada cete imati razlog da menjate te konvencije, a ako to i cinite, ne bi treba
10 da postupate proizvoljno. Aplikacije iz Microsoftovog paketa Offlce pr
venstveno, Access postavljaju dmge de fakto standarde. Ako ne postujete
standarde, Cinite to iz opravdanih razloga. U suprotnom, korisnicima vero
vatno necete UCilliti uslugu.
Mozda smatrate da su navigacione kontrole koje ste vi napravili :::.natno
zanimljivije od standardnih Accessovih video dugmadi. Ali imajte milosti
prema jadnim korisnicima. Oni su nauCili da pritisnu dugme "Play" kada
pozele da predu na nov zapis. A sad ih vi primoravate da zapamte da u v([.sem
programu moraju da pritisnu onu neverovatno "slatku" fotografiju vase I11<1C
ke i njenih maCica.
Naravno, Windowsove preporuke za korisnicki interfejs vrede koliko
vrede i ne pobivaju sve situacije. Ali najcesce cete m06 da se nadovezete na

opste smcrniee tIn biste pokrili specifican slucaj kOji obrac1ujete. Ako 1110rak
smni da clonesctc odredene odluke, onda se dosledno pridrzavajte. lJ na
rec1nom odeljku bite reci 0 tome koliko je vazno da uvek buclete closledni.
Trebalo bi cia vum bucle jasno sleclete: ako pokllsate cIa smanjite koliCinu
in[ormaeija koje korisllici treba da zapamte, ne bi trebalo ni cIa ih pri tome
primoravate cIa iste podatke unose cIvaput. Vee bilo reCi 0 upotrebi podra
zumevanih i pon1..1denih vrednosti 1..1 takvim situacijama. Osim toga, ako kori
snik mora da radi s nizom ekrana koji slede jedan dr1..1gom, trebalo bi da
omogu6te da se potrebni podaei prenose s jednog obrasca na drugi.
Dalje, ne bi trebalo da od kOlisnika zahtevate da rucno 1..1nose podatke
kOji se, 1..1 raz1..1mnim granicama, l110g1..1 izabrati s neke liste. RaC1..1nari su po
znati po netolerantnosti, ali ne bi trebalo da korisnici brinu 0 tome da li za
pis 0 Petru Pelieu unet kao "Petar Pelic",
. PeriC" iii "P. N. PeriC'.
Medutim, obratite paznju na to da sam rekla "u razumnim granicama". Zah
tevati od korisnika da saceka da sistem popuni padajueu listu sa 6,5.000 zapisa
sve je samo ne razumno. Ono sto bi bilo razumno jeste da kOlisnicima pruzite
nacin da mtriraju listu i da zatim izaberu odgovarajuee podatke iz podskupa s
kOjim se lako moze raditi.
Kada korisnicima stavljate na raspolaganje Iiste necega, dodajte $to viSe
dopunskih podataka, narocito ako stavke na listi nisu obavezno jedinstvene.
Ne bi trebalo da korisnike obavezujete da pamte da je "Mile Simic" on<lj sto
zivi u Valjevu, dok "Milan Simic" zivi u Novom Sadu. Accessove obicne i
padajuce liste omogucav<~iu prikazivaje podataka u viSe kolona. U Visual Ba
sicu, mozete nadovezati odgovarajuce elemente.
U oba okruzenja, razl110trite mogucnost pIikazivanja dopunskih podataka
pomocu menija zavisnog od konteksta. Tehnicki, trebalo bi da se ti podaei pri
kazuju izdavanjem odgovarajuce komande, npr. "Detalji", u kontekstnolll me
niju. (Imajte u vidu da ta stavka menija ne treba da saddi tIi tacke, cak i ako
otvara okvir za dijalog. Dodavanje tri tacke je cesta greska.) Medutim, ako je
bro] dopunskih podataka vrlo mali, mozda cete moCi da ih prikazete direktno
kao stavke kontekstnog menija. Tako ce kOlisnici ustedeti malo vremena.
I najzad, nemojte nikada prisiljavati kOlisnike da pamte zapetljane siste
me sifrovanja. Mozda koristite brojeve koje sistem genelise da biste obezbe
dili jedinstvenost zapisa, ali u veCini slucajeva ne bi trebalo da korisnici
uopste znaju da se to dogada. Ako generisani broj nema nikakvu objektivnu
upotrebu, kao sto je broj rac1..1na, nemojte
cak ni prikazivati.
Mnoge organizacije prave liste skracenica koje predstavljaju stvari kao
sto su kategorije proizvoda iIi prodajne regije. Pravilo koje ja primenjujem
kada treba da odlucim da Ii da te skracenice koristim u sistemu jeste da Ii se
one kOliste u ne[ormalnim razgovOlima. Bolje izbegavajte situacije u kOji111a

ljucli pric~(!jil 0 "sportskoj obuCi" ali momju c1a 11l10Se .,SO", Samo ako skrace
oncIa se onu 1110Y,e koristiti i
nicu "SO" koriste i II mectusobnim razgm'orima,
e,
u sistemu, Pa cak i 11 tom sillcaju, verovatno bih u poije za vrstu robe cloz\'o
lilia unosenje i "SO" i "sportska obuca",

Vazna je doslednost
Doslednost u kolisnickom interfejsu znaCi vise od toga da se isti meniji uvek
nalaze na istim mestima. Trebalo bi da nacin n<1 kOji sistem komunicira s ko
risnieima takode bude dosledan. Kada projektujete sistem kOji radi s bazama
podataka, trebalo bi da obratite paznju na sledece tri oblasti: kako korisnici
prelaze s jednog zapisa u tabeli na drugi, koliko su slozeni predstavljeni enti
teti i kako korisnid zapoCinju azuriranje postojeCih zapisa i unosenje novih.
U vecini sistema postoji niz obrazaca kOji predstavljaju najvaZnije entitete
u sistemu, Na primer, mozete imati obrazac Kupd, obrazac Altikli i obrazac
NalUdzbenica, Morate smisliti nacin na koji ce se korisnid kretati po skupo
vima zapisa kOji su iZVOli podataka za te obrasce. Ukoliko nemate vrio oprav
dan razlog za upotrebu razlicitih mehanizama, trebalo bi da odaberete jedan
metod ida ga koristite u svakom obrascu.
Podrazumevani naCin u Access'll i u Visual Basic'll jeste da vezani obrasd
prikazuju sadrZHj prvog zapisa iz izvornog skupa zapisa i sadrze navigadonu
dugmad koja korisnicima omogucavaju kretanje kroz skup zapisa, Iz raznih
razloga, mozete se opredeliti da izmenite taj standardni interfejs. Na primer,
mozete prikazivati sadrZaj jednog zapisa i ugraditi neki drugi mehanizam za
biranje zapisa koji ce biti prikazan mozda zaseban obrazac kOji o111oguCava
trazenje podataka Hi padajucu listu s koje korisnik moze da izabere zapis. N a
slici 15-3 prikazan je primer ove druge tehnike, preuzet iz primera baze
podataka Access Developer Solutions.
Zamena podrazumevanog mehanizma navigacije potpuno je prihvatljiva
- u stvari, cesto postoje sasvim opravdani razlozi da to uradite - ali kada se
opredelite za jedan od njih, koristite ga na svim obrascima u SV0111 sistemu.
Nepotrebno je i zbunjuje korisnike kada na obrascu Kupd imate standardnu
navigacionu dugmad, na obrascu Narudzbenica imate dugme "Trazi narudz
bin'll", a podaci na obrascu Artikli prikazuju se u tabelarnom obliku.
Izuzetak od ovog pravila je slucaj kada imate viSe kategorija obrazaca,
Na primer, mozete se opredeliti da se obrasd za oddavanje referentnih ta
bela kOliste drugaCije od onih za unosenje primarnih entiteta. U tom sluca
ju, ako je interfejs dosledan u svakoj kategoriji, l1e opterecujete korisnike
bez potrebe.

Druga ohlast u kojoj treba ela buclete doslcelni jeste preelstavljanjc slozl'
nih entiteta. Ako imatc entitete koji su moclelovani pomol-u vise oel jeelnc ta
bele u vezi tipa "jedan prema vise" (Porudzbina je klasican primer toga),
oblik u kojem ill predstavljate korisnicima mora biti dosledan. Nemojtc pred
stavljati stavke porudzbine u obliku tabele, a imena kupaca u oblikll Iiste.

Select Category:

,V;

Select Product:

,,~,;

Product ID:
Product Name:
Supplier:

.'1'

Category:

,v,

Quantity Per Unit:

Unit Price:

Units In Stock:

Units On Order:

Reorder Level:

o Discontinued
Slika 15-3 Padajuca lista moze ponekad biti koristan mehanizam kojim
korisnici biraju klijenta, ali morate ga dosledno koristiti

Nazalost u ovoj oblasti teze je odrZati doslednost, naroeito ako su u pi

tanju vise od dva skupa zapisa. Obrazac na kome jedan tabelarni prikaz sluzi
za imena kupaca, drugi za adrese, a treCi za kupljenu robu, moze postati pri
lieno ruzan. U takvim situacijama morate biti inovativni. Na primer, posta
vite svaki tabelarni prikaz na zasebnu karticu grupe kartica iii upotrebite
iskaeuce obrasce na kOjima ce biti tabelami prikazi. Mozda cete morati da se
opredelite za elva naCina prikazivanja ida ih se !ito doslednije pridrZavate.
Poslednja oblast u kojoj treba da vodite racuna 0 doslednosti jeste meha
nizam za unosenje novih zapisa i aZUliranje postojeCih, kOji mora biti apsolut
no dosledan i ujednacen u celom sistemu. Ako jedan obrazac omogueava
direktno aZUliranje prikazanih podataka, dok dmgi zahteva da korisnik ekspli
citno prec1e u rezim azuriranja tako sto plitisne dugme Azuriranje iii izabere
odgovarajucu stavku iz menija, u mkama imate pravi zbunjivac kOlisnika. Po
sebni rezimi aZUliranja uglavnom nisu preporucljivi, kao sto smo vee videli.
Ponekad postoje opravdani razlozi za zakljueavanje zapisa - tj. zabranji
vanje neposrednog azuriranja - nakon snimanja u bazu podataka. N a primer,
mozete dozvoliti korisnicima da menjaju porudzbine samo dok rob a nije

dostavljcn<l, posle
poruclzbin<l postaje istorijski zapis kOji se 11(:' mo7.e
menjati. Neki projektanti ugntctuju l11eh<111i7.<1111 koji, kacla koris11ik zahtc\'<l
azuriranje zapisa, proverava chi li je roba iz pormlzbinc isporucena. To je
(jedva) prihvatljivo sarno ako se sui abrasei tako ponasaju.
Bolje resenje je da dozvolite azuriranje clirektno na obraseu ali da ZCl
kljucat~ sva polJa ~brasca aka prikazuje p~rnclzbinu za koju je roba isporu
cena. Takvo ponasanje obrasca zahteva viSe posh, ali posto ga obavlja sistem,
to se nc racuna. Osim toga, omogucava da se direktno azuriranje poclataka
primeni i u preostalom delu sistema, gcle zakljucavanje istorijskih zapisa nije
potrebno.

;azetak
U OVOI11 poglavlju, razmotrili smo neke principe koji vaze pri projektovanju
korisnickih interfejsa. Najpre smo proucili tri modela interfejsa: korisnikov
mentalni model sisterna (sta on misli da se dogada), stvarni model sistema
(!ita se zaista dogada) i prividni model (5ta sistem prikazuje korisnicima da se
dogada).
Potom Sl110 razmotlili hi kategOlije kOlisnika: pocetnike, sa srednjim
nivool11 znanja i iskusne. Ukratko 51110 opisali posebne zahteve koji vaze za sva
ku kategOliju i kako te zahteve moze najbolje da ispuni kOlisnicki interfejs. I
najzad, razmotIili smo hi najvaznija pravila za projektovanje kOlisnickog inter
fejsa: prepustiti komandu kOlisniku, minimizovati umni napor i biti closledan.
U sledecem poglavlju proucicemo opstu arhitekturu sistema i bavicemo
se prakticnijim problemima pri projektovanju korisnickog interfejsa.

Arhitekture korisnickog
interfejsa
Kada pocnete da projektujete korisnicki interfejs novog sistema, prvo mora
te da odluCite kako cete strukturirati opsti interfejs sistema - tj. arhitekturu
korisnickog interfejsa. U ovom poglavlju razmotricemo nekoliko manje
viSe standardnih arbitektura koje su opisane u knjizi The l.Vindows 1l1te/face
G1lidelines for Software Design, a realizovane su u viSe popularnih softver
skih paketa.
Mozete smisliti i vlastitu arhitekturu korisnickog interfejsa, ali kao i uvek
kada se udaljujete od postojeCih standarda, trebalo bi da imate opravdan ra
zlog da to cinite. Imajte u vidu da doslednost, ne samo unutar aplikacija,
nego i izmeelu njih, korisnicima olaksava zivot.

Podrska za radne procese

Najvazniji princip pri odlucivanju 0 tome kako cete strukturirati interfejs je
ste sledeCi: vaS izbor treba da se zasniva na radnim procesima koje sistem
podrzava, a ne na strukturi podataka. ProuCite ono sto korisnici pokusavaju
da postignu i strukturirajte sistem taka da podrzava te aktivnosti.
Lako mozete
sledecu gresku: posto na E/R dijagramu sistema
imate entitet nazvan "Kupcr', pravite obrazac Kupci kOji omogucava unose
nje i azminmje zapisa 0 kupcima. Zatim pravite obrazac Porudzbine koji Citn
podatke iz tabele Kupci. U zelji da napravite sistem kOji ce biti "prijateljski
nastrojen prema korisniku", omogucavate korisnicimi:l da biraju ime Impca
sa ponudene liste i na osnovl1 tog izbora automatski popunjavate ostala polja
na obraseu podacima iz tabele KupeL Vas obrazae moze biti nalik onome na
iz ogledne baze podataka Northwind.
slici 16-1, koji je

251

Siika 16-1 Obrazac Orders (porudzbine) iz baze podataka Northwind

To nije tako los obrazac sam po 5ebi, ali pomislite na posao kOji korisnik
obavlja: unosenje porudzbine. Sta ako on otvOli obrazac Porudzbine i otkrije
da kupac jos ne postoji u sistemu? Korisnik mora da napusti taj obrazac, da
prede u neki drugi deo sistema i tamo unese novog kupca, zatim da ponovo
otvori obrazac Porudzbine i da najzad pocne da unosi porudzbinu. Ako obra
zac Porudzbine nije bio zatvoren, korisnik ce verovatno morati da se seb da
plitisne Shift+F9 (ili nesto podjednako oCigledno) da hi osvezio sadrzaj liste
kupaca. Nezgodno.
Neki pl'Ojektanti resavaju taj problem pomocu dogadaja NotInList pa
dajuce liste, omogucavajuci tako kolisnicima da unesu ime novog kupca.
U programskom kodu koji obraduje taj dogadaj, ti projektanti prikazuju po
ruku s pitanjem da Ii treba dodati novog kupca, pa ako korisnik odgovori
potvrdno, otvara se obrazac Kupci.
To resenje stedi korisniku nekoliko pritisaka na tastere, ali ga ipak prisi
ljava da prekine ono sto je do tog trenutka radio (unosenje porudzbine) i da
prede na nesto drugo (odrZavanje liste kupaca). Bilo bi znatno bolje kada bi
kOlisnik mogao da zavrsi tekuci posao bez prel--idanja. Ako korisnik unese ime
kupca kojeg nema na listi, polja koja bi inace bila popunjena, bice prazna.
(Uzgred, to je sasvim dovoljan pokazatelj da je u pitanju nov kupac; nema
razloga da plasite Ijude aktiviranjem zvucnog signala i prikazivanjem nepo
trebnih pOluka.) Posto korisnik popuni polja, sistem moze mirno da u pozadi
ni doda zap is 0 novom kupcu.

A];:o se sv,\ polja zapisa 0 kUpCll mogll popuniti podacima unetim nll
obrascu Porndzhine, posao je zavrscn. Ukoliko ilml cloc1atnih polju (sto se c:c
sto descl\a), })lO:'r!a cete se oprecleliti cia pitate korisnika zeli li cia te
doda bela zavrsi unosenje porucIzbine. (Ali nemojte ga to pitati dok ne
zavrsi unosenje poruelzbine nepristojno je prekidati nekoga.) Svoju odluku
treba da zasnivate na okolnostima u kojima se porudzbina unosi - drugim
recima, na radnim procesima.
Ukoliko porudzbinu unosi
pred kOjim stoji novi kupac, nakon
unosenja pOllldzbine pravi je trenutak za unosenje i podataka 0 nov0111 kupcu.
"Buduci da ste vi nas nov kupac, da Ii biste hili ljubazni da nam pruzite
liko dodatnih informacija ... pH Dmga prednost je to sto, ako se dopunski po
dad 0 kupcu (iii harem deo njih) nalaze na obrascu Porudzbine pomoeu kojeg
se unose dlllgi podaci, korisnik
lako da unese i podatke 0 kupcu dok ih
jos ima pred sobom, sto ce ga postedeti kasnijeg "kopanja po papirima.
Ali ako korisnik ima hlpU pomclzbina koje treba da unese a dopunski
podaci 0 kupcima nisu inti pri Illci, on 6e u veCini slucajeva zanemaIiti okvir
za dijalog i nece uneti dopunske podatke. Neprestano zapitkivanje korisnib
Ii da unese podatke koje nema pred sobom nimalo mu ne pomaze, vee
gnjavi. Bolje resenje bi hilo oznacavanje nepotpunih zapisa, koje korisnicima
omogucava da ih lako pronaau kasnije, kada dobiju potrehne podatke.
Mozete pitati korisnike da Ii
preau clirektno 11a odrZavanje poda
taka 0 kupcima (iIi kako god ste to nazvali u svom sistemu) kada
obrazac Porudzbine. Ali cinite to samo ako
pronalazenje i unosenje tih
podataka logican sledeCi korak za osobu koja unosi porudzbine.
H

Arhitekture interfejsa u obliku dokumenata

Arhitekture korisnickih interfejsa mogu se podeliti u dye grupe, u zavisnosti
od toga da Ii aplikacija prikazuje jedan prozor - interfejs s jednim doku
mentom (engl. single document interface, SDI) - ili prikazuje primarni
prozor unutar kojeg se mogu otvoriti drugi prozori - interfejs s vise doku
menata (eng!. multiple docmnent interface, !liDI).
Nijedan stil interfejsa nije sam po sebi bolji od drugog. Oba imaju svoje
prednosti i nedostatke koje ee1110 razmotriti u ovom odeljku. Vas izbor arhi
tekture korisnickog interfejsa treba da se zasniva na radnim procesima koje
sistem podrzavati.

Interfejsi s jednim dokumentom

U interfejsu S jednilll clokumentom (SDI), kao sto biste i ocekivali, korisnil.::
vic1i samo jedan primarni prozor. Mogu se pojavljivati i clodatni okviri za di
jalog koji prikazuju c10clatne poc1atke. SDr resenje je pogodno za sisteme koji
treba cIa odrzavaju jedan logicki entitet (koji u bazi podataka moze biti prec1
stavljen proizvoljnim bojem fizickih tabela). Na primer, za jednostavan si
stem kOji sluzi za odrZavanje podataka 0 zaposlenima, najprildadniji je SDI.
SDr resenje preporucuju prednosti koje 0110 pruZa: posto korisnici vide
samo jedan plimarni prozor, lako mogu da manipulisu njegovim sadrzajem.
Osim toga, uklapa se u pristup zasnovan na modelu dokumenta koji prepo
rucuju Microsoftovi strucnjaci za korisnicki interfejs.
SDr sistemi se lako prave pomoeu Microsoftovog Visual Basica. Nisu di
rektno izvodljivi u Accessu, posto su svi obrasci sadrZani u Accessovom
prozoru. Medutim, mozete postiei utisak SDr sistema ako pri pokretanju
aplikacije maksimirate primami obrazac sistema i uklonite njegovo dugme
za minimizovanje. U Accessu 2000 i u novijim verzijama, mozete zadati i da
Ii se prozor obrasca prikazuje na paleti poslova (engl. task bar). Uz brizljivo
programiranje i upravljanje, sistem koji napravite u Accessu
biti, za
sve prakticne svrhe i namene, SDr aplikacija.
Aplikacije tipa radna sveska

Arhitektura interfejsa u obliku radne

posebna je vrsta sistema SDI.
U radnoj svesci, razni prikazi podataka prikazuju se na karticama unutar jed
nog prozora umesto u zasebnim prozorima. Microsoftov Excel dobar pri
mer radne sveske.
Prednost te arhitekture interfejsa jeste to sto korisnicima pruza bezbe
clan kontekst a pri tome ih ne ogranicava na jedan obrazac. Medutim, moze
biti malo zapetljano realizovati takav interfejs s prihvatljivim vremenom
odziva. rpak, pod uslovom da se problemi performansi rese kako treba u
prakticnoj izvedbi
radna sveska je izuzetno koristan rnodel za pred
stavljanje razlicitih prikaza istog objekta ili plikaza skupova srodnih objekata
kada korisnicima
potrebno da ih medusobno porede.
N a primer, pomocl.l raclne sveske mozete prikazati zbirni izvestaj na jed
nom radnom listu, kruzni dijagram proclaje po kategorijama na drugom i tnt
kasti dijagram ovogodiSnje prodaje na trcem. To su sroclni skupovi podataka,
a i logicno je pretpostaviti da ce korisnici
da pregledaju te
kao
grupu. Ali verovatno im nece biti potrebno cla ih sve gledaju istovremeno
buduci da su to srodni izvestaji, ali nisu direktno uporedivi.

Listovi u radnoj sves('i mogu se porecbti odrcc1eni1l1 korisnim redoslc

Red11lo dn pravite podrskn La rac1ni pro('cs koji se sastoji od \'ise
dinacnih poslova koji sc cesto, ali ne uvek, obnvljaju Ladatim
Svaki posao 1110zete predstaviti jeclnim listom II raclnoj svesci. Hedosled
stova preslikava recloslecl obavljanja poslovtl, pri cemu korisnike ne obavezll
jete da slede taj redosJecl.
S druge strane, radna sveska obic'no
dobar naCin za predstavIjanje
viSe razlicitih raelnih procesa - koji su cesto potPll1l0 razIiCite aktivnosti niti
za predstavljanje podataka kOji ce se neposredno porediti. Imajte II vidu da
je u svakom trenutku vielljiv samo jedan radni list, a ne bi bilo dobro cla
opteretite korisnikovu kratkorocnu memoriju.
dOll!.

Interfejs u Outlookovom stilu

Druga specijalna vrsta arhitekture korisnickog interfejsa jeste ono !ito ja na
zivam "interfejs u Outlookovom stiIu" jer sam ga prvi put videla u Micro
softovom Outlooku. U tom stilu interfejsa, prozor aplikacije poeleIjen je na
elva olma; jedno sadrZi grupu ikonica a elrugo prikazuje saelrzaj elokumenta
(slika 16-2).

mCalendar Microsoft Outlook

Elle.

~dit

Yiew

ealertd;il ~~

\,;,0

1001<;

"1iiii".

"

(:rcll~
T yp,: .'3. 4~de:>tk)fl

actions

91

lsi

161

291

30

10

111

121

1
171

13
14

181

191

Open a Shared Calendar". ".

Mail

mm Calendar
Contacts
:~
. Tasks

h!.:;l~)

;Ir~' :11

81

fa

December 11

Slika 16-2 Outlookov interfejs deli prozor aplikacije na dva okna

20

Dopacla mi se taj stil interfejsa u aplikacijam<l koje poclrzavaju yise md

nih procesa. Pal eta ikonica na levoj strani obe7.beciuje korisnicima
kontekst, a podela palete na panele omogucCl\'a grupisanje ikonica u hlllkcio
nalne skupove.
Nazalost, ni Access ni Visual Basic nemaju standardne kontrole koje hi
omoguCile izradu te vrste interfejsa, uprkos Cinjenici da je l'ealizovan H
Accessovom prozoru Database (slika 16-3) Medutim, kontrole za Outlookov
stil za oba okruzenja mogu se nabaviti kod nezavisnih proizvodaca.

Customer Orders
~

Reports

_.

Sales Analysis Subforml

~ Customer Orders Subform 1

~ Sales Analysis Subform2

Pages

~ Customer Orders Subform2

~ Sales by Vear Dialog

;::z

Macros

,
Ei

- Sales Reports Dialog

~

Modules
Groups

faVorites

Customer phone list

~ Customers

~ Startup

Eli

~ Suppliers

Employees

,
8;i Main Switchboard

ID
Ei
Glii

1111

Orders Subform

Product List

Slika 16-3 Accessov prozor Database korlsti interfejs u Outlookovom stilu

Ako se opl'edelite za tu arhitekturu, dobro bi bilo da korisnicima omo

guCite da sakriju paletu ikonica, kao u Outlooku. Paleta ikonica je dobal' na
vigacioni mehanizam, ali posto korisnik ucita dokument s kOjim zeli da radi,
on se obicno zadrzi na njemu izvesno vreme, a paleta ikonica zauzima drago
cen prostor na ekranu.

Interfejs s vise dokumenata

U veCini sistema kOji rade s bazama podataka kOlisti se neka verzija MDl stila
inteI'fejsa, kOji omoguCava otvaranje viSe prozora potomaka (eng!. child win
dows) unutar jednog primarnog prozora. ProzOli potomci u MDl aplikaeiji
mogu da sadrze razlicite vrste podataka, npr. jedan obrazac moze da prikazuje
kupee, a drugi - pomdZbine. IIi, mogu da predstavljaju razlicite prikaze istih

podatab, npr. jeclan obraz,(C prikazuje poclatke 0 kupeu, a drugi prikazllje iz

\estaj () ukupnoj prodaji tom kupc:u. I najzad, mogll da prikazllju razlicite pri
merke iste vrste podntahl, npr. jedan obrazHe plikazuje podatke 0 Jovanovicu,
dok clrugi plimerak istog obrasca prikazllje poclatke 0 Petrovicu.
Kao i u SDI arhitektumma, MDI aplikacije mogu se strukturirati na viSe
naCina, pogodnih za nlzliCite zahteve. Ovde cemo razl110triti najcesce struk
ture, ali imajte u vidu cla to nisu i jedine konfiguracije, niti iskljuClljll jedna
clrugu.
"Klasicna" MOl arhitektura

Klasicna struktura MDI aplikacija sastoji se od primarnog prozora kOji sadrzi

viSe prozora potomaka ~ iste vrste iii razlicitih vrsta. MDI aplikacije korisne
su u mnogim sitllacijama u kojima je korisnicima potrebno da porede vise
raznih vrsta podataka u istom formatu iii u razlicitim formatima. Meoutim,
MDI aplikacije mogu da zaplase nove korisnike. Malo Ijlldi ce pomisliti da
treba da izaberu "Novo nesto" iz menija Otvaranje kada se nadu pred pro
zorom koji izgleda potpuno prazan.
MDI verzije Microsoftovog Worda (pre Officea 2000) omogucavale su
pokretanje s komandne linije s parametrom (In) da bi se automatski otvorio
prozor s novim dokumentom pri padizanju aplikacije, a lleSto slieno mozete
mzmotriti i za svoju aplikaciju aka se opredelite za tu arhitekturu interfejsa.
Na primer, mozete dodati parametar koji obezbeduje da se otvori obrazac
POllldzbine mdi unosenja podataka.
Obavezno ugradite mehanizam za iskljuCivanje te funkcionalnosti jer
moze da nervira korisnike kojima ne treba. Morate voditi rae una da u prak
ticnoj izvedbi, korisnicima koji odmah zatvore taj prozor ne prikazujete po
ruke 0 greskama nih da, sto bi bilo jos gore, dodajete prazne zapise u bazu
podataka.
N,~iveCi problem sa MDI interfejsom jeste nedoslednost moclela sadrza
vanja (engl. contaimnent model). Roditeljski prozor obieno sadrZi prozore
potomke koji su otvoreni u njemu, ali aplikacija koju on predstavlja ne sadrzi
obavezno objekte preclstavljene u tim prozorima. 'Hlj problem je izrazeniji u
aplikacijama kao sto je Microsoftov Word, gde su dokumenti zapravo objckti
iz sistema datoteka. Aplikacije koje rade s bazama podataka obicno znatno
bolje izoluju korisnika od slozenosti sistema datoteka. Ali cak i jednostavna
aplikacija koja radi s bazom podataka ne uspeva da to postigne u potpunosti.
Na primer, poglcdajte sliku 16--4 iz Accessove baze podataka Northwind.
Pretpostavimo da je korisnik prelazio iz jednog prozora u drugi i da je u svim
tim prozorima izmenio poclatke koje jos nije llpisao II bazll.

Microsoft Aess

,'-'

j)

..J..Qj~

lika :1.6-4 Model sadrzavanja u MDI apllkaciji moze da zbuni korisnike

Ako korisnik izabere opciju

iz menija File, sta ce se dogoditi? Bice
upisane same izmene naCinjene u prozoru Suppliers. Vi znate to jer znate LIn
se opcije 111enija ocInose same na tekllci prozor. Ali da Ii to zna i korisnik? Nije
Ii logicno ocekivati Ja 6e "NortlrvVind", ako l1111 izdate komandu da upise
podatke, upisati sve izmene,
obzira na to gde ste ih sve naCinili?
Knjiga The 1,VindOtvs Interface GUidelinesfor Softu;are Design (davno je
zastarela, ali jos uvek sac1rzi najbolju definiciju konvencija za korisl1icki il1
terfejs) propisuje cla se meniju
moze dodati stavka "Save All" koja snima
u bazll podalclka svc neupisane izmcne u svinl otvurcllilll prozurima. To
ste resenje problema, ali ipak predstavlja same dobar kompromis. Korisnici
i dalje moraju znati do. postoji razlikn izmedu MDI aplikacije i objekata s ko
jima ona radio

Tn razlika je sastami deo moclela realizacijc, ne korisnikoyog nWlltalnog

moclela, a iznenadujuce tdko razll1ll1jiv koncept za njih. Cak i relati\'no is
kllSni korisnici mogu cia pobrkaju sta se gde nalazi. fa .los UH:k brkam koje je
formatiranje smestello c1irektno u dokllment a koje jc smesteno n<1 \\'onlonl
listu stilova, a taj proizvocI vee godinama intenzivno koristim.
Uprkos svemll reeen0111, klasiene MDI aplikacije imajll svoje mesto.
One ostajll najbolje resenje za veCinu aplikacija n kOjima.ie potrebno cIa isto
vremeno bude otvoreno viSe prozora.
Interfejsi

obliku komandne table

Aplikacija Ciji korisnieki interfejs ima oblik komandne table (engL su.;itch
board), pri pokretanju prikazuje centralni obrazac, kao na slici 16-.'5, takocle
iz baze podataka NorthwincL VeCina dugmadi na obrascu UpUClljU na drugc
obrasce iIi izvestaje.

Slika 16-5 Komandna tabla se prikazuje pri pokretanju aplikacije

Posto korisnicki interfejs baza poclataka koje generiSe Accessov earob

njak New Database ima strukturu komandne table, ta struktura je postala
veoma uobicajena za aplikacije razvijene u tom okruzenju. Slieno ponasanje
moze se na jednostavan naCin realizovati i pomocu Visual Basica.
Moram priznati da imam predrasude prema komandnim tablama. :\festo
u njima podseea me na DOS i ostavlja mi uUsak klimavosti. Ne dopada mi 58
ni to !ito naginjll ka stmkturi menija tipa "Trazenje zapisa/Azmiranje zapisal
Stampanje izvestaja", koja tako zamara korisnike.

Medutim, aplikacije s komanclnim tabla111H

cia buclu korisne kacb
imate viSe razlicitih raclnih procesa koje treba cIa poc1rzi ista aplikacija, a ne
zelite da se petljate sa slozenim interfcjsom u OutlookO\'om stiltl, iii kada jc
potrebno cia aplikacija omoguCi otvaranje viSe prozora istovremeno. Koman
dna tabla na najvisem nivou koja sadrzi ciugllle za svaki radni proces elegan
tan je mehanizam za vO(lenje korisnika kroz aplikacijll.
Pri projektovanju aplikacija sa interfejsom U obliku komanclne table
kao i za druge arhitekture korisnickih interfejsa vazno je da voclite racuna
o tome da opcije komandne table budu strukturirane na osnovu radnih pro
cesa, a ne podataka. Trebalo bi da postavite dugme za svaku aktivnost koju
korisnici mogu da obavljaju, a ne za svaki obrazac i izvestaj u sistemu.
Projektni interfejsi

Projektni interfejs zamiSljam kao aplikaciju s komandnom tablom bez rodi

teljskog prozora. Umesto toga, prozor "Projekat" (koji ne mora da se bas tako
zove) omogucava otvaranje drugih prozora na radnoj povrsini, ko.1i su neza
visni jedan od drugog. SDI interfejs Visual Basica 6.0 SDI dobar je primer
projektnog interfejsa (slika 16-6).
Nakon otvaranja, ti nezavisni prozori prikazuju se na paleti poslova, a ko
risnici mogu da upravljaju njima nezavisno jedan od drugog. Njima takode
upravlja prozor Projekat. Kada je prozor Projekat minimizovan iii zatvoren,
to se odrazava i na sekundame prozore.
Projektni interfejs, posto eliminiSe obavezu da prozor bude saddan u
roditeljskom prozoru, izbegava nedoslednost modela svojstven klasicnim
MDI aplikacijama, ali uvodi drugu nedoslednost: odnos izmedu prozora
Projekat i (prividno) nezavisnih sekundamih prozora.
Razmotrite sledeCi scenario: korisnik otvara sekundami prozor tako sto
dvaput pritisne prozor Projekat, a zatim - da bi oslobodio prostor na radnoj
povrsini - minimizuje prozor Projekat. Puf, nestao je prozor koji je korisnik
upravo otvorio. Da, uvek se moze ponovo otvoriti s palete poslova, ali koji
zbunjivac korisnika.
Ako yam se dopada ideja projektnog prozora, smatram da je model
Accessovog prozora bolji od konvencionalnog projektnog interfejsa. Prozor
Database pruza navigacione prednosti projektnog prozora bez potencijalno
zastrasujuCih sporednih dejstava, buduCi da je sastavni deo klasicne MDI
aplikacije.

Slika :16-6 Visual Basic u SDI rezimu predstavlJa projektni interfejs

Carobnjaci

Poslednja vrsta arhitekture interfejsa upotrebljive u aplikaciji koja radi s ba

zom podataka
carobnjak (eng!. wizard). Carobnjaei se
od niza
stranica koje se prikazuju 11 okvirima za dijalog (slika 16-7).

Cancel

Slika 16-7 U Microsoftovom Accessu 2000 carobnjaci se intenzivno koriste

Carobnjaci 5e najcesce koriste za podrsku poslovima koji se rede oba

vljaju, kao sto je instaliranje aplikacije iii konfigUlisanje hardvera. Pogodni su
za podrzavanje reaih radnih procesa u aplikadji koja radi s bazom poclataka.
Carobnjaci mogu biti korisni i za podrzavanje slozenih radnih procesa.
Ako se raclni proces sastoji od
broja zasebnih poslova kOji se moraju
(ili barem mogul izvrsavati odreaenim reclosleclom, carobnjak moze biti do
bar izbor za korisnicki interfejs. Carobnjad su naroCito korisni aIm radni
proces saclrZi mnogo uslovnih poslova: "ako je ispunjen uslov a, obaviti posao
3 a zatim posao 4; ako je ispunjen uslov b, preci na posao 6."
Meautim, upotreba carobnjaka za slozene raclne procese moguca je
samo ako se pojeclinacni poslovi u procesu mogu obavljati reclosleclom kOjim
ih carobnjak predstavlja. To se dogada rec!e nego sto biste ocekivali. Ukoliko
poslovi ne moraju da se obavIjaju tacno odreaenim redosleclom, carobnjak
nije najboIji interfejs, iIi barem ne bi trebalo da bude jedini interfejs za oba
vIjanje posla.
Kada carobnjak koristite u aplikaciji koja radi sa bazom podataka, 1110ra
te pazljivo razmotriti kako i gde cete smestiti podatke koje korisnik unosi
upotrebi carobnjaka. Uobicajeni model slede6i: ako korisnik u bilo kom
trenutku postupka pritisne dugme
sistem se vra6a u stanje u kome
bio kada je korisnik pokrenuo carobnjaka sto znaci da se odbacuju svi
dad koje je korisnik uneo.

U zHvisnosti oel aplikacije, mozete sacllvuti podatke kud god korisnik

zansi mel na jednoj straniei carolJlljaka, iii pOll1lditi korisnikn IllOguC110st cia

kada pritisne dllgme Cancel, snimi podatke koje dotacl uneo. Uglavllolll

11('

preporucujem nijedl111 oel tih opeija, ali ako se tokom rada earobnjaka \lnos]

njih.
ve6a kolicina podataka, 1110ze biti opravdana jedntl
Druga mogucnost je da korisnieimtl ponlldite da priv1'emeno prekinll
md carobnjaka i da nastave kasnije. To je vrIo upotrebljivo resenje, ali i pri
licno slozeno za izradll jer zahteva privrerneno skladiSte za podatke, neki
mehanizam za odre(livanje gde korisnik stao i mogucnost nastavljanja od
te tacke.

Sazetak
U OYOl1l pogJavlju razmatraJi S1110 nacine na koje mozete strukturirati obrasce
u sistemu. Na m~visem nivou, mozete cla birate izmedu SDI sistema, koji pri
kazuje sve podatke u jednom prozOIll, i MDT sistema, koji radi s vise prozora.
SDT sistemi mogu se praviti u dye varijante: bo radne sveske i sa inter
fejsom u Outlookovom stilu, ,l svaka pruza prednosti U odredenim situaciia~
mao Vise varijanti postoji u MDI aplikaeijama od klasicnog MDT stila, do
arhitektura s komancInom tablom koju podrZava Aeeessov carobnjak Data
base, ukljucujuCi i projektnu arhitektllru Ciji je primer Visual Basic. I najzacl,
carobnjaci mogu biti upotrebljiva arhitektura bela treba podrZati posJove
koji se
obavljaju i sJozene radne procese.
U sledecem poglavlju prelazimo sa organizacije obrazaca na same obra
see da bismo odredili raspored elemenata obrasca na osnOVll strllkture enti
teta u modelu podataka.

Predstavljanje entiteta
na obrascima
U poslednjih nekoliko poglavlja toliko smo se bavili radnim procesima da se
mozda pitate zasto smo onda onoliko modelovali podatke. Ne brinite, U
ovom poglavlju razmotricemo kako se mogu strukturirati obrasci na osnovu
nacina na koji su entiteti sto se prikazlljll nn obrascima predstavljeni u 1110
delu podataka. Oelluke koje donosite 0 tome koje cete podatke prikazati 11a
datom obrascu zasnivaju se 11a radnim procesima, ali nakon tih odluka, vrstu
i raspored kontrola na obrascu odreauje struktura podataka koji se prikazuju
na obrascu.
Prva odluka koju morate da donesete jeste kako se obrazac preslikava na
model entiteta i veza. Da Ii obrazac predstavlja jeda11 entitet, elva entiteta u
vezi bpa "jedan prema jedan", elva entiteta u vezi tipa "jedan prema viSe" ili
vise od dva entiteta? Svaka od navedenih struktura entiteta moze se presli
kati u odreaene oblike obrazaca, kojima cemo se baviti u ovom poglavlju.
Razume se, isto kao i arhitekture koje smo razmotrili u prethodnom pogla
vlju, ti oblici su samo opste smernice, a ne pravila. To su oblici koji se, prema
mom iskustvu, najprirodnije uldapaju u odrea.ene vrste struktura podataka.

Jednostavni entiteti
Najprostija vrsta entiteta koja se moze predstaviti na obrascu jeste jedno
stavan entitet koji je u bazi podataka predstavljen 5amo jednom tabelom. Ako
takav entitet ucestvuje u vezama s dmgil11 entitetima, on je na strani
veze, iii se tabela 11a drugoj strani veze ("jeda11") ne predstavlja na obrascu.
Na primer, pogledajte E/H dijagram na slici 17-1, koji predstavlja entitet
Kupci, i veze u kojima llcestvuje.

265

Zaposleni

Kupci

Porudzbine

Slika 17-1 E/R dijagram koji prikazuje entitete povezane sa entitetom Kupci

:.Jegde u aplikaciji verovatno cete imati obrazac za odrzavanje poclataka

o kupcim<1. To vazi cak i ako se prvobitna verzija podataka 0 kupcu unosi kao
sporedan rezultat drugih aktivnosti. Entitet Kupci nalazi se na strani "vise"
veza prikazanih na dijagramu, OSi111 U vezi sa entitetom Porudzbine, kOji
verovatno ionako ne biste predstavili na obrascu Kupci. Porudzbine su logic
ki razlicit entitet, kOji ce kOlisnici odrZavati u nekom drugom delu sistema.
Entitet Kupci se prema tome 11alazi 11a strani "vise" svih entiteta koji ce
biti predstavljeni na obrascu za odrZavanje kupaca. To znaci cla ce iz drugih
tabela biti predstavljen sa1110 po jcdan zapis, pa se zbog toga Kupci moze
smatrati jednostamim entitetom.
1z toga mozemo izvesti jednostavan oblik obrasca. Nisu potrebni pod
obrasci niti tabelarne kontrole. Samo izaberite za svako polje k011trolu koja
ga najbolje predstavlja (time cemo se baviti u sledecem poglavlju), postavite
je na obrazac i zavrsili ste posao.
Zapravo, kontrolu necete postaviti hila kaka; sve kontrole cete uredno
rasporediti po obrascu, s marginom od sedam jedinica i razmakom od cetiri
jedinice izmedu kontrola, a najvazniji elementi bice postavljeni u gornjem
levom uglu, zar ne? Ali razumeli ste sustinu. :.Je treba da uradite niSta kom
plikovano, osim ako yam ponestane prostora na obrascll.
Medutim, vrlo lako se moze dogoditi da 'lam ponestane prostora. Tehnicki
gledano, na Accessov obrazac iii izveStaj tokol11 njegovog zivotnog ciklusa
mozete postaviti 1.54 kontrole (u ukupan zbir ubrajaju se i izblisane kontrole)
a lJ Visual Basic1l maksimalan broj kontrola je 2,54 (pli cemu se svald niz kon
trola broji kao jedna kontrola).

U praksi, ne hi trebalo cla kOlisnike plimora"ate ela racle s vise oel otplilike
2.3 do 30 kontrola iii grupa kontroh (Obratite paznju na to da sam relda "kon
trola ili grupa kontrola"; grupni okvir koji sadrzi tri ili ('etiri radio-dugmeta
smatra se jeelnom kontrolom.) Ali !ita eete uraditi ako imate jednostavan enti
tet sa 7,5 atIibuta? U svakom trenutku mozete prikazati samo deo tih podataka.
Najjednostavniji naCin da strukturirate obrazac koji predstavlja entitet s
prevelikim brojem atributa jeste da polja razdvojite u grupe iii kategorije.
Obieno prvo izdvojim atribute koji nedvosmisleno identifikuju entitet Tu
podrazumevam ne samo atribute kOji predstavljaju kandidate za kljueeve,
vee i sve druge opisne atribute na osnovu kojih ee korisnici biti sigurni da
rade sa odgovarajuCim primerkom entiteta.
Na primer, za entitet Kupci, ta grupa identifikujuCih atributa verovatno
bi sadrzala detalje kao sto su ime i adresa, a mozda i atribut Prodavac. Za en
titet Artikli, ta grupa bi mogla da sadrZi atribute KategorijaArtikla, Naziv i
Opis. Ta grupa atributa treba da bude u gornjem delu obrasca i uvek viclljiva.
Preostali atributi se potom rasporeauju u grupe srodnih atributa koji tre
ba da se plikazuju zajedno. Za entitet Kupci, mozete kombinovati atIibute
kOji predstavljaju uslove prodaje - uobieajeni popust i uslove plaeanja, na pri
mer - u jednu grupu, a podatke za korespondenciju - referenta nabavke, re
ferenta prodaje itd. u drugu. Za entitet Artikli, mozete kombinovati tehnicke
specifikacije u jednu grupu, a atibute koji se tieu vrste pakovanja u drugu.
Posto organizujete atribute u grupe, imate nekoliko moguenosti. Na glav
ni obrazac mozete postaviti kontrolu tipa glUpa kartica, na Cijim ee kmticama
biti predstavljene pojedine grupe atlibuta. To je resenje koje najeesee kOli
stim. Grupa kartica pruza korisnicima najjasniji kontekst - odmah prepoznaju
da postoje i drugi podaci i kOji su podaci u pitanju. Meautim, ako imate vise
od pet ili sest grupa podataka, kontrola tipa grupa kartica nije pogodna.
U tom slueaju, mozda eete morati da neke ili sve grupe podataka preme
stite na pomoene obrasce. Pomoeni obrasci su takoae pogodni kada grupa
sadrZi vise atributa nego sto moze da stane na jednu karticu. Korisnicima
omoguCite da otvaraju pomoene obrasce pomoeu komandne dugmadi na
glavnom obrascu, iz strukture sliene komandnoj tabli. Meautim, ako imate
previse komandnih dugmadi, obrazac ponovo postaje neupotrebljiv. U tom
slueaju, bolje je da se pomoeni obrasci otvaraju iz menija.
Kada koristite pomoene obrasce, vodite raeuna 0 tome da odrZite kon
tekst u kome je kOlisnik radio. KOlisnicima uvek treba da bude jasno kojem
primerku entiteta pripadaju prikazani detalji. N ajlaksi naein da identifikujete
entitet jeste da na pomoenom obrascu ponovite odredene podatke iz glavnog
obrasca. Najeesee nije neophodno da ponovite celu identifikujueu grupu, vee
samo deo te grupe kOji je dovoljan da se pomoeni obrazac poveze s glavnim.

Druga mogucllost je
se pOl11ocni obmsci On',lraju 1.::ao ll10clalni obra
sci, To je ,iedno od 111alobrojnih mesta U sistemu gde se 1l1oclalni nai::in racla
moze opravclati jer odrZ<lva kontekst u kome je korisnik radio, ,Vledutitl1,
ll10d,llni obrasci lIvek ogranii::avaju korisnike, sto bi trebalo cla izbegavate
kad god
moguce, Tn telmiku koristim Sal110 kao posleelnju l11ogllcnost,
kaela vise nema praznog prostora na obrascu gde bi se mogli pOSblviti onil1
nekoliko atributa koji su neophodni za odrzavanje konteksta.
Altemativa pomocnim obraseima jeste struktura sa panelima, U tom
slucaju je vrio jednostavno obezbediti korisniku mehanizam za menjanje
plikazanog sadrzaja, iz menija iii (bolje) pomocu kontrole na glavnom obra
seu. Slika 17-2 prikazuje primer iz Visual Studija u kome se prikazom upra
vlja pomocu kontrole tip a TreeView (prikaz stabla).

r.

Tabbed documents
MDI environment

f;f Show status bar

f;f Animate environment tools

P"

Speed - - J - - - +
Enable Command Window autocompletion

Web Browser

QJ Source Control
QJ Text Editor

C:l Analyzer
CJ Database Tools
CJ Debugging
CJ Device Tools

12i"''''',', . ,.j",::"'"""",,.,,,1',!.,01 L~;'

Display
Display

110

items in window menu

r:;-- items in most recently used lists

Docked Tool Window Behavior -""

f;f Close button affects active tab only

Auto Hide button afFects active tab only

,--------""'''''''-----,,-----
OK

Cancel

Help

Slika 17-2 Struktura sa panelima iz Visual Studija dobra je alternativa za

grupe kartica

I/eze tipa "jedan prema jedan"

U veCini slucajeva, obrasci koji predstavljaju podatke iz dva entiteta u vczi tipa
"jedan prema jedan" mogu se tretirati na isti nacin kao jednostmmi entiteti.
Napravite upit kOji kombinuje odgovarajuca polja iz obe tabele, a zatim ga tre
tirajte kao jedan jednostavan entitet. Ako imate vise atlibuta nego sto moze da
stane na jedan obrazac, primenjive su iste tehnike kao za jednostavne entitete.

Ako primarni entitet ueestnlje u vise n,za tipa ,jeclan prell1a jcclan" pri
rocla tih vcza odreciuje najpriroclniji razl11eStaj kontro1a na obrascll. Ukoliku
te veze l110gu cla postoje istovrel11eno, l110zete ih tretirati kao jedan \'cliki
skup zapisa i prikazati podatke na jec!nol11 ili na vise obrazaca, kao sto je
opisano u odeljku 0 jednostavnim entitetima.
Mec1utim, veze izmeciu entiteta eesto su medusobno iskljuCive, kao bela
svaki elati proizvod moze biti Napitak ili Sir, ali ne i jecino i elrugo. To
opravclava upotrebu vise podobrazaca ili panela, pod uslovom da imate do
voljno mesta na glavnom obrascu. Ne morate brinuti dOl li ce korisnici SIW,l
titi da u datom kontekstu ima i dodatnih informacija -jer ih nema. U stvari,
upotreba kontrole tipa grupa kartica u ovoj situaciji navela bi korisnika na
pogresan zakljueak.
Ako imate problema s manjkom prostora na glavnolll obrascu, upotre
bite jednu od tehnika za grupisanje i prikazivanje atributa koje smo opisali u
uc1eljku u jec1Ilustavnim entitetima. Ukuliku se kuntrole kuje prec1stavljaju
atribute potklase nalaze na jednoj od kartica, najbolje je dOl pokusate da
nadete neki opsti izraz koji cete prikazati na jezieku te kartice. Korisnike
moze da zbuni kada se natpis na jezieku kartice (ili na komandnom dugme
tu) menja kada prelaze se jednog zapisa tabele na drugi.
1z istog razloga, ako korisnici mogu da se krecu po zapisima primarnog
skupa zapisa, kontrole koje prikazuju atribute entiteta koji ima potklase izbe
gavam da postavim na prvu karticu grupe butica. BuduCi da su kontrole za
svaku potklasu razliCite, dobio bi se "skakutav" prikaz kada korisnik prelazi se
jednog zapisa na drugi. Kada atributi potldasa nisu na prvoj kartici, prikaz
moze ostati stabilan a sporedna korist je malo poboljsanje perfonnansi jer se
izbegava nepotrebno ponovno proraeunavanje sadrzaja nekih kontrola.

Veze tipa "jedan prema vise"

Na mnogim obrascima potrebno je da se prikazu entiteti imedu kOjih postoji
veza tip a "jedan prema vise". Odredivanje najboljeg rasporeda kontrola na
tim obrascima nije tesko, pod uslovom da voclite raeuna da obrazac treba cla
prikaze vezu tipa "jedan prema vise", a ne "vise prema jedan". Kada moclelu
jete slozene veze izmedu entiteta, eesto je lakse dOl razmisljate 0 skupovima
zapisa, umesto 0 entitetima. Prema tome, u ovom slueaju morate biti sigurni
da zapis na strani "jedan" upravlja prikazivanjem zapisa na strani "vise", a ne
obrnuto. Ako pokusate da upravljate zapisom na strani "jedan" pomocu zapi
sa na strani "vise", zavezacete se u evor (kao i sistem i njegovi korisnici).

To izgJeda ocigJec1llo ili barenl meni tako izgleda - ali .i(~ to prilicllo cc
sta grc!ika. Pre dse
zaradila san: lepll svotu popravljajuci S\'C obrascc
tipa "viSe prema
koje je projektovala gospoda s titulom ,,vi)ii projck
tant interfejsa" u jednoj velikoj austmlijskoj band, To bio prvi put da sam
povcrovala u tacnost teorije da "pravi prograJlleri ne rade u bankam<l".
Posto lltvrdite da zapis na strani "jeclan" odrecluje sadrzaj koji se prika
zuje na obraseu, potrebno da odredite kako cete prikazivati zapise na stra
ni "viSe". Imate dve mogucnosti: mozete ih prikazivati jedan po jedan iIi sve
istovremeno.
Vas izbor zavisi od toga koliko detalja korisnid treba da vide od svakog
zapisa na strani "vise" Ako treba da prikazete samo nekoliko polja, obi(';l1o
mozete da prikazete sve zapise. Obrazac prikazan na slid 17-3, iz
po
dataka Northwind, prikazuje pomoclI podobrasca cetiri polja iz svakog zapi
sa na strani "vise".

Slika 17-3 Ovaj obrazac prikazuje zapise na strani "vise" pomoGu podobrasca
koji radi u rezimu neprekidnog prikaza

Vertikalna traka za pomeranje n<l podobrascu pokazuje da nisu vidJjivi svi

zapisi. Sto se projektovanja interfejsa tice, to se ipak smatra pri!mzivanjem
"svih istovremeno". U narednom poglavlju razmotricemo i neke druge naci
ne istovremenog prikazivanja viSe zapisa.

Dopacla mi se stn "s\'i istovrcl1wl1o" jel' korisnicinm ohezbecluje naijas

niji kontekst. Ako imate problema sc neclostatkol11 prostora, clopullske cle
talje mozete uvek prikazati llll pomocnom obrascu. Ali taj stil obrasca llijc
uvek pogo dan , niti moguc, a mozda bas i treba dOl zapise na strani "vise" pri
kazujete jeclan po jec1an. U tom slueaju treba cia resite slec1eca cIva problema:
korisnicima treba c1a bude oCigled11o cIa postoji vise zapisa i morate smisliti
mehanizam kOji ce im omoguCiti cia prelaze s jednog zapisa 11a drugi.
Obrazac nn slid
identican je on0l11 sa slike 17-3, s tom razlikom sto
podobrazac prikazuje sadrZaj samo jednog zapisa, a ne neprekidnog obrasca.

Slika 17-4 Ovaj obrazac prikazuje zapise na strani "vise" jedan po jedan

Biraci zapisa (engl. record selectors) u obliku "video dugmadi" pri clnu
podobrasca predstavljaju standardni mehanizam Microsoftovog Accessa za
kretanje po zapisima. Po pravilu, upotrebljavam standardne mogucnosti kad
god je moguce, ali pogledajtc rczultat u ovom slucaju: dva biraca zapisa viele
se jeelan iznad drugog, a samo njihovi polozaji upucuju na to kOji birac delu
je na skup zapisa na podobrascu a kOji na primarni simp zapisa. Nije kraj sve
ta, ali nijc ni optimalno
Ponekad mozete da uklonite birac zapisa primarnog obrasca. To hi tre
balo da bude izvodljivo na obrascu sa slike 17-4 ako obezbedite dobar inter
fejs za pronalazenje katcgorija artikala. Posto ionako nije mnogo verovatno
da ce korisnici pretrazivati podatke pomocu obrasca za odrzavanje podataka
slicnog ovome, dobra mogucnost pretrazivanja gotovo sigurno ce zaclovoljiti
njihove potrebe.

Druga mogucllost je c1a jedan ocl bimca zapisa zamenite nekim c1rngim
111ehaniz1110111 za kretanje - na primer, konHmclnom dllgmacli ili namenskol1l
trakom za pomeranje. Mec1lltim, npotreba clrllgaCije tehnike za kretanje po
zapisima moze biti teze razumljiva jer uvoc1ite necloslednost \l interfe.is. To je
ipak dobra resenje ako voelite racuna 0 tome da izaberete jeclan model i cia
ga se dosledno priclrzavate.
Na primer, mozete se opredeliti da koristite nesto nalik dugmadima
Forward i Back Internet Explorera da biste upravljali kretanjem po zapisima
na strani "jedan", a pomocu biraca zapisa u oblikll video dugmadi mozete
upnlVljati kretanjem po zapisima na strani "vise", To ce raditi pod llslovom
da opisani model koristite dosledno Ll celoj aplikaciji, sto hi znacilo da cak i
na obrascima kOji predstavljajll jednostavne entitete i kOji p1'ema tome ne
maju zapise na strani "vise", treba da koristite dugmad Forward i Back
Ponekad cete imati obrazac sa primarnom tabelom koja ncestvuje II viSe
veza tipa "jedan prema viSe", a potrebno je cla prikazete viSe od jeclne tabele
na strani "viSe" tih veza.
Ako plihvatite moj savet, izbegavacete takve situacije kad god mozete.
Projektovanje prikazivanja veceg broja tabela na strani "viSe" na obrascu
moze biti tesko a njegova izrada .ios teza, ali ponekad necete imati drugog iz
bora. Ako na istom obrascu morate da prikazete veci broj veza tipa "jedan
prema vise", najjednostavnije resenje je da za plikazivanje podataka sa straml
"vise" upotrebite grupu kmtica, To resenje obezbecluje korisnicima jasan
kontekst. Osim toga, moze da poboljsa performanse, buduCi da se zapisi ZH
grupu butica moraju ucitati samo kada se plikazuje saddaj kartica.
Po svaku cenu treba da izbegavate vidljivu gomilu kontrola koje prikazu
ju zapise sa strane "viSe" iz veceg braja veza "jedan prema viSe" istovremeno.
To bi bilo sporo i ruzno, a prikazivanje n1 istom obrascu podrazumevalo bi
vezu izmedu entiteta na strani vise koja mozda ne postoji. Na primer, na slid
17-5 nije jasno da Ii prikazani brojevi telefona pripadaju kompaniji iIi 050
bama za kontakt.

lijerarhije
Svaka veza tipa "jedan prema vise" tehnicki je hiierarhija, ali se ta rec obicno
koristi za veze koje se sastoje od tri iii vise skupova zapisa: to bi bila veza tipa
,jeclan prema viSe prema vise", ako se tako mo7.e re6i. Hijerarhijske veze se
cesto pojavljuju u modelima podataka, ali nije cesto potrebno da budu precl
stavljene na obrasdma.

I!il Compall.\'

I!!IIiU3

Slika 17-5 Nije jasno da Ii brojevi telefona prikazani na ovom obrascu

pripadaju kompaniji iii osobama za kontakt

Na plimer, na slid 17-6, veze

Kupaca i Porudzbina, i Porudzbi
na i StavkiPorudzbina Cine hijerarhiju s tri nivoCl.

Slika 17-6 Ovaj E/R Diagram prikazuje hijerarhiju s tri nivoa

s takvol11 vrstOI11 strukture, veCina apIikacija imala bi obrazac Kupci koji,

ako hi i prikazivClo poc1atke 0 porndzbinama, to bi bilo u sazetom formatu.
Zaseban obrazac Pomdzbine plikazivao bi porudzbine i stavke izabrane po
rudzbine. Obrazac Porudzbine bi referencirao entitet Kupci, ali bi plikazivao
samo vezu hpa "jedan prema vise" izmedu Porudzbina i StavkiPorudzbina.
Nema mnogo aplikacija u kojima bi bio potreban obrazac kOji prikazuje de
talje iz sve hi tabele istovremeno.
Medutim, tesko je reCi da Ii ta sklonost ka izbegavanju prikazivanja hije
rarhijskih odnosa potiee od nedostatka stvarne potrebe za njima iii zato sto
ih je tesko prikazati 1..1 pogodnom obliku. Primera radi, pretpostavimo da je

klijcnt zahtc\'ao cia ugmclite l1logucnost pregledanja porudzbin,l ntl ohrascu

za oclrza\'anje podatakcl 0 kupcima. Tu fimkcionalnost biste lako ohezbedili
tako sto biste prikazivali zapise iz tabele Porudzbine (srednji n1vo) jedan po
jedan, istovremeno sa svim odgovarajuCim zapisim<l iz tabele StavkePorudz
bine. U sllstini, to bi znaCilo biste obrazac plikazan na slici 17-3 ugmclili kao
poclobrazac na obrazac za odrZavanje poclataka 0 kupcima.
Mec11.1tim, pojedinacni plikaz zapisa iz tabele PorudZbine ne odgovara za
ovu sit1.1aciju. Verovatnije je da ce korisnici pitati, "Koliko porudzbina je po
slao ovaj kupac?" iii "Koja je prosecna vreclnost njegovih poruclzbina?" nego
sto ce ih zanimati pojedini aliikli. Odgovaranje na ta 1.1obicajena pitanja bilo bi
nezgrapno ako prikaz1.1jete samo sadrZaj jednog zapisa iz tabele Porudzbine.
Da biste izbegli taj problem, mozete se opredeliti da na obrasc1.1 Kupci
prikazujete samo zbirne podatke 0 porudzbinama i da ugradite mehanizam
za otvaranje pomocnog obrasca Porudzbine ako korisnik1.1 treba viSe detalja.
Nazalost, resenje "zbirni podaci s detaljima" i111a i nekoliko ozbiljnil1 mana.
Ako korisnici pozele da vide stavke porudzbine kako bi utvrdili koje ar
tilde kupac llCljceSce narucuje, moraju da otvore jos jedan obrazac. BuduCi
da pomocni obrazac Porudzbine obicno prikazuje S<11110 jednu porudzbin1.1,
tesko je porediti artikle narucene 1.1 vise navrata.
Jedna l11ogucnost je da upotrehite kontrolu tipa TreeView (hijerarhijsko
stablo). Te kontrole su cudesne, ali je kolicina podataka koju mogu da pri
kazu na svakom nivou hijerarhije ogranicena, posto svi poclaci moraju cla se
pnkazu u jednom red1.1. Zbog tog ogranicenja, kontrola hijerarhijsko stablo
ne bi bila pogodna za nas primer. Zal11islite kako bi izgledalo kaela biste sve
podatke 0 kupcu plikazali u jednom reclu.
Microsoftov Access 2000 1.1veo je zavisne tabelarne prikaze (engl. sllb
datasheets) koji podrzavaj1.1 predstavljanje hijerarhijsbh poclataka u formatu
7).
s visc nivoa (slika
Zavisni tabelarni prikazi nis1.1 vizuelno elopadljivi, ali su upotrebljivi.
Mogu se ugnezdivati do osam nivoa d1.1bine ali na svakom nivou 1110zete
1.1gnezditi samo jedan simp zapisa. Na primer, ne mozete napraviti zavisni ta
belarni prikaz koji bi na istom nivo1.1 prikazivao i Aclrese i Porudzbine.
Visual Studio .NET ima kontrolu DataGlid koja pmza slicnu funkcional
Host, ali na malo nezgrapan nacin iako odrzava hijemrhijske veze izmedu ob
jekata DataSet, u svako111 dat0l11 trenutku prikazuje samo jedan od nj1h. U
nasem primeru, ako korisnik prikaze podatke iz tabele Porudzbine, nestali
bi podaci iz tabele Kupd, a korisnik bi 11101'ao cIa pritisne dugme Back da bi
ih ponovo prikazao.

21
$12,00.
2
25%
50.00 !
0%
4.03~Oct:1~-31-0~j':1997~1:fOZl.1997
46.

~"'~.~~,,~~~.
10&'''12
10702 ,

10B35
10%2
11011'

nOelEmi
.."i4:j5:j;~:193~!

I. 16-Mar-I998.

210ct,1997
.....
21-Jdn-1993
24-M.r-1993

~.QS:/lpr-l?38

13:,i\.pr-1993.

24NoI' 1997.

. . . . . . .... ,.... ..

..". "."

~..w"

2 561.02 ,
1. $2394.
3
1

I'

.. 24:S"p-19~

4. 04-Mar-I938 .
AntOillO

Moreno T~Que'ia

- - 1 [Qill[!] of :I

06-Sep-1997,

14:AJJg- 1997

26-0<>,-1997:

12-0e,-1997
11 M.,1993

01-Apr1998:

,Owner

1:$4390
3 $11.99

3 55392
Mai v

Slika 17-7 Zavisni tabelarni prikazi Accessa 2000 predstavljaju hijerarhijske podatke

Veze tipa "vise prema vise"

Poslednja vrsta logicke veze koju cete verovatno prikazivati na obrascu jeste
"vise prema vise", Ta veza se predstavlja pomocu tri ili vise tabela iz baze
podataka,
U velikoj veCini slucajeva, veze tipa "vise prema vise" mozete tretirati
kao "jedan prema vise". Na primer, na slici 17-8 prikazana je veza tipa "vise
prema vise" izmedu tabela Kupci i Artikli, a tabele Porudzbine i StavkePo
rudzbine igraju ulogu spojnih tabela,
Logicno je prikazivati sve aIiikle koje je odredeni kupac poruCio (u tom
slucaju, tabelu Kupci tretirali biste kao stranu "jedan" u vezi) iIi sve kupce kOji
su naruCili odredeni proizvod (u tom slueaju, tabela Aliikli bila bi strana
"jedan"). Mozete upotrebiti sve tehnike predstavljanja kao za obrazac koji pri
kazuje vezu tipa "jedan prema vise", Jedino treba da odredite gde cete precl
staviti podatke iz spojnih tabela i sta cete raditi s duplikatima na strani "vise" ,

(:

Porudzbine

Slika 17-8 Izmedu Kupaca i Artikala postoji veza tipa "vise prema vise"

VeCina spojnih tabela sadrZe sarno primarne kljuceve sa obe strane veze
"viSe prema vise" Keto sto smo videli u poglavlju 3 i kao sto je prikazano na
sliei 17-8, smna veza ponekad ima atribute kOji su modelovani tako da pri
padaju spojnoj tabeli. Ako te atribute treba da prikazete na obraseu, trebalo
bi da to bude na strani "vise".
U nasem primeru, ako obmzae treba da prikazuje artikle koje je kupio
odredeni kupae (tj. tabela Kupei je strana "jedan"), jasno je da je datum po
rudzbine koji je polje iz tabele Porudzbine deo podataka 0 artiklima, a ne
o kupeima. "Kupae X kupio je mtikal Y 15-og, mtikal Z 18-og ...". Datum po
rudzbine bio bi cleo podataka 0 kupeu u obrnutom slucaju, gcle bi Artikli bili
stral1<l "jedan": "Artikal X kupili su kupac Y 15-og kupac Z 18-og ..." posto se
u tom sluCaju tabela Kupei tretira kao strana "vise".
Vrlo je verovatno da ce na strani "viSe" biti duplikata, iii barem delimic
nih duplikata . .\1orate se opredeliti da Ii cete svaku clupliranu stavku prikazi
vati pojedinacno iii cete prikazivati sarno zbirne podatke. Na primer, ako
prikazujete kupce kOji su kupili pojedine artikle, mozete se opredeliti da pri
kazete svakog kupea po jeclanput za svaki kupljeni artikal; iii mozete navesti
kupea samo jedanput i prikazati ukupan broj puta kada je kupac narucio ar
tikal i ukupnu kupljenu kolicinu (a mozda i prosek kolicine).
Vodite racuna 0 tome da izbegnete prikazivanje samo cluplikata. Potpu
no je beskorisl1o da prikazete ime odl'edenog kupea
puta ako osim njega
ne prikazujete nikakve dodatne podatke, npl'. datum porudzbine. Jedini raz
log zbog kojeg bi korisnici pozeleli da vide taj poclatak jeste da bi saznali
ukupan broj porudzbina koje je poslao odredeni kupac, a tom aritmetikom
treba da se bavi aplikacija, a ne korisnik.
Mada tretiranje veze "vise pl'ema viSe" kao veze "jedan prema viSe" ispu
njava veCinu zahteva, ponekad ce biti potrebno da tu vezu prikazete u pot
punosti. Osoba oclgovorna za odredeni artikal, koja pretrazuje podatke 0
kupcima tog mtikla, moze pozeleti da zna koje su jos mtikle kupili ti kupci da
bi, na primer, fonnirala "specijalne ponude".

SrCCOl11, ta \Tsta Hllalize najces(:c se o!JaY]ja 11 clilllcnziollalnoj hazi poda

taka. Kao sto S1110 viclcli, alatke
Cine intcrfejs ka dimcnziol1alnilll baza
ma podataka, kao sto je Microsoftov Data Analyzer, projektovane SlI upra\'Cl
za obradu takvih situacija. Ali takav zahtev sasvim je mogue i kao cleo atlmi

nistrativne funkdonalnosti u produkdonoj bazi podataka.

Jedno relativno jednostavno resenje u tom slucaju jl'ste cIa veze tretirate
kao hijl'rarhije i da ih prikazujl'tl' pomocu zavisnih tabl'larnih prikaza iIi kon
troll' DataGrid. Ta metoda jl' opasna zato sto nije uvek jasno sta prikazani
cIodatni podaci tacno predstavljaju. Na primer, ako se uz listu artikala poja
vljuje zavisni tabelarni prikaz samo ill1ena kupaca, mozda neee biti ocImah
jasno da Ii su to imena kupaca tih artikala, iIi dobavljaca kod kojih kompanija
nabavlja tl' artikll'.
Ako vas brine mogucnost zabunl' u hijerarhijskom prikazu, iii ako klijent
ne zahtl'va izricito hijerarhijsh prikaz podataka, moze biti bolje cIa potrebne
podatke prikazete u sekundarnom prozoru, gde mozete jasno opisati njihovo
znacenje. Upotreba sekundarnog prozora takode omogueava da osim dl'talj
nih podataka, iii umesto njih, prikazete zbirne podatke.
Os obi odgovol11oj za odredeni mtikal koja trazi podatke 0 drugim mti
klima koje je kupio odredeni kupae, 11l0zda ce viSe odogovarati da lista arti
kala ko.1e su kupili svi kupd koji su kupili i primarni mtikal, bude organizovana
po procentima - na primer, svi kupd koji su kupili zvecku kupili su i euelu, ali
samo njih 10 procenata kupilo je i Cigru. Deo tih zbimih podataka mozete pri
kazati i na glavnom obrascu, ali posto jl' proracun prilicno slozen (i zbog toga
traje izvesno vreme), bol.1e je da rezultate prikazujete u sekundarnom prozoru
na zahtev korisnika, osim ako su b<L~ cesto potrebni.
Dve opisane tehnike za prikazivanje svih podataka iz vl'ze "vise p1'ema
viSe" ne iskljucuju jedna drugu. Na glavnom obrascu mozete prikazati listu
kupaca svakog mtikla u hijerarhijskom obliku, a u sekundarnom prozoru
koji ce kOlisnik otvOliti kad mu zatreba moz.etl' prikazati "deset najboljih
kupaca". Kao i uvek, svoju odluku morate zasnovati na predvidenom naCinu
koriScenja obrasca.

Sazetak
Posto S1110 u poglavlju 16 razl1lotrili kako mozete organizovati obrasce na
osonovu poslova koje korisnici obavljaju, u ovom poglavlju objasnili smo
kako bi trebalo da strukturirate kontrole na obrascima, u zavisnosti od struk
ture entiteta koje zelite da prikazete.

Izbore kOji cctc napraviti pri strukturiranjl1 obrazHca, Z<\Y1S1Ce plyen

sl:\'cno oel entitcta koje
cla prikazctc na obraSCll i od toga ako prika
Zlljete viSe ocl jednog cntiteta II kakyim su vczama ti entiteti. Strukturll
obrasca odrcduje i broj atributa kOji trcba prikazati, posto praksa pokazuje
da na obraSCll nikad ne bi trebalo da se vidi viSe ocl
do 30 kontrola ili
grupa kontrola.
U sledecem poglavlju prelazimo na naredni nivo projektovanja kori
snickog interfejsa: biranje pojedinih kontrola koje treba da predstave razlici
te vrste podataka,

Biranje Windowsovih
kontrola
U poglavlju 17 razmohili smo n1Zne nacine strukturiranja obrazaca u zavi
snosti od veza izmeau entiteta predstavljenih na obraseima. U OVOl11 pogla
vlju, razmotricemo biranje odgovarajuCih kontrola u zavisnosti od vrste
logickib podataka.
Pri izboru kontrola vaze dva osnovna principa. N 1jv1znije je c1a izaberete
kontrolu koja najbolje odgovara korisnikovom videnju podataka - drugil11 re
eim1, koja odgovara korisnikovom mentalnom modelu. Drugo, podatke koje
korisnik moze da unese treba ograniciti na najuzi moguCi opseg vrednosti.
Ljudi kOji rade s bazama podataka skloni su da posmatraju podatke kao
tekstualne vrednosti. Ako skup zapisa otvorite kao tabelarni prikaz u Accessu
(slika 18-1), sva polja su prikazana kao tekst. Ali, u stvari, samo polje Custo
l11erName (ime kupea) ima tip podataka Text. Polje CustomerNumber
kupca) je tipa AutoNul11ber, DateOfFirstOrder (datum prve porudzbine) je
Date/Time, CreditLimit (kreditni maksimum) je tipa Currency, a Preferred
Customer (dobar kupac) je tipa Yes/No (logicko polje).

Slika 18-1 U ovom tabelarnom prikazu vise tipova podataka prikazano je kao
tekstualne vrednosti

279

Kacla kao projcktanti sistema manipulisemo poclacima, mi imamo u viell!

razne clomene poclataka i ne pokusavamo cia spojimo datmll s logicllom
\Teclnoscll. Uprkos tome, kocl mnogih projektanata postoji sklonost
prika
zivanju vreclnosti razlicitih tipova 11 istom obliku, obicno u poljima za
To resenje funkcioniSe 11 polju za tckst lllozete prikazivati poclatkc svih vr
stn - ali time ne cinite llslugu korisnicima. Trcbalo hi da polje za tckst sma
trate svOj0111 poslednjom mogllcnoscll i koristite ga samo ako utvrditc da
nisu upotrebljivc kontrole drugih, speciflcnijih vrsta.
Kada gledate polje cleklarisano u domenu datul11/vreme, vi mozda \ric1ite
niz znakova formatiran na odreden naCin, ali korisnici tn viele datum. Kada
menjaju datum, njihov mentalni proces potpuno je clrugaciji od onog kacla
menjaju tekst. Ako korisnik pogresno otkuca ime, pomislice, na primer, "N tl
'Nira' treba da bude M". Medutim, llkoliko treba cla izmeni datum, verovat
nije je da ce razmiSljati ovako: "Ovo bi zapravo trebalo da bude sedam dana
od ponedeljka". Korisnicima mozete olaksati zivot ako izaberete kontrolll
koja J)oclrzava njihov naCin razmisljanja 0 poclacima.
Zivot cete im olaksati i ako ogranicite vreclnosti koje 1110gU cla unesu.
Ogranicavanje poclataka nije isti problem kao provera ispravnosti podataka,
kojim cemo se baviti u sledecem poglavlju. Provera ispravnosti podataka
postupak koji, nakon sto ko1'isnik unese podatak, sistem obavlja dOl bi
zbedio unosenje samo prihvatljivih vrednosti. Ogranicavanje podataka
cava korisnike da unesu neprihvatljive podatke.
Treba poceti od ogranicavanja tipa poclataka koje korisnik moze cla une
se. Kada birate kontrole, podatke mozete pocleliti u cetiri grupe: logicki
podaci, skupovi vrednosti, brojevi i datumi, j tekst. U ovom poglavlju razmo
tricemo pojedinacno svaku grupu.

NAPOMENA: Ovde ne mogu opisati sve iz prividno beskrajnog niza raznih alat
ki koje se mogu naci kod nezavisnih proizvodaca; razmatranje sam ogranicila na
one standardne u Visual Studiju .NET i u Accessu. Medutim, preporucujem vam
da istrazujete sta je sve na raspolaganju. (Microsoftova Web lokacija je dobra
polazna tacka.) Naci cete mnogo toga beskorisnog, ali i mnogo vrlo upotrebljivih
stvari a moze se dogoditi da vam nekoliko stotina dolara koje ste potrosili na
alatku nekog nezavisnog proizvodaca ustedi vise sedmica razvoja i testiranja.

Predstavljanje logickih vrednosti

Mach logickc vrcdnosti lllozctc prikazivati II polju za tekst, to l1ijc dobro
resenje. Na primer, tahela Kllpae moze cla sadrzi polje nazvano Oc1obrenKrc
clit, cleklarisano kao polje logickog tipa. Podatke iz tog polja lllo::ete prikaziva
ti u pOljll za tekst, a potom provcravnti u koelu da Ii je korisnik uneo
ili
. Ali kada dozvolite unosenje poclataka bez ikakvog ogranicenja, kao u
OV0111 slucaju, prosto terate korisnike cIa upHiu nesto poput "Privrcmeno" ili
"Ni slucajno". Ako niste spremni da prihvatite i tumacite tah1e podatke,
nicete korisnicima i sebi uslugu ako izabercte kontrolu koja je ogranicena na
samo dye moguce vrednosti.
U Accessu i u Visual Studiju postoje dye kontrole pogodne za tu vrstu
podataka: polja za potvrdivanje (eng!. check boxes) i preklopnici (eng!. toggle
buttons) (slika 18-2).

Slika 18-2 Svako polje za potvrdivanje i preklopnik predstavlja jednu logicku

vrednost

VeCina ljudi poznaje polja za potvrctivClnje, kojLl su clobar izbor za pred

stavljanje veCine logickih vrednosti. Preklopnici se rede koriste. Priklaclniji
su za logicke vrednosti koje predstavljaju stanja ,.ukljuceno"i "isldjuceno"
nego za "tacno" ili "netacno". Problem s preldopnicima je u tome !ito se u
stanju "iskljuceno" ne razlikuju od komandne dugmadi. BuduCi da korisnici
ocekuju da se - kada pritisnu dugme izvrsi neka akcija, mnogi ce se vero
vatno ustezati da pritisnu dugme s natpisom "Odobren kredit" jer ce
da ce time pokrenuti postupak odobravanja kredita umesto obiCnog sta
vljanja oznake da je to ucinjeno.
razloga, preklopnike radije koristim u
grupama, kao radio-dugmad oblik u kome su rcalizovani u Visual Stucliju.
To su zapravo kontrole tipa radio-dugme Cije je svojstvo Appearance (izgled)
podeseno na "Button" (dugme).

Haclio-clugmacl (poznata i kao c1ugmac1 za opcije), nemojte koristiti za

prec1stavljanje sumo jedne logicke vrednosti. Nistu \'US II \Vindowso\,o1l1
okruzenju ne sprec-ava da to cinite, ali .Ie to nepotrebno (polja 7.<1 potvn1i
vcmje su pogodnija) i neprildadno. Namena mdio-clugmadi .Ie predstavljanje
grupe medllsohno iskljueivih vrednostL Jedno usamljeno dugme za Opcijll
izgleda eucIno,
Sto je jos gore, ako pomocu dllgmadi za opeije preelstavljclte viSe logiCkih
vrednosti u istoj oblasti obrasca, 1110ze se dogoditi da korisnici pogresno po
misle da su ta dugmad na neld nacin medusobno povezana i da uvek mogll
izabrati samo jedno oel njih. Korisnici takode ocekuju da kacla izaberu jednll
od opcija, automatski iskljucuju sve ostale. Korisnike uvek zbunjuje kada se
racunarski sistem ne ponasa onako kako oni ocekuju.

Predstavljanje skLipova vrednosti

Postoji vise kontrola koje omogucavaju predstavljanje skupova vrednosti na
obrascu. Izbor zavisi najvise od toga treba Ii da se unese samo jednH vrednost
(mada iz opsega mogucih vrednosti) iIi vise njih.

Biranje jedne vrednosti iz skupa vrednosti

Prihvatljivost date vrednosti cesto zavisi oel toga cia Ii se ona nalazi na odre
denoj listi. Na primer, vrednost SifreKupca u zapisu tabcle Porudzbine
moze hiti ispravna samo ako taj kupac postoji II tabeli Kupci. BlldllCi cIa
vrednosti koje korisnik moze da uncse zelite da ograniCite na opseg pri
hvatljivih vrednosti gde god je to moguce, korisnicima treha da ponudite li
stu Kupaca i omoguCite im da izaberu jednog od njih.
U takvim situacijama najvise se koriste kontrole tip a padajuCa lista (eng!.
combo box) i obicna !ista (engl.list box)
18-3). Postoji nekoliko razlika
u funkcionisanju ovih lista, a najvaznija je to sto padajuCa lista ol11ogucava
korisnicima da unose vrednosti kojih nema na Bsb. Kao sto je vec ranije
opisano, ta funkcionalnost se ponekad mozc iskoristiti za unosenje novih za
pisa u povezanol11 entitetu. Cak i ako unosenje novih zapisa nije l~rikladno ili
potrebno u vasem projektu, mogucnost pronalazenja vrednosti na listi cIi
rektnim kucanjem korisna je veCini operatera koji brzo kucaju jer obavezll
upotrebe miSa iIi cak gledanja u ehan smatraju ometanjem.
Visual Studio omogucava da padajuce liste podesite tako cIa buclu otvo
rene uvek ili samo na zahtev. Access podrzava iskljuCivo padajuce liste.
(Osim toga, na ohicnim listama u Visual Studiju mozete prikazivati polja za
potvrdivanje pored vrednosti stavke; Access ne podrZava tu funkcionalnost.)

iii. Combo Boxes and List BOKes

IlIifD

A~!anda,d 1;'1 box'

L.

Slika 18-3 Visual Studio podrzava tri stila padaju6ih lista

Knjiga The vVindows [nte,face GUidelinesfor Software Design propisu

je da bi jednostavne padajuce Iiste i obiene Iiste trebalo da podesite tako cla
prikazuju tri do osam stavki. Ako nemate dovoljno prostora na obrascu,
upotrebite padajucu listu koja se otvara na zahtev.
Cak i ako i;l1ate dovoljno prostora da prikazete stalno otvorenu listu,
upotrebite padajucu listu ukoliko ona postaje nebitna nakon sto korisnik s nje
izabere stavku. Ponekad je dobro da korisniku omoguCite da jednim pogle
dom obuhvati koje su sve vrednosti moguce, naroCito ako se eesto menja
sama lista iii vreclnost koja se dodeljuje zapisu.
Na primer, u sistemu za podrsku radu biblioteke, u kome se naslovi svr
stavaju u kategOlije tema sa liste koja se cesto azurira i dopunjava, korisnici
ce 1110zda zeleti da vide najnoviju listu kako bi utvrdili da Ii neb nova kate
gorija bolje definiSe datu knjigu.
Ali ako, na primer, imate listu kupaca na obrascu Porudzbine, nakon sto
korisnik izabere kupca kOji mu treba, vise mu nije vazno koji su sve drugi
kupci poznati u sistemu. U takvim situacijama koristite padajucu listu koja
sakriva svoje stavke posto korisnik izabere onu koju je hteo.
Izuzetno korisna mogucnost i u Visual Studiju i u Accessu jeste prikazi
vanje vrednosti koja se ne upisuje u tabelu. Net primer, ako kao primarni
kljue tabele Kupci koristite vrednost tipa AutoNumber iIi identity, potrebno
je da je skladiStite i u tabeli Porudzbine kao njen spoljni kljne, ali nema raz
loga da ona bude vidljiva korisnicima. Umesto toga, na obrascu Porudzbine,
mozete prikazati listu imena kllpaca (iz tabele Kupci) s koje korisnik moze
da izabere kupca.
U Visual Studiju, to se radi taka sto se zaclaju razlieita imena poljel 11 svoj
stvima DataField i ListField. U Accessll, upotrebite padajucll listll s vise
kolona jednu za ime kupca a drugu za sifru kupca - povezite kontrolu s ko
10no111 za sifi'u kupca u tabeli Porudzbine, ana padajucoj listi sakrijte kolonu
za sifru kupca tako sto cete je podesiti na sirinu nula.

Mogncnost AccessO\'ih pac1ajllcih lista c1a prikazujll vise kolona, iZllzetno

je kDrisna i mlll\'(:k sam smatrala c1a je steta sto ona ne postoji 11 Visual Stu
dijll. Na primer, bela prikizujete listu lmpaca, dobro bi bilo cia se vide i
c10punski poclaci, kao sto prebivaliste, racli dalje identifikaeije kupea, U Vi
sual Studiju, to je izvodljivo S,11110 ako kao vrednost svojstva ListField zaclate
izracllnat~ polj~ koje m{dovezuje vrednosti Z,l prikaziv;mje. Medutim, to ni
bel ne izgleda tako dobro kao Accessove padajllce liste, narocito ako su neke
prikazane vrednosti prazne,
Koliko god cIa su obicne i padajuce liste korisne, nisu prakticne ako sa
drZe preveliki broj stavki. Ukoliko imate vise od nekoliko stotina stavki, 1110
racete da smislite naCin da ogranicite taj broj, Na primer, korisniku mozete
omoguci da izabere slovo azbuke, prodajnu oblast, opstinu i da zatim na
osnovu tog izbora filtrirate stavke Iiste,
Ako je list a vrlo hatka - ne vise od pet iii sest stavki - i te vrednosti so
fiksne, moze bili bolje da upotrebite grupu opcija umesto padajuce iIi obie
ne liste, Grupe opdja mozete fonnirati s dugmaclima za opcije iIi s preklop
nicima (slika 18-4), Uobicajen izhor su dugmad za opcije.

Slika :18-4 Dugmad za opcije iii preklopnici smesteni u okvir za grupu, mogu
da predstavljaju kratke liste fiksnih vrednosti

Mec1utim, iako je rnoguce, barem u Visual Studiju, generisati grupu op

cija tokom rada aplikacije, to nije dobro resenje. Korisnike ce zbuniti pro
mena sadrzaja i izgleda obrasca, kao sto ce ih zbuniti i ako opcije dodajete iIi
uklanjate tokom rada aplikacije, Ako je lista opcija fiksna (iIi je barem fiksna
do sledece verzije aplikacije), bolje resenje je obicna ili padajuca lista, Bu
duci cia se veliCina tih kontrala ne menja kada im dodate iii uldonite stavku,
korisnike nece ometati ako se stavke liste budu menjale,

Unosenje vise vrednosti

Ukoliko treba da ol1loguCite ul10senje skupa \'rec1nosti, to znaCi cia radite sa
stranom ,,\'iSe" \'eze tipa "jedan prema \'ise", K,lO sto SlllO vic1eli 11 pogIav!ju
17, 11 takvilll situ<lcijama pr\'() odlucite treba]i da unosite vrednosti za sve za
pise istovremeno ili zapis po zapis.
Ako u Accessu zelite da za
na strani "viSe" prikazlljete i unosite
vrednosti zapis po zapis, mozete upotrebiti podobrazac poclesen za prikazi
vanje jednog zapisa. Podesite svojstva LinkChildFields i LinkMasterFields,
a Access ce sam obaviti preostali deo pOShL U Visual Studiju, izrada takvog
podobrasca zabteva malo viSe posla (dobro, mnogo vise posln), ali zauzvrat
imate malo veCi stepen kontrole, U oba slucaja, to je dobra tehnika kada ko
1'isl1ik treba da unese vrednosti u viSe polja, narocito ako zelite da koristite
kontrole razliCitih vrsta.
Ukoliko treba da omogucite viSe vrednosti po zapisu i zelite da
sadrzaj vise zapisa istovremeno, u Accessu mozete da upotrebite tabelarni
prikaz (engl. datasheet), a u Visual Studiju, kontrolu DataGrid, Accessovi ta
belarni prikazi prilicno su mocni (ponekad eak i previ,se 111ocni), a osil11 polja
za tekst, o111ogucavaju i upotrebu viSe drugih vrsta kontrola. Kontrola Data
Grid Visual Studija .ie, iskreno reeeno, malo nezgodna za programiranje, ali
je ipak upotrebljiva (i stabilnija
kotrole tog tipa 11 starijim verzijama Vi
sual Basica).
Access o111ogucava alternativno resenje ako yam treba preciznija kontro
In onoga sto obrazac prikazuje. Accessova kontrola tipa podobrazac podrzava
upatrebu poclobrazaca u prikazu besprekidnog obrasca, sto ol11ogucava pri
kazivanje sadrzaja viSe zapisa istovremeno. To je dobar izbor ako treba da
prikazete vise zapisa i potrebna yam je neka kontrola od vrste kojl1 tabeJarni
prikaz ili kontrola tip a Griclne podrZava kao sto je grupa opcija, Da biste
obezbedili istu funkcionalnost u Visual Studiju, morali biste da napravite
kontrolu tipa UserControl.
Druga kontrola koja u nekim okolnostima moze biti korisna za prikazi
vanje vise zapisa jeste kontrola TreeView (hijerarhijski prikaz), Kontrola
TreeView se najeesce koristi za prikazivanje hijerarhijskih podataka u hije
rarhijskom obliku, ali se maze upotrebiti i za prikazivanje odabranih detalja
iz svakog zapisa. Kontrola Tree View nije eflkasan mehanizam za azurinmje
tih detalja, ali moze biti veoma eflkasna za kretanje s jednog zapisa na drug!.
Pomocu modela slicnog Mic1'osoftovol11 'Windows Exploreru, mozete prika
zati detalje izabranog zapisa u nekom drugom delu obrasca,
I najzad, u situacijama u Kojima korisnici treba da izaberu grupu stavki s
ponudene liste, par medusobno povezanih obicnih lista moze biti ko1'isna
struktura. Takva struktura, koju na slid 18-5 Cine liste Sample Fields i

Fields In 1\1.\' l"\c\\' Table, cesto se koristi 1I carobnjacima. (Slika ekrall<l po

tiee iz ('arobnjaka Tahle Acecssa :WOO.) Korisnic:i lako raZ11l11eju tako
ne Iist(" ali \'<\s mOnlm upozoriti cia se one malo teze programiraju.

Table Accessa 2000 koristi medusobno povezane Iiste

kako bi korisniku omogucio da izabere polja za novu tabelu

PHr obicnih lista, kao sto je opisani, pogodan je za unosenje pocetnih

vrednosti, ali nije prik1adna struktura za naknadno azmiranje i prikazivanje,
a jedan od raz10ga je to sto zal1zima previse prostom. Zbog toga se tn tehnika
najcesce koristi u carobnjacima, gde se svaki podatak moze obmaivati na za
sebnom ekranu, Posto zavrsi unosenje pocetne vrednosti, korisniku verovat
no vise 11e6e biti potrebno da vidi ce1e liste izabranih i neizabranih vrednosti,
pa zato mozete l1potrebiti jednu od prethodno navedenih kontro1a ili cak
samo jednu obicnu 1istu koja omogl1cava biranje vise stavki.
MeauUm, zbog na6ina na koji se biraju stavke na listama koje plihvataju
biranje vise stavki, one mogu biti opasne, Korisnik vrlo 1ako moze nenamemo
isk1juciti iz izbora sve trenutno izabrane stavke tako sto misem jednom priti
sne novu stavku (umesto da drZi pritisnut taster Ctrl dok misem bira stavke na
listi). Kada su stavke koje se biraju povezane s podacima, utvrdivanje kOji je
zapis bio dodat, kaji izbrisan a kOji ponovo izabran maze biti apsolutna noena
mora. Bo1je resenje je obicna !ista koja prihvata samo biranje stavku po stavku
i prikazuje prethodno izabranc stavkc - mozda u kombinaciji s poljem za tekst
iIi padajueom !istom za dodavanje stavki.

Predstavljanje brojeva i datuma

Numericke vrednosti i datumi najcesce se prikazllju u poljima za tekst. Keto
i uvek, najbolje .Ie da, gde god je to moguce, ogmnieite numericke vreclnosti
koje korisnic:i mogu cia unesu. Medutim, mozda to nece biti moguce ako .Ie
opseg vrec1nosti presirok.
Svojstvo Input Mask u Accessu i kontrola MaskedData u Visual Stucliju
pruzaju izvestan stepen kontrole nad brojevima koje korisnici unose u polje
za tekst - mozete barem spreciti unosenje slova. Access takocle prilieno "pa
metno" interpretira unete podatke, ali to .Ie provera isprav)losti podataka
koja se obavlja tek nakon unosenja i nije najbolje resenje ako postoji 1110
guenost ogranicavanja podataka vee pli unosenju.
U Visual Studiju postoje dye dodatne kontrole za unosenje kalenclarskih
podataka, a to su kontrole MonthView i DateTimePicker (slika 18-6). U
~essu postoji kontrola Calendar sliena kontroli MonthView iz Visual Studija.
~."~=

,,,-~~-.

--

lIlP~~f!~[l!iI~~q!ltrol~~~'f'" :t;':i)~~~ ~~lmI

MonthView Control:

November. 2004

'CJ Today:

DateTimePicker Control:

IWednesday. Novembel 03.2004

iJ

11/312004

Stika 18-6 Kontrole MonthView i DateTimePicker

Te kontrole mozete zamisliti kao kalendarske ekvivalente obiene i pada

juee liste - kontrola DateTimePicker prikazuje blendar samo na zahtev,
dok ga kontrola MonthView prikazuje uvek Medutim, obe kontrole mogu
da rade samo s datumima, ne i s datumima i s vremenima. BuduCi da to
moze dovesti do cudnih komplikadja bda su te kontrole povezane s poljima
tipa Datetrime, morate voditi racuna pri programiranju.
U Visual Studiju i u Accessu takode postoji kontrola UpDown (koja se
ponekad naziva birac vrednosti); ona se moze upotrebiti i za numericke i za
datumsko/vremenske podatke. VeCina korisnika poznaje kontrolu UpDown
jer su morali da podesavaju datum i vreme u vVindowsu, kao sto .Ie prikazano
na slid 18-7.

Dale/Time PlopeJlies

IJ I

Slika :1.8-7 Pomocu kontrole UpDown podesava 5e vreme u Window5U

Kontrola UpDOW11 narocito je kOlisna ako se vrednosti ne povecavaju u

jednakim koraeima - na primer, bda datum moze biti samo radni clan iii se
numericka vrednost mora zaokruziti 11a naiblizlI stotinu.
Posleclnje dve kontrole iz Visual Studija koje se mogu upotrebiti 2<1 uno
senje n1ll11elickih podataka jesll klizaci (engl. slider controls) i trake za po
meranje (engl. scroll b(ws) (slika 18-8).

Slika 18-8 Klizaci i trake za pomeranje ni5u narocito upotrebljivi u

aplikacijama koje rade 5 bazama podataka

Te kontrole nisll narocito upotrebljive u aplibcijama koje rade s bazama

podataka. U sustini, to su graficki mehanizmi za podesavanje numerickih

\Tcdnosti i ];:ao takYi, teorijski bi 5e mogli koristiti za lIllOsenje hi10 kak'ih

podataka 111111lcrickog bpa. (Trake za pomeranje \'erovatno ne mozete dn za
mislite kao llumericke alatke - jer njihov pri\-idni model niie taka\' ali OllC:'
zapravo u pozadini vracaju aplikaciji numericke vrecInosti.
Smatral11 dn 5U najkorisnije bda korisl1ik treba cIa poredi skup vrednosti
Ciji su relativni polozaji vazniji od tacnih vreclnosti tj. sluCajevi kada vazi
"vreelnost U OVOI11 polju vaznija je oel vrednosti U ol1orn polju". Na primer,
klizace sam u nekoliko navrata upotrebila za proveru poduclamosti, da bih
korisnicima omogucila da podese relativnu vaznost ili zahtevanu toleranciju
za polja koja uporeduju kada traze odredeni zapis.

Predstavljanje tekstualnih vrednosti

I najzacl, moramo se pozabaviti i kontrolama koje nam poslednje preostaju, a
to su polja za tekst (eng!. text boxes). Polja za tekst nisu 105a sama po sebi; pro
blem je sarno to 'ito se previse (zlo)upotrebljavaju. VeCina podataka u tipicnoj
bazi tekstualnog je bpa, pa su polja za tekst plildaclne kontrole za predsta
vljanje tih vrednosti. Izuzetak je slucaj kacla je polje spoljni kljue; onda je
padajuca lista iIi obicna lista najcesce holji izbor, keto !ito je vee opisano.
05novni principi za izbor vrste kontrola podjednako vaze i za polja za
tekst: koristite ill kac1a odgovaraju korisnikovom mentalnom moclelu i pri
menjujte sve upotrebljive tehnike ogranicavanja podataka pri unosenju.
Access omogucava ogranicavanje podataka pri unosenju pomocu svoj
stva Input Mask (ulazna maska) polja za tekst. To ni.1e direktno podrZano u
tekucoj verziji Visual Studija. Ulazne maske omogucavaju cIa zadate oblik
kO.1i treba da imaju pocIaci kO.1i se unose u polje. Na primer, telefonski broje
vi mogu se unositi u formatu (###)###-#### (leva zagrada, tri cifre, desna za
grada, tri cifre, crtica i cetiri cifre).
Ulazne maske su korisne u nekim situacijama, ali se te situacije javljaju
rec1e nego sto se misli, a ulazni pocIaci se lako mogu previse ograniciti. Tele
fonski brojevi su clobar primer: upotreba ulaznih maski za te vrednosti izgle
cia kao clobro re5enje, ali se pre toga morate uveriti da sistem treba cIa
prihvata samo domace telefonske brojeve. Telefonski brojevi iz cIrugih clrza
va cesto imajn drugaCiji format. Cak i unutar iste clrzave, rnorate uzeti U ob
zir i moguce varijante - na plimer, brojeve lokala i pristupne brojeve iii
prosto clrugacije nacine pisanja.
Australiji Ine je nerviralo to !ito neki ljudi
formatiraju sedrnoc:ifrene brojeve kao 999-9999, dok drugi koriste format
99-99-999.)

N e zaboravite sledece: kaela l1gracll1jetc ulaZlIll 111<1sk1l,

\'am je da
korisnicima olaksate zi\'ot. Ako ill sprecm'ate dn lll1('Sll sa\Tseno iSpra\llC ali
lleocekivane vrednosti, time ill ometate pri melt!.
Osim stanclardllih poIja za tekst, i Access i Visual Studio poclrzuvaju
lIpotrebu kontrole Hich Textbox za ullosenje teksta 11 k0111e se koriste razli
citi fontovi i stilovi teksta. Programiranje kontrole Rich Textbox tcze je od
progrmniranja drugih kontrola jer morate obezbediti i interfejs knji korisni
ku omogucava da podesava svojstva teksta u kontroli.
OSlm vece slozenosti interfejsa, kontrola Rich Textbox povecava i sloze
nost rada s podacima jer su elementi fonnatiranja ugrac1eni u tekst u kont1'O
Ii. Zbog toga 1'reporucujem da upotrebu kontrola Rich Textbox ograniCite na
situacije u kOjima njihova doelatna fllnkcionalnost pruza nespornu korist.
Oism toga, koristite ih iskljuCivo za vrednosti koje
se tretirati kao blokovi
teksta koji se 1'rikazuju na raznim mestima, ali se ne pretrazuju nib spajaju s
drugim vrednostima.
Na primer, blokovi teksta formatirani pomocu kontrola Rich Textbox
mogu se koristiti kao sablonski pasusi teksta kOji se kombil111ju da bi se sasta
vila standarelizovana pisma. Pojedinacni pasusi se kombinuju II Rich Text
formatu, ali se cuvajll II bazi podataka kao obican, neformatiran tekst, a ko
risnik ih bim na osnovu opisa iIi kategorije.

iazetak
U ovom poglavlju, razmotrili smo razne vrste kontrola koje l110zete upotre
biti za 1'rikazivanje i unosenje podataka. Vas izbor kontrola treba da se 1'0
kla1'a s ko1'isnikovim mentalnim modelol11, a podatke koje ko1'isnik unosi
morate og1'aniCiti na prihvatljiv opseg vrednosti bel god to moguce.
U narednom 1'oglavljll razl11otricemo sta mozete uraditi ako ogranica
vanje poelataka pri unosu nije moguce, a razlllotricemo i kaela se i na koji na
cin moze obezbediti provera ispravnosti podataka.

Jdrzavanje integriteta
laze podataka
Zamislite da ste vlasnik male proizvodne Finne i da ste naporno radili na
preuzimanju jednog klijenta od vaseg veceg i poznatijeg konkurenta. N ajzad
ste uspeli da ubedite klijenta da vmn pokloni svoje poverenje, ali robu mora
te isporuciti u roku od 48 sati. U proizvodnol11 pogonu potvrdili su vam da
mogu da urade zahtevani posao (malo "tesno", ali ipak mogu) i vi otvarate
sClmpanjac.
Deset minuta kasnije, pojavljuje se problem. Izgleda da racunovoda
neee da potpiSe radni nalog dok klijentu ne bude odobren kredit, za sta je
potrebno nedelju dana, n bez potpisanog radnog naloga ne moze da pocne
proizvodnja narucene robe. Sta eete uraditi? Verovatno eete prvo pokusati
da objasnite racunovodi da situacija zahteva da se pravila malo prekrse. Uko
liko vam to ne uspe, objasnicete cIa je obaveza da kredit bude odobren
obrade porudzbine V(l.e pravilo, a posto je i firma vaa, mozete krsiti pravila
kad god smatrate da to treba da Cinite. Ako nikakvo ubeclivanje ne uspe, na
kraju cete idiotu uruCiti otkaz i sami srediti papire.
Iz pouzdanih izvora znam da su racunovode Ijudi kao i svi drugi, i da
imaju pOl'odice i kredite kao i mi ostali, pa je scenario kOji sam opisala malo
verovatan. Ljudi ne odbijaju tek tako dn izvrse nnreclenje svog sefa (iii barem
ne ccsto). Ali racunarski sistemi to redovno cine. Oni lupaju svojil11 l11alim
elektronskim nozieama, 1111'ste svoja mala elektronska liea i odbijaju da ispu
ne potpuno razumne zahtcve, sve 11 ime "odrzavanja integriteta podataka".
Posto sam u prethodnom delu knjige opisala 5ta je to integritet podata
ka, kako se modeluje i gde se realizuje, sad eu vam reCi nesto ;::.aista strasno:
odrzavanje integriteta podat aka nije zaista vaZllO.
Sada eu napraviti pallZU i sacekati da se utisaju povici negodovanja.

291

.\Ie tvrdim da treba da elilllillUfete proveru ispravnosti po(btaka, \"(::c

samo to cIa odrzavanje integriteta baze podataka znatno m,mje vazno nego
dOl korisnicima omoguCite da obavljaju poslove za koje Sll z,lcluzeni, a sistem
treba cia projektujete imajuCi to u vicIn. Poc!aci mOl"C\jll cIa Imdu ispmvni /I
nckom m;:;/llIIl1omrokll, ali ne moraju cIa budu sasvim ispmvni u trellutku
ul1osenja.
Stanite trenutak i razmislite zbog
razvijate sistem kOji 6e raditi sa
bazom podataka: da biste ljudima omoguCili cIa obavljaju oclredeni posao.
Dobra je ana provera ispravnosti podataka koja Ijudima pomaze cIa rade jer
podrzava ciljeve sistema. Nije dobra ona provera ispravnosti koja sprecava
korisnike da obavljaju poslove redosledom koji njima izgleda logican, ili koja
ih sprecava da urade nesto potpuno razumno, ali neocekivano. Kraj price.
Sistem koji projektujete ne sme nikada da sprecava korisnika cia unese
podatke zato !ito su nepotpuni ili zato !ito iIt niste ocekivali. Kao i mnogo toga
drugog, to je ponekad lakse reCi nego uraditi. U OV0111 poglavlju, razl11otrice
mo razne vrste uslova integliteta i kako za!ititu podataka od slucajnih gresnka
mozete da uskladite sa odrzavanjem pouzdanosti i upotrebljivosti sistema.

tlase uslova integriteta

U poglavlju 4 podelili smo uslove
(engl. integrity cOllstraints) u
cetiri kategorije na osnovu njihovog logickog nivoa n relacionom modelu.
U ovom poglavlju upotrebicerno drugaciju organizacijll. Uslove integriteta
podelic-emo II dye klase: primami uslovi i poslovni llslovi.
Primarni uslovi (engl. intrinsic constraints) odreduju fizicku strukturu
podataka i izvedeni su iz relacionog modela. Pravilo koje zabranjllje kori5l1i
eima da izbriSu zapis iz tabele Kupci ako s njim povezani zapisi postoje u ta
beli Porudzbil1e jeste plimami uslov, budu6i da je referencijalni integritet
funkcija relaeionog modela. Ako korisnik izhriSe zapis odredenog kupca bez
blisanja zavisnih zapisa 0 porudfbinama tog kupca, baza podataka postaje
neuskladena. Ako kasnije bude dod at nov kupae sa istim primamim kljucem
kao izblisani
"osiroteli" zapisi 0 porudfbinama hice - pogresno po
vezani s novim zapisom 0 kupcu. To se lako moze dogoditi ukoliko, na pri
mer, vrednost pIimarnog kljuca izvodite iz imena kupca.
Cak i ako se izblisana vrednost primarnog kljl1ca nikad ponovo ne llpO
trebi, zapisi siroci6 l110gu da budu razlog zbog kojeg baza podataka daje po
gresne rezultate. Upiti kOji izracunavaju ukupne koliCine artikala prodatih

tokOl11 datog perioda da\'a~e razlicite rczultate, na primer, II z<\visnosti oeI

toga cia Ii tabela Poruclzbine
iIi nije spojena s tabelom Kllpci. Da hi se
dobio spisak kolicina
artikla prodatog svakom kupcu, obicno 5e pruvi
prirodni spoj izmedu tabela Kupci i Porudzbine. U proracun ukupne proda
je bice ukljuceni samo zapisi iz tabele Poruclzbine za koje postoji odgovnra
juCi zapis u tabeli Kupci. Bucluci dn zapisi sirociCi iz tabele Porudzbine
nem~iu priclruzen zapis u tabeli Kupd, oni nece biti obuhvaceni prora
cunom. S druge strune, za zbimi izvestaj 0 prodaji kOji povezuje tabelu
Porudzbine samo s tabelom Artikli, ti zapisi sirociCi bite ukljuceni u pro
raCU11 0 ukupnoj prodaji. To znaci da ce na pitanje "Koliko smo prodali u ju
nu?" sistem davati dva
odgovora, u zavisnosti od toga kako je
formulisano pitanje, sto je neplihvatIjivo.
Poslovni uslovi (engl. business constraints) (poznati i kao poslovna
pravila, engl. business rules), s druge strane, izvedeni su iz prostora pro
blema. Poslovni usIov je pravilo koje zabranjuje da se pri blisanju zapisa 0
odreaenom kupcu automatsh'i blisu i sve njegove porudzbine iz tabele Poru
dzbine, osim kaela su one obraaene ili ponistene. POSlovl1i uslovi odreduju "to
5e ne radi u toj situadji", dok primami uslovi oelreauju "to se ne sme uraditi".
U praksi, razlika izmeau primarnih uslova i poslovnih pravila nije uvek
jasna, niti tako bitna. Bitno je to da je jedna klasa uslova za integritet podata
ka izvedena iz prostora problema. Ispunjavanjem uslova iz te klase poma
zete korisnicima, a mozete ih zanemaliti kada je to pogodno za korisnike.
Brisanje kupca za kojeg postoje nezavrsene porudzbine nije pogodnost - to
se vrIo lako moze pretvoriti u katastrofu. Ali eloelavanje sestog Clana grupi
kaela posloV1lo pravilo propisuje ela svaki poslovoaa moze imati samo pet
podreaenih
biti pogodno. Stavise, nemogucnost doelavanja sestog cla
na grupi moze cak biti veoma nezgoelna.
Sustina je u tome da neispunjavanje poslovnih uslova nece naskocliti ni
stabilnosti ni pouzdanosti baze podataka. Ako korisnik izbriSe zapis odreae
nog kupca i pri tome izbrise i sve njegove porudzbine, sistem je izgubio vaz
ne podatke, ali nijedan oel preostalih podataka u sistemu nije ugrozen.
Odgovarajuci
u tabelama Kupci i Poruelzbine mogu se vratiti iz re
zervne kopije
rucno ponovo uneti i sve ce biti ponovo u redu.
Dve klase uslova integliteta podataka - plimarni uslovi i poslovni uslovi
sistem mora obraaivati na razlicite nacine. Pril11arni uslovi se ne mogu
zanemariti bez ugrozavanja pouzelanosti podataka. Poslovne uslove l11ozete,
a cesto i treba, zane mariti ako to odgovara korisniku. U narednil11 odeljcima
razmotricemo eletaljno obe Idase uslova integriteta.

'rimarni uslovi
Klasa pravila ispravnosti kOja nazivam primarni llslovi uprmlja hzickom
strnkturoll1 baze podataka. Ta klasa obuhvata pravila koja oclreduju tip,
mat i velicinu podataka, prihvatljivost Null vreclnosti, ogranicenja
integritet entiteta i referencijalni integritet.

Tip podataka
Ako ste izabrali kontrole odgovarajuce vrste, u 110rl11alnim okolnostima ko
risnici ne mogu da ne ispune uslov za ispravnost tipa poclataka. Nisam n1ko
ga viclela da namerno pokusava da upiSe datum u polje Iznos za uplatu, niti
da upisuje tekst u polje za potvrdivanje. i\1edutim, neko bi mogao cia pokusa
da upiSe "jedanaest" u polje za tekst koje ocekuje numericku vreclnost, sto je
razlog zbog kojeg je toliko vazan izbo;' kontrole za ul10senje poclataka, h~o
sto SI110 videli u prethodnom poglavlju.

Format
Formatiranje podataka obiC!1O nije problem, naroCito kada mozete ponovo
formatirati sacIrZaj nakon !ito korisnik napusti polje (to se lako radi i II Accessu
i u Visual Studiju) ili postaviti ulaznu maskll koja kmisnikn vooi pri unosenju
podataka. Medutim, voclite raeuna dn ne nametnete previse ogranicavajuCi
format. Ako se uneti poclaci ne uklapaju sasvim u format koji ste definisali,
mozda je najbolje da pooatke uklopite u format sto bolje mozete i cla kmisni
cima prepustite cIa podatke doteraju kako smatraju da je najbolje. To ne treba
da radite ako je pogresan format znak pogresnih poclataka, ali takva situacija je
retka. Kmisnik kOji lIpisuje telefonski broj kao 9-9999-99999-99 mozda prosto
ima posla s novim eudnim telefonskim sistemom.

Velicina podataka
Uslovi za velicinu podataka - naroCito u poljima tekstualnog tipa - stalan 5n
uzrok problema. Bez obzira na to koliko ste velikoclusni bili, izglecla da se
uvek pojavi potpuno ispravan ulazni poclatak kOji ne oclgovara zadatoj velieini.
Ponekad mozete izbeCi problem krsenja pravila za velicinu ako koristite polja
tekstualnog tipa, kojima dodelite maksimalnu cluzinu (2.55 znakova) i zaclate
da im je velicina promenljiva. U Microsoftovom Accessu, sva tekstualna polja
su promenljive velicine. U SQL Serveru, morate iZliCito zadati tip polja VAH
CHAR. BuduCi da obe masine baze podataka dodeljuju prostor samo za stvar
ne znakove koji se smestaju u bazu podataka, nema gllbljenja prostora.

1pak, tekstualna polja promenljive velicine nisll pogodnCl za sve situacijc.

Prvo, moze bib obavezna odrcc1ena velieina. Na primer, maticni brojevi oso
ha uvek se sastoje oel 1:3 znakova. Ako korisnik unese matieni broj oel 10 ;:n<\
kOVCl, nije prob!'em u duzini; takav poclatuk je neispravan i bilo l)i pogresno
dozvoliti cIa se on unese u bazu. Drugo, zbog nacina na koji SQL Server
azurira zapise kOji sadrze polja promenljive velieine, rezultat njihove upotre
be mogu bib slabije performanse. U veCini situacija, pad performansi je za
nemarljiv, ali u aplikacijama u kOjima su veoma vazne dobre perfonmmsc, a
podaci se cesto azuriraju, bolje je da koristite polja fiksne velicine. (Nema
razlike u performansama pri dodavanjlt podataka, samo pri azurirarUlt.)
I najzad, iako veorna velika polja mogu da poboljsaju upotrebljivost apli
kacije, to nije uvek tako. Ponekad to moze imati veoma lose posledice po
upotrebljivost. Izgled ekrana maze se pogorsati (problem su naroCito izvestaji,
jer se pIikazani sadrZaj ne moze pomerati kao na obrascima), a pronalazenje
zapisa kOji sadrZe odredene podatke moze se pretvoriti u noellU lIIoru.
Kada dugacke vrednosti podataka nisu pogodne, pokusajte cIa smislite
konvencije iii pravila za rad s podacima kOji se ne uklapaju. Ako je ime kupca
predugacko da bi stalo 1.1 zadati prostor, 1.1 dogovoru s korisnieima mozete
smislisti razumne konvencije za skmCivanje, kao sto je izostavljanje nastavka
"d.o.o." i skraCivanje reci "kompanija" na "komp.. To ee pomoei ali neee
garantovati
da "Kompanija s veoma, veoma clugackim il11enol11 , d.o.o."
uvek bude uneta kao "Komp. s veoma, 'leoma dugackil11 imenom", a ne jed
nom tako, a drugi put kao "Komp. s veoma dugackim imenolTl, e\.o.o.

Null vrednosti
Nedostajuce vrednosti su jos jedna oblast u kojoj korisnici cesto imaju te
skoca s primamim uslovima. Null vrednosti smo detaljno razmotrili na dru
gom mestu, gcle sam pokusala cla objasnim da - po mom miSljenju Null
vrednosti treba dozvoliti gde god u stvarnol11 svetll postoji raZ1ll11an razlog
da vrednost bude nepoznata, iIi barem tamo gde Null vrednost neee uciniti
da podatak bude potpuno neupotrebljiv 1.1 sistemu. Ako odluCite da zanema
rite ovaj muclar savet, moracete da smislite kako ce sistem pomoCi jadnom
korisniku koji pokusava da unese nov zapis a nema sve potrebne podatke.
U ovom slucaju, problem je kada ce biti potrebni podaei kOje korisnik
unosi. 1z analize radnih procesa sistema znate da su odredeni podaci neopho
clni pre zavrsetka ocIredenog posla. Ali to ne znaci da su sui podaei neophoclni
za obavljanje svih poslova obavezno potrelmi i kada se clodaje nov zapis.
Podaci 0 bankovnom racunu zaposlenog potrebni su yam da biste 1111.1 isplatili
zaradu. Prema tome, polja za podatke 0 bankovnom racunu ne mogu biti
Null kacla dode dan isplate. Ali ne bi trebalo da sistem sprecava kOlisnika da

IInese zapis 0 novol11 zaposlcnolll, niti da obavlja druge poslov(:', samo zato sto
nemu has we poc1atke. Moze biti potrebno da korisnik pokaze iclcntifikacionu
brticu da hi I11U bio dozvoljell ulaz u zgradu. Podaci 0 bankoVll0l11 racnllu
llisll potrebni za tu aktivnost. Podaci 0 bankovnom racunu bice potrebni 1/
odredenom trenlltku, ali 11e obavezno prvog <lana stupanja na posao. Nemojte
dozvoliti da to bude uzrok haosa u sistemu; sve ce biti ispravljeno kad docle
vreme - 0 tome ce se ionako postarati sam zaposleni!
Ako ne zelite da prihvatite Null vrednosti, cak ni privremeno, najlaksi
nacin da resite taj problem jeste da zadate neku razumnu podrazumevanu
vrednost. Jedna mogucnost je da u semi baze podaka deklarisete jednu po
drazumevanu vrednost za ceo sistem. Druga mogucnost je da sistem korisni
ku ponudi grupu vrednosti - mozda "NEPOZNATO", "NEVAZNO" i
"UNETI KASNIJE". Ponekad i sam sistem moze da izracuna prihvatljivu
podrazumevanu vrednost.

Opsezi vrednosti
Zadati opsezi vrednosti drugi su uslovi odredeni na nivou atributa OSi111
Null vrednosti - s kojima korisnici imaju teskoee. Neki uslovi za opseg vred
nosti eksplicitno su definisani tipom podataka - na primer,
je najveea
vrednost koju moze imati polje tipa short integer. Kada tip podataka odredu
je opseg moguCih vrednosti, ne mozete uCiniti mnogo vise nego da korisniku
objasnite uzrok ogranicenja. Aka su neophodne veee vrednosti, u semi baze
podataka morate izabrati tip podataka kOji prihvata siri opseg vrednosti. Ne
preporucujem vam da vasa aplikacija pokusava da to odredi tokom rada.
Mec1utim, ako ste ogranicenje opsega vrednosti definisali u semi baze
podataka u obliku pravila ispravnosti podataka iIi uslova tipa CHECK, iIi ste
ogranicenje realizovali u kodu aplikacije umesto u semi baze podataka, vero
vatno je u pitanju poslovno pravilo a ne primarni uslov, pa zato imate vise
manevarskog prostora. (Poslovna pravila razmatramo u narednom odeljku.)

Uslovi za integritet entiteta i referencijalni integritet

Verovatno se secate da uslov za integritet entiteta obezbeduje da se svaki zapis
1110ze identifikovati na jedinstven nacin, dok uslovi referencijalnog integriteta
sprecavaju da zapisi referenciraju zapise kOji ne postoje u istoj iIi u drugoj ta
bell. Morate smisliti nacin da ispunite uslove za integritet entiteta i referenci
jalni integritet, a ua pli tome ne ometate kOlisnika bez potrebe. Uobicajen
naCin je da korisnicima omoguCite da biraju sa ponudene liste ispravnih vred
nosti. Medutim, kao sto smo videli u prethodnom poglavlju, to nije uvek mo
guee, najcesce zato sto bi Iista bila predugacka da bi bila upotrebljiva.

Kada nije 1l1og11ce iii llije prikladno ogmniciti korisnika na upotrclm po

llUl1ene liste stavki, proverite llnete podatke cim to bude mogllce i odmah
obavestite korisnika II sluc'~iu problema. Ako korisnik pokllsa cia llnese zapis
koji izgleda da duplim postojeCi zapis II bazi poc1ataka, u pitanju je problern
integriteta entiteta. Najbolji oclgovor sistema u tom slucaju bin bi da korisni
ku POlllldi da prikaze postojeCi zapis - iii samo odgovarajuca polja - i cia kori
sniku prepusti da odluCi da Ii je novi zapis zaistn dllplikat, kao na slici 19-1.

The record you have entered appears to duplicate an existing record in the
database. What would you like to do?
Open a new window displaying the duplicate record. None of the
data you have just entered will be lost. After examining the
existing record, you can choose to keep the record you Mve just
entered or discard ~ and continue working with the existing
record.
Continue working with the record you have just entered without
viewing the existing record. Both records will be added to the
database.
Add the record you Mve just entered to the database and flag it
as a possible duplicate. You can recall both records later by
choosing Review Duplicates from the Administration menu.

Slika 19-1 Ovaj okvir za dijalog omogu6ava korisniku da odluci da Ii je novi

zaista duplikat

Vodite racnna da kada plikazlljete postojeCi zapis, ne izgubite podatke

koje
korisnik uneo kao nov zapis. Prikazite postojeCi zapis II zasebnom
prozoru i prepllstite kOlisniku da odluci da Ii ce umesto novog zapisa zadrzati
postojeei. Obratite paznjll i na to da okvir za dijalog prikazan na slici 19-1
omogucava korisniku da nastavi unosenje podataka bez plikazivanja moguceg
duplikata. Korisnik mozda vee zna da postoji drugi zapis, pa zato nema potre
be da
ometate vise nego sto je apsolutno neophodno. (Ponavljajte zajedno
sa mnom: "Racunar nije najpametniji, racunar nije najpametniji, racunar ...")
Korisnik kOji pokusava da ostavi nepopunjeno polje primamog kljuca
predstavlja nesto drllgaciji problem. Cinjenica da polje primarnog Idjllca l1e
maze biti prazno, najbolji je argument kOji Zl1am u plilog upotrebe primarnih
kljuceva koje sistem sam geneIise. Upotreba polja tipa AutoNllmber (Identi
ty u SQL Serveru) omogueava da korisnici rade sta god smatraju potrebnim s
prirodnim primarnim kljucevima a da pri tome ne ugroze integritet entiteta,
niti referencijalni integritet. Ako upotreba polja hpa AutoNumber (ili Identi
ty) nije prikladna za sistem koji projektujete, morate obezbediti da kOlisnici

obavezno uneSll neku \Tednost u swIm polje ])limarnog kljul'<\, Jcdnosh\\'lle

podrazlll11evane vrednosti nisu upotreblji\'(~, zato sto hi podnv,ul11e\'ctn<t
vreclnost bila prihvacena samo jeclanput u svakoj tabeli, Mo;$ete nClpntviti tnko
da sistem izracunava potrebnu vrednost tokom rada, ali nko je tn vrcdnost
potpuno proizvoljna, onda mozete koristiti i polje tipa AutoNumher. Vasa
dina preostala mogucnost je da zahtevate da korisnik llnese prihvatljivu
vrednost.
Kada se pojavi problem referencijalnog integriteta, uzrok je obicno to sto
korisnik pokusava da referencira zapis kOji ne postoji. To moze biti nenamer
no na primer, korisnik je mozda pogresno napisao necije ime - iii moze biti
manje iii vise namerno. Korisnik je mozda prevideo da referem:inmi zapis ne
postoji ili jos nije zavrsio unosenje podataka. Okvir za dijalog sa slike 19-2
plikazuje jedan od nacina resavanja takve situacije. Taj ohir za dijalog pruzn
korisniku cetiIi mogucnosti: da dozvoli sistemu da doda nov zapis kOji ce on
oumah popuniti podacima, da dozvoli sistemu da doda nov zapis kOji ce 011
azurirati kasnije, da promeni I'eferencu, iii da kasnije ispravi referencu.

Open a new window displaying the new customer. Ail of the

detans that you have entered in the order will be copied to the

new record and you can add any additional information that you
j

have available.
Add the new customer to the database, and COpy all the details
you have entered in the ord..... The Customer window will not
open. Vou can update the customer information later by
choosing Customers from the main menu.
Return to the Orders Window, where you can specify a different
customer.
Add the order you have just entered to the
as incomplete. You can resolve the unknown
choosing Incomplete Orders from the Administration menu.
order wlil not be fiUed until you resolve the reference.

Slika 19-2 Ovaj okvir za dijalog omogu6ava korisniku da izabere sta de uraditi
ako referencirani zapis U05) ne postoji

Obratite paznju na to da korisniku nije ponudena mogucllost da zane

mari obavezu popunjavanja polja. Taj uslov se ne sme zanemariti .leI' bi baza
podataka mogla postati nestabilna, kao sto smo vee videli.

Ako korisniku ne mozete c1a prika;t,ete okvir 7. c1ijalog sa listOlll ispramih

umesto toga lllozete II okviru za dijalog cla prikazete listll stayj.;:j kojc
najpribliznije odgovaraju unetim poclac:imH, Postoji viSe algoritumH koji oba
vljaju tu vrstn pretraga, ocl obicnog SQL iskaza sa odredbo1ll LIKE, do prc
trazivanja P0l110CU funkc:ije SOUNDEX,
U nekim situacijClmH nije l1i potrebno prikazivati okvi1' za dijalog za resa
vanje problema referencijalnog integriteta, U stvari, uglavnom je bolje cia to
ne Cinite i tako izbegnete ometanje korisnika pri mdu. Ukoliko m07,ete s
voljnim stepenom sigurnosti predvideti cia ce korisnici zeleti da dodaju nov
zapis, kOji ce popuniti kasnije, a takode ste ugradili mogucnost ponistavanja
akcija u sistemu ako ste pogresno pretpostavili, sistem moze mirno
u po
zadini doda nov zapis i da od toga ne pravi dramu. Posto korisnik popuni
polja zapisa, mozete prikazati poruku 0 tome na statusnoj traci iii u okviru za
dijalog, ako zelite da poruka bude uocljivija. Ali, sta god da radite, nemojte
prekidati korisnike dok unose podatke, ako mozete da to izbegnete; to je
nepristojno i samo plasi korisllike.
Suprotan slucaj od korisnika koji pokusava da referencira nepostojeCi za
pis jeste korisnik kOji pokusava da izbriSe ili iZ111e11i referencirani zapis. Na
primer, korisnik mozda pokusava da izbrise zapis () kUpCll za kojeg postoje
nezavrsene porudzbine, iii menja vrednost SifreArtikla za artikal kOji se refe
rencira II tabeli StavkePorudzhine.
Mierosoftova masina
podataka Jet omogucava da se Iancano azuri
nmje i lancano brisanje referenciranih zapisa obavlja
korisnikove inter
vencije. U SQL Serveru istu fllnkcionalnost mozete obezbediti pomocu
okidaca. Ako automatsko lancano azuriranje i brisanje imaju smisla u vas oj
aplikaciji, njihova upotreba je svakako najbolje resenje. Medutim, ukoliko
samo korisnik moze da odluCi sta je najpliklaclnija akcija, obavezno mll
objasnite posleclice njegovog izbonl, kao na slici 19-3.
Okvir za dijalog na slid
omoguCava korisniku da poniSti brisanje,
da laneal10 izbrise zavisne zapise, iii da zavisne zapise dodeli drugom kupc:u.
Obratite paznju na to da okvir za dijalog upozorava korisnika cIa se otvorene
(nezavrsene) poruclzbine ne 1110gu brisati (sto je poslovno pravilo) i pruza
111U mogucnost poniStavanja tih porudzbina (!ito
U Sllstini krsenje posiov
!log pravila) iii njihovog prikazivanja.
U okviru za dijalog u kome korisnik bim dalju akcijll, l110zete takode
prikazati otvorene porudzbine iii sve korisnikove porndzbine. Cilj vam da
ko1'i511iku pruzite sto vise infonnacija kako biste I11U omoguCili da donese
ispravnu odluku.

Return to the Customers window without deleting the record,

Delete this CtJstomer', ord.r>. In order for orders to be deleted,
they must be either filled or cancelled. The system has not yet
determined whether any of this customer', orders are still
outstanding.
You can choose to automatically cancel any open orders or to
review them. If YOl.l choose to review open orders (the default),
the ,ystem will open another dialog box showing you the details
of any open orders it finds. This new dialog will allow you to
cancel and delete all the orders or cancel the operation without
losing any data in the UJstomer> or Orders file.

o Review Open Orders

o Automatically Cancel and Delete Open Orders
Open a dialog box listing all customers known to the system. The
order> that are currently assigned to this customer will be
red~signed to the customer you choose in the dialoQ box,

Slika 19-3 Ovaj okvir za dijalog omogucava korisnicima da biraju izmedu

ponudenih opcija i objasnjava posledice svakog izbora

'oslovni uslovi
U prethodnom odeljku razmatrali smo primarne uslove koji stite strukturu i
integritet baze podataka. Malo je toga sto mozete tlciniti da biste pOJ11ogli
kOlisniku kOji krsi primarni uslov. Podaci moraju, barem na duzi rok, biti us
kladeni sa zahtevima relacionog modela. Medutim, podaci kOji ne ispunjava
ju odreden poslovni uslov, sasvim su drugo pitanje.
Kao sto sam vee rekla, poslovne uslove izvodite iz prostora problema, a ne
iz samog relacionog modela. Imajte u vidu da je model podataka upravo to
pojednostavljen model dela stvarnog sveta. Kao projektant sistema, potru
dicete se najbolje sto umete da biste u svom modelu obuhvatili sve vazne
aspekte rostora problema, ali uprkos najveCim naporima, neeete uvek uspeti
u tome. Cak i ako je vas model savrsen u svakom pogledu, kada napravite nje
govu prvu verziju, poslovno okruzenje se menja. Da bi bio uspesan, vas sistem
mora biti u stanju da bez veCih problema obraduje neocekivane situacije.
Postoje dva razloga zbog kOjih bi korisnici 1110gli da pokusaju da unesu
podatke koje sistem ne ume da obradi: slucajno iIi zato !ito stvarnost ne od
govara 1110delu sistema. (Postoje zapravo tJi razloga, ako dodate i namernu
sabotazu, ali uprkos pesimizmu prosecnog sistemskog analiticara, sabotaza
je izuzetno retka a - u svakom slucaju - poslovna pravila nisu nabolji nacin za
resavanje tog problema.)

Nenamerno unosenje neprihvatljivih podataka

Ako korisnici nenamerno unesu pogresne podatkc:, \'elsa jedin<l briga da im
sto \'iSe olaksate resavanje prohlema, Najmanje sto 1l10zete 11Ciniti
c1a
objasnite u cenm je problem i 5ta bi trebalo uracliti cla se on resi. Tamo gde
je to moguce, trebalo bi cIa ponudite i druge opcije koje sistem mo~,e da
moze se prikazati bela kori
izvrsi. Na pIimer, okvir za dijalog sa slike
snik zameni mesta dana i meseea u clatumu. Taj okvir za dijalog pokusava dOl
pogodi sta je korisnik zapravo hteo cIa unese i omogucava mu cla pritiskom
na dugme izabere ispravljeni datum.
,':'_w~_.".~ .. -"',-'_'_'_'"

JrU~'k~;~~'D~
-e>/;

'"

"

v ____

~~._

~___

~.. "'/#
__

~;.,

_Ill.

The DeliYery Date specifies when the customer would like the goods to be
deliyered to the address specified in the DeliYer Address, Unfortunately. the
s';stem is unable to interpret the data you ha~ entered: 31/01/99. What
would you like to do?
[;;6.~~,~~(h~Q~ti'!!

Replace the date you have entered, 31101199, with the value in
the text box below,
New Delivery Date:
Add the order you just entered to the database and flag it as
Incomplete, Vou can change the Delivery Date later by choosing
Incomplete Orders from the Administration menu. The order will
not be filled untn the Delivery Date is changed,
Open the Help window, which will display more information about
the Delivery Date field and entering date values.

Slika 19-4 Ovaj okvir za dijalog objasnjava gresku do koje je doslo pri
unosenju podataka i ne postavlja ultimatume korisniku

Kada korisnik nenamerno unese pogreSan podatak, to moze zaista biti

slucajno, iii mozda zato sto nije razumeo sta sistem tacno ocekuje. Okvir za
dijalog prikazan na slid 19-4 ukratko objasnjava svrhu polia Delivery Date,
ali saddi i dugme za pom06 koje korisnika upucuje na detaljnije informacije,
o pomoei korisnicima bice viSe reci u poglavlju 21.

Stvarnost i model sistema

Drugi raz10g zbog kojeg hi korisnici unosili neocekivane poc1atke jeste to sto
se stvarnost ne pok1apa s modelom sistema. Nn primer, korisnik mozcla po
kusava da ispravi situaciju u kojoj je narucena raba vee dostavljena, ali iz ne
kog razloga porudzbina nije hila uneta u sistem. Datum isporuke u toj
porudzbini bice stariji od datuma porudzhine, sto moze biti krsenje poslov
nog pravila. Ako korisnicima ne pruzite odgovarajuee smernice, uneee prvi

heslllislcni datum
koji CC sistem pri]l\'atiti i time narusiti inti'gritet
haze poclataka. Zbog toga je u ntsem intereslI da detaljllo razlllotrite S\'C iZl1
zetke kojih sc mozde setiti; to ee korisni\..:ll p0l1106 da 1I\"ek llade pri!i\atljin)
problema. Slika 19-5 prikazuje moguc odgovor sistema kada kori
datuma porudzbine
snik unese datum isporuke (Delivery Date) stariji
(Order Date). U ovom primeru se pretpostavlja da podrazumevani datum
porudzbine sistemski datum ida korisnik u normalnim okolnostima ne moze
da menja sac1rzaj tog polja.

The Delivery Date specifies when the customer would like the goods to be
delivered to the address specified in the DeliYer Address. It must be on or
after the date the order is placed. The date you entered is before the order
date. What would you like to do?
Replace the Def:very Date you have eilteredJ 01/01/99) with the
value in the text box below.
New Delivery Date:
Replace the Order Date you have entered, 01131199, with the
value in the text box below.
New OeUvery Date,
order you just entered to the database and flag it as
You can change the Delivery Date later by choosing
Orders from the Administration menu. TMe order will
until tMe Delivery Date Is changed.
Open the Help Window, which will display more Information about
the Delivery Date field and entering date values,

Slika 19-5 Ovaj okvir za dijalog omogucava korisniku da promeni

podrazumevani datum porudzbine

Ne mogu sa sva poslovna pravila prosto zanemarivati. Neka se poslovna

pravila l1e smeJtt prekrsiti, na primer, zato sto cIata situacija ne 1110ze nastati,
iIi zbog internih propisa. Ali ponekacI pitanje nije toliko "cIa li" se odredeno
pravilo sme prekrsiti, vee "ko" to sme da Cini. Na primer, na slid 19-6, kori
snik je pokusao da unese poc1atke 0 sestom zaposlenom koji je direktno pocl
reden oclredenom poslovodi, Cime krsi pravilo cIa poslovoda ne moze imati
vise oc1 pet podredenih.
TekuCi korisnik nema ovlaseenje cIa prekrsi to pravilo. Ali u sistemll je na
raspolaganju drngi okvir za dijalog kOji omogueava da 11eko ko ima takvo
ovlaseenje unese lozinku i sifru ovlascenja - to bi bio neki visi rukovodilac:.
Posto ovlascena liea nisu na raspolaganju' uvek kada zatreba, prvi okv1r za di
jalog takoc'le omogucava kOlisniku da snimi tekuCi zapis u bazu, a saelrzi i
llputstva za naknadno unosenje sifre ovlaseenja.

By default, only five employees can report to a manager. The employee YOli
just entered would exceed that number, and you do not have the authority
to override the rule. What would yOll like to do?
Q

dialog box aHowing a passl,:.;ord and authorization code to

,d. Once this has been done, the new employee will be
the database.

employee you just entered to the database and flag the

as incomplete. You can enter the authorization later by
Incomplete Employees from the Administration menu.
Return to the Employees window, and specify a different
manager.
Open the Help window, which will display more information about
the Manager field and the authorization override process.

Stika 19-6 Ovaj okvir za dijalog opisuje da poslovno pravilo moze prekrsiti
sarno onaj ko ima odgovarajuce ovlascenje

Ako ugradite mogucnost krsenja poslovnih praviIa, time l110zete znatno

povecati upotrebIjivost sistema, ali po cenu povecanja slozenosti moclela
podataka. U OV0111 primeru, morali biste u tabelu Zaposleni dodati polje koje
ce sadrZati sif)'u ovIascenja, a uslov integriteta tog entiteta morao bi da refe
rencira sifru ovlascenja. Morali biste takoc1e cIa smislite neb mehanizam sta
vljanja zapisa na ,Jistu cekanja" aIm je odobrenje odlozeno. Moguce resenje
je da tabeli Zaposleni dodate polje 1ogickog tipa koje pokazuje da zapis (jos)
nije upotrebljiv. Pomocu tog indikatora mozete kasnije pronaCi neispravne
zapise, kada korisnik bude spreman da resi odlozene probleme, iIi mozete da
filtrirate zapise pri izradi izvestaja. Ponekad je kOlisno da znate zasto
nije upotrebljiv; u ovom slucaju mozete dodati polje za sifru razloga - na pri
mer, "OR" za "ceka se odobrenje rukovodioca" iii "OKR" za "ceka se odobre
nje kredita". Ovo drugo resenje pmh vecu fleksibilnost pri obradi zapisa.
Izmene koje je potrebno sprovesti zbog zapisa na cekanju mozda cleJuju
jeclnostavno - u vecem delu one to i jesu - ali mogu se odraziti na sistem na
neocekivane naCine. N a primer, da Ii zapise na cekanju treba uzimati U obzir
pri iz1'acli izvestaja? Polje sa sifrom razloga cekanja moze biti ko1'is11o kacla
oclredujete kako cete sastavljati te izvestaje jer omogucava da odreclite koje
bi zapise trebalo iskljuciti iz odredenog izvestaja iii upita.
Ako zapise l1a cekanju ipak ukljucujete u izvestajc i upite, moratc takoc1e
razrnisliti ne bi li trebalo da ih na neki nacin oznaCite kao nepouzcIane, mo
zda tako sto cete ih grupisati pod zasebnim naslovol11.
Ukoliko ste odlucili da se zapisi na cekanju, iii oclrec1ena vrsta zapisa na
cekanju ne ukljucuju u dati izvestaj, morate oclluciti i da Ii se iskljucuju i S

njirn<l povezani zapisi. Na primer, ako .ie problem z<lpis () jos neodohrenol1l
li hi trebalo iskljuciti saillo zapis 0 tom zapOSlellOl1l,
se5tolll zap05Ie110111 ,
iii zapise 0 svim zaposlenima koji su poclredeni tom poslm'octi'?
Morate razlnotriti sva takva pitanja pre nego sto se opredelite dOl ugrac1i
te mogncl1ost krsenja oclrec1enog poslovnog pravila. Ako takva mogucnost
postoji, povecava se upotrebljivost sistema, ali rezultujuce povecanje sloze
nosti sistema mozcla neee biti opravdano. U jeclnostavl1im sistemima moze
biti bolje da oclbacite zapis kOji krsi odrecleno poslovno pravilo i da taj izuze
tak obradite izvan racunarskog sistema. Ukoliko se opreclelite da izuzetne
slucajeve obradujete izvan sistema, to obavezno navedite U okviru za dialog
kOji prikazujete pri proved ispravnosti podataka. Nemojte prisiljavati kori
snika cla pogada sta bi trebalo da bude njegov slecleCi korak.

aazetak
U 0\'0111 poglavlju iznela sam neuobicajeno miSljenje da sistemi koji mde s
bazama podataka ne moraju obavezllo da ispunjavaju Hslove za integritet
baze podatakH. Razmotrili smo clve klase uslova: primarne llslove, koji odre
dlljU fizicku strukturll poclataka i izvedeni Sll c1irektno iz relacionog modela,
i poslovne uslove, kOji Sll izvedeni iz prostora problema.
Videli 5mo da je opasno dozvoliti korisnicima da krse primarne uslove,
ali i da je cesto opravdano dozvoliti da zapisi kOji ne ispunjav<\ju poslovne
uslove budu stavljeni 11a cekanje dok se problem ne resi. Naveli smo i neko
liko primera obrade zapisa koji su na cekanju.
U slede6em poglavljn razJ1lotric:emo razne aspekte izrade izvestaja na
osnovu podataka koje sistem odrZava.

Izrada izvestaja
Cinjenice uskladistene u bazi podataka postaju upotrebljive informacije
samo kada se kombinuju na neki smislen nacin; bez toga, one su bezvredne.
U OV0111 poglavlju razmotricemo kako moz.ete omoguCiti korisnicima da stva
raju te smislene kombinacije cinjenica da hi dobili infonnacije.

NAPOMENA: Kada u ovom poglavlju koristim izraz "izrada izvestaja", ne mi

slim samo na izradu izvestaja u stampanom obliku. Taj izraz koristim u sirem
smislu, da bih opisala pruzanje informacija na osnovu podataka uskladistenih
u bazi. Te informacije mogu imati oblik stampanog izvestaja, ali se mogu prika
zati i na obrascu iii u obliku skupa zapisa u tabelarnom obliku.

U vreme kada su racunari kostali znatno vise nego zaposleni, a racunar

sko vreme je bilo izuzetno redak resurs, sistemi kOji su radili s ba'lama pocla
taka generisali su u redovnim intervalima nekoliko unapred definisanih
izvestaja. Ako ste pozeleli da sistem uradi bilo sta posebno, mogB ste otpri
like samo da mastate 0 tome. Posto se 'laostatak u poslu prosecnog odeljenja
'la informaticku obradu merio godinama, ako yam je bio potreban izvestaj
"potpuno isti kao ovaj, samo sortiran po kupeu i sa ukupnim zbirovima po
mesecu", dali biste ga svojoj sekretarici da ga rucno prekuca.
Demas su racunari jeftini i ima ih svuda, a sekretarice su postale i'luzetno
redak resurs. Trebalo bi da sada korisnik bude u stanju da kaze racunarskom
sistemu "Voleo bih izvestaj isti kao ovaj, ali ..." a to znaCi da je POStlO projek
tanta baze podataka postao jos malo tezi. Ali ipak jos nismo stigli do toga da
se stvar svodi na diktiranje kratkih upustava. (Verujte na rec.)
Postoje dva opsta pristupa i'lradi izvestaja u sistemu kOji radi s bazom
podataka: 1110zete pokusati da unapred preclvidite sve moguce izvestaje ili da
omoguCite korisnicima da ih sami sastavljaju prema potrebama. U veeini si
stema neophodna je neka kombinacija oba pristupa.
Izvestaje koje mozete predvideti tokom faze projektovanja sistema, l1a
pravite u fa'li izrade sistema. Tu vrstu izvestaja zovem standardni izvestaji.

305

\fozetc smisliti i mehanizrne pomOCll kojih cc korisnici SHl11i praviti nO\e

i7.\'cstaje nakol1 uvodenja sistemall redovnu upotrebll, Ttl vrstu izvcstaja zo
vem ad hok izvestaji. U 0\'0111 poglavlju razl11otriCcmo obe vrste iz\'estaja,
ali Cemo prvo prou6iti nacine za sortirnnje, pretrazivHnje i filtrirnnje podata

ka potrebnih za izradu izvestaja,

'ortiranje, pretrazivanje i filtriranje podataka

Kada piSete SQL iskaze, sortiranje, pretrazivanje i filtriranje podataka rela
tivno je jednostavno: treba samo da zadate odgovarajuce uslove u odredbi
WHERE iii u odredbi ORDER BY. Meautim, kada tu mogucnost
cIa
pruzite korisnicima, l1lorate smisIiti neki mehanizam kOji ce posredovati iz
meau njih i logike SQL-ovog
SELECT.
Problem je to sto se SQL-ova logika slabo poklapa s govornirn jezikom.
Kada direktor prodaje traZi spisak svih distributera u NiSu i u Kragujevcu, on
ocelmje spisak na kome ee biti distributeri iz NiSa i iz Kragujevca, Ali SQL-ov
iskaz SELECT sadrzace odredbu WHERE Grad = "Nis" OR Grad "Kra
gujevac", Gramaticki je ispravan veznik"i" ali je u formalnoj SQL-ovoj sintak
si ispravan veznik "ili" (eng!. or). To korisnicima predstavlja veliku teskocu
SQL je dovoljno blizak (engleskom) govornom jeziku pa zhog toga
no zhunjuje.
Moguce je obuciti korisnike da sami pisu uslove za SQL-ove
SELECT. Znam barem jednog projektanta baza podataka kOji to redovno 6i
ni, prema opstem miSljenju, s puno uspeha. Mislim da je bolje da ustedite
sebi, piscima dokumentacije i (sto najvaZnije) korisnicima napor direktne
upotrebe SQL-ove sintakse, tako sto cete im obezbediti intuitivniji interfejs.
Sreeom, u toj oblasti niste prepusteni sami sebi. Microsoftov Access
saddi pdmere interfejsa za sastavljanje uslova za SQL-ove odredbe. Mada
ne mozete uvek kopirati jedan od tih mehanizama za interfejse direktno u
svoj sistem, ti mehanizmi su barem dobre polazne tacke i tako eu ih tretirati
u ovoj knjizi. Interfejs Microsoftovog Visual Studija ne poddava nijedan od
tih mehanizama ali, uz malo truda, mozete napraviti veCinu njih p01110eu Vi
sual Basicovog koda.

Sortiranje podataka
Access ima odlican interfejs za sortiranje podataka - komande Sort Ascen
ding i Sort Descending. K0l1snik miSem pritisne kontrolu zavisno od naCina
na koji zeli da sOltira podatke, zatim bira odgovarajucu komandu u meniju
Records iIi na paleti alatki. Tesko zamisliti jednostavniji interfejs.

Filtriranje po izabranoj vrednosti

Kac1a II pitanju filtriranje pochtaka, Access ima komandu Filter 13\' Selec
tion i njenog parnjaka, Filter Excluding Selection. lntcrfejs te (he komancle
vcoma slii~an komandama Sort Ascending i Sort Descending, Ako korisnik
izabere saclrzaj nekog polja na obrascu iii samo postavi kursor u poljc, a Z<l
tim izabere komandu Filter By Selection, Access flltrira
lZ lzvora
podataka za obrazac prema vreclnosti koja je jeclnaka onoj u izabranom
polju. Drugim reCima, uslov u SQL-ovoj odredbi WHEHE je <ime polja> =
<vrednost kontrole>.
Ako korisnik izabere samo pocetni cleo saclrZaja polja, Access ogranicava
poclatke samo na zapise u kojima vrednost polja pocinje izabranim znakovima,
Na primer, ako kOlisnik izabere prva tri znaka proizvoda cije je ime "Char
treuse velte", ekvivalentna SQ L-ova odredba WHEHE bila bi WHEHE [Pro
duct Name] LIKE "Cha"", U -plimeru baze -poclataka North\vincl, taj. upit
'"
uCitava zapise koji sadrZe imena proizvoda Chmtreuse velte, Chai i Chang.
Ukoliko korisnik izabere neku clrugu grupu znakova u polju, Access llci
tava sve zapise kOji sadrZe izabranu grupu znakova bilo gde unutar polja. He
cimo, ako u prethodnom primeru korisnik izabere "aI''', ekvivalentna SQL
-ova oclredba WHEHE bila bi WHERE [Product Name] LIKE"
. U pri
meru baze podataka Nortl1\vind, taj upit bi ucitao cleset zapisa prikazanih na
slici 20-1.

Slika 20-1 Ovi zapisi se ucitavaju ako korisnik izabere komandu Filter By
Selection kada
izabrano "ar" u polju Product Name na obrascu iii u
tabelarnom prikazu

----_.._--------_._------
NAPOMENA: Nemojte pretpostavljati da Access zaista izvrsava SQL-ove ko
mande SELECT kada korisnik izabere komandu Filter By Selection. Mislim da
se to desava, ali nisam sigurna. Niko ne zna sta smisljaju oni mudraci iz Acces
sovog razvojnog tima.
------------------------~

----

.....--~..

Filtriranje po obrascu
Filter By Selection je jednostavan i elegantan interfejs koji kmisnici lako savla
davaju, ali kOji ih ogranicava na filtJiranje po samo jednom pOljll. Korisnici
mogll da zadajll dodatne komande Filter By Selection da bi postepeno sllzili
rezultujuCi skup podataka, ali to moze da postane napomo. Za kOlisnike kOji
zele m06niji intelfejs za filtliranje podataka, Access ima komandu Filter By
Form. Slika 20-2 plikazllje obrazac Customers iz baze podataka Northwind
nakon sto je kmisnik izabrao komandu Filter By Form iz menija Records.

Slika 20-2 Komanda Filter By Form omogucava korisnicima da filtriraju

podatake po vise polja istovremeno.

U prozoru Filter By Form, korisnik moze da zada vrednosti za filtriranje

na viSe kartica u prozoru. Vrednosti zadate na svakoj kartici Look For k0111
binuju se pomocu logickog operatora AND, a one na zasebnim karticama Or
kombinuju se pomo6u logickog operatora OR. Taj pristup problemu ne
minise u potpunosti razlike izmedu jezicke i formalne upotrebe vcznika
AND (i) i OR (iii), ali je dosta blizu.

Kada ga otvOlitc, prozor Filter By Form priknzujc svako

za tekst sa
izvorl1og obrasca u obliku padajuce lsite koja saclrzi sve tekuce vrednosti u
polju. To ponasanje mozete iskljllciti ako svojstvo Filter Lookup polja za teLst
podesite na Never. Ako je u prozOnl Filter By Form plikazana padajuca lista,
zapisi kOji se uCitavajll moraju da sadrze tacnu vrednost koju je korisnik iza
bmo. Ukoliko je plikazano polje za tekst, tj. ako svojstvo Filter Lookup pode
site na Never, kOlisniei mogu da llneSll vrednost za koju postoji tacno
poklapanje ili izraz poput LIKE "CHAo" ili IS NOT NULL. Oelluka 0 tome
da Ii da u prozoru Filter By Form koristite padajuce liste, zmisi oel veliCine iz
vornog skupa zapisa (nemojte plisiljavati kOlisnika da eeka dok Access popuni
pad(~jucu listu sa 100,000 stavki) i fleksibilnosti koja je potrebna korisnicima.

Komanda Advanced Filter/Sort

Filtriranje prema obraseu, iii interfejs sliean tome, dovoljan je za vednu si
tuaeija. Medutim, ako vasi korisnici znaju da sastavljaju upite II Accessll ili
ako ste im pomocu svojstva Filter Lookup omoguCili da biraju vrednosti s
padajuce liste II prozol'll Filter By Form, a zelite i da im pri tome omoguCite
da zadaju izraze za uslove filtIiranja, moze bib koristan prozor Access Ad
vanced Filter/Sort, prikazan na slici 20-3.
Prozor Advanced Filter/Sort nudi deo funkcionalnosti prikaza Design za
upite: mogu se zadavati samo odredbe WHERE i ORDER BY iskaza SEL
ECT. Taj prozor ne omogucava cIa menjate osnovnu stl'llktul'll rezllltujuceg
skupa zapisa tako sto cete izmeniti listu polja iii spojiti dodatne skupove zapisa.

Field:

Sort:
Criteria:
or:

Slika 20-3 Access 2000 prikazuje ovaj prozor ako u bazi podataka Northwind
korisnik izabere komandu Advanced Filter/Sort u otvorenom obrascu Customers

Prozor Advanced Filter/Sort jeclall jc ocl interfejsa za flltril'llnje koji 11['

bib pokllsala cIa l1<lpmvim pomocll Visual Basicovog koch!. Pretpostavljam cla
je to izvodjivo, ali sVotka1-::o ne bi bila tl'ivijalna vezba. Ako vnm
potrebn<l
takva funkcionalnost, verovatno bi trebalo da izaberete Access
razvojnu
alatku iIi da pronadete neki proizvod nezavisnog proizvoc1aca koji se moze
ugraditi U sistem.

Microsoftov English Query

Ako kao masin11 baze podataka
SQL Server, razlllotrite upotrebu
alatke Microsoft English QuelY. ViSe od obienog interfejsa za sortinmje i fil
triranje, English Query je slozen interfejs za upotrebu engleskog govornog
11 bazi podataka.
Da biste ugradili English QuelY u svoju aplikaciju, potrebno je da p1'esli
kate jezik prostora problema u selllU baze podataka tako sto cete napmviti
ono sto English QuelY zove "elatoteka aplikacije". Izrada datoteke aplikacije
za English Query nije teska, ali nije ni trivijalna. SHeno ineleksu dobre dato
teke za pomoc, potrebno je da posvetite puno vremena predvidanju reei po
mocu kojih ce korisnici refereneirati entitete i atribute u semi.
Post~ napravite elatoteku aplikaeije, integrisanje English Quelya u apli
kaciju koja mdi s bazom podataka postaje jednostavno. Korisnikovo pitanje,
izrazeno govornim jezikom, aplikacija p1'osleduje l11asini English QuelY a za
tim kao odgovor elobija SQL-ov iskaz. Pa, to je tako jednostavno sarno u teo
riji. U stvarnosti, aplikacija mozc dobiti pOrukll 0 greki koja opisuje dOl je
ko1'i511ik (jer ko1'isnici su tako heativna mala bib) formulisao pitanje na
na<::in kOji masina English QuelY ne razume.
Kada je u oelgovarajucem okruzenju, English Query je eudesna alatka.
Ako imate slozenu semu baze podataka i puno korisnika pocetnika kOji salju
upite (a znaju engleski), interfejs kOji obezbeduje English QuelY moze biti
odlieno resenje.

zrada standardnih izvestaja

Gotovo u svakom sistemu kOji meli s bazom podataka postoji izvestan broj iz
vestaja koji 5e mogu unapred definisati. VeCinu tih standardnih izvestaja ot
kriccte tokom analize radnih proccsa, ali je korisno i da posvetitc izvesno
vreme razmatranju seme baze podataka zajedno s korisnicima da biste utvr
dili da Ii bi im i drugi izvestaji bili od koristi.

Izveitaji

obliku spiskova i detaljni izvestaji

svnki entitet u sistenllI razmotrite izraclu i izvestaja U obliku spiska j de

taljnih izvestaja. Izvestaj U obliku spiska samo je spisak svih primcraka
odredenog entiteta - tj. svakog zapisa u tabeli. Ponekad saclrzaj tih spiskova
mozetc urecliti abecednim redosleclom. Cesce ce trebati cla te spiskove gru
piSete na odrecieni nacin. Na primer, kupd se mogu grupisati po gradu, geo
grafskoj oblasti iii po prodavcu.
Ako predviciate da ce izvorna tabela za izvestaj sac1rzati vise ocl nekoliko
stotina zapisa, pruzite korisnicima mogucnost da stampaju sarno izabrani op
zapisa. Na primer, svaki prodavac ce najverovatnije zeleti spisak Selmo
svojih kupaca, a ne svih kupaca u sistemu.
Dok spisak prikazuje samo po nekoliko podataka iz svakog plimerka
entiteta, detaljni izvestaj prikazuje sve podatke (iIi barem veCinu njih) 0
odrecienom entitetu. Za ovu vrstu izvestaja, korisnicima treba da obezbedite
i
nacin da biraju zapisc za stampanje. Kontrola tipa lista s mogucnoscu
biranja viSe stavki, cesto je dobar mehanizam za biranje zapisa ier ne zahteva
od kOlisnika da bira samo susednc zapise.
Meciutim, imajte u vidu prakticna ogranicanja kontrola tipa lista. Ako ta
bela saddi hiljade zapisa, morate upotrebiti grupu od viSe takvih kontrola da
biste korisnicim<1 ol1loguCili da postepeno suzavaju opseg zapisa. Alternativa
da upotrebite drugu vrstu kontrole. Na primer, mozete razmisliti 0 upo
trebi polja za tekst koje bi imalo funkcionalnost slicnu onome 11 vVordovom
okviru za dijalog Print pomocu kojeg se zadaje opseg stranica za stampanje.
Ne bi bilo tesko omoguCiti stampanjc opsega zapisa razdvojenih clticol1l, nib
pojedinncnih zapisa razdvojenih zarezima.

Zbirni izveitaji
Nesto malo slozeniji Z<1 programiranje, ali cesto i korisniji, jcsu izvestaji koje
nazivam, "izvestaji na parce": zbirni podaci kombinovani i porecicni na razne
nacine. Procenat prodaje po mesecu iii po referentn, iii broj kupaca koji su
kupili pojedine kategorije artikala, primed su takve vrste izvestaja,
Zbirni izvestaji su dobri kandidati za graficko predstavljanje, Micro
sof'tov Graph i razne druge alatke nezavisnih proizvociaca veoma pojec1no
stavljuju izradu grafickih izvestaja. Mcciutim, preporucujem vam da izvestaj
u grafickom obliku pravite kao dO}JwHt tekstualnim podacima, a ne IImesto
niih. Tekstualni zbirni izvestaj 0 prodaji mozda i nije najrazumljivija SNar na
svetu, ali se moze izvesti u neku alatku za statistiCku analizu iii u program za
tabelarne proracune kao sto je Excel, radi daljc obrade.

Izvestaji preslikani iz obrazaca

Osim izveStaja izvedenih iz seme haze podataka, obrasce sistema smatrajte
takode izvorom korisnih izvestaja. U svoje projekte stamlardno lIgradujelll
mogucnost stampanja papirnih verzija veCine obrazaca iz sistema. To se Ialeo
programira, a korisnicima je od velikog znacaja jer im omogucava cIa prove
ravaju svoj rad ili da b1'zo naprave papirnu kopiju koju ce pokazati nekom
c1rugom.
Ponekad detaljni izvestaj 0 odredenom entitetu sadrz.i iste podatke kao
obrazac. U tom slucaju mozete upotrebiti detaljni izvestaj umesto da pravite
nov izvestaj preslikavanjem obrasea. Medutim, detaljni izvestaji najcesce
sadrZe dodatne podatke ili su drugacije fonnati1'ani nego izvestaji preslikani
iz obrasca. Izvestaji preslikani iz obrasca (engl. form-based reports) toliko su
jeftini i jednostavno se programiraju da korisnieima obicno obezbedlljem i
detaljne izvestaje i izvestaje preslikane iz obrazaca. Izvestaj preslikan iz
obrasca standardno se stampa kad kOlisnik pritisne dugme na paleti alatki, a
detaljni izvestaj je na raspolaganju iz menija (a mozda i sa palete alatki).

Interfejsi za izradu izvestaja

Nije tesko omoguCiti pIistup izvestajima iz korisnickog interfejsa. Kao i svaku
dmgu komandu, mozete je staviti na raspolaganje kOlisnicima \I tli oblilca:
preko menija, dugmeta na paleti a1atki iIi komandnog dugmeta na obrascu.
Komanda koja stampa izvestaj uvek mora jasno pokazati korisniku k(?ji
izvestc~ stampa. To je lako izvodljivo u meniju: dodajte ime izvestaja kao
stavku menija Izvestaji. Ime izvestaja mozete staviti i kao kratak opis (Tool
Tip) dugmeta na paleti alatki ili kao natpis na komandnol1l dugmetu, ali bi
bilo korisno da imenu izvestaja p1'ethodi glagolska imenica "Stampanje". Na
primer, "Spisak kupaca" je dovoljno kao stavka menija izveStaji, ali odgova
rajuCi ToolTip iIi natpis na komandnom dugmetu bio bi "Stampanje spiska
kupaca". Osim uskladenosti s \Vindowsovim preporukama, taj tekst jasno
opisuje korisniku da ce sistem odstampati izvestaj, a ne otvOliti prozor koji
prikazuje izvestaj.
Osimmesta na kome cete korisniku omoguciti pristup izvest<~iima, (u
meniju, na paleti alatki iIi pomocu komandnog dugmeta), 1110rate smisliti i
kaka. Sistem koji radi s bazom podataka cesto sadrzi desetine, pa cak i stoti
ne izvestaja i bilo bi besmisleno da ih sve navedete u jednoj ogromnoj koloni
menija. Srecom, obicno nije tesko ograniCiti spisak izvestaja samo na one
koji imaju smisla u korisnikovom tekucem kontekstu. Na primer, nije ve1'O
vatno da ce korisnik hteti da odstampa spisak loklanih telefonskih brojeva
zaposlenih dok je usred unosenja pOludzbina.

Ako smatrate cia hi ipak trebnlo

na istom mestu o1l10guCitc pristllp
s\'im izvestajima koji postoje u sistcrnu, lllozete napraviti ok"ir 7.<1 dijalog koji
prikazuje kategori7.ovaml listll izvestaja i omoguC<lvH korisniku cia
17.
\'estaj kOji zeli cIa odstmnpa To resenje moze bib c1obro i ako je korisnicima
potrebno cia stampajn vise izvestaja istovremeno, Kada im omogucite cia 11
okviru za dijalog sa izvestajim<l istovremeno iznbern proizvoljan broj izvesta
ja, mogu da pritisl1n dugme za stampanje sarno jedanput i da zatim nastave
da se bave svojim poslovima.
Za izvcStaje kOji se cesto stampaju kao komplet - kao sto Sll zbirni podaci
na kraju svakog meseca - koristim varijantu opisane tehnike: prikazujem ok
vir za dijalog u kome su vee izabrani izvestaji kOji se obicno stampajll kao
komplet. Korisnici mogn da dodaju dopllnske izveStaje kOji se stampaju
samo povremeno, iIi da iz izbora iskljuce neki standardni izvestaj,
nego
sto ceo kornplet posalju na stampac.
Pojedinacno navodenje svakog izvestaja u kompletu korisnicima narnece
malo viSe posia nego kad se izrada celog kompleta pokrccc pomoeu jcdne
stavke menija, ali smatram da je dodatna flcksibilnost uglavnom vrcc1na do
datnog pritiska na taster misa. Cesto se dogacla da se jedan izvestaj iz kom
pleta mora po novo odstampati zbog problema sa stampacem ili zato !ito je
neko prosuo kafu po njemu. Okvir za dijalog kOji prikazuje izvestaje Imo gru
pu, ali omogu6ava i da se svaki stampa pojedinacno, eliminiSe obavezu da
svaki izvestaj bude naveden kao stavkn menija ili, sto bi bilo jos
da sc
ceo komplet izvestaja ponovo stampa zato st~) je hilo problel~la s jednim iz
vestajem iz kompleta,

Problemi pri stampanju

Vas sistem mora uvek biti u stanju da se izbori s problemima sa stampacem
ili greSkama pri stampanju; zbog toga
uobiCajene sitllacije pri stam
panju mogu biti veoma tesko resive. Na primer, korisnik moze da pozeli cla
odstampa sve mcnne koji jos nisll odstampani. To je cest zahtev, ali je jedan
od najtezih za elegantnu obradu jer sistem ne moze znati da Ii je odredeni iz
vest,~j bio nspesno odstampan. Sistem zna samo da je posiao izveStaj u bafer
stampaca, sto je nesto sasvim razlicito.
Neki projektanti resavaju moguce probleme pli stampanju tako sto na
kon slanja izvestaja na stampac, prikazujll pornku s pitanjem da Ii je izvestaj
uspesno odstampan. To je upotrebijivo
ali zahteva da korisnik pre
stane da koristi sistem dok ne dobije u ruke sve odstampanc prilllcrke. Ako
se slucajno dogodi da se posao stampanja nade u redll za stampanje iza ne6
jeg prirucnika od 1000 stranica, korisnik ce morati prilicno da se naceka.

OSi111 toga, buduc'i da ec

jzY(::staja {!.otO(;O un~k hiti odstampana hez
problema"iz prve", cekanje je nepotreimo u 99 posta slucnjcva.
Probleme pri stampa11ju obraclujem kao izuzetke, sto oni zapra\'o i
Ako se vratimo 11a vee opis<lni primer, ukoliko sistem treba da odstmnpa
samo racune kOji jos l1iSl1 bili odstnmpani, ionako cete morati da clodate
polje u odgovarajucu tabelu. Ako sistem ocekuje cia korisnik potvrdi da su
racuni pravilno odstampani, potrebno je samo polje logickog tipa. Umesto
toga, lako je cuvati i datum ili broj posh stampanja. Potom mozete dodati
komandu koja omogucava korisniku da evidentira problem pri stampanju po
poslu stampanja iii po racullu.
Ako se izvestaj ne stampa vise od jedanput dnevno, kao indikator moze
te upotrebiti tekuCi datum. Meclutim, bezbednije je da umesto toga
risete jedinstven broj za svaki posao stampanja i da tu vrednost cuvate u bazi
podataka. Ako bilo sta krene naopako, korisnik treba da izabere smno odgo
braj posla stampanja a sislem ce u polje u kome se cuva ta vrednost
ponovo upisati Null. Zapisi koji sadrze Null bice automatski uldjllceni U
deCi posao stampanja. Druga mogucnost je cla sistem plikaze sve
kOji
su bili ukljuceni u nezavrseni posao stampanja i da korisnik izabere sa1110 za
1'ise koje zeli da 1'onovo odstampa.
Kako ce kOlisnik pe1'oznati odredeni posao stampanja? Broj posla stam
panja mozete pIikazati u podnozju izvest(~ja, ali ja radije clodajem U sistem
tabelu u kojoj cuvam naziv izvestaja, datum stampanja i (ako je poznato) fme
korisnika koji je pokrenuo 1'osao stampanja. To vam omogucava da korisni
efma prikazete razumljivu Iistu poslova stampanja umesto da ih terate cia
pamte broj koji im nista ne znaci. Potom ce vrlo lako izabrati "racune koje
sam stampao prosle srede ujutro".
Ponekad je problem ozbiljniji od toga da Ii ce dati zapis hiti llkljucen u
sledece stampanje jer je taj zapis deo radnog proeesa. Na primer, racuno
vodstveni sistemi ponekad obuhvataju i generisanje izvestaja kao sastavni
deo redovne obrade na kraju svakog meseca. Kada mesee istekne, neke
vrednosti se ponovo inicijalizuju i ne postoji nacin (iii barem nejednostftv(lil
nacin) ponovnog generisanja izvestaja. Smatrarn da je to izuzetno losa
jektna strategija, mada je cesta.
Zbog nepouzdanosti stampanja, trudim se da generisanje izvestaja i azu
riranje zapisa (osim aiurinmja indikatora "zapis odstampan") obradlljem kao
dve zasebne aktivnosti, sto i vama preporucujem. Ako je za radni
apsolutno neophodno da azuriranje zapisa bude povezano sa stampanjem
najbezbednije je da prekinete obradu u sistemu dok osoba kOjel
stampa izvestaj ne potvrdi da je uspesno odstampan.

Posto se potn(\inmje cIa je

stampallja USPCSllO Z<lvrsen moze oba
Y]jati i kao pozadillski proces, nemH potrebe da Z<lUShlvite sistClli dok posao
stampanja He bude potvrden. Na primer, mozcte postclViti na p<l]etll pos]O\'<[
ikonicll koja, bela je korisnik plitisne, prikazuje o1<:vi1' Zll dijalog u k0111e ko
risnik potvrduje uspeh i azurira tabelu. Ohavezno prikazite korisniku poruku
koja opisuje sta on treba cia uradi.

Automatsko stampanje i stampanje na zahtev

Dmgi vazan element pJi izradi standardnih izvestaja jeste pitanje treba li da se
stmnpaju na zahtev, automatsld iIi na oba nacina. Moje opste pravilo je da sve
izvestaje projektujem tako da se stamp(~iu na zabtev. Jedini izuzetak cinim
kada je sasvim jasno da je izvestaj sastavni deo radnog procesa, kao sto je menn
koji se stampa posto kOJisnik unese porudzbinu. Trebalo bi da takav izvest<~i
1
, . .
1
l' v

bl
v
v
b uoe
na raspomganJu
1 na zantev, rae I resaWlllJa pm' erna sa stampaClma.
Imajte u vidll da se izvestaji vezani za odredeni 1'adni proces, kao !ito su
menni, mogll stampati pojedinacno iii grupno. Na primer, racnn mozete stam
pati eim se unese odgovamjuca porudzbina, ili mozete formimti grupll neod
stampanih izvestaja koje cete odstampati kada se zavrsi unosenje porudzbina.
KOlistila sam oba resenja sa uspehom. Raeune ob1cno stampam pojedinaeno
ako kOlisnik ima lokalni stampac, odnosno grupno, ako je u pitanju mrezni
stampac. Verovatno bi najbolje bilo da kOlisnicima omoguCite da sami podese
naCin rada - konfiguracije stampaea podlozne su promenama.
Neki projektanti se opredeljuju za resenje 11 kome sistem automatski
stampa izvestaje kOji se stampaju u redovnim intervaIima na primer, sed
micno iIi na kraju svakog mesesa ali licno volim da i takve izvestaje po
desim da se stampaju i na zahtev. Projektovanje sistema za automatsko
stampanje izvestaja predstavlja slozen posao. Sistem mora da racuna kada iz
vestaji treba da se stampaju (uzimajuci u obzir vikende i praznike) ida prati
da Ii je izveStaj bio odstampan na tacan datum. Ako viSe Ijudi koristi sistem,
on mora takode da odredi koja kategorija korisnika ima ovlascenje da po
krece posao stampanja, i sta treba da uradi ako se 111 zahtevani datum nije
dan korisnik iz te k1tegorije ne prijavi u sistem.
U poredenju sa svim problemima koji se pojavljuju pri automatskol11 ge
nerisanju izvestaja, O!110guciti korisniku da kad mu zatreba - izabere u ne
kom meniju stavku Stampanje sedmicnih izvestaja, trivijalan je zadatak. U
5vakom slucaju, moracete da obezbedite odgovarajucu st1vku menija (ili ok
vir za dijalog u slucaju problema pri stampanju izvestaja), posto kori5nicima
morate pruziti mogucnost da ponove stampanje izvestaja u sluCaju problema
pri stampanju.

1\';la1o je verovatno cla ce kOlisnici zabormiti cla stampajll seclmil'nc, mc

scene iii tromesecne izvestaje, ali jc ipak korisno cIa im omogucite cia zadajn
period u kome izvestaj treba da 5e stampa, u slucaju cia ira).; zahorave. Ako te
ku6 peliocl zadate kao podrazumevani i omoguCite korisnicimCl cIa menjaju
tn vrec1nost, 1ako 6e mod cla isprave svaki previd. Tn telmika takode 01110
gucava cIa se izvestaji koji se stampaju u redovnim intervalima oc1stampaju i
pre kraja tekuceg pelioda. Moze biti korisna mogncnost poredenja prometa s
dode1jenim budzetom dok jos ima vremena da se nesto uradi n vezi s poten
cija1nim premasivanjem dozvoljenih troskova.

Izrada ad hok izvestaja

Hadni procesi koje je sistem kOji mdi s bazom podataka projektovan da po
cIrzi, ponekad su izuzetno dobro definisani i mozete unapred zadati sve iz
vestaje koje sistem treba da generiSe. Medutim, iSeSce cete montti da pruzite
korisnicima odredene mogucnosti da sami podesavaju ili prave izvestaje.
Koliko siroke treba da budu te mogucnosti zavisi oel potreba korisnika i
razlikovace se od jednog sistema do drugog. Stepen fleksibilnosti moze se
kretati II opsegu oel toga da korisnicima obezbedite pravu alatku za izmdu iz
vestaja, do toga da kOlisnic:ima sa1110 pruzite mogucnost cIa za unapred defi
nisane izvestaje sami zadaju uslove flltriranja podataka.

Alatke za izradu izvestaja

Dodavanje aplikaciji alatke za izradu izvestaja jednostavno je ukoliko lIlozete
upotrebiti komercijalnu alatku, bo sto je Access, ili proizvod nezavisnog
proizvodaca, kao sto je Clystal Reports.
Alatke za izradu izvestaja korisnicima pruzaju prakticno neogranicenll
slobodu za projektovanje kakvih god izvestaja zele. Nazalost, ta fleksibilnost
ima svoju cenu, Sustina problema nije toliko visoka cena alatke za izradll iz
vestaja, mada ako obezbedite puni primerak Accessa stotinama korisnika
kojima to zapravo nije potrebno - trosak svakako neee biti zanemarljiv.
VeCi je problem obnCiti korisnike da projektuju izveStaje POl1l0Cll sofisti
ciranih alatki. Korisnici ne samo sto moraju da znaju kako da sastave izvestaj
pomoen programa za izradu izvestaja, vee moraju harem povrsno poznavati
semu baze podataka kako bi mogli da pristupaju podacima koji im trebajll.
Nista od navedenog nije izvan dosega prosecnog kOlisnika, uz dovoljno v1'e
mena i odgovarajueu obuku. Ali ti Ijudi vec rade odreueni posao, a to nije iz
rada namenskih izvestaja.

Izrada namenskih izvestaja

Da bi postupak izrade izvest<~ia bio efikasan za korisnike, cesto je bolje ugmdi
ti namensku komponentu 70<1 izradll i7o\'estaja nego upotrebiti neku komercijal
nu alatku. TeOlijski, moze se progmmimti alatka 70<1 izraclu izvestaja koja pruza
istu fleksibilnost leao Accessov program za izraclu izvestaja, ali je plilagodena
semi haze poclataka s kojom sistem radio Meclutim, to bi bila skupa vezba i tes
ko je zamisliti situaciju u kojoj bi ona hila opravdana. Uohic,~jeno resenje je da
napravite odreden broj unapred definisanih sablona za izveSt'~ie i cIa kOlisnici
ma omoguCite cIa zad'~iu podatke koji ti izvestaji prikazivati.
Accessov carobnjak Report verovatno je previSe direktno povezan s rea
lizovanim modelom da bi se mogao kOlistiti za namenske izvestaje, ali pri
1~1er dobrog resenja za izradu unapred definisanih sahlona za izvesh*.
Carobnjak Report pruza veliki broj mogucnosti za formatinmje izveStaja,
izbegava veCi cleo slozenosti clizajna izvestaja tako sto korisnicima omogu
cava da hiraju sa liste unapred definisanih sablona i stilova izvestaja. Posto
carohnjak Heport genelise izvestaj, korisnici l110gu da ga dalje doteraju u
Accessovom interfejsu.
Kada korisnicima omoguCite da zasebno zadaju raspored elel11enata i stH
izvestaja, time il11 obezbedujete visok stepen kontrole. Druga mogucnost je
cIa unapred komhinujete raspored elel11enata i stiI na vise naCina da biste 1'0
jednostavili postupak izrade izvestaja. VeCini korisnika potrehni su "specijal
ni" izvest~~ji koji su zapravo samo vmijacije stanclradnih izvestaja. Drugi111
recima, potreban im jedan od onih cuvenih "isti kao onaj, ali ..." izvestaj, a
0110 sto sledi iza "ali" samo je drugaCiji nacin sortiranja iii Hltriranja podataka.
Metod koji koristim u svojim aplikacija111a potpuno je drugaciji oel onog
kOji koristi Accessov carobnjak Report. Ad hok izvestaj delim na dve k0111pO
nente, koje zovem "format" i "uslovi". Format oclreduje raspored i stH kOI11
ponenata izvestaja, kao i polja (pa prema tome i tabelu iii upit koji je izvor
pocIataka za izvestaj) koja ce se stampati. To je zapravo objekat tipa izveStaj
koji se u trenutku izvrsavanja aplikacije menja u zavisnosti od uslova koje
zada korisnik.
U slovi odreduju sortiranje i Hltriranje koji sc primenjuju na fonnat. Ko
risniku gotovo uvek omogucavam da us love uskladiSti u baw poclataka i cIa
ih upotrebi vise puta. Kako se to radi, videcemo u nastavku ovog poglavlja.
Ponekad je dobro i da korisnicima omoguCite cIa definiSu nivoe grupisanja
podataka, ali sam ustanovila da je to uglavnom nepotrebno.
BuduCi da korisnici zadaju samo dve komponente, namenske izvestaje
generiSem iz okvira za dijalog. Opsta struktura tog okvira za dijalog prikaza
na je na slici 20-4. (Ako se opredelite za taj metod izracIe ad hok izvestaja, iz
menite plimer tako da odgovara korisnickom interfejsu vaseg sistema.)

Customer Name:
Pefformance Against Budget

E.!QiD

Midwest Region

Northern Region

Southea,t Region
SouthweSI Region
Sales by Sales Rep

jJty:

Save Report

2101e:
Legion:

ilika 20-4 Osnovna struktura koju koristim da bih omogucila jzradu ad hok izvestaja

Okvir za dijalog je podeljen u tri odeljka. U Ievom odeljku, kontrola

TreeView prikazuje korisniku listu [ormata koje moze cIa izabere. C'mesto
kontrole TreeView, l110Zete upotrebiti kontrolu tipa liste ili cak grupu radio
-dugmadi. U navedenom primeru, formati su grupisani po kategorijama. Ta
tehnika je korisna ako imate veci broj formata. N a primer, grupisanje forma
ta u "Administrativni izvcStaji", "Mesecni izvestaji" i "Izvestaji 0 prodaji",
olaksava korisnicima pronalazenje izvestaja kOji im treba.
Najnizi nivo hijerarhije prikazane na slici 20-4 jeste "reports" (izvestc~ii).
Uovom kontekstu, izvestaj je kombinacija sacuvanih uslova i f~rmata. Na
primer, ako kao uslov za format izvestaja 0 prodaji
regiju jugozapad
("Southwesf'), korisnik moze sacuvati taj sablon izvestaja kao "Prod,~ja u ju
gozapadnoj regiji". Ako imate slozene uslove za izvestaje, ta mogucnost
moze korisnicima ustedeti puno vremena.
Srednji odeljak okvira za dijalog omogucava korisnicima da zaclaju uslo
ve sOltiranja i filtriranja. Ponekad cete moci cla u odeljku za uslove upotrebi
te same jednu grupu kontrola za zadavanje uslova za sve formate, mada cete
mozda morati da iskljucite kontrole neprimenjive na format koji je korisnik
odabrao. U drugom slucaju, za svaki format bice potrebna potpuno drugaci
ja grupa kontrola za zadavanje uslova. U svojim projektima, obicno biram
srednji put. Kao sto je prikazano nn slici 20-4, formate izvestaja delim u ka
tegorije, a kategorija odreduje kontrole za zadavanje uslova.
Desni odeljak okvira za dijalog na slici 20-4 sadrzi grupu komandne
clugmadi. Dugme Print prikazuje pomocni okvir za dijalog kOji omogucava
korisnicima da zadaju opcije za stampanje, kao sto je broj primeraka. Ako te
opcije nisu na raspolaganju, verovatno je najbolje resenje da postavite elva
komandna dugmeta, Print i Print Preview, i time ustedite korisniku dodatan
korak prikazivanja okvira za dijalog.

Komandno clngmc Save Or Hcstore Criteria prikazlIjc okyir za dija]og

slican 0I10111e net slici 20-,5. Taj jeclnostm'an oL-vir za dijalog prikazuje iste
kontrole za zmlavanje uslova kao aIle u srednjem odeIjku na glavllom obnt
seu za stampanje izvestaja. Uslovi kojc je korisnik vee uneo u hazu podataka
prikaz<lni su na /isti sa leve strane okvira 1',,1 dijalog. UsJov izabnm n<1 toj listi
prikazujc se u srednjcm odcljku. Dugme Save As... prvo zahtevH da korisnik
zada ime, a zatim upisuje u bazu podataka zadati uslov, dok dugme Hcstore
ucitava uslov u glavni obrazae.

F"

",-=""'~'"

1I:~~~~"W""..

;;

""C/"'A%'='fi'

~ g,@;~Bql'Y: 1 ~ J;Slve*9}tc~I~.I':8 Crl'terls '"

Midwest Region
Northern Region

~~heaSI Retion

mftMl$lillU

<-~

~",,0";;:6

',<"

-"'~fE:~!;;rI~tt~"

0l@t;mwI~_

~~%~'~lJf'&~1i'Ii.~ ':"~~!Ii~;~".~~1$r.,)k~~_

. Report Critelia Sales Reports

Customer !iam.:
.!:ill'

.5,tate:
Region:

Slika 20-5 Ovaj okvir za dijalog, koji se poziva iz glavnog obrasca za stampanje
lamenskih izvestaja, omogucava korisniku da uslove za izvestaje upisuje u bazu
)odataka i ucitava ih iz nje

Mogucnost upisivanja uslova u bazu podatak1 na opisani nacin prilicno

se lako program ira. Potrebna vam je s1mo po jedna tabela za svaku katego
riju, s poljem za svaku kontrolu u odeljku obrasea. Ako aplikaciju koristi vise
ljudi, morate odluCiti da li ce uslovi uneti u bazu podataka biti na raspo
laganju svima ili 6ete svakom korisniku omogu6iti da odrzava svoju grupu.
Ukoliko su uslovi deljeni, tabele treba da budu smestene u glavnu bazu
podataka, zajedno s drugim deljenim podacima. Ako svaki korisnik odrZava
vlastitu grupu uslova, tabele treba da se cuvaju lokalno, u ceonoj bazi poda
taka (Hi u lokalnoj bazi podataka ako je vasa aplikacija napisana II necemu sto
nije Mierosoftov Access).
Dve navedene tehnike nisu medusobno iskljucive. Mozete lako omoguCi
ti upotrebu i deljenih uslova i uslova koji pripadaju pojedinim korisnicim<l
ako imc korisnika dodate tabeli uslova iIi napravite uniju deljene i lokalne ta
bele. Ja obicno dodam deljenoj tabeli polje za ime kOlisnika jer je tako lakse
podrZati "lutajuce" korisnike, kOji sistemu pristupaju s vise racunara.

Upisivanjc llslova u haZll poclataka i llcitm'<lnje iz nie 01110gU(<\\'<I korisl1i

cima da to cine po kategoriiam<l, Uneti llslavi sc prcma tome mogll pri111e
niti na svaki izvestaj u dataj kategoriji (pod pretpostavkom
izveStaji dele
spedfikacije uslova),
Ponekac1 je prildadnije da se lls]ovi povezu sa odredenim formatom izve
staja, sta obavlja poslednje komanclno dugme na slid 20-4, To se takocle lako
programira. Potrebne su yam tabele za svaki tip uslov<1 (mozete upotrebiti ta
bele za cuvanje uslova u bazi ako ste obezbeclili tu funkcionalnost) i tabela
koja povezuje formate izvestaja u uslove. Stmktura je plikazana na slid 20-6.

ReportCategories
;ategorylD
;ategoryName
;ategoryTableName

ReportFormats
i CategorylD

Format'D
FormatName
LPhysicalN ame

CategoryCriteria
FormatlD
ReportiD
ReportName
CriterialD

lika 20-6 Struktura tabela koja omogucava korisniku da sacuva uslove i izvestaje; uz
), omogucava da se izvestaji dodaju sistemu i tokom upotrebe aplikacije

Tabela Kategorijelzvestaja sacldi polje ImeTabeleKategorija. To 01110

gucava sistemu da pronac1e tabelu koja sadrzi uslove za oclrec1enu kategoriju
formata. Ako svi vasi izvestaji imaju istu strukturn uslova, to polje nije neo
phodno. S druge strane, ukoliko s\i vasi formati imaju razlicite strukture us
lova, to polje treba da bude u tabeli FormatiIzvestaja.
Struktura tabela prikazana na slici 20-6 takode omogucava da se izvestaji
koji vee postoje u sistemu konfigmisu tokom upotrebe aplikacije, ceml.l sluze
polja ImeFormata i Fizickolme u tabeli Formatilzvestaja. Ako SD vasi fonnati
izvestaja definisani nezavisno, kao objekti u bazi podataka (kao Accessovi iz
vestaji) iIi kao zasebne datoteke (kao u mnogim alatkama nezavisnih pmiz
vodaca), mozete primeniti indirekciju kako biste omoguCili dodavanje novih
izvestaja u sistem u svakom trenutku. Da biste to obezbeclili, stavke liste for
mata k'aja se prikazuje U okviru za dijalog treba da poticu iz tabele FormatiIz
vestaja, a ne da buclu eksplicitno programirane u samoj aplikaciji.
Da biste dodali nov format izvest<'tja, treba samo cla napravite objekat
koji predstavlja format (u Accessu hi to bio izvestaj, iii clatoteka operativnog
sistema) a zatim cla clodate nov zapis u tabelu Formatilzvestaja. Novi format
ce automatski biti na raspolaganju bez potrebe da se bilo sta menja u njego
voj osnovnoj funkcionalnosti. Polje ImeFonnata sadrzi tekst koji se prikazu
je kOlisniku, dok polje Fizickolme saclrZi stvamo ime objekta, a mozda i
putanju ukoliko se objekti cuvaju izvan
podataka.

\letOll izracle n<llllcl1skih izvestnja koji sam o\'cle opisala, mada jeclno
stavniji za korisnike od prave abtke za izradu iz\'cstajOl, ipak viSe nego 'ito
jc potrebno za nekc aplikacije. Korisnicima najcesce treba 5amo mogllcnost
<lOl U stan<larclnim izvestajima povremeno zadaju dodatne uslove za filtri
ranje podataka. Takve jeduostavne uslove cesto mozete poddclti ako II na
mensld okvir za dijalog iz kojeg korisnik stampa izvcstaje dod ate nekoliko
kontrola za zadavanje uslova, umesto da pravite slozcniji namenski interfejs
za izraclu izvestaja kao ovaj kOji sam opisala.

Tipska pisma
Specijalna vrsta namenskog izvestaja jeste tipsko (cirkulamo) pismo. Ponekacl
je tekst tipskih pisama fiksan, ali je cesCi slucaj da koIisnici biraju sablonske
pasuse a sistem ih kombinuje da bi sastavio pismo. Bez obzim na to da Ii je
tekst fiksan ili ne, smatram da izvestaj iz baze podataka nije najbolji oblik
spondencije.
Mada mogucnosti fonnatiranja izvestaja iz baze podataka postaju sve
bolje, one se ne mogu meriti s mogucnostima formatiranja koje pruzaju pro
grami za obradu teksta, namenski projektovani za taj POS<:lo. Osim toga, veCi
na korisnika zeli mogucnost da pre stampanja pismu doda tekst, ali nije
dobro cIa im omoguCite cIa manipulipsu izvestajima iz baze poclataka jer bi
svaka izmena standardne struktrure postala trajna.
Bazu podataka svakako koristite za odrzavanje liste imena i adresa, pa
cak i za cuvanje sablonskih pasusa. Ali prenosenje tih podataka u program za
obradu teksta kao sto je Microsoftov \i\1ord omoguCava slozenije formati
ranje, a korisnici mogu da menjaju tekst pre nego sto ga odstampaju.
Srecom, prosledivanje tipskih pisama programu za obradu teksta postaje
sve lakse. Prosli su dani kada ste morali da se namuCite cIa biste poslali odgo
varajuce DDE (Dynamic Data Exchange) komande nekoj lose dokumento
vanoj aplikaciji, koja jos i odbija da saraduje. Na primer, u Wordovom
dokumentu danas mozete direktno da zadate Accessovu tabelu iIi upit kao iz
vor podataka za izradu cirkularnih dokumenata. Potom mozete upotrebiti
VBA (Visual Basic for Applications) programski k6d da biste u Wordov doku
ment llmetnuli podatke iz baze podataka i da zatim tako dobijeni rezultat pri
kHzete korisniku radi dalje obrade ili da ga posaljete direktno na stampanje.
U nekim okolnostima potrebno je da evidentirate tipska pisma koja je
generisao sistem. Ako korisnicima ne omoguc:avate da pisma doteruju pre
stampanja, nema potrebe da skladiStite generisana pisma u bazi podataka.
Treba samo da cuvate podatak 0 tome da je pismo generisano i mozela jos
datum i ime korisnika koji je poslao pismo. S druge strane, ukoliko korisnici
generisu pisma kombinovanjem sablonskih pasusa, taj postupak mozete mo
delovati pomocu slozenijeg entiteta, kao na slici 20-7.

Slika 20-7 Ova struktura moze da (Suva tipske pas use koji se ume6u u pisma

Ako sistem omogucava cloterivanje pisama pre stampanja, bolje je cla

pisma ne cuvate u bazi podataka, posto ni Access ni SQL Server nisu
naroCito efikasni pri obradi velikih kolicina teksta. Bolje resenje je da cuvate
samo mesto 1 ime fizicke datoteke dokumenta, ali to znaci da sistem mora
bib u stanju da prati premestanje, preimenovanje iIi brisanje te datoteke,
obicno tako sto ce zahtevati uputstva od korisnika.

tazetak
U ovom poglavlju razmotrili smo razne aspekte pruzanja informacija korl
snicima na osnovu podataka uskladiStenih u bazi podataka. To obicl1o znnCi
izradu stampanih izvestaja, ali moze da znaci i da se informacije predstavlja
.iu na obrascu iIi u obliku skupa zapisa u tabelarnom prikazu.
Prvo smo proucili tehnike za sOltiranje i filtriranje podataka koje postoje
u Accessu, prikazane tehnike su do
u Accessu. Cak i ako aplikaciju ne
bri primm'i one vrste funkcionalnosti koju biste mozda zeleli da pruzite kori
snicima.
Ispitali S1110 nekoliko vrsta standardnih izvestaja koje bi sistem mogao da
medu kojima su izvestaji u obliku spiska i detaljni izvestaji, zatim
izvestaji i izvdtaji preslikani od obrazaca u sistemu. Zatim smo raz
motrili kako se komande za izradu izvestaja 1110gu integrisati u korisnicki in
sistema, kao i neka pitanja obrade gresaka koje se mogu pojaviti pri
izvestaja. Izrada ad hok izvestaja opisana je nesto detaljnije, a predsta
vila sam i tehniku koju koristim kada treba cla obezbedim tu funkcionalnost.
I najzad, razmotrili smo izradu tipskih pisama kombinovanjem mogucnosti
za upravljanje podacima koje pruza hazel podataka s naprednim mogucl1osti
ma za formatiranje teksta koje pruza program za obradu teksta.
U sledecem poglavlju bavicemo se temom pomoCi korisnicima i prouci
cemo oblike te pomoci kOji se mogu ugraditi u korisnicki interfejs sistema za
rad s bazom podataka.

Pomoc korisnicima
U izvesnom smislu, sve sto je opisano u cetvrtom clelu ove knjige spada u ka
tegoriju "pomoe korisnicima". Kada projektujete korisnicki interfejs i birate
strukturu prozora i kontrole, trebalo bi da yam eilj uvek bude pomoe
snicima u obavljanju poslova za koje su zaduzeni. Na primer, veCina gradiva
iz poglavlja 19, 0 integritetu podataka, zasnovana je na pIincipu da sistem
treba da pomaze korisnicima da izbegnu greske, ali da ih pri tome ne ometa.
U OV0111 poglavlju detaljnije cemo razmotriti oblike pomoCi korisnicima koje
mozete da ugradite u interfejs aplikacije.

~ivoi

znanja korisnika
Vee smo razmohili hi kategorije korisnika sistema koje projektujete. Pocetni
d
da znaju ta sistem wdL Korisnici sa srednjim nivoom znanja
da
;::;Il(!jlt kaka se obavljaju odre(leni poslovi, a iskusni korisniei zele cIa znaju kako
mogu da br:::.o obave pOSHO. Za svaki nivo korisnika potrebna je drugacija vrsta
pomoei. Uvoclni ekrani i vodici kroz sistem koji su tako kOlisni za pocetnike,
ometaee korisnike srednjeg niova i biee dosadni iskusnim korisnicima.
Morate smisliti posebne mehanizme za podrsku svake grupe korisnika, i
najbolji naCin uporednog funkcionisanja svih tih mehanizama. Na pIimer,
trebalo bi da uvodni okvir za dijalog, kOji plikazujete pocetnicima pri pokre
tanju aplikacije, sadrzi polje za potvrdivanje "Ne prikazivati viSe", koje na
prednijim korisnicima omogucava da iskljuce pikazivanje tog okvira za
dijalog. Kratki opisi (ToolTips) i poruke na statusnoj traci, koji su priklaclni za
korisnike sreclnjeg nivoa, obicno ne predstavljaju problem naprednijim kori
snicima ali za svaki slucaj - mozete obezbediti i nacin za iskljucivanje
kih opisa i poruka na statusnoj traci. U OVOI11 poglavlju detaljno cel110 opisati
pIilagodavanje kOlisnickog interfejsa pojedinim vrstama korisnika.

323

Osim istovremenog postojanja vise razlicitih meh,mizama za poclrskll ko

risnicima, razmislite i 0 tome kako hi vas sistem mogno cIa pOl11ogne korisnikll
da prede s jednog nivoa znanja na c1rugi, Mozda raCllnate na c10kumentaciju
sistema i spoljnll obuku, ali to nisll zaista efikasni mehanizmi za poclizallje
nivoa stmcnosti, iz razloga koje cemo razmotriti II nastavku ovog poglavlja.
Bolje je da kOlisnicima pomazete neposredno preko interfejsa,
VeCina sistema, cak i umereno slozenih, omogucava pristllp svakoj ko
mandi na vise naCina, Na pJimer, lIpisivanje izmena zapisa 1I bazll moze se
ohaviti pomocll stavke Save iz menija File, pJitiskanjem dugmeta na paleti
alatki iIi pritiskanjem tastera Ctrl-S. Svaki od tih nacina zove se komandni
vektor, a svaki komandni vektor prikladan je za razliCit nivo korisnika.
Pocetniei i koJisnici srednjeg nivoa znanja skloni su upotrebi menija da
bi se podsetili koja je funkcionalnost na raspolaganju; korisnici srednjeg
nivoa znanja viSe ce koristiti dugmad na paletama alatki, a iskusni korisnici
k01istice tastere precice. Da biste korisnicima pomogli cia prec111 s jednog
nivoa znanja na drugi, mozete II celom sistemu stanclarclno prikazivati sve
vektore, za svaku komandll,
Slika 21-1 prikazuje standardni Accessov meni File. Obratite paznju na
to da stavka Save prikazuje sve komandne vektore za tu komandu. Mnemo
nik za pristup pomocll tastature, Alt-F-S, prikazan je podvucenim velikim
slovom S u reci Save. (F u meniju File takode je podvuceno.) Prikazana je i
ikonica za tu komandu na paletama alatki, kao i precica CtJl-S. Prikazi
vanjem svih vekton! komande u meniju, sam interfejs pomaze korisnicima
da nance bae naCine za obavljanje odredenog posla.

Slika 21-1 Standardni meni File u Accessu 2000 prikazuje sve komandne
vektore za komandu Save

NAPOMENA: Visual Studio .[\IET ne omogucava prikazivanje ikonica s paleta

alatki u stavkama standardnih menija, mada to nije tesko postici pomocu
menija tipa OwnerDraw. Na raspolaganju je i vise kontrola nezavisnih proizvo
daca koje podrzavaju ikon ice u svojim menijima.
Mehanizam za izradu novih menija u Accessu omogucava dodavanje iko
nica, ali je izbor ugradenih ikonica toliko smesno slab da cete gotovo obavezno
morati da upotrebite alatku Button Editor da biste sami napravili novu ikonicu.
I u Visual Studiju i u Accessu, vrlo se lako definisu precice koje se automatski
prikazuju u menjima.

Istovremeno prikazivanje vise komandnih vektora ne predstavlja pro

blem korisnicima jer je to pasivan mehanizam. Svi mehanizmi za pomoc ko
risnieima mogu se podeliti na pasivne mehanizme, koji su sastavni deo
korisnickog int.e]'[ejsa, reaktivne mehanizme, kOji se pokrecu kao odziv na
odre(lenu korisnikovu akeiju i proaktivne mehanizme, kOji pokusavaju da
predvide korisnikove potrebe. U ovom poglavlju razmotricemo sve navede
ne mehanizme, a zavrSicemo kratkim pregledom materijala za obuku i prila
godavanja sistema za pomoc korisniku.

Mehanizmi pasivne pomoci

Mehanizmi pasivne pomoCi obuhvataju sve naznake, pokazivace i objasnjenja
koje ugradite u korisniCki interfejs da biste vodili korisnike pri upotrebi apli
kacije. Za razliku od reaktivnih mehanizama pomoCi, mehanizmi pasivne po
moCi ne zahtevaju da korisnik nesto uradi - otuda i njihovo ime.
Posto natpisi na kontrolama, tekst stavki menija, pa cak i naslovi obraza
ea i okvira predstavljaju mehanizme pasivne pomoCi, trebalo bi da pazljivo
razmislite kakav cete sadrZaj dodeliti tim elementima. Izaberite tekst koji sto
jasnije opisuje akciju koja ce se izvesti iii podatke koje treba uneti.
Osim tekstualnih opisa, postoji i vise drugih mehanizama pasivne po
moCi. Razmotricemo samo tri: mnemonike za pristup s tastature, kratke opi
se (ToolTips) i statusne trake.

Mnemonici za pristup

tastature

Mnemonici za pristup s tastature pruzaju korisnieima i neposrednu funkeio

nalnost i pasivnu pomoc. BuduCi da omogucavaju korisnicima brzo kretanje
kroz sistem, pristupni tasteri obezbeduju neposrednu funkcionalnost. Posto

su ll\'ek p()(kuccni II natpisima na kontrolama, pristupni tastcri

risnicima i pasivnu p011106. Svaki korisnik s cak i llmerenim iskustH)11l S 'Vil1
clOWSOlll, poznaje princip "Alt-podvuceni znnk".
Trebalo bi da obezbedite mnemoniclee pristupne tastere za ,we stavke
menija i sve kontrole, Slova koja cete upotrebiti 7.<1 pristupne tastere birajte
po sledecem redosledu prioriteta:
1. Prvo slovo teksta stavke menija iii natpisa na kontroli.
2. Suglasnik u tekstu stavke menija iii natpisa na kontralL
3. Samoglasnik u tekstu stavke menija iii natpisa na kontroli.

Definisanje pristupnih tastera je tri\ijalan posao i u Accessu i u Visual

Basicu: ispred znaka u natpisu koji odgovara plistupnom tasteru dodajte
znak ampersend (&), {; oba okruzenja, sistem ce podvuCi taj zn1k u tekstu
natpisa i automatsld omoguciti pristup kontroli. (Uzgred, da biste u tekstu
natpisa prikazali
<lmpersend umesto podvucenog znaka, stavite dva am
persenda. "Roek & Holl" bice prikazano kao "RoclcHoll", ali "Rock &&
Holl" bice prikazano k1o "Hock & Roll".)

Kratki opisi
Kratak opis (TooITip) za dugme Save na Accessovoj paleti alath Form View
prikazano je na slid
Princip na kome se zasnivaju hath opisi vrlo je
jednostavan: oni igraju ulogu natpisa za dugmad na paletama alatki i za dru
ge kontrole koje nemaju natpise,

p,;ij M iCfOSOft Access

Slika 21-2 Kratki opisi objasnjavaju svrhu kontrola koje ne mogu imati natpise
na sebi

NEita stnlSno uzbudljivo, zar

Ali koliko god bili neuzbudljivi i jedno
stavTti, krath opisi znacajno uticu na upotrebljivost sistema. Aka ste ikada
morali cia izaberete slicicu za ikonicu koja predstavlja odredenu funkdonal
nost sistema, znate koliko je tesko da ikoniea tacno prenese potrebnu infor
maciju. Izbor ikonice za funkciju
nije mnogo tezak (iii barem viSe nije

za s\'e nas kOji Sl110 \idcli ikonicll diskete koja se koristi 11 ivlicrosof't:o\DI11 01'
(keu), ali sta izabrati za dugme "Otvanmie obmsca Kupci') ivlozete upotre
biti slicicu ljudskog prom", ali sta ako vam zatrebaju sliCice j za otvanmje
obrazaca Zaposleni i Spoljni saradnici? Vasi vizuelni modeli mogu postati
pomalo "n<ltegnuti".
Se6om, kratki opisi vas oslobadajl1 veceg dela pritiska da naclete ikonicu
koja je sam a po sebi razumljiva. Ako im date pola objasnjenja, ve6ina Ijudi
prilicno lako smisli kratku prieu kojom povezuje sliku sa odredenim POj1110111
na tom principu se zasniva jedan od metoda pamcenj<l imena Ijudi - a krat
ki OpiS1 1m pruzaju tu polovinu objasnjenja.
Dakle, u Aceessu ste upotrebili slicicu ribe da biste predstavili Kupee.
(Sta su projektanti Accessa imali na 1111111?) Kada korisnik prvi put vidi vasu
paletu alatki, ne6e nikad pogoditi da riba predstavlja Kupce, ali 6e kratak
opis objasniti znaeenje te ikonice. Ako tu asocijadju pojacate dosleclnorn
upotrebom iste slieiee na svim mestima gde se referenciraju kupd - II mc
nijima, na obmscima i u dokumentaciji korisnici ce se tome prilagoditi bez
ikakavih problema.
Da biste zadali kratak opis u Accessu iii u Visual Basicu, treba samo da
zadate vrednost odgovaraju6eg svojstva, Tekst kratkog opisa treba da bude
kmtak jedna do dve reel. Imajte u vidll da kratak opis deluje kao natpis na
kontroli: njegova svrha je da korisnike podseti sta kontrola predstavlja, a ne
cla ih obucava kako se ona koristi.
Ako kontrola duplira odredenu stavku menija, kao kratak opis upotrebite
istu ree iIi izraz kao u tekstu stavke menija. Ukoliko kontrola ne cluplira nijed
nu stavku menija, upotrebite ime iii glagol koji najbolje opisuje funkcional
nost kontrole i na osnovu kog se kontrola razlikuje od drugih. Na primer, ako
paleta alatki sadrzi bi dugmeta koja otvaraju obrasee Kupci, Dobavljaci i Za
posleni, mozete zadati kratke opise "Kuper', "Dobavljaei" i "Zaposleni". Uko
liko pak jedno dugme otvara obrazac Kupd, a drugo omogucava stampanje
spiska kupaca, bili bi yam potrebni kratki opisi "Otvaranje obrasca Kupei" (iii
mozda "OdrZavanje kupaca") i "Stampanje spiska kupaca" da bi se ta dva
dugmeta razlikovala.
Napomena 0 slicicama: Pri povezivanju slieiea s pojmovima, kao i u svim
drugim oblastima projektovanja korisnickog interfejsa, kljueno je biti dosle
dan. Svaku slicicu koja predstavlja odredeni entitet u sistemu, koristite do
sledno gde god se u sistemu referencira taj entitet, !ito vazi i za svaku slieicu
povezanu s odredenim glagolom.
N ajbolje je cla izaberete grupu sliCica za svaku kategoriju - entitete i
glagole ida kombinujete slieice iz obe kategorije gde god je to potrebno.

Na primer, ako hi trebalo da povezem slicic:u simhola X s akcijol11 brisanja

necega, a sliCicu Ijudskog proflla s tabelolll Kupct, superponirala bill jednll
slicicu preko druge da bih naznacila "Brisanje kupca", kao 11a slid 20-:3.

Slika 21-3 Kombinovanje slicica moze biti veoma izraiajno

Statusna traka
Statusna traka je cest mehanizam za pruzanje pasivne pomoCi korisnieima.
Vidljiva pri dnu prozora, statusna traka l110ze da prikazuje modalne inforl11a
dje, kao sto je stanje tastera NUl11 Lock i Caps Lock, iii da Ii je uJdjucen
rezil11 prosirenog biranja. Statusna traka takoae plikazuje tekst poruka na
menjenih k01isnic111a. Na shei 21-4 prikazana jedna od Accessovih statusnih
traka. Imajte u vidu sledece: posto je obrazac Categories l11aksimiran, statu
sna traka pri dnu prozora prividno je deo tog obrasca. Meautim, statusna
traka je zapravo sastavni deo sal110g Accessovog prozora.

Slika 21-4 Statusna traka nalazi se pri dnu glavnog Accessovog prozora

U Accessll se n:\ statusnoj traci lako moze prikazati opisni tekst za 5V,lk11
kontrolu na ObmSCll: treba smno pOdC5iti
StatllsBarText kontrole.
Ako izricito lle zadate vrecInost svojstva StatusBarTcxt kontrole
odreclenim polj(om tnbele, 11a stat~sno.i traci se prikazujc vrednost
Description tog polja (koju zaclajete u prikazu Design tabele). Meclutim,
liko ja zna111, u Accessu ne mozete iz programskog kocb zaclati tekst kOji se
prikazuje na statusnoj traci, pa se zato tekst na statusnoj traci ne moze upo
trebiti za cletaljniji opis stavke menija iii za cIrugu vrstu poruke korisnicima.
U Visual Basicu, tekst koji se prikazuje na sh1tusnoj traci zaclajete u
svojstvu Text odgovarajuceg panela kontrole StatllsBar. To yam omogucava
da na statusnoj traci prikazujete objasnjenja u celom sistemu, a ne samo cIa
opisete aktivnu kontrolu - kao u Accessu. Nedostatak te dodatne fleksibil
nosti jeste to sto tekst morate uvek zadati u programskom kodu i ne postoji
nacin da kontroli docIelite tekst koji bi Visual Basic automatski prikazivao.
Tacno je da taj dodalni posao rnoze biti closadan, ali je to mala cena koju tre
ba platiti za siIu funkcionalnost.
Najveca precInost statusne trake je to sto ne ometa korisnike dok racle.
Za razliku od prozora s porukom, statusna traka ne blokira upotrebu tasta
ture, niti
cIa je kOlisnik ukloni sa ehana. U stvari, u Accessu (i Visual
Basicu, ako ugracIite tu funkcionalnost) korisnik moze zadati da se statusna
traka ne prikazuje.
U Visual Basicu, statusnu trakll mozete llpotrebiti da korisnicima prilm
zujete opsirnije opise iIi cIa ih obavestavate 0 toku procesa koji se odvijaju u
pozaclini. Statusnu traku mozete iskoristiti i za prikazivanje poruka 0 greska
ma, macIa pri tome morate voditi racuna cIa ce korisnik mozda isldjuciti pri
kazivanje statusne trake. Nije dobro da statusnu traku koristite za bilo sta sto
korisnik mora da vicIi. Cak i ako je statusna traka vidljiva u glavnom prozoru,
korisnici mozda nece uoCiti poruku prikazanu na njoj.
Prikazivanje poruka na statusnoj traci ipak ima svrhe. Ako, kao sto sam
preporucila u poglavlju 19, zapise kOji ne ispunjavaju uslove integriteta po
dataka ne ocIbacujete nego ih pdvremeno obelezavate kao sporne, statusna
traka je dobro mesto da prikazete opis problema i nacina njegovog resa
vanja. SadrZaj problematicnog polja ponekad prikazujem crvenim znacinm,
a kada korisnik izabere to polje, na statusnoj traci prikazujem opis problema
i predlog resenja. Posto je prostor na statusnoj traci ogranicen, takode sta
vljam na raspolaganje i okvir za dijalog sa opsirnijim uputstvima, koji se obic
no pojavljuje kada korisnik pritisne odredeni funkcijski taster.
Visual Studio .NET podrZClva kontrolu ErrorProvider, koja pmza istll
funkcionalnost (isticanje problematicne kontrole i prikazivanje poruke 0
gresci) u malo drugaCijem obliku. PrecInost upotrebe te kontrole ie znatno
manja kolicina programskog koda.

Mehanizmi reaktivne pomoci

l\Iehani7ol11i reaktivne p01110(:.i, 70a ra70liku od paSinlih mchanizama, stupaju u
dejstvo SHJllO 1.::ao odziv na neku korisnikovu akc.:iju. Korisnic.:i srednjeg nivoa
znanja iIi napredniji korisnic.:i verovatno ce viSe upotrebljavati reaktivne 111e
hanizme nego pocetnici, kOji mozda ne znaju kako dOl ih pokrenu, niti da
uopste postoje. Zbog toga to nisu narocito dobri mehanizmi 70<1 pomoc bpa
"a cemu ovo sluzi?", koja je neophodna pocetnicima.
Vecina reaktivne pomoci na raspolaganju je u nekom obliku neposredne
1'01110Ci (eng!. on-line help). Postoji vise rnodela za plUzanje neposredne po
11106, au OV0111 odeljku razmotricemo dva: tradicionalnu neposrednll pomoc
i noviji mehanizam saveta What's This. Mada se retko tretiraju kao tal<ve, po
ruke 0 greskama takode su jedan od oblika reaktivne pOl11oci,
cemo
obraditi nn kraju ovog odeljka.

Neposredna pomoc
Mehanizam tradicionalne neposredne pomoci u sustini je preslikavanje
stampane dok1ll11entacije u oblik upotrebljiv neposredno na racunaru. Kao
sto se gotovo uvek dogada bda se obezbeduje racunarska poclrsb za obje
kat iIi aktivnost iz stvarnog sveta, to preslikavanje olaksava neke stvari, dole
druge otezava.
Mehanizam za neposrednu pomoc koristi se lakse od stampane doku
mentacije, a mogucnost da se jednim pritiskom misa prikaze deo gradiva
kOji se referencira na tekucem ekranu, svakako je velika prednost. S druge
strane, mehanizam za neposrednu pomoc teze se pretrazuje, a i ne mozete
poneti sa sobom da biste ga l1a
prelistali LIZ soljll knfe.
Pazljivim projektovanjem sistema za neposrednu pomoc mogLl se do
nekle ublaziti njegovi nedostaci. (Medutim, on ce i clalje biti prenosiv koliko
je prenosiv racunar na kome je instaliran.) Projektovanje i pisanje sistema za
P0l110C vrIo je opsirna tema, Ciji veCi
izlazi izvan okvira ove knjige. Ovde
vam mogu dati samo nekoliko smernica, istaCi nekoliko speeificnosti pisanja
pomoci za sisteme koji racle s bazama podataka i uputiti vas na bibliogranju
ako vam trebaju detaljnije informacije.
Prva i najvaznija cinjeniea 0 kojoj
cla vodite racuna kada projektu
jete neposrednu pomoc za svoj sistem jeste sledeca: bez obzira na to koliko
je ta pomoc tesno integrisana u sistem, nemojte je nikad smatrati sastavnim
delom korisnickog interfejsa. To znaci da sistem mora biti samostalan i ne
sme ni u kom slucaju prisiljavati korisnika da pretrazuje neposrednu pomoc
(niti bilo koji drugi oblik dokumentacije) kako bi obavio odredeni posao.

Imajte \I \'idu da po[etnici mozda neel' nll'.lll11eti sta sadr7.i sisLem I'.a nc
posrednu P0I110C, pa se zato l110zda nece setiti cIa pritisnu taster F 1 kada ih
nesto zbl\ni. Mehanizam za neposrednu P0l110C smatrajte jednil11 od oblika
pomoCi koju pruza sam sistem, a ne kao zamenu za tu POl1loc. Projektanti
precesto smatraju da ih ugradnja mehanizma za neposrednll p01110e 0510
bac1a obaveze da nap rave sistem kOji je razumljiv sam po
Prem<l mom
iskllstvu, to je greska Cija je posledica ruzHn i neupotrebljiv softver.
Sledece sto treba da razmotrite kada projektujete mehanizam za nepo
srednu pomoc jeste u kom obliku cete pruzati tu pomoc. Teme neposredne
pomoCi mogu se grubo podeliti u dve vrste: orijentisane na obavljanje poslo
va i orijentisane na funkcije sistema. Teme orijentisane na obavljanje poslova
objasnjavaju korisnicima kako da obave odredeni posao, kao sto je stampanje
racuna ili zakazivanje sastanka. Teme orijentisane nc~ funkcije sistema detalj
no opisuju pojedine funkcije (kao sto je komanda Stampanje u meniju Iz
v ,) .,. I
1
I
1
,1
;t..{'
or
1
\
veStaJI
111 <OntrOle \l)OlJe za reKst LlUnU\.UpcU lIa 0 )nlSCU). Te
vrste
odgovanlju otprilike Uputstvu za korisnike i HeferentnOl1l prirueniku u
stampanoj dokllmentaciji.
Oba naveelena oblika p0l110Ci imaju svoje uloge u podrsci sistemima koji
rade s bazama podataka. Ako sistem kOji projektujete podrzava veCi broj rad
nih procesa, iii su raclni procesi koje sistem podrzava slozeni, P0J110C orijen
tisana na obavljanje poslova moze biti dragocena jer korisnicima sistema
pruza neku vrstu "mape" procedura u sistemu. Medutim, i dalje je vazl10 da
unutar samog sistema obezbedite pomoc i vodie za korisnika. Neprihvatljivo
da korisnicima samo prikazete abecedni spisak obrazaca kao onaj u Acces
sovom prozoru Database i da mehanizmu za neposrednu pomoc prepnstite
ela korisnicima objasni kOjim redosledom trebu da popunjavaju te obrasce.
(To svalmko ne bi bilo prihvatljivo kada biste mdili za mene.)
U ielealnom slueaju, teme orijentisane na obavljanje poslova ne bi treba
10 ela sadrze konceptualni, niti uvodni materijal. Ne zaboravite, to nije prava
alatka za objasnjavanje kOlisnicima sta sistem radio Jedina svrha tema orijen
tisanih na obavljanje poslova jeste da ukratko opiSu "kako" odredene proce
dure, a ne da objasnjavajll njeno "sta", niti "zasto".
AIm za slozene oblasti
vise tema pOl11oei, one ce biti eitljivije na
ekranu racunara. Ukoliko je radni proces kOji objasnjavate slozen i postoji
vise nacina da se obavi, najbolje
da i ne pokusavate da objasnite sve tc
nacine u jednoj temi. U glavnoj temi objasnite samo najjednostavniji iIi naj
uobicajeniji naein i postavite hiperveze koje vode ka temamH u kojima su
opisane varijac:ije.

Dok teme orijentisane nil obadjanje poslov<l OpiSlljU "kako", teme ori
jentisane na funkcije sistema opisnju "sta" i "zasto". U sistemimH koji rade s
bazmna podataka, veCina tema orijentisanih nn funkcije sistema oc1l1osice se
na elemente podataka i kontrole umesto n<1 same funkeije. Na primer, II
malo sistema kOji rade s bazama podataka bice potrebne teme kao sto su one
u Accessovom sistemu za pomoc, gde .ie, na primer, potrehno objasniti pre
ciznu sintaksu funkcije Mid$.
U tim sistemima neophodne su teme koje objasnjavaju znacen.1e svakog
entiteta i atributa u sistemu, kao i uslova kO.1i vaze za svaki mectu njima.
Mogu biti potrebne i teme ko.1e objasn.1ava.1u naCine upotrebe raznih vrsta
kontrola u sistemu na primer, kako se koristi kontrola tipa Tree View, iii
kako izabrati datum pomocu kontrole Calendar.
Kada planirate teme koje se odnose na podatke, vazno .1e da razmotrite
zbog cega bi korisnici zatrazili pom06. Ako koIisnik ima pred sobom obrazac
Porudzbine, l1a kome se nalazi pol.1e za tekst s natpisom "Zeljeni datum do
stave", zaista je izuzetno malo verovatno da ce pritisnuti taster F1 zato !ito ne
razume da .1e to datum na kOji bi korisnik zeleo da mu roba bude isporucena.
Ako .1e to sve sto objasnjavate u temi pomoei, ona je gora nego beskorisna
to .1e razlog gubl.1en.1a nerava i vremena,
Dakle, zbog cega bi korisnik pritisnuo F1? Mozda zato sto ne raZ\lme
zasto je datum vee popunjen ob.1asnite mu sta pedstavlja predlozena vred
nost i kako moze da je zameni. IIi, mozda Il1U je kupac rekao da zeli da mu
roba bude dostavljena "bilo kad posle plvOg u mesecu" pa objasnite cIa t!'e
ba da upiSe najraniji datum iIi drugo pravilo koje vazi u vasem okruzenju. Sto
bol.1e razmotrite pitanja koja kOlisnici mogu postaviti, toliko ce efikasniji biti
vas sistem za pomoc.

Saveti tipa What's This?

Saveti tipa 'What's This? veoma su slic:ni neposrednoj pomoCi orijentisanoj
na obavl.1anje poslova, osim po l1acinu prikazivan.1a. Saveti tipa What's This?
prikazuju se kada misem plitisnete ikonicu znaka pitanja na naslovno.1 traci
prozora, a zatim pritisnete jednu od kontrola 11 prozoru Na slid 21-,5 prika
zana je pomoc What's This? ko.1a se odnosi l1a polje za potvrdivanje u okvil'U
za dijalog Options Accessa 2000.
Dopada mi se osnovna ideja saveta What's This? jer su tako tesno inte
grisani u kOlisnicki interfejs sistema, Videla sam vise puta da pocetnici slu
cajno aktiviraju savet What's This? Nikad niS<1111 videla da pocetnik pokrene
sistem za neposrednu pomoc zato sto je slucajno pritisnuo F1, a verujem da
bi bio i malo preplasen kada hi to ueinio, zbog onih cudnih prozora ko.1i bi
odjednom poceli da se po.1avl.1u.1u po ekranu.

o Hidden objects
o System objects
EI Windows in Taskbar
Select to see an icon displayed on the Windows
taskbar for each open database object or window. To
use this feature, you must install Microsoft Internet
Explorer Active Desktop.

Slika 21-5 Saveti What's This? prikazuju se u okviru za dijalog kada pritisnete
dugme sa znakom pitanja na naslovnoj traci, a zatim pritisnete jednu od
kontrola na obrascu

U jednostavnim sistemima, dobra grupa tema vVhat's This? moze bib sve
sto je potrebno, naroCito ako sistem ne poddHva veliki broj slozenih radnih
procesa. Medutim, tekst saveta What's This? mora bib prilicno kratak, buduCi
cla se plikazuje preko prozora u kome je aktiviran i ne 1l1oze se pomerati. Ako
treba da objasnite slozenije uslove, necete imati clovoljno prostora i temi
What's This? moracete da clodate jednu iIi vise duzih tema u sistemu za ne
posrednu pomoc. (Ne zaboravite da na kraju teme What's This? clodate reee
nicu "Pritisnite FI za opsirnije objasnjenje" ili nesto slieno,)
Pitanje na koje tema What's This? pokusava da odgovori - kao sto ste
verovatno i sami pogodili jeste "sta je ovo?" Savet What's This? zamislite
kao natpis na kontmli koji je dugaeak jedan pasus. Zbog ogranieenja prosto
ra, obicno ne mozete biti nmogo kreativni u odgovorima na pitanja koja mis
lite da ce korisnici postavljati. Ali, uz malo promisljanja, ipak mozete smisliti
nesto bolje od natpisa na kontroli izrazenog drugim reeima.
Opisivanje zeljenog datum a isporuke samo kao "Datuma na kOji kupac
zeli da mu se isporuCi mba" isto je toliko lose u savetu What's This? koliko i
1J temi neposredne pomoci. Najmanje ::ito mozete reci .ie, na primer: "Najra
niji datum na koji treba isporuciti kupljenu robu, Predlozena vrednost je tri
dana posle datum a porudzbine, ali je mozete promeniti ako pritisnete polje
i upiSete nov datum. Pritisnite FI za opsirnije objasnjenje."

Zvucni signali
ZVllcni signal - upotreha zvub generisanug pomucll racunara za opisi\',mje
nekog stanja sistema - iZllzetno
mobn mehanizilm pomoCi korisniC'ima,
ali projektnnti mugu cIa upotrebe tu moe i za dobro i za
"Piiiip, pogresio
si" okvir za dijalog kOji se pojavljuje bela sistem otkrije ,,1<orisnikovu gresku"
skolski .Ie primer lose upotrebe zvucnog upozorenja. Korisnici ne vole da ih
neko iIi nesto upozorava na njihove greske, a pistanje ne S,lmo sto privlaCi
korisl1ikovu paznju na problem, vee i pazllju osobe koj1 je dovoljno blizu dn
ga cuje. Uzgred, standarelni racul11rski "piiiip" zaista l1ervira.
Meciutim, ako ZVUCl1e signale upotrebite l1a dobar naCin, to moze biti
veoma korisna alatb. U mesto da racunarski sistem zatrubi korisniku kada
ovaj nesto pogresi, pokusajte da napravite tako da racunar generiSe plijatan
zvuk (na primer, bo kad m1cb precle) bela k01'isl1ik uraeli nesto kako treba.
Recimo da pri unosenju podataka sistem proverava saclrZaj svakog polja Cim
korisnik prede l1a sleelecu kontrolu. Ako poelnci ispunjavaju zaelate uslove, si
stem moze
generiSe tihi
koji znaci "sve je u reelu". (Taj zvuk ne treba
da bude mnogo glasan.) Ako se pojavi problem, sistem se ne oglasava zvu
kOI1l vee prikazuje poruku na statusnoj traei. TiSinH
dovoljno upozorenje
da postoji problem, a korisnik ce pogleelati eknm.
Najbolja analogija za t~ tehniku pozitivnog oelziva (koju dugujem Ahmu
Cooperu) jeste tastatura. Cim pritisnete neki taster, cuje se tiho kuekanje.
Verovatno niste ni svesni tog zvuka, ali bela ga ne hi bilo, odmah biste pri
metili i ispitali u cemu je problem.
Primer tastature treba da umiri sva strahovanja u vezi s kakofonijom u
prostoriji punoj operatera koji unose poclatke. Kao' sto sam vee napom~nula,
"sve je u redu" zvuk ne mora cIa bucIe glasan cIa hi bio efikasan. Pozitivni
zvucni oelziv uspesno sam koristila u sistemu projektovanom za pozivni cen
tar s vise od 100 korisnika u istoj prostoriji.

Poruke

greskama

VeCina Ijueli ne smatra poruke 0 greskama oblikorn pomoCi korisnicima, sto

steta. Zbog toga veCina poruka 0 greskama ne pomaze korisnicima, vee ih
greli, sto je jos veca steta. U mesto ela poruke 0 greskama tretirate kao priliku
da istaknete kOlisnikove greske, tretirajte ih bo l1101bu sistema cIa mu kori
snik pomogne. Sistem je zapao u nevolju i potrebna mu je korisnikova po
moe da bi se iz nje izvukao.
Dobro vaspitana osoba, kada trazi neCiju pomoe, ne Cini to pomoeu ne
razumljivih receniea, niti u obliku izriCitih zahteva. Dobro vaspitana osoba
ne pokusava da istakne da je neko drugi hiv za njenu zbunjenost ili teSkoce.

Dobro V(lSpitallCl osoba objasnjava prolJ]Clll sto jclsllije 1I111C, llCti\O trazi po
moe, ne pokusClva c1a bmle namctljiv<l vise nego sto jt' potrebno i trmli se cia
objasni poslc;c1icc svojih zahtc;va.
Nista manje od navedenog ne bi trebalo da Cini ni c1obro \'<lspitan racu
narski sistem. U stvari, posto racunarski sistemi zasluzlljll manje postovanje
nego ljudi, treba10 bi c1a cine viSe. (Puzanje po. zemlji ne bi bilo. neprikladno
II OVOI11 slucaju.) Kada prikaze poruku "greska", sistem treba da:
Jasno opiSe situaciju, izrazima koje ce korisnici razumeti.
Uctivo zatraZi pomoc, bez isticanja da je korisnik krivac.
Ne gnjavi korisnika zahtevima da uradi nesto !ito sistem moze i sam
da obavi.
OpiSe pos1edice svake akcije koju bi korisnik izvrsio.
Sistem
se ponebd beznadeZllo "zakllcati", ili ce zbog nekog uzroka u
okruzenju, kao !ito je manjak memorije iii kvar diska, postati nemoguce tin
nastavi rad bez pomoCi korisnika. Kada se tako nesto dogodi, nemate mnogo
izbora osim da korisniku prikazete odgovarajucn poruku. To je odlicna prili
ka, ne samo da sistem dobije potrebnu pomoc, vee i da lwrisltik dobije infor
macije koje su mu potrebne kako bi pomogao sistemu da ubuduce izbegne
isti problem.
Ukoliko sitnaciju objasnite jasnim jezikom, bez upotrebe zbunjujuceg
zargona, poruka koju plikazete korisniku omoguCice mu da oclmah resi pro
blem. A ako je razumeo problem bda je prvi put nagao na njega, korisnik ce
znati kako cIa ga ubuduce izbegava - pod pretpostavkom da se situacija moze
izbeci. Pogresan format pri unosenju podataka moze se izbeCi, ali kvar cvr
stog diska obicno ne moze.
Ako korisnikll objasni posledice njegovog izbora, vr10 je verovatno cla ce
sistern dobiti naj10gicniji odgovor korisnika. Imajte u vidu da nmogo toga sto
vama izg1eda savrseno oCigledno, nece biti oCig1edno i korisniku. Nemojte
biti nametljivi, ali nemojte se ni bojati da istaknete cak i ono sto oCigleclno.
Uljudan sadrz.aj poruke i nenametljivo ponasanje prema korisnicima pi
odnosa prema njima. Secate Ii se cla vam je vasa mati pricala
tanje je
kako cete viSe muva uhvatiti pomocu meda nego pomocll sirceta? Ako su ko
risnici stekli opSti utisak da je sistem uglavnom uCtiv i od pomoci, radije ce
yam oprostiti onu cudnu gresktl koja rusi sistem a ciji uzrok nikako ne llspe
(Niko nije
vate da otkrijete.
.
. savrsen.)

'roaktivna pomoc
Pasivna i reaktivna pomoc korisnidma relativno 511 dobro shva6ene kategori
je podrske kori5nicima, mach postaju sve slozenije sa sirenjem naseg znanja
o komuniciranju izmec1u racunara i Ijudi, i s pojavom 110vih programerskih
alatki. Posleclnja kategorija, proaktivna p011106, svakako se moze opisati kao
"novi lik u komsiluku" i zasad je ugmdena u vrlo mali broj sistema.
Proaktivna P0l110C se zasniva na jednostavnom plincipu: racunarski si
stem prati korisnikove akcije i deluje proaktivno da bi mu pomogao, tako sto
claje preclloge za efikasniju upotrebu sistema ili precluzima akcije II ime ko
risnika. Alatka Assistant u Microsoftovom Officell pruza proaktivl111 P01110C
tako 5to korisniku daje savete nn osnovu njegovih akcija.
Vrsta proaktivne pomoCi koja trenutno privlaCi 111nogo paznje jeste tzv. pa
metni agent (engL intelligent agent). Pametni agent softver kome kOlisnik
prepusta obavljanje oclredenog posh Pametni agenti se cesto prave U obliku
specijalizovanog \Neb kOlisnickog interfejsa kOji odgovara na zahteve tipa
"Nadi 111i najnizu cenu za ov'~i mtika\" iii "Predlozi mi knjigu koju bih voleo da
procitam". Ali Ilista ih ne ogranicava samo na \Veb okruzenje. Na primer,
mozete napraviti agenta kOji pomaze studentil1lH cla organizuju svoj raspored
predavanja kako smatraju cla im m~jvise oclgovara - "N emoj 111i stavljati pre
davanja iz matematike
podne, a strani jezik bih najraclije popoc1ne".
Microsoft stav1ia na raspolaganje dve alatke za izracll..l interfejsa ZHsnOVH
nih na animinmim likovima, H to S1..1 Offlce Assistant i Microsoft Agent. VeCi
na ljudi poznaje malu skakutavu spajalicu koja preclstavlja Officeovog
asistent,l (kor1snik moze da izabere drugaciji lik), ali ne zna svako cla Of
ficeov asistent ima prograrnabilni interfejs. Mectutim, Officeov asistent je na
raspolaganju samo u Officeovim aplikacijama i ne moze se distribuirati za
jeclno sa izvrsnom Accessovom komponentom.
Ako raclite u Accessll (iii u bilo k0111 dr1.1gom razvojnom okruzenju u
korne se mogu koristiti ActiveX kontrole, ukljucujuCi i Visual Basic), mozete
preuzeti paket Microsoft Agent SDK sa Microsoftove Web lokacije. Znatno
je 1110cniji od Officeovog asistenta.
Microsoft Agent je vdo zabavna igracka. Osil11 gotovih likova koje dobije
te 1.1 SDK-u, mozete projektovati i programirati i vlastitc likove. Microsoft
Agent takode podrzava prepoznavanje govora (na engleskom jeziku) sto ima
fantastican potencijal II aplikacijama koje racle s bazama poclataka.Yolela bih
cla neko napravi Microsoft Agent interfejs za alatku Microsoft English Q1.1elY

(koja o1l1ogucava i7:vrS<lnlllje SQL upita zadatih obicnim go\'ornim

priclruzenu SQL
Zamislite kako bi to izgledalo kacl hi
poc1ataka bila prec1staYljena jednim Microsoft Agent likom.
Medutim, monun VLlS upozoriti na nesto: ni 1I Officeovom asistentu, ni u
Microsoft Agentu ne postoji clirektna poc1rska za pracenje korisnikovih akci
na njih. Na raspolaganju SU samo jednostavni interfejsi
ja, nib za
za slozel1o komunciranje s korisnikom pomocu tekstualnih poruka. Ako tre
ba da u pametnog agenta ugradite odredel1u kolieinu pameti, moracete ela
se snalazite sami.

Obuka korisnika
korisnika sistema koji rade s bazama podataka ne razlikuju
vrste softvera. Pocetna obuka moze se obaviti koriSce
njem dokumentacije, preelavnca ili racunara; navede11e mogucnosti ne isklju
cuju jedna
Ako se opredelite za pruzanje nekog oblika obuke na racunaru, ne za
boravite ela jasno definiSete opseg i ciljnu grupu tog projekta. Pocetnicima je
l1ajvaznije da saznaju sta sistem meli, a tek na elrugom mestu kako to radi.
Opseg obuke pocetnika zavisi oel 510ze11osti sistema i doelelje11og bucIze
tn. U mnogim sistemima dovolj11o je prikazati jeelan iii elva uvoelna ehana
koji objasnjavaju sta sistem raeli. Za slozenije sisteme prikladniji su slozeniji
oblici obuke, mozda neki vodic kroz sistem ili cak formaln1 obuka l1a raCll
naru, s vezbama, ispitima i slieno.
Korisnike sreelnjeg nivo<1 znanja zanima prvenstveno k1ko se obavljaju
pojedini poslovi i u mnogim slucajevima njihove potrebe 1110ze cIa zadovolji
sistem za neposrednu pomoc koji detaljno opisuje obavljanje poslova koje si
stem
U
razlika izmedu "pomoCi" i "obuke" elonekle je proiz
voljna. Medutim, u slozenijim sistemima, kOlisnicima srednjeg nivoa znanja
moze biti potrebna ista vrsta formalne obuke na racunaru kao i pocetnicima.
Bez obzira na opseg obuke koju cete obezbediti, nastojte da obuka bude
razelvojenn od samog sistema. Korisnicima svakako treba 0l110guCiti cia po
k1'el1u obuku iz korisnickog interfejsa sistema, mozda P0l110CU neke stavke
menija za pomoc. Ali upotrebu materijala za obuku 11e treba mesati S 1101'
malnom upotrebom sistema.
Zahtevi za

Sazetak
U OV0111 poglavlju razl110trili S1110 tri oblika pomoCi korisnicima: pasivnu po
moe ug1'acienu u ko1'i5nicki interfejs sistema, reaktivnu pomoc koja se aktivi
ra kao rezultat odreciene akcije korisnika i proaktivnu pomoc koju aktivi1'a
sam sistem.
Prvo smo proucili tri vrste pasivne pomoCi: mnemonicke pristupne ta
stere, kratke opise i statusne trake. Zatim S1110 preSli na reaktivnu pomoc
koja se obicno izvodi u obliku sistema za neposrednu pomoc i saveta \Vhat's
This?, ali moze obuhvatiti i zvucne signale a trehalo hi da obuhvata i poruke
o greskama. I najzad, ukratko smo razmotrili novu oblast proaktivne pomoci
i obuku korisnika.

Bibliografija
Deo I: Teorija relacionih baza podataka
Date, C. J. An Introduction to Database Systems. 7th Edition. Reading: Ad
dison-Wesley Publishing Company, 1999.

Date, C. J. i Hugh Darwen. Foundation for Object/Relational Databases:

The Third Manifesto. Reading: Addison-Wesley Publishing Company, 1998.

Fleming, Candace C. i Barbara von Halle. Handbook of Relational Database

Design. Reading: Addison-Wesley Publishing Company, 1989.

Teorey, Toby J. Database Modeling & Design. 3rd Edition. San Francisco:

Morgan Kaufmann Publishers, 1999.

Deo II: Teorija dimenzionalnih baza podataka

Gilb, Tom i Susannah Finzi. Plinciples of Software Engineering Manage

ment. Reading: Addison-Wesley Publishing Company, 1988.

Haught, Dan i Jim Ferguson. Microsoft Jet Database Engine Programmer's

Guide. 2nd Edition. Redmond: Microsoft Press, 1997.

McConnell, Steve. Rapid Development. Redmond: Microsoft Press, 1996.

Pressman, Roger S. Softwm'e Engineering: A Practitioner's Approach. 3rd

Edition. New York: McGraw-Hill, 1992.

Sommerville, Ian. Software Engineering. 6th Edition. Reading: Addison

Wesley Publishing Company, 1996.

Soukup, Ron. Inside j\,ficrosoft SQL Server 6.5. Redmond: Microsoft

1997.

339

Deo III: Projektovanje sistema koji rade s bazama podataka

Cooper, Alan. About Face: The Essciltials (~f User Jlltclj(fCC Desigll. Fuster
City: IDC Books Worldwide, 199.5.

Heckel, Paul. The Elements of Friendly

Books, 1991.

Mandel, Paul. The Elements

& Sons, 1997.

SOfi1C(lI'C

Desigll. New York: Warner

User Inicnjace Design, New York: John Wiley

Microsoft COll)oration. The Windows Illteljace Guidelines for Softu;are De

sign. Redmond: Microsoft Press, 1998.

Shneiderman, Ben. Designing the User Interface: Strategies for Effective

Human-Computer Interaction. Reading: Addison-Wesley Publishing Com
pany, 1980.

Recnik

ad hok izvestaj lzvestaj koji ce kOlisnik konfigUlisati dok mdi sa aplikacijol11.

alternativni kljuc Kandidat za kljuc relacije koji se ne kOlisti kao primami

kljuc tabele.

anomalije pri azuriranju Problemi pli radu s podacima ciji je uzrok lose

dizajniran model podataka.

aplikacija Skup obrazaca i izvestaja koje s kojima kOlisnik raeli.

aplikacija koja radi s bazom podataka Skup obrazaca i izvestaja s ko.1i

ma radi kOlisnik.

apstraktni entitet Entitet kOji modeluje vezu izmedu drugih entiteta.

atribut Kolona relacije.

baza podataka Kombinacija seme baze podataka i ukslaelistenih poclataka.

binarna veza Veza izmedu elva ucesnika.

celovitost PIincip da rezultat svih operacija nad relacijom mora takode biti

relacija koja se moze upotrebiti za dalje operacije.

Dekartov proizvod Helaciona operacija ko.1a kombinuje svaki zapis iz jed

nog skupa sa svakim zapisol1l drugog skupa.

deklarativni integritet Metoda definisanja uslova integriteta u kojoj se

llslovi iZliCito deklmisu kao sastavni deo definicije tabele.

dekomponovanje bez gubljenja podataka Mogucnost razbijanja rela

cija tako da se mogu ponovo kombinovati bez gubljenja podataka.

delimicno ucestvovanje Entitet kOji moze da postoji neza\lsno od svog

ucestvovanja u bilo kakvoj vezi s dmgim entitetom.

desni spoljni spoj Spoljni spoj koji vmea sva polja iz dmgog skupa zapisa

navedenog u iskazu SELEGr

domen Opseg vrednosti iz kojeg mogu poticati vrednosti datog atIibuta.

domeni s kompatibilnim tipovima Domeni kOji se mogu logicki porediti.

entitet
0 cemu sistem evidentira podatke.

entitet siroce Slabi entitet kOji nije povezan ni sa jednim entitetom u pri

mamoj relaciji.

341

funkcionalna zavisnost OdllOS iZ1lledu eh"a atributa u k0111e vrec1nost jecl

nog atlibuta odrecluje i vrednost clrugog.

integritet podataka Pravila koja vaze \l hazi podataka da bi se obezbedilo

cla podaci buehl, ako ne tacni, barem veroclostojni.

integritet transakcija Uslov integliteta koji upravlja ispravnoscu grupe

uporednih operacija u bazi podataka.

izvedena relacija Viliuelna relacija definisana pomocu drugih relacija.

jaki entitet Entitet kOji moze da postoji bez ucestvovanja u vezi s drugim

entitetom.

jednakovredni spoj Spoj izmedu tabela zasnovan na jednakosti.

kandidat za kljuc Jedan ili vise ahibuta koji nedvosmisleno identifikuju

relaciju.

kardinalitet relacije Broj redova saddanih u relaciji.

kardinalitet veze izmedu entiteta NaiveCi broi I)limeraka iednog enti-

teta koji moze ucestvovati u datoj vezi s drugim entitetom.

komhinovan entitet Entitet u prostoru problema modelovan pomocu dye

ili vise relacija.

komhinovan kljuc Kandidat za kljuc sastavljen od dva ili vise atJibuta.

komandni vektor NaCin izvrsavanja komande u kOlisnickom interfejsu; na

plimer, pomocu stavke menija ili dugmeta na paleti alatki.

konkretan entitet Entitet koji modeluje objekat ili dogadaj iz stvamog

sveta.

konvencionalna vrednost Proizvoljno odredena vrednost koja se kOlisti

za predstavljanje nepostojece ili nepoznate vrednosti.

kruzna zavisnost Kruzna povezanost hi relacije.

lancano azuriranje Automatsko azuriranje zapisa u spoljnoj tabeli kada se

promeni sadrzaj odgovarajuceg zapisa u plimamoj tabeli.

lancano hrisanje Automatsko brisanje zapisa iz spoljne tabele kada se

brise odgovarajuCi zap is iz plimame tabele.

levi spoljni spoj Spoljni spoj koji vraca sva polja iz prvog skupa zapisa u

iskazu SELECT.

logicki izraz Izraz Ciji rezultat moze biti samo "istinito" (True) ili "neistini

to" (False).

logicki operator Operator ciji je rezultat logicka vrednost (True iii False).

logicki tip podataka Opsti opis domena, kao sto je "Tekst" ili "Broj", bez

navodenja odredenog fizickog tipa podataka.

masina haze podataka Softver kOji obavlja fizicko skladistenje i manipuli

sanje podacima.

model podataka Konccptualni opis prostora problema POl1lo(:u izraza iz

rclac:ione teorije.

normalizovanje Postupak strukturiranja seme

podataka da bi se

obezbedio integritet poclatalm, izbegla redunclantnost i olaksalo llcitavanje

podataka.

normalne forme Pravila za clefinisanje strukture relacija racli eliminisanja

anomalija pli azutiranju.

objektni model za pristupanje bazama podataka Biblioteka softver

skih komponenata koja se koristi za komuniciranje izmedu masine baze poda

taka i razvojnog okruzenja.

okidac Proceduralni k6d kOji se izvrsava pli odredenom dogadaju 1I bazi

podataka.

osnovna relacija Relacija koja se u bazi podataka preslikava u tabelu.

pasivna pomoc korisniku Mehanizam pomoCi korisnicima koji je sastavni

deo kOlisnickog interfejsa.

polje Fizicld oblik atributa u bazi podataka.

posao Jedan od koraka u radnom procesu.

poslovni uslov Us]ov izveden iz prostora problema.

poslovno pravilo Uslov integriteta koji potice iz prostora problema, a ne iz

relacione teorije.

potpuno ucestvovanje Entitet ne moze da postoji ako ne ucestvuje u da

toj vezi.

prikaz Naziv izvedene relacije u SQL Serveru.

primama relacija Relacija ciji primami kljuc preuzimajn svi ostali uccsni

ci koji su s I1jorn povczani.

prim ami kljuc Kandidat za ldjuc relacije kOji se kOlisti za nedvos111isleno

identifikovanje zapisa u tabeli.

prim ami uslov Uslov koji odreduje fizicku struktunl baze podataka.

prirodni spoj Specijalan slucaj jednakovrednog 5poja, u kome se spajanje

obavlja na osnovu jednakosti, u spoju ucestvuju sva zajednicka polja, au skupu

rezultata pojavljuje se samo jedan skup zajednickih polja.

proaktivna pomoc korisniku Mehanizam p01110Ci kOlisnicima koji

sava da predvidi kOlisnikove potrebe.

proceduralni integritet Metoda obezbedivanja integliteta podataka pro

gramiranjem procedura koje se automatski izvdavaju kada se odredeni zapis

aZUlira, doda iIi izblise.

prost kljuc Kandidat za kljuc koji se sastoji od sa1110 jednog atlibuta.

prostor problema Deo stvamog sveta kOji modeluje aplikacija koja radi s

baZ0111 podataka.

puni spoljni spoj Spoljni spoj koji dajc s\'a polja iz oba llccsnika,

radni proces NeSto sto se olxlylja pOmOCll aplikacijc koja radi s bazol1l

podataka.

reaktivna pornoc korisniku Mehanizam pom06 koji se aktivira nckom

akcijom kOlisnika, kao sto je unosenje neplihvatlji\'og pod atka iii zahtev za ne

posrednu pomoc.

referencijalni integritet Uslovi integliteta koji obezbeduju ocuvanje veza

izmedu entiteta.

relacija Logicka struktura koja organizuje podatke u redove i kolone.

relaciona baza podataka Fizicka izvedba relacionog modela kOji je clefi

nisao dl' E. F. Codd.

relaciona razlika Relaciona operacija koja vraca zapise iz jednog skupa za

pisa kOji nemaju pamjake u drugom skupu zapisa.

relaciona unija Nadovezivanje elva skupa zapisa.

relacioni presek Relaciona operaci.1a izmectu dva skupa zapisa koja Ymca

postoje u oba skupa.

relaciono deljenje Spoj kOji vraca sve zapise iz jednog skupa kO.1i sac1rZe
vrec1nosti za koje postoje oelgovan\iuce vrednosti u drugom skupu zapisa.
sistern koji radi s bazorn podataka Kombinacija aplikacije koja mc1i s
bazom podataka, masine baze podataka i same baze podataka.
skalarna vrednost Jedna vrednost, koja se ne ponavlja.
skup zapisa Opsti izmz koji se u Microsoftovom Accessu odnosi na Fizicki
oblik relacije.
slabi entitet Entitet koji moze da postoji samo ako ucestvuje u vezi s dru
entitetom.
spojna tabela Tabela koia predstavalja vezu izmedu c1ve tabele u bazi
podataka.
spoljna relacija Relacija koja u vezi s drugom relacijom preuzima nien pli
mumi kljuc.
spoljni spoj Spoj koji vraca sve zapise koje bi Hatio ul1utrasnji spoj, plus
sve zapise iz jednog iii oba ucesnika u spoju.
standardni izvestaj Izvest,~ koji se moze definisati i napraviti kao sastavni
deo aplikacije koja rac1i s bazom podataka.
stepen relacije Broj kolona u relaciji.
stepen veze izrnedu entiteta Broj ucesnika u vezi.
serna Fizicka struktura tabela u sistemu kOji mdi s bazom podataka.
serna baze podataka Fizicka struktura tabela u bazi podataka,
tabela Fizicki oblik relacije iz seme baze podataka.
telo relacije Torke koje cine relaciju.

terllarlla veza \'eza lzll1eclu tri llcesnika.

teta-spoj Telmicld gledal1o, s\,,,ki spoj na osno\'\l operatoru

obicl1o Od110si na spojeve pomocu

nlzliCitih od operatom

torka Red 11 relaciji.

trovrednosna logika Model logickog racllnanja u kome rezultat izraZH

mogu biti smno vrednosti Tllle, False ili Null.

ucesnik Entitet koji je povezan s drugim entitetom.

unama veza Asocijacija relacije same sa sobom.

unutrasnji spoj Spoj koji vraca samo

za koje je ispul1jen spojni uslov.

upit Naziv izvedene relacije u Microsoftovom Accessu.

uslov haze podataka Uslov integIiteta koji se odnosi na viSe relacija

istovremeno.

uslov domella Uslov integliteta koji odreduje opseg moguCih vreclnosti u

datom domenu.

usloventiteta Uslov integliteta koji obezbeduje ispravnost entiteta 1110

delovanih u sistemu.

uslov integriteta Pravilo za integlitet podataka.

veza izmedu entiteta Asocijacija izmedu dva iii vise entiteta.

zaglavlje relacije Definicija atJibuta i domena na pocetku

zapis Fizicki oblik torke.

zavisni parovi grupa vrednosti Medusobno nezavisne grupe atJibuta

koje uscestvuju u funkcionalnim zavisnostima.

zhirna fUllkcija SQL-ova funkeija koja vmca zbime vreclnosti.

Spisak termina koriscenih u knjizi

nlternativlli kljuc
anomalije
pri azurirnnju
atribllt, obelezje
birac zapisa
celovitost
carobnjak
Cinjenicni atribut
datoteka dnevnihl
Dekartov proizvod
dekomponovanje
bez gu bitaka
entitet
entitet siroce
funkcionalna zavisnost
grananje
granularnost
grupisani indeks
indikator atributa
inkrementni razvoj
integritet podataka
integritet transakcija
interfejs s jednim
dokumentom
interfejs s viSe
dokumenata
izvedena relaeija
izvestaj preslikan
iz obrasca
izvrsavanje upita
jab entitet,
nezavisni entitet
jednakovredni spoj
kandidat za kljuc
kardinalitet
klizac
kljuc dimenzije

alternate key
update anomalies
attribute
record selector
closure
wizard
fact attribute
log file
Cartesian product
loseless
decomposition
entity
orphaned entity
f1lnctiollal
depende11cy
snowflaking
grain
clustered index
attribute flag
increntental
development
data integrity
transaction integrity
Single document
interface, SDI
multiple document
interface, MDI
derived relation
form-based report
qllenJing
regular entity
equi-join
candidate key
cardinality
slider control
dimension key

komandna tabla
S 1/; itc h boa rd
type compatible
kompatibilni po tipu
IIser services
korisnicke usluge
kruzna zavisnost
join dependency
lab klijent
thin client
cascading update
lancano azuriranje
cascading delete
lancano brisanje
masina baze podataka database engine
model podataka
data model
containment model
model sadrzavanja
neposredna pOl1106
on-line help
nezavisni entitet,
regular entity
jaki entitet
nivo detalja
ofgranularity
normalizovanje
normalization
obaveznost
oJ)tionality
obelezje, atribut
attribute
list b(n;
obicna lisbl
objektni model za pri data access object
stupanje podacima
model
odnos, veza (izmectu
relationsh ip
entiteta)
ogranicenje, uslov
constraillt
okidac
trigger
operator ogranicavanja restriction operator
operator spajanja
join operator
operator za izracllna
s1lmmarize operator
vanje zbimih podataka
operator
rename operator
za preimenovanje
operator za prosirenje extend operator
osnovna relacija
base relation
padaju6a lista
combo box
pahuljasta sema
snowflake
paleta poslova
task bar
pametni agent
intelligent agent
polje za potvrdivanje
check box
polje za tekst
text box
poslovne informacije
business intelligence

347

l510\'nc
:JSIo.\"J1i USlo.\'i
)Slo.\"110 prm'i!o
)tpuni spoljni spoj
"egradnk za podatke
'ekopavanje podatab
'ikaz
'imami kljuc
'imami USlo.Vi
'iro.dni spoj
'ojekcija
'o.stor problema
'o.zor poto.mak
.dni proces
:clunclantno.st

senices
COllstmillls

mIl'

full oulerjoin
data 111 a 1'1
data milling
r;iew
primary key
intrinsic constraints
naturaljoin
projection
problem space
child window
lVork process
redundancy
:ferentna tabela
lookup table
:lacija
relation
laeiona baza poelataka Telational database
:laciona razlika
relational difference
:laciona unija
relational union
lacioni presek
relational
intersectioll
zim raela
mode
mospo.j
seWoin
,tem koji radi
database system
s bazo.m podataka
,tcm za upravljanjc
database mallage
bazama podataka
ment system,
DEAtS
laclistenje podataka data warehol/sing
up rezultata
result set
recordset
up zapisa
,bi entitet, zavisni
weak entity
entitet
)j
tier
.ojna tabela
junction table
outerjoin
oljni spoj
ranicenje
paging
scrubbing
ruganje
ma baze podataka
database schellw
fa
code
bela cinjenica
fact table
bela dogadaja
coverage table
bela snimaka stanja snapshot table

tabela transakcija
tabclarni prikaz
teski klijent
tctn spoj
tipc)\"i po.dataka koje
definisc korisnik
torka
trovrednosna logika
ucesnici veze
unakrsni upit
unutrasnji spoj
upit
uslov, ogmnicenje
uslov za domen
uslovi integriteta baze
po.dataka
USlo.vi integriteta
promena stanja
uslovi za integritet
entiteta
uslovi za o.cuvanje referencijalnog integriteta
usluge
usluge po.clataka
Yew, oclnos (izmedu
entiteta)
veza "jeclan prema

trl1ls(!ctiol/

la/;/e

dot as/wei
fal clienl
Ihct({~joil/

user-defined data
types, UDDr
luple
three-valued logic
praticipallts
crosstab query
innerjoin
query
cOllstmint
domain const-raint
database integrity
coltstmints
transition integrity
cOilstraints
entity constraints
referential integrity
cOllstraillts
services
data services
relationship

one-to-one
Telationship
veza "jeclan prema vise" one-to-lIwllY
relationship
prema vise" 1IUmy-to-lnany
veza
relationship
veza tipa sastavnice
bill of lIwterials
relationship
zajednicki nivo zastite share-level security
record
zapis
zastita na nivo.u pojedi- user-level security
nacno.g korisnika
zavisni entitet,
weak entity
slabi entitet
lIlulti-vallied
zavisni parO\'i grupa
vreclnosti
dependency pairs
zavisni tabelarni prikaz sub-datasheet
sema
star schema

mpietan spisak termina koji se koriste u izdanjima Mikro knjige naiazi se na adresiwww.mk.co.yu/recnik.

Indeks
Simboli

u tabelama dimenzija,

arhitekture korisnickog

135-136

interfejsa, 251-253

(jednako) operator, 91

MOl (multiple document

izmene vrednosti,

interface), 256-26:3
141-143

A
podrska za radne proeese,
uslovi za, 218, 295-296

251-25:3
veza, identifikovanje, 191

Access (aplikacija), 5

SOl (single document

automatska zamena (masina

Accessov carobnjak Report,

interface),254-256
Jet), 95

,317

arhitekture podataka,
automatsko stampanje

ActiveX Data Objects

208-217

izvestaja, 31.5-316

(ADO),8

arhitekture sistema, 201-217

AutoNumber, tip polja, 34

ad hok izvestaji, :305-306,

arhitekture U obliku

:316-322

clokumenta, 2.53-263

ADO (ActiveX Data

arhitekture zasnovane na

Objects), 8, 19

baze podataka, definicija,

poslovima, 251-253

ADO. NET, 8

3-6

AS, rezervisana rec (SQL),

Advanced Filter/Sort,

bimc
vrednosti, kontrola, 287

105

prozor, 309-310

Boyce-Coddova
normalna

atributi, 12, 15-18

alatke za rad s bazalTla

forma,
42-43

definisanje elemenata

podataka, 6-9

pracenje,

brisanje
podataka,
podataka, 183-188

AllowZeroLength, indikator,

223

entiteta, odreclivanje,

81

Bulova logika, 90-92

194-195

alternativni kljucevi, 34

funkcionalna zavisnost,

analiza procesa, 177-179

35-36

analiza troskova i dobitaka,

kandidati i primarni

166-169,229

eelovitost, definicija, 10-11

kljucevi, 33-35

AND, operator, 91

CHECK, tip ogranicenja, 80,

ogranicavanje opsega

anomalije
azuriranju, 26

84,218

vrednosti,197-198

ANSCNULLS, opeija, 92

ciklicne kruzne z<lvisnosti,

u tabeJama cinjenica, 121

aplikacije, 6

46-47

kljucevi dimenzija,

tipa radna sveska, 2.54

ciljevi sistema, razvoj,

121-122

apstraktne relacije, .5:3

156-161,225-226

osobine cinjenicnih

apstraktni entiteti, 11

projektni uslovi, razvoj,

atributa, 122-129

arhitekture koda, 201-208

161-165

349

dijagrami elltiteta i veza (E/H

clijagrami),22-23,
230-2:31
arhitekturc interfejsa i,

2.51

definisanje veza izmedu

entiteta, 188-191

dijagrami toka radnih

arobnjaei,261-263

procesa, 179-181

etvoroslojna arhitektura

dimenzionalne baze

koda, 20.3-206

podataka, 111-119,232

etvrta normalna forma,

projektovanje obrasca i,

44-45

277

injenice, 114

tabele cinjenica, 114,

heterogcnc, 129-131

121-131

osobine atributa, 122-129

granularnost, 124-126,

140

)
struktura, 121-122

vrste, 127-129

)AO (Data Access Objects),

tabele
dimenzija, 13:3-137
8

grananje,138-140
)ataField, svojstvo, 283

izmene vreclnosti,
)ataGrid, kontrola, 274, 285

141-143

)ateTime, tip podataka, 37

struktura,
133-137

)ateTimePicker, kontrola,

clirektno
merljivi
projektni

287

uslovi,162

atumi,36

atumske vrednosti, kontrole

dizajn orijentisan premn

korisniku, 244-24.5

za predstavljanje, 287

clodavanje
poclataka,

efinisanje parametara,

pracenje,
223

1.5,5-169

clokumentovanje
radnih

ciljevi sistema, 156-161

procesa,
179-181

opseg sistema, 16.5-169

domeni,
12,
18-20,
195-197

projektni uslovi, 161-165

entiteta,
oclredivanje,

lekartov proizvod, 102-103

19,5-196

79

eklarativl1i
kompatibilnost
po tipu, 19

ekomponovanje bez

ogranicavanje
opsega

gubitaka,32
vrednosti,
197-198

elimieno ucestvovanje u
za,
218

uslovi
vezi, 21,49

doslednost dizajna
eljenje, operacija, 98-99

kOrisnickog interfejsa,
esni spoljni spojevi, 98

248-2.50
etaljni izvestaji, 311

ijagram promena stanja, 70

clruga normalna forma,

39-40

iljne grupe, predstavljallje

projekta sistema,
22.5-226
nbe, operator, 107

:UBE, operator (SQL), 107

dugmad za opcije, kontrole,

282,284

d\'Oslojne arhitekturc

podataka, 213-214

E
E/R (entity relationship)

dijagrami, 22-23, 119,

2.30-231

arhitekture interfejsa i, 2.51

definisanje veza izmedu

entiteta, 188-191

elementi podataka,

clefinisanje, 183-188

English Query, alatka, .310

entiteti, 1.3-15

E/R clijagrami, 119

ponovno razmatranje,

192-19.5

potklase, 56-59

predstavljanje na

obrascima, 26,5-277

siroCiCi, 73, 292

slabi i jaki, .50

uslovi za, 218

uslovi za integritet,

296-299

Excel,118

F
filtriranje poclataka, .306-310

fizicke tabele, definis<ln.ie u

semama, 217-218

f]zicki tipovi podataka, 82-8.3

fleksibinost, 28-31

format podataka, 294

formatiranje izvestaja,

320-322

formatiranje vreclnosti

u clomenu, 198

FROM, odredba iskaza

SELECT (SQL), 90

funkcionalna zavisnost, 3.5-36

obliku komamllie table"

259

graficki iz\'estaji, 311

1I OutlookO\om stilu, 2..55

grananje, 138~140

za govorni jezik, 310

granularnost, tnbclc

za izveStaje U obliku

Cinjenica,
140

menija,312

greske

za izvestaje u obliku palete

pri stampanju, 313~315

alatki,312

pri unosenju podataka, 301

IS NULL i IS NOT NULL,

GROUP BY, odredba iskaza

operatOli, 92

SELECT (SQL), 90, 103

iskusni kOJisnici, projekto

odredba ROLLUP,

vanje za, 243, 323

106~107
izmene, llpravljanje, 235

operator CUBE, 107

izmene vrednosti II

grupe koje se ponavljaju, 38

dimenzijama, 141-143

izracunavanje zbirnih

H
podataka, operator za,

103~104
heterogene Cinjenice,
izrada izvestaja, 30.5-322
129~131
ad hok (namenski) izvestaji,
HOLAP (hibridni OLAP)
305-306,316-322
sistemi, 11.5
pretrazivanje, sortiranje

i filtriranje podataka,

306-310

Identity, tip polja, 34

standardni izvestaji, 305,

"ima", vrsta veze, 50

310-31.3

indeksna datoteka, uticaj ntl

stampanje izvestaja,

performanse,211-21:3
312-316

indikatori, neskalarne
izrada modela podataka, 1.52,

vrednosti, 37

183-199

Input Mask, svojstvo, 287

analiza domena, 195-197

integrisanje komponenata

definisanje veza izme(l11

baze podataka, 151

entiteta, 188-191

integritet podataka, 67-87

identifikovanje elemenata

realizovanje, 76-87

podataka, 183-188

uslovi, 68-75

normalizovanje, 198

integritet transakcija, 7.5

ogranicavanje opsega

interakcije izmedu entiteta,

vrednosti, 197-198

193

ponovno razmatranje

interfejs

entiteta,192-195

s jednim dokllmentom

izvestaji

(SDI),254-256

preslikani od obrazaca, 312

s vise dokumenata (MDI),

11 obliku Hsta, 311

256-263

izvedene relacije, 89

1I

J
jaki cntiteti, 'so

(jeste)", vrsta \'oze, ,SO, 69

jcc1an prcmCl vise, tip \'cze,

21,59

predstavljanje na

obrascima, 269-272

jednako, tabela istinitosti

operatora,91

jeclnakovredni spojevi, 94

jednobitni inclikatori, 37

jednoslojna arhite'kiura

podataka,210-21.3

Jet, masina baze podataka, 6

flzicki tipovi podataka,

82-83

lancano brisanje/azurinmje,

73,299

objekti Relation, 86

po'drska za domene, 20

prirodni spojevi, 9.5

JOIN, odredba iskaza

SELECT (SQL), 90,

93-98

K
kanclidati za kljuceve,
52-.53,194
kardinalitet veza, 11,50

identiflkovanje, 190

poznat,6.5

klasicni MDI interfejsi,

2.57-259

klijenUselver sistemi, 213-214

klizac, kOl1trola, 288-289

kljucevi dimenzija, 121~122

kljucni atributi (tabele

Cinjenica), 114

kocke (c1imenzionalne

podataka), 116,

c1imenzionalne baze

podataka

komandni vektori, .324

Jl11hiJ1O\'<lni l'lltiteti, 192

prototip i spceif'ikacija,

2:33-2:3.J

programskog koda,
WindowsoYfc kontrole.

202-206

biranje

usluga, 202

za brojeve i datu me,

)1l1unieimnje s korisnicima,

287-289

172-173

za logicke vrednosti,

281-282

mkretni entiteti, 14

mtrole, 279-290

za skllpove vrednosti,

plikazivanje pornka na

282-286

statusnoj traci, 328-329

za tekstualne vrednosti,

tipa liste, 311

289-290

za brojeve i datume,

za izradu izvestaja,

312-313

287-289

korisnicki scenariji, 181

za logicke vrednosti,

kOrisnici, razgovori sa,

281-282

172-173

za skupove vrednosti, 282

za tekstllalne vrednosti,

kruzne zavisnosti, 46-47

289-290

lrisnicki illterfejs, projekto

L
vanje, 153, 232-233

Inki
klijenti, 216

arhitekture,251-253

lancano
aZuriranje, 73, 299

MDI (multiple document

lancano
brisanje,
73, 299

interface), 256-263

levi
spoljni
spojevi,
98

SDI (single document

LinkChildFields,
svojstvo,

interface),2.54-256

285

doslednost, 248-250

LinkMasterFields, svojstvo,

efikasnost, 239

28.5
korisnik komanduje,

lista
s hirnnjem viSe stavki,
244-245

286

minimizovanje ull1nog

ListField,
svojstvo, 283

napora, 246

logicke
vrednosti,
kontrole

modeli,240

za
predstavljanje,
nivoi korisnika, 242

281-282

[Jodrska za radne procese,

logicki
operatori, 90-92

251-253

logicki
tipovi
podataka, 68

jredstavljanje entiteta

lozinke,
222-223

na obrascima, 265-277

hijerarhije, 272-274

veze tipa "jedan prema

M
jcdan", 268

rnasine haze podataka, 6

veze tip a "jedan prema

MDI (multiple document

vise",269-272

interface), 256-26.3

veze tip a "vise prema

vise", 275-277

') III po 11 e n tc

l11chanizmi za podrskll
korisn ici ma, ,32:3-:3:37
oimka, :3:37
pasivni, 32,5-329
proaktivni,
3:36-:3:37
reaktivni, 32.5, 330-:3:35
meke izmene, pracenje, 143

mentalni model (korisnicki

interfejs), 240

merenje uspeha projekta,

161-165

metodologije, nnpomene

u vezi sa, 1.53

Microsoft ADO, 8

Microsoft Agent, 3:36

~Yficrosoft English Quel}',

alatka, :310

Microsoft Office Assistant,

.336-337

Microsoftov Aceess, 6

carobnjak Heport. 317

YIicrosoftov Excel, 118

minimizovanje umnog

napora, 246-247

mnemonicki pristupni

tasteri, 325-326

modalni dizajn, 244

model evolutivnog

150-151

model inkrementnog razvoja,

1.50-152

model sistema i stvarnost,

;301-304

model vodopacla, 147-148

modeli poclataka, .5, 1:3-23

f1eksibilnost, 28-;31
izrada,
183-199

analiza domena, 19.5-197

definisanje veza izmec1u

entiteta, 188-191

identifikovanje

elemenata podataka,

183-188

normalizovanje, 198

ogranic\\y,mje opsega
\TedJlosti,197-l98
ponovno nlzmatranje
entiteta, 192-195
predstavljanjc, 230-2:31
mzlike U odnosu
na stvarnost,

obrada,301-304

modeli zivotnog ciklusH,

147-1.52
modularnost programskog
koda,202-206
MOLAP (multidimensional
OLAP) sistemi, US
MonthView, kontrola, 287
MSDE (Microsoft Desktop
Engine),7

N
nadovezivanje skupova
zapis<1,99-100
namcnski (ad hok) izvestaji,

305-306,316-322

napreclni korisnici, projekto

vanje za,
323
neispunjavanje uslova
integriteta, 79
nenamerni pogresni podaci,
ispravljanje, 301
neposredna pomoc, 330-332
nepostojece vrednosti, 69,
76-78
nepovezane arhitekture
podataka, 2L5-217
nepoznate vrednosti, 69,
76-78
nivoi zastite, 222-223
nivoi znanja korisnika,
projektovanje za,

242-243,323

N-kocke, 116, Videti i

dimenzionalne baze
poclataka

normalizQl'ane baze
podataka. definicija, ] 1:2
normalizO\'anje bam
podataka, :31, 36-47, 198
normalizO\',mje eli menzija,
138-140
normalne forme. 31
N-slojne arhitekture
podataka, 215
Null vrednosti, 76-78. 90-92
uslovi,295
zbirne funkcije, 104
numericke vrednosti,
kontrole za
preclstavljanje, 287-289

o
obaveznost ucesnika u vezi,
,50,59
obaveznost veza
identifikovanje, 190-191
obicne liste, kontrole,
282-284
povezani par, 285
objektni modeli za
pristupanje podacima, 8
obrasci, projektovanje
za prikazivanje entiteta,
26.5-278
obrazac, filtriranje po,
308-309
Office Assistant, 3.36-337
ogranicavanje, operator, 93
ognmicavanje opsega
vrednosti, 296
okidacke procedure, 79
okruzenja za definisanje
podataka,9
OLAP (on-line analytical
processing) sistemi. 112
OLTP (on-line transactional
processing) sisterni, 112,
118

opcmcijc nad
S9-10S
dopune, 103-108
opcracije nad skupovima,
99-10:3
relacione operacije, 92-99
opis sistema,
clokumentovanje,
228-229
opseg sistema, odredivanje,
165-169
opsezi vreclnosti,
ogranicavanje, 197-198,
296
opste projektne strategije.
164
OH, operator, 91
OHDER BY. oclredba iskaza
SELECT (SQL), 93, :306
osnovne relacije, 89

p
padajuce liste
kontrole, 282-284
otvorene, 28.3
pahuljaste seme, 114
pasivni mehanizmi, 1'omoc
korisnicima, 32,5-:329
performanse, uticaj
arhitekture poclataka na,
212-217
peta normalna forma, 46-47
pistanje, kao upozorenje
korisniku. :334
PIVOT, odreclba, 106
poeetnici, projektovanje za,
323-324, :337
podobrazac, kontrola, 285
poluaditivne Cinjenice, 123
polja za potvrc1ivanje,
kontrole,281
polje za tekst, kontrola,
289-290

)omoc korisnicma, :32:3-:3:37

identifikmmljc

ohuka, :3,37
eiel1lcnatn pocbtaka,

pasi\'ni mcilanizmi,
183-188

:32.5-:329

lIorm,llizovanje, 198

proaktivni mehanizmi,

ograniCavanje

:32.5,:3:36-337

vreclnosti,197-198

reaktivni mehanizmi, :32.5,

ponovno razmatranje

330-335

entiteta, 192-195

)OnOVI10 razmatranje

komci postupka, 152-1.53

entiteta, 192-19.5

modeli zivotnog ciklus,l,

)oruke

147-152

o greskama, 334-3:3.5

preclstavljanje projekta

drugim<l, 22,5-226

prikazivanje na statusnoj

traci, 328-329

Windowsove kontrole,

~oslovi, 171. Videti i radni

biranje, 279-290

procesi

za brojeve i datUI11e,
clefinisanje

287-289

za logicke vreclnosti,

identifikovanje, 173-177

281-282

korisnicki scenariji, 181

zavisnosti, utvrdivanje,

za skupove vreclnosti,

177-179

282-286

oslmma pravila, 74,

za tekstualne vreclnosti,

174-177,300-304.

289-290

i lIslovi integriteta;
postupak projektovanja baZel

raclni procesi

poclataka, 147

entiteti i, 194

clefinisanje radnih procesa,

152,171-177

oslovne informacije,

117-119

clefinisanje sistemskih

osreclni uticaj na entitete,

parametara, 152,

15,5-169

193

ciljevi sistema, 156-161

ostupak projektovanja, 147

clefinisanje radnih procesa,

opseg sistema, 16.5-169

152,171-177

projektni uslovi,

161-165

definisanje sistemskih para

metara, 1,52, 155-169

izracla moclela poclataka,

152, 183-199

ciljevi sistema, 1,56-161

analiza domena,

opseg sistema, 165-169

195-197

projektni uslovi,

161-16.5

clefinisanje veza izmeclu

entiteta,188-191

izrada model a podataka,

152, 183-199

iclentifikovanje

analiza domena, 195-197

elemenata podataka,

cleHnisanje veza izmeclu

183-188

entiteta, 188-191

normalizovanje, 198

ogranicm"anje opscga
vreclnosti,197-198
1'0110\'110 razmatranje
entiteta, 192-195

korad postupka, 1.52-1,s:3

l1locleli zivotnog ciklllsa,

147-152

predstavljanje projekta

drugima, 22.5-226

vVindowsove kontrole,

biranje, 279-290

za brojeve i datume,

287-289

za logicke vreclnosti,

281-282

za skupove vreclnosti)
282-286

za tckstualne vreclnosti,

289-290

potklase, 129

potklase entiteta, .56-.59

potpuni spoljni spojevi, 98

potvrdne poruke, 245

pracenje aktivnosti korisnika,

223-224

pracenje izmena 11

climenzionalnim bazama

podataka, 141-143

precice sa tastature, 325-326

preclstavljanje

hijerarhija na obrascima,

272-274

projekta, 22,s-226

raclnih procesa na

dijagrnmima, 179-181

veza na clijagra1l1illla, ,52

pregraci za poclatke, 117, 126

preimenovanje, operator za,

105

prekopavanje podataka, 117

presek, relacioni, 100-101

preslikavanje reclova (masina

Jet), 95

prdrazivanjc poc1atab,
306-310
pribzi (SQL Sener), 89,
220-221
primarne relacije, ,51-,52
primarni kljucevi,
292
i jedinstveni indeksi, 84
nepopunjena polja, 297
primarni uslovi, 292-299
prirodni spojevi, 95
prividni model (korisnieki
interfejs), 241
privilegije, dodeljivanje, 223
proaktivni mehanizmi,
pomo(; korisnicim<1,
336-337
problem nedostajuCih
podataka, 69, 76-78.
Videti i Null vrednosti
problemi sa stampacem,
313-315
procecluralni integritet, 79
profili, korisnicki, 181
projekcija, operator, 93
projektni interfejs, 260
projektni uslovi, razvoj,
161-16,5
analiza troskova i dobitaka,
166-169,229
kOji se tieu radnog
okruzenja, 163-164
projektovanje i7vp~h.i"
316-322
projektovanje korisnickog
interfejsa,
232-233
arhitekture korisnickog
interfejsa, 251-2.53
MDI (multiple document
interface),256-263
SDI (single document
interface), 253-256
doslednost, 248-250

efikasnost, 239
korisnik komanc1ujc,
244-245
minimizoVC1l\je llmnog
napora, 246
mocleli, 240
nivoi korisnika, 242
podrska za radne procese,
251-253
predstavljanje entiteta
11a obrascima,
265-277
hijerarhije,272-274
veze tipa "jedan prema
jedan", 268
veze tipa "jedan prema
vise", 269-272

veze tipa "vise prema

vise", 275-277

prototip i specifikacija,
233-234
Windowsove kontrole,
biranje
za brojeve i datu me,
287-289
za logicke vrednosti,
281-282
za skupove vrednosti,
282-286
za tekstualne vrednosti,
289-290
za izradu izvestaja,
312-313
prosti kljucevi, 33
prostor problema, 5, 192
prosirenje, operator za, 104
prototip korisnickog
interfejsa,
241
provera isp'ravllOsti podataka,
204, 280. Videti i uslovi
integriteta
prva normalna forma,
36-38

R
raclio-clllgmad,
282
radni procesi, 74,229-2:30
analiziranjc, 177-179
clefinisanje, 1.52, 171-179
clefinisanje elemenata
podataka, 183-188
dokumentovanje, 179-181
podrska u arhitekturi
interfejsa, 2,51-2.53
predstavlj,;nje, 229-230
utieaj na entitete, 192-193
razgovori s kOlisnicim(l,
172-173
razlicito, tabela istinitosti
operatora, 91
razlika, relaciona, 101-102
razvoj ceone komponente
aplikacije,9
reaktivni mehaniz111i, pomoc
korisnicima, 32,5,
330-335
reclundantnost
eliminisanje, 25-27
u tabelama cilljenica, 122
relacije (skupovi zapisa), 10
definicija, 11
kandid<~ti i primnmi
kljncevi, 33-35
pracenje aktivnosti
korisnika, 223-224
virtuelni, 204
relaciona algebra, 89-108
dopune, 103-108
operacije nad skupovima,
99-103
relacione operacije, 92-99
relacioni model, 9-11
relacioni OLAP
lIS
Helation,objekti
baze
podataka),86
Report, carobnjak, 317
Required, svojstvo polja, 81

csellje S komel1cionalnim

vredllostima, Wi

cvizije, llpravljanjc, 2:35

,icll Tcxtbox, kontrola, 290

izici, razmatranje, 228

okovi, oc1govaranje na

pitanja 0, 227

i.OLAP (relacioni OLAP)

sistemi, 115

\OLLUP, odreclba (SQL),

106-107

ollup, operator, 10G-107

amostalni sistemi, 210-212

za rukovodstvo,

227-228

cenariji upotrebe, 181

DI (single document

interface),254-256

ELECT, iskaz (SQL), 89-90

cuvanje u bazi podataka,

220-221

dopune, 103-108

operacije nad skupovimH,

99-103

pretrazivC1nje, sOltiranje

i filtriranje podataka,

306-310

relacione operacije, 92-99

lstemi za pomo'::, 330-332.

Videti i pomo'::

korisnicima

stemski parametri,

definisanje,
155-169

ciljevi sistema, 1.56-161

opseg sistema, 165-169

projektni uslovi, 161-165,

169

dadiste za podatke, 117

mpovi vrednosti, kontrole za

predstavljanje, 282-286

abi entiteti, 50

sloj

za podatke,

20:3-204

sloj intcrfejsa za spoljasllji

pristup,
20.5

interfejsa za transakcije,

203-20.5

sloj korisnickih usluga, 202

sloj korisnickog interfejsa, 20:3

sloj poslovnih IIs1uga, 202

sloj usluga podataka, 202

slojevita struktura, 203-206

slozeni kljucevi, 33

sOliiranje podataka, 306

spajanje, operacije, 93-98

specifikaeija korisnickog

interfejsa, 234

spiralni model, 149

spojne tabele, 60

spoljne relaeije, 51~52

spoljni kljucevi, 52-53

ogranicenja tipa, 85-86

sirociCi, 73

spoljni spojevi, 98

SQL Server, 6

fizicki tipovi podataka,

82-83

podrska za domene, 20

UDDTs (user-defined

data types), 79-80

zbirne funkeije, 104

srednji nivo, projektovanje

za,243,323-324,337

stanc1ardi, napomene u vezi

sa, 153

standardni izvestaji, 305,

310-316

stanje, c1efinicija, 215

statusna traka, 328-329

stepen, relacije, 12

stranicenje, 216-217

strucnost, razmatranje, 228

strugnnje, 137

struktura baze podataka,

25-47

c!i Il1cnzionalne baze

poc1ataka, lll-118,
232. Vidcti i tabde

dimenzija; tahc1e

cinjeniea

projektovanje obmsea i,

277

fleksibilnost, 28-3]

normalizovanje, 31, 36-47,

198

Boyee-Coddova

normalna forma, 42

cetvrta i peta nor111alna

forma, 44-47

druga normalna forma,

39

prva normalna forma,

36-38

trecn nor111alna forma,

40-42

osnovni principi, 31-36

redu ndan tnost,

eliminisanje, 25-27

struktura dokumenta, 226

stvarni model (korisnicki

interfejs),241

stvarnost, razlike U odnosu na

model sistema, 301-304

svrha predstavljanja projekta

sistema, 225-226

seme baza podataka, .5,

201-224

arhitektura koela i, 206-208

arhitekture podataka,

208-217

kOJ11ponente, 217-221

preelstavljanje, 232

priprema, 15:3

zastita sistema, 221-224

sifre, neskalarne vrednosti, 37

stampanje izvestaja na

zahtev, 315-316

r
nhclarni prikaz, 2S.s

dcfinisanje II

semama, 217-21S

abelecinjenica, 114,121-1:31

granlllamost, 124-126, 140

struktura, 121-122

vrste, 127-129

:abele dimenzija, 133-143

grananje, 138-140

izmene vrednosti, 141-143

struktura, 1.33-137

:abele dogadaja, 128

:abele snimaka stanja, 127

:abele transakcija, 127

:asteri precice za stavke

menija, 325-326

:ekstllalne vrednosti,

kontrole za

predstavljanje, 289-290

:eio, relacije, 12

:ernarne veze, 21, 49, 62-6,5

:estiranje naCina llpotrebe

sistema, 241

Leta spojevi, 96-97

tipovi podataka, 82-83

biranje, 196-197

koje definise korisnik

(UDDT), 79-80

uslovi za, 197-198,294

tipska pisma, 321-322

ToolTips, ,326-328

tOIle, 11. Videti i kardinalitet

veza

uslovi integriteta promena

s tanj a, 70-71

traka za pomeranje, kontrola,

288-289

TRANSFORM, iskaz (SQL),

105-106

transform, operator, 105-106

treea normalna forma, 40-42

TreeView, kontrola, 274,28,5

troslojna arhitcktum koda,

202

uslm'i integritcta cntitcta,

troskovi, oclgomralljc na

uslO\'i integritcta promcna

stanja, 70-71

llslovi referencijalnog

integriteta,72-74,

8,5~86, 296-299

llspeh projekta, razvoj llslova

kOji pokazuju, 161-16,5

analiza troskova i dobitaka,

166-169,229

pitanja 0, 227

trovreclnosna logika, 90-92

u
llcesnici veze, c1efinicija,

20-21,49

UDDTs (user-defined data

l:J1)es),79-80

ulazna maska (svojstvo Input

Mask),289-290

umni napor, minimizovanje,

246-247

umrezene baze podataka, 210

unakrsni upit, 105

unarne veze, 49, 61

unije, relacione, 99-100

unutrasnji spojevi, 98

UpDown, kontrola, 287

upiti (masina Jet), 89

uskladisteni, 220-221

upravljanje izmenama, 23,5

uslovi

za opsege vrednosti,

197-198,280,296

Input Mask, svojstvo,

287,289-290

za veze izmedu entiteta,

191,218

zadavanje u semi baze

podataka, 218

uslovi integriteta, 67-7.5,

291-304. Videti i

integritet podataka

poslovna pravila, 74,

174-177,300-304

entiteti i, 194

primarni llslovi, 292-299

uslovi integriteta

podataka, 74

uslovi integriteta domena,

68-70, 79-80

71-72,

S1~S.S

ValidationRule, svojstvo, 81

velicina znakovnih podataka,

294

vestacki kljllcevi, 134-135

veze izmedll entiteta, 20-23,

49-66

binarne,
49

definicija ucesnika, 49

c1efinisanje,188-191,

217-218

modelov,mje, ,51-,54

obaveznost, ,50, 59

identifikovanje, 190-191

predstavljanje hijerarhija

na obrascima, 272~274

predstavljanje

na dijagramima, .52

ternarne, 21, 49, 62-6,5

tip a "jedan prema jedan",

21, 50, 54-59

predstavljanje na

obrascima, 268-269

tipa "jedan prema vise",

59

predstavljanje na

obrascima, 269-272

tipa "vise prema vise",

60

grananje, 138

predstavljanje na

obrascima, 275-277

llcesnici, uefinicija, :20-21

lIname, 49, 61

uslovi za, 191,218

.iseUimenzionalni OLAP

sistemi, 115

lirtuelni skupovi zapisa, 204

za slmp()\'e \Teclnosti,

282-286

za tekstualne vrecll1()sti,

289-290

XOR, operator, 91

Nhat's This?, saveti, 332--333

NHERE, odredba iskaza

SELECT (SQL), 93, 306

zaglavlje, relaeije, 12

zastita

Nindowsove kontrole,

na nivou pojedinacnog

279-290

korisnika, 222

za brojeve i datu me,

sistema,
221-224

287-289

z,~ednicki
nivo, 222

za logicke vrednosti,

281-282

z<1nemari\'anjc

prada, 301-304

zHvisni parovi grupa

\Tednosti, 44-45

z,lVisni tabclarni pribz,

274

zavisnosti

izmeau podataka, 178

utvrdivanje, 177-179

zbirne fUllkcije, SQL, 104

zbirni izvestaji, 311

znakovna polja promenljive

velicine, 294

zvezdaste seme, 114

zvucni signali, 334

ZVllcno upozorenje, ,334

Knjige Mikro knjige su drugacije.

Evo zasto ...

Svaka knjiga Mikro knjige je

uradena.

Mi objavljujemo knjige najboljih svetskih i doma6ih autora koji imaju tehnicko

znanje i sposobnost da svoje
prenesu u jasnu pisanu rec. Knjige
stranih autora najbolji prevodioci prevode za nas. Nasi urednici i strucni
saradnici, koji su i sami racunarski i
strucnjaci, vise puta citaju tekst i
proveravaju tacnost i razumljivosL Proveravaju se svi listinzi programa i pri
meri, a posebna paznja posvecena je demistifikaciji upotrebe racunara.
Za svaku knjigu pravi se detaljan indeks pojmova i spisak koris6enih termina.

Sve knjige graficki oblikuje i priprema za stampu nase strucno i odlicno

opremljeno tehnicko odeljenje. Svaka strana nasih knjiga priprema se
u visokoj rezoluciji, sto u stamp:
ostre i precizne tekstove, slike i boje.
Knjige stampamo u najboljim stamparijama i na najkvalitetnijem papiru.
Dve decenije radnog iskustva i trajno usmerenje na najvisi kvalitet, cine
Mikro knjigu vodecim izdavacem informaticke literature. Izdanja Mikro knjige
pomogla su stotinama hiljada Ijudi da uspesno koriste racunare. Nadamo se
da 6e pomo6i i vama.