Join operation

Different algorithm to implement joins are
Nested-loop join
Block nested-loop join
Indexed nested-loop join
Merge join
Hash join
Choice based on cost estimate
Example
Number of records of customer 10,000 depositor 5000
Number of blocks of customer 40 depositor 100

1.Nested-loop join
A nested loop join is a naive algorithm that
joins two sets by using two nested loops. Join
operations are important to database management.
Algorithm:
Two relations and are joined as follows:
For each tuple r in R do
For each tuple s in S do
If r and s satisfy the join condition
Then output the tuple <r,s>

This algorithm will involve nr*bs+ br block transfers and
nr+br seeks, where br and bs are number of blocks in
relations r and s respectively, and nr is the number of tuples
in relation r.
The algorithm runs in I/Os, where and is the number of
tuples contained in and respectively. Can easily be
generalized to join any number of relations.
The block nested loop join algorithm is a generalization of
the simple nested loops algorithm that takes advantage of
additional memory to reduce the number of times that the
relation is scanned.

2.Block nested-loop join
Algorithm:
for each block BR of R do begin
for each block BS of S do begin
for each tuple tR in BR do
for each tuple tS in BS do
check whether pair (tR; tS)
satises join condition
if they do, add tR tS to the result
end end end end
Also requires no indexes and can be used with any kind of join
condition.
Worst case: db buffer can only hold one block of each relation
=) br*bs+br disk accesses.
Best case: both relations t into db buffer
=) br+bs disk accesses.
If smaller relation completely ts into db buffer, use that as inner
relation. Reduces the cost estimate to BR + BS disk accesses.

3. Index Nested-Loop Join
 If an index is available on the inner loop's join attribute and join is
an equi-join or natural join, more efficient index lookups can
replace scans.
 It is even possible (reasonable) to construct index just to compute
a join.
 For each tuple tr in the outer relation R, use the index to lookup
tuples in S that satisfy join condition with tr
 Worst case: db buffer has space for only one page of R and one
page of the index associated with S:
 br disk accesses to read R, and for each tuple in R, perform
index lookup on S.
 Cost of the join: br+nr*c, where c is the cost of a single
selection on S using the join condition.
 If indexes are available on both R and S, use the one with the
fewer tuples as the outer relation.

4.Merge Join
Basic idea: first sort both relations on join attribute
(if not already sorted this way)
 Join steps are similar to the merge stage in the
external
sort-merge algorithm (discussed later)
 Every pair with same value on join attribute must
be matched.
values of join attributes
Relation R Relation S
1
2
2
3
4
5
1
2
3
3
5

If no repeated join attribute values, each tuple needs to be
read only once. As a result, each block is read only once.
Thus, the number of block accesses is BR + BS (plus the cost
of sorting, if relations are unsorted).
Worst case: all join attribute values are the same. Then the
number of block accesses is br*bs+br
If one relation is sorted and the other has a secondary B+-
tree index on the join attribute, a hybrid merge-join is
possible.
The sorted relation is merged with the leaf node entries of
the B+-tree. The result is sorted on the addresses (rids) of the
unsorted relation's tuples, and then the addresses can be
replaced by the actual tuples efficiently.

5.Hash-Join
only applicable in case of equi-join or natural join
A hash function is used to partition tuples of both
relations into sets that have the same hash value on
the join attribute
Partitioning Phase: 2 * Br+Bs block accesses
Matching Phase: Br+Bs block accesses
(under the assumption that one partition of each
relation ts into the database buffer)

OTHER OPERATIONS
Duplicate Elimination
Sorting: remove all but one copy of tuples
having identical value(s) on projection
attribute(s)
Hashing: partition relation using hash function
on projection attribute(s); then read partitions
into buffer and create in-memory hash index;
tuple is only inserted into index if not already
present

Set Operations:
Sorting or hashing
Hashing: Partition both relations using the same
hash function; use in-memory index for partitions Ri
R U S: if tuple in Ri or in Si, add tuple to result
∩: if tuple in Ri and in Si, . . .
- : if tuple in Ri and not in Si, . . .

Grouping and aggregation:
Compute groups via sorting or hashing.
Hashing: while groups (partitions) are built,
compute partial aggregate values (for group
attribute A, V(A,R) tuples to store values)

Evaluation of Expressions
Alternatives for evaluating an entire expression tree
are
Materialization: generate results of an expression
whose inputs are relations or are already computed,
materialize it on disk. repeat
Pipelining: pass on tuples to parent operations even
as an operation is being executed.

Evaluation of Expressions
Strategy 1: materialization. Evaluate one operation
at a time, starting at the lowest level. Use
intermediate results materialized in temporary
relations to evaluate next level operation(s).
Example: in figure below, compute and store.
σ balance<2500(account) the store its join with customer and finally
compute the projections on customer name.
Лcustomer name
∞
Лbalance<2500 customer
account

 Materialized evaluation is always applicable.
Cost of writing results to disk and editing them
back can be quite high.
overall cost = sum of cost of individual
operations + cost of writing intermediate results to
disk.
Double Buffering: use two O/P buffer for each
operation, when one is full write it to disk while
the other is getting filled, reduced execution time.

Strategy 2: pipelining. evaluate several
operations simultaneously, and pass the result
(tuple- or block-wise)on to the next operation.
In the example above, once a tuple from
OFFERS satisfying selection condition has been
found, pass it on to the join. Similarly, don't store
result of (final) join, but pass tuples directly to
projection.
Much cheaper than materialization, because
temporary relations are not generated and stored
on disk.

Pipelining is not always possible, e.g., for all
operations that include sorting (blocking
operation).
Pipelining can be executed in either demand
driven or producer driven fashion.

DATABASE TUNINIG
Tuning:
The process of continuing to revise/adjust the physical
database design by monitoring resource utilization as well as
internal DBMS processing to reveal bottlenecks such as
contention for the same data or devices.
Goal:
To make application run faster
To lower the response time of queries/transactions
To improve the overall throughput of transactions

Tuning Indexes
Reasons to tuning indexes
Certain queries may take too long to run for lack of
an index;
Certain indexes may not get utilized at all;
Certain indexes may be causing excessive overhead
because the index is on an attribute that undergoes
frequent changes
Options to tuning indexes
Drop or/and build new indexes
Change a non-clustered index to a clustered index
(and vice versa)
Rebuilding the index

Tuning the Database Design
Dynamically changed processing requirements
need to be addressed by making changes to the
conceptual schema if necessary and to reflect
those changes into the logical schema and
physical design.
Tuning Queries
Indications for tuning queries
A query issues too many disk accesses
The query plan shows that relevant indexes
are not being used.

Join operation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Join operation

Similar to Join operation (20)

Recently uploaded

Recently uploaded (20)

Join operation