Sadraj:2.Uvod23.Struktura relacijske baze podataka54.Model relacijske baze podataka65.Relacije u bazi podataka86.Atributi97.Kljuevi98.Pravila integriteta podataka109.Normalizacija1110.LITERATURA13

Uvod

Baza podataka je skup meusobno povezanih podataka, pohranjenih u vanjskoj memoriji raunala. Podaci su istovremeno dostupni raznim korisnicima i aplikacijskim programima. Ubacivanje, promjena, brisanje i itanje podataka obavlja se posredstvom zajednikog softvera. Korisnici i aplikacije pritom ne moraju poznavati detalje fizikog prikaza podataka, ve se referenciraju na logiku strukturu baze.

Sustav za upravljanje bazom podataka(DataBase Management System - DBMS) je posluitelj(server) baze podataka. On oblikuje fiziki prikaz baze u skladu s traenom logikom strukturom. Takoer, on obavlja u ime klijenata sve operacije s podacima. Dalje, on je u stanju podrati razne baze, od kojih svaka moe imati svoju logiku strukturu, no u skladu s istim modelom. Isto tako, brine se za sigurnost podataka, te automatizira administrativne poslove s bazom.

Podaci u bazi su logiki organizirani u skladu s nekim modelom podataka. Model podataka je skup pravila koja odreuju kako moe izgledati logika struktura baze. Model ini osnovu za koncipiranje, projektiranje i implementiranje baze. Dosadanji DBMS-i obino su podravali neki od sljedeih modela:

Relacijski model. - Zasnovan na matematikom pojmu relacije. I podaci i veze medu podacima prikazuju se pravokutnim tabelama.

Mreni model - Baza je predoena usmjerenim grafom. vorovi su tipovi zapisa, a lukovi definiraju veze medu tipovima zapisa.

Hijerarhijski model - Specijalni sluaj mrenog. Baza je predoena jednim stablom ili skupom stabala. vorovi su tipovi zapisa, a hijerarhijski odnos nadreeni-podreeni izraava veze meu tipovima zapisa.

Objektni model - Inspiriran je objektno-orijentiranim programskim jezicima. Baza je skup trajno pohranjenih objekata koji se sastoje od svojih internih podataka i metoda (operacija) za rukovanje s tim podacima. Svaki objekt pripada nekoj klasi. Izmeu klasa se uspostavljaju veze nasljeivanja, agregacije, odnosno meusobnog koritenja operacija.

Hijerarhijski i mreni model bili su u upotrebi u 60-tim i 70-tim godinama 20. stoljea. Od 80-tih godina pa sve do dananjih dana prevladava relacijski model. Oekivani prijelaz na objektni model za sada se nije desio, tako da dananje baze podataka uglavnom jo uvijek moemo poistovjetiti s relacijskim bazama.

Baze podataka predstavljaju viu razinu rada s podacima u odnosu na klasine programske jezike. Ta via razina rada oituje se u tome to tehnologija baza podataka nastoji (i u velikoj mjeri uspijeva) ispuniti sljedee ciljeve:

Fizika nezavisnost podataka - Razdvaja se logika definicija baze od njene stvarne fizike grade. Ako se fizika grada promijeni (na primjer, podaci se prepiu u druge datoteke na drugim diskovima), to nee zahtijevati promjene u postojeim aplikacijama.

Logika nezavisnost podataka - Razdvaja se globalna logika definicija cijele baze podataka od lokalne logike definicije za jednu aplikaciju. Ako se logika definicija promijeni (na primjer uvede se novi zapis ili veza), to nee zahtijevati promjene u postojeim aplikacijama. Lokalna logika definicija obino se svodi na izdvajanje samo nekih elemenata iz globalne definicije, uz neke jednostavne transformacije tih elemenata.

Fleksibilnost pristupa podacima - U starijim mrenim i hijerarhijskim bazama, staze pristupanja podacima bile su unaprijed definirane, dakle korisnik je mogao pretraivati podatke jedino onim redoslijedom koji je bio predvien u vrijeme projektiranja i implementiranja baze. Danas se zahtijeva da korisnik moe slobodno prebirati po podacima, te po svom nahoenju uspostavljati veze medu podacima. Ovom zahtjevu zaista zadovoljavaju jedino relacijske baze.

Istovremeni pristup do podataka - Baza mora omoguiti da vei broj korisnika istovremeno koristi iste podatke. Pritom ti korisnici ne smiju ometati jedan drugoga, te svaki od njih treba imati dojam da sam radi s bazom.

uvanje integriteta - Nastoji se automatski sauvati korektnost i konzistencija podataka, i to u situaciji kad postoje greke u aplikacijama, te konfliktne istovremene aktivnosti korisnika.

Mogunost oporavka nakon kvara - Mora postojati pouzdana zatita baze u sluaju kvara hardvera ili greaka u radu sistemskog softvera.

Zatita od neovlatenog koritenja - Mora postojati mogunost da se korisnicima ogranie prava koritenja baze, dakle da se svakom korisniku reguliraju ovlatenja to on smije a to ne smije raditi s podacima.

Zadovoljavajua brzina pristupa - Operacije s podacima moraju se odvijati dovoljno brzo, u skladu s potrebama odreene aplikacije. Na brzinu pristupa moe se utjecati odabirom pogodnih fizikih struktura podataka, te izborom pogodnih algoritama za pretraivanje.

Mogunost podeavanja i kontrole - Velika baza zahtijeva stalnu brigu: praenje performansi, mijenjanje parametara u fizikoj gradi, rutinsko pohranjivanje rezervnih kopija podataka, reguliranje ovlatenja korisnika. Takoer, svrha baze se vremenom mijenja, pa povremeno treba podesiti i logiku strukturu. Ovakvi poslovi moraju se obavljati centralizirano. Odgovorna osoba zove se administrator baze podataka.

Komunikacija korisnika odnosno aplikacijskog programa i DBMS-a odvija se pomou posebnih jezika.

Ti jezici tradicionalno se dijele na sljedee kategorije:

Jezik za opis podataka (Data Description Language - DDL) - Slui projektantu baze ili administratoru u svrhu zapisivanja sheme ili pogleda. Tim jezikom definiramo podatke i veze meu podacima, i to na logikoj razini.

Jezik za manipuliranje podacima(Data Manipulation Language - DML) - Slui programeru za uspostavljanje veze izmeu aplikacijskog programa i baze. Naredbe DML omoguuju manipulaciju podataka u bazi, te jednostavne operacije kao to su upis, promjena, brisanje ili itanje zapisa. U novije vrijeme, DML postupno biva potisnut naprednim ORM sustavima, koji omoguavaju programeru da komunicira s bazom direktno iz programskog jezika (najpoznatiji je Entity Framework od Microsofta).

Jezik za postavljanje upita(Query Language - QL) - Slui neposrednom korisniku za interaktivno pretraivanje baze. To je jezik koji podsjea na govorni (engleski) jezik Naredbe su neproceduralne, dakle takve da samo specificiraju rezultat kojeg elimo dobiti, a ne i postupak za dobivanje rezultata.

Ovakva podjela na tri jezika danas je ve prilino zastarjela. Naime, kod relacijskih baza postoji tendencija da se sva tri jezika objedine u jedan sveobuhvatni. Primjer takvog integriranog jezika za relacijske baze je SQL: on slui za definiranje podataka, manipuliranje i pretraivanje. Integrirani jezik se moe koristiti interaktivno (preko on-line interpretera) ili se on moe pojavljivati uklopljen u aplikacijske programe.

Struktura relacijske baze podataka

Dolazak do relacijske baze podataka podrazumijeva kreiranje modela podataka, najprije konceptualnog, a zatim i fizikog, iz kojeg bi se, na kraju, dobila relacijska baza podataka. Modeliranje podataka je proces nastanka modela podataka, apstrakcijom realnog sistema. Model objekti-veze pripada generaciji najpotpunijih modela podataka, jer podrava sve vrste apstrakcija i daje semantiki zadovoljavajui opis sloenog sustava. Relacijski model podataka je danas najrasprostranjeniji model podataka jer za njega postoji dosta komercijalno raspoloivih sustava za upravljanje bazama podataka.

Svaka baza podataka nastaje iz modela podataka. Model podataka je intelektualno sredstvo za prikazivanje objekata sustava, njihovih atributa i meusobnih veza (statikih karakteristika sustava) preko logike strukture baze podataka. Svaki model podataka posjeduje tri osnovne komponente:

Struktura modela skup koncepata za opisivanje objekata sustava, njihovih atributa i meusobnih veza.

Ogranienja semantika ogranienja na vrijednost podataka koja se ne mogu predstaviti samom strukturom modela, a koja u svakom trenutku moraju biti zadovoljena (pravila integriteta)

Operacije operacije nad konceptima strukture podataka, pod definiranim ogranienjima, preko kojih je mogue opisati dinamiku sistema u modelima procesa.

Relacijska baza podataka je baza podataka zasnovana na relacijskom modelu podataka. Moemo rei i da je relaciona baza podataka skup meusobno povezanih tablica, podataka koji se sadre u tim tablicama. Svaka tablica predstavlja jednu relaciju, koja posjeduje svoje atribute, skupove vrijednosti, koje mogu uzeti pojedine atribute i koja moe biti u direktnoj vezi sa drugim relacijama. Teorija relacijskog modela kae da redovi u tablici ne posjeduju implicitni poredak. To znai da je poredak fleksibilan i da se moe naznaiti prilikom konstruiranja upita za bazu podataka. Kao u sluaju redova ni kolone ne moraju imati predodreen poredak, zbog toga se kae da relacijska baza prua logiku nezavisnost podataka.

Model relacijske baze podataka

Da bi se model okarakterizirao kao relacijski model baze podataka Edgar F. Codd je postavio pravila koja treba da podre njegovu teoriju, i osiguraju ispravno koritenje relacijske strukture.

Coddova pravila su tako stroga da ih i dananji sistemi za upravljanje bazama podataka ne ispunjavaju u potpunosti. Pravila ima trinaest, numerirana su od nule do dvanaest.

0. Sistem se mora kvalificirati kao relacioni, kao baza podataka, i kao sistem za upravljanje. Da bi sistem za upravljanje bazom podataka nazvali relacionim, on iskljuivo mora koristiti svoje relacione mogunosti da upravlja bazom podataka.

1. Pravilo informacije : Sve informacije u bazi podataka moraju biti predstavljene na jedinstven nain, svojim vrijednostima kolona sauvanih u redovima.

2. Pravilo garantiranog pristupa : Svi podaci moraju biti dostupni bez dvosmislenosti. Ovo pravilo je reformulacija osnovnog zahtjeva za postojanjem primarnih kljueva. Ono zahtjeva da je svaka pojedinana vrijednost mora biti adresabilna navoenjem naziva tabele u kojoj se nalazi, naziva kolone u kojoj se nalazi i vrijednosti primarnog kljua reda u kojem se vrijednost nalazi.

3. Sistemsko tretiranje NULL vrijednosti : Sistem mora dozvoljavati da svako polje po potrebi moe ostati prazno (imati vrijednost NULL). Mora podravati predstavljanje informacija koje nedostaju ili se ne mogu dodijeliti, koje je sistematino, razliito od svih regularnih vrijednosti (npr. razliito od nule ili bilo kog drugog broja) i nezavisno od tipa podatka. Takoer se naglaava da takve reprezentacije sistem mora tretirati dosljedno.

4. Aktivan, uvijek dostupan katalog zasnovan na relacionom modelu : Sistem sadri opis baze podataka na logikom nivou u vidu tablica, tj. relacijski katalog dostupan autoriziranim korisnicima kroz upotrebu standardnog upitnog jezika. To znai da korisnici moraju biti u mogunosti da pristupaju strukturi baze podataka (katalogu) koristei isti upitni jezik kojim se slue da bi pristupili samim podacima.

5. Pravilo razumljivog podjezika : Sistem mora podravati bar jedan jezik koji a) ima linearnu sintaksu, b) moe da se koristi i interaktivno u okviru aplikativnih programa, c) podrava operacije definiranja podataka (ukljuujui definiranje pogleda), operacije manipulacije podacima (auriranje kao i izdvajanje), pravila integriteta kao i autorizaciju, kao i operacije manipuliranja transakcijama (begin, commit, rollback).

6. Pravilo auriranja pogleda : Sve poglede koje je teoretski mogue aurirati, aurira sistem.

7. Unoenje, auriranje i uklanjanje podataka na nivou skupova : Sistem mora podravati skupovne insert, update, delete operatore. To znai da se podaci iz relacijske baze mogu izdvajati u skupovima koje ine podaci iz vie redova i vie tablica. Ovo pravilo naglaava da operacije dodavanja auriranja i brisanja budu primjenjive na bilo koji skup podataka koji se moe izdvojiti iz baze, a ne samo na pojedinani red u jednoj tablici.

8. Fizika nezavisnost podataka : Promjene na fizikom nivou (nain na koji se uvaju podaci) ne smiju zahtijevati promjene aplikacija zasnovanih na danoj strukturi.

9. Logika nezavisnost podataka : Promjene na logikom nivou (tabela, kolona, redova itd.) ne smiju zahtijevati promjene aplikacija zasnovanih na danoj strukturi. Mnogo je tee postii logiku nego fiziku nezavisnost.

10. Nezavisnost od pravila integriteta : Pravila integriteta moraju biti definirana nezavisno od aplikativnih programa i sauvana u katalogu. Mora biti predviena mogunost njihove izmjene u bilo kom trenutku bez nepotrebnog uticanja na postojee aplikacije.

11. Nezavisnost od distribucije : Distribucija dijelova baze na razne lokacije mora biti nevidljiva za korisnike baze. Postojee aplikacije moraju nastaviti da rade :

a) kada se prvi put uvodi distribucija baze

b) pri bilo kojoj sljedeoj distribuciji podataka u sistemu.

12. Pravilo zatite podataka :Ako sistem podrava upotrebu jezika koji rade na niskom nivou (manipulacija jednim redom u danom trenutku), onda oni ne mogu biti koriteni za napad na sistem, u smislu zaobilaenja pravila integriteta ili sigurnosti relacija u sistemu.

Model nije stvaran svijet nego njegov pojednostavljen prikaz. Model koji je kompliciraniji od entiteta koji opisuje je bezvrijedan u modeliranju baze podataka. Entitet u sistemu moe predstavljati osobu, objekt, dogaaj ili pak moe opisivati relaciju izmeu objekata u stvarnom svijetu. Entiteti mogu biti konkretni ili apstraktni u zavisnosti od potrebe, ali se moraju moi jednoznano identificirati. Jasno je da je ovjek kao bie jedinstven objekt u fizikom svijetu. Ali ukoliko se entitet ovjek pojavljuje u bazi podataka koja se bavi biznisom, ovjek moe imati nekoliko uloga, moe biti zaposleni, suradnik, vlasnik ili kupac. Ako bi htjeli da predstavimo jo detaljnije entitet ovjeka u tom sistemu mogao bi da ima razliite atribute i ovlatenja u zavisnosti od uloge u sistemu. ef u kompaniji moe otpustiti radnika, ali radnik ne moe efa, iako su u sistemu predstavljeni kao isti entitet ovjek. Isti entitet bi mogao ako je vlasnik da ima neke druge atribute i ovlatenja. Postavlja se pitanje dali model treba da se bazira na pojedincu ili na ulogama koje bi mu se dodjelile. Veina baza podataka se bazira na ulogama koje se dodjeljuju pojedincu u sistemu baze podataka zbog lake manipulacije ovlatenjima i atributima.

Relacije u bazi podataka

Relacija ili veza je posebna vrsta entiteta. Relacija je nain da se entiteti veu jedan sa drugim, da bi se dobila nova informacija koja e postojati odvojeno od konkretnih objekata koje vee.

Entiteti mogu biti povezani preko jednog ili vie atributa, u praksi se to svodi na vezu izmeu primarnog kljua jedne tabele i vanjskog kljua druge. Mogu se razlikovati tri tipa relacija koje se uglavnom realiziraju preko prve dvije navedene relacije :

- JEDAN NA JEDAN : jednom redu jedne tablice odgovara tono jedan red druge tablice. Npr., ako se u jednoj tablici uvaju podaci o firmama, a u drugoj o njihovim sjeditima i to je veza jedan-jedan (one-to-one, 1:1).

- JEDAN NA VIE : Jednom redu prve tabele moe odgovarati vie redova druge tabele. Jedan kupac moe imati vie narudbi. (one-to-many, 1:n)

- VIE NA VIE : Jednom redu prve tablice moe odgovarati vie redova druge, ali vai i obrnuto, jednom redu druge tablice moe odgovarati vie redova prve tablice. Dobar primjer je tablica u kojoj uvamo sve dostavljae robe u nekoj firmi, a u drugoj tablici sva vozila koje dostavljai koriste. Veza je vie-vie, jer jedan dostavlja moe koristiti vie vozila, (recimo da ima deset dostavnih vozila) ali i isto vozilo moe koristiti koristi vie dostavljaa. U praksi se ova veza razbija na dvije veze jedan-vie.

Atributi

Atributi pripadaju entitetu i definiraju ga. Njemaki matematiar Leibnitz je otiao korak dalje i rekao da je entitet proizvod svih svojih atributa. Relacijski model slijedi njegovu tvrdnju, predstavljajui atribute kao kolone koje u svojim redovima uvaju vrijednosti instance entiteta. U relacijskoj teoriji redovi su neureeni, to nije sluaj u SQL koji i pored toga to sledi relacijsku teoriju ima ureene redove u tablicama. Ono to je vano naglasiti je to da se kod definiranja atributa entiteta uzimaju u obzir atributi koji su zahvaeni poljem interesa kojim se bavi baza podataka. Ako modeliramo entitet Vozilo u firmi, vani atributi bi bili broj sjedita, godina prve registracije, sljedei servis i dr. Iako postoji u stvarnom svijetu atribut boja vozila se ne bi uzimao u obzir prilikom definiranja atributa. S druge strane, ukoliko se kod entiteta ponu uoavati njegovi atributi kao bitni, onda bi se dati atribut trebao u sistemu izdvojiti kao poseban entitet. To u praksi znai da ako imamo tabelu vozilo i atribut model vozila, model vozila zbog vanosti vlastitih atributa trebao bi postati novi entitet, gdje bi postojala relacija izmeu glavnog entiteta vozilo i entiteta model vozila.

Kljuevi

Kandidat klju moe biti sastavljen od jednog ili vie atributa koji nepogreivo oznaavaju jedan red u tablici. Definicija relacije kae da je svaki red u tablici jedinstven, znai da se analizom kolona moe uoiti jedna ili vie kolona koje identificiraju svaki red. U jednostavnijim tablicama e se nametnuti jedna kolona za primarni klju. U drugim sluajevima to e biti dvije ili vie kolona i takav primarni klju(PK) se naziva kompozitni ili sloeni primarni klju. U najgorem sluaju to mogu biti sve

kolone u tablici, to je znak da se nije na pravi nain modelirala tablica. Da bi izabrali primarni klju od kandidata kljueva u tabeli, on mora ispuniti sljedee kriterije :

- mora biti jedinstven

- mora biti popunjen

- mora biti stabilan, sa malom vjerojatnosti promjene

- mora biti minimalan, jer to manje kolona sadri, pretraivanje baze e biti bre i manje e biti greaka pri unosu podataka.

Kao to je prethodno reeno o relacijskom modelu, veza izmeu tabela moe biti jedan ili vie atributa. Vanjskim kljuem se naziva svaki atribut koji postoji u drugoj tabeli sa istim vrijednostima. Takoer, atribut koji je dio veze izmeu tabela moe biti u primarnom kljuu tablice A ili tablice B. Moe biti primarni klju ili dio njega u obje ili ni u jednoj. Po ovim osobinama atributa za vezu moe se primijetiti velika fleksibilnost povezivanja izmeu tablica. Iako se vanjski klju ne mora naznaiti, preporuljivo ga je obiljeiti zbog preglednosti modela baze podataka.

Pravila integriteta podataka

Pravila integriteta su ogranienja sadraja baze podataka na neka dozvoljena stanja. Cilj tih pravila je da sprijee unos neispravnih, neistinitih ili nepotpunih podataka u bazu, to bi naruavalo konzistentnost baze podataka. Vano je istai da se integritet podataka ne odnosi samo na kljueve. Skup opih pravila integriteta sastoji se od dva pravila :

- Integritet objekta : atribut ili skup atributa koji ine primarni klju ili su njegov dio ne mogu uzeti NULL vrijednost, dakle vrijednosti za te atribute mora biti unijeta.

- Referencijalni integritet : ukoliko su dvije tablice u relaciji (npr.Firma i Radnik), tada svaka vrijednost atributa koji je vanjski klju (ID Radnik u tabeli Firme) mora biti ili jednaka vrijednosti primarnog kljua (ID Radnik u tabeli Radnik) ili NULL vrijednosti. Drugim rijeima, kada se unosi ID radnika u tabeli Firma, kolona sa tom vrijednou mora postojati u tabeli Radnik, ili se to polje mora ostaviti prazno.

Ukoliko se paljivo proue ogranienja koja utiu na operacije nad tablicama u relacijskom modelu podataka, moe se zakljuiti da ova, naizgled teorijska ogranienja i te kako imaju veze sa praksom i da se moe, ukoliko se potuju ova ogranienja, osigurati siguran unos, izmjena i brisanje podataka u bazi podataka, a da pri tome ne doe do poremeaja konzistentnosti baze podataka.

Christopher J. Date u svojoj knjizi Introduction to Database Systems iznosi tvrdnju koju naziva Golden Rule (Zlatno pravilo) integriteta baze podataka :

[No update operation must ever assign to any database a value that causes its database predicate

to evaluate to FALSE. ]

to u prijevodu znai : Nikada se na tablici baze podataka ne smije izvriti takva izmjena podataka koja bi ugrozila ispravnost relacije koju tabela posjeduje sa drugom tablicom. Dalje u tekstu kae da sistem BP ne moe garantirati istinitost podataka, samo konzistentnost. Ispravnost podrazumijeva konzistentnost, dok nekonzistentnost podrazumijeva neispravnost podataka. Pod ispravnim podacima se podrazumijevaju podaci samo ako odraavaju stvarno stanje interesne sfere u realnom svijetu. Integritet podataka se ne odnosi samo na ogranienja na tablicama zbog ispravnosti, nego i na ispravnost podataka dobivenih upitima.

U praksi se esto javlja sluaj nedostatka informacija koje su potrebne. Na primjer ako se vodi evidencija o ponuenoj robi, pri emu se zavode podaci o robi, ta da se radi u situaciji kada grupa robe nije prethodno definirana? Svaki dobar model realnog sistema mora pruiti mogunost da se rijei ovaj problem i on se rjeava uvoenjem takozvane NULL vrijednosti. NULL vrijednosti je oznaka da nam je stvarna vrijednost atributa nepoznata. Ogranienja koja se pojavljuju prilikom dizajniranja baza podataka mogu se svrstati u dvije grupe:

- Prvu grupu ine ogranienja na vrijednosti koje moe primiti neki atribut (npr. ID Robe ne moe biti slovo, niti manja od nule, a mora bitiu opsegu od -2^31 (-2,147,483,648) do 2^31-1 (2,147,483,647)) i koja ne zavise od vrijednosti ostalih atributa.

- U drugu grupu se ubrajaju ogranienja na vrijednosti koje moe primiti neki atribut, a koja zavise od vrijednosti ostalih atributa (npr. , ako se unosi realizacija ponude i potranje, unijeti datum u realizaciji ne moe biti manji od datuma kada je ponuda ili potranja objavljena).

Normalizacija

Normalizacija predstavlja sistemsku metodu za osiguravanje da je struktura baze podataka pogodna za upite opeg tipa, da se smanji mogunost redundancije podataka, da se smanji mogunost pojave anomalija unosa, auriranja i brisanja koje bi mogle da dovedu do gubitka integriteta podataka. Normalizacija je i iterativni proces tokom koga se vri reorganizacija baze podataka u cilju izbjegavanja redundancije i poveanja stabilnosti baze podataka. Postupak je podran i teoretski, ali poslije stalnog rada u relacijskom modelu se pokazuje da je zdravorazumsko razmiljanje najbolja osnova za izvravanje procesa normalizacije. Kasnije se moe izvriti provjera postupka normalizacije primjenom procedura za provjeru normalnih formi u kojima se nalaze tablice u bazi podataka. Normalizacijom baze podataka eliminiraju se sljedei atributi :

- atributi koji sadre vie od jedne vrijednosti,

- atributi koji su dupli ili se ponavljaju,

- atributi koji ne opisuju tabele,

- atributi koji sadre redundantne podatke,

- atributi koji su izvedeni iz ostalih atributa.

Potpuna normalizacija nije obavezna ali je preporuljiva. Uzdravanje od pune normalizacije obino podrazumijeva predvianje problema koji bi se mogli pojaviti (takav pristup je ponekad neophodan s obzirom na slabu odvojenost logikog i fizikog modela). Proces normalizacije je zasnovan na hijerarhiji normalnih formi. Svaka normalna forma se zasniva na prethodnoj i definira rjeenje problema koji prethodnik nije pokrio. Prve tri normalne forme je kao i pravila za uspostavljanje relacijskog modela ustanovio Codd. Baza se smatra normaliziranom ukoliko potuje pravila iz prve tri normalne forme (NF). Posle 3NF dolazi Boyce-Coddova normalna forma (BCNF) i proizala je iz zajednikog rada spomenute dvojice strunjaka. S druge strane, to viu NF baza podrava vie je relacija u njoj, vie je JOIN operatora zbog ega je tee doi do specifinog podatka, a baza koristi vie resursa da bi odgovorila na zahtjev. Jedan od problema je i to to detekcija nepravilnosti koje definira peta i vie normalne forme ne moe da se obavi bez raunalne analize.

LITERATURA

1. Christopher J. Date, An Introduction to Database Systems, C. J. Date, 2003.

2. Jan L. Harrington, Relational Database Design, Morgan Kaufmann Publishers, 2002.

3. Varga M.: Baze podataka - konceptualno, logiko i fiziko modeliranje podataka. DRIP, Zagreb, 1994.

13