IT2008 IM BazePodataka IT350 Bazepodataka L09

Lekcija 9 - Transformacija ER modela ufizički relacioni model baze podataka

| Contents | 2

Contents

LearningObject................................................................ 3Lekcija-9-Predavanja.........................................................................................................3Transformacija E/R modela u relacioni model baza podataka: transformacija entiteta.... 3Transformacija E/R modela u relacioni model baza podataka: max kardinalnost 1:1......5Transformacija E/R modela u relacioni model baza podataka: veze sa max

kardinalnošću tipa 1:N.................................................................................................5Transformacija E/R modela u relacioni model baza podataka: veze sa max.

kardinalnošću M:N........................................................................................................6Transformacija E/R modela u fizički model baza podataka: asocijativne veze..................8Transformacija E/R modela u fizički relacioni model baza podataka: atributi sa više

vrednosti.................................................................................................................... 10Transformacija E/R modela u relacioni model baza podataka: podklase........................ 11Transformacija E/R modela u relacioni model baza podataka: mešovite relacije............12Transformacija E/R modela u relacioni model baza podataka: Unarne (rekurzivne)

relacije........................................................................................................................13Transformacija E/R modela u relacioni model baza podataka:Primer.............................15Formiranje fizičkog modela............................................................................................ 16Osnovni elementi fizičkog modela................................................................................. 24Primer fizičkog modela...................................................................................................28Transformacija konceptualnog u fizički (relacioni) model...............................................31Transformacija E/R modela u relacioni model baza podataka: min kardinalnosti-

obavezan roditelj....................................................................................................... 32Transformacija E/R modela u relacioni model baza podataka: min kardinalnosti-

obavezna deca...........................................................................................................34Transformacija E/R modela u relacioni model baza podataka: Implementiranje akcija

koje podržavaju dizajniranje minimalne kardinalnosti............................................... 35Primer transformacije E/R modela u relacioni model.....................................................37Domaći zadatak..............................................................................................................39Lekcija-9-Predavanja.......................................................................................................39

| LearningObject | 3

LearningObject

Lekcija-9-Predavanja

UvodVeoma često, u slučajevima kada je konceptualni model baze podataka predstavljen E/Rmodelom fizički relacioni model baze podataka se dobija transformacijom urađenog E/Rmodela. Ukoliko je E/R model urađen korišćenjem CASE alata, ta transformacija se možeizvršiti automatski, na osnovu jasno definisanih pravila transformacije pojednih elemenataE/R modela: entiteta, atributa I relacija. U ovom predavanju se govori upravo o tim pravilatransformacije, koja bez obzira na mogućnost automatske transformacije treba poznavati,kako bi dobijeni relacioni model mogao da se verifikuje. U predavanju je posebna pažnjaposvećena dizajniranju minimalne kardinalnosti što predstavlja zadnji korak u transformacijikonceptualnog modela podataka u relacini model.

Transformacija E/R modela u relacioni model baza podataka:transformacija entiteta

Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti.Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza. Ovde ćebiti reči o pravilima za transformaciju entiteta.

Cilj• Prikazati način transformacija E/R modela u relacioni model baza podataka

Transformacija E/R modela u relacioni model baza podataka: transformacijaentitetaSvaki tip entiteta iz E-R dijagramu se transformiše u jednu relaciju odnosno tabelu bazepodataka. Identifikator tipa entiteta postaje primarni ključ relacije a drugi atributi tipa entitetapostaju atributi ne primarnih ključeva relacije.

Prilikom transformacije treba voditi računa o sledećem:

Primarni ključ treba da ima sledeće svojstva:• Vrednost primarnog ključa jedinstveno identifikuje svaki red u relaciji.• Ključ mora da bude neredudantan; nema atributa u ključu koji može biti izbrisan a da se ne

naruši njegova jedinstvena identifikacija

Idealan primarni ključ treba da bude kratak, numerički i fiksan. U slučajevima kada se to nemože postići, treba razmotriti mogućnost korišćenja nekog kandidat ključa kao primarnog.Ako nema kandidat ključeva, ili ni jedan od njih ne zadovoljava prethodne kriterijume, trebarazmotriti mogućnost korišćenja surogat ključa.


Surogat ključ je identifikator kojeg generiše DBMS, njegov redosled je jedinstvena u okvirujedne tabele i nikada se ne menja. On se dodeljuje u trenutku kreiranja reda u tabeli auništava se kada se red obriše.

Sledeći korak u kreiranju tabela je specificiranje kandidat ključeva. To su alternativniidentifikatori jedinstvenih redova u tabeli. Umesto termina kandidat ključ, često se koristi itermin alternativni ključ. Npr. U relacijiZAPOSLENI (BrojZaposlenog, ImeZaposlenog, Telefon, Email, DatumZaposlenja,DatumProvere, KodZaposlenog)

BrojZaposlenog je primarni ključ dok Email može biti kandidat ključ ili alternativni ključ.

Za atribut svake kolone treba obraditi pažnju na sledeće:• null status• tip podataka• default vrednosti• ograničenja podataka

Null status: Definiše da li kolona može da ima null vrednost. Dozvoljena null vrednost sedefiniše frazom NULL dok se nedozvoljena definiše sa NOT NULL. NULL ne znači da je kolonauvek NULL već znači da su dozvoljene NULL vrednosti.Tip podataka: Svaki DBMS ima neke svoje specifične tipove podataka koje koristi. Međutimako se želi postići nezavisnost od konkretnog DBMS mogu se specificirati generički tipovipodataka gde spadaju:• CHAR(n) – karakter string fiksne dužine• VARCHAR(n) - karakter string promenljive dužine• DATE• TIME• MONEY• INTEGER• DECIMAL

