Mr. Scott wrote:
....
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.)

paul c wrote:

I cannot make sense of what you wrote. I suspect you have omitted much
context, internal dialogue and assumptions.

Bob Badour wrote:
I usually try to omit at least two out of three of those, otherwise even
I can't guess what I'm talking about! Being of a minimalist persuasion,
not wanting more concepts than I can handle, I think I'd rather have
constraints, unlike CJ Date's, that are applied against values without
requiring them to be 'truth-valued' and 'and-ed' if you will. I don't
have a good name for this.

"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

A proposition either can be true or can't be true. Specifying what can be
true also specifies what can't; likewise, specifying what can't be true also
specifies what can.

"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote

There is nothing mystical here. Constraints specify what can and cannot be
assigned a positive truth value, they do not specify what has been assigned
a positive truth value. Queries manipulate what has been assigned a
positive truth value or what can be derived from what has been assigned a
positive truth value.

paul c wrote:

If not truth-valued, what would they be? Either something passes the
constraint or it doesn't.

Bob Badour wrote:
Sorry, I've forgotten what I was driving at, I was remembering some
notes I made months ago but can't find them right now. I'm sure the
notions will come back to me in a day or two. (Natch', I'm also sure you
aren't holding your breath!)

On Oct 28, 8:04*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

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.

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

Mr. Scott wrote:

Formally: a database instance is a set of named relations,
i.e. a mapping from names to relations.
A database is a set of possible database instances, such that
each instance maps the same names to relations with, per name, the same signature.
It is defined by a database schema (which maps each relation name to its signature)
and database constraints (which limit the possible combinations of relations
to which the names are mapped). (I can go on and define 'signature', etc.)
A database constraint is a predicate on database instances.

A 'table' (in this context) is a named relation in a database instance,
or perhaps a database restricted to that name (i.e. a relation name mapped to
the set of all possible values for that relation).

A 'view' (in this context) is a named mapping from database instances to relations.

--
Reinier

"Reinier Post" <rp (AT) raampje (DOT) lan> wrote

I really don't get what you're driving at. I also don't fully agree with
your characterization. What's the point you're trying to make?