You are on page 1of 79

V I S O K A T E H N I K A K O L A

N I



ZAVRNI RAD


NORMALIZACIJA PODATAKA U
BAZAMA OTVORENOG KODA

Predmet: Baze podataka


Mentor: Student:
dr Miloevi Borivoje Stefan Konstantinovi
Rer 12/08

NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

2

V I S O K A T E H N I K A KOLA
NI

ZAVRNI RAD

NORMALIZACIJA PODATAKA I FUNKCIONALNA
ZAVISNOST U BAZAMA OTVORENOG KODA

Predmet: Baze podataka

mentor: Student:
dr Miloevi Borivoje Stefan Konstantinovi
Rer 12/08
lanovi komisije:
1. _______________
2. _______________




NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

3























NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

4

Sadraj

1. Uvod...........5
2. Entiteti ...................................................................................................................... 30
2.1 Veze izmeu entiteta ............................................................................................ 31
2.2 Troslojna arhitektura baze podataka .................................................................. 34
3. Modeli baza podataka............
4. Logiko projektovanje baza podataka ........................................... 37
4.2 Postupak normalizacije .............................................................................. 38
4.3 Prva normalna forma (1NF) ........................................................................ 39
4.4 Druga normalna forma ............................................................................... 41
4.5 Potpuna funkcionalna zavisnost ...................................................................................... 41
4.7 Trea normalna forma ................................................................................ 42
4.8 Boyce-Codd normalna forma (BCNF) .......................................................... 42
4.9 etvrta normalna forma(4NF) ................................................................... 43
4.10 Peta normalna forma (5NF) ...................................................................... 45
5. Baze otvorenog koda ........................................................................ 45
5.1 Upoznavanja sa bazama otvorenog koda ......................................... 45
5.2 Zajednica Otvorenog koda i kod ................................................................. 47
5.3 Migracija ka bazama otvorenog koda. Specifikacije. .................................. 50
5.4 Upoznavanje sa nekim popularnim bazama otvorenog koda ..................... 50
5.5 Baze otvorenog koda: Karakteristike ......................................................... 53
6.PRAKTIAN RAD ........................................................................... 58
6.1 Normalizacija i funkcionalna zavisnost podataka na primeru MySQL baze....56
7. ZAKLJUAK ..76


NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

5

1. Uvod
U radu na temi Normalizacija i funkrionalna zavisnost baza podataka otvorenog koda
Predstavili smo baze podataka prema nekoliko kriterijuma, a to su: potreba, znaaj,
mogunost izbora i primene, kao i princip koji kao postulat vai ve decenijama, tj. od njihovog
nastanka. Prvo poglavlje je sasvim saglasno sa prvim naslovom i bavi se ovim principima, daje
opti pregled i znaaj bazama podataka. Drugo poglavlje se nadovezuje, opisujui neke od sa-
dralaca i faktora baza bez kojih dalje prouavanje istih ne bi bilo mogue, kao to su entiteti i
veze izmeu njih. Tree, nam daje samo jedan nabrojen pregled modela baza, a ve sa etvrtim
poglavljem logiko projektovanje ulazimo u samu sr principa koji ine svaku bazu na svetu,
kao i temu nad kojom poinjemo rad. Peto poglavje je nastavak teme, nastavak zato to nam je
od znaaja bio najbitniji princip pojanjavanja teme kao i baza podataka bilo kog tipa, peto se
ve konkretno bavi bazama otvorenog i komercijalnog koda, kao i njihovim uporeivanjem.
I na kraju esto poglavlje nam daje vizualni rezultat svega prethodno navedenog na praktinom
primeru pa se samim tim poglavlje i zove praktian rad na primeru baze otvorenog koda
MySQL.
Baze podataka se koriste za prikupljanje, uvanje i manipulaciju podacima na osnovu kojih se
dobijaju nove informacije u razliitim organizacijama, kao to su poslovni sistemi zdravstvo,
kolstvo, vladine institucije itd. Svakodnevno ih koriste pojedinci putem linih raunara, radne
grupe putem mrenih servera i svi zaposleni putem aplikacija koje se nalaze u poslovnim
sistemima. Bazama podataka takoe pristupaju kupci i drugi udaljeni korisnici korienjem
razliitih tehnologija kao to su govorni automati, web itai (browser-i), digitalni telefoni i sl.
Zbog velike konkurencije u svim oblastima poslovanja, moe se oekivati da tehnologija baza
podataka dobije jo vei znaaj. Menaderi trae nain da iz baza podataka bre dou do novih
saznanja kako bi bili u prednosti u odnosu na svoju konkurenciju. Na primer, detaljna baza
podataka o prodaji se moe iskoristiti kako bi se saznalo koji kupci kupuju koje proizvode, to
se koristi kao osnova za reklamu i marketinku kampanju. Organizacije mogu da ukljue u
svoje baze podataka procedure koji se zovu okidai ili trigeri (alerts) koji upozoravaju o
moguim vanrednim dogaajima ( kao to su predstojei nedostatak neke robe ili ansa za
prodaju dodatne koliine robe) i na osnovu kojih mogu nastati odgovarajue reakcije. Mnoge
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

6

organizacije danas prave posebne baze podataka koje se zovu ,,skladite podataka (data
werehouses) koje slue kao aplikacije za podrku u odluivanju.
Izuavanje baza podataka i sistema za upravljanje bazama podataka jesu osnova za izuavanje
informacionih sistema. Strunjak za informacione sisteme mora biti spreman da analizira
potrebe preduzea i da dizajnira i implementira baze podataka u okviru informacionog sistema
jedne organizacije. Takoe, mora biti spreman da se konsultuje sa krajnjim korisnicima, i da im
pokae kako se korienjem baza podataka moe imati bolja podrka za odluivanje, ime se
stvara bolja prednost nad konkurencijom. iroko rasprostranjeno korienje baza podataka za
vezanih za Internet sajtove, koji vraaju dinamike informacije korisnicima web sajta, zahteva
od projektanta da razume ne samo kako da povee bazu podataka sa sajtom i ve i kako da je
obezbedi tako da se njenom sadraju moe pristupiti ali ne i izmeniti od strane spoljnih
korisnika.
Postoji puno naina kako se moe definisati baza podataka. U osnovi to je skup podataka
koji su organizovani prema potrebama korisnika, koji se odravaju i koji se koriste za dobijanje
informacija. Moderne baze podataka se uvaju na raunaru, ali to nije bitno za samu definiciju.
Na primer, adrese poznanika i prijatelja, kolekcija filmova na CD-ovima, telefonski imenik itd.
su takoe baze podataka (mada ih veina ljudi tako ne zove). Meutim, smetanje baze podataka
na raunar omoguava laku i bru obradu podataka i dobijanje eljene informacije.
Karakteristian je primer sa telefonskim imenikom koji se nalazi na papiru. Jednostavno je
pronai telefonski broj eljene osobe, ali je znatno tee pronai ime osobe na osnovu telefonskog
broja. Ako je telefonski imenik vei (vie smetenih podataka) prethodni problem se dodatno
uslonjava. Raunarski zasnovane baze podataka omoguavaju jednostavno i brzo dobijanje
informacija. Pored osnovnih informacija iz odgovarajue baze podataka se mogu dobiti i
posebne informacije. Na primeru telefonskog imenika mogu se izlistati podaci za sve osobe po
imenu npr. Marko, mogu se izlistati sve osobe kojima telefonski broj poinje npr. sa 2, osobe
kojima se telefonski broj zavrava sa 45 i jo mnogo toga.
Na razvoj baza podataka presudno je uticao razvoj raunara, razvoj mrea, kao i
klijent/server obrade. Istraivanje, projektovanje i upotreba baza podataka su vrlo brzo pokazali
niz svojih dobrih strana smanjeni trokovi odravanja; smanjena potreba za mrenim resursima
poboljan integritet podataka; donoenje ispravnih odluka na osnovu objektivnih informacija,
bra reakcija na tritu, itd.
Baza podataka smetena u raunaru, predstavljena je nizom bita, organizovanih u
bajtove, a sa vie bajtova u odgovarajuem formatu zapisuju se vrednosti pojedinih podataka i
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

7

predstavljaju jedno polje baze podataka. Niz polja se organizuje u zapise (rekorde) koji imaju
znaenje jer mogu da predstavljaju opis nekog objekta iz realnog sveta ili neke veze izmeu
objekata realnog sveta. Zapisi istog formata se slau i ine datoteke, koje su fiziki zapisane na
disku. Baza podataka obuhvata vie povezanih datoteka i moe biti centralizovana na jednom
raunaru ili distribuirana na vie meusobno udaljenih raunara.
Pored podataka koji su zapisani u bazi podataka, postoje i posebni podaci kojima se
opisuju pojedinane datoteke, njene osobine, karakteristini parametri iz datoteka, uspostavljene
meusobne veze, pravila koja se odnose na pojave koje postoje i u realnom svetu i sl. Takvi
podaci se zovu meta-podaci (metadata), tj. podaci o podacima. Koriste se pri pokretanju rada sa
bazom podataka, kako bi se mogli uitati svi konfiguracioni podaci odgovarajue baze (self-
describing).



Slika 1. Baze podataka nekada i danas

1.1 Osnovni koncepti i definicije
Baza podataka se moe definisati kao organizovani skup logiki povezanih podataka. Ona
moe biti bilo koje veliine i kompleksnosti. Na primer, prodavac moe da ima malu bazu
podataka vezanu za kupce na svom notebook raunaru koja se sastoji od nekoliko megabajta
podataka. Preduzee koje zapoljava hiljadu i vie ljudi moe da ima veoma veliku bazu
podataka od nekoliko terabajta podataka (jedan terabajt = 1012 Gigbajtova) na mainframe
kompjuteru na kome se nalazi aplikacija za podrku odluivanju. Veoma velika skladita
podataka imaju vie od petabajta podataka (1 petabajt = 1000 terabajtova). U irem smislu, bazu
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

8

podataka moemo posmatrati kao integrisani skup podataka o nekom sistemu i skup postupaka
za njihovo odravanje i korienje, organizovan prema potrebama korisnika. To je dobro
struktuirana kolekcija podataka, koja postoji jedno odreeno vreme, koja se odrava i koju
koristi vie korisnika ili programa.
1.2 Podatak
Istorijski, pod terminom podatak se podrazumeva injenica o nekom predmetu i/ili dogaaju
koja se moe zabeleiti i sauvati na raunaru. Na primer, u bazi podataka nekog prodavca
podaci bi bile injenice kao to su ime, adresa i broj telefona kupca. Ovakav tip podatka se
zovestruktuirani podatak. Najvaniji struktuirani podaci su brojevi, karakteri i datumi (vreme).
Dananje baze podataka pored struktuiranih podataka sadre i druge vrste podataka kao to su
razna dokumenta, mape, fotografije, zvuk, ak i video zapise. Na primer, u bazi podataka nekog
prodavca mogla bi se nai i slika kupca. Takoe bi se mogao nai zvuni ili video zapis
poslednjeg razgovora sa kupcem. Ova vrsta podatka se naziva nestruktuirani podatak ili
multimedijalni podatak. Multimedijalni podaci se najee mogu nai na web serverima i u
Internet bazama podataka.
Danas se podatak definie kao sauvana reprezentacija predmeta i/ili dogaaja koja ima
smisla i vanosti za korisnika baze podataka. Ova definicija ukljuuje i struktuirane i
nestruktuirane podatke. esto se u okviru jedne baze podataka mogu nai kombinovani
struktuirani i nestruktuirani podaci kako bi se stvorilo multimedijalno okruenje. Na primer,
automehaniarska radnja moe kombinovati struktuirane podatke (koji opisuju klijenta i njegova
kola) sa multimedijalnim podacima (slika automobila i skenirana kopija osiguranja).
Pod podatkom se podrazumeva injenica prihvaena kao takva tj. kakva jeste. Podatak
sam po sebi nema znaenje, tek kada se interpretira nekom vrstom sistema za obradu podataka
poprima znaenje i postaje informacija. Tipino, termin podatak se odnosi na ono to je u bazi
podatak. Dakle, podatak je sirova injenica - neobraena informacija. Raunar vri
obradu podataka, prema zadatom programu, te se na osnovu saznanja sadranih u podacima, a
kao rezultat njihove obrade, stiu nova saznanja - informacije.
1.3 Informacija
Termini podatak i informacija su usko povezani i esto se koriste kao sinonimi.
Meutim, korisno je razlikovati termine podatak i informacija. Informaciju definiemo kao
podatak koji je bio obraen na takav nain da se znanje osobe koja koristi podatak povealo. Na
primer, razmotrimo sledei spisak injenica: Prikazane injenice po definiciji pretstavljaju
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

9

podatke, ali bi se veina sloila da su ovi podaci u sadanjoj formi beskorisni. ak iako
pretpostavljamo da se radi o imenima osoba i njihovim matinim brojevima, podaci ostaju
beskorisni jer ne znamo emu slue.





Slika 2. Skup podataka

Pogledajte ta se dogaa kada stavimo ove iste podatke u kontekst, kao to je pokazano
na slici 2. Dodavanjem jo nekoliko dodatnih podataka i njihovim ureivanjem, prepoznajemo
spisak upisanih studenata. Na ovaj nain se dolazi do informacije koja je korisna npr. upravi
fakulteta, profesorima, studentskoj slubi i sl.

Tabela 1. Tabelarni prikaz podataka iz BP - informacija o upisu
Drugi nain da se iz podataka dobiju informacije je da se podaci sumiranjem ili na neki
drugi nain obrade i prezentuju. Na primer, na slici 3 se vide sumirani podaci o upisu studenata
prezentirani u vidu grafike informacije. Ova informacija se moe iskoristiti kao osnova za
odluivanje o dodavanju novih predavanja ili o zapoljavanju novog nastavnog kadra. Moderne
baze podataka vrlo esto sadre i podatke i informacije. Podaci se esto obrauju i uvaju u
Ime i prezime JMBG Smer Godina upisa
Petar Petrovi 1506983710325 PP 2002
Marko Markovi 0211979850123 RGD 2001
Janko Jankovi 1112985830456 PP 2001
- - - - - - - - - - - - - - - - - - - - - - - - - - RGD 2003
Petar Petrovic 150698371
0325
Marko Markovic 021197985
0123
Janko Jankovic 111298583
0456
- - - - - - - - - - - - - - - - - - -
- - -

NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

10

obraenoj formi i slue za pomo pri donoenju odluka, a takvim podacima (informacijama) se
najbre pristupa.

.
Slika 3. Grafiki prikaz podataka iz BP - informacija o upisu

Podaci obraeni tako da dobijaju znaenje ine informaciju. Informacija koja je precizna,
relevantna, i dobijena na vreme je klju za donoenje dobre odluke.



-----------------------


Slika 4. Obradom prikupljenih podataka nastaje informacija
1.4 Metapodaci - podaci o podacima (metadata)
Podaci koji se prikupljaju i uvaju u bazi podataka esto se nazivaju i podaci krajnjih
korinika (end user data). Metapodaci su podaci koji opisuju svojstva ili karakteristike podataka
krajnjih korisnika i kontekst tih podataka. Neka tipina svojstva podataka su naziv (ime)
podatka, definicija, duina (veliina), i dozvoljene vrednosti. Kontekst podataka, koji opisuju
Gimnazija 58
Tehnika
79
Ekonomska
45
Ostali 63
Gimnazija
Tehnika
Ekonom.
Ostali
Obradapodataka
Podatak1
Podatak2
Podatak3
PodatakN
Informacija
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

11

metapodaci, podrazumeva izvor podataka, gde se uvaju podaci, vlasnitvo i korienje.
Metapodaci opisuju svojstva podatka ali se nalaze odvojeno od tog podatka. Metapodaci iz
tabele 1 ne prikazuju ni jedan podatak. Oni omoguavaju dizajnerima i korisnicima baza
podataka da razumeju koji podaci postoje u bazi, ta oni znae, i koja je razlika izmeu podataka
koji na prvi pogled izgledaju isto. Upravljanje metapodacima je veoma bitno jer podaci bez
jasnog znaenja mogu biti zbunjujui, pogreno protumaeni ili puni greaka.







Tabela 2. Primer Metapodataka

Naziv Tip Du. Min Max Opis Izvor
Ime Text 30 Ime i
prezime
studenata
Lina karta
JMBG Integer 1 Jedinstveni
matini broj
Lina karta
Smer CHAR 3 Smer na
Fakultetu
Studentska
sluba
GdUpisa Number 2001 Godina upisa Studentskasluba
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

12

1.5 Sistem za upravljanje bazama podataka
Sistem za upravljanje bazama podataka (DBMS - Data Base Management System) je
softverski sistem koji se koristi za kreiranje, odravanje i manipulisanje podacima, kao i za
kontrolu prava pristupa bazi podataka. DBMS omoguava krajnjim korisnicima i programerima
da dele podatke, tj. omoguava da se podaci koriste od strane vie aplikacija, a ne da svaka
aplikacija ima svoju kopiju podatka sauvanu u posebnim datotekama. DBMS takoe prua
mogunost kontrole pristupa podacima, osigurava integritet podataka, uspostavlja kontrolu
konkurentnosti i vri oporavak baze podataka. Programeri aplikacija za rad sa bazama podataka
ne moraju da poznaju detalje o nainu zapisa baze podataka na disku, ne moraju da formuliu
algoritme za efikasan pristup podacima, niti su optereeni bilo kakvim aspektima oko
upravljanja podacima u bazi podataka.
Danas je veoma bitan i znaajan koncept baze podataka po kome je to, ustvari, zajedniki
resurs koga istovremeno (konkurentno) koristi vei broj programa, jer se pravi efekti baze
podataka ispoljavaju kada se radi umrenom okruenju. Posmatrajmo bazu podataka jedne
banke u kojoj se nalaze rauni graana. Mogue je da se u istom trenutku na alteru u jednoj
ekspozituri podie novac sa jednog rauna i uplauje na drugi raun, a da se istovremeno u
sasvim drugoj ekspozituri uplauje novac na isti taj raun. Pomenuti DBMS je upravo tu da
upravlja konkurentnim radom vie korisnika i da obezbeuje sinhronizaciju njihovog rada.
Takoe, DBMS ima funkciju da sprei tetne posledice (narueni integritet baze,
nekonzistentno stanje baze...) pri promenama (transakcijama) koje se vre nad bazom podataka u
viekorisnikom okruenju. U tu svrhu postoje razne tehnike kao to su tehnika zakljuavanja
podataka, tehnika vremenskog markiranja itd. Posebno je znaajno upravljanje istovremenim
(konkurentnim) transakcijama. Tanost, zatita i dostupnost baza podataka, kao i korektnost i
performanse transakcija koje pristupaja tim bazama su bitni parametri za uspeh svakog
poslovnog sistema. Termini baza podataka i upravljanje bazom se ponekad meaju. Struno
govorei, baza podataka je uvek skup injenica, a ne raunarski program.
DBMS je uveden kao interfejs izmeu korisnika ( korisnikih programa, aplikacija) i
zapisa baza podataka na disku. Korisniki programi ne pristupaju podacima direktno, ve
komunicaraju sa ovim softverom (programom). DBMS upravlja strukturom baze podataka:
definie objekte baze, njihova svojstva (atribute), dozvoljene vrednosti atributa, veze izmeu
objekata, ogranienja nad objektima i meusobnim vezama. Omoguava manipulaciju podacima
u bazi: unoenje, brisanje i izmene, tj. omoguava njeno odravanje. Kontrolie pristup
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

13

podacima: ko moe da pristupi podacima, kojim podacima i ta moe sa njima da radi. DBMS
dozvoljava deljenje BP izmeu vie aplikacija/korisnika i ini upravljanje podacima uspenijim i
delotvornijim. Uobiajeno je da kada se govori o softveru za baze podataka, onda se misli
upravo na DBMS. DBMS upravlja interakcijom izmeu krajnjih korisnika (aplikacija) i baze
podataka. Krajnji korisnici imaju bolji pristup veem broju bolje organizovanih podataka.











1.6 Klasian sistem zasnovan na datotekama
Kada su se raunari poeli koristiti za obradu podataka, nisu postojale baze podataka. Raunari
su u to vreme bili znatno slabiji nego dananji personalni raunari, zauzimali su itavu prostoriju
i koristili su se skoro iskljuivo za nauna izraunavanja. Postepeno su raunari uvoeni u
poslovni svet. Da bi bili od koristi za poslovne aplikacije, raunari moraju da skladite,
manipuliu, i preuzimaju velike datoteke podataka. Kako su poslovne aplikacije postajale sve
kompleksnije, postalo je oigledno da klasini sistemi zasnovani na datotekama imaju veliki
broj nedostataka i ogranienja. U veini bitnih poslovnih aplikacija danas se umesto klasinog
sistema zasnovanog na datotekama koriste baze podataka.


Baza podataka- podaci na disku
Database Management System
Baza podataka
Aplikacija X
Aplikacija Y Aplikacija Z
Slika 5 DBMS je interfejs izmeu (aplikacija) korisnika i
zapisa podataka baze na disku
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

14






Klasian sistem obrade podataka zasnovan na datotekama i programskim jezicima prikazan je
blok emom na sledeoj slici. Programi su direktno povezani sa datotekama, svaki program
mora da poznaje detaljan zapis podataka na disku.











Da bi objasnili osnovne karakteristike sistema zasnovanog na datotekama, posmatrajmo jednu
fabriku sa odreenim proizvodnim programom. Pretpostavimo da su nabavljene raunarske
aplikacije za voenje poslovanja ove fabrike realizovane na klasinim sistemima koji se
zasnivaju na datotekama. Ovaj pristup dizajnu informacionog sistema se fokusira na potrebe za
obradom podataka pojedinanih odeljenja, a ne na potrebe organizacije kao celine. Kada bi se
kod korisnika javila potreba za novim sistemima pisali bi se novi raunarski programi za
individualne aplikacije kao to su kontrola proizvoda, prijem rauna, ili kadrovski poslovi. Svaki
od programa pravi se tako da odgovara potrebama odreenog odeljenja ili radne grupe. Prema
tome, ne postoji opti plan, mapa ili model kojim bi se rukovodili za planiranje razvoja sistema.
Tri raunarske aplikacije (A, B i C) pomou kojih se obrauju podaci zapisani u datotekama su
prikazane na slici 7. Programima se odravaju tri nezavisna sistema porudbine, naplate i plate.
Na slici se takoe vide osnovne datoteke vezane za svaku aplikaciju. Na primer, proces
porudbina ima tri datoteke: podaci o kupcu, podaci o proizvodima, podaci o porudbinama.
Datoteka X1
Datoteka X2
Datoteka X3
Datoteka Y1
Datoteka Y2
Datoteka Z1
Datoteka Z2
Datoteka Z3
Datotke -podaci na disku
Aplikacija X Aplikacija Y Aplikacija Z
Slika 6. Klasian sistem obrade podataka zasnovan
na programskim jezicima i datotekama
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

15

Neke od datoteka se ponavljaju u sva tri procesa (redudansa) to je tipino za sistem obrade
podataka koji se zasniva na datotekama.

Odeljenje prodaje Raunovodstvo Finansije







Slika 7 Klasina obrada podataka zasnovana na sistemu datoteka
1.7 Nedostaci sistema zasnovanog na datotekama
Postoji vie mana koje su tipine za sistem koji je zasnovan na datotekama i klasinim
programskim jezicima. Ove mane za primer prikazan na slici 1.7 kratko su opisane u nastavku.
Zavisnost izmeu programa i podataka
Opisi datoteka se uvaju u okviru svakog programa koji pristupa toj datoteci. Na primer,
u procesu porudbine sa slike 7 program A pristupa datoteci sa podacima o kupcu. Stoga,
ovaj program sadri detaljan opis datoteke. Kao posledica ovoga, svaka promena koja se
napravi u datoteci, a odnosi se na strukturu, momentalno podrazumeva da se mora
menjati i opis datoteka u svakom programu koji pristupa tim podacima. Primetite na slici
7 da se podaci o kupcima nalaze i u procesu porudbine i u procesu naplate.
Pretpostavimo da se veliina polja "adresa kupca" menja sa 20 karaktera na 30 karaktera.
Opis datoteke u svakom programu (moda ak u svih tri) se mora aurirati. esto je
teko i samo lociranje svih programa na koje je uticala ovakva promena. to je jo gore,
pri auriranju se esto prave greke.
Redudansa podataka
Porudbine
Naplate Plate

Podaci o
kupcu
Podaci o
zaposlenima
Podaci o
proizvodima
Podaci o
porudbini
podaci o
kupcu
cene
proizvoda
A B C
A B
B A
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

16

Kako se u prikazanom sistemu procesi odvijaju nezavisno jedni od drugih, ponavljanje
podataka nije izuzetak ve je pravilo. Na primer, na slici7 proces porudbina ima
datoteke sa osnovnim podacima o proizvodima dok proces naplate ima datoteku o
cenama proizvoda.

Dakle, obe ove datoteke sadre podatke o istim proizvodima kao to su: cena po jedinici
proizvoda, opis proizvoda, i kolina u skladitu. Zbog nepotrebnih duplikata potreban je
vei prostor za njihovo uvanje kao i vie truda i rada pri njihovom auriranju.
Neplanirana redudansa podataka moe da dovede do gubitka podataka. Na primer, isti
podaci mogu se voditi pod razliitim imenima atributa u razliitim dokumentima, ili
obrnuto, isto ime se moe koristiti za razliite vrste podataka.
Ogranienost deljenja podataka
Korienjem klasinog sistema zasnovanog na datotekama, svaki proces ima svoje
datoteke i korisnici nemaju ansu da meusobno dele podatke sa korisnicima iz drugih
procesa. Na slici 7 se vidi da radnici u raunovodstvu imaju pristup samo procesu
naplate, dok nemaju pristup procesima porudbina i plata. Menaderi su imali velike
probleme pri sastavljenju izvetaja za koje su im bili potrebni podaci iz razliitih
procesa, jer bi se esto desilo da su dokumenta nekompatibilna i da je potrebno dosta
programiranja kako bi se svi ti podaci sakupili u jedan izvetaj. Takoe, dodatni problem
je bio u tome to su se eljeni podaci esto nalazili u razliitim odeljenjima organizacije.
Dugo vreme za razvoj
Sa klasinim sistemom zasnovanom na datotekama postoji mala ansa za korienje
prethodnih razvojnih dostigua. Svaka nova aplikacija zahteva od projektanta da krene
od nule. Svaki put je neophodno definisati nove formate i opise podataka i pisati kod za
pristup podacima za svaki program. Ovako veliko potrebno vreme za razvoj nije u
skladu sa dananjim poslovnim potrebama, gde je svaki minut bitan da bi se postigao
uspeh.
Teko odravanje programa
Skup svih prethodno navedenih nedostataka dovodi do preterane potrebe za odravanjem
programa. ak 80% budeta predvienog za razvoj sistema zasnovanog na datotekama
odlazi na njegovo odravanje. Zbog toga, naravno, ostaje jako malo prostora za razvoj
novih aplikacija.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

17

Vano je znati da veina mana klasinog sitema zasnovanog na datotekama, koje smo u
prethodnom delu teksta pominjali, mogu isto tako biti ogranienja za bazu podataka, pogotovo
ako se ne promeni pristup razvoju baze podataka. Na primer, ukoliko preduzee razvije nekoliko
zasebnih baza podataka (recimo, za svaku radnu jedinicu ili proces po jednu bazu) sa malom ili
nikakvom vezom izmeu njih, onda moe doi do bespotrebnog ponavljanja istih podataka,
ogranienja deljenja podataka, produavanja vremena potrebnog za razvoj i preterane potrebe za
odravanjem programa.

1.8 Pristup zasnovan na bazama podataka
Pristup zasnovan na bazama podataka potencira integraciju i deljenje podataka izmeu svih
odeljenja jedne organizacije. Ovaj pristup zahteva potpunu promenu u nainu razmiljanja,
poevi od najvieg nivoa upravljanja. Takva promena naina razmiljanja za veinu
organizacija je veoma teka.
Da bi objasnili pristup zasnovan na bazama podataka posmatrajmo prethodno razmatrani
zastareli informacioni sistem fabrike koji se klasino zasnivao na datotekama. Koncept pristupa
razvoju informacionog sistema zasnovanog na bazama podataka prikazan je na slici 8. Odmah se
moe uoiti da podaci koji su prethodno uvani u vie razliitih datoteka, sada su integrisani u
jedinstvenu bazu podataka.
Takoe, metapodaci koji opisuju ove podatke se nalaze zajedno sa njima u bazi podataka. Sistem
za upravljanje bazama podataka prua mogunost stvaranja razliitih pogleda na istu bazu
podataka (ili baze podataka) za razliite korisnike u organizaciji. DBMS dozvoljava korisnicima
da dele, pretrauju, pristupaju i auriraju integrisanim podacima








NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

18








Slika 8 Blok ema informacionog sistema zasnovanog
na bazama podataka

1.9 Prednosti pristupa zasnovanog na bazama podataka
Pristup zasnovan na bazama podataka ima mnogo potencionalnih prednosti u odnosu na pristup
zasnovan na datotekama. Te potencionalne prednosti su sledee:
Nezavisnost izmeu programa i podataka
Odvajanje metapodataka od aplikacija koje koriste podatke naziva se nezavisnost
podataka. Ova osobina kod baza podataka dozvoljava promenu i prenos podataka
organizacije na druge raunarske sisteme bez potrebe za promenom programa koji
obrauje ove podatke.
Minimalna redudansa podataka
Cilj pristupa zasnovanog na bazama podataka je da se podaci koji su se u prethodnom
pristupu uvali odvojeno (i vie puta su zbog toga ponavljani) sada integriu u
jedinstvenu logiku strukturu. Svaki podatak se nalazi samo na jednom mestu u bazi
podataka. Pristup zasnovan na bazama podataka ne uklanja redudansu u potpunosti, ali
omoguava projektantu baze podataka da paljivo isplanira vrstu i koliinu redudanse. U
nekim sluajevima je poeljno napraviti ogranienu redudansu kako bi se performanse
baze podataka poboljale (npr. bra pretraga).
Poboljana konzistentnost podataka
Eliminisanjem (ili kontrolisanjem) redudanse podataka, u velikoj meri se smanjuju anse
za nekonzistentnou podataka. Na primer, ukoliko je adresa kupca zapisana na samo
jednom mestu ne moe da postoji ne podudaranje u podacima u bazi podataka. Takoe,
auriranje podataka je u velikoj meri uproeno, kada je svaka vrednost zapisana na
Odeljenje prodaje
Raunovodstvo
Finansije
Aplikacija
baze
podataka
DBMS
Kupci
Zaposleni
Proizvodi
Porudbine
. . . . . . . . . . . . .
Metapodaci
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

19

samo jednom mestu. Na kraju, uklanjanjem redudanse podataka dolazi do utede
memorije.
Poboljana razmena podataka
Baza podataka je dizajnirana kao resurs organizacije koji koriste svi njeni zaposleni
(kojima je ona neophodna u opisu posla). Odreenim internim i eksternim korisnicima je
dozvoljeno korienje baze podataka, i svaki od njih (bio u pitanju jedan korisnik ili
grupa) ima jedan ili vie pogleda koji mu olakavaju korienje baze podataka.
Korisniki pogled je logiki opis jednog dela baze podataka koji je neophodan korisniku
da obavi neki zadatak.
Poveana produktivnost u razvoju aplikacija
Velika prednost pristupa zasnovanog na bazama podataka je ta to se u znatnoj meri
smanjuju trokovi i vreme potrebno za razvoj novih poslovnih aplikacija. Postoje dva
vana razloga zato se aplikacije baza podataka razvijaju znatno bre nego kod klasinih
sistema sa datotekama:
1. Pretpostavljajui da su baza podataka i sve propratne aplikacije ve napravljene i
implementirane, programer se moe koncetrisati na odreenu funkciju koja je
neophodna za novu aplikaciju, a ne mora da razmilja o definisanju podataka ili o
detaljima vezanim za implementaciju.
2. DBMS prua veliki broj alata za izvetavanje, kao to su generatori formi i izvetaja,
i jezike uz pomo kojih se automatizuju neke od aktivnosti kao to su dizajn i
implementacija baza podataka.
Smanjena potreba za odravanjem programa
Sauvani podaci se moraju esto menjati iz velikog broja razloga: nove vrste podataka se
dodaju, formati podataka se menjaju, i tako dalje. Poznat primer ovoga problema je ulazak u
2000-tu godinu, kada se sa uobiajenog sistema prikazivanja godina sa dve cifre moralo
prei na etiri cifre. U sistemu obrade datoteka, metapodaci i logika pristupanju podacima se
nalaze u individualnim aplikacionim programima (ovo je zavisnost izmeu programa i
podataka o kojoj je ranije bilo rei). Kao rezultat ovoga, promena formata podataka i metoda
pristupanja momentalno dovodi do potrebe menjanja aplikativnih programa.
Kod baza podataka, podaci su znatno vie nezavisni od aplikativnih programa koji ih koriste. U
okviru odreenih granica, moemo da promenimo jednu od stavki, format podataka ili
aplikativni program, a da ne moramo da promenimo drugu stavku. Kao rezultat ovoga, javlja se
smanjenje potreba za odravanjem programa.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

20

1.10 Trokovi i rizici pristupa zasnovanog na bazama podataka
U prethodnom delu teksta navedeno je nekoliko glavnih potencijalnih prednosti pristupa
zasnovanog na bazama podataka. Meutim, kod velikog broja organizacija bilo je razliitih
problema kod ostvarenja iskorienja tih prednosti. Na primer, postizanje nezavisnosti podataka
(i stoga, smanjene potrebe za odravanjem programa) se pokazalo kao teko ostvarivo zbog
ogranienja starijih modela baza podataka i softvera za upravljanje bazama podataka. Na sreu,
relacioni modeli (kao i noviji objektno-orjentisani modeli) nemaju ovih problema. Drugi razlog
za neuspeh da se iskoriste ove prednosti, je loe planiranje i implementacija baza podataka
ak ni najbolji softver za upravljanje bazama podataka ne moe da prevazie ovakve
manjkavosti. Pristup zasnovan na bazama podataka sadri neke dodatne trokove i rizike koji se
moraju reavati kada se sistem pone primenjivati.
Novo, obueno osoblje
esto se deava da preduzee, koje se odlui za pristup zasnovan na bazama podataka,
mora da anagauje ili obui ljude za projektovanje, implementiranje i odravanje baza
podataka, kao i da te ljude ukljui u postojeu radnu organizaciju. Dalje, zbog estih
izmena i brzine razvoja tehnologije, znanje ovog novog osoblja zahteva stalnu
nadgradnju i unapreivanje. Jedino obueno osoblje moe da izvue maksimum korisnosti
iz novih tehnologija.
Trokovi i sloenost instaliranja, upravljanja i rada sistema sa bazama podataka
Viekorisniki sistem za upravljanje bazama podataka je veliki i sloen softver koji u
startu mnogo kota, zahteva obueno osoblje za instaliranje i rad i ima znaajne godinje
trokove za odravanje i tehniku podrku. Instaliranje ovakvog sistema moe
zahtevati nadogradnju hardvera. Stalne obuke se podrazumevaju, da bi se mogle pratiti
nove verzije i nadogradnje softvera. Takoe se moe pojaviti potreba za dodatnim i
skupljim softverom za baze podataka radi vee sigurnosti podataka.

Trokovi prilagoavanja (konvertovanja) podataka
Termin nasleeni sistemi se uglavnom koristi kada se govori o starijim aplikacijama u
preduzeu koje su bazirane na pristupu datoteka ili starijim bazama podataka. Trokovi
prilagoavanja ovakvih starijih sistema za rad sa modernim bazama podataka (mereni u
novcu, vremenu i zahtevnosti posla) esto deluju kao velika prepreka za preduzee.
Potreba za izradom sigurosnih kopija i oporavkom podataka (backup)
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

21

Deljena baza podataka preduzea uvek mora biti tana i dostupna. To zahteva razvijanje i
korienje jasnih procedura izrade sigurnosnih kopija kao i oporavak baze podataka kada
neko oteenje nastane. U dananjem okruenju, gde postoje raznovrsni bezbednosni
rizici, reavanje ovog problema je od izuzetne vanosti. Moderan sistem za upravljanje
bazama podataka obino sam obavlja izradu sigurnosnih kopija i oporavak podataka u
sluaju havarija.
Konflikti u organizaciji
Deljena baza podataka zahteva saglasnost u vezi sa definicijama i vlasnitvom podataka,
kao i utvrenu osobu ili osobe odgovorne za odravanje podataka. Iskustvo je pokazalo
da nesuglasice u pogledu definicija podataka, formata i kodiranja podataka, prava na
auriranje deljenih podataka i sl. su esta i vrlo teka tema za reavanje. Da bi se ovi
problemi reili potrebno je da je organizacija u potpunosti posveena
uvoenju/koritenju pristupa zasnovanog na bazama podataka. Zatim je potreban
sposoban administrator baze podataka kao i smislen pristup razvoju baza podataka.
Ukoliko podrka i posveenost glavnih menadera za pristup okrenut bazama podataka
izostane, velika je ansa da e krajnji korisnici razviti vei broj samostalnih baza
podataka. Ove baze podataka e teko pruiti prednosti koje smo prethodno opisali. U
krajnosti, one mogu da dovedu do donoenja loih odluka to naravno ugroava celu
organizaciju.
1.11 Primene baza podataka
Vrste baza podataka variraju od onih pravljenih za jednog korisnika PC raunara do baza koje su
smetene na glavni raunar (mainframe) i kojima pristupaju hiljade korisnika. Po broju korisnika
koji im pristupaju, baze podataka se mogu podeliti u vie kategorija: line baze podataka, baze
podataka za radne grupe, baze podataka odeljenja, baze podataka preduzea i Internet, intranet i
ekstranet baze podataka.
1.12 Line baze podataka
Line baze podataka se prave za korienje od strane jednog korisnika i ve su dugo prisutne u
korienju personalnih raunara. Pojavom linih digitalnih pomonika (PDA), line baze
podataka su nale primenu i u nizu mobilnih ureaja koji osim raunarskih imaju i neke druge
primene npr. mobilni telefoni, faks maine, Internet itai. Jednostavne aplikacije sa bazom
podataka u kojoj uvaju informacije i detalji o komunikaciji sa svakim klijentom, mogu da se
koriste i sa raunara i sa linog digitalnog pomonika, kao i da se prebacuju sa jednog na drugi
ureaj radi izrade sigurnosnih kopija (backup) ili zbog zahteva posla. Uzmimo za primer
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

22

preduzee koje ima odreeni broj prodavaca koji su u kontaktu sa postojeim i potencijalnim
klijentima. Ako svaki prodavac ima jo neke aplikacije, npr. grafike prezentacije, cenovnik sa
uslovima prodaje po kojem klijentu moe ponuditi najpovoljniju kombinaciju proizvoda i
koliina za naruivanje, onda bi mu za takav posao prenosni raunar, zbog svojih performansi i
skladinog prostora, mogao biti optimalno reenje. S druge strane, ako prodavac ima samo listu
klijenata i kontakata, njemu bi lini digitalni pomonik i aplikacija koja koristi malu bazu
podataka bili najbolje reenje.
Line baze podataka se iroko primenjuju jer esto mogu bitno unaprediti produktivnost
pojedinca. Meutim, one sadre jedan faktor rizika: podatke ovih baza nije lako deliti sa drugim
korisnicima. Na primer, ako bi menader prodaje eleo celokupan spisak klijenata i kontakata, to
se ne bi moglo ni brzo ni lako uraditi uzimanjem podataka iz linih baza svakog od prodavaca.
Ovo ilustruje veoma est problem: ako su neki podaci od interesa jednom oveku, onda su
verovatno (ili e brzo postati) od interesa i drugim ljudima. Zbog toga, line baze podataka bi
trebalo svesti na korienje pod posebnim okolnostima (npr. u veoma malim preduzeima) gde
je verovatnoa potreba za deljenjem podataka izmeu korisnika izuzetno mala.
1.13 Baze podataka za radne grupe
Radnu grupu ini relativno mali broj ljudi koji sarauju na jednom projektu ili aplikaciji ili na
grupi slinih projekata ili aplikacija. Radna grupa obino sadri desetak ljudi. Oni mogu biti
ukljueni u npr. planiranje, projektovanje ili razvoj novog raunarskog programa. Baza podataka
za radne grupe slui za podrku zajednikog rada jedne takve grupe. Uzmimo za primer, radnu
grupu koja pravi i standardne i programe po porudbini, koji se prodaju softverskim
kompanijama kao i krajnjim korisnicima. Obino, jedna ili vie osoba rade na datom programu,
ili dele programe, u isto vreme. Grupi je potrebna baza podataka koja e da prati razvoj svakog
dela i koja e da omogui da se podaci to lake razmenjuju meu lanovima tima. Svaki lan
radne grupe ima svoj raunar, a raunari su umreeni putem LAN-a. Baza podataka se nalazi na
centralnom raunaru koji se zove server baze podataka, koji je takoe na mrei. Stoga, svaki
lan grupe ima pristup podacima. Razliiti lanovi grupe (u zavisnoti da li je u pitanju
rukovodilac projekta ili projektant, programer) mogu imati razliita ovlaenja (privilegije), a
time i razliite poglede na podatke. Primetiete da je glavna mana linih baza podataka, teko
ostvariva razmena podataka, ovde prevaziena (barem je razmena podataka u okviru grupe lako
ostvariva). Meutim, razmena podataka otvara nova pitanja i probleme koji nisu postojali kod
linih baza podataka. Glavni problemi upravljanja podacima su vezani za njihovu bezbednost i
integritet, s obzirom da vie korisnika moe istovremeno da obavlja auriranje podataka.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

23

1.14 Baze podataka odeljenja
Odeljenje je funkcionalna radna jedinica u okviru organizacije. Tipini primeri odeljenja su:
kadrovsko, marketing, proizvodnja, raunovodstvo i sl. Odeljenje je obino vee od radne
grupe (nekada se sastoji i do 100 osoba) i odgovorno je za vei broj razliitih poslova. Baze
podataka odeljenja su napravljene da podre razliite oblike poslova i aktivnosti koje obavlja to
odeljenje. Uzmimo za primer bazu podataka kadrovskog odeljenja u kojoj se prate podaci vezani
za zaposlene, vrste poslova, strunu spremu i poslovna zaduenja. Kada su svi relevantni podaci
sauvani u bazi podataka, korisnici mogu da pretrauju bazu podataka u cilju dobijanja odgovora
na pitanja kao to su sledea:
Za odreenu vrstu zanimanja (npr programer) kakve prilike za zaposlenje trenutno
postoje u organizaciji?
Za tu istu vrstu posla koja struna sprema ili vetina je neophodna?
Koje vetine, znanje poseduje odreeni radnik? I obrnuto, koji radnici poseduju
odreenu vetinu, znanje?
Koji sve radnici su obavljali odreeni posao u organizaciji? I obrnuto, koje sve poslove
je odreeni radnik obavljao u organizaciji?
Koje sve zaposlene gleda nadreeni menader?
Tipina pitanja na koja se treba odgovoriti pri pravljenju baze podataka
odeljenja su:
1. Kako baza podataka i njeno okruenje trebaju da budu organizovani da bi se ostvarile
zadovoljavajue performanse, uzimajui u obzir veliki broj korisnika i veliki broj
transakcija?
2. Kako na odgovarajui nain obezbediti podatke od nedozvoljenog pristupa i/ili
distribucije?
3. Koje alate za razvoj baze podataka i aplikacija treba koristiti u sluaju ovako
kompleksnog okruenja?
4. Da li i druga odeljenja koriste iste vrste podataka, i ako je to sluaj, kako se najbolje
moe upravljati podacima po pitanju njihove redudantnosti i konzistentnosti
metapodacima po pitanju njihove konzistentnosti?
5. Da li su korisnici baze podataka geografski jedni od drugih udaljeni ili je veliina baze
podataka tolika da se podaci moraju uvati na vie raunara, tako stvarajui distribuirane
baze podataka?
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

24

6. Da li se bazi podataka moe pristupati preko Interneta i da li ona treba da bude ukljuena
u intranet organizacije?
1.15 Baze podataka organizacije
Baza podataka organizacije obuhvata itavu organizaciju ili vie njenih odeljenja. Ova vrsta
baza podataka je namenjena da podri sve procese organizacije i proces donoenja odluka.
Vano je istai da jedna organizacija moe imati vie baza podataka, tako da jedna takva baza
podataka ne sadri sve podatke jedne organizacije. Jedna baza podataka za celu organizaciju
srednjih do velikih dimenzija ne bi bila praktina iz mnogo razloga. Kao prvo zbog razliitih
potreba razliitih korisnika, kompleksnosti stvaranja jedinstvenih metapodataka za sve korisnike
baze podataka je ogromna. Baza podataka organizacije prua podrku za jedan odreeni broj
(skup) odeljenja. Tokom poslednje decenije, razvoj baza podataka organizacije je doveo do dva
najvanija oblika:
1. Enterprise resource planning (ERP) sistem
2. Implementacija skladita podataka (data werehouses)
ERP sistemi rade sa tekuim podacima organizacije, dok skladita podataka sakupljaju podatke
iz raznih operativnih baza podataka, ukljuujui i line, radnih grupa, odeljenja i ERP baze
podataka. Skladita podataka pruaju mogunost korisnicima da rade sa prethodnim podacima
kako bi pronali obrazce i trendove dogaaja i kako bi odgovorili na pitanja koja su vezana za
strategiju poslovanja.
Uzmimo za primer veliku zdravstvenu organizaciju koja upravlja grupom medicinskih centara, u
ta spadaju domovi zdravlja, bolnice, klinike i staraki domovi. Svaki od ovih medicinskih
centara ima svoju bazu podataka (ili baze podataka) koja prua podrku u obavljanju raznih
poslova. Ove baze podataka imaju podatke o pacijentima, doktorima, medicinskim uslugama,
poslovanju i drugim bitnim entitetima. Baza podataka prua adekvatnu podrku za veinu
poslova u svakom pojedinanom medicinskom centru. Meutim, postoji potreba za jedinstvenim
pogledom na celu organizaciju; na primer, da bi se videla sva poslovanja sa jednim dobavljaem
ili pacijentom. Povaanje produktivnosi se moe postii uvoenjem, na primer, centralnog
sistema za naruivanje materijala za sve zdravstvene centre i raporeivanjem osoblja i usluga
koje vre na sve zdravstvenim centre. ERP sistem omoguava uvoenje prethodnih promena.
Donoenje odluka na nivou cele organizacije, u vezi sa poslovanjem sa dobavljaima, i
podnoenje izvetaja raznim agencijama zahteva sakupljene svih prethodnih podataka i
informacija. Da bi se zadovoljile ove potrebe, organizacija koristi skladite podataka koje se
odrava i nalazi u seditu organizacije. Podaci koji se nalaze u skladitu podataka su preuzeti (i
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

25

potom sumirani) iz pojedinanih baza podataka svakog medicinskog centra. Ovaj proces
preuzimanja podataka se odvija periodino putem telekomunikaciono-raunarske mree.
1.16 Internet, Intranet i Extranet baze podataka
Internet tehnologije slue za olakavanje deljenja podataka i informacija. Na primer, u okviru
fabrike moe se koristiti lokalna mrea (LAN) koja povezuje radne stanice zaposlenih iz raznih
odeljenja sa serverom na kome se nalazi baza podataka. LAN unapreuje komunikaciju i proces
donoenja odluka u okviru same kompanije. Ako se uvede Intranet koji se zasniva na Web
tehnologiji, njemu se moe pristupati samo u okvirima kompanije. Radna stanica svakog
zaposlenog se moe koristiti kao web browser, i na taj nain se dobija brz pristup
informacijama kompanije, ukljuujui i telefonski adresar, specifikacije proizvoda, elektronsku
potu i tome slino. Takoe se radne stanice mogu koristiti i kao personalni raunari koji
povezani preko LAN-a pristupaju serveru na kome se nalazi baza podataka. Mogue je dodati i
Web interfejse nekim poslovnim aplikacijama, kao to su unoenje porudbina, da bi na taj
nain vie internih poslovnih aktivnosti moglo biti obavljano od strane zaposlenih preko
intraneta.
U cilu efikasnijeg ukupnog poslovanja intranet sistem se moe otvoriti ka kupcima preko
Interneta. Ovo omoguava maloprodajama da pretrauju katalog proizvoda (ukljuujui slike i
specifikacije proizvoda) i utvrde da li eljenog proizvoda ima u skladitu. Tada radnici u
maloprodajnim objektima mogu da obaveste svoje kupce i da porue eljeni komad proizvoda
preko Interneta. Internet konekcija je konfigurisana kao extranet to znai da samo odobrene
maloprodaje mogu da pristupe intranet-u fabrike.
Sve vee korienje Interneta, svetske mree koja povezuje korisnike, nebitno koje
platforme je dovelo i do promena u okruenju baza podataka. Prihvatanje Interneta od strane
poslovnog sveta je dovelo do bitnih promena u davno utvrenim modelima poslovanja. Veoma
uspene kompanije su bile ugroene zbog novih kompanija koje su prihvatile Internet pomou
koga su unapredile informisanje i usluge koje su pruale svojim klijentima, i koje su zaobile
tipine tokove marketinga i distribucije proizvoda. Na primer, kupci konfiguriu i poruuju svoj
PC raunar direktno od proizvoaa raunara. Informacije o upranjenim mestima i
aktivnostima organizacije se mogu dobiti preko Interneta za veinu organizacija. Svaka od ovih
radnji zahteva podrku baze podataka. Lak pristup Internetu svih vrsta platformi omoguava
kompanijama da reorganizuju svoje poslove i razviju bre aplikacije i to po manjim trokovima.
Standardni interfejsi omoguavaju veu produktivnost korisnika, uz manje provedenog vremena
na obuci, i manju potrebnu podrku. Osnova razvoja korisnikove aplikacije je prikljuivanje
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

26

baze podataka iz koje se mogu dobiti svee informacije. Kada je baza podataka povezana sa
nekom Internet lokacijom, korisnici preko Web browser-a mogu da postavljaju odreena pitanja
na koja e dobiti odgovore bazirane na sveim informacijama. Odgovaranje na pitanja je
automatsko; nema potrebe da se putem telefona prolazi kroz niz opcija da bi se postavilo pitanje
nekoj osobi i da bi se zatim od nje ekao odgovor. Internet baze podataka su nezamenljive u
razvoju sajtova za kupovinu preko Interneta. Kompanije prate sva deavanja na sajtu kako bi
doli do to vie informacija o svojim klijentima ( obrazci pri kupovini, navigacija sajtom,
duina zadravanja na svakoj stranici i tome slino) kako bi to vie unapredili svoj odnos prema
kupcima.
Veina primera koji su navedeni prikazuju Business-to-Customer (B2C) veze. Kada su kupci
kod nekih firmi druge firme, takav odnos se obino naziva B2B (Business-to-Business) odnos.
Internet se koristi da olaka B2C odnos, zato to su kupci obavezno spoljni faktor u odnosu na
firmu, i mogunost kupca da pristupi poslovnim podacima i informacijama je od velike vanosti
za uspean odnos. Dozvoljavanjem pristupa poslovnim bazama podataka, od strane osoba koje
nisu deo organizacije, javljaju se nova pitanja za rukovoenje informacionim sistemima vezana
za sigurnost i integritet podataka.
Kompanije su godinama vrile razmenu informacija putem elektronske razmene podataka (EDI-
eletronic data interchange). Mnoge kompanije i dalje koriste EDI sistem za obavljanje B2B
poslovanja. Neke kompanije, uglavnom nove ili one koje nisu imale EDI sistem, koriste extranet
za obavljanje B2B razmena podataka i informacija. Extranet koristi Internet tehnologiju,
meutim, pristup extranetu je, za razliku od Interneta kome mogu svi pristupiti, ogranien.
Ustvari, pristup je ogranien na kompanije koje su u ulozi dobavljaa i kupca i koje imaju
meusobni dogovor o pristupu podacima i informacijama jednih drugima. Obino, prethodno
pomenuti akteri imaju pristup delu intranet-a drugog aktera. Ovaj nain pristupa olakava
poslovne odnose tako to prua bri i efikasniji nain obrade i pristupanja podacima.
Kao to je prethodno pomenuto mnoge organizacije su koristile Internet tehnologiju za stvaranje
privatne mree namenjene za upravljanje informacijama u okviru organizacije. Po izgledu ne
postoji razlika izmeu intranet i Internet stranica, ali pristup intranet stranici je ogranien samo
na korisnike u okviru te organizacije. Stoga je i pristup bazi podataka organizacije ogranien.
Intranet moe da ostvari Internet konekciju ali ta konekcija e biti zatiena firewall-om koji
spreava neovlaeni pristup internetu.
1.17 Tipino okruenje baze podataka
Glavni delovi tipinog okruenja baze podataka i njihove veze su prikazani na slici 9.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

27

1. Baza podataka Organizovan skup logiki povezanih podataka, obino napravljena da
zadovolji potrebe za informacijama vie korisnika u organizaciji.
2. Skladite podataka Centralna baza znanja za sve definicije podataka, njihova
ogranienja, veze izmeu podataka, izgleda ekrana i izvetaja i drugih sistemskih
komponenti. Uskladiteni podaci iz prethodnog perioda.
3. DBMS Sistem za upravljanje bazama podataka (SUBP). Softverski sistem koji se koristi
za kreiranje, odravanje i kontrolu pristupa korisnika baze podataka.
4. Aplikativni programi Raunarski programi koji slue za kreiranje i odravanje baze
podataka i pruaju informacije korisnicima.
5. Administratori podataka i baza podataka Administratori podataka su osobe
odgovorne za upravljanje svim izvorima podataka u organizaciji. Administratori
podataka su odgovorni za fiziki dizajn baza podataka i za upravljanje tehnikim
problematikama u okruenju baza podataka.
6. Projektanti sistema Osobe kao to su sistemski analitiari i programeri koji dizajniraju
nove aplikativne programe. Projektanti sistema esto koriste CASE alate za analizu
potreba sistema i dizajn programa.
7. Korisniki interfejs Jezici, meniji, i itd. pomou kojih korisnici koriste razliite
komponente sistema, kao to su CASE alati, aplikativni programi, DBMS i metapodaci.
8. Computer-aided softver engineering (CASE) alati koji se koriste za dizajniranje baza
podataka i aplikativnih programa.
9. Krajnji korisnici Osobe koje dodaju, briu i modifikuju/auriraju podatke u bazi
podataka i koje zahtevaju ili primaju podatke iz njih. Svaka interakcija izmeu korisnika
i baze podataka deava se preko DBMS-a.









Projektanti sistema
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

28











Slika 9 Komponente okruenja BP
Sa unapreenjem softvera, korisniki interfejs postaje sve laki za upotrebu. Primeri za ovakav
napredak su sistemi zasnovani na menijima, sistemi sa mogunou pristupa Internetu, i sistemi
koji prepoznaju govor (prihvataju govorne komande). Cilj ovih sistema je da to vie krajnjih
korisnika moe da koristi raunar, to znai da korisnici koji nisu raunarski eksperti mogu sami
da naprave izvetaje i koriste jednostave aplikacije. Naravno, u ovakvom okruenju
administratori baza podataka moraju da obrate panju na bezbednost baze podataka. Okruenje
baze podataka prikazano na slici 9 predstavlja integrisani sistem hardvera, softvera i ljudi koji je
napravljen da olaka skladitenje, preuzimanje, kontrolu izvora informacija i da povea
produktivnost preduzea.
1.18 Modelovanje
Informacioni sistemi pojedinih firmi omoguavaju upravljanje podacima koji su bitni za njeno
poslovanje. Meutim, broj internih podataka i podataka iz okruenja je ogroman te je nemogue
sve podatke i sve uoene detalje opisati i sauvati unutar informacionog sistema.
Postupkom selekcije identifikuju se i uvaju samo relevantni podaci. Time se dolazi do pojma
modela podataka. On je izraz i posledica zahteva za obradom podataka relevantnih za odreeno
podruje primene. Modeli su ovekovo sredstvo pojednostavljivanja problema i njegovo
Case alati
Korisniki
interfejs
Aplikativni
programi
DBMS
Skladite
podataka
Baza
podataka
Administratori
podataka i baza
podataka
Krajnji korisnici

NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

29

posmatranje samo sa stanovita bitnih za ciljeve analize. Objekt posmatranja (npr. automobil)
ima uvek vie osobina (atributa) od kojih u datom trenutku analize moe biti dovoljan samo
njihov manji broj (npr. samo registarski broj, tip automobila, ime i prezime vlasnika). To su
najvaniji atributi potrebni u postupku pretraivanja i pronalaenja vlasnika vozila na osnovu
registarskog broja vozila unutar jednog informacionog sistema. Ostali atributi kao to su boja,
godina proizvodnje, broj sedita i sl. nisu bitni (mogu se zanemariti ) za takav postupak. ovek,
obdaren sposobnostima apstraktnog naina miljenja, stvara jedan apstraktni model realnog
sveta. Takav model realnog sveta (objekta posmatranja) zasniva se na simbolima i zove se
konceptualni model podataka.




Cilj svakog modela je da uini da je: Izlaz1~Izlazu2


Slika 10 Realan svet i njegov model

Modelovanje podataka se radi paralelno sa analizom potreba. Kako se informacije prikupljaju,
objekti se identifikuju, dodjeljuju im se imena koristei termine bliske krajnjim korisnicima.
Objekti se onda modeluju i analiziraju koritenjem dijagrama objekti-veze (ER dijagrami).
Dijagram se moe pregledati od strane dizajnera i krajnjeg korisnika da bi se osigurala njegova
kompletnost i tanost. Ako model nije taan, modifikuje se, to ponekad zahteva da se prikupe
dodatne informacije. Ciklus pregledanja i modifikovanja se nastavlja sve dok se ne dobije
potvrda da je model korektan.
1.19. Razvoj konceptualnih modela
Objekti iz relnog sveta se u raunarskoj primeni opisuju pomou podataka. Podaci su zato
apstrakcija realnosti, tj. sredstva za kodiranje osobina objekata iz realnog sveta. Modelovanje,
kao postupak kojim se realni svet svodi na odreeni broj podataka, predstavlja kompleksan
posao i sastoji se iz vie koraka:

Realan
Programi za
odravanje
Programi za
izvetavanje
Baza podataka

Izlaz2
Ulaz
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

30

