ERD-ENTITY RELATIONSHIP DIAGRAM

1
OBJECTIVES
 Definition of terms
 Importance of data modeling
 Write good names and definitions for entities,
relationships, and attributes
 Distinguish unary, binary, and ternary
relationships
 Model different types of attributes, entities,
relationships, and cardinalities
 Draw E-R diagrams for common business
situations
 Convert many-to-many relationships to
associative entities
 Model time-dependent data using time stamps
2
BUSINESS RULES
 Statements that define or constrain some
aspect of the business
 Assert business structure

 Control/influence business behavior

 Expressed in terms familiar to end users

 Automated through DBMS software

3
 E-R MODEL CONSTRUCTS
 Entities:
 Entity instance–person, place, object, event, concept (often
corresponds to a row in a table)
 Entity Type–collection of entities (often corresponds to a
table)

 Relationships:
 Relationship instance–link between entities (corresponds to
primary key-foreign key equivalencies in related tables)
 Relationship type–category of relationship…link between
entity types

 Attribute–property or characteristic of an entity or

relationship type (often corresponds to a field in a table)

4
Sample E-R Diagram (Figure 3-1)

5
Basic E-R notation (Figure 3-2)

Entity
Attribute
symbols
symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type
6 is
allowed
WHAT SHOULD AN ENTITY BE?
 SHOULD BE:
 An object that will have many instances in the
database
 An object that will be composed of multiple
attributes
 An object that we are trying to model
 SHOULD NOT BE:
A user of the database system
 An output of the database system (e.g., a report)

7
Figure 3-4 Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities

8
ATTRIBUTES
 Attribute–property or characteristic of an entity or
relationahip type
 Classifications of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single-Valued versus Multivalued Attribute
 Stored versus Derived Attributes
 Identifier Attributes

9
IDENTIFIERS (KEYS)
 Identifier (Key)–An attribute (or combination
of attributes) that uniquely identifies
individual instances of an entity type
 Simple versus Composite Identifier
 Candidate Identifier–an attribute that could
be a key…satisfies the requirements for
being an identifier

10
CHARACTERISTICS OF IDENTIFIERS

 Will not change in value

 Will not be null

 No intelligent identifiers (e.g., containing locations

or people that might change)

 Substitute new, simple keys for long, composite

keys

11
 Figure 3-7 A composite attribute

An attribute
broken into
component parts

Figure 3-8 Entity with multivalued attribute (Skill)

and derived attribute (Years_Employed)

Multivalued
an employee can have
Derived
more than one skill
from date
employed12
and current
date
Figure 3-9 Simple and composite identifier attributes

The identifier is boldfaced and underlined

13
Figure 3-19 Simple example of time-stamping

This attribute
that is both
multivalued
and
composite 14
MORE ON RELATIONSHIPS
 Relationship Types vs. Relationship Instances
 The relationship type is modeled as lines between
entity types…the instance is between specific
entity instances
 Relationships can have attributes
 These describe features pertaining to the association
between the entities in the relationship
 Two entities can have more than one type of
relationship between them (multiple
relationships)
 Associative Entity–combination of
relationship and entity

15
Figure 3-10 Relationship types and instances

a) Relationship type

b)
Relationship
instances

16
DEGREE OF RELATIONSHIPS
 Degree of a relationship is the number of
entity types that participate in it
 Unary Relationship
 Binary Relationship
 Ternary Relationship

17
Degree of relationships – from Figure 3-2

Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each 18
other
CARDINALITY OF RELATIONSHIPS
 One-to-One
 Each entity in the relationship will have
exactly one related entity
 One-to-Many
 An entity on one side of the relationship
can have many related entities, but an
entity on the other side will have a
maximum of one related entity
 Many-to-Many
 Entitieson both sides of the relationship
can have many related entities on the
other side
19
 CARDINALITY CONSTRAINTS
 Cardinality Constraints - the number of instances of
one entity that can or must be associated with each
instance of another entity
 Minimum Cardinality
 If zero, then optional
 If one or more, then mandatory
 Maximum Cardinality
 The maximum number

20
Figure 3-12 Examples of relationships of different degrees

a) Unary relationships

21
Figure 3-12 Examples of relationships of different degrees (cont.)

b) Binary relationships

22
Figure 3-12 Examples of relationships of different degrees (cont.)

c) Ternary relationship

Note: a relationship can have attributes of its own 23

Figure 3-17 Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have

recorded for one and recorded at least one
only one patient history, and can have
many
24
Figure 3-17 Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be An employee can be

assigned to at least assigned to any number
one employee, and of projects, or may not be
may be assigned to assigned to any at all
many 25
Figure 3-17 Examples of cardinality constraints (cont.)

a) Optional cardinalities

A person is is
married to at
most one other
person, or may
not be married
at all

26
Figure 3-21 Examples of multiple relationships

a) Employees and departments

Entities can be related to one another in more than one way

27
Figure 3-21 Examples of multiple relationships (cont.)

b) Professors and courses (fixed lower limit constraint)

Here, min
cardinality
constraint is 2

28
gure 3-15a and 3-15b Multivalued attributes can be represented as relationships

simple

composite
29
 STRONG VS. WEAK ENTITIES, AND
IDENTIFYING RELATIONSHIPS
 Strong entities
 exist independently of other types of entities
 has its own unique identifier
 identifier underlined with single-line
 Weak entity
 dependent on a strong entity (identifying owner)…cannot exist on its
own
 does not have a unique identifier (only a partial identifier)
 Partial identifier underlined with double-line
 Entity box has double line
 Identifying relationship
 links strong entities to weak entities

30
 Identifying relationship

Strong entity Weak entity

31
ASSOCIATIVE ENTITIES
 An entity–has attributes

A relationship–links entities together
 When should a relationship with attributes instead
be an associative entity?
 All relationships for the associative entity should be many
 The associative entity could have meaning independent of
the other entities
 The associative entity preferably has a unique identifier,
and should also have other attributes
 The associative entity may participate in other relationships
other than the entities of the associated relationship
 Ternary relationships should be converted to associative
entities

32
Figure 3-11a A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship
33
Figure 3-11b An associative entity (CERTIFICATE)

Associative entity is like a relationship with an attribute, but it is

also considered to be an entity in its own right.

Note that the many-to-many cardinality between entities in

Figure 3-11a has been replaced by two one-to-many relationships
with the associative entity. 34
Figure 3-13c An associative entity – bill of materials structur

This could just be a relationship with

attributes…it’s a judgment call
35
Figure 3-18 Ternary relationship as an associative entity

36
 Microsoft Visio
Notation for Pine
Valley Furniture
E-R diagram

Different modeling
software tools may
have different
notation for the same
constructs

37
Problem
 A company database needs to store information

about employees (identified by ssn, with salary

and phone as attributes), departments (identified
by dno, with dname and budget as attributes), and
children of employees (with name and age as
attributes).
 Employees work in departments; each department

is managed by an employee; a child must be

identified uniquely by name when the parent (who
is an employee; assume that only one parent
works for the company) is known. We are not
interested in information about a child once the
parent leaves the company.
 Draw an ER diagram that captures this

information.