Re: Clean Object Class Design -- What is it?

>> >Boys, boys. When will you two play nicely together? Honestly, sometimes
 I
>> >think you two *try* to misunderstand one another.
>>
>> I think I understand Carl extremely well. How do I not?
>
>Since the thread has been expired by my newsreader, I don't remember the
>context of this statement, other than that you two keep saying things like
 "The
>sky is blue!" "No, the soup is hot!"

Yes, I know. Carl must avoid direct responses to the issues I raise and must try to mischaracterize my points. He has snake-oil to sell, after all.

>> >Still, it would be nice if you would answer his question and tell us
 with
>> >which object databases you have experience.
>>
>> First, explain how it would have any relevance to any of my arguments.
>
>It may not have any relevance to you, but it is common courtesy in a
 discussion
>to answer a question when you are asked.

Hmmm. Apparently, you are saying that it is not discourteous to lie to people and to foster general misconception for financial gain, but it is discourteous to avoid irrelevancies. Interesting.

>You didn't answer my last question. Can an element of a domain be an n-ary
>relationship to another domain?

Of course. I have already stated that relation valued domains are quite acceptable.

>If I have a "Person" object (domain?) and it includes an open-ended number
 of
>Contact objects (domains?) is this modelled as a domain?

I doubt that I would often recommend such a design, but it is possible and allowable. I think that such a design would more likely appear in an application-specific view than in a base table.

>Normally, I would have expected this to be modelled as relations among the
>n-ary components. Exactly where do the domain boundaries come in?

Ultimately, that boundary will depend on many factors. Fabian Pascal's most recent book deals with addresses some of them.

>Note that two people ("Person" objects) can share the same contact
 information
>(co-habitants, co-workers). How does the relational model address this?

I am at a loss for why you think it might not. It would address this as it addresses everything -- as values in relations.

>How do
>domains play?

Domains specify data type, allowed values and available operations. How do object classes play?

>> >In an object-oriented world, an object can have members that are
>> >plain-ole-data (POD), other objects, references to other objects, or no
 data
>> >members at all. Can a domain do all this?
>>
>> Yes, it can.
>
>So the domain is a superset of relations?

Nope. A relation is an unencapsulated set of values and a domain is an encapsulated object class. Your premise is as absurd as suggesting that automobiles are a superset of parking lots.

>Too bad. You are the first person I've come across who doesn't model table
 as
>class and row as object.

I suggest you read some of Chris Date's recent works regarding data type, object-orientation etc. Fabian Pascal's most recent book offers a very good, practical introduction as well.

>This includes, I believe, the major ORDBMS vendors.

Aren't these the same vendors who gave you duplicate rows, non-updatable views, laughable integrity constraint declaration, "denormalization" for performance and a whole host of other monstrosities?

>If
>that basic premise is false, it deserves a little more explanation.

A relation is an unencapsulated set. A domain is an encapsulated data type. Haven't I already explained this? I know that Date explains it quite frequently in his work.

Can you believe that in another thread people accuse Date of confusing set and data type?

>If I understand correctly,
> domain ~ object class

Correct.

> tuple ~ object instance

Incorrect. Tuple (value or variable) ~ set of associated object values or variables

> relation value ~ collection ("set") of object instances

Incorrect. Relation value ~ set of tuple values, which are themselves sets of object values

> relation variable ~ collection of collection of object instance members

Relation variable ~ set of tuple variables, which are themselves sets of object variables.

>I'm confused where your distinction between "type" and "instance" is.

It is the same distinction everyone uses.

>A domain
>is a type and a tuple is an instance?

First, we need to make it clear that what most people call an instance is just a variable. A tuple value is a set of object values. A tuple variable is a set of object variables.

>And a tuple can have an element that is
>itself another tuple over which a relation is defined?

An element of a tuple can have arbitrary complexity provided that it is fully encapsulated.

>Hmmm. If the paradigm of the language is that everything is a pointer, then
 a
>Java variable does not "expose" a pointer any more than a FORTRAN variable
 does
>(which is, after all, just a pointer to a memory address).

There goes that word again... A fortran variable name identifies a memory address that stores a value, and one can argue that the completely unencapsulated nature of Fortran drove the market to explore newer, better languages. A java variable name identifies a memory address that stores a pointer to a memory address, and this is inherent in the definition of the language.

>> >so is the row-id generated by commercial
>> >RDBMSs.
>>
>> Which violate 1NF and which make commercial SQL databases non-relational.
 As
>> do duplicate rows etc. Do you have a relevant point?
>
>I guess not. Just trying to map this stimulating theoretical argument into
 the
>practical world in which I must code. I thought Carl was comparing ODBMS
 and
>(commercial) RDBMS -- SQL-DBMS if you please.

You seem to accept that SQL databases are non-relational and then you equate RDBMS with SQL-DBMS. Is the irony lost on you?

>> >It's just that the OID is more natural in an object-oriented
>>
>> You have not addressed any of my prior arguments (nor three decades of
 prior
>> arguments from relational proponents) regarding the problems of exposed
>> pointers and forced navigation.
>
>Nor am I likely to. However, what you see as the entirely evil "pointer
>exposing" I see as the beneficial "explicit relation".

I suggest you examine the three decades of prior work regarding the problems of forced navigation in database before you conclude any benefit. Pointers are anything but relations. Relations are explicit, symmetric and value based. Pointers are implicit, asymmetric and navigational.

>I find attribute joins
>problematic, especially where they force synthetic IDs into the data model

Do you mean you would prefer not to have any form of logical identifier? You will find such a lack much more problematic.

>Our backgrounds tell. A database outside the context of an application is
 of
>little value.

Au contraire. Forcing the context of a single application onto a database destroys value. A DBMS must meet the needs of all applications of the data.

