Re: Role of functional dependencies in database design

From: Nicola <nvitacolonna_at_gmail.com>
Date: Fri, 20 Feb 2015 10:08:54 +0100
Message-ID: <nvitacolonna-1B39DE.10085320022015_at_freenews.netfront.net>


In article <80f34c94-e62e-4d02-8244-7e928acdf476_at_googlegroups.com>,  compdb_at_hotmail.com wrote:

> > given two lecturers L1 and L2 and a time T
> > when L1 is teaching at time T and L2 is teaching at time T
> > then L1 and L2 are in different rooms
>
> FORALL L1,L2,T,R1,R2
> teaches(L1,T,R1) AND teaches(L2,T,R2) => R1 <> R2

I think that it should be:

 FORALL L1,L2,T,R1,R2
    L1 <> L2 AND teaches(L1,T,R1) AND teaches(L2,T,R2) => R1 <> R2  

> > (this is absolutely off the top of my head: don't take it as a serious
> > attempt).
>
> No FD.

Correct. The FD is implied, though:

Let X be L1 <> L2
Let Y be teaches(L1,T,R1) AND teaches(L2,T,R2) Let Z be R1 <> R2

Then the sentence above is the universal closure of

X AND Y -> Z, If my coffee has worked as it should, the latter is equivalent to

(NOT Z) AND Y -> NOT X, that is,

R1 = R2 AND teaches(L1,T,R1) AND teaches(L2,T,R2) -> L1 = L2,

or, simplifying,

teaches(L1,T,R) AND teaches(L2,T,R) -> L1 = L2.

The idea behind my example is that a hypothetical formalism based on natural language might allow the user to write specifications that are not a direct translation of the logical definition of a FD, but from which the system might *infer* a FD, giving the user more freedom in the way constraints may be expressed. But again, I haven't really thought about it too much.  

Nicola

Received on Fri Feb 20 2015 - 10:08:54 CET

Original text of this message