ER Diagram/ Model Unit IV RDBMS Arnav Chowdhury, PIMR, Indore

1. UNIT - IV
ENTITY RELATIONSHIP
MODELS
ENTITY RELATIONSHIP MODELS: BASIC CONCEPTS LIKE ENTITY SET,
ATTRIBUTE, RELATIONSHIP SET, MAPPING CONSTRAINTS, KEYS, E-R
DIAGRAM, FEATURES OF WEAK ENTITY SET, DESIGN OF AN E-R DATABASE
SCHEMA, EXPRESSING M: N RELATION, GENERALIZATION AND
AGGREGATION.

2. ER MODEL
• The ER model defines the conceptual view of a database. It works around real-world entities
and the associations among them. At view level, the ER model is considered a good option for
designing databases

3. ENTITY
• An entity can be a real-world object, either animate or inanimate, that can be easily identifiable.
For example, in a school database, students, teachers, classes, and courses offered can be
considered as entities. All these entities have some attributes or properties that give them their
identity.
• An entity set is a collection of similar types of entities. An entity set may contain entities with
attribute sharing similar values. For example, a Students set may contain all the students of a
school; likewise a Teachers set may contain all the teachers of a school from all faculties. Entity
sets need not be disjoint.

4. ATTRIBUTES
• Entities are represented by means of their properties, called attributes. All attributes have
values. For example, a student entity may have name, class, and age as attributes.
• There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.

5. TYPES OF ATTRIBUTES
• Simple attribute − Simple attributes are atomic values, which cannot be divided further. For
example, a student's phone number is an atomic value of 10 digits.
• Composite attribute − Composite attributes are made of more than one simple attribute. For
example, a student's complete name may have first_name and last_name.
• Derived attribute − Derived attributes are the attributes that do not exist in the physical database,
but their values are derived from other attributes present in the database. For example,
average_salary in a department should not be saved directly in the database, instead it can be
derived. For another example, age can be derived from data_of_birth.
• Single-value attribute − Single-value attributes contain single value. For example −
Social_Security_Number.
• Multi-value attribute − Multi-value attributes may contain more than one values. For example, a
person can have more than one phone number, email_address, etc.

6. ENTITY-SET AND KEYS
• Key is an attribute or collection of attributes that uniquely identifies an entity among entity set.
• For example, the roll_number of a student makes him/her identifiable among students.
• Super Key − A set of attributes (one or more) that collectively identifies an entity in an entity
set.
• Candidate Key − A minimal super key is called a candidate key. An entity set may have more
than one candidate key.
• Primary Key − A primary key is one of the candidate keys chosen by the database designer to
uniquely identify the entity set.

7. RELATIONSHIP
Relationship
• The association among entities is called a relationship. For example, an employee works_at a
department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.
Relationship Set
• A set of relationships of similar type is called a relationship set. Like entities, a relationship too
can have attributes. These attributes are called descriptive attributes.

8. ER MODEL
Entity
• Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent

9. ER MODEL
Attributes
• Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle).

10. COMPOSITE
If the attributes are composite, they are further divided in a tree like structure. Every node is then
connected to its attribute. That is, composite attributes are represented by ellipses that are
connected with an ellipse.

11. MULTIVALUED
• Multivalued attributes are depicted by double ellipse.
•

12. DERIVED
Derived attributes are depicted by dashed ellipse.

13. EXAMPLE

14. RELATIONSHIP TYPE AND RELATIONSHIP
SET:
• A relationship type represents the association between entity types. For example,‘Enrolled in’
is a relationship type that exists between entity type Student and Course. In ER diagram,
relationship type is represented by a diamond and connecting the entities with lines.

15. RELATIONSHIP SET
A set of relationships of same type is known as relationship set. The following relationship set
depicts S1 is enrolled in C2, S2 is enrolled in C1 and S3 is enrolled in C3.

16. DEGREE OF A RELATIONSHIP SET:
The number of different entity sets participating in a relationship set is called as degree of a
relationship set.
1. Unary Relationship –
When there is only ONE entity set participating in a relation, the relationship is called as
unary relationship. For example, one person is married to only one person.

17. BINARY RELATIONSHIP
•
When there are TWO entities set participating in a relation, the relationship is called as
binary relationship. For example, Student is enrolled in Course.

18. N-ARY RELATIONSHIP –
•
When there are n entities set participating in a relation, the relationship is called as n-ary
relationship.

19. CARDINALITY
The number of times an entity of an entity set participates in a relationship set is known as cardinality.
Cardinality can be of different types:
• One to one – When each entity in each entity set can take part only once in the relationship,
the cardinality is one to one. Let us assume that a male can marry to one female and a female
can marry to one male. So the relationship will be one to one.

20. MANY TO ONE –
• When entities in one entity set can take part only once in the relationship set and entities
in other entity set can take part more than once in the relationship set, cardinality is many
to one. Let us assume that a student can take only one course but one course can be taken by
many students. So the cardinality will be n to 1. It means that for one course there can be n
students but for one student, there will be only one course.

21. MANY TO MANY
• When entities in all entity sets can take part more than once in the relationship cardinality is
many to many. Let us assume that a student can take more than one course and one course
can be taken by many students. So the relationship will be many to many.

