Schemat bazy danych

0

Cześć,

Mam pytanie, potrzebuję pomocy w stworzeniu bazy danych. Buduję apkę na studia, która ma pomagać w zarządzaniu przychodnią lekarską. Czyli proste wybranie terminu lekarza i zapisanie to do bazy + ewentualne późniejsze modyfikacje. Chodzi mi o tabele TerminyWizyt. Chciałbym z góry narzucić, że każda wizyta ma trwać 15 minut czyli 4 w ciągu godziny i 32 w ciągu dnia. Chciałbym żeby to było w tabeli na przykład :

idTerminu =1
Termin = 201828 8:00
idTerminu =2
Termin = 201828 8:15
idTerminu =3
Termin = 201828 8:30

i żebym mógł to przypisywać, godzinę wizyty do konkretnego lekarza i pacjenta.
Ma w ogóle takie coś sens czy powinienem to jakoś inaczej zrobić. Już teraz widzę, że będę musiał ciągle generować nowe terminy wizyt a stare usuwać więc może da się to jakoś zrobić z automatu lub innym sposobem ?

screenshot-20181128094158.png

1

Jaki sens ma trzymanie terminów w osobnej tabeli?

IMO najwygodniej byłoby mieć tabelę Wizyty z kolumnami IdWizyty, IdPacjenta, Data i może jeszcze Status (odwołana / przesunięta etc., jeśli chcesz się bawić w takie rzeczy).

Chciałbym z góry narzucić, że każda wizyta ma trwać 15 minut czyli 4 w ciągu godziny i 32 w ciągu dnia.

Dlaczego?
Co w sytuacji, kiedy z góry wiadomo, że wizyta zajmie więcej czasu?
Co w sytuacji, kiedy z góry wiadomo, że danego dnia lekarz będzie miał inne godziny przyjmowania?
Co w sytuacji, gdy lekarz będzie pracował na np. 2/3 etatu?

1

15 minut czyli 4 w ciągu godziny i 32 w ciągu dnia

Takie rzeczy raczej ogrywa sie w kodzie a w bazie trzyma sie date(ewentualnie godzine) rozpoczecia i zakonczenia - dlaczego? Dla elastycznosci jak powiedzial wlasnie @Patryk27

Zrobieles trzy strzalki do Wizyty, ale jak chcesz to polaczyc bo ten schemat nie mowi nic o relacji poza jej kierunkiem? Musisz w tej tabeli trzymac 3 ID(lekarza terminu, i pacjenta)...

Teraz kolejny problem z terminami?

  • W Twoim wypadku co dziennie rano bedziesz tworzyl wpisy na wizyty na dzisiejszy dzien? Cron, triggery, pani Krysia z recepcji? A co jesli cos pojdzie nie tak i sie nie stworza i pani na recepcji nie bedzie mogla zarezerwowac wizyt?
  • Czy to ma byc uniwersalny schemat dla wszystkich dni jednakowy? Jesli tak to dlaczego nie zakodowac tego jako logike biznesowa?

Wedlug mnie tabela terminy powinna zostac zlaczona z Wizytami i zawierac ID, lekarza, pacjeta i date. rozpoczecia i zakonczenia, chyba ze wymaganiem biznesowym jest 4 wizyty na godzine jak w fabryce ( ͡° ͜ʖ ͡°), to wtedy mozesz dac data wizyty i przy tworzenieniu sprawdzac czy wczesniejsza trwa rowno 15 min ewentualnie czy okres miedzy dodawana a poprzednia jest wielokrotnoscia 15.

IdDane w tabeli dane wskazuja na to ze jedne dane moga nalezec do kilku pacjetow... Jesli tak Ok. ale jesli nie Dlaczego po prostu kluczem nie beda Id Osoby?

@MackoSawko dlaczego nie umieszczasz kluczy obcych na schemacie?

Kolejna rzecz:
IdPacjent
IdDane
IdWizyta

Te nazwy wyglada okropnie i sa redudantne i na etapie wdrazania sa uciazliwe.

Piszac zapytanie

SELECT wizyta.IdWizyta, pacjent.IdPacjent FROM wizyta, pacjent WHERE ... 

po co sie powtarzac?

SELECT IdWizyta FROM wizyta ... WHERE

Jw wyzej.

Jesli uzyjesz ORMa ktory ma zakodowana nazwe tabeli w jednym miejscu co jest jedna z jego idei aby mozna bylo latwo zmienic nazwe tej tabeli min i aby nie uzywac nazw wlasnych jako stringow w kodzie, jesli zmienisz nazwe tabeli to powodzenia z refaktoryzacja nazw pol w tabeli :)

0

co z tabelą DaneOsobowe? jeśli ma przechowywać dane lekarzy i pacjentów to dlaczego pola imie i nazwisko są redundantnie w obu tabelach a nie w DaneOsobowe, jeśli natomiast mają być tam trzymane dane pacjentów to po co osobna tabela?

0

Lekko przerobiłem bazę, czy teraz jest w miarę dobra czy dalej są jakieś rażące błędy ?

screenshot-20181203202424.png

1

