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

From: Bob Badour <>
Date: Sun, 9 Mar 2003 16:48:16 -0500
Message-ID: <d5Paa.407$>

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:b3i5u8$n84$
> "Bob Badour" <> wrote in message
> news:7ZT6a.359$
> > > 1. An implementation is incorrect if it does not faithfully reproduce
> > > aspects of the model. To me it is obvious that an implementation that
> > breaks
> > > say my A) and B) criteria is strictly incorrect.
> >
> > Every physical implementation of every logical model, then, is strictly
> > incorrect.
> I just don't get that. We should not tolerate physical implementations
> do not faithfully reproduce all aspects of the model. Just as we should
> tolerate an RDBMS that permits duplicate rows, we should also not tolerate
> RDBMS that breaks another aspect of the model, such as all pos reps of a
> represent the same number of values.
> Tell me, how do you classify which deviations from the logical model are
> tolerable and which are not?

In the situation given, the types are designed by some user. That user will determine the tolerances. If it is intolerable to the user to have approximate cartesian and polar representations, they user can choose which of the two representations to omit or can design the representations to use greater precision so that the approximations do not matter.

Since infinite precision will not be an option for the user, the user who designs the types will have to engage in actual design tradeoffs.

I don't find that surprising. Do you?

> > To a physicist, a theory is a predictive model of the universe. The
> > physicist's job is to test the quality of the theory and to seek better
> > theories.
> Agreed, with the ultimate goal to find the theory that explains

Perfect knowledge of the universe? Now that's a conceit!

> > > 3. But if, even in principle, no possible physical implementation
> > > implement the logical model correctly, then quite simply the logical
> > is
> > > (to some extent) broken.
> >
> > By that criterion, every logical model is broken. I fail to see the
> > usefulness.
> Why every model? Why is every model not physically implementable even in
> principle? Are you saying that the physical world does not obey rules?

I am saying that we do not live in an infinite universe and we cannot move with infinite speed.

> > > The received wisdom seems to suggest that it is OK to assume an
> > and
> > > continuous universe. Rubbish! Any logical model that needs to assume
> > is
> > > never going to be a true model of the world.
> >
> > A logical model should allow one to assume an infinite and continuous
> > universe if it is appropriate to the users' needs. If it is not
> > to the users' needs, do not assume it.
> Ok, I won't assume it.
> > Nothing in the relational model
> > requires one to make the assumption.
> This is my point. My interpretation of Date's and Darwen's usual POINT
> type implies that one needs to assume an infinite datatype such as REAL if
> example is take at face value: i.e. that it is a good example of a type
> has two possible representations.

If the user must assume an infinite and continuous universe, the user won't be able to use the specific type from the specific example. The user will have to use a different design that is suitable to their needs.

Are you saying that every design example must be suitable for every conceivable user's requirements?

> > > > Fourth and finally, I must ask: What other logical data
> > > > model do you propose that addresses the specific issue of cartesian
> > > > polar coordinates and possible rounding in the internal physical
> > > > representation?
> > >
> > > Well, lets have a go shall we.
> > >
> [snip]
> > With all due respect, Paul, the above is not a logical data model and
> > not suggest any alternative to the relational model. Neither is it
> > incompatible with any of Date's and Darwen's remarks regarding type
> > inheritance.
> Well, it was only the beginnings of an outline and yes it is meant to be
> compatible with their remarks (and certainly with the relational model!!).
> Heck it is inspired by them. All I am saying is that, in retrospect and
> being overly critical, not all of their remarks are self consistent. As
> as they changed their minds* that NUMERIC is not a good type** but say
> NUMERIC(4,2) is, then it follows that a POINT type with two possible
> representations is also not a great type, but say Point_Int32_Cart with
> one poss rep is.

These are design issues and some designer will have to make design tradeoffs. The design you propose may actually be very useful to many users' specific needs.

I think the pedagogy would get lost if your design were used to explain the base principles, though.

> * I don't have the temporal book on me, but see the footnote in the
> dealing with the NUMERIC interval type example.
> ** by 'not a good type', I probably mean 'not a type at all'. Although I
> guess you might retort that NUMERIC is a bad basis for an interval type,
> ok as a type per se. I would disagree.

Well, I think you are tilting at windmills. Pedagogy will continue to require the occasional simplification for the purposes of clarity. Received on Sun Mar 09 2003 - 22:48:16 CET

Original text of this message