Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych

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.