Default vrednost: To je vrednost koju generiše DBMS priliko kreiranja redova tabele. Tavrednost može biti konstanta ili rezultat neke funkcije kao što je sistemski datum ili vreme.Nekada se defaul vrednosti sračunavaju korišćenjem mnogo složenije logike, za šta senajčešće koriste trigeri.

Ograničenja podataka: Postoje nekoliko različitih ograničenjana vrednosti podataka:• Domen – kojim se vrednost kolona ograničava na određeni skup vrednosti. Npr.

KodZaposlenog može biti ograničen vrednostima ( ’novo zaposleni’, ’stalno zaposlen’,’honorarno zaposlen’ itd.)

• Opseg vrednosti – kojim se vrednosti ograničavaju na određeni interval. Npr. datumzaposlenja može biti u opsegu od 1. januara 1990 do 31. decembra 2007. godine.

• Intra relaciono ograničenje – ograničava vrednost kolone u odnosu na druge kolone istetabele. Npr. datum provere može biti najmanje 3 meseca posle datuma zaposlenja. Interrelaciono ograničenje ograničava vrednost kolone u odnosu na druge kolone drugih tabela.Ograničenje referencijalnog integriteta je jedan tip inter relacionog ograničenja.

Na kraju procesa transformacije etiteta iz E/R modela u tabele baze podatka treba proveritida li su tabele normalizovane. Drugim rečima treba dati odgovor na pitanje da li da litabele u BSNF i da li su otklonjene sve funkcionalne zavisnosti. Ukoliko nisu, tabele treba


normalizovati. Kako je normalizacija u nekim slučajevima nepoželjna, treba proveriti da linormalizovane tabele treba denormalizovati.Sledeći korak je transformisati veze između tipova entiteta.

Transformacija E/R modela u relacioni model baza podataka:max kardinalnost 1:1

Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti. Mogu se izdvojiti dve grupepravila: za transformaciju entiteta i transformaciju veza. Generalno, veza se transformišustavljanjem stranog ključa u tabele. Način na koji se to radi i svojstva kolona stranog ključazavise od maksimalne kardinalnosti relacije. Postoje tri tipa maksimalne kadinalnosti 1:1, 1:N iN:M. Ovde će biti reči o pravilima za veze (relacije) tipa 1:1.


Transformacija E/R modela u relacioni model baza podataka: veze sa maksimalnomkardinalnošću 1:1Veza sa maksimalnom kardinalnošću jedan-prema-jedan (1:1) između dva entiteta A i B, možebiti predstavljena na jedan od više načina:• Dodavanjem primarnog ključa relacije A kao stranog ključa u B.• Dodavanjem primarnog ključa relacije B kao stranog ključa u A.

Primer:

(b) sa stranim ključem u tabeli CLIB_MEMBER

Transformacija E/R modela u relacioni model baza podataka:veze sa max kardinalnošću tipa 1:N


Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti. Mogu se izdvojiti dve grupepravila: za transformaciju entiteta i transformaciju veza. Generalno, veza se transformišustavljanjem stranog ključa u tabele. Način na koji se to radi i svojstva kolona stranog ključazavise od maksimalne kardinalnosti relacije. Postoje tri tipa maksimalne kadinalnosti 1:1, 1:N iN:M. Ovde će biti reči o pravilima za veze (relacije) tipa 1:N.


Transformacija E/R modela u relacioni model baza podataka: veze sa maksimalnomkadinalnošću tipa 1:NVeza sa maksimalnom kardinalnošću jedan-prema-više (1:N) se predstavlja spuštanjematributa primarnog ključa relacije koji je na strani veze jedan, kao stranog ključa u relacijukoja je na strani veze više.

Podsetimo se da je termin roditelj korišćen za tabelu na strani jedan a termin dete za tabeluna strani više. Korišćenjem ove terminologije za dizajn 1:N veze se može reći da predstavlja„Spuštanje ključa roditelja u dete.”

Primer:

(b) Spuštanje ključa roditelja u dete

Transformacija E/R modela u relacioni model baza podataka:veze sa max. kardinalnošću M:N

Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti. Mogu se izdvojiti dve grupepravila: za transformaciju entiteta i transformaciju veza. Generalno, veza se transformišustavljanjem stranog ključa u tabele. Način na koji se to radi i svojstva kolona stranog ključa


zavise od maksimalne kardinalnosti relacije. Postoje tri tipa maksimalne kadinalnosti 1:1, 1:N iN:M. Ovde će biti reči o pravilima za veze (relacije) tipa 1:N.


Transformacija E/R modela u relacioni model baza podataka: veze sa maksimalnomkardinalnošću tipa M:NPretpostavimo da postoji binarna više-prema-više veza (ili asocijativni entitet) između dva tipaentiteta A i B. Za takvu vezu se kreira posebna relacija C. Primarni ključ te relacije je složeniključ koji se sastoji od primarnih ključeva svake od dve relacije dobijene transformacijomentiteta koji učestvuju u M:N vezi. Bilo koji atribut koji nije ključ a koji je pridružen vezi M:N jeuključen u relaciju C.

Primer:

(a) strani ključ nema nesta ni u jednoj tabeli

(b) stavljanje oba strana ključa u ID nezavisnu ubačenu tabelu

Napomenimo da se svaka M:N veza može uvek korišćenjem dodatne tabele dekomponovatina dve 1:N veze. Neki CASE alati nemaju mogućnost da predstave M:N veze u modelupodataka pa projektant mora da ovu transformaciju izvrši tokom faze modeliranja podataka.Međutim, ovakav zahtev se može smatrati neopravdanim jer u modeliranje podataka unosisloženost a logika modeliranja je upravo smanjenje složenosti.


