# 21
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 22
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 23
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 24
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 25
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 26
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 27
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 28
| |||

| |||

## |

paul c wrote: ,,, Neither has the Y' result dropped any tuples and we have a situation where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words DELETE R WHERE X = 1 AND Y = 1 does nothing! ... Oops, just noticed, that was pretty clumsy, what I wrote denies everything I've been saying all along and I didn't mean that. I should have said it subjunctively: "... if we had a situation where R' were not equal to X' AND> Y', we would have a serious contradiction in the algebra, so R' IS equal to X' <AND> Y' and no tuples are dropped from the result...". I stand by the rest, ie., the DELETE statement does nothing. (I don't know why Date referred to the statement as an "operation". Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. But as long as I live, I imagine there will always be nuances he suggests that will puzzle me.) Also, I want to comment further on what 'BS' said in a reply about an algebra and it not having any notion of 'before' or 'after'. I agree that the A-algebra doesn't have such notions, which in fact is one of its advantages, eg., there are fewer concepts in an algebra to confuse us (and I do mean the plural 'us'). As Darwen likes to point out, logic isn't concerned with meaning, which is its advantage because we can choose the analogues we want to use it for. It's like when McCarthy talked about submarines not being able to swim. They can't but we can pretend that they can pretend to (apologies to Bob B for the possible homomorphism, but even D&D overload the verb 'to know' when they talk about dbms's! As Djiksta said, when you get right down to it, all a program does is manipulate symbols. What the symbols mean is up to 'us'). But I would like to ask how is that a result can't be interpreted as an 'after value' when an algebraic equation does allow us to talk of a result of algebraic operations? What's more, no matter what changes happen over time, such an equation, if it doesn't contradict any others, as well as the result, is always true. It is simple to invent algebraic operands that can be interpreted as 'before' and 'after', one just makes up names, eg., R' and R. The names can stand double-duty too in that (consistent) equations are invariant. Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. Whether dire or not, I judge them to be self-inflicted consequences. |

Regardless of how many possible values there can be for a database, only one

can actually be the value of the database at any set point in time.

Algebraic expressions derive information from the actual value of the

database; updates, on the other hand, assert which possible value for the

database is also the actual value. Common sense tells us to discard a

result that is based upon a false premise, so it follows that the result of

an algebraic expression that involves a possible value for the database that

is not also the actual value is just as useless. The algebra and the

calculus are therefore limited in their utility to answering queries from

the actual value of the database and have absolutely nothing to do with

selecting which possible value is also the actual value. In other words,

neither the algebra nor the calculus are sufficient when it comes to

database updates. As a consequence, a 'purely algebraic' approach here is

contraindicated.

There's nothing wrong it using the algebra or the calculus for what they

were designed for, which is answering queries, or even for calculating the

resulting set of relations that are becoming the new value for the database,

but it's important to remember that it is the result that is assigned, and

that the assignment principle doesn't require that the result be

recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the

current value in x. This is in accord with the assignment principle because

the rhs of the assignment is only evaluated once.

# 29
| |||

| |||

## |

# 30
| |||

| |||

## |