dbTalk Databases Forums  

A different definition of MINUS, Part 3

comp.databases.theory comp.databases.theory


Discuss A different definition of MINUS, Part 3 in the comp.databases.theory forum.

Reply
 
Thread Tools Display Modes
  #21  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM







"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.






Reply With Quote
  #22  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM







"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.




Reply With Quote
  #23  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM




"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.




Reply With Quote
  #24  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM




"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.




Reply With Quote
  #25  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM




"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.




Reply With Quote
  #26  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM




"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.




Reply With Quote
  #27  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM




"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.




Reply With Quote
  #28  
Old   
Brian Selzer
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-17-2008 , 11:12 PM




"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

Quote:
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.
It isn't about implementation: it's about the logic that underpins the RM.
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.




Reply With Quote
  #29  
Old   
Cimode
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-18-2008 , 03:31 PM



Hope this will publish adequately...

R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - RXD

R=[{1},{2},{4}]
D= [{1},{3}]

R-D = [{1},{2},{4}] U [{2}, {3}] - [{1, 1}{1, 2}{1, 4} {3, 1} {3, 2}
{3, 4}]
=[{1}{2}{3}{4}] - [{1, 1}{1, 2}{1, 4} {3, 1} {3, 2}{3, 4}]
=[{1}{2}{3}{4}] - [{1}, {3}]
=[{2}{4}]

Reply With Quote
  #30  
Old   
Cimode
 
Posts: n/a

Default Re: A different definition of MINUS, Part 3 - 12-18-2008 , 03:31 PM






Hope this will publish adequately...

R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - RXD

R=[{1},{2},{4}]
D= [{1},{3}]

R-D = [{1},{2},{4}] U [{2}, {3}] - [{1, 1}{1, 2}{1, 4} {3, 1} {3, 2}
{3, 4}]
=[{1}{2}{3}{4}] - [{1, 1}{1, 2}{1, 4} {3, 1} {3, 2}{3, 4}]
=[{1}{2}{3}{4}] - [{1}, {3}]
=[{2}{4}]

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.