CS4222
Principles of Database
System
3. Entity-Relationship model 2
Huiping Guo
Department of Computer Science
California State University, Los Angeles
Outline
 Alternative (min, max) notation for relationship constraints
 Weak entity sets
 Relationships of higher degree
 Design choices for ER conceptual design
 Data Modeling Tools
 In class exercises
3. ER modeling 2
CS4222_Su17
3-2
Alternative (min, max) notation for
relationship 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 (signifying no
limit)
Must have minmax, min0, max 1
Derived from the knowledge of mini-world
constraints
3. ER modeling 2
CS4222_Su17
3-3
Alternative (min, max) notation for
relationship constraints
 Examples:

A department has exactly one manager and an
employee can manage at most one department.
• Specify (0,1) for participation of EMPLOYEE in MANAGES
• Specify (1,1) for participation of DEPARTMENT in
MANAGES

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 (1,n) for participation of DEPARTMENT in
WORKS_FOR
3. ER modeling 2
CS4222_Su17
3-4
Alternative (min, max) notation for
relationship constraints
Read the min,max numbers next to the entity
type and looking away from the entity type
3. ER modeling 2
CS4222_Su17
3-5
Weak Entity Sets

What are the weak entity sets?



Partial key of a weak entity set

The set of attributes of a weak entity set that uniquely identify
a weak entity for a given owner entity
The identifying Owner



Entities that do not have sufficient attributes to form a key
They need to “borrow” the primary key from another entity set
to form a key.
The entity set that “lends” the primary key to a weak entity set
Weak 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
3. ER modeling 2
CS4222_Su17
3-6
Weak Entity Sets
 The following constraints must hold:
 Owner entity set and weak entity set must
participate in a one-to-many relationship set,
which is called identifying relationship set of
the weak entity set
 Weak entity set must have total participation in
this identifying relationship set.
3. ER modeling 2
CS4222_Su17
3-7
Weak Entity Sets
 Example:

DEPENDENT is a weak entity type
• A DEPENDENT entity is identified by the dependent’s
name, and the specific EMPLOYEE with whom the
dependent is related
• Name of DEPENDENT is the partial key

EMPLOYEE is its identifying entity type via the
identifying relationship type DEPENDENT_OF
3. ER modeling 2
CS4222_Su17
3-8
Weak Entity Sets
 Rectangle with double lines

Weak identity sets
Identifying relationship set

Partial key of the weak identity set

 Broken lines
name
ssn
name
sex
N
1
Dependents_of
Employees
birthdate
Dependents
relationship
3. ER modeling 2
CS4222_Su17
sex
3-9
Refining the COMPANY database
schema by introducing relationships
 By examining the requirements, six relationship types are
identified
 All are binary relationships( degree 2)
 Listed below with their participating entity types:






WORKS_FOR (between EMPLOYEE, DEPARTMENT)
MANAGES (also between EMPLOYEE, DEPARTMENT)
CONTROLS (between DEPARTMENT, PROJECT)
WORKS_ON (between EMPLOYEE, PROJECT)
SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
3. ER modeling 2
CS4222_Su17
3-10
ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION,
DEPENDENTS_OF
3. ER modeling 2
CS4222_Su17
3-11
Discussion on Relationship
Types
 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
etc
 In general, more than one relationship type can exist
between the same participating entity types


MANAGES and WORKS_FOR are distinct relationship types
between EMPLOYEE and DEPARTMENT
Different meanings and different relationship instances.
3. ER modeling 2
CS4222_Su17
3-12
COMPANY ER Schema Diagram using (min,
max) notation
3. ER modeling 2
CS4222_Su17
3-13
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
 Constraints are harder to specify for higherdegree relationships (n > 2) than for binary
relationships
3. ER modeling 2
CS4222_Su17
3-14
Example: a ternary relationship
 Supplier Supply part for a project
3. ER modeling 2
CS4222_Su17
3-15
3. ER modeling 2
CS4222_Su17
3-16
Discussion of n-ary relationships (n > 2)
 In general, 3 binary relationships can represent different
information than a single ternary relationship
3. ER modeling 2
CS4222_Su17
3-17
Discussion of n-ary relationships (n > 2)
 Suppose that Can_Supply, includes an instance
(s,p) whenever supplier s can supply part p (to any
project)
 Uses includes an instance (j,p) whenever a project
j uses part p
 Supplies includes an instance (s, j) whenever
supplier s supplies some part to project j
 The existence of the 3 relationship instances
