# Re: Possible bridges between OO programming proponents and relational model

Date: 3 Jun 2006 07:37:00 -0700

Message-ID: <1149345420.152415.173700_at_f6g2000cwb.googlegroups.com>

<<What's the substantial difference with repect to 'dimensionality' ?>> Mainly that SQL current implementation are direct image implementation which limits their ability to represent relvar adequately. They can only manipulate relvar on a representation per representation basis.

<<See above, and what analogy do you have in mind ?>>Please read above. A ruby's cube has 3 dimensions (width, length, depth). When you look at one face of the cube you see only 2 dimensions. These 2 dimensions are on possible representation of the cube.

vc wrote:

*> Cimode wrote:
*

> > Thank you for your feedback.

*> >
**> > << This does not make any sense, the dimension of a relvar is the
**> > number
**> > of attributes.>>Absolutely. but SQL table implementations are not
**> > relvar, just a possible representation of a relvar. Commonly
**> > implemented SQL DBMS Tables are bidimensional.
**>
**> VAR CUBE RELATION { X REAL, Y REAL, Z REAL}
**>
**> TABLE CUBE(X REAL, Y REAL, Z REAL)
**>
**> What's the substantial difference with repect to 'dimensionality' ?
**>
**> > <<I suppose that you know how to represent a cube with a table.>> It is
**> > an analogy used for communication's sake. You misread and
**> > misunderstood my comment. I said that a face of a cube is
**> > bidimensional and is a comparable to what a SQL Table is to a relvar.
**> > (the relvar being a 3 dimensional relvar). This analogy has been used
**> > by DATE and PASCAL and I find it very valid.
**>
**> See above, and what analogy do you have in mind ?
*

Received on Sat Jun 03 2006 - 16:37:00 CEST