Re: Object-oriented thinking in SQL context?

"Nilone" <nilone_at_mega.co.za> wrote in message news:1245264392.410845_at_vasbyt.isdsl.net...
>
> "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'?

Just to be clear: a nested relation is different from a /relation/ with a relation valued or tuple valued attribute.

The meaning, or value, of a component, is the output of the valuation function (hence its name) for the first order language term that corresponds to the component. The valuation function maps each language term that denotes to things in the snapshot of the Universe of Discourse at the instant of interpretation. For constant symbols, the output of the valuation function is the same thing wherever and whenever it occurs. For a term that is a composition of symbols, the output of the valuation function can be different things at different times. For example, "the car in the handicapped parking spot" could mean a blue Volkswagen Beetle in the morning or a black Lincoln Continental in the afternoon, or the spot may be empty during lunch, in which case "the car in the handicapped parking spot" does not denote. For an instance of a relation-valued or tuple-valued attribute, on the other hand, the output of the valuation function must be exactly the same thing wherever and whenever it appears. By defining a domain of relations or tuples, the meanings of those relations or tuples become fixed for all time.

In another thread, I described an example relation schema for bins in warehouses in which the entire heading is the only key.

Bins {Warehouse, Row, Shelf, Bin}

In the same way that two distinct sets of components can map to the same bin but just at different times and that the same set of components can map to different bins at different times, two different sets of tuples or named values that each comprise a non-simple component of a tuple can map to the same thing but just at different times and the same set of tuples or named values that comprises a non-simple component can map to different things at different times. Received on Thu Jun 18 2009 - 02:19:49 CEST