0% found this document useful (0 votes)
2 views

Ch4 Algebra

The document discusses relational algebra as a foundational aspect of relational query languages, emphasizing its operational nature and utility in query execution plans. It outlines various operations such as selection, projection, and joins, as well as the importance of query optimization for efficient data retrieval. Additionally, it highlights the distinction between relational algebra and relational calculus, and provides examples of how to express complex queries.

Uploaded by

dhanvin.vihas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

Ch4 Algebra

The document discusses relational algebra as a foundational aspect of relational query languages, emphasizing its operational nature and utility in query execution plans. It outlines various operations such as selection, projection, and joins, as well as the importance of query optimization for efficient data retrieval. Additionally, it highlights the distinction between relational algebra and relational calculus, and provides examples of how to express complex queries.

Uploaded by

dhanvin.vihas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Relational

Algebra

Database Management Systems 3ed, R. Ramakrishnan and J. 1


Gehrke

Relational Query Languages


Query languages: Allow manipulation and
retrieval of data from a database.
Relational model supports simple, powerful QLs:
Strong formal foundation based on logic.
Allows for much optimization.
Query Languages != programming languages!
QLs not expected to be “Turing complete”.
QLs not intended to be used for complex
calculations. QLs support easy, efficient
access to large data sets.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 2

Formal Relational Query


Languages
Two mathematical Query Languages
form the basis for “real” languages
(e.g. SQL), and for implementation:
Relational Algebra: More operational,
very useful for representing execution
plans.
Relational Calculus: Lets users describe
what they want, rather than how to compute
it. (Non- operational, declarative.)

Database Management Systems 3ed, R. Ramakrishnan and 3


J. Gehrke
Preliminaries
A query is applied to relation instances,
and the result of a query is also a relation
instance.
Schemas of input relations for a query are
fixed (but query will run regardless of
instance!)
The schema for the result of a given query is
also fixed! Determined by definition of query
language constructs.
Positional vs. named-field notation:
Positional notation easier for formal
definitions, named-field notation more
readable.
Both used in SQL
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 4

R1 sid bid day


Example 22 101 10/10/96
Instances
“Sailors” and 58 103 11/12/96
“Reserves” relations S1
for our examples. sid sname rating age
We’ll use positional or
named field notation, 22 dustin 7 45.0
assume that names of 31 lubber 8 55.5
fields in query results
are 58 rusty 10 35.0
`inherited’ from names S2
of fields in query input sid sname rating age
relations.
28 yuppy 9 35.0
31 lubber 8 55.5
44 guppy 5 35.0
Database Management Systems 3ed,
Gehrke
58and J.rusty
R. Ramakrishnan 10 35.0 5

Relational
Algebra
Selection ( ) Selects a subset of rows from
Projection ( ) Deletes unwanted columns from
relation.
relation.
Cross-product ( 
) Allows us to combine two
relations.
Set-difference ( ) Tuples in reln. 1, but not in

reln. 2.
Union ( ) Tuples in reln. 1 and in reln. 2.
Additional operations:
Intersection, join, division, renaming: Not
essential, but (very!) useful.
Since each operation returns a relation,
operations can be composed! (Algebra is
Database Management Systems 3ed, R. Ramakrishnan and
J. Gehrke
6
sname ratin
Projection g
yuppy 9
Deletes attributes that are lubber 8
not in guppy 5
projection list. rusty 10
Schema of result contains  sname (S2)
exactly the fields in the ,rating
projection list, with the same
names that they had in the
(only) input relation.
Projection operator has to age
eliminate duplicates! (Why??) 35.0
Note: real systems 55.5
typically don’t do
duplicate elimination
unless the user explicitly
 age (S2)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 7

si sname rating
Selection d age yuppy 9
28
Selects rows that 58 35.0
satisfy rating  (S2)
selection condition. 8
No duplicates in
result! (Why?)
Schema of result
identical to schema
of (only) input sname rating
relation.
yuppy 9
Result relation can
be the input for rusty 10
another relational  ( (S2))
algebra operation! sname,rating rating  8
(Operator
Database Management Systems 3ed, R. Ramakrishnan and J. 8
Gehrke

Union, Intersection, Set-


Difference
All of these operations
sid sname rating age
take two input relations, 22 dustin 7 45.0
which must be union- 31 lubber 8 55.5
compatible:
58 rusty 10 35.0
Same number of
44 guppy 5 35.0
fields.
28 yuppy 9 35.0
`Corresponding’ S1 S2
fields have the
same type.
sid sname rating age
sid rating age 31 lubber 8 55.5
sname 58 rusty 10 35.0
22 S1 S2
dustin 7 45.0 S1
Database Management Systems 3ed, R. Ramakrishnan and
J. Gehrke
S2 9
Cross-Product
Each row of S1 is paired with each row of
R1.
Result schema has one field per field of S1
and R1, with field names `inherited’ if
possible.
Conflict: Both
(sid) sname ratingS1
ageand
(sid)R1
bidhave
day a field
22 dustin 7 45.0 22 101 10/10/9
6
22 dustin 7 45.0 58 103 11/12/9
6
31 lubber 8 55.5 22 101 10/10/9
6
31 lubber 8 55.5 58 103 11/12/9
6
Renaming 58 operator
rusty : 
10 (C(1
35.0 22 sid1, 5 sid2),
101 10/10/9 S1 R1)
6
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 10
58 rusty 10 35.0 58 103 11/12/9
6

Joins
Condition Join: R c S   c (R 
S)

(sid) snameS1 S age (sid) bid day


rating 1.sid  R1.sid
22Result
dustin 7 R1same
schema 45.0as 58
that of cross-
103 11/12/9
31product.
lubberFewer
8 tuples
55.5 than
58 cross-
103 6
product, might be able to compute 11/12/9
more efficiently 6
Sometimes called a theta-join.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 11

Joins
Equi-Join: A special case of condition join
where the condition c contains only
equalities.

S1 sid R1
Result schema similar to cross-product, but
onlysidone sname
copy ofrating
fields for which equality
age bid day
is specified. Natural Join: Equijoin on all
22 dustin 7 45.0 10/10/9
common fields.
Database Management Systems 3ed, R. Ramakrishnan and 12
J. Gehrke
58 rusty 10 101 6
35.0 11/12/9
103 6

Database Management Systems 3ed, R. Ramakrishnan and 12


J. Gehrke
Division
Not supported as a primitive operator, but
useful for expressing queries like:
Find sailors who have reserved all boats.
Let A have 2 fields, x and y; B have only
A/By:=  x |  x, y  A  y  B
field
i.e., A/B contains all x tuples (sailors) such
that for every y
tuple (boat) in B, there is an xy tuple in A.
Or: If the set of y values (boats) associated with an
x value (sailor) in A contains all y values in B, the x
value is in A/B.
In general, x and y can be any lists of fields; y
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 13

Examples of Division
A/B
sno pno pno pno pno
s1 p1 p2 p2 p1
s1 p2 p4 p2
B
s1 p3 p4
s1 p4
1 B2
s2 p1 sno B3
s2 p2 s1
s3 p2 s2 sno
s4 p2 s3 s1 sno
s4 p4 s4 s4 s1

A A/B1 A/B2 A/B3


Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 14

Expressing A/B Using Basic


Operators
Division is not essential op; just a useful
shorthand. (Also true of joins, but joins are so
common that systems implement joins specially.)
Idea: For A/B, compute all x values that are
not
`disqualified’ by some y value in B.

