Na przedstawionym diagramie ER zapis FK1 oznacza
Skrót FK1 na diagramie ER oznacza klucz obcy (ang. foreign key) i jest to dokładnie to, co powinno łączyć tabelę Zamówienia z tabelą Klienci. W relacyjnych bazach danych klucz obcy to atrybut lub zestaw atrybutów, który wskazuje na klucz podstawowy w innej tabeli. Dzięki temu baza danych wie, że konkretne zamówienie należy do konkretnego klienta. W twoim diagramie pole NR_klienta w tabeli Zamówienia jest oznaczone jako FK1, czyli jest kluczem obcym odwołującym się do NR_klienta będącego kluczem podstawowym (PK) w tabeli Klienci. To jest klasyczny przykład relacji 1:N – jeden klient może mieć wiele zamówień, a każde zamówienie jest powiązane z dokładnie jednym klientem. W praktyce, w SQL, taka relacja jest definiowana mniej więcej tak: `FOREIGN KEY (NR_klienta) REFERENCES Klienci(NR_klienta)`. Taka definicja pozwala silnikowi bazy danych pilnować spójności referencyjnej, czyli np. nie pozwoli wstawić zamówienia z numerem klienta, który nie istnieje w tabeli Klienci, ani usunąć klienta, do którego wciąż istnieją zamówienia (chyba że jawnie zdefiniujemy CASCADE). Z mojego doświadczenia poprawne używanie kluczy obcych bardzo upraszcza później raportowanie, łączenie tabel w zapytaniach JOIN i ogólnie utrzymanie porządku w bazie. W modelowaniu ER oznaczenie FK wraz z numerem (FK1, FK2 itd.) to po prostu sposób na jednoznaczne nazwanie konkretnych kluczy obcych, gdy w systemie jest ich więcej. W dobrze zaprojektowanych bazach danych zawsze warto jawnie definiować foreign key, zamiast tylko „ufać”, że aplikacja będzie podawała poprawne dane – to jest po prostu dobra praktyka i standard w profesjonalnych projektach.
Na diagramach ER oznaczenia typu FK1 zwykle odnoszą się do kluczy obcych, a nie do samej relacji ani do kluczy podstawowych. Łatwo się tu pomylić, bo obok tego symbolu widać też graficzne oznaczenie relacji 1:N między tabelami Klienci i Zamówienia, więc część osób automatycznie kojarzy podpis z typem połączenia. Tymczasem relacja 1:1 czy 1:N jest przedstawiana linią i odpowiednimi znacznikami przy końcach (kreska, „gałązki”, kółko), natomiast skróty PK i FK pojawiają się wewnątrz tabel i opisują role konkretnych kolumn. PK to primary key, czyli klucz podstawowy – unikalny identyfikator w danej tabeli. Na diagramie widać go przy NR_klienta w tabeli Klienci oraz przy ID_Zamówienia w tabeli Zamówienia. Oznaczenie FK1 przy NR_klienta w tabeli Zamówienia nie może więc oznaczać kolejnego klucza podstawowego ani samej relacji, tylko właśnie klucz obcy, który wskazuje na PK w innej tabeli. Częsty błąd polega na mieszaniu pojęć „relacja 1:N” z „kluczem obcym”. Relacja 1:N jest pojęciem konceptualnym: mówi, że jeden klient może mieć wiele zamówień. Klucz obcy to implementacja tej relacji w fizycznym modelu bazy: konkretna kolumna, która przechowuje wartość klucza podstawowego z drugiej tabeli. Innymi słowy, FK jest narzędziem, a 1:N opisem zależności. Kiedy ktoś interpretuje FK1 jako relację 1:1 albo 1:N, miesza warstwę symboliki linii z opisem kolumn. Dobra praktyka w projektowaniu baz danych i w narzędziach CASE jest taka, że PK i FK stoją zawsze przy nazwach atrybutów, a typ relacji rozczytujemy z grafiki między encjami, nie z tych skrótów. Zrozumienie tej różnicy jest kluczowe, bo potem w SQL dokładnie tak samo rozdzielamy definicję struktury tabel (PRIMARY KEY, FOREIGN KEY) od logicznej interpretacji, ile rekordów może być po każdej stronie relacji.