Model podataka za evidenciju i dodelu radnih zadataka zaposlenima [Task assignment]

Dakle u pitanju je pojednostavljeni problem dodele radnih zadataka zaposlenima.

Potrebno je omoguciti rukovodiocu(administratoru) da dodeljuje radne zadatke zaposlenima. Pri tom, na jednom radnom zadatku moze raditi vise zaposlenih (i obrnuto). Takodje, potrebno je omoguciti da zaposleni ostavljaju komentare o radnom zadatku za koji su zaduzeni(svaki radnik moze da ostavi vise komentara).

Moja ideja je bila jednostavna: uvesti cetiri entiteta Radnik, Zadatak, Zaduzenje i Komentar kao slab entitet, pri cemu je Zaduzenje 'agregacija' tj. mesoviti tip objekat-veza izmedju Radnika i Zadatka.

Medjutim, nedoumica je u vezi komentara. Prvo sam ga posmatrao kao viseznacan atribut agregacije Zaduzenje. Shodno tome, prvo resenje je bilo realizovati ga kao slab entitet agregiranog objekta Zaduzenje. Drugi rezon je bio da se Komentar izdvoji u zaseban entitet. Malo sam u problemu oko toga. Sa druge strane, mozda je i model inicijalno lose postavljen.

Molio bih vas za bilo kakvu sugestiju ili ideju

Rečenica:, nije baš najjasnija.

Ako (svaki radnik moze da ostavi vise komentara za svaki zadatak),
onda definitivno treba novi entitet. Od toga da li će veza biti identifikujuća, 001.jpg ili neidentifikujuća-obavezna (No Nulls),002.jpg, zavisiće način realizacije na aplikativnom nivou.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

^Pre svega, hvala Vam na odgovoru.

Pa da... Ta ideja oko 'komentara' sama po sebi nije bas najjasnija... Ja sam to nazvao komentarima, a sustina je da se obezbedi neki transparentan vid kolaboracije izmedju zaposlenih koji rade na zadatku.

Dakle, kada zaposleni dobiju zaduzenje i krenu da rade na odredjenom zadatku, sistem treba da im omoguci (pored chat-a) da asinhrono razmenjuju poruke prilikom saradnje. Pri tom, te poruke treba da budu transparentne (vidljive rukovodiocu). To me je podsetilo na koncept komentara na blogu i sl. pa sam ih zato tako nazvao. Svrha toga je da se napravi kao 'mini forum', gde bi topic bio radni zadatak, a zaposleni bi razmenjivali post-ove u svrhu resavanja zahteva koje namece zadatak.

Prosirio sam model koji je predlozio @Getsbi sa definicijom Rukovodilac i azuriranjem ko je Komentarisao.
Varijanta 001 je po meni bolja.

Potpis

http://zoraneremija.wix.com/eremijacv

Nemojte komentar vezivati za zaduženje, jer ako je neki radnik samo privremeno angažovan na nekom zadatku, posle njegovog angažmana (brisanje reda iz tabele zaduženje) izbrisaćete i sve komentare.

Zato ili:

1. Komentar direktno vežite na zadatak.
2. Napravite veznu tabelu između komentara i zadatka, jer ako unutar zadatka uvedete novi entitet npr. attachment, koji takođe može da se komentariše, trebate napraviti jasnu razliku koji komentar pripada kom entitetu.

Potpis

gramatika srpskog jezika
testovi iz srpskog jezika
jezičke nedoumice

Ne vidim razlog zašto bi neko ko je privremeno bio angažovan na zadatku bio obrisan. Ako je ostavio komentar, znači da je ostavio traga na zadatku i ne treba ga brisati. Ako je greškom unesen, onda je sasvim svejedno. Ovde je entitet Zaduženje postavljen kao projektni zato što nije dorađen. Inače je predpostavka da će imati atribute PočetakAngažovanja i KrajAngažovanja i time postati asocijativni.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Sjajno. Hvala svima, zaista.

Zoranov model deluje kao veoma dobro resenje...

Samo bih Vas zamolio za jos jednu pomoc.

Sobzirom da ce se prezistencija u aplikaciji realizovati koriscenjem Hibernate ORM(Object/Relational mapping) alata, malo me plasi da ne ukomplikujem sebi zivot sa slozenim kljucevima i njihovim spustanjem u ostale tabele. Hibernate ne preporucuje upotrebu i realizaciju many-to-many veza kao projektnih (link table) entiteta. Umesto toga, pretpostavljaju da ce taj entitet postati asocijativan (da ce imati neki atribut) pa sugerisu da se on realizuje kao zaseban entitet (sa svojim id-jem) sa many-to-one vezama ka, u ovom slucaju, Radniku i Zadatku. Da li bi ovakva fizicka realizacija pokvarila nas model u smislu ponistavanja nekih strukturnih ogranicenja?

Takodje zamolio bih Zorana, ako moze, da pojasni motiv za vezu izmedju Radnika i Komentara? Verovatno zbog neiskustva, deluje mi kao dupliranje 'veze', sobzirom da je Komentar vec posredno vezan za Radnika preko Zaduzenja. Da li je razlog razlicita semantika relacija Radnik -> Zaduzenje i Radnik -> Komentar, jednostavnije baratanje sa upitima u kasnijoj fazi ili...?

Izvinite na opsirnosti.

Relacija ili veza vise-vise je jedna od najslozenijih veza za realizaciju posle veze generalizacije-specijalizacije, tako da Vas razumem opravdano za bojazan.

Primer koji sam Vam predlozio nije uzimao u obzir odgovore na sledeca pitanja:

1. Da li jedan Radnik kroz vreme moze da ima vise puta isti zadatak.
2. Smisao zadatka, da li je to u pitanju neka operacija tj radnja ili je malo slozeniji postupak ili proces.

Moze se ta veza i drugacije fizicki definisati, recimo uvodjenjem atributa koji bi bio kljuc ZaduzenjeID, a ova druga dva RadnikID i ZadatakID, da budu slobodna, s time da moraju biti Not Null i mora se kodiranjem spreciti da se ta kombinacija ne ponovi ako je priroda stvari takva da se ne sme ponoviti, a ako nije onda se sve drugacije mora postaviti. Zato bi dalja analiza problema bila kvalitetnija ako bismo znali odgovore na ova 2 pitanja.

Na drugo Vase pitanje vezu izmedju Radnika i Komentara sam dodao imajuci u vidu situaciju da jedan Radnik moze biti zaduzen zadatkom a da drugi radnik ili vise njih komentarise znaci u entitetu Komentar u atribut RadnikID ide onaj RadnikID koji je zaduzen zadatkom ZadatakID, a u atributu KomentarisaoID ide onaj RadnikID koji je komentarisao. Znaci odgovor razlicita semantika nije u pitanju vec priroda stvari.

Potpis

http://zoraneremija.wix.com/eremijacv

^
Hvala Vam Zorane na trudu.

Sistem je prilicno jednostavno zamisljen, nije za neku komercijalnu upotrebu, vise je za interne potrebe tako da je sam domen u mnogome pojednostavljen.

Ukratko, zaduzenja su jednokratna i nema potrebe da se Radnik ponovo 'vraca' na neki Zadatak. Eventualno ce se produziti vreme njegovog angazovanja i to je to. Zadatak nije slozen postupak ili proces, odnosno moze biti ali je u kontekstu sistema bitan samo njegov verbalan opis.

Takodje, Vas model je pretpostavio logicnu stvar koja u prvi mah nije bila zamisao. Zamisao je bila da odredjeni zadatak komentarisu samo Radnici koji na njemu rade, sto bi jos vise uprostilo model.

U slucaju da treba da dozvolimo da komentare ostavljaju i radnici koji nisu angazovani na zadatku, da li bi u tom slucaju mozda bila bolja opcija da se Komentar realizuje kao slab Objekat Zadatka (kao sto je Dejan izneo) i da se uspostavi neobavezna, jedan-prema-vise veza od Radnika ka Zadatku, sto bi sprecilo spustanje slozenog kljuca u Komentare? Nekako mi egzistencijalna zavisnost Komentara od Zaduzenja ima smisla samo ukoliko treba omoguciti da Radnik ostavlja Komentare samo na Zadacima na kojima je angazovan, a u tom slucaju bi veza od Radnika ka Komentarima bila suvisna. Da li se slazete?

Posto ste objasnili granicu Vaseg sistema onda je i kolega @Dejan u pravu i mislim da ce Vam sledeci model sasvim odgovarati

Potpis

http://zoraneremija.wix.com/eremijacv

To bi bilo to... Sasvim dovoljno informacija

Hvala Zorane. Hvala svima.

Samo u slučaju kada nije potrebno da se prati ko je i kada bio angažovan na nekom zadatku (PočetakAngažovanja i KrajAngažovanja).
Onda bi sasvim korektno bilo da se izbriše red iz tabele Zaduženje ali bi tada onaj ko nastavlja njegov rad trebao da vidi sve komentare svojih prethodnika.
U svim drugim slučajevima podržavam rešenje koje je priloženo u dijagramu.

Da li postoji neki poseban razlog zašto Komentar ima trostruki primarni ključ?
Zašto to nije samo KomentarID, a da su RadnikID i KomentarID ostali kao FK?
Zanima me zbog auto increment opcije.

Potpis

gramatika srpskog jezika
testovi iz srpskog jezika
jezičke nedoumice

Hm.. Sada ste me podsetili Dejane, izleda da sam prevideo neke stvari... Izvinjavam se na maloj konfuziji.

Trebalo bi omoguciti evidenciju koji su Radnici radili na izvrsenju nekog Zadatka.

Preciznije, Radnik ce biti angazovan na Zadatku koji ce imati predefinisani rok. Dakle, ideja je bila da Radnik radi na Zadatku do njegovog izvrsenja, tako da bi period angazovanja bio u stvari period ili rok za izvrsenje Zadatka sto bi verovatno znacilo da ce Zaduzenje biti projektni entitet. Pri tom, pored Radnika koji rade na neposrednom izvrsenju Zadatka, u kolaboraciji(razmeni komentara) bi mogli da ucestvuju i radnici koji nisu direktno angazovani na tom Zadatku.

Kada sam ponovo pogledao model cini mi se da ne izlazi bas u susret zahtevu za evidencijom Radnika koji su radili na nekom Zadatku tj. nema vise-prema-vise veze izmedju Radnika i Zadatka. Da li bi to znacilo da se samo vrati Zaduzenje u model kao projektni objekat(sobzirom na to da bi Zadatak imao atribute npr. datumPocetka, datumZavrsetka)?

Jos jednom oprostite na konfuziji.

Prvo sto se tice "Konfuzije"! Nebrojeno puta sam sanjao problem kojii sam zeleo da izmodeliram. Kada dodjete u tu fazu to znaci da ozbiljno razmisljate o problemu. Kako rece Sojic "Pusti sada konfuziju" :-)



Iz ove Vase konstatacije dobija se prosireni odgovor na 2. moje pitanje i ukazuje da je ipak atribut OpisZadatka ima vecu znacajnost i namece stvarnu realnu potrebu da se izdvoji kao poseban objekat od intresa posmatranja. Tako da prethodni model dobija vecu znacajnost i zasigurno bolje resenje.



Osnovni razlog primene kaskadnog prenosenja kljuceva bio je s aspekta fizickog modela podataka i moje pretpostavke da je u pitanju primena relacionog modela. Ako je ova pretpostavka zadovoljena onda ovakav oblik veze je jednostavan i kontrole nad tom vezom regulise relacioni model. Drugi razlog tome je ista pretpostavka i pogled s strane definisanja jednostavnijih upita nad modelom. Moze i vase resenje ali ako je realicioni model u pitanju ovo koje sam predlozio je bolje.

Inace Auto Increment opcija se razlicito ponasa u zavisnosti od relacionog modela. Na primer MS Access kreira na dogadjaj BeforeInsert, a SQL Server na After Insert.