Disqualified x  x (( x (A) B)


values:
A/B:  x (A)  allA)disqualified
tuples
Database Management Systems 3ed, R. Ramakrishnan and 15
J. Gehrke
Find names of sailors who’ve reserved
boat # 103

Solution 1: sname(( Reserves) Sailors)


bid 103

Solution 2:  (Temp1,  Reserves)


bid 103
 (Temp2, Temp1 Sailors)
 sname (Temp2)

Solution  sname( (Reserves Sailors))


bid 103
3:
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 16

Find names of sailors who’ve


reserved a red boat

Information about boat color only


available in Boats;Boats)
so need an extra join:
 sname (( Reserves Sailors)
color ' red '

A more efficient solution:


 sname ( ((  Boats) Re s) Sailors)
sid bid color ' red '

A query optimizer can find this, given the first solution!


Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 17

Find sailors who’ve reserved a red or a


green boat
Can identify all red or green boats, then
find sailors who’ve reserved one of these
boats:

 sname(Tempboats Reserves Sailors)

Can also define Tempboats using union!


(How?)
What happens if  is replaced by  in this
Database Management Systems 3ed, R. Ramakrishnan and 18
J. Gehrke
Find sailors who’ve reserved a red and a
green boat

Previous approach won’t work! Must


identify sailors who’ve reserved red
boats, sailors who’ve reserved green
boats, then find the intersection (note
that sid is a key for Sailors):
 (Tempred,  (( Boats) Reserves))
sid color ' red '
 (Tempgreen,  (( Boats) Reserves))
sid color ' green'
 sname((Tempred  Tempgreen) Sailors)

Find the names of sailors who’ve


reserved all boats

Uses division; schemas of the input


relations to / must be carefully
chosen:

 (Tempsids, ( Re serves) / ( Boats))


sid,bid bid
 sname (Tempsids Sailors)

.... / (
. bid bname ' Interlake'
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 20

Summary

The relational model has rigorously


defined query languages that are
simple and powerful.
Relational algebra is more operational;
useful as internal representation for
query evaluation plans.
Several ways of expressing a given
query; a query optimizer should
choose the most efficient version.

Database Management Systems 3ed, R. Ramakrishnan and 21


J. Gehrke

You might also like