Re: a union is always a join!
Date: Thu, 5 Mar 2009 19:40:50 -0500
"Walter Mitty" <wamitty_at_verizon.net> wrote in message
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
>>> that states what is happening. Whenever nothing is happening, what has
>>> been the case /is/ the case. For example, if Joe has been second in
> Let's look at "whenever nothing is happening" in more detail. I submit
> that, at a point in time where there are no transactions in progress, that
> "nothing is happening". Further, I submit that, if serializability is the
> criterion for concurrency management, then the DBMS ensures that the view
> of the database is as if "nothing is happening", during a transaction,
> except for the actions of that transaction. Every other transaction can
> be seen as being completed "in the past" or beginning "in the future".
> So, if the transactions can be serialized, each transaction sees the
> database as if "nothing is happening". If you agree with all that, then
> why isn't your point moot? If you don't agree, where don't you agree?
My point has little if anything at all to do with transactions and concurrency control. Those belong to implementations. My point is that relational calculus, or any equivalent mechanism such as relational algebra, while necessary for describing database updates, is not sufficient for that purpose because it can only apply to a single database, not two successive databases. The mechanism of updating the database cannot be reduced to mere algebraic expressions, but instead to asserting, in the context of what has been the case, just what in the world is different and exactly how. Let me explain.
The set of all state constraints, such as join dependencies and inclusion dependencies, determines the set of all possible databases. Databases are simply assertions that state just what things have been in the world and exactly how those things relate to each other. Obviously, only one of those assertions at a time can be assigned a positive truth value under an interpretation. The [current] database is that one member that has been assigned a positive truth value; the database is that one assertion that states what has been the case. In the same way that databases are simply assertions, transitions are simply assertions that state, in the context of what has been the case, just what in the world is different and exactly how. The set of all transition constraints describes the subset of possible databases that are accessible from an arbitrary database. But more importantly, when applied to the current database, it describes which combinations of changes to what has been in the world are acceptable. For example, a traffic light can only change from red to green, from green to yellow, or from yellow to red; therefore, a change from green to red would not be acceptable. If the traffic light has been green, no possible database in which the traffic light is red would be accessible.
Given the assertion that states what has been the case (the database) and an assertion that states just what in the world is different and exactly how (a transition), the statement of what is the case can be calculated by eliminating all instances of expressions that are true in all interpretations from the logical sum of those two assertions. The result states what is the case and therefore becomes the statement of what has been the case (the database) until the next update.
I suppose that by now you're asking, why does this matter? Because <OR> is just an operator of a relational algebra. The application of <OR> that Paul referred to is a gross oversimplification of what actually has to occur during a database update. While disjunction is a necessary part of the calculation of what is the case, the remaining step of eliminating expressions that are true in all interpretations cannot be ignored. It should be easy to see that whenever there is a "DELETE," there will be expressions like (p \/ ~p) in the logical sum of the two assertions. These are redundant because they are a consequence of just the logic, and as a result they do not convey information. Received on Fri Mar 06 2009 - 01:40:50 CET