Jeżeli pole kolor w tabeli samochody ma przyjmować tylko wartości "ze słownika" lakier, to w praktyce oznacza to wymuszenie integralności referencyjnej: każda wartość w samochody.kolor musi odpowiadać istniejącemu rekordowi w tabeli lakier.
Do tego służy klucz obcy (FOREIGN KEY). Klucz obcy definiuje się w tabeli "dziecka" (tu: samochody), która przechowuje odwołanie, i wskazuje tabelę "rodzica" (tu: lakier) oraz jej kolumnę klucza (np. lakierId). Poprawne polecenie ma więc postać: modyfikacja tabeli samochody i dodanie FOREIGN KEY na kolumnie kolor z klauzulą REFERENCES do tabeli lakier.
Dlaczego pozostałe odpowiedzi są błędne?
- Wariant bez nawiasów i bez wskazania kolumny referencyjnej jest niepoprawny składniowo w typowych silnikach SQL oraz nie określa jednoznacznie, do czego ma prowadzić więz.
- Wariant odwołujący się do innej kolumny (np. barwa) lub do konstrukcji w stylu "samochody.lakier" miesza nazwy tabel i kolumn, przez co nie tworzy poprawnego ograniczenia FOREIGN KEY.
- Wariant dodający klucz obcy w tabeli lakier do tabeli samochody odwraca logikę: słownik nie powinien zależeć od tabeli z danymi. To samochody mają wskazywać wybrany lakier, a nie odwrotnie.
Wskazówka egzaminacyjna: szukaj odpowiedzi, w której ALTER TABLE dotyczy tabeli przechowującej odwołanie oraz występuje pełna konstrukcja FOREIGN KEY (kolumna) REFERENCES tabela(kolumna).
