Re: database integrity

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:t9mul2-gpp.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>> Q1: What is database integrity?
>>
>> A1: A measure of the self-referential consistency of all
>> the relations existent between the physical data elements
>> defined in the schema of a database.
>>
>> Any disagreements, improvements, comments?
>>
>
> Two big areas:
>
> 1) Free from corruption

Yes, this is like an external attribute of the database file (or perhaps its backup file). Here the (R)DBMS software prepares and passes a file to the OS, and the OS to the HW.

> 2) It is valid, or more verbosely, adheres to validity rules

This is the internal perspective.
Within the (R)DBMS software itself.

> Item 1 is pretty simple, it means only that the disk drive didn't fail, or
> the magtape didn't get folded, or the punched card didn't get bent.
> Corruption is one way that data can become invalid.
>
> That leaves Item 2, which we expand by determining the allowable kinds of
> validity rules. The basics are domain integrity, entity integrity and
> referential integrity. Practically speaking I have found it necessary to
> add only comparative constraints between a columns.
>
> 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.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Fri May 20 2005 - 09:25:43 CEST