Transformacija E/R modela u fizički model baza podataka:asocijativne veze

Uvodne napomenePrilikom transformacije E/R modela u relacioni fizički model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti.Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza.Generalno, veza se transformišu stavljanjem stranog ključa u tabele. Način na koji se to radi isvojstva kolona stranog ključa zavise od maksimalne kardinalnosti relacije. Ovde će biti reči opravilima za asocijativne veze koje su slične relacijama tipa N:M.

Cilj• Prikazati način transformacija E/R modela u fizički model baza podataka

Transformacija E/R modela u fizički model baza podataka: asocijativne vezeAsocijativne relacije veoma slične N:M relacijama i jedina razlika je u tome što asocijativnerelacije imaju jedan ili više atributa koji su dodeljeni toj relaciji a ne entitetima koji u njojučestvuju.

Primer:

(a) asocijativni entitet između entiteta KOMPANIJA i DEO


(b) tabele koje predstavljaju entitete

Asocijativni entiteti često povezuju više od dva tipa entiteta i predstavljaju ternarne ilikvaternarne relacije. U tom slučaju asocijativna relacija će sadržati ključeve svakog od svojihroditelja što je prikazano na sledećem primeru.

Primer:

(a) asocijativni entitet za tri entiteta KLIJENT, ARHITEKTA i PROJEKAT


(b) tabele koje predstavljaju entitete

Transformacija E/R modela u fizički relacioni model bazapodataka: atributi sa više vrednosti

Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti.Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza. Ovde ćebiti reči o pravilima za transformaciju atributa sa više vrednosti.


Transformacija E/R modela u relacioni model baza podataka: atributi sa viševrednostiSvaki atribut sa više vrednosti se može predstaviti ID zavisnim entitetom. Neka entitetKompanija koji ima atribute imeKompanije, grad, zemlja itd. kao i atribut sa više vrednostiKontakt_telefon. Taj se entitet može predstaviti sa dva entiteta, što je predstavljeno na slici.


Slika: Transformacija atributa sa više vrednosti

(a) E/R model kojim se može predstaviti atribut sa više vrednosti(b) tabele kojima se mogu predstaviti entiteti

Prilikom transformacije u relacije, entitet Kontakt_telefon treba transformisati u tabelu i svakinjen atribut predstaviti kolonom. U ovom slučaju atribut ImeKompanije je i deo primarnogključa i strani ključ.

Transformacija E/R modela u relacioni model baza podataka:podklase

Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti.

Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza. Ovde ćebiti reči o transformaciji veze specijalizacije kojom se neka super klasa deli na podklase.


Transformacija E/R modela u relacioni model baza podataka: modeli sa mešovitimrelacijamaPredstavljanje relacije podklasa je lako jer podklasa i njegova supe klasa predstavljaju istientitet. ZAPOSLENI (EMPLOYEE) je MENADZER (MENAGER) a MENADZER je ZAPOSLEN. Zbogpostojanja ovakve jednakosti svi ključevi tabela podklasa su identični ključevima tabelanadklasa što je prikazano na slici.


Slika: Transformacija relacije podtipova

ZaposlenBroj je i primerni ključ i strani ključ u svojim podtipovima.

Transformacija E/R modela u relacioni model baza podataka:mešovite relacije

Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti. Mogu se izdvojiti dve grupepravila: za transformaciju entiteta i transformaciju veza. Generalno, veza se transformišustavljanjem stranog ključa u tabele. Način na koji se to radi i svojstva kolona stranog ključazavise od tipa relacije. Postoje tri tipa veza između jakih entiteta 1:1, 1:N i N:M. Ovde će bitireči o transformaciji modela sa mešovitim relacijama.


Transformacija E/R modela u relacioni model baza podataka: modeli sa mešovitimrelacijamaPrimer jednog takvog modela je predstavljen na sledećoj slici.


Slika: Primer modela sa mešovitim relacijama

NARUDŽBENICA (SALES_ORDER) na slici imaID zavistan entitet STAVKA_NARUDŽBENICE(ORDER_LINE_ITEM) u kojoj je broj narudžbenice (SalesOrderNumber) kao strani ključ, deonjenog primarnog ključa. BrojStavke(ItemNumber) je strani ključ. (slika “Transformacijamodela sa mešovitim relacijama”)

Slika: Transformacija modela sa mešovitim relacijama

Transformacija E/R modela u relacioni model baza podataka:Unarne (rekurzivne) relacije


Uvodne napomenePrilikom transformacije E/R modela u relacioni model baza podataka se koriste jasnodefinisana pravila koja su ugrađena u CASE alate. U slučaju kada je E/R model urađen unekom CASE alatu, ta transformacija se može automatski obaviti.Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza.Generalno, veza se transformišu stavljanjem stranog ključa u tabele. Način na koji se to radii svojstva kolona stranog ključa zavise od maksimalne kardinalnosti relacije. Ovde će biti rečio transformaciji unarnih (rekurzivnih) relacija koje mogu imati maksimalne kadinalnosti 1:N iN:M


Transformacija E/R modela u relacioni model baza podataka: Unarne (rekurzivne)relacijeUnarna (rekurzivna) relacija može imati kardinalnost jedan-prema-više ili više-prema-više.

Razmotrimo unarnu 1:M relaciju prikazanu na slici “Transformacija narne (rekurzivne) jedan-prema-više veze”

Slika: Transformacija narne (rekurzivne) jedan-prema-više veze

