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

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:vzIIa.5$yt4.164_at_news.oracle.com...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:bcukop$29r4$1_at_gazette.almaden.ibm.com...
> > Thanks. Now make that a monthly payment to me, so making my annual Salary
> $0,
> > which (it could be argued) is different than not having a salary at all.
> >
> > On the other hand, if you constrain all payments to be greater than $0,
> then a
> > Salary of $0 could be defined as being equivalent to not having a salary,
> but
> > then why have two ways of representing the same thing?
>
> You introduced monthly payments, which lowers the level of "annual salary"
> abstraction. Then, "annual salary" is an aggregate sum of monthly payments,
> and NOT_SALARIED relation is just a view
>
> select name from EMP
> minus
> select recipient as name from PAYCHECKS
> group by recipient
>
> One, or the other way NOT_SALARIED is redundant!

Only if you assume that every Person either has a know salary, has an unknown salary or is unsalaried. If there is another possibility, say 'not-known-if-salaried-or-not', then NOT_SALARIED is required.

Having said that, Hugh does have such a constraint in his example:

  Every row in CALLED has a matching row in either EARNS, SALARY_UNK and UNSALARIED.
Which does then mean that either SALARY_UNK or UNSALARIED could be a view over the other two tables. It could be argued that a database that did not make one of those two a view would be more redundant than one that did.

In the case at hand, I would suggest dropping the SALARY_UNK and JOB_UNK tables. We would then want any shorthands for distributed keys and distributed foreign keys to cater for 'complete' and 'incomplete' cases.

Agree?

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Sat Jun 21 2003 - 19:27:23 CEST