Translating ER Model to

Relational Schema
Lec 4
 Mapping ER Diagrams to Relational
Tables
The process of converting an Entity-Relationship (ER) diagram
into a relational schema involves translating entities,
relationships, and attributes into relational tables. A relational
schema consists of a set of relations (tables) and their
associated constraints.
 Steps to Create an E-R Diagram
• Study your problem to identify entities
• Construct the context ERD to include entities
and relationship, but no attributes
• Choose a unique identifying attribute for the
entity
• See if a combination of 2 or more attributes
will uniquely identify the entity, this is called
concatenated key
Steps to Create an E-R Diagram(cont.)
• For M:N cardinality relationships, create a new
table. This is called an associative entity
because it is created from the association
between two entites.
• List the remaining non-key attributes
• For 1:1 cardinality relationships, merge all
attributes into one table
• For 1:N cardinality relationships, take the key
for the one side and post it as an attribute in
the many side. This new attribute becomes a
foreign key
Steps to Create an E-R Diagram(cont.)
• List any additional attributes that describe
new associative entites or are required to
make the key in the new table unique in the
associative entity table.
 Steps for Translating ER Model to
Relational Schema:
• Entities to Tables:
– Each entity in the ER diagram is mapped to a table
in the relational schema.
– The attributes of the entity become the columns
of the table.
– The primary key of the entity becomes the
primary key of the corresponding table.
 Steps for Translating ER Model to
Relational Schema(cont):
• Relationships to Tables:
– Each relationship in the ER diagram is mapped to
a relation (table) or incorporated into an existing
table depending on the relationship’s cardinality.
– If the relationship is many-to-many, a new table is
created to represent the relationship.
– If the relationship is one-to-many, the foreign key
is added to the table on the "many" side of the
relationship.
 Handling Relationships: One-to-
Many, Many-to-Many
One-to-Many Relationship:
• In a one-to-many relationship, where one entity is
associated with multiple entities from another set, the
foreign key is placed in the table corresponding to the
"many" side of the relationship.
Many-to-Many Relationship:
• In a many-to-many relationship, where multiple
entities in one set can be related to multiple entities in
another set, a new relation (table) is created to
represent the relationship. This new table will include
foreign keys that reference the primary keys of the two
entities involved in the relationship.
 Handling Weak Entities and Multi-
valued Attributes
Weak Entities:
• A weak entity is an entity that cannot be uniquely
identified by its own attributes alone. It relies on a strong
entity and a relationship for identification. A weak entity
requires a foreign key from the strong entity and its own
partial key to uniquely identify an instance.
Multi-valued Attributes:
• A multi-valued attribute is an attribute that can have
multiple values. In relational databases, we cannot store
multiple values for a single attribute in a single column.
Instead, we create a separate table to represent the multi-
valued attribute.
Example 1
For each of the following pairs of rules, identify two entity types and one
relationship. State the cardinality and existence of the relationship in each case.
Draw the ER diagram.
1. A customer may submit many orders. An order is for exactly one customer.
2. A department employs many persons. A person is employed by, at most, one
department.

dept person
3. A manager manages, at most, one department. A department is managed
by, at most, one manager.

manager dept
4. An author may write many books. A book may be written by many authors.
5. A lecturer teaches, at most, one course. A course is taught by exactly one
lecturer.
6. A flight-leg connects two airports. An airport is used by many flight-legs.

A flight leg takes off from exactly one airport and lands at exactly one airport
— why not make it so that the ER diagram represents the situation and
emphasizes these facts?
7. A purchase order may be for many products. A product may appear on many
purchase orders.
8. A team consists of many players. A player plays for only one team.
Example 2
Draw an ER diagram for the following. Be sure to indicate the existence and
cardinality for each relationship.
1. A college runs many classes. Each class may be taught by several teachers, and a
teacher may teach several classes. A particular class always uses the same room.
Because classes may meet at different times or on different evenings, it is
possible for different classes to use the same room.

room class prof

2. Each employee in an engineering company has at most one recognized skill,
but a given skill may be possessed by several employees. An employee is able
to operate a given machine-type (e.g., lathe, grinder) if he has one of several
skills, but each skill is associated with the operation of only one machine type.
Possession of a given skill (e.g., mechanic, electrician) allows an employee to
maintain several machine-types, although maintenance of any given machine-
type requires a specific skill (e.g., a lathe must be maintained by a mechanic).
Example 3
Draw an ER diagram for each of the following situations. On the diagram be sure
to identify the cardinality, existence, and optionality (for subtypes) of each
relationship.
1. A company has a number of employees. Each employee may be assigned to
one or more projects, or may not be assigned to a project. A project must
have at least one employee assigned, and may have several employees
assigned.
2. A college course may have one or more scheduled sections, or may not have a

