KWALIFIKACJA INF3 - CZERWIEC 2021

PYTANIE NR 12.
Który z typów relacji wymaga utworzenia tabeli pośredniej łączącej klucze główne obu tabel?
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Relacja n..m (wiele-do-wielu) nie może być poprawnie odwzorowana jednym kluczem obcym w jednej z tabel.
Stosuje się więc tabelę pośrednią, która przechowuje pary kluczy głównych obu tabel (zwykle jako dwa klucze obce). Relacje 1..n lub 1..1 realizuje się bezpośrednio kluczem obcym.

Pełne wyjaśnienie:

W modelu relacyjnym sposób odwzorowania relacji zależy od jej krotności (liczby powiązań między rekordami).

Relacja n..m (wiele-do-wielu) oznacza, że jeden rekord z pierwszej tabeli może być powiązany z wieloma rekordami drugiej tabeli, a jednocześnie jeden rekord z drugiej tabeli może być powiązany z wieloma rekordami pierwszej tabeli. Tego nie da się poprawnie zapisać pojedynczym polem-kluczem obcym w jednej tabeli, bo musiałoby ono przechowywać "wiele wartości" (co łamie zasady poprawnego projektu i utrudnia integralność).

Dlatego tworzy się tabelę pośrednią (łączącą, asocjacyjną), która zawiera co najmniej:

  • dwa klucze obce: do tabeli A i do tabeli B,
  • często klucz główny złożony z tych dwóch kolumn lub osobny identyfikator,
  • ewentualne atrybuty relacji (np. ilość produktu w zamówieniu, data nadania roli użytkownikowi).

Dlaczego pozostałe odpowiedzi są błędne?

  • 1..n: wystarczy dodać klucz obcy po stronie "n" wskazujący rekord po stronie "1" (bez tabeli pośredniej).
  • n..1: to w praktyce ta sama sytuacja co 1..n, tylko opisana z drugiej strony; również wystarcza klucz obcy po stronie "n".
  • 1..1: zwykle wystarcza klucz obcy z ograniczeniem unikalności (UNIQUE) lub scalenie tabel, jeśli ma to sens projektowy.

Wskazówka egzaminacyjna: jeśli w opisie relacji pojawia się "wiele po obu stronach", niemal zawsze oznacza to potrzebę tabeli pośredniej i dwóch kluczy obcych.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Relacja n..m (wiele-do-wielu) oznacza, że jeden rekord z tabeli A może łączyć się z wieloma rekordami tabeli B oraz odwrotnie. Typowym przykładem są zamówienia–produkty: zamówienie ma wiele produktów, a produkt może wystąpić w wielu zamówieniach.
Bo pojedyncza kolumna klucza obcego nie może przechowywać wielu powiązań bez łamania zasad projektu (np. trzymania listy identyfikatorów w jednym polu). Tabela pośrednia przechowuje pary kluczy obcych i pozwala zachować integralność oraz wygodne zapytania JOIN.
Minimum to dwa klucze obce: jeden do tabeli A i drugi do tabeli B. Często te dwie kolumny tworzą klucz główny złożony. Jeśli relacja ma własne dane (np. ilość, data), te atrybuty też umieszcza się w tabeli pośredniej.
Szukaj sygnału "wiele po obu stronach": wiele A do wielu B. Jeśli w opisie domeny da się sensownie powiedzieć: "A ma wiele B" i jednocześnie "B ma wiele A", to jest to n..m. Wtedy typową odpowiedzią jest tabela pośrednia.
Zwykle nie. Relację 1..n realizuje się przez dodanie klucza obcego w tabeli po stronie "n", który wskazuje rekord po stronie "1". Tabela pośrednia jest potrzebna dopiero wtedy, gdy "wiele" występuje po obu stronach lub gdy chcesz modelować atrybuty samego powiązania.
To ta sama krotność opisana z innej perspektywy. W obu przypadkach istnieje jedna strona "1" i druga strona "n". Implementacja w SQL wygląda tak samo: klucz obcy umieszcza się po stronie "n", bo tam znajduje się wiele rekordów wskazujących na jeden rekord drugiej tabeli.
Relacja 1..1 oznacza, że jeden rekord z tabeli A odpowiada co najwyżej jednemu rekordowi z tabeli B. W praktyce stosuje się klucz obcy z ograniczeniem UNIQUE (lub wspólny klucz główny). Często rozdziela się tabele, gdy dane są opcjonalne lub rzadko używane.
Nie zawsze. Często klucz złożony (A_id, B_id) jest naturalny i zapobiega duplikatom par. Czasem jednak dodaje się osobny identyfikator (surrogate key), gdy relacja ma dodatkowe atrybuty, a projekt wymaga łatwiejszego odwoływania się do wiersza (np. w ORM).
Najczęstsze błędy to: trzymanie listy identyfikatorów w jednym polu (np. "1,2,3"), brak ograniczeń kluczy obcych, duplikowanie tych samych par w tabeli pośredniej bez kontroli (brak UNIQUE/PK), oraz mylenie n..m z 1..n i próba dodania FK w złej tabeli.
Ćwicz na przykładach domen: sklep, blog, szkoła, rezerwacje. Dla każdej pary encji zapisz krotność (1..1, 1..n, n..m) i narysuj prosty ERD. Potem przełóż to na tabele: gdzie jest klucz obcy, a kiedy potrzebna jest tabela pośrednia.
info

Około 55% zdających odpowiada poprawnie na to pytanie. średnie

Eksperci podkreślają: "Relacje 1..n lub 1..1 realizuje się bezpośrednio kluczem obcym."

Źródła:

  • Microsoft Learn: "Many-to-many relationships" (Database design) - https://learn.microsoft.com/en-us/office/troubleshoot/access/database-design/many-to-many-relationships - accessed 2026-02-18
  • MySQL 8.0 Reference Manual: "FOREIGN KEY Constraints" (dla zrozumienia implementacji relacji przez klucze obce) - https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html - accessed 2026-02-18
  • PostgreSQL Documentation (current): "Foreign Keys" - https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK - accessed 2026-02-18

Materiały:

  • Dokumentacja wybranego silnika SQL (sekcje o kluczach obcych i relacjach many-to-many)
  • Materiały kursowe z modelowania ERD i normalizacji (1NF–3NF)
  • Ćwiczenia praktyczne: zaprojektuj schemat i utwórz tabelę pośrednią z dwoma kluczami obcymi

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego