Consider marriages. A marriage is a relationship between two persons.
Let's suppose `Person` is a strong entity set. We can register `Marriage` as a relationship set that refers to the two participating persons. It will then have two different foreign keys to `Person`: `Person`'s primary key will be included into `Marriage` twice (with different column names).
This will suffice, if all we need to record is whether two persons are married, or have been married.
We may add attributes, e.g. the date of marriage.
`Marriage` will continue to be a relationship set as long as the primary key consists of attributes in the foreign keys (i.e. marriages are identified by the identities of the marriage partners).
However, [Elizabeth Taylor][1] and [Richard Burton][2] were married twice. If we need to be able to distinguish between those marriages, we'll need to record both separately, and we'll need to add an attribute to the primary key.
Let's say we add the date of marriage to the primary key (and hope no couple will ever marry twice on the same day).
Now, we have a weak entity: the primary key partly, but not completely, consists of foreign keys.
Is this a reasonable design? It may be; if this is all the information we can gather about marriages, it may well be the best design.
However, chances are that we may be able to add other attributes that can help identify marriages. For instance, if the purpose of our database is to serve as an official registry of marriages, chances are that the process of marriage involves stamping each marriage with an official code or number of some kind, that needs to be recorded, and hence, is a uniquely identifying attribute for marriages.
In that case, we can turn that attribute into the primary key, and voilà: `Marriage` is a strong entity.
In summary: whether something turns out to be a relationship, a weak entity, or a strong entity, depends not only on what you're trying to model, but also on what information about it you have available.
[1]: https://en.wikipedia.org/wiki/Elizabeth_Taylor [2]: https://en.wikipedia.org/wiki/Richard_Burton

It's not that simple.
Consider marriages. A marriage is a relationship between two persons.
Let's suppose `Person` is a strong entity set. We can register `Marriage` as a relationship set that refers to the two participating persons. It will then have two different foreign keys to `Person`: `Person`'s primary key will be included into `Marriage` twice (with different column names).
This will suffice, if all we need to record is whether two persons are married, or have been married.
We may add attributes, e.g. the date of marriage.
`Marriage` will continue to be a relationship set as long as the primary key consists of attributes in the foreign keys (i.e. marriages are identified by the identities of the marriage partners).
However, [Elizabeth Taylor][1] and [Richard Burton][2] were married twice. If we need to be able to distinguish between those marriages, we'll need to record both separately, and we'll need to add an attribute to the primary key.
Let's say we add the date of marriage to the primary key (and hope no couple will ever marry twice on the same day).
Now, we have a weak entity: the primary key partly, but not completely, consists of foreign keys.
Is this a reasonable design? It may be; if this is all the information we can gather about marriages, it may well be the best design.
However, chances are that we may be able to add other attributes that can help identify marriages. For instance, if the purpose of our database is to serve as an official registry of marriages, chances are that the process of marriage involves stamping each marriage with an official code or number of some kind, that needs to be recorded, and hence, is a uniquely identifying attribute for marriages.
In that case, we can turn that attribute into the primary key, and voilà: `Marriage` is a strong entity.
In summary: yes, a weak entity can very well have multiple identifying strong entities, and whether something turns out to be a relationship, a weak entity, or a strong entity, depends not only on what you're trying to model, but also on what information about it you have available.
[1]: https://en.wikipedia.org/wiki/Elizabeth_Taylor [2]: https://en.wikipedia.org/wiki/Richard_Burton