POGLAVLJE Relacije 4

Strana 65

Relacije

okviru prethodnog poglavlja kreirane su i projektovane tabele koje čine podlogu za razvoj baze podataka RAD. Među njima postoje

određeni odnosi, veze i relacije. Te relacije i veze slika su realnih odnosa među entitetima koje tabele predstavljaju.

Povezivanje tabela i definisanje relacija, osnovni su korak u prelasku sa sistema „ravnih” tabela na moderne RDBMS, kakav je Access.

Pažljivom analizom veza koje postoje među podacima i veštom primenom mogućnosti programa mogu se kreirati veoma složeni sistemi.

U okviru ovog poglavlja najpre će se dati dodatna objašnjenja osnovnih pojmova u domenu baza, vezana za termine: Primarni ključevi, Spoljni ključevi i Indeksi.

Sledeći odeljak govori o relacijama između objekata. Ove relacije se mogu javljati u višestrukim oblicima, razvrstanim u klase: veza jedan

prema jedan (1:1), veza jedan prema više (1:), veza više prema jedan

(:1) i veza više prema više (:). Dat je opis i osnova ovih veza.

Za kreirane tabele u okviru prethodnog poglavlja i definisana ključna polja u okviru ovih tabela, opisana je potom procedura kreiranja njihovih međusobnih veza. Posebna pažnja posvećena je pojmovima kaskadnog ažururanja i kaskadnog brisanja. Data je praktična realizacija za sve definisane tabele a takođe, opisani su i primeri tipskih veza.

Definisanje šifarnika i upotreba LookUp Wizard-a za rad sa referentnim tabelama, materija je, koja je opisana u odeljku Refernetne

tabele.

U cilju upotpunjavanja tematike vezane za relacije, u poslednjem odeljku ovog poglavlja opisana su svojstva veza/relacija. Ta svojstva odnosno spojevi (unutrašnji, desni spoljni i levi spoljni spoj) prikazana su na prilagođenim primerima radi logičke sveobuhvatnosti. Tipovi spojeva su posebno aktuelni u domenu upita i uobičajeno pripadaju višem nivou proučavanja Access-a. Obim materije koji se izlaže u ovoj knjizi, ograničava njihovu primenu i upotrebu van ovog poglavlja.

U narednim odeljcima bazu podataka RAD obogatićemo relacijama i time zaokužiti njen logički model u ovoj fazi razvoja.

Gledano u viziru ideja i misaonih koncepata ovo je najteži i najodgovorniji deo puta na magistrali baza podataka.

KLJUČEVI I INDEKSI

U okviru materije, kojom smo ovladali u prethodnim poglavljima, u više navrata je kratko opisivana funkcija polja koja igraju ulogu primarnih ključeva u odgovarajućim tabelama. Tekst koji sledi daje detaljniji prikaz ovih pojmova.

U

POGLAVLJE

4

65-69

Ključevi i indeksi

69-73

Tipovi veza i referencijalni integritet

74-78

Uspostavljanje veza između tabela

78-85

Referentne tabele

85-89

Tipovi spojeva

89-90

Rezime i preporuke.

66 Deo II Poglavlje IV Relacije

Primarni ključevi

Prva faza u razvoju aplikacije RAD generisala je tabele: Dobavljaci, Odeljenja, Lokacije, Zaposleni i Racunari (sl.4-01).

Sl. 4-01 Prozor baze podataka RAD faza razvoja: početak 4. poglavlja Tabele: Dobavljaci

Lokacije Odeljenja Racunari Zaposleni

Vizuelni prikaz projektovanih tabela može se dobiti u Relationship dijagramu.

Postupak • Tools → Relationship (ili ikona Relationship na paleti sa alatima)

• Odabrati tabelu za učitavanje u relacioni dijagram

(primer: Dobavljaci) / dijalog Show table / LTM 1 x klik

• Add (Adding – dodati)

• Proceduru ponoviti za tabele:

Odeljenja, Lokacije, Zaposleni i Racunari.

• Rasporediti tabele i podesiti veličinu prikaza kao na sl.4-02..

• Zatvoriti prikaz Relationship sa / gore desno

Sl. 4-02 Prikaz kreiranih tabela u relacionom dijagramu (Relationship)

Kao što je već ranije rečeno, trebalo bi da svaka tabela u sitemu baze podataka ima primarni ključ, odnosno jedno ili više polja čiji je sadržaj jedinstven u svakom zapisu. Primarni ključevi tabela (primary keys) prikazani su pojačano polucrnim slovima (bold).

Deo IIKljučevi i indeksi 67

U tabeli T.4-01 navedeni su primarni ključevi početnih osnovnih tabela baze podataka RAD sa opisom njihovih svojstava.

Tabela 4-01 Primarni ključevi osnovnih tabela baze podataka RAD

Na primer, tekstualno polje ZaposleniID, dužine 6 znakova (characters) je primarni ključ tabele Zaposleni jer svaki zapis te tabele sadrži drugačiju šifru zaposlenog (svojstvo

Indexed: Yes (No Duplicates)) u poslovnom sistemu Olimpija. Primarni ključ neće dozvoliti dupliranje šifara, što se i vidi na sl.4-03.

Napomena: Svojstvo Caption polja ZaposleniID nazivu polja propisuje „nadimak” odnosno fakultativno ime Sifra Zaposlenog. Ovo opciono ime pojavljuje se kako u tabelarnom prikazu (sl.4-03) (kolona

Sifra Zaposlenog) tako i u obrascima i izveštajima, umesto naziva polja ZaposleniID.

Sl. 4-03 Primarni ključ ZaposleniID / Sifra Zaposlenog jednoznačno definiše zapise u tabeli Zaposleni

Svrha definisanja primarnih ključeva je da se zapisima u tabelama obezbede jedinstvene vrednosti. U terminologiji baza podataka to se zove integritet podataka.

Kreiranje primarnog ključa bazira se na nekom pravilu ili metodu. Algoritimi određivanja vrednosti mogu biti veoma jednostavni ili se pokoravati nekom „složenijem” matematičkom proračunu. Veoma često su to tekstualni podaci koji podležu određenim pravilima, koja se definišu putem ulaznih formata (Format), ulaznih maski (Input Mask) i dužinski ograničavaju preko Field Size. Pomenuti primarni ključ ZaposleniID je tekstualno polje maksimalne dužine 6 znakova koje se formira po sledećem pravilu: prvi deo ključa su inicijali zaposlenog a drugi, trocifrena numerička oznaka koja obezbeđuje jednoznačnost ukoliko u firmi postoje osobe sa istim inicijalima u imenu i prezimenu. Tipizacija pri unošenju podataka se obezbeđuje maskom LL-000;0;. Značenje parametara u masci je opisano ranije. Tako je za podatke Milovan Milivojević logičan ključ MM-001 a za sledećeg zaposlenog Miletu Markovića, ključ MM-002.

U zavisnosti od prirode sistema za koji se projektuje baza i informacioni sistem, za primarne ključeve se često uzimaju podaci, za koje se zna da su jednoznačni i neponovljivi u području funkcionisanja. Tipični primeri ovakvih primarnih ključeva su: Jedinstveni Matični Broj Građana (JMBG), broj indeksa studenta na nekom fakultetu, broj katasatarske parcele u Službi za katastar nepokretnosti, broj motora ili šasije kod automobila, serijski broj vodomera u bazi podataka za praćenje sistema priključaka na vodovodnu mrežu itd.

Preporuka je da polja primarnog ključa budu što kraća, jer to utiče na brzinu rada baze.

Tabela Primarni ključ

Tip polja / Filed Size

Svojstva polja

Zaposleni ZaposleniID Text / 6 Format: >

InputMask: LL\-000;0;

Caption: Sifra Zaposlenog

Description:

Unosi se Sifra zaposlenog u obliku MM-001 (Marko Mitic broj 001)

Indexed Yes (No Duplicates)

Dobavljaci DobavljaciID AutoNumber Odeljenja OdeljenjaID Text / 10 Format: >

Caption: Sifra Odeljenja

Indexed Yes (No Duplicates)

Description: Jednoznacna sifra odeljenja: SKOLA, AGENCIJA

Racunari RacunariID AutoNumber Lokacije LokacijaID AutoNumber


Podaci u primarnim ključevima pre svega služe za povezivanje tabela i imaju ulogu kohezionih sila u sistemu.

Dobro projektovana aplikacija ne zahteva od korisnika da pamti šifre i logiku kreiranja primarnih ključeva u svim tabelama. Drugim rečima, naprednim tehnikama obezbeđuje se da korisnik komunicira sa aplikacijom u „prirodnoj” formi. Na primer u user friendly aplikaciji za akcioni upit Pregled računarskih nabavki po Zaposlenim korisnik će unositi puno ime i prezime zaposlenog a „mašinerija” i mehanizmi, koji rade u drugom planu, će preko ključeva obezediti dinamički skup podataka (dynaset).

Polja primarnog ključa karakteriše:

o Indeks koji znatno ubrzava pretraživanje, soritranje i dobijanje dinamičkih skupova podataka;

o Obaveza popunjavanja u cilju održavnja baze podataka i unošenja samo prihvatljivih vrednosti;

o Izbegavanje dupliranja podataka zbog jednoznačnosti o Datasheet prikaz tabele automatski sortiran upravo po

polju primarnog ključa.

Indeksi

Indeksi ne moraju biti vezani samo za polja primarnog ključa. Ako se često sortiraju podaci po nekim poljima onda je preporučljivo tim poljima pridružiti indeks, odnosno indeksirati ih. Indeksiranjem tabele po odabranim poljima stvaraju se interne tabele, nevidljive za korisnika, u kojima su zapisi sortirani prema poljima koja su indeksirana. Ovakve interne tabele značajno ubrzavaju proces pronalaženja podataka, jer se pretraga realizuju po tabelama koje su već sortirane.

Ipak, potrebno je naći meru u određivanju polja (kolona) koje treba indeksirati, jer medalja ima i drugu stranu. Naime, indeksi usporavaju unošenje podataka i ažuriranje tabela. Ovo znači da svaki novi zapis ili promena na već postojećim podacima utiče na „dubinsko” sortiranje, što usporava sistem. Drugim rečima, potrebno je koristiti indekse samo u poljima gde je to neophodno i time obezediti optimum u odnosu:

brzina sortiranja i dobijanje podataka usporavanje prilikom unošenja podataka

Spoljni ključevi

Povezivanje podataka između dve tabele bazira na poljima koja imaju iste vrednosti podataka.

Polja koja se povezuju ne moraju imati ista imena ali moraju biti ista po tipu i po širini.

