Baze podataka
Ljubiša Mladenović
Baze podataka
Baze podataka
Ciljevi lekcije
1. Upoznati se sa značenjem
termina "baza podataka".
2. Upoznati se sa pojmom
"sistem za upravljanje bazama podataka" (DBMS), njegovim
tipičnim funkcijama.
3. Upoznati namenu "modela
podataka".
4. Upoznati se sa osnovim
konceptima relacionog modela podataka
Moderne kompanije i institucije poseduju različite elektronske
(računarske, informacione) sisteme koje koriste kao podršku u
procesu obrade informacija, koje nastaju kako unutar samog sistema
tako i onih koji dolaze spolja. Takvi informacioni sistemi
obezbeđuju kako osoblju tako i spoljnim korisnicima (kupci,
dobavljači, agencije i sl) da pristupe informacijama kompanije sa
različitim nivoima prioriteta i prava pristupa. Takvi sistemi mogu
da budu sistemi za upravljanje dokumenata, sistemi za upravljanje
projektima, e-mailing sistemi, intranet, internet stranice i sl.
Takvi sistemi imaju jedan neizostavan deo - sistem baza podataka,
koja čuva sve informacije koje se obrađuju i obezbeđuje pristup tim
informacijama. Baze podataka su ključna komponenta kod standardnih
informacionih sistema, ali i e-komerc i drugih Web zasnovanih
aplikacija. Koriste ih oragnizacije i preduzeća od onih najmanjih
do globalnih korporacija i milioni korisnika.
Šta je sistem baza podataka?
Sistem baza podataka
Sistem baza podataka sadrži 4 osnovne komponente (slika 1):
(1) korisnici,
(2) aplikacija nad bazom podataka,
(3) sistem za upravljanje bazama podataka (Database Management
System - DBMS), i
(4) baza podataka.
Slika 1. Komponente sistema baza podataka
Šta je baza podataka?
Baza podataka predstavlja kolekciju međusobno povezanih podataka
koji su organizovani u tabele i druge strukture podataka, a koriste
za jednu ili više aplikacija.
Osnovna namena baze podataka je da bude repozitorijum
(skladište) za podatke. Podaci mogu biti različitog tipa,
tekstualni, numerički, slike, audio i video zapisi i sl.
Podaci u bazi podataka se čuvaju tako da je unos novih podataka,
kao i čitanje i pretraživanje postojećih, je jednostavno, efikasno
i ako je moguće, bez grešaka.
Iz „definicije" baze podataka vidi se da je ona kolekcija
međusobno povezanih podataka organizovanih u tabele. U ovoj
„definiciji" dve su činjenice od značaja - organizacija podataka u
tabele i njihova međusobna povezanost.
Podaci u bazama podataka su organizovani u dvodimenzionalne
tabele. Tabela može da ima više kolona, gde svaka kolona
predstavlja neku osobinu ili atribut. Vrste tabele čine konkretni
podaci, odnosno konkrente vrednosti osobina/atributa nekog
objekta.
Na primer, jedna tabela može da sadrži informacije o učenicima.
Kolone tabele mogu da definišu ime, prezime, godinu rođenja
učenika, i sl. Vrste u takvoj tabeli su učenici, tako da se svaka
vrsta odnosi na jednog učenika.
Koje će tabele da sadrži baza podataka zavisi od problema za
koji treba realizovati bazu podataka. Na primer, baza podataka se
može odnosti na školu, pa će u tom slučaju tabele biti o učenicima,
nastavnicima, odeljenjima, i sl. Postupak izbora i definisanja
tabela za bazu podataka je deo procesa modeliranja odnosno
izgradnje modela podataka. Model podataka je detaljno objašnjen u
sekciji nakon sekcije o DBMSu.
Međusobna povezanost podataka je ono po čemu se baza podataka
razlikuje u odnosu na fajl sisteme (datoteke) i programe za
unakrsna izračunavanja ko što je Excel. Povezanost podataka
obezbeđuje značajne prednosti kod pretraživanja kada korisnik može
da na osnovu veza izvuče mnogo više podataka. Na primer, ako
postoji tabela koja čuva podatke o učenicima i tabela sa podacima o
odeljenjima, veza između učenika i odeljenja može da obezbedi da
odgovarajućim zahtevom (SQL upitom) izvučete sve učenike željenog
odeljenja.
Baza podataka sadrži i tzv. metapodatke, odnosno podatke o samoj
strukturi baze podataka. Metapodaci mogu da se odnose na imena
tabela, imena kolona u svakoj tabeli, na podatke o korisnicima
podataka, kao i raznim pomoćnim strukturama koje obezbeđuju brz
prstup podacima (indeksi).
Šta je Sistem za upravljanje bazama podataka (DBMS)?
Softverski sistem koji omogućava korisnicima definisanje,
ažuriranje i kontrolu pristupa bazi podataka naziva se sistem za
upravljanje bazama podataka (eng. Database Management System -
DBMS). DBMS obično nudi:
· Jezik za opis podataka (eng. Data Definition Language - DDL),
koji omogućava korisnicima definisanje tipa i strukture podataka,
kao i ograničenja nad podacima memorisanim u bazi podataka (naredne
lekcije - CREATE TABLE naredba).
· Jezik za manipulaciju podacima (eng. Data Manipulation
Language - DML), koji omogućava korisnicima umetanje, ažuriranje,
brisanje i pretraživanje podataka iz baze podataka (naredne lekcije
- SELECT, INSERT INTO, UPDATE naredbe).
· Jezik za definisanje načina memorisanja podataka (eng. Storage
Definition Language - SDL), koji se koristi za specificiranje
interne šeme baze podataka.
· Kontrolisani pristup bazi podataka, što uključuje različite
funkcije i mehanizme za pristup podacima u bazi podataka
Funkcije DBMSa
· DBMS treba da obezbedi sledeće funkcije za kontrolisani
pristup podacima u bazi podataka:
· Sigurnosni sistem, koji onemogućava pristup bazi podataka
neautorizovanim korisnicima (sigurnosni servisi), odnosno samo
autorizovani korisnici mogu da koriste podatke u skladu sa
definisanim privilegijama (autorizacioni servisi)
· Integritetni sistem, koji održava konzistentnost podataka u
bazi podataka, odnosno da se sve promene dešavaju u skladu sa
definisanim pravilima.
· Sistem za kontrolu konkurencije, koji dopušta deljivi pristup
podacima iz baze podataka, tj da se obezbedi korektno ažuriranje
podataka kada više korisnika pokušava istovremeno da vrši
ažuriranja.
· Sistem za kontrolu oporavka baze podataka, koji omogućava
rekonstrukciju prethodnog konzistentnog stanja u slučaju neke
hardverske ili softverske neispravnosti.
· Katalog kome korisnici mogu pristupati, koji sadrži opis
podataka koji su memorisani u bazi podataka.
· Podrška za transakcije, koja obezbeđuje korektno izvršavanje
niza transakcija koje mogu biti međusobno zavisne; transakcija je
skup operacija upisa i čitanja iz baze podataka koji se tretira kao
celina tj ima svoj početak i kraj.
· Razne korisničke funkcije, kao što su import, eksport
podataka, statističke analize, funkcije za nadgledanje,...
Izbor DBMSa
Danas na tržištu postoji veliki broj proizvođača DBMSa koji nude
sistema različitih performansi i koji su namenjeni različitim
segmentima tržišta. Koji DBMS ćete izabrati zavisi od tipa i
veličine problema koji treba da rešite realizacijom aplikacije. U
narednoj sekciji dat je kratak prikaz tipova sistema baza
podataka.
Tipovi sistema baza podataka
Tehnologija baza podataka se može koristiti za veliki broj
aplikacija. Praktično danas skoro i da ne možete da realizujete
aplikaciju koja ne koristi neki sistem baza podataka za čuvanje
podataka - bez obzira da li se radi o standardnim desktop
aplikacijama, kao što su knjigovodstvene aplikacije, sistemi za
upravljanje dokumentima, sistemi za banke, i sl, ili se radi o
modernim Web aplikacijama koje obezbeđuju složenu funkcionalnost u
distribuiranom okruženju, od on-line kupovine do raznih socijalnih
mreža i sl. U zavisnosti od aplikacije, zahtevi prema bazi podataka
mogu značajno da se razlikuju.
Jedan granični slučaj je da vam treba aplikacija za evidenciju
kućnih troškova. U tom slučaju ona obično sadrži samo nekoliko
tabela, gde svaka tabela može da ima samo nekoliko stotina vrsti.
Aplikaciju, a samim tim i bazu podataka, koristite samo vi, odnosno
samo jedan korisnik. Za takve sisteme se obično koristi naziv
personalni sistemi baza podataka. Naravno, ovakvi sistemi mogu da
se primene i na mnogo složenije aplikacije od evidencije kućnog
budžeta. Na primer, mogu da pokriju i poslovane manjeg preduzeća,
ili da podrže rad nekog Web sajta.
S druge strane, ako imate veliku kompaniju koja ima više
organizacionih jedinica, gde svaka od njih ima sopstvene poslovne
procese, neophodna vam je podrška sistema baza podataka koji može
da obezbedi čuvanje i pretragu velike količine informacija na više
distribuiranih lokacija. Takvi sistemi sadrže veliki broj tabela, a
neke od njih mogu da imaju i nekoliko stotina hiljada vrsta i više.
Podacima može konkurentno da pristupa veliki broj korisnika. Takvi
sistemi obično moraju da rade 24 časa dnevno, 7 dana u nedelju.
Takvi sistemi su poznati kao enterprise sistemi baza podataka.
Komponente personalnog sistema baza podataka su prikazane na
slici 2.
Slika 2. Personalni sistem baza podataka
Na slici 3. prikazan je enterpise sistem baza podataka.
Zanimljivo je da su na slici prikazane aplikacije razvijane u
različitim jezicima: Java, C#, HTML i ASP.NET. Takve aplikacije
koriste velike DBMS sisteme za upravljanje bazom podataka. Nem
čarobnjaka ili sličnih alata da pomognu u razvoju takvih sistema.
Programeri moraju da napišu kod koji će da obezbedi pristup i
pretraživanje podataka korišćenjem funkcija DBMSa
Slika 3. Enterprise sistem baza podataka
Modeli podataka
U procesu razvoja baze podataka najpre se formira model realnog
sistema, tako što se izaberu značajne karakteristike sistema koje
se predstavljaju modelom.
Postoji mnogo različitih mogućnosti da se modelira sistem. U
fazi modeliranja zadatak projektanta baze podataka je da otkrije
funkcije koje sistem mora izvršavati, podatke koje mora pamtiti i
obrađivati, informacije koje mora obezbeđivati za potrebe
korisnika, sekvence u kojima se funkcije moraju izvršavati i u
kojima se može pristupati podacima. Deo modela sistema koji se
odnosi na podatke naziva se model podataka.
Važno
Izabrani entiteti će kasnije u bazi podataka biti predstavljeni
tabelama. Zbog toga pogledajte pažljivo naveden objekte pošto mogu
da vam budu dobar vodič kod izbora entiteta!
Svaki objekat, odnosno entitet, poseduje neka svojstva. Na
primer, entitet "vozilo" ima vlasnika, registarski broj, datum
registracije, godinu proizvodnje, proizvođača, marku, boju, tip
motora, i dodatnu opremu. Svojstva ili atributi objekta će biti
predstavljena kolonama u odgovarakućoj tabeli.
Objekti međusobno mogu biti povezani različitim odnosima odnosno
relacijama. Svaka takva relacija može da poseduje posebna svojstva.
Relacije se mogu iskoristiti kod pretraživanja međusobno povezanih
podataka, na primer, kod pretraživanja podataka o registrovanim
vozilima i njihovim vlasnicima. Više detalja o načinu povezivanja
podataka iz tabela pogledajte u sekciji koja se odnosi na ključeve
relacija, konkretno na strane ključeve i očuvanje integriteta.
Važno
Izborom objekata, definisanjem njihovih svojstava i
prepoznavanjem veza između objekata, izvršili smo modeliranje dela
realnog sveta koji predstavlja naš problem!
Relacioni model podataka
Zanimljivosti
Relacioni model je svakako najpopularniji i najrasprostranjeniji
model podataka danas i predstavlja osnovu za relacione baze
podataka koje dominiraju na tržištu. Relacione baze podataka
dominiraju na tržištu već skoro 40 godina!
Relacioni model je predložio E.F. Codd 1970 godine, dok je radio
u IBMu.
System R je prvi sistem koji je koristio relacioni model, nakon
toga IBM je implementirao svoj sistem poznat kao DB2. Nakon toga je
Oracle realizovao svoj sistem zasnovan na ovom modelu,... i sve
ostalo je istorija.
Relacija, kao osnovni koncept relacionog modela je zapravo
matematička relacija, i ima jednostavnu reprezentaciju u obliku
tabele sa podacima.
Osnove relacionog modela
Relacioni model ima snažnu teorijsku osnovu, koja se zasniva na
matematičkoj teoriji relacija i na logici prvog reda, i za
korisnika vrlo prihvatljivu reprezentaciju u vidu dvodimenzionalne
tabele.
Relacioni model oslobađa korisnika frustracija oko rukovanja
podacima na niskom nivou, zalaženja u detalje smeštanja podataka i
metodama pristupa iz korisničkog interfejsa. Relacioni model
obezbeđuje sredstva za opis podataka sa njihovom prirodnom
strukturom, bez dodatnih struktura za potrebe mašinske
reprezentacije. Ovaj model daje osnovu za jezik visokog nivoa za
pristup podacima koji obezbeđuje maksimalnu nezavisnost
između programa, s jedne strane, i mašinske reprezentacije, s druge
strane.
U relacionom modelu podataka relacije se koriste za čuvanje
informacije o objektima koje treba predstaviti u bazi podataka. U
fazi projektovanja baze podataka, za konkretan problem, treba
najpre prepoznati objekte realnog sveta (entiteti) za koje treba
čuvati podatke i prepoznati njihove atribute. Svaki takav objekat
predstavlja se relacijom u relacionom modelu.
Atributi su zajedničke osobine koje poseduju svi entiteti jednog
skupa entiteta. Iz skupa atributa entiteta za potrebe konkretnog
informacionog sistema bira se samo određeni podskup. Pošto se
entiteti odnosno objekti realnog sveta predstavljaju relacijom,
atributi predstavljaju svojstva te relacije. Pošto je relacija
predstavljena tabelom, atributi predstavljaju kolone te tabele.
Svaka relacija predstavlja skup torki, gde se svaka torka odnosi na
konkretan entitet iz skupa entiteta. U tabelarnom prikazu relacije,
vrste tabele su podaci o konkretnim entitetima, odnosno torke, tako
da atribut za svaki konkretni entitet iz skupa entiteta poseduje
određenu vrednost.
Skup vrednosti koje neki atribut može uzimati zovemo domen
atributa. Praktično, svaki atribut u relaciji je definisan nad
nekim domenom. Koncept domena je vrlo važan. Omogućava korisniku da
definiše na jednom centralnom mestu značenje i izvor vrednosti koje
atribut može uzimati. Svaki domen atributa se definiše: tipom
podataka, dužinom podataka i opsegom vrednosti.
NULL Vrednosti atributa
Atributi uzimaju vrednosti iz odgovarajućeg domena koji im je
dodeljen, što u praksi znači da će vrednosti u tabeli za neku
kolonu da budu onog tipa podataka koji smo izabrali za tu
kolonu.
Međutim, DBMS dozvoljava da atribut nema dodeljenu vrednostm što
podrazumeva korišćenje tzv NULL vrednosti. Ova specijalna vrednost
se mora uvesti zato što u odgovarajuću ćeliju tabele treba da stoji
neka vrednost da bi pretrage i analize radile.
NULL vrednost može da ima dva značenja:
· Vrednost atributa za posmatrani entitet ne postoji ili još
uvek nije poznata. Na primer, za radnika koji je tek treba ili je
tek počeo da radi vrednost atributa prethodni radni staž nije
poznata.
· Vrednost atributa za posmatrani nije primenjiva. Na primer,
ako za relaciju RADNIK imamo atribut FAKULTET u kome se čuva naziv
fakulteta koji je radnik završio, svi radnici sa srednjom školskom
spremom će imati NULL vrednost za taj atribut.
Pregled osnovnih koncepata relacionog modela podataka
Važno
Relacija se u bazi podataka predstavlja dvodimenzionalnom
tabelom, gde vrste odgovaraju pojedinim slogovima, a kolone
atributima. Atributi se mogu pojavljivati u bilo kom redosledu u
tabeli. Redosled vrsta tabele takođe nije bitan. Svaka tabela, kao
i svaka kolona u tabeli imaju ime.
Osnovni koncepti relacionog modela podataka su:
Relacija
Relacija odgovara pojmu tabela sa vrstama i kolonama.
Atribut relacije
Predstavlja osobinu entiteta predstavljenog relacijom. Atribut
je praktično imenovana kolona relacije odnosno tabele, koje se
odnose na svojstva objekta predstavljenog relacijom.
Domen atributa
Domen je skup dozvoljenih vrednosti za jedan ili više atributa.
Praktično se odnosi na tip podatka za kolonu.
Torka relacije
Torka je vrsta relacije i odnosi se na jedan slog podataka.
Stepen relacije
Broj atributa relacije (unarna, ako ima jednu kolonu, binarna sa
dve kolone i sl)
Kardinalnost relacije
Broj vrsta (torki) relacije.
Šema relacije
Šema relacije je opis relacije. Sadrži ime relacije, imena
atributa i domene atributa.
Relaciona baza podataka
Kolekcija normalizovanih relacija.
Šema relacione baze podataka
Skup šema relacija, pri čemu svaka ima različito ime.
Očigledno je da je relacija u relacionom modelu, odgovara pojmu
tabela u bazi podataka. U svetu baza podataka, obično se koriste
jedni termini kada se govori o relacionom modelu, a drugi kada se
govori o bazi podataka, odnosno implementaciji relacionog modela.
Uporedni prikaz termina i njihovog značenja dat je na slici 4.
Relacioni model
Baza podataka
Relacija
Tabela
Torka
Vrsta
Atribut
Kolona
Domen atributa
Tip podatka kolone
Šema relacije
Opis tabele
Slika 4. Ekvivalentni skup pojmova
Svojstva relacije
Relacija ima sledeća svojstva:
Svaka relacija
ima ime koje se razlikuje od imena svih ostalih relacija u šemi
relacione baze podataka,
Svaka ćelija
tabele (određena vrstom i kolonom) kojom je relacija predstavljena
sadrži samo jednu atomičnu (prostu) vrednost,
Svi atributi
jedne relacije imaju različito ime,
Sve vrednosti
jednog atributa su iz istog domena,
Sve torke
relacije su različite, tj. u relaciji ne postoje duple torke,
Redosled
atributa u relaciji nema značaja, i
Redosled torki
u relaciji teoretski nema značaja, ali praktično redosled torki u
relaciji može uticati na efikasnost pristupa torkama!
Primer
Recimo da RADNIK predstavlja skup radnika nekog preduzeća
(entiteta, tj objekata iz realnog sveta). RADNIK je relacija u
relacionom modelu koju predstavljamo tabelom u koju ćemo da čuvamo
sve radnike. Za radnike treba čuvati informacije o imenu,
prezimenu, matičnom broju, adresi stanovanja i plati – sve ovo su
svojstva/osobine koje su nam važne i koje smo izabrali da ih
predstavimo atributima relacije, odnosno to su nam kolone u tabeli.
Svaka vrsta te tabele se odnosi na konkretnog radnika. U
rešenju narednog zadatka, dat je izgled tabele koja odgovara
relaciji RADNIK.
Zadatak 1
Izbor relacija
Ako je neophodno projektovati bazu podataka koja se odnosi na
preduzeće, prepoznati entitete i njihova svojstva, koje ćete
predstaviti relacijama u relacionom modelu, odnosno tabelama u bazi
podataka.
Rešenje
Pretpostavimo da preduzeće ima više radnika, i za svakog od njih
treba čuvati informacije: ime, matični broj, stručna sprema, datum
rođenja, pol, plata, adresa. Neka je preduzeće organizovano u
sektore (sektor ima naziv, broj).
Podaci o radnicima preduzeća se mogu predstavljaju
relacijom/tabelom RADNIK sa atributima LIME (lično ime), SSL
(srednje slovo), PREZIME, MBR (matični broj), DATRODJ (datum
rođenja), POL, PLATA i ADRESA. Niže je prikazana jedna instanca
relacije RADNIK (tabela RADNIK) i jedna instanca relacije ODELJENJE
(tabela SEKTOR).
RADNIK
LIME
SSL
PREZIME
MBR
DATRODJ
POL
PLATA
ADRESA
Ivana
S
Gocić
123456
15-10-87
Ž
17000
Niška 4
Milan
I
Savić
234567
01-03-57
M
32000
Humska 2
Ana
P
Rodić
666777
03-12-50
Ž
27000
Savska 34
Pera
K
Kostić
555333
31-12-53
M
43000
Čairska 3
SEKTOR
NAZIV
SBROJ
Projektovanje
40
Razvoj
50
Proizvodnja
60
Dodatni zadatak
Ovo je delimično rešenje zadatka. Prepoznati ostale potenijalne
relacije i njihove atribute!!
Zadatak 2
Domeni atributa
Identifikovati domene atributa relacije RADNIK iz prethodnog
primera.
Rešenje
Domeni nekih atributa relacije RADNIK su prikazani u sledećoj
tabeli:
Atribut
Domen
Značenje
Definicija domena
LIME
Imena Osoba
Skup mogućih imena osoba
Niz karaktera, dužine do 15.
PREZIME
Prezime Osoba
Skup mogućih prezimena osoba
Niz karaktera, dužine do 15.
MBR
Maticni Broj
Skup mogućnih matičnih brojeva radnika
Celi brojevi, napr. opsega 111111-999999*
DATRODJ
Datum Rodjenja
Moguće vrednosti za datume rođenja zaposlenih u preduzeću
Datum, opseg, od 01-JAN-44 nadalje
POL
Pol
Pol radnika
Karakter (1), vrednost M i Ž
PLATA
PlataRadnika
Moguće vrednosti plata radnika
Broj, opseg od minLD do 40000.00, gde je minLD minimalni
republički lični dohodak
ADRESA
AdresaRadnika
Moguće adrese radnika preduzeća
Niz karaktera (30)
Dodatni zadatak
Identifikovati domene atributa relacije SEKTOR!!
Ključevi relacije
Da bismo jedan entitet jednoznačno identifikovali u posmatranom
skupu entiteta on mora posedovati neko svojstvo, ili kombinaciju od
nekoliko svojstava, takvu da vrednost tog ili tih svojstava
jednoznačno određuju svaku pojavu tog tipa entiteta. Takva svojstva
nazivamo karakterističnim, a njihove vrednosti koristimo kao
identifikator entiteta unutar skupa.
Na primer, skup entiteta RADNIK predstavljamo relacijom/tabelom
gde svaka vrsta odgovara jednom entitetu, odnosno predstavlja
jednog konkretnog radnika. U tom slučaju neophodno je prepoznati
svojstva (atribute) koje možemo da koristimo za identifikaciju
radnika unutar skupa radnika.
U relacionom modelu podataka atribut ili skup atributa čije
vrednosti predstavljaju identifikator entiteta (torke u relaciji)
nazivamo ključem relacije. Takvi atributi se nazivaju ključni
atributi.
Ako relacija ne poseduje atribut ili skup atributa koji je
identifikuju, tada se uvodi specijalni identifikacioni atribut -
ključ surogat, koji se obično označava sa ID.
U relacionom modelu podataka postoji više termina koji se
koriste za relacione ključeve, što će niže biti uvedeno.
Terminologija
Ključ
Pošto su sve torke relacije različite, u relaciji mora postojati
atribut ili skup atributa (tzv kompozitni ključ – ključ od više
atributa), nazvani relacioni ključevi ili ključevi relacije, koji
na jedinstven način identifikuje svaku torku relacije.
Primarni ključ
Ključ kandidat koji je odabran da na jedinstven način
identifikuje torke unutar relacije.
Ključ surogat
Identifikator koji je dodat relaciji kao primarni ključ, zato
što relacija nema odgovarajući atribut ili skup atributa koji može
biti primarni ključ relacije.
Spoljni ključ / Strani ključ
Atribut ili skup atributa jedne relacije koji se uparuje sa
ključem kandidatom neke druge ili iste relacije. Važan za
ostvarivanje međusobnih veza između tabela!!!
Zadatak 3
Ključ relacije
Identifikovati primarne ključeve relacija RADNIK i SEKTOR iz
prethodnog primera.
Rešenje
Primarni ključ u relaciji SEKTOR je broj sektora, odnosno
atribut SBROJ, zato što na jedinstven način identifikuje svaki
sektor u preduzeću (ne mogu da postoje dva sektora sa istim
brojem). Ključ kandidat (i potencijalni primarni ključ) u ovoj
relaciji može biti i naziv sektora, uz pretpostavku da sektori ne
mogu da imaju ista imena. U relaciji RADNIK primarni ključ je
očigledno matični broj radnika. Kod radnika se može identifikovati
i potencijalni kompozitni ključ kandidat, na primer od kombinacije
atributa ime (ime, srednje slovo i prezime zajedno) i datuma
rođenja. Naravno, ovakav ključ se može izabrati ako ne postoji neki
očigledniji i jednostavniji kao što je u ovom slučaju matični
broj.
U relaciji RADNIK atributi BRSEK i MATBRS su spoljni ključevi.
Prvi je primarni ključ u matičnoj relaciji SEKTOR, a drugi je
primarni ključ u relaciji RADNIK. Relacija SEKTOR ima spoljni ključ
MATBRR koji je primarni ključ u relaciji RADNIK. U relaciji SEKTOR
atribut NAZIV je ključ kandidat, ako važi pravilo da u preduzeću
nepostoje dva ili više sektora sa istim imenima.
Relacioni integritet
U prethodnim odeljcima smo ukratko prikazali strukturnu
komponentu relacionog modela podataka. U ovom odeljku ćemo se
upoznati sa integritetnom komponentom. Već smo ukazali da se za
svaki atribut u relaciji vezuje određeni domen. Ustvari radi se o
domenskim ograničenjima (eng. domain constraints), kojima se
ograničava skup dozvoljenih vrednosti atributa relacije.
Postoje još dva pravila integriteta, poznata kao integritet
entiteta (eng. entity integrity) i referencijalni integritet (eng.
referential integrity), koja ograničavaju ili zabranjuju pojave
određenih torki u relaciji.
Ograničenja
Integritet entiteta
Nijedan atribut primarnog ključa bazne relacije nesme imati NULL
vrednost.
Referencijalni integritet
Ako postoji neki spoljni ključ u relaciji, njegova vrednost mora
biti jednaka vrednosti ključa kandidata neke torke u matičnoj
relaciji ili njegova vrednost mora biti NULL.
Referencijalni integritet je važan kod definisanja međusobnih
veza između tabela.
Ograničenja poslovanja (Business constraints, business
logic)
To su ograničenja koja definiše korisnik ili administrator baze
podataka, a proističu iz pravila poslovanja realnog sistema za koji
se baza projektuje. Jedno od pravila poslovanja u preduzeću je da
rukovodilac mora imati veću platu od svog osoblja. Drugo pravilo
može biti da radnici koji rade na lokaciji X imaju platu uvećanu za
10% od radnika na istom poslu na ostalim lokacijama sektora.
Referencijalni integritet i spoljni ključevi
Jedna od osnovnih osobina relacionih baza podataka je međusobna
povezanost podataka. Za ostvarivanje veza između podataka
predstavljenih relacijom koriste se strani (spoljni) ključevi. Kao
što je već navedeno, strani ključ predstavlja atribut koji se
uparuje sa ključem iz neke relacije. Šta to znači u praktičnoj
realizaciji?
Pretpostavimo da imamo relacije RADNIK i SEKTOR, kako je to
navedeno u prvom primeru, i da za radnike treba čuvati informacije
o sektoru u kome rade. U tom slučaju, dovoljno je da se u relaciju
RADNIK doda atribut čije vrednosti odgovaraju ključevima u relaciji
SEKTOR, tako da za konkretnog radnika ovaj atribut ima vrednost
koja odgovara ključu sektora u kome radnik radi. Za relaciju RADNIK
koju smo imali u primeru 1, treba dodati atribut BRSEK kao spoljni
ključ relacije.
S druge strane, za SEKTOR se može zahtevati da se čuvaju
informacije o rukovodiocu sektora. Rukovodioci su takođe radnici,
pa se svi podaci o njima čuvaju u tabeli RADNIK. Zbog toga je
dovoljno u relaciju SEKTOR dodati atribut MATBRS (sa značenjem
„matični broj šefa“) koji odgovara ključu relacije RADNIK i čuva
vrednost koja odgovara šefu sektora. Uz strani ključ koji
predstavlja vezu mogu se čuvati i druge vrednosti preko atributa
veze. Na primer, uz podatak o šefu sektora može se čuvati i
informacija o datumu postavljanja tako što se doda atribut
DATPOST.
Na primeru relacija koje smo imali u primeru 1, može se videti
sadržaj tabela RADNIK sa dodatim stranim ključevima BRSEK i MATBRS
(prvi je primarni ključ u matičnoj relaciji SEKTOR, a drugi je
primarni ključ u relaciji RADNIK), i SEKTOR sa stranim ključem
MATBRR koji je primarni ključ u relaciji RADNIK.
Može se uočiti da je Ivani Gocić šef radnik sa matičnim brojem
66777, a to je Ana Rodić, dok je Anin šef radnik sa matičnim brojem
55333, odnosno Pera Kostić. Radnici Milan i Petar nemaju šefove,
odnosno vrednost atributa MBRS je NULL.
Na osnovu vrednosti atributa BRSEK, vidi se da tri radnika rade
u sektoru čiji je broj 40 (iz tabele SEKTOR to je Projektovanje), a
samo jedan u sektoru sa brojem 60 (iz tabele SEKTOR to je
Proizvodnja).
RADNIK
LIME
SSL
PREZIME
MBR
DATRODJ
POL
PLATA
ADRESA
MBRS
BRSEK
Ivana
S
Gocić
123456
15-10-87
Ž
17000
Niška 4
66777
40
Milan
I
Savić
234567
01-03-57
M
32000
Humska 2
NULL
60
Ana
P
Rodić
666777
03-12-50
Ž
27000
Savska 34
55333
40
Pera
K
Kostić
555333
31-12-53
M
43000
Čairska 3
NULL
40
SEKTOR
NAZIV
SBROJ
MATBRR
DATPOST
Projektovanje
40
555333
15-01-2000
Razvoj
50
NULL
01-01-99
Proizvodnja
60
234567
01-01-97
Navedeni primeri pokazuju kako se preko stranih ključeva mogu
ostvariti veze između podataka u tabelama. Međutim, ovakav način
povezivanja omogućava predstavljanje veza 1:1 i 1:N. Pri tome, 1 i
N se odnose na kardinalnost (brojnost). Ako posmatrate vezu između
dve relacije, gledate najpre odnos između jednog entiteta iz prve
relacije i svih ostalih entiteta iz druge. Nakon toga isti postupak
ponovite za drugi smer, odnosno odnos jednog entiteta iz druge
relacije sa svim entitetima iz prve.
Na primer, pomenuta veza između relacija RADNIK i SEKTOR (odnosi
se na radnike koji rade u nekom sektoru):
RADNIK : SEKTOR
X : Y
- Najpre posmatramo jednog radnika i određujemo sa koliko
sektora je on u vezi. Pošto jedan radnik može da radi samo u jednom
sektoru, kardinalnost sa strane sektora je 1:
RADNIK : SEKTOR
X : 1
- Nakon toga posmatramo jedan sektor i određujemo sa koliko
radnika je u pomenutoj vezi. Jedan sektor može da ima više radnika,
pa je kardinalnost sa strane radnika u ovoj vezi N:
RADNIK : SEKTOR
N : 1
Veze tipa 1:1 i 1:N se jednostavno definišu dodavanje stranog
ključa. Kod veza 1:N, strani ključ se dodaje na N strani (u
primeru, u relaciju RADNIK se doda strani ključ iz relacije
SEKTOR). Kod veza 1:1 strani ključ se može dodati bilo kojoj
relaciji, ali se obično bira ona kod koje svi entiteti učestvuju u
vezi (ako takva postoji, ili proizvoljno na jednu ili drugu stranu
ako ne postoji). Na primer, ako posmatramo vezu RADNIK:SEKTOR, ali
u smislu rukovodioca sektora, svaki sektor ima jednog rukovodioca,
i jedan radnik rukovodi samo jednim sektorom. Veza je očigledno
1:1. U tom slučaju treba izabrati dodavanje stranog ključa u
relaciju SEKTOR zato što svi entiteti iz ove relacije učestvuju u
vezi, dok to nije slučaj za entitete iz relacije RADNIK (svi
sektori imaju šefa, ali nisu svi radnici šefovi).
Komplikovanija situacija je ako je veza između dve relacije
više-na-više, odnosno M:N. Na primer, ako imamo relacije PREDMET
koja se odnosi na predmete, i relaciju UČENIK, veza između njih
(PREDMET:UČENIK) koja definiše koji učenici pohađaju odgovarajući
predmet je M:N. Jedan predmet pohađa više učenika (x:N), a jedan
učenik ima više predmeta (M:N). Kako predstaviti ovakvu vezu?
Predstavljanje veza tipa M:N je jedino moguće kreiranjem nove
relacije koja sadrži ključeve iz obe relacije koje učestvuju u
vezi, plus eventualno dodatne atribute veze ako postoje. U primeru
veze PREDMET:UČENIK treba kreirati novu relaciju POHAĐA, koja
sadrži atribute: ključ relacije PREDMET, ključ relacije UČENIK, i
eventualno dodatne atribute veze. Ključ te nove relacije je
kombinacija atributa ključeva obe relacije.
Predstavljanje šema relacione baze podataka
Uobičajena konvencija za predstavljanje relacione šeme je
dijagram relacije. Svaka relacija se predstavlja jednim izduženim
pravougaonikom koji ima onoliko ćelija koliko je atributa u
relaciji. Ime relacije se ispisuje iznad pravougaonika, a imena
atributa u ćelijama, pri čemu ostaje pravilo da se primarni ključ
podvlači, a da se spoljni ključevi pišu italikom. Niže je prikazan
dijagram relacione šeme baze podataka PREDUZEĆE:
RADNIK
LIME
SSLOVO
PREZIME
MATBR
DATRODJ
POL
...
...
PLATA
ADRESA
MATBROJS
BRSEK
PROJEKAT
NAZIV
LOKPR
BROJPR
BRS
SEKTOR
NAZIV
SBROJ
MATBRR
DATPOST
CLAN_PORODICE
MATBRRAD
IME
POL
SRODSTVO
DATRODJ
LOK_SEKTOR
RADI_NA
BRS
LOKACIJA
MBR
BRPR
SATI
Pitanja
Pokušajte da odgovorite na sledeća pitanja. Nakon toga
pogledajte ponovo materijal u ovoj lekciji. Za svaki tačan odgovor
dodelite sebi 2 poena, za delimično tačan 1, a za netačan 0.
Pogledajte ponovo one delove lekcije za koje ste imali 0 poena.
1. Zašto je korišćenje baza
podataka važno?
2. Koja je svrha baze
podataka?
3. Šta je sistem baza
podataka i koje su 4 osnovne komponente?
4. Šta je baza podataka?
5. Kako su organizovani
podaci u bazi podataka?
6. Šta je Sistem za
upravljanje bazama podataka (DBMS)?
7. Koje su funkcije
DBMSa?
8. Navesti tipove sistema
baza podataka.
9. Šta obezbeđuju modeli
podataka?
10. Na koji način relacioni model predstavlja
entitete (objekte realnog sveta)?
11. Šta je relacija, a šta su atributi relacije?
12. Šta je domen atributa?
13. Koje značenje imaju NULL vrednosti atributa?
14. Navesti osnovne koncepte relacionog modela
podataka?
15. Navesti svojstva relacije.
16. Koja je uloga primarnog ključa relacije?
17. Navesti vrste ključeva koji mogu da postoje?
18. Kada se uvodi ključ surogat ili kolona ID?
19. Koje je značenje stranog ključa?
20. Šta podrazumeva relacioni integritet?
21. Na koji način se predstavlja relacioni model
podataka?
Relaciona šema baze podataka PREDUZEĆE
Baza podataka PREDUZECE
Na osnovu navedenih zahteva projektovati relacionu šemu baze
podataka PREDUZEĆE.
Zahtevi:
1. Preduzeće ima više sektora. Svaki sektor ima ime, broj i
rukovodioca. Sektor ima bar četiri radnika. Vodi se evidencija o
datumu kada je rukovodilac postavljen na tu funkciju. Sektor može
imati više lokacija.
2. U sektoru se radi na više projekata. Svaki projekat ima ime,
broj i jedinstvenu lokaciju.
3. Za svakog radnika se pamti ime, matični broj, adresa, plata,
pol i datum rođenja. Svaki radnik radi u jednom sektoru, a može
biti angažovan na više projekata, koje ne vodi isti sektor. Pri
tome se vodi evidencija o broju radnih časova koje radnik provede
na nekom od projekata. Takođe se vodi evidencija o hijerarhiji
odgovornosti, odnosno evidentira se za svakog radnika ko mu je
neoposredni rukovodilac.
4. Vodi se i evidencija o članovima porodice. Za svakog člana
evindetira se ime, pol, datum rođenja i srodstvo.
Rešenje zadatka: baza podataka PREDUZECE
Najpre ćemo na osnovu zahteva da prepoznamo potencijalne
relacije koje ćemo predstaviti tabelama. To su RADNIK, SEKTOR i
PROJEKAT, sa atributima kako je to prikazano:
RADNIK
LIME
SSLOVO
PREZIME
MATBR
DATRODJ
POL
PLATA
ADRESA
SEKTOR
NAZIV
SBROJ
PROJEKAT
NAZIV
LOKPR
BROJPR
Član porodice je takođe potencijalna relacija, ali je očigledno
da se svako dete u ovom slučaju nema atribut koji može da bude
ključ. S druge strane, dete se može identifikovati preko svog imena
ako je poznato ko mu je roditelj (odnosno preko ključa roditelja).
Zbog toga se ovoj relaciji dodaje kao strani ključ matični broj
roditelja. Ovo je situacija kada se član porodice pojavljuje kao
slabi tip entiteta, kod koga se ključ formira kao kombinacija
delimičnog ključa (u ovom slučaju ime deteta) i stranog ključa
(mat.br. roditelja). Vodite računa da je ovo dugačija situacija od
dodavanja ključa surogata kako je to navedeno kod objašnjavanja
ključeva.
CLAN_PORODICE
MATBRRAD
IME
POL
SRODSTVO
DATROĐ
Na osnovu zahteva se mogu prepoznati i veze:
RUKOVODI, između radnika i sektora. Ovo je veza 1:1, pošto jedan
radnik može da rukovodi samo jednim sektorom, a jedan sektor ima
jednog rukovodioca. Izbor na koju stranu staviti strani ključ se
može doneti na osnovu dodatne analize veze: u ovoj vezi potpuno
učestvuje svaka torka iz relacije SEKTOR, odnosno svaki sektor mora
da ima rukovodioca (s druge strane, relacija RADNIK ne učestvuje
potpuno, jer nisu svi radnici rukovodioci sektora). Zbog toga se
relaciji SEKTOR dodaje atribut DAT_POST (datum postavljanja
rukovodioca) i spoljni ključ MATBRR (matični broj rukovodioca) koji
predstavlja primarni ključ relacije RADNIK.
SEKTOR
NAZIV
SBROJ
MATBRR
DATPOST
Veze RADI_U i NADZOR, koje su tipa 1:N, u kojima se na N strani
javlja RADNIK, kao i veza JE_NOSILAC u kojoj je na N strani
PROJEKAT. Relacijama na N strani se dodaju kao spoljni ključevi
primarni ključevi relacije na 1 strani.
RADNIK
LIME
SSLOVO
PREZIME
MATBR
DATRODJ
POL
PLATA
ADRESA
MATBROJS
BRSEK
PROJEKAT
NAZIV
LOKPR
BROJPR
BRS
Na osnovu zahteva može se prepoznati i jedna veza M:N: RADI-NA
između relacija RADNIK i PROJEKAT, tako da se za nju formira
posebna relacija RADI-NA u koju se kao spoljni ključevi uključuju
primarni ključevi relacija RADNIK i PROJEKAT. Ova dva spoljna
ključa formiraju primarni ključ relacije RADI-NA.
RADI_NA
MBR
BRPR
SATI
Dodatna komplikacija u ovim zahtevima je i viševrednosni atribut
LOKACIJA koji se odnosi na relaciju SEKTOR. Za njega se formira
nova relacija LOK-SEKTOR koja kao spoljni ključ ima primarni ključ
relacije SEKTOR.
LOK_SEKTOR
BRS
LOKACIJA
Na taj način, na osnovu navedenih zahteva kreiran je kompletni
relacioni model baze podataka PREDUZEĆE koji konačno izgelda
ovako:
RADNIK
LIME
SSLOVO
PREZIME
MATBR
DATRODJ
POL
PLATA
ADRESA
MATBROJS
BRSEK
PROJEKAT
NAZIV
LOKPR
BROJPR
BRS
SEKTOR
NAZIV
SBROJ
MATBRR
DATPOST
CLAN_PORODICE
MATBRRAD
IME
POL
SRODSTVO
DATROĐ
LOK_SEKTOR RADI_NA
BRS
LOKACIJA
MBR
BRPR
SATI
Zadaci
Relacije
Na osnovu zahteva koji su dati prepoznati relacije i njihove
atribute, definisati odgovarajuće tabele i njihove primarne
ključeve:
(a) Brod: brod ima ime, registracioni kod, bruto nosivost, i
godina igradnje.
(b) Restoran: restorani imaju naziv, adresu, broj mesta,
telefon, i vrstu hrane (roštilj, riba, pice).
(c) Krava: krava muzara ima ime, datum rođenja, rasu i numerisnu
plastičnu oznaku na uvetu.
Veze između relacija
Na osnovu zahteva koji su dati prepoznati relacije i njihove
međusobne veze, definisati odgovarajuće tabele, primarne ključeve i
spoljne ključeve koji predstavljaju veze (napomena: atributi nisu
navedeni, tako da morate da predložite određeni skup atributa
relacije koji opisuju svojstva entiteta):
(a) Fakultet ima više studenata, ali jedan
student može da studira samo na jednom fakultetu.
(b) Avion može da ima više putnika, ali jedan putnik
može da bude na samo jednom letu u određeno vreme.
(c) Država ima više regiona, svaki region ima
više gradova.
(d) Ćevapdžinica prodaje više vrsta pljeskavica.
Isti dodaci (salate) se mogu koristiti uz različite tipove
pljeskavica.
(e) Pacijent može da ima više doktora, a jedan
doktor ima više pacijenata.
Modeliranje - jednostavan relacioni model
U bazi podataka treba čuvati podatke o dva tipa entiteta:
VOZILO, sa atributima Tip, RegistarskiBroj, BrojMotora, BrojŠasije,
i VLASNIK sa atributima LičnoIme, Prezime, Adresa, BrojDozvole. Za
vozila se znaju vlasnici. Jedan vlasnik može da poseduje više
vozila, a vozilo ima samo jednog vlasnika.
1. Prepoznati relacije i definisati odgovarajuće tabele.
2. Koji atributi su primarni ključevi ovih relacija?
3. Koji strani ključ i u koju relaciju treba dodati da bi se
modelirala veza između vlasnika i vozila?
Baza podataka o slikarima
Projektovati relacionu šemu baze podataka koja treba da čuva
podatke o slikarima i muzejima u kojima se nalaze njihove slike. Za
svaku sliku, treba pamtiti informacije o veličini (dimenzijama),
godini kada je ona nastala, naslov i stil. Za slikare pamtiti
nacionalnost, datum rođenja i datum smrti (ako je poznat). Za svaki
muzej, pamtiti lokaciju, kao i specijalnost, ako postoji.
Baza podataka o takmičenju u odbojci
Projektovati relacionu šemu baze podataka o takmičenju u
odbojci. U bazi podataka treba čuvati informacije o ekipama koje
učestvuju (naziv, zemlja, trener, najbolji plasman na svetskim i
evropskim prvenstvima) i igračima za svaku ekipu. Za igrače pamti
se ime i prezime, mesto u timu i broj. Brojevi igrača su
jedinstveni u okviru ekipe. Treba pamtiti i podatke o utakmicama
(jedinstveni identifikator, datum, vreme, sudije, dve ekipe koje
igraju i konacni rezultat u setovima). Utakmice se igraju na tri
dobijena seta, a za svaki set na utakmici treba pamtiti njegov
redni broj i rezultat. Za utakmice pamti se i statistika za igrace
i ekipu. Za svakog igrača, za svaku utakmicu, pamti se broj
osvojenih poena i broj promena. Za svaku ekipu na utakmici vodi se
statistika o broju as servisa, broju direktnih poena i broju poena
na greške protivnika.
Baza podataka za Video klub
Projektovati relacionu šemu baze podataka za Video klub.
Potrebno je pratiti sledeće informacije o filmovima: jedinstveni
broj, naslov filma, režiser, tip (akcioni, komedija, drama,...),
rejting filma („kritika“ u novinama označena brojem zvezdica),
godina, nominacije za nagrade Akademije (tzv. „Oskar“, Academy
Award), dobijene nagrade Akademije. Za svaki film treba pamtiti
imena glumaca i tip uloge (glavna, sporedna,...). O glumcima se
pamte imena (ime i prezime), podaci o datumu rođenja i mestu
rođenja, datumu smrti (ako postoji). Za svakog glumca postoji
jedinstveni identifikator. Pamtiti podatke o režiserima filmova: za
svakog režisera postoji jedinstveni broj, pamte se imena, datum
rođenja i datum smrti (ako postoji). Treba pamtiti i informacije o
članovima kluba: broj članske karte, ime i prezime, adresa,
jedinstveni broj, datum učlanjenja, ukupan iznos najamnine (od svih
iznajmljenih kaseta) i vrednost ostvarenog bonusa (određuje se na
osnovu pet iznajmljivanja). Pamtiti podatke o kasetama: jedinstveni
kod kasete, datum dobijanja, film koji se na njoj nalazi i broj
iznajmljivanja kasete. Više kaseta može biti sa istim filmom. Za
svakog člana kluba treba pamtiti kasete koje je uzeo i datum
izdavanja.