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

From: Adrian Veith <>
Date: Tue, 11 Sep 2001 15:51:05 +0200
Message-ID: <9nl4hf$ndq$>

From: "Bob Badour" <> Newsgroups: comp.databases,comp.databases.object,comp.databases.theory Sent: Monday, September 10, 2001 3:22 AM Subject: Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)
> "Adrian Veith" <> wrote in message news:<
> > "Bob Badour" <> schrieb im Newsbeitrag
> >
> > > "Adrian Veith" <> wrote in message
> > news:<9na529$6u5$>...
> > > > "Bob Badour" <> schrieb im Newsbeitrag
> > > > news:v2Vk7.768$
> > > > >
> > > > 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.

I have never talked of a non relational OODB. My opinion is, that a OODB should be relational, but with enhancements to the functionalty that todays RDBMS have.

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

I said so too: a collection is a subset 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.

I have never talked about pointers. I talked about a reference. The "reference" i am talking about has the following characteristics:

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

I can write views as well, because the reference, that is returned by a query (more correct: the collection of references), can identify a real object, or an interface to one or more objects.

Since it the job of the reference, to retrieve the actual data of the object, there is no need for a specific physical storage of the data.

But i am not limited to the references. If the database should return a collection of a set of attributes (what you would call a relation), this is also possible.

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

A database, as a result of a query, returns a collection of a set (tuple) of references and/or other attributes. I wouldn't call this limited. Since a table in itself is a collection of references to the objects, there is no difference in querying a table, or the result of a query. The join of two or more tables (collections), is a set of references to the result of the product of these collections, that meet a certain criteria.

What is wrong with this definition ?

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

> "Encourages it", I would say.

Please explain, or i will stay dumb.
The construct of a collection helps you to omit most of the relationship tables. Therefore it helps you to formulate queries without explicit joins (under the hood it is something like a relationship table). The construct of the "reference" brings the task of key-generation to the DBMS. You can look at a reference and it tells you: who or what it is and when it is.
Since the database can be optimized to use the "reference", it is also *allowed* to perform navigational tasks. But YOU don't have to use this feature.

> > > > I believe, that relational algebra works also in a proper defined
> > >
> > > 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.

I give up. Lets stop this.

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

Since my design skills are week ( and I am not an advocat for RDBMS like they exist now), please show us your simple approach in SQL.

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

I must confess, that there is some truth in the things you are saying, but if you have read the book, why don't you enlight us with your knowledge. Since many books are wasting of paper, I would prefer a reflected description.

> > Or you use a relation
> > for each node in the class hierarchy, then you are correct, in the means
> > a RDBMS. But what will you do, if I confront you with a class hierarchy
> > 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.

There are some situations, where navigation is useful. If the task you have to perform needs navigation, why should a DBMS (OO or R) hinder you ? For example, how do you implement a topological sort with a RDBMS. (Maybe there is a solution, but why should I hire a relational algebra pro, if the task is easy with navigation)

> > > > 1. You can transform any object hierarchy to a flat structure and
> > > > 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",
> > 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".

What about Inheritance ?

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

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

I am sure, that I am not the only one, who uses "relation" in the way I did.

> > > > 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?

You can have different attributes for the collection. If it has the attribute OWNS, then it will delete the associated objects. Anyway, the object, that is deleted, will be removed from all collections, that reference it.

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

Is it wrong, beeing a vendor ?
Or who do you think should produce the DBMS, you would like to have. Maybe not me, but another vendor.
Now who is ignorant ?

> > > 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
> 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?

This was absolute out of context, I have allways talked about a OODB that works relational. But anyway, you write "overall" and not "allways". If a RDMS would allow navigation (beside of description), there could be an "always" instead of an "overall".

> > > > Wrong is:
> > > > 1. That all optimizations of a query are done with relational
> > 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?

Parallel access to your data is a problem of transactions and their interference. This is one of the reasons, why I designed the "reference" with the abilty to know "when" it is.

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

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

You are talking about something you haven't seen.

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

Can a relational domain give you these answers: - i am of type ClassXY and i am derived from ClassX ? - i am not derived from ClassX, but i can look like and act like ?

If yes, please show me the product. I would like to learn.

  • I deleted the more stupid parts of the discussion. If there is a point you would like to bring up again, please don't hesitate.
Received on Tue Sep 11 2001 - 15:51:05 CEST

Original text of this message