Lecture 4

Slid
e 31

Chapter Outline
Example Database Application (COMPANY)
ER Model Concepts
Entities and Attributes
Entity Types, Value Sets, and Key Attributes
Relationships and Relationship Types

Slide
3- 2

Example COMPANY Database

We need to create a database schema design based on the
following (simplified) requirements of 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 unique name, unique number and is located at a single
location.

Slide
3- 3

Example COMPANY Database

(Contd.)
We store each EMPLOYEEs social security number, address,
salary, sex, and birthdate.
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.

Each employee may have a number of DEPENDENTs.

For each dependent, we keep track of their name, sex, birthdate, and
relationship to the employee.

Slide
3- 4

ER Model Concepts
Entities and Attributes
Entities are 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 are properties used to describe an entity.

For example an EMPLOYEE entity may have the attributes
Name, SSN, Address, Sex, BirthDate

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

Each attribute has a value set (or data type) associated with
it e.g. integer, string, subrange, enumerated type,

Slide
3- 5

Types of Attributes (1)

Simple
Each entity has a single atomic value for the attribute. For
example, SSN or Sex.

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.

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

Slide
3- 6

Types of Attributes (2)

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 multivalued attribute denoted by {PreviousDegrees (College, Year,
Degree, Field)}
Multiple PreviousDegrees values can exist
Each has four subcomponent attributes:
College, Year, Degree, Field

Slide
3- 7

Example of a composite
attribute

Slide
3- 8

Entity Types and Key Attributes (1)

Entities with the same basic attributes are
grouped or typed into an entity type.
For example, the entity type EMPLOYEE and
PROJECT.

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.

Slide
3- 9

Entity Types and Key Attributes (2)

A key attribute may be composite.

Vehicle TagNumber is a key of the CAR entity

type with components (Number, State).
An entity type may have more than one key.

The CAR entity type may have two keys:

VehicleIdentificationNumber (popularly called VIN)
VehicleTagNumber (Number, State), aka license plate number.

Each key is underlined

Slide
3- 10

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

See CAR example on next slide

Slide
3- 11

Entity Type CAR with two keys and a

corresponding Entity Set

Slide
3- 12

Entity Set
Each entity type will have a collection of entities stored in the
database
Called the entity set

Previous slide shows three CAR entity instances in the 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

Slide
3- 13

Initial Design of Entity Types

for the COMPANY Database Schema
Based on the requirements, we can identify four initial entity
types in the COMPANY database:

DEPARTMENT
PROJECT
EMPLOYEE
DEPENDENT

Their initial design is shown on the following slide

The initial attributes shown are derived from the
requirements description

Slide
3- 14

Initial Design of Entity Types:

EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Slide
3- 15

Lecture 5
Slid
e 316

Refining the initial design by introducing

relationships
The initial design is typically not complete
Some aspects in the requirements will be represented as
relationships
ER model has three main concepts:
Entities (and their entity types and entity sets)
Attributes (simple, composite, multivalued)
Relationships (and their relationship types and relationship sets)

We introduce relationship concepts next

Slide
3- 17

Relationships and Relationship Types (1)

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.

The degree of a relationship type is the number of

participating entity types.
Both MANAGES and WORKS_ON are binary relationships.

Slide
3- 18

Relationship type vs. relationship set (1)

Relationship Type:
Is the schema description of a relationship
Identifies the relationship name and the participating entity types
Also identifies certain relationship constraints

Relationship Set:
The current set of relationship instances represented in the
database
The current state of a relationship type

Slide
3- 19

Relationship type vs. relationship set (2)

Previous figures displayed the relationship sets
Each instance in the set relates individual participating entities
one from each participating entity type
In ER diagrams, we represent the relationship type as follows:
Diamond-shaped box is used to display a relationship type
Connected to the participating entity types via straight lines

Slide
3- 20

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)

Slide
3- 21

ER DIAGRAM Relationship Types are:

WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Slide
3- 22

 Weak Entity Types

Roles and Attributes in Relationship Types

ER Diagrams - Notation
ER Diagram for COMPANY Schema
Alternative Notations UML class diagrams, others

Slid
e 323

Weak Entity Types