Na postgres, ale myślę, że na Oracle też pójdzie:
http://sqlfiddle.com/#!15/713fb6/2

2
MackoSawko napisał(a):

Lekko przerobiłem bazę, czy teraz jest w miarę dobra czy dalej są jakieś rażące błędy ?

  1. Relationship* - nic nie wnosi do opisu i brzydko wygląda
  2. W prawdziwym życiu Lekarz może mieć więcej niż 1 specjalizację
  3. Nazwy relacji w liczbie mnogiej?
  4. Model pozwala na zdefiniowanie różnych terminów dla tej samej daty.
  5. Do tego samego lekarza można w tym samym terminie umówić różnych pacjentów? W końcu rozwiązanie problemu kolejek do lekarzy :-)
  6. Pacjent/Lekarz i DaneOsobowe - wygląda na jakąś niekonsekwencję. Dlaczego jest IdLekarza, a nie ma IdPacjenta, mimo, że obydwa powiązane są z DaneOsobowe?
  7. Czy na pewno w tym samym terminie dany pacjent może mieć różne wizyty? Model na to pozwala.
0
yarel napisał(a):
MackoSawko napisał(a):

Lekko przerobiłem bazę, czy teraz jest w miarę dobra czy dalej są jakieś rażące błędy ?

  1. Relationship* - nic nie wnosi do opisu i brzydko wygląda
  2. W prawdziwym życiu Lekarz może mieć więcej niż 1 specjalizację
  3. Nazwy relacji w liczbie mnogiej?
  4. Model pozwala na zdefiniowanie różnych terminów dla tej samej daty.
  5. Do tego samego lekarza można w tym samym terminie umówić różnych pacjentów? W końcu rozwiązanie problemu kolejek do lekarzy :-)
  6. Pacjent/Lekarz i DaneOsobowe - wygląda na jakąś niekonsekwencję. Dlaczego jest IdLekarza, a nie ma IdPacjenta, mimo, że obydwa powiązane są z DaneOsobowe?
  7. Czy na pewno w tym samym terminie dany pacjent może mieć różne wizyty? Model na to pozwala.
  1. Czyli jak powinienem poprawnie nazywać ?
  2. Pamiętam, że kiedyś ustawiałem w MySqlu coś takiego jak "łączony klucz główny" i wtedy mógłbym dać kilka specjalizacji do danego lekarza.
  3. A jakbym dał unikalne pole Data w tabeli Terminy to nie byłoby to dobre rozwiązanie ?
  4. Czyli utworzyć klucz główny w tabeli Pacjenci(IdPacjenta) i go ustawić jako obcy w Wizytach ?
  5. No nie może, to jak rozwiązać ten problem ? Myślałem, że taki problem rozwiązywałbym w kodzie aplikacji.
0
MackoSawko napisał(a):
  1. Czyli jak powinienem poprawnie nazywać ?
  2. Pamiętam, że kiedyś ustawiałem w MySqlu coś takiego jak "łączony klucz główny" i wtedy mógłbym dać kilka specjalizacji do danego lekarza.
  3. A jakbym dał unikalne pole Data w tabeli Terminy to nie byłoby to dobre rozwiązanie ?
  4. Czyli utworzyć klucz główny w tabeli Pacjenci(IdPacjenta) i go ustawić jako obcy w Wizytach ?
  5. No nie może, to jak rozwiązać ten problem ? Myślałem, że taki problem rozwiązywałbym w kodzie aplikacji.
  1. Bardziej opisowo i odzwierciedlając znaczenie danego związku?
    Zamiast: Wizyty --- Relationshiop9 --- Terminy
    może: Wizyta -- Realizowana w -- Termin (albo "Umówiona na", albo coś innego co opisze po ludzku modelowany związek)

  2. Łączony klucz główny? Model powinien być oderwany od konkretnego silnika.

Masz związek wiele-do-wielu, więc modelujesz za pomocą relacji pośredniej, np. Lekarz_Specjalizacja i masz wtedy 3 relacje:

  • Lekarz
  • Lekarz_Specjalizacja
  • Specjalizacja
  1. Tak, ma to sens.

  2. Tak, wówczas będziesz miał możliwość usunięcia powiązania pacjenta z danymi osobowymi (usunięcie danych osobowych pacjenta) i pozostawienia historii wizyt obsługiwanych przez lekarzy.

  3. Możesz dodać unikalne indeksy: (Termin, Lekarz), (Termin, Pacjent), ewentualnie jakąś relację "Rezerwacja", która zablokuje slot danego lekarza i dopiero jak wizyta dojdzie do skutku, to pojawi się wpis w Wizyta.

0
yarel napisał(a):
  1. Bardziej opisowo i odzwierciedlając znaczenie danego związku?
    Zamiast: Wizyty --- Relationshiop9 --- Terminy
    może: Wizyta -- Realizowana w -- Termin (albo "Umówiona na", albo coś innego co opisze po ludzku modelowany związek)

  2. Łączony klucz główny? Model powinien być oderwany od konkretnego silnika.