scheduled section.
3. A university has a large number of courses in its catalog. Each course may have
one or more other courses as prerequisites, or may have no prerequisites.
4. A hospital patient has a patient history. Each patient has one or more history
records (we assume that the initial patient visit is always recorded as an
instance of the history). Each patient history record belongs to exactly one
patient.
5. A video store may stock more than one copy of a given movie. It is also true
that the store may not have a single copy of a particular movie.
Example 4
Imagine that you are creating a website for a shop, what kind of information do
you have to deal with?
In a shop you sell your products to customers.
The "Shop" is a location;
"Sale" is an event;
"Products" are things; and "Customers" are people.
These are all entities that need to be included in your database.
But what other things are happening when selling a product?
A customer comes into the shop, approaches the vendor, asks a question and gets
an answer.
"Vendors" also participate, and because vendors are people, we need a vendors
entity.
Identifying Relationships
The next step is to determine the relationships between the entities and to
determine the cardinality of each relationship.
The relationship is the connection between the entities, just like in the real
world: what does one entity do with the other, how do they relate to each
other?
For example, customers buy products, products are sold to customers, a sale
comprises products, a sale happens in a shop.

The cardinality shows how much of one side of the relationship belongs to
how much of the other side of the relationship.
First, you need to state for each relationship, how much of one side belongs to
exactly 1 of the other side.
For example: How many customers belong to 1 sale?;
How many sales belong to 1 customer?;
How many sales take place in 1 shop?
 Customers --> Sales; 1 customer can buy something several times
 Sales --> Customers; 1 sale is always made by 1 customer at the time
 Customers --> Products; 1 customer can buy multiple products
 Products --> Customers; 1 product can be purchased by multiple customers
 Customers --> Shops; 1 customer can purchase in multiple shops
 Shops --> Customers, 1 shop can receive multiple customers
 Shops --> Products; in 1 shop there are multiple products
 Products --> Shops; 1 product (type) can be sold in multiple shops
 Shops --> Sales; in 1 shop multiple sales can me made
 Sales --> Shops; 1 sale can only be made in 1 shop at the time
 Products --> Sales; 1 product (type) can be purchased in multiple sales
 Sales --> Products; 1 sale can exist out of multiple products
There are four entities and each entity has a relationship with every other entity, so
each entity must have three relationships, and also appear on the left end of the
relationship three times.
Above, 12 relationships were mentioned, which is 4*3, so we can conclude that all
relationships were mentioned.
Now we'll put the data together to find the cardinality of the whole relationship.
In order to do this, we'll draft the cardinalities per relationship.
To make this easy to do, we'll adjust the notation a bit, by noting the 'backward'-
relationship the other way around:

 Customers --> Sales; 1 customer can buy something several times

 Sales --> Customers; 1 sale is always made by 1 customer at the time
The second relationship we will turn around so it has the same entity order
as the first. Please notice the arrow that is now faced the other way!

 Customers <-- Sales; 1 sale is always made by 1 customer at the time

Cardinality exists in four types:

one-to-one, one-to-many, many-to-one, and many-to-many.
In a database design this is indicated as: 1:1, 1:N, M:1, and M:N.
To find the right indication just leave the '1'. If there is a 'many' on the left side,
this will be indicated with 'M', if there is a 'many' on the right side it is indicated
with 'N'.

 Customers --> Sales; 1 customer can buy something several times; 1:N.
 Customers <-- Sales; 1 sale is always made by 1 customer at the time; 1:1.
The true cardinality can be calculated through assigning the biggest values for left
and right, for which 'N' or 'M' are greater than '1'.
In this example, in both cases there is a '1' on the left side.
On the right side, there is a 'N' and a '1', the 'N' is the biggest value.
The total cardinality is therefore '1:N'.
A customer can make multiple 'sales', but each 'sale' has just one customer.
If we do this for the other relationships too, we'll get:
 Customers --> Sales; --> 1:N
 Customers --> Products; --> M:N
 Customers --> Shops; --> M:N
 Sales --> Products; --> M:N
 Shops --> Sales; --> 1:N
 Shops --> Products; --> M:N
So, we have two '1-to-many' relationships, and four 'many-to-many' relationships.
Between the entities there may be a mutual dependency.
This means that the one item cannot exist if the other item does not exist.
For example, there cannot be a sale if there are no customers, and there cannot
be a sale if there are no products.
The relationships Sales --> Customers, and Sales --> Products are mandatory, but
the other way around this is not the case. A customer can exist without sale, and
also a product can exist without sale. This is of importance for the next step.
Redundant Relationships
Sometimes in a model we get a 'redundant relationship'.
These are relationships that are already indicated by other relationships,
although not directly.

