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

From: Bob Badour <bbadour_at_golden.net>
Date: Sat, 13 Oct 2001 13:44:10 -0400
Message-ID: <V3%x7.2891$cA2.94542889_at_radon.golden.net>


"Adrian Veith" <adrian_at_veith-system.de> wrote in message news:9q3fo7$ti5$00$1_at_news.t-online.com...
> Resent, because my PC had a wrong date.
>
> "Bob Badour" <bbadour_at_golden.net> schrieb im Newsbeitrag
> news:A4xt7.1500$yU1.104969349_at_radon.golden.net...
> >
> > "Adrian Veith" <adrian_at_veith-system.de> wrote in message
> > news:9nl4hf$ndq$1_at_wrath.news.nacamar.de...
> > > 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.
> >
> > The "enhancements" you desire render the dbms non-relational doing
> > tremendous harm in the process.
> >
>
> You are totally wrong. The enhancements I desire stand without any
conflict
> to a relational design.

I can only suggest you educate yourself regarding the fundamentals. My previous statement remains a true fact.

> > > > 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.
> >
> > A reference is a pointer.
>
> Here are definitions I have found in the Oxford Dictonary (As we use
> language to comunicate, I think we should take care not to redefine
> meanings - unfortunately the IT industry does)
>
> Reference:
>
> 1. Direction more or less precise to (page etc. of) book etc. where
> information may be found.
> 2. Relation, respect, correspondance, to

Yes, a reference is a pointer to a location.

Of course, in a technical discussion, I would suggest we use a more rigorous definition of the term accepted within the scope of the discussion.

> > > The
> > > "reference" i am talking about has the following characteristics:
> > >
> > > - it identifies the ascotiated object like a primary key, but is
> generated
> > > by the database
> >
> > It points to an object variable without providing any useful information
> for
> > identification.
>
> With the above definition of a reference, it gives you the place where you
> can find information.

Yes, it points to a location.

> There are many possible implementations of such a
> reference. A simple pointer would be the most stupid.

Additional levels of indirection or a more complex decoding algorithm change little.

> > > - but unlike the primary key, it gives you the following information:
> > > - what kind (class) of object it identifies.
> >
> > While a primary key does not provide type information, the combination
of
> > relation name and column name do. Since primary key value, relation name
> and
> > column name uniquely identify an object instance, the relational
> equivalent
> > to a pointer provides as much type information.
>
> Wrong. In your model you have to know in advance, which relation you want
to
> address with a primary key.

The relational equivalent to your pointer is the combination of a relation, key value and column name. How is anything I wrote wrong?

> With a reference you can address an object of
> unknown type and get all the information.

This is equally true in the relational model. The declared type specified by a relation and a column name does not have to match the most specific type of any object value further identified by a candidate key value in the relation. While I question the utility, one could have a universal "Object" supertype and declare the type of a column using this universal type.

> And you get even usefull
> information, if you provide a invalid reference (= the reference is
> invalid).

Again, the relational model likewise provides useful information regarding invalid references. An rdbms will explain that a relation is unknown to the dbms if that is the case. An rdbms will explain that the named column does not exist in the relation if that is the case. An rdbms will correctly state whether any provided key (or non-key) exists within the relation.

> > > - when is the object (two or more different transactions, can see
an
> > > object at a different state)
> >
> > I am not sure I understand your point here, but it sounds as though you
> are
> > talking about concurrency issues.
> >
>
> Of course. A big problem of all databases is, that they don't have a
proper
> handling of concurrency.

This is a remarkable statement. I hope you provide equally remarkable support for it.

> In a multigenerational database, locking hinders
> concurrency and therfore performance.

The relational model does not require locking in the first place. I wonder what point you are trying to make regarding relational vs non-relational object dbmses.

> In most cases, it is enough to know if
> an object (or record) has changed since the time the transaction started.

For those rare instances where users need such information, the relational model only requires that the dbms logically expose this information as values in the relation. The most commonly used methods are update counters and timestamps.

> If
> the database provides this information, you can reduce locking to those
> occasions, where it is absolutely necessary for data integrity.

As I mentioned previously, the concurrency model is orthogonal to the logical data model. The relational model allows any valid concurrency model and any implementation of that concurrency model.

> > > - any field (data) of the object can be adressed via the reference
> >
> > Not only do you want to discard the information rule by introducing
> > pointers, now you want to discard physical independence by
unencapsulating
> > domains (abstract data types).
> >
>
> ?!? Wrong.
>
> Example:
>
> class Foo
> int A,
> double B
> end
>
> class FooBar < Foo
> int C
> end
>
> Given a reference X to an object of class Foo i can the following:
>
> X is Foo -> True
> X is FooBar -> False
> print X.A
> print X.B
> print X.C -> Throws an exception
>
> This is encapsulation !

What is encapsulated and how?

> > > - it *must* never change throughout the lifetime of an object.
> >
> > How does it achieve this when I embed the object in my Excel
spreadsheet,
> > print out the spreadsheet and fax it to someone else?
> >
>
> As Jim has answered this, you can not embed an object in a spreadsheet.

Since I can embed a relation in a spreadsheet and since a relation contains object values, I must disagree with your statement.

> If
> you do so, you create a new object.

I disagree. The information recorded in the spreadsheet describes exactly the same entity in the real world and should preserve identity.

> Therefore you can only embed a copy of
> an object.

If I record my mother's birthday in a database and I record my mother's birthday in a spreadsheet, I have to make a copy of my mother?!? Yikes!

> In my opinion, this is also a major problem of persistance.

Actually, this is a problem of using pointers for identity. Identity is a concept independent of location. The relational model captures this concept logically using values. Your proposal confuses the concept of identity with the concept of location.

> Since with
> persistance you create copies of the objects in the database in the memory
> of the application.

The above statement demonstrates the confusion. The identity of the described object does not changed when information is recorded in multiple locations.

> This is one of the reasons I prefer to speak about
> interfacing the objects in the database.

I prefer to speak about concepts separately from logic and separately from physical location. I think your understanding will vastly improve if you do likewise.

> > > - it should give you an error if try to access an object, that has
been
> > > deleted.
> >
> > As would any dangling pointer, which is just one reason why pointers
prove
> > so inflexible and ineffective.
> >
>
> Again wrong. A reference knows, when it is dangling. And with a proper
> memory mangement, this should never happen.

Wrong in what way? Are you now claiming that it is impossible to try to access a deleted object through the pointer used to delete it? No error is possible? I am not sure what I said that was in error.

> > > - i don't make any assumptions how this reference is implemented.
> >
> > You don't have to make assumptions how the pointer is implemented. It
> > remains a pointer nevertheless.
>
> Repeating a stupid argument doesn't make it better.

Are you going to demonstrate any flaw in the argument or are you going to rely solely on emotional outbursts to support your position?

> > > > > 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.
> >
> > How do you project over a pointer? What results?
> >
> > How exactly does this new reference type differ from the relational
method
> > of simply exposing the object directly?
> >
>
> Given the pseudo definitions of Foo and FooBar above I can do:
>
> create table FooTable based on Foo
>
> select self
> from FooTable.Foo self
>
> returns a collection of references to all Foo's (and FooBar's as well).

One does not need to use references to allow polymorphism. A relational dbms can do the same without extending the relational model.

> select self
> from FooTable.Foo self
> where A = 1 or self.FooBar(C = 23)
>
> returns a collection of references to all Foo's where A=1 or it is a
FooBar
> and C = 23.

One does not need to use references to allow downcasts, either. A relational dbms can do the same without extending the relational model.

> select self
> from FooTable.FooBar self
>
> returns only all FooBar's.

Again, one does not need to use references to allow downcasts or to query specific type. A relational dbms can do the same without extending the relational model.

> Why references and not a copy of the attributes ? Because I want to be
able
> to write code like this in my applications:

You can write whatever code you want in your applications without extending the relational model. The relational model handles database management while your application programming language handles applications.

> And now the way how I plan to implement views:
>
> In the database:
>
> Interface IFooBar
> FooBar myFooBar,
> int X
> end

Requires someone to predefine the type of tuples in the view. Must someone predefine a type for every query?

> > > > > 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.
> > >
> > > 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.
> >
> > I would call it needlessly complex. A relational dbms, as a result of a
> > query, returns a set of a set (tuple) of objects. What can I do with a
> > reference that I cannot do with the object itself?
> >
> >
> > > 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 relational model does not limit the use of pointers at the physical
> > storage level. Since it exposes only objects at the logical level, there
> is
> > no difference in querying any relation regardless of storage or
> derivation.
> >
> >
> > > 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.
> >
> > Again, I see this as needlessly complex. What do references allow me
that
> > objects do not?
> >
> >
> > > What is wrong with this definition ?
> >
> > Needless complexity.
>
> Given the examples above - where is the needless complexity ?

Given the examples above, where is the need for references?

