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:09:05 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 82B41161174; Thu, 26 Feb 2015 07:09:05 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 734ED161186; Thu, 26 Feb 2015 07:09:05 -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 13B9B161174
for ; Thu, 26 Feb 2015 07:09:02 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 8912C1069A
for ; Thu, 26 Feb 2015 07:09:02 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 7CB8E33C90; Thu, 26 Feb 2015 07:09:02 -0500 (EST)
Date: Thu, 26 Feb 2015 07:09:02 -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: <20150226120902.GA7105-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.182.126.168 with SMTP id mz8mr8530830obb.9.1424412973765;
Thu, 19 Feb 2015 22:16:13 -0800 (PST)
X-Received: by 10.50.1.113 with SMTP id 17mr278751igl.8.1424412973677; Thu, 19
Feb 2015 22:16:13 -0800 (PST)
Path: reader1.panix.com!panix!news.linkpendium.com!news.linkpendium.com!news.glorb.com!hl2no19617434igb.0!news-out.google.com!db6ni32977igc.0!nntp.google.com!hl2no19617425igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Thu, 19 Feb 2015 22:16:12 -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: <80f34c94-e62e-4d02-8244-7e928acdf476-at-googlegroups.com>
Subject: Re: Role of functional dependencies in database design
From: compdb-at-hotmail.com
Injection-Date: Fri, 20 Feb 2015 06:16:13 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 96
Xref: panix comp.databases.theory:75563
On Thursday, February 12, 2015 at 8:02:19 AM UTC-8, Nicola wrote:
> So, the question is: what is the role of FDs (and possibly other types of=
dependencies) in database design?
We determine predicates that describe application situations. Basic predica=
tes correspond to base tables. A FD holds when a certain constraint predica=
te built from a table predicate holds. (A JD corresponds to being able to w=
rite a table predicate as a conjunction of others. A FD corresponds to a ce=
rtain JD.)
> In general, I don't think that it is possible for them to inform the desi=
gn activity since the early stages or that they should be used as the main =
design tool.
As soon as you have a predicate you can determine FDs.
> > Erwin wrote:
> >There you have it. When people tell you "there can only be one can=20
> >opener on any given desert island", then what do you see ?
> >
> >A table {desert island, can opener} with (a.o.) a key "desert island",=
=20
> >or
> >A relation schema of whatever set of attributes in which you must add=20
> >the FD desert island -> can opener ? Where this then tells you "the=20
> >identity of a desert island is a determinant factor to the identity of=
=20
> >the can opener that is on it" or "the relation over {desert island, can=
=20
> >opener} is a function from desert island to can opener" ?
You don't need keys or entities, you just need predicates and determinants.
"If desert island I has opener Oa and desert island I has opener Ob then Oa=
=3D Ob."
Ergo I -> O in "desert island I has opener O".
> At an early stage, you probably cannot say: it might also be that desert =
island and can opener should be represented as two relation schemas (for w=
hich we have identified no attributes yet) related through a one-one or one=
-many relationship. My point here is simply that FDs are not invented, they=
are discovered.
First *say something* then you can find the FDs. There is no "one-one or o=
ne-many relationship" until then. First comes *a particular* relationship i=
e predicate then come parameters/attributes and then arities and other cons=
traints.
> >> FDs are a special type of first-order formulas. I can imagine defining=
an English-like syntax for them.
>=20
> (Not that it would necessarily be a good idea, I should add.)
>=20
> >Hmmmmmmmm.
FD F1,... -> T holds in predicate R(F1,...,T,...) when (for all situations)=
:
FORALL F1,...,Ta,...,Tb,...
R(F1,...,Ta,...) AND R(F1,...,Tb,...)
=3D> Ta =3D Tb
Notice that the determinant variables are unchanged between atoms, that the=
re are two determined variables for one value, and that the other variables=
are don't-cares.
We can describe this pattern. Eg an FD holds "when each satisfying determin=
ant subtuple has just one determined value". But all we have to do is *use*=
it with each predicate.
> 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) =3D> R1 <> R2
> (this is absolutely off the top of my head: don't take it as a serious at=
tempt).
No FD.
For "then it was the same room", T -> R. For "then it was the same lecturer=
", T -> L.
> >And besides, avoiding redundancy was only a relevant topic in database=
=20
> >design as long as there were no feasible ways to control the=20
> >redundancies, e.g. via ASSERTIONs. Those days are gone.
But predicates, queries and updates are simpler in 5NF, ie when the only JD=
s are implied by the CKs.
philip
-- end of forwarded message --
----- End forwarded message -----
|
|
