Re: Object-oriented thinking in SQL context?

From: Nilone <>
Date: Wed, 17 Jun 2009 20:46:37 +0200
Message-ID: <>

"Brian Selzer" <> wrote in message news:D28_l.32$
> "Nilone" <> wrote in message
>> "Bob Badour" <> wrote in message
>> news:4a2ee2f5$0$23770$
>>> 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

Original text of this message