Izrada informacionog sistema biblioteke

Naime, poceo sam da projektujem informaiconi sistem biblioteke i to u ERWin CASE alatu. Pri kraju sam ove prve faze izrade informacionog sistema a ta prva faza je Funkcionalno modeliranje (pod knjizi Razvoj informacionih sistema od Alempija Veljovica). Tehnika koja se koristi je IDEF0. Kad zavrsim funkcionalno modeliranje prelazim na informaciono modeliranje u ERWin alatu. Ukolio ste upoznati sa ovim alatom i ovim nacinom projektovanja izvolite dajte komentare radi poboljsanja a ukoliko nesto mozete da iskoristite za vas rad ili zbog ucenja samo izvolite preuzmite ovaj fajl. Instalaciju BPWin alata mozete naci na biske.sitesled.com/Download.html.

---

BPwin ili ERwin? Nije isto :)
Da li bi mogao da okacis slike za nas koji ne samo da ne koristimo ERwin nego ne koristimo Windows?

---

Da pojasnim neke stvari. BPWin se koristi za funkcionalno modeliranje, kada se to zavrsi taj fajl (koji sam okacio uz poruku gore) se izvozi u ERWin gde se onda radi informaciono modeliranje. Kada se i to zavrsi onda se projekat iz ERWin-a izvozi u neki od RDBMS kao sto su Oracle, MSSQL, Access itd, gde se dobijaju gotove tablice koje je potrebno eventualno doraditi. U konkretnom RDBMS se onda izvodi treca faza Aplikativno modeliranje (upiti, forme, izvestaji) i na kraju sledi Implementacija.
Evo okacicu par slika da vidite kako to izgleda ali mislim da je mnogo bolje da preuzmete projekat i da ga otvorite u BPWin-u nego da pregledate slike. Kao sto sam i prikazao na jednoj od slika svaka strelica na kontekstnom dijagramu nosi neke podatke (na primer zahtev za izdavanje knjige menja podatke u entitetu IzdavanjeKnjige kao sto je prikazano na slici biblioteka4) tako da ne mogu da vam okacim slike za svaku strelicu pojedinacno.
Kao sto rekoh svako moze da preuzme projekat i da ga edituje ili koristi na bilo koji drugi nacin (kao open source:)).
Napomena: Nisam uspeo da uploadujem instalacije na sajt ali probacu na rapidshare pa ako uspem javicu.
Da cujem predloge, kritike, sugestije. Samo izvolite!

<sub>[Ovu poruku je menjao biske86 dana 26.07.2008. u 18:01 GMT+1]

[Ovu poruku je menjao biske86 dana 26.07.2008. u 18:02 GMT+1]

[Ovu poruku je menjao biske86 dana 26.07.2008. u 18:03 GMT+1]</sub>

---

Exportovanje iz ErWin-a u DBMS ili bolje rečeno generisanje šeme baze podataka iz informacionog modela urađenog u ErWin-u u neki od raspoloživih Desktop DBMS ili SQL DBMS je moguće. Ono prvo pomenuto exportovanje iz BpWin-a u ErWin ti nće dati zadovoljavajuće rezultate. Ne postoji dovoljno pametan softver koji će na osnovu pravilno urađenog funkcionalnog modela da predloži ErWinu entitete i atribute.

O tome možeš da pročitaš nešto ovde: http://www.elitesecurity.org/t302411-0#1801586

---

Nisam ni rekao da će BPWin predložiti ERWinu kandidate za entitete, atribute. To je stvar koja treba da se odradi naknadno u ERWin-u. Svaki od ovih alata ima svoju svrhu i to je nesporno. Pročitao sam tvoje odgovore u drugim temama ali da pojasnim ostalima o problemu. Ne treba da diskutujemo o tome da li ima svrhe raditi u BPWinu zato što je to potvrđeno kao dobro. Kao što sam naveo radim po knjizi Alempija Veljovića koju možete skinuti sa interneta besplatno. Tamo možete videti zasto ima smisla raditi modelovanje IDEF0 tehnikom tj. u mom slučaju u BPWin CASE alatu. Navešću ipak koje su prednosti, citiram profesora Alempija:

