Poput nekog velikog magneta,
Windows efikasno "privlaåi"
nove i nove aplikacije: najpre
su mu se prilagodili grafiåki
programi, onda tekst procesori
a ovih dana Windows preotima
i poslednji veliki bastion DOS-
a, baze podataka. Rad u grafiå-
kom okruæenju oduvek je bio
komforniji i prijatniji, a sada
postaje i efikasniji...

Dejan Ristanoviñ

Nenad Batoñanin

orisnici "velikih" raåunara do skora
su sa priliånim prezirom gledali
baze podataka na PC-ju: oduvek su

bile šarenije, ali je opseænija analiza otkri-
vala da je uåinjen tek mali korak u razvoju
ozbiljnog sistema zasnovanog na (toliko
pominjanom) relacionom modelu. Time,
naravno, neñemo da kaæemo da su se PC-
jeve baze podataka mogle koristiti samo za
obradu kuñnog telefonskog imenika ili in-
ventara nekog magacina - moglo se ispro-
gramirati sve što je potrebno, ali je progra-
mer bio suoåen sa priliåno opseænim po-
slom, a korisnik koji zna o åemu se radi sa
veåitom neizvesnošñu: ako je programer
pogrešio u nekoj sitnici, podacima se crno
piše!

Sigurni smo da su problem itekako

osetili svi koji su koristili neku od starijih
verzija Clipper-a za pisanje iole sloæenijeg
programa. Nisu, moæda, umeli da ga teorij-
ski formulišu, ali im je bilo jasno kako se
manifestuje: podaci se prostiru kroz neko-
liko baza podataka, i dešava se da, zbog
neke greške u programu, hardverskog ili
softverskog problema (npr. nestanak stru-
je) ili, u najgoroj varijanti, neke nepredvi-
œene akcije korisnika, podaci u jednoj bazi
ostanu neusklaœeni sa podacima u drugoj.
Obrišete, recimo, slog nekog kupca ali "za-
boravite" da obrišete artikle koji su za nje-
ga rezervisani. Artikli se i dalje ne mogu
koristiti, jer se, bar što se programa tiåe, åu-
vaju za nekoga, a taj neko ne postoji! Åesto
nam se dešavalo da dobra treñina Clipper
koda koji napišemo ode na provere raznih
neregularnih situacija - åim neki upis u ba-

zu iz bilo kog razloga ne uspe, moraju se
"odmotati" i prethodni uspešno obavljeni
upisi kako bi podaci bili konzistentni. Naj-
veñi problem nastaje kada jedan upis ne
uspe, pokušate da opozovete prethodno
obavljene operacije a upisi i dalje ne uspe-
vaju, obiåno zbog nekog hardverskog pro-
blema. Kada se problem otkloni, korisnik
ñe morati da startuje (a vi ñete pre toga mo-
rati da napišete) program koji pregleda sve
baze, pronalazi logiåke nekonzistentnosti i
onda ih ispravlja, automatski ili na osnovu
uputstva operatera.

Zakon odræanja baze

Mnogi Clipper programeri mislili su da ta-
ko naprosto mora da bude, ali ñe ih neki
noviji paketi pokolebati u tom uverenju:
veñ na prvi pogled videñete da Microsoft
Access potpuno automatski odræava kon-
zistentnost podataka. I to je odræava bez
obzira na "trud" korisnika da tu konzisten-
tnost poremeti: probali smo åak i da pritis-
kamo hardverski reset tokom (namerno
izazvane) pauze koja prethodi upisu u ne-
ku od tabela, i sve je ostajalo u stanju u ko-
me je bilo pre poåetka åitave operacije.
Odræanje konzistentnosti, doduše, zahteva
neki minimum discipline od strane progra-
mera: treba dosledno koristiti mehanizam
transakcija o kojima ñe biti reåi kada bude-
mo prikazivali Access. Ta sitna paænja ulo-
æena u dizajn aplikacije višestruko ñe pove-
ñati njenu pouzdanost i uåiniti åitav sistem
daleko otpornijim na sve vrste problema.

Struånim jezikom reåeno, nove baze

podataka u znaåajnoj meri podræavaju re-
lacioni model. To je formalni, matematiåki
model baze podataka u kome se svi poda-
ci vide samo kao skup tabela. Naziv "rela-
cioni" potiåe od toga što matematiåke rela-
cije mogu da se predstave tabelama, pa se,
u stvari, u ovom modelu podaci vide kao
skup relacija; moæe se reñi da je relacioni
model u suštini naåin na koji se vide poda-
ci. Ovaj model obuhvata tri veoma vaæna
elementa: podatke, pravila i operatore. Po-
daci åine iskljuåivo skup relacija, odnosno
tabela. Pravila obezbeœuju oåuvanje inte-
griteta podataka. Jedno pravilo kaæe da se
element relacije (tabele) mora razlikovati
od ostalih - tabela mora imati tzv. primarni
kljuå na osnovu åije vrednosti se uvek je-
dnoznaåno pronalazi odgovarajuñi red (vi-
še o primarnom kljuåu docnije). Drugo
pravilo govori o vezama izmeœu tabela.