22. PARTICIPATION CONSTRAINT
Participation Constraint is applied on the entity participating in the relationship set.
1. Total Participation – Each entity in the entity set must participate in the relationship. If each
student must enroll in a course, the participation of student will be total. Total participation is
shown by double line in ER diagram.
2. Partial Participation – The entity in the entity set may or may NOT participate in the
relationship. If some courses are not enrolled by any of the student, the participation of course
will be partial. The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set
having total participation and Course Entity set having partial participation.

23. STRONG ENTITY
• A strong entity is not dependent of any other entity in the schema. A strong entity will always have a
primary key. Strong entities are represented by a single rectangle. The relationship of two strong
entities is represented by a single diamond.
• Various strong entities, when combined together, create a strong entity set.

24. WEAK ENTITY
• A weak entity is dependent on a strong entity to ensure the its existence. Unlike a strong entity, a weak
entity does not have any primary key. It instead has a partial discriminator key. A weak entity is
represented by a double rectangle.
• The relation between one strong and one weak entity is represented by a double diamond.

25. EXAMPLE

26. DIFFERENCE
S.NO STRONG ENTITY WEAK ENTITY
1. Strong entity always has primary key. While weak entity has partial discriminator key.
2.
Strong entity is not dependent of any other
entity.
Weak entity is depend on strong entity.
3.
Strong entity is represented by single
rectangle.
Weak entity is represented by double rectangle.
4.
Two strong entity’s relationship is represented
by single diamond.
While the relation between one strong and one
weak entity is represented by double diamond.
5.
Strong entity have either total participation or
not.
While weak entity always has total participation.

27. LET'S STUDY THEM WITH AN EXAMPLE:

28. EXAMPLE
• 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

29. STEP 1) ENTITY IDENTIFICATION
• We have three entities
• Student
• Course
• Professor

30. STEP 2) RELATIONSHIP IDENTIFICATION
• We have the following two relationships
• The student is assigned a course
• Professor delivers a course

31. STEP 3) CARDINALITY IDENTIFICATION
• For them problem statement we know that,
• A student can be assigned multiple courses
• A Professor can deliver only one course

32. STEP 4) IDENTIFY ATTRIBUTES
• You need to study the files, forms, reports, data currently maintained by the organization to identify
attributes. You can also conduct interviews with various stakeholders to identify entities. Initially, it's
important to identify the attributes without mapping them to a particular entity.
• Once, you have a list of Attributes, you need to map them to the identified entities. Ensure an attribute
is to be paired with exactly one entity. If you think an attribute should belong to more than one entity,
use a modifier to make it unique.

33. Entity Primary Key Attribute
Student Student_ID StudentName
Professor Employee_ID ProfessorName
Course Course_ID CourseName

34. STEP 5) CREATE THE ERD
• A more modern representation of ERD Diagram

36. DESIGN OF AN E-R (EXAMPLE)

40. ER-MODEL: DESIGN OF AN ER DATABASE SCHEMA
• The data which is stored in the database at a particular moment of time is called an instance of the
database.
• The overall design of a database is called schema.
• A database schema is the skeleton structure of the database. It represents the logical view of the entire
database.
• A schema contains schema objects like table, foreign key, primary key, views, columns, data types,
stored procedure, etc.
• A database schema can be represented by using the visual diagram. That diagram shows the database
objects and relationship with each other.
• A database schema is designed by the database designers to help programmers whose software will
interact with the database. The process of database creation is called data modeling.

41. ER-MODEL: DESIGN OF AN ER DATABASE SCHEMA

42. GENERALIZATION, SPECIALIZATION AND
AGGREGATION IN ER MODEL
• Generalization –
• Generalization is the process of extracting common properties from a set of
entities and create a generalized entity from it. It is a bottom-up approach in
which two or more entities can be generalized to a higher level entity if they
have some attributes in common. For Example, STUDENT and FACULTY can be
generalized to a higher level entity called PERSON as shown in Figure 1. In this
case, common attributes like P_NAME, P_ADD become part of higher entity
(PERSON) and specialized attributes like S_FEE become part of specialized
entity (STUDENT).

43. GENERALIZATION, SPECIALIZATION AND AGGREGATION IN
ER MODEL

44. SPECIALIZATION
• In specialization, an entity is divided into sub-entities based on their
characteristics. It is a top-down approach where higher level entity is
specialized into two or more lower level entities. For Example, EMPLOYEE
entity in an Employee management system can be specialized into
DEVELOPER, TESTER etc. as shown in Figure 2. In this case, common attributes
like E_NAME, E_SAL etc. become part of higher entity (EMPLOYEE) and
specialized attributes like TES_TYPE become part of specialized entity
(TESTER).

45. SPECIALIZATION

46. AGGREGATION
• An ER diagram is not capable of representing relationship between an entity
and a relationship which may be required in some scenarios. In those cases, a
relationship with its corresponding entities is aggregated into a higher level
entity. For Example, Employee working for a project may require some
machinery. So, REQUIRE relationship is needed between relationship
WORKS_FOR and entity MACHINERY. Using aggregation, WORKS_FOR
relationship with its entities EMPLOYEE and PROJECT is aggregated into single
entity and relationship REQUIRE is created between aggregated entity and
MACHINERY.

47. AGGREGATION