Re: Object-oriented thinking in SQL context?

"none (Reinier Post)" <rp_at_raampje.> wrote in message news:4a381e7e$0$29930$703f8584_at_news.kpn.nl...
> 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
>>or
>>presumably some kind of persistent objects in an OODBMS, if there were
>>such
>>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