Relacja jeden do wielu (1:N) oznacza, że jeden rekord w tabeli nadrzędnej może być powiązany z wieloma rekordami w tabeli podrzędnej. W typowym schemacie baz danych realizuje się to tak, że tabela po stronie "wiele" przechowuje identyfikator rekordu z tabeli po stronie "jeden".
Dlatego poprawne powiązanie w relacji 1:N to: klucz obcy w tabeli filmy (kolumna reżyserzy_id) wskazuje na klucz podstawowy tabeli reżyserzy (kolumna id). Taki zapis zapewnia, że każdy film może mieć przypisanego reżysera, a system bazy danych może pilnować integralności referencyjnej (nie da się wpisać reżyserzy_id, którego nie ma w reżyserzy.id, jeśli zdefiniowano ograniczenie FOREIGN KEY).
Pozostałe odpowiedzi są błędne z typowych powodów projektowych:
- Połączenie dwóch kluczy podstawowych (filmy.id z reżyserzy.id) nie opisuje relacji 1:N między tabelami, tylko zestawia niezależne identyfikatory; nie tworzy to mechanizmu przypisania filmu do reżysera.
- "Klucz obcy … z kluczem obcym …" jest logicznie niepoprawne jako definicja relacji nadrzędnej–podrzędnej, bo klucz obcy powinien wskazywać na klucz unikalny/klucz podstawowy w tabeli referencjonowanej.
- "Klucz podstawowy filmy.id z kluczem obcym reżyserzy_id tabeli reżyserzy" odwraca role tabel: sugeruje, że to tabela reżyserzy referencjonuje filmy, co nie odpowiada typowemu modelowi "jeden reżyser – wiele filmów".
W praktyce egzaminacyjnej warto zapamiętać regułę: FK jest w tabeli po stronie "wiele" i wskazuje na PK (lub inny unikalny klucz) tabeli po stronie "jeden". To ułatwia zarówno interpretację diagramów, jak i pisanie złączeń JOIN.
