2.1.

ENTITY RELATIONSHIP MODELING

Introduction
The Entity-Relationship model (or ER model) is a way of graphically representing the
logical relationships of objects in order to create a database. Creation of an ER diagram is
the first step in designing a database. It helps the designer(s) to understand and to specify
the desired components of the database and the relationships among those components. An
ER model is a graphical representation which contains entities or "items", relationships among
the entities and attributes of the entities and relationships.

The following are the three basic elements in the ER model.

 Entities : Any objects or items

 Attribute: The Attribute is nothing but a property of an entity
 Relationships : The links between various entities

Let us take University database as an example and try to understand how ER model is arrived at.
Example:
A university consists of a number of departments. Each department offers several courses. Each
course includes a number of modules. Students enroll in a particular course and study modules
towards the completion of that course. Each module is taught by a lecturer from the appropriate
department, and each lecturer teaches a group of students.

Entities
Entities are real world items or concepts that exist on their own and are represented as objects
or things of interest. An entity type is a collection of entities that share a common definition.
Identify all nouns in our university example,

A university consists of a number of departments. Each department offers several courses. Each
course includes a number of modules. Students enroll in a particular course and study modules
towards the completion of that course. Each module is taught by a lecturer from the appropriate
department, and each lecturer teaches a group of students.This scenario consists of students,
lecturers, modules, courses and departments. So here the physical things(Physical things are
those which exist in this world, that we can touch, feel etc.) like students, lecturers and abstract
things(An abstract thing is an idea or a concept in your mind. It is not something that you can
physically reach out and touch, smell, hear, taste, see) like modules,department etc., make an
entity type. If we take students as an entity type, then each student in the university is an entity.
The entities are represented as nouns in the description because they are objects or things.

We can touch an entity of physical things and feel the entity of abstract things but an entity type
is simply an idea. Student is an idea of physical things (entity type) while Scott, Nancy, Lindsey,
and Mackenzie are touchable (Student names are entities). Department is an idea of abstract
things (entity type) while IT,CSE,ECE and CIVIL are entities.

Entity Diagrams

In an E-R Diagram, an entity is usually drawn as a rectangle.

The box is labeled with the name of the entity type. The entities identified in our example
are shown in Figure 2.1.

Figure 2.1 : Entities

Weak Entity

If an entity depends on another existing entity then it is considered as weak. A weak entity
cannot be identified by its own attributes. A weak entity is represented by double
rectangles in E-R diagram.
Example:
SubModule is a good example for weak entity. The SubModule will be meaningless without a
Module entity and so it depends on the existence of Module as shown in Figure 2.2

Figure 2.2 : Weak Entity

Attributes
Attributes represent properties, facts, aspects or details of an entity. There are attributes or
particular properties that describe each entity .In our University database each student in the
university will have a Student ID, Name, Course taken etc. Similarly each lecturer will have
his/her own properties of ID, Name, department etc.Attributes will have a name, an associated
entity and properties of an entity. Attributes are often nouns also.

Attributes in ER diagram

 In an E/R Diagram attributes are represented by an oval.

 A line is used to link an attribute to its entity.

The figure below represents the entities and their corresponding attributes in the University

database.

Figure 2.3 : Entities and Attributes

Multivalued Attribute

A multivalued attribute is an attribute that has more than one value attached to it. For
instance if phone number and graduating degree are the attributes of an Entity called
Person, then those attributes could have multiple values, as a person could have multiple
phone numbers or could hold multiple graduating degrees. We represent a multi valued
attribute by double oval in E-R diagram. Single Valued Attribute: Attribute that holds a
single value; in Our example the attributes of Students such as Roll number, Age, Date of Birth,
City etc., can have only a single value. In our example, a Student can have multiple phone
numbers, and so Phone number is a multi valued attribute.

Figure 2.4 : Multivalued Attributes

Relationships
The association between two or more entities is called a relationship. In our University
database, each student studies several Modules and each Lecturer teaches several Students. Here
the entity types Student - Modules and Lecturer - Students have a relationship. The Verbs most
often describe relationships between entities. Identify the verbs(relationships) in our University
database example:

A university consists of a number of departments. Each department offers several courses. Each
course includes a number of modules. Students enroll in a particular course and study modules
towards the completion of that course. Each module is taught by a lecturer from the appropriate a
department, and each lecturer teaches a group of students.

Each relationship has a name, a set of entities that participate in it, a degree and a cardinality
ratio. The degree is the number of entities that participate in that relationship(most have degree
2, For example in figure 2.3 each Lecturer teaches several Students, so we can say that this
relationship has degree 2. Here the degree is 2 because it has two entities related to it).

