I wrote:
>> My perception is based on experience [...] seeing OO enthusiasts
>> with no experience in data modeling [...] attempting to create an
>> object model and then forcing the object model directly onto the
>> database. [...] most people will design a customer object such
>> that the customer HAS-AN address object. [...] I think that a lot
>> of people aren't taught data modeling *first* and are dumped
>> right into (bad) object modeling. [...] I find UML useless for
>> database stuff. [...]

Russ Freeman wrote:
> I feel that much of your experience is of bad OO design rather
> than OO models as a flawed tool. Many of the situations you state
> are about the kinds on models people are comming up with rather
> than defects in the notation and technology of OO. Clearly an OO
> database is going to make a poor enterprise model even worse.

You're right -- but as much as anything else, I'm also condemning
the state of *training* for people who try to do OO models. I think
that I'm a decent object modeler, but only because I'm a damn good
data modeler. (Humble? About that? No way.)

UML *as it currently stands* (version 1.x) is a very poor fit to
database modeling, as it provides little information that a good ER
model provides. Relationships in UML are much more about IS-A and
HAS-A inheritance and containment relationships, whereas foreign
keys in databases are much more than just HAS-A relationships. An FK
can represent a HAS-A relationship (an employee HAS-A manager [also
an employee], represented as a "pig's ear" FK notation in ERDs).
Alternatively, it can represent an "is-constrained-by" relationship
(an email address stored in one table must map to a valid account).

I *personally* find the "crow's feet" notation much easier than the
diamond notation used in UML (the crow's feet notation can indicate
whether a relationship is mandatory or optional and "to one" or "to
many" -- without using the 0 .. * and 1 .. * notations required by
UML).

Within UML, I will use a lot of the features available: use
cases[1], class models, state charts, message passing charts (both
forms), etc. It's really quite useful for expressing how the system
will work, but I find that it's easier to consider the data model
*separate* from the object model, although they are definitely
related and there will be a feedback loop between the models.

> When I design a system I look at it from both a functional and
> data perspective. It is the insersection of these two views that
> produces a layered, flexible OO model, where the lower layers
> model common business entities, that are reusable across an
> enterprise, and higer layers that are specific to applications.
> The lower layers are likely to correlate with the models you refer
> to. However for me I would prefer to use a single modelling
> notation and langauge to capture and build these systems.

If I felt that UML could actually capture the information I need
from a database model, I would use it. So far, it has proven to be
incapable of doing so.

>> 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.
> Yes, good point.

I do find that having the data model and object model separate helps
here -- just a little. The data model gives the object modelers a
starting point for their object model and then they can modify their
object model's data as necessary to support the functionality
required. If they need more data than the data model provides, then
it's a matter of enhancing the data model -- but in a dynamic
system, that's healthy.

>> 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.
> Interesting, I'll take a look at those. However I'm not convinced 
it
> makes me feel anymore at one with my core lanaguage :)

It's a feature that's nice -- but I haven't yet used. (: I think it
will solve the problem you mentioned in that you can then have the
circular dependencies you want without violating transaction scope.

-a
[1] The creation and use of use cases is very poorly explained in
    every text and class I've had on UML, including a couple of
    "Rational University" courses a former employer paid for.
-- Austin Ziegler, austin / halostatue.ca on 2002.12.18 at 23.34.35