Chapter 3: Data Modeling Using The Entity-Relationship Model

Chapter 3: Data modeling using the Entity-Relationship Model
Outline:
٣.١ Design Phases.
Phase 1: Requirements collection and analysis.
Phase 2: Conceptual Design.
Phase 3: Logical design (data model mapping).
Phase 4: Physical design.
٣.٢ The Entity-Relationship (ER) Model.

Entity Types, Entity Sets, Attributes, and Keys.
Null Values.
Relationship.
The degree of a relationship type.
٣.٣ Structural Constraints on relationship.

Cardinality ratio.
Participation Constraints.
Alternative (min, max) notation for relationship structural constraints.
٣.٤ Weak Entity Types.
٣.٥ An Example of Database Application (COMPANY Database).
Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009
1
3.1 Design Phases
Phase 1: Requirements collection and analysis
• Interview prospective database users to understand and document their data requirements
• The result of this phase is concisely written set of users’ requirements and functional
requirements of the application; consist of the user defined operations (or transactions) that will
be applied to the database, and they include both retrievals and updates).
Phase 2: Conceptual Design
• Conceptual schema for the database, using High-Level Conceptual Data Model (entity types,
relationships, and constraints).Because these concepts do not include implementation details,
they are usually easier to understand and can used to communicate with no 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.
• The result is Conceptual Schema in high level model
Phase 3: Logical design (data model mapping)

• The actual implementation of a database, using a commercial DBMS; transformation of
conceptual schema from the high level data model into implementation data model.
• The result is Database schema in the implementation data model of the DBMS.
Phase 4: Physical design
• The internal storage structures, access paths, and file organizations for the database files are
specified.
2
Mini-World
Phase1: Requirements Collection and Analysis

phase
Database Requirements
Phase2: Conceptual Design
DBMS-independent
Conceptual Data Model
DBMS-specific
Phase3: Logical Design
Logical Data Model
Phase4: Physical Design
Figure 3.1: Design Phases
3
3.2 The Entity-Relationship (ER) Model
Used for conceptual database design
Relies on concepts of entities, attributes, and relationships
Entity Types, Entity Sets, Attributes, and Keys
Entity: An entity is a "thing" (a being, an object, an event) in the real world and is
distinguishable from other objects (things).
Figure 3.2: Entities Examples
Entity types represent sets of objects and are pictured by rectangular nodes
Entity Type
Characteristic of Entity:
• Existence: It may have a physical existence (also called concrete) (for example, car,
house, or an employee) in the real world or it may be an object with a conceptual
existence (abstract). (for example, a job, or a university course).
• Described by its attributes (set of properties); for example an EMPLOYEE entity may
have a Name, SSN, Address, Sex, BirthDate.
• Determined by particular value of its attributes; a specific entity will have a value for
each of its attributes(domain);
Example: a specific book entity will have title= “Database System Concepts”,
pages=821, ISBN= 0-07-044756-X
Example: A person name= “Mohammed”, age=21, add=salt
• Domain: the set of permitted values for each attribute
4
• Entity sets do not need to be disjoint. For example, it is possible to define the entity
set of all employees of a bank (employee) and the entity set of all customers of the bank
(customer). A person entity may be an employee entity, a customer entity, both, or
neither.
• An entity type defines a collection (or set) of entities that have the same attribute (for
example, employee entity type and company entity type). An entity is an instance of an
entity type. All entities having the same set of properties are grouped into an entity type.
• An entity set is the collection of all entities of a particular entity type in the database at
any point in time
Figure 3.3: Entity sets Example
• An entity set is also called an extension of the entity type.
Types of Attributes
Entity types and relationship types might have attributes.
Several types of attributes occur in the ER model (simple Vs. composite, single-valued Vs.
multivalued, Stored Vs. Derived Attribute, complex Attribute, and key Attribute)
١. Atomic attribute types (Simple)
o Each entity has a single atomic value for the attribute; for example SSN or Gender.
o Pictured by oval nodes
Simple Attribute
٢. Composite attribute types
5
o Achieved by concatenating simpler attribute types. The attribute may be composed of
several components; for example Address (Street, City, State, and Postal Code) or
Name (First Name, Middle Name, and Last Name).
Figure 3.4: Composite Attribute Examples
o Composite Attribute Pictured by trees of atomic attributes
A Composite
Attribute
o Composition may form a hierarchy where some components are themselves

composite; for example StreetAddress can be subdivided into three simple attributes,
Number, Street ,and ApartmentNumber, as shown in the following figure :
Figure 3.5: Hierarchy Composite Attribute Example
6
٣. Multivalued attribute types
o An entity may have multiple values for that attribute; for example Color of a CAR or
PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.
o Displayed in two nested ovals:
Multivalued Attribute
٤. Derived attribute types
o Some attribute values can be derived from related attributes or entities; for example
an attribute Age of employee entity can be determined from the current date and the
value of stored attribute (BirthDate).
o It displayed in dashed ovals
Derived Simple
Attribute
٥. Complex Attribute
o Composite and multi-valued attributes may be nested arbitrarily to any number of

levels although this is rare. For example, PreviousDegrees of a STUDENT is a
composite multi-valued attribute denoted by {PreviousDegrees(College, Year, Degree,
Field)}.
o example: {AddressPhone ( { Phone ( AreaCode, PhoneNumber ) }, Address (
StreetAddress ( Number, Name ), City, State, Zip ) ) }
Number Name
StreetAddress City
PhoneNumber AreaCode
State
Zip
Phone Address
AddressPhone
7
Figure 3.6: AddressPhone Complex Attribute
٦. Key Attribute (identifier)
o An attribute whose values are distinct for each individual entity in the collection. In
other words, an attribute of an entity type for which each entity must have a unique
value is called a key attribute of the entity type. For example SSN of EMPLOYEE.
o Displayed with underlined attribute type names
Key Attribute
o Key attribute may be composite. For example, VehicleRegistrationNumber is a key of

the CAR entity type with components (Number, State).
o An entity type may have more than one key. For example, the CAR entity type may
have two keys:
A. VehicleIdentificationNumber (popularly called VIN) and
B. VehicleTagNumber (Number, State), also known as license_plate
number.
o The following ER diagram for car:
OR
Figure 3.7: Car Entity Type.
Figure 3.8: Car Entity Set with three entities.

8
The following figure contains all of the above types of attributes:
Figure 3.9: Entity Type with all attributes types.
Null Values
There are two situations for null values:
o In some cases a particular entity may not have an applicable value for an attribute.
Example, the ApartmentNumber attribute of an address applies only to addresses that
are in apartment buildings and not to single-family homes.
o 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:
A. The first case arises when it is known that the attribute value is applicable, but
it is missing—for example, if the height attribute of a person is listed as null.
B. The second case arises when it is not known whether the attribute value
applicable —for example, if the HomePhone attribute of a person is null.
Example: Appartment-Number attribute:
o Not applicable: if the address does not include a apartment-number.
o Missing: an apartment-number exists but we do not know what it is.
9
o Unknown: we do not know whether or not an apartment-number is part of the
customer’s address
Relationship
A relationship is an association among at least two entities belonging to one or more entity
sets. For example, EMPLOYEE Sami works for IT DEPARTMENT.
An Employee Works for A Department
A Department has Many Employee
Figure 3.10: “Works for” Relationship set example.

Relationship types associate entity types. For example, the WORKS_FOR relationship type in
which EMPLOYEEs and DEPARTMENTs participate. They are pictured by Diamond nodes,
and edges connecting to the related entity types
Relationship
Type
Example:
Employee Works for Department
Figure 3.11: “Works for” Relationship set ER diagram.
10
Department
Personnel Department IT Department
Employee
Sara Ahmed Jamal Mazen

Hossam Sami
Abed Yanal Mona
Figure 3.12: Relationship set.
A relationship set is the collection of instances (i.e., relationships between objects) represented
by a relationship type.
Relationship type vs. relationship set

Relationship Type:
Is the schema description of a relationship
Identifies the relationship name and the participating entity types
Also identifies certain relationship constraints
Relationship Set:
The current set of relationship instances represented in the database
The current state of a relationship type
Relationship types may associate an entity type with itself. In such a case, the roles of the entity
types in the relationship type are listed on the edges, and the relationship is said to be recursive.
Pre-
requisite
Course
11
More than one relationship type can exist with the same participating entity types; for example
the WORKS_FOR relationship type in which EMPLOYEEs and DEPARTMENT participate,
or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate.
Works
for
Employee Department
Manage
Figure 3.13:
Example: We can have two binary relationship types associating the student and team types,
TeamMemberOf and LeaderOf. In the former case, a student entity is a member of a team
entity; in the later case, a student can be a leader of a team.
Member
of
Student Team
Leader
of
Figure 3.14:
A relationship type can have attributes called descriptive attributes:

o For example, HoursPerWeek of WORKS_ON
o Its value for each relationship instance describes the number of hours per week that an
EMPLOYEE works on a PROJECT.
o A value of HoursPerWeek depends on a particular (employee, project) combination
o Most relationship attributes are used with M:N relationships
12
Hours/week
Employee Works Project

on
Figure 3.15:
o Example:
Since
Employee Works Department

For
Figure 3.16:
What is the different between two the following figures?
Price
Pharmacy Sell Drug
Figure (1)
Price
Pharmacy Sell Drug
Figure2
The degree of a relationship type
It is the number of participating entity types.
13
١. Unary: related to another of the same entity type. Also called recursive relationships.
An Employee Supervise Many Employee (Supervisee)
An Employee Supervised by An Employee (Supervisor)
Supervise
Supervisor Supervisee
Employee
Figure 3.17: Unary Relationship type example.
٢. Binary: entities of two different types related to each other. (Two participating entities).
An Employee Works for A Department
Figure 3.18: Binary Relationship type example.
14
٣. Ternary: entities of three different types related to each other. (three participating
entities).
PartNo#
Part
Suppid Pname
Supplier Supply Project
Quantity
Figure 3.19: Ternary Relationship type example.
Figure 3.20: Ternary Relationship set example.
• Example:
Drug
Doctor Prescribe
Patient
Figure 3.21: “Prescribe” ternary relationship type.
15
٤. n-ary: entities of more than three different types related to each other.
3.3 Structural Constraints on relationship
Cardinality ratio (of a binary relationship)
Mapping cardinalities, or cardinality ratio, express the number of entities to which another
entity can be associated via a relationship set. (specifies maximum participation).
There are four types of cardinality: 1:1, 1:N, N:1, or M:N.
١. One-to-One (1:1) cardinality ratio, an entity in one set is associated with at most one entity
in another.
Figure 3.22: One-to-One relationship set.
16
For Example:
Department
Personnel Department IT Department
Employee
(Manager)
Abed Hossam
An Employee Manage A Department
A Department has A Manager (Employee)
The ER Diagram is:3.23: One-to-One relationship Example.

Figure
Employee Manage Department
Figure 3.24: One-to-One relationship ER diagram.
17
٢. One-to-many (1: N) cardinality ratio, an entity in the first set is associated with 0 or more
entities in the second set. However, those entities in the second set can be associated with
at most one entity in the first.
Figure 3.25: One-to-Many relationship set.
For Example:
A Department Controls Many Projects

TheAER
Project
Diagram is: Controlled by A Department
Project Controls Department
Figure 3.27: One-to-Many relationship ER diagram.
٣. Many-to-one (N: 1) cardinality ratio is just the reverse of the 1:N cardinality ratio. You
can think of whichever entity set you like as being the first set. Just specify the direction
18
that makes sense for your application, and then be consistent.
٤. Many-to-many (N:M) cardinality ratio, entities of either set may be associated with any
number of entities in the other.
Figure 3.28: Many-to-Many relationship set.
19
For Example:
Projects
Project (١) Project (٢)
Mona Hossam Mazen
Jamal Sami
Employee
An Employee Works on Many Projects
A Project Has Many Employee
Figure 3.29: Many-to-Many relationship set example.

The ER Diagram is:
20
Employee Work on Project
Figure 3.30: Many-to-Many relationship ER diagram.
Attributes of relationship types:

• The descriptive attribute of 1:1 or 1:N relationship type can be migrated to one of the
participating entity types:
In 1:1 relationship type, a descriptive attribute can be an attribute of either entity
type 1 or entity type 2.
In 1:N relationship type, a descriptive attribute can be migrated only to the entity
type at the N-side of the relationship.
• For N:M relationship type, some attribute must be specified as descriptive attribute.
• The cardinality ratio depends on the real-world situation.

• Example: there are two situation of the borrower relationship between customer and
loan:
If a loan can belong to only one customer, and a customer can have several
loans, then the relationship type from customer to loan is one-to-many.
If a loan can belong to several customers, the relationship type is many-to-many.
Participation Constraints (Existence Dependency Constraints)
Specifies minimum participation

Specifies whether the existence of an entity e ϵ entity type E depends on its being related to
another entity via the relationship type R.
The participation of an entity set E in a relationship set R is said to be:
١. Partial: if only some entities in E participate in relationships in R.

Each entity e ϵ E can participate in a relationship set.
Optional participation, not existence-dependent.
The minimum value is zero.
Shown by a single line.
٢. Total: if every entity in E participates in at least one relationship in R.

Each entity e ϵ E must participate in a relationship set.
mandatory participation, existence-dependent
• Example: if a company policy states that every employee must work for a
department, then an employee entity can exist only if it participates in a
works-for relationship instance.
21
The minimum value is one or more.
Every entity in E participates in at least one relationship in R
Shown by double line.
Employee Manage Department
Partial Total
Figure 3.31: Total/Partial ER diagram.
Alternative (min, max) notation for relationship structural constraints:
Specified on each participation of an entity type E in a relationship type R

Specifies that each entity e in E participates in at least min and at most max relationship
instances in R
(min1..max1) (min2..max2)
E1 R E2
Figure 3.32: Min..Max ER diagram.
Default (no constraint): min=0, max=n (signifying no limit).

Must have min≤max, min≥0, max ≥1
Derived from the knowledge of mini-world constraints
Examples: A department has exactly one manager and an employee can manage at most one
department.
o Specify (0..1) for participation of EMPLOYEE in MANAGES

o Specify (1..1) for participation of DEPARTMENT in MANAGES
Employee (0..1) Manage (1..1) Department
Figure 3.33: one-to-one relationship type example using Min..Max notation.
An employee can work for exactly one department but a department can have any number of
employees.
o Specify (1..1) for participation of EMPLOYEE in WORKS_FOR
o Specify (0..*) for participation of DEPARTMENT in WORKS_FOR
(1..1) (1..*)
22
Figure 3.34: many-to-one relationship type example using Min..Max notation.
3.4 Weak Entity Types

An entity type that does not have a key attribute.
It is pictured by
Weak Entity Type
A weak entity type must participate in an identifying relationship type with an owner or
identifying entity type.
Identifying relationship type is pictured by diamond with double lines.
Identifying
Relationship
Type
Entities are identified by the combination of:

o A partial key of the weak entity type .It is underlined with a dashed or dotted line.
Partial Key
o The particular entity they are related to in the identifying entity type
A weak entity type may have more than one identifying entity type and an identifying
relationship type of degree higher than two.
For example:
SSN Name
Employee Dependents Dependent

of
23
Figure 3.35: Weak entity Example.
o A DEPENDENT entity is identified by the dependent’s first name, and the specific
EMPLOYEE with whom the dependent is related.
• Name of DEPENDENT is the partial key
• DEPENDENT is a weak entity type
• EMPLOYEE is its identifying entity type via the identifying relationship type
DEPENDENT OF.
24
3.5 An Example of Database Application (COMPANY Database)
The database designers stated the following description of the “miniworld”—the part of the
company to be represented in the database:
١. The company is organized into departments. Each department has a unique name, a unique
number, and a particular employee who manages the department. 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.
٣. We store each employee’s name, social security number, address, salary, sex, 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 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.
25
Figure 3.36: The ER Diagram for the company DB.
26
Consider the following information about a university database:
Professors have an SSN, a name, a rank, and a research specialty.

Projects are identified by a project number, more than one sponsor name (e.g., NSF), a starting
date, an ending date, and a budget.
Graduate students have an SSN, a name, and a current degree program (e.g., M.S.or Ph.D.).
Each project is managed by one professor, each project is worked on by one or more professors
and each project is worked on by one or more graduate students.
When graduate students work on a project, a professor must supervise their work on the project.
Graduate students can work on multiple projects.
Departments have a department number, a department name, and a main office.
Departments have a professor (known as the chairman) who runs the department.
Professor works in one or more departments and for each department that they work in, a time
percentage is associated with their job.
Design and draw an ER diagram that captures the information about the University.
27

Chapter 3: Data Modeling Using The Entity-Relationship Model

Uploaded by

Copyright:

Available Formats

You might also like

Chapter 3: Data Modeling Using The Entity-Relationship Model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 3: Data Modeling Using The Entity-Relationship Model

Uploaded by

Copyright:

Available Formats

Chapter 3: Data modeling using the Entity-Relationship Model

٣.٢ The Entity-Relationship (ER) Model.

٣.٣ Structural Constraints on relationship.

٣.٤ Weak Entity Types.

٣.٥ An Example of Database Application (COMPANY Database).

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

Phase 2: Conceptual Design

Phase 3: Logical design (data model mapping)

Phase 4: Physical design

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

Phase1: Requirements Collection and Analysis

Phase2: Conceptual Design

Logical Data Model

Phase4: Physical Design

Figure 3.1: Design Phases

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

Entity Types, Entity Sets, Attributes, and Keys

Figure 3.2: Entities Examples

• Domain: the set of permitted values for each attribute

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

Figure 3.3: Entity sets Example

• An entity set is also called an extension of the entity type.

Entity types and relationship types might have attributes.

١. Atomic attribute types (Simple)

o Pictured by oval nodes

٢. Composite attribute types

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

Figure 3.4: Composite Attribute Examples

o Composite Attribute Pictured by trees of atomic attributes

o Composition may form a hierarchy where some components are themselves

Figure 3.5: Hierarchy Composite Attribute Example

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

o Displayed in two nested ovals:

٤. Derived attribute types

o It displayed in dashed ovals

o Composite and multi-valued attributes may be nested arbitrarily to any number of

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

٦. Key Attribute (identifier)

o Displayed with underlined attribute type names

o Key attribute may be composite. For example, VehicleRegistrationNumber is a key of

Figure 3.7: Car Entity Type.

Figure 3.8: Car Entity Set with three entities.

Figure 3.9: Entity Type with all attributes types.

There are two situations for null values:

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

An Employee Works for A Department

A Department has Many Employee

Figure 3.10: “Works for” Relationship set example.

Employee Works for Department

Figure 3.11: “Works for” Relationship set ER diagram.

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

Personnel Department IT Department

Sara Ahmed Jamal Mazen

Figure 3.12: Relationship set.

Relationship type vs. relationship set

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009

A relationship type can have attributes called descriptive attributes:

Prepared by: Sawsan Abu_TaleB and Randa Al_Dallah ©2009