Вопрос по mysql, database, sql – Моделирование базы данных для слабой сущности

5

У меня есть 2 таблицы в моей базе данныхorders а такжеorderHistory.

 -----------------                    -----------------------
 |  orders       |                    |  orderHistory       |
 -----------------                    -----------------------
 | orderID  (PK) |                    | historyLineID  (PK) |
 | orderDate     |                    | status              |
 | price         |                    | quantity            |
 -----------------                    -----------------------

Сейчасorder может иметь несколькоhistory lines, Тем не менее,history line не может существовать самостоятельно. Я слышал, это называется слабой сущностью и, следовательно,PK отorders должен быть частьюPK столаorderHistory.

Questions

Is this really a correct weak entity relationship? Is there other ways to identify them? Should I add the PK of table order to table orderHistory and make it a composite primary key? In case I decide to add a new record to orderHistory, how will I add a new composite key? (orderID is available from table orders, but historyLineID should be auto incremented.) What if I decide to model this as a normal One-To-Many relationship where orderID is added as a foreign key only instead? what are the cons of doing so? Will ignoring Weak entities at all cause any problems later in a design provided all tables are in 3rd normal form?

Note

И то и другоеorderID & Амп;historyLineID суррогатные ключи. Заранее спасибо.

Ваш Ответ

2   ответа
7

Сущность не является слабой, потому что она не может существовать независимо, а потому, что она не может бытьidentified независимо. Следовательно, отношения, которые "приводят" для слабой сущности называется "идентификация" отношения. На практике это означает, что первичный ключ родителя переносится в (обычноправильный) подмножество дочернего PK (термин «слабая сущность» обычно определяется по отношению к первичным ключам, хотя теоретически он может применяться к любому ключу).

Совершенно законно иметь объект, который не может существовать независимо, но может быть идентифицирован независимо, другими словами, который находится в неидентифицирующем отношении к ненулевому значению.

Вы должны спросить: можетhistoryLineID быть уникальныйaloneили в сочетании сorderID? Я подозреваю, что последний случай, который сделал бы это слабым юридическим лицом.

Is this really a correct weak entity relationship?

То, что вы показали нам, не является слабой сущностью - родительский ПК не переносится в дочерний ПК.

Is there other ways to identify them?

У вас есть два основных варианта:

  • orderHistory has a composite PK: {orderID, historyLineID}, where orderID is FK. BTW, this PK could be considered "natural":

    enter image description here

  • orderHistory has a surrogate PK: {orderHistoryID}, while orderID is outside of the PK. You'd still need to have an alternate key {orderID, historyLineID} though:

    enter image description here

Should I add the PK of table order to table orderHistory and make it a composite primary key?

Да, это первый вариант, описанный выше. Если у вас нет детских отношений наorderHistory Само по себе это тоже лучшее решение. ЕслиorderHistory Есть ли дети, чем это может или не может быть лучшим решением, в зависимости от нескольких факторов.

What if I decide to model this as a normal One-To-Many relationship where orderID is added as a foreign key instead? what are the cons of doing so?

Это не или-или. Поле может быть как FK, так и частью (первичного или альтернативного) ключа, как показано выше.

Will ignoring Weak entities at all cause any problems later in a design provided all tables are in 3rd normal form?

Вы не сможете достичь 3NF, если вы не укажете свои ключи правильно, и вы не сможете сделать это без учета того, какой объект может быть идентифицирован независимо, а какой - нет.

хм, я понимаю вашу точку зрения. Таким образом, в основном, если я добавлю поле идентификатора суррогатного автоинкремента ко всем моим таблицам (как я всегда делал), то у меня никогда не будет слабых объектов, верно? Songo
@ Сонго Как вы определяете порядок? Если PK клиента находится в пределах PK заказа, то он слабый. Если это не так, то это не так. В обоих случаях заказ не может существовать без клиента.
хорошо я создал суррогатный первичный ключOrderID для столаOrders, Раньше я никогда не думал о слабых сущностях, поэтому для каждой существующей сущности я просто создавал суррогатный ключ кidentify их. Если мне нужно связать сущности, я просто использовал внешние ключи (1-1, 1-M & Амп;M-M). Я не уверен, что теперьidentify действительно значит: D Songo
@ Сонго Что такое средство, на самом деле описано в третьем абзаце моего ответа. Вы по существу должны выяснить, могут ли данные поля быть уникальными в отдельности, или вам нужно объединить их с PK родительского элемента. В случае порядка, если только OrderID является уникальным (что, как я догадываюсь, имеет место), то порядок не является слабой сущностью. Кстати, не создавайте суррогаты без разбора. InnoDB кластеризован, а альтернативные индексы в кластеризованных таблицах дороги, поэтому, если вы можете житьjust с "натуральным" составной PK (и 1 индекс), это обычно лучше, чем наличие как суррогатного, так и натурального ключа (и 2 индекса).
Спасибо за ваш ответ :) Просто чтобы точно понять, что вы имели в виду: & quot;An entity is not weak because it can't exist independently, but because it can't be identified independently.& quot; что, если у меня есть 2 таблицыcustomers & Амп;orders?Customer может иметь многоOrders, ноOrder принадлежит только одномуCustomer, Я смоделировал это в 2 таблицы, гдеCustomerID добавляется вOrders стол какFK только. Однако теперь, когда я думаю об этомOrder само по себе не имеет значения, если оно не сделаноCustomer, ДолженOrders слабым лицом? Songo
0
  1. It is a weak entity relationship because of the reliance, but it is essentially an instance of indecisiveness. An order may have one to many history lines, but each history line must have a orderID, correct?

Это звучит как необязательное обязательное отношение.  Таким образом, ваш идентификатор заказа имеет & quot; необязательный & quot; атрибуты в порядке истории ... 2. Вы можете частично решить проблему, превратив первичный ключ в состав orderID и historyLineID. 3. Вам нужно будет выполнить инволютивные отношения в таблице orderID. поэтому вам придется присоединиться к order.orderID и затем создать новый historyLineID, в противном случае вы не сможете создать что-то, что еще не существует. 4. Так и должно быть. Это гораздо проще понять будущим людям, работающим над сценарием, и, возможно, вам самим. Используйте внешний ключ, чтобы создать orderID (родительский) с несколькими historyLineID (дочерними), потому что у заказа может быть несколько строк заказа, этот метод, вероятно, будет лучшим.

ССЫЛКА НА САЙТ:введите описание ссылки здесь

Похожие вопросы