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:23 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 3EC78161174; Thu, 26 Feb 2015 07:11:23 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 324C0161186; Thu, 26 Feb 2015 07:11:23 -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 AEC27161174
for ; Thu, 26 Feb 2015 07:11:22 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 875C910A21
for ; Thu, 26 Feb 2015 07:11:22 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 7BACD33C79; Thu, 26 Feb 2015 07:11:22 -0500 (EST)
Date: Thu, 26 Feb 2015 07:11:22 -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: <20150226121122.GL7105-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.236.41.73 with SMTP id g49mr3546893yhb.57.1424418161027;
Thu, 19 Feb 2015 23:42:41 -0800 (PST)
X-Received: by 10.50.1.113 with SMTP id 17mr282774igl.8.1424418160891; Thu, 19
Feb 2015 23:42:40 -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!j7no1827585qaq.1!news-out.google.com!qk8ni37643igc.0!nntp.google.com!hl2no13372894igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Thu, 19 Feb 2015 23:42:40 -0800 (PST)
In-Reply-To:
Complaints-To: groups-abuse-at-google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=24.68.153.253;
posting-account=FUDi7AoAAACOn42BTSjw9ZlWNiwGl2Nx
NNTP-Posting-Host: 24.68.153.253
References:
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID:
Subject: Re: Role of functional dependencies in database design
From: compdb-at-hotmail.com
Injection-Date: Fri, 20 Feb 2015 07:42:40 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 87
Xref: panix comp.databases.theory:75564
On Thursday, February 12, 2015 at 1:43:24 PM UTC-8, Nicola wrote:
> 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).
Each base table holds rows that make a corresponding designer-chosen predic=
ate true of the current application situation. A user evaluates the predica=
te for every row that could fit in a table and puts the ones making true pr=
opositions in. They look at the tables and plug the present and absent rows=
into its predicate to learn how the world is. They query by mapping a pred=
icate about the application situation to a hybrid relation/predicate expres=
sion that the DBMS evaluates to the rows making the predicate true.
A designer shows that particular predicates built from these base predicate=
s are true in every application situation that can arise. These are the con=
straints. A constraint is simultaneously a truth about each database state =
and its corresponding application situation. So the designer describes the =
application but this simultaneously describes table values.
> > > >> FDs are a special type of first-order formulas.
From: com...
> F1,... -> T
> FORALL F1,...,Ta,...,Tb,...
> R(F1,...,Ta,...) AND R(F1,...,Tb,...)
> =3D> Ta =3D Tb
> > > 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
From: com...
> FORALL L1,L2,T,R1,R2
> teaches(L1,T,R1) AND teaches(L2,T,R2) =3D> L1 <> L2
> > 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.
No. That FD is:
FORALL L1,L2,T,R
teaches(L1,T,R) AND teaches(L2,T,R) =3D> L1 =3D L2
> > 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.
It's not the same as the original constraint. Which isn't an FD. (Not surpr=
ising.)
But the natural language for an FD is not hard:
// {room,T} -> {L}
Given lecturers L1 and L2 and time T and room R,
if L1 teaches at T in R and L2 teaches at T in R
then L1 =3D L2
philip
-- end of forwarded message --
----- End forwarded message -----
|
|