An entity that does not have a key attribute
A weak entity 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
Example:
A DEPENDENT entity is identified by the dependents first name,
and the specific EMPLOYEE with whom the dependent is related
Name of DEPENDENT is the partial key
DEPENDENT is a weak entity type
EMPLOYEE is its identifying entity type via the identifying
relationship type DEPENDENT_OF

Slide
3- 24

Constraints on Relationships
Constraints on Relationship Types
(Also known as ratio constraints)
Cardinality Ratio (specifies maximum participation)
One-to-one (1:1)
One-to-many (1:N) or Many-to-one (N:1)
Many-to-many (M:N)

Existence Dependency Constraint (specifies minimum

participation) (also called participation constraint)
zero (optional participation, not existence-dependent)
one or more (mandatory participation, existence-dependent)
Slide
3- 25

Many-to-one (N:1) Relationship

Slide
3- 26

Many-to-many (M:N) Relationship

Slide
3- 27

Displaying a recursive relationship

In a recursive relationship type.

Both participations are same entity type in

different roles.
For example, SUPERVISION relationships
between EMPLOYEE (in role of supervisor or
boss) and (another) EMPLOYEE (in role of
subordinate or worker).
In following figure, first role participation labeled with 1 and
second role participation labeled with 2.
In ER diagram, need to display role names to distinguish
participations.
Slide
3- 28

A Recursive Relationship
Supervision`

Slide
3- 29

Recursive Relationship Type is: SUPERVISION

(participation role names are shown)

Slide
3- 30

Lecture 6
Slid
e 331

Attributes of Relationship
types
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.
A value of HoursPerWeek depends on a particular (employee,
project) combination

Most relationship attributes are used with M:N relationships

In 1:N relationships, they can be transferred to the entity type on the
N-side of the relationship

Slide
3- 32

Example Attribute of a Relationship Type:

Hours of WORKS_ON

Slide
3- 33

Notation for Constraints on

Relationships
Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or
M:N
Shown by placing appropriate numbers on the relationship edges.

Participation constraint (on each participating entity type):

total (called existence dependency) or partial.
Total shown by double line, partial by single line.

NOTE: These are easy to specify for Binary Relationship Types.

Slide
3- 34

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 (signifying no limit)
Must have minmax, min0, max 1
Derived from the knowledge of mini-world 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 (0,n) for participation of DEPARTMENT in WORKS_FOR

Slide
3- 35

The (min,max) notation for

relationship constraints

Read the min,max numbers next to the entity

type and looking away from the entity type

Slide
3- 36

COMPANY ER Schema Diagram using (min, max)

notation

Slide
3- 37

Alternative diagrammatic
notation
ER diagrams is one popular example for displaying database
schemas
Many other notations exist in the literature and in various
database design and modeling tools
Appendix A illustrates some of the alternative notations that
have been used
UML class diagrams is representative of another way of
displaying ER concepts that is used in several commercial
design tools

Slide
3- 38

Summary of notation for ER diagrams

Slide
3- 39

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

Chapt
er 340

Problems with Current

Modeling Tools
DIAGRAMMING
Poor conceptual meaningful notation.
To avoid the problem of layout algorithms and aesthetics
of diagrams, they prefer boxes and lines and do nothing
more than represent (primary-foreign key) relationships
among resulting tables.(a few exceptions)

METHODOLGY
lack of built-in methodology support.
poor tradeoff analysis or user-driven design preferences.
Chapt
poor design verification and suggestions for
er 341
improvement.

ER DIAGRAM FOR A BANK

DATABASE

The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition

Chapt
er 342

PROBLEM with ER notation

THE ENTITY RELATIONSHIP MODEL IN ITS ORIGINAL FORM DID
NOT SUPPORT THE GENERALIZATION ABSTRACTION.

Chapt
er 343

Extended Entity-Relationship
(EER) Model
Incorporates Set-subset relationships
Incorporates Generalization Hierarchies
LIMITATIONS OF THE ER MODEL:
No relationship may be defined between an entity type
and a relationship type
NEXT SECTION OF THIS Presentation ILLUSTRATES HOW
THE ER MODEL CAN BE EXTENDED WITH
- Set-subset relationships and Generalization Hierarchies
Chapt
and how we can impose further notation on them.
er 344