Re: Distributed foreign keys (was Re: Category Types)

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Wed, 25 Jun 2003 17:52:06 +0100
Message-ID: <bdck49$19vk$1_at_gazette.almaden.ibm.com>


"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0306250741.1a8bb467_at_posting.google.com...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:<bd9khq$rgg$1_at_gazette.almaden.ibm.com>...
>
> > P.S. does anyone share my dislike of the term 'Foreign Key'? to me it's a
> > misnomer
>
> Me too.
>
> Do you have an alternative term?
>
> BTW here is my crazy idea of the day :-)
>
> There is not doubt that FKs are only a shorthand for an integrity
> constraint.
>
> IMO candidate keys or keys are also a shorthand and they should not be
> obligatory.

Agreed

> All relvars have an implicit "key" which is formed by all the relation
> attributes. Therefore a key with all the relation attributes is
> redundant.

Agreed.

> The other keys are only a shorthand for an integrity constraint.

Agreed.

> E.g.
>
> var a real relation { a integer, b integer } key {a};
>
> is equivalent to:
>
> var a real relation { a integer, b integer };
> constraint count(a) = count(a{a});

It might be equivalent, but is cardinality the best primitive form? Why not use FDs.
E.g.

 var a real relation { a integer, b integer }; constraint a -> b

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Jun 25 2003 - 18:52:06 CEST

Original text of this message