Kao i u slučaju drugih tipova 1:M relacija, tip entiteta (kao što je ZAPOSLEN) se modelira kaorelacija. Njen primarni ključ je isti kao i za tip entiteta. Tada se relaciji dodaje strani ključ kojise referencira na vrednost primarnog ključa. Rekurzivni strani ključ je strani ključ u relaciji kojise referencira na vrednost primarnog ključa iste relacije. Relacija koja odgovara slici se možepredstaviti slikom 4.b.

Unarna (rekurzivna) M:N veza: Najčešće se predstavlja primerom prikazanim na sledećoj slicipod (a), koji se naziva struktura sastavnice. Kao i slučaju drugih tipova M:N veza, tip entitetamodeliramo kao relaciju a zatim kreiramo posebnu relaciju da bismo predstavili M:N vezu.Primarni ključ te nove relacije je složeni ključ koji se sastoji od dva atributa (koji ne morajuda imaju isto ime) a koji uzimaju vrednost iz istog primarnog ključa. Ako je relaciji pridruženjedan ili više atributa (npr. Atribut kolicina), oni su u novu relaciju uključeni kao atributi kojinisu primarni ključevi. Rezultat transformacije je prikazaa na sledećoj slici pod (b):


(b)

Slika: Transformacija unarne (rekurzivne) više-prema-više veze

Transformacija E/R modela u relacioni model bazapodataka:Primer


Transformacija E/R modela u relacioni model baza podataka: PrimerNa sledećoj slici je pretstavljem E/R model bate podataka jednog Univerziteta.

Slika: E/R model baze podataka jednog Univerziteta


Primenom praila za transformaciju E/R modela u relacioni model baze podataka, dobijen jedijagram prikazan na slici “Transformisani E/R model u relacioni model”.

Slika: Transformisani E/R model u relacioni model

Na slici stoji napomena da DepartmentName u tabeli STUDENT treba da se kao strani ključpojavi dva puta: jedanput da predstavi relaciju između entiteta STUDENT i DEPARTMENT adrugi put kao deo kompozicije (DepartmentName, ProfessorFirstName, ProfessorLasttName)što je strani ključ koji se dobija iz relacije između APPOINTMENT i STUDENT.

Izostanak drugog pojavljivanja DepartmentName u tabeli STUDENT je greška CASE alata(u ovom slučaju Erwin-a); on ne može da isti atribut u tabeli pojavi dva puta. Ovaj primerilustruje zašto je potrebno da znate principe dizajniranja baze podataka iako CASE alati kaošto je Erwin mogu da umesto vas kreiraju taj dizajn. Generisani dizajn ne mora da uvek budetačan.

Formiranje fizičkog modela

Cilj• Kreiranje fizičkog modela

Kreiranje fizičkog modelaKao što je već rečeno kada smo govorili o Power Designeru fizički model se kreira:• Iz konceptualnog modela, transformacijom i dodatnim uređivanjem i obogaćivanjem

modela• Iz postojeće baze podataka, reversnim inženjerinogom i dodatnim uređivanjem i

obogaćivanjem modela• Identifikacijom i specifikacijom osnovmih elemenata od kojih se sastoji



Nakon kreiranja fizičkog modela, možemo izabrati šta da se vidi u dijagramu.


Imenovanje referenci:


Pregled tabela, kolona, ključeva i indeksa:





Osnovni elementi fizičkog modela

Cilj• Osnovni elementi fizičkog modela

Osnovni elementi fizičkog modelaFizički model podataka predstavlja reprezentaciju dizajna struktura podaka, ali izumajući uobzir ograničenja i elemente koje obezbeðuje ciljana sistem za upravljanje bazama podataka.Drugim rečima, omogućuje predstavljanje dizajna sa tačke gledišta fizičke implementacije.Fizički model podataka se formira na kraju procesa analize struktura podataka.Fizički Model prikazuje Tabele, Njihove Kolone, Ključeve (Primarni, Sekundarni, Alternativni),Indekse, Reference, Ograničenja. Predstavlja šemu baze podataka na zadatom/izabranomRDBMS I koristi se za generisanje niza komandi čijim izvršavanjem se formira i inicijalizujebaza podataka.Osnovni elementi fizičkog modela su:Tabela – Osnovni elemenat manipulacijeTabela predstavlja dvodimenzionalnu šemu(skup).

• Matrica koja se sastoji od vrsta i kolona


• Vrste – vertikalna dimenzija – zapisi (records)

– skup vrednosti atributa,

• Kolone – horizontalna dimenzija – atributi

– Vrste su osnovna jedinica manipulacije

Tabela je semantička celina – skup vrednosti povezanih u celinu zadatog značenja,– Sve vrste u tabeli imaju istovetnu strukturu,• AKA – Vrsta(Row), Zapis(Record), Slog (Tuple)

Pristup podacima u tabeli se vrši kroz selekciju/projekciju po dimenzijama:• Podskup kolona – izbor atributa• Podskup vrsta– Kriterijum za izdvajanje željenih vrsta,– Nastaje preslikavanjem Entiteta• Entitet = Tabela• Atribut = Kolona– Svaka kolona je zadatog tipa koji je podržan od strane RDBMS,– Skup tipova podataka predefinisan odgovarajuæim RDBMS

Kolone - Osnovna ćelija zapisa

- Osnovne jedinice čuvanja podatakaNastaju od atributa i definisani su tipovima i ograničenjima. Predstavljaju jednu dimenzijutabele. Kolone koje pripadaju ključu ne mogu imati ponavljajućih kombinacija vrednosti.

Ključevi

