This presentation will help you to understand the ER Diagram and concepts.

2. Presentation Contents
• An Introduction
• Entities & Relationships
• Cardinality, Degree, Existence of Relationships
• Attributes and Identifiers
• Building an Entity-Relationship model

3. History of
E-R Model
An Introduction
• E-R Model was proposed by Dr. Peter Chen
(currently professor at Louisiana State
University)
• Chen’s original paper on E-R Model is the 35th
most sited paper in computer science
• Chen has written papers interconnecting E-R
model and linguistics

4. Database Life
Cycle
An Introduction
Requirements
• specification of customer/user needs/desires
Design
• specification of potential solution or solution approach
Implementation
• providing the solution
Test Results
• evaluations, inferences, reports, documentation
Modifications
• changes/additions to solution

5. An Introduction
The three schema approach to software engineering uses three levels
of ER models that was developed.
Conceptual data model
Logical data model
Physical data model
The Conceptual Model
• Conceptual model captures the global/institutional view of the data semantics.
• It investigates and enumerates the various entities that participate in the
business environment being modelled
Conceptual
Data Model

6. Features of
E-R Model
An Introduction
1. Diagrammatic.
2. Simple but expressive.
3. Easy to map into traditional DBMS models.
4. Extensions
> Extended ER Model
> Entity Category Relationship Model
> Enhanced ER Model

7. E-R Modeling
Entities & Relationships
Entity-Relationship (E-R) Modeling is a
conceptual modeling tool.
perceives the business environment in terms of
participating “entities” and the “relationship”
between them.
e.g. many employees work for a department

8. E-R Modeling
Entities & Relationships
Entity
is a “data object”
models some object/entity in the real-world;
entity type represents the set of all similar
objects.
identified by the nouns in the requirements
specification.
must have a name that is unique across the
entire model and has a consistent meaning
across the modelling team and the end users.

9. E-R Modeling
Entities & Relationships
Attributes
characteristics/properties of an entity, that
provide descriptive details of it.
every attribute must be given a name that is
unique across the entity (distinct entities may
have attributes with the same name).
attribute names are also subject to the same
rules that govern entity names (consistent
meaning, documentation, etc..)
EMP ID
Name Address

10. Types of
Attributes
Entities & Relationships
1.Simple and composite
2.Single-valued and multivalued
3.Null
4.Derived

11. Entities & Relationships
Relationship
• ER models in the real-world association between two
or more entities (binary, ternary relationship).
• A relationship can be optional or mandatory
“degree” is the number of entity sets involved in
• the relationship. typically 2 (binary); other
common degrees are 1 (recursive) and 3 (ternary).

12. Attributes and Identifiers
Simple and Composite
Attributes
Simple Attribute: An attribute composed of a
single component with an independent
existence. E.g position and salary of the Staff
entity.
Composite Attribute: An attribute composed
of multiple components, each with an
independent existence. E.g adress attribute of
the branch entity that can be subdivided into
street, city and postcode attributes

13. Single-Valued and Multi-Valued
Attributes
Single-Valued Attribute: An attribute that
holds a single value for each occurrence of an
entity type. E.g branch No.
Multi-Valued Attributes: An attribute that
holds multiple values for each occurrence of
an entity type. E.g telephone No.
Attributes and Identifiers

14. Derived
Attributes
Derived Attributes: An attribute that
represents a value that is derivable from the
value of a related attribute or set of
attributes, not necessarily in the same entity
type.
E.g attribute duration which value is
derived from the rent Start and rent Finish
attributes.
Attributes and Identifiers

15. Cardinality, Degree, Existence of Relationship
Cardinality
• “Cardinality” indicates the entity occurrences (instances) participating
in a relationship.
• takes values as “one” or “many”. e.g. a one: many relationship
indicates that for
• Every occurrence of one entity, there are many related instances of the
other entity.
Employee Department

16. Cardinality, Degree, Existence of Relationship
One-to-One (1:1)

17. Cardinality, Degree, Existence of Relationship
One-to-Many (1:*)

18. Cardinality, Degree, Existence of Relationship
Many-to-Many (*:*)

19. Building the ER Model
• the requirements specification is the first step to any
design; it captures the ‘what’ of the business
environment.
• also documents the “business rules” - i.e., the
constraints that will apply to your database.
e.g. every department must have a manager; and
only one manager.
• the ER model must capture the participating entities
as well as these business rules.

20. Building the ER Model
Entity : Categorization
• Fundamental/strong entity
an entity that is capable of its “own existence” -
i.e. an entity whose instances exist
notwithstanding the existence of other entities.
• Weak Entities
• Associative Entities

21. Building the ER Model
Weak Entity
• an entity that is not capable of “its own
existence”.
• characterised by the need to have at least one
external identifier (of another entity) as part of
its own identifier. e.g. consider “ payment” and
“ pmt_items” “ pmt_items” cannot exist without
a corresponding “ payment” instance. “pmt_id”
of “ payment” will be part of the identifier of “
pmt_items”.

22. Building the ER Model
Associative Entity
• a relationship translates into migration of a key
many:many relationship implies the keys migrating many
times, both ways.
• such migration leads to redundancy and many:many
relationships must therefore be resolved.
• “Associative entity” is an entity that is used to resolve a
many:many relationship.