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:11:12 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id C1441161174; Thu, 26 Feb 2015 07:11:12 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id B20FB161186; Thu, 26 Feb 2015 07:11:12 -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 2D1C9161174
for ; Thu, 26 Feb 2015 07:11:12 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 003AC109D8
for ; Thu, 26 Feb 2015 07:11:11 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id ED09033C79; Thu, 26 Feb 2015 07:11:11 -0500 (EST)
Date: Thu, 26 Feb 2015 07:11:11 -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: <20150226121111.GJ7105-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:28 -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 --
Path: reader1.panix.com!panix!goblin2!goblin.stu.neva.ru!newsgate.cuhk.edu.hk!news.netfront.net!nvitacolonna
From: Nicola
Newsgroups: comp.databases.theory
Subject: Re: Role of functional dependencies in database design
Date: Thu, 12 Feb 2015 22:43:20 +0100
Organization: ---
Lines: 68
Message-ID:
References:
NNTP-Posting-Host: 151.49.175.176
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Trace: adenine.netfront.net 1423777402 54438 151.49.175.176 (12 Feb 2015 21:43:22 GMT)
X-Complaints-To: news-at-netfront.net
NNTP-Posting-Date: Thu, 12 Feb 2015 21:43:22 +0000 (UTC)
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Xref: panix comp.databases.theory:75527
In article ,
Erwin wrote:
> My question, and what I would like to understand is : what exactly is the
> available input (its semantics and in which possible syntactic forms does it
> appear, and where) that allows this "discovery" to be made ? I think JKL's
> post where he used the word "pesky" expressed the very same concern.
Formally, FDs are axioms. As such, *within* the formal system they are
given facts, but the discovery must happen *outside* the formal system.
Hence, the available input cannot be described formally (or, if it can,
it will be in a different formal system that will have its own axioms).
You don't have any difficulty with the process of "discovering" keys, do
you? I don't see the process of "discovering" other constraints as
intrinsically different.
> >
> > >> FDs are a special type of first-order formulas. I can imagine >>
> > defining
> > >> an English-like syntax for them.
> >
> > (Not that it would necessarily be a good idea, I should add.)
> >
> > >Hmmmmmmmm.
> > >
> > >"The projection on {desert island, can opener} of the join of all
> > >tables in the database, represents a function from desert island to can
> > >opener."
> >
> > Well no, like this certainly no :) Maybe something along these lines
> > (paraphrasing the given-when-then constructs existing in some testing
> > tools):
> >
> > 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
>
> Well, there you have it. If you think that this sentence indicates an FD
> {L,T} -> {room}
Of course not.
> The correct conclusion here is the FD {room,T} -> {L}.
Yes.
> But before spotting
> that, I first had to twist the requirement into "only one lecturer can be in
> any given room at any time". Or "if two observations of a lecturer being in
> a room at time T, both involve the same room and the same time T, then they
> involve the same lecturer". But (knowing what the FD turned out to be and
> looking back on the natural language formulation) I find those alternatives
> only slightly less convoluted than your original.
I said not to take this example too seriously ;) The point of a
hypothetical specification in natural language is that you should not
bother with the mathematical formulation of the corresponding FD,
because the system would take care of it. My example may fail miserably
in being higher level compared to the corresponding FD, but that does
not mean much. If you had a program that takes as input the sentence "no
two teachers can teach in the same room at the same time" and outputs
the schema Teaches(room, time, teacher) with key {room, time} as
output, would you be satisfied? :)
Nicola
--- news://freenews.netfront.net/ - complaints: news-at-netfront.net ---
-- end of forwarded message --
----- End forwarded message -----
|
|