Veza se najčešće uspostavlja između polja primarnog ključa jedne i polja spoljnjeg ključa druge tabele. Vezno polje u toj vezanoj (drugoj) tabeli ne mora bit polje primarnog ključa. Ovo povezujuće polje, je polje (ili grupa polja) koje sadrži isti tip i širinu podataka kao primarni ključ povezane tabele.

Polje (ili grupa polja) koje tabelu povezuje sa primarnim ključem druge tabele, naziva se spoljnji ključ.

Termin Spoljni ključ (Foreign key) upotrebljava se, jer se povezivanje ove tabele vrši preko polja koje je isto kao polje primarnog ključa u drugoj – spoljnoj tabeli.

Polje spoljnjeg ključa u datoj tabeli ne mora biti i najčešće nije polje primarnog ključa. To polje samo mora da zadovolji karakteristike povezujćeg polja po tipu i širini.

Veza između dve tabele se najčešče uspostavlja kada primarni ključ jedne tabele ima iste vrednosti kao spoljni ključ druge tabele u sistemu (sl. 4-04).

Deo IIKljučevi i indeksi 69

Sl. 4-04 Polja - ključevi za povezivanje tabela primer: Tabele Odeljenja: OdeljenjeID (primarni ključ) Tabele Zaposleni: OdeljenjeID (spoljnji ključ) Napomena: Prikazana veza biće kreirana kasnije

TIPOVI VEZA I REFERENCIJALNI INTEGRITET

U okviru prethodnog odeljka definisani su i objašnjeni pojmovi primarnog i spoljnjeg ključa, koji su od primarnog značaja za uspostavljanje relacija i veza između tabela u bazi.

Pre nego što se krene u sam postupak realizacije veza potrebno je proanalizirati koje vrste veza postoje, odnosno kakvi odnosi među podacima postoje u realnim sistemima. Prepoznavanje pravilnih tipova veza među podacima je suptilna materija koja zahteva izraženu sposobnost analize i predmet je subjektivnih sposobnosti. Ipak, klasifikacije i tipski primeri mogu značajno pomoći u sticanju „misaone rutine” za prepoznavanje i uspostavljanje kvalitetnih interakcija između objekata u sistemu.

Kao što je pomenuto u uvodu ovog poglavlja veze (relationships) između tabela mogu da se svrstaju u sledeće četiri grupe:

1. Veza jedan prema jedan [1:1]

2. Veza jedan prema više [1:]

3. Veza više prema jedan [:1]

4. Veza više prema više [:]

Pravilan izbor i uspostavljanje veza između dve tabele je od suštinskog značaja. Realacija govori Access-u kako da posmatra dve tabele u spoju. RDBMS treba da „zna” da li jednom zapisu u „prvoj” tabeli odgovara samo jedan zapis u „drugoj” tabeli? Ili da li za svaki zapis u „prvoj” tabeli treba tražiti više zapisa u „drugoj” tabeli? Materija koja sledi vezana je za odgovore na prethodna pitanja.

Veza tipa 1:1

Ovaj tip veza se ređe koristi u RDBMS sistemima baza podataka, ali ponekad može dovesti do ušteda u memorijskom prostoru i do lakšeg popunjavanja i održavanja baze. Navedimo primer: Zamislimo da pored osnovnih personalnih podataka o svakom zaposlenom, želimo da organizujemo i širi skup podataka o porodičnom životu zaposlenih. Cilj bi mogao biti: pomoć računarskog sistema u štampanju čestitki za rodjendan ili datum venčanja. Takođe, mogli bi zahtevati od baze da nam stalno kreira ažuran spisak zaposlenih koji nemaju rešeno stambeno pitanje. Ovo bi mogla biti osnova za dodatak u plati i motivaciju.

Tačno je da bi svi ovi podaci mogli da se uskladište u tabeli Zaposleni, ali bi tabela bila verovatno „retko” popunjena. Razlog je, što se informatikom dobrim delom bave mlađi kadrovi, od kojih mnogi još nisu u „bračnim relacijama”.


Ovo ukazuje na formiranje tabele u kojoj bi se skladištili prethodni podaci. Nova tabela bi bila u relaciji 1:1 sa tabelom Zaposleni. Svakom zapisu nove tabele Brak, odgovarao bi jedan i samo jedan zapis u tabeli Zaposleni. Šematski prikaz ovog tipa veze, za navedeni primer dat je na sl.4-05.

Primarni ključevi u obe tabele su potpuno isti i oni učestvuju u kreiranju veze 1:1.

Veza tipa 1:

Ovaj tip veze se najčešće susreće u uobičajenim sistemima baza podataka. Pomoću nje se jedan zapis iz jedne tabele povezuje sa više zapisa iz druge tabele. Polja za povezivanje, kao što je opisano u prethodnom odeljku, su polje primarnog ključa jedne tabele i spoljnjeg ključa u povezanoj tabeli. Primeri relacija 1: u bazi podataka RAD su:

a) veza tabela Odeljenja – Zaposleni

b) veza tabela Zaposleni – Racunari

c) veza tabela Dobavljaci – Racunari

d) veza tabela Lokacije – Racunari.

Šematski prikaz ovog tipa veze za primer Odeljenja – Zaposleni dat je na sl. 4-06.

Relacija 1: se za dati primer može iskazati na sledeći način:

U svakom Odeljenju može raditi jedan ili više Zaposlenih a svaki Zaposleni može raditi u samo jednom Odeljenju.

