Re: Help! I can't support normalization

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Fri, 8 Nov 2002 20:56:52 -0000
Message-ID: <aqh8g6$16a4$1_at_sp15at20.hursley.ibm.com>


"Mikito Harakiri" <mikharakiri_at_yahoo.com> wrote in message news:bdf69bdf.0211081037.358377d3_at_posting.google.com...
> The question is if a representation spanning into 2 columns is
> legitimate. For example,
>
> table circuit (
> voltage_absolute_value NUMBER,
> voltage_phase NUMBER
> )
>
> has r * e ^ theta representation of complex number spanning into 2
> columns. The canonic design according to D&Co. would be
>
> table circuit (
> voltage COMPLEX
> )
>
> since they seem to feel uneasy about a value being decomposed. IMHO,
> this doesn't really matter, because we can always define a view that
> converts one representation into another:
>
> select voltage_absolute_value*cos(voltage_phase) as voltage_real,
> voltage_absolute_value*sin(voltage_phase) as voltage_imaginary
> from circuit

I guess it depends on whether you would find a data type of VOLTAGE useful in your database. It helps 'package up' any constraints that might otherwise be needed where a representation spans multiple columns. Also it is probably easier to make a VOLTAGE datatype updatable than the view above, and you can still have your decomposition views:

select abs_value(voltage) as voltage_absolute_value,

        phase(voltage) as voltage_phase
from circuit

Plus if there are any constraints between voltage_absolute_value and voltage_phase, I guess the DBMS could infer them from the presences of both phase(voltage) and abs_value(voltage) functions in the view.

Finally, if we could categorically advise against representations that span 2 columns, then that is one less thing for every database designer to choose between.

Agree?

P.S. I hope you don't really believe that only Jan contributes usefully to this group.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Fri Nov 08 2002 - 21:56:52 CET

Original text of this message