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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:2Mj17.4135$yM.67616956_at_radon.golden.net...
> >> >> One would want the physical store independent of the logical
 specification
> >> >> in any case. This is a good thing.
> >> >
> >> >Let's start with a naive question. Why?
> >>
> >> One wants the user to see as simple a view of the data as possible. One
 does
> >> not want to force users to understand inessential data to complete
 their
> >> tasks. One prefers to say: Such and such data is here. One prefers not
 to
> >> say: Such and such data is here and is duplicated here or can be
 derived
> >> there.
> >
> >So a user here would be someone who wants to query the database?
>
> Some users do. Regardless of whether the user wants to query the database,
> the user needs to understand some logical view of the data. Otherwise, the
> user isn't a user.
>
>
> >I think a fundamental disconnect between relation practioners and OO
> >programmers has to do with the whole notion of access to data. In an OO
> >world, *direct* access to data is evil.
>
> As it is in the relational world. Why should any data type expose the
> internal representation of the data to the user? Doesn't this violate
> physical independence?

Ummm....

UPDATE Foo SET Bar = "Baz"

That looks like direct data access to me. And yes, you can wrap some view around your tables, but you are still updating columns of rows of tables *directly*.

Let me try again. Suppose you have a Point. A view exposes this Point in Cartesian coordinates, but the underlying representation is in polar coordinates. In OO, I can constrain that X and Y must be set together, but not independently.

aPoint->setXY(5,6);

Updating through a relational view is trouble:

Update Point SET X = 5, Y = 6

Can a trigger on X know whether Y is also being updated? Can it prevent X being updated if Y is not also updated?

> >It is precisely because of the
> >integrity arguments you cite frequently that such is true. It is also
> >*precisely* to hide implementation details from "users". So rather than
> >state "such and such data is here", I would state, "this object supports
 a
> >method that returns this data".
>
> Your initial assumption is false which renders the remainder of the
 argument
> irrelevant.

Or your understanding of my initial statement is flawed. See how hard it is to use someone else's vocabulary effectively?

> >However, if access is already
> >constrained through methods, the machinery to ensure integrity is also
> >maintained.
>
> I disagree. What prevents someone from introducing a new method that
> violates integrity? Even a DBA? In the relational model, the dbms itself
> prevents all users, including the DBA, from violating known constraints.

Another relational/OO mismatch. Many small projects do not have the luxury of "a" DBA. In every program I've worked, the application programmers designed and implemented the database. So I might contend that one who would write such a function is acting in a DBA role.

While it may be possible for a programmer to bypass methods of a class that enforce constraints in a ODBMS, you deserve what you get. It is a fact that in the ODBMS with which I am familiar, one programs "closer to the metal" than with RDBMS. This can be good and bad. With power comes risk.

> >> For example, if one decides that one needs to cluster invoices with
 purchase
> >> orders for performance reasons, one does not want to force invoice
 users
 to
> >> know this.
> >
> >Here a user is a database programmer?
>
> Here a user is a user. I don't want to force any user, other than the DBA
> responsible for physical design, to know that invoices are stored with
> purchase orders. Whether the user is a programmer, business analyst,
 manager
> or clerk, it serves no purpose to force any of them to access a purchase
> order to reach an invoice in those situations where the user just wants
> access to an invoice.
>
>
> >Such a user probably *does* need to be
> >aware of performance constraints on the database.
>
> Again, your initial assumption is false which renders the remainder of the
> argument irrelevant.

Again, your reading is flawed. The only one who needs to know where an object is clustered is the programmer who writes the inserter. I don't think this is different between relational or object. And I don't believe any "user" of any database routinely (if ever) inserts data using raw SQL commands. They use some user interface instead, which has already put a layer of abstraction on top of whatever persistence model you use.

> >Again, the OO approach
> >would be to abstract the insertion into a factory method that performs
 the
> >clustering in the same way a relational DB would.
>
> Huh? The relational database peforms the clustering without requiring any
> additional methods or idioms. One inserts the data the same way one would
> insert the data when the data are not clustered. The non-relational OODB
> approach is in no way similar to the relational approach.

The relational database requires someone to write SQL to accomplish clustering. This is code. This code instructs the DBMS how to cluster. The syntax may not be the same, but the methodology is.

> Do you honestly contend that requiring users to learn and use unique
 methods
> for every operation will aid comprehension for business analysts,
 managers,
> shop supervisors and clerks?

See above. Since the shop clerk is using a data entry screen, what difference does it make what happens underneath?

> >What is external integrity?
>
> Any database constraint that is not strictly a domain constraint.
>
>
> >Guaranteeing that the "PERSON_ID" field of an
> >employee record refers to an existing person? That is part of the
 internal
> >state of an object.
>
> Really? When I delete a person but not the referencing employee, I am
 merely
> manipulating the internal state of the person object?

I'm telling you that such an operation is invalid, and in some cases impossible. As I said, there are ODBMSs that enforce referential integrity. If you delete a person, the employee will also be deleted automatically.

> Can I assume you expect a database design independent of application
 design?
> Can I assume you expect the OODB to have its own language(s) independent
> from the application programming language? Can I also assume you think the
> OODB might on occasion require a little administration?

As mentioned elsewhere, the ODBMs market is immature. The standards body is impotent if not irrelevant. Some vendors use DDL. Some use language header files. There is no common method among or between products.

So I don't expect anything. I just deal with what I have.

But, yes, I'd expect *any* database to require administration on occassion.

> If I can assume these things, what are the advantages you think a
> (non-relational) OODB has over a relational database? Apparently, you
> disagree with the other vendor.

For me, the advantages over relational databases are greater expressive power and improved performance. I've heard you reject these claims but I haven't seen any proof to sway me.

> In a relational database, the user learns a small number of statements for
> changing the state of the database. In SQL, those statements would include
> INSERT, UPDATE, DELETE. Casual users woud not have authority for CREATE,
> ALTER or DROP and would have no need to learn them.

YMMV. In my experience, "casual" users have no business updating data. Any modification that happens routinely is hidden behind a user interface. So then what?

The difficulty is not in learning "INSERT, UPDATE, DELETE". It is in learning the names of the tables (or views) and columns and in knowing the effect of changing a given field or row on the rest of the world. That's the primary reason we create user interfaces.

> Does this not mean that the causual user must then learn many unique
> class-specific methods instead of a few generally applicable statements?
 How
> is this any different from forcing the user to enforce the integrity
> constraints in the first place?

Because the "casual" user is forced to use the public interface of the object, he is not able to violate the integrity constraints that were programmed in.

> What is different about the OODBMS that it requires no additional thought
 or
> care on the part of the class designer? It certainly complicates things
 for
> the user. How does the user even know what method to use or where to
begin?

It is very easy to create tables and relations that do not enforce referential integrity. Constraints are established through distinct (and optional) SQL statements that the database designer must remember to add. You can (justly) argue that an experienced DBA will do this by nature. Fine. I'll leave it at parity.

> >Are you suggesting that your sales analysts are writing C++ code to
 access
> >an object database just so they can by-pass built-in integrity
 constraints
> >and prove your point?
>
> No, I am assuming the programmers on my development team might, though.

And if your developers change the interface of your persistent classes, that's the same as altering the schema, which I thought was the purview of the DBA. People in power can screw things up.

> >Inheritance should only be used to describe immutable relationships.
> >Employment is not immutable. So while one analysis might conclude that an
> >employee "is a" person, a better analysis would decide that employee is
 just
> >a role a person plays.
>
> What about the inheritance relationship others insisted exists between
> manager and employee? ie. Manager "is a" employee. ?

Certainly a Manager "is a" employee. He/she gets paid doesn't he/she?

> The following question is particularly important:
>
> Is a circle an ellipse?

No it's not. It's tired. Go to any OO reference for a full treatment.

> >If I have systems that understand "vehicle", I can extend my model to
> >include "airplane" and "submarine" as subtypes of vehicle and the
 existing
> >systems function properly using the new data types. This is powerful and
> >useful.
>
> If existing systems understand that one can take a vehicle from Las Vegas
 to
> Los Angeles, how will the existing systems allow one to take a submarine
> from Las Vegas to Los Angeles?

Your premise is flawed, so the rest of your argument is irrelevant :-)

*all* vehicles are capable of going from Las Vegas to Los Angeles?

> >> How many OO programmers do you know who would even recognize when to
 look
> >> for multi-valued dependencies or join dependencies?
> >
> >Since you've used inherently relational terms, I'll humor you by saying
> >precious few.
>
> A multi-valued dependency is a multi-valued dependency. A join dependency
 is
> a join dependency. Each relates to multi-way relationships. Do OODBMS not
> support multi-way relationships?

Sure, they directly model N-ary relationships.

> I certainly have not. I have explicitly stated that relational databases
 are
> object databases. Have I damned relational databases or those who use
them?

That's actually a relatively new though in this thread and one which I have a hard time buying.

> >The type of collection is an implementation decision that *may* be driven
 by
> >the problem space. However, I don't see how the type of collection could
> >make one model unsuitable for another application.
>
> If you absolutely have to have a hash for a performance critical, business
> critical application, you don't see how that might affect another
> application that prefers to index into an ordered array?

I'm confused by your circular reasoning. On the one hand you argue for physical indepdence, then you construct straw-man applications that depend on a particular physical implementation. Why would an application "prefer" to index into an ordered array?

> >So what if a collection
> >is implemented as a hash map? I can still query it. The "user" (a term
 you
> >seem to use with little precision) doesn't need to concern himself.
>
> Really? The user can treat the hash map as an ordered array? When the user
> applies restriction to a hash map, what results? Is the result still a
 hash
> map? When the user constructs the intersection of the array of students on
> the dean's list (ordered by rank) with the bag of students enrolled in the
> faculty of medicine, what is the type of the result? Is it an array? Is it
 a
> bag? Wouldn't it be important for the user to know which?

Ummm.... what's a CURSOR? Let's assume that the result of your query is analogous. Received on Sun Jul 22 2001 - 01:34:03 CEST