W przedstawionej na rysunku relacji pole <i>AutorID</i> znajdujące się w tabeli <i>ksiazki</i> jest kluczem

Pole AutorID w tabeli ksiazki jest klasycznym przykładem klucza obcego (foreign key) w relacyjnej bazie danych. Odwołuje się ono do pola IDAutor w tabeli autorzy, które jest kluczem podstawowym tej tabeli. Dzięki temu każda książka jest logicznie powiązana z konkretnym autorem, a baza danych może pilnować spójności referencyjnej. Innymi słowy: nie da się (a przynajmniej nie powinno się dać, jeśli relacje są poprawnie zdefiniowane) wstawić do ksiazki wartości AutorID, która nie istnieje w tabeli autorzy. W praktyce, w SQL definiuje się to np. tak: `AutorID INT CONSTRAINT FK_Ksiazki_Autorzy FOREIGN KEY REFERENCES autorzy(IDAutor)`. Moim zdaniem to jedno z najważniejszych pojęć w projektowaniu baz – bez kluczy obcych relacje między tabelami byłyby tylko „umowne”, a nie wymuszane przez silnik bazy. Klucz obcy zawsze wskazuje na klucz kandydujący, najczęściej na klucz podstawowy innej tabeli. Dzięki temu można łatwo wykonywać złączenia (JOIN): np. `SELECT Tytul, Imie, Nazwisko FROM ksiazki JOIN autorzy ON ksiazki.AutorID = autorzy.IDAutor;`. To jest dokładnie ten przypadek z rysunku: wiele książek może mieć tego samego autora, więc między autorzy a ksiazki mamy relację jeden‑do‑wielu, a pole AutorID jest po stronie „wiele” i pełni rolę klucza obcego. Dobre praktyki mówią też, żeby nazwy kluczy obcych jasno wskazywały, do czego się odnoszą (np. AutorID, Autor_Id), co tu również jest sensownie zrobione. W realnych systemach (biblioteki, księgarnie internetowe, systemy wydawnicze) dokładnie tak modeluje się powiązanie książka–autor: ID autora jako klucz podstawowy w tabeli autorzy i to samo ID jako klucz obcy w tabeli ksiazki.