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.

Unosio sam izmene koje ste mi preporučili a to za sobom povlači izmenu matrice odnosa i još nekih drugih stvari kao što su stelice i nove aktivnosti i kad dovršim (najverovatnije sutra) javljam se sa komentarima i naravno kompletnim rešenjem u BPwinu i onda prelazim na ERwin. Pozdrav

Evo kompletnog modela urađenog u BPwinu sa svim izmenama koje sam uneo. U prilogu se nalazi i zip fajl koji sadrzi bpwin fajl fajl koji sam ekspotrovao iz bpwina (ima ekstenziju .bp) i erwin fajl u kome se nalaze entiteti onakvi kakve sam ih uveo iz fajla sa ekstenzijom .bpx. Ukoliko neko ne zna kako se radi ovo izvoženje evo postupka pa probajte sami ukoliko vas interesuje (da se neko ne uvredi, napominjem za one koji ne znaju). Evo postupka:
Najpre u bpwinu je potrebno iz menija File izabrati Export i onda ERWin i zadamo ime fajla (u mom slučaju je Biblioteka.bpx). Zatim otvorimo erwin i na prozoru koji se pojavi kliknemo na open model zatim izaberemo Physical/Logical i otvoriće se novi projekat. Onda iz menija File izaberemo Import pa onda BPwin i pojaviće se novi prozor u kome biramo koje entitete i aktivnosti želimo da importujemo i ako želimo sve entitete i aktivnosti onda potvrdimo unos na ok i to je to.

U ERwin fajlu sam napravio veze među entitetima i podao sam različite poglede na model (fizicki, logicki, kljucevi i entiteti) pa pogledajte.

U ErWin-u, kod veze između entiteta „Clanarina“ i „UplacenaClanarina“ kao i veze između „Citaoc“ i „UplacenaClanarina“, dobro je uočeno da su obe jedan prema više i da je „UplacenaClanarina“ asocijativni entitet. Jasno je da jedan „Citalac“ može da uplati više „Clanarina“ (članarine za više perioda) i da za određeni članski period „Clanarine“ može da uplati više „Citalaca“.

1. Međutim po meni bi trebalo obe veze postaviti kao identifikujuće. Razlog: „UplacenaClanarina“ je evidencija koja i identifikaciono i egzistencijalno zavisi od „Citaoca“ i „Clanarine“. Niti može da egzistira bez oba činioca, niti može da se identifikuje bez oba činioca. Cilj evidencije je informacija u atributu „DatumUplate“. Slično kao u neodređujućoj vezi : „Autor“ -> „Napisao“ <- „Knjiga“, bez obzira što ovaj drugi vezni entitet („Napisao“) nema sopstvene atribute.

Mislim da ErWin po defaultu nudi identifikujuću vezu kada je u pitanju nasleđivanje ključeva. Iako su jake veza za nijansu teže pri ralizaciji, one se uvek, kasnije, u toku rada mogu olabaviti. Mnogo je teže učvrstiti slabiju vezu kada pri realizaciji već imete testne podatke u tabelama, jer podaci mogu da budu nekonzistetntni za tu priliku. Ovde je čak greškom postavljeno i Nulls Allowed (neobavezna neidentifikujuća veza) što nikako ne bi smelo.


2. Atribut „SifraClanarine“ u entitetu „UplacenaClanarina“ nema mnogo smisla, jer i ne postoji adekvatan šifarnik. Ili bi prvo njime trebalo dopuniti entitet „Clanarina“.

3. Atribut „SifraRadnika“ u entitetu „Ostecenje“ trebalo bi povezati sa entitetom „Radnik“, odnosno spustiti ključ od ovog drugog ka prvom.

4. Atribut „SifraZanimanja“ u entitetu „Knjiga“ mi je nelogičan.

Ostalo mi se čini u redu.

Da li bi neko mogao da okači sliku ER dijagrama?

Evo slike.

Promenio sam veze o kojima je Getsbi pricao i uneo sam dosta novina u model (neke atribute sam brisao neke dodavao) a evo stvari kojih se sećam da sam promenio.
Atribut SifraZanimanja je greškom dospeo u entitetu Knjiga a u stvari treba da bude u entitetu Citalac.
Zabrana je polje tipa Yes/No i ono se postavlja na Yes ukoliko je broj knjiga koje je čitaoc iznajmio veći od maksimalnog broja knjiga koje definiše biblioteka. Postavio sam definiciju ovog atributa u modelu. Postoje još neke definicije za neke entitete ali ne za sve ali probaću i to malo bolje da dokumentujem.
Atribut DatumUnosa u entitetu Knjiga sam izbrisao zato što u entitetu Primerak imam već DatumNabavke, a atribute Pozicija i NacinNabavke sam premestio iz entiteta Knjiga u entitet Primerak.
Izbacio sam atribut Plata iz entiteta Radnik.
Iako se u praksi ne dešava moguće je teorijski da jedan čitalac uzme jedan primerak knjige da je istog dana vrati i da se onda predomisli i hoće ponovo da je iznajmi. Onda mi primarni ključ koji je sastavljen od atributa SifraPrimerka, RedniBrojCitaoca i DatumIzdavanja bio loš. Zato mi je primarni ključ u entitetu IzdavanjeKnjige SifraIzdavanja.
U entitetu ISBNBroj sam dodao atribut RedniBrojISBN koji je AutoNumber da bih mogao da imam više ISBN brojeva.
Atribut SifraClanarine iz entiteta Clanarina sam izbrisao jer nema potrebe tu da stoji.
Promenio sam vezu između entiteta Clanarina i PeriodClanarine iz neidentifikujuće u identifikujuću jer primarni ključ iz PeriodClanarine učestvuje u primarnom ključu Clanarine.
Raskinuo sam vezu između entiteta Ostecenje i Primerak, a napravio novu vezu između entiteta Ostecenje i IzdavanjeKnjige.
Ne obraćajte pažnju na ograničenja jer je to poslednji deo koji treba da odradim pošto radim po redosledu koji je propisan u knjizi Razvoj informacionih sistema od Alempija. Za one koji imaju ovu knjigu trenutno radim aktivnost 2.3. Kreiranje atributa koja se sastoji od podaktivnosti Definisanje liste kandidata za entitete, Definisanje ključeva, Postupak normalizacije i Definisanje atributa. Mnogo su mi bitni druga i treća podaktivnost tako da očekujem još komentara u tom kontekstu. Getsbi je dao neke konkretne predloge koji su dobri.

Sve ove izmene moram da vratim nazad u BPwin ali nisam još to uradio. To ću uraditi kad dobijem konačan spisak atributa u ERwinu jer svaka promena na atributima povlači za sobom editovanje matrice odnosa.

Upravo ovo o čemu je pisao Getsbi.
Uzgred čitavu matricu odnosa ću morati da menjam na šta me je upozorio profesor jer sam potpuno obrnuto popunjavao matricu odnosa za ulazne i izlazne aktivnosti ali o tome nešto kasnije.

U attachmentu se nalazi projekat kao i slika modela za one koji nemaju ERwin program.

Evo novih primedbi od mene:

1, Nesviđa mi se ime 'ISBNBroj'. U skracenici ISBN ono N je skraćenica od engleske reči 'Number' odnosno u prevodu 'Broj'. Kada bi se skracenica ISBN prevela na srpski i "produžila" onda bi se onaj izraz 'ISBNBroj' zvao "internacionalni standardni broj knjige broj"! Dva puta se u terminu 'ISBNBroj' pojavljuje reč "broj", što je besmisleno. Taj termin je sasvim dovoljno označavati samo sa 'ISBN' što nas dovodi do sledeće primedbe

2. 'ISBNBroj' (odnosno preciznije samo 'ISBN') uopšte nije entitet! To je atribut entiteta 'Primerak'. Modeliranjem na ovaj način, gubi se potreba za naknadno uvedenim 'RedniBrojISBN'. Ovim 'RedniBrojISBN' je (neuspešno) pokušano rešenje problema, koji se nebi ni pojavio da je u startu 'ISBN' ispravno modeliran kao atribut!
Ovde ću dati još tumačenje tog nesretnog 'RedniBrojISBN' - Produženo i prevedeno to znači "redni broj internacionalnog standardnog broja knjige", odnosno ako izvučem suštinu dobijam "redni broj broja"! Tavko nešto jednostavno nepostoji! Postoji "broj" i postoji "redni broj" ali ne postoje "redni broj broja". Uporno insistiram na ispravnoj semantičkoj (značenje pojmova) analizi problema jer ona pomaže da se izbegnu mnogi problemi u modelu.

3. Nismo dobili kompletne i tačne definicije za 'Knjiga' i 'Primerak' pa je teško da se ispravno sagleda problem, ali mi se čini da 'BrojStrana', 'Dimenzija', 'VrstaPoveza', 'GodinaIzdavanja' uopšte nisu atributi knjige već su to atributi primerka! Knjiga "Gospodar Prstenova" je štampana u više izdanja sa više vrsta poveza, u raznim dimenzijama i s raznim ukupnim brojevima strana, ali je u suštini to ista knjiga! Opet napominjem, bez precizne definicije pojmova je ovo veoma teško modelirati.

4. Izdavač ne izdaje knjigu nego primerak knjige, tako da bi relacija 'Publikuje' trebala da povezuje entitete 'Izdavac' i 'Primerak'. (Ovde opet problem predstavlja nepostojanje definicija za entitete 'Knjiga' i 'Primerak'. Posle izmena iz 3 i 4 zaista mi se postavlja pitanje 'Šta je to knjiga?'. Posle svega - čini mi se da knjigu određuju autor(i), naslov i sadržaj, dok je forma same knjige ustvari ono što određuje konkretan primerak.)

5. Atributi 'StatusOstecenja' i 'StatusIzdavanja' entiteta 'Primerak' su izvedeni (izračunljivi) atributi te im stoga nije mesto u modelu podataka! On se uvek (i što je bitnije ispravno) mogu izračunati iz podataka smeštenih u 'IzdavanjeKnjige' i 'Ostecenje'. Mada... verovatno bi onda negde trebalo zabeležiti i da je knjiga reparirana.

6. Atribut 'Pozicija' ne pripada entitetu 'Primerak'. Pozicija primerka knjige na polici nikako ne određuje taj primerak. Promenom pozicije na polici primerak ostaje nepromenjen! Atribut 'Pozicija' verovatno pripada relaciji 'se čuva u' koja bi spajala entitete 'Primerak' i (zasada nepostojeći enitet) 'SkladisniProstor' (ili nesto slicno poput 'Polica'). Tačan naziv ovog novog eniteta bi trebalo utvrditi sa domen ekspertom koji je u ovom slučaju bibliotekar.

7. Ceo deo modela oko evidentiranja članarina mi nedeluje ispravno. Šta nije dobro? Ne mogu da kažem jer ne postoje dobre definicije za pojmove 'Clanarina' i 'PeriodClanarine'. "Definicije" ovih pojmova počinju sa "Ovo je entitet ..." (naravno da je entitet!) i "Ovo je sifarnik ..." a već sam ranije rekao da to nisu definicije. To eventualno može biti nekakva napomena osobe koja modelira sistem. Da su definicije ispravne tada ovakve napomene uopšte nebi ni trebale, tako da su te rečenice apsolutno nepotrebne!
Još jedan znak da sa ovim delom modela nešto nije u redu je sklapanje rečenica od imena entiteta i relacija koje ih povezuju, pa tako dobijamo:
- Članarina daje vrednost periodu članarine.
- Period članarine čita vrednost članarine.
Ove rečenice nemaju smisla (ili se to samo meni čini?), ali je rečenica 'Čitaoc plaća članarinu' daleko realnija i verovatno treba da nađe svoje mesto u modelu. Doduše... reč "plaća" je nesvršena radnja. Da li će čitaoc platiti članarinu i sledeće godine? To niko nemože da predvidi. Zbog toga je daleko primerenije da se koristi "je platio", pa bi rečenica glasila "Čitaoc je platio članarinu", a to je ujedno i činjenica koja je od bitnosti za poslovanje biblioteke. (Meni se i dalje više sviđa termin "Član biblioteke" ("Radovan III" :) ) od termina "Čitaoc". Ali... Šta ja znam, valjda je bibliotekar potvrdio da je termin "čitaoc" ispravan za korišćenje.)

8. Da se vratim malo i na IDEF0 model. Tu se pojavljuje kontrolni tok 'Broj uzetih knjiga'. Mislim da bi primerenije bilo da se taj tok zove 'Uputstvo o poslovanju', 'Pravilnik o poslovanju', ili nekako slično jer je to dokument kojim se propisuje maksimalan broj (jednovremeno) uzetih knjiga koje član biblioteke može da drži kod sebe. Ovim pravilnikom se verovatno propisuje i
- maksimalan broj dana koliko član može da zadrži knjigu kod sebe,
- broj dana koliko član može da neplati novu članarinu (odnosno da produži staru)
i ko zna šta se sve propisuje takvim pravilnikom.
Ako bi se zadržalo ime kontrolnog toka 'Broj uzetih knjiga' onda bi se za svako novo pravilo morao uvoditi nov kontrolni tok. Zamislimo da postoji 50 pravila o poslovanju biblioteke. Tada bi smo imali 50 kontrolnih tokova (što bi model učinilo nečitljivim i neupotrebljivim), dok se suštinski možda radi o jedno, dva ili maksimalno tri kontrolna toka (dokumenta) kojim se uređuje poslovanje biblioteke.

9. Dekompozicija osnovne aktivnosti 'Poslovanje biblioteke' je preterano kompleksna, jer je dekompozicija urađena na 7 podaktivnosti. Dekompoziciju aktivnosti bi trebalo raditi na maksimalno 4-5 podaktivnosti (Gde je u svojoj knjizi Prof. Veljović izvršio dekompoziciju na 6 ili 7 podaktivnosti?). Takvom metodologijom dekomponovanja, bi iole složeniji realni sistem bio dekomponovan na 20-30 podaktivnosti prvog nivoa!


@biske86. Za kraj jedno pitanje - Da li si pričao sa nekim bibliotekarom (ili još bolje bibliotekarkom ("Varljivo leto" :) ) o svom modelu biblioteke?


PS: @biske86: Reci ako te davim svojim komentarima, pa ću prestati.

Neke stvari su se izmenile od mog zadnjeg komentara, pošto ovu drugu verziju nisam gledao, a očigledno sam i u prvoj ponešto propustio da primetim.

Slažem se da se „StatusIzdavanja“ u entitetu „Primerak“ može izostaviti, a status pojedinog primerka dobiti:
1. odabirom „SifraKnjige“,
2. potom ekstrahovanjem svih „SifraPrimerka“ i na kraju
3. pretragom po entitetu „IzdavanjeKnjiga“, na način, da li za pojedini primerak ima zapis koji poseduje podatak o „DatumIzdavanja“, a nema podatak o „DatumVracanja“.

