KWALIFIKACJA INF3 - CZERWIEC 2024 (test 2)

PYTANIE NR 21.
Tabele: Studenci, Zapisy, Zajecia są powiązane relacją. Aby wybrać jedynie nazwiska studentów oraz odpowiadające im idZajecia dla studentów z grupy 15, należy wydać kwerendę
Ilustracja przedstawia diagram bazy danych, który jest używany w kontekście egzaminu zawodowego dla technika programisty,
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Poprawne jest zapytanie łączące Studenci z Zapisy po kluczu Studenci.id = Zapisy.idStudenta oraz filtrujące grupę w WHERE.
Kolumna idZajecia jest w tabeli Zapisy, więc nie trzeba dołączać tabeli Zajecia, jeśli nie pobieramy jej pól.

Pełne wyjaśnienie:

W schemacie relacyjnym tabela Zapisy pełni rolę tabeli łącznikowej (asocjacyjnej) dla relacji wiele-do-wielu między Studenci i Zajecia. Zawiera więc co najmniej dwa klucze obce: idStudenta (do Studenci.id) oraz idZajecia (do Zajecia.id).

Aby zwrócić wyłącznie nazwiska studentów oraz odpowiadające im idZajecia dla studentów z grupy 15, potrzeba:

  • złączenia tabel Studenci i Zapisy po właściwych kolumnach kluczy: Studenci.id = Zapisy.idStudenta (to jest sens klauzuli ON),
  • filtrowania wyników po kolumnie Studenci.grupa w klauzuli WHERE, aby ograniczyć wyniki do grupy 15,
  • wskazania w SELECT dwóch kolumn: nazwisko (z Studenci) i idZajecia (z Zapisy).

Zapytanie oznaczone jako poprawne spełnia te warunki: wybiera nazwisko i idZajecia, wykonuje JOIN po prawidłowym kluczu obcym oraz zawiera WHERE grupa = 15. Ponieważ idZajecia znajduje się w tabeli Zapisy, dołączenie tabeli Zajecia nie jest konieczne, jeśli nie pobieramy np. nazwy zajęć.

Dlaczego pozostałe propozycje są błędne:

  • Wariant bez WHERE zwróci rekordy dla wszystkich grup, więc nie spełnia warunku "dla studentów z grupy 15".
  • Wariant z warunkiem Studenci.id = Zapisy.idZajecia łączy niepowiązane logicznie kolumny (klucz studenta z identyfikatorem zajęć). Taki JOIN daje semantycznie niepoprawne dopasowania i przypadkowe wyniki.
  • Wariant bez klauzuli ON (przy INNER JOIN) jest w typowym SQL niepoprawny składniowo albo prowadzi do niezamierzonego iloczynu kartezjańskiego, a dodatkowo nie definiuje relacji między kluczami.

Wskazówka egzaminacyjna: zawsze sprawdzaj, w której tabeli faktycznie jest potrzebna kolumna. Jeśli pole jest w tabeli pośredniej (Zapisy), często da się uniknąć dodatkowego JOIN, co upraszcza zapytanie i zmniejsza ryzyko błędnego powiązania kluczy.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Tabela łącznikowa (asocjacyjna) przechowuje powiązania między rekordami dwóch tabel, gdy relacja jest wiele-do-wielu. Zwykle zawiera dwa klucze obce, np. idStudenta i idZajecia, dzięki czemu jeden student może mieć wiele zapisów na różne zajęcia.
Najczęściej widać trzecią tabelę pośrednią połączoną relacjami z dwiema tabelami głównymi. Ta tabela ma zwykle dwa pola będące kluczami obcymi. Jeśli student może mieć wiele zajęć i jedne zajęcia mogą mieć wielu studentów, to jest typowa relacja wiele-do-wielu.
Nie trzeba, ponieważ wymagane są tylko: nazwisko (z tabeli Studenci) oraz idZajecia (z tabeli Zapisy). Skoro identyfikator zajęć jest już w Zapisy, to dołączenie Zajecia ma sens dopiero wtedy, gdy chcesz pobrać np. nazwę zajęć albo prowadzącego.
Klauzula ON definiuje warunek połączenia tabel, czyli które wiersze mają do siebie pasować (np. klucz główny do klucza obcego). Bez poprawnego ON łatwo o błędne dopasowania lub wyniki przypadkowe. Filtrowanie (np. grupa=15) zwykle robi się w WHERE.
WHERE filtruje już połączone wyniki. W tym typie zadań to właśnie WHERE ogranicza rekordy do warunku, np. tylko studenci z grupy 15. Jeśli pominiesz WHERE, dostaniesz wyniki dla wszystkich grup, nawet gdy sam JOIN jest poprawny.
W większości silników baz danych samo słowo JOIN oznacza domyślnie INNER JOIN. Oba warianty zwracają tylko te wiersze, które spełniają warunek złączenia. Różnica jest głównie stylistyczna, ale zawsze sprawdź, czy zapytanie ma poprawne ON i wymagany filtr WHERE.
Typowe pomyłki to: łączenie niewłaściwych kolumn (np. id studenta z id zajęć), pomijanie jednej strony klucza obcego, albo zgadywanie po nazwie zamiast sprawdzenia schematu. Dobra praktyka: dopasuj klucz główny tabeli A do klucza obcego w tabeli pośredniej.
Zwykle nie. W klasycznym zapisie INNER JOIN powinien mieć warunek ON. Bez niego zapytanie bywa błędne składniowo albo zamienia się w niezamierzone łączenie "każdy z każdym" (iloczyn kartezjański), co daje ogromny i błędny zbiór wyników.
Alias to krótka nazwa tabeli używana w zapytaniu, np. Studenci jako S, Zapisy jako Z. Ułatwia czytanie i skraca zapis, szczególnie przy wielu tabelach. Alias nie zmienia logiki zapytania, ale pomaga uniknąć niejednoznaczności, gdy różne tabele mają kolumny o tej samej nazwie.
Trzeba wtedy dołączyć tabelę zajęć, bo nazwa jest w Zajecia. W praktyce dodajesz dodatkowy JOIN Zapisy–Zajecia po kluczu idZajecia = Zajecia.id i w SELECT wybierasz nazwę. To typowy krok, gdy chcesz "rozwinąć" identyfikator do danych opisowych.
info

Statystycznie 54% uczniów zna prawidłową odpowiedź. trudne

Według specjalistów z branży: "Poprawne jest zapytanie łączące Studenci z Zapisy po kluczu Studenci.id = Zapisy.idStudenta oraz filtrujące grupę w WHERE."

Źródła:

  • PostgreSQL Documentation: 7.2. Table Expressions (JOIN, ON, WHERE), https://www.postgresql.org/docs/current/queries-table-expressions.html - dostęp 2026-03-01
  • MySQL 8.0 Reference Manual: 13.2.13 SELECT Statement (JOIN syntax, WHERE filtering), https://dev.mysql.com/doc/refman/8.0/en/select.html - dostęp 2026-03-01
  • SQLite Documentation: SELECT statement (FROM, JOIN, WHERE), https://www.sqlite.org/lang_select.html - dostęp 2026-03-01

Materiały:

  • Dokumentacja SQL dla używanego silnika (np. PostgreSQL/MySQL/SQLite) – sekcje SELECT i JOIN
  • Materiały o modelowaniu relacyjnym: klucze główne/obce i tabele pośrednie
  • Ćwiczenia: projektowanie relacji wiele-do-wielu i pisanie zapytań z JOIN + WHERE

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego