Logičko projektovanje baza podataka

dr Gordana Pavlović-Lažetić
januar 2008.

1. Relaciona baza podataka – pojam i svojstva

Pojam baza podataka pojavio se krajem šezdesetih godina 20. veka i označavao je
skup međusobno povezanih podataka koji se čuvaju zajedno, i među kojima ima samo
onoliko ponavljanja koliko je neophodno za njihovo optimalno korišćenje pri
višekorisničkom radu. Podaci se pamte tako da budu nezavisni od programa koji ih
koriste, i struktuiraju se tako da je omogućen porast baze. Posle svake aktivnosti nad
bazom, koja predstavlja logičku celinu posla, stanje baze mora biti konzistentno
(valjano); to znači da podaci u bazi i odnosi među njima moraju zadovoljavati unapred
zadate uslove koji odslikavaju deo realnosti modelirane podacima u bazi.

U razvoju sistema baza podataka može se uočiti nekoliko generacija sistema za

upravljanje bazama podataka (SUBP), koje su ili koegzistirale na tržištu ili smenjivale
jedna drugu. Fundamentalna razlika između sistema ovih generacija je razlika u modelu
podataka, koja se u implementaciji odgovarajućih SUBP reflektuje na efikasnost pristupa
podacima i obrade podataka, produktivnost korisnika, funkcionalnost sistema i podršku
raznovrsnim aplikacijama. Tako se u prve dve generacije svrstavaju tzv. mrežni
(CODASYL) sistemi i hijerarhijski sistemi, koji su gotovo u potpunosti prevaziđeni,
osamdesetih godina prošlog veka, relacionom tehnologijom kao trećom generacijom
SUBP. Sve tri generacije namenjene su pre svega poslovno-orijentisanim aplikacijama.

Arhitektura najvećeg broja sistema baza podataka odgovara predlogu

ANSI/SPARC studijske grupe Američkog nacionalnog instituta za standarde, i poznata je
kao ANSI arhitektura (slika 1). Ova arhitektura predstavljena je hijerarhijom apstrakcija,
pri čemu svaki nivo hijerarhije uključuje specifični način predstavljanja, reprezentaciju,
objekata, odnosa među objektima i operacija nad objektima. Hijerarhijska arhitektura
omogućuje prirodnu dekompoziciju i efikasni razvoj sistema za upravljanje bazama
podataka.

Relaciona baza podataka je skup skupova podataka koji se na logičkom nivou

mogu posmatrati kao relacije odgovarajućih stepena i dinamičkog sadržaja. Pri tome su te
relacije normalizovane (u prvoj normalnoj formi, 1NF), tj. podaci u njima su atomični
(nedeljivi).
 Slika 1. ANSI arhitektura sistema baza podataka

Primer 1.1 Aproksimacija izdavačke relacione baze podataka može se predstaviti

sledećim relacijama:
Kao što se vidi, ove relacije moguće je predstaviti tabelama sa sledećim karakteristikama:
- nema dupliranih vrsta (jer je relacija skup)
- redosled vrsta je nebitan (jer je relacija skup)
- redosled kolona je nebitan (jer atributi relacije čine skup)
- sve vrednosti u tabeli su atomične.

2. Logičko projektovanje baze podataka

Poseban značaj u radu sa relacionim bazama podataka ima struktuiranje i
organizacija samih podataka. Podatke je na nivou korisnika potrebno struktuirati, a na
fizičkom nivou organizovati tako da njihovo održavanje bude najlakše, a operisanje
njima najefikasnije. Skup postupaka kojima se dolazi do dobro struktuiranih podataka
(pravilno grupisanih atributa) u bazi podataka naziva se metodama logičkog
projektovanja baze podataka.

Skup postupaka kojima se podaci fizički organizuju u bazi, tako da im je pristup i

održavanje najefikasnije, naziva se metodama fizičkog projektovanja, tj. metodama
fizičke organizacije podataka.

Primer 2.1 Prethodna baza podataka može da se predstavi sledećom šemom relacione
baze podataka:
P (P_SIF, IME, BR_NASLOVA, DRZAVA)
I (I_SIF, NAZIV, STATUS, DRZAVA)
K (K_SIF, NASLOV, OBLAST)
KP (K_SIF, P_SIF, R_BROJ)
KI (K_SIF, I_SIF, IZDANJE, GODINA, TIRAZ)
Ova relaciona baza podataka je dobro logički projektovana jer omogućuje jednostavno
unošenje, brisanje i izmenu objekata (ili njihovih odnosa) predstavljenih svakom
pojedinačnom tabelom.

