 | |
#41
 
| |||
| |||
|
Re: A different definition of MINUS, Part 3 -
12-18-2008
, 02:36 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}] |
R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - DXR --> Does make
a difference when headers are brought into the equation...
Apologies..
#42
| |||
| |||
|
|
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}] |
R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - DXR --> Does make
a difference when headers are brought into the equation...
Apologies..
#43
| |||
| |||
|
|
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}] |
R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - DXR --> Does make
a difference when headers are brought into the equation...
Apologies..
#44
| |||
| |||
|
|
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}] |
R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - DXR --> Does make
a difference when headers are brought into the equation...
Apologies..
#45
| |||
| |||
|
|
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}] |
R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - DXR --> Does make
a difference when headers are brought into the equation...
Apologies..
#46
| |||
| |||
|
|
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}] |
R-D= R - (R ∩ D) = R-[(RXD) - (R ∆ D)] = R U R∆D - DXR --> Does make
a difference when headers are brought into the equation...
Apologies..
#47
| |||
| |||
|
|
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 hereis contraindicated. |
more general polynomial system), e.g.
x + y = t
x - y = s
It is a mapping of input set of variables (vector) into an output set.
To extend the analogy to view updates, we also have an input delta
vector mapped into the output delta. In this particular example, it is
easy to establish that the view update problem (that is calculating
input delta vector from output one) is well defined.
Contrast this to relational model where a view is a mapping from a set
of base relations into some output relation variable. We have two
differences
i. The algebra
ii. The number of equations, because a view is defined as a single
equation
I never understood why view update problem is scoped to a single view.
In a typical usage scenario -- database schema evolution -- a set of
base tables is substituted with a set of views, and the user can see
the whole update transaction as affecting multiple views. Therefore,
it is not unreasonable to generalize view updates to a *system* of
view equations. Why do we want to do that? Two reasons:
1. Database constraints are equations, and this generalization is a
natural way to encompass them.
2. Information preservation. This one is easier to explain by the
familiar linear system example. If there is not enough (linearly
independent) equations, then there is a fundamental ambiguity of the
inverse map that calculates input delta vector from the output.
#48
| |||
| |||
|
|
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 hereis contraindicated. |
more general polynomial system), e.g.
x + y = t
x - y = s
It is a mapping of input set of variables (vector) into an output set.
To extend the analogy to view updates, we also have an input delta
vector mapped into the output delta. In this particular example, it is
easy to establish that the view update problem (that is calculating
input delta vector from output one) is well defined.
Contrast this to relational model where a view is a mapping from a set
of base relations into some output relation variable. We have two
differences
i. The algebra
ii. The number of equations, because a view is defined as a single
equation
I never understood why view update problem is scoped to a single view.
In a typical usage scenario -- database schema evolution -- a set of
base tables is substituted with a set of views, and the user can see
the whole update transaction as affecting multiple views. Therefore,
it is not unreasonable to generalize view updates to a *system* of
view equations. Why do we want to do that? Two reasons:
1. Database constraints are equations, and this generalization is a
natural way to encompass them.
2. Information preservation. This one is easier to explain by the
familiar linear system example. If there is not enough (linearly
independent) equations, then there is a fundamental ambiguity of the
inverse map that calculates input delta vector from the output.
#49
| |||
| |||
|
|
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 hereis contraindicated. |
more general polynomial system), e.g.
x + y = t
x - y = s
It is a mapping of input set of variables (vector) into an output set.
To extend the analogy to view updates, we also have an input delta
vector mapped into the output delta. In this particular example, it is
easy to establish that the view update problem (that is calculating
input delta vector from output one) is well defined.
Contrast this to relational model where a view is a mapping from a set
of base relations into some output relation variable. We have two
differences
i. The algebra
ii. The number of equations, because a view is defined as a single
equation
I never understood why view update problem is scoped to a single view.
In a typical usage scenario -- database schema evolution -- a set of
base tables is substituted with a set of views, and the user can see
the whole update transaction as affecting multiple views. Therefore,
it is not unreasonable to generalize view updates to a *system* of
view equations. Why do we want to do that? Two reasons:
1. Database constraints are equations, and this generalization is a
natural way to encompass them.
2. Information preservation. This one is easier to explain by the
familiar linear system example. If there is not enough (linearly
independent) equations, then there is a fundamental ambiguity of the
inverse map that calculates input delta vector from the output.
#50
| |||
| |||
|
|
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 hereis contraindicated. |
more general polynomial system), e.g.
x + y = t
x - y = s
It is a mapping of input set of variables (vector) into an output set.
To extend the analogy to view updates, we also have an input delta
vector mapped into the output delta. In this particular example, it is
easy to establish that the view update problem (that is calculating
input delta vector from output one) is well defined.
Contrast this to relational model where a view is a mapping from a set
of base relations into some output relation variable. We have two
differences
i. The algebra
ii. The number of equations, because a view is defined as a single
equation
I never understood why view update problem is scoped to a single view.
In a typical usage scenario -- database schema evolution -- a set of
base tables is substituted with a set of views, and the user can see
the whole update transaction as affecting multiple views. Therefore,
it is not unreasonable to generalize view updates to a *system* of
view equations. Why do we want to do that? Two reasons:
1. Database constraints are equations, and this generalization is a
natural way to encompass them.
2. Information preservation. This one is easier to explain by the
familiar linear system example. If there is not enough (linearly
independent) equations, then there is a fundamental ambiguity of the
inverse map that calculates input delta vector from the output.
 |
« 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.