Izbor (selekcija). U prvom koraku se mnotvo objekata iz realnog sveta redukuje na
manji skup objekata, koji e initi objekte modela. Npr. objekti mogu biti student,
predmet, profesor, studentska sluba, polaganje ispita i sl. U procesu selekcije ovaj broj
objekata se moe redukovati na manji broj, ako je cilj praenje uspenosti studiranja na
fakultetu. Time se sloenost realnog sistema smanjuje. Selekcija se ne odnosi samo na
objekte nego i na njihove osobine, kao i na meusobne veze (relacije) izmeu objekata.
Imenovanje. Svakom objektu u realnom svetu, svakoj vezi izmeu uoenih objekata,
kao i svakom atributu (svojstvu) uoenog objekta ili veze dodeljuje se ime.
Klasifikacija. Nehomogeni skup objekata i odnosa se svrstava u homogene klase i
tipove objekata. Klasifikacija uvek zavisi od podruja primene.
Rezultat navedenih koraka modelovanja zove se konceptualni model. On sadri, za posmatrani
problem iz realnog sveta, sve relevantne tipove objekata, njihove osobine i meusobne veze.
Rezultati prouavanja modela podataka doveli su do saznanja da svaki model podataka ima tri
neodvojive komponente:
strukturu podataka
operacije nad podacima
ogranienja (constrains)
Struktura i ogranienja, za razliku od operacija, opisuju stanje realnog sistema, tj.
predstavljaju statiki opis stanja sistema. Strukturu modela ine objekti, njihova svojstva,
veze izmeu objekata i njihovih svojstava. Operacije nad podacima u modelu su, u
stvari, operacije nad strukturom modela kojima se izraava dinamika realnog sistema.
Operacije izraavaju kretanje i promene tj. dinamiku realnog sistema. Ogranienja su
pravila koja razdvajaju doputena od nedoputenih stanja realnog sistema i u svojoj
prirodi deo su strukture modela podataka. Ponekad se ne posmatraju kao odvojene
komponenta, nego kao deo strukture modela podataka.
2. Entiteti
Modelima podataka nastoji se preslikati realan sistem. Realan sistem sastoji se od objekata iz
realnog sveta i njihovih veza izmeu kojih se uspostavljaju razliiti odnosi. Pod entitetom se
podrazumeva sve to se moe jednoznano odrediti, identifikovati i razlikovati. Tako iroko
postavljena definicija pokazuje da entitet moe biti svaki "realan" ili "apstraktan" objekat o
kojem u odreenom trenutku razmiljamo. Entitet je realan ako fiziki, stvarno postoji.
Najoptije se moe tvrditi da su granice entiteta u modelu podataka odreene ljudskim pogledom
i nainom razmiljanja.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

31

Svaki entitet uoen u realnom sistemu ima svoje osobine koje ga ine sloenim i njihove
vrednosti omoguavaju razlikovanje entiteta. Svojstvo entiteta ukljuuje dva elementa - atribut i
vrednost atributa (npr. entitetStudent ima atribute: Ime, Prezime, Broj indeksa, Adresu, Telefon i
sl. i vrednosti Marko, Markovi, 123/03, Danijelova, 15, 011/376-543 respektivno). Svaki put
kada se promeni vrednost atributa, potrebno je promenu evidentirati, tj. aurirati tu vrednost
atributa za dati entitet.
Precizno govorei, objekti koji se oznae pojmom entiteta mogu se zvati klase entiteta. Svaki
objekt ima osobine (atribute) klase entiteta kojoj pripada. Npr. klasu entiteta Student ine
pojedinani entiteti od kojih svaki ima zajednike atribute: Ime, Prezime, Broj indeksa, Adresa,
Telefon i sl. Svaki pojedinani entitet ima sve navedene atribute, ali e se razlikovati od drugih
entiteta po vrednostima pojedinih atributa.
Atribut opisuje entitet. Jedno konkretno pojavljivanje atributa naziva se vrednost. Ako je atribut
dovoljno sloen, tako da ima svoje dodatne atribute, moe se posmatrati kao novi entitet.
Domen atributa je skup svih moguih vrednosti koje atribut moe poprimiti.

Primarni klju je jedan ili vie atributa ija vrednost jednoznano odreuje primerak entiteta.
Na primer, za entitet Auto, primarni klju je atribut registarski broj. Dva razliita lana ili
primerka entiteta ne mogu imati isti primarni klju. Primarni klju je jedinstven za svakog lana
entiteta. Na primer, za entitet Student primarni klju bi mogao biti broj indeksa.
2.1 Veze izmeu entiteta
Baza podataka se ne odnosi samo na pojedinane objekte nego i na odnose izmeu objekata. U
realnom sistemu objekti nisu meusobno izolovani, nego se nalaze u meusobnoj interakciji.
Student se upisuje na fakultet, slua predavanja iz pojedinih predmeta, prijavljuje polaganje
ispita, polae ispit itd. To su primeri logikih i realnih veza izmeu objekata, koje slede iz
realnih odnosa u posmatranom sistemu studiranja na jednom fakultetu.
Istraimo jedan skup odnosa izmeu studenata koji sluaju predavanja kod odreenog profesora.
Postavlja se pitanje ta su u takvim odnosima objekti, koje su njihove osobine (atributi) i kako
prikazati njihove odnose. Identifikovati objekte, njihove osobine i odnose znai praktino
izgraditi model podataka. U modelu podataka ne postoje samo atributi objekta, nego i veze
izmeu objekata. Prvo se selektuju objekti, imenuju se, a zatim se analiziraju tipovi odnosa koji
se uspostavljaju izmeu objekata. Odnosi izmeu objekata posmatranja prikazuju se najee
primenom logike skupova i preslikavanja njihovih elemenata.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

32

Najjednostavniji odnos izmeu ta dva tipa objekata naziva se preslikavanje 1:1. Kod takvog
preslikavanja svaki se element skupa X moe preslikati na najvie jedan element skupa Y.
Istovremeno, i svaki element skupa Y moe biti preslikan na najvie jedan element skupa X.
Karakteristian primer bi bio sa entitetima Fakultet i Dekan. Na jednom fakultetu moe biti
samo jedan dekan, a jedan dekan moe biti dekan na samo jednom fakultetu. Takvi odnosi
izmeu entiteta su retki, a mogu se predstaviti sledeom slikom:









Druga vrsta odnosa naziva se preslikavanje N:1 (ili 1:N). Vie elementa skupa X moe se
preslikati na najvie jedan element skupa Y. Istovremeno jedan element skupa Y moe se
preslikati na vie elemenata skupa X. Pogodan primer za ovu vrstu odnosa izmeu entiteta je
odnos izmeu entiteta Student i Dekan. Vie studenata na jednom fakultetu ima samo jednog
dekana, a jedan dekan je dekan za vie studenata na svom fakultetu.









F1
F2
F3
Fn
D1
D2
D3
Dn
Slika 11. Preslikavanje entiteta N:N
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

33











Slika 12. Preslikavanje entiteta N:1










Slika 13. Preslikavanje tipa M:N
Najsloenije preslikavanje je tipa M:N. Svaki element prvog skup moe se preslikati na vie
elemenata drugog skupa, ali se i svaki element drugog skupa moe preslikati na vie elemenata
prvog skupa. Karakteristian primer ovakvih veza postoji ako se uoe entiteti Student i Profesor.
Jednom studentu predaje vie profesora, a ujedno jedan profesor predaje za vie studenata

S1
S2
S3
Sn
D1
D2
D3
Dn
Sn+1
S1
S2
S3
Sn
P1
P2
P3
Pn
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

34

2.2 Troslojna arhitektura baze podataka
Osnovni koncept baze podataka je ideja o skupu injenica ili delova znanja. injenice mogu da
budu struktuirane na razliite naine koji se nazivaju modeli podataka. Model podataka nije
statina struktura nego se menja kako bi odraavao promene koje se deavaju i u realnom
sistemu. Na primeru informacionog sistema jednog fakulteta, studenti polau pojedine ispite,
neke ponitavaju i dobijaju drugaije ocene, upisuju se novi studenti, drugi diplomiraju, neki
asistenti postaju profesori itd.
Za jednostavne sluajeve, kao i mali broj promena relacija i entiteta, mogue je auriranje
podataka vriti runo. Za kompleksnije sisteme (sa nekoliko stotina ili hiljada entiteta ili
relacija) auriranje podataka postaje ogroman problem. Jedino se uz pomo raunara moe
odravati aurnost podataka u velikim informacionim sistemima. Obrada podataka postaje ne
samo pitanje produktivnosti neke firme ili organizacije, nego i opstanka, rasta i razvoja u
okruenju s intenzivnom konkurencijom. Obrada podataka je deo svakog poslovnog procesa,
stoga je poznavanje baza podataka bitno ne samo za projektante informacionih sistema i
programere, nego i za krajnje korisnike rezultata takvih obrada. Oni nisu samo skup povremenih
korisnika baza podataka, kao to se to moe rei za programere ili projektante informacionih
sistema. Danas veliki broj zaposlenih, koji nisu upoznati sa konceptualnom emom BP, kreiraju,
unose, auriraju ili jednostavno koriste baze podataka na razliitim nivoima organiziranosti
poslovnih sistema.
Model baze podataka koji je danas poznat kao ANSI/X3/SPARC model prikazan je na slici 1.14.
Na bazi tog modela razvijeni su sistemi za upravljanje bazama podataka koji imaju troslojnu
arhitekturu ili varijantu te arhitekture. Aplikativni programi komuniciraju s bazom podataka
preko odgovarajueg eksternog modela. Zahtev za uitavanje odreenih podataka aplikativni
sloj upuuje na eksterni sloj, odnosno odgovarajui korisniki model. DBMS preslikava eksterni
model na konceptualni i konceptualni na interni model.
Konceptualni nivo je najblii stvarnosti. Taj se nivo definie u procesu kreiranja modela
podataka. Jedan od ciljeva modela podataka je oblikovanje podataka za sadanje i budue
aplikacije. Moe se rei da konceptualni nivo ine sve relacione eme modela podataka, sve
relacije i ogranienja. Spoljanji nivoi (modeli A, B i C) formiraju se na temelju konceptualnog
nivoa i predstavljaju samo pogled (VIEW) prema potrebama pojedinih korisnika.

Konceptualni model (sloj)
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

35

Eksterni
model (sloj) Interni model (sloj)







Slika 14. Troslojna arhitektura baze podataka

Unutranji (interni) sloj baze odnosi se na zapisivanje konceptualnog sloja na nekom medijumu
za uvanje (najee disku). Radi se o slogovima zapisanim u datotekama. Nii sloj, uslovno
reeno, ili nivo blii disku od internog sloja BP, je operativni sistem , koji na osnovu logikih
adresa slogova ita sadraj diska.








Model A
Model B
Model C

C
B
A
Podaci 1
Podaci 2
Podaci 3
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

36

3. Modeli baza podataka
Za modelovanje strukture podataka koriste se razliite tehnike. Odreeni modeli se lake koriste
za neke tipove sistema upravljanja bazama podataka nego drugi modeli. Model ini osnovu za
osmiljavanje, definisanje i implementaciju baze podataka.
Istorijski gledano sistemi za upravljanje bazama podataka mogu se podeliti u sledee osnovne
modele:

Hijerarhijski model ine ga podaci sloeni u hijerarhijsku strukturu;

Mreni model moe se predstaviti usmerenim grafom u kojem su vorita podaci,
lukovi meu voritima definiu veze meu podacima;
Relacioni model zasnovan na matematikom pojmu relacije. Podaci i veze meu
podacima se prikazuju preko dvodimenzionalnih tabela.
Objektni model bazira se na konceptu objekata, koji predstavljaju skup podataka i
operacija koje se na njima mogu izvravati.



NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

37

4. Logiko projektovanje baza podataka
Glavni cilj u procesu razvoja baze podataka je da se kreira sistem koji verno reprezentuje
podatke, njihove veze i odnose, kao i ogranienja. Da bi se postigao ovaj cilj, moraju se pravilno
uoiti odgovarajue tabele, a metoda koja se za to koristi naziva se normalizacija. Normalizacija
je tehnika za kreiranje tabela sa odgovarajuim svojstvima, uzimajui u obzir zahteve okruenja
za ije potrebe se projektuje baza. Normalizacija se esto realizuje tako to se vri serija testova
nad tabelom da bi se utvrdilo da li ona zadovoljava zahteve odreene normalne forme ili ne.
Inicijalno su promovisane tri normalne forme, prva (1NF), druga (2NF) i trea (3NF) normalna
forma. Kasnije su R.Boyce i E.F.Codd promovisali strou definiciju tree normalne forme koja
se naziva Boyce-Codd normalna forma (BCNF). Sve normalne forme se baziraju na
funkcionalnim zavisnostima izmeu atributa tabele. Promovisane su i vie normalne forme koje
prevazilaze BCNF, i to su etvrta (4NF) i peta (5NF) normalna forma. Ipak, ove forme se bave
situacijama koje su vrlo retke. Normalizacija omoguava projektantu baze da izvri optimalno
grupisanje atributa po tabelama. Proces normalizacije identifikuje tabele na osnovu primarnih
kljueva ili kljueva kandidata i na osnovu funkcionalnih zavisnosti koje postoje izmeu
atributa. Normalizacija sadri pravila koja se mogu upotrebiti za testiranje tabela, tako da baza
moe da se normalizuje do bilo kog stepena. Tabela koja ne ispunjava zahteve normalizacije
mora se rastaviti na dve ili vie tabela od kojih svaka pojedinano ispunjava zahteve
normalizacije. Vano je napomenuti da je za kreiranje tabela u relacionom modelu podataka
kritina samo 1NF. Sve ostale forme su opcione. Ipak, da bi se izbegle anomalije auriranja,
preporuuje se normalizacija najmanje do 3NF.
U najoptijem smislu, normalizacija je postupak kojim se proizvoljna nenormalizovana relacija
transformie u skup manjih normalizovanih relacija. U okviru normalizacije ne sme doi do
gubitaka informacija sadranih u relaciji. Drugim reima, mora biti mogue rekonstruisati
prethodne relacija na osnovu novodobijenih.
Dekompozicija eme relacije R(A1,A2,...,An) je zamena eme relacije R sa skupom ema
relacija {R1, R2, ... , Rk} za koje vai Ri_R i R1_ R2_..._Rk=R. Ako je r relacija zadata na R a
relacije r1,r2, ... ,rk su dobijene projekcijama relacije r na skupove atributa R1, R2, ... , Rk onda
se prirodnim spajanjem mora dobiti relacija r.


NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

38


4.1 Funkcionalna zavisnost
Funkcionalna zavisnost opisuje odnose izmeu atributa u tabeli i predstavlja jedan od glavnih
koncepata vezanih za normalizaciju. Osnovni razlog zbog koga se pristupa definisanju
funkcionalnih zavisnosti za tabelu je potreba odreivanja ogranienja za ouvanje integriteta
(integrity constraints). Verovatno najvanije ogranienje za ouvanje integriteta je uoavanje
kljueva kandidata, od kojih se jedan bira za primarni klju tabele. U procesu njihovog
definisanja, naroito je znaajno pronai one funkcionalne zavisnosti koje vae za sve mogue
vrednosti atributa jedne tabele, jer one predstavljaju tipove ogranienja za ouvanje integriteta.
Tipovi ogranienja za ouvanje integriteta definiu vrednosti koje tabela moe legitimno da
primi. Takoe je znaajno ignorisati tzv. trivijalne funkcionalne zavisnosti, jer za njih vai da su
uvek zadovoljene, pa stoga nisu od znaaja.
4.2 Postupak normalizacije
Neka polazna ema relacije nije u odreenoj normalnoj formi ako u skupu funkcijskih zavisnosti
F postoji bar jedna koja naruava definiciju normalne forme.

U svakom koraku normalizacije:
1. Uoava se jedna takva zavisnost (X_Y)
2. Vri se dekompozicija u cilju uklanjanja takve zavisnosti
3. Ako je u polaznoj vailo X_Y, dekompozicijom nastaju dve relacije. U prvoj se gube atributi
Y, a druga nastaje nad atributima X i Y.
4. Ne dozvoljava se gubitak podataka

Krajnji je cilj normalizacije najverovatnije trea normalna forma. U veini sluajeva ona
predstavlja najbolji kompromis izmeu ekstrema koji se odnose na funkcionalnost i lakou
implementacije. Nivoi iznad 3FN u praksi mogu da iskomplikuju dizajn baze podataka do take
da smetaju funkcionalnosti. Svi nivoi normalizacije su kumulativni to znai da baza koja se
nalazi u 2NF takoe mora da ispunjava i sve uslove zadate prvom normalnom formom.

NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

39

Proces analize eme relacije je proces primene serije testova na emu relacije da bi se proverilo
da li ispunjava sva pravila definisana za odreenu normalnu formu. Normalne forme pomau
projektantu baze podataka da ostvari eljeni kvalitet relacione baze podataka.
4.3 Prva normalna forma (1NF)
Pre diskusije o 1NF, najpre treba definisati stanje pre 1NF. Tabela koja sadri podatke koji se
ponavljaju nalazi se u nenormalizovanoj formi (NNF) i naziva se nenormalizovana tabela.
Tabela je u 1NF ako presek svakog njenog reda i kolone sadri jednu i samo jednu vrednost.
ema relacije R je u prvoj normalnoj formi ako i samo ako domeni relacije R sadre samo proste
(atomic) vrednosti (proste vrednosti su vrednosti koje se ne mogu dalje deliti ili ako u
konkretnoj situaciji nisu rastavljene na komponente). U 1NF nisu dozvoljeni vievrednosni i
kompozitni atributi i njihove kombinacije tj.nisu doputene relacije u relacijama ili relacije kao
atributi n-torki. ema relacije je u 1NF, ako je svaki njen atribut skalarnog tipa, tj. vrednost
svakog atributa je jednostruka i nedeljiva.

Ako ema relacije R(A1,A2,,An) nije u 1NF, onda postoji takva dekompozicija ema relacije
R u skup ema relacija {R1,Rk} koje su u 1NF, na nain da se operacijom prirodnog spajanja
iz ovih ema relacija moe ponovo dobiti ema relacije R.

Da bi se nenormalizovana tabela transformisala u 1NF, moraju se identifikovati i ukloniti podaci
koji se ponavljaju. Postoje dva uobiajena pristupa za uklanjanje podataka koji se ponavljaju iz
nenormalizovanih tabela:
1. Po prvom pristupu, odgovarajui podaci se ubacuju u prazne kolone redova koji sadre
podatke koji se ponavljaju. Drugim reima, tamo gde je to potrebno, prazna polja se
popunjavaju dupliranim podacima koji se ne ponavljaju. Rezultujua tabela sadri
atomine (pojedinane) vrednosti u preseku svakog reda i kolone, pa je stoga u 1NF.
Dakle, u ovom postupku se u tabelu namerno unose podaci koji se ponavljaju, a oni se
tokom sledeih, viih faza procesa normalizacije uklanjaju iz tabele.
2. Po drugom pristupu, podaci koji se ponavljaju se, zajedno sa kopijom originalne
vrednosti atributa kljua (ili originalne vrednosti vie kljueva), izmetaju u posebnu
tabelu. Za novu tabelu se definie primarni klju. Ponekad nenormalizovana tabela
sadri vie od jedne grupe podataka koji se ponavljaju ili ak grupe unutar grupe. U
takvim sluajevima postupak izmetanja se ponavlja sve dok se ne ukloni i poslednja
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

40

grupa podataka koji se ponavljaju. Za grupu tabela se kae da je u 1NF ako ne sadre
podatke koji se ponavljaju.
Oba pristupa su ispravna, mada drugi pristup direktno daje tabele koje su u najmanje 1NF. I prvi
pristup daje tabele koje su u 1NF, ali koje se tek u kasnijim fazama normalizacije razlau na iste
one tabele koje nastaju kao rezultat primene drugog pristupa. Dakle, moe se zakljuiti da je
drugi pristup direktniji i praktiniji.
Primer: ema relacije RADPROJ(JMBG, Ime, {ifP, Sati}) sadri ugnjedenu relaciju
PROJEKAT(ifP,Sati). Atribut ifP je parcijalni primarni klju relacije RADPROJ, tj. zajedno
sa atributom JMBG ini njegov primarni klju. Da bi ova ema relacije bila u 1NF nad njom se
definie sledea relacija (sa nekim trenutnim sadrajem):

