Relacja pomiędzy tabelami, realizowana przez bezpośrednie połączenie kluczy głównych obu tabel, jest relacją
A. 1..n
B. n..1
C. 1..1
D. n..m
Pytanie z egzaminu CKE, czerwiec 2023 (arkusz EE.09-SG-23.06).
Relacja realizowana przez bezpośrednie połączenie kluczy głównych obu tabel to relacja 1..1. Wynika to z tego, że klucz główny w tabeli identyfikuje dokładnie jeden rekord i z definicji musi być unikalny oraz niepusty. Jeżeli klucz główny jednej tabeli jest jednocześnie powiązany z kluczem głównym drugiej tabeli, to jeden rekord z tabeli A może odpowiadać co najwyżej jednemu rekordowi z tabeli B, i odwrotnie. W praktyce często robi się tak, gdy chcemy rozdzielić dane na część podstawową i dodatkową, np. tabela Uzytkownik oraz tabela ProfilUzytkownika, gdzie profil ma ten sam identyfikator co użytkownik. To jest zgodne z dobrymi praktykami projektowania relacyjnych baz danych: klucze główne pilnują jednoznaczności, a więzy klucza obcego pilnują spójności referencyjnej. Moim zdaniem to jeden z tych przypadków, gdzie warto patrzeć nie tylko na nazwy tabel, ale właśnie na ograniczenia: PRIMARY KEY, UNIQUE i FOREIGN KEY. One realnie decydują, jaka relacja działa w bazie, a nie sam opis słowny w dokumentacji.
W tym pytaniu łatwo pomylić kierunek relacji z samym sposobem jej technicznego wykonania. Relacja 1..n oznacza, że jeden rekord z jednej tabeli może być powiązany z wieloma rekordami w drugiej tabeli. Typowy przykład to Klient i Zamowienie: jeden klient ma wiele zamówień, ale każde zamówienie należy do jednego klienta. W takiej sytuacji klucz obcy umieszcza się zwykle po stronie wielu, czyli w tabeli Zamowienie, a nie łączy się bezpośrednio dwóch kluczy głównych jako równorzędnych identyfikatorów. Relacja n..1 to w zasadzie ten sam przypadek opisany od drugiej strony, więc też nie pasuje do połączenia PK z PK. Częsty błąd polega na tym, że ktoś widzi dwa identyfikatory i od razu zakłada zależność wiele-do-jednego, ale unikalność klucza głównego blokuje wielokrotne dopasowania. Relacja n..m również nie jest realizowana prostym połączeniem dwóch kluczy głównych tabel głównych. W modelu relacyjnym wymaga tabeli pośredniczącej, np. Uczen, Przedmiot i tabela Uczen_Przedmiot, która ma dwa klucze obce, często tworzące złożony klucz główny. Bez takiej tabeli nie da się poprawnie zapisać wielu powiązań po obu stronach bez duplikacji i problemów ze spójnością danych. Z mojego doświadczenia najlepiej zapamiętać to tak: PK z PK najczęściej prowadzi do 1..1, FK po stronie wielu daje 1..n, a n..m potrzebuje osobnej tabeli łączącej.