Examples of ER diagram for the given scenario”

1. Draw an ER diagram for the given scenario, Construct

an ER diagram to model a database for the given
information, How to draw Entity Relationship diagram?

Draw an ER diagram for the given scenario;

Suppose that you are designing a schema to record information about
reality shows on TV. Your database needs to record the following
information:
_ For each reality show, its name, genre, basic_info and participants
name. Any reality show has at least two or more participants.
_ For each producer, the company name, company country. A show is
produced by exactly one producer. And one producer produces exactly
one show.
_ For each television, its name, start year, head office. A television may
broadcasts multiple shows. Each show is broadcasted by exactly one
television.
_ For each user, his/her username, password, and age. A user may rate
multiple shows, and a show may be rated by multiple users. Each rating
has a score of 0 to 10.
Draw an entity relationship diagram for this database.

Solution:
Reducing Entity Relationship Diagram into Tables,
Convert ER diagram to tables, relational schemas, ER
model to relational model

2. Convert/reduce the ER Diagram given in figure 1 below;

Figure 1 - ER diagram with One-to-One relationship

Solution:

Given in the figure;

Entity sets and relationship sets

Name Entity set / Relationship set Type

Scientist Entity set Strong entity set
Invention Entity set Strong entity set
Invents Relationship set One-to-One relationship

Entity set Scientist

Attributes Attribute Type Description

SID Simple and Primary key Scientist ID
SName Simple Scientist Name
RArea Simple Research Area
Country Simple Country

Entity set Invention

Attributes Attribute Type Description

IID Simple and Primary key Invention ID
IName Simple Name of the invention
Year Simple Year of invention

Reduction into relational schema

Strong entity sets – Entity set that has a primary key to uniquely represent
each entity is Strong entity set.
Strong entity sets can be converted into relational schema by having the
entity set name as the relation schema name and the attributes of that
entity set as the attributes of relation schema.
Then we have,
Scientist (SID, SName, RArea, Country)
Invention (IID, IName, Year)

Relationship set – The association between two or more entity sets is termed
as relationship set.
A relationship may be either converted into a separate table or not. That
can be decided based on the type of the relationship. Only many-to-
many relationship needs to be created as a separate table.
Here, we are given a one-to-one relationship. That means, one entity
(record/row) of Scientist can be related to at most one entity
(record/row) of Invention entity.

To reduce / convert the relationship Invents into relational schema, we can

include the primary key of either relation schemas into the other. For
example, in our case we can derive the final set of relation schemas as
follows;

Include IID of Invention as the foreign key of Scientist

Scientist (SID, SName, RArea, Country, IID)
Invention (IID, IName, Year)
(OR)
Include SID of Scientist as the foreign key of Invention
Scientist (SID, SName, RArea, Country)
Invention (IID, IName, Year, SID)

Both are valid relational schemas.

Reduction of an ER diagram to tables, ER diagram to
table conversion exercise, mapping er model to relational
model, convert er diagram to relational table, how to map
er model to relational model, entity relationship diagram
to relational tables

ER diagram to Relational schema - Solved Exercise

3. Convert the following ER diagram to set of relational

schemas.

Solution:
Strong entity sets
At first, let us identify and reduce all the strong entity sets (those
that have primary keys) into relational schemas.

In the given diagram, ATM, Bank, Transaction, Customer, Branch,

and Account are strong entity sets. To do this, we can use the name
of the entity sets as schema names and all the attributes as part of
the schema. In this way, we have the following schemas;

ATM (ATM_id, cash_limit, location)

Bank (B_id, B_name, B_add)

Branch (Br_id, Br_name, Br_add)

Transaction (Tr_id, Tr_type)

Customer (Cust_id, Cust_name, Cust_add, Ph_no)

Account (Acc_no, Acc_type, Balance)

Primary keys are underlined

Composite attributes
In entity sets Branch and Customer, the
attributes Br_add and Cust_add respectively are composite
attributes. To reduce the composite attributes we retain the
component attributes in the schema. That is, instead of Br_add, we
shall include the component attributes state, country and pin the
Branch table as follows;

