Re: Object-oriented thinking in SQL context?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 18 Jun 2009 23:05:45 -0300
Message-ID: <4a3af27d$0$23771$9a566e8b_at_news.aliant.net>
>>Nilone wrote:
>>
>>>On Jun 18, 9:52 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>>>Nilone wrote:
>>
>>>>>"Brian Selzer" <br..._at_selzer-software.com> wrote in message
>>>>>news:CKf_l.42$8r.40_at_nlpi064.nbdc.sbc.com...
>>
>>>>>>"Nilone" <nil..._at_mega.co.za> wrote in message
>>>>>>news:1245264392.410845_at_vasbyt.isdsl.net...
>>
>>>>>>>"Brian Selzer" <br..._at_selzer-software.com> wrote in message
>>>>>>>news:D28_l.32$OF1.1_at_nlpi069.nbdc.sbc.com...
>>
>>>>>>>>"Nilone" <nil..._at_mega.co.za> wrote in message
>>>>>>>>news:1245239158.868623_at_vasbyt.isdsl.net...
>>
>>>>>>>>>"Bob Badour" <bbad..._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?
>>
>>>>I think it is long past due to cite Date's _Principle of Incoherence_.
>>
>>>It applies. I value Brian's patience as I home in on the concepts.
>>
>>>Nilone
>>
>>I have more concern for his coherence than for his patience.
Date: Thu, 18 Jun 2009 23:05:45 -0300
Message-ID: <4a3af27d$0$23771$9a566e8b_at_news.aliant.net>
Nilone wrote:
> On Jun 19, 1:35 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >
>>Nilone wrote:
>>
>>>On Jun 18, 9:52 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>>>Nilone wrote:
>>
>>>>>"Brian Selzer" <br..._at_selzer-software.com> wrote in message
>>>>>news:CKf_l.42$8r.40_at_nlpi064.nbdc.sbc.com...
>>
>>>>>>"Nilone" <nil..._at_mega.co.za> wrote in message
>>>>>>news:1245264392.410845_at_vasbyt.isdsl.net...
>>
>>>>>>>"Brian Selzer" <br..._at_selzer-software.com> wrote in message
>>>>>>>news:D28_l.32$OF1.1_at_nlpi069.nbdc.sbc.com...
>>
>>>>>>>>"Nilone" <nil..._at_mega.co.za> wrote in message
>>>>>>>>news:1245239158.868623_at_vasbyt.isdsl.net...
>>
>>>>>>>>>"Bob Badour" <bbad..._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?
>>
>>>>I think it is long past due to cite Date's _Principle of Incoherence_.
>>
>>>It applies. I value Brian's patience as I home in on the concepts.
>>
>>>Nilone
>>
>>I have more concern for his coherence than for his patience.
> > I followed most of what he said, although I had to work at it. I'll > appreciate it if you'll clarify the issue. > > Nilone
Trying too hard to understand something can be a mistake. Simple and sensible don't take a lot of effort to understand. Received on Fri Jun 19 2009 - 04:05:45 CEST