Re: Object-oriented thinking in SQL context?

In message <epAXl.50$P5.2_at_nwrddc02.gnilink.net>, Walter Mitty <wamitty_at_verizon.net> writes
>
>"Gene Wirchenko" <genew_at_ocis.net> wrote in message
>news:b0it25h2ai2ag1qghti23d0mq6evsbetnj_at_4ax.com...
>> Tegiri Nenashi <TegiriNenashi_at_gmail.com> wrote:
>>
>>>On Jun 9, 11:27 am, "Walter Mitty" <wami..._at_verizon.net> wrote:
>>>> Data Normalization. I don't know what this corresponds to in OO design.
>>>
>>>Refactoring?
>>
>> Since the two areas are different, why strain at correspondences?
>>
>> Normalisation is during design. Refactoring is after the fact.
>>
>
>Actually, normalization is a bottom-up approach, and is done after the fact.
>After the fact of coming up with an unnormalized model. If you do modeling
>*correctly*, your model will be normalized as soon as you build it, and you
>don't have to go through the rigmarole of converting the schema into another
>equivalent schema that acheives a higher normal form, and repeating that
>exercise.
>
>Having said that, I never learned how to model data *correctly*, so I ended
>up normalizing during design time, just as you say.

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.

-- 
Bernard Peek