Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)

"Adrian Veith" <adrian_at_veith-system.de> wrote in message news:<9ngc8f$de9$05$1_at_news.t-online.com>...
> "Bob Badour" <bbadour_at_golden.net> schrieb im Newsbeitrag
> news:cd3b3cf.0109081138.731c2192_at_posting.google.com...
> > "Adrian Veith" <adrian_at_veith-system.de> wrote in message
> news:<9na529$6u5$1_at_wrath.news.nacamar.de>...
> > > "Bob Badour" <bbadour_at_golden.net> schrieb im Newsbeitrag
> > > news:v2Vk7.768$LE3.134318184_at_radon.golden.net...
> > > >
> > > If relational algebra is that powerful, that you can declare any
> possible
> > > integrity constraint, why is it not possible to have relational
> integrity in
> > > an OODB ?
> >
> > I have previously stated several times that relational dbmses are
> > object oriented dbmses.
>
> My point is, that an OODB is a superset (should be, because some are not) of
> a RDBMS.

Actually, you have that backwards. Strictly speaking, a non-relational OODB is neither a subset nor a superset of a relational dbms. However, if we remove pointers, a non-relational OODB is very much a proper subset of a relational dbms.

For instance, a single column relation has all of the functionality of a collection, while a collection lacks much of the functionality of a single column relation.

The non-relational oodb lacks the equivalent of a "zero degree" relation, and the non-relational oodb lacks the equivalent of any relation with degree greater than 1.

The non-relational oodb attempts to overcome the lack of higher degree relations by adding pointers. However, the last three decades have clearly demonstrated the abject inferiority of pointers. Of course, that should be clear to any informed person: A pointer provides only partial functionality of a "2 degree" relation, and a pointer locks the dbms into a specific physical structure.

> Therfore, anything you can do with a RDBMS, you can do with an OODB
> as well.

You cannot write views with a non-relational oodb. You cannot declare univerally enforced constraints of arbitrary complexity in a non-relational oodb. You cannot arbitrarily alter performance characteristics without rewriting applications in a non-relational oodb. etc. etc. etc.

> >How do you arrive at the conclusion I think it
> > impossible?
>
> Somewhere in the discussion you wrote:
> > " Relations and the relational algebra provide a very powerful means for
> constraint
> > declaration. What does OODB have to offer in comparison?"
>
> > Since relational dbmses are object oriented dbmses, this is trivially
> > true.
>
> Since an OODB is a RDMBS, this is trivially true.

While an RDBMS is an oodb, not all oodb's are relational. Most of the products that people consider oodb are network model.

> > When one mistakenly equates an object collection with a relation, one
> > loses the ability to describe relations. Relations can describe
> > anything one can describe in a non-relational dbms; except that
> > relations do a much better job.
>
> Again you can't see the difference between left and right.

So you claim. What does your ad hominem really prove though?

> A collection is a
> subset (sub not super) of a relation. But in real live databases, you are
> confronted with 80% of relations, that can be described by a collection.

A collection cannot really describe a relation of any degree. For instance, collections do not support any closed relational algebra. The fundamental importance of this should not go unnoticed.

At best, a collection provides a very limited proper subset of a relation of degree 1.

> Therefore does a collection saves you from the task of doing stupid things
> again and again.

"Encourages it", I would say.

> > > I believe, that relational algebra works also in a proper defined OODB.
> >
> > In that case, you merely agree with me that relational dbmses are
> > object oriented dbmses.
>
> No, but you can use a RDBMS to implement an OO hierarchy.

Since RDBMSes are OO, the above is trivially true.

> > > If we look a typical object hierarchy:
> > >
> > > class media
> > > title: string
> > > end
> > >
> > > class cd < media
> > > number_of_songs: integer
> > > end
> > >
> > > class book < media
> > > number_of_pages: integer
> > > end
> > >
> > > one possibility to implement this hierarchy in an RDMS is to flatten out
> the
> > > hierarchy (Not very effective, but possible)
> >
> > The "possibility" you describe is nothing more than a very poor
> > design, and it makes the fundamental mistake of equating object
> > classes with relations. An object class describes an encapsulated data
> > type, while a relation describes an unencapsulated set. Your example
> > is nothing more than a straw man.
>
> No it shows, that a OODB is compatible with a RDBMS, but a RDBMS is not very
> compatible with a OO design.

Again, it is a straw man. It might demonstrate aspects of your design skills. It might demonstrate your skills at constructing fallacious arguments, but it demonstrates no general point about RDBMS or ODBMS.

