Converting an ER Diagram into a Relational Schema (ER-to-Relational Mapping)

1. Introduction

One of the most important concepts in Database Management Systems (DBMS) is converting an Entity-Relationship (ER) Diagram into a Relational Schema.

An ER diagram represents entities, attributes, relationships, and constraints in a database. However, before implementing the database using SQL, we need to convert this conceptual design into relational tables.

In this tutorial, we will learn how to:

• Convert strong and weak entity sets into tables.
• Handle composite, multivalued, and derived attributes.
• Convert different types of relationships into relational schemas.
• Apply primary key and foreign key constraints.
• Handle cardinality and participation constraints.
• Convert ternary relationships and aggregation.
• Convert specialization and generalization into relational tables.

The main objective is to create a relational schema that:

1. Preserves the constraints specified in the ER diagram.
2. Minimizes unnecessary data redundancy.
3. Maintains relationships between different tables.

Let's understand each concept with examples.

---

Part 1: Mapping Entity Sets into Relational Tables

2. Strong Entity Set

A strong entity set has its own primary key, which uniquely identifies each entity.

Consider a Student entity set with the following attributes:

• Enrollment Number
• Name
• Contact Number

Here, Enrollment Number is the identifying attribute because it uniquely identifies each student.

ER Diagram Representation

Student entity:

• Enrollment Number (Primary Key)
• Name
• Contact Number

Relational Schema

To convert a strong entity set into a relational table:

1. Create one table for the entity set.
2. Include all its simple attributes as columns.
3. Convert the identifying attribute into the primary key.

Therefore, the relational schema becomes:

STUDENT (Enrollment_No, Name, Contact_No)

Primary Key: Enrollment_No

Example Table

Enrollment_No (PK)	Name	Contact_No
101	Raj Kumar Misra	222222
102	Sanat K Roy	333333

Each row represents one student entity.

Remember: Every strong entity set is generally converted into one relational table, and its identifying attribute becomes the primary key.

---

3. Composite Attributes

A composite attribute is an attribute that can be divided into smaller meaningful attributes.

For example, consider the Name attribute of a student.

It can be divided into:

• First Name
• Middle Name
• Last Name

Instead of storing the complete name in one column, we store its individual components in separate columns.

ER Diagram Representation

Student:

• Enrollment Number (Primary Key)
• Name
  • First Name
  • Middle Name
  • Last Name
• Contact Number

Relational Schema

When converting a composite attribute into a relational table:

• Do not create a separate column for the composite attribute itself.
• Include each component of the composite attribute as an individual column.

Therefore:

STUDENT (Enrollment_No, F_Name, M_Name, L_Name, Contact_No)

Primary Key: Enrollment_No

Example Table

Enrollment_No (PK)	F_Name	M_Name	L_Name	Contact_No
101	Raj	Kumar	Misra	222222
102	Sanat	K	Roy	333333

Here, F_Name, M_Name, and L_Name together represent the composite attribute Name.

Remember: A composite attribute is replaced by its individual components when creating a relational schema.

---

4. Multivalued Attributes

A multivalued attribute is an attribute that can have multiple values for a single entity.

For example, a student may have multiple contact numbers.

Consider:

• Student 101 has two contact numbers.
• Student 102 has three contact numbers.

Problem with Storing Multiple Values in One Column

One approach is to store all contact numbers in a single column, separated by commas.

Enrollment_No	Name	Contact_No
101	Raj	222222, 444444
102	Sanat	333333, 555555, 666666

However, this design creates problems:

• Searching for a particular contact number becomes difficult.
• Updating individual contact numbers becomes complicated.
• It does not follow the standard relational model's requirement that each field contain a single atomic value.

Another Approach: Repeating Rows

We could create a separate row for every contact number.

Enrollment_No	Name	Contact_No
101	Raj	222222
101	Raj	444444
102	Sanat	333333
102	Sanat	555555
102	Sanat	666666

But this creates unnecessary data redundancy.

For example, student 102's name is repeated three times because the student has three contact numbers.

Correct Approach: Create Two Tables

The better approach is to decompose the original relation into two tables.

Table 1: STUDENT

Enrollment_No (PK)	F_Name	M_Name	L_Name
101	Raj	Kumar	Misra
102	Sanat	K	Roy

Table 2: STUDENT_CONTACT

Enrollment_No (FK)	Contact_No
101	222222
101	444444
102	333333
102	555555
102	666666