Realizacija je nešto teža, a pretraga nešto dugotrajnija. Ali ovde se radi o kršenju treće normalne forme što je dobro uočeno od kolege chachk-e. Za atribute „StatusOstecennja“ i „Pozicija“ je slična situacija.

Nisam gledao zadnji IDEF0 model, pa nisam ni uočio da je naknadno dodata još jedna aktivnost. Maksimalan broj aktivnosti na dijagramu je 6. Ako ima više, znači da nešto nije u redu sa modelom, odnosno treba uraditi generalizaciju (spajanje aktivnosti). Strelica takođe ne sme biti više od 6 po tipu na istom dijagramu (znači 24 bez internih). Moglo bi da se reorganizuje i prođe prvi nivo sa 4 do 5 aktivnosti. Ovde bi svakako moralo da se uradi uopštavanje pojmova i to naravno iziskuje dodatni rad na dijagramima. Kako o biblioteci znam samo sa aspekta čitaoca, moje primedbe i predlozi bi bile neukusni.

P.S. Ozbiljno razmisli o chachk-inom predlogu u vezi bibliotekarke

1. Izvršena je ispravka

2. ’ISBN’ jeste entitet i to zavistan od entiteta ’Knjiga’. Očigledno se nismo razumeli oko entiteta ’Primerak’ (sad sam dopisao definiciju). ’Primerak’ je u stvari samo kopija knjige i u tom entitetu se nalaze atibuti koji su bitni za jednu kopiju knjige, kao što su način nabavke, cena i drugi atributi. Dopisao sam definiciju i za ovaj entitet.
’RedniBrojISBN’ mi stoji jer je moguće da jedna knjiga ima dva ISNB-a i nisam imao ideju kako da dam ime ovom atributu. Možda nešto kao ’SifraISBN’ ali je i ISBN neka šifra pa mi je bilo bezveze. Kada kazem ’RedniBrojISBN’ mislim na redni broj ISBN u tabeli. kao što rekoh ovaj atribut mi omogućava unos više ISBN-ova za istu knjigu.

3. Dopisao sam definicije ovih entiteta. 'BrojStrana', 'Dimenzija', 'VrstaPoveza', 'GodinaIzdavanja' bi trebalo da ostanu tu gde su jer je logično ukoliko pogledaš definiciju entiteta ’Primerak’ koju sam dao pod 2. Ukoliko bi je stavio u primerku onda bi mi se ponavljala jedna vrednost broj strana onoliko puta koliko imam kopija date knjige a to bi bila ’’nepotrebna redudansa’’.

4. Ne slažem se sa mišljenjem da treba izbrisati entitet ’Knjiga’’ a nadam se i da je jasno zašto posle izlaganja pod 3.

5. Što se tiče atributa ’StatusOstecenja’ stvari stoje ovako: Ukoliko su strane samo malo izgužvane onda možemo ovaj primerak da izdajemo i dalje a ukoliko je iščupano dvadeset strana onda ova knjiga nije vise za izdavanje. Ovo polje se ne postavlja na osnovu informacija iz entiteta ’Ostecenje’ vec ga unosi bibliotekar. Ovo je takozvana ’’planirana redundansa’’. Što se tiče atributa ’StatusIzdavanja’ si u potpunosti u pravu i ne znam zašto sam ga stavio kad sam imao u glavi da do informacije o statusu izdavanja mogu doći ako pročitam da li je vrednost atributa ’DatumVracanja’ u entitetu ’IzdavanjeKnjige’ Null ili ne.

6. Sjajna stvar je ovo što si predložio. Ubacio sam ovaj entitet ali ću ga doraditi čim saznam način označavanja u biblioteci izvršim intervju nad bibliotekarom.

7. Prepravio sam definicije ali nisam siguran da li je dobro sada. Pošto nemam iskustva sa definicijama reci mi da li je sada dobro ili mi daj kompletnu definiciju recimo za ova dva entiteta kako bi ih ti definisao (nadam se da ti je jasna njihova svrha). Takodje mi je problem bio da imenujem relacije pa te molim i da mi ovde ukazes na neke generalne smernice sto se tiče njihovih imenovanja.

8. Prihvatam ovu primedbu.

9. Možda na onom primeru profesor Veljović nije imao potrebe da definiše više aktivnosti na prvom nivou modela Salim se naravno..Počeo sam sa pet aktivnosti ali sam kasnije dodao još dve ’Unos clanrine za odredjeni period’ i ’Unos osnovnih podataka o biblioteci’. Prva služi da unese vrednosti u entitet ’PeriodClanarine’ pa je zato nisam dodao u aktivnost ’Odrzavanje podataka o citaocu’ ali bih možda mogao da je dodam u aktivnost ’ Unos osnovnih podataka o biblioteci’. Posle bi broj aktivnosti pao na 6. Imate li neke predloge za dodato smanjenje aktivnosti. Možda da izmestim aktivnost ’Upravljanje iznajmljivanjem knjiga’ u aktivnost ’Odrzavanje podataka o knjigama’? Tada bi broj aktivnosti pao na 5 i to bi mislim bilo prihvatljivo.


Naravno da jesam. Isao sam da intervjuišem bibliotekarku dva puta i to ću uraditi još jednom da razjasnim još neke sitnice.

Naravno da ne. Pa ja bih voleo kad bi još ljudi osim tebe i Getsbija komentarisao ovaj rad pa nema veze ako mi to i ne pomogne. Ukoliko neko ima neka pitanja vezana za modelovanje tu smo da pomognemo.

Još jedna napomena: ne mogu da napišem trenutno definicije za sve entitete jer sam u frci sa vremenom. Naime 2. septembra imam ispit iz informacionih sistema 1 i do tad treba da predam BPwin i ERwin fajl kao i Access fajl sa definisanim tablicama i atributima u njima. Kad položim ispit idem dalje sa radom u Accessu i tu treba da definišem upite, forme, izveštaje, napravim eventualno makroe ili modue i da pripremim dokumentaciju i objašnjenja dijagrama kao i odgovarajući propratni komentar sa kojim ću odbraniti svoj završni rad za sticanje bachelor diplome. Nadam se da je sada jasno zašto nemam vremena da pišem definicije za sve entitete i atribute. Ukoliko ima nejasnoća odgovoriću na forumu.

I pored toga nemoj da se libiš da daješ komentare.

Sutra ću da okačim model u BPwinu i ERwinu kad načinim izmene.

Evo recimo predloga u vezi smanjnja početnog broja aktivnosti na prvom nivou dekompozicije:
Ostaviti trenutno postojeće aktivnosti:
„3. Odrzavanje podataka o citaocima“ - Evidentiranje citalaca
„5. Odrzavanje podataka o knjigama“ - Evidentiranje knjiga
„6. Odrzavanje podataka o zaposlenima“ - Evidentiranje zaposlenih

Aktivnosti
„2. Upravljanje iznajmljivanjem knjiga“
„7. Upravljanje izvestajima“

Stopiti u jenu aktivnost i preimenovati „Odrzavanje podataka o iznajmljivanju knjiga“ ili još bolje samo "Iznajmljivanje kniga".

Razlog: Pojam aktivnosti „Upravljanje izvestajima“ je vezan za informacije koje se dobijene izlazima.
svi izlazi (izlazne informacije) na dijagramu konteksta i ovako služe za izveštavanje.

