Коли ми повинні використовувати слабкі об'єкти при моделюванні бази даних?

12

Це в основному питання про те, що таке слабкі утворення? Коли ми повинні їх використовувати? Як їх моделювати?

У чому головна відмінність між нормальними і слабкими особами? Чи відповідають слабкі об'єкти цінним об'єктам, коли роблять дизайн, керований доменом?

Щоб утримати запитання про цю тему, наведено приклад із Вікіпедії, який люди можуть використовувати для відповіді на це запитання: введіть тут опис зображення

У цьому прикладі OrderItemмоделювали як слабке утворення, але я не можу зрозуміти, чому його не можна моделювати як нормальну сутність.
Інше питання - що, якщо я хочу відстежувати історію замовлень (тобто зміни в статусі), це буде нормальним чи слабким об'єктом?

— Сонго
джерело

10

Формально "слабке" утворення має такі характеристики.

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

Я б сказав, що на практиці ви не відверто вирішили зробити щось «слабке» сутність як таке; ви б замість цього структурувати дані, щоб вони були репрезентативними для того, що ви намагаєтеся моделювати. Якщо ви зробили це, ви подивитеся на певну сутність, і вона має характеристики "слабкого" об'єкта, ви зможете відповідним чином задокументувати це або зафіксувати, якщо з якихось причин ви відчуваєте необхідність явно викликати це або заради формальності.

— Ед Гастінгс
джерело

хммм, а як же мій приклад? тут OrderItemзалежить від того Order, що жодне не orderItemsможе існувати без належності до order, але я не можу зрозуміти, чому я не можу використовувати ItemLineNumberлише ідентифікацію предмета ?! Насправді я можу просто створити ItemLineNumberавтоматичне створення, intщоб забезпечити унікальність і використовувати зовнішній ключ orderIDдля зв’язку двох об'єднань разом ?!

— Songo

2

Якщо ви визначите свій OrderItem унікальним ідентифікаційним послідовним ідентифікатором, а OrderId не є частиною ключа, ви ставитеся до OrderItems як до громадян першого порядку і насправді не має слабкої сутності. Ви можете FK інші таблиці для OrderItems окремо, якщо хочете; зайве вже мати OrderId, щоб отримати в OrderItems. З іншого боку, якщо ви ввели команду OrderItem за допомогою OrderId та послідовного ID (або подібного), що мають відношення до Порядку, у вас буде слабке ціле, а окремі рядки-позиції мали б бути посиланнями лише за допомогою OrderId та rowId. Використання моделі за призначенням.

— Ед Гастінгс

2

Крім того, дотичний коментар, може бути дуже спокусливим просто надати кожній таблиці свій власний послідовний первинний ключ, а також зберегти відносини максимально просто з єдиними полями PK-> FK відносини. Зокрема, це чудово підходить для простих баз даних, і про це легко розмірковувати. Однак, моделюючи складніші та / або складніші зв'язки, складові клавіші стають дуже корисними та надають більше варіантів моделювання нюансів.

— Ед Гастінгс

1

Не OrderItemможе існувати без замовлення чи товару. Отже, він слабкий, оскільки залежність контролює його.

Якщо ви, наприклад, видалите замовлення, у вас немає можливості знати, куди товар повинен бути відправлений. Або якщо ви виймаєте продукт, ви не знаєте, що доставити.

— jgauffin
джерело

-1

Згідно з моїм розумінням, у вищенаведеній діаграмі вони включили дві сутності / таблиці замість одного, тобто замовлення та елемента замовлення, щоб отримати доступ до інформації стає простим, коли два об'єкти розроблені. А елемент замовлення залежить від суб'єкта замовлень, тому його розглядають як слабке підприємство. тому що характеристика слабкої сутності полягає в тому, що вона залежить від іншої сутності. Припустимо, якщо ви не включите особу товару замовлення, як ви зможете дізнатися ціну товару, знижку. і як сказав jgauffin Якщо ви, наприклад, видалите замовлення, ви не можете знати, куди товар повинен бути відправлений. Або якщо ви виймаєте продукт, ви не знаєте, що доставити.

Діаграма ER повинна бути розроблена відповідно до вимог бізнесу.

— Сем
джерело

-1

Дивіться, у замовлення є багато елементів замовлення (багатозначний атрибут). Таким чином, за правилом ми створюємо окрему таблицю.

Скажімо, 2 клієнти мають однаковий порядок. Наприклад, обидва купують iPhone за тією ж ціною, знижками, тією ж датою тощо. Тому в ідеалі повинні бути два точні кортежі для замовлення iPhone у порядку зв’язку. Але згідно з обмеженням відношення, всі кортежі повинні бути унікальними. Тож давайте дозволити відновити два замовлення до тієї самої проблеми item_line_number.no, як зараз Тепер розглянемо одну із скасування клієнтів. Чи замовлено iPhone.також кордон item_line_number буде видалено. Тепер інші клієнти, які придбали iPhone, також видаляються через листування M: 1. Тож нарешті база даних є непослідовною. Ось чому ми використовуємо дескрипторний ключ, який буде orderid.thus видалення одного замовленого iPhone не призводить до пошкодження бази даних.

— VIVEK барсопія
джерело