Когда мы должны использовать слабые объекты при моделировании базы данных?

12

Это в основном вопрос о том, что такое слабые сущности? Когда мы должны их использовать? Как они должны быть смоделированы?

В чем основное различие между нормальными и слабыми объектами? Соответствуют ли слабые объекты объектам-значениям при проектировании на основе домена?

Чтобы помочь сохранить вопрос по теме, вот пример из Википедии, который люди могут использовать для ответа на этот вопрос: введите описание изображения здесь

В этом примере OrderItemбыла смоделирована как слабая сущность, но я не могу понять, почему она не может быть смоделирована как нормальная сущность.
Другой вопрос: что если я хочу отслеживать историю заказов (т.е. изменения в ее статусе), это будет нормальная или слабая сущность?

— Songo
источник

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чтобы связать две сущности вместе ?!

— Сонго

2

Если вы определили свой OrderItem, чтобы иметь уникально идентифицирующий последовательный идентификатор, а OrderId не является частью ключа, то вы рассматриваете OrderItems как граждан первого порядка и на самом деле не имеете слабой сущности. Вы можете FK другие таблицы для OrderItems индивидуально, если вы хотите; уже нет необходимости иметь OrderId, чтобы попасть в OrderItems. С другой стороны, если вы введете OrderItem с OrderId и sequenceId (или аналогичным), относящимся к Order, у вас будет слабая сущность, и отдельные позиции будут ссылаться только с использованием OrderId и sequenceId. Использование модели по назначению.

— Эд Гастингс

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. Таким образом, удаление одного заказанного iPhone не приведет к повреждению базы данных.

— Вивек барсопия
источник