> The design I have choosen for the RDBMS side is
> aweful. But any possible solution for the RDBMS side is aweful.

Unfortunately, belief in the above statement takes a huge leap of faith in the face of contrary evidence. In the end, the statement above is simply false.

> > Further, no competent relational database designer would use the
> > logical design you propose where a media relation has the union of all
> > media subtype attributes.
>
> I totally agree with you. But It shows the problem of a RDBMS to implement
> such a class hierarchy.

No, it does not. It only demonstrates that you proposed a poor design in an attempt to support an unsupportable claim.

> Either you do it in the way I have shown, then you
> end up in a total inflexible and error prone design.

Again, you have not demonstrated this or in any way attempted to prove this. I suggest, again, that you read Fabian's book before making such claims.

> Or you use a relation
> for each node in the class hierarchy, then you are correct, in the means of
> a RDBMS. But what will you do, if I confront you with a class hierarchy of
> 10 or more levels ?

That depends on the full set of design criteria. I might declare a hierarchy of relational domains for them.

> Yes, you can design it with a RDBMS, but is this useful?

Yes, of course, it is. It is much more useful than any navigational approach.

> > > 1. You can transform any object hierarchy to a flat structure and some
> > > integrity constraints
> >
> > While one can easily and simply represent a multidimensional construct
> > like a relation in a two-dimensional "table", a relation is anything
> > but flat. In fact, a single tuple contains an entire set of
> > arbitrarily complex object values or variables.
>
> I am impressed, but with "object hierarchy", I ment "class hierarchy", sorry
> for the mistake. If you had read carfully, you would have realized it.

I understood what you meant regarding "object hierarchy". I ignored that, and I addressed your claim that a relation is flat.

If appropriate, you can simply declare a class hierarchy in an RDBMS. Remember: "Relational Domain" = "Object Class".

> > > 2. You can translate a collection of objects into a table with 1:n
> relation
> >
> > You can translate a collection of objects into a single table of
> > degree 1. A table, which is a relation, cannot have a 1:n cardinality.
> > Two tables associated by a foreign key can have 1:n relative
> > cardinality.
>
> Yes, you proved, that your english is better than mine. But we ment the same
> thing. If I use the term relation, I mean two tables, that are associated by
> a key. I hope you don't mind, that I will use the term relation in this way.

I do mind. I do not attempt to redefine programming language terms when posting to programming groups, and I ask that you not attempt to redefine database management terms when posting to database management groups.

> > > 3. You can translate a reference into a 1:1 relation
> >
> > I am not entirely sure what you mean here. The statement above is
> > nonsensical. A reference is a pointer. A relaion is what you call a
> > table. A table or relation cannot have 1:1 relative cardinality, which
> > requires an association between two relations.
>
> A reference can be described as a collection with maximum one element.

Since almost all non-relational odbms describe a collection as reference to a repeating group of references, the above description is circular and obscures the fact that such a collection is a reference to a reference.

> > > 5. In an OODB you need far less constraints, because they will be
> fulfilled
> > > automatically .
> > Statement #5 is simply untrue.
>
> It is simple to say "untrue". But fact is, that an OODB knows, what a
> collection (or reference) is, and what actions must be taken if an object is
> deleted.

Really? Without anyone telling it what actions to take? Does it always cascade the delete? Does it always Set NULL? Does it always balk? Which of the three does it automagically know to do?

What about all the other types of constraints? Domain constraints? Restrictive predicates? General predicates?

> > > 6. Not shown but obvious: Queries are much easier to formulate in an
> OODB,
> > > than in a RDBMS
> >
> > Not shown nor obvious nor true.
>
> I will present our query language on our web-site. But since it is still
> under development, there are many things to change.

I repeat: Not shown nor obvious nor true. I should have figured you are a vendor given the ignorance you try to spread.

> > > But most of the constraints are implemented automatically and you
> > > don't have to formulate all these things over and over again.
> >
> > Given the weakness of your straw man, it does not surprize me that you
> > might actually believe such absurdity.
>
> See Answer to #5 and #6.

I didn't see any more truth or any less absurdity in the answers above.

> > > Another myth states, that RDBMS are much more effective and quicker than
> an
> > > OODB.
> >
> > Here you have combined two issues -- one of which is true and one of
> > which is false. It is true that relational dbmses are much more
> > effective than dbmses based on any other known logical data model. You
> > apparently misunderstand the implications of physical independence.
> > The actual performance is determined by the physical structures that
> > the dbms supports and not by the logical data model. A relational dbms
> > is capable of exactly the same execution performance characteristics
> > of dbmses based on any other logical data model in any given context.
>
> This is another myth.

