W relacyjnych bazach danych, jeżeli dwie tabele są połączone za pomocą ich kluczy głównych, mamy do czynienia z relacją
A. n..1
B. n..n
C. 1..1
D. 1..n
Pytanie z egzaminu CKE, styczeń 2020 (arkusz EE.09-SG-20.01).
Relacja 1..1 jest tu właściwa, bo połączenie dwóch tabel za pomocą ich kluczy głównych oznacza, że wartość identyfikatora w jednej tabeli może wystąpić tylko raz i dokładnie taka sama wartość może wystąpić tylko raz w drugiej tabeli. Klucz główny z definicji jest unikalny i nie powinien przyjmować wartości NULL, więc nie da się podpiąć wielu rekordów z jednej tabeli pod jeden rekord z drugiej. W praktyce często wygląda to tak: tabela Uzytkownik ma kolumnę id jako klucz główny, a tabela Profil ma kolumnę id, która jednocześnie jest kluczem głównym i kluczem obcym wskazującym na Uzytkownik.id. Wtedy jeden użytkownik ma najwyżej jeden profil, a jeden profil należy do jednego użytkownika. Moim zdaniem to dobry przykład rozdzielenia danych, gdy część informacji jest opcjonalna, rzadziej używana albo bardziej poufna. Zgodnie z dobrą praktyką projektowania baz danych takie powiązanie wymusza się ograniczeniem PRIMARY KEY oraz FOREIGN KEY, a czasem także dodatkowymi regułami spójności referencyjnej, np. ON DELETE CASCADE, jeśli rekord zależny ma być usuwany razem z głównym.
W tym pytaniu łatwo pomylić samo pojęcie połączenia tabel z licznością relacji. Relacje n..n, n..1 oraz 1..n pojawiają się bardzo często w projektowaniu baz danych, ale wynikają z innego układu kluczy. Gdy jedna tabela zawiera klucz obcy wskazujący na klucz główny drugiej tabeli, typowo dostajemy relację 1..n albo n..1, zależnie od strony, z której patrzymy. Przykład: jeden klient może mieć wiele zamówień, a każde zamówienie należy do jednego klienta. Tam w tabeli Zamowienie znajduje się klucz obcy klient_id, ale nie jest on kluczem głównym tej tabeli, więc ta sama wartość klient_id może powtarzać się wiele razy. To właśnie daje wiele rekordów po jednej stronie. Relacja n..n też nie pasuje, bo wymaga tabeli pośredniczącej, na przykład Student_Przedmiot, gdzie wiele studentów może być przypisanych do wielu przedmiotów. Samo połączenie kluczy głównych nie tworzy takiej struktury, bo klucz główny nie pozwala na duplikaty. Typowy błąd myślowy polega na tym, że ktoś widzi dwa połączone identyfikatory i od razu zakłada, że relacja może być dowolna. W relacyjnych bazach danych liczy się jednak to, gdzie występuje unikalność i czy kolumna po stronie zależnej może się powtarzać. Jeżeli obie strony są kluczami głównymi, to każda wartość identyfikatora występuje maksymalnie jeden raz w każdej tabeli, więc sensownie opisujemy to jako relację 1..1. W normalnym projekcie warto to dodatkowo potwierdzić ograniczeniami PRIMARY KEY i FOREIGN KEY, bo diagram to jedno, a rzeczywista integralność danych w silniku bazy to drugie.