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?

Niestety nie mógłbym sprawdzić Twojego diagramu ERD odnosząc się do PW.
Natomiast zdecydowanie mogłabym to zrobić

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
Natomiast bez poprawek trudno podpowiedzieć coś jeszcze.

Poprawiłem na razie połączenia i relacje według twoich wytycznych, co byś jeszcze dodała? ( pomińmy na razie kwestie typu danych w atrybutach ):

Dwa razy udało mi się zamknąć zakładkę przed dodaniem odpowiedzi. Coś chyba nie chce żebym odpowiedziała

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.

A ty w skrócie jakbyś zrobiła model związków encji dla serwisu komputerowego? Bo ja już się trochę zakręciłem i mój wydaje się bez sensu.. Chodzi o taki w miarę prosty, nie złożony..