Data Modeling/Object Modeling (was Re: [OT] RE: help -- persuade my boss to adopt ruby)

On Wed, 18 Dec 2002 09:43:51 +0900, Russ Freeman wrote:
> Yep, fair play Austin, your knowledge of data modelling is
> impressive. Thanks for the info.

To be fair, I was also sitting with my reference handy to use the
specific terms that I don't use on a day to day basis. I'm not a DM
theorist; I'm a practitioner. I don't necessarily use the terms on a
daily basis, I just look for the results to match my experience. As
I also noted, I will *often* use proxy keys, which is frowned on by
some practitioners. (I use proxy keys most often when the other
candidate keys are likely to be volatile.)

> It's funny because having worked with OO over the years, my
> perception is quite different to yours!

My perception is based on experience -- specifically, seeing OO
enthusiasts with no experience in data modeling (specifically, the
capturing of data as related to the customer's needs) attempting to
create an object model and then forcing the object model directly
onto the database. I'll also admit that I can't *stand* object
databases, far preferring object-relational and pure relational
databases. I find that object databases are suitable only for one
application. In most cases, this also means that there's a single
access path to the data. This makes it difficult to find all
customers in a single postal code because most people will design a
customer object such that the customer HAS-AN address object.

> Object modelling was always intended to be a superset of ER
> modelling, e.g. finer grained multiplicity, agregation, ternary
> assocations, etc.

I think it was intended as such, but I think that a lot of people
aren't taught data modeling *first* and are dumped right into (bad)
object modeling.

> It is natural for me to choose A UML model over an ER diagram. I
> have an Oracle book that provides good examples of how one
> converts a UML model into a nomalised ER model. (Although funnily
> enough I think many OO methodologies promote 3NF from the outset).

Em, well, I find UML useless for database stuff. I will choose a UML
model for a program's object model, but I will design the ER diagram
to be more flexible -- based on the needs of the users, not just the
needs of the program.

> I think the perception that OO designers focus on functionality is
> probably true - I do it myself! This is often called
> "Responsibility-driven design" (Check out Wirfs-Brocks book).

But this is, IMO, a mistake as a *first* focus. I've seen people
design a customer object by saying "a customer will sign up for
something," and they focus on the customer object's actions before
they consider *what* a customer object is. Both parts are necessary.
Absolutely, object designers should focus on functionality -- but
only AFTER determining what the initial data model itself is. (The
data model will, of course, be enriched by an iterative design
process and interaction with the functionality.) My problem isn't
that OO design looks at functionality, it's that the data model
itself is ignored first by many OO developers.

> A common problem in OO (and I suspect evident in ER communities
> too) is "analysis paralysis", where a developer gets carried away
> in trying to produce the finest model in existence. Martin Fowler
> pointed out in his "Analysis Patterns" book that there are
> infinite models of any problem.

It's common, though I think that it's more common in OO than in ER
because ER only represents the data, where as OO models can vary
based on functionality as well as data.

> The only concrete driver behind any data requirement is what users
> actually want to do with the application. Of course as experienced
> designers, we look ahead and anticipate furture requirements and
> thus the models to support them. This is however a gamble and
> indicative I think of over engineering.

You're right -- looking too far in the future is over-engineering.
What I tend to do is to look at what the client is already
collecting vs. what they need to collect for current and near future
projects. It's a bit more important to make sure your primary
entities are well-defined in a database model than in an object
model, because it's more expensive to extend a database than an
object...

> I think the real travesty about OO is that of transparent object
> persistence or lack of it, possibly from the [onslaught] of camp
> Oracle.

That's a tough situation. You're right, it would be nice to have
such transparency, but as I've said before, this would be a problem
because the data model for a particular program may not match that
of another program -- and it could be inefficient to force each
program to deal with the extraneous data from the first program.

> At the end of the day, I want to be able to program in a single
> lanaguage, be able to create complex models and relationships,
> travese them and change them (within the bounds of a transaction),
> without having to worry about how that information is being
> physically stored.

I agree ... but still have the problem that I pointed out above.
Additionally, you have the problem of versioning -- which isn't as
*big* a problem in relational databases as it is in OO databases
(but it is often present nonetheless; I've done too many migration
documents to pretend otherwise). The problem of versioning is
significant -- you need to upgrade the data "in-place". What you
need to do is to read the object from the OODB in with the old
object definition and write it with the new object definition -- it
might be transparent *how* this is done, but it's still necessary to
be done.

> Take PSQL (which I know you are higly skilled in - respect!). If I
> want to implement a complex ring structure in OO, it is easy. To
> persist this today in an RDB, I would have to resort to PSQL to
> manage the integrity of the cyclic dependency. Why should I have
> to learn another langauge to do this?

Actually, you may not need to do that with the latest versions (8i
and higher) of Oracle, as there is a way of implementing a "delayed"
foreign key. That is, a key which ensures constraints, but doesn't
do so until after the transaction is completed. The canonical case
for this sort of foreign key is a two-way mandatory relationship, as
in an order and an order line item. In versions prior to 8i (maybe
8.0), one of the foreign keys would have to be foregone or
implemented with a post-insert trigger (PL/SQL). In later versions,
the delayed foreign key can be placed on one of the two tables and
you can then insert into both the order and order line item tables
without worrying about "which is first."

> I think RDBMS will always be a major part of large businesses
> because they are such a simple and accessible tool. I hope however
> that there remains a niche for applications that can benefit from
> the best in OO and transparent persistence and I think ruby is
> absolutely ideal for this.

I dislike the Cachadvertisements where it suggests that an OO
database is superior to a relational database. There are (as I noted
above) significant disadvantages to OO databases that aren't offset
by the advantage of transparency offered by OO databases.

-austin
-- Austin Ziegler, [e-mail] on 2002.12.17 at 20.54.13