Part2: Conceptual Modeling and Database Design

Chapter 3: Data modeling using the Entity-Relationship Model

Outline:
3.1 Design Phases.
 Phase 1: Requirements collection and analysis.
 Phase 2: Conceptual Design.
 Phase 3: Logical design (data model mapping).
 Phase 4: Physical design.

3.2 The Entity-Relationship (ER) Model.

 Entity Types, Entity Sets, Attributes, and Keys.
 Null Values.
 Relationship.
 The degree of a relationship type.

3.3 Structural Constraints on relationship.

 Cardinality ratio.
 Participation Constraints.
 Alternative (min, max) notation for relationship structural constraints.

3.4 Weak Entity Types.

3.5 An Example of Database Application (COMPANY Database).

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

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.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

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 1: Design Phases

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

3
3.2 The Entity-Relationship (ER) Model
 Used for conceptual database design
 ER Model describes data as:
o Entities
o Relationships
o Attributes

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 2: Entities Examples

 Entity types represent set (or collection) of entities that have the same attributes (for example,
employee entity type and company entity type). An entity is an instance of an entity type. The
Entity type is pictured by rectangular nodes
Entity Type

Figure 3: Two entity types, EMPLOYEE and COMPANY, and some member entities of each.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

4
  An entity set is the collection of all entities of a particular entity type in the database at
any point in time

Figure 4: Entity sets Example

 An entity set is also called an extension of the 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.

 An entity may have a set of zero or more attributes.

 Each attribute is drawn from some domain (such as integers) possibly augmented by
NULL (more about NULLs later).
 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

 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.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

5
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)

1. 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

2. Composite attribute types

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 5: Composite Attribute Examples

o Composite Attribute Pictured by trees of atomic attributes

A Composite

Attribute

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

6
 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 6: Hierarchy Composite Attribute Example

3. 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

4. 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
5. 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)}.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

7
 o example: {AddressPhone ( { Phone ( AreaCode, PhoneNumber ) }, Address (
StreetAddress ( Number, Name ), City, State, Zip ) ) }

Number Name

StreetAddress City

PhoneNumber AreaCode
State

Zip
Phone Address

AddressPhone

Figure 7: AddressPhone Complex Attribute

 A simple example of a person with attributes

o Child: Bob
o Child: Carol
o FN: Alice
o LN: Jone
o DOB: 1980-01-01
o Address.Number: 100
o Address.Street: Mercer
o Age: Current Date minus DOB specified in years

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

8
 6. 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:
 VehicleIdentificationNumber (popularly called VIN) and
 VehicleTagNumber (Number, State), also known as license_plate
number.
o The following ER diagram for car:

OR

Figure 8: Car Entity Type.

Figure 9: Car Entity Set with three entities.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

9
  The following figure contains all of the above types of attributes:

Figure 10: 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:
 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.
 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.
o Unknown: we do not know whether or not an apartment-number is part of the
customer’s address

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

10
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 11: “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 12: “Works for” Relationship set ER diagram.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

11
 Department

Personnel Department IT Department

Employee

Sara Ahmed Jamal Mazen

Hossam Sami
Abed Yanal Mona

Figure 13: Relationship set.

 Verbs indicate names of relationship types.

 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.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

12
 Pre-
requisite

Course

 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

 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

 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

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

13
 Hours/week

Employee Works Project

on

o Example:
Since

Employee Works Department

For

What is the different between two the following figures?

Price

Pharmacy Sell Drug

Figure (1)
Price

Pharmacy Sell Drug

Figure (2)

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

14
The degree of a relationship type

 It is the number of participating entity types.

1. 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 14: Unary Relationship type example.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

15
 2. Binary: entities of two different types related to each other. (Two participating entities).

An Employee Works for A Department

A Department
Employee has Works for Many Employee
Department

Figure 15: Binary Relationship type example.

3. Ternary: entities of three different types related to each other. (three participating
entities).
PartNo#

Part
Suppid Pname

Supplier Supply Project

Quantity

Figure 16: Ternary Relationship type example.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

16
 Figure 17: Ternary Relationship set example.

 Example:
Drug

Doctor Prescribe
Patient

Figure 18: “Prescribe” ternary relationship type.

4. n-ary: entities of more than three different types related to each other.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

17
Entities Vs Attributes

 Entities can model situations, the attributes cannot model naturally.

 Entities can 1. Participate in relationships, and 2. Have attributes.
o Attributes cannot do any of these
 Let us look at the following example for possible alternative modeling of Buys
o Price is just the actual amount, the number in $’s, so there likely is no reason to make
it an entity as we have below

o We should have

 Example2:

o If we want to model something about a person, such as the date of birth of a person or
whom a person likes.
o These require a person to have an attribute (date of birth) and enter into a relationship
(with other persons).
 We cannot model this situation if person is an attribute of Buy.
o Similarly, for product and vendor.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

18
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.
1. One-to-One (1:1) cardinality ratio, an entity in one set is associated with at most one entity
in another.

Figure 19: One-to-One relationship set.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

19
  For Example:

Department

Personnel Department IT Department

Employee
(Manager)

Abed Hossam

An Employee Manage A Department

A Department has A Manager (Employee)

Figure 20: One-to-One relationship Example.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