''Razlozi koji su motivisali nastanak IDEF0 funkcionalnog modeliranja su:

Prvo, služi kao dokumentacija i uputstvo za opis kompleksnih poslovnih procesa. Poznata je činjenica da što je dokumentacija veća - to se manje čita. Tačnije, dokument od jedne ili dve strane sa grafičkim prikazom biće najverovatnije pregledan. Dokument od 30 strana ima sve izglede da mesecima ne bude pročitan.
Drugo, omogućava brze organizacione promene, jer model procesa dokumentuje važne aktivnosti i omogućava uvid u kritične aktivnosti koje treba izvesti sa odgovarajućim resursima, što je bitan u održavanju reinžinjeringom definisanog poslovnog procesa.
Treće, sto je i najvažnije, koristi se kao prototipski pristup funkcionalnom modeliranju gde se na brz i jednostavan način proveravaju alternativne ideje. Mnogo je jednostavnije i jeftinije nacrtati model i proveriti ga na ''papiru'', nego izvršiti reorganizaciju sektora. To je veoma bitna osobina, jer brži razvoj informacionih tehnologija uslovljava potrebu za reinžinjeringom poslovnih procesa.''

Valjda je i onim manje upućenima sada jasno šta mogu da očekuju od funkcionalnog modeliranja odnosno od BPWina.

---

Kao što rekoh izvolite pa predložite nešto, neku kritiku, pohvalu, ukoliko ima nekih nejasnoća pitajte..

---

Predlog:

Pored graničnih streloca trebalo bi uvesti i interne ili eksplicitne strelice koje povezuju aktivnosti između sebe. Ako njih nema, dekompozicioni dijagram ukazuje isključivo na organizacioni pristup samoj dekompoziciji, odnosno na hijerarhiju, a ne funkcionalni pristup, što bi ovde trebalo da bude prioritet.
Predpostavljam da postoje informacije koje izlaze iz pojedinih aktivnosti i koje se mogu tretirati kao ulazi u druge (susedne ili nesusedne) aktivnosti. Njih takođe treba imenovati kao što su lepo imenovane i granične strelice. Glavna aktivnost bi trebalo da se zove recimo Poslovanje biblioteke (glagol + imenica) , a ne samo Biblioteka (imenica). Model može, a ne mora da poprimi taj složeni naziv.
Svaka od aktivnosti ima mogućnost da joj se popuni definicija i napomena u Activity Properties, što može da bude od važnosti za autora kad naknadno (nakon proteklog vremena) čita model ili za nekog novog člana koji se priključuje timu. U principu ovo i jeste grafičko-tekstualna dokumentacija.


Neke tehničke primedbe:

1. U meniju: Model; Model Properties; na kartici Numbering u delu Numbering Convention čekirati „Use Numbering Dijagram Format“, a u delu Diagram čekirati opciju „use dots“. Time se postiže označavanje hijerarhije i nasleđivanja (desni donji ugao).

2. Na kartici Display, dečekirati opciju ABC data ukoliko se ne želi prikazivati cena koštanja, frekvencija ili trajanje pojedinih aktivnosti u modelu (levi donji ugao), odnosno ukoliko to nije od značaja za model.

3. Naslove aktivnosti i strelica učiniti vidljivijim.

4. Ja bih nazive izlaznih strelica suzio (po ugledu na kontrole u diagramu A5) i koristio mogućnost „Squiggle“ (munja, škrabotin).

5. Ulazne strelice su lepo grupisane prema temi zahteva. Doslednosti radi možda bi se moglo to uraditi i sa izlazima.

Sve u svemu, lepo odabran i započet poslovni projekat. Biće interesantno videti informacioni model u ErWin-u.

---

Prvo zahvaljujem što si uopšte dao predloge za poboljšanje ovovg informacionog sistema. Predloge ću detaljno izanalizirati najkasnije do sutra pošto moram i da prepravim još neke stvari u modelu a i da uradim matricu odnosa.

