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

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:otu4a.13$h_3.136_at_news.oracle.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:KZh4a.9$k32.1286180_at_mantis.golden.net...
> > "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
> > news:ckb4a.14$7H6.123_at_news.oracle.com...
> > I disagree. What it says actually depends on the full
predicate--internal
> > and external--and not on whether Item represents a set or a multiset. To
> my
> > anglophone human eyes, it looks like it says Milk is an Item.
>
> My typo, again. In multiset model we have
>
> Item
> ----
> Milk
> Milk
> Soda (no pun intended:-)
>
> whereas, in set model
>
> Item Count
> ---- -----
> Milk 2
> Soda 1
>
> Now, the first entry in the multiset model tells that there is at least
one
> Milk container, while the first entry in the set model tells us that there
> are exactly 2 containers. The set model has more precision, here, granted.

The first entry in the set model also tells that there is at least one Milk container, and one must rely on physical position to know that the second row in the multiset model even exists.

> > 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. In practice, Integer would be a named relation literal for a set of integers within some large finite range of values. 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.

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

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 ) )

> > The distinction [between physical and logical] is an important one.
> > You do yourself a disservice by losing sight of it.
>
> There are limitations of every model. The question always is if the goals
> that one wishes to achieve warrant changing the model.

I have yet to see anyone describe any goal warranting the use of multisets as the basis of a logical data model as opposed to using relations. Given the necessary loss of logical identity and physical independence, I have difficulty assuming such a goal exists until proved otherwise. While mathematicians may someday supplant the relational model as the best theory-based logical data model, I don't expect it to happen tomorrow.

We are talking about abandoning thousands of years of incremental developments in the field of logic. Those sorts of things rarely ever happen and certainly do not happen overnight. Received on Tue Feb 18 2003 - 23:27:49 CET