Schemat bazy danych

Odpowiedz Nowy wątek
2018-11-28 09:44
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 = 2018:11:28 8:00
idTerminu =2
Termin = 2018:11:28 8:15
idTerminu =3
Termin = 2018:11:28 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

edytowany 2x, ostatnio: MackoSawko, 2018-11-28 09:45

Pozostało 580 znaków

2018-11-28 09:47

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?


edytowany 5x, ostatnio: Patryk27, 2018-11-28 09:55

Pozostało 580 znaków

2018-11-28 10:21
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 :)

edytowany 2x, ostatnio: daniel1302, 2018-11-28 10:28

Pozostało 580 znaków

2018-11-28 11:09
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?


Chcesz pomocy - pokaż kod - abrakadabra źle działa z techniką.
that's what she said ( ͡° ͜ʖ ͡°) - daniel1302 2018-11-28 13:15

Pozostało 580 znaków

2018-12-03 20:25
0

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

screenshot-20181203202424.png

po co są dwie oddzielne tabele Pacjent i DaneOsobowe ? - cw 2018-12-03 20:50

Pozostało 580 znaków

2018-12-03 20:54
1

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

Wygląda ok, ale chyba to odpowiedź do innego posta :-) - yarel 2018-12-03 21:15
No. Pora na urlop... :) - Marcin.Miga 2018-12-03 22:20

Pozostało 580 znaków

2018-12-03 21:10
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.

edytowany 1x, ostatnio: yarel, 2018-12-03 21:11

Pozostało 580 znaków

2018-12-05 13:10
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.

Pozostało 580 znaków

2018-12-05 14:07
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

3) Tak, ma to sens.
4) 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.

5) 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.

edytowany 1x, ostatnio: yarel, 2018-12-05 14:08

Pozostało 580 znaków

2018-12-06 19:12
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

3) Tak, ma to sens.
4) 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.

5) 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ć ? :)

Pozostało 580 znaków

2018-12-07 08:50
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.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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