У IDEF1X концепція залежних і незалежних сутностей посилюється типом взаємозв'язків між двома сутностями. Якщо ви хочете, щоб зовнішній ключ передавався в дочірню сутність (і, в результаті, створював залежну сутність), то можете створити ідентифікує зв'язок між батьківської та дочірньої сутностями.
Ідентифікують взаємозв'язку позначаються суцільною лінією між сутностями.
Неідентіфіцірующей зв'язку, які є унікальними для IDEF1X, також пов'язують батьківську сутність з дочірньою
Неідентіфіцірующей зв'язку використовуються для відображення іншого типу передачі атрибутів зовнішніх ключів - передача в область даних дочірньої сутності (під лінією).
Так як передані ключі в неидентифицирующей зв'язку не є складовою частиною первинного ключа дочірньої сутності, то цей вид зв'язку не проявляється ні в одній ідентифікуючої залежності. В цьому випадку і ВІДДІЛ, і СПІВРОБІТНИК розглядаються як незалежні сутності.
Проте, взаємозв'язок може відображати залежність існування, якщо бізнес правило для взаємозв'язку визначає те, що зовнішній ключ не може приймати значення NULL. Якщо зовнішній ключ повинен існувати, то це означає, що запис в дочірньої сутності може існувати тільки при наявності асоційованої з ним батьківської записи.
Ім'я ролі (функціональне ім'я) - це синонім атрибута зовнішнього ключа, який показує, яку роль відіграє атрибут в дочірньої сутності.
У прикладі, наведеному на рис. П8, по суті «СТРАХУВАННЯ» зовнішній ключ «Код клієнта» має функціональне ім'я «Хто страхується», яке показує, яку роль відіграє цей атрибут по суті. За замовчуванням в списку атрибутів показується тільки ім'я ролі. Щоб вивести імені атрибута (як функціонального імені, так і імені ролі) слід в контекстному меню, яке з'являється, якщо натиснути правою кнопкою миші по будь-якого місця діаграми, що не зайнятого об'єктами моделі, вибрати пунктEntitiyDisplayі потім включити опціюRolename / Attribute. Повне ім'я показується як функціональне ім'я і базове ім'я, розділені крапкою (дивись рис. П8).
Обов'язковою є застосування імен ролей в тому випадку, коли два або більше атрибути однієї сутності визначені по одній і тій же області, т. Е. Вони мають однакову область значень, але різний зміст.
Мал. П8. Імена ролей зовнішніх ключів
На рис. П9 сутність АЕРОПОРТ містить дані про всі аеропортах, між якими організовані рейси літаків. Інформація про політ, яка міститься в сутності ПОЛІТ, включає пункт призначення і пункт відправлення літаків. Отже, сутність ПОЛІТ і АЕРОПОРТ повинні бути пов'язані двічі і первинний ключ - Код аеропорту повинен двічі мігрувати в сутність ПОЛІТ як зовнішній ключ. Необхідно розрізняти ці атрибути, які містять інформацію про аеропорт, з якого вилітає літак, і аеропорту, в який прилітає літак. Вони мають різний зміст, але посилаються на одну і ту ж сутність АЕРОПОРТ (мають загальну область значень). У прикладі на рис. П9 атрибути отримали імена ролей «Пункт оправления» і «Пункт призначення».
Іншим прикладом обов'язковості присвоєння імен ролей є рекурсивні зв'язку (іноді їх називають «рибальським гачком» -fishhook), коли одна і та ж сутність є і батьківської і дочірньою одночасно.
Мал. П9. Випадок обов'язковості імен ролей
При завданні рекурсивної зв'язку атрибут повинен мігрувати в якості зовнішнього ключа до складу неключових атрибутів тієї ж сутності. Атрибут не може з'явитися двічі в одній сутності під одним ім'ям, тому обов'язково повинен отримати ім'я ролі. На рис. П10 сутність Співробітник містить атрибут первинного ключа Код співробітника. Інформація про керівника співробітника міститься в тій же сутності, оскільки керівник працює в тій же організації. Щоб послатися на керівника співробітника, слід створити рекурсивную зв'язок (на рис. 9 зв'язок керує) і привласнити ім'я ролі (Керівник). Зауважимо, що рекурсивна зв'язок може бути тільки неидентифицирующей. В іншому випадку зовнішній ключ мав би увійти до складу первинного ключа і отримати при генерації схеми прізнакNOTNULL. Це зробило б неможливим побудову ієрархії, - у дерева підпорядкованості повинен бути корінь, - співробітник, який нікому не підпорядковується в рамках даної організації.
Зв'язок «керує / підпорядковується» на рис. П10 дозволяє зберігати деревоподібну ієрархію підпорядкованості співробітників. Такий вид рекурсивної зв'язку називається ієрархічної рекурсією (hierarchicalrecursion) і задає зв'язок, коли керівник (екземпляр батьківського суті) може мати безліч підлеглих (примірників дочірньої сутності), але підлеглий має тільки одного керівника (дивись рис. П10).
Іншим видом рекурсії є мережева рекурсія (networkrecursion), коли керівник може мати безліч підлеглих і, навпаки, підлеглий може мати безліч керівників. Мережева рекурсія задає павутину відносин між екземплярами батьківської і дочірньою сутностей. Це випадок, коли сутність знаходиться сама з собою в зв'язку «багато до багатьох». Для вирішення зв'язку «багато до багатьох» необхідно створити нову сутність (детально зв'язок «багато до багатьох» буде розглянута нижче).
Мал. П10. Підпорядкованість примірників сутності в ієрархічній рекурсії
На рис. П3 розглянуто приклад реалізації мережевої рекурсії. Структура моделює відносини субординації між співробітниками будь-якої складності. Оскільки відношення субординації пов'язує завжди двох людей, від сутності Співробітник до суті відносини субординації встановлені дві ідентифікують зв'язку з іменами ролей «Керівник» та «Підлеглий». Кожен співробітник може бути у відносинах «керує / підпорядковується» з будь-яким іншим співробітником, але одну і ту ж пару співробітників може пов'язувати один тип відносин субординації.