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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:tQa17.4132$1L2.65073291_at_radon.golden.net...
> >> >Hmmm. You seem to be talking at cross purposes. Capturing the
 "semantics
 and
> >> >rules of the business" seem like a single application to the exclusion
 of
> >> >all others.
> >>
> >> I disagree. It is possible using a single relational data base to
 capture
> >> employee information cogent and useful for all uses. Payroll may only
> >> interact with a small subset of the employee data, but the database can
> >> enforce rules required by HR and other applications.
> >
> >By the same token, it is possible using a single object data base to
 capture
> >employee information cogent and useful for all uses. This not a feature
 of
> >relational or object oriented, but of good analysis and design.
>
> The OODB forces one to choose between arbitrarily different interfaces
 when
> modelling a single concept like a one to many relationship. The OODB
 forces
> one to choose between these arbitrary interfaces because each implies a
> different physical storage structure with different performance
> characteristics.

Why are you hung up on this? What difference is there *semantically* between a set and a relation that enforces uniqueness? Oh, the "arbitrary interface" thing. I don't get it. All the containers I deal with have a consistent interface. Choosing one container over another does not bias me toward an application any more than any other analysis decision. No one is prescient enough to always design for re-use in every condition.

> An RDBMS does not force one to choose between arbitrary interfaces for a
> single concept. All information are represented to the user as values in
> relations. Physical structure is handled independently from logical
> interface. One can change the physical bias of the database without
 changing
> the logical interface or any of the dependent applications.

But we aren't dealing with a single concept. You complained earlier about being forced to learn new concepts such as "bag" and "set" when the one "relation" would suffice. But "bag" and "set" do not map directly to "relation". You must add constraints on your relation and awkward arbitrary key values (that are often manufactured to make joins of disparate tables possible) in order to accomplish these concepts.

And if you are dead set on not learning new concepts then why are you even using a computer? New concepts extend our corporate body of knowledge so that the general public can deal with complex information that they did not have to derive. What's wrong with that?

> For example, the base relation may contain an entire employment history
> showing every department the employee ever worked for. One view might show
> the unique current department employing the employee. Another view might
> show the unique department that originally hired the employee. Yet another
> view might show all of the departments the employee worked in during the
> current calendar year.

Fine. These views are created because someone (you?) programmed them. I can program the same "view" into my objects. Of course, if the data model was not constructed to support all these views in the first place (e.g., "department" as a column of "employee" rather than an assignment table that links employee to department by date), then you will have to do a bit more work. So would I. So where's the beef?

> What facility do OODBs have to support the example given above? Since
 OODBs
> add needless complexity to the logical interface, what facility do OODBs
> give to allow one application to see a bag of employees per department in
> one view, a hash of employees per department in another view and an array
 of
> employees per department in a third view?

The same facility as a relational one. Someone programs in support.

I disagree with your assertion that OODBs add needless complexity. And since you reject the validity of bag/set/hash as distinct and valuable concepts, why do you then propose a strawman application where the distinction is significant? If it were, then the relational approach is doomed, since it can't even represent these distinct collections.

> >> When the consultant denormalized the data, did the database still
 enforce
> >> all of the referential integrity constraints?
> >
> >As I recall, the changes obviated some referential integrity constraints.
 It
> >had to do with variable-length elements being replicated as "field1,
> >field2,..." in a table.
>
> After this transformation, how does one formulate a query to search for a
> value that might appear in any of the fields?

The way one might expect: field1 = val or field2 = val or ...

That's part of the reason we didn't design the database that way in the first place.

> >> In what ways did the consultant denormalize? If he repeated data across
> >> multiple rows, would it not have been preferable to use physical
 clustering
> >> or physical redundancy without changing the logical view of the data?
> >
> >Perhaps, but physical clustering was not an option.
>
> Why not? Physical clustering would have given identical performance
> characteristics and still allowed users to easily search for a value that
> might appear in any of the "fields".

Because the database didn't support it.

> >> Would it not have been preferable to index the join without changing
 the
> >> logical view of the data? Could the database not have added a physical
> >> pointer to improve a lookup without changing the logical view of the
 data?
> >
> >Perhaps, but the cost of indexing dwarfed other performance issues.
>
> I see. Replacing two indexes with one index would have added indexing
 costs.
> Seems a little far-fetched to me.

Replacing no indices with one index added substantial cost. The original relation was not indexed.

> >> The question is: Why should I have to change the logical view of the
 data
 to
> >> achieve the physical performance I require? Some vendors provide more
> >> physical independence than others, but even the best implementations
 fall
> >> far short of the mark.
> >>
> >> Why does everyone want to throw away the logical model just because
 vendors
> >> have failed to deliver on the physical side? Changing the logical model
 will
> >> only make things worse.
> >
> >My favorite quote is attributed as Coggins' Law of Software Engineering:
> >"Elegance must give way to pragmatics because Nature cannot be
 impressed."
>
> Unfortunately, the quotation does not address any of my questions.

Certainly it does. People abandon purity to achieve success. Sometimes you do whatever you have to to get something to work. Even if it's not pretty, you have to live within the constraints nature gives you. These include the current state of the art of your database vendor's product.

> >Theory is great. Mathematical proofs are wonderful. But when you have
 real
> >problems to solve, sometimes the ugly solution wins.
>
> The problem here is the ugly solution is only required due to retarded
> database implementations. Of course, given no other choice, one must
 accept
> the ugly solution. The question is: Why do we have no other choice? It is
> certainly not a failing of the relational model; although, vendors are
 wont
> to lay the blame there.

Different thread in which I choose not to participate.

Some people look at things as they are and ask, "Why?" Others look at things as they might be and ask, "Why not?" I just make my software work.

> >And I'm suggesting that there are data more complex than sales orders and
> >payroll and other business-related constructs that are not so amenable to
> >user ad-hoc queries.
>
> Your statement was that users are not capable of creating cogent queries.
> Users are capable. If the data relates to their area of expertise, they
 will
> understand the complexities inherent in it.
>
> What data are so complex that the complexity exceeds the comprehension of
> the user community? If the data is this complex, how can anyone understand
> or model it?

Actually, the users don't want to have to learn or type arcane SQL statements.

I've been doing this for 20 years. I even provided an ad-hoc query capability on top of a relational database once and the users requested buttons for pre-defined queries instead.

And not all of my users *do* understand the complexity of the data. That's one of the reasons we create automated systems to process it. The question is not whether *anyone* can understand or model it, but whether the *average* user can do so. In my case, the answer is usually, "no".

> >And you have yet to acknowledge that it is *possible* that an object
> >database could be a superior tool for some applications.
>
> If the object database is a relational database, then it most definitely
 is
> a superior tool. In what respect is a network model database superior to a
> relational database?

You've missed my point.

Is it POSSIBLE that there is AT LEAST ONE application for which an object database is a superior tool than a relational one?

> >The gist of all
> >your preceding posts is "ODBMS are all crap. Users of same are ignorant.
 The
> >world would be a better place if they just got the true religion of
> >relational."
>
> Relational is not religion. Again, I find your accusation insulting. The
> world really would be a better place if more people, whose business it is
 to
> manage data, would just learn the basics of data management.

If you answered "no" to the above question, then either you are omniscient and therefore God, or you are making a religious assertion based on incomplete information. If you answered "yes", then I can live with most of what you've said. Received on Sun Jul 22 2001 - 01:34:02 CEST