Database Management Systems UNIT-II
2.1 E-R Model
E-R Model stands for Entity-Relationship Model, also known as E-R Diagram.
It was proposed by Peter Chen in 1971 to create a uniform convention which can be
used for relational database.
E-R model helps us to systematically analyse data requirements to produce a
well-designed database.
The ER model is used to define the conceptual view of database. The work of
the ER Model revolves around real-world entities and the associations between these
objects. At view level, the ER model is considered a good option for designing
databases.
Why we use ER Diagrams?
• Helps to describe entities, attributes, relationships.
• Provide a preview of how all your tables should connect, what fields are going
to be on each table.
• ER diagrams are translatable into relational tables which allows you to build
databases quickly.
• ER diagrams can be used by database designers as a blueprint for implementing
database.
• The database designer gains a better understanding about the database with
the help of ER diagram.
Advantages
• Simple: If we know the relationship between the attributes and the entities we
can easily build the ER Diagram for the model.
• Effective Communication Tool: This model is used widely by the database
designers for communicating their ideas.
• Easy Conversion to any Model: This model can be converted to any other
model like relational, network, hierarchical model etc.
Disadvantages
• No industry standard for notation: means one developer might use notations
which are not understood by other developers.
Ch. Vijayananda Ratnam @Dept. of CSE 1
Database Management Systems UNIT-II
• Hidden information: As it is a high-level view so there are chances that some
details of information might be hidden.
2.2 Components of the ER Diagram
This model is based on three basic concepts:
1. Entities.
2. Attributes.
3. Relationships.
Example ER diagram:
2.2.1 Entity and Entity Set
An entity is a real-world thing which is distinguishable from other. An entity can be
place, person, object, event or a concept. For example, in a company database,
employees, dealers, orders, and products can be considered as entities. Every entity is
made up of some 'attributes' which represent that entity. It is represented by a
rectangle.
Examples:
• Person: Employee, Student, Patient.
• Place: Store, Building.
• Object: Machine, product, and Car.
• Event: Sale, Registration, Renewal.
• Concept: Account, Course.
A collection of similar types of entities put together is known as an entity set. An
entity set may contain entities with attribute sharing similar values. For example, an
Ch. Vijayananda Ratnam @Dept. of CSE 2
Database Management Systems UNIT-II
Employee set may contain all the employees of a company. Entity sets need not be
disjoint.
Fig. Representation of Entity.
Types of Entities
There are two types of entities. They are:
1. Strong Entity.
2. Weak Entity.
Strong Entity
Strong entity are those entity types which has a key attribute. The primary key helps
in identifying each entity uniquely. It is represented by a rectangle. In the below
example, roll_no identifies each row of the table uniquely and hence, we can say that
STUDENT is a strong entity.
Fig. Representation of Strong entity.
Weak Entity
Weak entity doesn't have a key attribute. Weak entity type can't be identified
on its own. Its existence depends upon some other strong entity. For example, there
can be children only if the parent exits. There can be no independent existence of
children.
A weak entity is represented by a double outlined rectangle. The relationship
between a weak entity type and strong entity type is called an identifying
relationship and shown with a double outlined diamond. This representation can be
seen in the diagram below.
Ch. Vijayananda Ratnam @Dept. of CSE 3
Database Management Systems UNIT-II
Example: If we have two entities of Loan (Loan_no, amount, Total_EMIs) and Payment
(Payment_Id, P_Amount, P_Date). In this case, we cannot identify the Payment on its
own, because there is no Loan.
Fig. Representation of Weak entity.
2.2.2 Attributes
An attribute is a property or characteristic of the entity that holds it. For example, a
Student might have attributes: roll_no, name, address, phone_no, etc. It is represented
by an ellipse/oval.
Fig. Representation of Attribute.
There exists a specific domain or set of values for each attribute from where the
attribute can take its values.
For example, a student's name cannot be a numeric value. It has to be alphabetic. A
student's age cannot be negative, etc.
Types of Attributes
In ER diagram, attributes associated with an entity set may be of the following types-
1. Simple attribute.
2. Composite attribute.
3. Single valued attribute.
4. Multi valued attribute.
5. Derived attribute.
6. Key attribute.
Ch. Vijayananda Ratnam @Dept. of CSE 4
Database Management Systems UNIT-II
1. Simple attribute
― Simple attributes are atomic values, which cannot be divided further.
Example:
Fig. Representation of Simple attributes
Here, student’s class, gender, dob are atomic values which cannot be divided further.
2. Composite attribute
― A composite attribute is made up of more than one simple attribute.
― A composite attribute can be further divisible.
Example:
Here, the attributes “Name” and “Address” are composite attributes as they are
composed of many other simple attributes.
Fig. Representation of Composite attributes
3. Single Valued Attribute:
― These are the attributes which can take only one value at a time.
Example:
Ch. Vijayananda Ratnam @Dept. of CSE 5
Database Management Systems UNIT-II
Fig. Representation of Single valued attributes
Here, all the attributes are single valued attributes as they can take only one at a time.
4. Multi-Valued Attribute
― These are the attributes which can take more than one value at a time.
― They are represented by a double ellipse.
Example:
Fig. Representation of Multi - valued attributes
Here, the attributes “Mob_no” and “Email_id” are multi-valued attributes as they can
take more than one value.
5. Derived Attribute
― These are the attributes which can be derived from other attribute(s).
― They are represented by dashed ellipses.
Example:
Fig. Representation of Derived attributes
Here, “age” is a derived attribute as it can be derived from the attribute “dob”.
6. Key Attribute
Ch. Vijayananda Ratnam @Dept. of CSE 6
Database Management Systems UNIT-II
― These are the attributes which can identify an entity uniquely in an entity set.
― Key attributes should be underlined.
Example:
Fig. Representation of Key attribute.
Here, the attribute “roll_no” is a key attribute as it can identify each student uniquely.
2.2.3 Relationship
A relationship is an association among two or more entities. Entities take part in the
relationship. It is represented by a diamond shape.
For example, an employee works at a specific department. Here, "works at" is a
relationship and this is the relationship between an Employee entity and a Department
entity.
Like entities, a relationship too can have attributes. These attributes are called
descriptive attributes. Here “Since” is the descriptive attribute.
Fig. Example of Works_at relationship
Relationship Set
― A set of relationships of similar type is called a relationship set.
Ch. Vijayananda Ratnam @Dept. of CSE 7
Database Management Systems UNIT-II
Degree of a Relationship
― The number of entity sets that participate in a relationship set is termed as the
degree of that relationship. Degree of above relationship is 2.
Types of Relationships
On the basis of degree of a relationship set, a relationship can be classified into the
following types:
1. Unary relationship.
2. Binary relationship.
3. Ternary relationship.
4. N-ary relationship.
1. Unary relationship
― When there is a relationship between two entities of the same type is known as
Unary relationship. It is known as a recursive relationship.
― This means that the relationship is between different instances of the same
entity type.
― For example, an employee can supervise group of employees. Hence, this is a
recursive relationship of entity employee with itself.
Ch. Vijayananda Ratnam @Dept. of CSE 8
Database Management Systems UNIT-II
2. Binary Relationship
― When there are exactly two entity sets participating in a relationship then such
type of relationship is called binary relationship.
― For example, a student enrolls a course, Here, “enrolls” is a relationship and this
is the relationship between a Student entity and a Course entity.
3. Ternary relationship
― When there are exactly three entity sets participating in a relationship then
such type of relationship is called ternary relationship
― For example: In the real world, a patient goes to a doctor and doctor prescribes
the medicine to the patient, three entities Doctor, Patient and Medicine are
involved in the relationship “prescribes”.
N-ary relationship
― When more than three entity sets are participating in a relationship, then such
type of relationship is called an N-ary relationship
― For example: In the real world, a patient goes to a doctor and doctor prescribes
the diagnosis and medicine to the patient, four entities Doctor, Patient,
Medicine and Diagnostics are involved in the relationship “prescribes”.
Ch. Vijayananda Ratnam @Dept. of CSE 9
Database Management Systems UNIT-II
2.4 Mapping Cardinalities / Constraints
― It defines how many entities in entity set A can be related to entities in entity
set B in a relationship set R.
(or)
― It defines number of instances participated in a relationship.
― It is most useful in describing the relationship sets that involve more than two
entity sets.
― For binary relationship set R on an entity set A and B, there are four possible.
― These are as follows:
1. One to one (1:1)
2. One to many (1:M)
3. Many to one (M:1)
4. Many to many (M:M)
1. One to One (1:1)
― 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.
― Symbol used:
― For example, assume that the only male can be married to only one female
and one female can be married to only one male, this can be viewed as one-
Ch. Vijayananda Ratnam @Dept. of CSE 10
Database Management Systems UNIT-II
to-one cardinality.
2. One to Many (1 : M)
― An entity in A is associated with any (zero or more) entities of B, and an entity
in B can be associated with at most one entity in A.
― Symbol used:
― For example, a customer can place multiple orders from a website/shop.
3. Many to One (M: 1)
― An entity in A is associated with atmost one entity in B and an entity in B can
be associated with any (zero or more) number of entities in A.
― Symbol used:
― For example: A student can belong to at most one class but one class can have
many students.
Ch. Vijayananda Ratnam @Dept. of CSE 11
Database Management Systems UNIT-II
4. Many to Many (M : N)
― An entity in A is associated with any number of entities in B and an entity in B
is associated with any number of entities in A.
― Symbol used:
― For example: Here many books are written by many authors and many authors
write many books.
Participation Constraints
― There are two types of participation constraints — total and partial.
― The participation of an entity set E in a relationship set R is said to be total if
every entity in E participates in at least one relationship in R.
― If only some entities in E participate in relationships in R, the participation
of entity set E in relationship R is said to be partial.
― Double line indicates the total participation constraint.
― Single line indicates the partial participation constraint.
― For example, a student enrolled for course, if we are representing this as a
diagram,
― The participation of entity set course in enrolled relationship set is partial
because a course may or may not have students enrolled in.
― The participation of entity set student in enrolled relationship set is total
because every student is expected to relate at least one course through the
Ch. Vijayananda Ratnam @Dept. of CSE 12
Database Management Systems UNIT-II
enrolled relationship set
― Cardinality Constraints specify maximum participation i.e., At most.
― Participation Constraints specify minimum participation: At least or
Minimum.
2.5 Extended Features of E – R Model
As the complexity of data increased in the late 1980s, it became more and more
difficult to use the traditional ER Model for database modelling. Hence some
improvements or enhancements were made to the existing ER Model to make it able
to handle the complex applications better.
Hence, as part of the Enhanced ER Model, three new concepts were added to the
existing ER Model, they were:
1. Generalization.
2. Specialization.
3. Aggregation.
Features of Extended E-R Model
• EER creates a design more accurate to database schemas.
• It reflects the data properties and constraints more precisely.
• It includes all modelling concepts of the ER model.
• Diagrammatic technique helps for displaying the EER schema.
• It includes the concept of specialization and generalization.
Generalization
It is a bottom-up design approach in which two or more lower - level entities
are combined to form a higher-level entity if they have some common attributes.
Hence, lower-level entities are combined to form a more generalised entity.
For example, Teacher and Student entities can be generalised with entity name
Person based on some common attributes like Name, Address, Age and Aadhaar.
Ch. Vijayananda Ratnam @Dept. of CSE 13
Database Management Systems UNIT-II
Specialization
Specialization is opposite to Generalization. It is a top-down design approach in which
one higher level entity can be broken down into two or more lower - level entities
based on some distinct attributes.
For example, the generalized entity Account may be decomposed to further as
current account entity and savings account entity based on distinct attributes like
overdraft facility and minimum balance, interest rate respectively.
Aggregation
It is a process when relation between two entities is treated as a single entity. Simply
it is used when we need to express a relationship among other relationships.
(or)
Aggregation is an abstraction in which relationship sets (along with their associated
entity sets) are treated as higher-level entity sets, and can participate in relationships.
Ch. Vijayananda Ratnam @Dept. of CSE 14
Database Management Systems UNIT-II
In the diagram above, the relationship between College and Course together, is acting
as an Entity, which is in relationship with another entity Student. Now in real world, if
a Student visits College, he/she will never enquire about the College only or just
about the Course, rather he/she will enquire about both.
2.6 Weak entity set
• An entity set that does not have a primary key is referred to as a weak entity
set.
• The existence of a weak entity set depends on the existence of an identifying
entity set / strong entity set:
o It must relate to the identifying entity set via a total participation; one-
to-many relationship set from the identifying to the weak entity set.
o Identifying relationship depicted using a double diamond.
• The discriminator (or partial key) of a weak entity set is the set of attributes
that distinguishes among all the entities of a weak entity set.
• The primary key of a weak entity set is formed by the primary key of the strong
entity set on which the weak entity set is existence dependent, plus the weak
entity set’s discriminator.
• We depict a weak entity set by double rectangles and underline the
discriminator of a weak entity set with a dashed line.
• Weak entity relationship set depicted using double diamonds.
Ch. Vijayananda Ratnam @Dept. of CSE 15
Database Management Systems UNIT-II
Example: When the loan is approved, the customer begins payment. In this case,
the loan and payment are the two entities where the loan is a strong entity and
the payment is a weak entity, as its existence depends on the loan.
• Loan entity has loan_no as primary key.
• Payment entity has payment_no which is a discriminator.
• So, primary key for payment is (loan_no, payment_no).
2.7 Notations
E-R Diagram is a visual representation of data that describes how data is related to
each other using different symbols and notations. Following are the major
components and its symbols in E- R Diagrams:
• Rectangle: This symbol represents entity types.
• Ellipse: This symbol represent attributes.
• Dashed Ellipse: This symbol represent derived attributes.
• Diamond: This symbol represents relationship types.
• Lines: It links attributes to entity types and entity types with other relationship
types.
• Primary key: attributes are underlined
• Double Ellipses: Represent multi-valued attributes
• Double Diamonds: Represent identifying relationship.
Ch. Vijayananda Ratnam @Dept. of CSE 16
Database Management Systems UNIT-II
Fig. Symbols used in E – R Model
2.8 Examples on Conceptual Design:
1. In a university, a student enrolls in Courses. A student must be assigned to at least
one or more Courses. Each course is taught by a single Professor. To maintain
instruction quality, a professor can deliver only one course. Construct an E-R diagram
for above problem.
Steps to Create an ER Diagram
1. Identify the Entities
2. Find relationships
3. Identify the cardinalities
4. Identify attributes including key attributes for every Entity
5. Draw complete E-R diagram with all attributes including Primary Key
Step 1: Entity Identification.
1. Student.
2. Course.
3. Professor.
Ch. Vijayananda Ratnam @Dept. of CSE 17
Database Management Systems UNIT-II
Step 2: Find Relationships.
1. Student enrolls a course.
2. Course taught by professor
Step 3: Identify the cardinalities.
1. A student may enrolled for more than one course (one -to – many).
2. Each course is taught by one course (one – to - one)
Step 4: Identify attributes including key attributes for every Entity.
Entity Attributes
Student roll_no, name, address
Course c_id, cname
Professor emp_id, ename, dept
Step 5: Draw complete E-R diagram with all attributes including Primary key.
Fig. E-R Diagram
Ch. Vijayananda Ratnam @Dept. of CSE 18
Database Management Systems UNIT-II
2. Construct an E-R Model for a college database:
Assumptions :
• A college contains many departments.
• Each department can offer any number of courses.
• Many faculties can work in a department.
• A faculty can work only in one department.
• For each department there is a Head.
• A faculty can be head of only one department.
• Each faculty can take any number of courses.
• A course can be taken by only one faculty.
• A student can enroll for any number of courses.
• Each course can have any number of students.
Step 1: Identify the Entities.
1. Department.
2. Student.
3. Course.
4. Faculty.
Step 2: Find the relationships:
• Student enrolls for course.
• Department offers courses.
• Department has multiple instructors
• Each department is supervised by one faculty (Head).
• One course is taught by only one instructor.
Step 3: Identify the cardinalities
• One course is enrolled by multiple students and one student enrolls for multiple
courses, hence the cardinality between course and student is Many to Many.
• The department offers many courses and each course belongs to only one
department, hence the cardinality between department and course is One to
Many.
Ch. Vijayananda Ratnam @Dept. of CSE 19
Database Management Systems UNIT-II
• One department has multiple instructors and one instructor belongs to one and
only one department, hence the cardinality between department and instructor
is One to Many.
• Each department there is a “Head of department” and one instructor is “Head
of department “, hence the cardinality is One to One.
• One course is taught by only one instructor, but the instructor teaches many
courses, hence the cardinality between course and instructor is Many to One.
Step 4: Identify attributes including key attributes for every Entity.
• For the Department entity, the attributes are dept_id, dname, loc and here
dept_id is key attribute as it uniquely identifies every department.
• For the Course entity, the attributes are course-id, cname, duration, pre-
requisite and here course-id is key attribute.
• For the Faculty entity, the attributes are fac_id, fname, address, salary, and here
fac_id is key attribute.
• For the Student entity, the attributes are roll_no, sname, dob, address, mobile-
no and here roll_no is key attribute.
Step 5: Draw complete E-R diagram with all attributes including Primary Key
Ch. Vijayananda Ratnam @Dept. of CSE 20
Database Management Systems UNIT-II
3. Construct an E-R diagram for a Banking Management System.
Assumptions:
Where bank consists of many branches and every bank branch is situated in different
cities and can be uniquely identified by unique name. Each of these branches keeps
the tally of all the deposits and loans given to its customers. Bank customer have a
unique customer identifier, name, and postal address. A customer can have a checking
or a saving account and could also take loans. For loan customer may have get services
from personal bankers or loan officers. Each bank employee has a unique identifier.
Each employee has a manager, name, postal address, joining date, location of branch.
Accounts can be held by more than one customer and one customer can have many
accounts as well. Saving accounts has an interest rate whereas Checking account only
keeps the record of deposits dates, amounts and check numbers.
Ch. Vijayananda Ratnam @Dept. of CSE 21
Database Management Systems UNIT-II
*********** End of UNIT- II ***********
Ch. Vijayananda Ratnam @Dept. of CSE 22