Po sličnoj logici jedan zaposleni može naručiti jedan ili više računara a svaka konfiguracija može biti naručena od strane samo jednog zaposlenog. Ili za primer dobavljača i računara: Jedan dobavljač može isporučiti jedan ili više računara a svaki računar može biti isporučen od strane samo jednog dobavljača.

...

... zapi

si

Tabela: Zaposleni

zapi

si

Tabela: Brak Sl. 4-05 Veza 1:1

Svakom zapisu tabele Brak odgovara jedan i samo jedan zapis u tabeli Zaposleni

Broj zapisa u tabelama Brak i Zaposleni ne mora nužno biti isti.

...

...

zapi

si

Tabela: Odeljenja

zapi

si

Tabela: Zaposleni Sl. 4-06

Veza 1:

Svakom zapisu tabele Odeljenja

odgovara jedan ili više zapisa u tabeli Zaposleni

Svakom zapisu tabele Zaposleni odgovara jedan i samo jedan zapis u tabeli Odeljenja

Deo IITipovi veza i referencijalni integritet 71

Veza tipa :1

Ovakve vrste veza često se nazivaju i veze sa referentnim tabelama odnosno šifarnicima.

Kao primeri ovakvih, referentih tabela i veza :1 u narednom odeljku Uspostavljanje

veza među tabelama, biće kreirane tabele: Hobi i Slave. Gledano sa strane tabele Zaposleni: Više zaposlenih može slaviti jednu slavu pa je to veza :1. Ili više zaposlenih može imati jedan hobi. Ipak, gledano sa strane tabele Hobi, reč je o vezi 1:. Jedan hobi može imati više poklonika. Drugim rečima, veze tipa :1 i 1: mogu se smatrati jednakima. Razlika je jedino u smeru iz koga posmatramo vezu. Veze ovog tipa, najčešće nemaju podešen referencijalni integritet.

U klasu veza :1 spadaju i veze u kojima ne učestvuju primarni ključevi ni u jednoj od tabela koje su u vezi.

Veza tipa :

Veza tipa : (više prema više) je najsloženija i najteža za razumevanje. U okviru ovakvih relacija za dve tabele u vezi, jednom zapisu iz „prve” tabele odgovara jedan ili više zapisa iz „druge” tabele i obrnuto, jedom zapisu iz „druge” tabele odgovara jedan ili više zapisa iz „prve” tabele.

Tipičan primer ovakvih veza, nezavisno od baze podataka RAD, je relacija Proizvod – Porudžbina. Šematski prikaz interakcije ove dve tabele dat je na sl.4-07.

Ovakve relacije odgovaraju obostranoj vezi 1:, odnosno jedna porudžbina može imati

više proizvoda i obrnuto, svaki proizvod se može pojaviti u više porudžbina. Ovakav tip veza se dekomponuje na dve relacije 1:, umetanjem međutabele. Efekat dekompozicije je šematski prikazan na sl.4-08.

Relacija : se može prikazati i preko strukturnog prikaza tabela sa ključevima (sl.4-09).

...

zapi

si

Tabela: Porudžbine

zapi

si

Tabela: Proizvodi Sl. 4-07

Veza :

Jedna porudžbina može imati Više proizvoda

ali i

Jedan proizvod može se naći u Više porudžbina

...

Sl. 4-08 Dekomponovana

relacija : Porudzbine - Proizvodi

šematski prikaz

...

zapi

si

Tabela: Proizvodi

zapi

si

Tabela: Porudžbine

...

...

Tabela:

Detalji porudžbine


U cilju boljeg razumevanja ovog tipa relacija navodi se još jedan prototip odnosno tipična veza Student – Predmet. Dekomponovana šema sa međutabelom Ispit prikazana je na sl.4.10.

Jedan student može polagati više predmeta ali i jedan predmet može polagati više studenata. Vezna tabela Ispit rešava problem preko spoljnjih polja StudentID i Predmet ID i dve veze 1:.

U okviru baze podataka RAD, u kasnijoj fazi razvoja, biće kreirana tabela Projekat. Relacije tabele Projekat sa okolinom navode se šematski, u cilju upotpunjavanja materije. Ova tabela je vezana za tabelu Zaposleni sledećim odnosima: Jedan zaposleni može da učestvuje na više projekata ali i jedan projekat može da angažuje više zaposlenih. Reč je, dakle, o vezi :. Međutabela Tim, koja prevodi relaciju : u dve klasične relacije 1: prikazana je na sl.4-11.


relacija :

Primer 1

Međutabela Detalji Porudžbine

sadrži dva spoljna ključa koji odgovaraju primarnim

ključevima: PorudžbinaID i ProizvodID

Tabela: Proizvodi Tabela: Porudžbine

1

1 PorudzbinaID

…

Tabela: Porudžbine

DetaljiID

PorudzbinaID

ProizvodiID

…

Detalji Porudžbine

Tabela: Proizvodi

ProizvodiID

…

1

1 Tabela: Porudžbine

Detalji Porudžbine

Tabela: Proizvodi


relacija :

Primer 2

Međutabela Ispit

Spoljni ključevii: StudentID i PredmetID

Tabela: Predmet Tabela: Student

1

1 StudentID

…

Tabela: Student

IspitID

StudentID

PredmetID

…

Ispit

Tabela: Predmet

PredmetID

…

1

1 Tabela: Student

Ispit

Tabela: Predmet

Deo IITipovi veza i referencijalni integritet 73

Referencijalni integritet

Već je ranije rečeno da se pomoću primarnih ključeva obezbeđuje integritet zapisa i podataka u tabelama baze pojedinačno. Pored ovakve vrste zaštite, potrebno je uvođenje pravila koja obezbeđuju očuvanje uzajamnih veza između tabela u parovima. Ta pravila su poznata kao referencijalni integritet (referential integrity).

Pojam referencijalnog integriteta veoma se često susreće. Na primer: Najčešće nije uputno dozvoliti brisanje zapisa u tabeli Odeljanja, ukoliko nisu prethodno obrisani odgovarajući vezani zapisi u tabeli Zaposleni. Ukoliko bi taj proces bio omogućen, onda bi se u tabeli Zaposleni pojavili zaposleni koji ne pripadaju ni jednom odeljenju, odnosno zaposleni koji ne bi bili raspoređeni. Za koji bi profitni centar onda bile vezane njihove zarade? Ili, posmatrajmo tabele Lokacije i Racunari. Da li smemo dozvoliti olako brisanje zapisa u tabeli Lokacije? Šta ako u tabeli Racunari imamo računarske konfiguracije, koje se upravo nalaze na lokaciji čiji zapis smo obrisali. Praćenje i održavanje računarskog sistema, bilo bi u tom slučaju dovedeno u pitanje. Bezbroj je primera ovakvih problema u praksi, što ukazuje na značaj „očuvanja kvaliteta veza” u sitemima za relaciono upravljanje bazama podataka.

Tabele se mogu podesiti tako da referencijalni integritet među njima, bude automatski obezbeđen. Referencijalni integritet je vezan isključivo za polja primarnog i spoljnjeg ključa. Dodavanja, izmene ili brisanja podataka u ovim poljima podležu prethodnoj proveri održavanja referencijalog integriteta. RDBMS proverava da li eventualne promene narušavaju sistem veza i dozvoljava ove promene, samo u slučaju kada referencijalni integritet nije narušen.

Ako posmatramo tipične relacije 1: kao što su Lokacije – Racunari, Odeljenja – Zaposleni ili Dobavljaci – Racunari, onda se hijerarhijski „nadređena” tabela naziva „tabela roditelj” a podređena tabela - „tabela dete”. Dakle, veza 1: može se posmatrati i kao veza roditelj – dete. Referencijalni integritet obezbeđuje da se ne pojavljuje siroče, odnosno zapis u tabeli dete koji nema roditelja.

U okviru ovog odeljka postavili smo teorijsku podlogu za definisanje veza između tabela baze podataka.

Praktično uspostavljanje tipova relacija i podešavanje referencijalnog integriteta dato je u odeljku koji sledi.


relacija :

Primer 3

Međutabela Tim

Spoljni ključevii: ZaposleniID i ProjektiID

Tabela: Projekat Tabela: Zaposleni

1

1 ZaposleniID

…

Tabela: Zaposleni

TimtID

ZaposleniID

ProjekatID

…

Tim

Tabela: Projekti

ProjekatID

…

1

1 Tabela: Zaposleni

Tim

Tabela: Projekti


USPOSTAVLJANJE VEZA IZMEĐU TABELA

Access 2016 raspolaže veoma moćnim mehanizmom za rad sa vezama između tabela. Ovaj mehanizam omogućuje: dodavanje tabela, povezivanje tabela metodom „povuci i pusti”, jednostavne postupke definisanja tipova veza i lako zadavanje referencijalnog integriteta. Preporučuje se da veze između tabela budu trajne. Ovo utiče na smanjenje vremena za kreiranje upita i izveštaja. Naravno, veze među tabela mogu se, po potrebi, raskinuti i ponovo uspostaviti, ukoliko se novounešeni podaci pokoravaju referencijalnom integritetu.

Kreiranje veze

Veze se uspostavljaju u relacionom dijagramu. U prethodnom poglavlju je prikazana procedura podešavanja vidljivosti tabela u bazi podataka RAD (sl.4-02). Postupak izgradnje relacija, biće prikazan na primeru tabela Odeljenja i Zaposleni.

Postupak • Tools → Relationship (ili ikona Relationship na paleti sa alatima)

• Odabrati primarnu tabelu veze (primer: Odeljenja) / LTM 1 x klik

• Odabrati polje OdeljenjeID (primary key) u ovoj tabeli / LTM 1 x klik

• Mišem „prevući” polje OdeljenjeID i „spustiti” ga (drag and drop) na istoimeno polje OdeljenjeID u tabeli Zaposleni

• Nakon „otpuštanja” levog tastera miša pojaviće se dijalog za editovanje veza (Edit Relationship) kao na sl.4-12..

Obezbeđivanje referencijalnog integriteta između ove dve tabele, realizuje se jednostavnim potvrđivanjem („čekiranjem”) polja Enforce Referential Integrity.

Napomena: Ukoliko se referencijalni integritet ne potvrdi, mogu se zadavati novi zapisi, brisati povezani zapisi ili menjati ključna polja. Drugim rečima mogu se kreirati tabele koje sadrže siročiće odnosno roditeljske tabele bez dece. Uobičajeno je da pri ažuriranju ili unosu podataka referencijalni integritet bude potvrđen.

Sl. 4-12 Dijalog za uspostavlajnje relacije Odeljenja-Zaposleni

(Relationship)

Primarna tabela (roditelj)

Odeljenja

