Entity Relationship Model Note
Entity Relationship Model Note
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
1. Entity: Entity refers to an object or thing in real world. Object may be any person, place,
event etc. Ex. Students of colleges and schools, loans in banks, employees in any
company etc. In ER modelling, entity is represented by a rectangular box as shown
below.
2. Attributes: These are the characteristics of any entity. Ex., (i) A student can be described
by his name, age, address, height, class etc. (ii) Loans can be described by their types
such as house loan, car loan etc. (iii) Employees in any company can be described by
their Employee ID, name, department, designation etc. (iv) A car can be described by
its color, model, company etc. In ER modelling, attribute is represented by an eclipse
as shown below
3. Value: Value is the information or data which is stored in attributes of any entity.
4. Entity type. It is a collection of entities that have the same attributes
5. Entity Sets: An entity set is a collection of entities of a particular entity type at a point
in time.
6. Domain: Domain or value set is the set of all values or information about any attribute.
Weak and Strong entities
An entity which depends on other entity for its existence and doesn't have any key attribute of
its own is a weak entity. The entities of weak entity types identify themselves by relating to
another entity type called the identifying or the owner entity type. The relationship between the
weak entity type to its owner is called identifying relationship.
In ER modelling, notation for weak entity is given below.
In contrast to weak entity types, the entity types that have their own key attributes are called
strong entity types. In ER modelling, notation for strong entity is given below.
Types of attributes
An attribute as used in the E-R model, can be characterized by the following attribute types.
a) Simple and Composite Attributes: Simple attributes are the attributes which cannot be
divided into sub parts, e.g. customerid, weight. 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. In ER, the notation for
composite attribute is
b) Single-Valued and Multi-Valued Attribute: The attribute having unique value is single
–valued attribute, e.g. empno, customerid, matricno, age etc. The attribute having more
than one value is multi-valued attribute, Ex: phone-no, university degree.
c) Derived Attribute: The values for this type of attribute can be derived from the values
of existing attributes, Ex, age which can be derived from currentdate – birthdate and
experience_in_year can be calculated as currentdate-joindate. In ER, the notation for
derived attribute is
f) Key attribute The attribute (or combination of attributes) which is unique for every
entity instance is called key attribute. E.g the employee_id of an employee, matric
number of a student etc. If the key attribute consists of two or more attributes in
combination, it is called a composite key. In ER modeling, notation for key attribute is
given below
Identifying relationship
This is the relationship between weak entity type to its owner.
Name Number
Department Locations
2. PROJECT
Name, Number, Location, ControllingDepartment
Name Number
Project Location
3. EMPLOYEE
Name (FName. MName, LName), NIN, gender, Salary, BirthDate, Department, Project
Gender NIN
Name
Employee Birthdate
Salary
4. Dependent
Employee,DependentName, gender, BirthDate, Relationship
Birthdate
Employee
Dependent
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.
Relationship Constraints
There are certain constraints in E-R model. Data in the database must follow the constraints.
Constraints act as rules to which the contents of database must conform. There are two
types of mapping constraints: (a) Mapping cardinalities, (b) Participation constraints.
Mapping cardinalities (cardinality ratios)
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.
Relationships can have four possible connectivity as given below.
1. One to one (1:1) relationship
2. One to many (1: N) relationship
3. Many to one (M:1) relationship
4. Many to many (M: N) relationship
The minimum and maximum values of this connectivity is called the cardinality of the
relationship
1. One to One (1: 1): An entity in X is associated with at most one entity in Y and an entity
in Y is associated with at most one entity in X
1 N
A manager has many employees under it but an employee works under only one
manager.
3. Many to One (N: 1): An entity in X is associated with at most one entity in Y. An entity
in Y is associated with any number of entities in X.
One employee works in only one organization But one organization can have many
employees. Hence it is a N:1
Employee WORKS_FOR Organization
N 1
A student can enrol for more than one course and one course can be enrolled by more
than one student
Participation Constraint
It tells the participation of entity set in relationship sets. There are two types of participations.
1. Partial participation: If only some entities from entity set E participates in relationships
in set R then it is known as Partial participation.
2. Total participation: If every entity instance will be connected through the relationship
to another instance of the other participating entity types, then it is known as Total
participation. Consider the Figure below. Here Customer and Loan are two entity sets
and Relationship set is Borrower. Every customer may or may not take the Loan so
Customer entity set is partially participated. But every loan is taken by at least one
customer of the bank. So, Loan entity set is totally participated.
Customers
Borrows Loans
C1
C2 L1
B
C3
B L2
C4
Partial participation Total participation
E1 R E2
Question
A student accommodation service looks after several residential halls, and wishes to integrate
management of these into a single database. This involves recording the allocation of students
to rooms. You have the following information, arising from an initial requirements analysis.
• Each student has a universal username (UUN) that can be used to identify them in the
database. This is a unique 8-character alphanumeric code issued by the University.
Other than that, the database must record every student’s name and their year of study.
• Students are allocated to rooms. Each room has a fixed capacity — two, three, or even
more.
• No student can be allocated to more than one room; but some students in the system
might not yet have any room assigned.
• There are several halls, each with its own name and unique Building ID.
• Each room belongs to one hall, and is identified within that hall by its unique number.
Draw an entity-relationship (ER) diagram that represents this information. Make sure that you
capture the constraints described on the relationships involved, and designate appropriate
primary keys for all entities.
Solution
Assignment
Consider the ER diagram shown below for part of a BANK database. Each bank can have
multiple branches, and each branch can have multiple accounts and loans.
a. List the non-weak entity types in the ER diagram
b. Is there a weak entity type? If so, give its name, partial key and identifying relationship
c. List concisely the user requirements that led to this ER schema design
Sex
Name
1
N Department Locations
Employee WORKS_
Salary
_FOR
1
NIN
1
1 1
DEPENDENTS_OF
CONTROLS
MANAGES
N
Dependent
Sex
M N
N
Birthdate WORKS_
Relationship Name
_ON Project Number
Location
Name