MESSAGE
| DATE | 2015-02-26 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] [mrbrklyn@panix.com: (fwd) Re: Role of functional dependencies in
|
From owner-learn-outgoing-at-mrbrklyn.com Thu Feb 26 07:10:24 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 9F9FB161174; Thu, 26 Feb 2015 07:10:24 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 92FC2161186; Thu, 26 Feb 2015 07:10:24 -0500 (EST)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id A70CD161174
for ; Thu, 26 Feb 2015 07:10:23 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 826D610811
for ; Thu, 26 Feb 2015 07:10:23 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 7CFC533C79; Thu, 26 Feb 2015 07:10:23 -0500 (EST)
Date: Thu, 26 Feb 2015 07:10:23 -0500
From: Ruben Safir
To: learn-at-nylxs.com
Subject: [LIU Comp Sci] [mrbrklyn-at-panix.com: (fwd) Re: Role of functional dependencies in
database design]
Message-ID: <20150226121023.GD7105-at-panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
----- Forwarded message from Ruben Safir -----
Date: Thu, 26 Feb 2015 07:08:29 -0500 (EST)
From: Ruben Safir
To: mrbrklyn-at-panix.com
Subject: (fwd) Re: Role of functional dependencies in database design
User-Agent: tin/2.2.1-20140504 ("Tober an Righ") (UNIX) (NetBSD/6.1.5 (i386))
-- forwarded message --
X-Received: by 10.236.11.193 with SMTP id 41mr8795080yhx.53.1424424172307;
Fri, 20 Feb 2015 01:22:52 -0800 (PST)
X-Received: by 10.140.28.11 with SMTP id 11mr170251qgy.21.1424424172287; Fri,
20 Feb 2015 01:22:52 -0800 (PST)
Path: reader1.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!ottix-news.ottix.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!j7no1842033qaq.1!news-out.google.com!n6ni12qar.0!nntp.google.com!i13no2515482qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Fri, 20 Feb 2015 01:22:52 -0800 (PST)
In-Reply-To:
Complaints-To: groups-abuse-at-google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=212.123.30.210;
posting-account=-nQufgoAAABsreOCZNqo2Uyh8O-fYVPT
NNTP-Posting-Host: 212.123.30.210
References:
<80f34c94-e62e-4d02-8244-7e928acdf476-at-googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <64b9cd98-8a5e-4f95-a805-a8ab8c80ed70-at-googlegroups.com>
Subject: Re: Role of functional dependencies in database design
From: Erwin
Injection-Date: Fri, 20 Feb 2015 09:22:52 +0000
Content-Type: text/plain; charset=ISO-8859-1
Lines: 56
Xref: panix comp.databases.theory:75566
Op vrijdag 20 februari 2015 10:08:58 UTC+1 schreef Nicola:
> In article <>,
> pk 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
>
> --- news://freenews.netfront.net/ - complaints: ---
Well, even if you can manage to get that formalism fully specced (a tall order imo), the main problem will still remain that if you apply that formalism to any given input, the output produced will only be as reliable as the input it is applied to.
Which is by the way illustrated perfectly by the example used : I carelessly overlooked the possibility of L1=L2, thus neglected to explicitly specify L1<>L2 as a premisse (tacitly assuming it would be tacitly understood), and the rest is history ...
-- end of forwarded message --
----- End forwarded message -----
|
|
