Które z poniższych stwierdzeń dotyczących klucza obcego jest poprawne?
A. Musi zawierać wartości unikalne w obrębie swojej tabeli
B. Odwołuje się do klucza głównego (lub unikalnego) tabeli powiązanej
C. Nigdy nie może przyjmować wartości NULL
D. Może przyjmować tylko wartości numeryczne
Klucz obcy to mechanizm używany w relacyjnych bazach danych do pilnowania spójności danych między tabelami. Poprawne jest stwierdzenie, że odwołuje się on do klucza głównego albo do kolumny z ograniczeniem UNIQUE w tabeli powiązanej. W praktyce wygląda to np. tak: tabela zamowienia może mieć kolumnę klient_id, która wskazuje na id w tabeli klienci. Dzięki temu baza nie pozwoli zwykle dodać zamówienia dla klienta, którego w tabeli klienci po prostu nie ma. To jest właśnie integralność referencyjna, bardzo ważna rzecz w SQL i projektowaniu baz danych. Moim zdaniem to jeden z tych tematów, które naprawdę widać dopiero przy normalnym projekcie, np. sklepie internetowym, systemie ocen albo rezerwacjach. Klucz obcy nie musi być unikalny, bo wielu rekordów może wskazywać na tego samego klienta, kategorię czy autora. Standardowo definiuje się go przez FOREIGN KEY oraz REFERENCES, a dobre praktyki mówią też, żeby świadomie ustalać akcje typu ON DELETE CASCADE, ON DELETE SET NULL albo RESTRICT, bo od tego zależy zachowanie danych przy usuwaniu powiązanych rekordów.
W kluczu obcym łatwo pomylić jego rolę z rolą klucza głównego, a to prowadzi do kilku typowych błędów. Klucz obcy nie służy do jednoznacznej identyfikacji rekordu w swojej tabeli. Od tego jest klucz główny, najczęściej PRIMARY KEY. Kolumna będąca kluczem obcym może powtarzać wartości, i to jest całkiem normalne. Jeśli w tabeli zamowienia kilka zamówień należy do tego samego klienta, to wartość klient_id pojawi się wiele razy. Gdyby klucz obcy musiał być unikalny, relacja jeden-do-wielu praktycznie by się rozsypała, a przecież jest ona jedną z podstaw projektowania baz relacyjnych.
Nie ma też zasady, że klucz obcy musi mieć typ numeryczny. Bardzo często używa się liczb całkowitych, bo są szybkie, wygodne do indeksowania i proste w obsłudze, ale technicznie klucz obcy musi mieć typ zgodny z kolumną, do której się odwołuje. Może więc wskazywać na kod tekstowy, UUID, identyfikator znakowy albo inną wartość objętą PRIMARY KEY lub UNIQUE. Ważna jest zgodność typu i sens danych, nie sama liczbowość.
Mylny jest również pogląd, że klucz obcy nigdy nie może przyjmować NULL. To zależy od tego, czy kolumna ma ograniczenie NOT NULL. W wielu modelach NULL jest poprawny, np. gdy pracownik nie ma jeszcze przypisanego działu albo zamówienie nie ma przypisanego kuriera. Z mojego doświadczenia wynika, że najważniejsze jest tu rozumienie relacji: klucz obcy pilnuje, żeby istniejąca wartość wskazywała na poprawny rekord w tabeli nadrzędnej. Jeśli projekt dopuszcza brak powiązania, NULL może być jak najbardziej legalny.
Nie ma też zasady, że klucz obcy musi mieć typ numeryczny. Bardzo często używa się liczb całkowitych, bo są szybkie, wygodne do indeksowania i proste w obsłudze, ale technicznie klucz obcy musi mieć typ zgodny z kolumną, do której się odwołuje. Może więc wskazywać na kod tekstowy, UUID, identyfikator znakowy albo inną wartość objętą PRIMARY KEY lub UNIQUE. Ważna jest zgodność typu i sens danych, nie sama liczbowość.
Mylny jest również pogląd, że klucz obcy nigdy nie może przyjmować NULL. To zależy od tego, czy kolumna ma ograniczenie NOT NULL. W wielu modelach NULL jest poprawny, np. gdy pracownik nie ma jeszcze przypisanego działu albo zamówienie nie ma przypisanego kuriera. Z mojego doświadczenia wynika, że najważniejsze jest tu rozumienie relacji: klucz obcy pilnuje, żeby istniejąca wartość wskazywała na poprawny rekord w tabeli nadrzędnej. Jeśli projekt dopuszcza brak powiązania, NULL może być jak najbardziej legalny.