When should we use weak entities when modelling a database?

Question

This is basically a question about what are weak entities? When should we use them? How should they be modeled?

What is the main difference between normal entities and weak entities? Does weak entities correspond to value objects when doing Domain Driven Design?

To help keep the question on topic here is an example taken from Wikipedia that people can use to answer these question:

In this example OrderItem was modeled as a weak entity, but I can't understand why it can't be modeled as a normal entity.
Another question is what if I want to track the order history (i.e. the changes in it status) would that be a normal or weak entity?

Answer 1

Formally a "weak" entity has the following characteristics.

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.

I would say that in practice you wouldn't overtly decide to make something a "weak" entity per se; you would instead structure the data to be representative of whatever you are trying to model.

If, after you have done this, you look at a particular entity and it has the characteristics of a "weak" entity, you can document or diagram it accordingly, if for some reason you feel the need to explicitly call this out or for the sake of formality.

---

If you define your OrderItem to have a uniquely identifying sequential id, and the OrderId is not part of the key, then you are treating OrderItems as first order citizens and don't really have a weak entity.

You could FK other tables to OrderItems individually if you wanted to; it is unnecessary to already have an OrderId to get at OrderItems. On the other hand if you keyed OrderItem with OrderId and a sequenceId (or similar) relevant to the Order, you would have a weak entity and individual line items would only be referenceable using the OrderId and sequenceId. Model usage as intended.

Answer 2

An OrderItem can not exist without an order or an product. Hence it's weak since it's dependencies control it.

If you for instance remove the order you have no way of knowing where the item should be shipped. Or if you remove the product you don't know what to ship.

Answer 3

According to my understanding in the above diagram they have included the two entities/tables instead of one i.e orders and order item so that accessing the information becomes easy when two entities are designed. And order item is dependent on orders entity so it is considered as an weak entity. because the characteristic of weak entity is it depends on another entity. Suppose if you do not include order item entity how will you be able to know order item's price,discount. and as jgauffin said If you for instance remove the order you have no way of knowing where the item should be shipped. Or if you remove the product you don't know what to ship.

The ER diagram is to be designed according to the business requirement.

Answer 4

See ,a order has many order items(multivalued attribute). Thus according to rule we create separate table.

Now,let's say 2 customers has same order.e.g both buy iPhone at same price,discount, same date,etc. So ideally there should be two exact tuples for order of iPhone in orderitem relation. But according to constraint of a relationn,all the tuples should be unique. So lets relate two orders to same item_line_number.no problem uptil now. Now consider one of the customer cancels. Is iPhone order.also the item_line_number tuple will be deleted. Now other customer's who bought iPhone also gets deleted because of M:1 correspondence. So finally the database is inconsistent. That's why we use a descriptor key which will be orderid.thus deleting one iPhone ordered doesn't cause database corruption.