definisanje entiteta, atributa i relacija
TRANSCRIPT
S A D R Ž A J
Strana
1. UVOD......................................................................................................................................1
2. O MODELIMA PODATAKA..............................................................................................3
2.1. Objekat posmatranja – entitet...........................................................................................5
2.2. Atributi..............................................................................................................................8
2.3. Domeni...........................................................................................................................12
2.4. Veze među objektima.....................................................................................................14
2.4.1. Veza tipa 1 : 1.........................................................................................................15
2.4.2. Veza tipa 1 : N........................................................................................................15
2.4.3. Veza tipa N : M......................................................................................................16
3. PRIMER E – R ŠEME........................................................................................................16
4. ZAKLJUČAK......................................................................................................................18
LITERATURA.........................................................................................................................19
II
Definisanje entiteta, atributa i relacija
1. UVOD
Baze podataka su osnovna forma memorisanja podataka današnjice, kako u online,
tako i u offline svetu. Koriste se za memorisanje miliona različitih kombinacija/tipova
informacije kao što su podaci o proizvodima, zaposlenim, personalne, adresne informacije, itd.
Pre nego što počnete kreirati bazu podataka, nužno je razumeti osnovni koncept i
teoretske osnove: zašto se baze podataka koriste i kako se kreiraju.
Baze podataka su relativno nov, do danas najkompleksniji vid organizovanja podataka.
Postaju popularne i ulaze u sve širu primjenu tokom 70-tih godina prošlog veka.
Koncepcija baze podataka polazi od stanovišta da treba stvarati jedinstveni skup
podataka, time da između podataka postoje određeni odnosi. Jedan te isti skup podataka,
prema tome služi većem broju aplikacija, odnosno korisnika.
Baze podataka se stoga mogu definisati i kao skup međusobno povezanih, međusobno
usklađenih podataka, bez nepotrebne redundancije. Ili šire i preciznije rečeno: Baza podataka
je skup međusobno povezanih podataka, skladištenih zajedno, bez štetne ili nepotebne
redundancije, da bi na optimalan način služila jednoj ili većem broju aplikacija odnosno
korisnika. Podaci se memorišu na takav način, da budu nezavisni od programa koji se njima
služe. Za dodavanje novih podataka, odnosno modifikaciju i pretraživanje postojećih, koristi
se opšti kontrolisan pristup. To znači da ta organizacija omogućuje optimalnu upotrebu
podataka, koji se samo jednom zapisuju i s jednog mesta ažuriraju, pa mogu da služe većem
broju korisnika i aplikaciju.
U osnovi, bazu podataka možemo definisati kao organizovanu kolekciju podataka.
Baza podataka čuva i organizuje informacije. Informacija je osnov poslovanja bilo koje
kompanije ili organizacije, te je efikasna obrada informacija nužna za uspeh njihovog
poslovanja.
Baze podataka često označavamo kao DBMS (Database Management System), što je
skraćenica za Sistem za upravljanje bazama podataka. Microsoft Access je jedan od primera
sistema za upravljanje bazama podataka. Pored ovog, postoji i niz drugih, kao što su:
Microsoft SQL, MySQL, Oracle itd. Osnovne funkcije sistema za upravljanje bazama
podataka su:
kreiranje baze podataka,
1
Definisanje entiteta, atributa i relacija
fizička organizacija i pohranjivanje podataka,
pristup informacijama u bazi podataka: unos, brisanje, izmena, pregled,
zaštita podataka.
Baze podataka koriste upite (query). Upiti omogučavaju pregled podataka, unos i
izmenu podataka, i druge poslove vezane za korišćenje podataka u bazi. Upiti se grade
korišćenjem posebnog programskog jezika SQL (Structured Query Language). Ovaj
programski jezik takođe omogučava i kreiranje osnovne strukture baza podataka.
Zadatak našeg daljeg izlaganja biće da što bolje objasnimo pojmove entiteta, atributa i
relacija.
2
Definisanje entiteta, atributa i relacija
2. O MODELIMA PODATAKA1
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. 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.
Najniži nivo ANSI arhitekture je unutrašnji nivo. On je najbliži fizičkoj reprezentaciji
baze podataka, koja u računarskom sistemu jedina zaista postoji. Zbog toga se unutrašnji nivo
često i zove “nivo fizičke baze podataka”. Sledeći nivo ANSI arhitekture je konceptualni
(logički) i predstavlja način na koji se podaci iz fizičke baze podataka predstavljaju korisniku
u opštem slučaju. Najviši nivo ANSI arhitekture je spoljašnji nivo koji predstavu o podacima
iz baze prilagođava potrebama specifičnih korisnika ili grupa korisnika.
Globalna ANSI arhitektura sistema baza podataka može se predstaviti šemom na slici
1. Objasnimo nešto detaljnije njenu strukturu.
Slika 1. ANSI arhitektura sistema baza podataka
Reprezentacija koja se nalazi na “srednjem”, konceptualnom nivou ANSI hijerarhije
zove se model podataka. Modelom podataka predstavlja se logička struktura svih podataka u
bazi i skup operacija koje korisnik može izvršiti nad tim podacima. To znači da se na
1 www.download.tutoriali.org/Tutorials/Baze_podataka/Uvod_u_relacione_baze_podataka.pdf
3
Definisanje entiteta, atributa i relacija
konceptualnom nivou mogu “videti” svi podaci iz fizičke baze podataka, samo što je njihova
reprezentacija pogodnija za korisnika od fizičke (navišem je nivou apstrakcije).
Pojedini korisnici ili grupe korisnika mogu imati svoja sopstvena specifična gledanja
na model podataka (npr. iz razloga zaštite ili udobnosti), pa se pogledi (podmodeli, spoljašnji
nivo hijerarhije) nalaze iznad modela u hijerarhiji apstrakcija. Isti podaci iz fizičke baze
podataka (i sa konceptualnog nivoa), na ovom nivou mogu se raznim korisnicima predstaviti
na razne načine, dok se postojanje nekih podataka može od nekih korisnika i sakriti. Zato
postoji tačno jedan model podataka u sistemu, koji se odnosi na celokupnost baze podataka, i
veći broj spoljašnjih pogleda, od kojih se svaki sastoji od apstraktne slike dela baze podataka.
Na primer, baza podataka o studentima može da sadrži podatke iz dosijea studenata, sa
ličnim podacima i podacima o uspehu (predmetima, ocenama, datumima polaganja,
nagradama, kaznama) svakog studenta. Na konceptualnom nivou podaci mogu biti
predstavljeni tabelama DOSIJE, NASTAVNI PLAN, NAGRADE I KAZNE i POLAGANJE.
Na spoljašnjem nivou, korisnicima statističkih obrada ova baza podataka može se predstaviti
kao da sadrži samo podatke o uspehu (npr. u virtuelnoj tabeli USPEH PO PREDMETIMA);
ostali, lični podaci koji mogu da identifikuju studenta, skrivaju se od statističkih aplikacija.
Različitim podgrupama korisnika mogu odgovarati još apstraktnije predstave o podacima, koje
odgovaraju višim nivoima podmodela.
Korisnik svoje zahteve za operacijama nad bazom podataka postavlja na
konceptualnom ili spoljašnjem nivou, i to interaktivno, na posebnom “jeziku podataka”, ili
programski, kada je jezik podataka ugnježden u neki programski jezik opšte namene.
Na nivou fizičke baze podataka – unutrašnjem nivou, model podataka predstavlja se
specifičnim, fizičkim strukturama podataka (datotekama sa sekvencijalnim, indeksnim ili
direktnim pristupom), i procedurama za fizičku realizaciju operacija koje korisnik zadaje na
višem nivou.
Primarni cilj modela podataka u kontekstu baza podataka jeste da obezbedi formalni
sistem za predstavljanje podataka i manipulisanje podacima u bazi podataka.
Najapstraktniji nivo projektovanja baze podataka jeste model podataka, što je
konceptualni opis prostora problema. Modeli podataka sastoje se od elemenata koji mogu biti
entiteti, atributi, domeni i veze. U preostalom delu pojedinačno razmatramo te elemente.
4
Definisanje entiteta, atributa i relacija
2.1. Objekat posmatranja – entitet2
Podaci koje sakupljamo, memorišemo, organizujemo i obrađujemo nalaze se u svetu
oko nas i vezani su za neki proces koji se odvija u delu realnog sveta iz našeg okruženja, delu
koji želimo da bliže upoznamo na osnovu podataka iz njega.
Proces po definiciji predstavlja promenu jedne ili više veličina u vremenu (na primer:
promena temperature vazduha, kretanje nataliteta u nekom regionu, varijacija bruto
nacionalnog dohotka, promena opterećenosti elektroenergetskog sistema, itd.).
Podaci kojima se opisuje proces (koji je kontinualan u vremenu) su diskretne veličine
(poznajemo ih samo u određenim vremenskim trenucima) pa je postupak analize i praćenja
procesa preko podataka neka vrste analogno-digitalne (A/D) konverzije.
Iz diskretne baze podataka nova informacija dobija se obradom diskretnih podataka –
pa je i nova informacija diskretna veličina.
Da bismo izveli pomenutu “A/D konverziju”, i kontinualni proces opisali ograničenim
brojem diskretnih podataka, prisiljeni smo da definišemo naše “viđenje” za nas interesantnog
dela realnog sveta. Dobijeni rezultat naziva se kratko model-objekat, entitet, ili samo objekat.
Svojstva objekata opisuju se preko atributa (koje moramo odabrati u fazi modelovanja
objekta) a skup dozvoljenih vrednosti koje neki atribut može uzeti naziva se domen.
Na primer, objekat UČENIK opisuje se atributima – ocenama čiji domen je skup
prirodnih brojeva od jedan (1) do pet (5).
Broj atributa (n) koji su od značaja za opis nekog entiteta zavisi od procesa i obrade
podataka koju treba obaviti. Koji su to relevantni atributi kojima će se opisati neki entitet u
svakom konkretnom slučaju mora da definiše kompetentna osoba, jer će od toga zavisiti
upotrebljivost i verodostojnost obradom dobijenih informacija.
Ako odaberemo premalo atributa, ili atribute koji nisu relevantni za taj proces, model
će biti jednostavan za obradu i analizu, ali će mu verodostojnost biti mala, pa će i broj korisnih
i upotrebljivih informacija koje on može da prezentira biti ograničen, ili ih uopšte neće ni biti.
A ako se model opiše preterano velikim brojem atributa, njegovoj verodostojnosti se
neće moći prigovoriti, ali manipulacija podacima postaje teška – a dobijene informacije
najčešće konfuzne. Prema tome: prepoznavanje mere pri modelovanju procesa (pri izboru
2 www.vipos.edu.rs/e-nastava/file.php/11/BP01-uvod.pdf
5
Definisanje entiteta, atributa i relacija
broja atributa) jedan je od osnovnih zadataka projektanta informacionog sistema.
Ako je, na primer, predmet našeg interesovanja član radnog kolektiva posmatran sa
aspekta ličnog dohotka, onda atribut “broj cipela” nije relevantan.
Međutim, ako nam je potrebna informacija za nabavku HTZ opreme koju ta firma
nabavlja za svoje radnike, onda su broj cipela i veličina radnog odela i te kako važni podaci.
Entitet ili objekat, po prirodi može biti veoma različit kao na primer:
deo okruženja (član kolektiva, aparat, zgrada…..)
apstraktni pojam (neka mera, nečije zvanje, boja,…..)
događaj (udes, postupak upisa studenata,…...)
asocijacija (polaznik-kurs, predmet-nastavnik,)
itd.
Kako je proces po definiciji dinamička kategorija (njegovi pokazatelji se menjaju u
vremenu) to se i podaci kojima se proces opisuje moraju ažurirati, odnosno osvežavati u
vremenu. Kada, kako često, i ko će ažurirati podatke sledeci je važan faktor u projektovanju
informacionog sistema pa i to mora biti precizno definisano.
Veličine koje se ne menjaju u vremenu kao što su; broj π, ubrzanje zemljine teže g,
dielektrična konstanta vakuma ε0 i tome slično dovoljno poznavati samo jedanput.
Posmatrajmo postupak modelovanja objekta na jednom jednostavnom primeru:
Pretpostavimo da u sektoru za urbanizam neke opštine žele da imaju informacije o
ulicama u toj opštini. Entitet (objekat), je prema tome ULICA, a relevantni atributi kojima se
opisuje ulica mogli bi biti:
naziv,
dužina,
širina,
vrsta kolovoza,
godina izgradnje,
broj kuća,
dok podatak o promeni temperature asfalta u toku godine, u ovom slučaju, nećemo smatrati
relevantnim. Entitet ULICA definisan preko atributa možemo predstaviti kao:
ULICA < naziv, dužina, širina, vrsta_kol., god_ izg., broj_kuća… >
6
Definisanje entiteta, atributa i relacija
Za svaku ulicu vriednosti nabrojanih atributa, dakle podaci kojima se jedna ulica
pobliže opisuje, su različiti, a mogu se vremenom i promeniti (na primer: promena naziva
ulice, dužine, broja kuća itd.) što zahteva pomenuto, povremeno, “osvežavanje” podataka.
Veličina, odnosno dužina, tabele u kojoj će se nalaziti podaci o svim ulicama u opštini
zavisi od broja ulica pa je broj redova u tabeli, broj takozvanih slogova, ili n-torki, jednak
broju ulica u toj opštini. Na primer:
ULICA
Naziv Dužina(km)
Širina(m)
Vrsta kolovoza
Godina izgradnje
Broj kuća
Sime Milutinovića 0.56 12.30 asfalt 1908 231Jove Jovanovića 0.20 7.50 granitne kocke 1898 56Vuka Karadžića 1.75 6.00 asfalt 1864 442Paje Jovanovića 0.08 5.50 kaldrma 1888 12
Slika 2. Primer tabele ULICA
Izgradnjom nove ulice, njeni podaci se onda samo dopisuju u već postojeći spisak, u
postojeću tabelu. Prema tome; svaka tabela mora da ima definisano:
ime ili naziv tabele,
spisak atributa i
niz vrednosti atributa, to jest podatke.
Da rezimiramo; tabela se sastoji od polja u koja se upisuju podaci. Slaganjem polja u
jednom redu tabele dobijamo jedan:
slog, red, ili n-torku,
a skup svih redova (slogova), svih n-torki neke tabele čini:
telo tabele.
Neka druga tabela, u istom sektoru pomenute opštine, može da sadrži podatke o nekom
drugom entitetu – objektu, na primer, stambenim zgradama u toj opštini. Nazovimo tu tabelu
ZGRADA, a skup za nju relevantnih atributa mogao bi biti:
ZGRADA < ulica, kućni_br., god_izg., br_sprat., br_stanova, itd. .>
U tabeli (Umesto termina TABELA neki autori koriste termin DATOTEKA a često,
posebno u literaturi o relacionim bazama podataka, uz još neka ograničenja, i termin
RELACIJA) ZGRADA ulica je atribut, dok je u prethodnom primeru tabela imala taj naziv.
7
Definisanje entiteta, atributa i relacija
Naziv atributa u jednoj tabeli može prema tome biti naziv neke druge tabele. Izbor imena
atributa i tabela je proizvoljan a diktiran je pre svega našim željama, interesima i “pogledima”
koje na realni svet hoćemo da ”bacimo” preko podataka koje posedujemo, odnosno koje
informacije očekujemo da iz njih možemo dobiti.
Preporučuje se da ime tabela kao i atributa treba da asociraju na prirodu procesa koji
se u toj tabeli prati podacima. Korišćenje istih naziva treba u principu izbegavati jer to
najčešce dovodi do grešaka koje se tek kasnije u toku rada otkrivaju. Kod izbora imena
atributa posebno treba biti obazriv, jer osnovno pravilo kaže da:
atribut mora biti tako odabran (definisan) da se može iskazati samo jednom izričnom
rečenicom, to jest definisati samo jednim elementarnim (atomarnim) podatkom.
Ako je za opis atributa potrebno više podataka, onda nije više u pitanju atribut, nego
po svoj prilici novi entitet sa svojim atributima.
Tako u navedenim primerima, kada je od interesa bio entitet – stambena ZGRADA –
naziv ulice u kojoj se ta zgrada nalazi je u tabeli ZGRADA atribut za koji postoji “atomaran”
podatak – naziv te ulice.
Ali ako nam pored naziva ulice treba još podataka o ulici (na primer, dužina, širina,
itd.) ULICA postaje novi objekat – entitet sa svojim atributima a atribut naziv ulice u tabeli
ZGRADA treba brisati.
2.2. Atributi3
Sistem koji projektujete moraće da evidentira određeene činjenice o svakom entitetu.
Kao što smo već videli, te činjenice su atributi entiteta. Na primer, ako u svom sistemu imate
entitet Kupac, verovatno će vam biti važno da znate imena i adrese kupaca, a možda i njihova
zanimanja. Ako modelujete događaj kao što je ZahtevZaServisiranje, verovatno ćete hteti da
znate koji je klijent u pitanju, ko je zvao, kad je zvao i da li je problem rešen. Svi navedeni
elementi su atributi.
Određivanje atributa koje ćete ugraditi u svoj model jeste semantički postupak, što
znači da odluke morate donositi na osnovu značenja podataka i načina na koji će se oni
koristiti. Pogledajmo čest primer: adresu. Da li ćete adresu modelovati kao jedan entitet
3 www.mikroknjiga.rs/Knjige/PBP01_PBP.pdf
8
Definisanje entiteta, atributa i relacija
(Adresa) ili kao grupu više entiteta (Ulica, Broj, Grad, PoštanskiBroj, Država)? Većina
projektanata obično automatski razbija adresu na grupu atributa zbog opšteg principa da se
lakše radi sa strukturiranim podacima, ali to nije uvek tačno, a svakako nije očigledno.
Kao primer, uzmimo lokalno udruženje muzičara amatera. Potrebno im je da
evidentiraju adrese svojih članova kako bi mogli da štampaju nalepnice za koverte. Pošto je to
jedina svrha za koje će se adrese koristiti, nema razloga da se adresa ikada tretira drugačije
nego kao jedan blok od više redova teksta, koji se štampa na zahtev.
Ali šta je sa kompanijom koja se bavi prodajom robe u SAD putem Interneta? Zbog
obračuna poreza, kompaniji je potrebno da zna u kojoj saveznoj državi živi svaki njen kupac.
Iako se podatak o saveznoj državi može izdvojiti iz tekstualnog polja koje odgovara udruženju
muzičara, to nije lako; prema tome, logično je da u ovom slučaju treba modelovati barem
saveznu državu kao zaseban atribut. Šta je sa ostalim delom adrese? Da li bi trebalo da ga
razbijemo na više atributa i koji bi to atributi bili? Možda biste pomislili da bi odgovarao skup
atributa (Kućni broj, Ulica, Grad, Savezna država, Poštanski broj)? Međutim, može zatrebati i
broj stana, broj poštanskog pretinca i APO adresa. Šta ćete uraditi ako je u pitanju uslužna
adresa koja pripada nekom drugom? Pošto svet postaje sve manji, ali ne manje složen, šta će
se desiti kada dobijete prvog klijenta u inostranstvu? Domaće adrese imaju prilično
standardizovan format, ali to ne važi za porudžbine iz inostranstva.
Ne samo što morate da znate ciljnu državu i da tome prilagodite format poštanskog
broja, nego ćete možda morati da menjate i redosled atributa. Na primer, za razliku od SAD, u
većem delu Evrope kućni broj se piše iza imena ulice. To nije tako loše, lako ćete se setiti toga
kada budete unosili podatke, ali koliko će vaših operatera znati da adresa 4/32 Griffen Avenue,
Bondi Beach, Australija, znači stan broj 4, u zgradi na broju 32?
Suština u ovom slučaju nije to da je teško modelovati adresu (mada jeste), nego da ne
možete unapred određivati kako ćete modelovati određenu vrstu podataka. Složen sistem koji
razvijete za obradu međunarodnih porudžbina, biće potpuno neprikladan za udruženje
muzičara.
Slikaru Matisu pripisuje se tvrdnja da je slika gotova tek kad joj se više ništa ne može
ni dodati ni oduzeti. Projektovanje entiteta pomalo je slično tome. Kako znate da ste stigli u tu
fazu? Nažalost, odgovor glasi da u to nikad ne možete biti potpuno sigurni (a čak i ako mislite
da jeste, s vremenom ćete promeniti mišljenje). Pri tekućem stanju tehnologije, ne postoji
9
Definisanje entiteta, atributa i relacija
način da projektujete strukturu baze podataka za koju se može dokazati da je potpuno
ispravna. Možete dokazati da u određenoj strukturi ima propusta i grešaka, ali ne možete
dokazati da ih u drugoj strukturi nema. To znači, otprilike, da ne možete dokazati svoju
“nevinost”. Kako se može rešiti taj problem? Nema strogih pravila, ali postoji nekoliko
strategija.
Prva strategija: Krenite od rezultata i nemojte praviti složeniju strukturu nego što
je zaista potrebno. Na koja pitanja vaša baza podataka mora davati odgovore? Pošto je u
našem prvom primeru, udruženju muzičara, jedino pitanje bilo: “Na koju adresu treba poslati
pismo za tu i tu osobu?”, model s jednim atributom za adresu bio je dovoljan. U drugom
primeru, kompaniji koja prodaje robu putem Interneta, bio je potreban i odgovor na pitanje:
“U kojoj saveznoj državi živi ta i ta osoba?”, pa nam je zato bila neophodna drugačija
struktura adrese da bismo došli do zahtevanog rezultata.
Razume se, morate voditi računa i pokušati da obezbedite fleksibilnost koja će pružiti
odgovore, i to ne samo na pitanja koja korisnici postavljaju sada, već i na ona koja možete
predvideti da će se pojaviti u budućnosti. Na primer, kladili bi se da će u roku od godinu dana
nakon puštanja sistema u redovnu upotrebu, udruženje muzičara zatražiti od vas da im
sortirate adrese po poštanskom broju da bi dobili količinski popust.
Trebalo bi takođe da očekujete i pitanja koja bi korisnici postavili kada bi znali da
mogu da ih postave, naročito kada automatizujete postojeći ručni sistem. Zamislite da
rukovodilac biblioteke želi da zna koliko je iz fonda od četiri miliona knjiga bilo objavljeno u
Novom Sadu pre 1900. godine. On ili ona bi vam pokazali orman s kartotekom i poželeli vam
dobru zabavu. Međutim, u dobro projektovanom sistemu koji radi s bazom podataka, ta vrsta
zahteva smatra se trivijalnim.
Jedan od zaštitnih znakova dobrih projektanata jeste temeljitost i kreativnost s kojima
podstiču potencijalna pitanja. Neiskusni analitičari često tvrde da korisnici ne znaju šta tačno
hoće. Naravno da ne znaju; vaš posao je da im pomognete da otkriju šta zapravo žele.
Međutim, pri tome morate biti oprezni. “Cena” fleksibilnosti često je veći stepen
složenosti. Kao što smo videli na primeru adrese, što više “seckate” i usitnjavate podatke, više
ćete imati posebnih slučajeva za obradu, a to će vas dovesti do tačke kada predloženo rešenje
počinje da gubi smisao.
Tako stižemo do strategije broj dva: Otkrijte izuzetke. Ova strategija ima dva aspekta.
10
Definisanje entiteta, atributa i relacija
Prvo, morate identifikovati sve izuzetke, i drugo, sistem morate projektovati tako da obrađuje
što veći broj izuzetaka, ali da pri tome ne zbunjuje korisnike. Kao ilustraciju šta tačno znači
ovaj princip, razmotrićemo još jedan primer: imena osoba.
Ako će namena sistema koji projektujete biti korespondencija, od ključne je važnosti
da imena osoba budu tačno navedena. (Prikladan primer: svu poštu koju dobijam na kućnu
adresu, a primalac je gospodin R. M. Riordan, uopšte i ne otvaram.) Većina imena osoba
prilično je jasna sama po sebi. Ako je primalac “gospođa Jelena K. Jovanović”, elementi
imena su: Oslovljavanje, Ime, Očevo Ime i Prezime, zar ne? Pogrešno. Sigurnije je (i
pravilnije po bontonu) koristiti Uobičajeno Ime i Prezime. Dalje, šta ćete uraditi kad je
primalac Sir James Peddington Smythe, Lord Dunstable? Peddington Smythe je u tom slučaju
Prezime, ili je to Očevo Ime? Šta je onda “Lord Dunstable”? A pevač Sting? Da li je to
Uobičajeno Ime ili Prezime? A šta će se desiti Umetniku Ranije Poznatom Pod Imenom
Prince? Da li vas to zaista zanima?
Poslednje pitanje nije tako besmisleno kao što se čini. Pismo čiji je primalac naveden
kao Sir James Peddington Smythe, verovatno neće nikoga uvrediti. Ali ime pomenutog
gospodina s plemićkom titulom nije Sir Smythe; u javnosti ga oslovàavaju sa Sir James ili
možda Lord Dunstable. Međutim, budimo realni, koliko vaših klijenata ima titulu lorda?
Lokalno udruženje muzičara sigurno vam neće zahvaljivati ako im napravite ekran nalik na
onaj sa slike 3.
Slika 3. Previše složen ekran za unošenje adresa
11
Definisanje entiteta, atributa i relacija
Imajte u vidu da morate napraviti kompromis između fleksibilnosti i složenosti. Mada
je važno da obuhvatite što veći broj izuzetaka, potpuno je razumno da neke od njih zanemarite
jer su suviše malo verovatno da bi opravdali “cenu” svog uključivanja u sistem.
Razlikovanje entiteta od atributa ponekad može biti teško. Reći će vam opet da je
adresa dobar primer kao i da vaša odluka zavisi od prostora problema. Neki projektanti
predlažu upotrebu samo jednog entiteta za adresu koji bi predstavljao sve vrste adresa koje se
čuvaju u sistemu. Sa tačke gledišta praktične realizacije, to rešenje pruža nesporne prednosti u
pogledu kapsuliranja i višekratne upotrebe koda. Međutim, sa tačke gledišta strukture baze
podataka, imamo određene rezerve.
Na primer, malo je verovatno da će se adrese zaposlenih i kupaca koristiti na isti način
i za iste namene. Verovatnije je da će se cirkularne poruke zaposlenima slati putem interne e-
pošte nego putem klasične pošte. Ako je tako, za drugi slučaj pravila i zahtevi su drugačiji.
Grozan ekran za unošenje podataka prikazan na slici 2, ili nešto slično tome, može biti sasvim
prikladan za adrese kupaca. Međutim, ako imate samo jedan entitet za adrese, morate koristiti
isti ekran i za adrese zaposlenih; malo je verovatno da je to potrebno, a još manje da će se
svideti korisnicima.
2.3. Domeni4
Definicija domena određuje vrstu podataka koje predstavlja atribut. Tačnije rečeno,
domen (engl. domain) je skup svih prihvatljivih vrednosti koje atribut može imati.
Domeni se često brkaju s tipovima podataka; to su dva različita pojma. Tip podataka je
fizički pojam, dok je domen logički pojam. “Broj” je tip podataka; “Starost” je domen. I
“Ulica” i “Prezime” mogu biti predstavljeni poljima tekstualnog tipa, ali je očigledno da su u
pitanju različite vrste tekstualnih polja, koja pripadaju različitim domenima.
Domen je uži pojam od tipa podataka jer definicija domena zahteva precizniji opis
validnih podataka. Uzmite kao primer domen Stručna Sprema, koji predstavlja stručnu spremu
osobe. U šemi baze podataka, taj atribut se može definisati kao Text, ali to ne može biti bilo
koji tekst, već samo element iz skupa (niža, srednja, viša, visoka, magistratura, doktorat).
Razume se, ne možete sve domene definisati pojedinačnim navođenjem prihvatljivih
4 www.mikroknjiga.rs/Knjige/PBP01_PBP.pdf
12
Definisanje entiteta, atributa i relacija
vrednosti. Starost, na primer, sadrži otprilike stotinak vrednosti ako je u pitanju starost osoba,
ali to mogu biti desetine hiljada različitih vrednosti kada su u pitanju muzejski eksponati. U
takvim slučajevima, umesto u obliku liste vrednosti, lakše je definisati domen u obliku pravila
koja utvrđuju da li određena vrednost pripada skupu prihvatljivih vrednosti. Na primer, Starost
Osobe može se definisati kao “celobrojna vrednost u opsegu od 0 do 120”, dok bi Starost
Eksponata bila “celobrojna vrednost veća od 0”.
Možda ste sad pomislili da je domen kombinacija tipa podataka i pravila za ispravnost
podataka. Ako tako mislite, nećete daleko stići. Pravila ispravnosti podataka isključivo su deo
integriteta podataka, a ne opisa podataka. Na primer, pravilo ispravnosti za poštanske brojeve
određuje da su prihvatljivi samo određeni brojevi, dok je domen za poštanske brojeve
“petocifreni broj”.
Obratite pažnju na to da se u navedenim definicijama pominje vrsta podataka koji se
evidentiraju (znakovni ili numerički). To puno podseća na tip podataka, ali ipak nije tako.
Tipovi podataka su, kao što je već napomenuto, fizički pojam; oni se definišu i zadaju u obliku
koji prepoznaje mašina baze podataka. Bilo bi pogrešno definisati domen kao varchar ili Long
Integer jer su to opisi specifični za određenu mašinu baze podataka (SQL Server).
Za svaka dva data domena, ako je moguće porediti atribute definisane u tim domenima
(pa prema tome, obavljati i relacione operacije kao što je spajanje, kaže se da su oni
kompatibilni po tipu (engl. type compatible). Na primer, dve relacije prikazane na slici 4
mogu se povezati putem atributa EmployeeID = SalespersonID (šifra zaposlenog = šifra
prodavca). To možete uraditi npr. da biste dobili spisak faktura koje je svaki zaposleni izdao.
Domeni EmployeeID i SalespersonID kompatibilni su po tipu. Međutim, ako pokušate da
kombinujete te dve relacije putem atributa EmployeeID = OrderID (šifra zaposlenog = broj
porudžbine), verovatno nećete dobiti smislen rezultat, uprkos tome što su oba domena
definisana sa istim tipom podataka.
Nažalost, ni mašina baze podataka Jet, niti SQL Server ne pružaju ugrađenu podršku
za domene koja bi bila jača od obične provere tipova podataka. Čak i za tipove podataka,
nijedna mašina baze podataka ne obavlja striktnu proveru tipa: obe će mirno konvertovati
podatke u pozadini. Na primer, ako koristite Microsoftov Access i u tabeli Employees
definisali ste da je EmployeeID tipa Long Integer, a u tabeli Invoices (fakture) atribut
InvoiceTotal (ukupan zbir) definisan je kao tip Currency, možete napraviti upit koji povezuje
13
Definisanje entiteta, atributa i relacija
te dve tabele kao EmployeeID = InvoiceTotal. Microsoftov Jet će vam ljubazno sastaviti
spisak zaposlenih čije su šifre (EmployeeID) jednake ukupnim zbirovima određenih faktura.
Ta dva atributa nisu kompatibilna po tipu, ali to Jet ne zna ili zanemaruje.
Slika 4. Relacije Employees (zaposleni) i Orders (porudžbine)
Zašto biste se onda uopšte petljali s domenima? Zato što su oni, izuzetno korisne alatke
pri projektovanju baza podataka. “Da li su ta dva atributa međusobno zamenjivi?” “Postoje li
pravila koja važe u jednom, a ne važe u drugom domenu?” To su važna pitanja kada
projektujete model podataka, a analiza domena vam pomaže da nađete odgovore.
2.4. Veze među objektima5
Svet u kome živimo je veoma kompleksan pa su tako i informacioni sistemi koji ga
opisuju po svojoj prirodi kompleksni, ma koliko se mi trudili da model objekta
pojednostavimo. Izdvojeni model – objekti (kada ih ima više) su redovno međusobno
povezani vezama koje su refleksija veza koje postoje među objektima i u realnom svetu. Jer,
ako to ne bi bio slučaj, informacioni sistem ne bi bio realna slika dela sveta koji opisujemo, pa
ne bi imao nikakvu praktičnu vrednost.
5 www.pf.unze.banovalinkovi/Pages%2022_41%20from%20Info21_090515b.pdf
14
Definisanje entiteta, atributa i relacija
Prirodu veza među objektima najčešće diktira čovek, ređe su te veze posledica neke
prirodne zakonitosti.
U osnovi veza među objektima su najčešće zakoni, statuti, propisi, dogovori itd., a koji
su rezultat ljudskih aktivnosti. Danas razlikujemo tri tipa veza među objektima i to:
veza tipa 1 : 1,
veza tipa 1 : N,
veza tipa N : M.
2.4.1. Veza tipa 1 : 16
Pretpostavimo da je na nekom univerzitetu uspostavljen informacioni sistem u kome
između ostalog postoje i dva objekta:
FAKULTET
DEKAN
Prva tabela FAKULTET sadrži atribute kojima se opisuju fakulteti toga univerziteta na
primer:
FAKULTET <naziv, adresa, telefon, ...............itd. >
a druga, DEKAN, sadrži atribute koji bliže definišu dekane fakulteta, na primer:
DEKAN <šifra_dekana, ime, prezime, adresa, telefon, itd,...>
Ako je zakonom određeno da svaki fakultet može da ima samo jednog dekana, a da
samo jedan profesor (jedna osoba) može biti dekan, onda je veza među tabelama FAKULTET
i DEKAN definisana – veza je tipa 1 : 1.
2.4.2. Veza tipa 1 : N7
U informacionom sistemu univerziteta može da postoji i objekat PROFESOR čiji
atributi treba da bliže opišu profesore. Na primer:
PROFESOR <šifra_profesora, ime, prezime, zvanje, adresa, itd,...>
Ako zakonski propisi propisuju da jedan profesor može biti u radnom odnosu samo na
6 www.vipos.edu.rs/e-nastava/file.php/11/BP01-uvod.pdf 7 www.vipos.edu.rs/e-nastava/file.php/11/BP01-uvod.pdf
15
Definisanje entiteta, atributa i relacija
jednom (1) fakultetu, a da svaki fakultet angažuje više (N) profesora, onda je veza između
objekata FAKULTET i PROFESOR tipa 1 : N.
2.4.3. Veza tipa N : M8
Proširenje ovog univerzitetskog informacionog sistema može se odnositi i na studente.
O svakom studentu treba imati neke podatke, na primer:
STUDENT < Br._ind, ime, prezime, god._rođ, adresa, itd,....>
Kako u toku studija svaki student dolazi u kontakt sa više (M) profesora, ali i svaki
profesor drži predavanja većem broju (N) studenata to je veza među objektima PROFESOR i
STUDENT tipa M : N.
3. PRIMER E – R ŠEME9
Kreirati E-R šemu za DB za smeštanje informacija o profesorima, predmetima i
oblastima sa sledećim stavkama:
Ime i ID broj za svakog profesora
Plata i e-mail adrese svakog profesora
Koliko dugo profesor predaje na univerzitetu
Koju oblast u kom predemtu profesor predaje
Ime, broj i naslov za svaki ponuđeni predmet
Oblast i broj učionica za svaku oblast
Svaku oblast bilo kog predmeta predaje samo jedan profesor
Svaki predmet može imati više oblasti.
8 www.vipos.edu.rs/e-nastava/file.php/11/BP01-uvod.pdf 9 www.mfkg.kg.ac.rs/index.php?option=com_docman
16
Definisanje entiteta, atributa i relacija
Profesor
Ime
Licno ime
Prezime
Kursa
Radnik ID DatumZap Radni staz
Naziv
Učionica
Tema
predaje
1 N Oblast
Oblast ID
deo
1
N
Broj
emaill
Plata
Kredit
radi
N
N
Univerzitet
Naziv
Lokacija
Telefonww
w
1N
N
N
N
1
17
Definisanje entiteta, atributa i relacija
4. ZAKLJUČAK
Model objekti-veze je konceptualni model koji realni svet vidi kao kolekciju objekata
(entiteta) i veza među njima. Osnovna komponenta ovog modela je Dijagram objekti-veze
(Entity-Relationship diagram) koji se koristi za vizuelno predstavljanje objekata.
Entitet je osnovni objekat u kojem možemo memorisati podatake. To je bilo šta što u
realnom svetu možemo identifikovati, u konkretnoj ili apstraktnoj formi, kao što je osoba,
mesto, stvar, ili događaj, a ima veze sa bazom podataka koju gradimo. Kao primer entiteta
možemo navesti: radnik, projekat, račun, artikal, pretplatnik itd. Entitet je analogan tabeli
relacionog modela podataka.
Atributi opisuju entitet sa kojim su povezani. Pojedinačan primerak entiteta sadrži
vrednosti pojedinih atributa. Npr. entitet učenik ima atribute: prezime, ime, razred, datum
rođenja, adresa, broj telefona.
Za atribut definišemo i skup vrednosti koje taj atribut može uzeti – domen. Npr, domen
atributa naziv usmerenja je skup vrednosti. Dakle, domen predstavlja egzaktan skup vrednosti
koje atribut može poprimiti, ili domen definišemo uopšteno preko tipa podataka koji može
poprimiti. Npr, u slučaju atributa prezime, kažemo da je domen kombinacija slova abecede,
maksimalne dužine 30. Atribut može biti proglašen identifikatorom entiteta. Identifikator,
mnogo češće ga nazivamo ključem, jedinistveno identifikuje primerak entiteta. Npr, za entitet
razred, ključ je atribut razred (2t1, 2s1...) jer u školi postoji samo po jedan razred 2t1, 2s1..., te
ga pomoću ovog atributa uvek možemo jedinistveno identifikovati.
Relacija (Relationship) predstavlja vezu između dva ili više objekata. Relacije se
razlikuju po stepenu, kardinalnosti, smeru, tipu i egzistenciji.
Stepen relacije je broj entitita koji su obuhvaćeni vezom. Binarna relacija je ona koja
povezuje dva objekta, ternarna povezuje tri objekta. U opštem slučaju, n-arna relacija
povezuje n objekata. Npr. između objekata ucenik i razred postoji binarna relacija
ucenik_razred. Između objekata profesor, predmet, razred postoji ternarna relacija, budući da
ona povezuje tri objekta: neki profesor predaje neki predmet u nekom razredu.
Kardinalnost relacije određena je brojem primeraka objekta koji je(su) povezan(i) sa
primerkom drugog objekta obuhvaćenog relacijom. Osnovni tipovi relacija su:
jedan prema jedan (one-to-one),
18
Definisanje entiteta, atributa i relacija
jedan prema više (one-to-many),
više prema više (many-to-many).
Veza jedan prema jedan (1:1) je ona veza kod koje jedan primerak jednog entiteta
obuhvaćenog relacijom može biti povezan sa samo jednim primerkom entiteta drugog entiteta
obuhvaćenog vezom.
Veza jedan prema n (1:N) je ona relacija kod koje za jedan primerak entiteta A postoji
nula, jedan i ili više primeraka entitata B, ali za jedan primerak entiteta B, postoji samo jedan
primerak entiteta A.
Veza N:M je ona veza kod koje je jedan primerak entiteta A povezan sa nula, jedan ili
više primeraka entiteta B, a jedan primerak entiteta B je povezan sa nula, jedan ili n primeraka
entiteta B.
Model objekti veze omogućava potpunije shvatanje funkcionisanja sistema
semantičkim opisom objekata i njihovih uzajamnih veza.
19
Definisanje entiteta, atributa i relacija
LITERATURA
1. www.download.tutoriali.org/Tutorials/Baze_podataka/
Uvod_u_relacione_baze_podataka.pdf
2. www.mikroknjiga.rs/Knjige/PBP01_PBP.pdf
3. www.mfkg.kg.ac.rs/index.php?option=com_docman
4. www.pf.unze.banovalinkovi/Pages%2022_41%20from%20Info21_090515b.pdf
5. www.vipos.edu.rs/e-nastava/file.php/11/BP01-uvod.pdf
20