Neka se, na primer, za evidenciju poslov-
nih partnera u nekoj firmi uvedu tabele
Partneri i Gradovi, pri åemu se za svakog
partnera u tabeli Partneri navodi šifra od-
govarajuñeg grada. Ta šifra odgovara šifri
grada u tabeli Gradovi i zove se foreign key
(strani kljuå). Pravilo integriteta nalaæe da
u tabeli partnera ne sme postojati šifra gra-
da koji ne postoji u tabeli gradova. To zna-
åi da se ne sme dozvoliti brisanje grada ako
ima podataka koji se "referišu" na njega.

Treñi deo relacionog modela åini skup

operatora koji sluæe za razne manipulacije
sa podacima (tabelama). Tu su standardni
skupovni operatori unija, presek, razlika,
zatim specifiåne operacije kao što su pro-
jekcija i selekcija koje izdvajaju deo tabele i
sliåno. Primenom ovih operatora na posto-
jeñe tabele dobijaju se nove.

Vaænost relacionog modela najbolje

ilustruje C. J. Date u poznatoj knjizi "Data-
base Systems": relacioni model predstavlja
mašinski jezik savremenih i buduñih baza
podataka! Relacione baze podataka su da-
nas svakako preovlaœujuñe - uglavnom
zbog jednostavne implementacije, velikih
moguñnosti i jake formalne zasnovanosti.
Povremeno se sreñu sistemi zasnovani na
drugim modelima, obiåno mreænim i hije-
rarhijskim, a postoje i baze podataka sa
mešovitim pristupom.

Kodov model

Treba reñi da je gornji opis relacionog mo-
dela dat veoma grubo i u najkrañim crta-
ma. Pitanje oko koga se veoma dugo lome
koplja je "da li je neki sistem relacioni ili
ne"? Postoje uslovi koje je formulisao E.
Codd i koje treba da ispuni neka baza poda-
taka da bi se nazvala "relacionom". Na æa-
lost, ni jedna savremena baza podataka ne
zadovoljava sva ta pravila. Ipak, na osnovu
nekih pravila mogu se izdvojiti nekoliko
grupa baza podataka koje "konkurišu" za
naziv "relacioni sistem". Prvu grupu (koja
zadovoljava najmanje pravila) åine tzv. ta-
belarni sistemi. U njima se svi podaci vide
kao tabele, ali nema operatora koji operišu
sa tim tabelama na nivou skupova. Drugu
grupu åine tzv. minimalni relacioni siste-
mi koji imaju operatore selekcije, projekcije
i spajanja tabela. U ovu grupu se mogu
ubrojati i xBase proizvodi. Sledeñu grupu
åine baze koje podræavaju kompletniji
skup operatora (Oracle, Ingres, DB2, ...). Za-
kljuåak ove priåe je da xBase proizvodi u

Baze podataka

1 / APRIL 1995

SOFTVER

Windows baze podataka

suštini nisu pravi RDBMS sistemi, ali da po
osnovnoj koncepciji spadaju u relacione
baze podataka. Ono što im nedostaje je
uglavnom veñi skup operatora i nadgra-
dnja nad osnovnim sistemom za upravlja-
nje datotekama. Na primer, kod pravih re-
lacionih sistema se pravila za oåuvanje in-
tegriteta automatski "brinu" da foreign key
u jednoj tabeli uvak ima ispravnu vrednost
prilikom upisa, izmene ili brisanja podata-
ka iz baze, dok se rad kod veñine xBase pro-
izvoda izvodi na mnogo niæem nivou: sve
ove uslove mora da proverava program
prilikom svake operacije.

Razlog za sve ove nedostatke je veoma

jednostavan: do pre par godina PC raåuna-
ri nisu bili dovoljno moñni da bi se na nji-
ma vrtele baze podataka koje sve to omo-
guñuju! Meœutim, sada se situacija prome-
nila: PC raåunari su po moñi sasvim presti-
gli nekadašnje velike sisteme pa se neke
tradicionalno "velike" baze podataka sada
sele u "manja" okruæenja (Oracle, na pri-
mer). Sa druge strane, xBase proizvodi do-
bijaju nove elemente koji im poveñavaju
moñ i po karakteristikama ih sasvim pribli-
æavaju "velikim" bazama podataka. Na pri-
mer, nove verzije FoxPro-a podræavaju SQL
upite. Uåvršñivanje pozicije Windows-a i
masovna selidba aplikacija na novu plat-
formu je ovom procesu dala nov kvalitet:
prevazilaæenje DOS barijera je doprinelo
"unutrašnjem" kvalitetu baza podataka, a
grafiåki korisniåki interfejs je omoguñio
komforniji i atraktivniji spoljni izgled.

Što se popularnih proizvoda tiåe, Mi-

crosoft Access je najpopularnija baza poda-
taka koja se u velikoj meri prilagodila rela-
cionom modelu. Na raspolaganju su mo-
guñnosti oåuvanja integriteta u okviru je-
dne tabele (integrity enforcement) - ako se
uspostavi odnos izmeœu neka dva polja ta-
bele, sam Access ñe brinuti o tome da taj
odnos nikada ne bude narušen, bez obzira
da li se podacima pristupa iz programa ko-
ji je posebno prilagoœen toj bazi podataka,
direktno iz Access-ovih menija, iz nekog
posebnog Windows programa ili na bilo ko-
ji drugi naåin (naravno, ako vam ne padne
da pamet da startujete Norton Utilities i pi-
šete direktno po fajlu). Borland Paradox ta-
koœe ukljuåuje sve bitne osobine ovoga ti-
pa dok, recimo, FoxPro uopšte nema takvih
mehanizama. Pojedini generatori aplikaci-
ja, kao što je Clarion ili DataFlex, nalaze se
na polovini puta: ako kod generišete iz
njih, integritet tabele se garantovano oåu-
vava, ali ako samoj tabeli pristupite direk-
tno ili iz nekog drugog programa, zaštite
nema! Kod ostalih baza, integritet se oåu-
vava iskljuåivo kroz RANGE i VALID kla-
uzule GET naredbi i njihove ekvivalente.

SOFTVER - Baze podataka

1 / APRIL 1995.

Za detaljno testiranje odabrali smo

åetiri najveña i najznaåajnija Windows
RDBMS paketa - Borland-ov dBASE for
Windows 5.0, Visual Objects firme Compu-
ter Associates (naslednik kod nas toliko
popularnog Clipper-a), Microsoft Access
2.0 i FoxPro 2.6 for Windows (nekada proi-
zvod firme Fox Software, sada takoœe Mi-
crosoft-ov paket). Za testiranje je korišñe-
na mašina koju smatramo standardnom:
486/66 sa 256 K keša, 8 megabajta memo-
rije i brzim diskom od 500 megabajta.

Benchmark testovi su, u odnosu na

stara dobra DOS vremena, postali znatno
ozbiljniji problem: Windows interno kešira
rad, razlikuje se izvršavanje u pozadini i
u "prednjem planu" i, uopšte, merenje je
veoma osetljiva operacija u kojoj sitni
propusti mogu proizvesti veoma neprija-
tne rezultate. Opredelili smo se da pro-
grame testiramo primenom posebno pri-
lagoœenog paketa domañe proizvodnje,
koji se inaåe koristi u okviru Unitest-a za
procenu performansi raåunarskih siste-
ma i njihovih komponenti - rezultati su
prikazani u prateñem dijagramu i sami
po sebi su priliåno ubedljivi; ovde ñemo
samo opisati sam postupak testiranja i je-
dan ozbiljan problem na koji smo naišli.

Najpre se kreira baza od 10,000 slogo-

va sa sluåajnim sadræajem, a onda se me-
re parametri od znaåaja za rad sa podaci-
ma: pretraæivanje (traæi se pet razbacanih
podataka koji postoje u bazi, a zatim je-
dan koji ne postoji; test se ponavlja 4 pu-

ta), raåunanje (sabiraju se vrednosti je-
dnog numeriåkog polja, kroz sve slogove
baze, uz ponavljanje testa 12 puta), in-
deksiranje (formira se indeks åitave baze
po jednom alfanumeriåkom polju), in-
deksirano pretraæivanje (traæi se pet ra-
zbacanih podataka koji postoje u bazi, a
zatim jedan koji ne postoji, i to 100 puta)
i najzad sortiranje (po sadræaju alfanume-
riåkog polja, ponovljeno 4 puta). Vreme-
na nismo uproseåili, tj. dajemo svako od
njih posebno, pošto åitacima moæe biti od
interesa da procenjuju one segmente rada
koji su im u praksi najåešñe potrebni.

Prilagoœavanje istog programa za vi-

še razliåitih platformi uvek je sloæen po-
sao, pre svega zbog toga što bi "mehaniå-
ko" prevoœenje bilo nefer prema nekim
modernijim programima. Uz razne pro-
bleme koje smo rešavali "u hodu", naišli
smo na jedan koji se pokazao nerešivim:
prilikom testa pretrage, u jednom od po-
lja se javljao znak | koji, u poljima Access
baze, oznaåava sadræaj nekog polja tabele
(npr. |[datum]|). Posle konsultovanja
dokumentacije, help-a i raspitivanja po
domañim i stranim BBS-ovima, dolazimo
do zakljuåka da se vertikalna crta sama
po sebi nikako ne moæe traæiti, pa je baza
podataka koju smo koristili za testiranje
Access-a za bajt razliåita od baze na kojoj
smo testirali ostale programe. To svakako
nije uticalo na performanse, ali za åitaoce
koji koriste YUSCII raspored ovaj mome-
nat moæe da bude izuzetno neprijatan!