Слабка сутність

В реляційних базах даних слабка сутність — це сутність, яка не може бути однозначно визначена самими її атрибутами; а тому, вона повинна використовувати зовнішній ключ у поєднанні зі своїми атрибутами для утворення первинного ключа. Зовнішній ключ, як правило, є первинним ключем сутності, до якої він відноситься.

В діаграмах «сутність — зв'язок» (ER-діаграмах) набір слабких сутностей позначається жирним (або подвійним) прямокутником (сутністю), сполученим жирною (чи подвійною) стрілкою з жирним (або подвійним) ромбом (відношенням). Цей тип відношень називається ідентифікувальним відношенням і в нотації IDEF1X^[en] подається овальною сутністю, а не квадратною, як для базових таблиць. Ідентифікувальне відношення є таким, де первинний ключ передається дочірній слабкій сутності як первинний ключ тієї сутності.

Загалом (хоча не обов'язково) слабка сутність не має жодних елементів у своєму первинному ключі, крім успадкованих первинних ключів і порядкового номера. Існують два типи слабких сутностей: асоціативні сутності^[en] та підтипові сутності. Останні є важливим типом нормалізації, де супертипова сутність успадковує свої атрибути підтиповим сутностям, заснованим на значенні дискримінатора^[en].

В IDEF1X^[en], урядовому стандарті для захоплення вимог, можливими підтиповими відношеннями є:

Повні підтипові відношення, коли всі категорії відомі.
Неповні підтипові відношення, коли не всі категорії можуть бути відомі.

Класичним прикладом слабкої сутності без підтипового відношення будуть записи «заголовок / деталізація» в багатьох реальних ситуаціях на кшталт заявок, замовлень і рахунків-фактур, де заголовок фіксує загальну інформацію по всім формам, а деталізація фіксує інформацію, специфічну для окремих елементів.

Стандартним прикладом повного підтипового відношення є сутність Компанія. Даний дискримінатор ТИП КОМПАНІЇ (який може бути особою, партнерством, корпорацією К, підрозділом асоціації П, асоціацією, урядовим блоком, квазі-урядовим агентством) дві підтипові сутності — ОСОБА, що містить особову інформацію на кшталт імені, прізвища та дати народження, й ОРГАНІЗАЦІЯ, яка міститиме такі атрибути, як юридична назва, й організаційні ієрархії на кшталт центрів витрат.

Коли підтипові відношення відображаються в базі даних, супертипові стають тим, що називається базовою таблицею. Підтипи вважаються похідними таблицями, які відповідають слабким сутностям. Посилальна цілісність забезпечується через каскадні оновлення та вилучення.

Приклад ред.

Розглянемо базу даних, що записує замовлення клієнтів, де замовлення здійснюється на один або більше елементів, які продає підприємство. База даних міститиме таблицю, що визначає клієнтів за їхнім номером (первинний ключ); інша визначає продукти, що можуть продаватися, за номером продукту (первинний ключ); і вона міститиме пару таблиць, які описують замовлення.

Одна з таблиць може бути названа Замовлення, і вона матиме номер замовлення (первинний ключ) для однозначного визначення цього замовлення, а також номер клієнта (зовнішній ключ) для визначення того, кому продаються продукти, плюс інша інформація на кшталт дати й часу розміщення замовлення, способу оплати за нього, місця його доставки і так далі.

Інша таблиця може бути названа ЕлементЗамовлення; вона визначатиметься складеним ключем, що складається з номера замовлення (зовнішній ключ) та номера позиції; з іншими неключовими атрибутами на кшталт номера продукту (зовнішній ключ), який було замовлено, кількості, ціни, будь-яких знижок і додаткових опцій, і так далі. Може бути 0, 1 чи більше записів ЕлементЗамовлення, відповідних запису «Замовлення», але жоден запис ЕлементЗамовлення не може існувати без відповідного запису Замовлення (Випадок 0 кількості ЕлементЗамовлення зазвичай застосовується лише тимчасово, коли замовлення вперше введено та до запису першого замовленого елементу).

Таблиця ЕлементЗамовлення зберігає слабкі сутності точно, оскільки ЕлементЗамовлення не має сенсу незалежно від Замовлення. Дехто може заперечити, що ЕлементЗамовлення має деякий власний сенс; вона записує, що в деякий час не визначається записом, хтось, невизначений записом, замовив певну кількість певного продукту. Ця інформація може бути корисною сама по собі, але це обмежене використання. Наприклад, щойно ви захочете знайти сезонні чи географічні тренди у продажах елементів, вам необхідна інформація з пов'язаного запису Замовлення.

Замовлення не існуватиме без продукту й особи, що зробила його, тому можна стверджувати, що замовлення описуватиметься як слабка сутність, а тому замовлені продукти будуть багатозначним атрибутом замовлення.

Див. також ред.

Посилання ред.

Weak Entity Sets (PDF) (англійською) . Stanford InfoLab. (приклади слабких сутностей)
ERM Erweiterungen — Sonderfall Schwache Entitäten [Розширення ERM — особливий випадок слабких сутностей] (німецькою) . Архів оригіналу за 31 травня 2016. Процитовано 15 червня 2018.

Джерела ред.

Чен, Пітер (1976). The entity-relationship model — toward a unified view of data. ACM Transactions on Database Systems: 9—36.
Міра, Балабан; Шовал, Перетц (1999). Resolving the «weak status» of weak entity types in entity relationship schemas. Conceptual Modeling—ER'99: 369—383.
Сонг, Іл-Йєол; Еванс, Мері; Парк, Еун К. (1995). A comparative analysis of entity-relationship diagrams. Journal of Computer and Software Engineering 3.4: 427—459. {{cite journal}}: Cite має пустий невідомий параметр: |1= (довідка)