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

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:bd7cu2$26so$1_at_gazette.almaden.ibm.com...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:bd7bdg$t7g$1_at_gazette.almaden.ibm.com...
> > "Bob Badour" <bbadour_at_golden.net> wrote in message
> > news:kFFJa.361$ez1.56242211_at_mantis.golden.net...
> [snip]
> > > > I don't like asymmety, but I don't really see any here. If we take
the
> > > closed
> > > > world assumption, anything that we don't know anything about does
not
> get
> > > > inserted into the database. A distributed foriegn key should not be
> > > limited to
> > > > the 'complete' case.
> > >
> > > Why not? What's the point of a foreign key that says a value might or
> might
> > > not reference a tuple in some relation?
>
> BTW I did not say that. All I said was that in the complete case every
value
> in the PK needs to be a value in on of the FKs as well as ever FK value
being
> a PK value. In the in-complete case, only every FK value needs to a PK
value,
> not vice-versa.

Did you not say: "In other words, we should have a shorthand for ... Every row in CALLED has *at most* one matching row in either DOES_JOB or UNEMPLOYED." ? Does the above not equate to a foreign key constraint where every value references zero or one rows in DOES_JOB or UNEMPLOYED? Does a reference to zero or one rows not amount to the same thing as saying a value might or might not reference a tuple in some relation? What am I missing?

A distributed key over DOES_JOB and UNEMPLOYED already states that every key value appears at most once in the two relations. Or are you suggesting a constraint that would allow the value to appear multiple times in DOES_JOB and UNEMPLOYED as long as no referencing value appears in CALLED? When exactly would the new constraint shorthand you are proposing prevent an update that the existing constraint shorthands would allow? Received on Mon Jun 23 2003 - 20:50:28 CEST