Relationships in an ER diagram

Relationships are denoting links between two entities.

 The name of the relationship is given in a diamond box (For example Belongs to as
shown in Figure 5.1).

Cardinality Ratio

Each entity can be involved in three types of relationships as shown:

One to One (1:1)

 Each student belongs to one University. We can illustrate this ratio by writing ones on
the lines indicating the relationship as shown in Figure 2.5.

Figure 2.5 : One-one Mapping

 The notation for the 1:1 relationship is shown in Figure 2.6.

Figure 2.6 : One-one Mapping

One to Many (1:M)

 A lecturer teaches many students, and this One to Many relationship is illustrated in
figure 2.7.

Figure 2.7 : One-Many

 The notation for the 1:M relationship is shown in Figure 2.8.

Figure 2.8 : One-Many

Many to Many (M:M)

 Each student takes many modules, and each module is taken by many students as shown in

Figure 2.9 : Many-Many

Making E/R Models

Till now we have seen how to identify the basic elements in an ER Diagram. Finally, to make an
E/R model you need to identify:

 Entities
 Attributes
 Relationships
 Cardinality ratios

Now lets see how an ER model will look like when all these elements are put together. The final
ER Model of our University database is shown in the Figure 2.10. In this figure we have shown
the entities and the relationship between the entities which depict the complete ER model of a
University. Here Department, Course, Module, Lecturer and Student are the entities.
The relationships in the Figure 2.10 are defined as Department Offers many Courses and those
two entities have One to Many relationship. A Department Assigns Many Lecturers(One(1) To
Many(n)). Each Lecturer teaches Many Students(One(1) To Many(n)). Every Student takes
several Modules(Many(n) To Many(n)). Every Module includes Many Courses(Many(n) To
Many(n)). A Course is enrolled by Many Students(One(1) to Many(n)).

The ER Model for the above example is given below:

The complete ER Model for our University database will be as shown in the diagram below. It is
an Integrated ER model containing the Entities and Relationships for a University database.
 Figure 2.10 : University ER Model

Summary

 ER Diagrams play a major role in database designing.

 The ER Diagrams act as a non-technical communication tool.
 This tool is used by both technical and non-technical users.
 Entities represent real world things; They can be conceptual as a transaction or
physical as a bank.

Figure 2.11 : ER Model Summary

 2.2. NORMALIZATION - FIRST NORMAL FORM, SECOND NORMAL FORM AND
THIRD NORMAL FORM

The database design technique that is used to organize tables in a manner that reduces
redundancy and dependency of data is called Normalization. It is the scientific process of
decomposing complex tables(Relations) into smaller and easily manageable tables. The use of
normalization is to accurately access data from database. Without normalization, database
systems can be inaccurate, redundant, slow and inefficient. They might not produce the data
that is expected. Listed below are the advantages of normalization.

Advantages

 Smaller, simpler and well-structured relations.

 Avoids unnecessary duplication of data. That is, it helps to reduce redundancy.
 Provides data integrity.
 Helps to avoid update anomalies. That is, it isolates data so that additions, deletions,
and modifications of a field can be made in just one table. The changes are then
propagated to the rest of the database through the defined relationships.
 Save storage space.

Edgar Codd invented the relational model and he proposed the theory of normalization with the
introduction of First Normal Form. He continued to extend the theory with Second and Third
Normal Forms. Later Edgar Codd joined with Raymond F. Boyce to develop the theory of
Boyce-Codd Normal Form(BCNF).

Theory of Normalization is still developing. For example, the discussions on 6th Normal Form
are in progress. However, in most practical applications normalization achieves its best in Third
Normal Form. The evolution of Normalization theories is illustrated below:

Figure 2.12 : Normalization Evolution

Let's understand a few things before we proceed –

What is a KEY ?

A KEY is a value used to uniquely identify a row in a table. It could be a single column or a
combination of multiple columns.

Note: The columns in a table that are NOT used to uniquely identify a record or row in a
table are called non-key columns.

What is a primary Key?

A primary key is a single column value that is used to uniquely identify a database record.

Figure 2.13 : Primary Key

 The primary key column in a table must always have a value.

 The primary key column in a table cannot have duplicate values. Each primary key
value must be unique.
 The primary key values cannot be modified.
 The primary key column should have a value when a new record is inserted into the
table.

Example:
The table below contains the details of students. Here studentId is Primary Key which is used to
uniquely identify the details of a student from the table.
 Figure 2.14 : Primary Key Illustration

Composite Key

If two or more columns are used to uniquely identify a record then combination of those
multiple columns constitutes a composite key.In the Student table given below, we have
StudentId, TestId and Mark. Here one student can take multiple tests and one test can be taken
by multiple students. In this case in order to uniquely identify the mark of a student in a test we
require both StudentId and TestId. This is a composite key.

Student Table

Table 2.1

Functional Dependency

In simple terms, functional dependency can be explained as follows. If you know one attribute
then you can get another attribute. Then both these attributes are said to be functionally
dependent. In the Student table given below, we can get the attribute 'Name' if you know the
attribute 'StudentId', then Name and StudentId are functionally dependent. Here we can say
StudentId is determinant and Name as dependent.
For example, let's consider the Student table given below. Table 2.2 stores student
details(StudentId, Name, Languages Known), student's department details (Dept_No,
Dept_Name) and lecturer details (LecturerInCharge, Designation) for Students.

In this approach, we keep repeating the languages known and department details data for all
the students in the same field. This is called an UnNormalized table. Instead of storing the
same data again and again, we could normalize the data and create related tables.

Let's see how we can normalize the table,create related tables and learn forms with the Student
table(which is not normalized):

Student Table (UnNormalized Table):

Table 2.2

First Normal Form

To move from unnormalized form to first normal form all multi-valued attributes (called
repeating groups) should be removed. The repeating groups nust be eliminated. All attributes
must be atomic.

Table 2.2 is not in 1NF since there are repeating groups (more than 1 value in a field). The
column "Languages Known" has(English, Hindi and Tamil) in the Row(Tuple)1 and (English
and Hindi) in the Row(Tuple) 2 .To satisfy 1NF we can create separate rows for each value in
Languages Known by duplicating the values in the remaining columns. Table 2.3 represents the
same.
1NF Rules

 Each column in a table should contain single value.

 Each record needs to be unique as shown in Table 2.3
 Table 2.3 : 1NF Form

Second Normal Form

Partial functional dependencies must be removed. If two attributes of a table are combined to
form a composite key, then the non-key attributes of that table must depend on both the attributes
of the composite key. They must not depend on one of the attributes, which is the part of the
composite key.

2NF Rules

 Rule 1- The table should be in 1NF.

 Rule 2- The Single Column must be used as Primary Key.
 A relation in 1NF will be in second normal form (2NF) if there are no partial
dependencies.

Partial dependency

It is the functional dependency on part of the primary key instead of the entire primary
key.

It is clear that we can't move forward to make our simple database in 2nd Normalization form
unless we partition the columns in Table 2.3. Here, assume that StudentId and Dept_No together
act as the key (Composite key). As per 2NF all non-key attributes must be dependent on whole
key.

In Table 2.3 the attribute 'Dept_Name' is functionally dependent on whole

key(StudentId+Dept_No). That is, you can get the department name only if you know both
StudentId and Dept_No. All other column attributes can be identified by just providing
'StudentId'. So for all other columns StudentId acts as the primary key. So split the table as given
below to satisfy 2NF.
Student

Table 2.4

Department

Table 2.5

Languages

Table 2.6

Introducing Foreign Key

A foreign key is a field in a table that matches the primary key column of another table.
The cross-reference tables can be achieved by Foreign Key.

In Table 2.7,Dept_No is the foreign Key

Table 2.7
 Figure 2.15 : Foreign Key

Foreign key refers primary key of another table. It helps to connect the two tables.

The values of a foreign key and a primary key may be different.

 The foreign key ensures that a row in a table is mapped to a corresponding row in
another table.
 Foreign key does not have to be unique; most often it is not unique.

Foreign Key

Figure 2.16 : Foreign Key Illustration

Why do you need a foreign key? Foreign key is required in RDBMS for the concept of
Referential Integrity.
Referential integrity

It is a concept used in database to ensure that there is consistency in table relationships. If one
table has a foreign key to another table, then the concept of referential integrity states that you
cannot add a record to the table that contains the foreign key unless there is a corresponding
record in the link/relationship with the other table.

For example, consider the Figure 2.16 given in the previous page, where Dept_No in the Student
table is foreign key of Dept_No in Department table. Here let's try to add a student with
StudentId as "103" and Dept_No as "D003" in Student table as shown below. But the entry for
Dept_No "D003" is not present in Department table which means we have added a student to a
department which does not exist. This leads to inconsistency of data across related tables. Hence
RDMS has the concept of referential integrity which does not allow to add a record to the table
that contains the foreign key unless there is a corresponding record in the table to which it is
linked.

Student

Table 2.8

Department

Table 2.9
Transitive functional dependencies