(s,p), (j,p), and (s,j) does not necessarily imply that
an instance (s,j,p) exits in the ternary relationship
Supply, because the meaning is different
3. ER modeling 2
CS4222_Su17
3-18
Discussion of n-ary relationships (n > 2)
 If needed, the binary and n-ary relationships can
all be included in the schema design
 If only binary relationship is allowed, a ternary
relationship such as Supply must be represented
as a weak entity without partial key and with three
identifying relationships
3. ER modeling 2
CS4222_Su17
3-19
Ternary relationship as a weak
entity
3. ER modeling 2
CS4222_Su17
3-20
Design choices for ER conceptual
design
 The conceptual design is an iterative refinement process
 The initial design is created and then iteratively refined
until the most suitable design is reached
 Refinements


A concept may be first modeled as an attribute and then
refined into a relationship if the attribute is a reference to
another entity type
An attribute that exists in several entity type may be promoted
to an independent entity type
• Eg. Suppose in the University database, several entity types suchas
as Student, Instructor and Course
• Each has an attribute Department in the initial design
• An entity type department is created with a single attribute
dept_name and is related to the three entity types via appropriate
relationships
3. ER modeling 2
CS4222_Su17
3-21
Design choices for ER conceptual
design
 Refinements
 An inverse refinement to the previous case may be
applied
• Eg. If an entity type exists in the initial design with a single
attribute Dept_name and is related to only one other entity
type, Student
• In this case, Department may be reduced to an attribute of
Student
3. ER modeling 2
CS4222_Su17
3-22
Summary of notation for ER diagrams
3. ER modeling 2
CS4222_Su17
3-23
Data Modeling Tools
 A number of popular tools that cover conceptual modeling
and mapping into relational schema design.

Examples: ERWin, S- Designer (Enterprise Application Suite),
ER- Studio, etc.
 POSITIVES:

Serves as documentation of application requirements, easy user
interface - mostly graphics editor support
 NEGATIVES:


Most tools lack a proper distinct notation for relationships with
relationship attributes
Mostly represent a relational design in a diagrammatic form
rather than a conceptual ER-based design
3. ER modeling 2
CS4222_Su17
3-24
Some of the Currently Available
Automated Database Design Tools
COMPANY
TOOL
FUNCTIONALITY
Embarcadero
Technologies
ER Studio
Database Modeling in ER and IDEF1X
DB Artisan
Database administration, space and security management
Oracle
Developer 2000/Designer 2000
Database modeling, application development
Popkin Software
System Architect 2001
Data modeling, object modeling, process modeling,
structured analysis/design
Platinum
(Computer
Associates)
Enterprise Modeling Suite: Erwin,
BPWin, Paradigm Plus
Data, process, and business component modeling
Persistence Inc.
Pwertier
Mapping from O-O to relational model
Rational (IBM)
Rational Rose
UML Modeling & application generation in C++/JAVA
Resolution Ltd.
Xcase
Conceptual modeling up to code maintenance
Sybase
Enterprise Application Suite
Data modeling, business logic modeling
Visio
Visio Enterprise
Data modeling, design/reengineering Visual Basic/C++
3. ER modeling 2
CS4222_Su17
3-25
Exercise 1
 Design a DB representing cities, counties, and
states in the US:



For states, record the name, population, and state
capital (a city).
For counties, record the name, the population, and the
located state.
For cities, record the name, the population, the located
state and the located county.
3. ER modeling 2
CS4222_Su17
3-26
Design 1
Co. Popu.
Co. name
cities
Popu.
1
Located
states
name
Ci. Popu.
Ci. name
1
capit
al
1
Problem: County Population is repeated for each city.
3. ER modeling 2
CS4222_Su17
3-27
Design 2
Co. name
Co. Popu.
Popu.
1
counties
Located
name
states
1
Belongsto
1
cities
Ci. Popu.
Ci. name
3. ER modeling 2
1
capitals
The population of a county is derived
from those of its cities.
CS4222_Su17
3-28
Exercise 2
 Consider the following ER diagram.
3. ER modeling 2
CS4222_Su17
3-29
Exercise 2
 Assume that a course may or may not use a




textbook, but that a text by definition is a book
that is used in some course.
A course may not use more than five books.
Instructors teach from two to four courses.
Supply (min, max) constraints on this diagram.
State clearly any additional assumptions you make.
3. ER modeling 2
CS4222_Su17
3-30