I don't think "generalization" is a native concept in the ER model, and I guess most RDBMS's don't offer a way to enforce that kind of relationship. I think it is more an Object Oriented concept. But if you want to implement it in a database, I think this could be an example: -Create a table EMPLOYEES, with columns to store all general information for an employee. -Create a table TEMPORARY_EMPLOYEES, with columns to store information that is specific to temporary employees, such as contract duration or others. -Create a table PERMANENT_EMPLOYEES with columns to store information that is specific to permanent employees. But this kind of relations can't be completely enforced by the RDBMS. At most you can define foreign keys to ensure that every permanent and temporary employee exist in the main employees table.

I don't think "generalization" is a native concept in the ER model, and I guess most RDBMS's don't offer a way to enforce that kind of relationship. I think it is more an Object Oriented concept. But if you want to implement it in a database, I think this could be an example: -Create a table EMPLOYEES, with columns to store all general information for an employee. -Create a table TEMPORARY_EMPLOYEES, with columns to store information that is specific to temporary employees, such as contract duration or others. -Create a table PERMANENT_EMPLOYEES with columns to store information that is specific to permanent employees. But this kind of relations can't be completely enforced by the RDBMS. At most you can define foreign keys to ensure that every permanent and temporary employee exist in the main employees table.