Poprawnie – klucz obcy definiujemy właśnie po to, żeby utworzyć i wymusić relację między tabelami, najczęściej relację 1..n. W praktyce wygląda to tak, że w tabeli „dziecko” (np. ZAMOWIENIA) umieszczamy kolumnę, która odwołuje się do klucza głównego w tabeli „rodzic” (np. KLIENCI). Ta kolumna jest właśnie kluczem obcym. Dzięki temu każde zamówienie musi być powiązane z istniejącym klientem. To jest klasyczny przykład relacji 1 klient – wiele zamówień (1..n). Moim zdaniem to jest jeden z fundamentów relacyjnych baz danych: klucze obce pilnują integralności referencyjnej. Silnik bazy (MySQL, PostgreSQL, SQL Server itd.) sprawdza, czy wartość w kolumnie z kluczem obcym faktycznie istnieje w tabeli nadrzędnej. Jeżeli spróbujesz wstawić zamówienie z nieistniejącym id_klienta, dostaniesz błąd. To jest dokładnie to, co chcemy w dobrze zaprojektowanym systemie – brak „osieroconych” rekordów. W relacjach 1..n stosuje się standardowo schemat: tabela nadrzędna ma klucz podstawowy (PRIMARY KEY), a tabela podrzędna ma kolumnę z kluczem obcym (FOREIGN KEY), który wskazuje na ten klucz podstawowy. W SQL zapisuje się to np.: `FOREIGN KEY (id_klienta) REFERENCES klienci(id_klienta)`. Dobre praktyki mówią też, żeby na kolumnach kluczy obcych zakładać indeksy, bo to przyspiesza złączenia (JOIN) i operacje kasowania/aktualizacji. Warto też wiedzieć, że klucz obcy może być używany z dodatkowymi opcjami, np. `ON DELETE CASCADE` lub `ON UPDATE RESTRICT`, żeby automatycznie usuwać powiązane rekordy lub blokować operacje łamiące spójność danych. W realnych aplikacjach webowych (np. systemy sklepów internetowych, CRM-y, systemy magazynowe) poprawne zdefiniowanie relacji 1..n przez klucze obce to podstawa stabilności całej bazy – bez tego bardzo szybko robi się bałagan, duplikaty i niespójne dane.
W tym pytaniu łatwo się pomylić, bo wszystkie odpowiedzi zahaczają o tematykę baz danych, ale tylko jedna dotyczy faktycznego zastosowania klucza obcego. Klucz obcy w relacyjnej bazie danych służy do wiązania tabel ze sobą i pilnowania integralności referencyjnej. To oznacza, że jego główna rola to powiązanie rekordów: jeden rekord w tabeli nadrzędnej może mieć wiele powiązanych rekordów w tabeli podrzędnej. To jest właśnie relacja 1..n – najczęściej spotykana w normalnych systemach (np. jeden klient, wiele zamówień; jeden autor, wiele książek). Częsty błąd polega na kojarzeniu klucza obcego z transakcjami. Transakcje w SQL (BEGIN, COMMIT, ROLLBACK) to zupełnie inny mechanizm – służą do zapewnienia atomowości, spójności, izolacji i trwałości operacji (tzw. ACID). Można mieć transakcje w bazie nawet wtedy, gdy w ogóle nie ma żadnych kluczy obcych. Klucz obcy nie jest wymagany do rozpoczęcia czy wykonania transakcji, to po prostu inna warstwa logiki. Zdarza się też, że ktoś myli klucz obcy z kluczem podstawowym i myśli, że klucz obcy jest potrzebny do jego utworzenia. Jest dokładnie odwrotnie: najpierw definiuje się klucz podstawowy w tabeli nadrzędnej, a dopiero potem w innej tabeli tworzy się klucz obcy, który się do tego klucza podstawowego odwołuje. Klucz podstawowy identyfikuje jednoznacznie rekord w swojej tabeli, klucz obcy tylko wskazuje na ten rekord z innej tabeli. Jeśli chodzi o relacje 1..1, to one również mogą być realizowane za pomocą kluczy obcych, ale pytanie używa słowa „niezbędne” i w kontekście typowych zastosowań oraz nauczania relacyjnych baz danych klucz obcy kojarzymy głównie z relacją 1..n. Relacja 1..1 jest rzadziej używana i zwykle wymaga dodatkowych ograniczeń (np. klucz obcy, który jest jednocześnie unikalny), więc to już bardziej specyficzny przypadek. Typowym, podręcznikowym i praktycznym zastosowaniem klucza obcego jest właśnie relacja jeden do wielu, i na to pytanie celuje. Z mojego doświadczenia największy problem polega na tym, że uczniowie mieszają pojęcia: transakcje, klucze, relacje, wszystko wrzucają do jednego worka. Warto je rozdzielić: klucz podstawowy – identyfikacja rekordu, klucz obcy – powiązanie między tabelami (relacje, głównie 1..n), transakcje – kontrola przebiegu operacji w bazie. Jak się to poukłada w głowie, projektowanie schematu bazy danych staje się dużo prostsze i bardziej logiczne.