Re: temporary databases

"Mikito Harakiri" <mikharakiri_at_yahoo.com> wrote in message news:bdf69bdf.0206070934.3bb297b2_at_posting.google.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:<4fXL8.25117$H%2.196428937_at_radon.golden.net>...
>
> Welcome back, Bob.

Thanks! It's good to be back!

> > For all practical purposes, all intervals within a DBMS represent a set
of
> > discrete points. As a result, a tuple that has an interval attribute
> > represents a set of discrete propositions. In the absence of any
interval
> > attributes, a tuple represents a single proposition.
>
> Interval represented as a set of discrete points is just one
> possibility, and probably not the best one.

Well, given that Date et al. have developed interval type generator extended short-cuts for dealing with referential integrity, relational operators etc. and given that they have demonstrated the familiar integrity constraints, operators etc. are simply special cases of the new ones, one has quite a hurdle to clear to demonstrate that the choice is not a good one. While one might pretend that an interval contains an infinite set of points, until humans develop infinite artifacts it's a moot point.

> Given an interval defined
> by its 2 boundary points and discretisation step, one can always query
> all discrete points within the interval.
>
> Therefore, I would represent an interval by just 2 timestamp columns.

Time intervals are not the only interval types. Two timestamp columns hardly qualify as a general solution to the problem, and in a theory newsgroup all possible representations of a type are equally valid.

> It is unnecessary to consider it as a single object with 13(!)
> operations.

I am sorry. Do you suffer from triskaidekaphobia?

> > This affects the integrity function, the manipulation function etc.
> >
> > Consider an HOURS relation with a single interval column representing
the
> > hours of operation and an APPT relation with an interval column
representing
> > the time and duration of appointments plus other columns identifying the
> > customer and reason etc.
> >
> > One would like to declare an integrity constraint that the discrete
points
> > represented by any APPT interval are a subset of the points represented
by
> > the HOURS relation. Likewise, one would like to declare an integrity
> > constraint that the discrete points represented by all APPT intervals
are
> > unique within APPT. One would like uniqueness within the discrete points
of
> > time represented by the HOURS relation too.
>
> More simple than that:
> 1. Start and end of an appointment interval both are within HOURS.

Should I assume you prefer not to have a short-cut for declaring foreign key constraints?

> 2. Neither start nor end point of an appointment falls within some
> other appointment.

Should I assume you prefer not to have a short-cut for declaring candidate keys? Given the need for logical identity, this is a tough one to swallow.

> One motivation to consider an interval as a set of discrete points
> might be the fact that sets and subsets are a sweetheart of the
> relational model.

Whether the set is discrete and finite or whether the set is continuous and infinite, it would be just as much a set. Personal motivation is hardly a worthy topic for this newsgroup.

> IMHO the discrete topology of time line is a wrong
> model.

Build me an infinite computer, and we'll talk about making it continuous instead.

> > These constraints are very similar to a foreign key constraint and a
> > candidate key constraint, but they are subtly different due to the
> > intervals. For instance, a traditional foreign key constraint would
require
> > that the HOURS relation have the exact intervals in the APPT relation. A
> > traditional candidate key constraint would not prevent overlapping
intervals
> > and would thus not enfore uniqueness among the discrete points
represented
> > by the intervals.
>
> Yes, traditional foreign key constraints emphasize equality, and we
> would like to focus on the constraints with inequalities, instead.
> However, I fail to see any temporary specifics in that.

Intervals are useful for temporal databases, but they are not specific to time. One can have an interval of any enumerable, fully ordered type.

> > I recently attended a fascinating seminar by Chris Date on the subject.
He
> > is holding the same seminar the week of June 10th in Rome if you are in
> > Europe and can afford to go.
(http://www.technologytransfer.it/en/seminars/)
> >
> > He mentioned that he is writing a book on the subject that should hit
store
> > shelves Q4.
>
> Is any of his recearch published (in a series of articles)? Given that
> Snodgrass book is collecting dust somewhere on my bookshelf, I would
> be very careful this time. Even if the author is Chris Date.

I believe he is publishing in book form, and I believe the book should be available Q4. If you cannot afford to purchase it yourself, I suggest you recommend it to your library. Certainly, every university library should have a copy or two when it comes out. Received on Sat Jun 08 2002 - 05:44:34 CEST