Re: foreign key constraint versus referential integrity constraint

On Oct 28, 8:04 pm, paul c <toledobythe..._at_oohay.ac> wrote:

> Mr. Scott wrote:
> > Constraints specify what can be true, not what is supposed to be true.

Relational dbms constraints restrict updates to valid database states. They are logically redundant. Variable predicates and (the history of) the
world fully determine valid database states.

> I thought constraints constrain, ie., limit. (I've often thought that
> isn't enough in practice, eg., I've never seen a default defined
> algebraically and beyond that I wouldn't mind a variation on constraints
> that lets me force an assertion, eg., some tuple that is always present,
> whether the user has thought to include it or not, probably CJ Date
> would disagree with that.)

1.Constraint (v union relation{t}) = v // variable v must always contain tuple t
2.You have to start the dbms with its database in a valid state. So before the user may query, the designer and/or user have to assign initial values for variables so that all constraints are met. So any values given by the designer (which might be all of them) would be
your defaults.

In oo, establishing such a valid initial state is called construction or initialization. All module-based programming languages (have to) have such a phase in a module's life.

An application is a finite state machine, ie a variable with permitted update
operators with permitted sequences of calls. You have to understand this in order to actually describe or understand how any application behaves.
More simple fundamental computing theory orthogonal to the relational model.

philip Received on Sat Oct 31 2009 - 02:11:09 CET