1

a busy cat 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

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.

  • A very good explanation!. But one more thing. When deciding whether it's weak or not, do we have to consider the real nature? for an example now in an insurance company really, A vehicle entity really depends on the customer. But in nature, it can exist on its own. But in the DB it won't make any sense to have a vehicle without an owner. I think this is what you are saying by problem domain. right? – Nuwan Karunarathna Aug 23 '17 at 15:22
  • @NuwanKarunarathna We don't need to model all details of reality. The data model is a simplified view that is more convenient to work with. The “problem domain” is a common term to describe the set of concepts, constraints and requirements that we need to solve. The “insurance company” would be one problem domain, “car dealership” a completely different one. How we should model something can only be answered in the context of the problem domain. A car may or may not be an entity for an insurance company, but it would likely be an entity for a car dealer. – amon Aug 23 '17 at 15:51
3

In the Wikipedia article you are referring to, it says:

a weak entity is an entity that cannot be uniquely identified by its attributes alone

The idea is that the entity by itself contains incomplete information; in the example depicted, there could be several OrderItem entities which all have the same attributes (if you don't count the OrderNumber FK), but are actually related to different Order entities.

In contrast, each Order is uniquely determined by its primary key. Yes, there exist a relation with the Customer, but note that the order doesn't lose its identity if the reference to the CustomerNumber is removed. (Sure, it's a little weird to have an order and not know who the customer is, but the way this is conceptualized, the order really exists independently of the customer, once created.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.