# Re: Can relational alegbra perform bulk operations?

Date: Tue, 29 Sep 2009 16:26:20 -0300

Message-ID: <4ac25f5f$0$23753$9a566e8b_at_news.aliant.net>

Banana wrote:

*> I'm new to relational theory, having read a C.J. Date's book but I worry *

*> that I may have picked up mistaken impression about the relational *

*> theory and thus want to validate whether my understanding is accurate or *

*> not.*

*> *

*> Prior to reading the book, I've always had understood that anything we *

*> did in realm of relational algebra (or calculus) would be set-oriented *

*> and to lesser extent sames applies to the SQL implementation, at least *

*> in the theory (as not all vendors necessarily are consistent in the *

*> implementation). Given that any kind of update operation is logically *

*> all at once, I was quite concerned with the manners of updating itself.*

*> *

*> Given two relvars, r and s, containing some numbers of attributes, *

*> sharing a common attribute (or in more general parlance, s relvar *

*> contains a foreign key to relvar r's candidate key), and we wish to *

*> evalulate an expression upon the relvar r and s. Assume the evaluate *

*> will include restrict, project and join, though we need not restrict to *

*> only those three operators.*

*> *

*> Relational algebra, like ordinary algebra, can be employed in help us *

*> re-formulate the expression into a even simpler expression, with the net *

*> result that we can reduce the numbers of tuples to be evaluated as we *

*> process the expression. This can be done by examining the operators' *

*> properties such as joins having the commutative property and thus *

*> choosing the smaller relvar and evaluate its tuples against the bigger *

*> relvar's tuples. So far, so good. We can see how much relational *

*> algebra/calculus can help us optimize any kind of queries by *

*> transforming the expression.*

*> *

*> But... I don't see any means within the relational algebra that provides *

*> a way of evaluating multiple tuples in one go. Considering that a *

*> relation is essentially a collection of propositions conforming to a *

*> given predicate, it seems necessary to evaluate each tuples to determine *

*> whether they should participate in the join or not, satisfy the restrict *

*> condition and other things. For a lack of better terms, there is no *

*> "sieve" we can employ to evaluate a set of tuples in one go.*

*> *

*> Is the preceding paragraph accurate?*

*> *

** > TIA.
**
What you appear to be looking for is a physical structure not a logical
one, which in SQL one would build with the "CREATE INDEX" statement.
Received on Tue Sep 29 2009 - 14:26:20 CDT