Re: Object-oriented thinking in SQL context?

Walter Mitty wrote:

>"none (Reinier Post)" <rp_at_raampje.> wrote in message
>news:4a2edac9$0$27727$703f8584_at_news.kpn.nl...
>
>> The entity-relationship method is often used, advocated and taught
>> for the design of databases. The design starts by creating
>> an entity-relationship diagram, that is systematically transformed
>> and provided with implementation detail until an ER diagram results
>> that specifies a relational database schema.
>
>Back when I learned databases, ER modeling (including diagrams) was NOT
>used for design purposes. It was used for data analysis.

You're absolutely right; it is prior to design, and I was lumping them together.

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

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

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

-- 
Reinier