Pred BAZE5 2011 12ppt

1Napomena: Glavna literatura za ovo područje je: Mladen Varga, Baze podataka: konceptualno, logičkoi fizičko modeliranje podataka, DRIP, Zagreb, 1994.

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

2


• 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.

3

INTEGRITET U RELACIJSKOM MODELUOgranič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.

4

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).

5

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.

6

INTEGRITET U RELACIJSKOM MODELUPrimjer: 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.

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

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

U MS Accessu godina se piše bez točke na kraju.

8

INTEGRITET U RELACIJSKOM MODELUU 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.

9

INTEGRITET U RELACIJSKOM MODELUOdrž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 nul-vrijednost ili na početnu vrijednost (default).

10

INTEGRITET U RELACIJSKOM MODELUPravila 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.

11


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.

12

INTEGRITET U RELACIJSKOM MODELUVeze:

Veze među tablicama se uspostavljaju pomoću miša Drag and Drop tehnikom, a njihova svojstva se uređuju preko opcije Edit Relationship….

13

Karakteristike veze jedan-Karakteristike veze jedan-prema-jedanprema-jedanSvaki 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.

14

Karakteristike veze jedan-Karakteristike veze jedan-prema-višeprema-višeJedan 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.

15

Karakteristike veze više-prema-Karakteristike veze više-prema-viševišeOvdje 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

16

NORMALIZACIJA

17

NORMALIZACIJADobro 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.

18

NORMALIZACIJAZbog 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.

19

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.

20

NORMALIZACIJARazlozi 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.

21

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.

22

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.

23

NORMALIZACIJA

PARTNER_SIFRA

PARTNER_

NAZIV

PARTNER_ADRESA

MB IME_

PREZIME

DATUM_

RODJENJA

PLA

CA

DODATAK

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

24

NORMALIZACIJAU 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.

25

NORMALIZACIJADobro 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).

26

NORMALIZACIJARedoslijed 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.

27

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.

28

NORMALIZACIJA

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 XY 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_SIFRAPARTNER_ADRESA

Funkcijska zavisnost

29

NORMALIZACIJA

Npr. za tablicu IZDAVACI, IzdavacNaziv potpuno zavisi o IzdavacID atributu.

Pišemo: IzdavacIDIzdavacNaziv

To se može čitati:

"IzdavacID određuje IzdavacNaziv" ili:

"IzdavacNaziv zavisi o IzdavacID".

IZDAVACI

IzdavacID IzdavacNaziv

1234 Znak

30

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".

31

NORMALIZACIJA

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

Sažetak dekompozicije

32

NORMALIZACIJA

ISBN: 0-55-123456-9Naslov: Main StreetAutori: Jones, SmithIzdavač: 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.

1NF1NF Relacija se nalazi u 1NF ako su vrijednosti atributa Relacija se nalazi u 1NF ako su vrijednosti atributa nedjeljive.nedjeljive.Svaki njezin atribut je atomaran, tj. sadrži samo jednu Svaki njezin atribut je atomaran, tj. sadrži samo jednu vrijednost, nikako više vrijednosti.vrijednost, nikako više vrijednosti.

Prva normalna formaPrva normalna forma

33

NORMALIZACIJA

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 atomaranDakle, relacija je u 1NF ako je svaki njezin atribut atomaran.


34

NORMALIZACIJA

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.

35

NORMALIZACIJAPrva normalna formaPrva normalna forma

Nepoštivanje prve normalne forme je često kod ljudi koji naučealat (npr. Access), a ne znaju ništa o oblikovanju baza podataka, parade 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 kojaje po redu.

36

NORMALIZACIJA

2NF2NF Relacija se nalazi u 2NF ako su Relacija se nalazi u 2NF ako su svisvi neključni atributi neključni atributi potpuno funkcijski zavisni o bilo kojem ključu relacije.potpuno funkcijski zavisni o bilo kojem ključu relacije.

Druga normalna formaDruga normalna forma

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.

37

NORMALIZACIJA

3NF3NF Relacija se nalazi u 3NF ako ako ni jedan neključni atribut Relacija se nalazi u 3NF ako ako ni jedan neključni atribut nije tranzitivno zavisan o bilo kojem ključu relacije.nije tranzitivno zavisan o bilo kojem ključu relacije.

Treća normalna formaTreća normalna forma

Svaki neključni atribut mora zavisiti o ključu, cijelom ključu Svaki neključni atribut mora zavisiti o ključu, cijelom ključu i ni o čemu osim ključui 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.

38

NORMALIZACIJATreća normalna formaTreć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.

39

Primjeri normalnih formi

40

Prva normalna forma

Relacija se nalazi u prvoj normalnoj formi (1NF) ako su svi Relacija se nalazi u prvoj normalnoj formi (1NF) ako su svi neključni atributi funkcijski zavisni o (primarnom) ključu neključni atributi funkcijski zavisni o (primarnom) ključu relacije.relacije.

Nema ponavljajućih atributa (domena) ili grupa atributa.Nema ponavljajućih atributa (domena) ili grupa atributa.

1NF razmatra dvije stvari:1NF razmatra dvije stvari:

1.1. svaki redak tablice ne smije sadržavati ponavljajuće svaki redak tablice ne smije sadržavati ponavljajuće grupe (atribute) sličnih podataka (atomarnost)grupe (atribute) sličnih podataka (atomarnost)

2.2. svaki redak tablice mora imati primarni ključ svaki redak tablice mora imati primarni ključ (jedinstveni identifikator).(jedinstveni identifikator).

41

TRGOVAC_PARTNER_0 (0NF)

MBMB IME_PREZIMEIME_PREZIME ODJEL_BROJODJEL_BROJ ODJEL_NAZIVODJEL_NAZIV PARTNER_NAZIVPARTNER_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 FAmalija 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).

42


MBMB IME_PREZIMEIME_PREZIME ODJEL_BROJODJEL_BROJ ODJEL_NAZIVODJEL_NAZIV PARTNER_NAZIVPARTNER_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


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.

43


MBMB IME_PREZIMEIME_PREZIME ODJEL_BROJODJEL_BROJ ODJEL_NAZIVODJEL_NAZIV PARTNERPARTNER_NAZIVNAZIV











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).

44

1NF – Primjer ponavljajućih atributa ili grupa atributa1NF – 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)višestruki stupci (ponavljajuća grupa atributa)

MBMB IME_PREZIMEIME_PREZIME PARTNER1PARTNER1 PARTNER2PARTNER2 PARTNER3PARTNER3

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. ? ?

45

1NF – Primjer ponavljajućih atributa ili grupa atributa1NF – Primjer ponavljajućih atributa ili grupa atributa

višestruki stupci (ponavljajuća grupa atributa)višestruki stupci (ponavljajuća grupa atributa)

MBMB IME_PREZIMEIME_PREZIME PARTNER1PARTNER1 PARTNER2PARTNER2 PARTNER3PARTNER3

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.

46

1NF – Primjer ponavljajućih atributa ili grupa atributa1NF – Primjer ponavljajućih atributa ili grupa atributaTo možemo riješiti jednim stupcem (atributom) za partnere.

MBMB IME_PREZIMEIME_PREZIME PARTNERPARTNER

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.

47

1NF – Primjer ponavljajućih atributa ili grupa atributa1NF – Primjer ponavljajućih atributa ili grupa atributaRješenje: Tablica koja zadovoljava 1NF. (TRG_PART)

Primjetite da se primarni ključ sastoji od atributa MB i PARTNER.

TRG_PART (1NF)

MBMB IME_PREZIMEIME_PREZIME PARTNERPARTNER

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.

48

Druga normalna forma

2NF govori da svi neključni atributi moraju u potpunosti 2NF govori da svi neključni atributi moraju u potpunosti funkcijski zavisiti o čitavom (složenom) primarnom ključu, funkcijski zavisiti o čitavom (složenom) primarnom ključu, a ne samo o njegovom dijelu.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 2NF odnosi se samo na relacije sa složenim primarnim ključem. Ako relacija ima jednostavan primarni ključ, onda ključem. Ako relacija ima jednostavan primarni ključ, onda ona zadovoljava 2NF (naravno, ukoliko je prije toga ona zadovoljava 2NF (naravno, ukoliko je prije toga zadovoljila 1NF).zadovoljila 1NF).

49


MBMB IME_PREZIMEIME_PREZIME ODJEL_BROJODJEL_BROJ ODJEL_NAZIVODJEL_NAZIV PARTNERPARTNER_NAZIVNAZIV











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).

50

Druga normalna formaRelacija TRGOVAC_PARTNER_1 (1NF) nije u 2NF. Zbog toga se dekomponira na relacije TRGOVAC_2 i TRGOVAC_PARTNER_2, koje su u 2NF.

TRGOVAC_2 (2NF)

MBMB 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

MBMB PARTNERPARTNER_NAZIVNAZIV

3 Zagreb d.o.o.

3 Horizont d.d.

5 Horizont d.d.

5 Kompakt d.o.o.

9 Vicko Stić

9 Hotel F

9 Amalija d.d.

11 Josip Ferić

11 Brzopromet


51

Druga normalna formaPovež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






MBMB PARTNERPARTNER_NAZIVNAZIV

3 Zagreb d.o.o.

3 Horizont d.d.

5 Horizont d.d.

5 Kompakt d.o.o.

9 Vicko Stić

9 Hotel F

9 Amalija d.d.

11 Josip Ferić

11 Brzopromet

TRGOVAC_PARTNER_2 (2NF)TRGOVAC_2 (2NF)

1

52

Druga normalna forma

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 MBODJEL_BROJ i ODJEL_BROJODJEL_NAZIV vrijedi, prema aksiomu tranzitivnosti, i MBODJEL_NAZIV.Stoga je funkcijska zavisnost MBODJEL_NAZIV u relaciji TRGOVAC_2 nepotrebna, odnosno redundantna.Ovaj problem rješava treća normalna forma (3NF) koja izbacuje tranzitivne zavisnosti.

TRGOVAC_2 (2NF)






53

Treća normalna forma

Svaki neključni atribut mora zavisiti o ključu, cijelom Svaki neključni atribut mora zavisiti o ključu, cijelom ključu i ni o čemu osim o ključu.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.

54


Prilikom pretvorbe relacije iz 2NF u 3NF izdvajaju se svi neključni atributi između kojih postoji funkcijska zavisnost (ODJEL_BROJODJEL_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.

TRGOVAC_2 (2NF)






55


TRGOVAC_3 (3NF)

MBMB IME_PREZIME ODJEL_BROJ

3 Ana Horvat P1

5 Josip Antić P2

9 Ante Ivić P3

11 Maja Markić P1

ODJEL (3NF)

ODJELODJEL_BROJBROJ ODJEL_NAZIV

P1 O-Zagreb

P2 O-Osijek

P3 O_Split

56


MBMB IME_PREZIME ODJEL_BROJ

3 Ana Horvat P1

5 Josip Antić P2

9 Ante Ivić P3

11 Maja Markić P1

ODJELODJEL_BROJBROJ ODJEL_NAZIV

P1 O-Zagreb

P2 O-Osijek

P3 O_Split

TRGOVAC_3 (2NF) ODJEL (3NF)1

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.

57

NORMALIZACIJA

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.

Sažetak normalnih formi

Documents

Pred BAZE5 2011 12ppt