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

Date: Fri, 21 Feb 2003 03:04:31 -0500

Message-ID: <8sl5a.167$Nn.17704103_at_mantis.golden.net>

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:b2vnic$uhu$1_at_sp15at20.hursley.ibm.com...

> "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
**> > 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.

In their treatment of temporal databases, Date, Darwen and Lorentzos rely quite heavily on interval type generators. An interval type generator can generate an interval for any type with a total ordering. ie. a type with a unique first, a unique last, a successor for every value except the last and a predecessor for every value except the first.

One could define a view for every totally ordered type using their UNPACK operator and the interval type generator. Interestingly, such a view might also be considered a literal because it specifies a selector for a relation whose arguments are all literals.

> Bob where do you get the 'named literal' concept from? Sounds like a

Dateism

> but I can't recall seeing it.

Literals are very common in programming so it's really not a new concept for me. I work with named literals all the time. 'Nothing' and "vbCRLF" in visual basic, for instance. Pi is defined in some languages I have worked with. True and False are often named literals for 1 and 0. However, I do believe Date and Darwen deal with literals in TTM. For instance, a selector whose arguments are all literals is a literal so they have to deal with the concept at some point.

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

A precise definition need not enumerate all possible values. A stream datatype would have a large number of possible values as would a variable length character string type.

> I suggest that the type INTEGER has an infinite number of values, and

*> therefore is at best an 'abstract' type.
*

Of course. Real is an abstract type too. On any physical computer system, we make do with a tiny, tiny subset of Rationals when we really want Reals.

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.*

I disagree that it really messes anything up. The rationals are already approximations. X=1 and Y=1 really represents a point in some small area of 1-epsilon to 1+epsilon. As long as the polar representation has a representable value in that area, I see no problems. Even if the polar representation has no value in that area, but a point near that area I'm still okay with it.

*>
**> Regards
**> Paul Vernon
*

> Business Intelligence, IBM Global Services

Received on Fri Feb 21 2003 - 09:04:31 CET