Re: The Foundation of OO (XDb)

Bob Badour wrote:
> The logical model does not care how the dbms physically represents the data.

As long as the data is unchanged, i.e. you can convert from A to B to A again without loss. If changing representations changes the type's behaviour in any way, you have a different type (though perhaps functionally similar).

> A video is a video.

No. The above conversions are not lossless.

> AVI, MPEG and QuickTime are all just representations of Video.

Yes, but they're representations with different limitations, just like integer16, integer32 and real are all numbers with different limitations. Logically they might be regarded as numbers, but in many applications the limitations and type-approximations matter. In financial applications for example, the exact behaviour of integer rounding must be defined.

In general though I agree, the internal representations of a type should never be relevant. But in the real world we often deal with families of similar and easily convertable types, and those conversions can introduce errors.

Quick anecdote: I once worked with a 4GL into which you could type "113.45" in a numeric data field, and upon hitting Enter, it would display "113.44". Internally it was converting to a C "float" type for which there are no exact representations of some values, even ones with quite small numbers of significant digits, and then back to text - the two conversions were not and could *never* be made 100% reliable in the face of even simple addition.

> > my data models often need to support
> > specialisation, and though it doesn't break the relational model at all,
> > the products don't support it natively.
> Specialization of what? Why do you think views fail to support it?

Views do support it, but not IMO as conveniently as possible. I'm not asking for extensions to the relational model, just for some higher-level structures for convenience and aspect-separation. All the operations are still well defined in terms of relational algebra.

Also, placing additional data in joined tables may not produce the most efficient physical model - the DBMS may know (either by sampling or by being told) that 90% of the elements in A have additional attributes in B, and that the overall best physical storage compromise is to store the additional attributes of the B tuples with the B records. This could be easily supported by physical pragmas, e.g.: "create table B ( ... integer x...) cluster by x = A.x", but again, this sort of thing can be built into an intrinsic support for specialisation.

> Foreign key constraints are quite simple. If your constraints are complex, I
> suggest you need to reconsider your data model. If it turns out that the
> application domain is just complex, the complexity may be inherent in the
> problem.

I think that the complexity *is* inherent in the models I'm speaking of, but a greater difficulty comes when deciding what types of constraints are relevant to specialisation, and in finding a language to represent those constraints that communicate clearly and succinctly with its users (SQL it aint!). But I haven't really pursued this much so perhaps it's not as hard as it seems.

Clifford Heath Received on Mon Jun 17 2002 - 12:04:30 CEST