- Primarni ključevi - postoji tačno jedan primarni ključSastoje se od jedne ili više kolona tabele, Bilo koja kombinacija vrednosti kolona primarnogključa uvek određuje tačno jedan slog tabele. Vrednosti kolona primarnog ključa ne mogu bitinedefinisane.Nastaju preslikavanjem Identifikatora u slučaju definišuće relacije (prethodnovežbanje) kada kolone primarnog ključa nadređene tabele postaju deo primarnog ključapodređene tabele. Praćeni su indeksima koji se koriste za unapređene performansi upita.

- Strani KljučeviSastoje se od jedne ili više kolona tabele. Strani ključ definiše referencu između tabela.Vrednosti kolona stranog ključa mogu biti nedefinisane ako referenca nije obavezna. Nastajupreslikavanjem Identifikatora u slučaju nedefinišuće relacije (prethodno vežbanje) kada koloneprimarnog ključa nadređene tabele postaju strani ključ poređene tabele. Praćeni su indeksimakoji se koriste za unapređenje performansi upita.

Alternativni (Jedinstveni) ključevi

Sastoje se od jedne ili više kolona tabele. Bilo koja kombinacija vrednosti kolona alternativnogključa uvek određuje tačno jedan slog tabele. Vrednosti kolona alternativnog ključa ne mogubiti nedefinisane. Kako tabela može imati tačno jedan primarni ključ alternativni ključeviomogućavaju alternativu za jedinstvenu selekciju sloga. Praćeni su indeksima koji se koristeza unapređene performansi upita.


Ključevi mogu imati dva koncepta upotrebe:

1. Prirodni Ključevi kao Identifikatori – Upotreba prirodnih vrednosti atributa za Identifikatore.Mana je što korisnik može da izvrši promenu vrednosti primarnog ključa. Održavanjereferencijalnog integriteta je komplikovano. Lakše se manipuliše preko prirodnih i razumljivihvrednosti kolona primarnog ključa.

2. Surogat-Generisani Ključevi kao Identifikatori – Generisanje brojača pojava od straneRDBMS. Prednost je što korisnik nikada ne vidi niti može da menja vrednost ključa.Održavanje referencijalnog integriteta je jednostavnije. Mana je to što teško se održava.

Reference

Reprezentuju referenciranje sloga u podređenoj tabeli sa slogom u nadređenoj tabeli prekostranog ključa. Referenciranje se obavlja izjednačavanjem vrednosti jedne ili više kolonau povezanim tabelama grupisane kao strani ključ. Nastaju preslikavanjem relacije. KoloneIdentifikatora Nadređenog Entiteta postaju kolone Podređenog Entiteta. RDBMS održavareferencijalni integritet i obezbeđuje da su reference validne.

Reference su definisane:• Skupom kolona stranog ključa koje se izjednačavaju po vrednosti da bi se uspostavila

referenca između dva sloga• Kardinalnošću (1:1, 1:n)- n:m se pretvara u dodatnu tabelu sa kojom polazne tabele imaju 1:n odnos• Specifikacijom referencijalnog integriteta- Specifikacija ograničenja promene ili brisanja sloga- Način održavanja integriteta- Update, delete constraints• Naziv ograničenja

Reference nastaju preslikavanjem relacija. Atributi Identifikatora Nadređene Tabele se kopirajuu podređenu tabelu i postaju njene kolone. Definiše se skup vrednosti kolona koje se porede.Kod zavisne relacije kolone koje se kopiraju postaju deo primarnog ključa podređene tabele.Uspostavlja se ograničenje referencijalnog integriteta ( Kardinalnost Relacije = KardinalnostReference ). Broj pojava (Mandatory) se takođe preslikava. Vrsta ograničenja se postavlja napodrazumevanu vrednost.

Vrste referencijalnog ograničenja:• Primenjuju se na Update i Delete akcije• Restrict- Promena vrednosti kolona stranog ključa u nadređenoj, podređenoj tabeli nije dozvoljena- Brisanje sloga nadređene tabele nije dozvoljeno• Cascade- Promena vrednosti stranog ključa u nadređenoj tabeli će biti sprovedena i nad nijednim,jednim ili više slogova podređene tabele- Brisanje sloga nadređene tabele će prethodno obrisati nijedan, jedan ili više slogovapodređene tabeleVrste referentnog ograničenja:


• Set null- Promena vrednosti kolona primarnog ključa u nadređenoj tabeli će dovesti do postavljanjanull vrednosti u svim kolonama stranog ključa u nijednom, jednom ili više slogova podređenetabele- Brisanje sloga nadređene tabele će dovesti do postavljanja null vrednosti u svim kolonamastranog ključa u nijednom, jednom ili više slogova podređene tabele• Set Default

Primer:

Ograničenja (Constraints)Definiše pravila koja je potrebno proveriti pre nego što se vrednost zapiše u kolonu. Izvodi seiz domena konceptualnog modela. Postoje nekoliko vrsta:• Strani ključevi – referencijalni integritet• Not null – vrednost mora biti definisana• Enumeration – vrednost može biti iz skupa nabrojanih vrednosti• Validacija – pravila koja ograničavaju skup mogućih vrednostiOgraničenja se proveravaju se na nivou vrste.IndeksiNisu direktno deo šeme niti relacionog modela. Koriste se radi unapređivanja performansimanipulacije podacima. Nastaju primenom posebnog mehanizma zapisa i rukovanja nadvrednostima izabranog podskupa kolona. Realizovani kao posebni skup zapisa, specijalnatabela. Slogovi indeksa pokazuju na slogove tabele.Koriste za efikasnije izdvajanje podskupa slogova koji zadovoljavaju postavljene uslove.Pretraživanje tabele se sprovodi pretraživanjem indeksa (brže zbog prilagođenog načinačuvanja). Skup slogova indeksa, koji zadovoljavaju uslov, ukazuje na skup slogova koji takođezadovoljavalju postavljen uslov. Tabela može imati nijedan, jedan ili više indeksa. Ključevi suskoro uvek praćeni indeksima. Pretpostavlja se da će se vrednosti ključevi koristiti za selekcijupodskupa slogova.Vrste indeksiranja:


