The document discusses entity-relationship (E-R) modeling as a conceptual tool to represent business environments through entities and relationships. It covers key components such as attributes, cardinality, and types of entities while emphasizing the importance of the requirements specification in capturing business rules. Additionally, it explains the distinctions between fundamental, weak, and associative entities within the E-R model.

1. ER MODELING

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

3. Life-Cycle
n Requirements
n specification of customer/user needs/desires
n Design
n specification of potential solution or solution
approach
n Implementation
n providing the solution
n Test Results
n evaluations, inferences, reports, documentation
n Modifications
n changes/additions to solution

4. E-R Model (Peter Chen, 1976)
n Diagrammatic
n Simple but expressive
n Easy to map into traditional DBMS
models
n Extensions
n Extended ER Model
n Entity Category Relationship Model
n Enhanced ER Model

5. 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.

6. E-R Modeling
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.
works_
EMPLOYEE DEPARTMENT
for
entity relationship entity

7. 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.

8. 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..)

9. Types of Attributes
n Simple and composite
n Single-valued and multivalued
n Null
n Derived

10. Simple and Composite
Attributes
n Simple Attribute: An attribute composed of a
single component with an independent
existence. E.g position and salary of the Staff
entity.
n 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.

11. Single-Valued and Multi-
Valued Attributes
n Single-Valued Attribute: An attribute that
holds a single valuefor each occurrence of an
entity type. E.g branchNo.
n Multi-Valued Attributes: An attribute that
holds multiple values for each occurrence of
an entity type. E.g telephoneNo.

12. Derived Attributes
n 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.
n E.g attribute duration which value is
derived from the rentStart and rentFinish
attributes.

13. Relationship
models the real-world association between two
or more entities (binary, n-ary 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).

14. Relationship:Mapping Cardinality
“Cardinality” indicates the entity
occurrences (instances) participating in a
relationship.
takes values “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.
works_
EMPLOYEE DEPARTMENT
for

15. One-to-One (1:1)
Staff Branch
Manages
staffNo 1..1 0..1 branchNo
“Each branch is managed by “A member of staff can
manage zero or one branch”
One member of the staff”

16. One-to-Many (1:*)
Staff PropertyForRent
Oversees
staffNo 0..1 0..* propertyNo
“Each properity for rent is “Each member of staff
overseen by zero or one oversees zero or more
member of staff” properitys for rent”

17. Many-to-Many (*:*)
Newspaper PropertyForRent
Advertises
newspaperName 0..* 1..* propertyNo
“Each properity for rent is “Each newspaper advertises
advertised in zero or more one or more properties for
newspapers” rent”

18. 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.

19. Entity : Categorisation
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

20. Entity types : Weak
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”

21. Entity types : Associative
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.

22. Summary
Entities & Relationships
Building an Entity-Relationship model
Attributes and Identifiers
Cardinality, Degree, Existence of
Relationships