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.
Na tym przykładzie bardzo dobrze widać, jak łatwo pomylić różne rodzaje kluczy w relacyjnej bazie danych. W tabeli ksiazki pole AutorID wygląda jak zwykła kolumna z liczbą, ale jego sens wynika dopiero z relacji z tabelą autorzy. To pole nie identyfikuje jednoznacznie rekordu książki, więc nie może być kluczem podstawowym. Kluczem podstawowym jest tu IDKsiazki, bo to ono służy do unikalnego oznaczania każdego wiersza z książką. Typowy błąd myślowy polega na tym, że skoro AutorID też jest liczbą i też wygląda jak identyfikator, to ktoś uznaje go za klucz podstawowy lub kandydujący. Tymczasem klucz kandydujący to taki, który mógłby być kluczem podstawowym, czyli musi gwarantować unikalność. AutorID tej cechy nie ma – jeden autor może mieć wiele książek, więc ta wartość powtarza się w wielu wierszach. Dlatego nie spełnia warunku unikalności i odpada jako kandydat. Czasem pojawia się też skojarzenie z kluczem sztucznym, bo pola typu ID są często tworzone sztucznie, np. jako auto_increment. Klucz sztuczny to jednak pojęcie opisujące sposób tworzenia identyfikatora w tabeli, a nie jego rolę w relacji między tabelami. Sztuczny (surrogate) może być np. IDKsiazki czy IDAutor – liczba bez znaczenia biznesowego, używana tylko jako identyfikator. AutorID w tabeli ksiazki nie jest nowym sztucznym kluczem, tylko przechowywaniem wartości z innej tabeli. Jego podstawowa funkcja to łączenie tabel, czyli właśnie rola klucza obcego. Z mojego doświadczenia warto zawsze zadać sobie pytanie: „czy to pole jednoznacznie identyfikuje wiersz w tej tabeli, czy tylko wskazuje na wiersz w innej tabeli?”. Jeśli to drugie, to mówimy o kluczu obcym, a nie o kluczu podstawowym, kandydującym czy sztucznym. Taka prosta mentalna checklista bardzo pomaga przy projektowaniu schematów i unikaniu nieporozumień w nazewnictwie i projektowaniu relacji.