Bird
Raised Fist0
DBMS Theoryknowledge~6 mins

Converting ER diagrams to relational schema in DBMS Theory - Full Explanation

Choose your learning style10 modes available
Introduction
When designing a database, we often start with a picture showing how things relate to each other. But computers need a clear table format to store data. Converting these pictures into tables is the key step to make the design usable.
Explanation
Entities to Tables
Each entity in the diagram becomes a table in the database. The attributes of the entity turn into columns of that table. One attribute is chosen as the primary key to uniquely identify each row.
Entities become tables with attributes as columns and a primary key.
Relationships to Foreign Keys
Relationships between entities are represented by adding foreign keys. A foreign key is a column in one table that points to the primary key of another table. This shows how rows in one table connect to rows in another.
Relationships become foreign keys linking tables.
Handling One-to-One Relationships
For one-to-one relationships, you can add a foreign key to either table. This key references the other table's primary key, ensuring each row matches one row in the related table.
One-to-one relationships use a foreign key in one table referencing the other.
Handling One-to-Many Relationships
In one-to-many relationships, the table on the 'many' side gets a foreign key column. This column points to the primary key of the 'one' side table, linking many rows back to one row.
The 'many' side table holds the foreign key to the 'one' side.
Handling Many-to-Many Relationships
Many-to-many relationships need a new table called a junction or associative table. This table has foreign keys pointing to the primary keys of both related tables. It breaks down the many-to-many link into two one-to-many links.
Many-to-many relationships become a new table with foreign keys to both tables.
Mapping Weak Entities
Weak entities depend on another entity for identification. Their table includes a foreign key to the owner entity's primary key, combined with their own partial key to form a composite primary key.
Weak entities use composite keys combining their own and owner’s keys.
Real World Analogy

Imagine organizing a library. Books are entities, each with details like title and author. Relationships show which books belong to which categories. To keep track, you create shelves (tables) for books and categories, and labels (foreign keys) to link them.

Entities to Tables → Books placed on shelves representing tables
Relationships to Foreign Keys → Labels on shelves showing which books belong to which categories
Handling One-to-One Relationships → A special shelf with one book linked directly to one category label
Handling One-to-Many Relationships → One category label linked to many books on the shelf
Handling Many-to-Many Relationships → A separate shelf holding cards that link books and categories together
Mapping Weak Entities → Books that need a special tag combining their own ID and the category’s ID
Diagram
Diagram
┌─────────────┐      ┌─────────────┐      ┌───────────────┐
│   Entity A  │      │   Entity B  │      │ Associative   │
│ (Table A)   │      │ (Table B)   │      │ Table (for    │
│ PK: A_id    │      │ PK: B_id    │      │ many-to-many) │
└─────┬───────┘      └─────┬───────┘      │ FK: A_id      │
      │                     │              │ FK: B_id      │
      │ One-to-many          │              └───────────────┘
      │ relationship         │
      ▼                     ▼
┌─────────────┐      ┌─────────────┐
│ Table B     │      │ Table A     │
│ FK: A_id    │◄─────┤ PK: A_id    │
└─────────────┘      └─────────────┘
Diagram showing entities as tables and how one-to-many and many-to-many relationships convert to foreign keys and associative tables.
Key Facts
Entity → A real-world object or concept represented as a table in a database.
Primary Key → A unique identifier for each row in a table.
Foreign Key → A column that links one table to the primary key of another table.
One-to-Many Relationship → A relationship where one row in a table relates to many rows in another.
Many-to-Many Relationship → A relationship where many rows in one table relate to many rows in another, requiring a junction table.
Weak Entity → An entity that depends on another entity for its identification.
Code Example
DBMS Theory
CREATE TABLE Department (
  DeptID INT PRIMARY KEY,
  DeptName VARCHAR(100)
);

CREATE TABLE Employee (
  EmpID INT PRIMARY KEY,
  EmpName VARCHAR(100),
  DeptID INT,
  FOREIGN KEY (DeptID) REFERENCES Department(DeptID)
);

CREATE TABLE Project (
  ProjectID INT PRIMARY KEY,
  ProjectName VARCHAR(100)
);

CREATE TABLE EmployeeProject (
  EmpID INT,
  ProjectID INT,
  PRIMARY KEY (EmpID, ProjectID),
  FOREIGN KEY (EmpID) REFERENCES Employee(EmpID),
  FOREIGN KEY (ProjectID) REFERENCES Project(ProjectID)
);
OutputSuccess
Common Confusions
Thinking many-to-many relationships can be represented by just foreign keys in the two tables.
Thinking many-to-many relationships can be represented by just foreign keys in the two tables. Many-to-many relationships require a separate junction table with foreign keys to both related tables to properly represent the connections.
Believing that the primary key of an entity can be any attribute without uniqueness.
Believing that the primary key of an entity can be any attribute without uniqueness. The primary key must uniquely identify each row; attributes that can repeat cannot serve as primary keys.
Assuming weak entities can have independent primary keys.
Assuming weak entities can have independent primary keys. Weak entities use a composite key combining their partial key with the owner entity’s primary key to ensure uniqueness.
Summary
Entities in ER diagrams become tables with attributes as columns and a primary key.
Relationships are converted into foreign keys or new junction tables depending on their type.
Weak entities require composite keys combining their own and owner entity keys.

Practice

(1/5)
1. In converting an ER diagram to a relational schema, how is a one-to-many relationship typically represented?
easy
A. Add a foreign key in the table on the 'many' side referencing the 'one' side
B. Create a new table for the relationship
C. Add a foreign key in the table on the 'one' side referencing the 'many' side
D. Merge both entities into a single table

Solution

  1. Step 1: Understand one-to-many relationship

    In a one-to-many relationship, one entity instance relates to many instances of another entity.
  2. Step 2: Represent relationship in relational schema

    The foreign key is placed in the table representing the 'many' side, pointing to the 'one' side's primary key.
  3. Final Answer:

    Add a foreign key in the table on the 'many' side referencing the 'one' side -> Option A
  4. Quick Check:

    One-to-many = foreign key on many side [OK]
Hint: Foreign key goes on the 'many' side table [OK]
Common Mistakes:
  • Placing foreign key on the 'one' side
  • Creating unnecessary new tables for one-to-many
  • Merging entities incorrectly
2. Which of the following is the correct way to represent a many-to-many relationship in a relational schema?
easy
A. Add foreign keys in both entity tables referencing each other
B. Merge both entities into a single table
C. Create a new table with foreign keys referencing both entities
D. Add a foreign key in the 'one' side table referencing the 'many' side

Solution

  1. Step 1: Understand many-to-many relationship

    Many-to-many means multiple instances of one entity relate to multiple instances of another.
  2. Step 2: Represent many-to-many in relational schema

    Create a new table (junction table) with foreign keys referencing the primary keys of both entities.
  3. Final Answer:

    Create a new table with foreign keys referencing both entities -> Option C
  4. Quick Check:

    Many-to-many = new junction table [OK]
Hint: Use a new table for many-to-many relationships [OK]
Common Mistakes:
  • Adding foreign keys directly in entity tables
  • Merging entities incorrectly
  • Ignoring the need for a junction table
3. Given an ER diagram with entities Student(SID, Name) and Course(CID, Title) connected by a many-to-many relationship Enrolls, which relational schema correctly represents this?
medium
A. Student(SID, Name), Course(CID, Title, SID), Enrolls(SID, CID)
B. Student(SID, Name), Course(CID, Title), Enrolls(SID, CID)
C. Student(SID, Name, CID), Course(CID, Title)
D. Student(SID, Name), Course(CID, Title)

Solution

  1. Step 1: Identify entities and relationship type

    Student and Course are entities; Enrolls is many-to-many between them.
  2. Step 2: Convert entities and relationship to tables

    Student and Course become tables with their attributes. Enrolls becomes a new table with foreign keys SID and CID.
  3. Final Answer:

    Student(SID, Name), Course(CID, Title), Enrolls(SID, CID) -> Option B
  4. Quick Check:

    Many-to-many needs separate table [OK]
Hint: Many-to-many always needs a separate table [OK]
Common Mistakes:
  • Adding foreign key in Course for Student
  • Adding foreign key in Student for Course
  • Omitting the Enrolls table
4. You converted an ER diagram with a one-to-one relationship between Person and Passport by adding a foreign key PersonID in Passport. However, the database allows multiple passports for one person. What is the likely mistake?
medium
A. Foreign key in Passport lacks a UNIQUE constraint
B. Foreign key should be in Person table, not Passport
C. Passport table should be merged with Person table
D. PersonID should be primary key in Passport table

Solution

  1. Step 1: Understand one-to-one relationship enforcement

    One-to-one means each person has at most one passport and vice versa.
  2. Step 2: Check foreign key constraints

    Foreign key alone allows many passports per person unless a UNIQUE constraint is added to enforce one-to-one.
  3. Final Answer:

    Foreign key in Passport lacks a UNIQUE constraint -> Option A
  4. Quick Check:

    One-to-one needs UNIQUE foreign key [OK]
Hint: Add UNIQUE to foreign key for one-to-one [OK]
Common Mistakes:
  • Assuming foreign key alone enforces one-to-one
  • Placing foreign key in wrong table
  • Merging tables unnecessarily
5. An ER diagram has entities Author(AID, Name), Book(BID, Title), and a many-to-many relationship Writes with an attribute RoyaltyPercentage. How should you convert this to a relational schema?
hard
A. Create Author(AID, Name), Book(BID, Title), Writes(AID, BID)
B. Create Author(AID, Name), Book(BID, Title, RoyaltyPercentage), Writes(AID, BID)
C. Create Author(AID, Name, RoyaltyPercentage), Book(BID, Title), Writes(AID, BID)
D. Create Author(AID, Name), Book(BID, Title), Writes(AID, BID, RoyaltyPercentage)

Solution

  1. Step 1: Identify entities and relationship with attribute

    Author and Book are entities; Writes is many-to-many with attribute RoyaltyPercentage.
  2. Step 2: Convert entities and relationship with attribute

    Entities become tables with their attributes. The many-to-many relationship becomes a new table including foreign keys and the attribute RoyaltyPercentage.
  3. Final Answer:

    Create Author(AID, Name), Book(BID, Title), Writes(AID, BID, RoyaltyPercentage) -> Option D
  4. Quick Check:

    Relationship attributes go in junction table [OK]
Hint: Put relationship attributes in the new junction table [OK]
Common Mistakes:
  • Adding relationship attribute to entity tables
  • Omitting the junction table
  • Placing attribute in wrong table
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard