Entity-Relationship

Diagrams (ERD)
Chapter 2
Entity-Relationship Diagram (ERD)
An entity-relationship diagram (ERD) is a graphical representation of the data model
representing the proposed database
Entity-Relationship Diagram (ERD)
ER diagram answers the questions:
What entities (person, place, or thing) are being represented?
What attributes (characteristics of data) are stored about each entity?
What are the relationships between the entities?
Basically, what data do we want to capture and what are the business rules
surrounding that data
Entity-Relationship Diagram (ERD)
attribute
Entity Name
attribute
Date of birth

Author
Entity Relation: Writes

attribute
Title
attribute
Publication year

Book
Entity-Relationship Diagram (ERD)
An ERD contains three components:
Entity-Relationship Diagram (ERD)
Four goals of ER diagrams:
• Capture all required data
• Ensure data appears only once in the database design
• Does not include any data that is derived from other data
already in the data model
• Arrange data in the data model in a logical manner
Steps to Create ER Diagram
Step Task
1 Identify entities
2 Identify attributes
3 Assign unique identifiers (UID) / primary key (PK)
4 Identify unique keys
5 Identify relationships
6 Identify relationship cardinality (and optionality)
7 Assign foreign keys
8 Name relationships and ER language
9 Eliminate many-to-many relationships
10 Define data types
11 Normalize the database (Chapter 5)
What is an Entity?
"Something" of significance to the business about which data must be captured
Entity Characteristics:
Usually a noun
Singular form
Upper case
Examples: CUSTOMER, STUDENT, EMPLOYEE
What is an Entity?
An Entity can be a(n):
Person – example EMPLOYEE
Place – example BUILDING
Object – example PRODUCT
Event – example CONCERT

Entities can be:

Tangible, like PERSON or PRODUCT
Intangible, like SKILL LEVEL
An event, like CONCERT
Entities have Instances
An entity instance is a single occurrence of an entity
Examples:
STUDENT entity - each student is an instance or occurrence within the STUDENT
entity
EMPLOYEE entity could have instances of hourly employees and salary employees
DEPARTMENT entity could have instances of engineering, planning, accounting, IT
Blackwater Consulting
The database planning phase has been completed and the database system has been
approved

What's the next step?

Requirements Analysis – page 19

Blackwater Consulting
Each employee works for one and only one department. When first hired, some
employees are not assigned to any department. The employee data is stored in the
employee entity.
Each department may have many employees assigned to it. Some departments,
however, may not have any employees assigned. The department data is stored in the
department entity.
Blackwater Consulting
Each employee may have one and only one job title. Under certain circumstances,
some employees are not assigned a job title.
It is possible that several employees have the same job title. Some jobs titles,
however, may not be assigned to any employees. The job data is stored in the job
entity.
Blackwater Consulting
Employees may be assigned to a project. However, there are times when an
employee may be off and not assigned to a project.
It is possible that several employees may be assigned to the same project. Initially,
some projects may not have any employees assigned. The project data is stored in the
project entity.
Blackwater Consulting
The Requirements Analysis phase is completed.

What is the first step in the creation of the ER Diagram?

Step 1: Identify Entities

Blackwater Consulting
Requirements Analysis
What are the entities for Blackwater Consulting? That is, what does the company
want to store data about?
Step 1: Identify Entities
A singular name (usually a noun)
Capital letters in bold
Entity name at the top inside the rectangle
Step 2: Identify Attributes
An attribute:
A specific piece of data that describes an entity
Can only have one value at any one moment in time for each instance in the entity
attribute = color vs. value = "blue"
attribute = type vs. value = "dog"
The attribute value may change over time
Usually, but not always, an entity has at least one attribute
Blackwater Consulting
Requirements Analysis
Blackwater is divided into departments. Each department has a unique department id
and department name

What are the attributes?

DEPARTMENT Attributes
Blackwater is divided into departments. Each department has a unique department id
and department name
Blackwater Consulting
Requirements Analysis
We also need to store data about our employees. Each employee is assigned a unique
employee id. In addition, we store each employee's first name, last name, birth date,
gender, social security number, hire date, and salary.
What are the attributes?
EMPLOYEE Attributes
Each employee is assigned a unique employee id. In addition, we store each
employee's first name, last name, birth date, gender, social security number, date
hired, and salary.
Blackwater Consulting
Requirements Analysis
For each job, we store the job id, job title, minimum salary, and maximum salary

What are the attributes for the JOB entity?

JOB Attributes
For each job type, we store the job id, job title, minimum salary, and maximum salary
Blackwater Consulting
Requirements Analysis
Each project is assigned a project id. In addition, we store the project title, start date,
and end date.

What are the attributes for the PROJECT entity?

