Diagram ERD

Witam,
muszę zaprojektować diagram ERD dla bazy danych pewnej przychodni. Ogólnie planuje, aby finalny projekt był serwisem internetowym opartym właśnie o tą bazę. Wymyśliłem sobie to tak, że adminem jest jakiś kierownik obiektu, który powinien dodawać nowych pracowników do bazy. Dodatkowo mamy lekarzy, pacjentów. Chce żeby pacjent mógł zalogować się do serwisu i zarejestrować na wizytę oraz podejrzeć swoją kartę szczepień itd. Lekarz natomiast po zalogowaniu może wyświetlić dane umówionego pacjenta, kartę szczepień/choroby, wypisać receptę etc.

Dopiero zacząłem to projektować i zastanawia mnie czy dobrze połączyłem tabelę "Użytkownicy" z "Pacjenci", "Lekarze" i "Kierownik Obiektu". Czy w tabelach "Pacjenci", "Lekarze" muszę podawać "id", czy wystarczy to wygenerowane przez MySQL Workbench, tak jak to zrobiłem dla kierownika ? Czy kierownik powinien być jeszcze z czymś połączony jakąś relacją ?
Link do diagramu : https://zapodaj.net/560ef8f86ed5b.png.html

Jak na moje to osobna tabela dla kierownika jest po prostu niepotrzebną redundancją danych. Wystarczy że w roli będzie miał kierownik i tyle.
Czy user może mieć tylko jedną rolę? Jak się na to zapatrujesz? Mi się wydaje że role to zapis, odczyt, podgląd, ale mogę się mylić, zależy jak Ty to widzisz.
Z Twojego opisu wynika że Lekarz jest userem przemyśl czy ta tabelka osobna ma sens i co byś w niej trzymał, ja proponuję trzymać dyżury i w tabelce pośredniej poszczególne dyżury.
Ja bym dodała tabelkę pośrednią która łączy wizytę z userem i pacjentem.
ID zawsze powinno być, dla porządku.

Zakładam, że każdy "user" będzie miał tylko jedną rolę. Z tym, że źle się określiłem, bo to nie powinna być rola, tylko raczej stanowisko :)
Z tymi dyżurami to fajny pomysł, myślę że zrobię tak jak piszesz.

Dzięki za cenne wskazówki :)

Myślę, że uprawnienia powinny być bardziej skomplikowane, oprócz ról powinna być też mniejsza granulacja - uprawnienia. Np. Możesz mieć role: Administrator, a uprawnienia CREATE_USER, CREATE_REPORT, CREATE_EMPLOYEE (niekoniecznie ta sama osoba będzie to wykonywała, jedno będzie robiła pani z recepcji, drugie pani z sekretariatu może?).

Rozróżniasz w systemie trzy role, lekarz, pacjent, kierownik, a gdzie reszta zespołu? Gdzie pielęgniarki, panie z recepcji, administracyjna obsługa przychodni, itd? Czy oni nie będą mieli dostępu do systemu?
W jaki sposób będziesz dodawał pacjentów do systemu? Będą się sami dodawać przez jakiś interfejs? Ktoś będzie ich dodawał?

Może łatwiej Ci będzie jak będziesz sobie opisywał funkcjonalności a później do nich dodawał bazę?
Np WIZYTA:

• na wizycie musi być pacjent
• musi być lekarz
• może być też pielęgniarka do pomocy
• wizyta musi się odbyć w określonym gabinecie
• wizyta musi się odbyć o określonej godzinie, w określonym dniu
• ...
  W trakcie wizyty lekarz może:
• pobrać wyniki badań z laboratorium
• przeglądać historię choroby pacjenta
• zlecić badania laboratoryjne, rtg i inne
• wystawić receptę
• ...
  Po wizycie
• lekarz musi uzupełnić opis wizyty
• lekarz musi uzupełnić historię choroby pacjenta
• ...

Nie podałeś pełnego opisu i wszystkich funkcjonalności, więc ciężko zgadywać, jak powinna wyglądać baza.

