# 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 - 21:26:20 CEST