Polje: OdeljenjeiD (primary key)

Referencijalni integritet

Kaskadno ažuriranje

Kaskadno brisanje

Vezana tabela (dete)

Zaposleni

Polje: OdeljenjeiD (foreign key)

Kreiranje relacije Odeljenja-Zaposleni

Tipovi spojeva Tip veze: 1:

Deo IIUspostavljanje veza imeđu tabelama 75

Kako su povezana polja OdeljenjeID (polje primarnog ključa u tabeli Odeljenja) i polje OdeljenjeID iz tabele Zaposleni (polje spoljnjeg ključa tabele Zaposleni) to će se

kreirati veza 1: (One–To–Many) (sl.4-12).

Tipovi spojeva (Join Type) biće objašnjeni u poslednjem odeljku ovog poglavlja.

Potvrđeni referencijalni integritet, daje mogućnost dodatnih podešavanja vezanih za kaskadno ažuriranje i kaskadno brisanje zapisa.

Lančano ažuriranje povezanih polja

Opcija Cascade Update Related Fields (lančano ažuriranje povezanih polja) (sl.4-12) omogućuje korisniku da menja sadržaj primarnog ključa u primarnoj tabeli.

Ako je opcija Cascade Update Related Fields potvrđena, nakon promene primarnog ključa u primarnoj tabeli (primer: OdeljenjeID u tabeli Odeljenja), Access će:

1. proveriti integritet primarne tabele (zabrana dupliranja primarnog ključa) a zatim

2. automatski promeniti sadržaj povezujućih polja (spoljnjih ključeva) u povezanoj tabeli „detetu” (tabela Zaposleni).

Navedimo primer: U delu unetih test podataka, škola računara je u polju OdeljenjeID tabele Odeljenja, šifrirana sa Skola. Svi zaposleni u školi računara, u tabeli Zaposleni imaju u spoljnjem ključu OdeljenjID vrednost: Skola. Ukoliko se vrednost primarnog ključa u tabeli Odeljenja, za Školu računara, promeni sa Skola na primer na E-Centar, automaski će svi zapisi o zaposlenim u školi računara imati vrednost E-centar u polju spoljnjeg ključa tabele Zaposleni. Promena se lančano prenosi kroz ceo sistem baze podataka.

Ukoliko je polje primarnog ključa primarne tabele povezano sa spoljnjim ključevima u više tabela, opcija kaskadnog ažuriranja mora da bude potvrđena za sve povezane tabele.

Ukoliko opcija Cascade Update Related Fields nije potvrđena primarni ključ primarne tabele koja je povezana sa nekom drugom tabelom, ne može se menjati.

Lančano brisanje povezanih zapisa

Slično postupku kaskadnog ažuriranja, opcija Cascade Delete Related Records (lančano

brisanje povezanih zapisa) omogućuje korisniku da brisanjem sadržaja primarnog ključa u primarnoj tabeli automatizovano briše sve zavisne zapise u čitavoj bazi podataka.

Opcija brisanja za čitav sistem važi, ako je potvrđeno brisanje povezanih polja za sve relacije u kojima učestvuje neka tabela. Ona „grana” u lancu tabela, kod koje bar jedna veza nema potvrđenu opciju lančanog brisanja, neće dozvoliti automatozovan postupak brisanja zapisa po dubini.

Posmatrajmo, kao primer, relacije između tri već kreirane tabele u bazi podataka RAD: Odeljenja, Zaposleni i Racunari. Kao što je ranije opisano ove tabele su hijerarhijski

povezane tipom veza 1: (sl.4-13).

Ukoliko korisnik aktivira opciju brisanja zapisa u tabeli roditelju (primer: zapis o Agenciji

iz tabele Odeljenja) onda će svi zapisi u tabeli detetu (zapisi o zaposlenim u Agenciji - tabela

Zaposleni) i zapisi u tabeli unuku (zapisi o računarima koje su naručili zaposleni u Agenciji - tabela

Racunari) biti obrisani, pod uslovom da je u vezama uključena opcija Cascade Delete Related

Records. Brisanje se realizuje od hijerarhijski najnižeg nivoa. Dakle, RDBMS prvo briše računarske konfiguracije, potom zaposlene koji su ih naručili i na kraju i sam zapis o odeljenju Agencija.

Pri uključenoj opciji za kaskadno brisanje, sistem ne dozvoljava akcije koje bi dovele do pojave siročića u zavisnim tabelama.

Sl. 4-13 Primer kaskadnog brisanja u tri povezane tabele

1

1 Tabela: Odeljenja

Tabela: Zaposleni

Tabela: Racunari


Napomena: Lančano brisanje zavisnih zapisa funkcioniše po principu Domino efekta. Zato, ovu mogućnost koristite sa velikim oprezom!!! Acces ne upozorava da će obrisati sve podatke po dubini!!!

Preporučljivije je da se brisanje zapisa realizuje programski, pomoću VBA.

Konačno, nakon provere polja u roditeljskoj tabeli (Odeljanja) i tabeli detetu (Zaposleni), opcionog opredeljivanja za referencijalni integritet i eventualnih izbora lančanog ažuriranja i/ili brisanja - potrebno je kreirati vezu pomoću tipke Create. Formirana relacija poprima formu kao na sl.4-14.

Sl. 4-14 Uspostavljena relacija

1: Između tabela Odeljenja i Zaposleni