Hvala. Kad završim projekat u BPWinu izvešću ga u ERWin a tu i počinje najzanimljiviji deo a to je odabir kandidata za entitete, odabir primarnih, stranih, alternativnih ključeva, definisanje referencijalnog integriteta, kardinalnosti veza itd.
Kao što rekoh idem da doradim model pa se javljam za dan dva a ako neko ima još neki predlog neka izvoli bilo koja zamerka iliti ideja će detaljno bi uzeta u obzir na razmatranje. Pozz

---

Što se povezivanja aktivnosti tiče evo na ovom modelu su prikazane i to sam vec bio uradio
pre nego što si ti stavio post iznad ali nisam okačio fajl biblioteka koji sam izmenio.
U potpunosti se slažem da je ovo grafičko tekstualna dokumentacija pored ostalih funkcija
koje moze da zadovolji. Što se tiče definicije entiteta i atributa, možete videti da sam ih
već uneo odlaskom na Model pa Entity/Attribute Editor. U prozoru koji se pojavi izabrati
željeni entitet i klknuti na Definition of selected Entity i bice prikazan kratak opis entiteta
a isto to možemo uciniti sa atributima (definicije nisam uradio za svaki entitet). Ovo je posebno dobar nacin upoznavanja kao
što Getsbi reče novog radnika na projektu sa dosadašnjim radom, kao i svih na forumu koji žele da se upoznaju
sa projektom i da eventualno postuju svoja zapažanja, a za mene to ce kasnije biti izvor dokumentacije.


Evo odgovora na sugestije Getsbija:
1. Ovo je korisna stvar ne znam zašto nije podrazumevana opcija u BPWinu.
2. Ovo je takodje korisno
3. Pretpostavljam da mislis na strelice koje su kontrole kod aktivnosti upravljanje izveštajima
ali situacija mi ne dozvoljava da ih bolje organizujem a i ovako nije bas da nisu vidljive. Squigle
je dobra stvar to cu iskoristiti.
4. Ovo nisam prihvatio pošto je osnovna zamisao da nazivi strelica budu vidljivi za citanje
a ukoliko bi ih stavio po ugledu na kontrole onda bi morao da povecam rastojanje izmedu
strelica a mislim da bi to bilo nepregledno (ne da mislim nego znam pošto sam probao), bar po mom ukusu.
5. U pocetku sam mislio da sve izlazne strelice oznacim crnom bojom (i crno je boja zar ne:)) ali
sam prihvatio tvoj predlog i obojio sam ih u odgovarajuce boje prema ulazima.

Odmakao sam dosta u projektu ali sam stao kod aktivnosti 2.1.3 definisanje detaljnje matrice odnosa (napominjem radim po knjizi Alempija Veljovića Razvoj informacionih sistema). Naime jedna stvar me zbunjuje a to je šta predstavlja entitet u kontekstu definisanja matrice odnosa (ne mislim na definiciju entiteta da može da predstavlja neku osobu, događaj, proces, itd). Ja sam mislio da je entitet u stvari tabela u bazi ali kad sam stigao do definisanja matrica odnosa na 47 stranici gore pomenute knjige je prikazano da aktivnost ODRŽAVANJE PODATAKA O PREVODIOCIMA ima CRUD nad entitetom OSOBA. Na osnovu ovoga sam zaključio da je entitet u stvari jedan red u tabeli. Ja sam u svojim entitetima kao što možete da vidite na modelu koji sam uploadovao u takvim situacijama stavljao u CRUD matrici samo U (Update). Očigledno da je to izraz mog nepoznavanja pojma entitet pa bih molio da mi ukažete na ispravno rešenje..Molim što pre za odgovor da bih mogao da nastavim dalje..

---

"....Ja sam mislio da je entitet u stvari tabela u bazi ali kad sam stigao do definisanja matrica odnosa na 47 stranici gore pomenute knjige je prikazano da aktivnost ODRŽAVANJE PODATAKA O PREVODIOCIMA ima CRUD nad entitetom OSOBA. Na osnovu ovoga sam zaključio da je entitet u stvari jedan red u tabeli... "

Dobro si mislio u početku. Ono što je entitet na logičkom (konceptualnom) nivou, to je tabela na fizičkom nivou. Reodvi u tabeli su instance ili pojedinačni primerci entiteta sa logičkog nivoa.

Moglo bi ovako:

