FDMS - Chapter Six
FDMS - Chapter Six
3
Chapter Outline
Relational Model Concepts
Relational Model Constraints and Relational
Database Schemas
Relational Operations
4
Relational Model Concepts
The relational Model of Data is based on the concept of a
Relation
◦ The strength of the relational approach to data management
comes from the formal foundation provided by the theory of
relations
We review the essentials of the formal relational model in
this chapter
In practice, there is a standard model based on SQL – that
we described in Chapters 5
Note: There are several important differences between the
formal model and the practical model, as we shall see
5
Relational Model Concepts
A Relation is a mathematical concept based
on the ideas of sets
The model was first proposed by Dr. E.F.
Codd of IBM Research in 1970 in the
following paper:
◦ "A Relational Model for Large Shared Data
Banks," Communications of the ACM, June 1970
The above paper caused a major revolution in
the field of database management and earned
Dr. Codd the coveted ACM Turing Award
6
Informal Definitions
Informally, a relation looks like a table of values.
A relation typically contains a set of rows.
The data elements in each row represent certain facts
that correspond to a real-world entity or relationship
◦ In the formal model, rows are called tuples
7
Informal Definitions
◦ In the STUDENT table, SSN is the key
◦ Sometimes row-ids or sequential numbers are assigned
as keys to identify the rows in a table
Called artificial key or surrogate key
8
Formal Definitions - Schema
The Schema (or description) of a Relation:
◦ Denoted by R(A1, A2, .....An)
◦ R is the name of the relation
◦ The attributes of the relation are A1, A2, ..., An
Example:
9
Formal Definitions - Tuple
A tuple is an ordered set of values (enclosed in angled
brackets ‘< … >’)
Each value is derived from an appropriate domain.
A row in the CUSTOMER relation is a 4-tuple and would
consist of four values, for example:
◦ <632895, "John Smith", "101 Main St. Atlanta, GA 30332",
"(404) 894-2000">
◦ This is called a 4-tuple as it has 4 values
◦ A tuple (row) in the CUSTOMER relation.
A relation is a set of such tuples (rows)
10
Formal Definitions - Domain
A domain has a logical definition:
◦ Example: “USA_phone_numbers” are the set of 10 digit phone numbers
valid in the U.S.
A domain also has a data-type or a format defined for it.
◦ The USA_phone_numbers may have a format: (ddd)ddd-dddd where each
d is a decimal digit.
◦ Dates have various formats such as year, month, date formatted as
yyyy-mm-dd, or as dd mm,yyyy etc.
11
Formal Definitions - State
The relation state is a subset of the Cartesian
product of the domains of its attributes
◦ each domain contains the set of all possible values
the attribute can take.
Example: attribute Cust-name is defined over
the domain of character strings of maximum
length 25
◦ dom(Cust-name) is varchar(25)
The role these strings play in the
CUSTOMER relation is that of the name of a
customer.
12
Formal Definitions - Summary
Formally,
◦ Given R(A1, A2, .........., An)
◦ r(R) dom (A1) X dom (A2) X ....X dom(An)
R(A1, A2, …, An) is the schema of the relation
R is the name of the relation
A1, A2, …, An are the attributes of the relation
r(R): a specific state (or "value" or “population”) of relation
R – this is a set of tuples (rows)
◦ r(R) = {t1, t2, …, tn} where each ti is an n-tuple
◦ ti = <v1, v2, …, vn> where each vj element-of dom(Aj)
13
Formal Definitions - Example
Let R(A1, A2) be a relation schema:
◦ Let dom(A1) = {0,1}
◦ Let dom(A2) = {a,b,c}
Then: dom(A1) X dom(A2) is all possible combinations:
{<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> }
14
Definition Summary
15
Characteristics Of Relations
Ordering of tuples in a relation r(R):
◦ The tuples are not considered to be ordered, even though
they appear to be in the tabular form.
Ordering of attributes in a relation schema R (and of values
within each tuple):
◦ We will consider the attributes in R(A1, A2, ..., An) and
the values in t=<v1, v2, ..., vn> to be ordered .
(However, a more general alternative definition of relation does not
require this ordering. It includes both the name and the value for
each of the attributes ).
Example: t= { <name, “John” >, <SSN, 123456789> }
This representation may be called as “self-describing”.
16
Characteristics Of Relations
Same state as previous Figure (but with different order of
tuples)
17
Characteristics Of Relations
Values in a tuple:
◦ All values are considered atomic (indivisible).
◦ Each value in a tuple must be from the domain of the attribute
for that column
If tuple t = <v1, v2, …, vn> is a tuple (row) in the relation
state r of R(A1, A2, …, An)
Then each vi must be a value from dom(Ai)
18
CONSTRAINTS
Constraints determine which values are permissible and which
are not in the database.
They are of three main types:
1. Inherent or Implicit Constraints: These are based on the
data model itself. (E.g., relational model does not allow a list as
a value for any attribute)
2. Schema-based or Explicit Constraints: They are expressed
in the schema by using the facilities provided by the model.
(E.g., max. cardinality ratio constraint in the ER model)
3. Application based or semantic constraints: These are
beyond the expressive power of the model and must be
specified and enforced by the application programs.
19
Relational Integrity Constraints
Constraints are conditions that must hold on all valid
relation states.
There are three main types of (explicit schema-based)
constraints that can be expressed in the relational model:
◦ Key constraints
◦ Entity integrity constraints
◦ Referential integrity constraints
Another schema-based constraint is the domain constraint
◦ Every value in a tuple must be from the domain of its attribute
(or it could be null, if allowed for that attribute)
20
Key Constraints
Superkey of R:
◦ Is a set of attributes SK of R with the following condition:
No two tuples in any valid relation state r(R) will have the same
value for SK
That is, for any distinct tuples t1 and t2 in r(R), t1[SK] t2[SK]
This condition must hold in any valid state r(R)
Key of R:
◦ A "minimal" superkey
◦ That is, a key is a superkey K such that removal of any attribute
from K results in a set of attributes that is not a superkey (does
not possess the superkey uniqueness property)
A Key is a Superkey but not vice versa
21
Key Constraints (continued)
Example: Consider the CAR relation schema:
◦ CAR(State, Reg#, SerialNo, Make, Model, Year)
◦ CAR has two keys:
Key1 = {State, Reg#}
Key2 = {SerialNo}
◦ Both are also superkeys of CAR
◦ {SerialNo, Make} is a superkey but not a key.
In general:
◦ Any key is a superkey (but not vice versa)
◦ Any set of attributes that includes a key is a superkey
◦ A minimal superkey is also a key
22
Key Constraints (continued)
Ifa relation has several candidate keys, one is chosen
arbitrarily to be the primary key.
◦ The primary key attributes are underlined.
Example: Consider the CAR relation schema:
◦ CAR(State, Reg#, SerialNo, Make, Model, Year)
◦ We chose SerialNo as the primary key
The primary key value is used to uniquely identify each tuple
in a relation
◦ Provides the tuple identity
Also used to reference the tuple from another tuple
◦ General rule: Choose as primary key the smallest of the
candidate keys (in terms of size)
◦ Not always applicable – choice is sometimes subjective
23
Key Constraints (continued)
CAR table with two candidate keys – LicenseNumber chosen
as Primary Key
24
Relational Database Schema
Relational Database Schema:
◦ A set S of relation schemas that belong to the same
database.
◦ S is the name of the whole database schema
◦ S = {R1, R2, ..., Rn} and a set IC of integrity
constraints.
◦ R1, R2, …, Rn are the names of the individual
relation schemas within the database S
Following slide shows a COMPANY
database schema with 6 relation schemas
25
COMPANY Database Schema
26
Relational Database State
A relational database state DB of S is a set of
relation states DB = {r1, r2, ..., rm} such that each ri is
a state of Ri and such that the ri relation states satisfy
the integrity constraints specified in IC.
A relational database state is sometimes called a
relational database snapshot or instance.
We will not use the term instance since it also applies
to single tuples.
A database state that does not meet the constraints is
an invalid state
27
Populated database state
Each relation will have many tuples in its current relation
state
The relational database state is a union of all the individual
relation states
Whenever the database is changed, a new state arises
Basic operations for changing the database:
◦ INSERT a new tuple in a relation
◦ DELETE an existing tuple from a relation
◦ MODIFY an attribute of an existing tuple
Next
slide (Fig. 5.6) shows an example state for the
COMPANY database schema shown in Fig. 5.5.
28
Populated database state for Company
29
Entity Integrity
Entity Integrity:
◦ The primary key attributes PK of each relation schema R in S cannot
have null values in any tuple of r(R).
This is because primary key values are used to identify the
individual tuples.
t[PK] null for any tuple t in r(R)
If PK has several attributes, null is not allowed in any of these
attributes
◦ Note: Other attributes of R may be constrained to disallow null
values, even though they are not members of the primary key.
Referential Integrity
◦ A constraint involving two relations
The previous constraints involve a single relation.
◦ Used to specify a relationship among tuples in two
relations:
The referencing relation and the referenced relation.
30
Referential Integrity
Tuples in the referencing relation R1 have
attributes FK (called foreign key attributes)
that reference the primary key attributes PK
of the referenced relation R2.
◦ A tuple t1 in R1 is said to reference a tuple t2 in
R2 if t1[FK] = t2[PK].
A referential integrity constraint can be
displayed in a relational database schema as a
directed arc from R1.FK to R2.
31
Referential Integrity (or foreign key) Constraint
Statement of the constraint
◦ The value in the foreign key column (or columns)
FK of the the referencing relation R1 can be
either:
(1) a value of an existing primary key value of a
corresponding primary key PK in the referenced
relation R2, or
(2) a null.
In case (2), the FK in R1 should not be a part
of its own primary key.
32
Displaying a relational database schema and its
constraints
Each relation schema can be displayed as a row of attribute
names
The name of the relation is written above the attribute names
The primary key attribute (or attributes) will be underlined
A foreign key (referential integrity) constraints is displayed
as a directed arc (arrow) from the foreign key attributes to
the referenced table
◦ Can also point the the primary key of the referenced relation for
clarity
Next slide shows the COMPANY relational schema
diagram with referential integrity constraints
33
Referential Integrity Constraints for COMPANY
database
34
Other Types of Constraints
Semantic Integrity Constraints:
◦ based on application semantics and cannot be expressed
by the model per se
◦ Example: “the max. no. of hours per employee for all
projects he or she works on is 56 hrs per week”
A constraint specification language may have to be used
to express these
SQL-99 allows CREATE TRIGGER and CREATE
ASSERTION to express some of these semantic
constraints
Keys, Permissibility of Null values, Candidate Keys
(Unique in SQL), Foreign Keys, Referential Integrity etc.
are expressed by the CREATE TABLE statement in
SQL.
35
6.3 Relational Operations on Relations
INSERT a tuple.
DELETE a tuple.
MODIFY a tuple.
Integrity constraints should not be violated
by the update operations.
Several update operations may have to be
grouped together.
Updates may propagate to cause other
updates automatically. This may be necessary
to maintain integrity constraints.
36
Update Operations on Relations
In case of integrity violation, several actions
can be taken:
◦ Cancel the operation that causes the violation
(RESTRICT or REJECT option)
◦ Perform the operation but inform the user of the
violation
◦ Trigger additional updates so the violation is
corrected (CASCADE option, SET NULL option)
◦ Execute a user-specified error-correction routine
37
Possible violations for each operation
INSERT may violate any of the constraints:
◦ Domain constraint:
if one of the attribute values provided for the new tuple is not of the
specified attribute domain
◦ Key constraint:
if the value of a key attribute in the new tuple already exists in
another tuple in the relation
◦ Referential integrity:
if a foreign key value in the new tuple references a primary key
value that does not exist in the referenced relation
◦ Entity integrity:
if the primary key value is null in the new tuple
38
Possible violations for each operation
DELETE may violate only referential integrity:
◦ If the primary key value of the tuple being deleted is referenced
from other tuples in the database
Can be remedied by several actions: RESTRICT, CASCADE, SET
NULL (see Chapter 6 for more details)
RESTRICT option: reject the deletion
CASCADE option: propagate the new primary key value into the foreign
keys of the referencing tuples
SET NULL option: set the foreign keys of the referencing tuples to
NULL
◦ One of the above options must be specified during database
design for each foreign key constraint
39
Possible violations for each operation
UPDATE may violate domain constraint and NOT NULL
constraint on an attribute being modified
Any of the other constraints may also be violated, depending
on the attribute being updated:
◦ Updating the primary key (PK):
Similar to a DELETE followed by an INSERT
Need to specify similar options to DELETE
◦ Updating a foreign key (FK):
May violate referential integrity
◦ Updating an ordinary attribute (neither PK nor FK):
Can only violate domain constraints
40
Summary
Presented Relational Model Concepts
◦ Definitions
◦ Characteristics of relations
Discussed Relational Model Constraints and Relational
Database Schemas
◦ Domain constraints
◦ Key constraints
◦ Entity integrity
◦ Referential integrity
Described the Relational Update Operations and Dealing
with Constraint Violations
41
Relational Algebra
42
Relational Algebra Overview
Relational algebra is the basic set of
operations for the relational model
These operations enable a user to specify basic
retrieval requests (or queries)
The result of an operation is a new relation,
which may have been formed from one or
more input relations
◦ This property makes the algebra “closed” (all
objects in relational algebra are relations)
43
Relational Algebra Overview (continued)
The algebra operations thus produce new
relations
◦ These can be further manipulated using operations
of the same algebra
A sequence of relational algebra operations
forms a relational algebra expression
◦ The result of a relational algebra expression is also a
relation that represents the result of a database query (or
retrieval request)
44
Relational Algebra Overview
Relational Algebra consists of several groups of operations
◦ Unary Relational Operations
SELECT (symbol: (sigma))
PROJECT (symbol: (pi))
RENAME (symbol: (rho))
◦ Relational Algebra Operations From Set Theory
UNION ( ), INTERSECTION ( ), DIFFERENCE (or MINUS,
–)
CARTESIAN PRODUCT ( x )
◦ Binary Relational Operations
JOIN (several variations of JOIN exist)
DIVISION
◦ Additional Relational Operations
OUTER JOINS, OUTER UNION
AGGREGATE FUNCTIONS (These compute summary of
information: for example, SUM, COUNT, AVG, MIN, MAX)
45
Database State for COMPANY
All examples discussed below refer to the COMPANY database shown
here.
46
Unary Relational Operations: SELECT
The SELECT operation (denoted by (sigma)) is used to select a subset
of the tuples from a relation based on a selection condition.
◦ The selection condition acts as a filter
◦ Keeps only those tuples that satisfy the qualifying condition
◦ Tuples satisfying the condition are selected whereas the other
tuples are discarded (filtered out)
Examples:
◦ Select the EMPLOYEE tuples whose department number is 4:
(EMPLOYEE)
DNO = 4
47
Unary Relational Operations: SELECT
◦ In general, the select operation is denoted by
<selection condition>(R) where
48
Unary Relational Operations: SELECT (continued)
SELECT Operation Properties
◦ The SELECT operation <selection condition>(R) produces a relation S
that has the same schema (same attributes) as R
◦ SELECT is commutative:
<condition1>( < condition2> (R)) = <condition2> ( < condition1> (R))
◦ Because of commutativity property, a cascade (sequence) of
SELECT operations may be applied in any order:
<cond1>(<cond2> (<cond3> (R)) = <cond2> (<cond3> (<cond1> ( R)))
◦ A cascade of SELECT operations may be replaced by a single
selection with a conjunction of all the conditions:
<cond1>(< cond2> (<cond3>(R)) = <cond1> AND < cond2> AND < cond3>(R)))
◦ The number of tuples in the result of a SELECT is less than (or
equal to) the number of tuples in the input relation R
49
The following query results refer to this database state
50
Unary Relational Operations: PROJECT
PROJECT Operation is denoted by (pi)
This operation keeps certain columns
(attributes) from a relation and discards the
other columns.
◦ PROJECT creates a vertical partitioning
The list of specified columns (attributes) is kept in each
tuple
The other attributes in each tuple are discarded
Example: To list each employee’s first and
last name and salary, the following is used:
LNAME, FNAME,SALARY(EMPLOYEE)
51
Unary Relational Operations: PROJECT (cont.)
The general form of the project operation is:
<attribute list>(R)
◦ (pi) is the symbol used to represent the project
operation
◦ <attribute list> is the desired list of attributes from
relation R.
The project operation removes any duplicate
tuples
◦ This is because the result of the project operation
must be a set of tuples
Mathematical sets do not allow duplicate elements.
52
Unary Relational Operations: PROJECT (contd.)
PROJECT Operation Properties
◦ The number of tuples in the result of projection
<list>(R) is always less or equal to the number of
tuples in R
If the list of attributes includes a key of R, then the
number of tuples in the result of PROJECT is equal to
the number of tuples in R
◦ PROJECT is not commutative
<list1> ( <list2> (R) ) = <list1> (R) as long as <list2>
contains the attributes in <list1>
53
Examples of applying SELECT and PROJECT
operations
54
Relational Algebra Expressions
We may want to apply several relational
algebra operations one after the other
◦ Either we can write the operations as a single
relational algebra expression by nesting the
operations, or
◦ We can apply one operation at a time and create
intermediate result relations.
In the latter case, we must give names to the
relations that hold the intermediate results.
55
Single expression versus sequence of relational operations
(Example)
To retrieve the first name, last name, and salary of all
employees who work in department number 5, we must
apply a select and a project operation
We can write a single relational algebra expression as
follows:
◦ FNAME, LNAME, SALARY( DNO=5(EMPLOYEE))
OR We can explicitly show the sequence of operations,
giving a name to each intermediate relation:
◦ DEP5_EMPS DNO=5(EMPLOYEE)
◦ RESULT FNAME, LNAME, SALARY (DEP5_EMPS)
56
Unary Relational Operations: RENAME
The RENAME operator is denoted by (rho)
In some cases, we may want to rename the attributes
of a relation or the relation name or both
◦ Useful when a query requires multiple operations
◦ Necessary in some cases (see JOIN operation later)
The general RENAME operation can be expressed
by any of the following forms:
◦ S (B1, B2, …, Bn )(R) changes both:
the relation name to S, and
the column (attribute) names to B1, B1, …..Bn
◦ S(R) changes:
the relation name only to S
◦ (B1, B2, …, Bn )(R) changes:
the column (attribute) names only to B1, B1, …..Bn
57
Unary Relational Operations: RENAME (continued)
For convenience, we also use a shorthand for
renaming attributes in an intermediate
relation:
◦ If we write:
• RESULT FNAME, LNAME, SALARY (DEP5_EMPS)
• RESULT will have the same attribute names as
DEP5_EMPS (same attributes as EMPLOYEE)
• If we write:
• RESULT (F, M, L, S, B, A, SX, SAL, SU, DNO)
RESULT (F.M.L.S.B,A,SX,SAL,SU, DNO)(DEP5_EMPS)
• The 10 attributes of DEP5_EMPS are renamed to F,
M, L, S, B, A, SX, SAL, SU, DNO, respectively
Note: the symbol is an assignment operator
58
Example of applying multiple operations and
RENAME
59
Relational Algebra Operations from Set Theory: UNION
UNION Operation
◦ Binary operation, denoted by
◦ The result of R S, is a relation that includes all tuples that are either in R or in S
or in both R and S
◦ Duplicate tuples are eliminated
◦ The two operand relations R and S must be “type compatible” (or UNION
compatible)
R and S must have same number of attributes
Each pair of corresponding attributes must be type compatible (have same or
compatible domains)
Example:
◦ To retrieve the social security numbers of all employees who either work in department 5
(RESULT1 below) or directly supervise an employee who works in department 5 (RESULT2
below)
◦ We can use the UNION operation as follows:
DEP5_EMPS DNO=5 (EMPLOYEE)
RESULT1 SSN(DEP5_EMPS)
RESULT2(SSN) SUPERSSN(DEP5_EMPS)
RESULT RESULT1 U RESULT2
◦ The union operation produces the tuples that are in either RESULT1 or RESULT2 or both
60
Figure 8.3 Result of the UNION operation
RESULT ← RESULT1 ∪ RESULT2.
61
Relational Algebra Operations from Set Theory
Type Compatibility of operands is required for the binary set
operation UNION , (also for INTERSECTION , and SET
DIFFERENCE –, see next slides)
R1(A1, A2, ..., An) and R2(B1, B2, ..., Bn) are type
compatible if:
◦ they have the same number of attributes, and
◦ the domains of corresponding attributes are type compatible (i.e.
dom(Ai)=dom(Bi) for i=1, 2, ..., n).
The resulting relation for R1R2 (also for R1R2, or R1–
R2, see next slides) has the same attribute names as the first
operand relation R1 (by convention)
62
Relational Algebra Operations from Set Theory:
INTERSECTION
INTERSECTION is denoted by
The result of the operation R S, is a relation that
includes all tuples that are in both R and S
◦ The attribute names in the result will be the same as the
attribute names in R
The two operand relations R and S must be “type
compatible”
SET DIFFERENCE (also called MINUS or EXCEPT) is
denoted by –
The result of R – S, is a relation that includes all tuples
that are in R but not in S
◦ The attribute names in the result will be the same as the
attribute names in R
Thetwo operand relations R and S must be “type
compatible”
63
Example to illustrate the result of UNION,
INTERSECT, and DIFFERENCE
64
Some properties of UNION, INTERSECT, and
DIFFERENCE
Notice that both union and intersection are commutative
operations; that is
◦ R S = S R, and R S = S R
Both union and intersection can be treated as n-ary
operations applicable to any number of relations as both are
associative operations; that is
◦ R (S T) = (R S) T
◦ (R S) T = R (S T)
The minus operation is not commutative; that is, in general
◦ R–S≠S–R
65
Relational Algebra Operations from Set Theory:
CARTESIAN PRODUCT
CARTESIAN (or CROSS) PRODUCT Operation
◦ This operation is used to combine tuples from two relations in a
combinatorial fashion.
◦ Denoted by R(A1, A2, . . ., An) x S(B1, B2, . . ., Bm)
◦ Result is a relation Q with degree n + m attributes:
Q(A1, A2, . . ., An, B1, B2, . . ., Bm), in that order.
◦ The resulting relation state has one tuple for each combination
of tuples—one from R and one from S.
◦ Hence, if R has nR tuples (denoted as |R| = nR ), and S has nS
tuples, then R x S will have nR * nS tuples.
◦ The two operands do NOT have to be "type compatible”
66
Relational Algebra Operations from Set Theory:
CARTESIAN PRODUCT (cont.)
Generally, CROSS PRODUCT is not a
meaningful operation
◦ Can become meaningful when followed by other
operations
Example (not meaningful):
◦ FEMALE_EMPS SEX=’F’(EMPLOYEE)
◦ EMPNAMES FNAME, LNAME, SSN (FEMALE_EMPS)
◦ EMP_DEPENDENTS EMPNAMES x DEPENDENT
EMP_DEPENDENTS will contain every combination of
EMPNAMES and DEPENDENT
◦ whether or not they are actually related
67
Relational Algebra Operations from Set Theory:
CARTESIAN PRODUCT (cont.)
To keep only combinations where the
DEPENDENT is related to the EMPLOYEE,
we add a SELECT operation as follows
Example (meaningful):
◦ FEMALE_EMPS SEX=’F’(EMPLOYEE)
◦ EMPNAMES FNAME, LNAME, SSN (FEMALE_EMPS)
◦ EMP_DEPENDENTS EMPNAMES x DEPENDENT
◦ ACTUAL_DEPS SSN=ESSN(EMP_DEPENDENTS)
◦ RESULT FNAME, LNAME, DEPENDENT_NAME (ACTUAL_DEPS)
RESULT will now contain the name of female employees
and their dependents
68
Figure 8.5 The CARTESIAN PRODUCT (CROSS
PRODUCT) operation.
69
Figure 8.5 (continued) The CARTESIAN PRODUCT (CROSS
PRODUCT) operation.
70
Figure 8.5 (continued) The CARTESIAN PRODUCT
(CROSS PRODUCT) operation.
71
Binary Relational Operations: JOIN
JOIN Operation (denoted by )
◦ The sequence of CARTESIAN PRODECT followed by
SELECT is used quite commonly to identify and select related
tuples from two relations
◦ A special operation, called JOIN combines this sequence into a
single operation
◦ This operation is very important for any relational database with
more than a single relation, because it allows us combine related
tuples from various relations
◦ The general form of a join operation on two relations R(A1,
A2, . . ., An) and S(B1, B2, . . ., Bm) is:
R <join condition>S
◦ where R and S can be any relations that result from general
relational algebra expressions.
72
Binary Relational Operations: JOIN (cont.)
Example: Suppose that we want to retrieve the name of
the manager of each department.
◦ To get the manager’s name, we need to combine each
DEPARTMENT tuple with the EMPLOYEE tuple whose
SSN value matches the MGRSSN value in the department
tuple.
◦ We do this by using the join operation.
73
Some properties of JOIN
Consider the following JOIN operation:
◦ R(A1, A2, . . ., An) S(B1, B2, . . ., Bm)
R.Ai=S.Bj
◦ Result is a relation Q with degree n + m attributes:
Q(A1, A2, . . ., An, B1, B2, . . ., Bm), in that order.
◦ The resulting relation state has one tuple for each combination
of tuples—r from R and s from S, but only if they satisfy the
join condition r[Ai]=s[Bj]
◦ Hence, if R has nR tuples, and S has nS tuples, then the join
result will generally have less than nR * nS tuples.
◦ Only related tuples (based on the join condition) will appear in
the result
74
Some properties of JOIN
The general case of JOIN operation is called
a Theta-join: R S
theta
The join condition is called theta
Theta can be any general boolean expression
on the attributes of R and S; for example:
◦ R.Ai<S.Bj AND (R.Ak=S.Bl OR R.Ap<S.Bq)
Most join conditions involve one or more
equality conditions “AND”ed together; for
example:
◦ R.Ai=S.Bj AND R.Ak=S.Bl AND R.Ap=S.Bq
75
Binary Relational Operations: EQUIJOIN
EQUIJOIN Operation
The most common use of join involves join
conditions with equality comparisons only
Such a join, where the only comparison
operator used is =, is called an EQUIJOIN.
◦ In the result of an EQUIJOIN we always have one
or more pairs of attributes (whose names need not
be identical) that have identical values in every
tuple.
◦ The JOIN seen in the previous example was an
EQUIJOIN.
76
Binary Relational Operations: NATURAL JOIN Operation
NATURAL JOIN Operation
◦ Another variation of JOIN called NATURAL JOIN — denoted
by * — was created to get rid of the second (superfluous)
attribute in an EQUIJOIN condition.
because one of each pair of attributes with identical values is
superfluous
◦ The standard definition of natural join requires that the two join
attributes, or each pair of corresponding join attributes, have
the same name in both relations
◦ If this is not the case, a renaming operation is applied first.
77
Binary Relational Operations NATURAL JOIN (continued)
Example: To apply a natural join on the DNUMBER attributes of
DEPARTMENT and DEPT_LOCATIONS, it is sufficient to write:
◦ DEPT_LOCS DEPARTMENT * DEPT_LOCATIONS
Only attribute with the same name is DNUMBER
An implicit join condition is created based on this attribute:
DEPARTMENT.DNUMBER=DEPT_LOCATIONS.DNUMBER
78
Example of NATURAL JOIN operation
79
Complete Set of Relational Operations
The set of operations including SELECT ,
PROJECT , UNION , DIFFERENCE ,
RENAME , and CARTESIAN PRODUCT
X is called a complete set because any other
relational algebra expression can be
expressed by a combination of these five
operations.
For example:
◦ R S = (R S ) – ((R S) (S R))
◦R <join condition>S = <join condition> (R X S)
80
Binary Relational Operations: DIVISION
DIVISION Operation
◦ The division operation is applied to two relations
◦ R(Z) S(X), where X subset Z. Let Y = Z - X (and
hence Z = X Y); that is, let Y be the set of attributes of R that
are not attributes of S.
81
Example of DIVISION
82
Table 8.1 Operations of Relational
Algebra
83
Table 8.1 Operations of Relational
Algebra (continued)
84
Additional Relational Operations: Aggregate
Functions and Grouping
A type of request that cannot be expressed in the basic
relational algebra is to specify mathematical aggregate
functions on collections of values from the database.
Examples of such functions include retrieving the average or
total salary of all employees or the total number of employee
tuples.
◦ These functions are used in simple statistical queries that
summarize information from the database tuples.
Common functions applied to collections of numeric values
include
◦ SUM, AVERAGE, MAXIMUM, and MINIMUM.
The COUNT function is used for counting tuples or values.
85
Aggregate Function Operation
Use of the Aggregate Functional operation ℱ
◦ ℱMAX Salary (EMPLOYEE) retrieves the maximum salary value
from the EMPLOYEE relation
◦ ℱMIN Salary (EMPLOYEE) retrieves the minimum Salary value
from the EMPLOYEE relation
◦ ℱSUM Salary (EMPLOYEE) retrieves the sum of the Salary from
the EMPLOYEE relation
◦ ℱCOUNT SSN, AVERAGE Salary (EMPLOYEE) computes the count
(number) of employees and their average salary
Note: count just counts the number of rows, without removing
duplicates
86
Using Grouping with Aggregation
The previous examples all summarized one or more
attributes for a set of tuples
◦ Maximum Salary or Count (number of) Ssn
Grouping can be combined with Aggregate Functions
Example: For each department, retrieve the DNO, COUNT
SSN, and AVERAGE SALARY
A variation of aggregate operation ℱ allows this:
◦ Grouping attribute placed to left of symbol
◦ Aggregate functions to right of symbol
◦ DNO ℱCOUNT SSN, AVERAGE Salary (EMPLOYEE)
Above operation groups employees by DNO (department
number) and computes the count of employees and average
salary per department
87
Figure 8.10 The aggregate function operation.
a. ρR(Dno, No_of_employees, Average_sal)(Dno ℑ COUNT Ssn, AVERAGE Salary
(EMPLOYEE)).
b. Dno ℑ alary(EMPLOYEE).
c. ℑ COUNT Ssn, AVERAGE Salary(EMPLOYEE).
88
Figure 7.1a Results of GROUP BY and HAVING
(in SQL). Q24.
90
Figure 8.11 A two-level recursive query.
91
Additional Relational Operations (continued)
The OUTER JOIN Operation
◦ In NATURAL JOIN and EQUIJOIN, tuples without a matching
(or related) tuple are eliminated from the join result
Tuples with null in the join attributes are also eliminated
This amounts to loss of information.
◦ A set of operations, called OUTER joins, can be used when we
want to keep all the tuples in R, or all those in S, or all those in
both relations in the result of the join, regardless of whether or
not they have matching tuples in the other relation.
92
Additional Relational Operations (continued)
The left outer join operation keeps every tuple
in the first or left relation R in R S; if no
matching tuple is found in S, then the attributes
of S in the join result are filled or “padded”
with null values.
A similar operation, right outer join, keeps
every tuple in the second or right relation S in
the result of R S.
A third operation, full outer join, denoted by
94
Additional Relational Operations (continued)
OUTER UNION Operations
◦ The outer union operation was developed to take
the union of tuples from two relations if the
relations are not type compatible.
◦ This operation will take the union of tuples in two
relations R(X, Y) and S(X, Z) that are partially
compatible, meaning that only some of their
attributes, say X, are type compatible.
◦ The attributes that are type compatible are
represented only once in the result, and those
attributes that are not type compatible from either
relation are also kept in the result relation T(X, Y,
Z).
95
Additional Relational Operations (continued)
Example: An outer union can be applied to two relations
whose schemas are STUDENT(Name, SSN, Department,
Advisor) and INSTRUCTOR(Name, SSN, Department,
Rank).
◦ Tuples from the two relations are matched based on having the
same combination of values of the shared attributes— Name, SSN,
Department.
◦ If a student is also an instructor, both Advisor and Rank will have a
value; otherwise, one of these two attributes will be null.
◦ The result relation STUDENT_OR_INSTRUCTOR will have the
following attributes:
STUDENT_OR_INSTRUCTOR (Name, SSN, Department,
Advisor, Rank)
96
Examples of Queries in Relational Algebra :
Procedural Form
Q1: Retrieve the name and address of all employees
who work for the ‘Research’ department.
RESEARCH_DEPT DNAME=’Research’ (DEPARTMENT)
RESEARCH_EMPS (RESEARCH_DEPT DNUMBER=
EMPLOYEE)
DNOEMPLOYEE
97
Examples of Queries in Relational Algebra – Single
expressions
As a single expression, these queries become:
Q1: Retrieve the name and address of all
employees who work for the ‘Research’
department.
Fname, Lname, Address (σ Dname= ‘Research’
(DEPARTMENT
Dnumber=Dno(EMPLOYEE))
Q6: Retrieve the names of employees who
have no dependents.
Lname, Fname(( Ssn (EMPLOYEE) − ρ Ssn (
Essn (DEPENDENT))) ∗ EMPLOYEE)
98
Relational Calculus
A relational calculus expression creates a
new relation, which is specified in terms of
variables that range over rows of the stored
database relations (in tuple calculus) or over
columns of the stored relations (in domain
calculus).
In a calculus expression, there is no order of
operations to specify how to retrieve the
query result—a calculus expression specifies
only what information the result should
contain.
◦ This is the main distinguishing feature between
relational algebra and relational calculus.
99
Relational Calculus (continued)
Relational calculus is considered to be a
nonprocedural or declarative language.
This differs from relational algebra, where
we must write a sequence of operations to
specify a retrieval request; hence relational
algebra can be considered as a procedural
way of stating a query.
100
Tuple Relational Calculus
The tuple relational calculus is based on specifying a number
of tuple variables.
Each tuple variable usually ranges over a particular database
relation, meaning that the variable may take as its value any
individual tuple from that relation.
A simple tuple relational calculus query is of the form
{t | COND(t)}
◦ where t is a tuple variable and COND (t) is a conditional
expression involving t.
◦ The result of such a query is the set of all tuples t that satisfy
COND (t).
101
Tuple Relational Calculus (continued)
102
Languages Based on Tuple Relational Calculus
The language SQL is based on tuple calculus. It uses the
basic block structure to express the queries in tuple calculus:
◦ SELECT <list of attributes>
◦ FROM <list of relations>
◦ WHERE <conditions>
SELECT clausementions the attributes being projected, the
FROM clause mentions the relations needed in the query, and
the WHERE clause mentions the selection as well as the join
conditions.
103
End of Chapter Six
Thank You
104