Data Modeling Using the Entity-Relationship Model

• Outline
– Using High-Level Conceptual Data Models for
Database Design
– Entity Types, Entity Sets, Attributes, and Keys
– Relationships, Relationship Types, Roles, and Structural
Constraints
– Weak Entity Types
– Refining the ER Design for the COMPANY Database
– ER Diagrams, Naming Conventions, and Design Issues

1
Phases of Database Design (Simplified)

User-defined operations
(transactions) •Entity t types
Data flow diagrams
•Relationships
•constraints

2
 Using High-Level Conceptual Data Models for Database Design

• The first step shown in the previous diagram is

requirements collection and analysis.
• During this step, the database designers interview
prospective database users to understand and
document their data requirements
• The result of this step is a concisely written set of users’
requirements
• These requirements should be specified in as detailed
and complete a form as possible
• In parallel with specifying the data requirements, it is
useful to specify the known functional requirements of
the application
• These consist of the user-defined operations (or
transactions) that will be applied to the database, and
they include both retrievals and updates.

3
 Database Design
(cont…)
• Once all the requirements have been collected and analyzed, the
next step is to create a conceptual schema for the database
• The conceptual schema is a concise description of the data
requirements of the users and includes detailed descriptions of the
entity types relationships and constraints
• These are expressed using the concepts provided by the high-level
data model
• Because these concepts do not include implementation details, they
are usually easier to understand and can be used to communicate
with non-technical users
• The high-level conceptual schema can also be used as a reference
to ensure that all users’ data requirements are met and that the
requirements do not include conflicts

4
 Database Design
(cont…)

• The next step in database design is the actual

implementation of the database, using a commercial
DBMS
• Most current commercial DBMSs use an implementation
data model—such as the relational or the object
database mode
• So the conceptual schema is transformed from the high-
level data model into the implementation data model.
• This step is called logical design or data model
mapping, and its result is a database schema in the
implementation data model of the DBMS

5
 Physical design

• At this stage, the internal storage structures,

access paths, and file organizations for the
database files are specified
• In parallel with these activities, application
programs are designed and implemented as
database transactions corresponding to the
high-level transaction specifications

6
 An example Application

• For this discussion, we will describe an example

database application, called COMPANY, which serves to
illustrate the ER model concepts and their use in schema
design.
• The COMPANY Database keeps track of Employees,
Departments, and Projects. After the requirement
collection and analysis the database should keep the
following information:
• The company is organized into departments.
• Each department has a unique name, a unique number,
and a particular employee who manages the
department.

7
 Example (cont…)

• A department controls a number of projects,

each of which has a unique name, a unique
number, and a single location
• We keep track of the start date when that employee
began managing the department
• We store
A department may have several locations
each employee’s name, social security
number , address, salary, sex, and birth date

8
 Example (cont…)

• 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 number of hours per week that
an employee works on each project
• We also keep track of the direct supervisor of each
employee
• We want to keep track of the dependents of each
employee for insurance purposes
• We keep each dependent’s first name, sex, birth
date, and relationship to the employee
•

9
ER Diagram for the company database

10
Entity Types, Entity Sets, Attributes, and Keys

The ER model describes data as entities, relationships

and attribute
Entities and Attributes
Entities and Their Attributes

The basic object that the ER model represents is an

entity, which is a "thing" in the real world with an
independent existence.
An entity may be an object with :
A physical existence: a person, a car , a house
A Conceptual existence : a company, a job
11
 •Attributes—the particular properties that describe an
entity.
•For example, an employee entity may be described by
the employee’s name, age, address, salary, and job.
•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.

12
 Two entities and their attribute values

employee department

13
 Types of Attributes
i) Composite Versus Simple (Atomic) Attributes
Composite attributes can be divided into smaller subparts,
which represent more basic attributes with independent
meanings.
•For example Address can be subdivided into ( city,state,
StreetAddress, State, and Zip).
Attributes that are not divisible are called simple or atomic
attributes.
Composite attributes can form a hierarchy; for example,
StreetAddress can be subdivided into three simple attributes,
Number, Street, and ApartmentNumber.

14
 ii) Single-valued Versus Multivalued
Attributes
Single- valued : Attrubutes which has a single
value. Eg. Age of a person
Multivaued: attribute which has two or more
value. Eg. Color of a car, CollegeDegree etc
A multivalued attribute may have lower and
upper bounds on the number of values allowed
for each individual entity.
For example the college degree may be
Bachelor, Master and PhD. 15
iii) Stored Versus Derived Attributes
• In some cases two (or more) attribute values are related—for
example, the Age and BirthDate attributes of a person.
• 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 BirthDate.
• Therefore, the Age attribute is hence called a derived attribute
and is said to be derivable from the BirthDate attribute, which
is called a stored attribute.
• Some attribute values can be derived from related entities; for
example, an attribute NumberOfEmployees of a department
entity can be derived by counting the number of employees
related to (working for) that department.

16
iv) Null Values

• A particular entity may have no applicable value for an attribute.

• For example an attribute CollegeDegree is applicable only for persons who
goes to College . For those who do not go to college, the value for
CollegeDegree will be Null.
• In addition, Null value is used when we do not know the value of the
attribute for the particular entity (eg the home phone number of the employee).
• The unknown category of null further classified into two:
• the value exists but missing e.g. the height attribute of a person
• Not known whether the attribute value exists e.g. homephone
attribute of a person

17
v) Complex Attributes

• Notice that composite and multivalued attributes can be

nested in an arbitrary way. We can represent arbitrary
nesting by grouping components of a composite attribute
between parentheses ( ) and separating the components with
commas,
• and by displaying multivalued attributes between braces {}.
Such attributes are called complex attributes.
• For example, if a person can have more than one residence
and each residence can have multiple phones, an attribute
AddressPhone for a PERSON entity type can be specified as
shown below.
• {AddressPhone({Phone(AreaCode, PhoneNumber)},
Address(StreetAddress(Number, Street, ApartmentNumber),
City, State, Zip))}
( ): composite attribute
• { }: multivalued attribute
•

18
 3.3.2 Entity Types, Entity Sets, Keys, and Value Sets

Entity Types and Entity Sets

An entity type defines a collection (or set) of entities that have
the same attributes.
Each entity type in the database is described by its name and
attributes.
Example Employee, Department, Person, etc
Entity set is 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.
An entity type is represented in ER diagrams as a rectangular
box enclosing the entity type name . 19
Two entity types and some of the member entities of each

20
• Attribute names are enclosed in ovals and are
attached to their entity type by straight lines
• Composite attributes are attached to their
component attributes by straight lines
• Multivalued attributes are displayed in double
ovals.
• An entity type describes the schema or intension
for a set of entities that share the same structure
• The collection of entities of a particular entity type
are grouped into an entity set, which is also called
the extension of the entity type

21
 Key Attributes of an Entity Type

•An attribute whose values are distinct for each individual

entity in the collection is called a Key attribute.
•Its value is used to identify each entity uniquely. For example
StudentID uniquely identifies each student so StudentID is a
key for the Student entity.
•Composite Key is a key made of two or more attributes
which can identify an entity uniquely. For example Title, year
and StarName can be key for movie entity which can identify
uniquely one movie from the other. Key attribute is underlined in
the ER diagram
•Specifying that an attribute is a key of an entity type means that the
preceding uniqueness property must hold for every extension of the entity
type
22
CAR entity type
Component of composite multivalued attribute
attribute

Registration key attribute

VehicleID attribute

Uniqueness property must hold for every extension of the entity set
23
 Fname Minit Lname Number

Name Name
Locations
Sex
NumberOf
SSN Address Employee
Department
Salary
Bdate EMPLOYEE
singled

multiple-valued

Entity type
key attribute

derived attribute
24
 Value Sets (Domains) of Attributes

• Each simple attribute of an entity type is associated with

a value set (or domain of values), which specifies the
set of values that may be assigned to that attribute for
each individual entity.
– For example the value of age attribute for a college
student is between 17 to 30, so the value should be
fixed on this range.
– Each simple attribute of an entity type is associated
with a value set (or domain of values), which
specifies the set of values that may be assigned to
that attribute for each individual entity.

25
 Initial Conceptual Design of the
COMPANY Database
• After defining several entities and attributes we can
redesign our Company database as follows. The
requirement which is refined is given below:
 An entity type DEPARTMENT with attributes Name,
Number, Locations, Manager, and ManagerStartDate.
Locations is the only multivalued attribute.
 We can specify that both Name and Number are
(separate) key attributes, because each was specified
to be unique.
 An entity type PROJECT with attributes Name, Number,
Location, and ControllingDepartment.

26
 Initial conceptual design

 Both Name and Number are (separate) key attributes

 An entity type EMPLOYEE with attributes Name, SSN
(for social security number), Sex, Address, Salary,
BirthDate, Department, and Supervisor.
 Both Name and Address may be composite attributes;
however, this was not specified in the requirements
 We must go back to the users to see if any of them will
refer to the individual components of Name—FirstName,
MiddleInitial, LastName—or of Address.
 An entity type DEPENDENT with attributes
DependentName, Sex, BirthDate, and Relationship (to
the employee)

27
key attribute

key attribute

{ …. } : multivalued attribute
( ) : component of a composite attribute
28
 Relationships, Relationship Types, Roles, and
Structural Constraints

• A relationship type R among n entity types E1,E2 , . . .

En, defines a set of associations
• As for entity types and entity sets, a relationship type
and its corresponding relationship set are customarily
referred to by the same name R.
• Each of the entity types E1 ,E2 , . . .,En is said to
participate in the relationship type R, and similarly each
of the individual entities e1 ,e2 , . . ., en is said to
participate in the relationship instance ri =
( e1,e2 , . . .,en ).

29
Some instances of the WORKS_FOR relationship
many-to-one

30
 Relationship Degree, Role Names, and
Recursive Relationships

DEPARTMENT -The degree of a relationship type is the number of

participating entity types.
Both MANAGES and WORKS_ON
are binary relationships.
unary relationship: degree 1
WORKS_FOR MANAGES
More than one relationship type can exist with the same
participation entity types; for example, MANAGES and
WORKS_FOR are distinct relationships between
EMPLYEE and DEPARTMENT participate.
(ternary relationship: degree 3)
EMPLOYEE

31
The ternary relationship SUPPLY
S supplies part P to project J

32
 Relationships as Attributes

• It is sometimes convenient to think of a relationship type in terms of attributes

• Consider the WORKS_FOR relationship in the previous slide

• One can think of an attribute called Department of the EMPLOYEE entity type

whose value for each employee entity is (a reference to) the department entity

that the employee works for

• Hence, the value set for this Department attribute is the set of all

DEPARTMENT entities.

•This is what we did in when we specified the initial design of the entity type

EMPLOYEE for the COMPANY database.

33
• However, when we think of a binary relationship as an attribute, we
always have two options.
• In this example, the alternative is to think of a multivalued attribute
Employees of the entity type DEPARTMENT whose values for each
department entity is the set of employee entities who work for that
department.
• The value set of this Employees attribute is the EMPLOYEE entity
set.
• Either of these two attributes—Department of EMPLOYEE or
Employees of DEPARTMENT—can represent the WORKS_FOR
relationship type.
• If both are represented, they are constrained to be inverses of each
other

34
• Each entity type that participates in a relationship type
plays a particular role in the relationship.
• The role name signifies the role that a participating
entity from the entity type plays in each relationship
instance, and helps to explain what the relationship
means.

35
 Role Names and Recursive Relationships

• Employee plays a role of Employee/ worker

• Department plays a role of Department/employer
• In some cases the same entity type participates more
than once in a relationship type in different roles.
• Such relationship type is called Recursive relationships
• In supervision relationship, employee plays two roles:
supervisee and supervisor

36
 e5

The lines marked "1" represent the supervisor role, and

e1 e4 those marked "2" represent the supervisee role; hence,
e1 supervises e2 and e3; e4 supervises e6 and e7; and
e5 supervises e1 and e4
e2 e3 e6 e7 37
 Constrains on Relationship Types
•Cardinality ratio and Participation (total and partial)
Cardinality Ration for Binary Relationships

•The cardinality ratio for a binary relationship specifies the number of

relationship instances that an entity can participate in
•For example, in the WORKS_FOR binary relationship type:
DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N, meaning that each
department can be related to (that is, employs) numerous employees ( but
an employee can be related to (work for) only one department.
The possible cardinality ratios for binary relationship types are
1:1, One- to-One
1:N, One-to- Many
N:1, Many- to-One
M:N, Many-to-Many
Cardinality ratios for binary relationships are displayed on ER diagrams by
displaying 1, M, and N on the diamonds (relationships)
38
MANAGES one-to-one 1:1 relationship
Partial participation of EMPLOYEE
Total participation of DEPARTMENT

One-to one 1:1 Relationship

39
WORK_ON M:N relationship

40
 Participation Constraints and Existence Dependencies

The participation constraint specifies whether the existence of an entity

depends on its being related to another entity via the relationship type.

Two types: Total and Partial Participation

Total Participation if every entity in E participates in at least one relationship

in R. E.g. Employee entity in Works for relationship has a total participation
to the Department entity

Partial Participation: if only some entities in E participate in relationships in R,

the participation of entity set E in relationship R.

E.g. Employee entity in Manages relationship has a partial participation to

Department entity since Every employee can not be a manager.

In ER diagrams, total participation is displayed as a double line connecting

the participating entity type to the relationship, whereas partial participation
is represented by a single line. 41
 Attributes of Relationship Types

-Relationship types can also have attributes, similar to

those of entity types. For example, to record the number
of hours per week that an employee works on a particular
project, we can include an attribute Hours for the
WORKS_ON relationship type

EMPLOYEE WORKS_ON PROJECT

HOUR

42
- For a 1:1 relationship type, a relationship attribute can be
migrated to either participating entity types.

StartDate

1 1
EMPLOYEE MANAGES DEPARTMENT

- For a 1:N relationship type, a relationship attribute can

be migrated only to the entity type at the N side.

StartDate

N 1
EMPLOYEE WORKS_FOR DEPARTMENT

43
-For M:N relationship types, some attributes may be
determined by the combination of participating entities.
must be specified as relationship attributes
HOURS

M N
EMPLOYEE WORKS_ON PROJECT

44
Weak Entity Types (vs. Strong Entity types)

- An entity type that does not have a key attribute

- A weak entity type must participate in an identifying
relationship type with an owner or identifying
entity type.
- Entities are identified by the combination of :

 A partial key of the weak entity type

is a set of attributes can uniquely identify weak
entities that are related to the same owner
entity
 The particular entity they are related to in the
identifying entity type

45
Example:
Suppose that a DEPENDENT entity is identified by the
dependent’s first name and birthdate, and the specific
EMPLOYEE that the dependent is related to.
DEPENDENT is a weak entity type with EMPLOYEE as its
identifying entity type via the identifying relationship type
DEPENDENT_OF.
A weak entity type always has a total participation
constraint (existence dependency) with respect to its
identifying relationship.

46
Summary of ER diagram notation

for each entity e in E, e must

participate in at least min and
at most max relationship
instances in R at all times.
47
 Proper Naming of Schema Constructs
Entity type :
a singular names
Names are in uppercase and are nouns
Relationship type :
a singular names
names are in uppercase and are verbs
Attributes:
names are Capitilized
names are nouns which describes the
entity type
Role names are in lowercase

48
ER diagram for the COMPANY Scheme

Proper Naming of Schema Constructs

49