Re: Can relational alegbra perform bulk operations?
Date: Tue, 29 Sep 2009 16:26:20 -0300
> 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
> 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?
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