So you claim, but I have repeatedly demonstrated how the above is true.

> Of course has the logical data model some implications
> to the physical structure. At least, if you want to do it in an optimal way.

Actually, if you want to rearrange your physical structure in an optimal way (without rewriting all of your applications), you must require physical independence. Physical independence means that the logical data model has no implications on the physical structure.

> Since a RDBMS has no "built in" solution to retrieve something like an
> object

The clause above is simply untrue on the face of it. Since a relational domain is an object class, the primary function of a relational dbms is "object" retrieval. Of course, you have not specified whether you intend "object value" or "object variable", but the distinction between the two is not that important in this context. Just as long as we realise that you do not mean "object" class or "object type" etc.

> you don't have to be smart to see, that the logical data model has
> implications on the execution performance.

Actually, to see it, you have to be ignorant regardless of intelligence.

> > It is true that relational dbmses will perform better overall than
> > non-relational dbmses, but that performance benefit includes
> > application development time, facility of schema evolution etc.
>

What's the matter? Cat got your tongue?

> > > Wrong is:
> > > 1. That all optimizations of a query are done with relational algebra.
> The
> > > most common optimization is to use an index.
> >
> > Since physical storage determines execution speed, all optimizations
> > involve physical storage structures. Many different types of indexes
> > exist to change performance characteristics. However, indexes only
> > scratch the surface of performance altering physical structures. You
> > ignore clustering, physical pointers, pointer pools, distribution,
> > parallelization and everything else the human mind can imagine.
>
> This all has nothing to do with relational algebra!

It has everything to do with relational algebra. How else will you specify your intent without restricting the possible physical access methods?

> So you agree, that
> relational algebra has nothing to do with the execution speed of a database.

I agree that logical data model is independent of execution speed. The relational algebra allows one to change the physical structure without changing applications.

> Of course, you can use all of these optimization techniques with an OODB -
> and we do.

Since your oodb has no concept of view or of join or of projection etc., I doubt your product uses even a small subset of the optimization techniques available to an RDBMS. Since I expect your product to force applications to change in order to alter performance, I doubt your product optimizes at all.

> > > Relational algebra is used to
> > > transform the query to use the index. But the index in itself is not
> defined
> > > by relational algebra.
> >
> > You apparently misunderstand Dr. Codd's most fundamental goals when he
> > proposed the relational data model. The relational model explicitly
> > avoids any definition of physical structures for the very purpose of
> > allowing physical independence. It permits any physical structure.
> >
>
> I have understood very well and I disagree. It permits to retrieve data,
> that fits into the model, from any physical structure. But the model is
> *not* optimal for something like an object.

Since a relational domain is an object class and since the values exposed to the user in relations are object values, I can see no valid support for the above statement. It is just another outrageous claim by a vendor trying to sell a flawed product.

> Therefore, if you widen the
> model for objects, you have the same thing, but this time true for objects
> as well.

Since relational domains are object classes, the relational model is already wide enough.

> > By defining physical structures in the logical data model,
> > non-relational odbmses cripple themselves in comparison.
>
> Again, you misunderstand an OODB with a non relational DB.

If you are arguing that a relational oodb is relational, all I can say is "Well, Duh!"

If you are arguing against the relational model, you obviously intend a non-relational oodb.

> > > 3. An OODB has build in optimizations like references (a controlled
> shortcut
> > > for a 1:1 relation).
> >
> > A relational dbms has built-in optimizations too -- it just cannot
> > expose them in the logical interface. The non-relational dbms harms
> > its users by forcing them to navigate pointers.
>
> You never "have to" navigate with pointers, but you "can" use references to
> access your data. It is like you use a key to access data in an RDMS - but
> simpler.

Au contraire. Pointers are navigational and problematic. As soon as you expose the pointer in the logical data model, you can never remove it without rewriting all applications that use it. If the cost of maintaining pointers exceeds their benefit, too bad. You are stuck with them, or you must break every application that uses them.

> And again you present your paradoxon. If a RDBMS is an OODB (in your
> opinion), what is a RDBMS ?

As I already stated, if an RDBMS is an OODB, an RDBMS is an OODB.

> In your words it is not relational

In my words, a relational OODB is relational and a non-relational OODB is non-relational. Why do you think I would make the distinction in the first place if it were unecessary?

> logic, you have invented the not relational RDBMS.

I have invented nothing. The relational data model as described by Dr. Codd in 1970 was already OO. Dr. Codd did the inventing. Almost the entire market did the ignoring. Received on Mon Sep 10 2001 - 03:22:42 CEST