Re: Proving an Upgrade is Possible

Jan Hidders wrote:

> Kenneth Downs wrote:

>> If you have a data dictionary containing the meta data that describes the
>> database, an upgrade = a change to the data dicitonary.  So just as a
>> user transaction changes the state of a database, an upgrade changes the
>> meta data, or the meta state.

>> My goal is to always know completely whether all structure changes to a
>> db are valid.

The example considers only a constraint, to keep it simple. The OP states structure and constraints. Also included in my systems are automated columns and tables, so they must be included alos.

>

>> Here is a case of where you can prove an upgrade will fail, or at least
>> you
>> cannot prove it will succeed.  If the WIDGETS table currently has a
>> unique constraint on COL_A, COL_B, and COL_C, we know that an upgrade (or
>> any change to the database) can fail if the new version has the unique
>> constraint only on COL_A and COL_B.  While it may succeed in some cases,
>> it will fail in others.

You are on target, except that constraints are included, and also automation (columns like price_extended = price * qty). So while we are at it, this means things like NULL/NOT NULL rules, DEFAULT values and so forth.

Another way to state the question is: "What structure of meta-data allows us to specify completely a database of arbitrary complexity and also allows us to demonstrate by analysis that any given change in the meta data is valid or not valid".

Methinks the structure of the meta-data would reduce the truth to a data validity issue (an invalid transform would fail a validitity check in the meta data), which is closer to an algorithm than to a mathematical proof. Yet, I have the strong intuitive sense that a before-hand mathematical proof could lead to the table structure.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)