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

Question

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

5

Задан 18 May 2012, 19:49 от Songo

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 ответа

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

от Branko Dimitrijevic · Answer 1 · 18 May 2012, 19:29

Сущность не является слабой, потому что она не может существовать независимо, а потому, что она не может быть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":
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:

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, если вы не укажете свои ключи правильно, и вы не сможете сделать это без учета того, какой объект может быть идентифицирован независимо, а какой - нет.

от Hituptony · Answer 2 · 18 May 2012, 16:34

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 (дочерними), потому что у заказа может быть несколько строк заказа, этот метод, вероятно, будет лучшим.

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