Model związków encji - sprawdzenie Opcje

[dexter22]

Temat: Serwis komputerowy

1. Klient zglasza problem panu w recepcji
2. Pan w recepcji otwiera zlecenie z opisem problemu
3. Zlecenie jest przekazywane do planisty, który szuka najblizszego wolnego pracownika i przypisuje mu dane zlecenie, uprzednio zamawiając bądź pobierając część z magazynu
4. Pracownik zmienia swój status na " w toku "
5. Pracownik kończy swoje zlecenie i przechodzi w stan "zakończony"
6. Zostaje drukowany paragon
7. Sprzęt wraca do klienta

Co byście do tego dodali, według tego co napisałem?

(IMG:http://img190.imageshack.us/img190/2622/serwiskomputerowy.png)

[Shili]

Dwa razy udało mi się zamknąć zakładkę przed dodaniem odpowiedzi. Coś chyba nie chce żebym odpowiedziała (IMG:style_emoticons/default/wink.gif)

1) Harmonogram na pierwszy rzut oka bardziej pasuje do zlecenia - jest charakterystyką zlecenia, nie planisty; jak zmieni się planista harmonogram powinien pozostać

2) Magazyn i hurtownia moim zdaniem powinny być połączone z tabelą np. zamówienie, a dopiero ta tabela z planistą (jakoś tak bardziej logicznie moim zdaniem)

3) Pracownik -> Planista -> Zlecenie has planista -> Zlecenie -> Pracownik
Diagram ma cykl. Robi to między innymi redundancję danych - Pracownik Pesel jest w dwóch tabelach, które i tak są ze sobą połączone.

Tutaj pewnie zależy od podejścia - pracownika można by dodać do zlecenie_has_planista albo do harmonogramu.

Druga kwestia z pracownikiem: a co jak pracownik złamie Nogę?
Update na trzech tabelach bazy danych i strata historii realizacji zamówienia?
Zrobiłabym pracownika podobnie do recepcjonisty i planisty.

Swoją drogą wygląda mi to na projekt na studia, a wtedy podejście zależy bardzo od prowadzącego zajęcia - w razie czego warto to mieć również na uwadze, jeśli dobrze zgadłam.