Re: database integrity

From: x <x_at_not-exists.org>
Date: Fri, 20 May 2005 09:54:18 +0300
Message-ID: <d6k1is$jgo$1_at_domitilla.aioe.org>


"erk" <eric.kaun_at_gmail.com> wrote in message news:1116520255.494924.279810_at_g43g2000cwa.googlegroups.com...

> A DBMS can't protect the data unless it knows what constraints to
> enforce. Falsehood isn't enforceable in general, although specific
> variants might be - for example, aging could be, although it raises the
> issue of whether the fact that something was ONCE true, but no longer
> is, matters - and when it became invalid, of course.

You're right. I used the word false in the logic sense and in the general sense.
 As in wrong, innacurate.

Without integrity constraints, the contract between the DBMS and the applications cannot be enforced.
The applications may not function as designed as soon as the constraints are broken.

For example:
- if a money record is inserted multiple times in a financial application, if you do a join with that record, the aggregate functions will give wrong (unexpected) results
- if an inventory record is inserted with a non existent inventory code, the items in the inventory will behave as ghosts - if you have unmanaged redundancy in the database and ask the same query expressed in two different ways, you may obtain two different answers

If there are integrity rules that are not automatically enforced by the DBMS, one can insert valid data (true data) for the DBMS, but wrong data for the users.

The integrity of the database cannot be assured if it is updated outside of a DBMS (non subversion rule). Received on Fri May 20 2005 - 08:54:18 CEST

Original text of this message