Logičko projektovanja baze podataka - Skup postupaka kojima se dolazi do dobro struktuiranih podataka u bazi podataka. Entiteti, atributi, torke i veze.

Fizičko projektovanje baze podataka - Skup postupaka kojima se podaci fizičcki organizuju u bazi, tako da im je pristup i održavanje najefikasnije. Tabele, kolone, vrste i relacije.

Mada ne bih da se upuštam u diskusiju o dvojakoj upotrebi naziva relacije.

P.S. Pogledaću prikačeni fajl kasnije. Možda ima još onih koji prate ovu temu, pa će to uraditi pre mene.

---

Molim te kad budeš imao vremena pogledaj taj primer na stranici 47 ukoliko imaš knjigu (ako ne ima je na netu besplatno) i pogledaj kako sam ja uradio matricu odnosa na nivou entiteta (ne atributa) u fajlu koji sam prikačio i ako misliš da nisam dobro uradio matricu odnosa ukazi mi samo na jednom entitetu zašto misliš da ne valja i kako bi trebalo da uradim a ja ću na osnovu toga da zaključim kako ću dalje.. Hvala na odgovoru.

---

Nema fajla bible.bpx.

---

Oprostite pogrešni fajl sam prikačio. Trebalo je Biblioteka.rar a ja sam slučajno izabrao bible.bpx što je u stvari fajl koji sadrži data dictonary za izvoz u ERwin. Evo pravog fajla i probaj da mi odgovoriš na pitanja ukoliko ti nije frka. Usput za one koji nemaju BPwin i ERwin sutra preko dana će biti uploadovane instalacije na rapidshare pa kad to bude gotovo javljam. Pozdrav

Tek sad sam video u čemu je greška. Ja sam mislio da sam uploadovao pogrešan fajl ali nisam, fajl je dobar. Ne obraćaj pažnju na to jer je to greška koja je nastala zato što sam izbrisao taj fajl bible.bpx koji sam izvezao iz BPwina. Slobodno ignoriši poruku..

_{[Ovu poruku je menjao biske86 dana 19.08.2008. u 01:04 GMT+1]}

---

Sa stanovišta površnog poznavaoca bibliotekarskih poslova, meni CRUD matrica izgleda O.K. Ono što ja primećujem, a do čega ćeš verovatno doći tokom informacionog modeliranja u ErWin-u je nesvrsishodnost nekih entiteta. U pitanjuje je iskustvo koga verovatno ne poseduješ, pa mi stoga entiteti : „MaksimalanBrojUzetihKnjiga“, „BrojUzetihKnjiga“ , „Periodi“ i „Primerak“ bodu oči.

Prvi pojam predstavlja ograničenje i zadaje se kao atribut nekog entiteta koji definiše proces izdavanja knjiga. Recimo u entitetu „IzdavanjeKnjiga“ koji već imaš. Kao atribut se uvodi ako je promenljiv od čitaoca do čitaoca, zbog dudgogodišnje saradnje ili zasluga stečenih urednim vraćanjem knjiga bez kašnjenja i oštećenja. Ukoliko nije promenljiv onda se na nivou aplikacije postavlja zabrana izdavanja preko određenog broja.

Drugi pojam predstavlja podatak koje se smatra izračunatim.Uvek može da se prebroji, bez obzira da li su to trenutno iznajmljene knjige ili ukupan broj knjiga koje je taj čitalac pročitao.

Treći možda nije samo najsretnije imenovan. Predpostavljam da bi mu Evidencija članarine bolje pristajala ukoliko bi dodao i šifru čitaoca. Međutim koliko vidim ti već imaš entitet Clanarina. Bez obzira što tvrdiš da su članarine različite u različitim periodima možda je VrstaClanarine bolje rešenje. Članarina za decu, odrasle i penzionere ne mora da bude ista. To što se iznos članarine menja iz godine u godinu ili nakon par godina nije dovoljan razlog za držanje posebnog entiteta. Sve se to može realizovati u trenutno postojećem entitetu „Clanarina“

Četvrti bi po svemu sudeći bio instanca entiteta Knjiga. U tom slučaju bi nazivi Naslov i Primerak bili adekvatni. No pošto nisam dovoljno ušao u suštinu, nije pametno ni da komentarišem.

Savet: Nazive entiteta piši ili u jednini (radije) ili u množini. Niako mešano.

Rečnik podataka je jedina svetla tačka u povezivanju alata BpWin i ErWin. Moraćeš često da se vraćaš u BpWin i prepravljaš ga sve dok u ErWin-u budeš radio ispravke. Mnogi ne koriste ovu vezu, što ne znači i da nije korisna. Pogotovo kada ti iskustvo poraste a lenjost ne preovlada, što kod mene i nije slučaj.

---

Samo da odgovorim na brzinu što se tiče maksimalnog broja uzetih knjiga. Znam da u aplikaciji mogu da stavim na primer da ne mogu da se izdaju knjige ukoliko je na primer broj izdatih knjiga >3 ali sam se odlučio da ne uradim tako već da ostavim biblioteci odluku kolika je granica za broj uzetih knjiga. Da li je moguće u aplikaciji dodeliti nekoj promenljivoj ovaku vrednost da ne radim to u tabeli?

Za ostale primedbe ću dati detaljan odgovor u toku dana (što pre mogu), čim ih detaljno izanaliziram. Pozz

---

Ako si odlučio da ostaviš biblioteci, da za svakog čitaoca odluči o maksimalnom broju trenutno izdatih knjiga onda je atribut "MaksimalanBrojUzetihKnjiga" u entitetu "Citaoc" pravo rešenje. Tako možeš po defaultu za to polje (jer kasnije će to biti polje na formi za unos i ažuriranje ćitalaca) postaviti broj 3, a bibliotekar ga može smanjiti ili povećati. Prilikom pokušaja izdavanja 4. knige, aplikacija uradi upit nad tabelom „IzdavanjeKnjiga“, i ako pronađe tri ne vraćene knjige, te potom konsultuje polje "MaksimalanBrojUzetihKnjiga" u sada već tabeli "Citaoc" , priajavi grešku. No dotle ima još vremena. Važno je predvideti mogućnost i u startu se odreći onog što nije entitet i to ne mora da bude, odnosno da postoji bolje rešenje.

---

Ne slažem se sa tobom oko ovoga jer ne želim da za svakog čitaoca radim posebno već na nivou biblioteke da stavim ograničenje. Ukoliko je tako onda bi upisivanje u tabeli svakog čitaoca bila velika redundansa. Što se tiče entiteta broj uzetih knjiga slažem se da ne treba da postoji jer uvek mogu za određenog čitaoca da pretražim po atributu datum vraćanja i u kombinaciji sa funkcijom count izbrojim koliko knjiga ima za tog čitioca koje nije vratio. To je moguće zato što prilikom zahteva za uzimanjem knjige se upisuju u entitetu IznajmljivanjeKnjige svi atributi sem DatumVracanja. Ovo se popunjava kad se aktivira Zahtev za vracanje knjige (sve ovo se lepo vidi na matrici odnosa). Zahvaljujući ovome mogu prebrojati knjige i mislim da je ovo super rešenje.
Kao što rekoh javljam se malo kasnije sa odgovorima na ostale sugestije.

---

Ako je ograničenje na nivou biblioteke i ako "MaksimalanBrojUzetihKnjiga" važi za sve čitaoce bez izuzetka onda uredu.

Inače redundanca kao pojam je suvišnost, suvišna informacija, prekomernost odnosno ponavljanje istih podataka. U slučaju kada se čitaoci kategorišu jednim atributom na one koji maksimalno mogu da iznajme, recimo (deca 1; odrasli 2; dugogodišnji aktivni čitaoci 3) knjige, onda se to ne može smatrati redundancom jer je to od interesa za poslovni proces. Kao što se ne smatra redundancom ni uvođenje atributa "pol", kojim će otprilike polovina populacije čitalaca imati oznaku M, a druga polovina oznaku Ž.

Redundanca bi bila kada bi u istoj tabeli držao i podatke o čitaocima (ime prezime, adresa) i podatke o višekratnim plaćenim iznosima članarine, jer bi se tada nepotrebno ponavljali podaci o čitaocima. Time bi se kršila i prva normalna forma koja zahteva da jedna činjenica bude na jednom mestu.

