KWALIFIKACJA INF3 - TEST WIEDZY NR 4

PYTANIE NR 24.
Rozważ następującą tabelę:
ID Imię Nazwisko
1 Jan Kowalski
2 Anna Nowak
3 Piotr Wiśniewski
Który z poniższych atrybutów jest kluczem relacji w tej tabeli?
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Klucz relacji (klucz główny) to atrybut, który jednoznacznie identyfikuje każdy wiersz tabeli. W podanej tabeli wartość "ID" jest różna dla każdego rekordu, więc może pełnić rolę klucza. Same "Imię" lub "Nazwisko", ani ich zestaw, nie muszą być unikalne w danych.

Pełne wyjaśnienie:

W modelu relacyjnym klucz (w praktyce najczęściej klucz główny) to taki atrybut lub zestaw atrybutów, który pozwala jednoznacznie wskazać pojedynczy rekord w tabeli. Oznacza to, że dla dwóch różnych wierszy nie może wystąpić ta sama wartość klucza oraz że klucz powinien być możliwie stabilny.

Odpowiedź "ID" jest właściwa, ponieważ w przykładzie każda osoba ma inną wartość ID (1, 2, 3). Takie pole jest typowym identyfikatorem technicznym i bardzo często projektuje się je właśnie jako klucz główny, aby relacje między tabelami (klucze obce) były proste i odporne na zmiany danych opisowych.

  • "Imię" nie jest dobrym kluczem, bo wiele osób może mieć to samo imię. Nawet jeśli w małej próbce danych się nie powtarza, w realnej bazie szybko pojawią się duplikaty.
  • "Nazwisko" również zwykle się powtarza, więc nie gwarantuje jednoznacznej identyfikacji rekordu.
  • "Imię i Nazwisko" może wydawać się bardziej "dokładne", ale nadal nie zapewnia unikalności (istnieją osoby o tym samym imieniu i nazwisku). Dodatkowo takie dane mogą się zmieniać (np. zmiana nazwiska), co utrudniałoby utrzymanie spójności powiązań.

Wskazówka egzaminacyjna: jeśli wśród atrybutów widzisz pole typu ID/liczba porządkowa i jest ono różne dla każdego rekordu, to najczęściej jest to kandydat na klucz główny. Natomiast dane osobowe traktuj jako potencjalnie nieunikalne, chyba że zadanie wyraźnie podaje ograniczenie unikalności.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Klucz główny to kolumna (lub zestaw kolumn), która jednoznacznie identyfikuje każdy rekord w tabeli. Jego wartości nie powinny się powtarzać, a w praktyce zwykle nie mogą być puste. Najczęściej stosuje się techniczne pole typu ID, aby łatwo łączyć tabele i utrzymywać spójność danych.
Sprawdź, czy wartości w kolumnie są unikalne dla wszystkich wierszy oraz czy mają sens jako identyfikator. Kolumna typu "ID" z kolejnymi liczbami zwykle spełnia ten warunek. Dane opisowe (np. imię, nazwisko) często się powtarzają, więc rzadko są dobrym kluczem.
Imię nie gwarantuje unikalności, bo wiele osób może mieć to samo imię. W konsekwencji nie da się wskazać jednego rekordu wyłącznie na podstawie imienia. Klucz ma identyfikować rekord jednoznacznie, a nie tylko go opisywać, dlatego imię jest typowym przykładem atrybutu niekluczowego.
Zwykle nie, ponieważ nazwiska powtarzają się w populacji i nie zapewniają jednoznacznej identyfikacji. Dodatkowo nazwisko może ulec zmianie (np. po ślubie), co utrudniałoby utrzymanie relacji z innymi tabelami. Klucz główny powinien być stabilny i możliwie niezależny od danych osobowych.
Nie zawsze. Mogą istnieć różne osoby o tym samym imieniu i nazwisku, więc taki zestaw nie daje gwarancji unikalności. Nawet jeśli w małej próbce danych jest unikalny, w realnym systemie może przestać być. Bez dodatkowego ograniczenia unikalności lub dodatkowych pól to ryzykowny wybór.
Klucz kandydujący to atrybut lub zestaw atrybutów, które potencjalnie mogą pełnić rolę klucza głównego, bo jednoznacznie identyfikują rekord. Z kluczy kandydujących wybiera się klucz główny. Pozostałe (jeśli istnieją) mogą być zabezpieczone ograniczeniem unikalności.
W SQL służy do tego ograniczenie PRIMARY KEY. Po jego zdefiniowaniu DBMS pilnuje, aby nie dało się wstawić dwóch rekordów z tą samą wartością klucza. W wielu systemach PRIMARY KEY oznacza także automatyczne utworzenie indeksu, co przyspiesza wyszukiwanie po tym polu.
ID jest proste, krótkie i stabilne: nie zależy od danych użytkownika, które mogą się zmieniać. Ułatwia tworzenie relacji (np. zamówienie → użytkownik) oraz integrację z frameworkami i ORM. Dzięki temu zapytania i indeksy są wydajne, a spójność między tabelami łatwiejsza do utrzymania.
Częsty błąd to wybór pola "wyglądającego na ważne" (np. nazwisko) zamiast pola unikalnego. Inny błąd to zakładanie, że kombinacja dwóch pól zawsze jest unikalna. Warto też uważać na mylenie klucza głównego z kluczem obcym oraz na sytuacje, gdy zadanie nie mówi wprost o unikalności.
Przećwicz rozpoznawanie kluczy na przykładach tabel oraz zapis w SQL DDL: PRIMARY KEY, UNIQUE, FOREIGN KEY. Pomaga także rysowanie prostych modeli (encje i relacje) oraz analiza, które pola są stabilnymi identyfikatorami. Rozwiązuj zadania z łączenia tabel po kluczach.
info

Około 81% zdających odpowiada poprawnie na to pytanie. średnio łatwe

W praktyce zawodowej kluczowe jest to, że klucz relacji (klucz główny) to atrybut, który jednoznacznie identyfikuje każdy wiersz tabeli.

Źródła:

  • PostgreSQL Documentation: "CREATE TABLE" / "PRIMARY KEY" constraint, https://www.postgresql.org/docs/current/ddl-constraints.html (accessed 2026-03-01)
  • MySQL 8.0 Reference Manual: "PRIMARY KEY" definition and behavior, https://dev.mysql.com/doc/refman/8.0/en/constraint-primary-key.html (accessed 2026-03-01)
  • SQLite Documentation: "CREATE TABLE" constraints (PRIMARY KEY), https://www.sqlite.org/lang_createtable.html (accessed 2026-03-01)

Materiały:

  • Dokumentacja DBMS: sekcje o PRIMARY KEY (np. PostgreSQL, MySQL)
  • Podręcznik do podstaw baz danych: model relacyjny, klucze, normalizacja
  • Zadania praktyczne: projekt tabeli i wskazywanie klucza głównego dla przykładowych danych

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego