| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)
From: "Bob Badour" <bbadour_at_golden.net>
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" <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.
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.
O.K.
> > > 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.
> >
> > So you claim. What does your ad hominem really prove though? >
> > 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
things
> > 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
OODB.
> > >
> > > In that case, you merely agree with me that relational dbmses are
> > > object oriented dbmses.
> >
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
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.
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. > >> > > logical design you propose where a media relation has the union of all
> > > Further, no competent relational database designer would use the
> > No, it does not. It only demonstrates that you proposed a poor design > in an attempt to support an unsupportable claim. >
> > 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
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, 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
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".
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
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.
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.
> >
> > 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. > >
> >
> > 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? > >
> >
> > 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.
> >
> > So you claim, but I have repeatedly demonstrated how the above is > true. > >
> > 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. > >
> > 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. > >
> > Actually, to see it, you have to be ignorant regardless of > intelligence. > >> > > non-relational dbmses, but that performance benefit includes
> > > It is true that relational dbmses will perform better overall than
> > 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
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.
> >
> > 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
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. > >
> > 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.
> > >
> >
> > 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.
 |
 |