Može se dogoditi da formiranje relacije ne uspe. Najčešći razlog je narušeni referencijalni integitet, odnosno, veoma je verovatno da tabela dete poseduje zapise „siročiće”. Access će dati kratko uputstvo i preporuke koje ukazuju na to da se iz povezujuće tabele moraju ukloniti zapisi koji narušavaju referencijalni integritet. Tek

nakon korekcije, može se uspostaviti veza među tabelama. Selekcija i brisanje „nepodobnih” zapisa često se realizuje pomoću upita (Queries).

Kad se uspostavi veza među tabelama, Relation Builder (čarobnjak za kreiranje veza) prikazuje vezu u obliku tanke spojne linije sa zadebljanjem na krajevima. Pri potvrđenom referencijalnom integritetu, na krajevima linija nalaze se oznake (1), odnosno beskonačno

() (sl.4-14). Ukoliko referencijalni integritet nije potvrđen, spojna linija koja reprezentuje

vezu nema oznaka (1) i ().

Veze između tabele baze podataka RAD

Na osnovu prikazanog postupka kreiranja veza i ranije analize u odeljku Tipovi veza i

referencijalni integritet (Veze 1:), potrebno je kreirati ostale relacije u bazi podataka RAD prema tabeli T.4-02 i sl.4-15.

Tabela 4-02 Veze u bazi podataka RAD

Kao što se vidi, sve uspostavljene relacije su tipa 1: i sve, izuzev veze Lokacije– Racunari, imaju potvrđen referencijalni integritet. Veza koja nema referencijalni integritet u spoju nema prikazane oznake 1i .

Primarna tabela / Polje

Povezana tabela / Polje

Ref. integritet

Kaskadno ažurir. i brisanje

Tip veze

Odeljenja / OdeljenjeID Zaposleni / OdeljenjeID Da Da 1:

Zaposleni / ZaposleniID Racunari / Narucilac Da Da 1:

Dobavljaci / DobavljaciID Racunari / Dobavljac Da Da 1:

Lokacije / LokacijeID Racunari / Lokacija Ne Ne 1:

Deo IIUspostavljanje veza imeđu tabelama 77

Sl. 4-15 Relacije u bazi podataka RAD prva faza

Dalje je pri analizi veza bilo je reči o vezi tipa 1:1. Kao primer, definisana je tabela Brak. Vreme je da projektujemo ovu tabelu, i da je povežemo sa tabelom Zaposleni.

Struktura tabele Brak u režimu Design data je na sl.4-16. Primarni ključ ove tabele u potpunosti odgovara primarnom ključu tabele Zaposleni. Kratki opis svojstava (Field

Properties) za ostala polja dat je u tabeli T.4-03.

Sl. 4-16 Struktura tabele Brak Prikaz u režimu Design

T. 4-03 Osobine polja za tabelu Brak

Name Type Size Property Value

Ime Text 15

Mobilni Text 15

DatumVencanja Date/Time Format: Short Date InputMask: 99.99.00;0; Caption: Vencanje Validation Rule <Date() Validation Text Datum mora biti mladji od tekuceg

DatumRodjenja Date/Time Format: Short Date

InputMask: 99.99.00;0; Caption: Rodjendan

Stan Yes/No Format: ;"DA"[Red];"NE"[Green]

Povrsina Number Byte


Nekoliko test podataka za ovu tabelu dato je u tabeli T.4-04. Podatke treba uneti u režimu DataSheet.

T. 4-04 Test podaci za tabelu Brak

ZaposleniID Ime Mobilni Vencanje Rodjendan Biografija Stan Povrsina MM-001 Zora 064-777-999 05.05.93 02.04.77 Zavrsila Ekonomsku. .. Da 58

TM-001 Milena 063-111-222 15.06.98 11.09.79 Zavrsila FON, sjajan... Da 94

Procedura pikaza tabele Brak u relacionom dijagramu i njenog povezivanja sa tabelom Zaposleni data je u nastavku. Izgled relacije 1:1, vidi se na slici sl.4-15.

Postupak: Prikaz tabele Brak

• Tools → Relationship (ili ikona Relationship na paleti sa alatima)

• Prikazati pomoćni prozor sa tabelama / DTM 1 xklik na neutralnu zonu relacionog dijagrama

• Show Table / LTM 1xklik u pomoćnom prozoru

• Odabrati tabelu Brak / LTM 1 x klik

• Add (Adding – dodati) → Close

Postupak: Kreiranje relacije Zaposleni - Brak

• Odabrati primarnu tabelu veze (primer: Zaposleni) / LTM 1 x klik

• Odabrati polje ZaposleniID (primary key) u ovoj tabeli / LTM 1 x klik

• Mišem „prevući” polje ZaposleniID i „spustiti” ga (drag and drop) na istoimeno polje ZaposleniID u tabeli Brak

• U dijalogu za editovanje veza (Edit Relationship), potvrditi referencijalni integritet i kaskadno ažuriranje i brisanje..

Ukoliko se definišu pogrešni parametri bilo koje veze u sistemu baze, naknadne korekcije realizuju se veoma jednostavno.

Postupak: • Aktivirati relaciju / LTM 2 x klik na liniju veze

• U dijalogu Edit RelationShip podesiti i korigovati parametre veze

• Zatvoriti dijalog sa Close

Zatvaranje relacionog dijagrama po potrebi realizuje se sa / gore desno

