Re: Object-oriented thinking in SQL context?

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 Received on Fri Jun 19 2009 - 01:54:18 CEST