When changing a non-key column might cause any of the other non-key columns to change,
it is called transitive functional dependency. Attributes that are not a part of the key must
not depend on any non-key attribute.

Consider the table 2.9. Changing the non-key column Lecturer In Charge , may change
Designation. Here Dept_No acts as the key. All other columns are non-key attributes. As per
3NF non-key attributes should not be dependent on any other non-key attributes but 'Lecturer In
Charge' is dependent on 'Designation'. Both Lecturer In Charge and Designation are non-key
attributes. So it forms transitive dependency. So, to satisfy 3NF let's split the table in a short
while.

Third Normal Form

Third normal form (3NF) is the third step in database normalization and it builds on the
first (INF)and second normal forms(2NF).The Third Normal Form(3NF) states that all
column references in the referenced data that are not dependent on the primary key should
be removed. Another way of putting this statement is that only foreign key columns should be
used to reference another table, and the other columns from the parent table should not exist in
the reference table. The Second Normal form(2NF) covers in case of multi-column primary
keys. 3NF is meant to cover single column keys as mentioned in transitive functional
dependencies above.

3NF Rules

 Rule 1- The table should be in 2NF.

 Rule 2- The table has no transitive functional dependencies which is explained above.

We need to divide our table if it has to be moved from second normal form(2NF) into Third
Normal form(3NF). In table 2.1 Dept_No acts as the key. All other columns are non-key
attributes. The non-key attributes should not be dependent on any other non-key attributes as per
third normal form. The 'Designation' is dependent on 'Lecturer In Charge' and these are non key
attributes in the Lecturer table explained. It forms transitive dependency. So, to satisfy 3NF split
the table as follows.
Student

Table 2.10

Department

Table 2.11

Lecturer

Table 2.12

Languages

Table 2.13
The example given above cannot be decomposed further to attain higher forms of normalization
because it is already normalized to the highest level.Normally only complex data bases would
need next levels of normalization.

2.3. JOINS

What are Joins?

A join is a technique where records from two or more tables are retrieved through a single
SQL query and shown as a single output. As it forms a set, It can be saved as a table or used as
it is. A join is a means of combining columns from two tables by using values common to
both tables. It allows us to combine data from more than one table into a single result set. A
join condition is used in the WHERE clause of select, update and delete queries.

Note: The query will give results from two tables as Cartesian product(A Cartesian product is
defined as all possible combinations of rows in all tables). If join condition is omitted. The first
table's rows are joined with all rows of the second table. For example, if the first table has 30
rows and the second table has 10 rows, the result will be 30 * 10, or 300 rows. This query will
take a long time to execute.
Let's use the two tables below to explain the join conditions.

Table "Student"

Table 2.14

Table "Department"

Table 2.15

In the above example the column that is common between both the tables is Dept_No. Using
Dept_No,the Student and Department tables can be joined to combine data from both the tables
as shown below.

Figure 2.17 : Joining of tables

Lets consider a scenario to retrieve the details of student who belong to 'CSE' department. We
have to join two tables based on the common column present in the two tables.

Figure 2.18 : Mapping data

Result: After joining two tables:

2.4. SUMMARY

 The Entity-Relationship model (or ER model) is a way of graphically representing the

logical relationships of objects in order to create a database.
 An ER model is a graphical representation which contains entities or "items",
relationships among them and attributes of the entities and the relationships.
 The database design technique which is used to organize tables in a manner that
reduces redundancy and dependency of data is called as Normalization.
 There are three forms of normalization. They are First Normal form(1NF),Second
Normal form(2NF) and Third Normal form(3NF).
 A key is a value used to uniquely identify a row in a table. One or more columns could
be used to form a key for a table.
 A primary key is a single column value used to identify a database record uniquely.
 A composite key is a primary key derived by combining multiple columns and is used
to identify a record uniquely.
 The field in a table which matches the primary key column of another table is called
as foreign key. The cross-reference tables can be achieved by foreign key.
 First Normal Form-The multi-valued attributes (called repeating groups) should be
removed i.e. elimination of repeating groups. All attributes must be atomic.
 Second Normal Form- Partial functional dependencies must be removed. The
attributes that are not a part of the key should be dependent on the entire key for that
entity.
 Third normal Form- States that all column reference in referenced data that are not
dependent on the primary key(transitive dependency) should be removed.
 Join is a means of combining fields from two tables by using values common to both. It
allows to combine data from more than one table into a single result set.

2.5. WEBLIOGRAPHY

 http://jcsites.juniata.edu/faculty/rhodes/dbms/ermodel.htm
 http://www.phlonx.com/resources/nf3/
 http://www.w3schools.com/sql/sql_join.asp