Relational schemas:

• STUDENT (Enrollment_No, F_Name, M_Name, L_Name)
• STUDENT_CONTACT (Enrollment_No, Contact_No)

In the STUDENT_CONTACT table:

• Enrollment_No is a foreign key referencing STUDENT.
• The combination of Enrollment_No and Contact_No forms the composite primary key, assuming duplicate contact numbers per student are not allowed.

Important Rule: A multivalued attribute is represented by creating a separate table containing the primary key of the original entity and the multivalued attribute.

---

5. Derived Attributes

A derived attribute is an attribute whose value can be calculated from another attribute.

For example, consider:

• Date of Birth
• Age

Age can be calculated using the Date of Birth.

Date of Birth is called a base attribute, whereas Age is a derived attribute.

Why Should We Avoid Storing Age?

Age changes over time, but Date of Birth remains constant.

If we store age directly in the database, we must continuously update it.

Instead, we can calculate age whenever required using Date of Birth.

Relational Schema

STUDENT (Enrollment_No, F_Name, M_Name, L_Name, Date_of_Birth)

Primary Key: Enrollment_No

We normally do not store the derived attribute Age because it can be calculated from Date_of_Birth.

Remember:

• Base attribute: Stored directly in the database.
• Derived attribute: Calculated using another attribute.

---

Part 2: Mapping Relationships into Relational Tables

6. Many-to-Many (M:N) Relationship

Consider two entity sets:

1. STUDENT
2. COURSE

They are connected through a relationship called ENROLLS.

A student can enroll in multiple courses, and a course can have multiple students.

Therefore, it is a Many-to-Many (M:N) relationship.

Cardinality Constraints

• A student can enroll in zero or more courses.
• A course can have zero or more students.

In other words:

• Student: 0 to N
• Course: 0 to N

How to Convert M:N Relationships into Tables?

Important Rule: For a Many-to-Many relationship, create a separate table for the relationship set.

The primary keys of both participating entity tables become foreign keys in the relationship table.

Consider the following tables.

STUDENT

Student_No (PK)	Student_Name
101	Raj
102	Sanat

COURSE

Course_No (PK)	Course_Name
CS101	Computer Science
MT110	Mathematics

ENROLLS

Student_No (FK)	Course_No (FK)
101	CS101
102	CS101
102	MT110

The relational schemas are:

• STUDENT (Student_No, Student_Name)
• COURSE (Course_No, Course_Name)
• ENROLLS (Student_No, Course_No)

The composite primary key of ENROLLS is:

(Student_No, Course_No)

Both columns are also foreign keys.

Understanding the Relationship

From the ENROLLS table:

• Raj (101) is enrolled in Computer Science.
• Sanat (102) is enrolled in Computer Science.
• Sanat (102) is also enrolled in Mathematics.

What if a course has no students?

Simply do not insert any corresponding record in the ENROLLS table.

For example, if Mathematics has no enrolled students, there will be no entry containing MT110 in ENROLLS.

Similarly, if Raj is not enrolled in any course, there will be no entry containing 101 in ENROLLS.

This is possible because both sides have optional participation.

Relationship with Descriptive Attributes

Sometimes, a relationship has its own attributes.

For example, consider Enrollment_Date, which records when a student enrolled in a particular course.

This attribute belongs to the relationship ENROLLS, not directly to STUDENT or COURSE.

Therefore, we add it to the relationship table.

ENROLLS (Student_No, Course_No, Enrollment_Date)

Primary Key: (Student_No, Course_No)

Remember: For an M:N relationship, create a separate table containing the primary keys of both participating entities and any descriptive attributes of the relationship.

---

7. One-to-Many (1:N) Relationship

Consider the relationship between STUDENT and COURSE.

Suppose:

• A student can enroll in at most one course.
• A course can have multiple students.

This is a Many-to-One relationship from STUDENT to COURSE, or equivalently, a One-to-Many relationship from COURSE to STUDENT.

Cardinality Constraints

• Student: 0 to 1 course.
• Course: 0 to N students.

Important Rule

For a One-to-Many relationship:

The primary key of the ONE side becomes a foreign key in the MANY side.

Here:

• COURSE is the ONE side.
• STUDENT is the MANY side.

Therefore, Course_No becomes a foreign key in the STUDENT table.

Relational Schemas

COURSE

