Entity Relationship Modeling

Objectives:
• To illustrate how relationships between entities are defined and refined.
• To know how relationships are incorporated into the database design
process.
• To describe how ERD components affect database design and
implementation.

ERD :: 19 / 1 / 07 1
 1.0 What is Conceptual
Database Design?
 Process of describing the data, relationships
between the data, relationships between the data,
and the constraints on the data.
 After analysis - Gather all the essential data required
and understand how the data are related
 The focus is on the data, rather than on the
processes.
 The output of the conceptual database design is a
Conceptual Data Model ( + Data Dictionary)

ERD :: 19 / 1 / 07 2
 2.0 Gathering Information for
Conceptual Data
Modeling
 Two perspectives
 Top-down
 Data model is derived from an intimate understanding of
the business.
 Bottom-up
 Data model is derived by reviewing specifications and
business documents.

ERD :: 19 / 1 / 07 3
 2.0 Entity-Relationship
(ER) Modeling.
 ER Modeling is a top-down approach to database
design.
 Entity Relationship (ER) Diagram
 A detailed, logical representation of the entities,
associations and data elements for an organization or
business
 Notation uses three main constructs
 Data entities
 Relationships Chen Model &
Crow’s Foot
 Attributes Model

ERD :: 19 / 1 / 07 4
 Chen Notation

Association
between the
instances of one or
more entity types

EntityName Verb Phrase AttributeName

Person, place, object, event named property or

or concept about which data characteristic of an
is to be maintained entity

Represents a set or collection of

objects in the real world that
share the same properties
Crow’s Foot Notation

Entity Attribute Relationship

EntityName
EntityName Verb phrase

List of
Attributes

Acceptable
2.1 Entities

 Examples of entities:
 Person: EMPLOYEE, STUDENT, PATIENT
 Place: STORE, WAREHOUSE
 Object: MACHINE, PRODUCT, CAR
 Event: SALE,REGISTRATION, RENEWAL
 Concept: ACCOUNT, COURSE
 Guidelines for naming and defining entity types:
 An entity type name is a singular noun
 An entity type should be descriptive and specific
 An entity name should be concise
 Event entity types should be named for the result of the
event, not the activity or process of the event.

ERD :: 19 / 1 / 07 7
2.2 Attributes

 Example of entity types and associated attributes:

STUDENT: Student_ID, Student_Name, Home_Address,
Phone_Number, Major

 Guidelines for naming attributes:

 An attribute name is a noun.
 An attribute name should be unique
 To make an attribute name unique and clear, each
attribute name should follow a standard format
 Similar attributes of different entity types should use
similar but distinguishing names.

ERD :: 19 / 1 / 07 8
 2.2.1 Identifier Attributes

 Candidate key
 Attribute (or combination of attributes) that uniquely identifies each
instance of an entity type
 Some entities may have more than one candidate key
 Ex: A candidate key for EMPLOYEE is Employee_ID, a second is the combination of
Employee_Name and Address.
 If there is more than one candidate key, need to make a choice.

 Identifier
 A candidate key that has been selected as the unique identifying
characteristic for an entity type

ERD :: 19 / 1 / 07 9
 2.2.2 Referential Attributes

 Make Reference to another instance in another table

Referential attribute: Ties the lecturer entity to

another entity that is department.

Name IdNum DeptID Email

Ali 105 LG [email protected]

Mary 106 IT [email protected]

John 107 ENG [email protected]
Lim 108 IT [email protected]
Instance of Lecturer.

ERD :: 19 / 1 / 07 10
 Following are the main components and its symbols in ER Diagrams:
•Rectangles: This Entity Relationship Diagram symbol represents entity types
•Ellipses : Symbol represent attributes
•Diamonds: This symbol represents relationship types
•Lines: It links attributes to entity types and entity types with other relationship types
•Primary key: attributes are underlined
•Double Ellipses: Represent multi-valued attributes

ER Diagram Symbols

ERD :: 19 / 1 / 07 11
ERD :: 19 / 1 / 07 12
ERD :: 19 / 1 / 07 13
ERD :: 19 / 1 / 07 14
ERD :: 19 / 1 / 07 15
ERD :: 19 / 1 / 07 16
ERD :: 19 / 1 / 07 17
ERD :: 19 / 1 / 07 18
Example

Name Gender

StaffID IC

Staff

Staff
PK StaffID

Name
Gender
IC

ERD :: 19 / 1 / 07 19
2.3 Relationships

 Associations between instances of one or more entity types that is of interest

 Given a name that describes its function.
• relationship name is an active or a passive verb.

Relationship name:
writes

Author Book

An author writes one or more books

A book can be written by one or more authors.

ERD :: 19 / 1 / 07 20
 2.3.1 Degree of Relationships

 Degree: number of entity types that participate in a relationship

 Three cases
 Unary: between two instances of one entity type
 Binary: between the instances of two entity types
 Ternary: among the instances of three entity types

ERD :: 19 / 1 / 07 21
 2.4 Cardinality and
Connectivity

 Relationships can be classified as either

 one – to – one
 one – to – many Connectivity
 many – to –many

 Cardinality : minimum and maximum number of

instances of Entity B that can (or must be)
associated with each instance of entity A.

ERD :: 19 / 1 / 07 22
 2.4 Cardinality and Connectivity

Professor teaches Class

teaches
Professor Class

A professor teaches class OR

A class is taught by professor

How Many??

ERD :: 19 / 1 / 07 23
 2.4 Cardinality and Connectivity

Connectivity

1 M
Professor teaches Class

(1,4) (1,1)

Cardinality

Connectivity

teaches
Professor Class

(1,1) (1,4)

Cardinality
ERD :: 19 / 1 / 07 24
 2.4.1 Connectivity

 Chen Model
 1 to represent one. 1
 M to represent many

M
 Crow’s Foot

One Mandatory one , means (1,1)

many

One or many
Optional

ERD :: 19 / 1 / 07 25
2.5 Binary Relationships

 1:M relationship
 Relational modeling ideal
 Should be the norm in any relational database design

The 1: M relationship between PAINTER and PAINTING

ERD :: 19 / 1 / 07 26
The Implemented 1:M relationship between PAINTER and PAINTING
 2.5 Binary Relationships

 1:1 relationship
 Should be rare in any relational database
design
 A single entity instance in one entity class is
related to a single entity instance in another
entity class
 Could indicate that two entities actually
belong in the same table

ERD :: 19 / 1 / 07 28
The 1:1 Relationship Between PROFESSOR and DEPARTMENT
The Implemented
1:1 Relationship
Between
PROFESSOR
and
DEPARTMENT
 2.5 Binary Relationships

 M:N relationships
 Must be avoided because they lead to data
redundancies.
 Can be implemented by breaking it up to produce
a set of 1:M relationships
 Can avoid problems inherent to M:N relationship
by creating a composite entity or bridge
entity
 This will be used to link the tables that were originally related in
a M:N relationship
 The composite entity structure includes-as foreign keys-at
least the primary keys of the tables that are to be linked.

ERD :: 19 / 1 / 07 31
 The M:N Relationship Between STUDENT and CLASS

Bowser Accounting 1 (ACCT-211)

Intro to Microcomputing (CIS-220)

Smithson

Intro to Statistics (QM-261)

This CANNOT be implemented as shown next…..

The tables have many redundancies!!

+ CLASS_CODE
CLASS_CODE

+ STU_NUM
Changing the M:N relationship to TWO 1:M relationships
 The database designer has 2 main options to
define a composite table’s primary key:
either
use the combination of those foreign
keys or create a new primary key.

Foreign keys reference the primary keys in the

other tables of which it has a relationship with

Converting the M:N relationship into TWO 1:M relationships

 2.6 Mandatory vs. Optional
Cardinalities

 Specifies whether an instance must exist or

can be absent in theOptional
Mandatory relationship

handles
Lecturer Class
(1,1) (0,N)

1 M
Lecturer handles Class
(0,N) (1,1)

A Lecturer may handle zero or many classes.

A class is handled by one and only one Lecturer.

ERD :: 19 / 1 / 07 36
 2.7 How to Evaluate a Data
Model?

 A good data model has the following:

 Accuracy and completeness
 Non redundancy
 Enforcement of business rules
 Data Reusability
 Stability and Flexibility
 Communication Effectiveness
 Simplicity

ERD :: 19 / 1 / 07 37
A Common Mistake

Modeling the business processes or functions

instead of the data.

What data we want to keep??

We are interested in modeling the data,
NOT the processes or functions that use
or generate those data.

ERD :: 19 / 1 / 07 38
 Example:

M N
Member Searches Books

Is this part of the data requirement?

Are we interested to know the books searched by the members?

If answer is NO, then DO NOT include that as a relationship.

Use other appropriate diagramming techniques to capture the business
processes such as Data Flow Diagram.
Do not mix up the use of ER Modeling with DFD.

ERD :: 19 / 1 / 07 39
 ~The END~

Q&A

ERD :: 19 / 1 / 07 40