Formally a "weak" entity has the following characteristics.
It is existence-dependent on another entity.
i.e., it cannot exist without the entity with which it has a relationship.
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
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
sequenceId. Model usage as intended.