Fundamentals of
Database Systems
Chapter 3
Data Modeling Using
Entity-Relationship Model
IM ISU
Database
1
Database Design Process
 Two main activities:
 Database design
 Applications design
 Focus in this chapter on database design
 To design the conceptual schema for a database
application
 Applications design focuses on the programs
and interfaces that access the database
 Generally considered part of software engineering
IM ISU
Database
2
Database Design Process (cont.)
 Requirements collection and analysis
 The database designers interview prospective
database users
 The result is data requirement
 Functional analysis
 Specify the known functional requirements of
the application
 Consist of user-defined operations, such as
retrievals and updates
IM ISU
Database
3
Database Design Process (cont.)
 Conceptual design
 Specify concisely the data requirement of the users,
such as entity types, relationships, and constraints
 Use high-level conceptual data model, e.g., EntityRelationship model
 Used as a reference to communicate with
nontechnical users
 Modifications to the conceptual schema can be
introduced when some functional requirements
cannot be specified
IM ISU
Database
4
Database Design Process (cont.)
 Logical design (data model mapping)
 Refer to the actual implementation of the
database using a commercial DBMS
 Need to transform the conceptual data model
into the implementation data model, e.g.,
relational model
 Physical design
 Specify the internal storage structures, access
paths, and file organizations
IM ISU
Database
5
IM ISU
Database
6
Example Database
 An COMPANY database
 The company is organized into departments
 Each department controls several projects
 Need to keep track all employee and their
working hours
 Need to keep track of the dependents of each
employee
IM ISU
Database
7
Example Database (cont.)
IM ISU
Database
8
ER Model Concepts
 Entities and Attributes
 Entities are specific objects or things in the
mini-world, e.g., EMPLOYEE John Smith
 Attributes are properties used to describe an
entity, e.g., Name, SSN, Address, Sex,
BirthDate for EMPLOYEE
 A specific entity will have a value for each of
its attributes, e.g, Name = ‘John Smith’
IM ISU
Database
9
ER Model Concepts (cont.)
 Two example entities
IM ISU
Database
10
ER Model Concepts (cont.)
 Types of attributes
 Simple vs Composite
» Each entity has a single atomic value for the
attribute, e.g., SSN
» Composite attributes may be composed of several
components, e.g., address, and may form a
hierarchy
 Single-valued vs Multi-valued
» Most attributes are single-valued, but some
attributes may have multiple values, e.g., Expert
IM ISU
Database
11
ER Model Concepts (cont.)
 An example hierarchy of composite attributes
IM ISU
Database
12
ER Model Concepts (cont.)
 Stored vs Derived
» In some case, two (or more) attributes are related
» Age (derived attribute) can be derived from the
BirthDate attribute (stored attribute)
 Complex
» In general, composite and multi-valued attributes
may be nested arbitrarily
» e.g., AddressPhone for a person
IM ISU
Database
13
ER Model Concepts (cont.)
 Entity Types and Key Attributes
 Entities with the same basic attributes are
grouped or typed into an entity type, e.g,
EMPLOYEE type
 Key attribute
» An attribute for which each entity must have a
unique value, e.g, SSN for EMPLOYEE
» A key attribute may be composite
» An entity type may have more than one key
attributes, e.g, VehicleId, Registration
IM ISU
Database
14
ER Model Concepts (cont.)
IM ISU
Database
15
ER Model Concepts (cont.)
IM ISU
Database
16
Displaying an Entity type
 In ER diagrams, an entity type is displayed in a
rectangular box
 Attributes are displayed in ovals
 Each attribute is connected to its entity type
 Components of a composite attribute are connected
to the oval representing the composite attribute
 Each key attribute is underlined
 Multivalued attributes displayed in double ovals
IM ISU
Database
17
Displaying an Entity type (cont.)
 Example diagram for CAR entity type
IM ISU
Database
18
Entity Set
 Each entity type will have a collection of
entities stored in the database
 Called the entity set
 e.g, entity set for CAR
 Same name (CAR) used to refer to both the
entity type and the entity set
 Entity set is the current state of the entities of
that type that are stored in the database
IM ISU
Database
19
ER Model Concepts – Relationships
 Relationships and Relationship Types
 A relationship relates two or more distinct
entities with a specific meaning
» e.g, EMPLOYEE John Smith works on ProductX
PROJECT
 Relationships of the same type are grouped or
typed into a relationship type
IM ISU
Database
20
ER Model Concepts – Relationships
(cont.)
IM ISU
Database
21
ER Model Concepts – Relationships
(cont.)
 Degree of a relationship type: the number of
participating entity types
» e.g., WORKS_FOR is a binary relationship,
SUPPLY is a ternary relationship
 A relationship type can be represented as
attributes
» e.g., WORKS_FOR relationship =>
Department of EMPLOYEE or
Employees of DEPARTMENT
IM ISU
Database
22
ER Model Concepts – Relationships
(cont.)
IM ISU
Database
23
ER Model Concepts – Relationships
(cont.)
 Recursive relationships: A relationship relate
two entities of the same entity type
(participates in different roles)
» e.g., SUPERVISION: relates relates one
EMPLOYEE (in the role of supervisee) to another
EMPLOYEE (in the role of supervisor)
 A relationship type can have attributes
» e.g., HoursPerWeek of WORKS_ON
IM ISU
Database
24
ER Model Concepts – Relationships
(cont.)
IM ISU
Database
25
ER Model Concepts – Relationships
(cont.)
 Structural constraints on relationships
 Cardinality ratio (of a binary relationship)
» Specify the number of relationship instances that an entity
can participate in
» 1:1, 1:N, N:1, or M:N (e.g., WORKS_ON)
 Participation constraint (on each participating entity
type)
» Specifies whether the existence of an entity depends on
another entity
» Two different types
– Total (called existence dependency), e.g.,
EMPLOYEE in WORKS_FOR
– Partial, e.g., EMPLOYEE in MANAGES
IM ISU
Database
26
ER Model Concepts – Relationships
(cont.)
IM ISU
Database
27
ER Model Concepts – Relationships
(cont.)
IM ISU
Database
28
ER Model Concepts (cont.)
 Weak entity types
 Entity types that does not have a key attribute
 Entity types that have a key attribute are
called regular (or strong) entity types
 A weak entity type must participate in an
identifying relationship type with an owner
(identifying entity type)
 A weak entity type always has a total
participation constraint
IM ISU
Database
29
ER Model Concepts (cont.)
 Example
» Suppose that a DEPENDENT entity is identified
by
– the dependent's first name and birthdate
– the specific EMPLOYEE the dependent is related to
» DEPENDENT is a weak entity type
– EMPLOYEE as its identifying entity type
– via the identifying relationship type
DEPENDENT_OF
IM ISU
Database
30
Notation Summary for ER Diagrams
IM ISU
Database
31
Notation Summary for ER Diagrams
(cont.)
IM ISU
Database
32
Notation Summary for ER Diagrams
(cont.)
IM ISU
Database
33
Alternative Notation for ER Diagrams
 Alternative notation for relationship
structural constraints
 Associate (min, max) with each participation
of an entity type E in a relationship type R
» Each entity e in E participates in at least (min)
and at most (max) relationship instances in R
» Default (no constraint): min = 0, max = n
» Must have 0 < min < max, max > 1
» min = 0 implies partial, min > 0 implies total
IM ISU
Database
34
Alternative Notation for ER Diagrams
(cont.)
Read the min,max numbers next to the entity type
and looking away from the entity type
IM ISU
Database
35
Notation for ER Diagrams (cont.)
IM ISU
Database
36
ER Conceptual Design
 Design Paradigm
 Initial design
» Identify all entity types and their attributes
 Iterative refinement
» Refine the attribute that are reference to another
entity into a relationship
» An attribute in several entity types may be
refined into its own entity type
– e.g., Department in STUDENT, INSTRUCTOR, and
COURSE
» An inverse refinement to the previous case may
be applied
IM ISU
Database
37
ER Conceptual Design (cont.)
 Example: An company database
 Initial design
IM ISU
Database
38
IM ISU
Database
39
ER Conceptual Design (cont.)
 Refinement
We specify the following relationship types
» MANAGES, 1:1 (EMPLOYEE:DEPARTMENT)
» WORKS_FOR, 1:N (DEPARTMENT:
EMPLOYEE)
» CONTROLS, 1:N (DEPARTMENT:PROJECT)
» SUPERVISION, 1:N (EMPLOYEE:EMPLOYEE)
» WORKS_ON, M:N (EMPLOYEE:PROJECT)
» DEPENDENTS_OF, 1:N (EMPLOYEE:
DEPENDENT)
IM ISU
Database
40
ER Conceptual Design (cont.)
 In the refined design, some attributes from the
initial entity types are refined into relationships:
 Manager of DEPARTMENT -> MANAGES
 Works_on of EMPLOYEE -> WORKS_ON
 Department of EMPLOYEE -> WORKS_FOR
 In general, more than one relationship type can
exist between the same participating entity types
 relationship types MANAGES and WORKS_FOR
between EMPLOYEE and DEPARTMENT
IM ISU
Database
41
Higher Degree Relationship
 Binary relationship vs ternary (or n-ary)
relationship
 A ternary relationship type  three binary
relationship types
 cp. Fig. 4.13, (s, p), (j, p), (s, j) > (s, j, p)
 In general, a ternary relationship type
represents more information than do three
binary relationship types
» e.g., quantity, supply date
IM ISU
Database
42
Higher Degree Relationship (cont.)
IM ISU
Database
43
Higher Degree Relationship (cont.)
 In case that only binary relationships are
permitted, a ternary relationship must be
» represented as a weak entity type with no partial
key, and
» with three identifying relationships
 It is often tricky to decide when to use binary
or n-degree relationship representation
IM ISU
Database
44
Higher Degree Relationship (cont.)
IM ISU
Database
45
Higher Degree Relationship (cont.)
» (i, c, s) => (i, c), (i, s), (c, s)
» (i, c), (i, s), (c, s) > (i, c, s)
IM ISU
Database
46
Higher Degree Relationship (cont.)
 Constraints on ternary (or n-ary)
relationships
 Cardinality ratio
 Participation constraint
» Partial
» Total
 (min, max) notation
IM ISU
Database
47
Chapter Summary
 ER Model Concepts: Entities, attributes,
relationships
 Constraints in the ER model
 Using ER in step-by-step conceptual schema
design for the COMPANY database
 ER Diagrams - Notation
 Alternative Notations
IM ISU
Database
48