Relacje baz danych / klucze złożone

0

Cześć, potrzebuję pomocy. Mam taki schemat bazy:

Schemat bazy danych dla przychodni lekarskiej

screenshot-20191008192649.png

Chciałbym dać relację, że każdy pacjent ma jeden adres a każdy lekarz może mieć wiele specjalizacji. U mnie wygląda to tak:

**dla pacjentów **

screenshot-20191008192926.png

dla lekarzy

screenshot-20191008193008.png

plus mógłby ktoś powiedzieć kilka słów o co chodzi w tym Relationsip Type : Identifying / Non-Identifying i Mandatory Parent/Child

Chciałbym jeszcze, żeby tabela Terminy była kluczem złożonym z dwóch pól IdLekarza i PESEL, tylko tak myślę, że jak ktoś będzie chciał wizytę u tego samego lekarza ale w innej jego specjalizacji to jak to sensownie rozdzielić.

Dzięki za pomoc ! :)

0

Chciałbym dać relację, że każdy pacjent ma jeden adres a każdy lekarz może mieć wiele specjalizacji. U mnie wygląda to tak:

Ale jakie jest pytanie? Chciałbyś, ale... z jakiegoś powodu nie możesz? Nie wiesz, czy to poprawnie w tym programie?

plus mógłby ktoś powiedzieć kilka słów o co chodzi w tym Relationsip Type : Identifying / Non-Identifying

Nie słyszałem o tym; niemniej możesz zobaczyć tutaj, może pomoże: https://stackoverflow.com/questions/762937/whats-the-difference-between-identifying-and-non-identifying-relationships

Uwaga ode mnie: przydałaby się nazwa programu, z które zrobiłeś te zrzuty ekranu; każdy program może mieć zdeczko odmienne nazewnictwo.

0

Chciałem się zapytać czy jest to dobrze ustawione w opcjach i relacjach. Ogólnie czy to ma sens tak samo z tym kluczem złożonym w tabeli Terminy czy takie coś ( stworzenie klucza złożonego z pól IdLekarza, Pesel ) będzie w miarę sensownym rozwiązaniem czy myśleć nad czymś innym.

1

stworzenie klucza złożonego z pól IdLekarza, Pesel

Takich kluczy (tzw. intelligent keys) powinno się raczej unikać. Baza powinna być spójna, klucz unikalny i niezmienny.
Pesel może sie zmienić np. ktoś się pomylił i wprowadził błędny. Trudniej to potem aktualizować. Dlatego jestem raczej
za czymś takim id_lekarza, id_pacjenta.

0
Silv napisał(a):

Chciałbym dać relację, że każdy pacjent ma jeden adres a każdy lekarz może mieć wiele specjalizacji. U mnie wygląda to tak:

To dodaj.
Ale klucz złożony w bazi danych to jest zło i należy go unikać jak ognia.

Ale jakie jest pytanie? Chciałbyś, ale... z jakiegoś powodu nie możesz? Nie wiesz, czy to poprawnie w tym programie?

plus mógłby ktoś powiedzieć kilka słów o co chodzi w tym Relationsip Type : Identifying / Non-Identifying
Nie słyszałem o tym; niemniej możesz zobaczyć tutaj, może pomoże: https://stackoverflow.com/questions/762937/whats-the-difference-between-identifying-and-non-identifying-relationships

Nie słyszałeś?
Hmm... to wyjaśnienie jest poprawne, ale nieco zamotane.
Najprościej jak się da:

  • non-identifying
    Pole łączące w tabeli podrzędnej nie jest kluczem podstawowym w tej tabeli.
    To najczęstszy przypadek i takie pole może być opcjonalne wypełnione.
  • identifying
    Pole łączące w tabeli podrzędnej jest kluczem podstawowym w tej tabeli.
    To najczęściej stosuje się w relacja jeden-do-jeden.

Uwaga ode mnie: przydałaby się nazwa programu, z które zrobiłeś te zrzuty ekranu; każdy program może mieć zdeczko odmienne nazewnictwo.

To oczywiste ;-)
Toad Data Modeler, kiedyś znany pod nazwą CaseStudio.

MackoSawko napisał(a):

Chciałem się zapytać czy jest to dobrze ustawione w opcjach i relacjach

Moim zdaniem, nie do końca.
Tabela adresy jest nadrzędną dla pacjenta.
Po co?
Powinno być dokładnie odwrotnie, ponieważ usunięcie pacjenta powinno automatycznie usunąć jego adres.
Ale próba usunięcia adresu dla istniejącego pacjenta, powinna zostać zabroniona.
Ty masz zrobione to odwrotnie i sam sobie odpowiedz czy jest to sensowne.

