Re: Object-oriented thinking in SQL context?

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:_tw_l.93$8r.65_at_nlpi064.nbdc.sbc.com...
>
> "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.

OK, I wasn't being consistent about the meaning of domain as applied to compositions.

>
>> 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.
>

I appreciate your time. I need to hit the books again - I'll focus on these topics.

Nilone Received on Thu Jun 18 2009 - 22:52:04 CEST