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:17 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id BABA2161174; Thu, 26 Feb 2015 07:11:17 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id AB74B161186; Thu, 26 Feb 2015 07:11:17 -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 2D8EE161174
for ; Thu, 26 Feb 2015 07:11:17 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 2173810A08
for ; Thu, 26 Feb 2015 07:11:17 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 1882433C79; Thu, 26 Feb 2015 07:11:17 -0500 (EST)
Date: Thu, 26 Feb 2015 07:11:17 -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: <20150226121117.GK7105-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 --
X-Received: by 10.66.196.11 with SMTP id ii11mr6016306pac.37.1423779068058;
Thu, 12 Feb 2015 14:11:08 -0800 (PST)
X-Received: by 10.140.21.146 with SMTP id 18mr95640qgl.30.1423779067797; Thu,
12 Feb 2015 14:11:07 -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!hl2no10774377igb.0!news-out.google.com!c1ni4qar.1!nntp.google.com!i13no854996qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Thu, 12 Feb 2015 14:11:07 -0800 (PST)
In-Reply-To:
Complaints-To: groups-abuse-at-google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=213.219.142.118;
posting-account=-nQufgoAAABsreOCZNqo2Uyh8O-fYVPT
NNTP-Posting-Host: 213.219.142.118
References:
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <76a7403c-cea0-43bd-9af0-3bfd89226661-at-googlegroups.com>
Subject: Re: Role of functional dependencies in database design
From: Erwin
Injection-Date: Thu, 12 Feb 2015 22:11:07 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 99
Xref: panix comp.databases.theory:75528
Op donderdag 12 februari 2015 22:43:24 UTC+1 schreef Nicola:
> In article <>,
> Erwin <> wrote:
>=20
> > My question, and what I would like to understand is : what exactly is t=
he=20
> > available input (its semantics and in which possible syntactic forms do=
es it=20
> > appear, and where) that allows this "discovery" to be made ? I think J=
KL's=20
> > post where he used the word "pesky" expressed the very same concern.
>=20
> Formally, FDs are axioms. As such, *within* the formal system they are=20
> given facts, but the discovery must happen *outside* the formal system.=
=20
> Hence, the available input cannot be described formally (or, if it can,=
=20
> it will be in a different formal system that will have its own axioms).
>=20
> You don't have any difficulty with the process of "discovering" keys, do=
=20
> you? I don't see the process of "discovering" other constraints as=20
> intrinsically different.
> =20
> > >=20
> > > >> FDs are a special type of first-order formulas. I can imagine >>=
=20
> > > defining=20
> > > >> an English-like syntax for them.
> > >=20
> > > (Not that it would necessarily be a good idea, I should add.)
> > >=20
> > > >Hmmmmmmmm.
> > > >
> > > >"The projection on {desert island, can opener} of the join of all=20
> > > >tables in the database, represents a function from desert island to =
can=20
> > > >opener."
> > >=20
> > > Well no, like this certainly no :) Maybe something along these lines=
=20
> > > (paraphrasing the given-when-then constructs existing in some testing=
=20
> > > tools):
> > >=20
> > > 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
> >=20
> > Well, there you have it. If you think that this sentence indicates an =
FD=20
> > {L,T} -> {room}
>=20
> Of course not.
>=20
> > The correct conclusion here is the FD {room,T} -> {L}.
>=20
> Yes.
>=20
> > But before spotting=20
> > that, I first had to twist the requirement into "only one lecturer can =
be in=20
> > any given room at any time". Or "if two observations of a lecturer bei=
ng in=20
> > a room at time T, both involve the same room and the same time T, then =
they=20
> > involve the same lecturer". But (knowing what the FD turned out to be =
and=20
> > looking back on the natural language formulation) I find those alternat=
ives=20
> > only slightly less convoluted than your original.
>=20
> I said not to take this example too seriously ;) The point of a=20
> hypothetical specification in natural language is that you should not=20
> bother with the mathematical formulation of the corresponding FD,=20
> because the system would take care of it. My example may fail miserably=
=20
> in being higher level compared to the corresponding FD, but that does=20
> not mean much. If you had a program that takes as input the sentence "no=
=20
> two teachers can teach in the same room at the same time" and outputs=20
> the schema Teaches(room, time, teacher) with key {room, time} as=20
> output, would you be satisfied? :)
>=20
> Nicola
>=20
> --- news://freenews.netfront.net/ - complaints: ---
I probably would.
For what it's worth : "no two teachers can ..." immediately makes me think =
of a certain RENAME/JOIN combination that then in turn immediately makes me=
conclude "aha, a key".
But my mental process in that regard is probably heavily influenced by the =
work I've done on constraint enforcement. Give me a database [design] and =
I immediately start looking for all possible [data] faults (and their defin=
ing relational expressions). But somehow for keys, that's not the process =
I follow. I just wonder "what makes this thing unique". It's probably jus=
t too deeply instilled, but it works without FDs.
-- end of forwarded message --
----- End forwarded message -----
|
|