20
  The ER Diagram is:

Employee Manage Department

Figure 21: One-to-One relationship ER diagram.

2. 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 22: One-to-Many relationship set.

 For Example:

A Department Controls Many Projects

A Project Controlled by A Department

Figure 23: One-to-Many relationship set example (from
department to project).

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

21
  The ER Diagram is:

Project Controls Department

Figure 24: Many-to-One relationship ER diagram (from project

to department).

3. 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
that makes sense for your application, and then be consistent.

4. Many-to-many (N:M) cardinality ratio, entities of either set may be associated with any
number of entities in the other.

Figure 25: Many-to-Many relationship set.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

22
  For Example:
Projects

Project (1) Project (2)

Mona Hossam Mazen

Jamal Sami

Employee

An Employee Works on Many Projects

A Project Has Many Employee

Figure 26: Many-to-Many relationship set example.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

23
  The ER Diagram is:

Employee Work on Project

Figure 27: Many-to-Many relationship ER diagram.

 Example: determine the cardinality ratio on the following situations:

1.

Person Entity set: (Ahmad, Ali, Omar, Jamal)

Product Entity set: (Computer, Monitor, Printer)
A. Likes relationship set: (Ali likes computer, Ali likes Monitor, Ahmad likes
computer, Jamal likes computer)
B. Likes relationship set: (Ali likes computer, Ali likes Monitor, Omar likes Printer)
Notes:
 Not every person has to Like a product
 Not every product has to be Liked
 A person can Like many products
 A product can be Liked by many persons

2.

Person Entity set: (Ahmad, Ali, Omar, Jamal).

A. Likes relationship set: (Ali likes Ahmad, Ali likes Omar, Ahmad likes Omar,
Ahmad likes Jamal, Ahmad likes Ahmad, Omar likes Ahmad).
B. Likes relationship set: (Ali likes Ahmad, Ahmad likes Omar, Jamal likes Omar,
Omar likes Omar).
Note:
 If Ali likes Ahmad, then Ali is the “Liker” and Ahmad is the “Liked”.

 The cardinality ratio depends on the real-world situation.

 Example: there are two situation of the borrower relationship between customer and
loan:

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

24
  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.

 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.
 Example 1: Consider the following situations:

 We can slide the date to the entity, if no two squares end up in the same entity as
follows:

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

25
  Example2: Consider relationship Buys among Person, Vendor, and Product
 We want to specify that a person Buys a product from a vendor at a specific
price
 Price is not
 A property of a vendor, because different products may be sold by the
same vendor at different prices
 A property of a product, because different vendors may sell the same
product at different prices
 A property of a person, because different products may be bought by the
same person at different prices
 So Price is really an attribute of the relationship Buys
 For each tuple (person, product, vendor) there is a value of price

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:

1. 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.

2. 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.
 The minimum value is one or more.
 Every entity in E participates in at least one relationship in R

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

26
  Shown by double line.

Employee Manage Department

Partial Total
‫ف‬
Figure 28: Total/Partial ER diagram.

 Example: determine the structural constraints on the Born relationship

o Each person was born in one country

o Maybe nobody was born in some country as it has just been Established

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 29: 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 30: one-to-one relationship type example using Min..Max notation.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

27
  An employee must 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) (0..*)
Employee Works for Department

Figure 31: 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.
o Identified by being related to specific entities from another entity type.
 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.
 A weak entity always has a total participation constraint.
 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.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

28
  For example:

SSN Name

Employee Dependents Dependent

of

Figure 32: 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.

 Example 2:

 Example 3:
A:

o We assume that every person has his/her own SSN

o Woman is a strong entity as we can identify a specific woman based on her attributes.
She has a primary key: her own SSN
o Man is a strong entity as we can identify a specific man based on his attributes. He has
a primary key: his own SSN

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

29
 B:

o We assume that women are given SSNs

o Men are not given SSNs; they have first names only, but for each we know who the
mother is (that is, we know the SSN of the man’s mother)
o Man is a weak entity as we cannot identify a specific man based on his own attributes
o Many women could have a son named Bob, so there are many men named Bob
o However, if a woman never gives the same name to more than one of her sons, a man
can be identified by his name and by his mother’s SSN.

 We need to specify for a weak entity through which relationship it is identified; this done by
using double lines as the following example

 There can be several levels of “weakness”

o Here we can say that a horse named “Speedy” belongs to Bob, whose mother is a
woman with SSN 072-45-9867

o A woman can have several sons, each of whom can have several horses

 Represent a weak entity as a regular entity type by introducing an artificial or surrogate key.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

30
  Some database design tools permit only binary relationships
o Ternary relationship must be represented as a weak entity type.
 Consider the following example:

Figure 33: Ternary relationship types. (a) The SUPPLY relationship. (b) Three binary relationships not
equivalent to SUPPLY. (c) SUPPLY represented as a weak entity type.

o In general, a ternary relationship type represents different information than do three

binary relationship types.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

31
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:
1. 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.
2. A department controls a number of projects, each of which has a unique name, a unique
number, and a single location.
3. 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.
4. 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.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

32
 Figure 34: The ER Diagram for the company DB.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

33
 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.

Prepared by: Eng. Randa Al_Dallah and Sawsan Abu_Taleb

34