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 izuzetno 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 tokom analize i projektovanja sistema kOji radi s bazom podataka, meau kojirna su definidja sistemskih parametara i radnih procesa, konceptualni model baze podataka i sema baze podataka. Projektovanje korisnickog interfejsa, 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 delova 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 jednostanla varijanta prikazana .ie na slid 9-1.

Po stupak zapoCinje sistemskom analizom, koja se ponekad naziva i analiza zahteva jer joj je cilj da utvrdi sta organizacija i budu6i korisnici zahtevaju 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 neophodne 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 izrade 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 vodopada potpuno ispravne. U stvari, ako izostavite bilo koju od njih, prizivate katastrofu. Problem s modelom vodopada je njegova lineamost, tj. pretpostavka 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 i Q ! Pcoj,kt"""OJr---'----;, i Planiranje i I

iprocena 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 zahteva menjanje seme baze poc1ataka, a izmena seme moze clovesti c10 neocekivanih - 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 deuelopment) 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 spiralnog modela, izvodi se pocetna analiza celog sistema, a ne samo jednog njegovog 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 komponenata. 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

fazama projekta 1ll0Ci dn obezbedite klijentu odredeni deo 05110\'ne fnnkcionalnosti. To omoguC(\\'1\ sistem pocne cla isplacuje nmLtc ulozen 11 c1otadasnji 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 bavite 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 morate da obavite barem jedanput u svakom projektu.

Definisanje sistemskih parametara U idealnom slnCaju, svaki projekat bi poceo od jasne definicije onog sto zelite da postignete, zbog to pokusavate da postignete i na osnovn cega ce se procenjivati vas nspeh. Bnduei da za ve

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 korisnicki 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 korak 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 procedure radi upravljanja postupkom projektovanja. Postoji vise metodo)ogija za tu namenu, a veCina ima i automatizovane alatke za podrsku. Necu iZllCitO preporuCiti 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 uputio potpredsedniku kompanije jer je ovaj po hiljaditi put pokusao da prosiri opseg projekta. (U oblasti projektovanja sistema, kao i u svakoj drugoj, korisno je znati skim tacno imate posla.) Bilo kako bilo, to ostaje jedna od najistinitijih 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 njegove 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 jeclnostavno. Ponekac1, ako imate IIl1lOg0 srece, zaista jc tako. Ponekad je upotrebljiva definieija cilja i opsega projekta sastavni cleo opisa projektnog zac1atka. Cesce se desava da je njihovo definisanje slozen postupak u ko.1em cete morati da kombinujete formalne tehnike analize, projektne kompromise i poprilicnu koliCinll cliplomatije.

Cilj razvojnog projekta obi6no je najvazniji cinilac pri odredivanju i opsesistema 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(1utim, "automatizovanje postojeceg sistema za obradu porudzbina" predstavlja zadatak H ne cilj. Cilj je razlog, iii verovatnije viSe njih, zbog kOjih se projekat 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 direktor 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 prosecno 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 U 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. MecIlltim, al

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 produktivnost 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" svakako je bolje od "poboljsati eflkasnost". Mectutim, prva recenica podrazumeva da vi znate koliko je vremena sada potrebno za obradu porudzbine, a Otkr1vanje 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 maloprodajna cena bila $2.500. (Priznajem, na tu Cinjenicu sam ukazala samo jedanput, 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 povracaja poreza.)

Resenje za prevodenje takvih uopstenih zahteva u upotrebljive projektne uslove, nalazi se U osecaju za meru i u konceptu "dovoljno dobro". Ako sudbina kompanije ili neCija karijera zavisi od kvaliteta novog raeunarskog sistema, 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 dobro" da znate da u tekucem sistemu prosecna osoba moze cIa obradi otprilike 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 pocnete cia mi saljete uvredljive poruke, znajte da nisam nikad radila za njih.)

Uvek vredi pitati zbog cega je potrebno odredeno poboljsanje, Na primer, moze biti zaostalog posla, a rukovocIilae mora odlueiti cia Ii da ubrza postupak 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 prvobitno dao. Ukoliko vas klijent zeli cIa smanji vreme obrade na po!ovinu, morate 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 pravite 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 razumljiva racunarskom sistemu. To je vas posao. Vasi ldijenti nece yam svesno i namemo uputiti nerazumne zahteve, navesti vas na gresku, niti vas optuziti za stvari za koje niste krivi. Ali, deo vaseg posla je da pomognete svojim klijentima 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 uzdrzanosti 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 napravite sistem onako kako vam je predstavljeno ili da odustanete od projekta (naravno, svesna sam da to nije uvek moguce). Najbolje cemu se l110zete nadati jeste da ispitate projekat kOji dobijete; ako pronadete neke sustinske nedostatke, 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 proizvod, 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 izradu riznice poclataka koje ce koristiti ceia organizacija. Zelim samo da napomcncm da ispitati da Ii podaci kOji cine sastavni deo sistema imaju vrednost i za druge delove organizacije Hi druge procese u istoj oblasti. Mozda 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.

NCl primer, aka sistem Zit obraclu poruclzbina odrzClv

Cak i II rclativl10 kratkotrajno])1 projektu, lllO;t.e se c]ogoditi da II kasnijim f~lZlmHl 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 dopunjavacete 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".

~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 cIiskusiju, pretpostavicemo cIa ste vee sastavili spisak ciljeva projekta i da sada treba 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 direktno podrzavaju jedan iii vise ciljeva sistema. Ukoliko vam se 6ni da odredeni 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 sl11cajevima 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

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 uslova. Ne znam da li je to pitanje rnnogo vazno. Policija zn specifikacije \

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 vrednosti 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, sistem 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 korisnika koje sistem treba da podrzava. VeCina sistema ima vise kategorija korisnika, 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 pomdzbine, 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, masina 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 istovremeno 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 01110gucava merenje uspesnosti.

Nel110jte zanemarivati ovu Vl"stu ciljeva; 1110zete ih zadati u obliku projektnih 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 realizacije. U ovoj fazi jos ne projektujete sistem, vee samo definiSete lIs10ve na osnovu kojih ce se procenjivati uspeh projekta. U navedenim primerima pominjn se izrazi "gde god je izvodljivo" i ugradnja "odgovarajuCih provera"; detalji izvedbe odlozeni su za kasnije faze projekta !

Odlican primer takvog nacina razmiSIjanja nalazio se u starijim verzij

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 sistem 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 zanilllljivih, ali ne bas neophodnih" funkcija koje ste odbacili kada ste definisali opseg 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 analiziranje 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 procenjenom 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 zajednicke jedinice mere. Svi troskovi se moraju meriti istim jedinieama, i svi dobici 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 jedinieama, rezultati su potpuno ispravni.

Proeenjena eena moze se obicno izraziti u radnim casovima iii kao novcani iznos, a u pOSlovl10m okruzenju uglavl10m se jednostavno prelazi s jedne 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 ,lllalize 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 procesa poboljsati eflkasnost za 20 procenata i smanjiti broj gresaka za ,50 procenata. 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 jedinicama) 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 primer, dobitke mozete proceniti izrazene u obliku "ustedenih iznosa", "zaradenih 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 jabuke i pomorandze, ali je u ovoj fazi prihvatljivo da ih posmatrate !

Tabela 10-1 Primer analize ponderisanih dobitaka

Funkcija 1 3 6 2 11 22 3,6 7,0'

Funkcija 2 6 2 3 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 poredenje relativnih vrednosti pojedinacnih komponenata, sto moze biti k011sno pri odredivanju opsega projekta i vremenskog plana izrade projekata. Medutim, 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 cinioeima, 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 komponenata, 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 procenjivanje 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 "pravi" korak postupka pro.1ektovanja, a to je deflnieija radnih procesa koje ce sistem podrZavati.

Definisanje radnih procesa

1ako je veliki broj sistema koji rade s bazama podataka projektovan za jednostavno sldadiStenje i uCitavanje odredenih vrsta podataka, svrha veCine je pomoe 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 stepena 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

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 analizirate. Heclosled koji~11 razmatrate pojedine procese unutar opsega sistema obicno je nevazan. Cak i kad oclredene komponente sistema planirate ili realizujete pre dlllgih (inkrementni razvoj), trebalo bi cIa obavite barem povr5nu analizu svih radnih procesa koje sistem treba da podrZi pre nego sto zapocnete 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 prodavca i prvo pogledamo da Ii je pravilno popunjen; ako jeste, p11stupamo datoted 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 zameniti, 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'Ukovodiocem sluzbe iii neposrednim nadreaenim. Iskustvo mi kaze da su rukovodioci 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 nadreaenima, 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 porudzbin 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 aktivnost koju korisnik obavlja, trebalo bi da ga pitate sta sve moze poCi naopako 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? Odgovori 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 izvrsioci. Trebalo bi da razgovarate sa svim ueesnicima procesa kad goclje to moguee. Ova preporuka odnosi se i na Ijude koji se bave poslovima naizgled izvan opsega sistema. Uzmimo na primer vee pomenuti proces obrade porudzbine. Posao "Dostavljanje kupljene robe" moze biti zapravo "Prosleclivanje 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 razgovarate 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 izvestaj, 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 organizacijom 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 poddati, trebalo bi da prilieno dobro razumete aktivnosti koje se odvijaju u tekucem 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

Prvo sto bi trebalo uociti na ovoj listi jeste ela Sll aktivnosti nm-eelene pomalo 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 razliCite nivoe detalja. To pitanje razmotrieemo malo kasnije. Zasacl eemo samo identifikovati poslove.

Prva stavka na listi, "Provera da li je pravilno popunjen obrazac porudzbine", ima jasan pocetak i kraj. Ta akcija se odvija pri prijemu nove porudzbine, a zavrsava se kada je proveren ceo sadrZaj dokumenta. Posto mozemo pretpostaviti da sva poslovna pravila vaze na pocetku procesa, u ovom slucaju 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 datoteke 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 provere dokumenta porudzbine, ali posto se datoteka koristi i u kasnijim akcijama, trenutak zavrSetka ove akcije nije poznat. Prema tome, to ne moze biti posao, vee samo jedan od koraka nekog posh

U stvari, datoteka kupaca se kOlisti u stavci 3 ("Unosenje podataka za dostavu 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 grupisati u jedan posao koji biste nazvali, na primer, "Evidentiranje porudzbine". U ovom slucaju, stavka 4, "Unosenje podataka 0 porudzbini", sasvim je 06gledno 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 provere 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 kredita 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 odobrenog 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 zavrSHVU situacijama slicnim opisal1oj, obavezno saznajte ;::.a.

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

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 poslovima nash\ju novi podaei, kao sto su sifre kupaca, kOji se potom koriste It drugim poslovima. Na pJimer, jedan moj klijent kOlistio je proces evidentiranja 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 porudzbina moze prihvatiti. Problem s tim naCinom rada jeste, to sto Sll podaci 0 porudzbini 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" porudzbine 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 poslova 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! ocigledni, ali ponekad, ako pratite poelatke kroz proces, naci cete podatke koji se generiSu racIi upotrebe II nek0111 drugom poslu ili procesu, ali kome viSe

niSll 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 aa svojoj tetki Gertrudi kazete 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 ispitivanje radnih procesa.

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 belezenje imena i telefonskih brojeva, mozda nece biti potrebno vise od jednocasovnog 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 sastanka 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 Iista 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 dokumentovanje 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

Ukoliko ne pOZl1

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 prirucniku 0 projektovanju i analizi sistema. U bibliografiji je navedeno vise njih.

Korisnicki scenario

Alternativa formalnoj analizi radnih procesa jeste identifikovanje korisnickih 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 upotrebljava 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 specificne korake transakcije. BuduCi da se viSe bave naCinol11 rada korisnika, ponekad je tesko pripremiti korisnicki scenario koji ne bi zavisio od korisnickog interfejsa sistema.

MedutiIl1, posto je namena metode da se utvrde korisnikovi ciljevi i ocekivanja, korisnicki scenalio je narocito pogodan za sisteme koji treba da podrze 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 11110SCnja pormlzhine, do clostave fakturisanja i uplata odgovarajuCih iZllosa", tacno opisuje kako ce ta grupa korisnika koristiti sistem. Opi5 ne namccc nibkve 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 korisnika 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'isl1i6kih 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 projektnih uslova i analizirali ste radne procese. Vreme je da zapoenete izradu 1110dela podataka.

Podsetite se da konceptualni model podataka sadrzi opis entiteta, njihove 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 dokumenta. Taj sImp se sastoji od dokumenata koje yam je prosledio klijent uzorci obrazaca za unosenje podataka, plimeri izvestaja i tome slieno i dokumentacije 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. Ponekad radni proces zapoeinje zbog drugog dogadaja, kada je jedan od prvih poslova najeesce popunjavanje papirnog obrasca. N astavljajuCi s nasim primerom obrade porudzbina iz poglavlja 11, obrazac porudzbine moze biti nalik na onaj sa slike 12-1.

183

/',.0'~::I. .~NORTHWINn"It. TUDt!tS

/',\,w, ! :,:I" ..'."!iI' h. .,\."

Ship TCC AJtedS FutterldS'te Ooere St;, ~7 Berlin 1220'il O.;'!l1l'\any

E:i! 10: ~fmd$ F\..1terklS'te Chen: Str, 67 Berlin 1120g Germany

INVOICE

~Iat.t: 03-Hov-2004

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: $814.50 ff1?iit,l: $2g.4Il lotal: $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 navljaju, ako ih ima, a treba ida identifikujete elemente podataka za je vasa analiza radnih procesa pokazala da nedostaju. Vasa pocetna Usta elemenata podntaka moze biti sliena onoj nn slid 12-2.

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

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

"i fj.,,J,,.ci U

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!", 81ffT- A!!,w, Cu..rt(Jl1(er ~ 0"ip T- A!';""", C,,,,;,a'\f;V,,,,,,