Masz związek wiele-do-wielu, więc modelujesz za pomocą relacji pośredniej, np. Lekarz_Specjalizacja i masz wtedy 3 relacje:

  • Lekarz
  • Lekarz_Specjalizacja
  • Specjalizacja
  1. Tak, ma to sens.

  2. Tak, wówczas będziesz miał możliwość usunięcia powiązania pacjenta z danymi osobowymi (usunięcie danych osobowych pacjenta) i pozostawienia historii wizyt obsługiwanych przez lekarzy.

  3. Możesz dodać unikalne indeksy: (Termin, Lekarz), (Termin, Pacjent), ewentualnie jakąś relację "Rezerwacja", która zablokuje slot danego lekarza i dopiero jak wizyta dojdzie do skutku, to pojawi się wpis w Wizyta.

screenshot-20181206191022.png

Troszkę lepiej ? :D

Nie za bardzo rozumiem punktu piątego. Mógłbyś mi to jakoś łopatologicznie wytłumaczyć albo zobrazować ? :)

0

Do 5-tego to możesz mieć 2 dodatkowe relacje:

Blokada_Terminu_Pacjent

  • ID_Pacjent PK
  • ID_Termin PK

Blokada_Terminu_Lekarz

  • ID_Lekarz PK
  • ID_Pacjent PK

W taki sposób jesteś w stanie zablokować konkretny termin Pacjenta i Lekarza. Jeśli pacjent:

  • przyjdzie - tworzysz rekord w Wizyta.
  • nie przyjdzie - jesteś w stanie namierzyć pacjentów, którzy zapisali się na wizyty, ale na nie nie przyszli (będą rekordy w blokada_terminu, ale nie będzie w wizytach).
  • odwoła wizytę - usuwasz blokadę terminu pacjenta i lekarza (możesz mieć jakieś statusy, żeby zapamiętywać, że często odwołuje wizyty albo dedykowaną relacje: Odwolane wizyty itd. ;-) )

Nazwy relacji nadal są od czapy. Chodzi o to co dana relacja obrazuje, np. Autor "pisze" Książkę, Pacjent "rezerwuje" Wizytę itd, Student "zapisany na" Zajecia itd.

0
yarel napisał(a):

Do 5-tego to możesz mieć 2 dodatkowe relacje:

Blokada_Terminu_Pacjent

  • ID_Pacjent PK
  • ID_Termin PK

Blokada_Terminu_Lekarz

  • ID_Lekarz PK
  • ID_Pacjent PK

W taki sposób jesteś w stanie zablokować konkretny termin Pacjenta i Lekarza. Jeśli pacjent:

  • przyjdzie - tworzysz rekord w Wizyta.
  • nie przyjdzie - jesteś w stanie namierzyć pacjentów, którzy zapisali się na wizyty, ale na nie nie przyszli (będą rekordy w blokada_terminu, ale nie będzie w wizytach).
  • odwoła wizytę - usuwasz blokadę terminu pacjenta i lekarza (możesz mieć jakieś statusy, żeby zapamiętywać, że często odwołuje wizyty albo dedykowaną relacje: Odwolane wizyty itd. ;-) )

Nazwy relacji nadal są od czapy. Chodzi o to co dana relacja obrazuje, np. Autor "pisze" Książkę, Pacjent "rezerwuje" Wizytę itd, Student "zapisany na" Zajecia itd.

Myślałem nad tym co napisałeś i wydaję mi się, że dla mnie byłoby prostsze i jaśniejsze jakbym do Tabeli "Wizyty" dodał po prostu pole status które po terminie wizyty przyjmowałoby powiedzmy 3 statusy, Wizyta zakończona ( przyszedł pacjent ) wizyta odwołana ( po prostu odwołał termin bez względu na to czy przełożył czy nie ) i np. brak obecności. Zostawiłbym jednak "Blokada_Terminu_Pacjenta", żeby Pacjent nie mógł rejestrować się w tym samym czasie na kilka wizyt.

PS jak z nazewnictwem tych relacji ? :D

screenshot-20181207131533.png

0

Z tego schematu wynika, że dany pacjent w danym dniu moze pójść tylko do jednego lekarza... (Pacjent, Terminy, Blokada_Terminu_Pacjenta)

0

Przyznam, że cały czas zastanawia mnie koncepcja z tymi oddzielnymi blokadami, oddzielną encją dla terminów. Czy nie prościej jest po prostu zrobić encje:
rezerwacje:
-id_rezerwacji (PK)
-id_pacjenta (FK)
-id_lekarza (FK)
-data_rozpoczecia (datetime)
-data_zakoczenia (datetime)
-id_status_rezerwacji (FK)

statusy_rezerwacji:
-id_status_rezerwacji (PK)
-nazwa

wizyty:
-id_wizyty (PK)
-id_rezerwacji (FK)
-opis

Oczywiście można jeszcze pomyśleć o receptach, lekach czasach wizyt w zależności od specjalizacji lekarza itd, ale na tym etapie raczej ten kierunek byłby lepszy.

0

@MackoSawko: Z jakiej aplikacji korzystasz generując tego rodzaju schemat "wizualny"?

1 użytkowników online, w tym zalogowanych: 0, gości: 1