In transforming an entity–relationship (ER) model to a relational schema, is it correct that each entity type is represented as a separate table (with relationships mapped via keys or associative tables)?

Introduction / Context:
Logical design converts an ER model into a relational schema. A core rule is that each entity type becomes a table (relation), while relationships are enforced with foreign keys or separate intersection (associative) tables for many-to-many links.

Given Data / Assumptions:

• Standard ER-to-relational mapping is being applied.
• Attributes of entities become columns in the corresponding table.
• Identifiers (primary keys) are chosen as natural or surrogate keys.

Concept / Approach:
Every entity type (strong or weak) maps to a table. One-to-many relationships become foreign keys in the “many” side. Many-to-many relationships become separate intersection tables with foreign keys to both parents. Subtype/supertype hierarchies map via one of several patterns (single table, class table, or concrete table inheritance). The statement focuses on entities, and that mapping is correct.

Step-by-Step Solution:

Verification / Alternative check:
Compare the resulting schema to the ERD: counts of entity types should match counts of core tables (excluding associative tables introduced for M:N relationships).

Why Other Options Are Wrong:

• Restricting to weak or supertype entities ignores standard mapping.
• “Entities become views” is design-specific and not the default mapping rule.
• “Incorrect” contradicts standard methodology.

Common Pitfalls:
Forgetting to normalize multi-valued attributes; failing to create intersection tables for M:N; mishandling subtype mapping and keys.

Final Answer:
Correct