I am having trouble with weak entities and weak relationships.
The problem is this:
For example a database has a customer(table1) who places an order(orders=table2). The order consists of order details(table3) (1 detail per product, eg order of 4 of product X) and the product detail is linked to the table product(table4).
Now customer and product are strong entities(?). According to me Order and OrderDetail are weak entities(?).
Now The table order detail has all the keys in it which seems wrong......
(see attachment)

My understanding of the term "weak" entity is that it is an entity that cannot be uniquely identified without reference to another entity. Sicne an Order normally has a unique Order Number attribute, an Order is not a weak entity by that definition. Order Line is, because an Order Line cannot be uniquely identified without refering to the Order to which it belongs.

Thanks!
I think I am getting a better understanding of it all. Is it not so that you can choose to model entities as weak or strong. Surely orders are dependent on a customer but it is usually given a unique order number making it a strong entity. Couldn’t this also be done with order Line? The advantage of modeling order line as weak is that you cannot inadvertently enter two order lines, on the same order, with the same product.

Yes, you could do that with an order line surrogate key. But you would still need to define an alternate unique identifier on (order number, product code) if it was a rule that the same product cannot appear twice in an order. So I suppose it would still be "weak".

To be honest, in 15 years or so of entity modelling I have never used the terms "weak" and "strong". I know what they are because someone asked a question a year or two ago, and so I Googled the terms. I'm not sure what purpose it serves. As I implied above, you don't really "choose" to make an entity weak or strong, it just is or isn't - unless you deliberately subvert the business rules by not defining a unique constraint like (order number, product code) where one should exist, or perhaps make a strong entity like Customer weak by including another entity's ID in the unique identifier (e.g. Branch ID + sequence within branch).

Perhaps these terms feature more in a different ERD style than the one I use (Barker).

The weak versus strong comes into play as you move toward the relational theory end of the database spectrum. It doesn't matter as much at the SQL level.

A strong entity can have predicates declared on the entity by itself. A weak entity needs to have all of the weak entities between it and it's nearest strong entity included within the predicate. To put that in more English terms, you can make a concrete statement about a strong entity, you can't make a concrete statement about a weak entity without including everything else that you need to get to a strong entity.

So in your example, you can state that an order exists because the order doesn't depend on anything else for it's existance... You can't be sure about the existance of an order line without refering to the order that includes that order line.

-PatP

the terms i'm familiar with are identifying and non-identifying foreign keys

(thank you, ERwin, for all the cheerful memories and frequent nightmares)

an identifying foreign key is included within the primary key