Branch (Br_id, Br_name, State, Country, Pin)

Likewise, Customer becomes;

Customer (Cust_id, Cust_name, State, Country, Pin, Ph_no)

Multi-valued attributes
Ph_no attribute of Customer entity set is a multi-valued attribute.
That is, it can have one or more values in it per record (row). To
reduce the multi_valued attribute, we need to create a separate
table with a new name with the multi_valued attribute as one
attribute along with the primary key of the base entity set as
follows;

Customer_Phone (Cust_id, Ph_no)

The primary key for this relation is both (cust_id, ph_no).

Relationship sets

We have the following type of relationships in the given ER

diagram;

Belongs – a one-to-many relationship from Bank to ATM. One

bank can have many ATMs (and an ATM can belong to at most one
Bank).

Has – a one-to-many relationship from Bank to Branch. One bank

can have many branches (and a branch can belong to only one
bank).

Operates – a many-to-many relationship from ATM to Customer.

A customer can operate many ATMs and an ATM can be operated
by many customers.
 Performs – a many-to-one relationship from Transaction to
Customer. A transaction can be performed by only one customer
(and a customer can perform any number of transactions).

Holds – a many-to-many relationship from Customer to Account.

A customer can have any number of accounts and an account can
be maintained by more than one customer as joint accounts.

- For a many-to-many relationship, we need to create a separate

schema by including the primary keys of participating entity sets as
attributes.

- For all others, the primary key of one side has to be included as the
foreign key of the other side (no need to create a separate table).

Hence, we have the following changes;

 Operates (ATM_id, Cust_id) - many-to-many

 Holds (Cust_id, Acc_no) – many-to-many
 For Belongs, include B_id (primary key of Bank, one side) in
ATM entity set (many side).
o ATM (ATM_id, cash_limit, location, B_id)
 For Has, include B_id (primary key of Bank, one side) in
Branch entity set (many side).
o Branch (Br_id, Br_name, State, Country, Pin, B_id)
 For Performs, include Cust_id (primary key of Customer, one
side) in Transaction entity set (many side).
o Transaction (Tr_id, Tr_type, Cust_id).

At the end, after reduction and modification, we have the following

set of relation schemas for the given ER diagram;
Bank (B_id, B_name, B_add)

Customer (Cust_id, Cust_name, State, Country, Pin)

Customer_Phone (Cust_id, Ph_no)

Account (Acc_no, Acc_type, Balance)

ATM (ATM_id, cash_limit, location, B_id)

Branch (Br_id, Br_name, State, Country, Pin, B_id)

Transaction (Tr_id, Tr_type, Cust_id)

Operates (ATM_id, Cust_id)

Holds (Cust_id, Acc_no)

4. Draw an ER diagram for the given scenario, Construct

an ER diagram to model a database for the given
information, How to draw Entity Relationship diagram?

Draw an ER diagram for the given scenario;

Suppose that you are designing a schema to record information about
reality shows on TV. Your database needs to record the following
information:

_ For each reality show, its name, genre, basic_info and participants
name. Any reality show has at least two or more participants.

_ For each producer, the company name, company country. A show is

produced by exactly one producer. And one producer produces exactly
one show.

_ For each television, its name, start year, head office. A television may
broadcasts multiple shows. Each show is broadcasted by exactly one
television.
_ For each user, his/her username, password, and age. A user may rate
multiple shows, and a show may be rated by multiple users. Each rating
has a score of 0 to 10.

Draw an entity relationship diagram for this database.

Solution:
Reduction of ERD to Relational Schema - Solved
Exercise

5. Reduce the following ER diagram to relational database schema

Solution:
Notations used in the ERD for relationships

Step 1: First let us reduce the strong entity sets into schema. We have
the strong entity sets LOT, RAW_MATERIALS and
PRODUCTION_UNITS. They can be converted into schemas as follows;

Rules to convert: Strong Entity Set

Name of the schema = Name of the strong entity set
Attributes of the schema = attributes of the strong entity set
Underline the primary key attribute in the resultant schema

 Lot (LotNumber, CreateDate, Cos-of-Materials)

 Raw_Materials (material-ID, UnitCost, type)
 Production_Units (serial#, exactWeight, productType,
productDesc, qualityTest)

Step 2: To decide on whether relationships to be converted into separate

tables or not. We have two relationship sets in our problem.
(1) Includes is a one-to-many relationship from entity
set Lot to Production_Units.
Rules to convert: One-to-Many relationship set
Insert the primary key attribute of one side entity set as a foreign key in
the many side entity set.

LotNumber attribute to be inserted into Prodution_Units schema as a

foreign key. So, the schema Production_Units is updated as follows;
 Production_Units (serial#, exactWeight, productType,
productDesc, qualityTest, LotNumber)

(2) Created_From is a many-to-many relationship set

between Lot and Raw_Materials.
Rules to convert: Many-to-Many relationship set
Create a separate table for many-to-many relationship set with primary
keys of participating entity sets as attributes. All the primary key
attributes of participating entity sets will form a composite key in the
resultant relation.
Hence, create a separate schema for Created_From as follows;
 Created_From(LotNumber, material-ID)

Step 3: To reduce Descriptive attributes into schema.

Rules to convert: Descriptive attribute
Descriptive attribute is an attribute attached to the relationship directly.
While reducing the relationship into schema, insert the descriptive
attributes with that schema.
Hence, Created_From is updated as follows;
 Created_From(LotNumber, material-ID, Units)

Resultant schema:
After reduction, the schema looks like the following; [primary keys are
underlined, foreign keys are connected with the concerned primary keys
with headed arrows]

6. Convert the following ERD to relational schema;

Reduction rules:

Strong entity – all attributes of strong entity will be attributes of relation

schema.

M-to-M relationship – separate table need to be created with the

primary keys of all participating strong entity sets.

1-to-M relationship – primary key of one side entity is included as

foreign key in many side entity set.

Specialization – super class is modeled as strong entity set. Sub-classes

are included with the super class’s primary keys along with their own
attributes as in 1-to-M relationship.

ER Component Reduced into Relational Schemas

Strong Entity

Driver Driver(ID, Name, PhoneNo)

Truck Truck(LicNo, maxVol, maxWt)

Trip Trip(tripNo)

Shipment Shipment(ShipNo, Vol, Weight)

M-to-M Relationship

Binary - Journey Journey(ID, LicNo, tripNo)

Ternary -Between Stoppoint stores either FROM address or

TO address. Hence, we have renamed
Address attribute as follows;

SBetween(ShipNo, From_Address,
Pickup_time, To_Address, Dropoff_time)

1-to-M Relationship

Carries No separate schema. But the many side

strong entity set is added with one side’s
primary key.

Shipment(ShipNo, Vol, Weight, tripNo)

Specialization

StopPoint StopPoint(Address)

(super class
entity) Warehouse(Address, port)
Warehouse
 (sub-class entity) shopNpay(Address, openHrs)

shopNpay

(sub-class entity)

Final set of relations are as follows;

Driver(ID, Name, PhoneNo)

Truck(LicNo, maxVol, maxWt)

Trip(tripNo)

Shipment(ShipNo, Vol, Weight, tripNo) – tripNo is foreign key referencing

Trip.

Journey(ID, LicNo, tripNo) – ID, LicNo, and tripNo all are foreign
keys referencing Driver, Truck, and Trip relations respectively.

SBetween(ShipNo, From_Address, Pickup_time, To_Address, Dropoff_time) –

From_Address, To_Address are foreign keys referencing StopPoint’s
Address attribute. Pickup_time and Dropoff_time are descriptive
attributes of the ternary relationship SBetween.

StopPoint(Address)

Warehouse(Address, port) – Address is the foreign key referencing the super

class’s primary key.
shopNpay(Address, openHrs) - Address is the foreign key referencing the
super class’s primary key.