Nie podałem pełnego opisu, bo chciałem nakreślić tylko powierzchownie o co mi chodzi i rozwiać pierwsze napotkane wątpliwości. Na początek, mój projekt będzie trochę ubogi, gdyż robię coś takiego pierwszy raz, ale w miarę rozumienia kolejnych aspektów, będę dodawał bardziej skomplikowane rzeczy :)

Założenia :

• Kierownik obiektu - dodaje pracowników do bazy (lekarzy, pracowników recepcji, pielęgniarki)
• Pracownicy recepcji - wpisują do bazy pacjentów, którzy przyszli osobiście do przychodni (zakładają im konto w serwisie, jednocześnie wpisując do terminarza wizyt)
• Pacjenci - mogą umówić się na wizytę poprzez serwis online, obejrzeć kartę szczepień, kartę choroby
• Lekarze - wyświetlają dane pacjenta, kartę szczepień, kartę choroby, wystawiają receptę online
• Pielęgniarka - uzupełnia kartę szczepień pacjenta

Udało mi się zrobić coś takiego: https://zapodaj.net/b95a41927607f.png.html

Lekarze sami sobie uzupełniają dyżury tak samo pielęgniarki,chyba raczej jest to w obowiązkach kogoś kto uzupełnia grafik, prawdopodobnie jedna z pielęgniarek, albo asystent kierownika przychodni?
Karty szczepień są uzupełniane zarówno przez lekarzy jak i pielęgniarki, a do tego są częścią dokumentacji medycznej, ale tego mogłeś nie wiedzieć.
Karty chorób muszą być edytowalne przez lekarzy.
Recepty też muszą być w relacji z kartą pacjenta, dlatego że wyobraź sobie sytuację, przychodzi pacjent i twierdzi że ma jakieś objawy, dostaje receptę która jest drukiem ścisłego zarachowania i potem co? Szukasz recepty po pacjencie czy po wizycie?
PS nie wiem czy wiesz ale apteki nie składują wykorzystanych recept tylko odsyłają je do NFZ.
Tego też mogłeś nie wiedzieć ;)

Co do uprawnień.
Tak jak pisała @shagrin rozważ ile masz uprawnień, jeśli chcesz zrobić tak że każda pielęgniarka ma takie same uprawnienia to trochę źle. Dlaczego?
Dlatego że są pielęgniarki które np robią rezonans magnetyczny, druga robi EKG, trzecia robi np zastrzyki, czwarta robi badanie spirometrem i co z tego wynika? Ano to że nie każda pielęgniarka może zrobić każde badanie. Z reguły w przychodniach zadania są podzielone i część pielęgniarek przechodzi jedną część szkoleń, a inne pielęgniarki przechodzą inne szkolenia. Wbrew pozorom tych rzeczy jest całkiem sporo, oczywiście pobieranie materiału do badań, zastrzyki czy proste zabiegi chirurgiczne są wykonywane przez każdą z pielęgniarek, ale już nie każda może zrobić np badanie RTG.

Tak wiem że tego też większość pacjentów nie wie :)

Dzięki za cenne spostrzeżenia :-) Rzeczywiście o części z tych rzeczy nie wiedziałem :D

Czyli dyżury będzie uzupełniał Asystent Kierownika Obiektu.
A tak jak teraz zrobiłem to znaczy, że lekarz nie może edytować karty chorób pacjenta ?
No i rozwodzimy się nad uprawnieniami, tylko nie za bardzo wiem, jak te uprawnienia mam zaznaczyć w tym diagramie. Np. dla pielęgniarek. Powinienem je powiązać jakąś relacją z innymi tabelami np. (badanie EKG, RTG) ?

Jakoś nie pasuje mi ten diagram...
Czemu nie zrobisz tabeli Employee z wszystkimi pracownikami przychodni i do tego;
Tabeli Roles z rolami (przykładowe dane: SYSTEM_ADMINISTRATOR, ADMINISTRATOR, DOCTOR, NURSE, etc)
Tabeli Permissions (przykładowe dane: APPOINTMENT, USERS, MEDICAL_RECORDS, etc)
Tabeli Privileges (przykładowe dane: CREATE, UPDATE, READ, DELETE)
Tabeli User_Access, która będzie odwzorowaniem uprawnień pracowników: (np. employeeId: 1, roleId: 2, permissionsId: 3, privilegesId: 1)

