definisanje entiteta, atributa i relacija

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


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


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

http://www.download.tutoriali.org/Tutorials/Baze_podataka/Uvod_u_relacione_baze_podataka.pdf


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


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

http://www.vipos.edu.rs/e-nastava/file.php/11/BP01-uvod.pdf


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


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


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

http://www.mikroknjiga.rs/Knjige/PBP01_PBP.pdf


(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


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


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


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



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


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

http://www.pf.unze.banovalinkovi/Pages%2022_41%20from%20Info21_090515b.pdf


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




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

http://www.mfkg.kg.ac.rs/index.php?option=com_docman



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


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


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


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


http://www.pf.unze.banovalinkovi/Pages%2022_41%20from%20Info21_090515b.pdf

http://www.mfkg.kg.ac.rs/index.php?option=com_docman


http://www.download.tutoriali.org/Tutorials/Baze_podataka/%20Uvod_u_relacione_baze_podataka.pdf

http://www.download.tutoriali.org/Tutorials/Baze_podataka/%20Uvod_u_relacione_baze_podataka.pdf

definisanje entiteta, atributa i relacija

Documents