JMBG Ime ifP Sati
123 Marko P1 3
123 Marko P3 2
123 Marko P5 2
222 Petar P3 4
222 Petar P4 2
333 Janko P1 5









Tabela 3. RadnikProjekat
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

41

Da bi se relacija RADPROJ prevela u bolju 1NF, potrebno je da se ugnjedena relacija formira
kao nezavisna relacija. eme relacija sada imaju oblik: RADNIK(JMBG,Ime) i
PROJEKAT(JMBG, ifP, Sati):










4.4 Druga normalna forma
Druga normalna forma se bazira na konceptu potpune funkcionalne zavisnosti, koja e najpre
biti definisana.
4.5 Potpuna funkcionalna zavisnost
Funkcionalna zavisnost A_B (ita se B je funkcionalno zavisno od A) je potpuna funkcionalna
zavisnost ako uklanjanje bilo kog atributa iz A rezultuje time to zavisnost prestaje da vai, pri
emu su A i B atributi tabele. Funkcionalna zavisnost A_B je delimino zavisna ako postoje
neki atributi koji se mogu ukloniti iz A, a zavisnost i dalje vai.
4.6 Definicija druge normalne forme
Druga normalna forma se odnosi na tabele sa sloenim kljuevima, tj. tabele iji se primarni
kljuevi sastoje iz dva ili vie atributa.
Tabela iji primarni klju sadri samo jedan atribut je automatski u najmanje 2NF. U
tabeli koja nije u 2NF mogu da se pojave anomalije auriranja.
Tabela je u 2NF ako je u 1NF i ako je svaki atribut koji nije primarni klju potpuno
funkcionalno zavisan od primarnog kljua.
RADNIK
JMBG IME
M1 I1
M2 I2
M3 I3
Nezavisna relacija
JMBG ifP Sati
123 P1 3
123 P3 2
123 P5 2
222 P3 4
222 P4 2
333 P1 5
Tabela 4. Radnik
Tabela 5. Nezavisna relacija RadnikProjekat
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

42

Normalizacija tabele iz 1NF u 2NF se vri uklanjanjem deliminih zavisnosti, tj. funkcionalno
zavisni atributi se izmetaju u novu tabelu zajedno sa kopijom njihovih determinanti (kljueva).
4.7 Trea normalna forma
ak iako je u 2NF, u tabeli mogu da se pojave anomalije auriranja zbog tranzitivnih zavisnosti,
koje se moraju ukloniti iz tabele postupkom normalizacije do 3NF.
Tranzitivna zavisnost je stanje u kome su A, B i C atributi tabele takvi da, ako A_B (B je
funkcionalno zavisno od A) i B_C (C je funkcionalno zavisno od B), onda je C tranzitivno
zavisno od A preko B (pod uslovom da A nije funkcionalno zavisno od B ili C).
Definicija tree normalne forme tabela je u 3NF ako je u 1NF i u 2NF i ako u njoj ne postoje
atributi ne-primarni- kljuevi koji su tranzitivno zavisni od primarnog kljua.
Normalizacija tabela iz 2NF u 3NF se vri uklanjanjem tranzitivnih zavisnosti, tj. tranzitivno
zavisni atributi se izmetaju u novu tabelu zajedno sa kopijom njihovih determinanti (kljueva).
4.8 Boyce-Codd normalna forma (BCNF)
Druga i trea normalna forma eliminiu delimine i tranzitivne zavisnosti za primarne kljueve,
ali one ne razmatraju da li takve zavisnosti postoje i za kljueve kandidate, ako ih ima u tabeli.
Dakle, i u 3NF mogu da postoje delimine i tranzitivne zavisnosti za kljueve kandidate, pa je
stoga promovisana stroa normalna forma poznata kao Boyce-Codd normalna forma (BCNF).
BCNF se bazira na funkcionalnim zavisnostima koje uzimaju u obzir sve kljueve kandidate u
tabeli, a sadri i jo neka ogranienja u poreenju sa 3NF.
Definicija Tabela je u BCNF ako i samo ako je svaka determinanta klju kandidat.
Da bi se odredilo da li je tabela u BCNF, potrebno je uoiti determinante i proveriti da li su sve
one kljuevi kandidati. Podsetiemo se da je determinanta atribut ili grupa atributa od kojih je
neki drugi atribut potpuno funkcionalno zavisan.
Razlika izmeu 3NF i BCNF je u tome to 3NF dozvoljava funkcionalnu zavisnost A_B (B je
funkcionalno zavisno od A) ako je B primarni klju a A nije klju kandidat, dok BCNF nalae
da A mora biti klju kandidat. Dakle, BCNF je jaa forma od 3NF, pa je svaka tabela koja je u
BCNF automatski i u 3NF, a obratno ne vai.
Tabela se transformie u BCNF tako to se vri njena dekompozicija na dve ili vie novih tabela.
Meutim, ponekad nije poeljno normalizovati tabelu do BCNF. Naime, moe se desiti da se
prilikom dekompozicije tabele izgubi jedna ili vie funkcionalnih zavisnosti zbog toga to se
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

43

determinanta i od nje zavisni atributi izmeste u razliite tabele. U ovakvoj situaciji treba
proceniti da li je bolje stati kod 3NF, koja uvek uva sve funkcionalne zavisnosti. Odluku da li
normalizovati tabelu do BCNF ili stati kod 3NF treba doneti na osnovu sledee analize:
Da li e znaajni podaci biti izgubljeni u sluaju dekompozicije tabele i gubitka jedne ili
vie funkcionalnih zavisnosti
Kolika e biti koliina redundantnih podataka (podataka koji se ponavljaju) u sluaju da
se dekompozicija ne izvri, tj. da se ostane na 3NF.
4.9 etvrta normalna forma(4NF)
Iako BCNF eliminie sve anomalije koje proistiu iz funkcionalnih zavisnosti, dalja istraivanja
su dovela do uoavanja jo jednog tipa zavisnosti koji se naziva zavisnost viestruke vrednosti
koji takoe moe da prouzrokuje redundatnost podataka.
Zavisnost viestruke vrednosti pojava zavisnosti viestruke vrednosti u tabeli moe da se desi
zbog 1NF koja ne dozvoljava da atribut ima vie vrednosti, tj. da se sastoji iz vie podataka.
Zavisnost viestruke vrednosti bie objanjena na primeru tabele EkspozituraZaposleniVlasnik
iz baze podataka agencije za prodaju i izdavanje nekretnina.

Tabela 6. EkspozituraZaposleniVlasnik
IdentBrEkspoziture Ime zaposlenog ImeVlasnikaNekretnine
B003 Zoran Petrovi Jelena Jankovi
B003 Miodrag Aleksi Jelena Jankovi
B003 Zoran Petrovi Predrag Stefanovi
B003 Miodrag Aleksi Predrag Stefanovi

U ovom primeru zaposleni Zoran Petrovi i Miodrag Aleksi rade u ekspozituri B003, a vlasnici
nekretnina Jelena Jankovi i Predrag Stefanovi su registrovani u istoj ekspozituri, dakle B003.
Poto ne postoji direktna veza izmeu zaposlenih i vlasnika u datoj ekspozituri, mora se kreirati
zapis za sve kombinacije zaposlenih i vlasnika da bi se obezbedila konzistentnost. Ova situacija
predstavlja zavisnost viestruke vrednosti u tabeli EkspozituraZaposleniVlasnik. Drugim reima,
zavisnost postoji zato to su u tabeli predstavljene dve nezavisne 1:* veze.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

44

Zavisnost viestruke vrednosti predstavlja zavisnost izmeu atributa A, B i C u tabeli, takvu da
za svaku vrednost A postoji vie vrednosti B i vie vrednosti C, pri emu su vrednosti B i C
nezavisne jedna od druge.
Definicija etvrte normalne forme tabela je u 4NF ako je u BCNF i ako ne sadri zavisnosti
viestruke vrednosti.
4NF je jaa normalna forma od BCNF, jer ne dozvoljava da tabele imaju zavisnost viestruke
vrednosti, a samim tim i redundantne podatke (podatke koji se ponavljaju). Normalizacija iz
BCNF u 4NF se vri dekompozicijom tabele i izmetanjem atributa zajedno sa njihovim
determinantama u novu tabelu. Tabela EkspozituraZaposleniVlasnik iz prethodnog pasusa se
dekomponuje na tabele EkspozituraZaposleni i EkspozituraVlasnik.

Tabela 7. EkspozituraVlasnik




4NF eliminie redundantnost podataka (podatke koji se ponavljaju) i mogunost pojave
anomalija auriranja.








IdentBrEkspoziture ImeVlasnikaNekretnine
B003 Jelena Jankovi
B003 Predrag Stefanovi
IdentBrEkspoziture ImeZaposlenog
B003 Zoran Petrovi
B003 Miodrag Aleksi
Tabela 8. Postojanost spajanja (lossless-join)
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

45


4.10 Peta normalna forma (5NF)
Uvek kada se vri dekompozicija tabele na dve nove, rezultujue tabele imaju svojstvo poznato
kao postojanost spajanja (lossless-join). Ovo svojstvo se odnosi na injenicu da se tabele nastale
dekompozicijom mogu ponovo spojiti u originalnu tabelu. Meutim, postoje sluajevi kada je
potrebno izvriti dekompoziciju originalne tabele na vie od dve nove tabele. Iako se u praksi
prilino retko sreu, ovakvi sluajevi se reavaju primenom pete normalne forme (5NF).
Postojanost spajanja (lossless-join) je svojstvo dekompozicije koje omoguava da se,
prilikom ponovnog spajanja tabela, generiu samo originalni podaci.
Dakle, postojanost spajanja osigurava da se, prilikom ponovnog spajanja dve tabele u onu ijom
su dekompozicijom nastale, generiu samo oni podaci koji su postojali u originalnoj tabeli pre
dekompozicije, to znai da je zagarantovana potpuna rekonstrukcija originalne tabele.
Definicija pete normalne forme tabela je u 5NF ako nema zavisnosti spajanja.
Normalizacija do 5NF se vri dekompozicijom tabele u kojoj se uoe zavisnosti spajanja na vie
od dve nove tabele. Vano je napomenuti da e ponovno spajanje bilo koje dve od novonastalih
tabela generisati lane podatke, ali e zato ponovno spajanje svih novonastalih tabela verno
rekonstruisati originalnu tabelu.

5. Baze otvorenog koda
5.1 Upoznavanja sa bazama otvorenog koda
Rast potranje Open source software, tj. programa i platformi otvorenog koda u poslednjoj
dekadi vodi do migracije (prelaska) na svim nivoima softvera: file servera, desktop okruenja,
operativnih sistema, baza podataka, naveemo neke od njih, kao to su: Firebird, Ingres,
MaxDB, MySQL i PostgreSQL.
Open Source Pod otvorenim kodom se podrazumeva da je izvorni kod softvera javno dostupan
za distribuiranje i da je izmenljiv.
Prelazak na baze otvorenog koda Naveemo tri kljuna argumenta kao osnovni motiv za
migraciju baza podataka: smanjenje trokova pri kupovini i licenciranju softvera (Lowering
Total Cost of Ownership [TCO] ), specijalne karakteristike, otvoren kod i njegova zajednica.
Tabela 8. Spajanje (Join)
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

46

Ukupna cena vlasnitva (Total Cost of Ownership[TOC] )
Uglavnom se migracija baza otvorenog koda uzima u obzir kad je finansijski razlog
vodei interest, takoe trokovi kupovine i licenciranja e biti manji ili nee postojati.
Ipak je teko dati preciznu tvrdnju koliine smanjenja trokova vlasnitva migracijom iz
zatvorenog koda do otvorenog koda.
(TCO) deli trokove unapred na (npr. prodajna cena i licenca), trokove podrke i trud.
Dok, su prva dva vezana za sticanje vlasnikog softvera, druga dva se smatraju veim
iako koristite Open source softver. Ali:
Pitanje je, Gde elimo da ide na novac? - pozajmljenim ekspertima koji rade za
komercijalnog prodavca (npr. Microsoft), ili domaim (kunim), koji rade na reenjima i
potrebama nae organizacije.
Drugi, takoe vaan aspekt je skabilnost: dok prodavci komercijalnog softvera naplauju
po korisniku(useru), ili po procesoru(CPU), trokovi licenci rastu pri proirivanju naih
sistema.
Taksa za licence otvorenog koda ostaju na nulu i trokovi ljudskih resursa se nee
poveati jer neemo zaposliti jo tri radnika kad dodajemo npr. jo tri procesora serveru.
MySQL npr. tvrdi da se voenjem (TCO) baza :
Smanjuje trokove licenciranja za 90% .
Ree sistemski zastoj na 60%.
Smanjuje hardverkse trokove na 70%.
Smanjuje administraciju, potrebno ljudstvo i trokove podrke za 50%.

Karakteristike
Govorei o funkcionalnosti ili performansama nemamo mnogo argumenata da napravimo o
uslugama baza podata otvorenog koda, bar ne poredei ih sa vodeim DBMS. to ne znai da
oni ne mogu da budu dovoljne za ispunjenje zadataka, jer esto samo deo funkcionalnosti baza
bude iskorien.
Ipak, tu su neke oblasti gde baze otvorenog koda nadmauju njihove kolege zatvorenog koda.
Jedna od primera je podrka operativnih sistema. Oracle na primer, ne moe da se pokrene na
FreeBSD, DB2 ne podrava MAC OS X i *BSD i SQL npr. se pokree samo na Windows.
Sa druge strane tri najpopularnije baze otvorenog koda (Firebird, MySQL, PostgreSQL)
podravaju sva tri spomenuta, takoe i Linux i Unix. Takoe sadre i napredne tehnike
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

47