---

Prvo bih ponovio Getsbijevu primedbu na imenovanje entiteta. U imenovanju treba biti jednoobrazan, odnosno treba koristiti ili jedninu ili množinu!

Ja predlažem da se za imenovanje entiteta koristi množina jer se tako naglašava da se radi o skupu istovrsnih elemenata, a da tih elemenata može biti više. Naravno postoje i odstupanja od ovog pravila pa je za imenovanje nekih entiteta potrebno upotrebiti jedninu. Primer ovog odstupanja je recimo entitet kojim se modelira Bog. Jasno je da je Bog samo jedan i da se tu neradi o nikakvom skupu uzvišenih bića već o jednom jedinom uzvišenom biću. Tada se za takav entiet uoptrebljava jednina pa bi se entitet zvao 'Bog' i tom jedninom bi bilo naglašeno da je to jednočlani entitet. Naravno, ovde sam mislio na Boga sa velikim B, dok bi se panteon Grčkih, Rimskih, itd bogova modelirao na drugi način.


Dalje bih se osvrnuo na definicije koje prate entitete. Definicija služi da se jasno iskaže šta se modelira konkretnim entitetom. Definicija mora biti jasna, precizna i nesme se pozivati sama na sebe.

Evo i konkretnih primedbi vezanih za imenovanje i definianje entiteta:

1. Neki entiteti nemaju definiciju - Trebalo bi dati definicije za SVE entitete. Ako entitet nemože da se definiše, vrlo je verovatno da se uopšte i neradi o entitetu!
Na priimer:
- Entitet 'Autor' nema definiciju, a trebao bi da je ima.
- Entitet 'BrojUzetihKnjiga' takođe nema definiciju. (Za trenutak zanemarimo da je već rečeno i usaglašeno da ovo nije entitet) Šta je to 'BrojUzetihKnjiga'? Kako ovo definisati? Da probam - Broj uzetih knjiga je ukupan broj knjiga koje je član pozajmio iz biblioteke. Da li ovo zvuči dobro? Ne! U samoj definiciji sam opet upotrebio sve reči 'broj', 'knjiga', 'uzeto'. Faktički sam pojam definisao sa samim njim! To jednostavno nesme da se dogodi u definiciji! Nemogućnost davanja dobre definicije takođe jasno ukazuje da se ovde uopšte neradi o entitetu.

2. Neke definicije su loše.
Primer:
- Entitet 'Citaoc'. Njegova definicija glasi - 'Ovo je sifarnik svih citaoca.'
Da li bi bilo koji bibliotekar na zemaljskoj kugli na pominjanje termina "čitaoc" rekao: "Čitaoc je šifarnik svih čitaoca."?!
Naravno da nebi! To je pokazatelj da je definicija loša. Da podsetim - Definicija mora biti jasna! Definicija mora biti jasna kako projektantu tako i ekspertu iz oblasti koja se projektuje, pa čak i laiku sa strane. Sa rečenicom "Čitaoc je šifarnik svih čitaoca" bismo ubili u pojam kako bibliotekara tako i sve čitaoce. Evo, ja čitam knjige, dakle ja sam čitaoc. ali ja za sebe nikada nebih rekao da sam šifarnik svih čitaoca!
Definicija za entitet 'Citaoc' bi trebala da glasi ovako nekako: "Čitaoc je osoba koja čita knjige." Ovo me dovodi do treće primedbe.

3. Imena nekih entiteta nisu primerena (ovde zanemarujem mešanje jednine i množine)
Primer: Upravo gore spominjani entitet 'Citaoc' je dobar primer jer je proces njegovog definisanja doveo do toga da se zaključi da taj enitet uopšte nema dobro ime! Kako?
Čitaoc je osoba koja čita knjige. Čitaoc je bilo koja osoba na zemaljskoj kugli koja čita knjige. Da li je naša biblioteka zainteresovana da vodi evidenciju o svim čitaocima na planeti zemlji? Naravno da nije. Biblioteka je zainteresovana da vodi evidenciju o njenim ČLANOVIMA. Dakle, entitet 'Citaoc' bi u stvari trebao da se zove 'Clanovi' s definicijom: Član je osoba koja pozajmljuje knjige iz biblioteke.

Znači nedostatak definicije ili loša definicija entiteta govore da sa tim entitetom nešto nije u redu!
Sve ovo što je naveo Getsbi se uklapa u gornju rečenicu o nedostatku definicije ili o lošoj definiciji. Iskustvo pomaže da se ovakve stvari uoče i bez eksplicitnog navođenja definicije (ali se te definicije podsvesno vrzmaju po glavi).

Trebalo bi proći kroz listu postojećih eniteta i dodeliti im dobre definicije. Nakon ovoga će i ceo domen koji se modelira biti mnogo jasniji nama koji to pratimo (laici sa strane), a na taj način će se možda izvršiti izbacivanje nekih entiteta, pa čak i ubacivanje novih.

Još jedna primedba za kraj:
Pojam 'MaksimalnaBrojUzetihKnjiga' jednostavno nema dobru definiciju da bi bio proglašen za entitet! To jednostavno nije entitet već data element, odnosno atribut. Postavlja se pitanje - kom entitetu treba dodeliti ovaj atribut?
Na čega nas asociraju reči 'maksimalan broj uzetih knjiga'? Asociraju na ograničenje koje je propisala biblioteka. Biblioteka! To je pravi entitet da udomimo naš atribut 'MaksimalnaBrojUzetihKnjiga'.

I došli smo do primera jednočlanog entiteta u našem informacionom sistemu, a to entitet 'Biblioteka'. I ovde mi jednina u imenu entiteta naglašava da se radi o jednoj jedinoj biblioteci koju obuhvata naš IS (Setite se Boga s početka teksta)! Naravno, ovaj naš entitet ima još atributa poput nametljivih prirodnih atributa:
- ime biblioteke,
- adresa,
- broj telefona.

Kasnijim proširenjem pravila poslovanja biblioteke, ovom entitetu bi se verovatno pridodao i recimo atribut 'MaksimalanBrojDana', i ko još zna šta sve.

Sa tehnikom "na koji entitet me asocira ovaj atribut?" sam se prvi put susreo u knjizi od Michael J. Hernandez "Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design".


_{[Ovu poruku je menjao chachka dana 20.08.2008. u 00:55 GMT+1]}

---

Da su u pitanju samo imenice kao nazivi entiteta mogao bih da se složim sa kolegom Chachk-om. Ali pošto su u pitanju pored objekata, stvari i lica (koja se mogu označiti samo imenicom), još i pojave i događaji, to po meni malo menja situaciju oko množine. Za nazive entiteta često se koriste i glagoli uz imenicu da definišu neku aktivnost ili događaj.

Primeri: EvidentiranjeProtokaGasa, PrometMaterjala..... ili pojmovi DnevniRaspored, StanjeVozila.

Obratite pažnju da imenice u nazivima ne predstavljaju množinu već odgovaraju na pitanje koga? čega? ili koga? šta? Množine bi bile malo neprimerene. Ili možda nebi? Možda u drugim jezicima to nije slučaj. Pošto ja nisam stručnjak za jezike ovde ću iz pristojnosti da stanem.

Ako ovo gore zanemarim, u prilog jednini bih naveo, da to jeste skup ali da se ovde radi o pojedinačnim primercima entiteta i da se uvek posmatra jedan primerak. Čini mi se da sam čak nailazio u literaturi na uputstva, da se entiteti pišu u jednini, a kasnije kada se pređe na fizički nivo, tabele imenuju u množini. Ja se s tim ne slažem i ostavljam nazive na fizičkom nivou onakvim kakvi su bili na logičkom. Razlog je što sve više koristim opcije u alatima za generisanje šeme baze podataka, tako da bi to predtavljalo dodatni napor koji i ovako nema previše smisla.

No, bilo kako bilo, ovo i ne treba da bude krucijalno pitanje. Važno je biti dosledan u konvenciji. U ostalom delu se u potpunosti slažem sa kolegom Chachk-om, koji je detaljnije analizirao situaciju.

---