Prethodni koraci daju solidnu osnovu i objašnjenja za kreiranje tipskih veza 1: i 1:1. Povezivaje osnovnih tabela sa šifarnicima biće opisano u narednom odeljku.

REFERENTNE TABELE

U odeljku LookUp poglavlja Tabele, bilo je reči o tekstualnim poljima koje se popunjavaju preko padajuće liste. Opisana je procedura kreiranja listi direktnom popunom pomoću čarobnjaka i najavljeno, da se kombinovano polje može povezati sa već kreiranom tabelom. Takve tabele, često se nazivaju tabele šifarnici.

Kao primer za povezivanje tabela sa šifarnicima, biće formirane tabele Hobi i Slave.

Kao i sve druge tabele i šifarnici se projektuju u režimu Design. Izgled stuktura ovih tabela dat je na sl.4-17. Tabela Hobi ima samo jedno polje, tekstualnog tipa dužine 20, koje je ujedno i primarni ključ. Tabela Slave kao primarni ključ ima numeričko polje (Number) veličine jednog byte-a. Ostala polja: NazivSlave, NazivSlavePun i Datum su tekstualna polja maksimalne dužine 20, 30 i 10 znakova (characters), respektivno.

Test podaci za kreirane tabele – šifarnike dati su u tabeli T.4-05. Ove podatke treba uneti u režimu DataSheet.

Sl. 4-17 Struktura tabela Hobi I Slave

T. 4-05 Test podaci za tabele Hobi i Slave

Kreiranje padajućih listi za polja Hobi i Slave u tabeli Zaposleni na bazi tabela šifarnika, realizuje se po metodologiji sličnoj onoj koja je opisana u odeljku LookUp. Razlike tehnika, u odnosu na padajuću listu koju direktno popunjava korisnik, su veoma male.

Ipak, pošto se ovaj koncept veoma često pojavljuje u praksi, dodatno ćemo opisati postupak povezivanja polja Slava u tabeli Zaposleni sa šifarnikom – tabelom Slave.

Postupak popune padajuće liste pomoću tabele šifarnika • Aktivirati tabelu Zaposleni u Design režimu

• Markirati polje Slava u koloni Field Name

• Markirati tip polja u okviru padajuće liste Lookup Wizard

• Odabrati način na koji se kreira Lookup kolona (I want the lokup column to look up the values

in a table or query - Kreiranje padajuće liste na bazi postojećih tabela).

• Next

• Odabrati tabelu koja predstavlja osnovu za padajuću listu (Tabela:Slave) → Next

• Selektovati polja za padajuću listu: SlaveID, NazivSlave i Datum→ Next

• Odabrati polje sortiranja padajuće liste (polje: NazivSlave) → Next

• Podesiti širinu kolona u padajućoj listi i opcionu vidljivost primarnog ključa referentne tabele (Hide key column/recomended –Skrivena kolona primarnog ključa/preporučeno) (sl.4-18)

• Next

HOBI SLAVE NazivHobija SlavaID NazivSlave NazivSlavePun Datum Film 1 Nikoljdan Sv.Nikola 19.12

Knjizevnost 2 Jovanjdan Sabor Sv. Jovana Krstitelja 21.01

Lov 3 Djurdjevdan Sv.Georgije 06.05

Muzika 4 Mala Gospojina Rodjenje Presvete Bogorodice 21.09

Pcelarstvo 5 Tomindan Sv. Apostol Toma 19.10

Planinarenje 6 Vraci Sv. Kozma i Damjan 14.11

Ribolov


Sl. 4-18 Podešavanje širina kolona padajuće liste za polje Slave u tabeli Zaposleni Kolona primarnog ključa SlavaID je skrivena što je i preporučeno

• Prihvatiti ponuđeni naziv za referentnu kolonu u padajućoj listi

• Memorisati promene u strukturi tabele sa Yes (RDBMS u pozadini kreira vezu!!!)

Napomena: Polje Slava u tabeli Zaposleni će automatski promeniti tip (DataType) iz Text u Number i po veličini se prilagoditi (Byte) polju SlavaID u tabeli Slave.

• Zatvoriti tabelu Zaposleni sa → Yes / gore desno

Na sličan način, potrebno je povezati polja Hobi u tabeli Zaposleni sa šifarnikom – tabelom Hobi. Padajuća lista pojaviće se u formi jedne kolone.

Prikaz tabela Slave i Hobi u relacionom dijagramu (DTM 1xklik → Show Table → Izbor

tabele Slave → Add …) automatizovano prikazuje i relacije koje je LookuUp čarobnjak kreirao u pozadini (sl.4-19).

Sl. 4-19 Relacije u bazi podataka RAD Nakon dodavanja tabela Hobi i Slave

i uspostavljanja odgovarajućih veza

druga faza

Veza Hobi – Zaposleni je :1, bez potvrđenog referencijalnog integriteta (vezujuća polja

su polje NazivHobija iz tabele Hobi i polje Hobi iz tabele Zaposleni). Slično, relacija Slave –

Zaposleni nema referencijalni integritet (vezujuća polja su polje SlaveID iz tabele Slave i polje

Slave iz tabele Zaposleni).

Popunjavanje polja Hobi i Slava realizuje se, pomoću padajućih listi, u prikazu DataSheet tabele Zaposleni (sl.4-20) (BLOK 6).

Dalji elementi logike izgradnje relacionog modela baze podataka slede u BLOKU 6.

POGLAVLJE Relacije 4

Documents

Transcript of POGLAVLJE Relacije 4