Kwalifikacje w Zawodzie - Testy zawodowe online | Egzaminy Zawodowe

KWALIFIKACJA INF3 - CZERWIEC 2016


PYTANIE NR 23.
Wskaż poprawną zasadę dotyczącą spójności danych w bazie danych
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Klucz podstawowy identyfikuje rekord jednoznacznie, więc nie może przyjmować wartości NULL (pustej), bo rekord przestałby być poprawnie rozróżnialny. Klucz obcy może być NULL, jeśli relacja jest opcjonalna, a opis relacji 1..n nie polega na łączeniu kluczy obcych między sobą, lecz na powiązaniu klucza obcego z kluczem podstawowym.

Pełne wyjaśnienie:

W relacyjnych bazach danych spójność (integralność) danych realizuje się m.in. przez ograniczenia narzucane na kolumny i relacje między tabelami. Jedną z podstawowych zasad integralności encji jest to, że klucz podstawowy ma jednoznacznie identyfikować każdy rekord w tabeli. Z tego powodu nie powinien dopuszczać wartości NULL (czyli "brak wartości"), bo nie da się wtedy zagwarantować jednoznacznej identyfikacji wiersza.

Stwierdzenie "pole klucza podstawowego nie może być puste" oddaje tę zasadę w uproszczeniu. W praktyce warto pamiętać o rozróżnieniu: "puste" bywa potocznie używane, ale w bazach danych kluczowe jest, czy wartość jest NULL (brak), czy np. pustym tekstem ''. Wymóg integralności dotyczy przede wszystkim braku wartości (NULL) i unikalności.

Pozostałe stwierdzenia są mylące:

  • "pole klucza obcego nie może być puste" nie jest regułą ogólną. Klucz obcy może przyjmować NULL, jeśli powiązanie jest opcjonalne (np. rekord nie musi wskazywać rekordu nadrzędnego). Dopiero gdy wymagamy obowiązkowego powiązania, projektujemy kolumnę klucza obcego jako NOT NULL.
  • "pole klucza podstawowego musi posiadać utworzony indeks" bywa prawdą w wielu systemach jako efekt uboczny implementacji, ale jako zasada spójności danych jest to nieprecyzyjne: indeks dotyczy wydajności i egzekwowania unikalności, a nie jest sformułowaniem definicyjnym spójności w każdym ujęciu egzaminacyjnym.
  • "w relacji 1..n pole klucza obcego jest połączone z polem klucza obcego innej tabeli" opisuje relację błędnie. Typowo w relacji 1..n klucz obcy w tabeli po stronie "wiele" wskazuje klucz podstawowy (lub unikalny) tabeli po stronie "jeden", a nie inny klucz obcy.

Na egzaminie warto zapamiętać: PRIMARY KEY = identyfikator rekordu (unikalny, bez NULL), a FOREIGN KEY = odwołanie do rekordu w innej tabeli (czasem może być NULL), zależnie od tego, czy relacja jest obowiązkowa.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Co to jest klucz podstawowy w bazie danych?
Klucz podstawowy (PRIMARY KEY) to kolumna lub zestaw kolumn, które jednoznacznie identyfikują każdy rekord w tabeli. Jego wartości powinny być unikalne, a w typowym ujęciu nie dopuszcza się wartości NULL, aby nie było rekordów "bez tożsamości".
Dlaczego klucz podstawowy nie może być NULL?
Bo PRIMARY KEY ma gwarantować, że każdy rekord da się wskazać bez wątpliwości. Wartość NULL oznacza brak wartości, więc rekord nie miałby poprawnego identyfikatora. To łamie integralność encji i utrudnia powiązania z innymi tabelami.
Czy klucz obcy może mieć wartość NULL?
Tak, często może. Jeśli relacja jest opcjonalna (np. rekord może, ale nie musi mieć przypisanego rekordu nadrzędnego), to kolumna FOREIGN KEY może być NULL. Gdy relacja ma być obowiązkowa, wtedy projektuje się ją jako NOT NULL.
Jaka jest różnica między PRIMARY KEY a FOREIGN KEY?
PRIMARY KEY identyfikuje rekord w tej samej tabeli (unikalny identyfikator). FOREIGN KEY przechowuje wartość, która odwołuje się do klucza w innej (lub tej samej) tabeli, pilnując spójności powiązań między danymi.
Co oznacza relacja 1..n w bazie danych?
Relacja 1..n (jeden do wielu) oznacza, że jeden rekord tabeli nadrzędnej może być powiązany z wieloma rekordami tabeli podrzędnej. Zwykle realizuje się to tak, że tabela po stronie "wiele" ma kolumnę FOREIGN KEY wskazującą rekord po stronie "jeden".
Dlaczego nie łączy się klucza obcego z kluczem obcym w relacji 1..n?
W relacji 1..n potrzebujesz wskazać konkretny rekord nadrzędny. Dlatego FOREIGN KEY w tabeli podrzędnej odnosi się do PRIMARY KEY (lub innego unikalnego klucza) w tabeli nadrzędnej. Łączenie dwóch kluczy obcych nie daje jednoznacznej "tożsamości" rekordu docelowego.
Co to jest integralność encji w bazie danych?
Integralność encji to zasada, że każdy rekord w tabeli musi być rozróżnialny. W praktyce zapewnia ją PRIMARY KEY: wartości klucza są unikalne i nie powinny być NULL. Dzięki temu tabela nie zawiera rekordów, których nie da się jednoznacznie wskazać.
Co to jest spójność referencyjna i jak działa?
Spójność referencyjna (integralność referencyjna) pilnuje, aby wartości FOREIGN KEY wskazywały na istniejące rekordy w tabeli nadrzędnej. Jeśli próbujesz dodać klucz obcy odwołujący się do nieistniejącego rekordu, baza powinna to zablokować (zależnie od definicji ograniczeń).
Czy PRIMARY KEY zawsze tworzy indeks?
W wielu popularnych systemach baza tworzy indeks automatycznie, aby sprawnie egzekwować unikalność i przyspieszyć wyszukiwanie. Jednak w pytaniach egzaminacyjnych warto oddzielać zasady integralności (unikalność, brak NULL) od kwestii implementacyjnych i wydajnościowych (indeksy).
Jakie błędy najczęściej popełniają uczniowie przy kluczach w SQL?
Częste pomyłki to: mylenie NULL z pustym tekstem, zakładanie że FOREIGN KEY zawsze jest NOT NULL, błędny opis relacji 1..n (łączenie FK z FK), oraz traktowanie indeksu jako "wymogu spójności". Pomaga rysunek ERD i świadome rozróżnienie ról kluczy.
info

To pytanie poprawnie rozwiązuje 59% zdających egzamin. średnie

W praktyce zawodowej kluczowe jest to, że klucz podstawowy identyfikuje rekord jednoznacznie, więc nie może przyjmować wartości NULL (pustej), bo rekord przestałby być poprawnie rozróżnialny.

Źródła:

  • PostgreSQL Documentation: "PRIMARY KEY" (Constraints) — https://www.postgresql.org/docs/current/ddl-constraints.html (accessed 2026-03-02)
  • MySQL 8.0 Reference Manual: "CREATE TABLE ... PRIMARY KEY" — https://dev.mysql.com/doc/refman/8.0/en/create-table.html (accessed 2026-03-02)
  • MariaDB Documentation: "Constraints" (PRIMARY KEY, FOREIGN KEY) — https://mariadb.com/kb/en/constraint/ (accessed 2026-03-02)

Materiały:

  • Dokumentacja używanego SZBD (PostgreSQL/MySQL/MariaDB) dotycząca PRIMARY KEY i FOREIGN KEY
  • Podręcznik do projektowania relacyjnych baz danych (integralność encji i referencyjna)
  • Ćwiczenia praktyczne: tworzenie tabel z ograniczeniami PRIMARY KEY/FOREIGN KEY i testowanie wstawiania danych
Zobacz też:

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego