Data Modeling:
EntityRelationship
Diagram
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Outline
▪ Using high-level conceptual data models for
Database Design
▪ A Sample Database Application
▪ Entity Types, Entity Sets, Attributes, and Keys
▪ Relationship Types, Relationship Sets, Roles,
and Structural Constraints
▪ Weak Entity Types
▪ ER Diagrams, Naming Conventions, and Design
Issues
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Introduction
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Conceptual Data Modeling
▪ Conceptual data modelling is a very important
phase in designing a successful database
application.
▪ The conceptual data modeling:
▪
▪
▪
Sketches out the entities to be represented
Determines what kinds of relationships exist between
them.
Defines the general rules that need to be considered.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Conceptual Data Modeling Using the
Entity-Relationship (ER) Model
▪ Entity-Relationship (ER) model
▪
Popular high-level conceptual data model
▪ ER diagrams (ERD)
▪
Diagrammatic notation associated with the ER
model
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Conceptual Data Modeling Using the
Entity-Relationship (ER) Model
▪ The database design process consists of 4 steps:
1) Requirements collection and analysis
▪ Database designers interview prospective database
users to understand and document data
requirements
▪ The result of this step:
• Data requirements.
• Functional requirements of the application
(transactions that will be applied to the database,
e.g. retrievals and updates).
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Conceptual Data Modeling Using the
Entity-Relationship (ER) Model
2) Conceptual design
▪
Creating conceptual schema for the
database, using a high-level conceptual data
model (ERD).
▪ Conceptual schema is a description of data
requirements of the users and Includes
detailed descriptions of the entity types,
relationships, and constraints.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Conceptual Data Modeling Using the
Entity-Relationship (ER) Model
3) Logical design or data model mapping
▪
▪
It is the actual implementation of the database,
using a DBMS.
Its result is a database schema in implementation
data model of DBMS
4) Physical design phase
▪ During this phase internal storage structures,
file organizations, indexes, access paths, and
physical design parameters for the database
files are specified
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
A Sample Database Application
▪ COMPANY
▪
The COMPANY database keeps track of a company’s
employees, departments, and projects.
▪
Company is organized into departments Each department
has a unique name, a unique number, and a particular
employee who manages the department which must have a
manager at all times. We keep track of the start date when
that employee began managing the department. A
department may have several locations.
▪
A department controls a number of projects, each of which
has a unique name, a unique number, and a single
location.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
A Sample Database Application
▪ COMPANY
▪
We store each employee’s name, Social Security
number,2 address, salary, gender, and birth date. An
employee is assigned to one department, but may work on
several projects, which are not necessarily controlled by
the same department. We keep track of the current
number of hours per week that an employee works on
each project. We also keep track of the direct supervisor
of each employee (who is another employee).
▪
We want to keep track of the dependents of each employee
for insurance purposes. We keep each dependent’s first
name, gender, birth date, and relationship to the
employee.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Entity-Relationship Diagram (ERD)
▪ ER model describes data as:
▪
Entities
▪ Attributes
▪ Relationships
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Entities
▪ Entity
▪ Thing in real world with independent
existence.
• Physical existence: person, car, house, or
employee
• Conceptual existence: job, university
course.
• In ERD entities are shown in rectangular
boxes.
EMPLOYEE
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Attributes
▪ Attributes
▪ Particular properties that describe entity
▪ In ERD Attributes are shown in ovals, and each
attribute is attached by a straight line to its entity type or
relationship type.
Salary
▪
Types of attributes:
• Composite versus simple (atomic) attributes
• Single-valued versus multivalued attributes
• Stored versus derived attributes
• NULL values
• Complex attributes
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Attributes (cont’d.)
▪ Composite versus simple (atomic) attributes
▪ Composite attributes: can be divided into smaller
subparts. For example, the Name attribute of the
EMPLOYEE entity can be subdivided into Fname, Mname
and Lname.
▪ In ERD component attributes of a composite attribute
are attached to the oval representing the composite attribute
Fname
Mname
Lname
Name
▪ Simple or atomic attributes: Attributes that are not
divisible.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Attributes (cont’d.)
▪ Single-valued versus Multivalued attributes
▪ Most attributes have a single value for a
particular entity; such attributes are called
single-valued. Example age of a person.
▪ In some cases, an attribute can have a set of
values for the same entity, such attributes are
called multivalued. Example phone number
attribute.
▪ In ERD Multivalued attributes are shown in
double ovals.
Location
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Attributes (cont’d.)
▪ Stored versus Derived attributes
▪ Derived attributes: its values can be derived
from related entities (stored attributes).
▪ Example For a particular person entity, the
value of Age can be determined from the
current (today’s) date and the value of that
person’s Birth_date.
▪ In ERD Derived attributes are shown in
dotted ovals.
Age
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Attributes (cont’d.)
▪ Complex attribute
▪ The nesting of two or more composite and
multi-valued attributes. Therefore, these
multi-valued and composite attributes are
called 'Components' of complex attributes
▪ For example, if a person can have more than
one residence and each residence can have a
single address and multiple phones.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Attributes (cont’d.)
▪ NULL values
▪
A particular entity will have a value for each of its
attributes. The attribute values that describe each
entity become a major part of the data stored in the
database.
▪ In some cases, a particular entity may not have an
applicable value for an attribute.
▪ NULL can also be used if we do not know the value of
an attribute for a particular entity.
▪ The unknown category of NULL can be further
classified into two cases:
- It is known that the attribute value exists but is
missing.
- it is not known whether the attribute value exists.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Entities and Attributes (cont’d.)
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Entity Types and Entity Sets
▪ Entity type
▪
▪
Collection (or set) of entities that have the same attributes.
▪
Each entity type is described by its name and attributes.
Entity set: the collection of all entities of a particular entity
type in the database at any point in time. The entity set is
usually referred to using the same name as the entity type.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Key Attribute, and Value Sets
▪ Key or uniqueness constraint
▪
Attributes whose values are unique for each
individual entity in entity set.
▪ Key attribute
• Uniqueness property must hold for every entity set
of the entity type.
• In ERD, each key attribute has its name underlined
inside the oval.
Number
▪ Value sets (or domain of values)
▪
Specifies set of values that may be assigned to
that attribute for each individual entity
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Relationship
▪ Relationship
▪
▪
▪
When an attribute of one entity type refers to another
entity type.
For example, the attribute Manager of DEPARTMENT
entity refers to an employee who manages the
department.
References should not be represented as attributes but
as relationship.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Relationship Types, Sets, and Instances
▪ Relationship type R among n entity types E1, E2, ...,
En
▪ Defines a set of associations among entities from
these entity types.
▪ In ERD Relationship types are shown in diamondshaped boxes attached to the participating entity
types with straight lines.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Relationship Types, Sets, and Instances
▪ Relationship instances ri
▪ Each ri associates n individual entities (e1, e2, ...,
en)
▪ Each entity ej in ri is a member of entity set Ej
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Relationship Degree
▪ Degree of a relationship type
▪
Number of participating entity types
▪ Types: Binary, ternary
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Role Names and Recursive Relationships
▪ Role names
▪
Role name signifies role that a participating
entity plays in each relationship instance.
▪ Role names are not technically necessary in
relationship types where all the participating
entity types are distinct.
▪ Recursive relationships
▪
Same entity type participates more than once
in a relationship type in different roles.
▪ Must specify role name
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
The SUPERVISION relationship type relates an employee to a
supervisor, where both employee and supervisor entities are members of
the same EMPLOYEE entity set. Hence, the EMPLOYEE entity type
participates twice in SUPERVISION: once in the role of supervisor (or
boss), and once in the role of supervisee (or subordinate).
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Constraints on Binary Relationship Types
▪ Cardinality ratio for a binary relationship
▪
▪
Specifies maximum number of relationship instances
that entity can participate in
Types : 1:1, 1:N, N:1, and M:N.
One to One 1:1
One to Many 1:N
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Many to One N:1 Many to Many M:N
Constraints on Binary Relationship Types
▪ Cardinality ratio for a binary relationships are the
cardinality ratio of each binary relationship type is
specified by attaching a 1, M, or N on each participating
edge.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Constraints on Binary Relationship Types
▪ One to One 1:1 Example: MANAGES relationship which
relates a department entity to the employee who manages that
department. This represents the miniworld constraints that—at
any point in time—an employee can manage one department
only and a department can have one manager only.
▪ One to Many 1:N Example: WORKS_FOR relationship,
DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N, meaning
that each department can be related to (that is, employs) any
number of employees, but an employee can be related to
(work for) only one department.
▪ Many to Many Example: WORKS_ON relationship is M:N
because the miniworld rule is that an employee can work on
several projects and a project can have several employees.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Constraints on Binary Relationship Types
▪ Participation constraint
▪
▪
▪
▪
Specifies whether existence of entity depends on its
being related to another entity
Types: total and partial
Total participation: (indicated by double line) every
entity in the entity set participates in at least one
relationship in the relationship set.
Partial participation: some entities may not
participate in any relationship in the relationship set.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Constraints on Binary Relationship Types
▪
Total Participation Example: EMPLOYEE in
WORKS_FOR relationship meaning that every entity
in the total set of employee entities must be related to
a department entity via WORKS_FOR.
▪
Partial Participation Example: EMPLOYEE in the
MANAGES relationship meaning that some or part of
the set of employee entities are related to some
department entity via MANAGES, but not necessarily
all.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Attributes of Relationship Types
▪ Attributes of 1:1 or 1:N relationship
types can be migrated to one of the
participating entity type.
▪ For a 1:N relationship type
▪
Relationship attribute can be migrated only to
entity type on N-side of relationship
▪ For M:N relationship types
▪
Some attributes may be determined by
combination of participating entities
▪ Must be specified as relationship attributes
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Weak Entity Types
▪ Do not have key attributes of their own
▪ Identified by being related to specific entities
from another entity type
▪ Identifying relationship
▪ Relates a weak entity type to its owner
▪ Always has a total participation constraint
▪ In ERD both a weak entity type and its identifying
relationship are distinguished by surrounding their
boxes and diamonds with double lines.
Weak Entity
Identifying Relationship
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Weak Entity Types (cont’d.)
▪ Example
▪
DEPENDENT entity, related to EMPLOYEE. The
attributes of DEPENDENT are Name (the first name
of the dependent), Birth_date, Gender, and
Relationship (to the employee).
▪ Two dependents of two distinct employees may, by
chance, have the same values for Name, Birth_date,
Sex, and Relationship, but they are still distinct
entities.
▪ They are identified as distinct entities only after
determining the particular employee entity to which
each dependent is related. Each employee entity is
said to own the dependent entities that are related to it.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Weak Entity Types (cont’d.)
▪
▪
A weak entity type normally has a partial key, which
is the attribute that can uniquely identify weak entities
that are related to the same owner entity.
In our example, if we assume that no two
dependents of the same employee ever have the
same first name, the attribute Name of
DEPENDENT is the partial key
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Summary of the notation for ER diagrams.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Proper Naming of Schema Constructs
▪ Choose names that convey meanings
attached to different constructs in schema.
▪ 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.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe
Design Choices for ER Conceptual Design
▪ Model concept first as an attribute
▪
Refined into a relationship if an attribute is a
reference to another entity type
▪ Attribute that exists in several entity types
may be elevated to an independent entity
type
▪
Can also be applied in the inverse
▪ Specify structural constraints on relationships
▪ Replaces cardinality ratio (1:1, 1:N, M:N) and
single/double line notation for participation
constraints.
Copyright © 2011 Ramez Elmasri and Shamkant Navathe