Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Possible bridges between OO programming proponents and relational model

Re: Possible bridges between OO programming proponents and relational model

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 05 Jun 2006 23:59:46 GMT
Message-ID: <Sz3hg.18047$A26.418157@ursa-nb00s0.nbnet.nb.ca>


JXStern wrote:

> On 5 Jun 2006 03:41:34 -0700, "Cimode" <cimode_at_hotmail.com> wrote:
>

>>I am convinced all people here are of good faith but just lack specific
>>information to allow them to communicate efficiently with other type of
>>audiences.

>
>
> I think there are some real disagreements, too.
>
>
>>>Odd that this thread doesn't seem to use terms like "projection" or
>>>"composition" (maybe I did see "decomposition").  Or, y'know,
>>>"semantics".
>>
>>semantics and terminology are necessary to bring coherence in RM
>>definition.  Lack of commitment to precise definition bothers RM
>>knowledgeable audiences.  For good reasons.  Projections or
>>compositions have not been evocated yet because there was no context
>>yet for them to be evocated.  What do you have in mind?

>
>
> When the example was representing parts of a Rubik's Cube, I thought
> the projection and composition topics were relevant.
>
> In comparisons of object vs. relational practices, the issue of
> whether a relation needs to be reified and/or explicitly labelled (say
> as an association table) always comes up. The logical relation here
> may be a semantic one, so that's the way to have commonality between
> the two models. And whatever new features are introduced that bridge
> the two sides, should IMHO often be described in semantic terms.
>
>
>>>The relational model really only uses one "relation", which is
>>>adjacency.
>>
>>I do not agree with that. RM is about defining an infinity of
>>relations.
>>
>>Perhaps this is another Cimode concept in the making.
>>
>>Could you define precisely "Adjacency".  I am not certain to what it
>>means to you.

>
>
>
>>You
>>
>>>can have as many dimensions of adjacency as you like.  You can
>>>reinterpret a dimension of adjacency as something else, like time
>>>sequence, but as soon as you do, you run across the limits of the
>>>relational model.  Now, it is also the great strength of the
>>>relational model that it is built so simply, and the question is
>>>whether that strength is comprimised when we go to extend it.
>>
>>I do not understand this argument.  Could you ellaborate?

>
>
> When you have a number of fields in a row, what do you know about
> them? Only that they all depend on the PK. The column name may
> provide an additional hint of just what the relationship is (eg
> "father", "licence_number", "isActive", but the nature of the
> relationship is invisible to the RM. Domains and constraints are
> additional hints, but no more. All we know is that in a cannonical
> representation of whatever the application area is, we want to store
> this column with that PK.
>
> So, what is the alternative to an "adjacency-only" RM?

I once again object to the silly idea that the RM depends on location.

   Something
> extensible and messy, where you explicitly type relations of fields to
> keys, the types coming out of an ontology, comprising entirely new
> domains of metadata about the primary model.
>
> If we're not getting into stuff like that, maybe we're not on the
> right road in new database technologies.

No matter how complex one makes things, one will always have an eternal predicate. (See Goedel.)

Creating more complex structures does not affect the observation that computers do not think; they compute. A computer will happily perform symbolic manipulations of more complex structures. However, humans will not understand those structures as clearly, and the greater the complexity the more likely the humans writing the programs will fail. Received on Mon Jun 05 2006 - 18:59:46 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US