Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

From: Mikito Harakiri <mikharakiri_at_ywho.com>
Date: Tue, 18 Feb 2003 15:43:50 -0800
Message-ID: <lEz4a.23$h_3.149@news.oracle.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:OOy4a.31$yy3.2993280_at_mantis.golden.net...
> > > Are you saying that a set-based relational dbms with full support for
> > > domains would not allow the user to freely transform data among
> > > representations?
> >
> > Please, write down a query that transforms
> >
> > Num
> > ---
> > 2
> > 5
> >
> > into
> >
> > Seq# Num
> > ---- ---
> > 1 2
> > 2 2
> > 1 5
> > 2 5
> > 3 5
> > 4 5
> > 5 5
> >
> > in pure relational syntax. Now, the same, please, without
> explode/recursion
> > operator.
>
> First, we will have to give a name to the original relation containing the
> Num column. I will use Foo for convenience. The solution follows:
>
> ( ( Integer RENAME Value as Seq# ) JOIN Foo ) RESTRICT Seq# BETWEEN 1 AND
> Num )
>
> I assume that Integer is a named relation literal for the set of all
> integers and that it has a single attribute, Value.

The relational model is silent about the Integer Relation, of course. Alas, this is something many users are constantly asking for.

Is Integer a base relation or a view?

> In practice, Integer
> would be a named relation literal for a set of integers within some large
> finite range of values.

With a disclaimer like this, how could you insist that Relational Model "allows the user to freely transform data among representations"?

> Because the operands to the JOIN operation share no
> attributes, the JOIN will, of course, evaluate to a cartesian product;
> however, even the most primitive optimizers will evaluate the restriction
> before the join.

Correct. The above relation should be executed as a Nested Loops where inner relation -- Integer -- is range scanned (with the "restrict" predicate).

> Mikito, I cannot imagine why you would seriously consider recursion for
such
> a simple expression. Was there some mistake or typo in your challenge?

Recursion is a way to generate integers which is not constrained by some artificially chosen upper bound.

> If you do not like the named literals, we could replace Foo and Integer
> above with some suitable anonymous literals:
>
> Foo := RELATION ( TUPLE ( Num INTEGER( 2 ) ), TUPLE( Num INTEGER( 5 ) ) );
> Integer := RELATION (
> TUPLE ( Value INTEGER( 1 ) )
> , TUPLE ( Value INTEGER( 2 ) )
> , TUPLE ( Value INTEGER( 3 ) )
> , TUPLE ( Value INTEGER( 4 ) )
> , TUPLE ( Value INTEGER( 5 ) )
> );

Did I really have to explicitly say "the solution must also work for numbers in the Foo other than 1,2,3,4,5" ? Received on Tue Feb 18 2003 - 17:43:50 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US