Re: The Practical Benefits of the Relational Model

Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<3D939E1D.6050706_at_hotmail.com>...

> > I do not think it is accurate to characterize my comments as stating
> > that "OO has pretty much all the bad qualities..." As a data
> > management solution, it does indeed have undesirable qualities.
>
> You'd be interested to read an alternative point of view. Of course OO
> in database management is not meant to be a replacement for the
> relational model but an extension of the relational model.
> Interestingly enough, many of the major contributor to OODB theory have
> previously contributed substantially to the development of relational
> theory.

Unfortunately, I think a great many folks "mean" it to replace the RM, using problems in SQL as supposed evidence. Also, the relational model does not need to be "extended"--a blunder made repeatedly over the years. Why would the model possibly need to be "extended" to include something it is already orthogonal to. The OODB folks I've met never understood the RM. It is common to hear from them, things like "the relational model was incapable of handling the complex data types demanded by today's applications." One of the many classic SQL = relational blunders.

> > As
> > for OO's particular incarnation of type inheritance (or subtyping if
> > you please) I am convinced that it suffers from several problems.
>
> There's no "OO particular incarnation of subtyping". There's C++
> incarnation of that, there's Java incarnation of that, and so on, so forth.
>
> Many of such incarnations suffer from various problems. In general, in
> designing a proper type systems for a particular endeavor (be it a
> general purpose programming language or a database language), one has to
> choose some trade-off. Therefore it is quite unlikely that even D&D may
> ultimately come out with _the_ relational incarnation of subtyping. As
> they noted in their book the type systems is relatively orthogonal to
> the relational model, so somebody may come up with a different type
> system to attach to the same basic relational model.

"relational incarnation of subtyping"!!? I really don't see why you keep using such wording when you seem to understand (see your next sentence) that the type model is an autonomous concept. If you are suggesting that _they_ do not understand this orthogonality, I assure you this is not the case. Someone surely could propose an alternative type model for implementation in a relational system. To my knowledge, nobody has done this.

> To cut a long reading short, you may want to start with Luca Cardelli
> "Type Systems" (it's quite short indeed), and possibly Constable's
> "Naive type theory". Then you'll be able to judge if D&D have a "formal
> type system" in TTM.

Thank you for the recommendations.

> >>"Type inheritance" as such does appear in some OO books here and there,
> >>though I think the prevalent term is "class inheritance". In most OO model a
> >>class automatically defines a type, but the reverse is not generally true.
> >
> >
> > "...a class automatically defines a type..." Hopefully you mean to
> > say that a class is by definition a type?
>
> No I mean a class defines a type. Meaning for every class in the system
> there's automatically a type associated with it. It is a common
> consensus in the scientific community that it is worthy to make the
> distinction between classes and types.

Distinction? Only because a class is a specific kind of type! Surely you don't suggest that a class it a different thing?! If a class "automatically defines" a type, than what type is that type?! Cloudy notions if you ask me!

Let's make sure we agree that the simplest complete definition of a type is nothing more or less than a set of values. If we disagree there, we will need to change gears in this discussion.

> Inheritance is an implementation mechanism: you "inherit" and reuse the
> code, without being necessarily in a subtyping relation with the class
> that you inherit from. I know that sounds kind of utopic in C++ and Java
> but it can be done both in theory and in practice.

Sounds like you are referring to a form of reuse sometimes called "delegation". Easily doable in C++, perhaps a bit tricky in Java.

> Then, as I said to Mr. Date in a previous correspondence the search for
> a consensus on subtyping is utopic and misguided. Each subtyping
> definition will belong to a particular type system.

I fail to see why consensus is not both possible and practical. For scalar types, I don't know of a simpler, yet equally capable, model than that presented by Date and Darwen. Whatever the case, it should be clear that TTM's scalar type inheritance model cannot be compared accurately with the ones found in the OO world... so any direct comparisons must be based on the practical benefits of each.

> There will naturally be different type systems best fitted for different
> problems.

True.

> Now here's the big problem: how the system makes sure that the user
> defined types together with the system defined types actually form a
> lattice ? How to resolve this crucial problem is left open, therefore
> "undefined". See the final point on the page 333.

Indeed true. In our system, such decisions are left to the type designer. This forces the type designer to _actually think_ about the nature of the types he is using (for the better). Something of a lost art in the data management world.

> A solution to this problem just can't be left as an exercise for the
> reader, because it is unlikely to find an easy and convenient
> resolution. ... This clearly can't be left for any sane user to do,
> cause it's sure as hell it will tunr back to Oracle and SQL.

:-) In practice, we have found it to not be such an issue. In application, we seldom even use subtyping, but: a) we have found if helpful when we do need it; and b) It's presence helps us clearly think out the implications of the types we deal with. In other words, practice has shown that if you throw a 100 types into the system, the situation is pretty clear. In fact, as stringent as the model appears, in practice it has proven pretty forgiving. If you, as a type designer, don't get the "lattice" right, the byproduct is probably missed reuse.

> Independently of the resolution of this particular problem, there is the
> undefined type equivalence, and this is a crucial aspect of type system.
> When two types are the same ? Or to begin with when a type is a subtype
> of another ? D&D just declares that by "fiat": when there one is subset
> of another, but real life doesn't work that way.
> ...
> What happens with X1 and X2 from the system point of view ? Are they the
> same types, and how can the system reach that conclusion ?

The system doesn't (at least our system doesn't). As mentioned, this is left up to the type designer. Yes, the type designer can mess this up, but I see this as no different from any other logical mistake the app developer can make when interpreting the real world.

> D&D can say that this is an implementation exercise, but it can be
> proven that this exercise cannot be solved, because it ultimately boils
> down to resolving the implication problem in the case where the
> predicates defining the types (mandated by S by C) are any boolean
> expression defined in the D language.

Again... why we don't _attempt_ to solve this in the system.

> Yes, indeed. I don't think you can accurately say that "a formal and
> well defined model of type inheritance" IS A "practical benefit of
> relational model".

True, but a practical benefit of the relational model IS derived from the allowance of multiple type models (so long as we agree on the definition of a type), which was intended as the core point of my bullet.

> The best thing that can be said is that an implementation of relational
> model can benefit from a formal type system, supporting subtyping.
> Additionally, the implementation might offer to the user the benefit of
> using inheritance as a mechanism to more efficiently implement user
> defined types and user defined functions.

Well said.

Regards,

--
Nathan Allan