W bazie danych samochodów pole kolor z tabeli samochody przyjmuje wartości kolorów jedynie ze słownika lakier. Aby połączyć tabele samochody i lakier relacją należy, zastosować kwerendę
|
A.
D.
C.
B.
Odpowiedź B jest właściwa, ponieważ poprawnie tworzy klucz obcy w tabeli samochody na kolumnie kolor i wskazuje, do jakiej kolumny w tabeli słownikowej lakier ma się on odnosić. Składnia ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId) oznacza: wartości wpisywane w samochody.kolor muszą istnieć wcześniej w kolumnie lakier.lakierId. W praktyce zabezpiecza to bazę przed wpisaniem koloru, którego nie ma w słowniku, np. przypadkowego tekstu typu blekitnyy zamiast identyfikatora poprawnego lakieru. To jest właśnie integralność referencyjna, bardzo ważna w relacyjnych bazach danych. Z mojego doświadczenia to jedna z tych rzeczy, które na początku wydają się formalnością, a potem ratują dane przed bałaganem. Dobra praktyka branżowa to jeszcze nadanie nazwanej więzi, np. ALTER TABLE samochody ADD CONSTRAINT fk_samochody_lakier FOREIGN KEY (kolor) REFERENCES lakier(lakierId);. Warto też pamiętać, że lakierId powinno być kluczem głównym albo przynajmniej kolumną unikalną, a typ danych samochody.kolor musi pasować do typu lakier.lakierId.
W tym zadaniu chodzi o utworzenie relacji między tabelą główną samochody a tabelą słownikową lakier. Klucz obcy zawsze zakłada dwa konkretne miejsca: kolumnę w tabeli podrzędnej, czyli tę przechowującą odwołanie, oraz kolumnę w tabeli nadrzędnej, zwykle klucz główny albo unikalny identyfikator. Samo napisanie FOREIGN KEY kolor REFERENCES lakier jest niewystarczające i w wielu systemach SQL będzie po prostu błędne składniowo, bo kolumna klucza obcego powinna być podana w nawiasie, a tabela referencyjna najlepiej z konkretną kolumną, np. lakier(lakierId). Częsty błąd myślowy polega na tym, że ktoś widzi nazwę tabeli lakier i uznaje, że baza domyśli się reszty. No nie zawsze się domyśli, a profesjonalnie nie powinno się na tym opierać.
Niepoprawne jest też mieszanie nazw kolumn i nazw tabel, na przykład użycie barwa, jeśli w treści zadania występuje pole kolor. Taka kolumna musiałaby naprawdę istnieć w tabeli, inaczej polecenie ALTER TABLE nie ma sensu. Podobnie zapis samochody.lakier sugeruje dziwne odwołanie do obiektu wewnątrz tabeli samochody, a nie do tabeli słownikowej lakier i jej klucza. Jeszcze inny problem to próba dodania klucza obcego w tabeli lakier wskazującego na samochody(kolor). To odwraca relację. Słownik lakier powinien być tabelą nadrzędną, bo przechowuje dozwolone wartości, a samochody powinny się do niego odwoływać. W dobrym projekcie bazy słowniki są stabilne, mają własny identyfikator, a tabele operacyjne przechowują tylko odwołanie. Dzięki temu nie powiela się tekstów kolorów w wielu rekordach i łatwiej utrzymać spójność danych.
Niepoprawne jest też mieszanie nazw kolumn i nazw tabel, na przykład użycie barwa, jeśli w treści zadania występuje pole kolor. Taka kolumna musiałaby naprawdę istnieć w tabeli, inaczej polecenie ALTER TABLE nie ma sensu. Podobnie zapis samochody.lakier sugeruje dziwne odwołanie do obiektu wewnątrz tabeli samochody, a nie do tabeli słownikowej lakier i jej klucza. Jeszcze inny problem to próba dodania klucza obcego w tabeli lakier wskazującego na samochody(kolor). To odwraca relację. Słownik lakier powinien być tabelą nadrzędną, bo przechowuje dozwolone wartości, a samochody powinny się do niego odwoływać. W dobrym projekcie bazy słowniki są stabilne, mają własny identyfikator, a tabele operacyjne przechowują tylko odwołanie. Dzięki temu nie powiela się tekstów kolorów w wielu rekordach i łatwiej utrzymać spójność danych.