Dalej terminarz wizyt: potrzebujesz tam tylko takie dane jak: data, godzina od, godzina do, id pacjenta, id lekarza, utworzone przez (id pracownika) data utworzenia, zatwierdzone przez (id pracownika), data zaakceptowania

Do tego dodałabym encję wizyta: id_użytkowników (załoga medyczna, lekarze, pielęgniarki biorący udział w wizycie), id użytkownika (pacjent), opis wizyty, zalecenia, data utworzenia wpisu, utworzone przez (id użytkownika), etc

Encja recepta: id użytkownika (pacjent), utworzone przez (id lekarza), data i godzina, edytowane przez (id lekarza), data i godzina edycji, treść recepty

Encja karta szczepień: data i godzina, opis szczepienia, id użytkownika (pacjenta), wykonane przez (id użytkownika lekarza / pielęgniarki)

Encja dyżury: data, godzina od, godzina do, id dyżuru i tabela pomiędzy: id dyżuru + id użytkownika

Jeśli chcesz robić dodatkowe kolumny dla lekarzy, wtedy łączysz ją z employee, to samo dla pielęgniarek. Jeśli jakiś pracownik edytuje kartę szczepień czy historię choroby, wtedy tylko dodajesz jego id. Po id możesz sprawdzić co to był za człowiek, lekarz czy pielęgniarka. Też nie widzę potrzeby rozbijania dyżurów na pielęgniarki i lekarzy, bo masz jedną tabelę z definicja dyżurów i dla jednych i dla drugich..

Moja propozycja poniżej. Od razu zaznaczam, że nie zam tematyki takiego gabinetu więc cześć rzeczy na logikę, część na podstawienie dyskusji.

A czy mogłoby być to zrobione w ten sposób ?

Najbardziej zależy mi na tym, aby relacje były dobre :D

Jak dla mnie to masz jakiś plan, który realizujesz. Dobrze byłoby abyś się nim podzielił jeśli oczekujesz pomocy.
Ja nie rozumiem idei:

1. vaccination cards, doctors vaccination cards, nursues vaccination cards - po co to jest rozbite i jaki jest cel? Czy tylko szczepienia robią w tym gabinecie?
2. disease cards, doctors disease cards - jak fizycznie to ma być tj. przy każdej wizycie lekarz zakładka kartę choroby dla danej choroby? czy jest po jednej karcie szczepień i karcie choroby? Skąd będzie wiadomo jaka pacjent ma chorobę (za każdym razem czytać opisy, kwestia ich jakości itp.)?
3. pesel nie jest najlepszym identyfikatorem
4. employess - po co?

Proponuje najpierw dowiedzieć się jak to obecnie wygląda, jakie są potrzeby co do zmian w związku z nowym systemem i wtedy zamodelowac procesy biznesowe i aktorów. Na tej podstawie funkcjonalności w systemie i dopiero wtedy można myśleć o projektowaniu bazy danych. Ale ja się nie znam.

1. Pomiędzy doktorami i kartami szczepień występuje relacja wiele do wielu, tak samo pomiędzy pielęgniarkami i kartami szczepień, dlatego stosuje tablę łącznikową żeby się jej pozbyć, po to to jest.
2. Każdy pacjent ma jedną kartę szczepień i kartę choroby. Tutaj rzeczywiście, nie przemyślałem tego, powinny być jeszcze dodatkowe encje, reprezentujące jakby "stronę w karcie szczepień/choroby".
3. Może i nie jest, ale jest unikalny i jakoś tak mnie naszło żeby go użyć.
4. Employees są po to, żeby nie robić osobnej encji dla każdego pracownika w przychodni. Myślę jednak, że mógłbym to pominąć i zrobić wszystko bezpośrednio z users ?

Większość rzeczy, co i jak zostało opisane powyżej. Najbardziej zależy mi, aby relacje były dobrze dobrane i miało to ręce i nogi. Wiem, że w przychodniach nie robi się tylko szczepień, jednak na tą chwilę, potrzebuję tylko szczepień, żeby pokazać o co mi chodzi, a jak to będzie OK, to nie będzie problemu rozszerzyć usług.

