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

Bob --

First, let me set the stage: The key difference between OO/AD and pure data modelling isn't the data at all, it is the behaviour. Look: While one could argue that a "table" in the relational world is a form of data encapsulation, and -- may god strike me down for saying this -- the stored procedure is a form of encapsulating the "behaviour" associated with these encapsulated data bits, it is a very weak link at best.

Your opening paragraph states that there might be the possibility of an object model that obviates the need to "normalize". Well, I certainly hope so! You see, "normalization" is a data modelling concept; it has no place in a "clean" object-oriented system. Responsibility and roles are what one should be designing towards in an object-oriented system, not the one-dimensional concept of "data normalization".

Now, one can constrain a system -- where a "clean" object model might live -- with a relational data store, which will cause a deformation of that once "clean" object model to begin. Why? Because the relational model has only one dimension, and that is the data it stores. You cannot cram multiple dimensions into fewer. In the end, some of that extra information has to be lost to the eternal bit-bucket. What goes? The roles, responsibilities -- the object model. Objects become fancy holders of primitive data that can be pushed into the relational database. Yuck.

Every type of "data" in an object-oriented system is an object. As where, in the relational world, it has to be boiled down to a primitive data type that is dumb. Really dumb. Say you have a "zip code". You certainly can't have a ZipCode table that stores only zip-codes for an entire data model. While Codd might admire you for trying, it isn't a practical implementation. So one must "denormalize" and create a primitive and non-descript version of the ZipCode in the relational model to aid in system performance.

(NOTE: I realize there are relational database systems that have quasi "class" specific capabilties, but they are not ones in popular use.)

This leads to: You cannot really compare relational modelling techniques with object-modelling techniques because the two are not even remotely similar. I'm sorry, but they are not. Mathematics debates aside, there is no similarity.

Do object-oriented systems contain data? Yes, they _are_ data. They are systems upon systems of "smart data".

Now, on to your question of, "Can one deterministically determine whether a given design is clean?" My answer: No. Well, kinda. You see, this is another rather big difference between the "old" world and the "new" world -- or, at least as I see it. Relational systems tend to be like fast moving trains: When you start a project and model data in the relational model, it is moving at a good clip. However, as you denormalize and finialize your model, the train slows down until it eventually stops. Now, you discover that some critical elements are missing! What to do? Sadly, it takes an army to start pushing that train again to get it up to high-speed because it weighs a ton -- and heaven forbid there are passengers (read: users) aboard that train. To bad, have to denormalize to get the new data in -- uh, the train just derailed.

My point is that relational models, to a large degree, require some notion of "clean", or done-ness. As where in the object-oriented world, backed by a transparent _object store_ (note: I did _not_ say, object-oriented _database management system_. This is a bad term; we must get away from it. It carries with it images of DB/2 or Oralce, or what have you. Bad.), there needn't be any arbitrary notion of "clean" or done-ness. One can continue to "factor" a system to cleanliness over and over again until one is satisfied. However, to get this, you _must_ have the right tools. Pairing an object-oriented language with a relational database is not, and I have a lot of personal experience here, the way to do this.

I will, however, finish by saying that for most problem domains there is usually a readily apparent, approximately "clean", object model waiting in the aether for one to grab and make real.

• Jeff Panici Worker Bee Solutions, Inc.

"Bob Badour" <bbadour_at_golden.net> wrote in message news:AFvS6.819$RP4.201306140_at_radon.golden.net...
> It has been suggested in another thread that a clean object class design
> obviates the need for normalization.
>
> In relational data modelling, I understand how normalization turns a fuzzy
> and general conceptual model into a robust logical model. The steps for
> achieving normalization are well documented, if not entirely
 deterministic.
> The algorithms for recognizing normalized designs are deterministic as
 well.
>
> What constitutes a "clean" object class design? How does one achieve the
> goal of "cleanliness"? How does one recognize a "clean" design vs an
> "unclean" design? Are the steps for achieving a "clean" design documented
> anywhere? Can we deterministically determine whether a given design is
> "clean" ?
>
> How?
>
>
Received on Sun Jul 22 2001 - 01:32:39 CEST