Data Modeling Using the

Entity-Relationship (ER) Data

Model

•Phases of Database Design Steps in DB Design

Conceptual Design Requirements

Definition
E-R model
Data-oriented approach - because data are more stable Develop
than the functions (or processes) in an organization. ER Model

Normalized
Tables

Design
Application

1
Database Design and Conceptual Data
Model

Analogous to analysis phase of software development

Requirement Collection and Analysis
- Designers interview database users to understand and
document data requirements.
Functional Requirements
- User defined operations to be applied on the database

2
 Database Design and Conceptual
Data Model (contd.)

• Conceptual Design
-Conceptual schema; a permanent description of
database specifications.
- Capture the semantics of the data; description of data,
constraints, relationships
- No storage details needed

3
 HISTORY OF DATA MODELS
• Description in high-level model
- Close to the user' view of mini-world
- Abstract concepts
- Means of communication between the non-technical
users and the developer
- Allows user to influence design and is independent of
any particular DBMS.
•Entity Relationship Data Model
- developed by Peter Chen (1983)
- basis for ANSI IRDS (Dolk & Kirsch, 1987; Winkler 1989)
4
 Example COMPANY Database

• Requirements for the COMPANY Database:

- The company is organized into DEPARTMENTs. Each
department has a name, number, and an employee who
manages the department. We keep track of the start date
of the department manager. A department may have
several locations.
-Each department controls a number of PROJECTs. Each
project has a name, number, and is located at a single
location.

5
 Example COMPANY Database
(contd.)

- We store each EMPLOYEE's social security number,

address, salary, sex, and birth date. Each employee
works for one department but may work on several
projects. We keep track of the number of hours per week
that an employee currently works on each project. We
also keep track of the direct supervisor of each employee.

6
 Example COMPANY Database
(contd.)

- Each employee may have a number of DEPENDENTs.

For each dependent, we keep their name, sex, birth date,
and relationship to the employee.

7
 ER Model Concepts
(Popular Conceptual model)

•Entities
Specific objects or things in the mini-world that are
represented in the database; for example the EMPLOYEE
John Smith, the Research DEPARTMENT, the ProductX
PROJECT
•Attributes
Properties used to describe an entity (or relationship); for
example an EMPLOYEE entity may have a Name, SSN,
Address, Sex, BirthDate.
8
 ER Model Concepts (contd.)

- A specific entity will have a value for each of its

attributes; for example a specific employee entity may
have Name='John Smith', SSN='123456789',
Address='731 Fondren, Houston, TX', Sex='M',
BirthDate='09-JAN-55'.
•Domain
Possible values for an attribute; for example ‘M’ and ‘F’ for
the Sex attribute.

9
 ER Model Concepts (contd.)

•Types of Attributes:
- Simple: Each entity has a single atomic value for the
attribute; for example SSN or Sex. (i.e., single-valued)
- Composite: The attribute may be composed of several
components; for example Address(Apt#, House#, Street,
City, State, ZipCode, Country) or Name(FirstName,
MiddleName, LastName). Composition may form a
hierarchy where some components are
themselves composite.

10
 ER Model Concepts (contd.)

- Multi-valued: An entity may have multiple values for

that attribute; for example Color of a CAR or
PreviousDegrees of a STUDENT. Denoted as {Color} or
{PreviousDegrees}
In general, composite and multi-valued attributes may be
nested arbitrarily to any number of levels although
this is rare. For example, PreviousDegrees of a
STUDENT is a composite multi-valued attribute
denoted by {PreviousDegrees(College, Year, Degree,
Field)}.

11
 Entity Types and Key Attributes

- Entities with the same basic attributes are grouped or

typed into an entity type. For example, the
EMPLOYEE entity type or the PROJECT entity type.

- An attribute of an entity type for which each entity

must have a unique value is called a key attribute of
the entity type. For example SSN of EMPLOYEE.

12
 Entity Types and Key Attributes
(contd.)
- A key attribute may be composite. For example,
VehicleRegistrationNumber is a key of the CAR entity
type with components (Number, State).

- An entity type may have more than one key.

for example, the CAR entity type may have two
keys: VehicleIdentificationNumber and
VehicleRegistrationNumber(Number, State).

13
 Relationships and Relationship Types

- A relationship relates two or more distinct entities with

a specific meaning; for example, EMPLOYEE John
Smith works on the ProductX PROJECT or
EMPLOYEE Franklin Wong manages the
Research DEPARTMENT.

- Relationships of the same type are grouped or typed

into a relationship type. For example, the
WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the
MANAGES relationship type in which
EMPLOYEEs and DEPARTMENTs participate.

14
 Relationships and Relationship Types
(contd.)
-The degree of a relationship type is the number of
participating entity types. Both MANAGES and
WORKS_ON are binary relationships.

- More than one relationship type can exist with the

same participating entity types; for example,
MANAGES and WORKS_FOR are distinct
relationships between EMPLOYEE and
DEPARTMENT participate.

15
 Structural Constraints and Roles

- A relationship can relate two entities of the same entity

type ; for example, a SUPERVISION relationship
type relates one EMPLOYEE (in the role of
supervisee ) to another EMPLOYEE (in the role
of supervisor ). This is called a recursive
relationship type

- A relationship type can have attributes; for example,

HoursPerWeek of WORKS_ON; its value for each
relationship instance describes the number of hours
per week that an EMPLOYEE works on a
PROJECT.

16
 Structural Constraints and Roles
(contd.)

