Re: Object-oriented thinking in SQL context?

"Nilone" <nilone_at_mega.co.za> wrote in message news:1245348769.884443_at_vasbyt.isdsl.net...
>
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:CKf_l.42$8r.40_at_nlpi064.nbdc.sbc.com...
>>
>> "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.
>
> I think I understand. So relation valued attributes and tuple valued
> attributes are attributes which define a relation schema, whereas each
> nested relation defines its own schema. Defining the domain of an
> attribute fixes its valuation function, and the definition of a schema
> defines the domains of the attributes in that schema. Does that sound
> about right?

Not exactly. A relation valued attribute draws its values from a domain of relations in the same way that an integer attribute draws its values from the domain of integers. It is the definition of the domain of relations that fixes the meaning of each member of that domain. What it boils down to is that a composition of symbols is more than the sum of its parts. At the same time that each symbol in the composition maps to something in the Universe of Discourse, the composition itself maps to something distinct from its parts. By defining the domain of relations, that something is the same thing at all times.

> Now, while we're talking about relation and tuple valued attributes, can
> they be used to solve the view update problem? I'm thinking that
> returning the source tuples on which the derived tuple is based, as
> attributes of the derived tuple, would allow the user to update the data
> from which the view was derived. Just wondering.

I doubt it. The view update problem is the result of the ambiguity inherent in the relational expressions that define views. It is made worse when deletes, updates and inserts are coerced into being relational assignments, for then it is not possible to determine whether the assignment was the result of an update, or a delete and an insert, or none of the above. Received on Thu Jun 18 2009 - 21:22:37 CEST