Can relvars be dissymetrically decomposed? (vadim and x insight demanded on that subject)
Cimode
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.
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.
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.
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.
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.
Jonathan Leffler
terms meant.
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.
Can you provide some pointers to 'ensemblist mathematics'? Google
didn't seem to help.
> 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).
'value DoR1'? Or of 'type DoR1' or 'domain DoR1'?
> The question that arose from that observation is whether the domain
> DoR1 is equivalent to the ensemble consitued by the some adjonction of
constituted? And 'adjunction'? (Are these typos, or some new words?)
> 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.
>
> In Zermelo-Fraenkel approach, this would be expressed as
Googling 'Zermelo-Fraenkel' picks up reasonably comprehensible
definitions at Wikipedia and Wolfram Mathworld.
> 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.
>
> 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.
Google couldn't help on a definition of dissymetric, though it turned up
a number of references to the word.
Can you help me understand whether it is a variant of 'asymmetric',
'non-symmetric', 'anti-symmetric', 'unsymmetric' or some other word, or
whether it has some specialized meaning and what that meaning is?
> 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.
>
--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
Cimode
Jonathan Leffler wrote:
> I suspect this might be quite an interesting if only I knew what all the
> terms meant.
>
> 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.
>
> Can you provide some pointers to 'ensemblist mathematics'? Google
> didn't seem to help.
if they did get published inUS...Here are a few pointers you may look
for "Bourbaki association"
+ a few names...
Henri Cartan, Claude Chevalley, Jean Coulomb, Jean Delsarte, Jean
Dieudonné, Charles Ehresmann, René de Possel,
> > 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).
>
> 'value DoR1'? Or of 'type DoR1' or 'domain DoR1'?
Sorry, this sentence is indeed ambiguous. The sentence should read
//....all occurrences of relvar R1 populate a domain of values that
constitute domain DoR1...///
meaning all occurences of the relvar R1 are the elementary elements of
DoR1
> > The question that arose from that observation is whether the domain
> > DoR1 is equivalent to the ensemble consitued by the some adjonction of
>
> constituted? And 'adjunction'? (Are these typos, or some new words?)
I guess *made of * could be a synonym.
> > 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.
> >
> > In Zermelo-Fraenkel approach, this would be expressed as
>
> Googling 'Zermelo-Fraenkel' picks up reasonably comprehensible
> definitions at Wikipedia and Wolfram Mathworld.
Yep. Check also names above.
> > 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.
> >
> > 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.
>
> Google couldn't help on a definition of dissymetric, though it turned up
> a number of references to the word.
replace *dissymetric* by *non symetric*. Sorry my English speaking
math is limited.
Tony D
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.)
> 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 ?
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.
> 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.
> 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).
> 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.)
paul c
> <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>
as one who often takes things too far, eg., farther than i think Codd
intended, i would defend that approach even if it means prying open
doors that he didn't completely close, like this one, making domains out
of relations and my pet, rva's which if i try to understand Codd's
information principle in a strict way might reasonably be said to be
verboten even though there are at least a couple of big names such as
Darwen and Date who state that certain rva's are valid in rt. the
reason i think doing this is valid is that from a theory point of view i
think some effort deserves to be made when describing a theory to
determine its boundaries, eg., where does rt theory end and domain or
type theory begin, not to mention whether 'percolation' is possible if a
domain-defining relvar changes, but what's been written so far doesn't
have enough meat for me, like examples, plus it uses words like
ensemblist that are way over my head and sound like they admit
potentially a lot of fuzziness. i think Cimode could try to qualify or
characterize what he has said or give some examples that the rest of us
could take pot shots at.
p
Cimode
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.)
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.
Cimode
understanding of RM through use of different math tool. Ensemblist
math certainly is not a fuzzy concept it is pure math. The axiom of
ensemble of parties has not been proven wrong yet and is considered by
math community as sound as 1+1=2. As for examples, I do not see
exactly what kind of examples you expect? I was under the clear
impression the example provided was more than sufficient to understand
the problem. thanks for clarifying your request so I may adjust to
your level of abstraction.
> p
Tony D
Cimode wrote:
> 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.
Unfortunately every Google on "théorie des ensembles" returned
definitions of set theory. I Amazon'd for the Bourbaki book, and the
English translation is "Elements of Mathematics I : The Theory of
Sets". However, from the table of contents I think I know what you're
getting at. Just to check; are "ensembles of parties" the "families of
sets" described in sections 3 & 4 of chapter II ? That would give me
something to go searching on.
> 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.
>
As an aside, what are the issues you consider unclear in the work of
Codd & Date ? (Not argumentative; I'd like to know what areas are
problematic to you.)
> 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.
>
What do you mean by "relvar characterization" here ?
> I am sorry but that is really off topic. The question is not about
> constraints but about the relvar itself.
>
It's sneakily relevant in a way; if the domains are different, then the
sets of values are different; if the domains are the same, then the
sets of values are the same, but the restrictions occur elsewhere.
> 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.
>
> *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...
>
That's why the difference drawn between data type and domain is
important; as I mentioned above, it potentially changes the sets of
values available.
> 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.
We're in unknown territory for me anyway, that's for sure. However, the
terrain is quite interesting ...
Cimode
Tony D wrote:
> Cimode wrote:
> > 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.
>
> Unfortunately every Google on "théorie des ensembles" returned
> definitions of set theory. I Amazon'd for the Bourbaki book, and the
> English translation is "Elements of Mathematics I : The Theory of
> Sets". However, from the table of contents I think I know what you're
> getting at. Just to check; are "ensembles of parties" the "families of
> sets" described in sections 3 & 4 of chapter II ? That would give me
> something to go searching on.
ensembles* was published in US under the pseudonym of Nicolas BOURBAKI
and the name you provided ...(In fact there are several mathematicians
constituing the BOURBAKI association)...
Here is the book I have found on Amazon.
http://www.amazon.fr/exec/obidos/ASIN/3540225250/403-4729874-1286004
>From additional research, I discovered also that the axiom of the
*ensemble of parties* (French litteral translation) would be known as
*Axiom of power set*. I recommend that reading for continuing this
discussion in a useful manner.
> > 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.
> >
>
> As an aside, what are the issues you consider unclear in the work of
> Codd & Date ? (Not argumentative; I'd like to know what areas are
> problematic to you.)
In general, relvars themselves, as opposed to their projections . For
instance, relvar are multidimensional variables that have not been to
my knowledge defined one according to the others in simple terms. For
instance, no operators have been defined for handling relvars...such as
R1 = r1 op r2 op r3 (r1, r2 and r3 being attributes and R1 being the
global relvar) --> what operator is defined at relvar level as opposed
to operators defined on their projection as R tables. This is what I
came to the conclusion that relvars have no been characterized
sufficiently.
> > 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.
> >
>
> What do you mean by "relvar characterization" here ?
I mean specifying the characteristics of relvars as opposed to their
projections.
> > I am sorry but that is really off topic. The question is not about
> > constraints but about the relvar itself.
> >
>
> It's sneakily relevant in a way; if the domains are different, then the
> sets of values are different; if the domains are the same, then the
> sets of values are the same, but the restrictions occur elsewhere.
How are restrictions defined mathematically on relvars themselves?
The formula proposed reveals some assymetrical nature which would be a
consequence of restrictions applied on extractions from domains.
> > 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.
> >
>
> > *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...
> >
>
> That's why the difference drawn between data type and domain is
> important; as I mentioned above, it potentially changes the sets of
> values available.
Yes. I won't argue with something obvious that has been defined and
redefined over and over. But consider the problem on a different
perspective: what if the difference between data type and domain is not
the main focus. What about the relvar itself? What are the
characteristics of a relvar R1 (operators) in relationship to the
elementary relvars that constitute it? How one can *evaluate*
operators that apply on a specific relvar based on the operators that
apply on the attributes that constitute the relvar?
> > 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.
>
> We're in unknown territory for me anyway, that's for sure. However, the
> terrain is quite interesting ...
In that case, I reitterate my encouragement to do some reading first.
Aloha Kakuikanu
> In general, relvars themselves, as opposed to their projections .
By "projection" you don't mean RA projection, or do you?
BTW, Bourbakism is the worst thing that happened to math in 20th
century.
Cimode
Aloha Kakuikanu wrote:
> Cimode wrote:
> > In general, relvars themselves, as opposed to their projections .
>
> By "projection" you don't mean RA projection, or do you?
I mean relvars projections from multidimensional representation to
bidimensional representation as Rtables.
> BTW, Bourbakism is the worst thing that happened to math in 20th
> century.
That's an opinion I respect but I do not quite agree with because it is
simplyistic.
Because of its associative structure, early century Bourbakism math
showed some fuzziness but it has been reaching maturity in the sixties
with very rigorous formalism. Do not forget that we owe to Bourbakism
very important axioms and symbolic (*Whatever x*, *belong to* math
operator). But Bourbakism is not the issue here...I am interested in
your insight about the topic brought up which is relvar
characterization.
Feel free to refer to other mathematics tools to help deal with the
question of relvar nature.
Aloha Kakuikanu
Cimode wrote:
> Aloha Kakuikanu wrote:
> > Cimode wrote:
> > > In general, relvars themselves, as opposed to their projections .
> >
> > By "projection" you don't mean RA projection, or do you?
> What does RA stand for?
RA is relational algebra.
> I mean relvars projections from multidimensional representation to
> bidimensional representation as Rtables.
There is nothing 2-dimensional about relations. A relation normally is
considered to be a set of n-dimensional vectors. A recent post
http://groups.google.com/group/comp.databases.theory/msg/f7bdd36e39086909?hl=en&
claims that relations are 0-dimensional varieties.
Cimode
Aloha Kakuikanu wrote:
> Cimode wrote:
> > Aloha Kakuikanu wrote:
> > > Cimode wrote:
> > > > In general, relvars themselves, as opposed to their projections .
> > >
> > > By "projection" you don't mean RA projection, or do you?
> > What does RA stand for?
>
> RA is relational algebra.
coordinate system (ex: vectorial N coordinate system, or
multimensionally defined functions) to bidimensional coordinate system
(ex: Rtable, plane)
> > I mean relvars projections from multidimensional representation to
> > bidimensional representation as Rtables.
>
> There is nothing 2-dimensional about relations. A relation normally is
> considered to be a set of n-dimensional vectors. A recent post
> http://groups.google.com/group/comp.databases.theory/msg/f7bdd36e39086909?hl=en&
> claims that relations are 0-dimensional varieties.
I suspect a harmless communication problem here. Relations are N
dimensional, there is no doubt about that. I refered to projections of
relations in a specific point in time. The topic here is not about the
dimensionality of relations: look at the example provided and feel free
to bring insight about the topic ;) I am trying to avoid dispersion on
a very complex topic.
Aloha Kakuikanu
Cimode wrote:
> Relations are N
> dimensional, there is no doubt about that. I refered to projections of
> relations in a specific point in time.
Time is out of scope of the relational theory.
> The topic here is not about the
> dimensionality of relations: look at the example provided and feel free
> to bring insight about the topic ;)
Where is the example?
Cimode
Aloha Kakuikanu wrote:
> Cimode wrote:
> > Relations are N
> > dimensional, there is no doubt about that. I refered to projections of
> > relations in a specific point in time.
>
> Time is out of scope of the relational theory.
sense that relations have not been defined according to time. As I
said, much work needs to be done in such direction.
> > The topic here is not about the
> > dimensionality of relations: look at the example provided and feel free
> > to bring insight about the topic ;)
>
> Where is the example?
Stated previously...
Consider R1 relvar defining domain DoR1 of values. Each occurence of
DoR1 is a member of DoR1.
Consider R1{A1, A2, A3} where D1, D2, D3 are the domains from which A1,
A2 and A3 respectively draw and restrict values (through data type
definitions). The question is onto *how* R1 can be expressed according
to D1, D2, D3 and DoR1....using a simple equation such as the one
proposed:
R1 = DoR1 INTERSECT B(DoR1) with B(DoR1) being the ensemble to which
belongs ALL D1, D2, and D3.
erk
> [snipped]
> I suspect a harmless communication problem here. Relations are N
> dimensional, there is no doubt about that. I refered to projections of
> relations in a specific point in time.
I think there are established terms for what you mean; in Date's
writings he frequently distinguishes between relvars and relvals
(although he uses the latter less frequently). The term "projection" is
a different concept, and time has nothing to do with it.
A relvar can have different values at different points in time - like
any variable. The values are relvals (of course). Every
UPDATE/INSERT/DELETE is, I believe, syntactic sugar for an assignment
like R = R op X op Y op ..., where R is being assigned the result of
applying operations to itself, with other relVALs as parameters (e.g.
an insert is a union of R with a single-tuple relval).
Sorry if I'm repeating the obvious; I think the terminology is getting
in the way. And I'm still not sure what your goal is in
"characterizing" relvars, as distinct from relvals. A relvar is simply
a variable that can "hold" values of the same type. Several relvars can
be created with identical definitions (obviously their predicates
(real-world semantics) are different, but in all other ways they can be
identical), so relvars do have types, and a relvar with constraints has
at least 2 types: one including the constraints, and the supertype
without the constraints.
- Eric
Cimode
erk wrote:
> Cimode wrote:
> > [snipped]
> > I suspect a harmless communication problem here. Relations are N
> > dimensional, there is no doubt about that. I refered to projections of
> > relations in a specific point in time.
>
> I think there are established terms for what you mean; in Date's
> writings he frequently distinguishes between relvars and relvals
> (although he uses the latter less frequently). The term "projection" is
> a different concept, and time has nothing to do with it.
*representation* as an RTable. I consider this representation as
varying over time and operations made on and with the relation.
> A relvar can have different values at different points in time - like
> any variable. The values are relvals (of course).
What you said is logically correct but I would not say it that way. A
relvar holds different values over time because the relations expressed
by relvars have a *behavior* that changes over time (Caution: behavior
has nothing to do with OO fuzzy concepts, it is meant in a mathematical
function describing sense). For instance, some relvar may be used to
express several relations the same way the variable *x* may express
several functions. And of course, x may *hold* different values
(relvalues in RM) over time.
> Every
> UPDATE/INSERT/DELETE is, I believe, syntactic sugar for an assignment
> like R = R op X op Y op ..., where R is being assigned the result of
> applying operations to itself, with other relVALs as parameters (e.g.
> an insert is a union of R with a single-tuple relval).
I see you point and I thank you for this example which will help
clarify the issue. It is correct to assume that an INSERT (operation)
is the union of a relation R1 and single-tuple relval BUT that says
something only about the INSERT operation not about the R1. The
question I am trying to raise is HOW does the insert operation impact
R1. For instance, if you consider the function F(X) = A(X) and you add
the value B to F(X), you are basically doing a translation making a new
function T(X) = F(X) + B = A(X) + B In this case, the result of adding
B to the function can be expressed (characterized) as a mathematical
translation (jumping from F(X) to T(X)). It says a lot about the
function F(X) behavior and may help describe it better over time. The
challenge of this thread is to do a similar effort on relations. For
instance, an interesting question raised would be: is an INSERT
operation equivalent to a translation in relational perspective?
Overall, how does a relation R1 *changes* when an INSERT, UPDATE,
DELETE operation is made on it? Characterizing such change would help
describe better relations themselves.
> Sorry if I'm repeating the obvious; I think the terminology is getting
> in the way. And I'm still not sure what your goal is in
> "characterizing" relvars, as distinct from relvals.
Basically, to work at relation abstract mathematical level as opposed
to operational level in RM.
For instance, if one considers the function F(x) = A(x) + B.... such
function is expressed as an equality using 1 relvar (in this case *x*),
2 operators (in this case *X* and *+*) and 2 values (a and b). By
characterizing relation R1, I mean how would it be possible to
express in a similar fashion some relation R1 (NOT a the relvar but the
relation itself) using as relvalues domains and some operator.
> A relvar is simply
> a variable that can "hold" values of the same type. Several relvars can
> be created with identical definitions (obviously their predicates
> (real-world semantics) are different, but in all other ways they can be
> identical), so relvars do have types, and a relvar with constraints has
> at least 2 types: one including the constraints, and the supertype
> without the constraints.
No agument here. A matter of perspective (a different angle on the
same problem). See above.
> - Eric
erk
> erk wrote:
> I see your point. I use the term *projection* in as *encoding* or
> *representation* as an RTable. I consider this representation as
> varying over time and operations made on and with the relation.
I still wouldn't call that an encoding or representation. An encoding
would be, perhaps, the on-disk string of bytes which holds the contents
of the relvar. A relvar really has only one operation: assignment
(assigning a new value to the relational variable). There are, of
course, many relational expressions, but any that use relvars are
really using the current values (relvals) of the relvars; thus only
assignment "does anything" to the relvar.
Of course, other people should chime in, as my terminology might be
idiosynchratic.
> > A relvar can have different values at different points in time - like
> > any variable. The values are relvals (of course).
> What you said is logically correct but I would not say it that way. A
> relvar holds different values over time because the relations expressed
> by relvars have a *behavior* that changes over time (Caution: behavior
> has nothing to do with OO fuzzy concepts, it is meant in a mathematical
> function describing sense). For instance, some relvar may be used to
> express several relations the same way the variable *x* may express
> several functions. And of course, x may *hold* different values
> (relvalues in RM) over time.
I don't agree at all here, at least not to the extent that I understand
you. If a variable x can "express several functions" over time, then I
assume x has several assignment statements which change it. This
implies that the type of variable x is a supertype of all the assigned
functions, or the assignment would make no sense. This isn't the case
with relations; if I create a relvar, and consider its type T (e.g. {A,
B C} as attributes), I can't assign arbitrary relvals to it unless they
are also of type T.
> [snip]
> For instance, if you consider the function F(X) = A(X) and you add
> the value B to F(X), you are basically doing a translation making a new
> function T(X) = F(X) + B = A(X) + B In this case, the result of adding
> B to the function can be expressed (characterized) as a mathematical
> translation (jumping from F(X) to T(X)). It says a lot about the
> function F(X) behavior and may help describe it better over time.
But F isn't changing. You're creating a new function, not changing an
existing one. Assuming the expression F(X)+B makes sense, T has the
same type as F, but it's not the same function, as its post-conditions
are different.
> The
> challenge of this thread is to do a similar effort on relations. For
> instance, an interesting question raised would be: is an INSERT
> operation equivalent to a translation in relational perspective?
> Overall, how does a relation R1 *changes* when an INSERT, UPDATE,
> DELETE operation is made on it? Characterizing such change would help
> describe better relations themselves.
The data changes, as "facts" are changed (each tuple is a fact). I
don't see how this changes behavior, or anything other than the results
of logical deductions (e.g. queries) made using that relation.
> [snip]
> For instance, if one considers the function F(x) = A(x) + B.... such
> function is expressed as an equality using 1 relvar (in this case *x*),
> 2 operators (in this case *X* and *+*) and 2 values (a and b). By
> characterizing relation R1, I mean how would it be possible to
> express in a similar fashion some relation R1 (NOT a the relvar but the
> relation itself) using as relvalues domains and some operator.
> [snip]
Sorry, not getting this at all. What operator is *X*? If x is a
relation, then isn't A(x) a relational expression, and thus B and F(x)
too, rather than values?
- erk
Aloha Kakuikanu
> Consider R1 relvar defining domain DoR1 of values. Each occurence of
> DoR1 is a member of DoR1.
> Consider R1{A1, A2, A3} where D1, D2, D3 are the domains from which A1,
> A2 and A3 respectively draw and restrict values (through data type
> definitions). The question is onto *how* R1 can be expressed according
> to D1, D2, D3 and DoR1....using a simple equation such as the one
> proposed:
>
> R1 = DoR1 INTERSECT B(DoR1) with B(DoR1) being the ensemble to which
> belongs ALL D1, D2, and D3.
Could you lower abstraction level a little bit? (This would kill two
things at once: your text would be comprehensible for abstraction
challenged readers, and you'll be able to spot your own mistakes better
in it).
Cimode
erk wrote:
> Cimode wrote:
> > erk wrote:
> > I see your point. I use the term *projection* in as *encoding* or
> > *representation* as an RTable. I consider this representation as
> > varying over time and operations made on and with the relation.
>
> I still wouldn't call that an encoding or representation. An encoding
> would be, perhaps, the on-disk string of bytes which holds the contents
> of the relvar. A relvar really has only one operation: assignment
> (assigning a new value to the relational variable). There are, of
> course, many relational expressions, but any that use relvars are
> really using the current values (relvals) of the relvars; thus only
> assignment "does anything" to the relvar.
>
> Of course, other people should chime in, as my terminology might be
> idiosynchratic.
> > > A relvar can have different values at different points in time - like
> > > any variable. The values are relvals (of course).
> > What you said is logically correct but I would not say it that way. A
> > relvar holds different values over time because the relations expressed
> > by relvars have a *behavior* that changes over time (Caution: behavior
> > has nothing to do with OO fuzzy concepts, it is meant in a mathematical
> > function describing sense). For instance, some relvar may be used to
> > express several relations the same way the variable *x* may express
> > several functions. And of course, x may *hold* different values
> > (relvalues in RM) over time.
>
> I don't agree at all here, at least not to the extent that I understand
> you. If a variable x can "express several functions" over time, then I
> assume x has several assignment statements which change it.
I realize now after reading that my sentence was confusing because I
packed up too many ideas at once. I admit and I apologize for it.
Let's make it short...
First statement, A relvar holds different content (relvalue) over time
BECAUSE the relation it describes has a time bound behavior. That the
first statement.
Second, a variable may help express functions in general (not over
time). For instance, the variable *x* may express function F(X) = A(x)
+ B as it may express function Y(x) = D(x) + G
The confusion came from the fact I used *For instance* which
established a relationship between the two concepts.
> This
> implies that the type of variable x is a supertype of all the assigned
> functions, or the assignment would make no sense. This isn't the case
> with relations; if I create a relvar, and consider its type T (e.g. {A,
> B C} as attributes), I can't assign arbitrary relvals to it unless they
> are also of type T.
>
> > [snip]
> > For instance, if you consider the function F(X) = A(X) and you add
> > the value B to F(X), you are basically doing a translation making a new
> > function T(X) = F(X) + B = A(X) + B In this case, the result of adding
> > B to the function can be expressed (characterized) as a mathematical
> > translation (jumping from F(X) to T(X)). It says a lot about the
> > function F(X) behavior and may help describe it better over time.
>
> But F isn't changing. You're creating a new function, not changing an
> existing one. Assuming the expression F(X)+B makes sense, T has the
Now that's finally getting interesting... If I follow your reasoning
that would mean that once an INSERT is done, there would be necessarily
a new relation resulting from the INSERT operation performed?
> same type as F, but it's not the same function, as its post-conditions
> are different.
What are *post conditions*?
> > The
> > challenge of this thread is to do a similar effort on relations. For
> > instance, an interesting question raised would be: is an INSERT
> > operation equivalent to a translation in relational perspective?
I rephrase then : is an INSERT operation equivalent to a translation in
relational perspective resulting in a new relation?
> > Overall, how does a relation R1 *changes* when an INSERT, UPDATE,
> > DELETE operation is made on it? Characterizing such change would help
> > describe better relations themselves.
Are operations in general performed on relations create new relations.?
> The data changes, as "facts" are changed (each tuple is a fact). I
> don't see how this changes behavior, or anything other than the results
> of logical deductions (e.g. queries) made using that relation.
>
> > [snip]
> > For instance, if one considers the function F(x) = A(x) + B.... such
> > function is expressed as an equality using 1 relvar (in this case *x*),
> > 2 operators (in this case *X* and *+*) and 2 values (a and b). By
> > characterizing relation R1, I mean how would it be possible to
> > express in a similar fashion some relation R1 (NOT a the relvar but the
> > relation itself) using as relvalues domains and some operator.
> > [snip]
>
> Sorry, not getting this at all. What operator is *X*? If x is a
> relation, then isn't A(x) a relational expression, and thus B and F(x)
> too, rather than values?
I used *X* as the multiply operator in the expression A * (x) + B to
be able to put between quotes.
> - erk
Cimode
erk
> [snip]
> > > [snip]
> > > For instance, if you consider the function F(X) = A(X) and you add
> > > the value B to F(X), you are basically doing a translation making a new
> > > function T(X) = F(X) + B = A(X) + B In this case, the result of adding
> > > B to the function can be expressed (characterized) as a mathematical
> > > translation (jumping from F(X) to T(X)). It says a lot about the
> > > function F(X) behavior and may help describe it better over time.
> >
> > But F isn't changing. You're creating a new function, not changing an
> > existing one. Assuming the expression F(X)+B makes sense, T has the
> Now that's finally getting interesting... If I follow your reasoning
> that would mean that once an INSERT is done, there would be necessarily
> a new relation resulting from the INSERT operation performed?
Well, the INSERT does an assignment after evaluating a relational
expression - so doing an INSERT to a relvar R is the same as assigning
to R the result of a relational expression involving R's current value.
So the "new relation" you speak of is a new relation value, which is
(as the very last step) assigned to variable R.
Note that constraints complicate this - the assignment to R can fail
because of database constraint violations. The evaluation of the
expression can (unless decent type-checking is used) fail if it's not a
valid value of type TYPE(R).
> > > The
> > > challenge of this thread is to do a similar effort on relations. For
> > > instance, an interesting question raised would be: is an INSERT
> > > operation equivalent to a translation in relational perspective?
> I rephrase then : is an INSERT operation equivalent to a translation in
> relational perspective resulting in a new relation?
Any relational expression produces a relation value. If that's what you
mean by the "new relation," then yes. If it's an UPDATE/INSERT/DELETE,
that value is then assigned to the relvar, so the relvar has a new
value - maybe that's what you mean.
> > > Overall, how does a relation R1 *changes* when an INSERT, UPDATE,
> > > DELETE operation is made on it? Characterizing such change would help
> > > describe better relations themselves.
> Are operations in general performed on relations create new relations.?
Expressions (relational or otherwise) evaluate to values, which in the
case of relational expressions are relations. "Create new" doesn't have
much meaning in that context.
- erk
Cimode
erk wrote:
> Cimode wrote:
> > [snip]
> > > > [snip]
> > > > For instance, if you consider the function F(X) = A(X) and you add
> > > > the value B to F(X), you are basically doing a translation making a new
> > > > function T(X) = F(X) + B = A(X) + B In this case, the result of adding
> > > > B to the function can be expressed (characterized) as a mathematical
> > > > translation (jumping from F(X) to T(X)). It says a lot about the
> > > > function F(X) behavior and may help describe it better over time.
> > >
> > > But F isn't changing. You're creating a new function, not changing an
> > > existing one. Assuming the expression F(X)+B makes sense, T has the
> > Now that's finally getting interesting... If I follow your reasoning
> > that would mean that once an INSERT is done, there would be necessarily
> > a new relation resulting from the INSERT operation performed?
>
> Well, the INSERT does an assignment after evaluating a relational
> expression - so doing an INSERT to a relvar R is the same as assigning
> to R the result of a relational expression involving R's current value.
Suppose a relation R1 on which a single tuple is added. Let's consider
there 10 tuples identified as R1(1), R1(2)...R1(10) ..R1 would then be
expressed as
R1 = R1(1) UNION R1(2) UNION R1(2).......UNION R1(10)
Now let's consider a *candidate* tuple (candidate as valid for
insertion in terms of uniqueness, constraints respect, and NON NULL)
added called S (for the moment let's not assume it is already a value
of R1). The point that seems quite clear to me is that the result of
the INSERT produces a new relation..Look below
The insert would be expressed as
R1(1) UNION R1(2) UNION R1(2).......UNION R1(10) UNION S
S being NON NULL
it would be equivalent to
R1 UNION S = R2
instead of
R1 UNION S = R1
else it would be in contradiction with S being NON NULL
Furthermore, as a result of the operation S becomes R2(11) but not
R1(11) which would be coherent with the analogy of a translation
producing a new function.
> So the "new relation" you speak of is a new relation value, which is
> (as the very last step) assigned to variable R.
I am not convinced that a value added (tuple) is actually a value that
is already a part of the initial relation unless it is a NULL value
(not SQL NULL but a NULL tuple having no impact on the initial relation
R1)
A similar reasoning could be applied to DELETE operations.
> Note that constraints complicate this - the assignment to R can fail
> because of database constraint violations. The evaluation of the
> expression can (unless decent type-checking is used) fail if it's not a
> valid value of type TYPE(R).
I see your point but I am not worried about typing. Let's assume that
all candidate tuples for INSERT/DELETE are valid.
> > > > The
> > > > challenge of this thread is to do a similar effort on relations. For
> > > > instance, an interesting question raised would be: is an INSERT
> > > > operation equivalent to a translation in relational perspective?
> > I rephrase then : is an INSERT operation equivalent to a translation in
> > relational perspective resulting in a new relation?
>
> Any relational expression produces a relation value. If that's what you
> mean by the "new relation," then yes. If it's an UPDATE/INSERT/DELETE,
> that value is then assigned to the relvar, so the relvar has a new
> value - maybe that's what you mean.
Let's forget relvar and relvalue for the moment and focus on the
relation (I should have called this thread accordingly). The question
is that if one considers that the INSERT of a new tuple is the
possibility for the relvar to hold a new value does it hold it for
relation R1 or does it hold for a new relation R2. The answer seems
clear to me.
> > > > Overall, how does a relation R1 *changes* when an INSERT, UPDATE,
> > > > DELETE operation is made on it? Characterizing such change would help
> > > > describe better relations themselves.
> > Are operations in general performed on relations create new relations.?
>
> Expressions (relational or otherwise) evaluate to values, which in the
> case of relational expressions are relations. "Create new" doesn't have
> much meaning in that context.
At abstract level of reasoning, I am not convinced that relations can
*only* be characterized by their values or operations. I do not feel
confortable with *create new* concept because it is not really and idea
of creating a new instance but a whole new relation.
Suppose for instance R1 constitute a domain on which values can be
drawn. It necessarily has a limited number of values. Don't you think
adding a new value changes fundamentally the nature of the R1 defined
domain and therefore is possible if and only if a new domain and a new
relation R2 are created?
> - erk
Tony D
from the initial question of non-symmetrical decomposition onto a
question on the nature of variables.
Let's go :
Cimode wrote :
> I see your point. Lets try to formulate this differently...
> Suppose a relation R1 on which a single tuple is added. Let's consider
> there 10 tuples identified as R1(1), R1(2)...R1(10) ..R1 would then be
> expressed as
>
> R1 = R1(1) UNION R1(2) UNION R1(2).......UNION R1(10)
>
Ok, accepting the notation, we're fine so far.
> Now let's consider a *candidate* tuple (candidate as valid for
> insertion in terms of uniqueness, constraints respect, and NON NULL)
> added called S (for the moment let's not assume it is already a value
> of R1). The point that seems quite clear to me is that the result of
> the INSERT produces a new relation..
Yes.
>Look below
>
> The insert would be expressed as
> R1(1) UNION R1(2) UNION R1(2).......UNION R1(10) UNION S
> S being NON NULL
> it would be equivalent to
> R1 UNION S = R2
Yes-ish; but what is R2 ? Is it a new relation value, or a relation
variable ? I think you mean it's a new relation value, so your
statement is correct; but ...
> instead of
> R1 UNION S = R1
> else it would be in contradiction with S being NON NULL
>
Well, it depends on what is meant by R1. Does R1 now mean a relvar or a
relation value ?
Aside : I should say before I start that Tutorial D (which is the main
source, I suspect, for many of us of the term "relvar") is an
imperative language, so in that context a relvar is just another,
ordinary, 3GL, name-for-a-piece-of-memory variable. It isn't a
mathematical, logical,
referentially-transparent-placeholder-shorthand-for-an-expression
variable. With that said, here comes a rant/ramble :
One of the many things to hate about imperative, stateful languages is
the constant and gleeful elision of dereferencing. Let's look at a
simple example before moving on to relations and relvars per se.
Consider the following fragment, quite acceptable to a C or FORTRAN
compiler :
X = X + 1
This is, on the face of it, utter madness. X is X; how can it possibly
be "X + 1" ? Let's take out one source of complaint; the '=' operator.
Quite obviously, we are not asserting an equality, so let's use a
different operator - Pascal's ':=', say. So we get
X := X + 1
to be read aloud as "x becomes x plus 1". But this also has a problem;
since when was '+' defined on variables ? It takes two numbers, surely.
Have we suddenly invented a new '+' ? Of course we haven't; what has
happened is we've elided out a dereference on X. What this really means
is
X := the_current_value_of(X) + 1
with the obvious read alound meaning of "take the current value of X,
add one to it, throw the old value away and assign the new value to X,
assuming that the new value is acceptable according to the constraints
currently on X (for example, the assignment fails if X is a subrange
type [1..10] and X was already 10, or X is defined to accept only odd
or only even numbers)".
Now that we've sussed what a fairly obvious imperative statement
actually means, it should be obvious that if
INSERT X RELATION { TUPLE { A1 INTEGER(1) , A2
INTEGER(2) } }
is a synonym for
X := X UNION RELATION { TUPLE { A1 INTEGER(1), A2
INTEGER(2) } }
it should also be obvious that what we mean is, "take the relation
value currently indicated by X, union it with the relation value given
to produce a new relation value, throw away the old relation value X
used to indicate and assign the new relation value to X, so long as
that new relation value is acceptable according to the current
constraints applicable to X."
Unless of course, the designers of Tutorial D fell out of a tree,
landed on their collective head and chose to make assignments on
relation variables work completely differently to assignments on any
other kind of variable in the language. But somehow I doubt that :)
Now, having come a very long way for a short cut, hopefully this makes
clear that
R1 UNION S = R1
makes sense if R1 is a relation *variable*, but it is the nonsense you
suspect if R1 is a relation *value*.
[ snippage ]
> I see your point but I am not worried about typing. Let's assume that
> all candidate tuples for INSERT/DELETE are valid.
>
That would be a pretty big assumption to take; the fundamental
constraints on a relation variable are the names and attributes of the
relation values the relation variable can indicate.
[ snippage ]
> Let's forget relvar and relvalue for the moment and focus on the
> relation (I should have called this thread accordingly). The question
> is that if one considers that the INSERT of a new tuple is the
> possibility for the relvar to hold a new value does it hold it for
> relation R1 or does it hold for a new relation R2. The answer seems
> clear to me.
>
If this means what I think it means, then there is a new relation
value, R2. (Date usually uses "relation" as a shorthand for "relation
value"; is that also what you mean ? I'm a little concerned by the
opening "let's forget relvar and relvalue for the moment and focus on
the relation" that you might be using "relation" differently. Is that
so ?)
> At abstract level of reasoning, I am not convinced that relations can
> *only* be characterized by their values or operations. I do not feel
> confortable with *create new* concept because it is not really and idea
> of creating a new instance but a whole new relation.
>
How else would you characterise relations ? What do you think or
suspect is missing ? (This is probably the most important question in
the exchanges so far, I think.)
> Suppose for instance R1 constitute a domain on which values can be
> drawn. It necessarily has a limited number of values. Don't you think
> adding a new value changes fundamentally the nature of the R1 defined
> domain and therefore is possible if and only if a new domain and a new
> relation R2 are created?
>
But R1 isn't a type - it *has* a type, but it isn't a type itself. The
*type* of R1 would constitute a new domain, as that would describe
which relation values could be considered to be of that type.
Endnote: completely (well, almost completely) by chance, my copy of
Date's Introduction (7th ed.) is open at page 133, which ends with :
"... we should now add that to talk, as we have just been doing, of
"updating a tuple" (or set of tuples) is really rather sloppy. Tuples,
like relations, are values and cannot be updated (by definition, the
one thing you cannot do to any value is change it). In order to be able
to "update tuples", we would need some notion of a tuple variable or
"tuplevar" - a notion that is not part of the relational model at all !
Thus, what we really mean when we talk of "updating tuple t to t'," for
example, is that we are replacing the tuple t (the tuple value t, that
is) by another tuple t' (which is, again, a tuple value). Analogous
remarks apply to phrases such as "updating attribute A" (in some
tuple). In this book, we will continue to talk in terms of "updating
tuples" or "updating attributes of tuples" - the practice is convenient
- ***but it must be understood that such usage is only shorthand, and
rather sloppy shorthand at that.***" (add'l emphasis mine)
Tony D
Tony D wrote:
> But R1 isn't a type - it *has* a type, but it isn't a type itself. The
> *type* of R1 would constitute a new domain, as that would describe
> which relation values could be considered to be of that type.
>
To go back to the much earlier example in the thread, R1 isn't a type,
but DoR1 would be.
Bob Badour
> Cimode wrote:
>
>>[snip]
>>
>>>>[snip]
>>>>For instance, if you consider the function F(X) = A(X) and you add
>>>>the value B to F(X), you are basically doing a translation making a new
>>>>function T(X) = F(X) + B = A(X) + B In this case, the result of adding
>>>>B to the function can be expressed (characterized) as a mathematical
>>>>translation (jumping from F(X) to T(X)). It says a lot about the
>>>>function F(X) behavior and may help describe it better over time.
>>>
>>>But F isn't changing. You're creating a new function, not changing an
>>>existing one. Assuming the expression F(X)+B makes sense, T has the
>>
>>Now that's finally getting interesting... If I follow your reasoning
>>that would mean that once an INSERT is done, there would be necessarily
>>a new relation resulting from the INSERT operation performed?
>
> Well, the INSERT does an assignment after evaluating a relational
> expression - so doing an INSERT to a relvar R is the same as assigning
> to R the result of a relational expression involving R's current value.
A simpler answer would have been 'Yes'. A relation value is a relation,
and one doesn't usually qualify the term. One qualifies a relvar as a
relation variable because a relvar is not a relation. The value the
variable identifies is a relation.
[snip]
Bob Badour
Your last statement above overlooks logical independence. A relvar is
not a piece of memory, and it can be a mathematical, logical,
referentially-transparent-placeholder-shorthand-for-an-expression
variable. What, after all, is a view if not a relvar and not a
mathematical, logical,
referentially-transparent-placeholder-shorthand-for-an-expression variable?
With that said, here comes a rant/ramble :
>
> One of the many things to hate about imperative, stateful languages is
> the constant and gleeful elision of dereferencing. Let's look at a
> simple example before moving on to relations and relvars per se.
> Consider the following fragment, quite acceptable to a C or FORTRAN
> compiler :
>
> X = X + 1
>
> This is, on the face of it, utter madness. X is X; how can it possibly
> be "X + 1" ? Let's take out one source of complaint; the '=' operator.
> Quite obviously, we are not asserting an equality, so let's use a
> different operator - Pascal's ':=', say. So we get
>
> X := X + 1
>
> to be read aloud as "x becomes x plus 1". But this also has a problem;
> since when was '+' defined on variables ?
Since algebra.
[snip]
Tony D
> Your last statement above overlooks logical independence. A relvar is
> not a piece of memory, and it can be a mathematical, logical,
> referentially-transparent-placeholder-shorthand-for-an-expression
> variable. What, after all, is a view if not a relvar and not a
> mathematical, logical,
> referentially-transparent-placeholder-shorthand-for-an-expression variable?
>
Fair point. I forgot that, in the Introduction to Database Systems at
least (I don't have TTM here), relvars are noted as coming in two
varieties.
> Since algebra.
>
Since I was in the context of a 3GL, I didn't think this objection
would come up. Silly of me. I would amend that sentence then to read
"Since when was '+' defined over memory references ?"
(Casts, BCPL and C-derived lunacy excepted. "*s++" indeed.)
Cimode
Tony D wrote:
> OK, I'm going to chime in a bit here, because I think we've strayed
> from the initial question of non-symmetrical decomposition onto a
> question on the nature of variables.
communication with erk. I wish to get back to the initial topic I
should have called "Are relations of dissymetrical nature". relvar was
not what I had in mind. I am dealing with issue of relations as
mathematical construct. For analyzing them, I wish them separated by
definition from the concept of relvar and relvalue.
> Let's go :
>
> Cimode wrote :
>
> > I see your point. Lets try to formulate this differently...
> > Suppose a relation R1 on which a single tuple is added. Let's consider
> > there 10 tuples identified as R1(1), R1(2)...R1(10) ..R1 would then be
> > expressed as
> >
> > R1 = R1(1) UNION R1(2) UNION R1(2).......UNION R1(10)
> >
>
> Ok, accepting the notation, we're fine so far.
>
> > Now let's consider a *candidate* tuple (candidate as valid for
> > insertion in terms of uniqueness, constraints respect, and NON NULL)
> > added called S (for the moment let's not assume it is already a value
> > of R1). The point that seems quite clear to me is that the result of
> > the INSERT produces a new relation..
>
> Yes.
>
> >Look below
> >
> > The insert would be expressed as
> > R1(1) UNION R1(2) UNION R1(2).......UNION R1(10) UNION S
> > S being NON NULL
> > it would be equivalent to
> > R1 UNION S = R2
>
> Yes-ish; but what is R2 ? Is it a new relation value, or a relation
> variable ? I think you mean it's a new relation value, so your
> statement is correct; but ...
R2 is a new relation, meaning a new mathematical construct product of
having some inserting new relvalues to the domain DoR1 that is defined
by R1. In that domain, ALL relvalues (tuples) that the relation may
have are elements of the domain DoR1.
> > instead of
> > R1 UNION S = R1
> > else it would be in contradiction with S being NON NULL
> >
>
> Well, it depends on what is meant by R1. Does R1 now mean a relvar or a
> relation value ?
This is a tricky question.
In an abstract sense, the concept of relation R1 can not equate to
neither relvalues or relvar. A relation may however be *evaluated* in
time to a specific relvalue. A more accurate perspective would be to
consider that a relation value as a single possible occurence of a
specific relation R1. For instance if ones assumes that relation R1
has a single tuple then single tuple R1(1) is a relvalue of the
relation R1. By analogy,consider a function F(x) = 2*x + 2
Such function F may have a value 6 in time when x = 2 but that does not
mean the function = 6 (relvalue) or the function = x (relvar) because
F(x) = 6 is not function F and F(x) = x is not function F either: F(x)
is still defined as (2*x + 2)
> Aside : I should say before I start that Tutorial D (which is the main
> source, I suspect, for many of us of the term "relvar") is an
> imperative language, so in that context a relvar is just another,
> ordinary, 3GL, name-for-a-piece-of-memory variable. It isn't a
> mathematical, logical,
> referentially-transparent-placeholder-shorthand-for-an-expression
> variable. With that said, here comes a rant/ramble :
Maybe the term *relvar* is just a name for variable and such concept
exists since mathematical relations have been identified. I rather use
the mathematical definition of it than a possible implementation of it.
Thank you for this remarks. But I suggest not relying on
implementation layer for abstract thinking. Tutorial D or other
implementations has pre established semantics and I do not feel
confortable using it as proof for mathematical and deductive
reasonning.
> Now, having come a very long way for a short cut, hopefully this makes
> clear that
>
> R1 UNION S = R1
>
> makes sense if R1 is a relation *variable*, but it is the nonsense you
> suspect if R1 is a relation *value*.
R1 can neither be equated to relvar nor to relvalue. See analogy about
function F(x)
> [ snippage ]
>
> > I see your point but I am not worried about typing. Let's assume that
> > all candidate tuples for INSERT/DELETE are valid.
> >
>
> That would be a pretty big assumption to take; the fundamental
> constraints on a relation variable are the names and attributes of the
> relation values the relation variable can indicate.
In abstract reasonning, one has to make assumptions over constraints to
be able to reason because trying to study all parameters of a
hypothesis leads to confusion.
> [ snippage ]
>
> > Let's forget relvar and relvalue for the moment and focus on the
> > relation (I should have called this thread accordingly). The question
> > is that if one considers that the INSERT of a new tuple is the
> > possibility for the relvar to hold a new value does it hold it for
> > relation R1 or does it hold for a new relation R2. The answer seems
> > clear to me.
> >
>
> If this means what I think it means, then there is a new relation
> value, R2. (Date usually uses "relation" as a shorthand for "relation
> value"; is that also what you mean ? I'm a little concerned by the
> opening "let's forget relvar and relvalue for the moment and focus on
> the relation" that you might be using "relation" differently. Is that
> so ?)
I do not feel confortable with a lot of Date's *shorthands* in defining
terminology for SQL audiences. I consider them as an effort for
vulgarization of RM concepts that sometime leads to add more confusion
than anything else. R2 is a new relation that is the product of adding
through INSERT the relvalue S to relation R1.
> > At abstract level of reasoning, I am not convinced that relations can
> > *only* be characterized by their values or operations. I do not feel
> > confortable with *create new* concept because it is not really and idea
> > of creating a new instance but a whole new relation.
> >
>
> How else would you characterise relations ? What do you think or
> suspect is missing ? (This is probably the most important question in
> the exchanges so far, I think.)
You are right this is the question on which I have been chewing on the
last few years with some interesting observations. What I believe
current relation definition are missing are definitions, operators and
tools that can specify their nature and interaction at relation level.
To clarify the problem at hand I will use an example.
For the rest of the example, let's suppose all attribute data types are
integers.
For instance, assume relation R1{A1, A2} with 2 tuples noted R1(1) and
R1(2) and
relation R2{2, 3} containing single tuple R2(1).
As a consequence of the above assumptions
R1(1) = {3, 4}
R1(2) = {4, 2}
and
R2(1) = {2, 3}
If we INSERT relvalue R2(1) to R1 then the operation would produce R3
being a new relation that is neither R1 nor R2. The operation is
usually expressed as UNION between R1 and R2 that produces a relation
R3
R1 UNION R2 = R3
R3 single occurrences could be expressed as
R3(1) = {3, 4}
R3(2) = {4, 2}
R3(3) = {2, 3}
As you can notice above, R1, R2 and R3 are characterized as being a
part of the operation R1 UNION R2 = R3. But what else could be said
of R1(x), R2(x), R3(x)? How could these expressions of the relation
can be specified independently from the operations they perform.
You can also notice that relations are also characterized by the
relvalues that allowed to build up the UNION. But what about the
structural aspect of relations. So the question is how do we define
relations independently from the relvalues. For instance, the function
F(x) = 2*x +2 expresses the function independently of some specific
value because the variable x could represent any value to which
function F can be evaluated. A similar effort of expression should be
done for relations in the sense that expression should be done
independently from operations performed and possible relvalues the
relation may have.
Such area is indeed at the limit of current understanding of RM issues.
Which is why mathematical insight on the problem is necessary (which
gets us back at the initial topic).
> > Suppose for instance R1 constitute a domain on which values can be
> > drawn. It necessarily has a limited number of values. Don't you think
> > adding a new value changes fundamentally the nature of the R1 defined
> > domain and therefore is possible if and only if a new domain and a new
> > relation R2 are created?
> >
>
> But R1 isn't a type - it *has* a type, but it isn't a type itself. The
> *type* of R1 would constitute a new domain, as that would describe
> which relation values could be considered to be of that type.
For the moment, forget typing and consider only domain definition. R1
relvalues are the element that define Domain DoR1. N relation data
types could later *derived* from DoR1 by applying restrictions on DoR1
extraction. But typing is not at the moment the issue that is
interesting.
> Endnote: completely (well, almost completely) by chance, my copy of
> Date's Introduction (7th ed.) is open at page 133, which ends with :
>
> "... we should now add that to talk, as we have just been doing, of
> "updating a tuple" (or set of tuples) is really rather sloppy. Tuples,
> like relations, are values and cannot be updated (by definition, the
> one thing you cannot do to any value is change it). In order to be able
> to "update tuples", we would need some notion of a tuple variable or
> "tuplevar" - a notion that is not part of the relational model at all !
I know this definition but I don't feel confortable with it as it
contradicts initial Codd's postulate and defeats the purpose of
application of mathematical relations to RM. What he calls *tuplevar*
is nothing but relvar some relation R1. I suspect it is a word of
caution because lots of work needs to be done for better specification
of relations.
> Thus, what we really mean when we talk of "updating tuple t to t'," for
> example, is that we are replacing the tuple t (the tuple value t, that
> is) by another tuple t' (which is, again, a tuple value). Analogous
> remarks apply to phrases such as "updating attribute A" (in some
> tuple). In this book, we will continue to talk in terms of "updating
> tuples" or "updating attributes of tuples" - the practice is convenient
> - ***but it must be understood that such usage is only shorthand, and
> rather sloppy shorthand at that.***" (add'l emphasis mine)
Date's word of caution is significant that some aspects of relations
should be specified. To my knowledge, Date's has not gone far enough
for that but that does not make it outside of Codd's intent of what RM
should be: a direct application of math. Question is: are mathematical
relation a sufficient math tool to characterize sufficiently the nature
of relations on a mathematical perspective. I personally believe not
which is why ensemblist math seems to be helpful.
Cimode
derived and defined. Sorry for all confusions I may have induced.
Cimode
about relations should avoid decutiveness based on implementation. As
a rule of thumb, I am not sure about some point in RM, I always get
back to math.
Cimode
*Strong* caution must be put here before assuming relations and
relvalue are synonyms. relvalues are not to be confused with relations
in abstract thinking. The only thing that can be said is that a
relvalue is *necessarily* the *evaluation* of a specific relation. An
N tuples relvalue necessarily constitutes the *evaluation* a relation
R1 but does not equate to R1.
Question is how a relation can be defined or specified otherwise than
by the relvalues it may evaluate to? When a function F(x) is defined
as 2 * x + 2 such definition is independent from the values to which
the function is evaluated. The value F(2) is an evaluation of
function F when the variable x = 2. Stating that F(x) = 2 changes the
nature of the function.
The*usual* vulgarization intended (shorthand) meaning or *usage* of the
term relation does not constitute a proof.
> [snip]
Cimode
Aloha Kakuikanu
...
There is a coherent article on the topic:
http://arxiv.org/PS_cache/cs/pdf/0607/0607039.pdf
with bourbaki "ensmble" theory as a first citation. Didn't digest it
yet.
Cimode
That's because it is not supposed to be easily *digestable* ;) Thanks
for the effort...
As you can see, we are far from Date's (useful) proselythism of RM's
initial footprint...
An interesting synthetizing effort ...(I particularly encourage readers
to read Paul R. Halmos. Naive Set Theory.)
Tony D
Excellent - I've had a quick run at the first few sections (with "a-ha
!" moments as similarities to the lambda calculus get pointed out) and
look forward to spending more time on this. Thanks !
erk
> *Strong* caution must be put here before assuming relations and
> relvalue are synonyms. relvalues are not to be confused with relations
> in abstract thinking. The only thing that can be said is that a
> relvalue is *necessarily* the *evaluation* of a specific relation.
An "evaluation of a specific relation" means that you must be
evaluating an expression. Perhaps you mean "dereferencing", which would
return the value referenced by a variable?
Either way, the concepts of values and variables are fundamental;
"abstract thinking" can't smooth over their differences. When you say
"relation," you mean either a VALUE (the usual definition), or a
VARIABLE. If there's another concept here, define it.
> An N tuples relvalue necessarily constitutes the *evaluation* a relation
> R1 but does not equate to R1.
I don't understand this sentence.
> Question is how a relation can be defined or specified otherwise than
> by the relvalues it may evaluate to?
Then in this context by "relation" you mean a RELVAR, which can "hold"
RELVALS of a type (the type of the relvar), and thus can vary over
time.
> When a function F(x) is defined
> as 2 * x + 2 such definition is independent from the values to which
> the function is evaluated. The value F(2) is an evaluation of
> function F when the variable x = 2. Stating that F(x) = 2 changes the
> nature of the function.
It defines a new function. It doesn't make sense to refer to a changing
function; you're defining a new one - for example, "F(x) = 2" has type
ANY -> int, while "F(x) = 2*x + 2" might be int -> int or number ->
number.
There's no relationship between redefining a function F and changing
the relval assigned to a relvar (e.g. via update operations).
Especially in view of database constraints which not only restrict
tuples in a relvar but also restrict sets of relvars simultaneously
(e.g. database constraints, rather than those in a single relvar).
- Eric
Bob Badour
> Cimode wrote:
>
>>*Strong* caution must be put here before assuming relations and
>>relvalue are synonyms. relvalues are not to be confused with relations
>>in abstract thinking. The only thing that can be said is that a
>>relvalue is *necessarily* the *evaluation* of a specific relation.
Bullshit. A relation is a relation no matter how one describes it.
[eric's reply snipped]
>>When a function F(x) is defined
>>as 2 * x + 2 such definition is independent from the values to which
>>the function is evaluated. The value F(2) is an evaluation of
>>function F when the variable x = 2. Stating that F(x) = 2 changes the
>>nature of the function.
Just as each tuple is an instantiated predicate. Big deal.
[eric's reply snipped]
Cimode
erk wrote:
> Cimode wrote:
> > *Strong* caution must be put here before assuming relations and
> > relvalue are synonyms. relvalues are not to be confused with relations
> > in abstract thinking. The only thing that can be said is that a
> > relvalue is *necessarily* the *evaluation* of a specific relation.
>
> An "evaluation of a specific relation" means that you must be
> evaluating an expression. Perhaps you mean "dereferencing", which would
> return the value referenced by a variable?
evaluated mathematically speaking. When a relvar hold a specific
relvalue in time, then and only the such evaluation represents an
relvalue N tuple set. The definition of the relation itself can not be
equated to either a specific relvalue nor to a relvar. Besides the
same relation can be expressed using several relvars: it still is the
same relation.
For instance F(x) is expressed as 2 * x + 2 if you express another
function T(y) as =
2 * y + 2 then F = T
When the variable x in F or the variable y for T holds the value 2 both
F and T = 2 * 2 + 2 = 6 . By analogy F and T are equivalent to
relations R1 and R2, just as *x* and *y* are relvars, just as *6* is a
specific relvalue to which relation R1 is evaluated when *x* and *y*
have a specific relvalue. An inverse reasoning allow to establish that
a relvalue is necessarily a relation as well.
> Either way, the concepts of values and variables are fundamental;
> "abstract thinking" can't smooth over their differences. When you say
> "relation," you mean either a VALUE (the usual definition), or a
> VARIABLE. If there's another concept here, define it.
I define relation as a specific type of function. For relation
definition, look for function definition as opposed to variable and
value definitions.
> > An N tuples relvalue necessarily constitutes the *evaluation* a relation
> > R1 but does not equate to R1.
>
> I don't understand this sentence.
See above analogy.
> > Question is how a relation can be defined or specified otherwise than
> > by the relvalues it may evaluate to?
>
> Then in this context by "relation" you mean a RELVAR, which can "hold"
> RELVALS of a type (the type of the relvar), and thus can vary over
> time.
Definition of relation is independent from both relvalues and relvar
definition.
> > When a function F(x) is defined
> > as 2 * x + 2 such definition is independent from the values to which
> > the function is evaluated. The value F(2) is an evaluation of
> > function F when the variable x = 2. Stating that F(x) = 2 changes the
> > nature of the function.
>
> It defines a new function. It doesn't make sense to refer to a changing
> function; you're defining a new one - for example, "F(x) = 2" has type
> ANY -> int, while "F(x) = 2*x + 2" might be int -> int or number ->
> number.
Absolutely. Which is why a relation or a function should *not* be
assimilated by deifnition to either relvar or relvalue.
> There's no relationship between redefining a function F and changing
> the relval assigned to a relvar (e.g. via update operations).
True. I have used the example above the illustrate the danger to
deifne relation accordingly to either relvalues or relvar. It just
lead to false reasonning/
> Especially in view of database constraints which not only restrict
> tuples in a relvar but also restrict sets of relvars simultaneously
> (e.g. database constraints, rather than those in a single relvar).
The primary purpose of DB constraints through type definitions is *not*
to restrict tuples in relvars but to restrict relvalues that later
*fill in* the relvar. Therefore, a relvar can only be filled with
permissible NTuples relvalues by definition. That is the whole point
with RM definitions.
>
> - Eric
erk
> erk wrote:
> > An "evaluation of a specific relation" means that you must be
> > evaluating an expression. Perhaps you mean "dereferencing", which would
> > return the value referenced by a variable?
> No. I mean a relation can be evaluated just as a function can be
> evaluated mathematically speaking.
What does "evaluate" mean, mathematically? Without bringing a formal
definition into it, evaluation is a process of symbolic manipulation,
to reduce an EXPRESSION to another expression (usually to a value, a
kind of expression).
You really do mean dereferencing if you mean "getting the current value
of a variable," like getting the current relval from a relvar.
"Evaluation" is a different beast, and the word CAN be used, for
example, to reduce the expression R1 UNION R2 if you know what R1 and
R2 (or their current relvals) are.
> When a relvar hold a specific
> relvalue in time, then and only the such evaluation represents an
> relvalue N tuple set.
I have no idea what this means, but what does the evaluation
"represent" the rest of the time?
> The definition of the relation itself can not be
> equated to either a specific relvalue nor to a relvar.
Then what is it?
> Besides the
> same relation can be expressed using several relvars: it still is the
> same relation.
So a Relation is a template, or type, for typing variables? If so, I
think you should use a term other than "relation," which is already
overloaded, as our discussion shows.
> For instance F(x) is expressed as 2 * x + 2 if you express another
> function T(y) as =
> 2 * y + 2 then F = T
Yes, but relations aren't quite the same. For an O-O example, let's say
you have an object class called Boob. You can declare variables
(references) as follows:
public Boob tweedleDee;
public Boob tweedleDum;
But although they're of the same type, that doesn't mean they're the
same thing. Same with relations. Imagine this syntax:
relation T1 = {boob left, boob right} (or whatever you like,
including constraints, such as left != right, except perhaps in
cyclopettes)
...
relvar GREAT_BOOBS as T1;
relvar LOUSY_BOOBS as T1;
Both GREAT_BOOBS and LOUSY_BOOBS are of type T1, but have different
meanings - their predicates are different. They're not the same.
So to me, the definition of "same relation" isn't the type, but the
specific relvar. Since each relvar can occur in a database once and
once only, that seems reasonable and useful.
> When the variable x in F or the variable y for T holds the value 2 both
> F and T = 2 * 2 + 2 = 6 .
F and T are the same function; changing the name of the free variable
is meaningless. And functions which behave the same ARE the same.
Relvars can have different relvals at different points in time; thus 2
relvars, even of the same re
> By analogy F and T are equivalent to relations R1 and R2,
No, they're not. Mathematically, functions are subsets of relations.
And as we're discussing them here, I don't see the analogy.
> just as *x* and *y* are relvars, just as *6* is a
> specific relvalue to which relation R1 is evaluated when *x* and *y*
> have a specific relvalue.
This line in particular confuses me.
> I define relation as a specific type of function.
It's the other way around; a function is a specific type of relation.
> For relation
> definition, look for function definition as opposed to variable and
> value definitions.
Variables are a computing construct (and a poor replacement for
postconditions and constraints); mathematics deals with values. Forgive
the overgeneralization.
> > > An N tuples relvalue necessarily constitutes the *evaluation* a relation
> > > R1 but does not equate to R1.
> >
> > I don't understand this sentence.
> See above analogy.
Which I didn't understand.
> Definition of relation is independent from both relvalues and relvar
> definition.
Then please state the definition.
> > It defines a new function. It doesn't make sense to refer to a changing
> > function; you're defining a new one - for example, "F(x) = 2" has type
> > ANY -> int, while "F(x) = 2*x + 2" might be int -> int or number ->
> > number.
> Absolutely. Which is why a relation or a function should *not* be
> assimilated by deifnition to either relvar or relvalue.
But the relations we're talking about aren't exactly the same as
mathematical ones. It would help if you defined relation as you
understand it. In relational model term "relation" means either relvar
or relval - it's loose.
> > There's no relationship between redefining a function F and changing
> > the relval assigned to a relvar (e.g. via update operations).
> True. I have used the example above the illustrate the danger to
> deifne relation accordingly to either relvalues or relvar. It just
> lead to false reasonning/
????
> The primary purpose of DB constraints through type definitions is *not*
> to restrict tuples in relvars but to restrict relvalues that later
> *fill in* the relvar.
True, I was sloppy.
> Therefore, a relvar can only be filled with
> permissible NTuples relvalues by definition. That is the whole point
> with RM definitions.
True.
- erk
Tony D
to last night, but wanted to check on something in this post.
Here goes :
Cimode wrote:
> No. I mean a relation can be evaluated just as a function can be
> evaluated mathematically speaking. When a relvar hold a specific
> relvalue in time, then and only the such evaluation represents an
> relvalue N tuple set. The definition of the relation itself can not be
> equated to either a specific relvalue nor to a relvar. Besides the
> same relation can be expressed using several relvars: it still is the
> same relation.
>
> For instance F(x) is expressed as 2 * x + 2 if you express another
> function T(y) as =
> 2 * y + 2 then F = T
>
> When the variable x in F or the variable y for T holds the value 2 both
> F and T = 2 * 2 + 2 = 6 . By analogy F and T are equivalent to
> relations R1 and R2, just as *x* and *y* are relvars, just as *6* is a
> specific relvalue to which relation R1 is evaluated when *x* and *y*
> have a specific relvalue. An inverse reasoning allow to establish that
> a relvalue is necessarily a relation as well.
>
So, would this mean something like :
relation := what we would otherwise think of as the relation header
(plus a mapping ?)
relvar := what we would otherwise think of as an attribute
relvalue := the result of 'evaluating' a 'relation' with the 'relvars'
filled in with appropriate values
If this is the case, and it is attempted to define a relation as a
function, what is the type of the function ? That is, given a
'relation' R with 'relvars' of type A,B and C
R : A -> B -> C -> ???
Without thinking about it in great depth, I can see some problems here.
We'd normally view a relation as a predicate, and the tuples as true
propositions, so on the face of it you might say
R : A -> B -> C -> Boolean
But what are the implications of that ? (Presumably, the map of the
function could only return True, otherwise could you directly assert a
falsehood ?) Alternatively, what else could be the result type of an
evaluation like this ?
[ snippage ]
Back to reading ...
Cimode
erk wrote:
>Cimode wrote:
>What does "evaluate" mean, mathematically? Without bringing a formal
>definition into it, evaluation is a process of symbolic manipulation,
>to reduce an EXPRESSION to another expression (usually to a value, a
>kind of expression).
The evaluation of a relation for a specific Ntuple relvalue is another
unique relvalue.
A relation can be defined mathematically as a transformation of a
specific N-tuple set into another Ntuple set just as a linear function
can be defined as a transformation of a numeric value into another
numeric value .
With function F(x) = 2 * x + 2, the evaluation of function F for x = 1
is 4, the evaluation of function F for x = 2 is 6 an so forth...
>You really do mean dereferencing if you mean "getting the current value
>of a variable," like getting the current relval from a relvar.
>"Evaluation" is a different beast, and the word CAN be used, for
>example, to reduce the expression R1 UNION R2 if you know what R1 and
>R2 (or their current relvals) are.
No. Evaluation is a mathematical concept that exists since algebra
exists.
See above example.
> > When a relvar hold a specific
> > relvalue in time, then and only the such evaluation represents an
> > relvalue N tuple set.
>
>I have no idea what this means, but what does the evaluation
>"represent" the rest of the time?
As relvar holds N possible relvalues a relation evaluates to N other
relvalues.
> > The definition of the relation itself can not be
> > equated to either a specific relvalue nor to a relvar.
>
>Then what is it?
See above definition. A relation can be viewed as a transformation.
> > Besides the
> > same relation can be expressed using several relvars: it still is the
> > same relation.
>
>So a Relation is a template, or type, for typing variables? If so, I
>think you should use a term other than "relation," which is already
>overloaded, as our discussion shows.
Typing is a part of relation definition. It can be viewed as a
mechanism to allow restriction on extraction from domain of values.
A relation is a mathematical construct that can be expressed in several
ways
which demonstrates independence from relvalues.
> > For instance F(x) is expressed as 2 * x + 2 if you express another
> > function T(y) as =
> > 2 * y + 2 then F = T
>
>Yes, but relations aren't quite the same. For an O-O example, let's say
>you have an object class called Boob. You can declare variables
>(references) as follows:
>
>public Boob tweedleDee;
>public Boob tweedleDum;
>
>But although they're of the same type, that doesn't mean they're the
>same thing. Same with relations. Imagine this syntax:
>relation T1 = {boob left, boob right} (or whatever you like,
>including constraints, such as left != right, except perhaps in
>cyclopettes)
>...
>relvar GREAT_BOOBS as T1;
>relvar LOUSY_BOOBS as T1;
Looking at this line is revealing...You are loosing the whole interest
into using relations which is type derivation.
consider a relation R1 = {boob_type} where boob_type can extract values
from domain DoR1 having relvalues{great boobs, super boobs, lousy
boobs, flat boobs}.
consider relation R1 is defined as follows:
--> a data type named goodboobtype to define boob_type attribute.
--> Imagine that goodboob type is defined as a restriction from
domain D1 so that accepts *only* permissible values to *great boobs*
and *super boobs* discarding *lousy boobs* and *flat boobs*. The
relation R1 basically transforms the Ntuples relvalue {great boobs,
super boobs, lousy boobs, flat boobs} to the relvalue {great boobs,
super boobs}
Consider now a relation R2 that has the same characteritics as R1 above
but is has different terminology defining it. (The relation would be
called R2 instead of R1). It would be reasonnable to assume R1 = R2.
Both R1 and R2 are an expression of the same relation.
consider relation R3 is defined as follows:
--> a data type called *badboobtype* to define boob_type attribute.
--> Imagine that *badboobtype* is defined as a restriction from
domain D1 so that accepts *only* permissible values to *lousy boobs*
and *flat boobs* discarding *great boobs* and *super boobs*. The
relation R1 basically transforms the Ntuples relvalue {great boobs,
super boobs, lousy boobs, flat boobs} to the relvalue {lousy boobs,
flat boobs}
Now, if you consider the domain created by R1 as being *possible*
values {great boobs, super boobs}, thanks to defining a new data type
called verygoodboobtype you may define a new relation R3 that includes
only the following relvalue {super boobs}.
Relation R3 transforms the set of tuples {great boobs, super boobs} to
{super boobs}
You may then define relvars
as
relvar GREAT_BOOBS as goodboobtype
relvar LOUSY_BOOBS as badboobtype
relvar SUPER_BOOBS as verygoodboobtype
>Both GREAT_BOOBS and LOUSY_BOOBS are of type T1, but have different
>meanings - their predicates are different. They're not the same.
You can *not* consider that there is no distinction in data type
between such oppositely defined concepts. You are loosing
information. RM is by definition explicit.
>So to me, the definition of "same relation" isn't the type, but the
>specific relvar. Since each relvar can occur in a database once and
>once only, that seems reasonable and useful.
>
> > When the variable x in F or the variable y for T holds the value 2 both
> > F and T = 2 * 2 + 2 = 6 .
>
>F and T are the same function; changing the name of the free variable
>is meaningless. And functions which behave the same ARE the same.
>Relvars can have different relvals at different points in time; thus 2
>relvars, even of the same re
>
> > By analogy F and T are equivalent to relations R1 and R2,
>
>No, they're not. Mathematically, functions are subsets of relations.
>And as we're discussing them here, I don't see the analogy.
I can not see why you don't see the analogy given the examples. I am
sorry I can not explain it better. .
I can not see how a function is a subset of a relation. Do you mean
that a trigonometric function is a subset of a relation?
A relation on the other hand is a subset of function in the sense it
share the common transformation of functions. For instance, a linear
function transforms numeric values into other numeric values, a
rotation transforms a set of points into another set of point. Same
thing applies to relation which transforms a relvalue into another
relvalue. Which basically makes a relation a subset of functions.
> > just as *x* and *y* are relvars, just as *6* is a
> > specific relvalue to which relation R1 is evaluated when *x* and *y*
> > have a specific relvalue.
>
>This line in particular confuses me.
>
> > I define relation as a specific type of function.
>
>It's the other way around; a function is a specific type of relation.
Sorry but no. It is not the other way around, at least not
mathematically. Keep in mind that all subsets necessarily share the
characteritics of the superset. All relation characteristics do not
necessarily apply to other functions, therefore ANY functions is not
subset of relation (rotation for instance). Therefore ANY function is
not necessarily a subset of relations.
> > For relation
> > definition, look for function definition as opposed to variable and
> > value definitions.
>
>Variables are a computing construct (and a poor replacement for
>postconditions and constraints); mathematics deals with values. Forgive
>the overgeneralization.
No. Variables exists since algebra exists.
> > > > An N tuples relvalue necessarily constitutes the *evaluation* a
>relation
> > > > R1 but does not equate to R1.
> > >
> > > I don't understand this sentence.
> > See above analogy.
>
>Which I didn't understand.
>
> > Definition of relation is independent from both relvalues and relvar
> > definition.
Think transformation.
>Then please state the definition.
>
> > > It defines a new function. It doesn't make sense to refer to a
>changing
> > > function; you're defining a new one - for example, "F(x) = 2" has type
> > > ANY -> int, while "F(x) = 2*x + 2" might be int -> int or number ->
> > > number.
> > Absolutely. Which is why a relation or a function should *not* be
> > assimilated by deifnition to either relvar or relvalue.
>
>But the relations we're talking about aren't exactly the same as
>mathematical ones. It would help if you defined relation as you
>understand it. In relational model term "relation" means either relvar
>or relval - it's loose.
RM is not about being *loose*. It's about direct application of
mathematical theory and so should be terminology employed.
All I can say is that in RM abstract and logical definitions should be
driven by math as Codd intended it so math shows the way not the way
around. One who makes conclusions about RM through the perspective of
computational and implementation layer (SQL, programming) increases
dramastically the chance of doing false reasonning.
[Snipped]
>- erk
Cimode
Tony D wrote:
> So, would this mean something like :
>
> relation := what we would otherwise think of as the relation header
> (plus a mapping ?)
No a relation is a tranformation of specific relvalues (N Tuples) into
some other relvalue.
> relvar := what we would otherwise think of as an attribute
> relvalue := the result of 'evaluating' a 'relation' with the 'relvars'
> filled in with appropriate values
A relvalue is an NT Tuple set.
> If this is the case, and it is attempted to define a relation as a
> function, what is the type of the function ? That is, given a
> 'relation' R with 'relvars' of type A,B and C
A function that transforms NTuple set into other NT Tuple sets.
The type of the attribute is a mechanism that allows restriction of
extraction of possible values.
> R : A -> B -> C -> ???
>
> Without thinking about it in great depth, I can see some problems here.
> We'd normally view a relation as a predicate, and the tuples as true
> propositions, so on the face of it you might say
A predicate is not a relation. A relation is a function while a
predicate is a constraint mechanism that helps define through binary
logic if Ntuple relvalues are possible candidates for possible
INSERT/DELETE/UPDATE operation.
With attribute constraints respect, a predicate allows to define the
coherence of an N-tuple system to become a permissible candidate
relvalue to be added/deleted/updated to a specific relation. By
definition, such predicate must be evaluated to true with all tuples.
> R : A -> B -> C -> Boolean
>
> But what are the implications of that ? (Presumably, the map of the
> function could only return True, otherwise could you directly assert a
> falsehood ?) Alternatively, what else could be the result type of an
> evaluation like this ?
Predicate is a mechanism that helps define if a relvalue is a
*candidate* relvalue for UNION with the relvalue of some relation.
The consequence of a predicate evaluated to true + respect of
constraints of UNIQUENESS + respect of relvalue - attribute data type
constraints is the possibility to operate the relation to produce a new
relation. For instance, consider R1(attribute1, attribute2) with the
folowing relvalues...
Tuple1 R1{1, A}
Tuple2 R1{3, B}
Tuple3 R1{2, E}
Tuple4 R1{3, A}
Tuple5 R1{2, R}
Supppose attribute1 has data type allowing permissible values {1, 2,
3}. Supppose attribute2 has data type allowing permissible values {A,
B, E, R, T}
Now consider relation R2 with same attributes as R1 but with different
relvalues.
Tuple1 R2{2, A}
Tuple2 R2{1, E}
As you can see R1 UNION R2 would result in R3 with the following
relvalues:
Tuple1 R3{1, A}
Tuple2 R3{3, B}
Tuple3 R3{2, E}
Tuple4 R3{3, A}
Tuple5 R3{2, R}
Tuple1 R3{2, A}
Tuple2 R3{1, E}
Such operation was possible because ALL tuples of R2 respect the
following conditions:
1) attribute1 and attribute2 in R1 are *respectively* of the same
type than attribute1 and attribute2 in R2
2) R1 INTERSECT R2 = NULL (no tuple in R1 is present in R2)
3) Both relvalues of R1 and R2 allow to evaluate the same predicate
because each tuple on both relations R1 AND R2 always evaluate to
TRUE
erk
you're making points, I'm not understanding them. So I've trimmed the
below to address things I could make sense of. If you have the same
comments on my comments, don't bother - I don't think this can go any
further.
It was probably a big mistake to continue as long as I did.
On second thought, I'm stopping now. The more I respond, the more
convinced I am that I have no chance of understanding what you're
saying. If anyone else does, I'd like to know, just to spot-check my
own sanity. Any time I get down to specifics, you say "this is
mathematical since algebra" or some such. We've reached the end of the
trail.
- Eric
Cimode
erk wrote:
> We seem to just have an insurmountable failure to communicate. If
> you're making points, I'm not understanding them. So I've trimmed the
> below to address things I could make sense of. If you have the same
> comments on my comments, don't bother - I don't think this can go any
> further.
you are using computational perspective to RM while I prefer a
fundamentalist mathematical approach to RM definitions. In their own
framework none of them is really wrong jus a matter of perspective.
The only difference is I perfectly understand your perspective. I am
sorry I could not get the point through. I have tried using several
examples but it just does not get through.
> It was probably a big mistake to continue as long as I did.
It is all right. At least it is not sterile OO VS RM debate. One
conclusion already reached is importance of terminology which is a good
conclusion. I also pointed out some math reading throughout the
thread that may clarify some issues.
> On second thought, I'm stopping now. The more I respond, the more
> convinced I am that I have no chance of understanding what you're
> saying. If anyone else does, I'd like to know, just to spot-check my
> own sanity. Any time I get down to specifics, you say "this is
> mathematical since algebra" or some such. We've reached the end of the
> trail.
Tony D has already understood most of the concepts I have explained and
asked clarifications and questions I responded. The reason I invoke
simple reasons such as *since algebra exists* is because I define
variables according to mathematical perspective while you seem to have
a pure computational perspective on it. I encourage you to do more
math and you will understand better. After all RM is a direct
application of math.
Nice chat ;)
> - Eric
Tony D
Cimode wrote:
> Tony D has already understood most of the concepts I have explained and
> asked clarifications and questions I responded.
I think "understood" might be overstating things a little ;)
Anyway, I've given the paper Aloha referenced a while ago a couple of
quick reads and had a few eye-opening moments, so now that work has
calmed down I can give it a more thorough read. I will probably return
with yet more questions ...
Cimode
Tony D wrote:
> Cimode wrote:
>
> > Tony D has already understood most of the concepts I have explained and
> > asked clarifications and questions I responded.
>
> I think "understood" might be overstating things a little ;)
asked the right questions implied by the assertions made on a math
fundamental perspective.
> Anyway, I've given the paper Aloha referenced a while ago a couple of
> quick reads and had a few eye-opening moments, so now that work has
> calmed down I can give it a more thorough read. I will probably return
> with yet more questions ...
That is a good approach. I encourage you to read some of the pointers
exposed in Aloha' paper...Some understanding of the math issues may
explain better where I am getting at...