Re: Object-oriented thinking in SQL context?

From: Walter Mitty <wamitty_at_verizon.net>
Date: Tue, 09 Jun 2009 22:45:45 GMT
Message-ID: <tCBXl.66$P5.50_at_nwrddc02.gnilink.net>


"Bernard Peek" <bap_at_shrdlu.com> wrote in message news:YsEN5ynCstLKFwbA_at_shrdlu.com...
> Some years back I was handling support for a CASE tool that handled
> normalisation. The users didn't want a tool that took them through the
> various stages, they assumed that the first time they committed a
> structure to the system it would already be in TNF - which was as far as
> they were interested in.

Some years back, I had occasion to use Data Architect, part of the Power Designer suite from Sybase.

It had two kinds of data models, a Concpetual Data Model and a Physical Data Model.

The CDM was basically ER modeling with a few additions. It also supported user defined domains.

The PDM was DBMS specific, for any one of over a dozen DBMSes. The PDM included tables, indexes, procedures, yada yada. And also product specific objects like Tablespaces for Oracle.

If you did the ER model "right", your table came out in 3NF right away. Two examples of "wrong" ER modeling: attaching an attribute to the wrong entity, and picking bad keys for your entities. IIRC, you couldn't hang attributes on relationships. If you had a relationship with attributes, you had to "reify" it. The word "reify" wasn't in DA documentation. I picked it up somewhere else. It's right up there with haeccity. Received on Wed Jun 10 2009 - 00:45:45 CEST

Original text of this message