> > > > > 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.
> >
> > A collection encourages one to do the stupid things repeatedly. On
second
> > thought, iteration requires it.
> >
> >
> > > 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).
> >
> > Since a collection has no equivalent to the relational algebra, it
> prevents
> > one from formulating queries. Views, themselves described as queries,
help
> > users formulate queries without explicit joins.
> >
>
> class FooCollect
> collection of Foo myCollection,
> int D
> end
>
> create table FooCollectTable based on FooCollect
>
> select self
> from FooCollection self
> where myCollection.Has(A = 3 or FooBar(C=11))
>
> returns a collection of references to all FooCollect Objects where Foo has
> Objects with A=3 or it is a FooBar and C = 11.

It also violates encapsulation, requires significant additional complexity in the query language and defines implicit operations on explicit types.

> select self
> from FooTable self
> where Invers(FooCollectTable.FooCollection.Foo).Has(D = 23)
> and self.FooBar(C = 11)
>
>
> returns a collection of references to all Foo Objects which are referenced
> by FooCollect Objects with D=23 and the object is a FooBar with C = 11.
>
> Please explain why a collection hinders to formulate queries ?

It greatly complicates the query language. Please explain why it helps to formulate queries.

For instance, you have only demonstrated simple restriction. Yet, doing so:

Just imagine the complexity you must add to use FooTable in a Join, Union, Intersection, Difference or Projection. (Not to mention when nesting these operations.)

> > > The construct of the "reference" brings the task of key-generation to
> the
> > > DBMS.
> >
> > Unfortunately, it hides the identity of data from the user at the same
> time.
> > A DBMS can generate unique key values without resorting to pointers.
>
> ???

!!!

> > > You can look at a reference and it tells you: who or what it is and
> > > when it is.
> >
> > I sincerely doubt that many human users can tell anything by observing a
> > reference.
> >
> >
> > > Since the database can be optimized to use the "reference", it is also
> > > *allowed* to perform navigational tasks.
> >
> > But you claim that a reference is not a pointer? Above you introduced
the
> > concept of an unencapsulated "field" in an object. Can a field hold a
> > reference to an object? If so, does the user not have to navigate from
one
> > object to another to another?
> >
> >
> > > But YOU don't have to use this feature.
> >
> > Unfortunately, by introducing unecessary pointers at the logical level,
> your
> > DBMS would prevent me from doing many of the things that I do want to
do.
> > YOU don't need references to do anything. Why should your arbitrary
desire
> > limit other users?
>
> You still have the possibilty to write something like:
>
> select self.A, self.B, self.FooBar.C // returns C if self is a FooBar or
> null
> from FooTable.Foo self
> where A = 1 or self.FooBar(C = 23)

Again, one does not need references for polymorphism or for querying specific type. A relational dbms can do the same without extending the relational model.

> > > > > 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.
> >
> > Fabian devoted an entire chapter to the topic. Since I cannot cover the
> > topic as succinctly or as eloquently, I direct you to his book. If your
> > local library does not have a copy, please suggest that they purchase
one.
> > You will do your community a service.
> >
> > Fabian's book deals with many other practical issues as well.
> >
>
> You have made me curious about this book. I have ordered it already, but
it
> will take some time to come to germany.

I hope it proves as useful to you as it has to me. I think it will clarify a number of issues for you.

> > > > > 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.
> > >
> > > 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 ?
> >
> > No task requires navigation. Why should any dbms require it?
>
> How can you be so sure. I am not.

Ponder the following two statements: A pointer (or reference) establishes a unidirectional relationship between two variables. A tuple in a relation variable establishes a symmetric relationship among N variables.

> For me it looks like a religion - navigation is evil. If does not cause
any
> harm, why is it forbidden to use it ?

Much empirical evidence and many logical arguments have clearly demonstrated that forced navigation causes harm. Your own examples demonstrated considerable needless complexity.

> > > 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)
> >
> > You do not need an expert on RDBMS to implement a topological sort, you
> need
> > an expert on graph theory.
>
> The algorithm I know requires navigation. Why should I look for another
> solution ?

I disagree. A topological sort does not require 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 ?
> >
> > What kind of inheritance? An RDBMS should support type inheritance. For
an
> > example of one relational proponent's views on type inheritance, see:
> > http://www.firstsql.com/dbdebunk/cjd8a.htm
> >
>
> Sorry, this is to academic for me. A circle is a graphical object and the
> ellipse is a graphical object.

You misunderstand circle and ellipse. They can be properties of graphical objects, but they are not graphical objects.

> But an ellipse is not a circle and a circle
> is not an ellipse (In my view of objects). It just happens that a ellipse
> with identic focal points looks like a circle.

A circle is always an ellipse. It has two focal points.

> > > > > > > 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.
> >
> > Ignorance is no excuse. I already know that many people are unknowingly
> > ignorant of the relational model, which perhaps explains their
willingness
> > to dismiss the relational model as impractical theory. Microsoft even
has
> an
> > incorrect definition in a so-called dictionary, and I see that they
> further
> > propagate their ignorance in ADO.net. Nevertheless, Dr. Codd publicly
> > applied the mathematical concept of "relation" to the problem of
database
> > management back in 1970. A relation is what you would call a table.
> > Referential integrity and foreign key relationships are just that:
> > referential integrity and foreign key relationships.
> >
> > The ISO Standard Vocabulary for Databases, ISO/IEC 2382-17, defines
> > "Relation" as:
> >
> > "A set of entity occurences that have the same attributes, together with
> > these attributes. Note -- In a relational database, a relation can be
> > represented by a table with the rows corresponding to the entities and
> > columns corresponding to the attributes." ISO/IEC 2382-17.04.01
> >
> > Ich habe kein deutsches Normung. Ich habe nur das
> englisches/franzoesisches
> > Normung, und mein deutsch-englisches Computerverzeichnis ist in New
> Jersey.
> > Ich habe ein deutscher Freund gefragt und er hat gesagt dass die
logische
> > oder mathematische Ausdruecke "function" und "relation" sind "Funktion"
> und
> > "Relation" ins Deutsch. Ich glaube dass das Problem nicht eine
> Uebersetzung
> > Ausgabe ist.
> >
>
> perfect ;-)
>
> > Your english is much, much better than my german.
> >
>
> To be frank, I am positivly surprised.

I am gratified to hear that. (I think)

> > > > > > > 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.
> >
> > These arbitrary and ad hoc "attributes" are less functional than the
> general
> > integrity function of an RDBMS.
> >
>
> That is true, but as I pointed out, that collections are a subset of
> relations.

That's like saying pedal-cars are a subset of cars. It's true. But is it helpful?

> > > Anyway, the
> > > object, that is deleted, will be removed from all collections, that
> > > reference it.
> >
> > Why on earth would the DBMS remove an object value from all relations
just
> > because I delete it from one???
> >
>
> If a collection references an object that is deleted, than the reference
to
> this object must be removed.

Only if one defines the referential integrity constraint with cascaded deletion. What you call deletion of the object is nothing more than removal of the object from the extent. In an rdbms, the data modeller has full control over what happens when one deletes any given object variable.

> > > > > > > 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 ?
> >
> > No. It is wrong to spread ignorance and misconception. It's just less
> > surprizing when done for financial gain.
> >
>
> Everybody is ignorant - sometimes - one less one more.

However, not everyone tries to spread their ignorance or to reinforce the ignorance of others. (I am not just splitting hairs here. This is a vitally important distinction.)

> > > Or who do you think should produce the DBMS, you would like to have.
> >
> > A knowledgeable, conscientious, educated vendor instead of the all too
> > common variety I usually encounter.
>
> Saint Who ? I doubt, that someone does without financial interest.

Financial interest is orthogonal to knowledgeability, conscientiousness and education. (Or at least, it should be!)

> > > If a
> > > RDMS would allow navigation (beside of description), there could be an
> > > "always" instead of an "overall".
> >
> > Untrue. Exposing pointers in the logical interface offers no performance
> > advantage over using physical pointers hidden from the user.
> >
>
> From my examples, you can see, that the reference is not exposed to the
> user, but to the interface of the programming language.

The programming language is a user.

> > > > > > > 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?
> > > >
> > >
> > > 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.
> >
> > You have not answered my question. You have only further validated the
> > contention that the introduction of pointers needlessly complicates all
> > database functions: integrity, manipulation, definition, concurrency,
> > security, etc. Incidentally, the idea of combining a pointer with a
> > transaction identifier is not new -- SQLBase did that years ago.
>
> I am not claiming to do something new. I am just doing the things I am
> convinced of. Maybe the combination is new, but that I don't know.

You have not addressed the more important issues.

> > > > > > > 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 ?
> >
> > Yes, if you mean type inheritance when you say "derived".
>
> Where is the relational domain defined ?

The concept of domain was introduced in Codd's 1970 paper. If you are talking about specific domains in the dbms, the user defines some and the dbms defines some as built-in types.

> Which product implements it ?

Lee's Java-based product is the closest I know of.

> From my question you can see, that this is new to me.
>
>
> --
> Adrian Veith,
> Veith System GmbH.
> www.db-gonzales.de
Received on Sat Oct 13 2001 - 19:44:10 CEST

Original text of this message