• B Tree – Binarno stablo• Bitmap – binarna reprezentacija vrednosti (0,1)• ISAM – sortirana lista slogova po broju sloga• Hash – primenom Hash algoritma nad vrednostima

Primer fizičkog modela

Cilj• Primer fizičkog modela

Primer fizičkog modelaZa projektovani konceptualni model podataka informacionog sistema jedne savremeneuniverzitetske biblioteke.prikazanog na sledećoj slici napravite fizički model podataka.

Slika: Konceptualni model-primer 1

File: IT2008-IM-DMOD-EERD-PrimerKonceptualnogModela-Primer1.cmd


Fizički model koji je dobijen iz konceptualnog modela prikazan je na sledećoj slici:



Slika: Fizički model-primer 1

Transformacija konceptualnog u fizički (relacioni) model

Cilj• Prikazati primer izrade relacionog modela

Transformacija konceptualnog u logički (relacioni) modelNa slici “E/R dijagram Sistema za Internet prodaju u CD Selections” je prikazan konceptualnimodel koji treba transformisati u fizički relacioni model baze podataka korišćenjemPowerDesigner-a (koristiti fajl E/R dijagram Sistema za Internet prodaju u CD Selections)

Slika: E/R dijagram Sistema za Internet prodaju u CD Selections

File: IT2008-IM-DMOD-EERD-Identifikovanje entiteta, atributa i relacija-E-R CD Selectionsazurirana verzija

Nakon izvršene transformacije, izvršiti verifikaciju dobijenog relacionog modela. Fizički modelje prikazan na sledećoj slici


Slika:Fizički model Sistema za Internet prodaju u CD Selections

Transformacija E/R modela u relacioni model baza podataka:min kardinalnosti-obavezan roditelj


Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza.Generalno, veze se transformišu stavljanjem stranog ključa u tabele. Svojstva kolona stranogključa zavise pored maksimalne zavise i od minimalne kardinalnosti relacije.

Relacije mogu imati četiri minimalne kadinalnosti: opcione i roditelje i decu (O-O), Obavezneroditelje a opcionu decu (M-O), opcione roditelje a obaveznu decu (O-M) i obavezne roditelje iobaveznu decu (M-M). Analiza je obavljena u dva pravca; za slučaj kada su obavezni roditelji(relacije M-O i M-M) i za slučaj kada su obavezna deca (O-M i M-M). U slučaju relacije O-O netreba preduzimati nikakve akcije.

Ovde će biti reči o akcijama u slučaju obaveznog roditelja.



Transformacija E/R modela u relacioni model baza podataka: Dizajniranjeminimalne kardinalnosti-obavezan roditeljU slučaju obaveznog roditelja, potrebno je obezbediti da svaki red tabele deteta ima validan,not-null strani ključ. Da bi se to postiglo potrebno je ograničiti akcije ažuriranja i brisanjaprimarnog ključa roditelja i akcije kreiranja i modifikovanja stranog ključa kod dece.

Akcije nad redovima roditelja u slučaju obaveznog roditelja:U slučaju kreiranja novog roditelja ne treba raditi ništa jer ni jedan red deteta još uvek nezavisi od tog novog reda.U slučaju pokušaja da se promeni vrednost postojećeg primarnog ključa reda roditelja,morale bi se promeniti sve postojeće vrednosti stranih ključeva dece (ako ih ima) tako da sepodudaraju sa novim vrednostima primarnih ključeva roditelja ili se modifikacija primarnihključeva roditelja mora zabraniti. Politika menjanja stranih ključeva dece saglasno primarnimključevima roditelja se naziva kaskadno ažuriranje.U slučaju da se izbriše red tabele roditelja, moraju se brisati i svi postojeći odgovarajućiredovi tabele dece (ako ih ima) ili se brisanje mora zabraniti. Brisanje dece saglasno brisanjuroditelja se zove kaskadno brisanje.

Akcije nad redovima dece u slučaju obaveznih roditelja:U slučaju kreiranja novog reda dece, važno je obezbediti da taj red ima validan strani ključ,ako se on zahteva. Ako toga nema, kreiranje reda nije dozvoljeno. Često, postoji neka defaulvrednost koja se dodeljuje stranom ključu i odgovara vrednosti primarnog ključa roditelja.U slučaju da se strani ključ menja, nova vrednost mora da se podudara sa vrednošćuprimarnog ključa roditelja. U suprotnom, menjanje je zabranjeno.U slučaju brisanja redova dece, nema nikakvih restrikcija. Redovi dece se mogu izbrisati bezikakvih konsekvenci na redove roditelja.

Akcije koje treba preduzeti u slučaju obaveznog roditelja se sumarno mogu prikazati sledećomtabelom:

Tabela: Akcije u slučaju obaveznoh roditelja nad redovima roditelja i dece


Transformacija E/R modela u relacioni model baza podataka:min kardinalnosti-obavezna deca


Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza.Generalno, veza se transformišu stavljanjem stranog ključa u tabele. Svojstva kolona stranogključa zavise od maksimalne i od minimalne kardinalnosti relacije.

