Re: Possible bridges between OO programming proponents and relational model

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.
Maybe but that's not important. What matters most is th subject at hand.

> >> 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.
Yes they are nut operations are relvar seem a little bit complicated to be aborded straight away. I do believe that defining an economical loading process for IO/Disk values extracted from domains is a primary issue that needs to be solved first. insuch perspective there's a need to define an adressing scheme that is more coherent with domain definitions than direct image implentation. After all, relations are multidimensional variables drawing values from specific domains.

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

RM and OO are difficult to compare as the are of different nature. RM is a logical model
based on set theory that regulates logically operations. OTOH, OO is a set of computing mechanisms that have certain reccuring characteristics that are mainly useful at implementation level. Question is what can these mechanisms can allow more economical representation and operations of relvar.

> >> 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.
I am not sure what you mean by invisible? Could you ellaborate on that?
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.
Domains are much more than hints as they are a fundamental issue of RM as it is what allows the definition of data types on attributes. Therefore relations are domain bound. Don't tell that to relational advocates? They may burn you in public place. Constraints are also a fundamental issue in RM as it is what allows to declare a sub ensemble of possible values extracted from a domain. There is no way to get around these two into implementing RM.

> So, what is the alternative to an "adjacency-only" RM?
RM defines tuple at logical. Based on predicates logic, RM allows to make assertions such as
EMP# is named NAME# and earns SALARY# $...It dictates that all tuples responding to that predicate must be a boolean value of TRUE for all occurences of a tuple. NAME# and SALARY# are values extracted from a sub ensemble of a specific domain of values. RM dictates precise rules to define all relationship between these values which allows to relate them in the sense you asked.

> 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.
I dont' exactly understand such pessimism. could you ellaborate?
> J.
Received on Mon Jun 05 2006 - 20:12:41 CEST