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