Relacije mogu imati četiri minimalne kadinalnosti: opcione i roditelje i decu (O-O), obavezneroditelje a opcionu decu (M-O), opcione roditelje a obaveznu decu (O-M) i obavezne roditeljei obaveznu decu (M-M). Analiza se obavlja u dva pravca; za slučaj kada su obavezni roditelji(relacije M-O i M-M) i za slučaj kada su obavezna deca (O-M i M-M). U slučaju relacije O-O netreba preduzimati nikakve akcije.

Ovde će biti reči o akcijama u slučaju obavezne dece.


Transformacija E/R modela u relacioni model baza podataka: Dizajniranjeminimalne kardinalnosti-obavezna decaAko su obavezna deca, to znači da treba obezbediti bar jedan red u tabeli dece za svakired tabele roditelja. Poštovanje ovog ograničenja je mnogo teže od prethodnih kada jeobavezan roditelj. Obaveznost roditelja se može obezbediti usaglašavanjem vrednosti stranihi primarnih ključeva dok se za proveru obaveznosti dece mora uvek sračunavati broj dece kojije pridružen svakom roditelju za šta treba napisati odgovarajući kod.

Akcije nad redovima roditelja kada su obavezna deca:Kreiranje novog reda roditelja podrazumeva i kreiranje reda dece. To znači da moramo ilinaći neki postojeći red u tabeli dece i promeniti njegov strani ključ tako da se podudara saprimarnim ključem roditelja ili moramo kreirati novi red dece u istom trenutku kada kreiramo ired roditelja. Ako se ne preduzmu obe akcije, kreiranje je zabranjeno.


U slučaju da se primarni ključ roditelja ažurira, mora se ažurirati i strani ključ bar jednog redadeteta ili se ažuriranje ne sme dozvoliti. Ovo ograničenje se nikad ne odnosi na roditelje sasurogat ključem jer se njegova vrednost nikada ne menja.Ako se red roditelja izbriše, ne treba preduzimati nikakve akcije, jer obavezno je postojanjedeteta a ne roditelja.

Akcije nad redovima dece kada su obavezna deca:Prilikom ubacivanja novog reda dece ne treba preduzimati nikakve akcije.Prilikom ažuriranja stranog ključa dece, ne postoje nikakve restrikcije osim u specijalnomslučaju kada je dete zadnje za datog roditelja. U tom slučaju se ažuriranje ne sme izvršiti.Međutim, da bi se odredio broj dece za datog roditelja, potrebno je napisati proceduruPrilikom brisanja redova dece postoje slične restrikcije kao i prilikom ažuriranja.

Akcije koje treba preduzeti u slučaju obavezne dece se sumarno mogu prikazati sledećomtabelom:

Tabela: Akcije nad redovima roditelja I dece kada su obavezna deca

Transformacija E/R modela u relacioni model baza podataka:Implementiranje akcija koje podržavaju dizajniranje minimalnekardinalnosti



Mogu se izdvojiti dve grupe pravila: za transformaciju entiteta i transformaciju veza.Generalno, veza se transformišu stavljanjem stranog ključa u tabele. Svojstva kolona stranogključa zavise od maksimalne i od minimalne kardinalnosti relacije.

Relacije mogu imati četiri minimalne kadinalnosti: opcione i roditelje i decu (O-O), obavezneroditelje a opcionu decu (M-O), opcione roditelje a obaveznu decu (O-M) i obavezne roditeljei obaveznu decu (M-M). Analiza se obavlja u dva pravca; za slučaj kada su obavezni roditelji(relacije M-O i M-M) i za slučaj kada su obavezna deca (O-M i M-M). U slučaju relacije O-O netreba preduzimati nikakve akcije.

Ovde će biti reči o implementiranju akcija koje podržavaju dizajniranje minimalnekardinalnosti za sve četiri vrste: opcione i roditelje i decu (O-O), obavezne roditelje a opcionudecu (M-O), opcione roditelje a obaveznu decu (O-M) i obavezne roditelje i obaveznu decu (M-M).


Implementiranje akcija koje podržavaju dizajniranje minimalne kardinalnostiU sledećoj tabeli su sumirane akcije koje treba preduzeti u aplikaciji da bi se podržao svaki odtipova minimalne kardinalnosti.

Tabela: Akcije koje treba podržati za svaki od tipova minimalne kardinalnostiImplementiranje akcija koje podržavaju M-O kardinalnost: (potrebno je da svako deteima svog roditelja). Ove akcije obezbeđuje sam DBMS korišćenjem dva ograničenja:Definisanjem ograničenja referencijalnog integriteta koji obezbeđuje da svaka vrednoststranog ključa ima odgovarajuću vrednost u tabeli roditelja.Na primer: ImeOdeljenja u ZAPOSLENI mora da postoji u ImeOdeljnja u ODELJENJEStavljanjem karakteristike NOT NULL za kolonu stranog ključa. Postoji i opcija kojom sedefiniše da li ažuriranje i brisanje kaskadno ili je zabranjeno.

Implementiranje akcija koje podržavaju O-M kardinalnost: DBMS ne obezbeđuje oveakcije već se one mogu implementirati korišćenjem trigera.


Sa strane roditelja, treba napisati trigere na INSERT i UPDATE redova u tabeli roditelja kojimatreba ili kreirati odgovarajući red u tabeli deteta ili “ukrasti” postojeći red deteta od nekogdrugog roditelja. Ako se ove akcije ne mogu izvršiti, INSERT i UPDATE se moraju zabraniti.Sa strane deteta, red deteta se može insertovati bez ikakvih problema. Kada se dete vežeza roditelja, ta se veza ne može ukinuti ako je to zadnje ili jedino dete. To znači da za redovedece treba napisati trigere na UPDATE i DELETE sa sledećom logikom: Ako je strani ključ null,red nema svog roditelja pa se UPDATE i DELETE mogu dozvoliti. Ako strani ključ mora daima vrednost, proveriti da li je red deteta zadnji. Ako jeste, red roditelja se mora brisati ili seUPDATE i DELETE moraju zabraniti.