Course_No (PK)	Course_Name
CS101	Computer Science
MT110	Mathematics

STUDENT

Student_No (PK)	Student_Name	Course_No (FK)
101	Raj	MT110
102	Sanat	NULL
103	Vikas	CS101

Notice that:

• Raj is enrolled in Mathematics.
• Sanat is not enrolled in any course.
• Vikas is enrolled in Computer Science.

Since a student can enroll in zero courses, Course_No must allow NULL values.

Also, we do not need a separate table for the relationship.

Remember: In a 1:N relationship, place the primary key of the ONE side into the table on the MANY side as a foreign key.

---

8. One-to-One (1:1) Relationship

A One-to-One relationship means that one entity can be associated with at most one entity on the other side, and vice versa.

Consider two entity sets:

• DEPARTMENT
• MANAGER

Suppose:

• A department can have at most one manager.
• A manager can manage at most one department.

This is a 1:1 relationship.

Method 1: Treat It as a Many-to-One Relationship

We can treat a 1:1 relationship like a Many-to-One relationship.

Suppose we place the primary key of DEPARTMENT into MANAGER.

DEPARTMENT

Dept_No (PK)	Dept_Name
D101	Computer Science
D102	Mathematics

MANAGER

Manager_No (PK)	Manager_Name	Dept_No (FK)
M101	Raj	D101
M102	Sanat	D102

Here, Dept_No is a foreign key in MANAGER.

To maintain the 1:1 constraint, the foreign key must also have a UNIQUE constraint.

This prevents multiple managers from being assigned to the same department.

Alternatively, we can place Manager_No in the DEPARTMENT table.

Method 2: Combine Both Tables into One Table

If the relationship has total participation on both sides, we can combine both entity sets into a single table.

For example:

MANAGER_DEPARTMENT

Manager_No (PK)	Manager_Name	Dept_No (UNIQUE)	Dept_Name
M101	Raj	D101	Computer Science
M102	Sanat	D102	Mathematics

In this representation:

• Manager_No is the primary key.
• Dept_No is also unique.
• Both entity sets are represented in one table.

This is one possible design when both sides have total participation and the entities are in a 1:1 relationship.

Remember: For a 1:1 relationship, either side's primary key can be placed as a UNIQUE foreign key in the other table. If both sides have total participation, combining the tables is also possible.

---

Part 3: Participation Constraints

9. Cardinality and Participation Constraints Together

Cardinality and participation constraints are important when converting an ER diagram into relational tables.

Let's understand them with an example.

Consider STUDENT and COURSE.

Suppose:

• Every student must enroll in at least one course.
• Every student can enroll in at most one course.
• A course can have zero or more students.

Understanding the Constraints

For STUDENT:

• Minimum participation = 1
• Maximum participation = 1

Therefore, every student must enroll in exactly one course.

For COURSE:

• Minimum participation = 0
• Maximum participation = N

Therefore, a course may have no students or multiple students.

Relational Schema

COURSE

• Course_No (Primary Key)
• Course_Name

STUDENT

• Student_No (Primary Key)
• Student_Name
• Course_No (Foreign Key, NOT NULL)

Why is Course_No NOT NULL?

Because every student must enroll in at least one course.

Therefore, the foreign key cannot contain NULL.

The NOT NULL constraint enforces mandatory participation of STUDENT in the relationship.

Special Case: 1:1 Relationship with Total Participation on Both Sides

Suppose:

• Every manager must manage exactly one department.
• Every department must have exactly one manager.

In this situation, we can represent both entity sets using a single table.

MANAGER_DEPARTMENT

Manager_No (PK)	Manager_Name	Dept_No (UNIQUE)	Dept_Name
M101	Raj	D101	Computer Science
M102	Sanat	D102	Mathematics

Here:

• Manager_No is the primary key.
• Dept_No is UNIQUE.
• Both attributes are NOT NULL.

This ensures that each manager is associated with exactly one department and each department is associated with exactly one manager.

---

Part 4: Weak Entity Sets

10. Mapping Weak Entity Sets

A weak entity set is an entity set that cannot be uniquely identified using its own attributes alone.

It depends on a strong entity set for identification.

Consider:

• COURSE: Strong entity set.
• SECTION: Weak entity set.

A course can have multiple sections.

For example, a course may have sections belonging to different semesters and academic years.

ER Diagram Attributes

COURSE

• Course_ID (Primary Key)
• Title

SECTION

• Section_ID (Partial Key)
• Semester (Partial Key)
• Year (Partial Key)

The SECTION entity is weak because its attributes alone may not uniquely identify a section.

Important Rule

For a weak entity set:

1. Create a separate table for the weak entity.
2. Include all its attributes.
3. Include the primary key of the owner (strong) entity as a foreign key.
4. Combine the owner's primary key with the weak entity's partial key to form the complete primary key.

Relational Schemas

COURSE

Course_ID (PK)	Title
C101	Database Management
C102	Operating Systems

SECTION

Course_ID (FK)	Section_ID	Semester	Year
C101	S1	Spring	2026
C101	S2	Autumn	2026
C102	S1	Spring	2026

The primary key of SECTION is:

(Course_ID, Section_ID, Semester, Year)

The Course_ID is also a foreign key referencing COURSE.

Remember: The primary key of a weak entity is formed by combining the primary key of its strong entity with the partial key of the weak entity.

---

Part 5: Advanced Relationships

11. Ternary Relationships

Until now, we have considered binary relationships involving two entity sets.

A ternary relationship involves three entity sets.

Consider three entities:

• TEACHER
• STUDENT
• PROJECT

They are connected through a relationship called PROJECT_GUIDE.

This relationship represents which teacher guides which student for which project.

Mapping into Relational Tables

First, create separate tables for the three entity sets.

TEACHER

• Teacher_No (PK)
• Teacher_Name

STUDENT

• Student_No (PK)
• Student_Name

PROJECT

• Project_No (PK)
• Project_Name

Now create a separate table for the ternary relationship.

PROJECT_GUIDE

• Teacher_No (FK)
• Student_No (FK)
• Project_No (FK)
• Since

Primary Key

Assuming the combination of all three entities uniquely identifies each relationship occurrence, the primary key is:

(Teacher_No, Student_No, Project_No)

Final Relational Schemas

• TEACHER (Teacher_No, Teacher_Name)
• STUDENT (Student_No, Student_Name)
• PROJECT (Project_No, Project_Name)
• PROJECT_GUIDE (Teacher_No, Student_No, Project_No, Since)

Remember: A ternary relationship is represented by a separate relationship table containing the primary keys of all three participating entity sets, along with any descriptive attributes.

The exact primary key depends on the cardinality constraints of the ternary relationship.

---

12. Aggregation

Aggregation is an advanced concept in ER modeling.

Normally, a relationship connects two or more entity sets.

However, sometimes we need to establish a relationship between an existing relationship set and another entity set.

This concept is called aggregation.

Example

Consider the following entities:

• TEACHER
• STUDENT
• PROJECT

The relationship PROJECT_GUIDE represents a teacher guiding a student for a particular project.

Now suppose an EXAMINER evaluates this project guidance.

We introduce another relationship called EVALUATE.

This relationship connects:

• PROJECT_GUIDE
• EXAMINER

It also has a descriptive attribute called Evaluation_Date.

Step 1: Create Entity Tables

TEACHER

• Teacher_No (PK)
• Teacher_Name

STUDENT

• Student_No (PK)
• Student_Name

PROJECT

• Project_No (PK)
• Project_Name

EXAMINER

• Examiner_No (PK)
• Examiner_Name

Step 2: Create PROJECT_GUIDE

Since PROJECT_GUIDE is a ternary relationship, it contains the primary keys of all three participating entities.

PROJECT_GUIDE

• Teacher_No (FK)
• Student_No (FK)
• Project_No (FK)
• Since

Primary Key:

(Teacher_No, Student_No, Project_No)

Step 3: Create EVALUATE

Now consider EVALUATE as a relationship between PROJECT_GUIDE and EXAMINER.

Assuming it is a Many-to-Many relationship, the primary key of PROJECT_GUIDE and the primary key of EXAMINER become attributes in EVALUATE.

EVALUATE

• Teacher_No
• Student_No
• Project_No
• Examiner_No
• Evaluation_Date

Primary Key:

(Teacher_No, Student_No, Project_No, Examiner_No)

The first three columns together identify the PROJECT_GUIDE occurrence, and Examiner_No identifies the examiner.

Final Relational Schemas

• TEACHER (Teacher_No, Teacher_Name)
• STUDENT (Student_No, Student_Name)
• PROJECT (Project_No, Project_Name)
• EXAMINER (Examiner_No, Examiner_Name)
• PROJECT_GUIDE (Teacher_No, Student_No, Project_No, Since)
• EVALUATE (Teacher_No, Student_No, Project_No, Examiner_No, Evaluation_Date)

Remember: Aggregation allows a relationship set to participate in another relationship. When mapping it into relational tables, the primary key of the aggregated relationship is used to identify it in the new relationship table.

---

Part 6: Specialization and Generalization

13. Specialization in ER Diagrams

Specialization is the process of dividing a higher-level entity set into lower-level entity sets based on their specific characteristics.

For example, consider a university.

A PERSON can be classified into:

• FACULTY
• STUDENT

Here, PERSON is the superclass, while FACULTY and STUDENT are subclasses.

The subclasses inherit the attributes of the superclass.

For example:

PERSON

• ID (Primary Key)
• Name

FACULTY

• Salary

STUDENT

• Grade

There are two important constraints in specialization:

1. Overlapping and Disjoint
2. Total and Partial

Let's understand them with examples.

---

14. Overlapping and Partial Specialization

Consider a university where a person can be:

• A faculty member.
• A student.
• Both a faculty member and a student.
• Neither a faculty member nor a student.

For example, a Teaching Assistant (TA) may work as a faculty member and also study as a student.

This is called Overlapping Specialization because the same person can belong to multiple subclasses.

It is also Partial Specialization because some persons may belong only to the PERSON superclass without belonging to any subclass.

Method 1: Separate Tables for Superclass and Subclasses

Create three tables.

PERSON

ID (PK)	Name
101	Raj
102	Sanat
103	Vikas

FACULTY

ID (PK, FK)	Salary
101	50000
103	60000

STUDENT

ID (PK, FK)	Grade
102	A
103	B

Notice that person 103 belongs to both FACULTY and STUDENT.

This is possible because the specialization is overlapping.

Person 101 belongs only to FACULTY, person 102 belongs only to STUDENT, and person 103 belongs to both.

A person who belongs to neither subclass can still exist in PERSON.

Method 2: Include Common Attributes in Subclass Tables

If we want to avoid performing joins whenever we retrieve subclass information, we can duplicate the common attributes.

FACULTY

• ID (PK)
• Name
• Salary

STUDENT

• ID (PK)
• Name
• Grade

PERSON

• ID (PK)
• Name

This approach introduces redundancy because Name is stored in multiple tables.

However, it can reduce the need for joins when retrieving subclass information.

Remember: In overlapping specialization, an entity can belong to more than one subclass. In partial specialization, an entity may belong to none of the subclasses.

---

15. Disjoint and Partial Specialization

Consider a university where STUDENT can be divided into:

• UNDERGRADUATE STUDENT
• POSTGRADUATE STUDENT

Suppose a student can belong to only one of these categories.

For example, a student cannot be both an undergraduate and postgraduate student at the same time.

This is called Disjoint Specialization.

Now suppose some students cannot be classified into either category.

They still belong to the general STUDENT entity set.

This is called Partial Specialization.

Attributes

STUDENT

• Student_ID (Primary Key)
• Student_Name

UNDERGRAD_STUDENT

• Project_Marks

POSTGRAD_STUDENT

• Thesis_Marks

Method 1: Separate Tables

STUDENT

Student_ID (PK)	Student_Name
101	Raj
102	Sanat
103	Vikas

UNDERGRAD_STUDENT

Student_ID (PK, FK)	Project_Marks
101	85

POSTGRAD_STUDENT

Student_ID (PK, FK)	Thesis_Marks
102	90

Student 103 belongs only to the STUDENT superclass.

To retrieve complete undergraduate or postgraduate information, we can join the corresponding subclass table with STUDENT.

Method 2: Duplicate Common Attributes

Alternatively, we can include Student_Name in the subclass tables.

UNDERGRAD_STUDENT

• Student_ID
• Student_Name
• Project_Marks

POSTGRAD_STUDENT

• Student_ID
• Student_Name
• Thesis_Marks

This avoids some joins but introduces redundancy.

Remember:

• Disjoint: An entity can belong to only one subclass.
• Partial: An entity may belong to no subclass.

---

16. Disjoint and Total Specialization

Consider an entity set called PART.

Every part must belong to one of the following categories:

• PURCHASED_PART
• MANUFACTURED_PART

Suppose:

• A part cannot be both purchased and manufactured.
• Every part must be either purchased or manufactured.

This is called Disjoint and Total Specialization.

Attributes

PART

• Part_No (Primary Key)
• Part_Name

PURCHASED_PART

• Price
• Vendor

MANUFACTURED_PART

• Department

Mapping into Relational Tables

Since the specialization is total, every PART must belong to one of the subclasses.

Therefore, we can avoid creating a separate PART table and place the common attributes directly into the subclass tables.

PURCHASED_PART

Part_No (PK)	Part_Name	Price	Vendor
P101	Keyboard	500	Vendor A
P102	Mouse	300	Vendor B

MANUFACTURED_PART

Part_No (PK)	Part_Name	Department
P103	Monitor	Electronics
P104	CPU	Hardware

Here:

• Part_No is the primary key in both tables.
• Part_Name is duplicated because it is a common attribute of PART.
• Every part belongs to exactly one subclass.

This approach avoids the need to join the superclass table with a subclass table to retrieve complete subclass information.

Remember: In disjoint and total specialization, we can represent the subclasses using separate tables containing both inherited and subclass-specific attributes.

---

Part 7: Final Revision

17. Important ER-to-Relational Mapping Rules

ER Diagram Concept	Relational Mapping Rule
Strong Entity	Create a separate table with its primary key.
Composite Attribute	Replace it with its individual components.
Multivalued Attribute	Create a separate table containing the original primary key and the multivalued attribute.
Derived Attribute	Usually do not store it; calculate when required.
1:1 Relationship	Place one side's primary key as a UNIQUE foreign key in the other table, or combine tables when appropriate.
1:N Relationship	Place the primary key of the ONE side in the MANY side as a foreign key.
M:N Relationship	Create a separate relationship table containing both primary keys.
Weak Entity	Combine the owner's primary key with the weak entity's partial key.
Ternary Relationship	Create a separate table containing the primary keys of all participating entities.
Aggregation	Use the primary key of the aggregated relationship in the new relationship table.
Specialization	Map superclass and subclasses using an appropriate mapping strategy.

18. Important Interview Points

Before converting an ER diagram into a relational schema, remember these points:

1. Strong Entity: Its identifying attribute becomes the primary key.
2. Composite Attribute: Break it into smaller individual attributes.
3. Multivalued Attribute: Always consider creating a separate table.
4. Derived Attribute: Usually calculate it when required instead of storing it.
5. Many-to-Many Relationship: Create a separate relationship table.
6. One-to-Many Relationship: The primary key of the ONE side becomes a foreign key on the MANY side.
7. One-to-One Relationship: Use a UNIQUE foreign key and consider participation constraints.
8. Weak Entity: Combine the partial key with the owner's primary key.
9. Ternary Relationship: Consider all three participating entity keys.
10. Aggregation: A relationship can participate in another relationship.
11. Overlapping Specialization: An entity can belong to multiple subclasses.
12. Disjoint Specialization: An entity can belong to only one subclass.
13. Total Specialization: Every superclass entity must belong to at least one subclass.
14. Partial Specialization: Some superclass entities may not belong to any subclass.

---

19. Conclusion

Converting an ER diagram into a relational schema is an essential step in database design.

The process involves identifying entity sets, mapping attributes, converting relationships, and maintaining the required constraints using primary keys, foreign keys, UNIQUE constraints, and NOT NULL constraints.

The most important thing is to understand the mapping rules for different relationship types and specialization constraints.

Once these rules are clear, you can convert almost any ER diagram into a relational schema systematically.

Key takeaway: Always consider entity attributes, relationship cardinality, participation constraints, and primary key requirements before creating relational tables.

Important technical improvements made

I also corrected a few points in the original transcript that are important for DBMS exams and interviews:

• 1:1 relationship: A foreign key alone does not enforce 1:1. A UNIQUE constraint is also required.
• Multivalued attributes: The separate table should generally use a composite primary key when duplicate values are not allowed.
• Weak entities: The owner's primary key and partial key together form the weak entity's primary key.
• Ternary relationships: The combination of all three keys is not automatically always the primary key; it depends on the cardinality constraints.
• Total specialization: Separate subclass tables can contain inherited attributes without requiring a superclass table, provided the mapping preserves the required constraints.
• Age: It is better calculated from Date of Birth, but the calculation should account for whether the birthday has occurred in the current year.

The result is organized as a complete blog-style tutorial, suitable for DBMS study notes and interview preparation.