indeksiranja: Samo PostgreSQL podrava R-/R+ stablo, Hash, Expression, Bitmap, delimino i
obrunuto indeksiranje, dok nijedna od komercijalnih ili zatvorenog koda alternativa ne nudi to.
Neke od prednosti ta vie dodeljene Bazama otvorenog koda (ali ne neophodno sve se odnose
na baze otvorenog koda) su standardna komfornost, stabilnost, laka administracija.
5.2 Zajednica Otvorenog koda i kod
Pored niske cene ( i nekih vanih karakteristika), tu je i druga vana prednost baza otvorenog
koda, to je oigledno, njihov otvoren kod. Ova karakteristika omoguuje migraciju kompanija
da:
1. Da se pridrue svetskoj, ukljuujui i direktno povezivanje sa sistemskim programerima
(izvetavanje o grekama, elje, diskusije..) iroka modunost dokumentovanja i
podrke.
2. steknu bolju kontrolu na svom softveru, inei rad IT infrastrukture vie efikasnijim i
vie po meri.
3. Da se oslobode od straha zastarelosti softvera i proizvoaeve odrivosti i opstanka
takoe otvoren kod ostaje i moe biti preuzet, preureen i nastavljen od strane bilo koga,
ko ima volje mogunosti za nastavak(npr. nastavak projekta Mozila browsera ak i posle
odustajanja od daljeg projekata Mozila fondacije ).
4. Uivanje u visok stepen bezbednosti zasnovan na Open source pregledu, brzo krpljenje,
sve dok sistem ne trai sistemsko administrativne dozvole.
5. Prilagoditi i proiriti sistem prema potrebama kompanije razvijanjem nedostajaih
funkcija.
Razvijanje softvera otvorenog koda vodi do istijeg koda, ovo nije samo mit zasnovan na Eric
S. Raymond-ovom uvenom citatu: Imajui dovoljno oiju sve greke su plitke. Ako elimo
da analiziramo softver, moemo da koristimo dobro poznatog provajdera statinog analizatora
softvera (http://www.coverity.com). Jezgro linuksa sadri manje od 2 greke na svakih 10,000
linija koda, MySQL baza ima manje od 3 greke na svakih 10,000 linija, dok PostgreSQL ima
0.25 na svakih 10,000 linija koda. Prema proceni uraenoj na Carnegie-Mellon Univerzitetu
softver zatvorenog koda (komercijalni) sadri izmeu 10 i 300 greaka na 10,000 linija koda.
Bilo da razvijanje otvorenog koda uva od naduvenog koda i karakteristika koji nisu jasne. Sa
jedne strane ponovni pregled(peer review) nastoji da proizvede bolji struktuirani kod. Takoe
programiranje za zajednicu umesto kupca spreava dodavanje karakteristika npr. samo za
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

48

marketing, ili sl. Dok sa druge strane, otvoren softverski kod moe aktivno da bude razvijen od
strane 1000 saradnika. Ukoliko ovo ne bude nadgledano od jednog ili dva mentora, kod e
definitivno biti naduven. Velika i raznovrsna zajednica takoe moe zahtevati (i obezbediti
sebi) mnogo karakteristika, koje programeri-razvijaoci(developeri) ne moraju da sprovode ili
pripajaju zbog marketinga (bolje prodaje softvera), ali e ipak uraditi zbog reputacije ili slube u
korist svojih kolega.
Primenjujui ove generalne argumente na baze otvorenog koda koje pokazuju svoju raznolikost:
Prvo MySQL, Ingres i MaxDB su komercijalne baze otvorenog koda koje su pod pritiskom
dodavanja novih karakteristika za sticanje trinih akcija.
Drugo: Dok PostgreSQL, Firebird, Ingres i MaxDB su veoma napredni sistemi baza, njihovi
korisnici bie verovatno mnogo homogeni, sastojae se od iskusnih administratora baza koji
rukuju sa velikim instalacijama, uporeujui sa MySQL, iji su korisnici vrlo raznovrsni kao
njihov nain korienja u pogledu iskustva i veliine baza. Kao to je potreba za dodavanjem
novih karakteristika neophodna sa obzirom na razliite nivoe strunosti.
Ipak, tu su nekoliko razloga zbog ega se migracija uopte ne dovodi u pitanje: Ponajvie
troak, vreme i napor reininjeringa kao i neizvesnost krajnjeg rezultata dozvoljava
kompanijama da se dre njihovih sistema. Ova pitanja se odnose na softverske migracije u
celini. Migracija baza je specijalna u pogledu znanja ugraenim u eme, i jedinstvenih
vrednosti podataka smetenih u bazama. Njihov gubitak ili propadanje moe biti rizik koji
kompanija ne eli da preuzme.
Posebno migracija sistema baza otvorenog koda moe da se smatra rizinom. Razmotriemo
svako upozorenje odvojeno: neformalna podrka, komplikovano licenciranje, nedostatak
spregnutih aplikacija, veliko odravanje, nedostatak odgovornosti, nedostatak mogunosti.
Neformalna podrka proizvoda, nedostatak profesionalnih servisa. Ovo ne vai za sva pet
preduzea sistema za upravljanje bazama podataka otvorenog koda. Tri su odravane od strane
komercijalnih kompanija (MySQL: MySQL AB, Ingres: Computer Associates, MaxDB:
MySQL / SAP AG). Firebird ima potporu IBPhoenix dok PostgreSQL nudi velik izbor
profesionalne podrke irom sveta (http://www.postgresql.org/support/). tavie, neformalna
podrka je bolja nego njena reputacija. Dolazak do programera preko IRC, email-a ili pratioca
greaka(bug trackers), deljenje iskustva sa zajednicom korisnika proizvoda na forumima ili mail
listom se najee praktikuje od strane korisnika.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

49

Komplikovano licenciranje. Mnogo kompanija koristi koncept komercijalnog licenciranja,
tako da je teko kretati se kroz dunglu naina licenciranja. Firebird koristi- IPL, Ingres
CATOSL, MySQL i MaxDB mogu dvostruko da se licenciraju (komercijalno i GPL-General
Public Licence). PostgreeSQL koristi BSD licencu. Ipak, komercijalna licenca i ugovor sa
krajnjim korisnikom moe da sadri dosta klopki, dok sa druge strane postoji mnotvo resursa
za dobijanje informacija o licencama otvorenog koda (http://www.opensource.org/ ).
Nedostatak vrsto povezanih(spregnutih aplikacija), integracija tree strane, i podrke
nezavisnih prodavaca softvera. Posebno u sektoru baza podataka ovo je ozbiljno upozorenje,
iako je mnogo open source alata dostupno za povezivanje sa novim sistemom baza kompanije
trenutno koriste komercijalni alat za dizajniranje baza ili zajednica bussines intelligence
najverovatnije nee podrati Open source baze.
Veliki trokovi poslovanja Open source postaje jedan od omiljenih alata hakera korienjem
alata interfejs komandne linije, i tako donosioci odluka oekuju malu upotrebljivost, velike
trokove za trud, uenje strmih krivina za administratore, programere i korisnike. Ali danas, svih
pet velikih sistema baza otvorenog koda imaju napredni grafiki korisniki interfejs, kao i
reputaciju baza lakih za administriranje u poreenju sa njihovim komercijalnim kolegama, to je
jedan od razloga za uspeh MySQL-a u web aplikacionom sektoru.
Nedostatak garancija i odgovornosti. Garancija i odgovornost se najee pripisuju
vlasnikim softverskim proizvodima zatvorenog koda, uporeivajui ih sa dvd diskom koji
moe da se vrati prodavcu ukoliko postoji neka greka. Veina softverskih EULA (End User
Licence Agreements) ipak nema ili ima ograniavajue garancije. Ova diskusija vodi ka pravcu
neformalne podrke proizvoda. Tri od pet predstavljenih baza podataka su distriburane od
strane komercijalnih prodavaca softvera koje omoguavaju garancije u istom opsegu kao
kompanije zatvorenog koda. Takoe, kod i sistemi za praenje greaka su otvoreni,
funkcionalne mane mogu biti istaknute i iskazane mnogo lake.
Nedostatak karakteristika. Ovo je definitivno vaan faktor za odluivanje protiv baza
otvorenog koda kada nijedan od njih ne prua mogunost trenutne postavke??? Npr.
materializovani pogledi (materialized views ) samo PostgreSQL ih obezbeuje.

NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

50

5.3 Migracija ka bazama otvorenog koda. Specifikacije.
Nakon to smo obezbedili okruenje za odluivanje za ili protiv baza otvorenog koda, jedno
pitanje jako bitno se takoe postavlja: Pri emu se migracija ka bazama otvorenog koda
razlikuje od drugih napora migracije baza? Ima nekoliko razloga za izdvajanje istraivanja o
specifikacijama migracije baza otvorenog koda iz zavetenih migracija baza, objektno
orjentisanih migracije baza ili migracija ka vlasnikim bazama:
Zadravanje jednog modela podataka. Veina dokumentovanih i istraenih migracija
zamenilo je zavetanje (hijerarhijsko, mreno) relacionim modelom ili iz relacionih u
objektno orjentisane modele.
Razlozi za migraciju. Dok je normalno migracija deo modernizacije, migracija baza
otvorenog koda je uglavnom upravljana naporima za smanjivanje trokova.
Manje karakteristike(mogunosti). Verovatno da ciljane baze otvorenog koda nee
ponuditi vie mogunosti od komercijalnih. Ovo zahteva detaljnu procenu raspoloivosti
sistema za upravljanje bazama, traei najbolju koja e odgovarati sadanjem
podeavanju najbolje. Zahteva detaljnu analizu sistema zatvorenog koda da ukae koje
karakteristike se koriste momentalno.

Nedostatak migracionih alata. Migracija ka bazama zatvorenog sistema moi e da
obezbedi podrku i alate od snabdevaa softvera. to znai da veliki delovi migracije
treba uraditi runo i temeljno sa razumevanjem i temeljno razumevanje migracionog
toka je od sutinskog znaaja.

5.4 Upoznavanje sa nekim popularnim bazama otvorenog koda
Svrha baza otvorenog koda koje emo prouavati je da se obezbede istu funkcionalnost kao i
baze zatvorenih sistema. Sistem za upravljanjem baza otvorenog koda (DBMS) trebalo bi biti
izabran na osnovu funkcionalnosti i mogunosti koje podravaju baze zatvorenog koda. Postoji
pregrt baza otvorenog koda koje prema funkcionalnosti moemo porediti sa najmonijim
komercijalnim bazama zatvorenog koda: npr. Firebird, Ingres, MaxDB, MySQL i PostgreSQL.
Firebird je zasnovan na Borlandov InterBase sistem za upravljanje bazama i kao takav datira
od 1984. 2000-te Borland kompanija je odluila da pree na otvoren kod svog proizvoda
(InterBase v.6.0), trine akcije su postale manje kao i takse za licenciranje su pruale manju
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

51

zaradu nego komercijalna podrka ime se oiveo Open source projekat. Posle nekog vremena
manja zarada je uticala da Borland povue odluku o softveru otvorenog koda i opet poinje sa
softverom zatvorenog koda, poevi sa verzijom v.7.1. Ali u meuvremenu Firebird hvata
zamah i potranja se iri. Danas, Firebird sistem moda nije popularan kao MySQL na primer
ili PostgreSQL, ali bez obzira veoma je rasprostranjen i veoma hvaljen od strane njegovih
korisnika.

Slika 15. Sistem Relacionih baza podatka: Vremenska linija (Timeline)
Licencirana je pod prvobitnom Developer javnom licencom/ InterBase javnom licencom koja
omoguava da se zatvori bilo koji kod koji ima kao platformu Firebird. Samo u sluaju
modifikacije baze izvorni kod treba da bude javno dostupan. Firebird sistem se pokree na
Linux-u, MAC-u, Windowsu, HP-UX, i jo nekim verzijama Unix-a. Podrka je obezbeena
preko kompanije IBphoenix-a (http://www.ibphoenix.com) .



NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

52


Ingres
Datira jo iz 1974-god, kao projekat koji je razvijen na Univerzitetu Kalifornije, tanije
University of California, Berkeley koji je zapoeo da istrauje implementaciju relacionog
modela podataka. 1982god. Ingres je komercijalizovan od strane Ingres korporacije koji je pak
kupljen od strane Computer Associates (CA), tj. raunarskog udruenja. Pratei isto
obrazloenje kao Borland, Ingres biva pretvoren u open source reenje 2004, dok (CA) nastoji
da prua komercijalnu podrku. Ingres se pokree na Linux-u, Windows-u, kao i na OpenVMS.
Licenciran je pod CATOSL (CA Trusted Open Source License), stavljajui doprinos samo
softveru baze koji je bod CATOSL-om, i ne dodirajui se do dela koji je pod Ingres-om.
MaxDB
Ova baza poreklom je iz Nemake, zapoeta kao projekat Distribuirane baze pod mini
kompjuterima na TU Nemake. Komercijalizovana je 1981 od strane Nixdorf-a kao DDB/4,
koji je pak kupio Software AG 1993 godine i prvobitno nazvan Entire SQL server kasnije
Adabas D. SAP ga je preuzeo 1997 brendirajui ga kao SAP DB. 2000-te SAP je izbacio
SAP DB pod GPL-om. MySQL AB i SAP su formirali partnerstvo 2003, sticajui pravo
MySQL da dalje razvija SAP DB, pri emu je i reimenovan u (MaxDB), i prodaju komercijalne
licence kupcima ne elei da budu vezane GPL-om. MySQL AB usvojio je model dvostrukog
licenciranja za svoje proizvode, koristei GPL za korisnike koji su to prihvatili i komercijalne
licence koji nisu prihvatili GPL. SAP je razvio sistem baza da slui kao platforma za sve teke
aplikacije poznatu kao SAP R/3. Kao takva je zastupljena svuda u svetu i koriste je
najpoznatiji svetski brendovi kao to je: Toyota, Intel, DaimlerChrysler, Bayer, Yamaha, i
mnogi drugi. SAP e nastavljati sa razvitkom MaxDB, sa sistemom baza koji e takoe biti
SAP sertifikovani. MaxDB se pokree na Linuxu, Windowsu, i nekoliko Unix varijanti
[MaxHis, SAPHis, MaxMyS]. MaxDB se jo uvek razvija i odrava u SAP AG. Komercijalna
podrka je obezbeena od strane SAP-a i MySQL AB-a.
MySQL
MySQL je izbaen 1995-god od strane vedske kompanije MySQL AB-e. Od samog poetka je
softver otvorenog koda i brzo je pridobio enormnu bazu korisnika i zajednicu nudei lako
korienje baza koje podravaju web servere. Kao i MaxDB, MySQL prua mogunost
dvostrukog licenciranja. Neki od poznatih korisnika ove baze su Yahoo, SourceForge, NASA,
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

53

Lycos i T-sytems, kao i mnogi drugi. uveni Open source softveri kao to su: Typo3 i
Drupal(CMS), Nucleus i Wordpress(blogovi), Wikipedia/Mediawiki, PHProjekt i eGroupware
(project management/groupware). MySQL se pokree na Windows, GNU/Linux, OS/2, Mac
OS X, kao i nekoliko drugih linuks verzija, sve to moemo proveriti na:(http://www.mysql.com).
MySQL obezbeuje komercijalnu i optu podrku. PostgreSQL.
Projekat nastao 1986 pratei prethodnika Ingres-a, na istom Berkeley Univerzitetu, kao glavni
istraivaki projekat baza podataka. Kada je projekat zavren 1994, zatim je dodat SQL
interpreter i PostgreSQL je dobio naziv PostgreSQL95. Puten je zatim kao softver otvorenog
koda pod BSD licencom.1996 je konanon preimenovan u PostgreSQL.
5.5 Baze otvorenog koda: Karakteristike
Da li je migracija ka bazama otvorenog koda mogua i iji projekat treba biti izabran, zavisi od
stepena funkcionalnosti omoguenoj trenutno instaliranog sistema baza. Uglavnom se analitiari
slau da sledee karakteristike najvie utiu pri izboru sistema za upravljanje bazama, a to su:
1. Integritet podataka: Podrka za ACID transakcije, podtransakcije(tzv.umetnute
transakcije), dvofazno izvravanje, zakljuivanje na nivou reda ili Multiversion
Concurency Control (MVCC).
2. Organizacija podataka: Napredni objekti baza kao to su pogledi, eme, privremene
tabele.
3. Pristup podacima:
Napredne SQL karakteristike: Nasleivanje, korisniki definisani tipovi
podataka, operatori i funkcije, podselekcije, kompleksni upiti, napredne
strategije indeksiranja, podrka za distribuirane upite.
Opcija ukljuivanja biznis inteligencije unutar baza: Trigeri, dogaaji, sekvence,
uskladitene procedure.
Viestruki interfejsi, konekcioni drajveri, APIs.
4. Operacije:
Performance i skabilnost: viestruko tridovanje (Multithreading, niti dele resurse
procesa stim to se izvravaju nezavisno), viestruka podrka procesora, keiranje,
particionisiranje, skladitenje, grupisanje, paralelizacija upita.
Visoka dostupnost: Replikacija, napredan backup kao i oporavak podataka.
Bezbednost: enkripcija, grupni koncept, dozvole, logovanje..

NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

54

Na slici 15 prikazan je pregled karakteristika spomenutih baza kao i njihovo poreenje.
Moramo spomenuti da je mnogo lake uporediti SQL karakteristike i standarde, ili broj
podranih uskladitenih jezikih procedura nego uporeivati karakteristike koje postiu visoku
mogunost, oporavak ili skabilnost. Ovo je teko za uporeivanje iz prostog razloga jer
generalno ne postoji zajedniki standard sa kojim bi se moglo uporeivati. Ipak emo pokuati
da nabrojimo neke.
Firebird
Firebird nudi (nadogradive) poglede, trigere, (BEFORE & AFTER), skladitene procedure,
korisniko definisane funkcije, itd. Tu su i ACID transakcije, viestruka ogranienja (ukljuujui
i CHECK), dvofazno izvravanje, umetnute transakcije(tzv. savepoints) i MVCC(tzv.
Multgenerational Architecture).
Moemo pristupiti bazi preko ODBC, JDBC, OLE DB i .NET. Firebird ima interfejse za
programske jezike kao to su C, C++, Java, Delphi, PHP, Pyton, Perl, kao i njegov uskladiteni
jezik procedure PSQL takoe se ulau napori da se obezbedi kompatibilnost sa Oraclovim
PL/SQL-om.
Nema ugraene replikacije, nema grupisanja(clustering), nema optereenja, nema svrhe za
vremenski oporavak. Takoe nedostaci su vezani za podrku eme, privremenih tabela, podela
tabela i sve napredne tehnike indeksiranja. Firebird nema korisniko definisane tipove podataka,
no CLOBs(character large object), nema Bolen kao ni proireni tip. Podeavanje moe imati bilo
multiprocesorsku(simetrino multiprocesiranje), koristei Firebird Classic Server ili vienitnu
podrku koristei varijantu Super Servera(ne oba).
Ingres
Budui da je najstariji od prethodna pet sistema baza, Ingres nudi pregrt mogunosti.
Obezbeuje dogaaje, procedure skladitenja, eme, privremene tabele, pripremljene upite,
pripremljene upite, sinonime, proirene tipove, i naravno poprilino ACID transakcija.
Tu su pogledi(ali ne nadogradivi), trigeri(ali samo AFTER), neki od naprednih
indeksiranja(hash i R stablo, ali bez izraza, parcijalno ili puno indeksiranje), ogranienja(ali bez
CHECK). Ingres ima samo traenje po redovima, bez MVCC. Za visoku dostupnost, tu su
umetnute transakcije(savepoints), transakcioni log fajlovi, dvofazna izvravanja, oporavak
point-in-time, kao vrue backup-ovanje. Ingres nudi reim vie mastersko repliciranje od
take do take. Koristi viestruke niti(mutli-threaded, koristei niti operativnog sistema),
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

55

podrava simetrino procesiranje (SMP), i moe da proiriti izvrenje jednog zadatka preko vie
paralelnih procesora.
Konekcija baze je omoguena od strane ODBC, JDBC, .NET provajdera. Glavni API je za
ugraen SQL, ali takoe tu je i interfejs za Pyton, C, JAVA, Perl i PHP. Ingres podrava i ulazni
SQL92, nekoliko delova srednjeg nivoa i neto SQL99. Tu je kaskadni UPDATE i DELETE,
distribuirani upiti kao i podselekcije. Nudi i korisniko definisane funkcije, tipove podataka, kao
i operatore.
Nedostaci: nedostatak tebelarnog prostora, materializovanih pogleda kao i SSL podrku.
Max DB
MaxDB se poklapa sa bazom Ingres po starosti i karakteristikama. Ima poglede(nadogradivost i
pridruivost tabela), trigere(samo AFTER), dogaaje, skladitene procedure, eme, privremene
tabele, funkcionalne i viekolonsko indeksiranje, pripremljene upite kao i sinonime. MaxDB
SQL je samo ANSI kompatibilan samo sa SQL-92 poetnim nivoem. Naravno, tu su ACID
transakcije i ogranienja (ukljuujui i CHECK). Zatvaranje se zavrava na nivou reda(ne
MVCC).
Podacima moemo da pristupimo preko ODBC-a, JDBC-a, .NET-a, kao i SQLDBC-a. Tu je i
C/C++ prekompajler, kao i API za PHP, Perl i Pyton
MaxDB nudi pregrt opcija za backup kao i oporavak. Transakcioni log fajlovi, (vrue,
komplentno i uvean) backup, oporavak podataka(point-in-time) kao i umetnute transakcije(tzv.
savepoints). Pokree vienitno(koristei unutranje nezavisne niti operativnog sistema) takoe
nudi i multiprocesorsku podrku(multi-processor support-SMP) kao i paralelizaciju upita i
klastiranje.
MaxDB nema distribuirano optereenje(load balancing) i klastere baze podataka, ima samo
raspodelu optereenja preko viestrukih procesora na jednoj maini. U starijim verzijama, nisu
bile prave podrke za replikaciju, ali novije verzije su to premenile pomou Sinhronizacionog
menadera- Synchronization Manager za ove zadatke. Ne nudi tabelarni prostor(tablespaces),
nema podele tabela, kao i podrke za dvofazno izvrenje. Max DB nije nudio korisniko
definisani tip podataka i neproirene tipove podataka. Ali od verzije 7.6 nude se korisniko
definisane funkcije.
PostgreSQL
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

56

PosgreSQL je prenatrpan funkcijama. Obezbeuje nam eme, privremene tabele,
trigere(BEFORE&AFTER), uskladitene procedure, poglede(kao i unije[UNION] i pridrene
tabele sa Bizgres distribucijom obezbeuje nam materijalizovane poglede). Tu su korisniko
definisane funkcije, tipovi podataka i operatori. PosgreSQL nudi podrku za IPv6, kao i GIS
implementaciju. Prua nam mnogo napredniju tehniku indeksiranja nego bilo koja od
spomenutih baza otvorenog koda: Izrazni indeks, parcijalan index, R stablo, hash funkciju,
pretraivaka maina potpunog teksta(full-text engine, preko integrisanog Tsearch2), kao i
viekolonska indeksiranje, takoe tu je i bitmap indeksiranje (za OLAP). PostgreSQL ima
proirene i Boolen tipove podataka. PostrgreSQL je jedini objektno-relacioni model baze
podataka u potpunosti, prema tome nudi tabele i nasleene tipove podataka. Takoe je i jedini
sistem upravljanja za bazama koji vri konverziju korisniko definisanog stringa(niza) u
podatke(TO_DATA) kao i string u numeriku konverziju (TO_NUMBER). Tree, ona je jedina
baza koja prua unakrsnu vezu baza za pristupanje podacima u jednoj bazi od skripta pokrenutog
u drugoj emi. Tu su i ACID transakcije i ogranienja(constraints- ukljuujui i CHECK). Zatim
tu je i dvofazno izvravanje, umetnute transakcije(savepoints), pretraivanje po redovima(row-
level locking) i MVCC.
PostgreSQL-u se moe pristupiti preko ODBC, JDBC ili jednom od API-a kao to su(C, C++,
Java, Perl, Pyton, PHP, Ruby, R). Tu je i velik izbor uskladitenih jezikih procedura kao to su:
PL/pgSQL, PL/TCL, PL/perl, PL/Pyton, PL/PHP, PL/sh, PL/R i PL/Ruby. PostgreSQL je
kompatibilan sa ANSI 92 i ANSI 99 i podrava veliki podskup SQL2003 i SQL2008. Nudi
sekvence, kolekcije, podselekcije i kaskadno update/delete.
Backup se moe izvriti korienjem SQL otpada, backup-a na nivou fajl sistema ili vruim on-
line backup-ovanjem. Unapred zapisani logovi(Write-ahead logs, WAL) pruaju oporavak od
vremenske take, tj. point-in-time recovery. Replikacija je podrana od doprinetih modula(npr.
Slony). Tabelarni prostor i pripremljeni upiti poboljavaju performanse.
PostgreSQL nema sinonime i dogaaje. Nudi grupisanje, ali ne i distribuirano optereenje.
Takoe je i ne-nitno okruenje i kao takav je onemoguen da iri jedan upit preko vie
procesora. Ipak tu je multi procesorska podrka (SMP) za pokretanje vie upita na vie konekcije
na vie procesora.
MySQL
MySQL nudi izbor 12 razliitih uskladitenih tipova tabela: MyISAM, MERGE, MEMORY
(HEAP), BDB (BerkeleyDB), EXAMPLE, FEDERATED, ARCHIVE, CSV, BLACKHOLE,
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

57

ISAM, InnoDB, MySQL Cluster (NDB). Tj. baza moe da sadri tabele razliitih tipova.
Karakteristike tabela su:
Samo kada koristi InnoDB nain skladitenja, MySQL nudi MVCC, podklase,
kaskadajui update/delete i distribuirane upite. Online backup je dostupan samo za
InnoDB, i samo kao zatvoreni kod, tj. kao komercijalni dodatak.
Za grupisanje kao i distribuirano optereenje mora da koristi NDB nain skladitenja.
Samo NDB i InnoDB pruaju ACID transakcije, strane kljueve, pretragu po redovima,
kao i ugnjedene/umetnute transakcije za delimian povratak.
Samo MyISAM tip tabele podrava pun tekst(full-text) kao i R-stablo indeksiranja i
proirene tipove podataka.
Privremene tabele mogu samo biti tipa HEAP, ISAM, MyISAM, MERGE i InnoDB.

MySQL dolazi sa (vruim/online) backup alatima, oporavak od vremenske take, tzv.point-in-
time transakcionim logovanjem, kao i umetnutim transakcijama (savepoints). MySQL nam
prua replikacije(single-master, multi-slaves) i grupisanje(clustering), kao i upite keiranja,
pripremljene upite, prostor tabela zbog performansi. MySQL omoguava vienitni reim(tzv.
multi-threading- koristei niti operativnog sistema) kao viestruko procesorsku podrku.
Bazi se moe pristupiti preko ODBC i JDBC. Tu je i API za C, C++, C#, Eiffel, Smalltalk,
Java, Lisp, Perl, PHP, Python, Ruby i Tcl. MySQL je ANSI-92 kompatibilan, podrava i irok
podskup ANSI-99.










NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

58



6. PRAKTIAN RAD
6.1 Normalizacija i funkcionalna zavisnost podataka na primeru MySQL
baze.
U radu emo napraviti jo jedan kratak osvrt na izabranu bazu otvorenog koda, predstaviti njene
osnovne karakteristike, kreirati bazu od logike do fizike implementacije, putem algoritma, ili
tzv. ivotnog ciklusa baze, koja je glavna struktura svake relacione baze podataka. Ali opet ne
skreujui sa glavne glavne teme koja ima za cilj da nam predstavi znaaj normalizacije i
zavisnosti putem konkretnog primera.
Razmatraemo sledee stavke koje su osnova svake relacione baze a to su:
I. Analiza zahteva. Priklupljanje informacija od krajnjih korisnika, koje su presudne za
definisanje optimalne i funkcionalne baze, u zahteve pored neophodnih podataka
spadaju i relacione veze kao i softverska platforma za implementaciju baze.

II. Logiki dizajn. Globala ema, konceptualni dijagram modela podataka, koji pokazuje
sve podatke i njihove veze, obino je razvijen korienjem tehnika kao to je ER
(Entity-relationship model) ili UML (Unified Modeling Language). Koncept modela
podataka na kraju treba da se transformie u normalizovanu relaciju, ili tabelu.
Metodologija razvijanja globalne eme je ista za centralizovane ili distribuirane baze
podataka.

III. Fiziki dizajn. Fiziko predstavljanje baza najee predstavlja izbor indexa, tj.
pristupnih metoda koje koristimo, i jedna od glavnih uloga mu je da optimizuje
performanse to je blie mogue.

IV. Implementacija, monitoring i modifikacija. Jednom kada zavrimo sa dizajnom baze,
baza moe biti kreirana korienjem data definition language (DDL) kao deo DBMS. I
DML ( data manipulating language ) moe biti iskorien za upite i auriranje baze, kao
podeavanje indexa, omoguavanja ogranienja poput referentne integracije. SQL jezik
sadri oba jezika DDL i DML; na primer, komada create table predstavlja DDL, dok
komanda select predstavlja DML.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

59


MySQL predstavlja vienitni SQL sistem za rad sa bazama podataka. Sistem radi kao server,
obezbeujui istovremeno pristup bazi podataka za vie korisnika. Proizvod je kompanije
MySQL AB, a u vlasnitvu je poznate firme Sun Microsystems. Predstavlja softver otvorenog
koda, tj. otvoren je za prouavanje, testiranje, nadogradnju i poboljanje od strane bilo kog
programera. Na raspolaganju je kao besplatan i kao komercijalni softver. Moe se nabaviti pod
uslovima opte GNU licence, a ukoliko je potrebna komercijalna licenca, moe se kupiti.
MySQL je sistem za upravljanje relacijskim bazama podataka. Relacijska baza podataka je baza
podataka koja podatke radije sprema u odvojene tabele nego sve u jednu tabelu, zbog
izbegavanja redudantnosti podataka. Ovo daje brzinu i fleksibilnost bazama podataka. Tablice su
povezane definisanim relacijama to omoguuje kombinovanje podataka iz nekoliko tablica u
sluaju da postoji zahtev za to. SQL znai eng. "Structured Query Language" (strukturni jezik za
pretraivanje) najei standardizovan jezik za pristupanje bazama podataka.
Zato koristiti MySQL? Vrlo je brz, pouzdan, i lagan za korienje. Takoe ima vrlo praktine
dodatne opcije razvijene u bliskoj saradnji sa korisnicima. MySQL je originalno razvijan za
manipulaciju vrlo velikih baza podataka, mnogo bre od postojeih reenja i uspeno se koristi u
visoko zahtevnim produktivnim okruenjima ve godinama. Pristupanost, brzina i sigurnost
ine MySQL vrlo pogodnim za pristupanje bazama podataka na Internetu.
Performanse
Na MySQL-ovoj zvaninij web lokaciji mogu se pogledati rezultati poreenja MySQL-a i
drugih baza podataka. Ti podaci pokazuju da uglavnom primetno nadmauje brzinom svoje
rivale. U naelu, rezultate bilo kog testiranja treba prihvatiti sa izvesnom rezervom, naroito
zbog toga to ih je izvrio proizvoa baze podataka. Meutim, i nezavisni testovi pokazuju da
je MySQL jedan od najbrih proizvoda na raspolaganju. Brzina je oduvek bila kljuna odlika o
kojoj projektanti MySQL-a vode rauna. U MySQL se ugrauju nove mogunosti samo ako nisu
na tetu performansi. Zbog toga se ponekad nove mogunosti dodaju sporije nego to to
korisnici ele, ali se time obezbeuje da MySQL uvek bude brz.
Stabilnost
Projektanti su uvek smatrali da je stabilnost sistema od prvorazrednog znaaja. Sve verzije
MySQL-a izdate u binarnom obliku, ak i alfa izdanja, moraju proi kroz skup testova
stabilnosti. Postupak obuhvata testiranje funkcija i drugih osobina, kao i ispitivanje rezultata
operacija pri kojima su u prolosti otkrivene i ispravljene greke, ime se obezbeuje da se
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

60

ponovo ne uvede ve ispravljena greka. Ispravljanju greaka projektanti moraju da daju vii
prioritet od drugih poslova. U sutini, projektant prekida tekui posao sve dok se ne otkloni
greka koja spada u njegovu oblast strunosti. Pravilo nalae da svako izdanje MySQL-a mora
biti oieno od dotad poznatih greaka koje se mogu reprodukovati u poznatim uslovima.
Razume se, odreeni problemi ne mogu se reti a da pritom ne prouzrokuju druge probleme na
drugom mestu. To naroito vai za produkcione verzije u koje ne bi trebalo ugraivati sutinske
izmene koje bi mogle da utiu na stabilnost verzije. U takvim sluajevima, problem se
dokumentuje i otklanja u jednoj od narednih verzija. I najzad, kvalitet softvera obezbeuju
MySQL-ovi klijenti i zajednica korisnika. Preko etiri miliona korisnika irom sveta rade u
veoma razliitim okruenjima, to prua jedinstvenu priliku za otkrivanje greaka ve u
poetnim fazama razvoja. Budui da je MySQL-ov sistem za otkrivanje i dokumentovanje
greaka javan, svaki korisnik ima uvid u sve to su drugi korisnici otkrili i moe da dodaje svoje
napomene.
Lakoa upotrebe
Trea kljuna odlika MySQL-a jeste lakoa upotrebe. Nije potreban sloen postupak
podeavanja da biste poeli da radite. MySQL server radi kako treba im ga raspakujete.
Standardne vrednosti parametara su takve da minimiziraju utroak prostora diska i memorije.
Razume se, da bi se postigle optimalne performanse odreenih funkcija koje su vane u
produkcionom okruenju, kao to je npr. prijavljivanje korisnika za rad u bazu podataka,
potrebno je finije doterivanje tih standardnih vrednosti radnih parametara MySQL-a. Pri tome
vam mogu pomoi primeri konfiguracionih datoteka koje dobijate uz MySQL.
Cena
Cena je stavka koja se moda najlake poredi sa konkurentima. Za mnoge uslove upotrebe,
MySQL je besplatna aplikacija. Uslovi licence tipa GPL omoguavaju da neogranieno koristite
softver, da menjate njegov izvorni kd i da MySQL distribuirate drugim ljudima takoe pod
GPL uslovima. U odreenim situacijama, kada elite da distribuirate MySQL kao sastavni deo
komercijalnog proizvoda, moraete da kupite komercijalnu licencu. Drugim reima, za MySQL
postoje dva sistema licenciranja, gde je besplatna upotreba odreena GPL uslovima, a nain
komercijalne upotrebe odreen je standardnim sporazumima EULA (End User Licence
Agreement- sporazum o licenci sa krajnjim korisnikom) ili OEM (Original Equipment
Manufacturer izvorni proizvoa opreme) uslovima. Pravilo kompanije je sledee: Ako je va
proizvod besplatan, i na je; ako se va proizvod plaa na takoe. Najvaniji konkurenti
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

61

nude iskljuivo komercijalne licence, uz sloene sisteme cena, koje zavise od nameravanog
naina upotrebe, broja procesora po serveru i broja istovremenih korisnika koji e uspostavljati
veze sa bazom podataka. Trokovi za Oracle server, Microsoft SQL Server, IBM-ov DB2 i
Sybase-ov server, mogu dostii desetine hiljada dolara u okruenju sa umerenim optereenjem,
pa ak i stotine hiljada dolara za server sa vie procesora na koji se povezuje vei broj klijenata.
MySQL se ponekad poredi sa drugim bazama podataka otvorenog koda, kao to su PostgreSQL
i Firebird. Od svih pomenutih baza podataka otvorenog koda, jedino je MySQL proizvod iza
kojeg stoji jedna kompanija, koja je vlasnik svih prava intelektualne svojine i koja nudi celovite
komercijalne licence, koje obuhvataju i odgovornost i odtetu u sluaju neispravnosti, kao to
zahtevaju velike organizacije. Jo jedna kategorija softvera sa kojom se MySQL poredi jesu
jeftine baze podataka koje nisu namenjene radu u klijent/server okruenju, a ciljna trina grupa
su im kuni korisnici ili male firme. U tu kategoriju spadaju Access i Filemaker Pro. Mada se
grafiki korisniki interfejs programa iz ove kategorije esto jednostavno upotrebljava, njima
uglavnom nedostaje vana funkcionalnost i nisu dovoljno stabilni, skalabilni i brzi da bi bili
upotrebljivi za aplikacije od kljune vanosti za firmu.
Mogunosti
Poreenje mogunosti softvera u mnogome zavisi od toga koje mogunosti smatrate vanim za
sistem ili aplikaciju za koju vam je potreban. MySQL prua odreene mogunosti, kao to su:
Tekstualno pretraivanje
Replikovanje
Podrka za veoma obimne tabele
kojih u drugim jeftinim proizvodima uopte nema ili ne rade najbolje. Meutim MySQL-u
nedostaju neke mogunosti kao to su uskladitene procedure i pogledi, koje su standardne u
najskupljim proizvodima, a postoje ak i u nekim jeftinim proizvodima. Neke od tih
nedostajuih mogunosti (kao to su uskladitene procedure) planirane su za naredne verzije,
dok e za druge biti potrebno vie vremena. Neke MySQL-ove mogunosti kao npr.
zakljuavanje na nivou reda, ne postoje ak ni u najskupljim sistemima. Na web lokaciji
MySQL-a nalazi se link http://www.mysql.com/information/features.html , na kojoj se moe
nai uporedni pregled mogunosti MySQL-a i dvadesetak konkurenata. Kratak spisak
mogunosti koje ne podravaju svi MySQL- vi konkurenti:
Transakcije u skladu sa grupom pravila ACID
Podrka za razliite platforme
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

62

Replikovanje
Podrka za obimne tabele i baze podataka
Tekstualno pretraivanje
Podupiti
Podrka za veinu sintakse po standardu SQL 92
6.2 Logiki model baze podataka agencije za promet nekretnina
Podaci koje uvaju agencije za promet nektretnina. U naoj dravi agencije za promet
nekretnina su u privrednom registru registrovane za delatnost obavljanja prometa
nepokretnostima. Prema Zakonu o nepokretnostima u nepokretnosti spadaju: zemljite
(poljoprivredno, graevinsko, umsko i umsko zemljite), zgrade, posebni delovi zgrada
stanovi, poslovne prostorije, garae i garana mesta) i drugi graevinski objekti. Poto obavljaju
poslove kupoprodaje i izdavanja nepokretnosti, agencije za promet nekretnina imaju potrebu da
vode evidenciju o nepokretnostima, njihovim vlasnicima (ukoliko agencija nije vlasnik
nekretnine, to uglavnom nije sluaj) i klijentima (odnosno kupcima ili klijentima koji su
iznajmili nekretninu) i podacima vezanim za te poslove. Agencije za promet nekretnina
uglavnom vre delatnost kao posrednici prilikom kupoprodaje ili izdavanja nekretnine. Naknada
za posrednike poslove definie se ugovorom izmeu vlasnika nepokretnosti i same agencije. To
moe biti procenat od vrednosti nepokretnosti ili na drugi naina definisana naknada.

Slika 16 Relacioni model baze podataka uraen u MySQL Workbench programu
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

63


Slika 16 grafiki prikazuje emu baze podataka agencije za promet nekretnina. ema je uraena
u MySQL-ovom programu Workbench koji predstavlja grafiki interfejs za realizaciju tabela i
baza. ema se moe prikazati i teksualno na sledei nain: Vlasnik ( vlasnikID, ime, adresa,
telefon) Lokacija (lokacijaID, drava, grad, optina, ulica) Objekat (objekatID, tip, povrina,
cena, sprat, struktura, vlasnikID, lokacijaID) Dodatno (terasa, parking, klima, grejanje,
kablovska, objekatID) Foto (fotoID, sadrzaj, foto_alt, objekatID) Klijent (klijentID, k_ime,
k_adresa, k_telefon) Ugovor (ugovorID, datum, iznos, istek, vlasnikID, klijentID) ema date
baze podataka agencije za promet nekretnina ima sedam tabela. Kolone koje su ispisane
podebljanim slovima predstavljaju primarne kljueve datih tabela, dok kolone koje su
podvuene predstavljaju spoljne kljueve.
6.3 Pristup izradi modela
Prva stvar koju treba uraditi jeste neka vrsta istraivanja o samoj delatnosti firme ili sistema za
koji projektujemo model baze podataka. U stvarnom ivotu ne postoje dva potpuno identina
sistema, stoga svakom modelovanju treba pristupiti pojedinano. Znai, treba uoiti i zapisati
sve osnovne elemente, procese i odnose. Ti osnovni elementi koje emo da modelujemo su, u
stvari, entiteti i relacije. Entiteti predstavljaju stvari iz stvarnog sistema o kojima uvamo
podatke u bazi podataka. U naem primeru, entitet je objekat, vlasnik objekta ili klijent o kojima
uvamo podatke u bazi. Svaki je entitet za sebe: vlasnik objekta je jedan entitet, objekat je drugi
entitet, a klijent bi predstavljao trei entitet. Relacije su, u stvari veze izmeu entiteta. One mogu
biti razliitih vrsta, pa tako imamo relacije tipa jedan prema jedan, jedan objekat naprema
vie, i vie objekata prema vie. Relacija tipa jedan prema jedan povezuje samo dva
entiteta. Primer je da jedna nekretnina moe biti samo na jednoj lokaciji. Primer za relaciju
jedan prema vie jeste jedan vlasnik koji moe posedovati vie nekretnina ili jedna nekretnina
moe imati vie fotografija u bazi.
MySQL je sistem za upravljanje relacionim bazama podataka, to znai da podrava baze u
kojima postoje relacije izmeu podataka koji se uvaju u tabelama. Kolone (atributi),
predstavljaju kolone tabele koje opisuje odreeni podatak koji se nalazi u svakom redu tabele.
Re klona i atribut koriste se kao sinonimi, ali tanije je rei da je kolona deo tabele, a atribut se
odnosi na entitet iz stvarnog sveta koji tabela modeluje.
Redovi tabele sadre podatke iz kolona tabele. Redovi u tabeli se jo nazivaju i zapisi ili n-torke.
U naem primeru na slici 2 vidi se da svaki red u tabeli vlasnik predstavlja zapis o jednom
vlasniku nekretnine.
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

64


Slika 17. Prikaz tabele vlasnik
Kljuevi su kolone koje identifikuju red tabele. Primarni klju je kolona ili grupa kolona
pomou koje se moe jednoznano identifikovati pojedini red u tabeli. Mi hoemo da u naem
primeru odredimo kolonu po kojoj emo moi da identifikujemo pojedinano svakog vlasnika
nekretnine. U ovom sluaju to je prva kolona vlasnikID koja je numerikog tipa i predstavlja
unikatni redni broj zapisa. To je bolji klju od kolone Ime jer se moe dogoditi da dve osobe
imaju isto ime i prezime. Kod izbora kolone za primarni klju, najbolje je izabrati neku koja
moe imati jedinstvene vrednosti za svaki zapis.
Spoljni kljuevi predstavljaju veze izmeu tabela. To je uglavnom primarni klju iz neke druge
tabele kojim se napravi veza sa tom tabelom i svim podacima iz te tabele.

Slika 18. Prikaz tabele ugovor
Redovi vlasnikID I klijentID u tabeli ugovor na slici 3 predstavljaju spoljne kljueve a odnose se
na primarne kljueve u tabelama vlasnik i klijent.
6.4 Principi kod projektovanja baza podataka
Kod projektovanja baze podataka moramo sebi postaviti dva vana pitanja:
Koje sve podatke treba uvati, odnosno o kojim sve stvarima ili entitetima
moramo da uvamo podatke?
Koje emo upite postavljati bazi podataka?
Na osnovu odgovora na ova pitanja moemo da napravimo bazu podataka ija e
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

65

struktura biti takva da iskljuuje strukturne probleme kao to su redudantnost i anomalije
podataka.
Redudantnost podataka
Kada projektujemo bazu podataka, to moramo uraditi tako da redudantnost (dupliranje) podataka
bude minimalna, a da pri tome ne izgubimo nijedan podatak koji nam je neophodan.
Redudantnim podatkom se smatra onaj koji se ponavlja u razliitim redovima iste tabele ili u
razliitim tabelama jedne baze podataka. U naem primeru to bi moglo da se zamisli kad bi
recimo u tabeli ugovor (slika 1) unosili podatke o klijentu i vlasniku (ime i prezime, adresu),
umesto to sada imamo samo njihove ID vrednosti, pri emu bi dolo do dupliranja podataka u
bazi.
Anomalije podataka
Anomalije predstavljaju neto sloeniji problem i pojavljuju se kod loe osmiljene strukture
baze podataka. Mogu se javiti kod dodavanja, brisanja i auriranja podataka. Recimo, u tabelu
vlasnik uneli smo odreenu osobu koja poseduje neku od nekretnina iz tabele objekat. Tabele
vlasnik i objekat povezane su kolonom vlasnikID koja identifikuje jedinstvenog vlasnika. Ako
elimo da promenimo vlasnika, kod auriranja moe doi do anomalije ako nismo uveli pravilo
referencijalnog integriteta da se pri auriranju jedne tabele aurira automatski i druga tabela u
kojoj se nalazi spoljni klju. Isti problem moe nastati kod brisanja zapisa iz tabele.
Vrednost Null
Jo jedno pravilo dobrog projektovanja baza podataka nalae da treba izbegavati eme koje
dozvoljavaju veliki broj nepopunjenih atributa. To nam govori da ti podaci nisu mnogo znaajni
za bazu (ako od 100 zapisa u jednoj koloni 95 imaju vrednost null), ili da su veoma malo
zastupljeni, pa se umesto toga moe napraviti nova tabela koja bi uvala neki strani klju i
podatke iz kolone koji nisu null.






NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

66

6.5 Kreiranje baze podataka agencije za promet nekretnina
Kreiranje tabela
Krenuemo sa kreiranjem tabela za nau bazu agencije za promet nekretninama. Poto smo
napravili emu baze u kojoj postoji sedam tabela sada emo ih kreirati runo u MySQL monitoru
koji je ukljuen u sve instalacije MySQL-a, a komande se zadaju preko komandne linije.
MySQL monitor nije jedini korisniki interfejs. Za pristup se mogu koristiti i MySQL Control
Centar koji je grafiki korisniki interfejs i zvanini je proizvod za rad sa MySQL-om, ali ne
nalazi se na svim instalacijama. Moete ga preuzeti sa adrese:
www.mysql.com/downloads/mysqlcc.html . Trei najzastupljniji korisniki interfejs jeste
phpMyAdmin, koji je web korisniki interfejs za upotrebu MySQL-a. Veoma je popularan kod
hosting kompanija koje svojim korisnicima stavljaju na raspolaganje MySQL radi razvijanja
web aplikacija. Za phpMyAdmin potrebno je da imate funkcionalan web server i instaliran PHP.
No, da se vratimo MySQL monitoru. Pri startovanju potrebno je uneti lozinku koju smo zadali
prilikom instalacije. Posle unosa lozinke moemo poeti sa kreiranjem baze podataka.

Slika 18. Kreiranje baze i tabela u MySQL monitoru




NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

67

Kreiranje baze vri se komandom:
CREATE DATABASE nekretnine;
pod uslovom da baza sa takvim imenom ne postoji u spisku baza kod MySQL-a. Ako niste
sigurni da li neka baza sa tim imenom postoji onda se pre comande create database moe zadati
komanda: drop database if exists nekretnine; to znai da e se takva ako eventualno postoji
obrisati.
Komanda : USE nekretnine; koristi se da bi selektovala bazu sa kojom elimo da radimo.
Izraz CREATE TABLE vlasnik (kolone tabele); kreira tabelu vlasnik sa zadatim kolonama, gde
svaka kolona mora imati definisan tip podataka.




Numeriki tip Znakovni tip Vremenski tip
INT CHAR DATE
DECIMAL VARCHAR TIME
FLOAT TEXT DATETIME
DOUBLE BLOB TIMESTAMP
ENUM YEAR
SET

Kao to si i vidi u tabeli 1, postoji mnogo razliitih tipova za smetanje podataka.
Osnovni tipovi koji se koriste su:
Numeriki tipovi: tinyint, smallint, int, mediumint, bigint, numeric, decimal, float i
double
Znakovni tipovi: char, varchar, text i blob
Za rad sa datumima i vremenima: date, time, datetime, timestamp i year
Ostali tipovi podataka
Tabela 9. Vlasnik
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

68


Odabirom pravih tipova, tabele se optimizuju. Racionalnije se koristi prostor za memoriju
podataka, a samim tim i realizovanje upita, odnosno sam odziv rezultata pretrage moe se
znaajno ubrzati. Pravilo je upotrebiti najmanji tip podataka koji je dovoljan za unos podataka sa
kojima e se raditi. Na primer, ako se u koloni tabele uvaju brojevi od jedan do deset, nije
neophodno zadavati tip int , ve tip tinyint. to su krai redovi i manje tabele, to e se one bre
pretraivati. Isto vai i za podatke tipa varchar, kod kojih se mora deklarisati maksimalna
duina podatka koji se moe uneti. Moe se zadati i tip char, koji predstavlja znakovnu
vrednost fiksne duine. Bez obzira da li je zadato varchar ili char, nain rada sa tim podacima
se nee razlikovati. Jedina razlika je oblik u kojem se podaci smetaju u memoriju. Podatak tipa
varchar(15), zauzima onoliko prostora koliko je potrebno za smetanje stvarnog broja
karaktera, dok podatak tipa char(15), uvek zauzima petnaest znakova u memoriji, bez obzira na
to da li je u njega uneta bilo kakva vrednost.
Prva kolona koja je kreirana u tabeli vlasnik je kolona vlasnikID (slika 4). Ona je tipa int (eng.
integer), a posle te deklaracije tipa slede ostale deklaracije koje odreuju tu kolonu. Zadali smo
da je kolona vlasnikID not null drugim reima, u svakom redu tabele ta kolona mora sadrati
neku vrednost. Zatim smo zadali auto_increment, ime smo omoguili da svaki naredni red
koji unesemo u kolonu dobija jedinstvenu vrednost po redosledu niza. Primary key znai da e
ta kolona biti primarni klju te tabele. Ako tabela ima samo jedan primarni klju, onda se moe
zadati ovako. U sluaju da tabela ima dva ili vie primarnih kljueva, onda se sintaksa razlikuje
u tome to se posebno navede primary key(), a u zagradi se navedu kolone koje ine primarni
klju.
Zatim smo deklarisali tipove za kolone ime, adresa i telefon, i time smo definisali tabelu vlasnik.
Tabela vlasnik trebala bi da sadri osnovne i kontakt podatke o vlasnicima nekretnina.
Tip tabele koji smo deklarisali je InnoDB tabela. Standardni tip tabele u MySQL-u je MyISAM
tabela, i za nju nije neophodno dodati odredbu type. MyISAM tabele su esto bre od tabela tipa
InnoDB. To je njihova prednost, dok im je mana to to ne podravaju spoljne kljueve i
transakcije.

NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

69


Slika 19. Prikaz kreiranja tabela objekat i dodatno

Na slici 19 prikazano je kreiranje tabele objekat koja je napravljena za uvanje osnovnih
vrednosti objekta nekretnine i tabele dodatno za smetanje nekih dodatnih karakteristika
nekretnine. I jedna i druga tabela imaju spoljne kljueve koji referenciraju na kolone u drugim
tabelama. Tako je tabela objekat povezana sa tabelama Vlasnik i Lokacija, dok je tabela dodatno
povezana sa tabelom Objekat.
Tip podataka ENUM, u zagradi definie vrednosti koje se mogu nalaziti u redovima te kolone,
ali moe i sadrati vrednost null, ukoliko nije uneta nijedna od navedenih. Tip podataka SET,
takoe u zagradi definie vrednosti koje se mogu nalaziti u redovima te kolone, s tim to moe
sadrati vie opcionih vrednosti od tipa podataka ENUM.
Kolone koje su spoljni klju u ovom primeru definisane su sa slubenom rei references, to
znai da pokazuju na koju tabelu a zatim u zagradi, na koju tano kolonu u toj tabeli se odnose.
Tako, u naem primeru, kolona vlasnikID u tabeli objekat odnosi se na istoimenu kolonu u tabeli
Vlasnik. Ime ove kolone koja predstavlja spoljni klju moglo je biti i razliito od kolone na koju
se odnosi, ali meni je vie odgovaralo da bude isto, to u pokazati u narednim primerima kada
se budu kreirali upiti za bazu.
Da objasnimo, rei ON UPDATE i ON DELETE govore nam o tome ta e se desiti sa
podacima u koloni ako se ona kolona na koju oni referenciraju aurira ili brie. Pa se tako moe
setovati da to bude cascade, restrict ili set null. Ako setujemo sa cascade, onda e se promena u
glavnoj tabeli, izvriti i u koloni sa spoljnim kljuem. Znai promena u glavnoj dovodi do
promene u zavisnoj povezanoj tabeli. Komanda restrict znai da e biti odbijeno da se izvri
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

70

promena u zavisnoj tabeli, dok komanda set null oznaava da e u sluaju auriranja ili brisanja
zapisa u glavnoj tabeli dovesti do toga da vrednosti zapisa u zavisnoj tabeli uzmu vrednost null.
Ovim navedenim komandama se definiu pravila referencijalnog integriteta za bazu podataka.
Ostalo nam je da kreiramo tabele foto, za eventualno smetanje fotografija nekretnina, zatim
klijent i ugovor.
Tabelom klijent agencija za promet nekretnina uvae podatke o klijentima koji su kupili ili
iznajmili neku nekretninu koja je u vlasnitvu agencije ili vlasnika nekretnine. Tabela ugovor bi
trebalo da uva podatke o stranama koje su potpisale ugovor, zatim iznosu, datumu
zakljuivanja ugovora kao i o isteku ugovora ako se radi o zakupu.



Slika 20. Prikaz kreiranja tabela foto, klijent i ugovor

Poto smo kreirali sve tabele iz nae pretpostavljene eme sa slike 20 sada moemo pogledati i
njihovu strukturu u MySQL-u. Za prikaz strukture tabela u bazi koristiemo komandu desc.


Slika 21. Prikaz strukture tabele vlasnik
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

71


Slika 22. Prikaz strukture tabele lokacija

Slika 23. Prikaz strukture tabele objekat

Slika 24. Prikaz strukture tabele dodatno


Slika 25. Prikaz strukture tabele foto


Slika 26. Prikaz strukture tabele klijent
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

72


Slika 27. Prikaz strukture tabele ugovor

6.6 Realizacija upita
Da bismo mogli da oitamo podatke koji su sauvani u tabelama baze podataka, moramo
postaviti upite nad tabelama. Slubena re koja se koristi kod upita je SELECT.
Njegov oblik izgleda ovako:
SELECT ime kolone
FROM ime tabele
[ WHERE uslovi ]
[ GROUP BY grupisanje ]
[ HAVING uslov_grupe ]
[ ORDER BY redosled ]
[ LIMIT ogranienja ]
[ PROCEDURE ime_procedure(argumenti) ];

Jednostavni upiti
Upiti koji se postavljaju nad tabelama mogu biti:
Jednostavni
Sloeni upiti
Jednostavni upit je onaj koji se postavlja nad jednom tabelom i nije previe
optereen uslovima. Primer takvog upita moe biti:
SELECT * FROM Vlasnik;
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

73

Jedan od korisnih elemenata jeste operator * kojim se biraju sve kolone iz navedene
tabele ili tabela.


Naravno, sutina relacione baze nije u tome da vam daje sve podatke koje ste u nju uneli, ve da
vam omogui da pronaete odreene podatke. Da biste izdvojili odreeni podskup redova iz
tabele, potrebno je da zadate uslov za njihov izbor. Tome slui odredba WHERE. Na primer:
SELECT ime, telefon FROM Vlasnik WHERE telefon LIKE 011%;

Tabela 11. Prikaz rezultata upita sa uslovom

Na slici 18 moemo da vidimo da su izdvojeni podaci, imena iz tabele Vlasnik iji brojevi
telefona poinju sa 011. Koristili smo rezervisanu re LIKE i operator % koji nam je posluio
kao doker znak za pravljenje uzorka na osnovu kojeg je filtrirana kolona sa brojevima telefona.

Tabela 10. Upit tabele Vlasnik
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

74

Odredba ORDER BY sortira redove po redosledu vrednosti iz jedne ili vie kolona navedenih u
iskazu. Ako nije navedeno, podrazumeva se rastui redosled, a ako elimo da podaci budi
sortirani po opadajuem redosledu, koristi se re DESC iza navedenog imena kolone.

Odredbom LIMIT moe se ograniiti broj redova rezultata koje daje upit. Ova odredba moe
sadrati i dva parametra, pri emu je prvi broj reda od kog poinje uitavanje a drugi je broj koji
predstavlja maksimalan broj redova rezultata. Naroito je korisna kod web aplikacija koje
koriste MySQL jer omoguava jednostavan mehanizam podele rezultata na stranice.
Uklanjanje dupliranih vrednosti u rezultatima pretrage moe se postii pomou
odredbe DISTINCT.
Osim grupisanja podataka i upotrebe grupnih funkcija, rezultat grupne funkcije moete porediti
sa zadatom vrednou pomou odredbe HAVING. Ta odredba pie se neposredno iza odredbe
GROUP BY i slina je odredbi WHERE, ali se odnosi samo na grupe podataka i rezultate
grupnih funkcija.

Tabela 12. Ugraene funkcije za upotrebu u odredbi GROUP BY
Funkcija Namena
Avg (kolona) Vraa prosek vrednosti saranih u datoj koloni
Count(kolona) Vraa ukupan broj vrednosti u datoj koloni
Min(kolona) Vraa najmanju vrednost u datoj koloni
Max(kolona) Vraa najveu vrednost u datoj koloni
Std(kolona) Vraa standardnu devijaciju za vrednosti
sadrane u datoj koloni
Sum(kolona) Vraa zbir vrednosti sadranih u datoj koloni




NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

75





Tabela13. Operatori koji mogu da se koriste sa odredbom WHERE
Operator Primer Opis
= VlasnikID = 3 Ispituje da li su vrednosti
jednake
> cena > 50.00 Ispituje da li je prva
vrednost vea od druge
< cena < 50.00 Ispituje da li je prva
vrednost manja od druge
>= cena >= 50.00 Ispituje da li je prva
vrednost vea od druge
ili su jednake
<= cena <= 50.00 Ispituje da li je prva
vrednost manja od druge
ili su jednake
!= ili <> sprat != 0 Ispituje da li su dve
vrednosti razliite
IS NOT NULL adresa is not null Ispituje da li polje sadrzi
bilo kakvu vrednost
IS NULL adresa is null Ispituje da li je polje
prazno
BETWEEN iznos between 0
and 50.000
Ispituje da li je vrednost
u zadatom opsegu
IN grad in ("Srbija") Ispituje da li je vrednost
u skupu navedenih
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

76

vrednosti
NOT IN grad not in
("Srbija")
Ispituje da li je vrednost
izvan skupa navedenih
vrednosti
LIKE ime like ("Marko %") Ispituje da li postoji SQL
podudarnost sa zadatim
uzorkom
NOT LIKE ime not like ("Marko
%")
Proverava da li se
vrednost nepodudara sa
zadatim uzorkom
REGEXP ime regexp Ispituje da li postoji
podudarnost sa
zadatim regularnim
izrazom

Poslednja tri reda u tabeli odnose se na operatore LIKE i REGEXP koji omoguavaju
prepoznavanje uzoraka.
Operator LIKE omoguava SQL prepoznavanje jednostavnih uzoraka. Uzorci mogu da se
sastoje od obinog teksta i znaka za procenat (%), koji predstavlja bilo koji broj znakova,
odnosno podvlake (_), koja predstavlja samo jedan znak.
REGEXP omoguava prepoznavanje uzoraka pomou regularnih izraza.Umesto rezervisane rei
REGEXP moete upotrebiti njen sinonim RLIKE.

Sloeni upiti
Sloeni upiti izvravaju se nad vie tabela istovremeno, pa je potrebno tabele spojiti radi
manipulacije nad podacima. Tabele koje povezujemo navodimo u odredbi FROM, zajedno sa
vrstom spoja. Takoe treba zadati i uslov koji opisuje nain na koji bi tabele trebalo da budu
spojene. Primer:
SELECT ime.Vlasnik, telefon.Vlasnik, tip.Objekat, cena.Objekat FROM
Vlasnik, Objekat WHERE vlasnikID.Vlasnik = vlasnikID.Objekat;
NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

77


U ovom primeru je zadat upit nad tabelama Vlasnik i Objekat, gde je uslov za spajanje tabela
jednakost izmeu primarnog kljua u tabeli Vlasnik i spoljnog kljua u tabeli Objekat. U odredbi
FROM lista tabela je zadata zarezom izmeu tabela. Umesto zareza moe se koristiti rezervisana
re JOIN koja je sinonim.
Kada se zada ovakva vrsta spoja, MySQL pretrauje sve tabele koje su zadate i pokuava da
pronae najefikasniji nain spajanja, pri emu ne mora da spoji tabele redosledom na koji ste
naveli. Ako hoemo da to bude tano po redosledu koji je naveden onda se koristi rezervisana
re STRAIGHT JOIN.
Levi i desni spoj
Spojevi sa JOIN rade u sluaju da su spojevi koje smo zadali jednakovredni. ta se
deava kada elimo da pronaemo sve redove u jednoj tabeli za koju ne postoje
odgovarajui redovi u drugoj tabeli?

Tada se koriste levi ili desni spoj. Levi spoj radi tako to za sve redove tabele iz prve koja je
zadata(leva tabela), trai odgovarajue redove u tabeli koja je pridruena. Pronaeni redovi se
postavljaju pored leve tabele, a za svaki red koji nema parnjaka u desnoj tabeli, operator LEFT
JOIN dodaje vrednost NULL.











NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

78

7. Zakljuak
Razvojem web-a, tehnologija, kao i pod uticajem drugih faktora poput ekonomije, korisnici
se sve vie opredeljuju za open source reenja, ili softverskim reenjima otvorenog koda gde
umesto kupovine i podrke komercijalnih softvera korisnici biraju reenja otvorenog koda gde
umesto kupovine dobijaju podrku za njih, mada dosta od ovih reenja imaju mogunost
dvostrukog licenciranja, gde se biraju razliiti uslovi korienja softvera.
Tenja za slobodom govora i izraavanjem oduvek je prisutna u svim segmentima
oveanstva, bilo da je prikazana duhovnim ili stvaralakim nainom, tako je i sloboda softvera
nala svoj udeo slobode u raunarskom ininjeringu, u radu su opisana softverska reenja
slobodnog koda koja se tiu baza podatka, takoe se opisivanjem karakteristika ukazuje itaocu
koje su njihove glavne prednosti i nedostaci ali i kriterijumi prilikom izbora.
Teko se moe sa preciznou ukazati koje softversko reenje treba izabrati, to je na
projektantu da odlui na osnovu zahteva organizacije, stim da je ovo brana koja zahteva stalno
praenje trendova na svim nivoima, tako i to se tie problema prilikom izbora sistema za
upravljanje bazom treba sagledati aspekte ekonominosti i funkcionalnosti.













NORMALIZACIJA PODATAKA I FUNKCIONALNA ZAVISNOST U BAZAMA OTVORENOG KODA

79


LITERATURA
1. Jeffrey Ullman 1997: First course in database systems, PrenticeHall Inc., Simon & Schuster
2. Tsitchizris, D. C. and F. H. Lochovsky (1982). Data Models. Englewood-Cliffs, PrenticeHall.
3. Beynon-Davies P. (2004). Database Systems 3rd Edition. Palgrave, Basingstoke, UK.
4. Raul F. Chong, Michael Dang, Dwaine R. Snow, Xiaomei Wang (3 July 2008)."Introduction to
DB2".
5. C. W. Bachmann (November 1973), "The Programmer as Navigator".
6. IBM Corporation. "IBM Information Management System (IMS) 13 Transaction and Database
Servers delivers high performance and low total cost of ownership".
7. Codd, E.F. (1970)."A Relational Model of Data for Large Shared Data Banks".
In: Communications of the ACM 13 (6): 377387.
8. William Hershey and Carol Easthope, "A set theoretic data structure and retrieval language".
9. Ken North, "Sets, Data Models and Data Independence", Dr. Dobb's, 10 March 2010