Re: Proving an Upgrade is Possible

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 05 Jun 2005 09:52:37 -0400
Message-Id: <cqcbn2-m75.ln1@pluto.downsfam.net>

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.

>
> Ok. So you are talking about updates to the database schema.
>

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

>
> When you say "structure changes" you don't mean just changes to the
> structure, do you? You mean changes to both the database structure and
> the database constraints, right? Although below it seems you in fact
> exclude changes to the structure and only consider changes to the
> constraints.

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.

>
> Ok, so I suspect are you asking the following:
>
> "Given the old database schema and a few updates to its constraints (but
> not its structure) is it possible to algorithmically decide (or
> mathematically prove) whether all instances of the old schema are also
> instances of the new schema?"
>
> I leave it to you whether it is "algorithmically decide" or
> "mathematically prove".
>
> Am I close?
>

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@(Sec)ure(Dat)a(.com)

Received on Sun Jun 05 2005 - 08:52:37 CDT