. Ogólnie czy to ma sens tak samo z tym kluczem złożonym w tabeli Terminy czy takie coś ( stworzenie klucza złożonego z pól IdLekarza, Pesel ) będzie w miarę sensownym rozwiązaniem czy myśleć nad czymś innym.

Nie, nie jest to sensowne i będzie rodziło ogromne problemy przy rozbudowie systemu.
Zauważ, że aby zidentyfikować wiersz z takiej tabeli będzie musiał podać wartości dla wszystkich pól, które wchodzą w skład klucza podstawowego.
Wszędzie będziesz musiał to podawać i przy każdej operacji (select, join, delete, itd.).
To nie jest fajny pomysł...

lookacode1 napisał(a):

stworzenie klucza złożonego z pól IdLekarza, Pesel

Takich kluczy (tzw. intelligent keys)

NIE!
To nie jest ani *natural * ani *intelligent *(który jest pochodną natural), tylko composite keys.
A klucze naturalne to zupełnie inny pies.

powinno się raczej unikać. Baza powinna być spójna, klucz unikalny i niezmienny.
Pesel może sie zmienić np. ktoś się pomylił i wprowadził błędny. Trudniej to potem aktualizować. Dlatego jestem raczej
za czymś takim id_lekarza, id_pacjenta.

Pełna zgoda.

1

a jak pacjentem będzie obcokrajowiec bez numeru PESEL ?

0

Pomijając kwestie opisane wyżej PESEL nie jest unikalny więc wybranie go jako PK jest błędem.

0

PESEL nie jest unikalny

Czy możesz to rozwinąć? Bo zawsze żyłem w przekonaniu, że numery PESEL, NIP i REGON jednoznacznie identyfikują posiadający je podmiot/osobę.

https://pl.wikipedia.org/wiki/PESEL#Numer_PESEL

Każdy wpis w rejestrze jest określany unikatowym symbolem jednoznacznie identyfikującym osobę fizyczną.Numer PESEL jest to 11-cyfrowy stały symbol numeryczny jednoznacznie identyfikujący określoną osobę fizyczną.

No chyba, że chodzi Ci o możliwość wpisania do bazy kilka razy tego samego pacjenta. Ale w takim razie nie jest to wina PESELa, tylko logiki zastosowanej podczas wprowadzania danych.

0

Ech co za czasy żeby linki do googla wklejać :)
https://www.google.com/search?q=dwie+osoby+ten+sam+pesel&oq=ten+sam+pesel

0
cerrato napisał(a):

PESEL nie jest unikalny

Czy możesz to rozwinąć? Bo zawsze żyłem w przekonaniu, że numery PESEL, NIP i REGON jednoznacznie identyfikują posiadający je podmiot/osobę.

https://pl.wikipedia.org/wiki/PESEL#Numer_PESEL

Każdy wpis w rejestrze jest określany unikatowym symbolem jednoznacznie identyfikującym osobę fizyczną.Numer PESEL jest to 11-cyfrowy stały symbol numeryczny jednoznacznie identyfikujący określoną osobę fizyczną.

No chyba, że chodzi Ci o możliwość wpisania do bazy kilka razy tego samego pacjenta. Ale w takim razie nie jest to wina PESELa, tylko logiki zastosowanej podczas wprowadzania danych.

Błędy w nadawaniu numeru PESEL

W praktyce zdarzają się (a przynajmniej zdarzały i wciąż istnieją) numery PESEL z błędami. Błędy w dacie zwykle były zauważane i poprawiane od razu, lecz zdarzały się też powtórzenia numeru porządkowego, błędy w określeniu płci i błędne cyfry kontrolne, które zostały wychwycone po latach przy okazji wprowadzania numeru PESEL do komputerowych baz danych. W związku z tym nie można zakładać, że wynik sprawdzania jednoznacznie określa istnienie bądź nieistnienie podanego numeru PESEL.

Numer PESEL można zmienić[19]. Powodem do zmiany są przypadki, gdy nastąpiła zmiana płci, osoba ma nowy akt urodzenia lub decyzja urzędu okazała się błędna (w wyniku błędów urzędników w 2012 roku ten sam numer nadano różnym osobom w 2 tys. przypadków[20]).

Z tego samego artykułu, który podlinkowałeś

0

No dobra, ale Panowie - to są błędy.

Wychodząc z takiego założenia, to właściwie niczego byśmy nie zrobili, bo zawsze ktoś albo coś może się gdzieś pomylić. Co do zasady - PESEL powinien być unikalny. Pewne rzeczy można uznać za godne zaufania, a poza tym w sytuacji, w której Ty, jako programista, pomieszasz dwie osoby, bo jakiś urząd się pomylił i nadał im takie same numery PESEL, nikt nie ma prawa mieć do Ciebie pretensji w związku z tym faktem. No i jeszcze kwestia skali - mówimy o błednych PESELACH w ilościach rzędu jednej setnej procenta, więc nawet przyjmując do wiadomości fakt, że PESEL może się powtórzyć, realne szanse na to, że się to stanie akurat w naszej aplikacji, są bliskie zera.

