Assignment 1

Title: Propose a Conceptual Design using ER features, Identifying entities, relationships

between entities, attributes, keys, cardinalities, generalization, specialization etc. Convert the ER
diagram into relational tables.

Theory:

An Entity–relationship model (ER model) describes the structure of a database with the help of
a diagram, which is known as Entity Relationship Diagram (ER Diagram). An ER model is a
design or blueprint of a database that can later be implemented as a database. The main
components of E-R model are: entity set and relationship set.

An ER diagram shows the relationship among entity sets. An entity set is a group of similar
entities and these entities can have attributes. In terms of DBMS, an entity is a table or attribute
of a table in database, so by showing relationship among tables and their attributes, ER diagram
shows the complete logical structure of a database.

Example:

In the above diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students
however a student cannot study in multiple colleges at the same time. Student entity has
attributes such as Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as
Col_ID & Col_Name.
Entity

Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent.

Attributes

Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle).

If the attributes are composite, they are further divided in a tree like structure. Every node is then
connected to its attribute. That is, composite attributes are represented by ellipses that are
connected with an ellipse.

Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

Relationship

Relationships are represented by diamond-shaped box. Name of the relationship is written inside
the diamond-box. All the entities (rectangles) participating in a relationship, are connected to it
by a line.

Binary Relationship and Cardinality

A relationship where two entities are participating is called a binary relationship. Cardinality is
the number of instance of an entity from a relation that can be associated with the relation.
 One-to-one − When only one instance of an entity is associated with the relationship, it
is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.

 One-to-many − When more than one instance of an entity is associated with a

relationship, it is marked as '1:N'. The following image reflects that only one instance of
entity on the left and more than one instance of an entity on the right can be associated
with the relationship. It depicts one-to-many relationship.

 Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.

 Many-to-many − The following image reflects that more than one instance of an entity
on the left and more than one instance of an entity on the right can be associated with the
relationship. It depicts many-to-many relationship.
Participation Constraints

 Total Participation − Each entity is involved in the relationship. Total participation is

represented by double lines.

 Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.

The ER Model has the power of expressing database entities in a conceptual hierarchical manner.
As the hierarchy goes up, it generalizes the view of entities, and as we go deep in the hierarchy,
it gives us the detail of every entity included.

Going up in this structure is called generalization, where entities are clubbed together to
represent a more generalized view. For example, a particular student named Mira can be
generalized along with all the students. The entity shall be a student, and further, the student is a
person. The reverse is called specialization where a person is a student, and that student is Mira.

Generalization

As mentioned above, the process of generalizing entities, where the generalized entities contain
the properties of all the generalized entities, is called generalization. In generalization, a number
of entities are brought together into one generalized entity based on their similar characteristics.
For example, pigeon, house sparrow, crow and dove can all be generalized as Birds.
Specialization

Specialization is the opposite of generalization. In specialization, a group of entities is divided

into sub-groups based on their characteristics. Take a group „Person‟ for example. A person has
name, date of birth, gender, etc. These properties are common in all persons, human beings. But
in a company, persons can be identified as employee, employer, customer, or vendor, based on
what role they play in the company.

Similarly, in a school database, persons can be specialized as teacher, student, or a staff, based
on what role they play in school as entities.

Relation Data Model

Relational data model is the primary data model, which is used widely around the world for data
storage and processing. This model is simple and it has all the properties and capabilities
required to process data with storage efficiency.

Concepts
Tables − In relational data model, relations are saved in the format of Tables. This format stores
the relation among entities. A table has rows and columns, where rows represents records and
columns represent the attributes.

Tuple − A single row of a table, which contains a single record for that relation is called a tuple.

Relation instance − A finite set of tuples in the relational database system represents relation
instance. Relation instances do not have duplicate tuples.

Relation schema − A relation schema describes the relation name (table name), attributes, and
their names.

Relation key − Each row has one or more attributes, known as relation key, which can identify
the row in the relation (table) uniquely.

Attribute domain − Every attribute has some pre-defined value scope, known as attribute
domain.

ER Model to Relational Model

ER Model, when conceptualized into diagrams, gives a good overview of entity-relationship,

which is easier to understand. ER diagrams can be mapped to relational schema, that is, it is
possible to create relational schema using ER diagram. We cannot import all the ER constraints
into relational model, but an approximate schema can be generated.

There are several processes and algorithms available to convert ER Diagrams into Relational
Schema. Some of them are automated and some of them are manual. We may focus here on the
mapping diagram contents to relational basics.

