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
"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> > "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
> 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.
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
> > > "allows the user to freely transform data among representations"?
> > If you prefer to completely ignore practice, simply omit the disclaimer.
> > is not required for the example. Otherwise, when we have an artifact
> > of representing each of an infinite set of elements in finite time, let
> > 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.
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
> with INGEGER_+/-_2^15 being a subtype of INGEGER_+/-_2^31.
> This is the kind of idea Date & Darwen propose when considering interval
> 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
> example of a type with mutiple possiable representations. I.e.
> A geometric POINT type with both CARTESIAN and POLAR possible
> that use RATIONAL numbers only (for the representations) would be rather
> limited because many rational CARTESIAN representations map to
> 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
> those point values that are expressable using RATIONALs in both of the two
> representations. Ruling out X=1, Y=1 for one.
Examples of practical types might be
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.
> Paul Vernon
> Business Intelligence, IBM Global Services
Received on Fri Feb 21 2003 - 09:04:31 CET