No i nie starajmy się być bardziej święci od Papieża. Skoro banki, urzędy, sądy, policja, szkoły, NFZ itp. używają PESELa jako numeru jednoznacznie identyfikującego osobę, to tym bardziej u nas w bazie możemy także przyjąć, że jest on unikalny i się nie powinien powtórzyć.

1

No właśnie, zawsze ktoś lub coś się może pomylić ale nasz system ma zawsze działać.
Dobrą praktyką jest jeżeli dane nie są generowane w twoim systemie to nie narzucasz sztywnych warunków.

4

Na szczęście nasz system nie implementuje głupich ograniczeń biznesowych i pozwala na zduplikowane PESELE. Dzięki temu nie tylko umrzemy pana ale i kilku postronnych żywych Kowalskich

@yarel - chciałem wstawić w komentarzu, ale coś mi nie działa, więc robię jako osobny post :D

screenshot-20191010154023.png

0

Hej,

lekko pozmieniałem bazę, wyszło tak :

screenshot-20191015191248.png

Mam pytanie czy dla takich funkcjonalności jak tworzenie pacjentów, lekarzy z przydzielaniem specjalizacji, tworzenie wizyt (termin, lekarz, pacjent) będzie to wystarczające ? Chcę napisać proste REST Api w Springu a do frontu chciałem użyć Angulara.

  1. Mógłby mi ktoś jeszcze pomóc w dobieraniu typów ? Czy BigInt będzie dobrym rozwiązaniem dla numeru telefonu i peselu ?
  2. Czy jak stworzę kilka specjalizacji w bazie "Specjalizacje" to klucz obcy (IdSpecjalizacji) w "Lekarzach" jest okej do przydzielania kilku specjalizacji lekarzom ?

Np. rekordy dla jednego lekarza, który ma kilka specjalizacji
Chodzi mi o coś takiego

IdLekarza Imię/Nazwisko IdSpecjalizacji
1 Jan Kowalski 1 (Lekarz rodzinny)
2 Jan Kowalski 2 (Laryngolog)
3 Jan Kowalski 3 (Kardiolog)

Czy takie rozwiązanie chodź trochę jest dobre ? :D

0
MackoSawko napisał(a):

Hej,

lekko pozmieniałem bazę, wyszło tak :

screenshot-20191015191248.png

Wygląda OK...

Mam pytanie czy dla takich funkcjonalności jak tworzenie pacjentów, lekarzy z przydzielaniem specjalizacji, tworzenie wizyt (termin, lekarz, pacjent) będzie to wystarczające ?

Co do modelu relacyjnego to tak.
A co do atrybutów (jakie kolumny mają mieć poszczególne tabele i co powinno się w nich znaleźć), to sam sobie odpowiedz.

Chcę napisać proste REST Api w Springu a do frontu chciałem użyć Angulara.

  1. Mógłby mi ktoś jeszcze pomóc w dobieraniu typów ? Czy BigInt będzie dobrym rozwiązaniem dla numeru telefonu i peselu ?

Nie.
Użyj Varchar lub Char.

  1. Czy jak stworzę kilka specjalizacji w bazie "Specjalizacje" to klucz obcy (IdSpecjalizacji) w "Lekarzach" jest okej do przydzielania kilku specjalizacji lekarzom ?
    Np. rekordy dla jednego lekarza, który ma kilka specjalizacji
    Chodzi mi o coś takiego
IdLekarza Imię/Nazwisko IdSpecjalizacji
1 Jan Kowalski 1 (Lekarz rodzinny)
2 Jan Kowalski 2 (Laryngolog)
3 Jan Kowalski 3 (Kardiolog)

Czy takie rozwiązanie chodź trochę jest dobre ? :D

To jest fatalne rozwiązanie...
Jeżeli lekarz może mieć wiele specjalizacji, to nie jest to poprawne.
Potrzebujesz dodatkowej tabeli która będzie wiązała wiele specjalizacji do wielu lekarzy.
Analogicznie jak zrobiłeś tabelę Terminy.

0

Uuuu... polskie nazwy kolumn :(

Nie widzę sensu stosowania nazw dla PK w stylu "IdLekarza". Nazwij to po prostu "Id".

Polskie litery w nazwach kolumn? Auć...

Varchar(20) to może być za mało dla niektórych danych.

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