Jednoznacznym identyfikatorem rekordu w bazie danych jest pole
A. klucza podstawowego.
B. klucza obcego.
C. numeryczne.
D. relacji.
Pytanie z egzaminu CKE, styczeń 2016 (arkusz E.14-X-16.01).
Pole klucza podstawowego jest jednoznacznym identyfikatorem rekordu, bo jego zadaniem jest odróżnienie jednego wiersza tabeli od wszystkich pozostałych. W relacyjnych bazach danych klucz podstawowy, często oznaczany jako PK, musi mieć wartości unikalne i nie może być pusty, czyli nie powinien przyjmować wartości NULL. Dzięki temu można bezpiecznie wskazać konkretny rekord, np. klienta o id_klienta = 15, produkt o id_produktu = 203 albo zamówienie o id_zamowienia = 9001. To jest bardzo praktyczne, bo na takim polu opiera się edycja, usuwanie, wyszukiwanie oraz łączenie danych z innymi tabelami. W dobrych praktykach projektowania baz danych klucz podstawowy powinien być stabilny, możliwie krótki i jednoznaczny. Z mojego doświadczenia najczęściej stosuje się sztuczny identyfikator liczbowy typu INT z autoinkrementacją, ale to nie znaczy, że każde pole numeryczne jest kluczem. Ważna jest funkcja w strukturze tabeli, a nie sam typ danych. Klucz podstawowy jest też podstawą tworzenia relacji, bo inne tabele mogą się do niego odwoływać przez klucze obce. Moim zdaniem to jedno z najważniejszych pojęć przy projektowaniu bazy, bo bez poprawnego identyfikatora łatwo zrobić bałagan w danych i potem trudno to odkręcić.
Jednoznaczny identyfikator rekordu to klucz podstawowy, a nie dowolne pole, które wygląda technicznie albo kojarzy się z bazą danych. Klucz obcy pełni inną rolę: wskazuje rekord w innej tabeli i służy do budowania powiązań między tabelami. Na przykład w tabeli zamowienia pole id_klienta może być kluczem obcym, bo odwołuje się do klienta z tabeli klienci. Nie identyfikuje ono jednak jednoznacznie samego zamówienia, bo jeden klient może mieć wiele zamówień. To jest częsty błąd myślowy: skoro pole bierze udział w relacji, to ktoś uznaje je za główny identyfikator. Nie zawsze tak jest. Pole numeryczne też nie musi być identyfikatorem. Cena, liczba sztuk, wiek albo rabat mogą być liczbami, ale mogą się powtarzać i często mogą się zmieniać. Sama numeryczność nie gwarantuje unikalności, braku wartości NULL ani stabilności. W praktyce branżowej identyfikator rekordu powinien być jawnie zdefiniowany jako PRIMARY KEY, a nie tylko mieć typ INT czy BIGINT. Słowo relacja również nie oznacza pola identyfikującego rekord. Relacja opisuje powiązanie między tabelami albo, w teorii relacyjnej, samą strukturę tabeli jako zbioru krotek. Może to brzmieć trochę akademicko, ale w SQL ma bardzo konkretne skutki: klucze podstawowe i obce pilnują integralności danych. Dlatego przy projektowaniu tabel warto najpierw ustalić, co jednoznacznie odróżnia rekord, a dopiero potem dobierać typ danych i powiązania. Inaczej baza może działać przez chwilę, ale przy większej liczbie danych zaczną się duplikaty, trudne aktualizacje i problemy z poprawnym łączeniem tabel.