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 relationalalgebra - why did SQL become the industry standard?

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

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Thu, 13 Feb 2003 13:51:40 -0000
Message-ID: <b2g807$su6$1@sp15at20.hursley.ibm.com>


"Anton Versteeg" <anton_versteeg_at_nnll.iibbmm.com> wrote in message news:3E4B9144.8CBC4296_at_nnll.iibbmm.com...
>
>
> Lauri Pietarinen wrote:
>
> > I don't think that anybody is suggesting that intermediate results need
> > to remove duplicates. It's
> > the end result that counts. E.g. in the following code fragment
> >
> >
>
> Well, I think that even for end results duplicates can be useful.

If you define 'end results' as not being the result of a relational query, but the result of some extra non-relational transformation of a relation then OK, but please don't try to argue that a database is best supported by a 'bag' algebra (or an array algebra, or a network algebra,...) rather than a relational algebra.

> It is the difference between the set theory and query results in practice.

No. It is not a case of theory not matching practice (which, if true, tells us that a theory is broken), rather it is the lack of a clear understanding of where relational algebra ends and something else (like array variable and values) picks up.

Of course theorists are sometimes guilty of over stating the scope of a theory, but much more usually it is the practitioners that do the try to apply a given theory outside of it's bounds.

> For instance: a set doesn't have an order but it would be impossible to
present
> results to a user of our database if we cannot order the end result.

We live in a four dimensional world, and there is order everywhere: up/down, left/right, before/after. Because of this we indeed cannot ever see or hear or feel or somehow sense a Relation per se. The best we can do is to logically transform an relation into say an array, then present such an array using some visual display unit, like a computer screen. Things like arrays, trees, lists etc are all slightly closer to being able to be sensed than relations (although I'm not sure one can really see an array either, all we see is light...)

> To give an example of the use of duplicates:
> Suupose we have a table that holds text (letters for instance).
> We would probably have a line number field and a text field.
> To improve readability we will have several occurrences of blank lines.
> If we then select the text column ordered by the line number, we will have
> (meaningful) duplicates in the end result.

OK, but just be clear such an 'end result' is not a relation and so any syntax to help produce such 'end results' is not part of a relational algebra. A logically clean syntax would be to 'cast' a relational query result to say an array, then further 'select' certain array elements for display in some specified(or unspecified) order.

Unfortunately SQL does not make such a clean separation. Regardless of it being a bag algebra (of sorts), it lets ORDER BY operate on it's bags without any explicit casting to a orderable non-scalar type such as an array.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Thu Feb 13 2003 - 07:51:40 CST

Original text of this message

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