Assignment 1: ER Modelling and Normalization

Problem Statement: Propose a Conceptual Design using ER features using tools like ERD plus
etc. (Identifying entities, relationships between entities, attributes, keys, cardinalities,
generalization, specialization etc.) Convert the ER diagram into relational tables ad normalize
Relational data model.

Objectives:

1. Learn the basics about ER diagram (entities, relationships between entities, attributes,
keys, cardinalities, generalization, and specialization). Decide a case study related to real
time application and design an ER diagram. Convert the ER diagram to relational tables.
2. Normalize Relational Data Model.
3. Mini-Project

Theory:

 Entity Relationship Diagrams (ER diagrams)

An ER diagram identifies 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 of ER diagram

Figure : ER diagram 1
Let’s discuss the above ER diagram in detail

Entity

An entity is an object or component of data. An entity is represented as rectangle in an

ER diagram. Hence in above diagram The Student and College are two entities.

Relationship between Entities

A relationship is defined as an association among several entities. It is represented in a

diamond. In the above diagram “StudyIn” is a relationship between Student and College
which is read as “Student studies in the College.

Attribute

An attribute describes the property of an entity. An attribute is represented as Oval in an

ER diagram. Hence in above diagram, the attributes of student entity are Roll No, Name,
Phone Number, Address. The attributes of College entity are College_ID, Name,
Address.

There are four types of attributes:

1. Key attribute
2. Composite attribute
3. Multi-valued attribute
4. Derived attribute

1. Key Attribute

A key attribute can uniquely identify an entity from an entity set. For example, student
Roll No can uniquely identify a student from a set of students. Key attribute is
represented by oval same as other attributes however the text of key attribute is
underlined.

2. Composite Attribute

An attribute that is a combination of other attributes is known as composite attribute. For

example, In student entity, the student address is a composite attribute as an address is
composed of other attributes such as Street No, City, State, Pin Code.
 3. Multivalued attribute:

An attribute that can hold multiple values is known as multivalued attribute. It is

represented with double ovals in an ER Diagram. For example – A studet can have more
than one phone numbers so the Phone Number attribute is multivalued.

4. Derived attribute:

A derived attribute is one whose value is dynamic and derived from another attribute. It is
represented by dashed oval in an ER Diagram. For example – Student age is a derived
attribute as it changes over time and can be derived from another attribute (Date of birth).

 Cardinalities

A relationship is represented by diamond shape in ER diagram, it shows the relationship

among entities. There are four types of relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

When a single instance of an entity is associated with a single instance of another entity
then it is called one to one relationship. For example, one professor delivers only one
subject.

2. One to Many Relationship

When a single instance of an entity is associated with more than one instances of another
entity then it is called one to many relationship. For example – a student can enroll to
many subjects

.
 3. Many to One Relationship

When more than one instances of an entity is associated with a single instance of another
entity then it is called many to one relationship. For example – many students can study
in a single college.

4. Many to Many Relationship

When more than one instances of an entity is associated with more than one instances of
another entity then it is called many to many relationship. For example, Many students
can participate in many projects.

 Generalization

Generalization, as the name suggests, is a process of generalizing two or more lower-

level entity types into a higher-level entity type. Entities are clubbed or grouped
together to represent a more generalized view. In this process, the common attributes of
two or more entities combine to form a new entity type. The new entity type formed is
called a generalized entity.

Example: Suppose we have two entity types, Student and Faculty. The attributes of
Student entity type are Roll No, Name, Phone and Address. The attributes of Faculty
entity type are College_ID, Name, Phone, Address, Department, Email.
 We can see that the three attributes i.e. Name, Phone, and Address are common here.
When we generalize these two entities, we form a new higher-level entity type Person.

The new entity type formed is a generalized entity.

 Specialization

Specialization is a top-down approach in which a higher-level entity is divided into

multiple specialized lower-level entities. In addition to sharing the attributes of the
higher-level entity, these lower-level entities have specific attributes of their own.
Specialization is usually used to find subsets of an entity that has a few different or
additional attributes.

The following enhanced entity relationship diagram expresses the entities in a

hierarchical database to demonstrate specialization:
 Converting ER diagrams to tables

1. Entity type becomes a table.

In the given ER diagram 1, STUDENT, SUBJECT and COLLEGE forms

individual tables.

2. All single-valued attribute becomes a column for the table.

In the STUDENT entity, NAME, ROLL NO form the column of

STUDENT table. COLLEGE ID, COLLGE NAME form the column of
COLLEGE table

3. A key attribute of the entity type represented by the primary key.

In the given ER diagram, ROLL No, COLLEGE ID are the key attribute
of the entity.

4. The multivalued attribute is represented by a separate table.

In the student table, a PHONE NUMBER is a multivalued attribute. So it

is not possible to represent multiple values in a single column of
STUDENT table. Hence we create a table STUD_PHONE_NO with
column name STUDENT_ID and PHONE_NO. Using both the column,
we create a composite key

.
 5. Composite attribute represented by components.

In the given ER diagram, student address is a composite attribute. It

contains CITY, PIN, STREET, and STATE. In the STUDENT table, these
attributes can merge as an individual column.

Normalization

Normalization is the process of organizing data in a database. This includes creating tables and
establishing relationships between those tables according to rules designed both to protect the
data and to make the database more flexible by eliminating redundancy and inconsistent
dependency.

First normal form

 Eliminate repeating groups in individual tables.
 Create a separate table for each set of related data.
 Identify each set of related data with a primary key.

Second normal form

 Create separate tables for sets of values that apply to multiple records.
 Relate these tables with a foreign key.

Third normal form

 Eliminate fields that do not depend on the key.

Normalizing an example table

These steps demonstrate the process of normalizing a fictitious student table.

 1. Unnormalized table:

TABLE 1

Student Advisor Adv-Room Class1 Class2 Class3

1022 Jones 412 101-07 143-01 159-02

4123 Smith 216 101-07 143-01 179-04

2. First normal form: No repeating groups

Tables should have only two dimensions. Since one student has several classes, these
classes should be listed in a separate table. Fields Class1, Class2, and Class3 in the above
records are indications of design trouble.

Spreadsheets often use the third dimension, but tables should not. Another way to look at
this problem is with a one-to-many relationship, do not put the one side and the many side
in the same table. Instead, create another table in first normal form by eliminating the
repeating group (Class#), as shown below:

TABLE 2

Student Advisor Adv-Room Class

1022 Jones 412 101-07

1022 Jones 412 143-01

1022 Jones 412 159-02

4123 Smith 216 101-07

4123 Smith 216 143-01

4123 Smith 216 179-04

3. Second normal form: Eliminate redundant data

Note the multiple Class# values for each Student# value in the above table. Class# is not
functionally dependent on Student# (primary key), so this relationship is not in second
normal form.
 The following tables demonstrate second normal form:

Students:

TABLE 3

Student Advisor Adv-Room

1022 Jones 412

4123 Smith 216

Registration:

TABLE 4

Student Class

1022 101-07

1022 143-01

1022 159-02

4123 101-07

4123 143-01

4123 179-04

4. Third normal form: Eliminate data not dependent on key

In the last example, Adv-Room (the advisor's office number) is functionally dependent on
the Advisor attribute. The solution is to move that attribute from the Students table to the
Faculty table, as shown below:
 Students:

TABLE 5

Student Advisor

1022 Jones

4123 Smith

Faculty:

TABLE 6

Name Room Dept

Jones 412 42

Smith 216 42

Conclusion : Thus the concepts of ER-diagram and Normalization have been studied.