W relacyjnej bazie danych relacja jeden do wielu zwykle oznacza, że jedna pozycja w tabeli "po stronie 1" (np. jeden adres) może być powiązana z wieloma rekordami "po stronie N" (np. wiele osób może wskazywać ten sam adres). Technicznie realizuje się to przez klucz obcy w tabeli po stronie "wiele".
Aby wyświetlić nazwiska i przypisane miasta, zapytanie musi:
- pobrać kolumnę z tabeli Osoby (np. nazwisko),
- pobrać kolumnę z tabeli Adresy (np. Miasto),
- połączyć rekordy warunkiem zgodnym z relacją, czyli klucz obcy = klucz główny.
Spełnia to zapytanie: SELECT nazwisko, Miasto FROM Osoby JOIN Adresy ON Osoby.Adresy_id = Adresy.id;. Złączenie JOIN (domyślnie typu INNER) zwróci tylko te osoby, dla których istnieje pasujący rekord w tabeli Adresy.
Dlaczego pozostałe odpowiedzi są błędne?
- Łączenie po Osoby.id = Adresy.id jest niepoprawne, jeśli relacja jest zdefiniowana przez Osoby.Adresy_id. To typowy błąd "zgadywania", że kolumny id zawsze się parują, co prowadzi do losowych lub pustych dopasowań.
- Błędna składnia z podwójnym FROM nie wykona się w poprawnym SQL — to nie jest prawidłowa konstrukcja SELECT.
- Brak warunku łączenia (same dwie tabele w FROM) tworzy iloczyn kartezjański: każda osoba zostanie zestawiona z każdym adresem, więc miasta nie będą "przyporządkowane", tylko powielone w wielu kombinacjach.
Wskazówka egzaminacyjna: gdy widzisz relację 1:N i chcesz "dopiąć" dane z tabeli powiązanej, szukaj w tabeli po stronie N kolumny będącej kluczem obcym (np. *_id) i użyj jej w warunku ON.