•Structural constraints on relationships:

-Cardinality ratio (of a binary relationship):

1:1, 1:N, N:1, or M:N.
-Participation constraint
(on each participating entity type): total (called existence
dependency ) or partial.

17
 Structural Constraints and Roles
(contd.)

• Alternative (min, max) notation for relationship

structural constraints:

- Specified on each participation of an entity type E

in a relationship type R.
- Specifies that 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 min<max, min>0, max>1.
- Derived from the mini-world constraints.

18
 Structural Constraints and Roles
(contd.)

• Examples:

(a) A department has exactly one manager and an

employee can manage at most one department.

- Specify (1,1) for participation of EMPLOYEE in

MANAGES
- Specify (0,1) for participation of EMPLOYEE in
MANAGES

19
 Structural Constraints and Roles
(contd.)

(b) An employee can work for exactly one department

but a department can have any number of
employees.

- Specify (1,1) for participation of EMPLOYEE in

WORKS_FOR
- Specify (0,n) for participation of DEPARTMENT in
WORKS_FOR

20
 Weak Entity Types

•An entity type that does not have a key attribute

• A weak entity type must participate in an identifying

relationship type with an owner or identifying entity type
• Entities are identified by the combination of :
- A partial key of the weak entity type
- The particular entity they are related to in the
identifying entity type

21
 Weak Entity Types (contd.)

Example:

Suppose that a DEPENDENT entity is identified by the

dependent's first name and birthdate, and the specific
EMPLOYEE that the dependent is related to.
DEPENDENT is a weak entity type with EMPLOYEE as
its identifying entity type via the identifying relationship
type DEPENDENT_OF

22
 Relationships of Higher Degree

- Relationship types of degree 2 are called binary

- Relationship types of degree 3 are called ternary and of

degree n are called n-ary

- In general, an n-ary relationship is not equivalent to n

binary relationships

23
 Enhanced Entity-Relationship Model
(Concepts/Features)
•Subclass/subtype, superclass/supertype
Specialization -- define subclasses
Generalization -- define superclass
•Constraints on Specialization
Disjointness (Disjoint or Overlap)
Completeness (Total or Partial Specialization)
•Inheritance.
•Hierarchies and Lattices
•Union Types (Categories)
24
 Enhanced ER Model (EER)

• EER Model = ER Model + Extensions

• Extensions:
- Subclass (Specialization)
- Superclass (Generalization)
- Category
- Attribute and Relation Inheritance

25
 Subclass/Superclass

• Subclass: Entities of an Entity type sharing a set of

attribute which are grouped together
• Superclass: The ‘parent’ entity type from which
subclasses are formed
• Class/Subclass relationship: Relationship between a
superclass and oneof the subclasses
• Specialization: The process of forming subclasses
from a superclass

26
 Subclass/Superclass (contd.)

• Type Inheritance: Member of subclass possessing all

attributes and relationships of a member of superclass
• Local Attributes: Attributes that apply only to
members of a subclass (a.k.a. specific attribute)
• Local Relationships: Relationships applicable only to
members of a subclass(a.k.a. specific relationships)
• Generalization: Process of forming a supercalss from
subclasses. (Functionally, inverse of specialization)

27
 Specialization/Gerneralization
Characteristics

• Several Specializations could be defined on the same

entity type (Superclass)
• Specialization with single subclass is also permitted
• Predicate-defined subclass: Specialization specified
by a condition on the value some attribute of
superclass. (a.k.a. condition-defined)
• Defining predicate: Condition satisfied by all
members of a predicate-defined subclass

28
 Specialization/Gerneralization
Characteristics (contd.)

• Attribute-defined specialization: All subclasses

having membership condition on the same attribute of
the superclass
• Defining Attributes: No condition exists for determing
membership in the subclass

29
 Specialization/Generalization
Constriaints

• Disjointness constraint: Subclasses of the

specialization must be disjoint (an entity is a member
of at most one subclass)
- Overlapping: Subclasses not constrained to be
disjoint
• Completeness Constraint:
- Total: Every entity in superclass must be a member
of some subclass (e.g.\{HOURLY\_EMPLOYEE,
SALARIED\_EMPLOYEE\}

30
 Specialization/Generalization
Constriaints (contd.)

- Partial: An entity in superclass may not be a member

of any subclass
• Disjointness and Completeness are independent.
(leads to 4 possible constraints on specialization)
- Disjoint, Total
- Disjoint, Partial
- Overlapping, Total
- Overlapping, Partial

31
 Specialization Hierarchies and
Lattices

• Subclass may have further subclasses, and so on.

• Specialization Hierarchy: Every subclass participates
in only one class/subclass relationship
• Specialization Lattice: A subclass can participate in
more than one class/subclass relationship
• Leaf Node: A class that has no subclass

32
 Specialization Hierarchies and
Lattices
(contd.)
• Shared Subclass: A subclass with more than one
superclass
• Multiple Inheritance: A shared subclass inheriting
attributes and relationships from multiple (super)
classes

33
 Union Type/Categories

• Uniontype (Category): Subclass with class/subclass

relationship with more than one superclass of
different entity types
• Category is a subset of the union of its superclass
• An entity in Category is a member of only one of its
superclass
• Category types: Total or Partial

34
Coincidences between the ER Model and the
Surface Structure of English
(P. Chen, 1983)
Symbol ER Meaning English Equivalent

Entity Noun

Relationship Verb

Attribute of:
Entity Adjective
Relationship Adverb

35