Potpis

http://zoraneremija.wix.com/eremijacv

^
Hvala Zorane na odgovorima. Uvek nesebicno pomognete.

Sto se tice konfuzije, nije ona rezultat moje neozbiljnosti vec verovatno loseg razumevanja modela, sto je pretpostavljam rezultat veoma skromnog iskustva u oblasti modelovanja.

Dakle od pocetka je postojala potreba da se Zadaci dodeljuju odredjenim Radnicima i da samo Radnici koji rade na nekom Zadatku imaju mogucnost da ostavljaju Komentare na Zadatku. Vas predlog je bio na mestu, pa smo tu prvobitnu ideju promenili i omogucili smo da Komentare moze da ostavi svaki Radnik (KomentarisaoID). I ok, imamo evidenciju o tome ko je komentarisao Zadatak.

Medjutim i dalje je ostala potreba da se zna koji su Radnici radili na izvrsenju nekog Zadatka, a ne samo ucestvovali u kolaboraciji. Dakle, u kolaboraciji (razmeni poruka) mogu da ucestvuju svi ali Zadatak izvrsavaju samo oni Radnici kojima je Zadatak dodeljen i samo je to potrebno evidentirati, bez detalja koji je Radnik sta radio na Zadatku.

Kada ste postavili pitanje u vezi sa slozenoscu Zadatka, mislio sam da govorite o nekoj njegovoj strukturi npr. o pojedinacnim aktivnostima koje sacinjavaju zadatak, pa bi iz toga izlazilo da se Radniku dodeli konkretna aktivnost na izvrsenje. Nema potrebe za tim. Kao sto sam ranije napisao, problem je prilicno pojednostavljen tako da je verbalni opis Zadatka, datum pocetka i datum zavrsetka jedino sto je bitno za Zadatak.

Interesuje me koja je mana modela na slici? Kao sto sam ranije napisao, u realizaciji baze ce se koristiti relaciona baza, ali u aplikaciji ce se za perzistentni sloj koristiti objektno relaciono mapiranje sto moze malo da oteza situacije sa spustanjem slozenih kljuceva


_{[Ovu poruku je menjao slomir dana 07.06.2010. u 14:10 GMT+1]}

Model koji ste dali u potpunosti moze da podrzi Vase zahteve, kao i model koji sam u prvoj verziji predlozio.

Uocili ste razliku potpuno. Problem je u pristupu. Vas pristup ima posledicu objektnog modeliranja i verovatno realizaciju objektnim alatima s jedne strane, a sa druge strane podaci ce se nalaziti u relacionom modelu. Jedan i drugi nisu 100% kompatibilni i slazem se da cete imati problema sa modelom koji sam Vam predlozio, jer odrzavanje prenesenih kljuceva iziskuje da programirate. Ako je zelja da se izradi aplikacija na takav nacin onda je bolji model koji ste ovde prilozili, malo je laksi u odnosu na model koji sam predlozio, a ako za realizaciju koristite neki relacioni model (MS Access) onda je model koji sam Vam predlozio jednostavniji iz sledecih razloga.

1. Apliciranje radi obuhvata podataka je jednostavnije jer se prenosenje kljuceva prepusta relacionom modelu.
2. Mozete lakse aplicirati ko sta moze da radi
3. Izvestavanje se svodi na postavljanje relativno jednostavnih upita
4. Vreme realizacije je neuporedivo krace

Na Vama je da odlucite.

Potpis

http://zoraneremija.wix.com/eremijacv

Sta da Vam napisem Zorane... Zaista dajete strpljive, precizne i kvalitetne odgovore iz kojih moze mnogo da se nauci. Veliko Vam hvala na tome.

Mislim da sada ima sasvim dovoljno informacija i objasnjenja za odluku. Verovatno cu jos malo razmotriti alternative pa odluciti.

Jos jedno veliko hvala svima.

Licno ja bih problem resavao u relacionom modelu (MS Access), jer sve ostalo je ubijanje vola za kilo mesa.

Potpis

http://zoraneremija.wix.com/eremijacv