ER diagrams mainly comprise of −

 Entity and its attributes

 Relationship, which is association among entities.

Converting ER Diagrams to Tables-

After designing an ER Diagram,

 ER diagram is converted into the tables in relational model.

 This is because relational models can be easily implemented by RDBMS like MySQL ,
Oracle etc.
Following rules are used for converting an ER diagram into the tables-

Rule-01: For Strong Entity Set With Only Simple Attributes-

A strong entity set with only simple attributes will require only one table in relational model.

 Attributes of the table will be the attributes of the entity set.

 The primary key of the table will be the key attribute of the entity set.

Example-

Roll_no Name Sex

Schema : Student ( Roll_no , Name , Sex )

Rule-02: For Strong Entity Set With Composite Attributes-

 A strong entity set with any number of composite attributes will require only one table in
relational model.

 While conversion, simple attributes of the composite attributes are taken into account and
not the composite attribute itself.

Example-

Roll_no First_name Last_name House_no Street City

Schema : Student ( Roll_no , First_name , Last_name , House_no , Street , City )

Rule-03: For Strong Entity Set With Multi Valued Attributes-

A strong entity set with any number of multi valued attributes will require two tables in relational
model.

 One table will contain all the simple attributes with the primary key.

 Other table will contain the primary key and all the multi valued attributes.

Example-

Roll_no City

Roll_no Mobile_no
Rule-04: Translating Relationship Set into a Table-

A relationship set will require one table in the relational model.

Attributes of the table are-

 Primary key attributes of the participating entity sets

 Its own descriptive attributes if any.

Set of non-descriptive attributes will be the primary key.

Example-

Emp_no Dept_id since

Schema : Works in ( Emp_no , Dept_id , since )

NOTE-

If we consider the overall ER diagram, three tables will be required in relational model-

 One table for the entity set “Employee”

 One table for the entity set “Department”

 One table for the relationship set “Works in”

Rule-05: For Binary Relationships With Cardinality Ratios-

The following four cases are possible-

Case-01: Binary relationship with cardinality ratio m:n

Case-02: Binary relationship with cardinality ratio 1:n

Case-03: Binary relationship with cardinality ratio m:1

Case-04: Binary relationship with cardinality ratio 1:1

Case-01: For Binary Relationship With Cardinality Ratio m:n

Here, three tables will be required-

 1. A ( a1 , a2 )

2. R ( a1 , b1 )

3. B ( b1 , b2 )

Case-02: For Binary Relationship With Cardinality Ratio 1:n

Here, two tables will be required-

1. A ( a1 , a2 )

2. BR ( a1 , b1 , b2 )

NOTE- Here, combined table will be drawn for the entity set B and relationship set R.

Case-03: For Binary Relationship With Cardinality Ratio m:1

Here, two tables will be required-

1. AR ( a1 , a2 , b1 )

2. B ( b1 , b2 )

NOTE- Here, combined table will be drawn for the entity set A and relationship set R.

Case-04: For Binary Relationship With Cardinality Ratio 1:1

Here, two tables will be required. Either combine „R‟ with „A‟ or „B‟

Way-01:

1. AR ( a1 , a2 , b1 )

2. B ( b1 , b2 )

Way-02:

1. A ( a1 , a2 )

2. BR ( a1 , b1 , b2 )
Rule-06: For Binary Relationship With Both Cardinality Constraints and Participation
Constraints-

 Cardinality constraints will be implemented as discussed in Rule-05.

 Because of the total participation constraint, foreign key acquires NOT NULL constraint
i.e. now foreign key can not be null.

Case-01: For Binary Relationship With Cardinality Constraint and Total Participation
Constraint From One Side-

Because cardinality ratio = 1 : n , so we will combine the entity set B and relationship set R.

Then, two tables will be required-

1. A ( a1 , a2 )

2. BR ( a1 , b1 , b2 )

Because of total participation, foreign key a1 has acquired NOT NULL constraint, so it can‟t be
null now.

Case-02: For Binary Relationship With Cardinality Constraint and Total Participation
Constraint From Both Sides-

If there is a key constraint from both the sides of an entity set with total participation, then that
binary relationship is represented using only single table.
Here, Only one table is required.

 ARB ( a1 , a2 , b1 , b2 )

Rule-07: For Binary Relationship With Weak Entity Set-

Weak entity set always appears in association with identifying relationship with total
participation constraint.

Here, two tables will be required-

1. A ( a1 , a2 )

2. BR ( a1 , b1 , b2 )

Conclusion: Thus we have drawn the ER diagram and converted it to the relational database
model.