In the case of our example there is a direct relationships between customers and
products.
But there are also relationships from customers to sales and from sales to
products, so indirectly there already is a relationship between customers and
products through sales.

The relationship 'Customers <----> Products' is made twice, and one of them is
therefore redundant.

In this case, products are only purchased through a sale, so the relationships
'Customers <----> Products' can be deleted. The model will then look like this:
Solving Many-to-Many Relationships
Many-to-many relationships (M:N) are not directly possible in a database.
What a M:N relationship says is that a number of records from one table belongs to
a number of records from another table.
Somewhere you need to save which records these are and the solution is to split
the relationship up in two one-to-many relationships.

This can be done by creating a new entity that is in between the related entities.
In our example, there is a many-to-many relationship between sales and products.
This can be solved by creating a new entity: sales-products. This entity has a many-
to-one relationship with Sales, and a many-to-one relationship with Products.

In logical models this is called an associative entity and in physical database terms
this is called a link table or junction table.
In the example there are two many-to-many relationships that need to
be solved:
'Products <----> Sales', and 'Products <----> Shops'.
For both situations there needs to be created a new entity.
For the Products <----> Sales relationship, every sale includes more products.
The relationship shows the content of the sale.
In other words, it gives details about the sale. So the entity is called 'Sales
details'. You could also name it 'sold products'.
The Products <----> Shops relationship shows which products are available in
which the shops, also known as 'stock'.

Our model would now look like this:

 Identifying Attributes

About the products that you sell, you want to know, for example, what the
price is, what the name of the manufacturer is, and what the type number is.

About the customers you know their customer number, their name, and
address.

About the shops you know the location code, the name, the address.

For the sales you know when they happened, in which shop, what products
were sold, and the sum total of the sale.

For the vendor you know his staff number, name, and address.
Derived Data
Derived data is data that is derived from the other data that you have
already saved.
In this case the 'sum total' is a classical case of derived data.
You know exactly what has been sold and what each product costs,
you can always calculate how much the sum total of the sales is.
So really it is not necessary to save the sum total.
Assigning Keys
Primary Keys
In the example there are a few obvious candidates for the primary key.
Customers all have a customer number,
products all have a unique product number and
the sales have a sales number.
Each of these data is unique and each record will contain a value, so these attributes
can be a primary key.
Often an integer column is used for the primary key so a record can be easily found
through its number.
Link-entities usually refer to the primary key attributes of the entities that they
link.
The primary key of a link-entity is usually a collection of these reference-
attributes.
For example in the Sales-details entity we could use, is the combination of the
Primary keys of the sales and products entities as the PK of Sales_details.
In this way we enforce that the same product (type) can only be used once in the
same sale. Multiple items of the same product type in a sale must be indicated
by the quantity.
In the ERD the primary key attributes are indicated by the text 'PK' behind the
name of the attribute.
In the example only the entity 'shop' does not have an obvious candidate for the
PK, so we will introduce a new attribute for that entity: shopno.

Foreign Keys
The Foreign Key (FK) in an entity is the reference to the primary key of another
entity.
Fan Trap and Chasm Trap in ERD Model
Fan Trap
Definition:
• A Fan Trap occurs when a one-to-many relationship exists between
an entity and two other entities, but these entities are not directly
related to each other. This results in incorrect query results when
trying to retrieve meaningful data.
Example:
• Consider a University Database with the following relationships:
• Department (Dept_ID, Dept_Name) → One-to-Many → Employee
(Emp_ID, Emp_Name, Dept_ID)
• Department (Dept_ID, Dept_Name) → One-to-Many → Project
(Project_ID, Project_Name, Dept_ID)
 Fan Trap
In this scenario:
• A Department has multiple Employees.
• A Department is responsible for multiple Projects.
• However, there is no direct relationship between Employees and
Projects.
Problem:
• If we want to find out which Employee is working on which
Project, we cannot do so directly because there is no direct
connection between Employee and Project. This is the Fan Trap
problem.
Solution:
• To fix the Fan Trap, we need to introduce a direct relationship
between Employees and Projects
 Chasm Trap
A Chasm Trap occurs when there is a missing relationship
between entities, leading to missing data when
performing queries.
Example:
Consider a Hospital Database with the following
relationships:
• Hospital (Hospital_ID, Hospital_Name) → One-to-
Many → Department (Dept_ID, Dept_Name,
Hospital_ID)
• Department (Dept_ID, Dept_Name) → One-to-Many
→ Doctor (Doctor_ID, Doctor_Name, Dept_ID)
Problem:
• Some Hospitals may have Departments without any Doctors.
• If we query all Doctors working in a specific Hospital, those Departments
without any Doctors will not be included in the result, creating missing data.

This is the Chasm Trap because the query fails to return Hospitals with
Departments but no Doctors.

