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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:oKD4a.62$6q4.6244403_at_mantis.golden.net...
> "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
> > The relational model is silent about the Integer Relation, of course.
> Alas,
> > this is something many users are constantly asking for.

Why Alas? I've never understood why such things don't seem to be part of the model.

> > Is Integer a base relation or a view?
>
> It is a named literal. It is neither stored nor derived from another
> relation.

Whatever it is, it is certainly not updateable, but I'ld want one for every domain defined in a database.

Bob where do you get the 'named literal' concept from? Sounds like a Dateism but I can't recall seeing it.

> > > 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"?
>
> If you prefer to completely ignore practice, simply omit the disclaimer. It
> is not required for the example. Otherwise, when we have an artifact capable
> of representing each of an infinite set of elements in finite time, let me
> know, and I'll get back to you.

Any datatype should define *precisely* the set of values that it contains.

I suggest that the type INTEGER has an infinite number of values, and therefore is at best an 'abstract' type. Examples of practical types might be

     INGEGER_+/-_10^31
     INGEGER_+/-_2^63
     INGEGER_+/-_2^31
     INGEGER_+/-_2^15

with INGEGER_+/-_2^15 being a subtype of INGEGER_+/-_2^31.

This is the kind of idea Date & Darwen propose when considering interval types based on DECIMAL(n,m) in their new book on temporal data. They show a nice type lattice for DECIMALs where n < 4 and m < 4.

All very interesting, although I did note that it rather messes up thier usual example of a type with mutiple possiable representations. I.e.

A geometric POINT type with both CARTESIAN and POLAR possible representations that use RATIONAL numbers only (for the representations) would be rather limited because many rational CARTESIAN representations map to non-rational POLAR representations and vis-versa.
x = 1, y = 1 <-> r = SQRT(2), theta = 45 degrees

but SQRT(2) is not a rational number.

Without say a non-abstract REAL number type, a POINT type with rational CARTESIAN and POLAR poss representations would need to be limited to exactly those point values that are expressable using RATIONALs in both of the two representations. Ruling out X=1, Y=1 for one.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Feb 19 2003 - 11:38:04 CET