| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: database integrity
mountain man wrote:
> "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,
Well, if you are asking me, no. There is a thread from a few days "Modelling considered harmful" where I tried to spin out the position that because they "mere" record keeping systems, we should not dress them up by describing them as "models" of reality.
>
>
>> 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.
If the fact was true when committed, a change in rules cannot falsify it. If I bought a widget with no VAT before VAT existed, then VAT comes into play, the record of my prior purchase must be valid.
Can you offer a counter-example?
>
>> To change it is to alter >> (falsify is a stronger word) records.
Conversion to a new format has nothing to do with the rules.
>
> 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.
Hmmmm. In a prior life I built a system that checked for constraints before they were applied, to detect failures. This was necessary because of the assumption that a change in constraints would apply to old data.
It was in doing this that it occurred to me that constraints developed over time should most likely apply only to data moving forward. The exception was a bug fix where you wanted to fix bad data, leading to the conclusion that both options should be supported.
Now the real trick question is, how do you build constraints that apply only to new data?
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth@(Sec)ure(Dat)a(.com)Received on Mon May 23 2005 - 20:23:53 CDT
 |
 |