44 ER JEZIK: PRIJEDLOG PROSIRENJA INFORMATICA 3/91 Keywords: entity-relatinship data model, data modeling, logical database design Mario Radovan Fakultet Ekonomije i turizma, Pula; Institut »Jožef Štefan«, Ljubljana ER LANGUAGE: A PROPOSAL FOR EXTENSION The paper gives an analysis of the expressive power and of (some) limitatins of ER language as a means for designing data models. Starting from a different "origin", "nature" and function of different entities - and from the practical need that such a features be emphasized in the model - two proposals for extending the "standard" ER language are given: symbols for process and disjunction are introduced. ER JEZIK: PRIJEDLOG PROSIRENJA U članku je data analiza izražajnih mogučnosti i (nekih) ograničenja" ER jezika kao sredstva za oblikovanje modela podataka. Polazeči od različitog "porijekla", "prirode" i funkcije pojedinih entiteta -i praktikče potrebe da se ta svojstva naglase u modelu - iznijeta su dva prijedloga proširenja "standardnog" ER jezika: uvedeni su simboli procesa i disjunkcije. 1. Uvod (use sound thinking) kod oblikovanja svojih tabela, onda nečete imati problema kod kasnijeg 'prikazivanja' svojih podataka". Autorima ove "teorije oblikovanja baze podataka" oprostiti čemo na "nepodnošljivoj lakoči" (i kratkoči) njihove teorije, jer je knjiga "Understanding Oracle" ipak pri je svega priručnik za sistem Oracle. (No, takva "teorija" zacijelo može imati (a po svemu sudeči i ima!) nepovoljan utjecaj na rjiodele podataka koje oblikuju njeni Citate!ji ! ) Model (baze) podataka tvori esencijalni dio informacijskog sistema, i presudno utječe na njegov kvalitet. Stoga je tokom posljednjih decenija razvijen niz prijedloga jezika (pretesno grafičkih) za oblikovanje modela (baze) podataka. Dominantno mjesto i najširu primjenu medu njima ima ER jezik (ili: ER model podataka, kako se češče naziva u literaturi), čija je osnova predložena u . "Nešto lakonskiji" pristup oblikovanju baze podataka moZemo nači , naprimjer, u . Tamo čitamo: "Relacijska teorija zasnovana je na zdravom razumu. ... Ako 'zdravo razmišljate' U cilju izbjegavanja mogučih (a nepotrebnih) "terminoloških prijepora", pogledajmo najprije (uobičajeno) značenje samog pojma "model podataka". 45 Prema Ullmanu, , modelom podataka nazivamo "matematički formalizam" sačinjen od dva dijela: 1. Notacije (i metode) za opis forme podataka. 2. Skupa operacija za rukovanje podacima. Obzirom da u ER jeziku nisu definirane "operacije" (niti se taj jezik eksplicitno bavi samim podacima, več samo njihovim formama) Ullman zaključuje da možemo tvrditi kako "ER model" zapravo i ni je "model podataka". Formalno, Ullmanova primjedba stoji, jer ER jezik ne ispunjava uvjet 2. Stoga ovdje i preferiramo izraz "ER jezik" (kojim se opisuju forme entiteta iz "fragmenta realnog svijeta" o kojem želimo "bilježiti neke podatke"). Utoliko bi i zapise u ER jeziku valjalo zvati "model ima forme podataka" (što ER model, zapravo, i jeste). No, radi jednostavnosti izražavanja, u nastavku koristimo izraz "ER model podataka" (kako je to, uostalom, u literaturi i uobi čajeno). Analiza i prijedlozi koje iznosimo u nastavku, uvelike temelje na iskustvima primjene ER jezika u okviru projektiranja baza podataka za potrebe turističke privrede (te su, stoga, iz tog problemskog područja uzimani i primjeri). Polazeči od tih iskustava - te od "standard-nog" ER jezika (datog u npr. , ili ) - ovdje predlažemo ono što držimo stvarnom potrebom a ne (samo) hipotetičkom mogučnošču proširenja ER jezika. 2. 0 ER jeziku Polaznu osnovu ER jezika možemo izreči otprilike slijedečim riječima: Podaci su znanja o objektima, vezama (medu tim objektima) i svojstvima (objekata odnosno veza); stoga, cilj jezika za predstavljanje strukture podataka jeste da,omoguči precizan i jednostavan zapis znanja tih triju temeljnih kategorija. (Napome-nimo, da pojmom "entitet" ovdje ne označavamo samo "objekte" - kako se to često čini - več je to "generativni pojam" koji obuhvača sve tri iznad navedene kategorije.) Na Chenov prijedlog uslijedile su brojne dopune (proširenja) jezika, posebno uvodenjem n-arnih veza za n > 2, i hijerarhije entiteta. Obzirom na terminološki i notacijski nesklad pojedinih prikaza jezika, na slici 1 data je osnovna notacija ER jezika kakvu koristimo u ovom tekstu. Pritom, imena objekata i veza upisujemo u sam simbol, a njihova svojstva zapisujemo pored simbola (kako to ilustriraju slijedeče slike). Isto tako, u simbol upisujemo i "svojstvo generalizacije" (kod general izacijske hijerarhije). Identifikatore objekata podcrtavamo. Slikal Prema Thompsonu, , ER jezik je "izuzetno koristan za razumijevanje i oblikovanje baze podataka ... Njegova temeljna odlika 46 jeste u tome Sto "prekida" sa razmišljanjem na razini "zapisa" (records)", i okreče se ka entitetima sistema. Naime, " ... zapisi su sasma beskorisni (na razini oblikovanja baze), • dok su entiteti i veze (medu njima) "obečavaju-či početak". Stoga je od suštinskog značaja "zahvatiti" upravo njih". U svom vrlo elokvent-nom stilu (viSe efektnom nego efikasnom), Thompson zaključuje: "Model podataka živi ili umire 'od lakoče' kojom se dade shvatiti". I koristiti! - dodali bismo. A dosadašnjih 15 godina široke primjene ER jezi- ka pokazuje da ER jezik - "živi". Cini se da bismo iz toga onda smjeli izvesti i zaključak o "lakoči njegova shvačanja i primjenei". ER jeziku pripisuju se odlike i kao komuni-kacijskom jeziku. "ER jezik pokazao se najus-pješnijim kao sredstvo komuniciranja izmedu projektanta i korisnika u toku analize (sistema) i oblikovanja baze podataka", nalazimo u . Ta odlika, prema Teorey et al, proizlazi iz njegove "okrenutosti entitetima" (koju ističe i Thompson), te jednostavnosti samog jezika. Ostajuči uvelike suglasni sa iznijetim pozitivnim ocjenama ER jezika, u ovom članku želimo istači njegove odlike kao sredstva za zorno dokumentiranje strukture baze podataka, ali i neka ograničenja koja "dolaze" iz nemogučnosti prikaza različitosti "porijekla" i "procesnih uloga" pojedinih entiteta modela. Iznijeti prijedlozi proširenja standardnog ER jezika imaju za cilj otklanjanje tih ograničenja (nedostataka). 3. Izvorni i izvedeni entiteti Prvi "raskorak" izmedu ER jezika "na razini načela" i "na razini primjene" dolazi odtuda Sto, u praksi, medu entitetima sistema postoji znatna razlika u prirodi nastanka (formiranja) i ulozi koju imaju u modelu (baze) podataka (odno- sno u procesu obrade podataka). S tog aspekta promatranja, držimo primjerenim (i potrebnim) entitete (tj., u samoj bazi: "tabele" i "kolone") podijeliti na slijedeči način: Svojstva: izvorna i izvedena Objekti i veze: izvorni, izvedeni i kombin i ran i. Izvedenim (izračunatim) svojstvima nazvali smo ona svojstva čije se vrijednosti izračuna-vaju (izvode) iz vrijednosti drugih svojstava (istog ili pak nekih drugih objekata). Izvornim svojstvima nazvali smo ona svojstva objekata koja nisu izvedena. Izvedenim objektima (vezama) nazvali smo one objekte (veze) čija su sva svojstva izvedena. IzvoTTTTfrCčbjeikttma (vezama) nazvali smo one objekte (veze) kod kojih nijedno svojstvo nije izvedeno. Takve objekte često nazivamo i mati čnima. Kombiniranim objektima (vezama) nazvali smo one objekte (veze) koji sadrže bar jedno (ali ne sve!) izvedeno svojstvo. 3.1. Izvedena svojstva Jednostavan primjer izvedenog svojstva imali bismo kod (slabog) objekta STAVKA, sa svojstvima: ... KOLIČINA, CIJENA, IZNOS. Oči to, svojstvo IZNOS izvedeno je svojstvo jer se njegova vrijednost izračunava iz vrijednosti svojstava CIJENA i KOLIČINA. A to bi onda ujedno značilo da na relaciji dobivenoj "prij-evodom" tako definiranog objekta STAVKA, postoji (i) funkcijska zavisnost CIJENA,KOLIČINA —> IZNOS Teorijski gledano, entiteti ne bi trebali (a ni smijeli!) sadržavati takova (izračunata) svojstva. Naime, takva svojstva, zapravo (u buduču tabelu) uvode redundantna polja, a tirne - u pravilu - i funkcijske zavisnosti koje nisu od ključa. Prihvatimo da je u promatranom primjeru (i praktički gledano) odista nepotrebno eksplicitno "čuvati" vrijednosti svojstva IZNOS jer je CPU vrijeme za njegovo izračunavanje zanemarivo 47 malo u odnosu na vrijeme dostupa do samog zapisa u kojem su sadržane vrijednosti za njegovo izračunavanje. Drugim riječima, dostup do "iznosa" neznatno varira u zavisnosti da Ti ga samo čitamo ili ga i izračunavamo. Medutim, sa aspekta ER modela, zanimlj i vi j i m izgleda problem prikaza izvedenosti onih svoj-stava čije se vrijednosti izračunavaju na temelju vrijednosti svojstava drugih objekata. Takav primjer dat je na slici 2. IDNAM N NAZIV NAMGJ PRODCJ Sliko 2 Relacijski zapis tog modela glasi: NAMIR(IDNAM.NNAZIV.NAMCJ) SASTAV(IDNAM.IDJELA.NORMATIV) JEL0(IDJELA.JNAZIV■SASCJ,PRODCJ). U ovom modelu, izvedeno svojstvo jeste SASCJ (cijena sastojaka (namirnica) u datom jelu). Vrijednost tog svojstva izračunava se iz vrijednosti (izvornog) svojstva NAMCJ (cijene namirnica) i izvornog svojstva NORMATIV veze SASTAV. Naime, normativ pokazuje količinu pojedine narnirnice u pojedinom jelu. Napomenimo da svojstvo PRODCJ (prodajna cijena jela) jeste izvorno svojstvo, jer se njegova vrijednost ne izračunava (al gor itamski) iz cijene sastojaka (SASCJ). Naime, iako se vrijednost SASCJ svakako uzima kao osnova, ipak se vrijednost svojstva PRODCJ utvrduje apro-ksimativno, i to u zavisnosti od niza faktora, poput energije i rada potrebnih za pripremu (i serviranje) jela, pouzdanosti ponude namirnica, potražnje jela, itd. Vratimo se izvedenom svojstvu SASCJ. U razmatranom slučaju, pokazalo se potrebnim ("procesno opravdanim") uvodenje tog (redun-dantnog) svojstva u model podataka. Naime, to se svojstvo često koristi, i to ne samo za aproksimativno utvrdivanje prodajne cijene jela, več i kod raznih drugih kalkulacija. Bilo bi stoga neopravdano - zbog samog načel nog zahtjeva po neredundantnosti modela - to svojstvo izostaviti iz njega. Medutim, ostavljajuči po strani probleme redundance na razini relacijskog modela (tj. na razini "tabela podataka"), ovdje se postavlja pitanje da 1 i i kako - u samom ER modelu -eksplicitno prikazati izvedenost svojstva i/ili način izračunavanja njegove vrijednosti. Drugim riječima, valja odlučiti o eventualnoj eksten-ziji ER jezika uvodenjem (simbola) procesa. Na slici 3 dat je jedan prijedlog načina na koji se to može uči ni ti. PRODCJ Slike 3 Čini se da bi takva ekstenzija jezika učini-1a model informativnijim (a da pritom ipak ne zademo u DeMarcov dijagram toka podataka (DTP, )). Medutim, kod opsežnijih modela, eksplicitnim prikazom procesne prirode svojstava (pose- bno ako izvedenih svojstava ima mnogo!) model bi mogao brzo postati nepreglednim. A upravo smo jasnoču i preglednost modela podataka isticali kao temeljnu odliku ER jezika 48 u ulozi sredstva za dokumentiranje. Stoga, prijedlog sa slike 3 - na razini izvedenih svojstava - navodimo samo kao mogučnost, ali ne i kao obavezan element ER jezika. U nastavku, razmatramo potrebu (opravdanost) uvodenja simbola procesa na razini prikaza izvedenih objekata (veza). REZERV IDREZ DATUM IME ADRESA TIPSMJ OBJEKT OD DO KOL 3.2. Izvedeni objekti (veze) Prema danim definicijama, objekt NAMIRnice i veza SASTAV jesu izvorni. Objekt JEL0 je kombiniran jer sadrži jedno izvedeno svojstvo (ali i dva izvorna svojstva). No, čini se da posebnu pažnju zaslužuju izvedeni objekti (veze). Potrebu po uvodenju takvih entiteta analiziramo na primjeru situacije koju opisuje model podataka sa slike 4. Slika 5 ID OBJ NAZIV KATEG IDSMJ 0P1SS STATUS Slika 4 Model sadrži objekte: OBJEKT (hotel, turi-stičko naselje, ... ) SMJED (smještajna jedini-ca u okviru objekta) i TIPSMJ (tip smještajne jedinice, odreden prema kapacitetu, komforu, ... pojedine smještajne jedinice). Postavlja se pitanje da li takav model omo-gučava da se izvrši rezervaciju npr. 5 smješ-tajnih jedinica datoga tipa. Uzmimo pritom da bi rezervacija mogla (morala) sadržavati barem svojstva data na slici 5. Model sa slike 6 pokazuje na koji način je to moguče uči ni ti. IDREZ Slika 6 Medutim, več pokušaj provjere ispunjenosti prvog preduvjeta za prihvačanje rezervacije -naime, postojanja slobodnih smještajnih jedinica! - ukazuje na izrazite slabosti takova rješenja. Naime, prema modelu podataka sa slike 6, uvid u "slobodne kapacitete" bio bi procesno vrlo zahtjevan. Jer postojanje slobodnih smještajnih jedinica (u datom objektu, datog tipa, u datom periodu) bilo bi moguče utvrditi jedino tako da se za dati objekt najprije izračuna broj smještajnih jedinica (datog tipa); da se zatim - iz tabele REZERVacije - utvrdi rezerviranost (zauzetost) jedinica toga tipa (za dati period), te da se "iz razlike" utvrdi postojanje i broj slobodnih smještajnih jedinica - i tek nakon toga izvrši rezervaciju (ako slobodni kapacitet to dopušta). Naravno, iako je takav postupka - u kontekstu datog 49 modela podataka - moguč, operativno ("procesno") promatrano, takav bi postupak izračunavanja bio krajnje suboptimalan. Proces provjere prihvatlj ivosti (a i izvrše-nja) rezervacije dade se bitno pojednostaviti uvočenjem redundantnog entiteta (veze) KAPacitet. (Dakle, odstupanjem od jednog od temeljnih načela oblikovanja modela podataka, koje u glasi: "Redundantne veze trebaju biti eli mi ni rane! ") Pritom, kapacitetom nazivamo količinu smještajnih jedinica po tipovima i objektima. Dakle, KAPacitet može biti prikazan vezom (mnogo-mnogo), kako je to učinjeno na si i ci 7 . Nadalje, status zauzetosti sobe odnosno kapaciteta ne mijenja se samo na temelju rezervacije, ali u te pojedinosti ovdje nema potrebe zalaziti.) Na razini "zornog prikaza i dokumentacije", model podataka sa slike 7 pokazuje dvije slabosti, 1. Objekt REZHRVacija ne možemo "vezati" na vezu KAPacitet. (Naime, veza može "stajati" samo izmedu objekata.) Stoga smo prinudeni postupiti na jedan od dva načina data na slici 8. Za vezu rezervacije i kapaciteta sa slike 8a, možemo reči da je (u najboljem slučaju) IDOBJ NAZIV KATEG Slika 7 IDSMJ 0P1SS STATUS Napomenimo da je svojstvo N0MK (nominalni kapacitet) skalar, a da je svojstvo SLOBK (slo-bodni kapaciteti) vektor (sa 366 polja), pri čemu svako sadrži broj slobodnih smještajnih jedinica (datog tipa u datom objektu) za pripa-dni dan u godini. Rezervacija je sada, naravno, moguča ako - u traženom periodu - broj slobo-dnih smještajnih jedinica nije manj i od broja traženih. A uz postojanje izvedene (redundan-tne) veze KAPaciteti, to je trivijalno utvrdi ti. Naravno, prihvačanje rezervacije uvjetuje i on-line ažuriranje vrijednosti svojstva SLOBK za dati period. (Napomenimo, da se i na razini smještajne jedinice vodi analogna evidencija (svojstvo STATUS), i to zbog omogučavanja rezerviranja točno odredene smještajne jedinice. («I (b) Slika 8 IDOBJ NAZIV KATEG IDSMJ OPISS STATUS 50 "implicitna". Naime, postojanje takve veze nipošto nije "očito" iz samog modela, več to postaje tek ako se "prisjetimo" da če se - kao vanjski ključevi - u shemi relacije REZERVacija nači svojstva IDOBJ i IDTIP, te da upravo taj par svojstava tvori identifikator (ključ) veze (relacije) KAPaciteti. 2. Uvodenje simbola objekt-veza (), kako je to učinjeno na slici 8b, omogučuje eksplicitni pokaz vezanosti rezervacije na kapacitet, te stoga uvodenje takvog simbola držimo korisnim. Medutim, nijedan od dvaju navedenih načina ne pokazuje ekspl ici trio da je entitet KAPaciteti izvedeni entitet! (Dakle, "formalno redun-dantan", ali "procesno potreban"!) Stoga, ovdje predlažemo uvodenje "procesnog simbola", koji je več "ispitivan" kod izvedenih svojstava, a čije uvodenje držimo sasma opravdanim kod izvedenih objekata odnosno veza. Naime, izgleda da se tim proširenjem ER jezika ne gubi ništa; model neče postati nepregledni jim, več upravo suprotno, kako to ilustrira slika 9. Slika 9 Za izvedeni entitet KAPacitet možemo reči da - posredstvom procesa P - si i jedi iz (slabog) objekta SMJED. Naime nominalni kapacitet (NOMK) - po smještajnim objektima i tipovima smještaj-nih jedinica - izračunava se na temelju svojstava objekta (budučih "kolona tabele") SMJED, što modeli sa slike 8 nisu eksplicitno pokaži val i. Razmotrimo i izvedeno svojstvo SLOBK (slobo-dni kapaciteti). Naime, učinivši "prvi korak" ka "procesualizacij i" modela podataka, postavlja se pitanje zašto ne učiniti i više. Napri-mjer, zašto ne pokazati eksplicitno (u modelu) i "način utjecaja".rezervacije na slobodan kapacitet (SLOBK), kako je to učinjeno na slici 10? IDFIEZ DATUM SlikalO Očito, ovakav način prikazivanja "porijekla i procesne prirode" izvedenih svojstava čini model podataka informativnijim. Medutim, u slučajevima gdje ima velik broj izvedenih svojstava, ekspliciten prikaz procesa (načina) njihova formira- nja, doveo bi do toga da model podataka postane nepreglednim. Stoga, uvodenje "procesnih opisa" na razini izvedenih objekata/veza držimo sasma opravdanim i korisnim. S druge strane, primjerenost uvode-nja takova prikaza na razini svojstava zavisi od specifičnih osobina konkretnog modela podataka. Konačno, želimo li imati oboje: informativ-nost i preglednost, model možerno prikazati na dvije razine detalj izacije. Dakle, na "global- 51 noj razini" (bez procesnih opisa za svojstva), i na "razini detalja" (sa takvim opisima). 4. Veze i disjunkcija Sistem rezervacija mora omogučavati rezervaciji! ne samo datog tipa smještajne jedinice, več i točno odredene smještajne jedinice. Modeli sa slika 6 - 10, očito to ne omogučava-ju. Nadalje, rezerviranje može vršiti pojedinac ili agencija; isto tako, valja omogučiti da se jednom rezervacijom rezerviraju bilo razne smještajne jedinice (ili jedinice raznih tipo-va), bilo pojedinačnih smještajnih jedinica, i to za razna vremenska razdoblja. Naime, bilo bi neprikladno da se za jedno (npr. agencijsko) rezerviranje otvara toliko rezervacija (tj., da se toliko puta ponavlja pisanje "zaglavlja") koliko se (tipova) smještajnih jedinica rezei— vira. Stoga, objektu REZERVacija pridružujemo slabi objekt STAVKA, kako je to učinjeno na siici 11. IDREZ DATUM IDAGEN NAZIV IME ADR TEL IDSTAV IDOBJ IDTIP IDSMJ OD DO KOL Očito, tako definirani objekti imaju niz svoj stava koja se mečusobno isključuju. Napri-mjer, ako rezervaciju vrši agencija, onda je svojstvo IME isključeno ("neprimjen1 j ivo"); jednako neprimjen1 j i v ima bivaju svojstva IDAGEN ("šifra" agencije) i NAZIV kada rezerviranje vrši individualni gost. Analogno vrijedi za STAVKE: ako se rezervira tip (IDTIP), onda je broj smještajne jedinice (IDSMJ) neprimjen1 j i v. U suprotnom, rezervacija točno odredene sobe isključuje potreba po ekspliciranju tipa. U takvim situacijama - prema načelu oblikovanja modela podataka - uvode se podtipovi (primjere-ni (disjunktnim) podskupovima instanci datog tipa entiteta). Slijedeči rigorozno to načelo, sačinili bismo model podataka dat na slici 12. Slika 12 No, takav model ne bi se nipošto odlikovao preglednošču. Nadalje, (nepotrebno) veliki broj relacija (tabela) koje bi iz njega nastale ne bi predstavljao optimalno rješenje ni sa proce-snog, a ni sa čisto operativnog (praktičkog) aspekta. Stoga, ovdje predlažemo pojednosta-vljenje modela (i njegova prikaza!) uvodenjem (simbola) disjunkcije na razini veze, kako je to pokazano na slici 13. Slikali 52 IDG05T IPAG^N Slika 13 Prijevod takova ER modela glasio bi: GOST(IDGOST.IME■ADR,TEL) AGENC(IDAGEN,NAZIV.ADR.TEL) RERERV(IDR£Z>DATUM,IDAGEN,IDGOST) STAVKE(IDREZ■IDSTAV.IDOBJ,IDTIP, IDSM J,OD,DO,KOL) SMJEDCIDOBJ■IDSMJ.OPIS.STATUS) KAPAC(IDOBJ.IDTIP,NOMK,SLOBK) TIPSMJ(IDTIP.OPIS) OBJEKT tIDOBJ. ... ) Promatrano sasma operativno, pri likom otva-ranja rezervacije, mogao bi biti uspostavljen neki fiktivni indentifikator (npr. redni broj rezervacije) jer taj identifikator nema neke izravne praktičke primjene. Nadalje, nakon pre-uzimanja datuma, ako se radi o individualnom gostu onda se IDAGEN "preskače" (neprimjenljivo svojstvo), te se uzimaju podaci o gostu. (Način i razlozi (u)vodenja i (trajnog) čuvanja zapisa o (potencijalnom) gostu ovdje su nevažni). U suprotnom, postupa se analogno sa agencijom. (Napomenimo, da se iz "praktičkih razloga" -pored IDAGEN / IDGOST - u rezervaciju, u pravilu, zapisuju i redundantna svojstva poput naziv/ime, adresa, telefon, ... .) Slijedi upisivanje (jedne ili više) stavki, pri čemu IDSTAV može biti jednostavno redni broj stavke u rezervaciji. Ako se vrši rezervacija na razini kapaciteta, onda broj sobe (IDSMJ) ostaje "prazan"; u suprotnom, ispunja-vaju se sva polja, s tirne da KOLičina biva "1". Dakle, čini se da uvodenje disjunkcije veza s jedne strane daje znatno pregledni j i model poda- taka, a s druge strane (implicitno) odražava i sam proces vršenja rezervacije. Naravno, to ni pošto ne znači da model podataka "nameče" detalje same procedure koristenja informacij-skog sistema (npr. redoslijed operacija kod rezerviranja). Procedura rezerviranja može se zacijelo odvijati i drukčije (npr. pitanje što se i gdje rezervira može prethoditi pitanju tko rezervira), pri čemu model podataka ostaje, naravno, sasma nezavisnim od operativnih postu-paka takove vrste. Naravno, specifičnosti mjesta na kojem se vrši rezerviranje (npr. centralna recepcija, ili pak recepcija pojedinog objekta (hotela)) mogu zahtijevati prilagodbu modela. Naprimjer, ako se rezervacija može vršiti samo za jedan objekt (na recepciji tog objekta), onda podaci o objektu zacjelo neče ulaziti u stavke. U tom slučaju, OBJEKT bi - prema potrebi - mogao biti "vezan" na "zaglavlje rezervacije" (tj. na objekt REZERV). 5. Zaključak Poput svakog formalnog sistema, jezik za oblikovanje modela (baze) podataka "kreče se" izmedu dvaju - u pravilu, protustavljenih -zahtjeva: po jednostavnosti i po " izražajnosti" (tj. po "semantičkom bogatstvu"). U ovom članku ukazali smo na potrebu i opravdanost proširenja 53 ER jezika uvodenjem dvaju novih simbola: simbola procesa i simbola disjunkcije. Pokazali smo kako ti simboli povečavaju mogučnosti (a i jednostavnost!) oblikovanja modela podataka pomoču ER jezika. Naravno, svjesni smo da uvo-denje novih elemenata (posebno procesnih) može "zasjeniti" sam model podataka. No, mnijenja smo da ovdje iznijeti prijedlozi to ne čine, več da pri je doprinose njegovoj preglednosti. reference Brackett, H.M.: Developing Data Structured Databases, Prentice-Hall, 1987. Chen, P.P: The Entity-Relatinship Model: Toward a Unified View of Data, ACM Trans, on Database Systems, No. 1, 1976. Date, C.J. : An Introduction to Database Systems, Vol. 1, Addison-Wesley, 1990. Furtado, L.A., Neuhold, J.E.: Formal Techniques for Data Base Design, Springer-Verlag, 1986. Hawryszkiewycz, I.T.: Systems Analysis and Design, Prentice Hal 1, 1988. Martin, J.: Recommanded Diagramming Standards for Analysts & Programmers: A Basis for Automation, Prentice-Hall, 1987.