Database Management System

Entity–Relationship Modeling 
Prepared By
Mehak Usmani

Modified By: Sophia Ajaz

1
Objectives
To learn:
•How to use Entity–Relationship (ER) modeling in database design.
•The basic concepts associated with the Entity–Relationship (ER) model, namely entities,
relationships, and attributes.
•A diagrammatic technique for displaying an ER model using the Unified Modeling Language
(UML).
•How to identify and resolve problems with ER models called connection traps

2
Concepts of the ER Model
• ER modeling is a top-down approach to database design that begins by
identifying the important data called entities and relationships between the
data that must be represented in the model.
• We then add more details such as the information we want to hold about the
entities and relationships called attributes and any constraints on the entities,
relationships, and attributes.
• To understand nature of the data and how it is used by the enterprise, we need
to have a model for communication that is non-technical and free of
ambiguities.

• Entity
• Relationship
• Attributes

3
Entity
An entity is an object in the real world that is distinguishable from other objects.

•Entity Type
A name/label assigned to items/objects that exists in an environment that have
similar properties.
•Entity Instance
A particular object belonging to a particular entity type.
•Entity Set
Collection of entity instances.

4
Examples of Entity Types

5
ER Notations
• Although there is general agreement about what each concept means, there
are a number of different notations that can be used to represent each
concept diagrammatically
• We can use following notation for drawing ER models
• UML notation - an increasingly popular object-oriented modeling language
called the Unified Modeling Language
• Chen notation
• Crow’s Feet notation

6
ER diagram of Staff and Branch entity types

7
ER diagram – representing entity
Entities are represented by means of rectangles.

8
Entity Type
• Strong Entity Type
• Entity type that is not existence-dependent on some other entity type. The
instances of this type can exist independently.

• Weak Entity Type

9
Entity Type
• 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.
• Weak entity must relate to the strong set via a one-to-many relationship set.
• Weak entity set is represented by double rectangles. The discriminator of a weak
entity set is underline with dashed line.

10
Strong & Weak Entity

11
12
Entity Type
• Associative Entity
• An entity used in a many-to-many relationship (represents an extra table). All
relationships for the associative entity should be many.
• An associative (or junction) table maps two or more tables together by
referencing the primary keys of each data table.

13
Entity Type
Weak entity of the relationship is depicted by double rectangle.

Associative entity is depicted by diamond in rectangle.

14
Entity Types

15
Strong entity type Client and weak entity type Preference

16
Relationship
The connection and interaction between the entity instances.

•Relationship type
• Name/label of meaningful associations among entity types.
•Relationship Instance
• Uniquely identifiable association, which includes one occurrence from each
participating entity type.

17
ER diagram of Branch Has Staff relationship

18
ER diagram – representing Relationships
• In some ER diagram, Relationships are represented by diamond-shaped
box. Name of the relationship is written inside the diamond-box.
• All the entities (rectangles) participating in a relationship, are connected to
it by a line.

19
Relationship Types
• Degree of a Relationship
• Number of participating entities in relationship.

• Relationship of degree :
• Unary relationship
• Binary relationship
• Ternary relationship

20
Unary relationship
• Recursive Relationship
• Relationship type where same entity type participates more than once in
different roles.
• Involves single entity type.
• Relationships may be given role names to indicate purpose that each participating
entity type plays in a relationship.

21
Recursive or unary relationship

22
Binary relationship
A relationship involves two entity types is called binary relationship.

23
Ternary relationship

24
Entities associated through two distinct relationships with role names

25
Attributes
• Attribute
• Property associated with an entity or a relationship type.
• An entity is described using a set of attributes.
• All entity instances in a given entity set have the same attributes.
• Choice of attributes reflects the level of detail we wish to store.

• Attribute Domain
• Set of allowable/possible values for one or more attributes.

26
ER diagram – Representing Attributes
Attributes are represented by means of ellipses(oval). Every ellipse represents
one attribute and is directly connected to its entity (rectangle).

27
Attributes
• Simple Attribute
• Attribute composed of a single component with an independent
existence.

• Composite Attribute
• Attribute composed of multiple components, each with an
independent existence.

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

29
Attributes
• Single-valued Attribute
• Attribute that holds a single value for each occurrence of an entity type.

• Multi-valued Attribute
• Attribute that holds multiple values for each occurrence of an entity type.

30
Attributes
• Multi-valued attributes are depicted by double ellipse.

31
Attributes
• Stored Attribute
• Already present in database.

• Derived Attribute
• Attribute that represents a value that is derivable from value of a related
attribute, or set of attributes, not necessarily in the same entity type.

32
Attributes
• Derived attributes are depicted by dashed ellipse.

33
Keys

• Primary Key
•Candidate key selected to uniquely identify each occurrence of an entity type.

• Composite Key
•A candidate key that consists of two or more attributes.

• Partial Key
•For Weak Entity, underline the discriminator with a dashed line.

34
ER diagram of Staff and Branch entities and their attributes

35
ER diagram - Primary Key
Primary key can be represented by underlining the attribute.

36
ERD – Entity, Relationship & Attributes

37
Entity – Example
Draw following entities with attributes.

 Employee
 Patient
 Book
 Customer

38
Attributes on Relationships
• Attributes can also be assigned to relationships known as descriptive
attributes.
• In UML, we represent attributes associated with a relationship type using the
same symbol as an entity type. However, to distinguish between a
relationship with an attribute and an entity, the rectangle representing the
attribute(s) is associated with the relationship using a dashed line.
• In other notation, we simply use ovals attached to diamond shape.

39
Relationship called Advertises with attributes
For example, consider the relationship Advertises, which associates the Newspaper and
PropertyForRent entity types. To record the date the property was advertised and the cost,
we associate this information with the Advertises relationship as attributes called dateAdvert
and cost, rather than with the Newspaper or the PropertyForRent entities.

40
Attributes on Relationships

41
Entity vs. attribute
Should a field be an attribute of entity or a separate entity?
Example: Address
Depends upon the use we want to make of address information, and the
semantics of the data:
•If we have several addresses per employee, address must be an entity.

•If the structure (city, street, etc.) is important, e.g., we want to retrieve
employees in a given city, address must be modeled as an entity (since attribute
values are atomic).

42
Structural Constraints
• Main type of constraint on relationships is called multiplicity.
• A multiplicity is made up of a lower and an upper cardinality.

• Multiplicity - number (or range) of possible occurrences of an entity type that may
relate to a single occurrence of an associated entity type through a particular
relationship.

• Represents policies (called business rules) established by user or company.

43
Multiplicity
• There are following types of multiplicities
• one-to-one (1:1)
• one-to-many (1:*)
• many-to-many (*:*)

44
Multiplicity one-to-one (1:1)

45
Multiplicity one-to-many (1:*)

46
Multiplicity many-to-many(*:*)

Note: When implementing the ERD, a many-to-many relationship set is represented as a table with
columns for the primary keys of the two participating entity sets, and any descriptive attributes of the
relationship set.

47
Summary of multiplicity constraints

48
Other Notation for Multiplicity
• When it comes to notation, data modelers have many options to choose
from. While crow's foot notation is widely accepted as the most intuitive
style, some developers use OMT, IDEF, Bachman, or UML notation to
indicate cardinality.
• There are many notation styles that express cardinality:
 Chen
 Crow's foot
 Bachman
 OMT

49
Chen Notation
• one-to-one (1:1)
• one-to-many (1:N)
• many-to-many (M:N)

where M & N can be 0,1,2,3…

50
Crow's foot

51
Bachman

53
Object Modeling OMT

54
Examples

55
Examples

56
Structural Constraints
• Multiplicity is made up of two types of restrictions on relationships: Cardinality &
Participation

Cardinality
• Describes maximum number of possible relationship occurrences for an entity
participating in a given relationship type.
• It simply refers to the relationship that one table can have with another table.
These relationships include:
• many-to-many,
• one-to-many, or
• one-to-one

57
Structural Constraints
Participation
•Determines least or minimum entity occurrences participate in a relationship.The
participation for a given entity in a relationship is represented by the minimum
value on the opposite side of the relationship.

There are two types of participation constraints.

•Partial or optional (0):

58
Total & Partial Participation

59
60
 Works
total participation for

Employee Department

partial participation
manages

61
Multiplicity as cardinality and participation constraints

62
Try it!
Consider Library Management System, what data will you store to implement the
system and how will you organize the data.

1.Write down basic requirements.

63