U Ovoj novoj aktivnosti „Odrzavanje podataka o iznajmljivanju knjiga“ mogla bi da se nađe i bivša aktivnost
„4. Unos clanarine za odredjeni period“
Jer promena iznosa članarine za određeni period i ovako spada u delokrug rada oko iznajmljivanja knjiga

Aktivnost „1. Unos osnovnih podataka o biblioteci“ je jednokratna (treba jednom uneti jedan zapis) i po meni čak ne bi ni morala da se modeluje, mada njen ostanak neće preterano povećati kompleksnost dijagrama.

Na taj način bi maksimalno imao 5 aktivnosti na prvom nivou. Ulazne i izlazne strelice ne bi trebalo toliko detaljizovati na samom po;etku dekompoyicije. Postoji metoda kojom se one granaju u kasnijim nivoima Recimo ulazi:

„Zahtev za unos novog citaoca“
„Zahtev za azuriranje citaoca“
„Zahtev za zabranu uzimanja knjiga citaocu“

Mogli bi se na prvom nivou (kao i na dijagramu konteksta) utopiti kao jedna „Zahtevi za citaoca“ , a adekvatni izlazi:

„Podaci o citaocu su uneti“
„Podaci o citaocu su promenjeni“
„Citaocu je zabranjeno uzimanje knjiga“

Mogli bi se utopiti i imenovati jednom novom strelicom „Podaci o citaocu.“

Savet: izbegavaj imenovanje strelica čitavim rečenicama tipa: „Citaocu je zabranjeno uzimanje knjiga“, već samo imenicom i pridevom, imenicom i prilogom ili subjekat i predikat. Recimo "zabrana iznajmljivanja".








_{[Ovu poruku je menjao Getsbi dana 25.08.2008. u 11:19 GMT+1]}

Hajde da vidimo šta wikipedia kaže za ISBN.
- "The International Standard Book Number (ISBN) is a unique, numerical commercial book identifier..." prevedeno na naš jezik: "ISBN je jedinstven numerički identifikator komercijalne knjige"
ISBN je identifikator! Identifikator služi za identifikovanje entiteta, pa samim tim on nemože da bude entitet!
Dalje u tekstu stoji:
- "An ISBN is assigned to each edition and variation (except reprintings) of a book." što bi se reklo "ISBN se dodeljuje svakom izdanju i varijaciji (izuzev reprintu) knjige."
ISBN se dodeljuje izdanju knjige (To je nov pojam koji se pojavio u ovom modelu!). Dakle, ISBN je atribut entiteta 'Izdanje'. Ovaj entitet nam je falio i zbog tog nedostatka je neispravno uveden ISBN kao entitet.

Hajde da definišemo neke od pojmova.
Pošto nam fali dobar srpsko-srpski rečnik (nažalost, www.vokabular.org je skromnog sadržaja), poslužio sam se englesko-engleskim rečnikom na www.dictionary.com.
- Autor je osoba koja piše novele, poeme, eseje, itd.
- Izdavač je osoba ili preduzeće koje se bavi izdavanjem knjiga.
- Knjiga je pisano ili štampano delo, najčešće na listovima papira povezanih unutar korica.
- Izdanje je jedno od serije štampanja iste knjige, gde je svaka serija štampanja inicirana u različitom vremenu.
- Primerak je pojedinačna, prepoznatljiva kopija jednog izdanja knjige. (Pošto nisam znao kako da nađem pojam 'primerak knjige', dao sam svoju definiciju u kojoj su mi ipak pomogle engleske reči specimen i individual.)

Nakon ovoga je model jasniji i dobija svoj oblik koji je dat na slici u prilogu. Izmene koje sam uradio na polaznom modelu:
- izbačen je "enititet" 'ISBN', a ubačen je atribut 'ISBN' u entite 'Knjiga'.
- Postojeći entitet 'Knjiga' je podeljen na dva entiteta: 'Knjiga' i 'Izdanje'.
- Atributi koji su pripadali nekadašnjem entitetu 'Knjigać su raspoređeni između novih entiteta 'Knjiga' i 'Primerak'.
- Veza između 'Izdavac' i nekadašnjeg entiteta 'Knjiga' je prebačena tako da povezuje entitete 'Izdavac' i 'Izdanje'.

Komentar: Knjigu napiše autor, da joj ime i kompletan tekst knjige. U tom momentu, a ni kasnije, njemu nije bitno da li će knjiga biti štampana na 200, 300 ili 1000 strana, da li će biti ilustrovana, u mekom ili tvrdom povezu.
Samu forumu pri štampi knjige određuje izdavač. On odlučuje da li će to biti knjiga džepnog formata, ili će možda biti uklesana na glinenim pločama. To je ono što se zove izdanje knjige.
Kada knjiga dospe na tržište, kupca niko nemože da spreči da kupi 2, 3 ili 5 kopija istog izdanja, pa čak i da kupi istu knjigu u izdanju drugog izdavača.
Kada član biblioteke uđe u biblioteku i traži neku knjigu neinteresuje ga ko ju je izdao i koliko ima strana. Njega opet interesuje samo naslov i sadržaj knjige, a ne i forma. Papir je samo posrednik između pisca i čitaoca.


Evo i primera već spomenutog 'Gospodara Prstenova'. Na internetu sam pronašao podatke o dva izdanja ove knjige:

izdanje 1
tvrd povez, 1131 strana, 24 cm, latinica
Izdavač: Narodna knjiga - Alfa
Beograd 2002.
ISBN 86-331-0460-1

izdanje 2.
broširani povez, 1300 strana, 21 cm, latinica
Izdavač: Esotheria, Moć knjige
Beograd 2002.
Edicija: Grifon
ISBN 86-81585-69-X

Da li se ovde radi o dve knjige ili o jednoj knjizi u dva izdanja? Odgovor se nameće sam po sebi, jer je Tolkien napisao knjigu pre nego je Esotheria uopšte nastala.

U "našoj" biblioteci može da se neđe više primeraka izdanja koje sam obeležio brojem 1 i više primeraka izdanja koje sam obeležio brojem 2. Ovi primerci mogu biti u različitom stanju (oštećenja) i na njima je verovatno udaren neki delovodni pečat biblioteke po kojem se svaki primerak može jedinstveno identifikovati.

