Correct option is A
In a typical employee schema, Employee ID is a unique identifier assigned to exactly one employee, and each employee (hence each Employee Name instance) has exactly one ID.
This creates a bijective (1:1) correspondence between the set of valid names and the set of IDs within the organization’s database.
In Chen notation, such a relationship means each entity on either side participates in at most one relationship instance with the other.
While real-world names can repeat across different people, within the Employee entity an individual’s name attribute instance maps to just one ID, and that ID maps back to that same person.
Hence the relationship shown is one-to-one.
In Chen notation, such a relationship means each entity on either side participates in at most one relationship instance with the other.
While real-world names can repeat across different people, within the Employee entity an individual’s name attribute instance maps to just one ID, and that ID maps back to that same person.
Hence the relationship shown is one-to-one.
Important Key Points
- Uniqueness: Employee ID is a key—unique and non-null—so one ID ↔ one employee.
- Participation: Each employee must have an ID (total participation), and each ID refers to one employee (single participation).
- 1:1 vs 1:N: If either side could associate with multiple instances (e.g., one ID to many names), it would be 1:N—not the case here.
- Modeling note: Practically, both “name” and “ID” are attributes of the Employee entity; the diagram simplifies them as boxes for the relationship question.
- Keys & constraints: Implement with a primary key on EmployeeID and a (non-key) attribute Name for the employee; optional UNIQUE on (EmployeeID) is inherent.
- Normalization: Keeping ID as the key avoids anomalies and supports efficient joins and indexing.
Knowledge Booster
- Why not (b) One to many? That would imply one name maps to multiple IDs (e.g., the same person given several IDs), which violates ID uniqueness.
- Why not (c) Many to many? That would allow multiple names per ID and multiple IDs per name—contradictory to unique identifier semantics.
- Why not (d) Many to one? That would imply many IDs for a single name instance, again breaking the unique key constraint for employees.
English
160 Questions
400 Marks
120 Mins
