Relacje baz danych / klucze złożone

Odpowiedz Nowy wątek
2019-10-08 19:38

Rejestracja: 2 lata temu

Ostatnio: 1 miesiąc temu

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 ! :)

edytowany 2x, ostatnio: MackoSawko, 2019-10-08 20:07
relacja jest synonimem słowa tabela (patrz: https://pl.wikipedia.org/wiki/Model_relacyjny); to, o czym mówisz, to związek / złączenie. - Patryk27 2019-10-08 20:09

Pozostało 580 znaków

2019-10-08 19:54

Rejestracja: 5 lat temu

Ostatnio: 1 minuta temu

Lokalizacja: Warszawa

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/que[...]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.


Pozostało 580 znaków

2019-10-08 20:09

Rejestracja: 2 lata temu

Ostatnio: 1 miesiąc temu

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.

Pozostało 580 znaków

2019-10-08 20:57

Rejestracja: 6 lat temu

Ostatnio: 17 godzin temu

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.

edytowany 1x, ostatnio: lookacode1, 2019-10-08 21:18
Podasz szczegóły, czemu powinno się unikać? - Silv 2019-10-08 20:58
Zaktualizowałem post. - lookacode1 2019-10-08 21:19
Dzięki. Jakby co, dla autora wątku: https://www.techrepublic.com/[...]lligent-keys-arent-that-dumb/ Pytanie do Ciebie: Czy takie klucze mogą też być nazywane "natural keys"? - Silv 2019-10-08 21:22
Tak, natural też Ok. Ja jeszcze ze studiów zapamiętałem to jako intelligent ;). - lookacode1 2019-10-08 21:27
Ja właśnie zawsze myślałem o tym jako o "natural": https://en.wikipedia.org/wiki/Natural_key - Silv 2019-10-08 21:29
@wloochacz: rzeczywiście, dzięki. :) - Silv 2019-10-10 13:37

Pozostało 580 znaków

2019-10-10 13:06

Rejestracja: 16 lat temu

Ostatnio: 2 minuty temu

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/que[...]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.

edytowany 1x, ostatnio: cerrato, 2019-10-10 13:15

Pozostało 580 znaków

cw
2019-10-10 13:45
cw

Rejestracja: 4 lata temu

Ostatnio: 7 minut temu

1

a jak pacjentem będzie obcokrajowiec bez numeru PESEL ?

takich nie leczymy - cerrato 2019-10-10 13:53
Lecimy, musi jedynie mieć ubezpieczenie. ba nie koniecznie ZUS. Poza tym odpłatnie to zawsze ... - _13th_Dragon 2019-10-10 13:56

Pozostało 580 znaków

2019-10-10 15:14

Rejestracja: 1 rok temu

Ostatnio: 6 godzin temu

0

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

Pozostało 580 znaków

2019-10-10 15:16
Moderator Kariera

Rejestracja: 2 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: Poznań

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.


Naczelny forumowy hejter Apple

That game of life is hard to play, I'm gonna lose it anyway
The losing card I'll someday lay, So this is all I have to say
edytowany 1x, ostatnio: cerrato, 2019-10-10 15:17
O ile nie przeżyjesz 200 lat to dokładnie jak mówisz. - _13th_Dragon 2019-10-10 15:57
Jeśli ktoś przeżyje 200 lat, to będzie miał inne zmartwienia, niż zduplikowany PESEL ;) - cerrato 2019-10-10 15:58

Pozostało 580 znaków

2019-10-10 15:17

Rejestracja: 1 rok temu

Ostatnio: 6 godzin temu

0

Ech co za czasy żeby linki do googla wklejać :)
https://www.google.com/search[...]am+pesel&oq=ten+sam+pesel

Pozostało 580 znaków

2019-10-10 15:18

Rejestracja: 1 rok temu

Ostatnio: 10 sekund temu

Lokalizacja: Silesia

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ś


edytowany 3x, ostatnio: Kamil Żabiński, 2019-10-10 15:21

Pozostało 580 znaków

2019-10-10 15:21
Moderator Kariera

Rejestracja: 2 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: Poznań

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ć.


Naczelny forumowy hejter Apple

That game of life is hard to play, I'm gonna lose it anyway
The losing card I'll someday lay, So this is all I have to say
edytowany 2x, ostatnio: cerrato, 2019-10-10 15:31
- Pana nie obsługujemy. Pan ma błędy PESEL. Proszę najpierw iść do urzędu i zmienić PESEL - Ale ja umieram - Trudno, system nie pozwala pana obsłużyć :D - Kamil Żabiński 2019-10-10 15:31
dokładnie. Zasady i porządek muszą obowiązywać wszystkich ;) - cerrato 2019-10-10 15:33
"- 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." :P - yarel 2019-10-10 15:33
Śmichy chichy, ale kolega miał realny problem z PESELem córki. Wygenerowali mu błędny, bo zakodowali niepoprawnie płeć dziecka. No i jakiś tam magiczny system w przychodni nie mógł jej zarejestrować bo PESEL nie zgadza się z płcią dziecka, a są to obowiązkowe pola. No i jesteś z chorym kilkumiesięcznym dzieckiem w kolejce do lekarza, a mówią ci "nie przyjmiemy pana dziecka, bo SYSTEM NIE POZWALA!". - robertos7778 2019-10-17 23:38

Pozostało 580 znaków

Odpowiedz

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