Weak entities depend on other strong entity sets to generate its Primary Key
A very good example of this is the entity set of dependants of an employee of a bank. The bank may want to store the dependants information for various reasons such as policies etc. In this case the dependants are not uniquely identified by their attributes (name, age, gender (most likely)); But together with the employee-id of the employee they can be distinguished. In this case the dependants are the weak entity set, the employees are the ‘Identifying Owner’ and the policy relationship is called the ‘Identifying relationship’. Note that the weak entity must always have full participation and also each entity in this set can have only one owner (Key constraint) otherwise, they are not uniquely determined by the strong entity set.
Another Example is the Course and Section entity sets.
In this case, the weak entity is the section which is dependent on the strong entity course. Together with the course-id and sec-id, year and semester the section can be uniquely determined. As stated before, a double line is used to indicate a weak entity and an identifying relationship.
Why not convert each weak entity to a strong entity?
For this we require multiple copies of the primary key, which leads to storage redundancy. (Wastage of a large amount of storage).