W wyniku połączenia relacją kluczy głównych dwóch tabel otrzymuje się relację typu
A. jeden do wielu.
B. wiele do wielu.
C. jeden do jednego.
D. wiele do jednego.
Pytanie z egzaminu CKE, czerwiec 2019 (arkusz EE.09-X-19.06).
Relacja typu jeden do jednego jest tutaj właściwa, ponieważ połączenie dwóch tabel przez ich klucze główne oznacza, że po obu stronach wartości są unikalne. Klucz główny nie może się powtarzać w tabeli, więc jeden rekord z tabeli A może odpowiadać co najwyżej jednemu rekordowi z tabeli B, i odwrotnie. W praktyce robi się tak np. wtedy, gdy dane użytkownika są rozdzielone na dwie tabele: Uzytkownik i ProfilUzytkownika. Obie mogą mieć ten sam identyfikator jako klucz główny, a profil rozszerza dane użytkownika. Moim zdaniem to dość eleganckie rozwiązanie, gdy chcemy oddzielić dane podstawowe od rzadziej używanych albo bardziej wrażliwych. W projektowaniu baz danych zgodnym z dobrymi praktykami trzeba jednak pilnować więzów integralności, czyli np. ograniczeń PRIMARY KEY, FOREIGN KEY oraz UNIQUE. Sama nazwa kolumny id nie wystarczy, baza musi mieć zdefiniowane ograniczenia. Relacja PK-PK naturalnie wymusza unikalność po obu stronach, dlatego mówimy o relacji 1:1.
W tym pytaniu łatwo pomylić samo pojęcie łączenia tabel z typem relacji między rekordami. Jeśli ktoś wybiera relację wiele do wielu, zwykle myśli o sytuacji, w której wiele rekordów z jednej tabeli pasuje do wielu rekordów z drugiej. Tak jest np. przy uczniach i kursach: jeden uczeń może chodzić na wiele kursów, a jeden kurs ma wielu uczniów. Tego nie robi się przez proste połączenie dwóch kluczy głównych, tylko przez tabelę pośredniczącą, często nazywaną tabelą łącznikową, z kluczami obcymi do obu tabel. Relacja jeden do wielu lub wiele do jednego pojawia się wtedy, gdy klucz główny jednej tabeli jest powiązany z kluczem obcym w drugiej tabeli, ale ten klucz obcy może się powtarzać. Przykład: jeden klient ma wiele zamówień, więc id klienta występuje w wielu rekordach tabeli Zamowienia. To nie jest połączenie dwóch kluczy głównych, bo w tabeli zamówień identyfikator klienta nie jest unikalnym kluczem głównym każdego zamówienia. Przy połączeniu klucza głównego z kluczem głównym obie strony mają wymuszoną unikalność. Z mojego doświadczenia najczęstszy błąd polega na patrzeniu tylko na nazwy tabel, a nie na ograniczenia w bazie. To właśnie ograniczenia PRIMARY KEY, FOREIGN KEY i UNIQUE decydują o kardynalności relacji, a nie sam fakt, że robimy JOIN w SQL.