Прекалено мислите за връзката между опцията и идентичността. Докато всичко не стане по-естествено за вас, най-добре е да мислите за тях като за напълно несвързани .
По отношение на опцията е важно да запомните, че опцията е насочена. За да използвате вашия пример за employee_equipment :Разбира се, служителите нямат нужда от оборудване. Връзката едно към много от employee към employee_equipment е по избор. В същото време, гледайки от обратната гледна точка, връзката е задължителна. Не можете да имате запис в employee_equipment освен ако няма employee да го свържете с.
Идентичността няма нищо общо с опцията, освен случайно идентифициращата връзка е задължителна от детето към родителя. Дали също е задължително от родителя към детето, не е нито тук, нито там, що се отнася до самоличността.
Това, което прави връзката идентифицираща, е, че трябва да знаете за кой родител говорите (както и някои други неща), за да знаете за какво дете говорите. Тоест, първичният ключ на детето трябва да включва външен ключ към родителя.
Чисти пресечни таблици (напр. employee_equipment ) са добри примери за това. Първичният ключ на чистото пресичане е комбинацията от външни ключове към двете родителски таблици. Имайте предвид, че някои хора могат също да добавят сурогатен ключ към тези видове таблици. Няма толкова голямо значение от гледна точка на идентичността, ако има множество кандидат-ключове. Това, което е важно при определянето на самоличността, е дали външният ключ е част от кандидат ключ, дали този кандидат ключ е първичен ключ или не.
Друг добър пример би бил нещо като каталог с метаданни на база данни, където колона се идентифицира от таблицата, към която принадлежи, точно както таблицата се идентифицира от схемата, в която се намира, и т.н. Знаейки, че една колона се нарича NAME не ви казва коя е колоната. Знаейки, че това е NAME колона в CUSTOMER таблицата помага. (Ще трябва също да знаете коя схема CUSTOMER е в и така нататък).
