Transcript Pred-BAZE5-2011-12

INTEGRITET U RELACIJSKOM MODELU
• Integritet, konzistencija i osiguranje odnosno zaštita podataka
po svom značenju su međusobno srodni
• Pod integritetom baze podataka podrazumjevamo ispravnost i
istinitost informacija, odnosno podataka sadržanih u bazi
• Zajednička karakteristika svih integritetskih ograničenja jest
činjenica da svaki podatak koji nije u skladu s nekim od pravila
sigurno nije istinit
Napomena: Glavna literatura za ovo područje je: Mladen Varga, Baze podataka: konceptualno, logičko
1
i fizičko modeliranje podataka, DRIP, Zagreb, 1994.
INTEGRITET U RELACIJSKOM MODELU
• Baza podataka, da bi bila upotrebljiva, mora sadržati
semantički konzistentne podatke.
• Uvjeti koji određuju jesu li podaci konzistentni zovu se
ograničenja.
• Svaka promjena podataka u bazi podataka koja nije učinjena u
skladu sa zadanim ograničenjima dovodi do pojave
nekonzistentnih (nepouzdanih i/ili netočnih) podataka.
2
INTEGRITET U RELACIJSKOM MODELU
Ograničenja koja se mogu definirati su:
• jedinstvenost vrijednosti, ne smiju postojati dvije
n-torke koje imaju iste vrijednosti određenog atributa (ili skupa
atributa),
• ne
nul-vrijednost,
atribut
ne
smije
poprimiti
nul-vrijednost (minimalna kardinalnost atributa jest 1),
• referencijalni integritet, vrijednost jednog atributa (strani
ključ) je nul-vrijednost ili je jednaka vrijednosti drugog atributa
stanovite n-torke druge ili iste relacije (primarni ključ),
• ograničenje uz kontrolu (check constraint), određeni uvjet
mora biti ispunjen za sve n-torke relacije; široko ograničenje kojim
se može npr. odrediti domena vrijednosti atributa, propisati da vrijedi
određeni odnos vrijednosti različitih atributa itd.
3
INTEGRITET U RELACIJSKOM MODELU
• Entitetski integritet je kombinacija ograničenja jedinstvenosti i
ne-nulvrijednosti. Definira ograničenje ključa i jamči
jednoznačno identificiranje bilo koje n-torke u bazi podataka.
• Referencijalni integritet ima veliku važnost za konzistentnost
baze podataka. Povezuje pojam primarnog ključa sa stranim
ključem.
• Definicija ref. integriteta (Tkalac, 1993):
Ako u relaciji R postoji strani ključ koji odgovara
primarnom ključu relacije S, svaka vrijednost stranog
ključa u relaciji R mora biti jednaka vrijednosti primarnog
ključa u nekoj n-torki relacije S ili jednaka nul-vrijednosti
(R i S mogu biti ista relacija).
4
INTEGRITET U RELACIJSKOM MODELU
• Referencijalni integritet je održan ako svaki strani ključ
pronalazi primarni ključ s istom vrijednosti.
• Strani ključ uspostavlja odnos n-torki dviju relacija što
odgovara binarnoj vezi u modelu entiteti-veze.
5
INTEGRITET U RELACIJSKOM MODELU
Primjer: Relacijska baza podataka PARTNER_TRGOVAC definirana je
relacijskom shemom:
PARTNER (PARTNER_SIFRA, PARTNER_NAZIV,
PARTNER_ADRESA, MB)
TRGOVAC(MB, IME_PREZIME,DATUM_RODJENJA, MB_VG,
PLACA, DODATAK)
Svaki trgovac radi s nijednim, jednim ili više partnera. Svaki partner
pripada jednom i samo jednom trgovcu. Trgovci su organizirani u grupe,
svaki radi u okviru jedne grupe. Nije predviđeno da se za grupu vode
posebni podaci. Svaki trgovac može biti voditelj jednom ili više
trgovaca u grupi, te mora imati jednog i samo jednog voditelja grupe.
Napomena: Primarni ključevi označeni su crvenom bojom, a strani ključ
plavom bojom.
6
PARTNER
PARTNER_SIFRA
PARTNER_NAZIV
PARTNER_ADRESA
MB
10
Zagreb d.o.o.
Zagreb
3
20
Horizont d.d.
Sesvete
5
30
Josip Ferić
D. Selo
11
40
A-banka d.d.
Zagreb
?
60
Brzopromet
Zagreb
1
70
Vicko Stić
Split
9
75
Kompakt d.o.o.
Osijek
5
80
Hotel F
Rijeka
9
90
Amalija d.d.
Pula
9
TRGOVAC
U MS Accessu godina se piše bez točke na kraju.
MB
IME_PREZIME DATUM_RODJENJA
MB_VG
PLACA
DODATAK
1
Ivan Perić
26.11.1948
1
120
0
3
Ana Horvat
19.03.1952
11
110
10
5
Josip Antić
13.09.1959
1
80
30
9
Ante Ivić
06.05.1962
1
100
45
11
Maja Markić
01.12.1939
11
120
0
7
INTEGRITET U RELACIJSKOM MODELU
U relacijskoj bazi podataka PARTNER_TRGOVAC relacije PARTNER
i TRGOVAC povezane su stranim ključem. Atribut MB u relaciji
PARTNER strani je ključ koji odgovara primarnom ključu MB u relaciji
TRGOVAC, a govori da partner ima trgovca s kojim radi.
Referencijalni integritet održan je ako svaka vrijednost stranog
ključa pronalazi primarni ključ s istom vrijednosti. Ako ne,
integritet je narušen.
Npr. partner ne može raditi s trgovcem 22 (strani ključ MB u relaciji
PARTNER ima vrijednost 22), ako trgovac 22 ne postoji (n-torka u
relaciji TRGOVAC čiji primarni ključ PARTNER_SIFRA ima
vrijednost 22).
Strani ključ se može referencirati na primarni ključ u istoj relaciji.
Npr. strani ključ MB_VG u relaciji TRGOVAC koji odgovara
primarnom ključu u istoj relaciji govori da TRGOVAC ima voditelja
grupe koji je također trgovac.
8
INTEGRITET U RELACIJSKOM MODELU
Održavanje refererencijalnog integriteta nije jednostavno. Npr., što
učiniti s podatkom trgovca u relaciji PARTNER, ako se briše njegova
n-torka u relaciji TRGOVAC, remeteći time referencijalni integritet?
Moguće akcije propisane su pravilima održavanja stranog
ključa:
• odbijanje, operacija se ne obavlja sve dok postoji i jedna
n-torka koja ima strani ključ s istom vrijednošću,
• kaskadno brisanje, briše se (mijenja se) n-torka s primarnim
ključem i sve n-torke koje imaju strani ključ s istom
vrijednošću,
• nuliranje, briše se (mijenja se) n-torka s primarnim ključem, a
svi strani ključevi s istom vrijednošću postavljaju se na nulvrijednost ili na početnu vrijednost (default).
9
INTEGRITET U RELACIJSKOM MODELU
Pravila održavanja stranog ključa za operaciju promjene primarnog
ključa daju iste tri mogućnosti. Operacija se odbija, obavlja kaskadno
(promjena se radi na primarnom i na svim stranim ključevima) ili se
obavlja nuliranje (postavljanje na nul-vrijednost ili na početnu
vrijednost).
Kod operacije unošenja n-torke sa stranim ključem operacija se odbija
ako ne postoji n-torka koja ima primarni ključ s istom vrijednošću.
10
INTEGRITET U RELACIJSKOM MODELU
Ograničenja u MS Accessu :
Tablica u pogledu Design View – polje Field Properties.
Veze: prozor Relationships…
U ovom prozoru određujete veze između tablica. Access
omogućuje jednostavno povezivanje tablica upotrebom grafičkog
sučelja.
11
INTEGRITET U RELACIJSKOM MODELU
Veze:
Veze među tablicama se uspostavljaju pomoću miša Drag and Drop
tehnikom, a njihova svojstva se uređuju preko opcije Edit Relationship….
12
Karakteristike veze jedan-prema-jedan
Svaki zapis prve tablice odgovara točno jednom zapisu druge
tablice i obrnuto. Takve veze su rijetke.
Postoje dva razloga za takvu vezu:
1) sigurnost - da se neki podaci zaštite od pristupa
2) brzina - ako tablica ima mnogo stupaca od kojih se samo
nekoliko često koristi za upite onda je bolje te stupce držati
posebno.
Nedostatak: potrebno je nadzirati tablice kako bi ostale
sinhronizirane.
Entiteti povezani vezom 1:1 se mogu modelirati u jednu
tablicu bez uzrokovanja redudancije.
13
Karakteristike veze jedan-prema-više
Jedan zapis prve tablice (naziva se "roditelj") odgovara
nekoliko zapisa druge tablice (naziva se "dijete"). Ponekad se
navodi i veza M:1, ali je to samo obrnuto gledana veza 1:M.
Povezivanje se vrši preko ključnih polja (primarnih
ključeva). Nastoji se davati iste nazive tim poljima u obje
tablice, ali nije nužno.
Modeliranje dva entiteta povezana vezom 1:M u jednu
tablicu dovodi do redudancije.
14
Karakteristike veze više-prema-više
Ovdje se zapis iz jedne tablice može povezati s više zapisa iz
druge tablice i obrnuto.
Da bi se podržavala veza M:N između entiteta A i B moramo
stvoriti tri tablice:
a) Tablica A koja odgovara entitetu A
b) Tablica B koja odgovara entitetu B
c) Treća tablica za podržavanje veze između ova dva entiteta
15
NORMALIZACIJA
16
NORMALIZACIJA
Dobro oblikovana relacijska baza podataka predstavlja skup
podataka koji:
• nije redundantan (nema zalihosti),
• posjeduje semantički integritet, tj. ne pokazuje anomalije
pri unosu, brisanju ili promjeni podataka, odnosno
jednostavno se koristi.
Redundancija (zalihost) govori da se istovrsni podatak
memorira na više mjesta. To se smatra nedostatkom, jer se
obrada redundantnih podataka, bilo unos, brisanje ili
promjena, mora istovremeno obaviti na više mjesta.
Posljedično se javljaju anomalije pri unosu, brisanju i
promjeni podataka.
17
NORMALIZACIJA
Zbog moguće nekonzistentnosti istog podatka, koji se
memorira više puta, mogu se pojaviti i neispravni odgovori
na zadani upit.
Zašto normalizirati?
Dobro strukturirane relacije sadržavaju minimum
redudancije (dupliciranja podataka). Redudancija je
općenito uzalud potrošen prostor. Možete misliti da s
današnjim velikim diskovima to nije neki problem, ali
velika baza je spora. U pravilu, baza podataka u normalnoj
formi daje fleksibilnije opcije za upite. Nažalost, to se
primjeti tek kada je potrebno dodati nešto novo u aplikaciju
koja se služi bazom, a to se često događa tek mjesecima
nakon što je baza puštena u upotrebu.
18
NORMALIZACIJA
Razlozi zbog kojih se može odustati od normalizacije
Za većinu praktičnih primjena dovoljno je relacije
normalizirati do 3NF (treće normalne forme).
Ponekad je potrebno neku relaciju i dalje normalizirati do
BCNF (Boyce-Coddove normalne forme) ili 4NF, dok 5NF
koja se navodi u literaturi nije od praktičnog značaja.
Postoje razlozi zbog koji se iznimno može odustati od
potpune normalizacije. Navesti ćemo dva takva razloga.
19
NORMALIZACIJA
Razlozi zbog kojih se može odustati od normalizacije
1. Složeni atribut – nekoliko atributa u relaciji čine cjelinu
koja se u praksi nikad ne rastavlja na sastavne dijelove. Npr.
KUPAC(Prezime_i_ime, Poštanski_broj, Grad, Ulica).
Strogo govoreći, atribut Grad je funkcionalno ovisan o
atributu Poštanski_broj, pa relacija nije u 3NF. No, mi
znamo da Poštanski_broj, Grad i Ulica čine cjelinu koju
zovemo adresa. Budući se podaci iz adrese koriste i
ažuriraju "u paketu", ne može doći do ranije spominjanih
anomalija te nije preporučljivo rastavljati ovu relaciju na
dvije.
20
NORMALIZACIJA
Razlozi zbog kojih se može odustati od normalizacije
2. Djelotvorno čitanje podataka
Normalizacijom se velike relacije rastavljaju na mnogo
manjih. Pri čitanju često je potrebno podatke iz malih
relacija ponovo sastaviti u veće n-torke. Uspostavljanje veza
među podacima u manjim relacijama traje znatno dulje nego
čitanje podataka koji su već povezani i upisani u jednu
veliku relaciju.
21
NORMALIZACIJA
Zašto ne normalizirati?
Unos podataka postaje sve složeniji što je više tablica.
Ponekad je prednost ako dozvolimo malo redudancije jer je
uzimanje podataka iz više tablica sporije nego iz jedne
tablice. To je moguće ako se tablice ne mijenjaju često, ali
dobivaju složene upite. Ponekad se redudancija planira u
"skladištima podataka" (DataWarehouse).
Primjer lošeg semantičkog integriteta prikazan je na relaciji
PARTNER_TRGOVAC prikazanoj na sljedećem slajdu. Relacija
je rezultat vanjskog spajanja relacija PARTNER i TRGOVAC
(ranije obrađeno!). Pritom je zbog jednostavnosti izbačen atribut
MB_VG.
22
NORMALIZACIJA
PARTNER
_SIFRA
PARTNER_
NAZIV
PARTNER
_ADRESA
MB
IME_
PREZIME
DATUM_
PLA
RODJENJA CA
DODA
TAK
10
Zagreb d.o.o.
Zagreb
3
Ana Horvat
19.03.1952
110
10
20
Horizont d.d.
Sesvete
5
Josip Antić
13.09.1959
80
30
30
Josip Ferić
D. Selo
11
Maja Markić
01.12.1939
120
0
40
A-banka d.d.
Zagreb
?
?
?
?
?
60
Brzopromet
Zagreb
1
Ivan Perić
26.11.1948
120
0
70
Vicko Stić
Split
9
Ante Ivić
06.05.1962
100
45
75
Kompakt d.o.o.
Osijek
5
Josip Antić
13.09.1959
80
30
80
Hotel F
Rijeka
9
Ante Ivić
06.05.1962
100
45
90
Amalija d.d.
Pula
9
Ante Ivić
06.05.1962
100
45
23
NORMALIZACIJA
U prikazanoj relaciji anomalija unosa znači nemogućnost unosa
podataka novog trgovca sve dok se istovremeno ne unesu podaci
partnera s kojim radi.
Anomalija brisanja vezana je uz mogućnost potpunog gubljenja
podataka određenog trgovca ako se izbriše n-torka partnera s
kojim radi. Slično se događa s nekim partnerima ako se izbrišu
n-torke jednog trgovca.
Anomalija promjene znači otežanu promjenu podataka, koja se
mora istovremeno obaviti na više mjesta. Ako se mijenjaju podaci
trgovca, npr. njegova plaća, te se promjene moraju učiniti na više
mjesta, u svim n-torkama partnera s kojima trgovac radi. Propusti
li se načiniti promjena u svim n-torkama, podaci trgovca su
nekonzistentni, jer isti trgovac može imati različite podatke o
plaći.
24
NORMALIZACIJA
Dobro oblikovana relacijska baza podataka treba biti u
prikladnoj normalnoj formi. Normalne forme definiraju
ograničenja podataka u relacijama. Time se jamči
konzistentnost relacija i njihovo jednostavno korištenje, a
izbjegavaju moguće anomalije pri unosu, brisanju ili promjeni.
Normalna forma definira se na relacijskoj shemi, a primjenjuje
na relaciji koju shema opisuje. Normalna forma može se
proširiti na čitavu relacijsku shemu baze podataka.
Postoji 6 normalnih formi.
Svaka od njih je jača od prethodne. Tako je npr. tablica u trećoj
normalnoj formi (3NF) i u drugoj normalnoj formi (2NF).
25
NORMALIZACIJA
Redoslijed formi od nižih (blažih) prema višim (strožim)
formama:
• Prva normalna forma (1NF),
• Druga normalna forma (2NF),
• Treća normalna forma (3NF),
• Boyce-Coddova normalna forma (BCNF),
• Četvrta normalna forma (4NF),
• Peta normalna forma (5NF).
Ponekad ćete naći podatak i da postoji nulta normalna forma.
Relacija je u nultoj normalnoj formi ako ima jedinstven primarni
ključ, no nije potrebno posebno isticati tu formu zato što je
primarni ključ po definiciji jedinstven i relacija ga mora imati.
26
NORMALIZACIJA
Ograničenja pomoću kojih se definiraju normalne forme:
• funkcijska zavisnost,
• višeznačna zavisnost i
• spojna zavisnost (zavisnost spajanja).
Normalizacija je postupak prevođenja jedne ili skupa relacija iz
niže u višu normalnu formu. Pritom se služi operacijama
projekcije i prirodnog spajanja.
27
NORMALIZACIJA
Funkcijska zavisnost
Pojam funkcijske zavisnosti se koristi za definiranje normalnih
formi.
Definicija:
Ako su X i Y skupovi atributa relacije R, relacija R zadovoljava
uvjete funkcijske zavisnosti XY ako u svakom trenutku za
svaku X-vrijednost x postoji samo jedna Y-vrijednost y.
Primjeri:
Npr. Svaki poslovni partner ima samo jednu adresu.
PARTNER_SIFRAPARTNER_ADRESA
28
NORMALIZACIJA
IZDAVACI
IzdavacID
IzdavacNaziv
1234
Znak
Npr. za tablicu IZDAVACI, IzdavacNaziv potpuno zavisi o
IzdavacID atributu.
Pišemo: IzdavacIDIzdavacNaziv
To se može čitati:
"IzdavacID određuje IzdavacNaziv"
ili:
"IzdavacNaziv zavisi o IzdavacID".
29
NORMALIZACIJA
Općenito, pretpostavimo da su {A1, … ,Ak} atributi sheme
relacije, a {B1, … ,Bn} također atributi te iste relacije. (B-ovi ne
moraju biti različiti od A-ova).
Tada atributi B1, … ,Bn zavise o atributima A1, … ,Ak i pišemo:
{A1, … ,Ak} {B1, … ,Bn}
ako vrijednosti A1, … ,Ak potpuno određuju vrijednosti B1, … ,Bn.
Atributi s lijeve strane potpuno određuju atribute s desne strane:
"sada i za sva vremena bez obzira koje podatke ćemo dodavati u
bazu podataka".
30
NORMALIZACIJA
Sažetak dekompozicije
Normalizacija relacije je postupak prevođenja relacije iz niže u višu
normalnu formu. Ona se obavlja dekompozicijom, rastavljanjem
relacije na dvije ili više relacija u višoj normalnoj formi. Dekompozicija
se provodi sve dok se ne dobije skup relacija u traženoj normalnoj
formi.
Dekompozicija relacije R zamjena je relacije R s dvije relacije R1 i R2,
koje mogu imati zajedničke atribute R1.X i R2.X. Ako
SPOJ(PROJEKCIJA(R,R1),PROJEKCIJA(R,R2),R1.X*R2.X)=R,
relacija R je dekomponirana bez gubitka informacija, odnosno
dekompozicija je pouzdana (reverzibilna).
Kad se relacije dobivene prirodnom dekompozicijom prirodno spoje,
dobiva se polazna relacija. To govori da je dekompozicija pouzdana.
Dekompozicija je pouzdana ako je presjek skupova atributa relacija R1
i R2 ključ u R1 ili R2.
dodatne informacije – knjiga M. Varga
31
NORMALIZACIJA
Prva normalna forma
1NF
Relacija se nalazi u 1NF ako su vrijednosti atributa nedjeljive.
Svaki njezin atribut je atomaran, tj. sadrži samo jednu
vrijednost, nikako više vrijednosti.
ISBN: 0-55-123456-9
Naslov: Main Street
Autori: Jones, Smith
Izdavač: Algoritam
ISBN
Naslov
Autori
Izdavač
0-55-123456-9
Main Street
Jones, Smith
Algoritam
Kako shema relacije dozvoljava više od jednog autora za atribut
Autori, ova relacija nije u 1NF.
32
NORMALIZACIJA
Prva normalna forma
Očito je nemoguće sortirati podatke po prezimenu autora.
Atributi koji sadrže samo jednu vrijednost (dozvoljavaju nedjeljive
vrijednosti) zovu se skalarni atributi ili atomarni atributi.
Atributi čije vrijednosti mogu biti, npr. popis vrijednosti (kao
popis autora) se zovu strukturirani atributi.
Dakle, relacija je u 1NF ako je svaki njezin atribut atomaran.
33
NORMALIZACIJA
Prva normalna forma
Općenito, prilagodbe koje su potrebne za osiguranje prve normalne
forme nisu teške i 1NF je dobro opće pravilo. Međutim, kao i s
drugim normalnim formama, svaka situacija se mora posebno
proučiti (posebno kako se ide prema višim normalnim formama).
Tako npr. jedno polje može sadržavati adresu: "Bruna Bušića 55".
Hoće li kućni broj i naziv ulice biti razdvojeni u različite atribute,
to je stvar konteksta. Drugim riječima, je li adresa atomarna ili ne
ovisi o kontekstu.
Ako postoji razlog za postupanje s kućnim brojevima odvojeno od
naziva ulice, onda bi sigurno morali biti odvojeni. Inače, možda ne.
Svaka sljedeća normalna forma mora zadovoljavati 1NF.
34
NORMALIZACIJA
Prva normalna forma
Nepoštivanje prve normalne forme je često kod ljudi koji nauče
alat (npr. Access), a ne znaju ništa o oblikovanju baza podataka, pa
rade tablice kao u Excelu. Kako to prepoznati?
Zahvaljujući izjavama:
• Program ne dopušta da itko upiše više od 10 predmeta.
• Na jednom računu može biti najviše 15 stavki.
• Naš radnik može imati najviše petero djece.
• Uz jednu osobu ne može biti vezano više od 3 telefona.
• Ne mogu pronaći stavku na Vašoj narudžbi ako mi ne kažete koja
je po redu.
35
NORMALIZACIJA
Druga normalna forma
2NF
Relacija se nalazi u 2NF ako su svi neključni atributi
potpuno funkcijski zavisni o bilo kojem ključu relacije.
Drugim riječima, relacija (ili tablica) je u 2NF ako svi strogo
informacijski atributi (atributi koji ne pripadaju ni jednom
ključu) entiteta relacije daju informacije upravo o tom
entitetu, a ne o nekom drugom.
Primjer: tablica s podacima o kućnim adresama
(Grad, Ulica, Broj, BrojStanovnikaGrada)
BrojStanovnikaGrada očito ne pripada ovdje jer je to atribut
gradova, a ne kućnih adresa.
36
NORMALIZACIJA
Treća normalna forma
3NF
Relacija se nalazi u 3NF ako ako ni jedan neključni atribut
nije tranzitivno zavisan o bilo kojem ključu relacije.
Svaki neključni atribut mora zavisiti o ključu, cijelom ključu
i ni o čemu osim ključu.
Npr. pretpostavimo zbog ilustracije da dvije knjige istog naslova
nemaju istog izdavača.
{Naslov, IzdavacID, BrojStranica, Cijena}
Jedini ključ
Informacijski atributi
Pretpostavimo da izdavač određuje cijenu knjige samo prema broju
stranica. Najprije, primijetimo da je ova tablica u 2NF.
37
NORMALIZACIJA
Treća normalna forma
Cijena zavisi o BrojStranica, a također i o IzdavacID (pravom
podskupu ključa) zato što svaki izdavač može odrediti svoj način
davanja cijene.
3NF ne dozvoljava da ni jedan strogo informacijski
atribut zavisi o bilo čemu drugom osim primarnog ključa.
38
Primjeri normalnih formi
39
Prva normalna forma
Relacija se nalazi u prvoj normalnoj formi (1NF) ako su svi
neključni atributi funkcijski zavisni o (primarnom) ključu
relacije.
Nema ponavljajućih atributa (domena) ili grupa atributa.
1NF razmatra dvije stvari:
1. svaki redak tablice ne smije sadržavati ponavljajuće
grupe (atribute) sličnih podataka (atomarnost)
2. svaki redak tablice mora imati primarni ključ
(jedinstveni identifikator).
40
TRGOVAC_PARTNER_0 (0NF)
MB
IME_PREZIME
ODJEL_BROJ
ODJEL_NAZIV
PARTNER_NAZIV
3
Ana Horvat
P1
O-Zagreb
Zagreb d.o.o.
Horizont d.d.
5
Josip Antić
P2
O-Osijek
Horizont d.d.
Kompakt d.o.o.
9
Ante Ivić
P3
O-Split
Vicko Stić
Hotel F
Amalija d.d.
11
Maja Markić
P1
O-Zagreb
Josip Ferić
Brzopromet
?
?
?
?
A-banka d.d.
Shema tablice TRGOVAC_PARTNER_0 (MB, IME_PREZIME, ODJEL_NAZIV,
PARTNER_NAZIV) znači "trgovac s matičnim brojem, imenom i prezimenom,
zaposlen u odjelu s brojem i nazivom odjela, radi s partnerom". Iz podataka u tablici
vidi se npr. da trgovac Josip Antić radi s poslovnim partnerima Horizont i Kompakt, a
da s A-bankom ne radi ni jedan trgovac (? označava nul-vrijednost).
41
TRGOVAC_PARTNER_1 (1NF)
MB
IME_PREZIME
ODJEL_BROJ
ODJEL_NAZIV
PARTNER_NAZIV
3
Ana Horvat
P1
O-Zagreb
Zagreb d.o.o.
3
Ana Horvat
P1
O-Zagreb
Horizont d.d.
5
Josip Antić
P2
O-Osijek
Horizont d.d.
5
Josip Antić
P2
O-Osijek
Kompakt d.o.o.
9
Ante Ivić
P3
O-Split
Vicko Stić
9
Ante Ivić
P3
O-Split
Hotel F
9
Ante Ivić
P3
O-Split
Amalija d.d.
11
Maja Markić
P1
O-Zagreb
Josip Ferić
11
Maja Markić
P1
O-Zagreb
Brzopromet
?
?
?
?
A-banka d.d.
Relacija TRGOVAC_PARTNER_1 je u 1NF i dobila se jednostavnim dodavanjem
n-torki kod neatomarnih atributa u relaciji TRGOVAC_PARTNER_0.
Vidi se da je velika redundancija TRGOVAC_PARTNER_1 i pojavljuju se anomalije
unosa, brisanja i promjene podataka.
42
TRGOVAC_PARTNER_1 (1NF)
MB
IME_PREZIME
ODJEL_BROJ
ODJEL_NAZIV
PARTNER_NAZIV
3
Ana Horvat
P1
O-Zagreb
Zagreb d.o.o.
3
Ana Horvat
P1
O-Zagreb
Horizont d.d.
5
Josip Antić
P2
O-Osijek
Horizont d.d.
5
Josip Antić
P2
O-Osijek
Kompakt d.o.o.
9
Ante Ivić
P3
O-Split
Vicko Stić
9
Ante Ivić
P3
O-Split
Hotel F
9
Ante Ivić
P3
O-Split
Amalija d.d.
11
Maja Markić
P1
O-Zagreb
Josip Ferić
11
Maja Markić
P1
O-Zagreb
Brzopromet
?
?
?
?
A-banka d.d.
Uzrok redundancije: ključ relacije je sastavljen od atributa MB i PARTNER_NAZIV.
Pritom atributi IME_PREZIME, ODJEL_BROJ i ODJEL_NAZIV nisu zavisni o
cijelom ključu, nego samo o njegovom dijelu, točnije atributu MB.
Taj problem rješava sljedeća, tj. druga normalna forma (2NF).
43
1NF – Primjer ponavljajućih atributa ili grupa atributa
- potrebno je eliminirati istovjetne stupce iz iste tablice
- u istom retku tablice ne smiju se ponavljati podaci
Primjer: Svaki trgovac (ključ mu je MB) radi s nijednim, jednim ili
više partnera. Svaki partner pripada jednom i samo jednom trgovcu.
U početku bi nenormalizirana tablica izgledala ovako:
višestruki stupci (ponavljajuća grupa atributa)
MB
IME_PREZIME
PARTNER1
PARTNER2
PARTNER3
3
Ana Horvat
Zagreb d.o.o.
Horizont d.d.
?
9
Ante Ivić
Vicko Stić
Hotel F
Amalija d.d.
11
Maja Markić
Josip Ferić
Brzopromet
?
?
?
A-banka d.d.
?
?
44
1NF – Primjer ponavljajućih atributa ili grupa atributa
višestruki stupci (ponavljajuća grupa atributa)
MB
IME_PREZIME
PARTNER1
PARTNER2
PARTNER3
3
Ana Horvat
Zagreb d.o.o.
Horizont d.d.
?
9
Ante Ivić
Vicko Stić
Hotel F
Amalija d.d.
11
Maja Markić
Josip Ferić
Brzopromet
?
?
?
A-banka d.d.
?
?
1NF eliminira višestruke stupce iz iste tablice.
Stupci PARTNER1, PARTNER2 i PARTNER3 se nepotrebno
ponavljaju. Ana Horvat i Maja Markić imaju dva partnera. Stupac
PARTNER3 im je suvišan (nepotrebno zauzimanje prostora).
Maja Markić ima 3 partnera. Što ako dobije još jednog partnera? Bit će
potrebna modifikacija.
45
1NF – Primjer ponavljajućih atributa ili grupa atributa
To možemo riješiti jednim stupcem (atributom) za partnere.
MB
IME_PREZIME
PARTNER
3
Ana Horvat
Zagreb d.o.o., Horizont d.d.
9
Ante Ivić
Vicko Stić, Hotel F, Amalija d.d.
11
Maja Markić
Josip Ferić, Brzopromet
?
?
A-banka d.d.
Ali, javlja se problem. Atribut PARTNER nije atomaran, tj. ima
višestruke vrijednosti, pa predložena relacija (tablica) nije u 1NF.
46
1NF – Primjer ponavljajućih atributa ili grupa atributa
Rješenje: Tablica koja zadovoljava 1NF. (TRG_PART)
Primjetite da se primarni ključ sastoji od atributa MB i PARTNER.
TRG_PART (1NF)
MB IME_PREZIME
PARTNER
3
Ana Horvat
Zagreb d.o.o.
3
Ana Horvat
Horizont d.d.
9
Ante Ivić
Vicko Stić
9
Ante Ivić
Hotel F
9
Ante Ivić
Amalija d.d.
11
Maja Markić
Josip Ferić
11
Maja Markić
Brzopromet
?
?
A-banka d.d.
47
Druga normalna forma
2NF govori da svi neključni atributi moraju u potpunosti
funkcijski zavisiti o čitavom (složenom) primarnom ključu,
a ne samo o njegovom dijelu.
Prilikom pretvorbe relacije iz 1NF u 2NF izdvajaju se atributi
koji djelomično zavise o ključu, zajedno s dijelom ključa o
kojem zavise, u novu relaciju.
U preostaloj relaciji ostaje kompletan ključ i atributi koji
funkcijski potpuno zavise o ključu.
2NF odnosi se samo na relacije sa složenim primarnim
ključem. Ako relacija ima jednostavan primarni ključ, onda
ona zadovoljava 2NF (naravno, ukoliko je prije toga
zadovoljila 1NF).
48
TRGOVAC_PARTNER_1 (1NF)
MB
IME_PREZIME
ODJEL_BROJ
ODJEL_NAZIV
PARTNER_NAZIV
3
Ana Horvat
P1
O-Zagreb
Zagreb d.o.o.
3
Ana Horvat
P1
O-Zagreb
Horizont d.d.
5
Josip Antić
P2
O-Osijek
Horizont d.d.
5
Josip Antić
P2
O-Osijek
Kompakt d.o.o.
9
Ante Ivić
P3
O-Split
Vicko Stić
9
Ante Ivić
P3
O-Split
Hotel F
9
Ante Ivić
P3
O-Split
Amalija d.d.
11
Maja Markić
P1
O-Zagreb
Josip Ferić
11
Maja Markić
P1
O-Zagreb
Brzopromet
?
?
?
?
A-banka d.d.
Relacija TRGOVAC_PARTNER_1 (1NF) nije u 2NF. Ključ relacije je sastavljen od
atributa MB i PARTNER_NAZIV. Pritom atributi IME_PREZIME, ODJEL_BROJ i
ODJEL_NAZIV nisu zavisni o cijelom ključu, nego samo o njegovom dijelu, točnije
atributu MB. Taj problem rješava druga normalna forma (2NF).
49
Druga normalna forma
Relacija TRGOVAC_PARTNER_1 (1NF) nije u 2NF. Zbog toga se dekomponira
na relacije TRGOVAC_2 i TRGOVAC_PARTNER_2, koje su u 2NF.
TRGOVAC_PARTNER_2 (2NF)
TRGOVAC_2 (2NF)
MB IME_PREZIME ODJEL_BROJ ODJEL_NAZIV
MB PARTNER_NAZIV
3
Ana Horvat
P1
O-Zagreb
3
Zagreb d.o.o.
5
Josip Antić
P2
O-Osijek
3
Horizont d.d.
9
Ante Ivić
P3
O-Split
5
Horizont d.d.
11
Maja Markić
P1
O-Zagreb
5
Kompakt d.o.o.
9
Vicko Stić
9
Hotel F
9
Amalija d.d.
11
Josip Ferić
11
Brzopromet
50
Druga normalna forma
Povežimo novonastale relacije (uspostavimo između njih vezu 1:M (U Accesu
označena kao 1- . Dakle, povezan je primarni ključ relacije TRGOVAC_2 sa
stranim ključem MB u relaciji TRGOVAC_PARTNER_2
TRGOVAC_2 (2NF)
TRGOVAC_PARTNER_2 (2NF)

1
MB IME_PREZIME ODJEL_BROJ ODJEL_NAZIV
MB PARTNER_NAZIV
3
Ana Horvat
P1
O-Zagreb
3
Zagreb d.o.o.
5
Josip Antić
P2
O-Osijek
3
Horizont d.d.
9
Ante Ivić
P3
O-Split
5
Horizont d.d.
11
Maja Markić
P1
O-Zagreb
5
Kompakt d.o.o.
9
Vicko Stić
9
Hotel F
9
Amalija d.d.
11
Josip Ferić
11
Brzopromet
51
Druga normalna forma
TRGOVAC_2 (2NF)
MB IME_PREZIME ODJEL_BROJ ODJEL_NAZIV
3
Ana Horvat
P1
O-Zagreb
5
Josip Antić
P2
O-Osijek
9
Ante Ivić
P3
O-Split
11
Maja Markić
P1
O-Zagreb
U relaciji TRGOVAC_2 još uvijek postoji redundancija, koja uzrokuje anomalije
pri obradi. Ovdje problem proizlazi iz zavisnosti neključnog atributa
ODJEL_NAZIV o drugom neključnom atributu ODJEL_BROJ.
Ovdje atribut ODJEL_NAZIV funkcijski zavisi o dva atributa, o ključu MB i
neključnom atributu ODJEL_BROJ. S obzirom da vrijede funkcijske zavisnosti
MBODJEL_BROJ i ODJEL_BROJODJEL_NAZIV vrijedi, prema aksiomu
tranzitivnosti, i MBODJEL_NAZIV.
Stoga je funkcijska zavisnost MBODJEL_NAZIV u relaciji TRGOVAC_2
nepotrebna, odnosno redundantna.
Ovaj problem rješava treća normalna forma (3NF) koja izbacuje tranzitivne
zavisnosti.
52
Treća normalna forma
Svaki neključni atribut mora zavisiti o ključu, cijelom
ključu i ni o čemu osim o ključu.
Prvi dio ove definicije ("mora zavisiti o ključu") kaže da za
svaki ključ postoji samo jedna vrijednost neključnog atributa,
čime određuje 1NF, drugi ("o cijelom ključu") određuje 2NF, a
treći ("ni o čemu osim o ključu") određuje 3NF.
Relacija je, dakle, u 3NF ako su iz nje izbačeni svi tranzitivno
zavisni atributi.
53
Treća normalna forma
TRGOVAC_2 (2NF)
MB IME_PREZIME ODJEL_BROJ ODJEL_NAZIV
3
Ana Horvat
P1
O-Zagreb
5
Josip Antić
P2
O-Osijek
9
Ante Ivić
P3
O-Split
11
Maja Markić
P1
O-Zagreb
Prilikom pretvorbe relacije iz 2NF u 3NF izdvajaju se svi neključni atributi
između kojih postoji funkcijska zavisnost
(ODJEL_BROJODJEL_NAZIV) u posebnu relaciju.
U prvoj relaciji pstaje ključ i ostali atributi, koji o njemu tranzitivno ne
ovise.
Dekompozicijom relacije TRGOVAC_2 dobivaju se relacije TRGOVAC_3
i ODJEL, koje su u 3NF, a prikazane su na sljedećem slajdu.
54
Treća normalna forma
TRGOVAC_3 (3NF)
ODJEL (3NF)
MB
IME_PREZIME
ODJEL_BROJ
ODJEL_BROJ ODJEL_NAZIV
3
Ana Horvat
P1
P1
O-Zagreb
5
Josip Antić
P2
P2
O-Osijek
9
Ante Ivić
P3
P3
O_Split
11
Maja Markić
P1
55
Treća normalna forma
Povežimo novonastale relacije (uspostavimo između njih vezu 1:M (U Accesu
označena kao 1- . Dakle, povezan je primarni ključ ODJEL_BROJ relacije
ODJEL sa stranim ključem ODJEL_BROJ u relaciji TRGOVAC_3.
TRGOVAC_3 (2NF)

1
ODJEL (3NF)
MB
IME_PREZIME
ODJEL_BROJ
ODJEL_BROJ ODJEL_NAZIV
3
Ana Horvat
P1
P1
O-Zagreb
5
Josip Antić
P2
P2
O-Osijek
9
Ante Ivić
P3
P3
O_Split
11
Maja Markić
P1
56
NORMALIZACIJA
Sažetak normalnih formi
1NF otklanja višestruke vrijednosti atributa.
2NF otklanja redudantne podatke koji proizlaze iz djelomičnih
funkcijskih zavisnosti.
3NF i BCNF otklanjaju tranzitivno zavisne atribute, odnosno one koji
nisu isključivo zavisni o ključu. Pri tome BCNF ispravlja propust od
3NF.
4NF razdvaja nezavisne veze M:N i stavlja ih u odvojene relacije.
5NF razdvaja semantički povezane n-arne veze (n>2).
Ako je relacija u 3NF, a ključ se sastoji od samo jednog atributa,
tada je relacija istovremeno i u 5NF.
57