KWALIFIKACJA INF3 - PAŹDZIERNIK 2016

PYTANIE NR 20.
Baza danych księgarni zawiera tabelę ksiazki z polami: id, idAutor, tytul, ileSprzedanych oraz tabelę autorzy z polami: id, imie, nazwisko. Aby stworzyć raport sprzedanych książek z tytułami i nazwiskami autorów, należy
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Raport z tytułami i nazwiskami wymaga danych z dwóch tabel, więc trzeba je powiązać relacją autor–książka (zwykle 1..N: jeden autor, wiele książek) i wykonać kwerendę ze złączeniem (JOIN) po kluczu obcym.
Same kwerendy jednotabelowe lub relacja 1..1 nie zapewnią poprawnego powiązania rekordów.

Pełne wyjaśnienie:

Aby otrzymać zestawienie "sprzedane książki" zawierające jednocześnie tytuł (z tabeli ksiazki) oraz nazwisko autora (z tabeli autorzy), trzeba połączyć informacje z dwóch różnych tabel. W modelu relacyjnym robi się to przez:

  • zdefiniowanie relacji o odpowiedniej krotności, wynikającej z kluczy: pole ksiazki.idAutor wskazuje na autorzy.id, więc typowo jest to relacja 1..N (jeden autor może mieć wiele książek, a każda książka wskazuje jednego autora),
  • kwerendę łączącą (JOIN), która zestawia w jednym wyniku wiersze z obu tabel na podstawie warunku zgodności klucza obcego, np. logicznie: ksiazki.idAutor = autorzy.id.

Odpowiedź "stworzyć kwerendę wyszukującą tytuły książek" jest niewystarczająca, bo zwraca pola tylko z jednej tabeli i nie dostarcza nazwisk autorów. Podobnie "stworzyć dwie osobne kwerendy" nie gwarantuje poprawnego skojarzenia konkretnych książek z konkretnymi autorami w jednym raporcie – bez złączenia pozostają dwa niezależne zbiory wyników.

Wariant z relacją 1..1 jest co do zasady nieadekwatny: wymuszałby, że jeden autor ma dokładnie jedną książkę i odwrotnie, co nie odpowiada typowemu modelowi księgarni. W raportowaniu i aplikacjach webowych taka relacja prowadziłaby do błędów projektowych lub sztucznego ograniczania danych.

Wskazówka egzaminacyjna: jeśli w treści jest "pola z dwóch tabel", w większości przypadków szukaj odpowiedzi zawierającej JOIN/złączenie oraz poprawną relację klucz obcy → klucz główny.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Relacja 1..N oznacza, że jednemu rekordowi w tabeli "po stronie 1" może odpowiadać wiele rekordów w tabeli "po stronie N". Rozpoznasz ją po kluczu obcym: np. ksiazki.idAutor wskazuje na autorzy.id, więc jeden autor może mieć wiele książek.
Kluczem obcym jest idAutor w tabeli ksiazki, ponieważ przechowuje identyfikator autora i wskazuje na pole id w tabeli autorzy. To powiązanie pozwala łączyć dane o książce z danymi autora w jednej kwerendzie.
JOIN jest potrzebny, bo tytuł znajduje się w tabeli książek, a nazwisko w tabeli autorów. Bez złączenia otrzymasz dane tylko z jednej tabeli. JOIN łączy wiersze na podstawie zgodnych wartości (np. ksiazki.idAutor = autorzy.id), dzięki czemu raport ma komplet informacji.
Przykładowo (logika złączenia): SELECT tytul, nazwisko FROM ksiazki JOIN autorzy ON ksiazki.idAutor = autorzy.id. W praktyce możesz dodać filtr lub sortowanie, np. po ileSprzedanych, aby uzyskać raport sprzedaży.
Zwykle nie. Relacja 1..1 oznaczałaby, że jeden autor ma dokładnie jedną książkę w bazie i ta książka ma dokładnie jednego autora. W realnych danych autor może mieć wiele tytułów, dlatego typowym wyborem jest 1..N (autor → książki) lub dodatkowa tabela pośrednia przy wielu autorach.
Relacja N..M jest potrzebna, gdy jedna książka może mieć wielu autorów, a jeden autor może pisać wiele książek. Wtedy nie wystarczy pojedyncze pole idAutor w tabeli książek – stosuje się tabelę łącznikową (np. "ksiazki_autorzy") przechowującą pary identyfikatorów.
Najczęstsze błędy to: brak warunku złączenia (powstaje "iloczyn" rekordów), złączenie po złych polach (np. po nazwisku zamiast po identyfikatorze), użycie relacji 1..1 zamiast 1..N oraz próba robienia raportu z dwóch osobnych kwerend bez powiązania wyników w jedną spójną tabelę.
Spójność sprawdzisz, gdy każda wartość ksiazki.idAutor ma odpowiadający rekord w autorzy. W systemach baz danych wymusza to klucz obcy (FOREIGN KEY). Praktycznie: brak "osieroconych" książek bez autora i brak możliwości usunięcia autora, jeśli są do niego przypisane książki (zależnie od reguł).
W wielu środowiskach tak: możesz napisać zapytanie z JOIN bez "rysowania" relacji w GUI. Jednak logicznie relacja nadal istnieje (klucz obcy → klucz główny). W projektach i na egzaminie warto umieć zarówno rozumieć relacje, jak i łączyć tabele kwerendą.
Ćwicz na prostych modelach (klienci–zamówienia, autorzy–książki): wyznacz klucz główny, wskaż klucz obcy, określ krotność (1..N lub N..M) i napisz SELECT z JOIN. Sprawdzaj, czy wynik ma tyle wierszy, ile oczekujesz, i czy pola pochodzą z właściwych tabel.
info

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

Źródła:

  • PostgreSQL Documentation: "Joins Between Tables" (SELECT, JOIN) https://www.postgresql.org/docs/current/tutorial-join.html - accessed 2026-03-02
  • MySQL 8.0 Reference Manual: "JOIN Clause" https://dev.mysql.com/doc/refman/8.0/en/join.html - accessed 2026-03-02
  • SQLite Documentation: "SELECT" (JOIN syntax) https://www.sqlite.org/lang_select.html - accessed 2026-03-02

Materiały:

  • Dokumentacja SQL dotycząca JOIN (wybrany silnik: MySQL/PostgreSQL/SQLite)
  • Materiały o normalizacji i relacjach w bazach danych (klucze, integralność referencyjna)
  • Ćwiczenia: projekt ERD dla księgarni i zapytania SELECT z JOIN

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego