Re: Object-oriented thinking in SQL context?

From: Bob Badour <>
Date: Thu, 18 Jun 2009 16:52:34 -0300
Message-ID: <4a3a9b06$0$23772$>

Nilone wrote:

> "Brian Selzer" <> wrote in message 
> news:CKf_l.42$

>>"Nilone" <> wrote in message
>>>"Brian Selzer" <> wrote in message
>>>>"Nilone" <> wrote in message
>>>>>"Bob Badour" <> wrote in message
>>>>>>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?

I think it is long past due to cite Date's _Principle of Incoherence_. Received on Thu Jun 18 2009 - 21:52:34 CEST

Original text of this message