2009-03-18 04:42:48 +07:00
|
|
|
|
|
|
|
Complexity
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
Purpose of this document is to describe in a detailed way the
|
|
|
|
complexity of relational algebra operations. The evaluation will be
|
|
|
|
done on the specific implementation of this program, not on theorical
|
|
|
|
lower limits.
|
|
|
|
|
|
|
|
Latest implementation can be found at:
|
|
|
|
http://galileo.dmi.unict.it/svn/trunk
|
|
|
|
|
|
|
|
Notation
|
|
|
|
Big O notation will be used. Constant values will be ignored.
|
|
|
|
|
|
|
|
Single letters will be used to indicate relations and letters between
|
|
|
|
| will indicate the cardinality (number of tuples) of the relation.
|
2009-03-19 07:56:15 +07:00
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
Number of tuples can't be enough. For example a relation with one
|
|
|
|
touple and thousands of fields, will not take O(1) in general to be
|
|
|
|
evaluated. So we assume that relations will have a reasonable and
|
|
|
|
comparable number of fields.
|
|
|
|
|
2009-03-19 07:56:15 +07:00
|
|
|
Then after evaluating the big O notation, an attempt to find more
|
|
|
|
precise results will be done, since it will be important to know
|
|
|
|
with a certain precision the weight of the operation.
|
2009-03-18 04:42:48 +07:00
|
|
|
|
|
|
|
1. UNARY OPERATORS
|
|
|
|
|
2009-03-18 04:58:25 +07:00
|
|
|
Relational defines three unary operations, and they will be studied
|
|
|
|
in this section. It doesn't mean that they should have similar
|
|
|
|
complexity.
|
|
|
|
|
2009-03-18 04:42:48 +07:00
|
|
|
1.1 Selection
|
2009-03-18 04:58:25 +07:00
|
|
|
|
|
|
|
Selection works on a relation and on a python expression. For each
|
|
|
|
tuple of the relation, it will create a dictionary with name:value
|
|
|
|
where name are names of the fields in the relation and value is the
|
|
|
|
value for the specific row.
|
|
|
|
We can consider the inner cycle as constant as its value doesn't
|
|
|
|
depend on the relation itself but only on the kind of the relation
|
|
|
|
(how many field it has).
|
|
|
|
Then comes the evaluation. A python expression in truth could do
|
|
|
|
much more things than just checking if a>b. Anyway, ssuming that
|
|
|
|
nobody would ever write cycles into a selection condition, we have
|
|
|
|
another constant complexity for this operation.
|
|
|
|
Then, the tuple is inserted in a new relation if it satisfies the
|
|
|
|
condition. Since no check on duplicated tuples is performed, this
|
|
|
|
operation is constant too.
|
|
|
|
|
|
|
|
In the end we have O(|n|) as complexity for a selection on the
|
|
|
|
relation n.
|
|
|
|
|
2009-03-18 04:42:48 +07:00
|
|
|
1.2 Rename
|
2009-03-18 04:58:25 +07:00
|
|
|
|
2009-03-19 07:56:15 +07:00
|
|
|
The rename operation itself is very simple, just modify the list
|
|
|
|
containing the name of the fields.
|
|
|
|
The big issue is to copy the content of the relation into a new
|
|
|
|
relation object, so the new one can be modified.
|
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
So the operation depends on the size of the relation: O(|n|).
|
2009-03-19 07:56:15 +07:00
|
|
|
|
|
|
|
1.3 Projection
|
|
|
|
|
2009-04-01 08:37:56 +07:00
|
|
|
The projection operation creates a copy of the original relation
|
|
|
|
using only a subset of its fields. Time for the copy is something
|
2009-04-01 09:30:19 +07:00
|
|
|
like O(|n|) where f is the number of fields to copy.
|
2009-04-01 08:37:56 +07:00
|
|
|
But that's not all. Since relations are set, duplicated items are not
|
|
|
|
allowed. So after extracting the wanted elements, it has to check if
|
|
|
|
the new tuple was already added to the new relation. And this brings
|
2009-04-01 09:30:19 +07:00
|
|
|
the complexity to O(|n|²).
|
2009-03-19 07:56:15 +07:00
|
|
|
|
2009-04-01 08:40:21 +07:00
|
|
|
2. BINARY OPERATORS
|
|
|
|
|
|
|
|
Relational defines nine binary operations, and they will be studied
|
2009-04-01 09:30:19 +07:00
|
|
|
in this section. Since we will deal with two relations per operation
|
|
|
|
here, we will call them m and n, and f and g will be the number of
|
|
|
|
their fields.
|
2009-04-01 08:40:21 +07:00
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
2.1 Product
|
|
|
|
|
|
|
|
Product is a very complex operations. It is O(|n|*|m|).
|
|
|
|
Obvious.
|
2009-04-01 08:40:21 +07:00
|
|
|
|
|
|
|
2.2 Intersection
|
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
Same as product even if it does a different thing. But it has to
|
|
|
|
compare every tuple from n with every tuple from m, to see if they
|
|
|
|
match, and in this case, put them in the resulting relation.
|
|
|
|
So this operation is O(|n|*|m|) as well.
|
|
|
|
|
2009-04-01 08:40:21 +07:00
|
|
|
2.3 Difference
|
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
Same as above:
|
|
|
|
|
2009-04-01 08:40:21 +07:00
|
|
|
2.4 Union
|
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
This operation first creates a new relation copying all the tuples
|
|
|
|
from one of the originating relations, then compares them all with
|
|
|
|
tuples from the other relation, and if they aren't in, they will be
|
|
|
|
added.
|
|
|
|
In fact it is same as above: O(|n|*|m|)
|
|
|
|
|
2009-04-01 08:40:21 +07:00
|
|
|
2.5 Thetajoin
|
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
This operation is the combination of a product and a selection. So it
|
|
|
|
is O(|n|*|m|) too.
|
|
|
|
|
2009-04-01 08:40:21 +07:00
|
|
|
2.6 Outher
|
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
This operation is the union of the outer left and the outer right
|
|
|
|
join. Makes it O(|n|*|m|) too.
|
|
|
|
|
2009-04-01 08:40:21 +07:00
|
|
|
2.7 Outher_left
|
2009-04-01 09:30:19 +07:00
|
|
|
|
|
|
|
O(|n|*|m|), very depending on the number of the fields, because they
|
|
|
|
are compared.
|
2009-04-01 08:40:21 +07:00
|
|
|
|
|
|
|
2.8 Outher_right
|
|
|
|
|
2009-04-01 09:30:19 +07:00
|
|
|
Mirror operation of outer_lef
|
|
|
|
|
2009-04-01 08:40:21 +07:00
|
|
|
2.9 Join
|
2009-04-01 09:30:19 +07:00
|
|
|
|
2009-04-03 14:03:02 +07:00
|
|
|
Same as above.
|
2009-04-01 09:30:19 +07:00
|
|
|
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|