Normalizacija relacija je postupak razvoja relacionog konceptualnog modela u kome se svaka relacija nekog relacionog modela svodi na odgovarajuću „normalnu formu”. Međutim, definicije normalnih formi imaju i opštiji značaj i mogu se eksplicitno ili implicitno koristiti i za primenu drugih modela u konceptualnom modelovanju.
Uobičajeno je da se postupak normalizacije tretira i kao postupak logičkog projektovanja baze podataka. Logički model baze podataka, nezavisan od konkretnog SUBP-a, tretira se kao konceptualni model, pa se normalizacija, koja takođe ne zavisi od konkretnog SUBP-a, tretira kao postupak konceptualnog modelovanja. Relacioni model zahteva da se sve relacije u modelu nalaze u prvoj normalnoj formi. Prva normalna forma se definiše na sledeći način:
Relacija R je u prvoj normalnoj formi (1 NF) ako su sve vrednosti njenih atributa atomske.
Termin „normalizovana relacija” se koristi za relacije u prvoj normalnoj formi. Ostale normalne forme relacija, o kojima će se detaljno govoriti, nisu zahtev samog relacionog modela, već predstavljaju način da se iskažu kriterijumi za dobru praksu konceptualnog modelovanja, odnosno logičkog projektovanja relacione baze podataka.
Uobičajeno je da se normalizacija tretira kao postupak kojim se odstranjuju tzv. „anomalije u održavanju (ažuriranju)” relacija do kojih dolazi zbog redundanse podataka u bazi podataka. Osnovne operacije održavanja (ažuriranja) baze podataka u relacionom modelu su dodavanje nove n-torke u relaciju, izbacivanje neke n-torke iz relacije i izmena vrednosti nekog atributa u relaciji. Anomalije u ažuriranju će biti objašnjene na primeru.
Redundansa podataka je osnovni uzrok sledećih anomalija u održavanju:
-
Anomalije u dodavanju su naziv za situaciju u kojoj u bazu podataka nije moguće ubaciti neki logički skup podataka, a da se pri tome, zbog strukture relacija, ne zahteva i ubacivanje nekih drugih podataka.
-
Anomalije u izbacivanju su naziv za situaciju u kojoj izbacivanje nekog logičkog skupa podataka iz baze, prouzrokuje i neželjeno izbacivanje nekih drugih podataka.
-
Anomalije u promeni sadržaja su situacija u kojoj promena jednog podatka zahteva i promenu nekih drugih podataka u bazi.
Već je rečeno da je redundansa podataka uzrok prikazanih anomalija. Međutim, isto tako se može reći da su redundansa, odnosno anomalije u ažuriranju prouzrokovane činjenicom da relacija predstavlja spoj (agregaciju) više različitih objekata sistema.
Postavlja se i pitanje kako se, od bilo kog skupa relacija, može doći do skupa koji zadovoljavajuće modeluje realni sistem, pa samim tim ima i minimalnu redundansu.
Normalizacija je opšti postupak dovođenja relacija u normalne forme koje predstavljaju fundamentalne objekte sistema i njihove veze. Normalne forme, samim tim, garantuju minimum redundanse podataka u bazi i održavanje baze bez anomalija.
Prilikom definisanja atributa, kao što je rečeno, pristupa se modeliranju podataka odozdo nagore (Bottom Up). Ovaj pristup veoma je prihvatljiv za početnike u ovoj oblasti, jer polazi od opipljivih informacija definisanih na dokumentima i u kartotekama. Osnovu za ovaj način modeliranja podataka čine analiza funkcionalnih zavisnosti i postupak normalizacije.
U okviru aktivnost postupak normalizacije uklanjaju se sve strukture koje stvaraju redundansu podataka, pa je slogan normalizacije: jedna činjenica na jednom mestu.
Pravilno izveden postupak normalizacije podataka omogućuje korektno izvođenje aktivnosti aplikativno modeliranje koja ima strukturu kojom osigurava da u radu sa njom neće biti neželjenih anomalija, kao što su, npr. uništavanje određenih podataka ili neusklađenost između memorisanih podataka kao posledica ažuriranja baze podataka.
Drugim rečima, postupak normalizacije predstavlja transformaciju početnog entiteta u jednu ili više korektnih entiteta ili veza u kojima su svi atributi potpuno funkcijski zavisni od ključa, a međusobno funkcijski nezavisni.
Da bi se mogao opisati postupak normalizacije, treba prethodno opisati pojam funkcijske zavisnosti.
Ako je svakoj vrednosti atributa A u relaciji R priključena samo jedna vrednost atributa B u istoj relaciji, onda je atribut B funkcijski zavisan od atributa A. Funkcijska zavisnost se može definisati između složenog ključa (više atributa) i jednostavnog atributa.
Funkcijska zavisnost
Ako se svakom paru vrednosti atributa A i B relacije R može priključiti tačno jedna vrednost C iste relacije, tada je atribut C funkcijski zavisan od sastavljenog atributa A i B.
Potpuna funkcijska zavisnost se definiše na osnovu definicije funkcijske zavisnosti.
Atribut B je potpuno funkcijski zavisan od atributa A iste relacije, ako je funkcijski zavisan od atributa A, a ne od nekog sastavnog dela atributa A.
Na osnovu ovako izvedenih definicija na primeru entiteta OSOBA biće pokazan postupak normalizacije kroz definisanje prve (1NF), druge (2NF) i treće (3NF) normalne forme.
Prva normalna forma (1NF)
Može li se na osnovu posmatranja entiteta OSOBA uočiti greška? Zbog lakšeg razumevanja treba prevesti entitet OSOBA u tabelu sa definisanim primercima (koristi se i termin instance).
Problem je u atributu Isplate. U vezi sa entitetima i atributima naglašeno je da sva imena moraju biti u jednom primerku, tj. da se u jedan atribut ne može smestiti više isplata. S obzirom na to da nije poznato koliko isplata treba zapamtiti, koliko je prostora za to potrebno i šta raditi ako ima više isplata nego prostora, to onda ovakva tabela krši prvu normalnu formu. Da bi se popravila prethodna tabela, treba na neki načim ukloniti atribute isplate iz entiteta OSOBA.
Rešenje
Pošto je otkrivena grupa podataka koji se ponavljaju i od njih stvoren novi entitet ISPLATA, time je učinjen prvi korak prema normalizovanom modelu.
Rešenje primer 2
Kao još jedan primer vezan za definisanje prve normalne forme, treba navesti slučaj koji se najčešće pojavljuje višeznačna upotreba istog atributa, gde se jednim atributom, npr. “Dat_zap ili Dat_odlaska” definišu dve činjenice.
Dakle, problem je u atributima: ‘dat_zap ili dat_odlaska’ koji predstavljaju jednu od dve činjenice, početak rada u firmi i prestanak rada u firmi. Ne postoji mogućnosti da se otkrije šta taj datum predstavlja, kao sto ne postoji mogućnost da se zapamte oba datuma, iako su, možda, oba poznata. Rešenje nije u tome da atribut može da sadrži dve činjenice, već da postoje dva atributa koji govore o početku i završetku rada. Stoga je potrebno da se ugrade dva atributa koji nose dve različite informacije.
Zadovoljavanje modela
U oba primera rešenja ne zadovoljavaju 1NF. Menjajući strukturu, sasvim sigurno, jedan se atribut pojavljuje samo jednom u entitetu i nosi samo jednu činjenicu. Dakle, 1NF je ispunjena ako svaki od atributa entiteta ima jedno značenje i ne više od jedne vrednosti za svaki primerak. Ako je sigumo da svi entiteti i atributi ne nose više činjenica, model zadovoljava 1NF.
Ovi elementi su ugrađeni i u ERwin CASE alatu koji prihvata bilo koje ime za definiciju entitetat ili atribut, ali postoje ograničenja:
-
ERwin će obavestiti o ponovnom korišćenju imena entiteta, zavisno od postavke opcije o jedinstvenom imenu,
-
ERwin će obavestiti o ponovnom korišćenju imena atributa, osim ako je to ime uloge (Rolename),
-
Erwin neće dozvoliti ulazak prenešenih ključeva u entitet više nego jednom.
Sprečavajući da se višestruko koristi isto ime, ERwin vodi korisnika da svaki podatak smesti tačno na jedno mesto.
Druga normalna forma (2NF)
Definicija druge normalne forme je sledeća:
Entitet A zadovoljava drugu normalnu formu ako zadovoljava prvu i ako svaki atribut koji nije ključ potpuno zavisi od primarnog ključa.
Za opis ove definicije poslužiće primer višestrukog pojavljivanja istih činjenica. Ako bi se na primeru u entitet ISPLATA stavio atribut ‘Datum zaposl.’, može se uočiti da ovaj atribut zavisi od dela ključa entiteta ISPLATA (Sifra osobe), a ne od celog ključa entiteta ISPLATA.
Da bi se zadovoljila 2NF potrebno je prebaciti atribut ‘Datum zaposl.’ u entitet OSOBA. Dakle, entitet krši 2NF ako podatak može biti pronađen kada se zna samo deo ključa entiteta.
Može da nastane greška druge normalne forme ako se postavi neki atribut nekorektno, a ne postoji algoritam koji bi bez dodatnih informacija, pored onih u modelu, otkrio grešku. U entitetnom dijagramu Erwin ne može znati da ime koje je dodeljeno atributu može predstavljati listu objekata.
Treća normalna forma (3NF)
Definicija treće normalne forme je sledeća:
Entitet zadovoljava treću normalnu formu ako svaki atribut koji nije ključ zavisi od ključa, čitavog ključa i ne služi ničemu drugom osim ključa.
Na primer, bila bi povređena treća normalna forma ako se u entitet ISPLATA ugradi atribut ‘Suma isplata’. ‘Suma isplata’ zavisi od atributa ‘Isplata’ i može se izračunati.
Pored ovih formi postoje i četvrta i peta i Boyce-Codd-ova forma, a njihova upotreba zavisi od skupa transakcija koje treba izvršiti. Ovde se neće razmatrati. Mora se naglasiti da iskusni projektanti već razmišljaju u 3NF.
