KWALIFIKACJA INF3 - TEST WIEDZY NR 3

PYTANIE NR 33.
Przyjrzyj się poniższemu kodowi SQL:
CREATE TABLE Klienci (
    ID INT PRIMARY KEY,
    Imie VARCHAR(100),
    Nazwisko VARCHAR(100),
    Email VARCHAR(100) UNIQUE
);
Które stwierdzenie jest prawdziwe na temat tej tabeli?
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Ograniczenie UNIQUE przy kolumnie Email oznacza, że wartości w tej kolumnie nie mogą się powtarzać między rekordami, co zapobiega duplikatom adresów e-mail. Klucz główny jest w kolumnie ID, więc ID nie może mieć duplikatów, a Nazwisko nie jest kluczem.

Pełne wyjaśnienie:

W definicji tabeli zastosowano dwa kluczowe typy ograniczeń integralności danych:

  • PRIMARY KEY dla kolumny ID – identyfikuje jednoznacznie każdy rekord. W praktyce oznacza to brak duplikatów wartości ID oraz brak wartości pustych w kluczu głównym (szczegóły implementacyjne mogą zależeć od DBMS, ale idea jest stała).
  • UNIQUE dla kolumny Email – ma na celu uniemożliwienie wstawienia dwóch rekordów z takim samym adresem e-mail. Dzięki temu email może pełnić rolę unikalnego identyfikatora kontaktowego (np. do logowania lub komunikacji).

Dlatego zdanie "Kolumna Email musi mieć unikalne wartości dla każdego rekordu." jest prawdziwe w sensie reguły, którą projektant chce wymusić: brak powtórzeń w tej kolumnie.

Dlaczego pozostałe stwierdzenia są nieprawdziwe?

  • "Wszystkie kolumny mogą mieć wartości NULL." – nie wynika to z definicji; dodatkowo klucz główny ma wymuszać identyfikację rekordu, więc dopuszczenie NULL dla ID byłoby sprzeczne z jego rolą (konkretne reguły egzekwuje DBMS).
  • "Kolumna ID może mieć duplikaty." – PRIMARY KEY nie pozwala na duplikaty, bo wtedy rekordy nie byłyby jednoznacznie identyfikowalne.
  • "Kolumna Nazwisko jest kluczem głównym." – w kodzie wyraźnie wskazano PRIMARY KEY przy kolumnie ID, a nie przy Nazwisko.

Wskazówka egzaminacyjna: zawsze szukaj w kodzie słów kluczowych PRIMARY KEY i UNIQUE, bo to one bezpośrednio mówią o zakazie duplikatów. Nazwy kolumn (np. "Nazwisko") nie przesądzają o roli w tabeli.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Ograniczenie UNIQUE wymusza, aby ta sama wartość nie pojawiła się wielokrotnie w danej kolumnie. W praktyce chroni przed duplikatami (np. identycznymi adresami e-mail) i podnosi jakość danych. Dokładne zachowanie dla wartości NULL może zależeć od silnika bazy.
PRIMARY KEY zapewnia jednoznaczną identyfikację każdego klienta. Dzięki temu łatwo odwoływać się do rekordu w innych tabelach (relacje), indeksować dane i unikać sytuacji, w której dwa rekordy "wyglądają tak samo" i nie da się ich rozróżnić.
Nie. Klucz główny ma identyfikować rekordy, więc wartości muszą być unikalne. Gdyby duplikaty były dopuszczone, nie dałoby się pewnie wskazać jednego rekordu do aktualizacji lub usunięcia, a relacje między tabelami mogłyby działać niepoprawnie.
Nie. UNIQUE dotyczy zakazu powtórzeń wartości w kolumnie (lub zestawie kolumn). PRIMARY KEY to szczególny przypadek: zwykle także unikalny, ale dodatkowo pełni rolę głównego identyfikatora rekordu i jest standardowo wykorzystywany do relacji między tabelami.
W bazie, która egzekwuje ograniczenie UNIQUE na kolumnie Email, druga próba wstawienia identycznej wartości zakończy się błędem naruszenia ograniczenia. Dzięki temu problem jest wykrywany od razu na poziomie bazy, a nie dopiero w logice aplikacji.
Nie. Klucz główny jest wskazany jawnie w definicji tabeli przez zapis PRIMARY KEY przy kolumnie ID. Sama nazwa kolumny (np. "Nazwisko") nie nadaje jej żadnej roli klucza, jeśli nie ma odpowiedniego ograniczenia.
Zależy od DBMS. Zwykle używa się poleceń typu DESCRIBE/SHOW CREATE TABLE (np. w MySQL) albo zapytań do widoków katalogowych/information_schema (np. w PostgreSQL). Na egzaminie kluczowe jest umieć odczytać ograniczenia bezpośrednio z kodu CREATE TABLE.
Unikalny e-mail ułatwia logowanie, reset hasła i komunikację z użytkownikiem. Zapobiega też dublowaniu kont i chaosowi w danych (np. dwa profile tej samej osoby). Wymuszenie w bazie jest silniejsze niż sama walidacja w formularzu, bo działa niezależnie od aplikacji.
W wielu systemach baza tworzy strukturę indeksową wspierającą sprawdzanie unikalności, ale szczegóły zależą od DBMS. Na poziomie egzaminu ważniejsze jest rozumienie skutku: baza musi móc szybko wykryć powtórzenie, więc implementacja zwykle opiera się o indeks lub podobny mechanizm.
Często mylą role ograniczeń: traktują UNIQUE jak klucz główny albo odwrotnie. Inny błąd to ignorowanie fragmentów definicji tabeli i ocenianie po nazwie kolumny ("Email na pewno jest kluczem"). Pomaga nawyk: najpierw wypisz ograniczenia, dopiero potem interpretuj tabelę.
info

Około 63% zdających odpowiada poprawnie na to pytanie. średnie

Eksperci podkreślają: "Ograniczenie UNIQUE przy kolumnie Email oznacza, że wartości w tej kolumnie nie mogą się powtarzać między rekordami, co zapobiega duplikatom adresów e-mail."

Źródła:

  • PostgreSQL Documentation: CREATE TABLE — Constraints (UNIQUE, PRIMARY KEY), https://www.postgresql.org/docs/current/sql-createtable.html (dostęp: 2026-03-01)
  • MySQL 8.0 Reference Manual: CREATE TABLE Statement oraz informacje o UNIQUE indexes, https://dev.mysql.com/doc/refman/8.0/en/create-table.html (dostęp: 2026-03-01)
  • SQLite Documentation: CREATE TABLE oraz Constraints (PRIMARY KEY, UNIQUE), https://www.sqlite.org/lang_createtable.html (dostęp: 2026-03-01)

Materiały:

  • Dokumentacja DBMS: sekcja o CREATE TABLE i constraints
  • Ćwiczenia: tworzenie tabel z kluczami i ograniczeniami UNIQUE
  • Materiały szkolne z modelu relacyjnego i normalizacji

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego