Professional Documents
Culture Documents
Baze Podataka: S - Id S - Ime S - Adresa S - Predmet 401 402 403 404
Baze Podataka: S - Id S - Ime S - Adresa S - Predmet 401 402 403 404
Dražana Gašpar
Daniel Vasić, asistent
BAZE PODATAKA
Normalizacija tablica
Bez normalizacije postaje jako teško upravljati bazom podataka bez gubitka podataka. Umetanje
uređivanje i brisanje podataka su jako česti ako baza nije normalizovana, samim time se smanjuju
pereformanse sustava. Da bismo shvatili te anomalije pogledati ćemo primjer tablice student.
Anomalija uređivanja: da bismo uredili adresu studenta koji se ponavljuju više od dva puta moramo
urediti svaku adresu koja se nalazi u koloni S_Adresa, inače će podatci biti nekonzistentni.
Anomalija umetanja: Da bismo unjeli novi podatak trebamo imati sve podatke, da bismo recimo
unjeli novog studenta koji još nije odabrao niti jedan predmet trebali bismo postaviti u kolonu
S_Predmet moramo postaviti na NULL vrijednost što opet dovodi do inkonzistentnosti podataka.
Anomalija brisanja: Ako pobrišemo pojedini predmet koji student želi ispisati moramo pobrisati i
samog studenta.
Pravila normalizacije:
Red nemože sadržavati ponavljajuću grupu podataka. Svaka kolona mora imati jedunstvenu vrijednost
i svaki redak mora imati jedinstveni identifikator, to ćemo primjeniti na tablici te dobijamo sljedeču
tablicu.
Očito je vidljivo da osoba Marko je osoba koja se ponavlja što nam narušava prvu formu te također
Matematika nam se isto ponavlja dva puta. Što znači da bismo zadovoljili 1NF moramo razdvojiti ovu
tablicu na 2 tablice Student i Predmet.
Baze podataka Prof. Dr. Sc. Dražana Gašpar
Daniel Vasić, asistent
Druga normalna forma podrazumjeva da je tablica u 1NF te da nijedan atribut nije djelomično ovisan
o primarnom ključu. U tom kontekstu možemo reći da ako tablica koja ima složeni primarni ključ od
dva atributa. Ako su neki atributi ovisni samo o jednom ključu tada pada na 2NF.
Ovo je primjer tablice koja poštiva pravila prve normalne forme ali ne i druge normalne forme jer
vrijednost Detalji_prodaje nije funkcijski ovisna o ključu. Klijent_ime je ovisan o Klijent_id, a
Naziv_narudžbe je ovisan o Narudžba_id ključu, ali ne postoji jasna veza između Detalja_prodaje i
Ime_klijenta tj. Imamo parcijalnu vezu između tih atributa što prema drugoj normalnoj formi nemože
biti.
Da bismo riješili taj problem moramo navedenu tablicu razviti u više pod tabela. Prvo ćemo odvojiti
tablicu klijenta:
Nakon toga drugi korak je da tablicu narudžbe odvojimo od ove tablice te u skladu sa time dobijamo
sljedeće:
Narudzba_id Naziv_narudžbe
10 Narudzba1
11 Narudzba2
12 Narudzba3
13 Narudzba4
Zadnje je da formiramo tablicu u kojem su atributi međusobno ovisni o primarnom ključu, u ovom
slučaju složenom primarnom ključu, te na osnovu toga dobijamo:
Treća normalna forma nam kaže da svaki neprimarni atribut mora funkcionalno biti ovisan o
primarnom ključu uzmimo za primjer sljedeću hipotetsku situaciju:
U ovoj tablici student_id je primarni ključ, ai grad i država ovise o Zip kodu. Ova ovisnost između ZIP
koda i drugih polja naziva se tranzitivna ovisnost. Da bismo primjenili 3NF moramo pomjeriti Adresu,
Grad, Državu u novu tabelu gdje je ZIP primarni ključ.
Boyce-Codd normalna forma je viša verzija treće normalne forme u kojoj se javlja anomalija koja se
ne dotiče 3NF a to je da tablica u 3NF mogu imati više kandidat ključeva. Tablica koja nema više
ovakvih ključeva nalazi se u BCNF.