W bazie danych szkoły tabele klasy i uczniowie są połączone relacją jeden do wielu (jedna klasa - wielu uczniów). Klucz obcy należy zdefiniować w tabeli
A. klasy, wskazujący na klucz podstawowy tabeli uczniowie.
B. uczniowie, wskazujący na klucz obcy tabeli klasy.
C. klasy, wskazujący na klucz obcy tabeli uczniowie.
D. uczniowie, wskazujący na klucz podstawowy tabeli klasy.
W relacji jeden do wielu klucz obcy zapisuje się po stronie wielu, czyli w tabeli uczniowie. Jedna klasa może mieć wielu uczniów, ale pojedynczy uczeń należy zwykle do jednej konkretnej klasy. Dlatego w tabeli uczniowie powinno znaleźć się pole, np. id_klasy, które wskazuje na klucz podstawowy tabeli klasy, np. klasy.id. To jest klasyczny sposób modelowania relacji 1:N w relacyjnych bazach danych. Dzięki temu baza wie, do której klasy przypisany jest dany uczeń, a jednocześnie nie trzeba powielać danych klasy przy każdym uczniu, tylko przechowuje się identyfikator. Moim zdaniem to jedna z najważniejszych zasad projektowania baz, bo od niej zależy porządek w danych. W praktyce wygląda to tak: tabela klasy ma rekordy typu 1A, 2B, 3C, a tabela uczniowie ma wiele rekordów uczniów, z kolumną id_klasy. Klucz obcy powinien wskazywać na klucz podstawowy tabeli nadrzędnej, czyli rodzica relacji. Dobrą praktyką jest też ustawienie więzów integralności referencyjnej, żeby nie dało się dopisać ucznia do klasy, która nie istnieje. W SQL można to zrobić przez FOREIGN KEY (id_klasy) REFERENCES klasy(id). Takie podejście jest zgodne z normalizacją danych i ogranicza bałagan, duplikaty oraz przypadkowe niespójności w bazie.
W tej relacji łatwo pomylić stronę, po której powinien znaleźć się klucz obcy. Trzeba patrzeć na to praktycznie: jeśli jedna klasa ma wielu uczniów, to nie tabela klasy powinna przechowywać identyfikatory uczniów. Gdyby w tabeli klasy próbować zapisać odwołanie do ucznia, pojawiłby się problem, bo jedna klasa musiałaby wskazywać wielu uczniów naraz. Relacyjna baza danych nie działa dobrze, gdy w jednej komórce zaczynamy trzymać listę identyfikatorów, np. 5, 7, 12, 18. To łamie podstawowe zasady normalizacji, szczególnie zasadę atomowości danych. Każde pole powinno zawierać jedną wartość, a nie zbiór wartości. Z mojego doświadczenia uczniowie często mylą klucz podstawowy z obcym i myślą, że klucz obcy może wskazywać na inny klucz obcy. W poprawnym projekcie klucz obcy najczęściej odwołuje się do klucza podstawowego tabeli nadrzędnej, bo to on jednoznacznie identyfikuje rekord. Tabela klasy jest tutaj tabelą nadrzędną, a tabela uczniowie podrzędną, bo wiele rekordów uczniów należy do jednego rekordu klasy. Niepoprawne jest więc umieszczanie klucza obcego w tabeli klasy, gdy opisujemy zwykłą relację jedna klasa - wielu uczniów. Niepoprawne jest też wskazywanie na klucz obcy zamiast na klucz podstawowy, bo wtedy relacja staje się niejasna i trudniejsza do kontrolowania przez system zarządzania bazą danych. Poprawny model pozwala wykonywać proste zapytania JOIN, pilnować integralności referencyjnej i uniknąć sytuacji, że uczeń jest przypisany do nieistniejącej klasy. Właśnie dlatego w tabeli uczniowie tworzy się kolumnę id_klasy jako klucz obcy odnoszący się do klucza podstawowego tabeli klasy.