Re: Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)

Tony D wrote:
> <health warning>
> OK, this thread has been sitting here for a few days with not much
> action, and gently intriguing me. Nobody else who really knows about
> this stuff, so at risk of betraying cluelesseness about some of this
> stuff, I'd like to kick some discussion off. I may misinterpret some
> terms, so if I do and go off on a tangent be gentle. Ok ?
> </health warning>
>
> Cimode wrote:
> > As far as I could observe, relational variables are repetitively
> > confused with their projections as tables. On the last few years, I
> > have focused some efforts into searching mathematical tools to help
> > characterize more precisely relvars.
> >
> > On such perspective, I have found ensemblist mathematics useful.
> >
>
> I'm assuming at this point that "ensemblist" = "set theoretic" ? (One
> of the references to Bourbaki I found on teh intairweb made that
> equation; if it's wrong I'm even more off beam than I thought.)
No. Mathematics of ensembles (known as Ensemblist mathematics) is a totally independent area from set theory (they of course exist relationship between the two). While set theory main focus is operation definitions between sets of values, ensemble mathematics main focus is characterization and definition of ensembles of values at higher level of abstraction. For simplification purposes, I guess one could consider ensemblist math as a macro view and set theory as a micro view of the same problem.
As stated, my belief is that set theory might not be *sufficient* to characterize nature of relvars and that much work still needs to be done using math to clarify issues that are unclear in Codd's and Date's work.

> > Once defined according to predicate theory requirements and RM, relvar
> > have the characteristics of constituing themselves new domain of
> > arbitrarily complex values. For instance, relvar R1{A1, A2} draws and
> > restricts values from domains Da1 and Da2 (for attributes A1 and A2).
> > As soon as defined, all occurrences of relvar R1 populate a domain of
> > value DoR1. (Such domain may be utilized for instance to define a new
> > data type DaR1).
> >
> > The question that arose from that observation is whether the domain
> > DoR1 is equivalent to the ensemble consitued by the some adjonction of
> > all attribute domains D1, D2. So far, assuming they are different
> > indeed has some advantage: it allows differentiation of domains which
> > simplifies deduction about relvar characterization. As a consequence,
> > I expressed the relvar R1 as equal to the intersection between the
> > domain of value it would constitute, and the ensemble consituted by the
> > attributes domains.
> >
>
> So I suppose the question is, do the constraints on R1 that would
> prevent it accepting any value drawn from the product type of D1, D2,
> ... Dn apply to the relvar R1, or to the domain DoR1 ?
No. The question is not really about how are defined the constraints or according to *what* they are applied. The question is about the relvar characterization knowing how they have been already defined in Codd's and Date's work thanks to the use of other mathematical tools.

> At this point, I would tend towards the constraints applying to the
> relvar, rather than to the domain itself, on the general view that
> values can't be constrained, but variables can. For example, you can't
> apply a constraint to the value 2, but you could apply a constraint to
> an integer variable so that it can only indicate even numbers.
I am sorry but that is really off topic. The question is not about constraints but about the relvar itself.

> > In Zermelo-Fraenkel approach, this would be expressed as
> >
> > Assuming DoR1 there is an ensemble of values constituted by R1 occuring
> > values, there exists an ensemble of parties B(DoR1) that represents
> > their attributes as element of the DoR1 group.
> >
> > Considering B(DoR1) as an ensemble of values different from DoR1, R1
> > could be defined by the intersect of the 2 ensembles.
> >
> > Stated in math language...
> >
> > R1 = DoR1 INTERSECT B(DoR1)
> >
> > One observation that arises from this axiom is the dissimetrical nature
> > of relvar definition due to restriction of drawing value by data type
> > definition. One advantage would be formal expression of the difference
> > between domain and data type.
> >
>
> As we've discussed before, this is a difference I don't readily accept;
> I'm willing to accept a convincing argument as to why I should accept
> it though. This would be the logical consequence of separating "domain"
> and "data type" though.
Accepting the difference between domain and data type is not really relevant to this topic because such difference is not the main focus of trying to launch discussion about the nature of relvars.

> > A consequence is that the ensemble of parties made by all attributes
> > are constituted as a product of belonging and restrictions.
> >
> > For all R1{A1, A2, A3} relvars drawn from domain DoR1, there exists an
> > ensemble of parties that allows dissymetrical decomposition and
> > characterization of relvars.
> >
>
> I'm not sure I'm quite clear on what is meant by "ensemble of parties",
> so I won't comment on this section (I can take a guess, but it would be
> a guess and might lead to a horrible misunderstanding).
*Ensemble of parties* is a the abstract ensemble that is defined as a ensemble to which necessarily belong N sub ensembles. It has been proven mathematically that such ensemble ALWAYS exists when some sub ensemble of values exist. Such ensemble is also called Ensemble of parties (noted B(DoR1) --> read *Beta of DoR1*). As you may have guessed domains here are used as ensembles...

> > The admission of this axiom may have interesting consequences in
> > operation characterization.
> >
> > I would like to get some insight, advice and reading pointers from
> > vadim and x on that point but anybody else that has constructive
> > motivation is welcome as well.
>
> Can we have some discussion on this ? It might be quite interesting.
> (More interesting than yet more blether about object oriented stuff,
> anyway.)
That's a valid point. But be aware that we are here in unknown ground in RM (which in my perspective should be the purpose of comp.database.theory). Keep also in mind, that it may be interesting to get some better understanding of ensemblist math theory before getting any further. Received on Sat Jul 15 2006 - 11:02:49 CEST