Nešto formalnije, “dobro” logičko projektovanje relacione baze podataka

zasnovano je na karakterističnim zavisnostima koje postoje među atributima svake
pojedinačne relacije. Na primer, u relaciji I, jedinstveni identifikator vrste jeste šifra
izdavača (atribut I_SIF), tj. I_SIF jednoznačno određuje vrednost svakog od atributa
NAZIV, STATUS, DRZAVA (svaki od atributa NAZIV, STATUS, DRZAVA
funkcionalno zavisi od atributa I_SIF). Ovo jednoznačno određenje, tj. funkcionalna
zavisnost, označava se na sledeći način:

Inače, važi funkcionalna zavisnost između dva podskupa X, Y skupa atributa

relacije R (u oznaci X → Y) ako za svake dve n-torke (vrste) t1, t2 relacije R, jednakost na
atributima iz X implicira njihovu jednakost na atributima iz Y, što se označava kao
t1[X]=t2[X]
t1[Y]=t2[Y] (t[X] je tzv. projekcija n-torke (vrste) t na atribute X).

U relaciji I, atribut I_SIF je ključ jer svi ostali atributi od njega funkcionalno
zavise. Razne n-torke relacije I moraju imati različite vrednosti atributa I_SIF.

Relacije opisane izdavačke baze podataka su dobro projektovane jer su sve

zavisnosti posledice ključa (na levoj strani imaju ceo ključ).

Primer 2.2. Razmotrimo primer loše isprojektovane relacije R:

U ovoj relaciji postoje problemi sa unošenjem, brisanjem i izmenom podataka, tzv.

“anomalije”, jer nisu sve zavisnosti posledica ključa.
3. Metoda normalnih formi (NF) za logičko projektovanja relacione
baze podataka
Problem sa relacijom R je u tome što je par atributa {I_SIF, K_SIF} – ključ te
relacije, a atribut NAZIV, koji nije deo ključa, zavisi samo od jednog dela ključa, tj. od
atributa I_SIF. Kaže se da postoji parcijalna zavisnost neključnog atributa od ključa, pa
zbog toga relacija R nije u drugoj normalnoj formi, 2NF. Ako se relacija R zameni
projekcijama

dobijene relacije su dobro projektovane i ne pokazuju anomalije (one su u 2NF, ali i u

svim višim normalnim formama). Međutim, i 2NF relacije mogu da budu loše
isprojektovane, kao što to pokazuje sledeći primer.

Primer 3.1

U relaciji S važe funkcionalne zavisnosti P_SIF → I_SIF, I_SIF 5→ P_SIF, I_SIF →

DRZAVA. U njoj nema parcijalne zavisnosti neključnih atributa od ključa, a S opet
pokazuje anomalije unošenja, brisanja i izmene. Uzrok anomalijama sada je tranzitivna
zavisnost neključnog atributa (DRZAVA) od ključa (P_SIF). Relacija S zbog toga nije u
trećoj normalnoj formi, 3NF. Problem se rešava zamenom relacije S projekcijama:
Relacije IZDAVAC i UGOVORI_PISCI_IZDAVACI su u 3NF i ne pokazuju anomalije.

Logički model dobijen zamenom relacije njenim projekcijama sa boljim

osobinama (tzv. dekompozicijom) nazvaćemo modelom dobijenim metodom normalnih
formi, tj. NF modelom. Osnov za dekompoziciju i NF modeliranje je funkcionalna
zavisnost, tj. može da se dokaže sledeća teorema.

Teorema: Funkcionalna zavisnost X→Y u relaciji R je dovoljan uslov za dekompoziciju

relacije R u par projekcija R1= R[X,Y], R2=R[X,Ostatak] t.d. R1*R2=R (operacija * je
operacija spajanja, tj. dopisivanja n-torki relacije R2 na n-torke relecije R1 ako imaju
jednake vrednosti na zajedničkim atributima X).

4. Primer logičkog projektovanja baze podataka primenom NF metode

Neka baza podataka sadrži podatke o predavanjima, sa informacijama o
predavaču (lični broj, ime, zvanje, naučni stepen), predmetu (šifri predmeta, nazivu,
smeru, godini predavanja, fondu časova), vremenu i mestu održavanja. Logičko
projektovanje relacione baze metodom normalnih formi polazi od univerzalne relacije
koja sadrži sve navedene informacije kao svoje atribute i koja je u 1NF (atributi ključa su
podvučeni):

predavanje (predavač#, ime, zvanje, stepen, šifra_predmeta, naziv, šifra_smera,

naziv_smera, godina, fond_časova, vreme, br.sale, sprat)

Funkcionalne zavisnosti u ovoj relaciji su:

1. predavač# → ime, zvanje, stepen
2. šifra_predmeta → naziv
3. šifra_predmeta, šifra_smera → godina, fond_časova
4. šifra_predmeta, šifra_smera, predavač#, vreme → br.sale, sprat
5. šifra_smera → naziv_smera
6. br.sale → sprat
 Iz funkcionalnih zavisnosti pod brojem 1, 2, 3 i 5, sledi parcijalna zavisnost
neključnih atributa ime, zvanje, stepen, naziv, godina, fond_časova i naziv_smera, od
ključa. Prema ovim zavisnostima, polazna relacija predavanje može se zameniti
sledećim skupom relacija (svojih projekcija) koje su u 2NF:

predavač (predavač#, ime, zvanje, stepen)

predmet (šifra_predmeta, naziv)
predmet-smer (šifra_predmeta, šifra_smera, godina, fond_časova)
(ova se relacija može nazvati i “nastavni plan”)
smer(šifra_smera, naziv_smera)
predavanje2(predavač#, šifra_predmeta, šifra_smera, vreme, br.sale, sprat)

Relacije predavač, predmet, predmet-smer i smer su i u 3NF. U relaciji

predavanje2 prisutna je tranzitivna zavisnost neključnog atributa “sprat” od ključa
(predavač#, šifra_predmeta, šifra_smera, vreme → br.sale; br.sale → sprat). Zato se
relacija predavanje2 može zameniti, sledećim relacijama koje su u 3NF:

sala (br.sale, sprat)

predavanje3 (predavač#, šifra_predmeta, šifra_smera, vreme, br.sale)

Dakle, šema relacione baze podataka dobijena metodom normalnih formi sastoji
se od relacijskih šema za relacije (koje su u 3NF): predavač, predmet, predmet-smer,
smer, sala, predavanje3.

5. Semantičko modeliranje: prošireni model entiteta i odnosa (EER)

Sistemi zasnovani na tradicionalnim modelima - hijerarhijskom, mrežnom i
relacionom, imaju tendenciju da u značajnoj meri razgraničavaju unutrašnji (fizički) nivo
podataka od konceptualnog (logičkog) i spoljašnjeg, ali ne u dovoljnoj meri i spoljašnji
nivo od konceptualnog. Osim toga, ovi modeli ne podržavaju semantiku podataka, već je
ona prepuštena korisniku.

Tako, na primer, relacioni sistemi “ne prepoznaju” da su “naslov knjige”' i

“država”' semantički različiti atributi, pa je moguće, ako su definisani na istom domenu
(niske simbola), izvršiti operaciju poređenja nad njima. Ovi modeli “ne prepoznaju” ni da
je, na primer, tip entiteta “programer” specijalni slučaj tipa entiteta “radnik”, a da je ovaj
- specijalni slučaj tipa entiteta ”osoba. Tako se dolazi do potrebe za proširenjem
postojećih modela semantičkim aspektom podataka, tj. do stvaranja novih modela koji
uključuju semantičku komponentu. Predstavljanje značenja podataka modelom podataka
zove se semantičko modeliranje.

Model entiteta i odnosa (koji je definisao Peter Chen 1976. godine) je primer
jednog semantičkog modela. Doživeo je veći broj različitih proširenja i modifikacija, tako
da je i danas u upotrebi veći broj verzija tog modela. Uz model je razvijena i dijagramska
tehnika za predstavljanje entiteta i odnosa među njima, sa svim njihovim
karakteristikama.

Posebnu primenu model entiteta i odnosa ima u realizaciji efikasne i produktivne

semantičke metode logičkog projektovanja. Šema baze podataka koja se dobije ovom
metodom obično se (automatski) preslikava u šemu relacione baze podataka, na koju se
primenjuje neki od relacionih jezika za definisanje i manipulisanje podacima. Ako je
proces logičkog projektovanja, zasnovan na modelu entiteta i odnosa, korektno
sproveden, tj. ako su uočeni svi bitni entiteti i pravilno uspostavljeni odnosi među njima,
onda dobijena relaciona baza podataka ima svojstvo da su joj, gotovo uvek, sve relacije u
nekoj od viših normalnih formi (bar u 3NF).

Strukturni deo modela entiteta i odnosa uključuje, pre svega, entitet sa atributima:

Entitet može da bude nezavisan ili slab (zavisan) entitet:

Među entitetima uspostavljaju se binarni odnosi, na primer odnos asocijacije:

Entiteti mogu da budu i u odnosu genrealizacija / specijalizacija, na primer:

Ukoliko odnos ima sopstvene atribute, on se proglašava za agregirani entitet, na primer:

Pravila transformacije šeme entiteta i odnosa u relacioni model, tj. pravila

logičkog projektovanja relacione baze podataka primenom EER modela su sledeća:

- nezavisni entitet se prevodi u relaciju sa svim njegovim atributima;

- slabi entitet se prevodi u relaciju koja sadrži sve njegove atribute i ključ entiteta od
kojeg zavisi;
- agregirani entitet se prevodi u relaciju koja sadrži sve njegove atribute i ključeve
komponenata;
- podtip nekog nadtipa entiteta prevodi se u relaciju koja sadrži njegove specifične
atribute i ključ odgovarajućeg nadtipa;
- odnos se prevodi u relaciju koja sadrži ključeve entiteta koji grade odnos;
- ako se u nekom odnosu jedan tip entiteta preslikava u drugi tip entiteta preslikavanjem
kardinalnosti (1,1), onda se prvom tipu entiteta kao atribut dodeljuje ključ drugog tipa
entiteta; odnos između njih se ne prevodi u posebnu relaciju.

6. Primeri logičkog projektovanja baze podataka primenom EER

modela

Primer 6.1 Isti primer predavanja (kao u tački 4) proizvodi sledeći EER model:

Transformacija u relacioni model proizvodi istu šemu relacione baze podataka kao i NF
metoda.

Primer 6.2 Takmičenje

Ratmotrimo sledeći problem : Svake godine teniski klub učestvuje u
međuklupskom takmičenju koje organizuje teniska federacija. Takmičenje se odvija u
ekipama. Klub izlaže informacije u vezi sa sastavom ekipa koje učestvuju na takmičenju.
Jedna ekipa se registruje za samo jednu ligu i samo jednu kategoriju. Jedna kategorija
ima ime koje je identifikuje (npr. juniori-zene, veterani-muskarci, ...). Kategoriju opisuje
i najmanji broj igrača u ekipi koja učestvuje u toj kategoriji i uslovi koji se odnose na pol
i starost osoba koje mogu da učestvuju u toj kategoriji. Starosno ograničenje se izražava
intervalom - parom godina rođenja. Na primer, kategorija veterani-muškarci definiše se
sledećim ograničenjima: četiri (4) igrača, muški pol, godina rođenja između 1944 i 1964.
Jednu ekipu opisuje obeležje koje je razlikuje od drugih ekipa jednog kluba koji se
prijavio za istu ligu i istu kategoriju. Za svaku ekipu, znaju se igrači koji joj pripadaju kao
i kapiten koji mora biti jedan od igrača te ekipe. Igrač ima ime, prezime, jedinstveni broj
koji je dobio od Federacije, i klasu. Poznat je njegov pol i datum rođenja. Za svaku
kategoriju znaju se lige koje je sačinjavaju. Liga se identifikuje rednim brojem. Jedna ista
liga može ući u sastav više kategorija. Na primer, liga I se nalazi u svakoj postojećoj
kategoriji, dok liga IV postoji samo u kategoriji «Veterani-muškarci ». Jedan igrač može
da bude član većeg broja ekipa, ukoliko su te ekipe prijavljene u različitim kategorijama.
Svi članovi ekipe moraju da poštuju uslove kategorije za koju je prijavljena ta ekipa.

EER model sa eksplicitnim uslovima ograničenja (C1, C2, C3):

Transformisana šema relacione baze podataka sastoji se od sledećih relacija:

EKIPA (oznaka, rBroj, nazivK)

KATEGORIJA (nazivK, brIgraca, pol, pocD, krajD)
LIGA (rBroj)
IGRAC (ime, prezime, fedBroj, klasa, pol, datRod)
SASTAV (oznaka, rBroj, nazivK, fedBroj)
SASTAVK (rBroj, nazivK)