Primer transformacije E/R modela u relacioni model

Cilj• Prikazati jedan primer transformacije E/R modela u relacioni model

Primer transformacije E/R modela u relacioni modelView Ridge je mala umetnička galerija koja prodaje umetničke predmete iz Evrope i SeverneAmerike uključujući litografije, originalne slike i fotografije. Ona poslije skoro 30 godina i imasvog vlasnika i troje zaposlenih. Zahtevi za izradu aplikacije koja treba da podrži poslovanjeove galerije su:Da se evidentiraju i prate svi kupci i njihovo interesovanje za pojedinim umetnicimaDa se evidentiraju sve porudžbine koje izvrši galerijaDa se evidentiraju sve porudžbine kupacaDa se formira lista svih umetnika i njihovih radovaDa se omogući izveštavanje o tome koliko brzo su radovi pojedinih umetnika prodatiDa se prikaže tekuće stanje zalihaPrvo, vlasnik i prodavci žele da beleže imena, prezimena, adrese, telefone, email-ove svojihkupaca. Oni takođe žele da znaju kojim se kupcima sviđaju koji umetnici.

Kada galerija kupi novi umetnički predmet, beleže se podaci o umetniku, prirodi umetničkograda, datumu nabavke i ceni nabavke. Galerija može da od kupca koji je kupio neki umetničkirad, taj radotkupi i ponovo ga proda, tako da se jedan rad u galeriji može pojaviti više puta. Kada seumetnički rad otkupi od kupca koji ga je kupio, podaci o umetniku i umetničkom radu se neunose ponovo u bazu ali se unosi novi datum i cena nabavke. Takođe, kada se umetničko deloproda, u bazi podataka se pamte datum i cena prodaje i identitet kupca.

Podaci žele da analiziraju datume kupovine kako bi za najaktivnije kupce mogli da izdvoje viševremena. Oni takođe često koriste podatke o kupovini kako bi pronašli lokacije umetničkihradova na kojima su oni zadnji put prodati.

Za marketinške svrhe, galerija želi da iz baze podataka dobije listu umetnika i radova koji suse pojavili u galeriji. Vlasnik takođe želi da odredi koliko se brzo prodaje jedno umetničko deloi koje su margine prodaje.

Na slici 1. je prikazan model podataka za bazu podataka View Ridge galerije. Ovaj modelima dva jaka entiteta: CUSTOMER (kupac) i ARTIST (umetnik). Pored toga, entitet WORK


(umetnički rad) je ID zavistan od ARTIST a entitet TRANSACION (transakcija) je ID zavistan odWORK.

Umetnik (ARTIST) se može uneti u bazu podataka čak i ako se ni jedan njegov rad ne pojaviu galeriji. Tako umetnik može imati 0 ili 1 umetnički rad. Identifikator entiteta umetnički rad(WORK) je složen (Naslov i Kopija) jer u slučaju litografija i slika može postojati više kopijaza dati naslov. Takođe, jedan umetnički rad se u galeriji može pojaviti više puta pa postojipotreba da se za svaki umetnički rad pamti više transakcija (TRANSACTION). Svaki put kadase umetnički rad pojavi u galeriji, moraju se zabeležiti datum i cena nabavke, pa za svakiumetnički rad mora da postoji bar jedan red u entitetu transakcija.

Kupac može da kupi više radova što se beleži kao relacija 1:M između CUSTOMER iTRANSACION. Ova relacija je opciona u oba smera. Na kraju, između CUSTOMER I ARTISTmostoji relacija N:M.

Slika: Model podataka za bazu podataka View Ridge galerije

Dizajn baze podataka za model podataka sa slike 1. je prikazan na slici 2. Iz dizajna semože videti da su svi primarni ključevi osim ARTIST.name problematični. Ključevi za WORK iTRANSACION su suviše veliki a ključ za CUSTOMER može biti sumnjiv jer neki kupci ne morajuimati email. Zbog ovih problema su kreirani surogat ključevi.

Slika: Dizajn baze podataka za model podataka sa slike 1.

Dizajn baze podataka sa surogat ključevima je prikazana na slici 3.


Slika: Dizajn baze podataka sa surogat ključevima

Domaći zadatak

Domaći zadatak1. Krirane konceptualne modele iz zadatka 8, korišćenjem Power Designer-a, transformišiteu fizičke realcine modele. Izvršite verifikaciju dobijenih modela. Sliku dobijenog relacionogmodela smestite u fajl:

IT350-DZ09-Ime_Prezime_brIndexa.docgde su Ime, Prezime i brIndexa vaši podaci. Dokument poslati predmetnom asistentu.

Lekcija-9-Predavanja

ZaključakU ovom predavanju je opisan proces transformacije konceptualmog modela baze podataka ulogički, relacioni model na konkretnom primeru baze podataka univerziteta. Kroz ovaj primerje prikazan način transformacije entiteta, atributa, relacija zavisno od njihove kardinalnostiu odgovarajuće elemente relacija koje sačinjavaju logički model podataka. Opisan je i načintransformacije elemenata naprednijih E/R modela kao što su slabi entiteti, asocijativneveze, rekurzivne relacije, generalizacija i specijalizacija. Naročita pažnja je posvećenatransformacija minimalne kardinalnosti veza i njen uticaj na način dobijanja sekundarnihključeva.

Documents

IT2008 IM BazePodataka IT350 Bazepodataka L09