{ Software } Informacioni sistem za vođenje APOTEKE

Nekako mi ona definicija pod a) Inženjerska disciplina, najviše odgovara, mada su ljudi skloni da sve što im izgleda iole komplikovano nazovu umetnost. :-) Pre bih to umesto umetnosti nazvao skupom iskustava stečenih radom na projektovanju informacionih sistema korišćenjem već ranije pominjanih pravila.

Zašto uopšte dijagrami?

Zato što je uopšteno govoreći mnogo lakše vršiti i razvoj i naknadne promene prilikom posedovanja grafičko-tekstualne dokumentacije, radilo se o timu developera ili pojedincu Posmatrano sa aspekta promene članova tima i njihove migracije sa projekta na projekat ova potreba postaje nužnost. Kada su veći projekti u pitanju, vlasnici sve češće zahtevaju standardizovanu dokumentaciju putem nadzornih organa.

Zašto oba?

Pretpostavljam da je prvi dijagram ili funkcionalno modeliranje koji se tiče poznavanja poslovnih procesa, aktivnosti, poslovnih pravila i svega drugog što je neophodno za samo projektovanje informacionog sistema nad jednim projektnim zadatkom, manje sporan. Iluzorno je i upuštati se u projektovanje nečeg o čemu nemate elementarna znanja i čiju problematiku uopšte ne poznajete. S druge strane ako se tim promeni ili pojedinac nešto zaboravi, hoće li vlasnik dozvoliti ponovno intervjuisanje po istim pitanjima.

Eventualno bi se moglo postaviti pitanje zašto dijagram baze podataka ili informacionog modela kada to isto ili nešto slično imamo u fizičkom modelu baze podataka ili ga iz njega možemo iscrpeti. Odgovor bi bio takođe zbog standardizacije. Kada posedujete standardizovanu dokumentaciju na logičkom nivou, onda je u mnogome olakšana komunikacija između članova tima koji u osnovi svi i ne moraju poznavati i raditi u istom SUBP-u. Pogotovo je ovo važno kada se prelazi sa jednog SUBP-a na drugi. Svi koji su se bavili konverzijama baza podataka, znaće o čemu pričam.

---

Getsbi je lepo odgovorio. Evo i mog dodatka:

Da li je onda projektovanje baza podataka:

a) Inženjerska disciplina
b) Umetnost
c) Crna magija
d) Sve ovo zajedno
e) Ništa od gore navedenog...

???


a) Inženjerska disciplina
Nazalost nije. Ali je na putu da to postane, pre ili kasnije. Inzinjerske discipline zasnivaju se na matematice, fizici i hemiji recimo, ali idu dalje od naucnih principa. Iz fizike se uci na primer kosi hitac, i svesno se zanemaruje otpor vazduha, kao nebitan uticaj u principu. Medjutim, u praksi je otpor vazduha i te kako bitan, toliko bitan da mu se vise paznje poklanja nego samom principu, koji se prihvata skoro zdravo za gotovo. Inzenjerske prihvataju principe iz fizike, koji definisu STA se radi. Inzenjerske discipline principe ne dokazuju, to je uradila fizika. One ih nadgradjuju i odatle proizilaze pravila KAKO se nesto radi. Ako gradjevinskom inzinjeru date da sracuna sile i momente za neki nosac, on to moze uraditi graficki, rucno, pomocu šibera, digitronom, racunarskim programom i razultati ce uvek biti isti. Provera tacnostije uveki ista i jednostavno se radi bez ikakvih pomagala: suma svih sila i momenta u bilo kom preseku nosaca mora biti nula. Za to ne treba ni digitron, rucno sabiranje je savrseno moguce.

Projektovanje baza podataka postace inzenjerska disciplina kada budemo mogli da pogledamo u dijagram baze i da vidimo da li je dijagram "dobar", na nacin na koji proveravanmo da li je zbir sila i momenata nula u svim tackama na nosacu. Za to moramo da znamo "vanjske sile koje deluju na sistem". U bazama podataka vanjske sile su poslovna pravila i uslovi integriteta, kardinalnost i slicno. Vanjske uticaje daje nam dijagram biznis procesa. Odatle sledi dijagram baza podatka. Kad imamo gotov dijagram baze podataka, i poznajemo vanjske uticaje, onda mozemo recimo da proverimo da li je baza podataka normalizovana. Znaci, pravila normalizacije treba primeniti na kraju, kao proveru da li je baza dobro uradjena. I zaista, kad projektujemo bazu, smisljamo tabele i sta u koju ide i kako se one odnose jedna prema drugoj, mi vidimo da nesto treba razbiti na vise tabela. Niko ne kaze "Prvo cu sve da stavim u flat tabelu. Pa cu sad cu sve da dovedem na 1NF. Dobro, sad cu da 1NF prevedem u 2NF i tako dalje". Posle ovoliko godina mi jednostavno 'znamo' da se fakture stavljaju u jednu tabelu, artikli u drugu a da se stavke fakture stavljaju u trecu tabelu koja povezuje artikle i fakture.

Rekosmo kako dijagramu baze podataka prethodi dijagram biznis procesa. U gradjevinarstvu, postoji arhitektonski crtez (1). Sa njega inzenjer je u stanju da vidi staticke uticaje, pa sledi dijagram nosaca sa silama koje na njega deluju (2). Onda sledi proracun (3), pa provera proracuna (4). A onda dodje dimenzionisanje elemenatka konstrukcije grede, ploce , zidovi, temelji (5) i onda neko to sve napravi i dobijemo gotov proizvod - kucu, most, vodovod (6)
Vidimo 6 jasno definisanih koraka. Svaki korak je regulisan pravilima prakse, profesionalnom etikom i drzavnim zakonima. Zakon zahteva da se pre koraka (6), izgradnja, napravi revizija projektne dokumntacije. Nezavistan inzenjer proverava da li su projektanti (tim) odradili sve korake, da li je svaki korak odradjen u skladu sa pravilima struke i po zakonima. Tek onda se ide u izgradnju, koja se opet kontrolise - imate nadzorni organ na gradilistu. Svega toga u projektovanju baza podataka i izradi informacionog sistema nema. Ima nekih elemenata, ali jasan sistem ne postoji, niti zakonska regulativa. A ne daj boze da se ztrazi revisija projektne dokumentacije, da se pogleda dizajn baze ili dizajn programskiog koda pre nego sto se pristupi pisanju aplikacija i fizickom kreiranju baze. Inzenejri kad god otkriju nesto novo, neki postupak, materijal, brze bolje trce da to objave negde da i ostali vide i mozda nauce. Softverasi se ubise pokusavajuci da sakriju kod od drugih, sto je jako glupo, ali ne vredi govoriti onom ko ne zeli da slusa.

Zato projektovanje baza podataka nije inzenjerska disciplina i ljudi ne zele da to postane. Ali ce morati d apostane inzenjerska disciplina li ce jednostavno nestati kao profesija. ne mozete sebe proglasiti inzenjerom. Ali i te kako mozete sebe da proglasite programerom ili projektantom baza podatka.

b) Umetnost
Jeste donekle. Za umetnost je potreban talenat, za projektovanje baza podatka takodje. Svaka inzenjerija je umetnost.

c) Crna magija
Nekada se alhemija smatrala hemijom, posto hemija nije postojala. Ukoliko prihvatimo da jos uvek ne postoji hemija za baze podataka kao inzenjerska disciplina, odgovor je da, jeste po malo i magija, bela ili crna, jer trenutno nemamo nista bolje na raspolaganju.

d) Sve ovo zajedno
Ocigledno je da jeste sve ovo zajedno, ali ce se verovatno kroz vreme zastupljenost pojedinih komponenti promeniti u korist rigorozne inzinjerske discipline.

e) Ništa od gore navedenog...
Posto je projektovanje baza podataka sve gore navedeno, onda ocigledno ne moze biti "nista od ovoga navedenog"

???