?+-- saM;''''''' C"Cad;V"",.

0"ip0, A!';""", O,.!.,.OaCe ~ Oac.Rf"r.!

81fft:" 0"ip!":"PNcl.d

0"CredU'"tPNC' C,t,rtZ"CIt,rO,.!",.Odaif 0"Cac.IP",,;,f,'Oi.rG(J"l(t C,"IfC,.,Ed'If!.!PNC. P,dafC,!.O,.!.,. T-taf

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

------+ 0"lWftbr ? +-- CaCep", . tZc, P.,. U'lflt ?

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

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 (porudzbina) 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

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 entitetu Customer. Aleo klijenti organizaeije imaju vise adre5a na koje im 5e dostavlja 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

Zanimljiv element podataka je atlibut Ship Via (naCin clostave). Na nlllOnarudzbenicama 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 menjab davaoce tih usluga ili unajmiti nove? Koliko organizacija mora biti otvorena 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 razmohiti kako cete to podrfati. Moracete da hodate tankol11 linijom izmcclU fleksibilnosti ko.1a je dovoljna za obradu svih razumnih mogucnosti i nametanja nepotrebnog opterecenja kOlisnicima sistema. U ovom primel1l, na.1bolje 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 5istemu. U OV0111 primeru, iako je jasno da orgnizacija mora da zna kako ce poslati robu kupcu, to se viSe ne s'lodi na jednostavno biranje n

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 rcecpcioneru da odgovam na pitanja 0 dostavi robe jeste dobro,

necete biti u stanju cla ill citate, mozetc napraviti i Iistc atrillllta koic stc iclentinkovali za s\'

Slika 12-.'5 prikazujc E/E dijagram obrade porudzhill

S strane, veza izmec1u entiteta Product Category (katcgorija arti~ kab) i Product (artikal) obavezna samo u jedn0l11 smeru. i\{oze postojati kategorija artikala kojoj ne pripada artikal, ali sV

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 jednostavno. "Entitet Kupac modeluje flzicke osobe i organizacije koje kupuju nase artikle". NajveCi problem ovde .ie, kao sto sam ustanovila, smisliti recenicu ko.1a nije beznadezna tautologija. "Entitet Zaposleni modelu.1e zaposlene u organizaciji" jedva vredi pomenuti.

Ako je veza modelovana k:ao entitet, stvmi se mogu zapetljati .ler ta.l entitet 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 predstavljaju 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 kupac. 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 naveli gde se sve podaci koriste, korisno je da te informacije navedete i u dokumentaciji 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 tako(\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 clostave robe odrec1enol11 kupeu, nih cia "Specijalni bonus" odrec1en za neku kategoriju 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 programe1'a zaduzenih za odrzavanje, ukoliko nisll detaljno dokumentovane.

Vecina analiticara doh1l11entuje te utic

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 dostave i Posebna uputstva", mora takode biti dokumentovano.

Atributi Poslednji element dokumentacije neophodan za entitete jeste spisak atributa 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 kombinaciju atributa. U tahim slucajevima, potreban vam je proizvoljan identifikator 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 050ba 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 podataka 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 zanemaruju postojanje domena i atribute preclstavljaju c1irektno s njihovim tipovima podataka i uslovima. Ako zanemarite taj korak postupka, velikom drustvu. To nece biti ispravno, ali te3ko da ce vam to iko zameriti.

11

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 posh 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 pojedinacno za svaki atribut, ali zasto bismo to radili? Osim toga, posto su atributi 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 kupaca 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 c1efiniSe 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 "datum 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. Ponekad cete to najlakse uCiniti ako zadate pravilo: "koliCine moraju biti pozitivne celobrojne vrednosti".

Ponekad je jednostav11ije da listu prihvatljivih vrednosti u do-menu. mora biti jedna od sledeCih: Severozapadna, S eve 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 izmene 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 odgovarajuCih 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 identifikovanja uslova koji treba da vaze u sistemu, a krsenjem definicije domena za domene koji se ponavljaju u modelu podataka stedi se vreme i smanjuje verovatnoca greske.

U specillkaciji clomena morate takocte zachti cia Ii su za atrihute cJellllisane u c10menu prilwatljive vreclnosti Nun, znakovni nizovi cluzine nub iIi jeclno i clrugo. Korisno je da to izriCito cleklarisete u clefiniciji clomena, C'ak i kac1 opseg vreclnosti moclelujete pomoeu nekog sistemskog entiteta, kacla se prilwatljivost 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 dodatni 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 clefinisani 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), trebalo 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, ometaeete 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 nigde 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", verovatno 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 zahoravite, 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 pojedinacno 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 elementima, 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 odluka 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 drugi 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 najvise 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 pogIavIju, 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 pokusao da izmeni (iIi da samo sbvati) monolitni sistem bilo kog stepena slozenosti, vise nikad nece na isti nacin pogledati tanjir spageta. Da bi uveli malo

201

rectl II zbrku, programeri Sli poceli clet strukturiruju svoj k6c1 U z

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

1 1 1 1

Komponenta Komponenta Komponenta

interfejsa interfejsa interfejsa

za podatke za podatke za podatke

1 Komponenta Komponenta

interfejsa za interfejsa za

transakcije transakcije

11 Komponenta interfejsa

za spoljasnji pristup za spoljasnji pristup

Komponenta interfejsa

1 1 Masina baze podataka

modelSlika 13-1

Sloj korisnickog interfejsa odgovara sloju korisnickih usluga u troslojnom 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 zahteva koje je korisnik zadao.

S]oj interfejsa za podatke oc1govoran je za oclrZHvanje poclataka U 111e1110riji (nasuprot trajnol11 euvanju vrcc1nosti poclntaka, Zit koje su zaduzeni sloj interfejsa Zit spoljasnji pristup i m

cia bude nezavisall od komponenata 11 slojl1 korisnickog interfejsa, vredl10sti koje se

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 ugradivanjem 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 resenje 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, programskog 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 lokalne mreze ili preko ne smem ni da pomislim mreze sirokog opsega iIi terneta 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, korisnik 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 namerama. 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 cloprinese 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 automatski. Kada za odredeno polje definiSete pravilo ispravllosti podataka nn nivou tabele, H zatim ga prevucete na vezan obrazac, obrazac nasleduje pravilo ispravnosti.

U verzijama Access,l pre 2000, ta moguenost je nazalost takodc dobar primer problema dvostmke provere ispravnosti. Ako nakon postavljanja polja n" vezan obrazac i70menite pravilo ispravllosti na nivou tabele, tc izmenc 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 clrugih aplikacija), morate rucno izmeniti pravila ispravnosti u 5vakol11 obrascll (ili taenije reeeno, u komponentama sloja interf(:~jsa 70n poclatke koje poclrzavaju obrasce).

Da biste resili tnj problem, mozete lIeitavati pravila ispravnosti iz masine baze podataka tokom rada aplikacije. Ta tehnika donekle opterecuje aplikadju, ali ako se pravila ispravnosti eesto menjaju, lose posledice dodatnog optereeenja 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. Preporucujem vam da to einite pri otvaranju obrasca. Ako to raclite pri pokretanju aplikadje, mozete llcitati nepotrebne informacije koje se oclnose na obrasce koje korisnik mozda neee otvoriti. Ukoliko to cinite pre svakog HZlIriranja 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 svaki zapis. Ali, buclimo renlni, moze Ii postojati sistem u kome se pravila ispravnosti 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

Komponenta korisnickog

Komponenta interlejsa za podatke

Komponenta interfejsa

za transakcije

Komponenta interfejsa za spoljasnji pristup

4 Aplikacija

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 komponenta) moze da postoji na razlicitom racunaru i da konmnicira s drugima preko odredene vrste mreze. U drugoj krajnosti, sve komponente rnogu cIa postoje 11

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, aplikacija 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 obrada 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 podacima 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 zavisi oel toga sta oni rade, a prvenstveno oel toga koliko je efikasan clizajn sistema. 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 poboljsanje prodaje odredenih artikala.

SmHnjivHllje optereeenja mreze neposrec1no utice na SCll1\l haze poc1ataka. lmajte II \'iclu to cla se cclokupna obrada oc1vija lla 10kal110111 racunaru; II izvesnom smislu, racunar na kOji.ic smestena baza poclatakl tretim se otprilike 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, precl1azem 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 10kalne racunare korisnika.

]'\a primer, liste artikala s kojima organizacija posluje u veCini slucajeva prilicno su stabilne, a cesto se referenciraju. Ako tabela artikala nije prevelika (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 Accessa, replikovanje ce vrlo lepo obaviti taj posao.

Liste postanskih brojeva, opstina, drZava i podela na regije koje se koriste 11 organizaciji, takocle su dobli kandidati za smestanje na lokalne raeunare 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, Jiste kupaca iii stuelenata obicno nisli pogodne za smestanje na lokalne racunare. 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 zamisliti kao neku vrstu mini tabele ciji se sadrzaj odrZava u zadatom redosledu; zapis te "tabele" sadrii samo polja koja su neophodna cia bi 5e zapisi izvorne tabele postavili u odredeni redosled, kao i "pokazivac" na stvarni zapis (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 saznate 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 tabeli 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