KWALIFIKACJA INF2 + INF3 - STYCZEŃ 2015

PYTANIE NR 17.
Wynikiem poniższego polecenia będzie wybranie kolumn
Ilustracja przedstawia fragment zapytania SQL, które jest częścią pytania egzaminacyjnego związanego z kwalifikacjami
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Poprawna interpretacja polecenia zakłada złączenie dwóch tabel po kluczach: tabela1.id odpowiada tabela2.id_pracownika. Wynik zapytania to wybór wskazanych kolumn (nazwisko i wynagrodzenie) zgodnie z tym dopasowaniem rekordów. Odpowiedzi łączące po nazwisku zmieniają sens relacji i są typowo błędne.

Pełne wyjaśnienie:

Pytanie sprawdza rozumienie, co zwraca zapytanie SQL łączące dwie tabele. Kluczowy jest warunek łączenia (JOIN/ON): jeżeli polecenie dopasowuje wiersze tak, że kolumna id w tabeli1 odpowiada kolumnie id_pracownika w tabeli2, to wynik zawiera dane tylko dla tych rekordów, które spełniają to dopasowanie.

Odpowiedź "nazwisko i wynagrodzenie z tabel: tabela1 i tabela2, gdy kolumna id w tabeli 1 odpowiada kolumnie id_pracownika w tabeli2" oddaje sens relacji klucz główny–klucz obcy: w praktyce tabela1 przechowuje rekord pracownika (z identyfikatorem), a tabela2 rekord powiązany z pracownikiem (np. wynagrodzenie) wskazujący na pracownika przez id_pracownika.

Dlaczego pozostałe odpowiedzi są niepoprawne?

  • "... z tabeli1, gdy nazwisko w tabeli1 odpowiada nazwisku w tabeli2" błędnie zakłada łączenie po nazwisku. Nazwisko nie jest dobrym, jednoznacznym kluczem (może się powtarzać, może się zmieniać), a jeśli w poleceniu występuje warunek id = id_pracownika, to nie wolno go zastępować innym kryterium.
  • "... z tabeli2, gdy nazwisko w tabeli1 odpowiada nazwisku w tabeli2" ma ten sam problem: zmienia warunek dopasowania na nazwisko i dodatkowo sugeruje, że wynik dotyczy wyłącznie tabeli2, co nie odpowiada typowemu zapytaniu wybierającemu kolumny wskazane w SELECT z kontekstu złączenia.
  • "nazwisko i wynagrodzenie z tabel: tabelal i tabela2" jest nieprecyzyjne: nie podaje warunku łączenia (a to on decyduje, które rekordy trafią do wyniku) i zawiera literówkę w nazwie tabeli, co w SQL mogłoby oznaczać całkiem inny obiekt lub błąd składni.

Wskazówka egzaminacyjna: zawsze najpierw odczytaj ON (po czym łączysz tabele), a dopiero potem SELECT (jakie kolumny wyświetlasz). To minimalizuje pomyłki między łączeniem po identyfikatorze a łączeniem po polu tekstowym.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
JOIN służy do łączenia wierszy z dwóch (lub więcej) tabel na podstawie warunku dopasowania, zwykle relacji klucz główny–klucz obcy. Dzięki temu można w jednym wyniku pokazać np. dane pracownika z jednej tabeli i powiązane wynagrodzenie z drugiej.
Sprawdź część warunku łączenia, najczęściej po słowie ON. To tam jest zapisane, które kolumny mają być równe (np. tabela1.id = tabela2.id_pracownika). Ten fragment decyduje, które rekordy zostaną dopasowane.
Nazwisko nie jest zwykle unikalne ani stabilne (mogą istnieć dwie osoby o tym samym nazwisku, a dane mogą się zmienić). Łączenie po takim polu może zwrócić zduplikowane lub błędnie dopasowane rekordy. Bezpieczniej łączyć po identyfikatorach (id).
Najczęściej jest to klucz obcy wskazujący na pracownika w innej tabeli. Oznacza to, że rekord wynagrodzenia "należy" do konkretnego pracownika, a złączenie po id i id_pracownika pozwala połączyć dane osobowe z danymi płacowymi w jednym wyniku.
Oznacza to, że wynik zawiera konkretne kolumny wskazane w SELECT, ale ich wartości mogą pochodzić z różnych tabel objętych złączeniem. Żeby dane "pasowały" do siebie, muszą być dopasowane przez warunek JOIN/ON, a nie przypadkowo zestawione.
Tak, w praktyce INNER JOIN zwraca tylko te wiersze, dla których istnieje dopasowanie po warunku łączenia w obu tabelach. Jeśli dla danego id nie ma odpowiadającego id_pracownika, taki rekord nie pojawi się w wyniku INNER JOIN.
Częsty błąd to ignorowanie warunku ON i skupienie się tylko na nazwach kolumn w SELECT. Inny błąd to mylenie, z której tabeli pochodzi dana kolumna, lub zakładanie łączenia po polu tekstowym (np. nazwisku), mimo że w zapytaniu łączy się po identyfikatorach.
Najpewniej, gdy zapytanie używa prefiksów (np. tabela1.nazwisko). Jeśli ich nie ma, trzeba znać schemat tabel. Na egzaminie warto zwracać uwagę na aliasy i prefiksy, bo jednoznacznie wskazują źródło kolumny.
Klucz obcy stosuje się, gdy jedna tabela ma wskazywać rekord w innej tabeli w sposób jednoznaczny i spójny. To standard w relacyjnych bazach danych: zamiast trzymać nazwisko w wielu tabelach, przechowuje się id, a pełne dane pobiera przez JOIN.
Ćwicz czytanie zapytań: najpierw określ tabele i typ złączenia, potem warunek ON, a na końcu listę kolumn w SELECT. Rozwiązuj krótkie zadania na relacje 1:N (np. pracownik–wynagrodzenie) i sprawdzaj, jak zmienia się wynik dla różnych warunków.
info

Około 47% zdających odpowiada poprawnie na to pytanie. trudne

Według specjalistów z branży: "Poprawna interpretacja polecenia zakłada złączenie dwóch tabel po kluczach: tabela1.id odpowiada tabela2.id_pracownika."

Źródła:

  • PostgreSQL Documentation: Queries - Joins Between Tables, https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-JOIN (dostęp: 2026-02-27)
  • MySQL 8.0 Reference Manual: JOIN Clause, https://dev.mysql.com/doc/refman/8.0/en/join.html (dostęp: 2026-02-27)
  • Microsoft Learn: FROM (Transact-SQL) i JOINS (sekcja o INNER JOIN), https://learn.microsoft.com/en-us/sql/t-sql/queries/from-transact-sql (dostęp: 2026-02-27)

Materiały:

  • Dokumentacja SQL dla wybranego silnika (sekcja JOIN/INNER JOIN)
  • Kurs podstaw relacyjnych baz danych (relacje, klucze, normalizacja)
  • Zadania praktyczne: pisanie zapytań SELECT z JOIN na 2–3 tabelach

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego