LECTURE-5: ER-MODEL

Data Model:
The data model describes the structure of a database. It is a collection of conceptual tools for
describing data, data relationships and consistency constraints and various types of data models
such as
1. Object based logical model
2. Record based logical model
3. Physical model

Types of data model:

1. Object based logical model
a. ER-model
b. Functional model
c. Object oriented model
d. Semantic model
2. Record based logical model
a. Hierarchical database model
b. Network model
c. Relational model
3. Physical model

Entity Relationship Model (ER Model)

The entity-relationship data model perceives the real world as consisting of basic objects, called
entities and relationships among these objects. It was developed to facilitate database design by
allowing specification of an enterprise schema which represents the overall logical structure of a
data base.

Main Features of ER-MODEL:

 Entity relationship model is a high level conceptual model
 It allows us to describe the data involved in a real world enterprise in terms of objects and
their relationships.
 It is widely used to develop an initial design of a database
 It provides a set of useful concepts that make it convenient for a developer to move from a
basic set of information to a detailed and description of information that can be easily
implemented in a database system
 It describes data as a collection of entities, relationships and attributes.

Basic Concepts:
The E-R data model employs three basic notions : entity sets, relationship sets and attributes.

Entity Sets:
An entity is a “thing” or “object” in the real world that is distinguishable from all other objects. For
example, each person in an enterprise is an entity. An entity has a set properties and the values for
some set of properties may uniquely identify an entity. BOOK is entity and its properties (called as
attributes) bookcode, booktitle, price etc.

An entity set is a set of entities of the same type that share the same properties, or attributes. The set
of all persons who are customers at a given bank.

Attributes:
An entity is represented by a set of attributes. Attributes are descriptive properties possessed by
each member of an entity set.

Customer is an entity and its attributes are customerid, custmername, custaddress etc.

An attribute as used in the E-R model, can be characterized by the following attribute types.

a) Simple and Composite Attribute:

Simple attributes are the attributes which can’t be divided into sub parts, e.g. customerid, empno
Composite attributes are the attributes which can be divided into subparts, e.g. name consisting of
first name, middle name, last name and address consisting of city, pincode, state.

b) Single-Valued and Multi-Valued Attribute:

The attribute having unique value is single –valued attribute, e.g. empno, customerid, regdno etc.
The attribute having more than one value is multi-valued attribute, eg: phone-no, dependent name,
vehicle.

c) Derived Attribute:
The values for this type of attribute can be derived from the values of existing attributes, e.g. age
which can be derived from currentdate – birthdate and experience_in_year can be calculated as
currentdate-joindate.

d) NULL Valued Attribute:

The attribute value which is not known to user is called NULL valued attribute.

Relationship Sets:
A relationship is an association among several entities. A relationship set is a set of relationships of
the same type. Formally, it is a mathematical relation on n>=2 entity sets. If E 1, E2…En are entity
sets, then a relation ship set R is a subset of
{(e1,e2,…en) | e1Є E1, e2 Є E2.., en Є En}
where (e1,e2,…en) is a relation ship.

customer borrow loan

Consider the two entity sets customer and loan. We define the relationship set borrow to denote the
association between customers and the bank loans that the customers have.

Mapping Cardinalities:
Mapping cardinalities or cardinality ratios, express the number of entities to which another entity
can be associated via a relationship set. Mapping cardinalities are most useful in describing binary
relationship sets, although they can contribute to the description of relationship sets that involve
more than two entity sets. For a binary relationship set R between entity sets A and B, the mapping
cardinalities must be one of the following:

1. One to One:
An entity in A is associated with at most one entity in B, and an entity in B is associated with at
most one entity in A.
Eg: relationship between college and principal
1 1
college has principal

2. One to Many:
An entity in A is associated with any number of entities in B. An entity in B is associated with at the
most one entity in A.
Eg: Relationship between department and faculty
1 M
Department Works Faculty
in

3. Many to One:
An entity in A is associated with at most one entity in B. An entity in B is associated with any
number in A.

M 1
emp Department
Works

4. Many to Many:
Entities in A and B are associated with any number of entities from each other.

M N
customer account
deposits

More about Entities and Relationship:

Recursive Relationships:
When the same entity type participates more than once in a relationship type in different roles, the
relationship types are called recursive relationships.

Participation Constraints:
The participation constraints specify whether the existence of any entity depends on its being
related to another entity via the relationship. There are two types of participation constraints
a) Total : When all the entities from an entity set participate in a relationship type, is called total
participation. For example, the participation of the entity set student on the relationship set must
‘opts’ is said to be total because every student enrolled must opt for a course.

