Re: database integrity

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:nmu0m2-gna.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>>>
>>> One question on my mind is the change in rules over time. Do we say:
>>>
>>> 1. Data is valid if it adheres to all existing biz rules, OR:
>>> 2. Data is valid if it adheres to rules that were in force when it was
>>> inserted or updated.
>>
>>
>> You have preempted my second question
>> in regard to data integrity.
>>
>> Q2: Is data integrity a static or a dynamic thing?
>>
>> A2: Data integrity is a dynamic, because the world is dynamic.
>> Rules change, data ages. Without some form of proactive measures
>> examining and reviewing the integrity of a database, degradation of
>> integrity may be expected to occur as change progresses.
>>
>>
>> How do ppl out there guard against loss of integrity due
>> to change? My approach has been to attempt to identify
>> and itemise the elements of change, and for each item of
>> change determine if data elements are effected, and then
>> identify exhaustively these data elements, then "correct" them.
>>
>> This is another example of why I favour the establishment
>> and use of an automated data integrity exception register.
>>
>
> If we consider a database to be a record-keeping system,

As an aside ... do you think that one may ever validly consider a database to be *more* that a record keeping system?

> then data that is
> valid when committed remains valid forever, it is a record of some
> transaction that was valid when performed.
>
> When the rules change the old data remains valid.

I am not sure that this is always correct. Change certain rules and old data may not be appropriate for the new rules.

> To change it is to alter
> (falsify is a stronger word) records.

Conversion of records to a new format because of new or changed rules may not be able to be avoided, even in the most sophisticated relational database.

I dont see this as having to do with falsification, but having alot to do with the task of monitoring and identifying issues in data integrity.

> An integrity exception register would be interesting at upgrade time.
> Upon
> the application of some new constraint, it may be useful to mgt to see
> where the constraint does not apply to older data. This _may_ provide
> insight into how the change will impact business. In fact, running an
> unapplied upgrade (doing the analsysis without applying the changes) would
> do the same thing.

I view the automation of an integrity exception register as the automation of valuable analysis. Such analyses _may_ never turn anything up, in which case, you can be certain (if you've built the thing correctly) that no integrity exceptions identified in the register currently exist in your data.

OTOH, the day after the implementation of a new constraint, it may turn up an exception, missed in the analysis, because the analyst had to leave early to go for a surf before the sun set.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Sat May 21 2005 - 08:33:21 CEST