Nadmiernie zastanawiasz się nad związkiem między opcjonalnością a tożsamością. Dopóki wszystko nie przyjdzie ci bardziej naturalnie, najlepiej myśleć o nich jako o całkowicie niepowiązanych .
O opcjonalności należy pamiętać, że opcjonalność jest kierunkowa. Aby użyć przykładu employee_equipment :Jasne, pracownicy nie potrzebują sprzętu. Relacja jeden-do-wielu od employee do employee_equipment jest opcjonalne. Jednocześnie, patrząc na to z odwrotnej perspektywy, relacja jest obowiązkowa. Nie możesz mieć wpisu w employee_equipment chyba że istnieje employee skojarzyć go z.
Tożsamość nie ma nic wspólnego z opcjonalnością, z wyjątkiem przypadku relacja identyfikująca jest obowiązkowa od dziecka do rodzica. To, czy jest to również obowiązkowe od rodzica do dziecka, nie jest ani tu, ani tam, jeśli chodzi o tożsamość.
To, co sprawia, że związek się identyfikuje, to fakt, że musisz wiedzieć, o którym rodzicu mówisz (oraz kilka innych rzeczy), aby wiedzieć, o jakim dziecku mówisz. Oznacza to, że klucz podstawowy dziecka musi zawierać klucz obcy do rodzica.
Tabele czystego przecięcia (np. employee_equipment ) są tego dobrymi przykładami. Kluczem podstawowym czystego przecięcia jest kombinacja kluczy obcych do obu tabel nadrzędnych. Zauważ, że niektórzy ludzie mogą również dodać klucz zastępczy do tego rodzaju tabel. Z perspektywy tożsamości nie ma to większego znaczenia, jeśli istnieje wiele kluczy kandydujących. To, co jest ważne przy określaniu tożsamości, to to, czy klucz obcy jest częścią klucza kandydującego, czy ten klucz kandydujący jest kluczem podstawowym.
Innym dobrym przykładem może być katalog metadanych bazy danych, w którym kolumna jest identyfikowana przez tabelę, do której należy, tak jak tabela jest identyfikowana przez schemat, w którym się znajduje, i tak dalej. Wiedząc, że kolumna nazywa się NAME nie mówi, która to kolumna. Wiedząc, że jest to NAME kolumna w CUSTOMER stół pomaga. (Musisz również wiedzieć, który schemat CUSTOMER jest i tak dalej).
