Re: Distributed foreign keys (was Re: Category Types)
Date: Sun, 22 Jun 2003 11:09:54 -0400
Message-ID: <jvkJa.314$s57.50265177_at_mantis.golden.net>
"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:bd48bt$2ejc$1_at_gazette.almaden.ibm.com...
> "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.
I don't think a view really captures the data. The distributed key requires one to insert the value into two relations. Using a view would require one to sometimes insert a value into two relations for two of three cases and prevent one from inserting a value into two relations in the other case.
I find the asymmetry of the view approach unappealing. Received on Sun Jun 22 2003 - 17:09:54 CEST