CHAPTER 2

Entity Relationship Model and Relational Model

Introduction:

What is an Entity Relationship Diagram?

An Entity Relationship Diagram (ERD) is a graphical representation that shows

how entities, such as people, objects, or concepts, relate to each other within a system.
ERDs are commonly used in database design to visualize the relationships between
entities and their attributes. They help in understanding the logical structure of databases by
showing entities' connections and relationships using symbols like rectangles, diamonds,
ovals, and connecting lines.
ERDs are essential for designing or debugging relational databases in software
engineering, business information systems, education, and research.

The Entity Relationship Model

The Entity Relationship Model is a model for identifying entities (like student, car or
company) to be represented in the database and representation of how those entities are
related. The ER data model specifies enterprise schema that represents the overall logical
structure of a database graphically.

Why Use ER Diagrams In DBMS?

• ER diagrams represent the E-R model in a database, making them easy to
convert into relations (tables).
• ER diagrams provide the purpose of real-world modelling of objects which
makes them intently useful.
• ER diagrams require no technical knowledge of the underlying DBMS used.
• It gives a standard solution for visualizing the data logically.

Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which
consists of these symbols:
• Rectangles: Rectangles represent Entities in the ER Model.
• Ellipses: Ellipses represent Attributes in the ER Model.
• Diamond: Diamonds represent Relationships among Entities.
 • Lines: Lines represent attributes to entities and entity sets with other
relationship types.
• Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
• Double Rectangle: Double Rectangle represents a Weak Entity.

Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database
System.

What is Entity?
An Entity may be an object with a physical existence – a particular person, car, house,
or employee – or it may be an object with a conceptual existence – a company, a job, or a
university course.
What is Entity Set?
 An Entity is an object of Entity Type and a set of all entities is called an entity set.
For Example, E1 is an entity having Entity Type Student and the set of all students is called
Entity Set. In ER diagram, Entity Type is represented as:

1. Types of Entity

There are two types of entity:

1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not
depend on other Entity in the Schema. It has a primary key, that helps in identifying it
uniquely, and it is represented by a rectangle. These are called Strong Entity Types.

2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set.
But some entity type exists for which key attributes can’t be defined. These are called Weak
Entity types.

For Example, A company may store the information of dependents (Parents, Children,
Spouse) of an Employee. But the dependents can’t exist without the employee. So Dependent
will be a Weak Entity Type and Employee will be Identifying Entity type for Dependent,
which means it is Strong Entity Type.
 A weak entity type is represented by a Double Rectangle. The participation of weak
entity types is always total. The relationship between the weak entity types and its identifying
strong entity type is called identifying relationship and it is represented by a double diamond.

2. What are Attributes?

Attributes are the properties that define the entity type. For example, Roll_No, Name,
DOB, Age, Address, and Mobile_No are the attributes that define entity type Student. In ER
diagram, the attribute is represented by an oval.

Types of Attributes

1. Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key
attribute. For example, Roll_No will be unique for each student. In ER diagram, the key
attribute is represented by an oval with underlying lines.

2. Composite Attribute

An attribute composed of many other attributes is called a composite attribute. For

example, the Address attribute of the student Entity type consists of Street, City, State, and
Country. In ER diagram, the composite attribute is represented by an oval comprising of
ovals.
3. Multivalued Attribute

An attribute consisting of more than one value for a given entity. For example,
Phone_No (can be more than one for a given student). In ER diagram, a multivalued attribute
is represented by a double oval.

4. Derived Attribute

An attribute that can be derived from other attributes of the entity type is known as a
derived attribute. e.g. Age (can be derived from DOB). In ER diagram, the derived attribute
is represented by a dashed oval.

The Complete Entity Type Student with its Attributes can be represented as:
 3. Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example,
‘Enrolled in’ is a relationship type that exists between entity type Student and Course. In ER
diagram, the relationship type is represented by a diamond and connecting the entities with
lines.

A set of relationships of the same type is known as a relationship set. The following
relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3.

Relationship set