Jasno je da je ISBN jedinstveni identifikator knjige ali ja ga ne mogu koristiti u informacionom sistemu za tu svrhu. On u stvarnosti jeste jedinstven za jedno izdanje (ne računajući kopije knjige) ali u informacionom sistemu to ne može biti jer ne ispunjava neke uslove. Najprostije rečeno ne može biti jednistveni identifikator knjige tj. primarni ključ jer nemaju sve knjige ISBN iste dužine (knjige sa ISBN od 10 i 13 cifara)i zato to u informacionom sistemu ne može biti jedinstveni identifikator već samo dodje kao jedna informacija koja može da se dobije iz informacionog sistema. Kao što sam rekao većina knjiga ima jedan ISBN broj, međutim postoje knjige koje imaju dva ISBN broja i nadam se da se tu ne sporimo. Ukoliko je tako onda ISBN ne može biti atribut jer ne bi smo mogli da unesemo dva ISBN-a za jednu knjigu. Jos jedno rešenje bi moglo biti da imamo dva atributa ’PrviISBN’ i ’DrugiISBN’ ali mislim da bi ovo bilo loše rešenje jer bi ovaj drugi atribut bio uglavnom Null.
Opravdano je uvođenje entiteta Izdanje. Sada je ovo jedna nova situacija gde na primer treba vezati entitet ISBN za ovaj entitet. Takođe kao što si na priloženoj slici uradio treba za ovaj entitet vezati entitet ’Publikovao’.
Ja sam u mom modelu imao u vezanom entitetu ’Publikovao’ imao atribut ’DatumPublikacije’ a ti si stavio ’GodinaIzdavanja’ u entitetu ’Izdanje’. Iz ’DatumPublikacije’ je moguće pomoću ugrađenih funkcija moguće izdvojiti godinu ali nije to ono što me interesuje već gde je bolje staviti ovakav atribut, da li u entitetu ’Izdanje’ ili u entitetu ’Publikovao’ ili je možda svejedno (čisto da znam za buduće projekte).
U skladu sa ovim promenio sam malo i entitet ’Primerak’. Naime, sada primarni ključ čine atributi ’SifraIzdanja’ i ’RedniBrojPrimerka’. Prethodni primarni ključ ’SifraPrimerka’ sam stavio kao običan atribut i promenio mu ime u ’InterniBroj’. Njegova definicija u modelu glasi:
’’Ovo je interni broj koji biblioteka dodeljuje svakom primerku knjige. Na primer prva knjiga ce dobiti oznaku 1, druga oznaku 2, hiljadita knjiga oznaku 1000 itd. To je u stvari nalepnica koja se postavlja na prednjoj strani knjige.’’
Nadam se da je jasno značenje ovog atributa.
Ukoliko je ovo sve u redu a ja za sada ne bih dodavao ništa više trenutno jer kako rekoh nemam baš mnogo vremena a eventualne izmene ostavljam za naredna izdanja. Za polaganje ispita je ovo dovoljno. Naravno kad uradim još i ograničenja (kardinalnosti veza, referencijalni integritet i identifikacija poslovnog domena) kao i ispravke na aktivnostima i matrici odnosa na IDEF0 modelu kao i uvoz ovog u Access.
Još nisam uradio izmene u BPwinu ali se javljam kad i to odradim. Posle ovih izmena radim definisanje poslovnih pravila a onda i izvoz u Access.
Getsbi javljam se sa komentarima na tvoje predloge kad završim sa ovim izmenama u BPwinu.
U prilogu se nalazi model kao i slika za one koji nemaju BPwin i ERwin.

Molio bih još da malo proanaliziramo entitet 'Ostecenje'. Tu mi je promakao atrubut 'Upotrebljiva' a takav atribut imam u entitetu 'Primerak' a to je atribut 'StatusOstecenja'. Ukoliko bi recimo izbrisao ovaj atribut u entitetu 'Primerak' a ostavio ovaj u entitetu 'Ostecenje' mislim da to ne bi valjalo. Ovo polje će biti check box i biće čekirano od strane bibliotekara ukoliko je oštećenje veliko da se knjiga ne može više izdavati (na primer ukoliko su iščupane stranice od 233 do 262) a ukolio su dve strane malo izgužvane onda neće biti čekirano i knjiga će moći i dalje da se iznajmljuje čitaocima. Ukoliko bi ostavio ovo polje u entitetu Ostecenje onda bi imao veliku redundansu. Razmotrimo slučaj na konkretnom primeru. Na primer jedan čitalac Ivan je izgužvao dve strane knjige Gospodar Prstenova i onda se to unosi u tabelu ostećenja gde se unosi SifraOstecenja, SifraIzdavanja, Ostecenje (tekstualni opis oštecenja) i ukoliko bi postojao atribut Upotrebljiv (misli se na primerak) i check box koji bi se odnosio na primerak onda bi postojala redundansa. Zašto? Primerak pomenute knjige nije mnogo oštećen i ponovo je izdat. Pošto je to popularna knjiga svakojaki čitaoci je uzimaju ne čuvaju je baš pažljivo. Žile je uzeo isti primerak i pogodite šta, izgužvao je neke tri stranice knjige. Ponovo se gore pomenuta polja upisuju u oštećenja i to sve dok naiđe oštećenje koje je veliko i zbog kojeg će bibliotekar da čekira polje Upotrebljiva. Tu i jeste problem jer se ovo polje nepotrebno nalazi u entitetu Ostecenje. Po mom mišljenju bolje bi bilo da se ovo polje nalazi u entitetu Primerak. Znači na postojećem modelu bih izbrisao atribut 'Upotrebljiva' u entitetu 'Ostecenje' a atribut 'StatusOstećenja' u entitetu 'Primerak' bih preimenovao u 'Upotrebljiva'.
Čekam vaše mišljenje.

Završio sam aktivnost definisanja kardinalnosti veza i evo pogledajte izmenjeni model. Sad radim definisanje referencijalnog integriteta pa se javljam (najverovatnije u toku dana) kad završim i ovu aktivnost.

Problematična mi je veza "Primerak" – "Skladišni prostor". Ispada da se jedan primerak čuva u nijednom, jednom ili više skladišnih prostora.

Mislim da je bila bolja varijanta sa početka kada su "Primerak" i "Ostecenje" bili direktno povezani. "Ostecenje" bi po meni moglo da ima dva datumska atributa: "NeupotrebljivoOd" i "NeupotrebljivoDo" kao i atribut "OpisOstecenja". Ovi datumski atributi bi bili popunjavani po potrebi i znalo bi se da li je primerak u upotrebi po popunjenosti jednog ili oba atributa. U entitetu Primerak ti onda atribut "Upotrebljiva" ne treba. Kod izdavanja se na zahtev čitaoca u aplikaciji potraži SifraKnjige i preko SifreIzdanja svi mogući primerci. Za svaki od ovih primeraka bi se pomenutom vezom i atributima znalo da li je knjiga raspoloživa ili ne.

Što se tiče veze 'Primerak'-'SkladišteniProstor' u pravu si da treba da se promeni. Promenio sam tako da jedan primerk roditelja (Primerak) je povezan sa tačno jednim primerkom deteta (SkladišniProstor). Ovaj entitet SkladisniProstor će doživeti izmene prilikom implementacije u nekoj biblioteci jer nemaju sve biblioteka istu organizaciju prostora.
Promenio sam naziv atributa Ostecenje u OpisOstecenja i upravo to mi je i predstavljao ovaj atribut ali ga nisam lepo imenovao.
Ja ne bih raskidao vezu između Ostecenje i IzdavanjeKnjige jer odatle vučem neke bitne informacije. Ukoliko ga vežem za Primerak onda ne bi ni znao kad je knjga izdata na primer. Hajde da sačekamo i mišljenja drugih ljudi povodom ovog.

Evo napravio sam izmene u BPwin modelu i tu je još ostala samo još matrica odnosa nedovršena ali obećavam do sutra ujutu da će biti gotova. Što se tiče ERwin modela uradio sam definisanje kardinalnosti veza, referencijalni integritet i aktivnost definisanje poslovnih domena. Molim vas obratite pažnju posebno na prve dve aktivnosti jer su one mnoogo bitne.
Jedna stvar koju sam tek danas primetio je da mi je veza između 'Radnik' i 'IzdavanjeKnjige' jedan prema više. Ja mislim da bi trebalo da je više prema više (ne izdaje samo jedan radnik knjige). Takve veze se razbijaju na dve veze jedan prema više ali ne znam šta bi mogao da mi bude vezani objekat. Imate li neke komentare i na ovo?

