Zdefiniowanie klucza obcego jest niezbędne do utworzenia

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.