Evo kako bi moglo sa dijagranma biznis procesa da se dodje do modela baze podataka:
1) Procitati akcije koje se vide na dijagramu poslovnog procesa. Primer: Kupac kupuje robu od prodavca.
2) Svaka imenica u jednoj ovakvoj recenici je potencijalni entitet, sto ce mozda postati tabela. Imenice u jednoj reenici su ocigledno povezane. Eto potencijalnog Foreign Key. Slede entiteti/tabele tblKupci, tblRoba, tblKupljenaRoba
3) Pored akcija, mogu se uociti i neki dokumenti koji postoje ili nastaju u procesu. Dokumenti su u stvari nacin zapisivanja akcija. Primer: Kupac kupuje robu od prodavca. nastaje dokumet Racun. Racun ima zaglavlje i stavke. Racun se izdaje kupcu. Sve osim poslednje recenice imamo pokriveno tabelama do sada. Dodajemo novu tabelu, Racuni kojoj je roditelj Kopci, a dete je KupljenaRoba, koju mozemo preimenovati u StavkeRacuna

Znaci, (dijagram poslovnog procesa) => (recenice koje opisuju proces, dokumenti u procesu) => entiteti

Kad smo definisali nekoliko kljucnih entiteta, onda im dodamo atrinute, koji opet dolaze sa dijagrama procesa i/ili dokumenata.

4) Onda pogledamo da li trenutni raspored entiteta i njihovih veza dovodi do anomalija prilikom INSERT/UPDATE/DELETE operacija (Ovo se cesto predaje kao uvod u normalizaciju)
5) Pokusamo da otklonimo uocene anomalije pravljenjem novog rasporeda entiteta i atributa

6) Kad msilimo da imamo dobar raspored entiteta i atributa, proverimo da li trenutni model zadovoljava uslove normalnih formi, recimo do trece. Pravila prakse bi trebalo da definisu do kog stepena normalizaciej (do koje forme) treba ici u kom slucaju, kao i minimum. Na primer 3NF je minimum, a ako se uvodi vremenska komponenta u igru onda mora biti zadovoljena 5NF.

Ako bismo objavljivali radove i objasnjavali kako je sta uradjeno, ubrzo bismo naucili sta je najbolje raditi kad se projektuje IS za bakalnicu, a sta radi dobro kad se projektuje IS za autobusku stanicu ili aero saobracaj. Ili distribucija gasa, vode, struje. Ili sta je najbolje raditi kada se projektuje IS za skole ili lekarske ordinacije.

E tada cemo psotati inzenjerska disciplina.

Mislim da je projektovanje baza (ipak) inženjerska disciplina. To malo udara na našu bazadžijsku sujetu, ali je tako. Da je umetnost, izučavalo bi se na nekoj od umetničkih akademija. Baza ima sasvim praktičnu namenu i nije joj svrha neko izazivanje emocija (mada znam za neke korisnike koji prema svojim bazama gaje određene emocije :-) ). Kada kažem "inženjerska disciplina" mislim na sledeće: Za zadati skup problema (projektni zadak) do rešenja (projekta) se dolazi primenom izabrane metodologije (skupa pravila koji, kada se primene na uslove iz projektnog zadatka, sigurno dovode do rešenja). Mislim da su prednosti ovog pristupa očigledne i da ne zahtevaju detaljniju elaboraciju.

P.S.
Da li ona dva ranije pomenuta dijagrama imaju još neke funkcije osim dokumentovanja?

Dobro, neka je inzinjerska disciplina. To je najblize pameti.

Kako kome. Ja bez njih ne mogu da uradim nista vljano. Nije da nisam probao :)

Kad se kuća završi, onda zaista arhitektonski crteži i statički proračuni ne služe ničemu više osim za post projektnu dokumentaciju. Ali do tog momenta to je dokumentacija na osnovu koje se objekat gradi. Tako i ovo. Kad je sistem završen, nikoga više nije briga za dijagrame i šeme. Za razliku od građevinskih objekata, IT sitemi nikada nisu završeni, tako da dijagrami s vremena na vreme pritrebaju.

Lično još nisam spreman da prihvatim da je projektovanje baza podataka inženjerska disciplina. Trebalo bi da bude, ali nisu se još uvek stekli uslovi.

:-)

Može li mi neko dati link koji već dva sata tražim na forumu gde ima opis dijagrama za poslovanje za modeliranje IS-a. Našao sam dva puta i sad treći kad mi treba ne mogu da ga nadjem. U pitanju su početni dijagrami nulte razine.

Kao što sam rekao da ću pisati tutorijal za informacione sisteme pa evo nešto o metodi IDEF0 takozvanoj Funkcionalno modeliranje IDEF0.

– omogućuje sistematičnu analizu posla tj. za svaku poslovnu funkciju se obezbeđuje kontrola ispravnosti, planiraju se potrebni resursi potrebni da se funkcija realizuje, ulazi u poslovnu funkciju, kao i izlazi koji se na osnovu ulaza generišu.

– IDEF0 je tehnika modeliranja aktivnosti bazirana na kombinaciji grafike i teksta koji su predstavljeni na organizovan i sistematičan način da bi se povećala razumljivost, koja podržava analizu, obezbeđuje logiku za potencijalne izmjene, specifira zahtjeve, ili podržava analizu sistema po nivoima i integriše aktivnosti.

IDEF0 model se sastoji od hijerarhijskog niza dijagrama koji postepeno prikazuju sve više detalja o funkcijama i njihovoj međuvezi ( interface ) sa ostalim dijelovima sistema. IDEF0 ili workflow modeliranje omogućuje analizu osobina određenog poslovnog procesa sa ciljem njegovog maksimalnog unapređenja.

Postoje tri vrste dijagrama:

o grafički
o tekstualni
o rečnik ( glossary)

IDEF0 omogućuje:

• izvršenje sistema analize i dizajna na svim nivoima, za sistem sastavljen od ljudi, mašina, materijala, računara i informacija;
• stvaranje dokumentacije paralelno sa razvojem sistema koja služi kao osnova za integraciju novih sistema ili za unapređenje postojaćih sistema
• bolju komunikaciju između analitičara, dizajnera, korisnika i menadžera
• omogućuje diskusije u radnom timu da bi se postiglo međusobno razumijevanje
• omogućuje upravljanje velikim i složenim projektima
• obezbeđuje elemente potrebne za modeliranje podataka


Za početak je mislim sasvim dovoljno pa će nastavak biti sutra :)

Jel našao neko link onaj što sam tražio? još uvek ne mogu da ga nađem?

Ne znam o kojem linku se radi. Jel' o ovom ?
http://www.databaseanswers.org/data_models/

---

E tooooooooooooo hvala puno

Stoji ti na prvoj strani ove teme već dve nedelje. :-)

---

Ja kontam sve nije na ovoj temi pa nije negde sam drugdje našao uffff hvala brate :)

ima i u jednoj TOP temi takodje

---

Ima firma koja je uradila softver za apoteku, i ljudi koji su ga radili proveli su dve godine u apoteci da bi se upoznali sa poslom da bi mogli da urade program koji moze da zadovolji potrebe apotekara. Konkretno koristim taj program i nije ni malo naivno tako nesto napraviti. Zato razmisli jos jednom o toj ideji.

2 godine u apoteci da bi napravili program?
to mogu da razumem ako su (apsolutni) pocetnici u projektovanju

za 2 godine firma predje na ERP u celosti (kako koja i u zavosnosti od novca i korisnika, al' moze da se predje u potpunosti za 2 godine)

---

Dve godine? Možda je neki od projektanata/programera besplatno lečio čir na želucu. :-)
Šalim se naravno. Dužina uglavnom zavisi od kvaliteta tima. Brojnost članova, specijalnosti, iskustvo, dobar odabir i poznavanje alata za projektovanje i RDBMS-a, korišćenje metode intervjua, prikupljanje dokumenta.......
Ako sve ovo učite iz početka, onda vam je i dve godine malo.

---

Cekaj, cekaj
Nisu oni pravili program 2 godine, vec su proveli dve godine u apoteci da bi skontali sta treba da naprave :-D
Za to vreme su, valjda, da bi preziveli, radili kao apotekari, a hranu su im donosile zene i devojke :-D

To se zove extreme programming :-D

---

Mozda taj program zna sam da vodi apoteku, da da uputstva za pravljenje koje pomade ili nekog leka, zatrazi kupcu recept, kaze na koliko se pije lek i u kojim dozama:-)