What is Cardinality?
The number of times an entity of an entity set participates in a relationship set is
known as cardinality. Cardinality can be of different types:

1. One-to-One: When each entity in each entity set can take part only once in the
relationship, the cardinality is one-to-one. Let us assume that a male can marry one female
and a female can marry one male. So the relationship will be one-to-one.
the total number of tables that can be used in this is 2.

Using Sets, it can be represented as:

2. One-to-Many: In one-to-many mapping as well where each entity can be related to more
than one entity and the total number of tables that can be used in this is 2. Let us assume that
one surgeon department can accommodate many doctors. So, the Cardinality will be 1 to M.
It means one department has many Doctors.
total number of tables that can used is 3.

Using sets, one-to-many cardinality can be represented as:

3. Many-to-One: When entities in one entity set can take part only once in the relationship
set and entities in other entity sets can take part more than once in the relationship set,
cardinality is many to one. Let us assume that a student can take only one course, but one
course can be taken by many students. So the cardinality will be n to 1. It means that for one
course there can be n students but for one student, there will be only one course.
The total number of tables that can be used in this is 3.
Using Sets, it can be represented as:

each student is taking only 1 course but 1 course has been taken by many students.
4. Many-to-Many: When entities in all entity sets can take part more than once in the
relationship cardinality is many to many. Let us assume that a student can take more than one
course and one course can be taken by many students. So the relationship will be many to
many.
the total number of tables that can be used in this is 3.

Using Sets, it can be represented as:

In this example, student S1 is enrolled in C1 and C3 and Course C3 is enrolled by S1, S3,
and S4. So it is many-to-many relationships.

Need to Draw ER Diagram

ER diagram or ER model is drawn to visually represent the relationships between entities

in a database system. Some benefits of drawing ER diagrams for database design are:

➢ It helps in understanding the data relationships.

➢ ER diagrams are like a blueprint for designing a database.
➢ Helps in communicating about databases with database designers, developers, users,
etc.
➢ They help in describing different relationships and operations within an organization.

4. Steps to model an Entity Relation Diagram (ERD)

A step-by-step process to draw an entity relation diagram (ERD) is:

Step 1: Identifying Entities

➢ Determine the main objects you want to represent in the database. E.g., "students",
"courses", or "products".

Step 2: Defining Attributes

➢ Identify the properties(attributes) of properties of each entity. These attributes provide
more details about an entity.

Step 3: Specifying Relationships

➢ Create relationships between entities to specify how entities interact with each other.
Relationships are verbs like "teaches", "studies", or "sells".

Step 4: Drawing Entities

➢ Draw entities as rectangle and write the name.

Step 5: Adding Attributes

 ➢ To add attributes of a entity write attributes inside the rectangle or connect them with
lines.

Step 6: Connecting Entities

➢ Draw lines between the related entities to represent their connection.

Step 7: Specifying Cardinality

➢ Indicate the minimum and maximum number of relationship instances associated with
an entity using notations like crow's foot.

Step 8: Organizing ER Diagram

➢ Organize all entities and relationships in a clean way for better readability and
understanding.

Draw Entity Relationship Diagram Example

After learning the steps of how to draw an entity relationship diagram, we will create a demo
ER diagram.
Let’s take an example of ER diagram for a bank through which we can learn how to design
an ER and understand all the required methods.
Entity Relationship Diagram for BANK
We will follow the steps mentioned above, to draw entity relationship diagram for bank.

Defining Entities
A thing in the real world with an independent existence. It may be an object with physical
existence (ex: house, person) or with a conceptual existence (ex: course, job). They are
represented by rectangle.

Entities for Bank are:

Bank, Branch, Employee, customer, loan, account.

Adding Attributes
Attributes are the kind of properties that describe the entities. They are represented by ovals.

Attributes for Bank are:

➢ For Bank Entity the Attributes are Bname, code.

