Re: Object-oriented thinking in SQL context?

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:D28_l.32$OF1.1_at_nlpi069.nbdc.sbc.com...
>
> "Nilone" <nilone_at_mega.co.za> wrote in message
> news:1245239158.868623_at_vasbyt.isdsl.net...
>> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
>> news:4a2ee2f5$0$23770$9a566e8b_at_news.aliant.net...
>>> none Reinier Post wrote:
>>>>
>>>> Think 'class' ~ 'relation' (table)
>>>
>>> But that would not only be a blunder but a great blunder.
>>
>> I'd like to clarify this for anyone coming from the OO side. If you map
>> class to relation, you're breaking the OO rule of encapsulation and
>> reducing the class to a simple aggregate type (struct). Presumably, you
>> chose an encapsulated, polymorphic abstraction device for a reason, or
>> did you do so just because you (or somebody at your company) read
>> Lhotka's book? Classes map to domains (types) in the relation model, but
>> be aware that subclassing is NOT subtyping.
>>
>
> I disagree. Classes that are reference types map to relation schemata,
> not relations, and definitely not domains. Domains were originally
> supposed to be disjoint sets of constant symbols, but instances of a
> reference type can appear different at different times, so they are
> definitely not constants; therefore, so long as there can be reference
> types, not all types are domains. Classes that are value types, on the
> other hand, can map loosely to domains, since each instance is the exact
> same value wherever and whenever it appears. I say loosely because
> whenever a value type is defined with more than one attribute, it is
> closer to being a relation schema for which there is and can only ever be
> exactly one instance than being a domain, and that instance could be
> referenced directly in relational expressions.
>
> Non-simple domains, though convenient, perhaps, introduce complexity that
> is rarely, if at all, required. Usually, the same information can be
> recorded using simple domains, thereby reducing the complexity of the
> queries used to retrieve information, and I'm a great believer in the
> keep-it-simple-stupid adage. Moreover, non-simple domains do not
> completely eliminate the need for either nested relations or the
> introduction of surrogates. A relation that has a relation valued or a
> tuple valued attribute is not the same thing as a nested relation, because
> each non-simple component of a tuple in a nested relation can "mean"
> different things at different times, but each element of the domain for a
> relation valued or tuple valued attribute can only "mean" one thing for
> all time. As a consequence, flattening out a nested relation schema may
> demand the introduction of surrogates.
>

I understand and agree. Thanks for explaining. However, I don't understand the part about a nested relation being different from a relation valued or tuple valued attributed. Specifically, what do you mean by 'each non-simple component of a tuple in a nested relation can "mean" different things at different times'?

Nilone Received on Wed Jun 17 2009 - 20:46:37 CEST