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

Date: Tue, 25 Feb 2003 19:08:25 -0500

Message-ID: <7ZT6a.359$345.54874164_at_mantis.golden.net>

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:b3fqck$u4o$2_at_sp15at20.hursley.ibm.com...

> "Bob Badour" <bbadour_at_golden.net> wrote in message

*> news:mnF6a.332$QR3.51347581_at_mantis.golden.net...
**> > "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
**> > news:b3dr5r$sss$1_at_sp15at20.hursley.ibm.com...
**> > > "Bob Badour" <bbadour_at_golden.net> wrote in message
**> > > news:zst6a.297$9O1.43758648_at_mantis.golden.net...
**> > > > > Let me put it this way. If a type has 2 possiable representations,
**> > then
**> > > > > A) the number of values represented by PosRep1 must equal the
**> > number
**> > > > > of values represented by PosRep2
**> > > > > B) each value represented by PosRep1 must 'map' to exactly one
**> > value
**> > > > > represented bt PosRep2, and versa.
**> > > >
**> > > > While desirable whenever possible and while certainly possible in an
**> > ideal
**> > > > machine, I do not require this of physical implementations.
**> > >
**> > > Yes and that is my worry. I'm not comfortable with such a fudge. If
*

the

> > > logical model cannot be implemented correctly then is there not

something

*> > > wrong with the model?
**> >
*

> > First, I would disagree that the implementation is incorrect. Second, I

*> > would observe that a logical data model is an ideal abstraction. Third,
*

I

> > would observe that any flaw lies in the physical implementation and not

the

> > logical data model.

>

> That does seem to be the received wisdom. I don't take people's word for

it

> however.

>

> 1. An implementation is incorrect if it does not faithfully reproduce all

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

> 2. I disagree with the conceit that a 'logical data model is an ideal

*> abstraction' with all the implications that the 'real world' has forever
**> unknowable complexities . Ask a physicist. Do they consider their theories
*

as

> abstractions of the world, or rather, as I see it, the theories are how

the

> world *actually* works.

A good physicist will certainly say that the mathematical models are abstractions of the world. No physicist knows whether space is continuous. No physicist knows why masses attract each other.

> 3. But if, even in principle, no possible physical implementation could

*> implement the logical model correctly, then quite simply the logical model
*

is

> (to some extent) broken.

By that criterion, every logical model is broken. I fail to see the usefulness.

> The received wisdom seems to suggest that it is OK to assume an infinite

and

> continuous universe. Rubbish! Any logical model that needs to assume that

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 appropriate to the users' needs, do not assume it. Nothing in the relational model requires one to make the assumption.

> > Fourth and finally, I must ask: What other logical data

*> > model do you propose that addresses the specific issue of cartesian and
**> > polar coordinates and possible rounding in the internal physical
**> > representation?
*

>

> Well, lets have a go shall we.

>

> In the case of polar and catesian points, something like the following

type

> hierarchy suggests itself to me

>

> POINT_Real

> / \> / \> Point_Int32_Polar Point_Int32_Cart> \ /> \ /> Point_Int32_Polar_isect_Int32_Cart

> >

> Here POINT is an abstract type with both poss reps both using the abstact

type

**> for the components of the pos reps.**

*> REAL*>

> Point_Int32_Polar is the set of POINTS representable using signed 32 bit

*> integers in the r & thera polar poss rep components. This type has only*

one

> poss rep.

>

> Point_Int32_Cart is the set of POINTS representable using signed 32 bit

*> integers in the r & thera cartiesian poss rep components. This type has*

only

> one poss rep.

>

> Then Point_Int32_Polar_isect_Int32_Cart is the intersection of

*> Point_Int32_Polar and Point_Int32_Cart. This would include all *exactly*

equal*

> points in the two representations.

*> e.g. (a:0, b:0) = (r:0, theta:0), (a:1,b:0) = (r:1, theta:0) etc etc.*

*> This type has two poss reps.*

With all due respect, Paul, the above is not a logical data model and does not suggest any alternative to the relational model. Neither is it incompatible with any of Date's and Darwen's remarks regarding type inheritance. Received on Wed Feb 26 2003 - 01:08:25 CET