➢ For Branch Entity the Attributes are Blocation, Bname.
➢ For Employee Entity the Attributes are Eid, Designation, salary.
➢ For Customer Entity the Attributes are Cid, Cname, Address, DOB.
➢ For Loan Entity the Attributes are Loan_no, amount, rate.
➢ For Account Entity the Attributes are acc_no, type.
Establishing Relationships
Entities have some relationships with each other. Relationships define how entities are
associated with each other.
Let's Establishing Relationships between them are:

➢ The Bank has branches.

➢ The Branch provides loan.
➢ The Employee works in branch.
➢ The Branch contains customers.
➢ The Customers has account.
➢ The Branch maintains account.
➢ The Customer avails loan.
Specifying Cardinality
Cardinality defines the numerical constraints on the relationships between entities. It
is a notation that tells the ERD reader whether there are one, many or some combination of
those factors between each entity.

1. One to One relationship (1:1)

In the entity relationship diagram, the one-to-one relationship means that single entity
in one table is associated with single entity in another table. For example, one driver have
only one license.

2. One to Many relationship (1: N)

One to many relationships means that single entity in one table is related to more than
one entities in another table. For example, one bank has many branches.

3. Many to One(N:1)
Many-to-one relationship in entity relationship diagram means that multiple entities
are related to only single entity in another table. For example, many developers works on
single project.
4. Many to Many relationship(M: N)
Many to many relationship means that multiple entities in one table is associated with
multiple entities in another table. For example, multiple customers have multiple accounts.

Specify cardinality for Bank:

Bank and branch has One to Many relationship (a bank has multiple branches).
Branch and loan has also One to Many relationship(a branch can provide many loans).
Branch and employee has One to Many relationship(one branch has many employees).
Branch and account has One to Many relationship(one branch has many accounts).
Branch and customer has Many to Many relationship(multiple branches have multiple
customers).
Customer and account has Many to Many relationship(multiple customers have multiple
accounts).
Customer and loan has Many to Many relationships(multiple customers have multiple loans)
Identify Primary Keys
Primary keys are the unique identifier for each record in database table. It is denoted
by an underline under the attribute name.

➢ The Primary key of Bank is code.

➢ The Primary key of Branch is branch_code.
➢ The Primary key of Employee is Eid.
➢ The Primary key of Customer is Cid.
➢ The Primary key of Loan is loan_no.
➢ The Primary key of Account is acc_no.

Final ER Diagram
The below diagram is our final entity relationship diagram for bank with all entities,
their attributes and the relationship between them with the PRIMARY KEY and Cardinality
ratio.

Benefits of an ER Diagram:

• ER diagrams provides a clear and visual representation of the database structure.

This makes it easier for developers and designers to understand the relationships
between the entities.
• It is an effective communication tool for database designers and the stakeholders
which helps to understand the data model.
• ER diagrams serve as the foundation for designing the database schema. They guide
the creation of tables, relationships and constraints in the database management
system.
• Creating an ER diagram helps in understanding and analysing the data requirements
of the system.
• Database managers can more quickly and efficiently undertake maintenance
activities, including adding new entities or changing existing relationships.
5. Relational Model in DBMS
The Relational Model represents data and their relationships through a collection of
tables. Each table also known as a relation consists of rows and columns. Every column has a
unique name and corresponds to a specific attribute, while each row contains a set of related
data values representing a real-world entity or relationship. This model is part of the record-
based models which structure data in fixed-format records each belonging to a particular type
with a defined set of attributes.

E.F. Codd introduced the Relational Model to organize data as relations or tables. After
creating the conceptual design of a database using an ER diagram, this design must be
transformed into a relational model which can then be implemented using relational database
systems like Oracle SQL or MySQL.

What is the Relational Model?

The relational model represents how data is stored in Relational Databases. A
relational database consists of a collection of tables each of which is assigned a unique name.
Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE,
and AGE shown in the table.

Student Table
Key Terms
• Attribute: Attributes are the properties that define an entity. e.g. ROLL_NO,
NAME, ADDRESS.
• Relation Schema: A relation schema defines the structure of the relation and
represents the name of the relation with its attributes. e.g., STUDENT
(ROLL_NO, NAME, ADDRESS, PHONE, and AGE) is the relation schema for
STUDENT. If a schema has more than 1 relation it is called Relational Schema.
• Tuple: Each row in the relation is known as a tuple. The above relation contains
4 tuples one of which is shown as:

