Scribd
Upload
4 views10 pages

class5.PPT

Uploaded by

shivacharanreddypatlolla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
4 views10 pages

class5.PPT

Uploaded by

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

Relational Algebra

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

<number
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.)

• Understanding Algebra & Calculus is key to


• understanding SQL, query processing!
<number
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 Relational Algebra and SQL
<number
R1
Example Instances

• “Sailors” and “Reserves”


relations for our S1
examples.
• We’ll use positional or
named field notation,
assume that names of
fields in query results are
`inherited’ from names S2
of fields in query input
relations.

<number
Relational Algebra
• Basic operations:
⚬ Selection ( ) Selects a subset of rows from relation.
⚬ Projection ( ) Deletes unwanted columns from 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 “closed”.)

<number
Projection
• Deletes attributes that are not in
projection list.
• Schema of result contains exactly
the fields in the projection list,
with the same names that they
had in the (only) input relation.
• Projection operator has to
eliminate duplicates! (Why??)
⚬ Note: real systems typically
don’t do duplicate elimination
unless the user explicitly asks
for it. (Why not?)

<number
Selection

• Selects rows that satisfy


selection condition.
• No duplicates in result!
(Why?)
• Schema of result
identical to schema of
(only) input relation.
• Result relation can be
the input for another
relational algebra
operation! (Operator
composition.)

<number
Union, Intersection, Set-
Difference
• All of these operations
take two input relations,
which must be union-
compatible:
⚬Same number of
fields.
⚬`Corresponding’ fields
have the same type.
• What is the schema of
result?

<number
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 S1 and R1 have a field
called sid.

<number

You might also like