10/15/2012

1
1992-2012 by Pearson Education, Inc. & McGraw Hill Inc.
ENGR 3700 Data Management Systems
(CSCI 3030: Database Systems & Concepts)
Lecture 11
Entity Relationship (ER) Model
(Chapter 7 from textbook)
Dr. Eyhab Al-Masri
ENGR 3700
Fall 2012 - UOIT
10/15/2012
2
ENGR 3700
Fall 2012 - UOIT
Midterm
Monday October 22, 2012
Review Thursday October 18, 2012
Lab 2
Due October 19, 2012
Project Phase II
Due October 30, 2012
Office Hours
Extended: Thursdays 2:00 pm 3:30 pm
Location: ENG 1023
ENGR 3700
Fall 2012 - UOIT
Denoted by r
<join condition>
s
Purpose: Combines related tuples from two
relations into single longer tuples
Consider each pair of tuples t
r
from r and t
s
from s.
If t
r
and t
s
have the same value on each of the
attributes in r s, add a tuple t to the result, where
t has the same value as t
r
on r
t has the same value as t
s
on s
10/15/2012
3
ENGR 3700
Fall 2012 - UOIT
Degree
degree(r) + degree(s)
Cardinality
between 0 and cardinality (r) * cardinality(s).
The order of attributes in r s is
{ A1, A2, , An, B1, B2, , Bm}
where
A1, A2, , An are the attributes of r and
B1, B2, , Bm are the attributes of s
The resulting relation has one tuple for each
combination of tuples one from r and one for s as
long as the combination satisfies the join condition
ENGR 3700
Fall 2012 - UOIT
10/15/2012
4
ENGR 3700
Fall 2012 - UOIT
Theta JOIN
EQUIJOIN
Natural JOIN
Outer JOIN
Left Outer Join
Right Outer Join
Full Outer Join
ENGR 3700
Fall 2012 - UOIT
Denoted by: r
<r.A s.B>
s
where
A is an attribute of r, B is an attribute of s
A and B have the same domain
is one of the comparison operators {=, , < , >, , }
Purpose: Serves as a general join condition
Combines two tuples into a single combined tuple
satisfying a given condition
10/15/2012
5
ENGR 3700
Fall 2012 - UOIT
EmployeeID Name DeptID Position Salary DeptID DeptName Location
111 Sue 1 Manager 65000 1 Sales Room 245
222 John 2 Accountant 42000 2 Purchase Room 430
333 Mary 1 Clerk 28000 1 Sales Room 245
DeptID DeptName Location
1 Sales Room 245
2 Purchase Room 430
3 Marketing Room 212
Employee
Department
Employee
DeptID = DeptID
Department
Example
EmployeeID Name DeptID Position Salary
111 Sue 1 Manager 65000
222 John 2 Accountant 42000
333 Mary 1 Clerk 28000
444 Victor NULL Manager 52000
ENGR 3700
Fall 2012 - UOIT
EQUIJOIN is the most common join condition
that involves an equality comparisons where
is {=}
This special type of Theta JOIN is called EQUIJOIN
Denoted by: r
<r.A = s.B>
s
EmployeeID Name DeptID Position Salary DeptID DeptName Location
111 Sue 1 Manager 65000 1 Sales Room 245
222 John 2 Accountant 42000 2 Purchase Room 430
333 Mary 1 Clerk 28000 1 Sales Room 245
Emploee
DeptID = DeptID
Department
Example
Disadvantage: redundancy
10/15/2012
6
ENGR 3700
Fall 2012 - UOIT
Denoted by: r * s
Purpose: Removes the extra attribute in an
EQUIJOIN
Both join attributes must have the same
name in both relations
If this is not the case, a renaming operation is
applied first
EmployeeID Name DeptID Position Salary DeptName Location
111 Sue 1 Manager 65000 Sales Room 245
222 John 2 Accountant 42000 Purchase Room 430
333 Mary 1 Clerk 28000 Sales Room 245
ENGR 3700
Fall 2012 - UOIT
Natural JOIN eliminates tuples that have no relation
or do not match
This includes tuples with NULL values
Outer Join is an extension of the join operation that
avoids loss of information
That is, keep all tuples in R, or all those in S, or all those in
both relations regardless of whether or not they have
matching tuples in the other relation
Three main Outer JOIN types:
LEFT OUTER JOIN
RIGHT OUTER JOIN
FULL OUTER JOIN
10/15/2012
7
ENGR 3700
Fall 2012 - UOIT
Denoted by: r s
Purpose: Keeps every tuple in the first (or left) relation r
If no matching tuple is found in s, then the attributes of s in
the join result are filled with NULL values
EmployeeID Name DeptID Position Salary DeptName Location
111 Sue 1 Manager 65000 Sales Room 245
222 John 2 Accountant 42000 Purchase Room 430
333 Mary 1 Clerk 28000 Sales Room 245
444 Victor NULL Manager 52000 NULL NULL
Emploee Department
Example
ENGR 3700
Fall 2012 - UOIT
Denoted by: r s
Purpose: Keeps every tuple in the second (or right)
relation r
If no matching tuple is found in r, then the attributes of r in the
join result are filled with NULL values
EmployeeID Name DeptID Position Salary DeptName Location
111 Sue 1 Manager 65000 Sales Room 245
222 John 2 Accountant 42000 Purchase Room 430
333 Mary 1 Clerk 28000 Sales Room 245
NULL NULL 3 NULL NULL Marketing Room 212
Emploee Department
Example
10/15/2012
8
ENGR 3700
Fall 2012 - UOIT
Denoted by: r s
Purpose: Keeps all tuples in both the left and right
relations when no matching tuples are found
Add NULL values as required
EmployeeID Name DeptID Position Salary DeptName Location
111 Sue 1 Manager 65000 Sales Room 245
222 John 2 Accountant 42000 Purchase Room 430
333 Mary 1 Clerk 28000 Sales Room 245
444 Victor NULL Manager 52000 NULL NULL
NULL NULL 3 NULL NULL Marketing Room 212
Emploee Department
Example
ENGR 3700
Fall 2012 - UOIT
Outer Union operation compute the union of two
relations if the relations are partially union compatible
Characteristics:
The list of compatible attributes includes a key for both
relations.
Tuples from the component relations with the same key are
presented only once in the result and have values for all
attributes in the result.
The attributes that are not union compatible from either
relation are kept in the result.
Tuples that have no values for these attributes are padded
with null values.
OUTER UNION is equivalent to a FULL OUTER JOIN if the join
attributes are all the common attributes of the two relations.
10/15/2012
9
ENGR 3700
Fall 2012 - UOIT
Aggregation function takes a collection of values and
returns a single value as a result.
avg: average value
min: minimum value
max: maximum value
sum: sum of values
count: number of values
Aggregate operation in relational algebra
G1, G2, , Gn F1( A1), F2( A2),, Fn( An)
(E)
E is any relational-algebra expression
G
1
, G
2
, G
n
is a list of attributes on which to group (can be
empty)
Each F
i
is an aggregate function
Each A
i
is an attribute name
ENGR 3700
Fall 2012 - UOIT
A B
o
o
|
|
o
|
|
|
C
7
7
3
10
sum(c)
(r)
sum(C)
27
r
10/15/2012
10
ENGR 3700
Fall 2012 - UOIT
Find the average salary in each department
dept_name avg(salary)
(instructor)
avg_salary
ENGR 3700
Fall 2012 - UOIT
Result of aggregation does not have a name
Can use rename operation to give it a name
For convenience, we permit renaming as part of
aggregate operation
dept_name avg(salary) as avg_sal
(instructor)
10/15/2012
11
ENGR 3700
Fall 2012 - UOIT
Select o
Project [
Rename
Union
Difference
Intersection
Division
Assignment
Cartesian Product X
Join
Natural Join *
Left Outer Join
Right Outer Join
Full Outer Join
Aggregate Function g
ENGR 3700
Fall 2012 - UOIT
10/15/2012
12
ENGR 3700
Fall 2012 - UOIT
Overview of Database Design Process
Example Database Application (COMPANY)
ER Model Concepts
Entities and Attributes
Entity Types, Value Sets, and Key Attributes
Relationships and Relationship Types
Weak Entity Types
Roles and Attributes in Relationship Types
ER Diagrams - Notation
ER Diagram for COMPANY Schema
Alternative Notations UML class diagrams, others
ENGR 3700
Fall 2012 - UOIT
Conceptual modeling is an important phase in designing
a successful database application
What is a database application?
Generally refers to a particular database and the associated
programs that implement the database queries and updates
Application design is typically covered in software
engineering
Focuses more on programs and user interfaces that access the
database
Focus in this chapter:
We will focus on the Entity-Relationship (ER) model: a popular
high-level conceptual data model
10/15/2012
13
ENGR 3700
Fall 2012 - UOIT
ENGR 3700
Fall 2012 - UOIT
Many design tools employ the ER concepts
Notation associated with the ER model is known
as ER diagrams
ER diagram is a detailed, logical representation of the
data for an application
Unified Modeling Language (UML) can also be
used for database design
Class diagrams are similar in many ways to ER diagrams
10/15/2012
14
ENGR 3700
Fall 2012 - UOIT
Phase 1: Requirements collection and analysis
Database designers interview prospective database
users to understand and document data requirements
Result: data requirements
Functional requirements of the application
Consist of user-defined operations that will be applied to
the database
In UML: data flow diagrams, sequence diagrams, scenarios
ENGR 3700
Fall 2012 - UOIT
Phase 2: Conceptual schema
Conceptual design
Create a conceptual schema for the database using a high-
level conceptual data model (i.e. ER)
Do not include implementation details
Concentrate on specifying properties of the data
Description of data requirements
Includes detailed descriptions of the entity types,
relationships, and constraints
10/15/2012
15
ENGR 3700
Fall 2012 - UOIT
Phase 3: Logical design or data model mapping
Actual implementation of the database using a
commercial DBMS
Most commercial DBMS use an implementation data model
(i.e. relational or object-relational)
Conceptual schema is transformed from high-level data
model into implementation data model
Result: database schema in the implementation data
model of the DBMS
Often automated within database design tools
ENGR 3700
Fall 2012 - UOIT
Phase 4: Physical design phase
Internal storage structures, file organizations, indexes,
access paths, and physical design parameters for the
database files specified
10/15/2012
16
ENGR 3700
Fall 2012 - UOIT
An ER diagram consists of
Entity Sets
Attributes
Relationships
ENGR 3700
Fall 2012 - UOIT
Entity
Specific object that exist and is distinguishable from other
objects
Examples: Person, Car, Book, University, Account, Loan
May be concrete (i.e. a person) or abstract (i.e. holiday)
An entity is represented by a set of attributes
Entity type/set
Collection (or set) of entities that have the same
attributes (Example: collection of books)
Entity set is usually referred to using the same name as the
entity type
10/15/2012
17
ENGR 3700
Fall 2012 - UOIT
ENGR 3700
Fall 2012 - UOIT
Attributes
Properties that describe an entity
Examples: an EMPLOYEE entity has attributes Name,
SSN, Address, Age, BirthDate, Salary, etc
Each attribute has a value set (data type) associated
with it
Domain of the attribute is the set of all permitted values
Example: integer, string, date, etc
10/15/2012
18
ENGR 3700
Fall 2012 - UOIT
Attributes (contd)
Each entity is described by a set of (attribute, data value)
pairs
A specific entity will have a value associated with each
attribute
Example: a specific employee entity will have
Name=John Smith,
SSN=123456789,
Address=2311 Kirby St., Houston, Texas 77001,
Sex=M,
BirthDate=01-JAN-55
An attribute of an entity type for which each entity must
have a unique value is called a key attribute
Example: SSN or EMPLOYEE
ENGR 3700
Fall 2012 - UOIT
Simple or Atomic
Composite
Single-Valued
Multivalued
Stored or derived
Null
Complex
10/15/2012
19
ENGR 3700
Fall 2012 - UOIT
Simple or Atomic
Attributes that cannot be further divided into smaller
parts and nonetheless represent the basic meaning
Example
Employee
Salary
Name
Age
FirstName
LastName
Simple Attributes
ENGR 3700
Fall 2012 - UOIT
An attribute is composed of multiple
components
Value of composite attribute is a concatenation
of the values of its component simple attributes
Example
Employee
Salary
Name
Age
FirstName
LastName
Simple Attributes
Composite Attribute
10/15/2012
20
ENGR 3700
Fall 2012 - UOIT
ENGR 3700
Fall 2012 - UOIT
Attributes that have a single value for a
particular entity
Example
Employee
Salary
Name
Age
Single-Valued Attribute
10/15/2012
21
ENGR 3700
Fall 2012 - UOIT
Attributes can have a set of values for the same
entity
Denoted as {EntityName}
May have lower and upper bounds to constrain the
number of values allowed
Example
Employee
Salary
Name
Skills
Multivalued Attribute
ENGR 3700
Fall 2012 - UOIT
Derived attributes are those attributes that may
not be stored directly but can be derived from
stored attributes
Some attribute values can be derived from related entities
(Example: NumberOfEmployees)
Example
Employee
Salary
Name
NumOfYears
Derived Attribute
Years of service of
an employee is
determined from
the current date
and the date of the
employee joining
the company
10/15/2012
22
ENGR 3700
Fall 2012 - UOIT
In some cases, a particular entity may not have
an applicable value for an attribute
Example
ApartmentNumber attribute of an address applies only
to addresses that are in Apartment Buildings and NOT
to other types of residences (i.e. house)
ENGR 3700
Fall 2012 - UOIT
Composite and multivalued attributes can be
nested
Example: Person can have more than one residence
Can be represented by grouping components of:
composite attribute are represented between () and
separating them with commas
multivalued attributes are represented between {}
10/15/2012
23
ENGR 3700
Fall 2012 - UOIT
Key Attribute:
An attribute whose value is unique for each individual entity in the
entity set
Used to identify each entity uniquely
A key attribute may be composite
VehicleTagNumber is a key of the CAR entity type with components
(Number, State)
An entity type may have more than one key
The CAR entity type may have two keys:
VehicleIdentificationNumber (popularly called VIN)
VehicleTagNumber (Number, State), aka license plate number
In ER model, each key is underlined
ENGR 3700
Fall 2012 - UOIT
In ER diagrams, an entity type is displayed as a
rectangular box enclosing entity name
Attributes are displayed as ovals
Each attribute is connected to its entity type by a
straight line
Composite attributes are attached to their component
attributes by straight lines
Multivalued attributes are displayed in double ovals
10/15/2012
24
ENGR 3700
Fall 2012 - UOIT
Entity set is the current
state of the entities of that
type that are stored in the
database
ENGR 3700
Fall 2012 - UOIT
Strong Entity type:
It contain a key attribute
It is an independent entity set (it is
used to identify each entity uniquely)
Weak Entity type:
It does not contain a key attribute
Is an entity that is existence-
dependent on some other entity
Can have partial key: attribute uniquely
identifies weak entities (discriminator)
Weak entity types are represented by
surrounding their boxes and
diamonds with double lines
Employee
EmpID
EmpName
has
Dependent
DepName DepAge
weak
entity
strong
entity
identifying
relationship
identifying
or owner
entity type
10/15/2012
25
ENGR 3700
Fall 2012 - UOIT
We need to create a database schema design
based on the following (simplified) requirements
of the COMPANY database
Part I:
Company is organized into DEPARTMENTS.
Each department has a unique name & number
Each department has 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
ENGR 3700
Fall 2012 - UOIT
Part II:
Each department controls a number of PROJECTS
Each project has a unique name, unique number, and is
located at a single location
Part III:
We store each EMPLOYEEs name, SSN, address, salary, sex,
and birth date
Each employee works for one department but may work on
several projects
We keep track of the number of hours per week that an
employee currently works on each project
We also keep track of the direct supervisor of each
employee
10/15/2012
26
ENGR 3700
Fall 2012 - UOIT
Part IV:
Each employee may have a number of DEPENDENTS
For each dependent, we keep track of their name, sex,
birthrate, and relationship to the employee
ENGR 3700
Fall 2012 - UOIT
Based on the requirements, we can identify four
initial entity types in the COMPANY database:
DEPARTMENT
PROJECT
EMPLOYEE
DEPENDENT
10/15/2012
27
ENGR 3700
Fall 2012 - UOIT
composite
multivalued
ENGR 3700
Fall 2012 - UOIT
Part I
Company is organized into DEPARTMENTS.
Each department has a unique name and number
Each department has 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
10/15/2012
28
ENGR 3700
Fall 2012 - UOIT
Part II:
Each department controls a number of PROJECTS
Each project has a unique name, unique number, and
is located at a single location
ENGR 3700
Fall 2012 - UOIT
Part III:
We store each EMPLOYEEs name, SSN, address, salary,
sex, and birth date
Each employee works for one department but may
work on several projects
We keep track of the number of hours per week that an
employee currently works on each project
We also keep track of the direct supervisor of each
employee
10/15/2012
29
ENGR 3700
Fall 2012 - UOIT
Part IV:
Each employee may have a number of DEPENDENTS
For each dependent, we keep track of their name, sex,
birthrate, and relationship to the employee
ENGR 3700
Fall 2012 - UOIT
Initial design is typically not complete
We have not represented that an employee can work on
several projects
We have not represented the number of hours per week an
employee works on
Some aspects in the requirements will be represented as
relationships
Example: attribute Manager of DEPARTMENT refers to an
employee who manages the department
Example: Controlling_department of PROJECT refers to the
department that controls the project
In the ER model, these references should be represented
as relationships
10/15/2012
30
ENGR 3700
Fall 2012 - UOIT
Relationship
Is an association between two or more entities
Examples:
EMPLOYEE John Smith works on the ProductX PROJECT
Relationship types
Set of associations (or relationship set) among entities
of certain entity types
Are useful for expressing certain business rules
Student
Course
entity
type
registers
relationship
ENGR 3700
Fall 2012 - UOIT
Degree of a relationship is the number of
participating entity types
Relationship between 2 entities is called binary relationship
Relationship among 3 entities is called ternary relationship
Relationship among n entities is called n-ray relationship
10/15/2012
31
ENGR 3700
Fall 2012 - UOIT
ENGR 3700
Fall 2012 - UOIT
Each relationship
instance (r
i
) associate
three entities:
SUPPLIER, PART, and
PROJ ECT
Hence, this
relationship type is of
degree three (ternary)
10/15/2012
32
ENGR 3700
Fall 2012 - UOIT
Each instance in the relationship set relates
individual participating entities
one from each participating entity type
In ER diagrams, we represent the relationship
type as follows
Diamond-shaped box is used to display a relationship
type
Connected to the participating entity types via straight
lines
ENGR 3700
Fall 2012 - UOIT
Instructor
Department works_in
binary relationship
Instructor
Department works_in
ternary relationship
Term
10/15/2012
33
ENGR 3700
Fall 2012 - UOIT
Role names
signifies role that a participating entity plays in each
relationship instance
Examples: SUPERVISION relationship
supervisor (or boss) role
Supervisee (or subordinate) role
Role names are not necessary in relationship types
where all participating entity types are distinct