• Relation Instance: The set of tuples of a relation at a particular instance of time

is called a relation instance. It can change whenever there is an insertion,
deletion or update in the database.
• Degree: The number of attributes in the relation is known as the degree of
the relation. The STUDENT relation defined above has degree 5.
• Cardinality: The number of tuples in a relation is known as cardinality. The
STUDENT relation defined above has cardinality 4.
• Column: The column represents the set of values for a particular attribute. The
column ROLL_NO is extracted from the relation STUDENT.
• NULL Values: The value which is not known or unavailable is called a
NULL value. It is represented by NULL. e.g., PHONE of STUDENT having
ROLL_NO 4 is NULL.
• Relation Key: These are basically the keys that are used to identify the rows
uniquely or also help in identifying tables. These are of the following types:
o Primary Key
o Candidate Key
o Super Key
o Foreign Key
o Alternate Key
 o Composite Key

Why do we require Keys in a DBMS?

We require keys in a DBMS to ensure that data is organized, accurate, and easily
accessible. Keys help to uniquely identify records in a table, which prevents duplication
and ensures data integrity.
Keys also establish relationships between different tables, allowing for efficient
querying and management of data. Without keys, it would be difficult to retrieve or update
specific records, and the database could become inconsistent or unreliable.

Different Types of Database Keys

Super Key
The set of one or more attributes (columns) that can uniquely identify a tuple (record)
is known as Super Key. For Example, STUD_NO, (STUD_NO, STUD_NAME), etc.
• A super key is a group of single or multiple keys that uniquely identifies rows in
a table. It supports NULL values in rows.
• A super key can contain extra attributes that aren’t necessary for uniqueness. For
example, if the “STUD_NO” column can uniquely identify a student, adding
“SNAME” to it will still form a valid super key, though it’s unnecessary.
Example:
Table STUDENT
Candidate Key
The minimal set of attributes that can uniquely identify a tuple is known as a candidate
key. For Example, STUD_NO in STUDENT relation.
• A candidate key is a minimal super key, meaning it can uniquely identify a
record but contains no extra attributes.
• It is a super key with no repeated data is called a candidate key.
• The minimal set of attributes that can uniquely identify a record.
• A candidate key must contain unique values, ensuring that no two rows have the
same value in the candidate key’s columns.
• Every table must have at least a single candidate key.
• A table can have multiple candidate keys but only one primary key.
Example:
STUD_NO is the candidate key for relation STUDENT.
Table STUDENT
Primary Key
There can be more than one candidate key in relation out of which one can be chosen
as the primary key. For Example, STUD_NO, as well as STUD_PHONE, are candidate keys
for relation STUDENT but STUD_NO can be chosen as the primary key (only one out of
many candidate keys).
• A primary key is a unique key, meaning it can uniquely identify each record
(tuple) in a table.
• It must have unique values and cannot contain any duplicate values.
• A primary key cannot be NULL, as it needs to provide a valid, unique
identifier for every record.
• A primary key does not have to consist of a single column. In some cases,
a composite primary key (made of multiple columns) can be used to uniquely
identify records in a table.
• Databases typically store rows ordered in memory according to primary key for
fast access of records using primary key.
Alternate Key
An alternate key is any candidate key in a table that is not chosen as the primary key.
In other words, all the keys that are not selected as the primary key are considered alternate
keys.
• An alternate key is also referred to as a secondary key because it can uniquely
identify records in a table, just like the primary key.
• An alternate key can consist of one or more columns (fields) that can uniquely
identify a record, but it is not the primary key
• Eg:- SNAME, and ADDRESS is Alternate keys
Foreign Key
A foreign key is an attribute in one table that refers to the primary key in another
table. The table that contains the foreign key is called the referencing table, and the table
that is referenced is called the referenced table.
• A foreign key in one table points to the primary key in another table,
establishing a relationship between them.
• It helps connect two or more tables, enabling you to create relationships
between them. This is essential for maintaining data integrity and preventing data
redundancy.
• They act as a cross-reference between the tables.
• For example, DNO is a primary key in the DEPT table and a non-key in EMP

