Winter 2017

Bojana Bislimovska

CS 338

Data Modeling Using the Entity-Relationship

(ER) Model

Major research

• Conceptual design

• An example

• Entities

• Relationships

• ER model refinement

• ER conventions and naming issues

Outline

Major research

Database Design Steps

Major research

Database Design Steps

Major research

A Sample Database Application

• Requirements gathered for COMPANY

• Company is organized into departments. Each department has a unique

name, a unique number, and an employee (manager) of the department.

The DB keeps track of when the employee began managing the

department. A department may have several locations.

• Department controls a number of projects, each of which has a unique

name, a unique number and a single location.

• The DB will store ea h e plo ee’s a e, So ial Security number, address,

salary, sex (gender), and birth date. An employee is assigned to one

department, but may work on several projects, not necessarily controlled

by the same department. The DB keeps track of current number of hours

per week that an employee works on each project, as well as the direct

supervisor of each employee (who is another employee).

• The DB keeps track of the dependents of each employee for insurance

purposes, i ludi g ea h depe de t’s first a e, se , irth date a d relationship to the employee.

Major research

A Sample Database Application

• Requirements gathered for

COMPANY

Employees, departments, and

projects

Company is organized into

departments

Department controls several

projects

Employee: require each

e plo ee’s a e, So ial Security number, address,

salary, sex (gender), and birth

date

Keep track of the dependents

of each employee

Major research

ER Model Overview

• ER model describes data as entities, relationships and attributes

Entities and entity sets – objects in the real world with

independent existence

Relationships – Connections between objects (entities)

Attributes- Properties that describe entities or relationships

Major research

Entities and Attributes

• Example

Attribute types

• Simple

• Composite –divided into smaller basic attributes with independent meaning

• Single-valued –single value for an entity

• Multi-valued

• Derived- computed (determined) from related entities or attributes

• Stored

• NULL values –entity does not have an applicable value for an attribute

Locations No of employees

Multivalued Derived

Composite

Entities

• Entity type – a collection of entities that share the same attributes

• Entity set- a collection of all entities of a particular entity type

• ER model defines entity sets, not individual entities

Entities

• Key attribute- has a distinct value for each individual entity in the

entity set

• Value sets of attributes- sets of values that can be assigned to the

attribute for each entity

Initial Conceptual Design for the Company DB

• Four entity types

• Most attributes are simple, single-valued, and stored Works_on and Locations

are multivalued

E plo ee’s Na e is composite

• Employee has one key, department and project have two keys, dependent has none

Relationships

• Relationship –an attribute of one entity refers to another entity

Works_on

Relationship Types, Sets and Instances

• Relationship type- defines a set of associations among entities from n entity types

• Relationship instance- association that includes exactly one entity from each entity type

• Relationship set- set of relational instances

Relationship Degree

• Binary

• Higher degree

• n entity types

• Typically n=3 => ternary relationship

Binary

Ternary

Role Name and Recursive Relationships

• Role name

• Explains the role of a participating entity in each relationship instance

• Required when the same entity type participates in a relationship type in different roles => recursive relationships

Recursive Relationship Example

1-Supervisor

2-Subordinate

Relationship Cardinality Constraints

• One-to-one (1:1): each entity in one set can be related to at most one entity in the other, and vise versa

EMPLOYEE

MANAGES

DEPARTMENT

1

1

Relationship Cardinality Constraints

• Many-to-one (N:1): each entity in one set can be related to at most one entity in the other, but an entity in the second set may be related to many entities in the first

• One-to-many (1:N): same as N:1 switching the two entities

EMPLOYEE

WORKS_FOR

DEPARTMENT

N

1

Relationship Cardinality Constraints

• Many-to-many (M:N): an entity in one set can be related to many entities in the other set, and vice versa

EMPLOYEE

WORKS_ON

PROJECT

M

N

Relationship Participation Constraints

Participation constraint specifies whether the existence of an entity depends on its participation in a relationship type with another entity

• Total participation (existence dependency)

• Partial participation

EMPLOYEE DEPENDENT DEP_OF N 1

Relationship Structural Constraints

Structural Constraints=Participation+Cardinality Constraints

Change in notation: (min,max) are specified

0-partial participation, 1- total participation

EMPLOYEE DEPENDENT (1,1) (0,N)

DEP_OF

Relationship Type Attributes

• For 1:1 relationship type, relationship attributes can be migrated to either of the participating entity types

• For 1:N relationship type, attributes can be migrated to the N-side of the relationship

• For M:N relationship type, some attributes depend on both of participating entities, hence cannot be migrated

Works_on Hours

Weak Entity Types

• Do not have key attributes

• Related to a spe ifi e tit t pe ow er through o e of the ow er’s attri utes (identifying relationship)

• Have total participation constraint

• Have a partial key that uniquely identifies weak entities related to the same owner entity

• Can be represented as complex attributes (designer decision)

Refining Company DB ER Design

• Change attributes that reference entity types into relationship types

Weak entities use identifying relationship

• Determine cardinality ratio and participation constraints for each relationship type

Refining Company DB ER Design

Alternative Notation

ER Model Design Conventions

• Choose names that convey meanings attached to various constructs.

• Nouns give rise to entity type names

• Verbs indicate names of relationship types

Choose binary relationship names to make ER diagram readable from left to right and from top to bottom

• Review all attributes

Refine into a relationship if attribute references an entity type

Attribute that exists in several entity types may be better modelled as an independent entity type

• Entities that must participate in a relationship with another entity type and with cardinality constraint of 1 might be better modelled as weak entity

Higher Degree Relationship Types: Choice of Degree

Three binary relationships Supply as a weak entity