 | |
#1
 
| |||
| |||
|
header part of the value? -
02-24-2008
, 12:48 PM
#2
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#3
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#4
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#5
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#6
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#7
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#8
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#9
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
#10
| |||||
| |||||
|
|
Occasionally the question has come up as to whether a relation value is the body, or the body+the header. In the past I've sided with the just-the-body approach, but today I decided that I don't think that anymore. |
Quote:
|
Consider the algorithm to perform a natural join on two relation values. Just values: not tables in a database with a known schema or whatever. Just two plain relation values. The natural join specification *requires* the header; it is defined (in part) in terms of the header. So the header must be part of the value. |
Quote:
|
Of course, that then leads me to think of a relation value as a <header, body> tuple. |
to think that? Why is a db-relation value not merely a set of finite
partial functions (db-tuples), mapping attribute names onto values?
We've broadly agreed in another thread that functions can be
represented themselves as mathematical relations, so let us represent
an example ternary relation-value, without a header component in
sight:
{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,
....
{ (a, xn), (b, yn), (c, zn) }
}
No probs there right?
Quote:
|
(Let us omit column type information for the present discussion.) Then one imagines an updatable relation variable in a database as holding a value of this tuple type. BUT then we notice that we have this restriction that the header must not be updated. Why is that? |
point in time) a value from a set of valid relations - lets call it V
- as defined by the predicate and constraints. So, for instance,
continuing the above example we had a relvar R, that had to match the
predicate P(x, y, z) and enforce the constraint that c is less than
10, we'd have:
R(t) $B":(B V
where:
V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }
or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and
constraints upheld] }
I'm not sure we need anything more than that. When we try and make an
update, the model checks that the relation value we are suggesting
does exist in V. If it does R(t+1) becomes the new value, and if it
doesn't, we are returned a "looks like you've made a mistake" error.
Least that's how I see the mathematical situation after Codd
incorporated attribute names into the mix (we don't need no steenking
heea-ders, speedy gonzales). Regards, Jim.
Quote:
|
Certainly in practice this is the sort of thing that would be almost universally a good idea. But what theoretical basis does it have? I can think of none. So I propose, for your amusement, the mental model that a relation variable is merely a simple binding from a name to a header, body> relation value, period, full stop. Also, *customarily* the variable has the update constraint that old.header = new.header. Marshall |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.