It may be worth noting that, unlike the Primary Key of any given relation, Foreign Key can
be NULL as well as may contain duplicate tuples i.e. it need not follow uniqueness
constraint. For Example, STUD_NO in the STUDENT_COURSE relation is not unique. It
has been repeated for the first and third tuples. However, the STUD_NO in STUDENT
relation is a primary key and it needs to be always unique, and it cannot be null.
Composite Key
Sometimes, a table might not have a single column/attribute that uniquely identifies
all the records of a table. To uniquely identify rows of a table, a combination of two or more
columns/attributes can be used. It still can give duplicate values in rare cases. So, we need
to find the optimal set of attributes that can uniquely identify rows in a table.
• It acts as a primary key if there is no primary key in a table
• Two or more attributes are used together to make a composite key.
• Different combinations of attributes may give different accuracy in terms of
identifying the rows uniquely.
Relational Model Notation
• Relation schema R of degree n is denoted by by R(A1, A2, …,An).
• Uppercase letters Q, R, S denote relation names.
• Lowercase letters q, r, s denote relation states.
• Letters t, u, v denotes tuples.
• In general, the name of a relation schema such as STUDENT also indicates the
current set of tuples in that relation.
• An attribute A can be qualified with the relation name R to which it belongs by
using the dot notation R.A for example, STUDENT.Name or STUDENT.Age.
• An n-tuple t in a relation r(R) is represented as t=<v1, v2,…,vn> where vi is the
value corresponding to the attribute Ai. The value vi for attribute Ai in tuple t can
be accessed using t[Ai] or t.Ai.

Characteristics of the Relational Model

• Data Representation: Data is organized in tables (relations), with rows (tuples)
representing records and columns (attributes) representing data fields.
• Atomic Values: Each attribute in a table contains atomic values, meaning no
multi-valued or nested data is allowed in a single cell.
• Unique Keys: Every table has a primary key to uniquely identify each record,
ensuring no duplicate rows.
• Attribute Domain: Each attribute has a defined domain, specifying the valid
data types and constraints for the values it can hold.
• Tuples as Rows: Rows in a table, called tuples, represent individual records or
instances of real-world entities or relationships.
• Relation Schema: A table’s structure is defined by its schema, which specifies
the table name, attributes, and their domains.
• Data Independence: The model ensures logical and physical data
independence, allowing changes in the database schema without affecting the
application layer.
• Integrity Constraints: The model enforces rules like:
o Domain constraints: Attribute values must match the specified
domain.
o Entity integrity: No primary key can have NULL values.
 o Referential integrity: Foreign keys must match primary keys in the
referenced table or be NULL.
• Relational Operations: Supports operations like selection, projection, join,
union, and intersection, enabling powerful data retrieval manipulation.
• Data Consistency: Ensures data consistency through constraints, reducing
redundancy and anomalies.
• Set-Based Representation: Tables in the relational model are treated as sets,
and operations follow mathematical set theory principles.

6. Constraints in Relational Model

While designing the Relational Model, we define some conditions which must hold
for data present in the database are called Constraints. These constraints are checked before
performing any operation (insertion, deletion, and updation ) in the database. If there is a
violation of any of the constraints, the operation will fail.
Domain Constraints
Domain Constraints ensure that the value of each attribute A in a tuple must be
an atomic value derived from its specified domain, dom(A). Domains are defined by the data
types associated with the attributes. Common data types include:
• Numeric types: Includes integers (short, regular, and long) for whole numbers
and real numbers (float, double-precision) for decimal values, allowing precise
calculations.
• Character types: Consists of fixed-length (CHAR) and variable-
length (VARCHAR, TEXT) strings for storing text data of various sizes.
• Boolean values: Stores true or false values, often used for flags or conditional
checks in databases.
• Specialized types: Includes types
for date (DATE), time (TIME), timestamp (TIMESTAMP),
and money (MONEY), used for precise handling of time-related and financial
data.
Key Integrity
Every relation in the database should have at least one set of attributes that defines a
tuple uniquely. Those set of attributes is called keys. e.g.; ROLL_NO in STUDENT is key.
No two students can have the same roll number. So a key has two properties:
• It should be unique for all tuples.
 • It can’t have NULL values.
