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

From: Adrian Veith <>
Date: Sun, 9 Sep 2001 19:53:36 +0200
Message-ID: <9ngc8f$de9$05$>

"Bob Badour" <> schrieb im Newsbeitrag
> "Adrian Veith" <> wrote in message
> > "Bob Badour" <> schrieb im Newsbeitrag
> > news:v2Vk7.768$
> > >
> > If relational algebra is that powerful, that you can declare any
> > 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. Therfore, anything you can do with a RDBMS, you can do with an OODB as well.

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

> 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. 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. Therefore does a collection saves you from the task of doing stupid things again and again.

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

> > 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
> > 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. The design I have choosen for the RDBMS side is aweful. But any possible solution for the RDBMS side is aweful.

> 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. Either you do it in the way I have shown, then you end up in a total inflexible and error prone design. 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 ?

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

> > What does this example show:
> It shows only that you have a very confused understanding of
> relations. At a very fundamental level, your example confuses an
> unencapsulated set with an encapsulated data type.
> > 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.

> > 2. You can translate a collection of objects into a table with 1:n
> 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.

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

> > 5. In an OODB you need far less constraints, because they will be
> > 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.

> > 6. Not shown but obvious: Queries are much easier to formulate in an
> > 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.

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

> > Another myth states, that RDBMS are much more effective and quicker than
> > 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. 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.

Since a RDBMS has no "built in" solution to retrieve something like an object, you don't have to be smart to see, that the logical data model has implications on the execution performance.

> 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.
> > Often this myth is explained with relational algebra and the
> > possibility to optimize queries in an RDBMS.
> Your so-called myth is just another straw man. The relational algebra,
> however, does facilitate optimization.
> > As with all myths, there is true part:
> > Relational algebra gives you the possibility to transform a query in
> > to optimize it.
> And a whole lot more...
> > Wrong is:
> > 1. That all optimizations of a query are done with relational algebra.
> > 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! So you agree, that relational algebra has nothing to do with the execution speed of a database.

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

> > Relational algebra is used to
> > transform the query to use the index. But the index in itself is not
> > 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. Therefore, if you widen the model for objects, you have the same thing, but this time true for objects as well.

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

> > (Since an index is normally a tree-structure, it has
> > more in common with an OODB if you want)
> While the most common indexes for databases are variants of the B+Tree
> and ISAM, many other indexing structures exist.

> > 3. An OODB has build in optimizations like references (a controlled
> > 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.

And again you present your paradoxon. If a RDBMS is an OODB (in your opinion), what is a RDBMS ? In your words it is not relational - impressing logic, you have invented the not relational RDBMS. Received on Sun Sep 09 2001 - 19:53:36 CEST

Original text of this message