b) Partial: When it is not necessary for all the entities from an entity set to particapte in a
relationship type, it is called partial participation. For example, the participation of the entity set
student in ‘represents’ is partial, since not every student in a class is a class representative.

Weak Entity:
Entity types that do not contain any key attribute, and hence can not be identified independently are
called weak entity types. A weak entity can be identified by uniquely only by considering some of
its attributes in conjunction with the primary key attribute of another entity, which is called the
identifying owner entity.

Generally a partial key is attached to a weak entity type that is used for unique identification of
weak entities related to a particular owner type. The following restrictions must hold:
 The owner entity set and the weak entity set must participate in one to may relationship set.
This relationship set is called the identifying relationship set of the weak entity set.
 The weak entity set must have total participation in the identifying relationship.

Example:
Consider the entity type Dependent related to Employee entity, which is used to keep track of the
dependents of each employee. The attributes of Dependents are: name, birthdate, sex and
relationship. Each employee entity set is said to its own the dependent entities that are related to it.
However, not that the ‘Dependent’ entity does not exist of its own, it is dependent on the Employee
entity.

Keys:

Super Key:
A super key is a set of one or more attributes that taken collectively, allow us to identify uniquely an
entity in the entity set. For example , customer-id, (cname, customer-id), (cname, telno)

Candidate Key:
In a relation R, a candidate key for R is a subset of the set of attributes of R, which have the
following properties:
1. Uniqueness: No two distinct tuples in R have the same values for the candidate key
2. Irreducible: No proper subset of the candidate key has the uniqueness property that is
the candidate key. Eg: (cname,telno)

Primary Key:
The primary key is the candidate key that is chosen by the database designer as the principal means
of identifying entities within an entity set. The remaining candidate keys if any, are called Alternate
Key.
 LECTURE-6: ER-DIAGRAM:

The overall logical structure of a database using ER-model graphically with the help of an ER-
diagram.

Symbols use ER- diagram:

composite attribute
entity

Weak entity

attribute Relationship

Multi valued attribute

Identifying
Derived attribute Relationship
Key attribute

1 m
1 1

One-to -one One-to -many

m 1
m n

many-to -one many-to -many

Total participation Partial participation

A Univeristy registrar's office maintains data about the following entities:
(a) Course, includeing number,title,credits,syllabus and prereqisites
(b) course offering,including course number,year,semester,section number,instructor timings,
and class room
(c) Students including student-id,name and program
(d) Instructors, including identification number,name,department and title
further, the enrollment of students in courses and grades awarded to students in each course they are
enrolled for must be appropriate modeled.
Construct an E-R diagram for the registrar's office. Document all assumptions that you may make
about the mapping constratints
Cosidet a university database for the scheduling of class rooms for final exams. This database could
be modeled as the single entity set exam, with attributes course-name,section-number,room-number
and time, Alternatively, one or more additional entity sets would be defined, along with relationship
sets to replae some of the attributes of the exam entity set, as
 course with attributes name,department and c-number
 section with attributes s-number and enrollment and dependent as a weak entity set on
course
 room with attributes r-number,capacity and building
 LECTURE-7: Advanced ER-Diagram:

Abstraction is the simplification mechanism used to hide superfluous details of a set of objects. It
allows one to concentrate on the properties that are of interest to the application. There are two main
abstraction mechanism used to model information:

Generalization and specialization:

Generalization is the abstracting process of viewing set of objects as a single general class by
concentrating on the general characteristics of the constituent sets while suppressing or ignoring
their differences. It is the union of a number of lower-level entity types for the purpose of
producing a higher-level entity type. For instance, student is a generalization of graduate or
undergraduate, full-time or part-time students. Similarly, employee is generalization of the classes
of objects cook, waiter, and cashier. Generalization is an IS_A relationship; therefore, manager
IS_AN employee, cook IS_AN employee, waiter IS_AN employee, and so forth.

Specialization is the abstracting process of introducing new characteristics to an existing class of

objects to create one or more new classes of objects. This involves taking a higher-level, and using
additional characteristics, generating lower-level entities. The lower-level entities also inherits the,
characteristics of the higher-level entity. In applying the characteristics size to car we can create a
full-size, mid-size, compact or subcompact car. Specialization may be seen as the reverse process of
generalization addition specific properties are introduced at a lower level in a hierarchy of objects.

empno name
dob

employee
Generalization Specialization

Is Is
degree _a _a degree

Full time Part-time

employee employee

Is Is Is Is
_a _a _a _a

faculty staff teaching casual

degree Intrest Intrest Classificatio hourra

n te

EMPLOYEE(empno,name,dob) Faculty(empno,degree,intrest)
FULL_TIME_EMPLOYEE(empno,salary) Staff(empno,hour-rate)
PART_TIME_EMPLOYEE(empno,type) Teaching (empno,stipend)
Aggregation:
Aggregation is the process of compiling information on an object, there by abstracting a higher
level object. The entity person is derived by aggregating the characteristics of name, address, ssn.
Another form of the aggregation is abstracting a relationship objects and viewing the relationship as
an object.

Job

Branch
Employe
Works
e on

Manag
es

Manager
ER- Diagram For College Database
 LECTURE-8: Conversion of ER-Diagram to Relational Database

Conversion of Entity Sets:

1. For each strong entity type E in the ER diagram, we create a relation R containing all the
single attributes of E. The primary key of the relation R will be one of the key attribute of R.

STUDENT(rollno (primary key),name, address)

FACULTY(id(primary key),name ,address, salary)
COURSE(course-id,(primary key),course_name,duration)
DEPARTMENT(dno(primary key),dname)

2. For each weak entity type W in the ER diagram, we create another relation R that contains
all simple attributes of W. If E is an owner entity of W then key attribute of E is also include
In R. This key attribute of R is set as a foreign key attribute of R. Now the combination of
primary key attribute of owner entity type and partial key of the weak entity type will form
the key of the weak entity type

GUARDIAN((rollno,name) (primary key),address,relationship)

Conversion of Relationship Sets:

Binary Relationships:
 One-to-One Relationship:
For each 1:1 relationship type R in the ER-diagram involving two entities E1 and E2 we
choose one of entities(say E1) preferably with total participation and add primary key
attribute of another E as a foreign key attribute in the table of entity(E1). We will also include
all the simple attributes of relationship type R in E1 if any, For example, the department
relationship has been extended tp include head-id and attribute of the relationship.
DEPARTMENT(D_NO,D_NAME,HEAD_ID,DATE_FROM)

 One-to-Many Relationship:
For each 1:N relationship type R involving two entities E1 and E2, we identify the entity type
(say E1) at the N-side of the relationship type R and include primary key of the entity on the
other side of the relation (say E2) as a foreign key attribute in the table of E1. We include all
simple attribute (or simple components of a composite attribute of R (if any) in the table E1)

For example:
The works in relationship between the DEPARTMENT and FACULTY. For this relationship
choose the entity at N side, i.e, FACULTY and add primary key attribute of another entity
DEPARTMENT i.e., DNO as a foreign key attribute in FACULTY.

FACULTY(CONTAINS WORKS_IN RELATIOSHIP)

(ID, NAME, ADDRESS, BASIC_SAL, DNO)

 Many-to-Many Relationship:
For each M:N relationship type R, we create a new table (say S) to represent R, we also
include the primary key attributes of both the participating entity types as a foreign key
attribute in S. Any simple attributes of the M:N relationship type (or simple components as a
composite attribute) is also included as attributes of S.
 For example:
The M:N relationship taught-by between entities COURSE and FACULTY should be
represented as a new table. The structure of the table will include primary key of COURSE
and primary key of FACULTY entities.

TAUGHT-BY (ID (primary key of FACULTY table), course-id (primary key of COURSE
table)

 N-ary Relationship:
For each N-ary relationship type R where n>2, we create a new table S to represent R, We
include as foreign key attributes in S the primary keys of the relations that represent the
participating entity types. We also include any simple attributes of the N-ary relationship type
(or simple components of complete attribute) as attributes of S. The primary key of S is
usually a combination of all the foreign keys that reference the relations representing the
participating entity types.

Customer Loan

Loan -
sanctio
n

Employee

LOAN-SANCTION (cusomer-id, loanno, empno, sancdate, loan_amount)

 Multi-Valued Attributes:
For each multivalued attribute ‘A’, we create a new relation R that includes an attribute
corresponding to plus the primary key attributes k of the relation that represents the entity
type or relationship that has as an attribute. The primary key of R is then combination of A
and k.
For example, if a STUDENT entity has rollno, name and phone number where phone number
is a multivalued attribute then we will create table PHONE (rollno, phoneno) where primary
key is the combination. In the STUDENT table we need not have phone number, instead if
can be simply (rollno, name) only.
PHONE(rollno, phoneno)
 name
Account_n
o
Account branch

generalisation
specialisation
Is-a

intrest charges

Saving Current

 Converting Generalisation /Specification Hierarchy to Tables:

A simple rule for conversion may be to decompose all the specialized entities into table in
case they are disjoint, for example, for the figure we can create the three tables as:
Account (account_no, name, branch, balance)
Saving_Account (account-no, intrest)
Current_Account (account-no, charges)