>A database is a means to an end, not an end unto itself.

Yes. A DBMS is the means to meet the needs of all applications of a database.

>An
>application extracts data from the database and does something useful with
it.

Not necessarily. One could have an integrated programming language that requires no extraction to perform useful applications.

>Without an application, there is no user.

Without any applications, there is no database. Any given DBMS will have myriad applications and many users over an extended period of time. You are beginning to sound like you are constructing a straw man.

>Consequently, I view database
>management as only a subset of overall application development.

Again, you are proposing an absurd premise. Database management is necessarily orthogonal to application development. We tried making database management a sub-task of application development and it did not work. Hence, the advent of the DBMS.

>The line is not
>so clearly drawn in my mind as in yours.

That is unfortunate, but not at all uncommon.

>I doubt I can offer you any proof in this medium that will satisfy you.

I doubt that you could offer proof in any other medium. Your position derives from a demonstrably false assumption. Before you can even begin to form a valid counter-argument, you will have to abandon the false assumption.

>In real benchmarks
>we ran based on the nature of our application, the object databases where
 an
>order of magnitude faster than the SQL databases.

This does not address any of the points I have raised nor does it make any statement regarding the comparative advantages of either data model. If you are going to conclude that the relational model is slower than some object model, what aspect of either model explains the performance difference?

Further, you will need to provide much more information than you have given. How much effort went into the construction of each of the compared databases? What is the scope of the comparison? Can I easily introduce new applications and expect a comparable performance advantage?

>> That said: the full relational model won't ever get implemented until the
>> market willingly sheds its misconceptions and ignorance.
>
>I think this notion of how the market drives things is naive (I don't mean
 to
>be insulting). I can't envision any demand by the market that would cause,
 say,
>Oracle, to completely re-design and re-code its database offering to fully
>implement the relational model.

Who says Oracle must do anything? Did IBM satisfy the market demand for 80386-based computers back in the 80's? Or did Compaq eat IBM's lunch?

Are you saying that Sony doesn't produce VHS recorders, players, tapes etc?

Do you honestly think that those who recognize the power of free markets are naive?

>Once a vendor gets to a certain size (think
>Microsoft) they have a way of dictating to customers how they will think
 and
>solve problems.

I guess that's why folks are forecasting that Java will overtake C and C++ by next year.

>If the pure relational model is empirically superior for solving the
 majority
>of applications, some upstart will write a relational database and start
>gathering market share.

Here, you are discounting the cost of educating the market. Who is going to pay for the effort required to overcome all of the widely held misconceptions that the current vendors actively promote and prey upon?

>FWIW, I think the object databases have a better shot at this than the SQL
>databases. But I'm just a coder. What do I know?

I agree that SQL is too badly damaged to ever deliver on the promise of the relational model, and I also agree that any upstart will have to have full support for user-defined types. If you think that navigational databases have any chance of unseating SQL, you are ignoring history at your own peril.

>> >In
>> >fact, what you are in essence arguing for, while admitting the
 performance
>> >benefit of the object database representation,
>>
>> I have made no such admission. Please do not put words in my mouth. I am
>> quite capable of doing that myself.
>>
>> >is a layer on top of an
>> >object database that transforms the "natural" object structure into your
>> >pure relational model.
>>
>> Bullshit. Show me where I have ever made any statement even approximating
>> the above.
>
>Sorry I don't have chapter and verse handy, but you said more than once in
 this
>thread that a relational database could store its physical implementation
 in
>exactly the same way as an object database, thereby achieving exactly the
 same
>performance as an object database.

Physical independence is very different from "layering [anything] on top of an object database" and is the very antithesis of admitting a representation based performance advantage. I do not equate the physical storage options of object databases with object databases; although, I recognize that object databases equate their logical representation with a single physical storage option.

I repeat: Do not put words in my mouth.

>> >What I think Carl takes as a given and I don't think you accept at all
 is
>> >the target audience of the database. I think most object databases are
>> >intended to be used by programmers.
>>
>> I think anything claiming to be a DBMS must intend use by all users --
>> programmers and non-programmers alike. Any so-called DBMS that inherently
>> excludes a large portion of the user community does not perform the basic
>> function of database management.
>
>You are welcome to your opinion. I don't understand why you think that a
 DBMS
>must be useful to non-programmers.

You are welcome to your confusion. I only observe that programmers make up a tiny minority of the population.

>If a DBMS could respond to a query like a
>manager gives his secretary -- "Carol, pull the BizWorks file and let me
 know
>when they recieved the widget shipment!" -- then I might buy it. But I
 wouldn't
>expect that to be a fundamental feature of database management. If, on the
>other hand, you mean a ubiquitous, "standard" programming language (e.g.,
 SQL)
>by which one may extract and manipulate data of interest, then we are back
 to
>programming.

The representation of the data to the user involves no requirement of a "standard" programming (sic) language.

>> >I tend to side with Carl, because
>> >every database I've used (relational or object) was hidden behind the
 code I  

>> >was writing.
>>
>> Every database I've used was exposed directly to me, to my colleagues and
 to
>> other users of the DBMS. If you intentionally limit use of your databases
 to
>> programmers, I expect you to observe that only programmers use your
>> databases. I just question what one can conclude from the observation.
>
>The SQL interpreter you use or the 4GL report writer is software.
 Programmers
>wrote it. Interaction with the database by end-users is through software.
 As
>long as the end-users get the answers they want, they don't give a hoot
 about
>the purity of the data model underneath the hood.

Purity is not the issue. Simplicity and comprehensibility are. Users will not get the answers they want when confronted with a complex, incomprehensible representation of the data. Received on Sun Aug 26 2001 - 20:08:20 CEST