Ad1. Wystarczy z tablicy użytkownicy po roli przypisać szczepienie, a dokładniej usługę.

Ad2. Nie encje, a atrybuty encji. Po co Ci encja na każdą usługę. Robisz encje dla usług z atrybutami.

Ad3. Pesel nie jest unikalny i nadaje id.

Ad4. Dokładnie masz tablicę użytkownicy.

Pomyśl od razu o encji usługi bo to da elastyczność tj. kolejna usługa to dodanie do słownika, a nie przeprojektowanie bazy danych oraz systemu. Jasne, że nie musisz od razu robić wszystkiego ale projektów myśląc o przyszłości.

A co byś teraz powiedział ?

Nadal nie rozumiem czemu budujesz encje dla poszczególnych usług tj szczepienia, choroby. Dodatkowo czemu ma służyć encja pacjenci?

Karta choroby to nie jest usługa. Chce to wydzielić i pokazać, że pacjent ma kartę chorób i kartę zabiegów. Z kolei w karcie zabiegów, są zebrane te "usługi".
Czyli radzisz wywalić pacjentów i pociągnąć wszystko z users ?
P.S. Czy to dobrze, że zrobiłem podwójną relację z tabeli users do description i appointments ?

Tylko czy karty chorób nie możesz wygenerować z listy usług? Jest jakaś przyczyna/powód, że to musi być encja? Zakładam, że konkretny zabieg może (ale nie musi ) być powiązany z chorobą.
Podwójna relacja jest ok jeśli zakładasz, że ktoś z tablicy user jest podwójnie w innej tablicy (niekoniecznie to są różne osoby).

W sumie nie musi to być encja. Teraz rozumiem.

Podwójną relacje zastosowałem po to, aby pokazać, że w tabeli "Appointments" mamy dwóch użytkowników z tabeli users(lekarza i recepcjoniste). Rozumiem, że trzeba to inaczej załatwić ?

Appointments może być jak teraz tj. oddzielny atrybut dla poszczególnych ról użytkowników (np. lekarz, recepcjonistka itp). Tylko to jest rozwiązanie na "sztywno". Bardziej elastyczne podejście to tablica pośrednia dla tablic users i appointments (relacja wiele do wielu) gdzie "trzymasz" wszystkich uczestników wizyty (role i tak już masz przypisane [roles] choć jak chcesz możesz dodać atrybut dodatkowe role używane na potrzeby wizyty - tylko czy faktycznie są potrzebne).

OK. O coś takiego chodzi ?

Poniżej propozycja bazy [varchar(45) to domyślna wartość].

1. do końca nie rozumiem Twojej relacji miedzy users a users_access wiec dałem swoja propozycję
2. shifts - date_from i date_to jako datetime bo teoretycznie zmiana może zaczyna się jednego a kończyć drugiego dnia plus oszczędność miejsca.
3. employees_shifts - nie ma potrzeby dodawać pola id
4. users_has_appointments - pokazuje o co mi chodziło w temacie użytkowników na wizycie
5. dodałem encje service (możliwe usługi np. recepta, szczepionka, zabieg), service_types (pozwala zdefiniować grupy zabiegów - może być pomocne przy wyszukiwaniu usługi jeśli wiele ich będzie) oraz appointments_has_services (usługi jakie były wykonane na wizycie)

Moim zdaniem taka organizacja danych pozwoli Ci na identyfikacje:

1. szczepionek jakie miał wykonywane konkretny pacjent i kiedy
2. wszystkich wizyt pacjenta/lekarza itd. oraz możliwość wygenerowania karty pacjenta
3. wystawionych recept

Wygląda, że realizowane są Twoje wymagania przy prostszej i bardziej elastycznej strukturze bazy.

Dzięki wielkie :) teraz już wszystko rozumiem :)

P.S. relacja pomiędzy users, a users_has_shifts, nie powinna być opcjonalna ? Pacjent na przykład nie chodzi na zmiany :)