From: Russ Freeman <russ@...>
Date: 2002-12-18T21:19:46+09:00
Subject: Re: Data Modeling/Object Modeling (was Re: [OT] RE: help -- persuade my boss to adopt ruby)

>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. 
<snip>
>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.
<snip>
> 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.
<snip>
>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 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.

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.  

> 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.

> 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 :)

> -austin
> -- Austin Ziegler, austin@halostatue.ca on 2002.12.17 at 20.54.13

Thanks for the comments
Russ

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/2002
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/2002