Referential Integrity Constraints
When one attribute of a relation can only take values from another attribute of the
same relation or any other relation, it is called referential integrity. Let us suppose we have
2 relations
Table STUDENT

BRANCH_CODE of STUDENT can only take the values which are present in
BRANCH_CODE of BRANCH which is called referential integrity constraint. The relation
which is referencing another relation is called REFERENCING RELATION (STUDENT in
this case) and the relation to which other relations refer is called REFERENCED RELATION
(BRANCH in this case).
7. Anomalies in the Relational Model
An anomaly is an irregularity or something which deviates from the expected or
normal state. When designing databases, we identify three types of
anomalies: Insert, Update, and Delete.

Insertion Anomaly in Referencing Relation

We can’t insert a row in REFERENCING RELATION if referencing attribute’s value
is not present in the referenced attribute value. e.g.; Insertion of a student with
BRANCH_CODE ‘ME’ in STUDENT relation will result in an error because ‘ME’ is not
present in BRANCH_CODE of BRANCH.

Deletion/ Updation Anomaly in Referenced Relation:

We can’t delete or update a row from REFERENCED RELATION if the value of
REFERENCED ATTRIBUTE is used in the value of REFERENCING ATTRIBUTE. e.g. if
we try to delete a tuple from BRANCH having BRANCH_CODE ‘CS’, it will result in an
error because ‘CS’ is referenced by BRANCH_CODE of STUDENT, but if we try to delete
the row from BRANCH with BRANCH_CODE CV, it will be deleted as the value is not
been used by referencing relation. It can be handled by the following method:

On Delete Cascade
It would delete the tuples from REFERENCING RELATION if the value used by
REFERENCING ATTRIBUTE is deleted from REFERENCED RELATION. e.g.; if we
delete a row from BRANCH with BRANCH_CODE ‘CS’, the rows in STUDENT relation
with BRANCH_CODE CS (ROLL_NO 1 and 2 in this case) will be deleted.

On Update Cascade

Super Keys
Any set of attributes that allows us to identify unique rows (tuples) in a given
relationship is known as super keys. Out of these super keys, we can always choose a proper
subset among these that can be used as a primary key. Such keys are known as Candidate
keys. If there is a combination of two or more attributes that are being used as the primary
key then we call it a Composite key.

Codd Rules in Relational Model

Edgar F Codd proposed the relational database model where he stated rules. Now
these are known as Codd’s Rules. For any database to be the perfect one, it has to follow the
rules.

Advantages of the Relational Model

• Simple model: Relational Model is simple and easy to use in comparison to
other languages.
• Flexible: Relational Model is more flexible than any other relational model
present.
• Secure: Relational Model is more secure than any other relational model.
• Data Accuracy: Data is more accurate in the relational data model.
• Data Integrity: The integrity of the data is maintained in the relational model.
• Operations can be Applied Easily: It is better to perform operations in the
relational model.

Disadvantages of the Relational Model

• Relational Database Model is not very good for large databases.
• Sometimes, it becomes difficult to find the relation between tables.
• Because of the complex structure, the response time for queries is high.
8. Mapping from ER Model to Relational Model

Converting an Entity-Relationship (ER) diagram to a Relational Model is a crucial

step in database design. The ER model represents the conceptual structure of a
database, while the Relational Model is a physical representation that can be directly
implemented using a Relational Database Management System (RDBMS) like Oracle or
MySQL. Here, we will explore how to convert an ER diagram to a Relational Model for
different scenarios, including binary relationships with various cardinalities and
participation constraints.

Case 1: Binary Relationship with 1:1 cardinality with total participation of an entity