Solution:
• Introduce a direct relationship between Hospital and Doctor, so that even if a
Department has no Doctors, the Hospital-Doctor query still returns all relevant
data.
 Generalization and Specialization in
ERD
Generalization:
Generalization is the process of combining two or
more lower-level entities into a higher-level entity
by identifying common attributes. It follows a
bottom-up approach.
Key Characteristics:
• Combines similar entities into a single general entity.
• Removes redundancy by placing shared attributes in
the higher entity.
• Follows a bottom-up approach, moving from specific
to general.
Example:
Consider a university database where we have "Undergraduate Student" and
"Graduate Student" as separate entities. Both have common attributes like
Student_ID, Name, and Date of Birth. Instead of repeating these attributes, we
create a generalized entity "Student".

Student

Undergraduate Graduate
Here, Student is the generalized entity, and Undergraduate Student and Graduate
Student are subclasses that inherit common attributes.
Real-World Examples of Generalization:
• Vehicle (General) → Car, Truck, Bike (Specific)
• Person (General) → Student, Employee, Customer (Specific)
• Account (General) → Savings Account, Checking Account (Specific)
 Specialization
Specialization is the process of breaking down a higher-level
entity into two or more lower-level specialized entities based
on unique attributes. It follows a top-down approach.
Key Characteristics:
• Creates more specific entities from a generalized entity.
• Adds additional attributes specific to each subclass.
• Follows a top-down approach, moving from general to
specific.
Real-World Examples of Specialization:
• Employee → Manager, Engineer, Salesperson
• Doctor → Surgeon, Dentist, Pediatrician
• Customer → Regular Customer, Premium Customer
 Constraints in Generalization &
Specialization
a) Disjoint vs Overlapping Constraints
• Disjoint Constraint: An entity must belong to only one subclass.
Example: A Student can be either an Undergraduate Student or a
Graduate Student, but not both.
• Overlapping Constraint: An entity can belong to multiple subclasses.
Example: A Faculty Member can also be a Researcher.

b) Completeness Constraints
• Total Specialization: Every entity in the parent class must belong to at
least one subclass.
Example: Every Account must be either a Savings Account or
Current Account.
• Partial Specialization: Some entities may not belong to any subclass.
Example: Not all Employees are Managers or Engineers.
Q1. Develop an EER model for the following situation, using the traditional EER
subtypes inside supertypes notation, as specified by your instructor: A person may be
employed by one or more organizations, and each organization may be the employer
of one or more persons. An organization can be an internal organizational unit or an
external organization. For persons and organizations, we want to know their ID, name,
address, and phone number. For persons, we want to know their birth date, and for
organizations, we want to know their budget number. Employee can be permanent
employee or may be a part time job holder but at the same time a person can be
both. For permenant they have extra bonus and credit while for part time job older we
keep their extra hours. For each employment, we want to know the employment date,
termination date, and bonus. Employment of a person by an organization may result
in the person holding many positions over time. For each position, we want to know
its title, and each time someone holds that position, we need to know the start date
and termination date and salary. An organization is responsible for each position. It is
possible for a person to be employed by one organization and hold a position for
which another organization is responsible.
Q2. Develop an EER model for the following situation using the traditional EER notation.
An international school of technology has hired you to create a database management
system to assist in scheduling classes. After several interviews with the president, you
have come up with the following list of entities, attributes, and initial business rules:
• Room is identified by Building ID and Room No and also has a Capacity. A room can be
either a lab or a classroom. If it is a classroom, it has an additional attribute called Board
Type.
• Media is identified by MType ID and has attributes of Media Type and Type
Description. Note: Here we are tracking type of media (such as a VCR, projector, etc.),
not the individual piece of equipment. Tracking of equipment is outside of the scope of
this project.
• Computer is identified by CType ID and has attributes Computer Type, Type
Description, Disk Capacity, and Processor Speed. Please note: As with Media Type, we
are tracking only the type of computer, not an individual computer. You can think of this
as a class of computers (e.g., PIII 900MHZ).
Instructor has identifier Emp ID and has attributes Name, Rank, and Office
Phone.
Timeslot has identifier TSIS and has attributes Day Of Week, Start Time, and End
Time.
• Course has identifier Course ID and has attributes Course Description and
Credits. Courses can have one, none, or many prerequisites. Courses also have
one or more sections.
• Section has identifier Section ID and attribute Enrollment Limit. After
some further discussions, you have come up with some additional business
rules to help you create the initial design:
• An instructor teaches one, none, or many sections of a course in a given
semester.
• An instructor specifies preferred time slots.
• Scheduling data are kept for each semester, uniquely identified by semester
and year.
• A room can be scheduled for one section or no section during one time slot in
a given semester of a given year