Re: Object-oriented thinking in SQL context?

From: Walter Mitty <>
Date: Wed, 17 Jun 2009 02:36:18 GMT
Message-ID: <CEYZl.1463$>

"none (Reinier Post)" <rp_at_raampje.> wrote in message news:4a381e7e$0$29930$
> Walter Mitty wrote:

>>analysis and design are easily confused with each other, but they are not
>>the same thing. The same would go for OOA and OOD.
> But here we are getting on slippery ground ... I've seen people
> defend that OO specification is already "design" or even "implementation".

Peter Coad makes a better case than I can that OOA and OOD are not the same thing.

And, no matter what formalism you use, it's easy to cross the line and start to describe a problem by describing some feature of a proposed solution to it.

>>The fact that database design features don't go into an ER model is not a
>>limitation of ER. It's a feature.
> Exactly.
>>That means that you can start with ER and from there move forward to
>>designing relations or SQL tables, or CODASYL sets, or IMS hierarachies
>>presumably some kind of persistent objects in an OODBMS, if there were
>>a thing.
> Or non-persistent objects; all it takes is calling your ER models
> "UML class diagrams" and tweaking the notation and details accordingly.

Fair enough.

>>> An ER diagram is a representation of the relations (tables)
>>Entities are not tables, or relations. It only looks that way.
> My point is that an ER model can also be "reverse engineered"
> (questionable name, btw) from an existing relational schema,
> the same way a UML class diagram can be generated from OO source code.
> Many tools can do this.

Agreed, except for questioning the name "reverse engineering". What's in a name? Received on Wed Jun 17 2009 - 04:36:18 CEST

Original text of this message