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: Wed, 19 Feb 2003 17:29:18 -0000
Message-ID: <b30f0c$17a2$1@sp15at20.hursley.ibm.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:8bR3a.84$2W5.14858339_at_mantis.golden.net... [snip]
> >
> > CAST_AS_ARRAY(select SUM(SAL), DEPT from emp)
> > Y_ORDERED_BY SAL
> >
> > would be logicaly more correct that the SQL syntax, but finding a nice
> syntax
> > (which that above certainly is not) is another matter.
>
> I disagree. What you have given above involves a redundant type conversion
> that the dbms should optimize away in any case. The final result of the
> operation is not an array--it is an external physical representation of a
> set of tuples in an explicit order.

I agree, more or less.

I'm a relational imperalist. I would like to see the rigour of relational theory expand out from its home teroroy of relations onto some of the other more common non-scarlar types out there.

A relational isolationist is happy to just leave relations as the interface between the closed world of the RDMBS and the outside world. I however, would like to see RDBMS systems that can present data in lots of differnet non-scalar types (including, unfortuantly, XML. Although I think it will be thought provoking using things like XTABLES and XQuery when they get released into the wild).

In the above example, my display tool might only understand ARRAYs so therefore I must cast any relational result to an ARRAY type. Even if my display tool does support relations nativly, I am claiming that another *intermediate* non-scalar type such as an ARRAY is probably a better basis for the 'logical model' that the user interacts with when scrolling and re-ordering any displayed data. Selections, updates etc could be at both logical levels with a direct mapping between the two. I.e. use the mouse to select one cell of the array <-> some relational selection statement. The deletion of an array row <-> the deltion of a tuple. It is this direct mapping of selection and manipulation aspects of mapped non-scalar types that requires DMBS support rather than isolationist rejection.

Question. Is the mapping of an ARRAY to a RELATION, not infact a mapping of an ARRAY to a DATABASE (i.e. a collection of RELATIONs) because the collection of relations would also include a 'meta-data' relation that describes the order of attributes and tuples in the ARRAY that is otherwise lost in the mapping? I say yes.

BTW, do the people here think that a DATABASE is a good term for a 'set' of RELATIONs? or is there another, better term around. For that matter is calling a DATABASE a 'set' of relations a gross misuse of the term set and so 'collection' is better?

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Feb 19 2003 - 11:29:18 CST

Original text of this message

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