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]

Niestety nie mógłbym sprawdzić Twojego diagramu ERD odnosząc się do PW.
Natomiast zdecydowanie mogłabym to zrobić (IMG:style_emoticons/default/smile.gif)

Z bardziej rozbudowanymi ERD od jakiegoś czasu nie miałam do czynienia, także w razie czego chętnie podyskutuję nad przyjętymi przez Ciebie rozwiązaniami.

1) Pesele nie powinny być kluczami.
Powód jest prosty - zdarza się (serio!) że dwie osoby mają taki sam pesel.
Poza tym pesel nie mieści się w int, który jest najlepszym kluczem.
Przerób wszystkie klucze typu pesel na zwykłe np. autoincrement ID. Będzie bezpieczniej.

2) NIP ma 10 znaków i maksymalnie 3 minusy (maksymalnie, bo są dwa rodzaje nipów, teraz pewnie sobie nie przypomnę który co i jak). Nie ma sensu ograniczanie go do 40.

3) Daty utworzenia i realizacji przechowuj jako typ "Datowy"; timestamp, datetime, coś w tym kierunku
Da Ci to możliwość operowania na datach bez zaprzęgania dodatkowych funkcji po stronie oprogramowania.
Dotyczy to wszystkich dat.

4) Czemu Klient ma powiązanie z Recepcjonistą?
Raczej Kient powinien mieć powiązanie z Opisem problemu (Zlecenie zapewne) i z drugiej strony Recepcjonista również powinien mieć powiązanie z tym Opisem. Oczywiście powiązanie z Planistą nadal istnieje.

Btw, co się zdarzy, jak Planista lub Recepcjonista zostaną zwolnieni, albo Planista będzie miał wypadek z powodu przygniecenia towarem i nie da rady go zfinalizować?
Będziesz robił update bazy? Nowy będzie działał na starym ID?
Widzę tu raczej związek wiele do wiele ze zleceniem.

Pracownik ma zmieniać status na "W toku". Natomiast nie jest powiązany w żaden sposób ze zleceniem, które ma status "W toku".
To samo z zakończonym.

Btw, nie wiem jak ma być to funkcjonalne.
Pracownika, Recepcjonistę i Planistę zebrałabym w IS_A, jeśli orientujesz się mniej więcej co to jest.
Finalnie w programowaniu i tak wyjdą Ci trzy bazy, natomiast moim zdaniem jest tak czytelniej.

Nie rozumiem czemu w harmonogramie są produkty? To raczej kwestia magazynowa i hurtownicza.
Harmonogram widziałabym bardziej związany ze zleceniem. W końcu jak zmieni się planista, to harmonogram nadal jest w "toku".

Części z magazynu i hurtowni podobnie - również ma to związek z możliwą zmianą planisty.

Zapewne nie jest to wszystko.
Mam jednak nadzieję, że kilka z tych uwag pomoże poprawić Ci diagram (IMG:style_emoticons/default/smile.gif)
Natomiast bez poprawek trudno podpowiedzieć coś jeszcze.