Blackwater Consulting
Requirements Analysis
Each project is assigned a project id. In addition, we store the project title, start date,
and end date.

What are the attributes for the PROJECT entity?

Mandatory (Required) Attributes
An attribute that must contain a value
The value is mandatory or required
Cannot be NULL
Appears as bold in the entity rectangle

Example:
An EMPLOYEE entity must require a value for the employee id, first name and last
name attributes
Mandatory (Required) Attributes
Appears as bold in the entity rectangle
Optional Attributes
Attribute that may not have a value or is NULL (unknown)
Example:
An EMPLOYEE entity might contain an optional mobile number
Appears in normal font in the entity
Multivalued Attributes
An attribute that can have more than one value
A customer may have more than 1 contact number (home, mobile, office)
An EMPLOYEE may have more than one dependent

Consider later
Volatile and Derived Attributes
A volatile attribute contains a value that constantly changes over time:
length_of_membership
years_of_service
age
Would have to be updated constantly
Volatile and Derived Attributes
A derived attribute
Contains a value that can be calculated from existing attributes
Not stored in the database, but computed when required
length_of_membership can be calculated using the current date and
membership_date attribute
years_of_service can be calculated using current date and hire_date attribute
Age can be calculated using the current date and birth date
Nonvolatile Attributes
Attributes that rarely change
Examples:
Order date
Birth date
Hire date

Select nonvolatile attributes. For example, use birth date instead of age
Step 2: Define Attributes for
Blackwater Consulting
Attributes are listed under the entity name in lower case
Mandatory attributes in bold
Optional attributes in normal font
Words are joined with an underline
Unique Identifier (UID) /
Primary Key (PK)
Every entity must have a unique identifier or primary key
Referred to as primary key in relational (physical) model and database
Unique Identifier (UID) /
Primary Key (PK)
A single attribute or a combination of attributes
Must be unique – Uniquely identifies one and only one instance of an entity
A unique identifier value should never change
Must contain a value – cannot be NULL
There should be no practical limit to the number of unique identifier values available
Only one unique identifier should be specified for each entity. Remember, an UID can
be one or more attributes
Candidate Keys
Attributes that qualify as UIDs/Primary Keys (PK)
Each candidate key must meet the following criteria:
Same rules as unique identifier
Values must be unique for each instance within the entity
Cannot contain a NULL value
Determine Candidate Keys
Which attributes qualify as candidate keys?
Candidate Keys
Candidate keys identified by red rectangle
Step 3: Assign Unique Identifiers (UIDs)/
Primary Key (PK)
Listed as the first attribute in the box as PK (primary key)
Must contain a unique value
Is required and thus specified in bold
Underline
Step 4: Assign Unique Keys (UK)
All candidate keys not selected as UID/PK
Identified by UK
Can contain a NULL value; thus can be an optional attribute
diagrams.net for Data Modeling
Library Example
•Identify entities Let's expand our library system to include more
relevant entities:
•Book
•Author
•Borrower (library member)
•Library Branch
•Loan
Library Example
•Identify attributes For each entity, we'll list relevant attributes:

•Book: •Borrower:
•ISBN •Member ID
•Title •First Name
•Publication Year •Last Name
•Number of Pages •Email •Loan:
•Genre •Phone Number •Loan ID
•Current Status (available, borrowed, etc.) •Address •Borrow Date
•Membership Start Date •Due Date
•Author: •Return Date
•Author ID •Library Branch:
•First Name •Branch ID
•Last Name •Branch Name
•Birth Date •Address
•Nationality •Phone Number
Library Example
•Identify attributes For each entity, we'll list relevant attributes:

•Book: •Borrower:
•ISBN •Member ID
•Title •First Name
•Publication Year •Last Name
•Number of Pages •Email •Loan:
•Genre •Phone Number •Loan ID
•Current Status (available, borrowed, etc.) •Address •Borrow Date
•Membership Start Date •Due Date
•Author: •Return Date
•Author ID •Library Branch:
•First Name •Branch ID
•Last Name •Branch Name
•Birth Date •Address
•Nationality •Phone Number
Library Example
•Assign unique identifiers (UID) / primary key (PK) For each entity,
we'll choose a primary key:

•Book: ISBN (as it's already a unique identifier for books)

•Author: Author ID
•Borrower: Member ID
•Library Branch: Branch ID
•Loan: Loan ID
Library Example
•Identify unique keys In addition to primary keys, we'll identify other attributes or combinations of attributes
that could uniquely identify each entity:

•Book: ISBN (primary key)

•Author: Author ID (primary key)

•Borrower: Member ID (primary key)

•Email (assuming each member has a unique email address)

•Library Branch: Branch ID (primary key)

•Branch Name (assuming each branch has a unique name)

•Loan: Loan ID (primary key)