Entitet "IzdavanjeKnjige" je evidencija jedne aktivnosti i nema potrebe za razbijanjem na dve veze. Taj entitet već jeste vezni entitet između "Radnik" i "Primerak" koji se izdaje.
"Radnik" izdaje jedan ili više "Primerak". "Primerak" može biti izdavan od jednog ili više "Radnik".

Nedaj se zbuniti. Ostalo ću pogledati čim budem mogao.

Uh..Bas sam se iscimao kad sam video ovo. Pomislih zar još izmena, ali hvala Bogu što je ovako ispalo. Evo samo da završim još matricu odnosa i javljam se sa kompletnim modelima u BPwinu i ERwinu.

U IDEF0 i dalje ostaje problem prevelikog broja strelica po tipu. Ne bi trebalo da bude više od 6 ulaznih i 6 izlaznih. Možda ti je ova primedba promakla, a možda si i odustao od prepravke.

Nije mi promakla primedba, već sam ostavio ovako kako jeste jer nemam vremena za dodatne ispravke (prvog septembra imam ispit iz baza a drugog iz informacionih sistema) a imaću na umu kad budem dorađivao model.
Ukoliko je nekom potrebno uputstvo za generisanje šeme baze podataka ili je naišao na probleme pri ovom procesu neka postavi temu i detaljno ću objasniti. Česti problemi koji se mogu javiti je da se isti opis veze roditelj-dete javlja dva puta i onda će se javljati greške. Još jedna greška koja mi se javila kada sam generisao bazu iz ERwina je da mi je primarni ključ 'SifraIzdanja’ u entitetu ‘Izdanje’ bio AutoNumber a u entitetu primerak gde je deo primarkog ključa kao strani ključ (ForeignKey) je bio Integer. Nikako nije htela da se generiše šema i onda sam promenio iz Integer u LongInteger i onda je sve odradilo bez problema..
Javljam se posle jedanaestog septembra za pomoć oko pravljenja aplikacije u Accessu kad položim i poslednji ispit iz treće godine (naravno ukoliko položim prethodno baze I informacione sisteme).
Evo kompletnog modela zajedno sa generisanom šemom baze podataka u Access 2003.

Jedno pitanje za moderatore foruma: Da li da postavljam novu temu za pravljenje aplikacije u Accessu (mislim na upite, forme, izveštaje,..) u novoj temi ili mogu da nastavim u ovoj. Ukoliko bi ste mi dozvolili ja bih nastavio u ovoj temi i zbog drugih ljudi na forumu da vide kako ide jedan postupak izrade baze zajedno sa aplikacijom od funkcionalnog, preko informacionog do aplikativnog modeliranja.

Ja sam igrom slučaja moderator na Access forumu i mislim da bi bilo dobro rešenje da otvoriš novu temu na Access forumu i u prvom postu postaviš link ka ovoj temi, uz obrazloženje da se prethodno urađena dokumentacija nalazi ovde. Time bi smo zadovoljili pravila i povezali teme.

U redu onda. Pozdrav

Položio sam ispit i na ispitu mi je profesor ukazao na još neke sitnije propuste pa se javljam kad završim te ispravke a to će biti za dva tri dana.

Sad ispratih celu temu, pa i ja malo da dodam.

Vratio bi se malo na ISBN.

Ako dobro shvatam stvari stoje ovako:

Jedna knjiga može da ima više izdanja.
Svako izdanje dobija jedinstveni ISBN broj na planetarnom nivou.

Elem, u tom slucaju mi i dalje bode oci sto si ISBN gurnuo u
poseban entitet - tabelu, kada je on upravo idealan da bude
prirodni primarni kljuc entiteta izdanja.

Ono sto naslucujem je da tebe brine sto ISBN iako je jedinstven
nije jednake duzine. To ne treba da te brine.
Bitno je da je jedno izdanje jedan jedinstveni ISBN.

Ono sto moze biti problem je mozda to sto je sam ISBN
malo "kabast" za unos (10 ili 13 karaktera), pa treba odmeriti
ucestalost unosa istog prilikom normalnog rada,
(moja procena je da nije, ali nisam bibliotekar), pa ako je bas
"muka", onda bi ga gurnuo da bude atribut entiteta izdanja,
a tek onda (ako nema drugih kandidata) generisao sinteticki primarni kjuc
za entitet izdanja.

Mislim, moze i ovako, ali ako postavis da ISBN bude primarni
kljuc entiteta izdanja, uproscava se ceo model bez gubitka na
funkcionalnosti, a i imaces manje posla prilikom izrade aplikacije.

Pozdrav Bojan.

Veoma mi je žao što nisi dobro tj. do detalja probao da ispratiš diskusiju. Jer da jesi, video bi da smo već diskutovali o ovom problemu. Ipak, da ponovim još jednom: ISBN nisam stavio kao primarni ključ zato što ne ispunjava osnovni uslov da primarni ključ mora da bude iste dužine. Druga stvar zašto sam stavio kao poseban entitet je zato što je moguće da jedno izdanje ima dva ISBN-a gde jedan ISBN označava izdavača a drugi izdanje. Ukoliko bi ISBN stavio kao atribut u entitetu 'Izdanje' onda ne bi mogao da unesem dva ISBN za jednu knjigu. Nadam se da smo načisto sa ovim..Drago mi je da se još neko uključio u diskusiju..
Uskoro ću postaviti konačan model sa ispravkama koje mi je predložio profesor, kada završim i poslednji ispiti iz treće i kad krenem sa pravljenjem aplikacije u Accessu..

Temu sam ispratio pazljivo i upravo zato se i ukljucujem u celu pricu.
Postoji samo mogucnost da neko od nas dvojce nije nesto dobro razumeo.

Pa da rezimiramo jos jednom:

ISBN izdanja je jedinstveni internacionalni broj izdanja jednog dela ili ti knjige?
ISBN izdavača je jedinstveni internacionalni broj izdavača?
Jedno izdanje ne može imati više od ova dva navedena ISBN-a?

Da li je ovo dobro shvaceno?

Po mom shvatanju oba ISBN-a su atributi jednog izdanja neke knjige.
Odnosno mi i nemamo dva ISBN-a nego:

1. ISBN - Internatioaal Standard Book Number
2. ISPN - International Standard Publisher Number :-)

Čak da ih i priznamo da su entiteti, to bi onda bila dva različita entiteta i onda
po meni ovakva postavka modela nije dobra, jer nisi u stanju da prepoznaš
koji je koji entitet.

Vidim da si u stvari zabrinut oko toga što se (pretpostavljam) ISBN izdavača
(ISPN po meni) retko može naći na izdanjima i da bi ti u tom slučaju taj atribut često bio null.
Ne bi to trebalo da te brine, ako ga nema, onda ga nema, šta da se radi i bar
znamo da ga nema. U tvojoj postavci čak i ne znamo koji od ova dva nedostaje.
Nije nužno da ako je neki atribut često null da sa njim "nešto nije u redu".

Što se tiče dužine primarnog ključa, ne vidim problem ako je on nejednake
dužine, mislim da je dovoljno da znamo najveću moguću dužinu i da je
jedinstven. Ispravite me ako grešim?

Onda sam malo njuškao oko ISBN (http://www.isbn-international.org)
i našao dosta interesantnih detalja koje ne bi bilo loše da se prouče,
obzirom na temu kojom se bavimo.
Evo par stvari koje sam tamo našao, a zapale su mi za oko:

Od 2007. god. ISBN je prešao sa 10 na 13 cifarski kod.
Postoji pravilo za konverziju starih ISBN u nove.
Sam ISBN u sebi sadrži podatke o izdavaču, izdanju... (nisam čitao do kraja)
Zadnja cifra ISBN-a je kontrolna.

Što će nam reći:

ISBN je ipak fiksne dužine, znači može kao primary key.

ISBN ima u sebi ugrađen mehanizam za kontrolu unosa.

ISBN u sebi sadrži podatak o izdavaču, što postavlja pitanje postojanja drugog
ISBN-a (ISPN-a) , koji si ti u praksi sretao. Nemam iskustvo iz prakse, ali mislim da
je po ovom pitanju neophodno izaći na čistac, šta je u stvari taj drugi broj koji
se može naći na izdanjima.
U prilog tome ide i to što je ISBN jedinstven za svako pojedinačno izdanje i
po toj definiciji mi po jednom izdanju možemo imati samo jedan ISBN.
Ako ima još nešto, onda to nešto nije ISBN, možda nisam u pravu,
ali mi ovako izgleda logično.

Mogao bih da se kladim je je upravo ISBN primarni ključ svih primarnih ključeva u
centralnoj bazi ISBN registra. :-)

Ja bi ISBN bez rezerve uzeo za primarni ključ entiteta izdanja osim
ako se u biblioteci mogu naći izdanja na kojima ISBN ne postoji.
U tom slučaju bi ga zadržao da bude "jak" atribut entiteta izdanja,
nažalost zbog mogućih null vrednosti bez Unique Constraint.
U svakom slučaju na neki način bi implementirao kontrolu jedinstvenosti
unosa, tako da nema šanse da se otvore dve stavke sa istim ISBN.

Možda se čudiš što sam se uhvatio ISBN-a "ko' pijan plota", ali mislim
da je on u celoj ovoj priči veoma bitan iz prostog razloga što ga
praktično ceo svet koristi i da ako želiš da tvoja buduća aplikacija
jednog dana komunicira sa spoljnim svetom, nije loše da joj se odmah
udare dobri temelji.

Da li smo se razumeli, ako ne, idemo dalje, očekujem tvoje dalje komentare
i spreman sam da i dalje diskutujemo oko ovoga, a i oko ostatka aplikacije
kad objaviš zadnju verziju projekta. Mislim da iz ovakvih diskusija ljudi mogu
dosta da nauče.

Nadam se da nisam udavio.

Pozdrav,
Bojan

PS: U prilogu ISBN user manual

Iako nisam hteo više da terem mak na konac po pitanju ISBN-a... ipak moram.

Ovo apsolutno nije tačno! ISBN označava izdanje knjige i ništa drugo. U delu ISBN-a se nalazi oznaka izdavača!

