How to really decide whether an entity is weak or not

This is the ER diagram example from the Wikipedia. Here they have marked the Orders entity as a strong entity.
As I understand a weak entity is an entity which cannot exist without a corresponding strong entity.

In this case, I think the Orders entity is existence-depended on the Customer entity. Because an Order would not exist without a corresponding customer.

So even though we can have a primary key for the Orders entity isn't it depends on the Customer ? Isn't it needs to be a weak entity?

I will be glad if someone can explain this.

2 Answers 2

There is a bit of wiggle room whether some concept should be modelled as an entity or as a weak entity.

You notion that weak entities cannot exist without another entity isn't wrong, it's just not the defining feature. Strong entities can reference other entities without becoming weak entities.

Instead, we should ask whether the entity exists independently of the values it contains. In databases, this question is usually equivalent to: does this entity have an ID?

Strong entities exists regardless of what values they have, so they can only be identified by their ID. In your data model: two different customers can live at the same address, but are different customers because they have a different CustomerNumber. Here, it is modelled that Orders have an OrderNumber.

Weak entities are identified by their values. Here, OrderItems are identified by the combination of Order+ItemLineNumber (a composite key). The ItemLineNumber is not a primary key on its own because multiple items can have the same line number, if they are part of different Orders.

Of course this could have been modelled differently. The Orders could be a weak entity that's identified by Customer+OrderNumber. Or each OrderItem could have an ID field, elevating it to a strong entity.

So when should you chose which variant? This depends entirely on the context. The "X belongs to Y" or "X cannot exist without Y" rule is a good heuristic that X might be a weak entity. Then you think about the problem domain. E.g. in my country invoices need to have a unique number, so it makes sense to use the invoice number as an ID for the order – the order has a natural key/domain key. You should also think about how the database will be queried. If an entity is the target of some foreign key reference, queries will be much easier if it is a strong entity with an ID – you can assign a surrogate key/synthetic key.