A person has 0 or 1 passport number and Passport is always owned by 1 person. So, it is
1:1 cardinality with full participation constraint from Passport.

First Convert each entity and relationship to tables. Person table corresponds to
Person Entity with key as Per-Id. Similarly, Passport table corresponds to Passport Entity
with key as Pass-No. Has Table represents relationship between Person and Passport
(Which person has which passport). So, it will take attribute Per-Id from Person and Pass-
No from Passport.
From Table 1, each Per-Id and Pass-No has only one entry in Has Table. So, we can merge
all three tables into 1 with attributes shown in Table 2. Each Per-Id will be unique and not
null. So, it will be the key. Pass-No can’t be key because for some person, it can be NULL.

Case 2: Binary Relationship with 1:1 cardinality and partial participation of both
entities
A male marries 0 or 1 female and vice versa as well. So, it is 1:1 cardinality with partial
participation constraint from both. First Convert each entity and relationship to
tables. Male table corresponds to Male Entity with key as M-Id. Similarly Female table
corresponds to Female Entity with key as F-Id. Marry Table represents relationship
between Male and Female (Which Male marries which female). So, it will take attribute
M-Id from Male and F-Id from Female.

As we can see from Table 3, some males and some females do not marry. If we merge 3
tables into 1, for some M-Id, F-Id will be NULL. So, there is no attribute which is always
not NULL. So, we can’t merge all three tables into 1. We can convert into 2 tables. In table
4, M-Id who are married will have F-Id associated. For others, it will be NULL. Table 5 will
have information of all females. Primary Keys have been underlined.
Case 3: Binary Relationship with n: 1 cardinality

In this scenario, every student can enroll only in one elective course but for an elective
course there can be more than one student. First Convert each entity and relationship to
tables. Student table corresponds to Student Entity with key as S-Id. Similarly
Elective_Course table corresponds to Elective_Course Entity with key as E-Id. Enrolls
Table represents relationship between Student and Elective_Course (Which student
enrolls in which course). So it will take attribute S-Id from Student and E-Id from
Elective_Course.
As we can see from Table 6, S-Id is not repeating in Enrolls Table. So, it can be considered
as a key of Enrolls table. Both Student and Enrolls Table’s key is same. We can merge it as
a single table. The resultant tables are shown in Table 7 and Table 8. Primary Keys have
been underlined.
Case 4: Binary Relationship with m: n cardinality

In this scenario, every student can enroll in more than 1 compulsory course and for a
compulsory course there can be more than 1 student. First Convert each entity and
relationship to tables. Student table corresponds to Student Entity with key as S-Id.
Similarly Compulsory_Courses table corresponds to Compulsory Courses Entity with
key as C-Id. Enrolls Table represents relationship between Student and
Compulsory_Courses (Which student enrolls in which course). So it will take attribute S-
Id from Person and C-Id from Compulsory_Courses.
As we can see from Table 9, S-Id and C-Id both are repeating in Enrolls Table. But its
combination is unique; so it can be considered as a key of Enrolls table. All tables’ keys
are different, these can’t be merged. Primary Keys of all tables have been underlined.

Case 5: Binary Relationship with weak entity

In this scenario, an employee can have many dependents and one dependent can
depend on one employee. A dependent does not have any existence without an employee
(e.g; you as a child can be dependent of your father in his company). So it will be a weak
entity and its participation will always be total. Weak Entity does not have key of its own.
So its key will be combination of key of its identifying entity (E-Id of Employee in this case)
and its partial key (D-Name).

First Convert each entity and relationship to tables. Employee table corresponds to
Employee Entity with key as E-Id. Similarly Dependents table corresponds to Dependent
Entity with key as D-Name and E-Id. Has Table represents relationship between
Employee and Dependents (Which employee has which dependents). So it will take
attribute E-Id from Employee and D-Name from Dependents.
As we can see from Table 10, E-Id, D-Name is key for Has as well as Dependents Table.
So we can merge these two into 1. So the resultant tables are shown in Tables 11 and 12.
Primary Keys of all tables have been underlined.