@biske86: Da si pročitao link ka wikipedijinom članku o ISBN-u i da si malo pretražio internet (recimo http://www.isbn.org/standards/home/isbn/transition.asp) bilo bi ti jasno da postoji ALGORITAM za pretvaranje ISBN-10 u ISBN-13. ISBN je izmislila ozbiljna organizacija koja je na vreme razmišljala kako da proširi inicijalnu dužinu od 10 karaktera. ISBN je atribut, a to da li će u bazi biti puno NULL-ova uopšte nije problem koncepcijskog pa čak ni logičkog modeliranja (što su faze u kojima si ti bio).

ISBN nemože da bude ključ jer su se knjige izdavale mnogo pre nego što je ISBN izmišljen, pa ga mnoge knjige jednostavno nemaju. ISBN je izmišljen da bi olakšao trgovinu knjigama, a ne da bi olakšao njihovo popisivanje. To što ISBN nemože da bude ključ ne umanjuje činjenicu da je ISBN atribut a ne entitet!

Uvideo sam da su mi potrebna neke izmene u modelu. Na primer, u entitetu ‘IzdavanjeKnjige’ imam informaciju koji je bibliotekar izdao knjigu, ali ne mora ta ista knjiga da se vrati kod istog tog bibliotekara, već naravno to može biti i drugi bibliotekar. Zato sam uveo još jedan atribut ‘RadnikKodKogaJeVracena’ a prethodni je preimenovan u ‘RadnikKojiJeIzdao’. Znam, znam da su imena očajna ali se nadam da će neko od vas naći neko zgodnije ime za ova dva atributa jer je meni ponestalo inspiracije.

Naravno odgovara mi što si pokrenuo ovo pitanje još jednom, pa možemo jednom da budemo načisto sa ovim problemima oko ISBN kada završimo diskusiju.

Evo i maila koji sam dobio kada sam pitao za pomoć oko ovih problema:


Ovo je odgovor na sledeći komentar:

Poslao sam još jedan mail za dodatna objašnjenja pa ću javiti kad dobijem odgovor. Takođe ću javiti i šta je bilo na intervjuu sa bibliotekarkom..

Mehanizam za kontrolu ISBN je dobra stvar. Pogldedao sam kako se radi i nije ga teško implementirati. Ovo ću zasigurno ugraditi u svoju aplikaciju.

Naravno da je poželjno da podeliš svoje mišljenje sa nama jer od ovoga imam ja koristi jer ću uraditi dobar završni rad za fakultet, srušiću neke svoje zablude, naučiti nove stvari..Isto je i sa ostalim korisnicima ali koliko vidim oni ne učestvuju aktivno u diskusiji ali nije bitno mogu iz naših razmatranja takođe da nauče..Koliko sam pročešljao ovaj forum ima vrlo malo konkretnih projekata koji su izneseni na videlo i mislim da ovakve diskusije doprinose poboljšanju foruma..

OK Teramo dalje ...

Prvo da dam predlog kako da 'krstis' atribute:

RadnikKojiJeIzdao
RadnikKodKogaJeVracena

PrimerakIzdao
PrimerakPrimio

ili

RadnikIzdao
RadnikPrimio


ISBN:

Svaka cast na trudu da dodjes do pravih informacija (mislim na mail pisan ISBN agenciji).
Po ovome sto se do sad saznalo, stvar je ipak komplikovanija nego sto sam pretpostavljao.

Ako je ISBN agencija u pravu, onda jedno izdanje moze imati kolk'o oces ISBN-ova, ne samo
dva (sto ne bi postojao slucaj gde izdanje ima na primer pet izdavaca, i svi zele njihov
ISBN na knjizi?).

U ovakvom slucaju, naravno resenje je da se ISBN gurne u poseban entitet, odnosno po
ovome bi nam u stvari bilo potrebno dva entiteta:

1. ISBN - Izdanja
2. ISBN - Celine

Naravno, postoji nedoumica oko ISBN za celinu, treba proveriti da li postoje celine koje
imaju vise izdavača, a samim tim i više ISBN, po logici stvari, ako postoje izdanja
sa vise izdavaca, zasto ne bi postojale i celine.

Ajd' da sacekamo jos malo, da ti stignu sve informacije pa da zakljucimo ovaj deo price.

Pozdrav,
Bojan

Još mi ne stiže odgovor od narodne biblioteke tj. od žene kojoj sam prošli put pisao mail tako da se nisam javljao. Kod bibliotekarke na fakultetu sam otišao po informacije i ona mi kaže da se ne seća knjige koja ima dva ISBN broja, pa se pitam da li uopšte knjiga i ne može da ima dva ISBN-a. Ja mislim da sam letos video u drugoj biblioteci knjigu koja ima dva ISBN-a ali se ne sećam koja je. Možda su to bila dva ista ISBN-a ali je jedan bio stari desetocifarni a drugi isti taj prekonvertovan u trinaestocifreni ali su odštampana oba u prelaznom periodu. Verovatno bih stavio u informacionom sistemu da imam samo jedan ISBN ali me je zbunio prvi mail koji sam dobio iz narodne biblioteke koji sam postovao u ovoj temi. Može li neko od vas da pita bibliotekara u gradu ukoliko vam nije daleko biblioteka, možda dobijemo potuniju sliku. Nešto me vuče na to da je žena iz narodne biblioteke previdela kada mi je napisala pomenuti mail, što je malo verovatno ali moguće a i ne odgovara mi na mail koji sam joj poslao pre dva dana u kome tražim da mi razjasni ovo za dva ISBN-a..

Hvala Bojane na predlozima za nazive atributa..
Kada završimo sa ovim diskusijama okačiću fajlove..

Ukoliko nekom trebaju BPwin i ERwin instalacije (obe u verziji 4.1), javite se na PP.

Sve cestitke za sve sto si do sada uradio!!!!!!!!! Ja mogu reći da sam razgovarao sa jednom bibliotekarkom i da mi je ona rekla da postoje knjige i sa dva ISBN-a. To se dešava od knjiga koje se nalaze npr. u sklopu sabranih djela, a na njima se nalazi ISBN sabranih djela i ISBN knjige u sklopu njih.
Imam za sada samo četiri pitanja:
1. Zašto entitet "Skladisni prostor" nema sopstvenu šifru, već koristiš "RedniBrojPrimerka" i "SifraIzdanja"? Pretpostavljam da je logičnije rešenje "SifraIzdanja" i "SifraPozicije"
2. Dali si razmišljao da kao novi entitet iskoristiš i tzv UDK (univerzalna decimalna klasifikacija) koja prilično opisuje svaku knjigu, tj. izdanje, a mogla bi se vezati za entitet "Izdanje" na isti način kao i ISBN?
3. Možeš li, meni kao laiku objasniti oznake AK1.1, AK1.2, IE1.1, IE1.2 koje si koristio u ERwinu?
4. Dali se kao šifra u entitetu "Citalac" mogu koristiti JMBG svakog čitaoca, a isto tako i u entitetu "Radnik"?

Još nešto, čini mi se da su ti sugerisali da ti rešenje kod definisanja plaćanja članarine nije dobro, pa možeš li mi reći dali si zadovoljan sa ovim rešenjem, a ako nisi kako si to rešio.

Pozdrav

_{[Ovu poruku je menjao corke dana 25.09.2008. u 15:53 GMT+1]}

1. Zato što nema potrebe da imamo novi širfu u skladištenom prostoru jer je relacija između primerka i skladištenog prostora 1 prema 1 i jednom primerku može biti dodeljena tačno jedna pozicija. U tom kontekstu nema potrebe da uvodim višak dodavanjem još jednog atributa.
2. Naravno da ću to ubaciti u nekim novijim verzijama ove baze. Ovo bi ubacio čisto doslednosti radi, jer ovaj broj sadrži mnogo informacija ali nije podogan za tehničku obradu na računaru, jer kada se pojavljuju nove oblasti u nauci one se onda dodaju, pa se menjaju rasporedi, takođe nije ni iste dužine. To ću ubaciti čisto doslednosti radi, da bi sistem oslikavao realno stanje stvari u biblioteci ali ništa od informacija se ne dobija uvođenjem ovog atributa. Pošto ovo radim kao završni rad za sticanje bachelor diplome ne mogu da vršim sada ispravke jer moram da završim rad za desetak dana.
3. To su alternativni i inverzni ključevi. AK - alternativni, IE - inverzni.
“Alternativni ključ (AKn) predstavlja atribut ili grupa atributa koji jedinstveno identifikuju primerke entiteta. ERwin generiše jedinstveni indeks za svaki alternativni ključ.
Ako treba definisati indeks nad atributom ili grupom atributa koji ne identifikuju jedinstveno primerke entiteta definiše se takozvani Inverzion Entry (IEn) indeks.“
Razvoj informacionih sistema, Alempije Veljović
Na primer alternativni ključ kod mene je JMBG zato što je jedinstven ali nemaju ga svi čitaoci (npr. strani državljani) a invezni ključ je na primer Ime jer to polje nije jedinstveno jer se mogu naći dva čitaoca koji se zovu Ivan.
4. Pošto strani državljani nemaju JMBG onda nije moguće.

Napravio sam dosta izmena, tamo gde sam primetio da imam redudanse ili gde je bilo moguće poboljšati model. Ne sećam se tačno šta sam menjao od poslednjeg posta ali na primer atribute „GrupaKnjige“, „TipKnjige“, „VrstaPoveza“ sam izdvojio u poseban entitet jer sam prilikom probnog unosa u bazu primetio da mi se javlja redudansa.
Pošto sam u frci oko završetka završnog rada nisam u mogućnosti da stalno odnovaram na temu. Takođe nemam stalni pristup internetu tako da se izvinjavam na kašnjenju odgovora. Kada odbranim završni rad onda možemo nastaviti diskusiju oko ovog modela, da bi smo ga još poboljšali jer ovo nije samo moj model već je praktično i vaš.
Planiram i da prebacim bazu na Oracle kad počnem da ga učim u narednom semestru a aplikaciju najverovatnije u VB.NET (nisam siguran za aplikaciju).

Aplikaciju radim u Access 2003 i možete je pogledati u sledećoj temi:
http://www.elitesecurity.org/t337481-Biblioteka-baza-podataka

Evo u attachmentu kompletnih modela u BPwinu i ERwinu..

Pozdrav svima. Dosta ljudi mi se javlja sa zahtevom da im pošaljem biblioteku pa sam rešio da je postavim na svom blogu. Na adresi http://biske.rs/projekti/biblioteka/ se nalazi kratak opis, par slika, kao veza za preuzimanje modela procesa, modela podataka, same baze kao i dokumentacije tj. mog završnog rada.

Aktivirasmo staru temu, a sa njom i staro pitanje: Da li jedno izdanje može da ima dve ISBN-13 oznake?

@biske86: Šta je krajnji ishod tvoje prepiske sa ljudima iz ISBN registraciong tela i sa ljudima iz narodne biblioteke?

Ne sećam se da li su mi poslali mejl, odavno beše Tada sam imao yahoo nalog koji sam kasnije ugasio pa ne mogu da proverim. Ali evo sinoć sam ih upitao i dobio sam odgovor. Evo mejla, nadam se da ne moram da ga prevodim:

Znači to je ono što smo pominjali u diskusiji.
1. Jedna knjiga u različitim formatima ima dva različita ISBN. Na primer papirna i elektronska verzija knjige. Ali ovo ne znači da se na jednoj knjizi unose dva ISBN, nego svaki format ima na sebi utisnut po jedan ISBN. Po meni u biblioteci elektronsko i papirno izdanje knjige treba posmatrati kao dva različita primerka knjige.
2. Jedini slučaj kada knjiga može da ima dva ISBN je zbog konverzije iz starog 10-cifrenog u novi 13-cifreni format.

Da li ima neko drugačiji primer iz prakse?

Zbog obaveza na studijama prestao sam da usavršavam ovaj sistem ali mi je ovo sad zagolicalo maštu. Baš ću da odem kod par bibliotekara i da probam da propitam malo oko ovoga

Nakon ljubaznog odgovora ponovo sam poslao mejl sa dodatnim razjašnjenjima. Evo mog mejla:


Odgovor je sledeći: