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:07 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 899B8161174; Thu, 26 Feb 2015 07:11:07 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 7A900161186; Thu, 26 Feb 2015 07:11:07 -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 EE7A0161174
for ; Thu, 26 Feb 2015 07:11:06 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id CB925109B2
for ; Thu, 26 Feb 2015 07:11:06 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id BE30633C79; Thu, 26 Feb 2015 07:11:06 -0500 (EST)
Date: Thu, 26 Feb 2015 07:11:06 -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: <20150226121106.GI7105-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.50.29.6 with SMTP id f6mr4383098igh.2.1423767497936;
Thu, 12 Feb 2015 10:58:17 -0800 (PST)
X-Received: by 10.140.40.242 with SMTP id x105mr74619qgx.14.1423767497801;
Thu, 12 Feb 2015 10:58:17 -0800 (PST)
Path: reader1.panix.com!panix!usenet.stanford.edu!hl2no15102169igb.0!news-out.google.com!n6ni6qar.0!nntp.google.com!j7no145566qaq.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Thu, 12 Feb 2015 10:58:17 -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:
Subject: Re: Role of functional dependencies in database design
From: Erwin
Injection-Date: Thu, 12 Feb 2015 18:58:17 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 145
Xref: panix comp.databases.theory:75524
Op donderdag 12 februari 2015 17:02:19 UTC+1 schreef Nicola:
> I hope you won't mind if I start a new thread for the subject. The other=
=20
> thread has got quite long and somewhat off-topic.
>=20
> So, the question is: what is the role of FDs (and possibly other types=20
> of dependencies) in database design? My personal take:
>=20
> In general, I don't think that it is possible for them to inform the=20
> design activity since the early stages or that they should be used as=20
> the main design tool. I do think, however, that when a system is=20
> understood sufficiently well (e.g., by means of a conceptual design),=20
> they offer an aid (are my schemas well-designed according to certain=20
> criteria?) and insight (allowing us to possibly find alternative ways to=
=20
> design a database, for example).
The problem is that formally speaking, you must first have that conceptual =
design (entities+relships) translated into a logical one (relvars). Only a=
fter that can you start thinking about FDs and normalization, and it requir=
es that you somehow derived the FDs from, well what else other than the con=
ceptual schema you have, perhaps incremented with a pack of tacit understan=
dings of what it represents.
And what in a conceptual schema is it that you can get the FDs from ? NOT =
from any key specifications that are already there, because if you already =
have them, it's pointless deriving FDs from them only to find out that norm=
alization theory gives you exactly the keys you started off with.
The normalization procedure/process as rooted in normalization theory, assu=
mes a bottom-up methodology. First assume the database is a single giganti=
c table, then start decomposing. The trouble is that most people intuitive=
ly prefer top-down, in practice they also do it, and I have certainly known=
a time when they got things close to 99% right without any application of =
any kind of normalization theory.
>=20
> >> Nicola wrote:=20
> >> FDs do not come out of void, they follow from your requirements. They=
=20
> >> are just a formal version of a very special (and relatively simple)=20
> >> type=20
> >> of requirement. I don't arbitrarily decide to assume that {desert=20
> >> island} -> {can opener}, unless you tell me that there cannot be two=
=20
> >> can=20
> >> openers in the same desert island, in the world of desert islands you=
=20
> >> are interested in.
>=20
> > 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" ?
>=20
> At an early stage, you probably cannot say: it might also be that desert=
=20
> island and can opener should be represented as two relation schemas (for=
=20
> which we have identified no attributes yet) related through a one-one or=
=20
> one-many relationship. My point here is simply that FDs are not=20
> invented, they are discovered.
My question, and what I would like to understand is : what exactly is the a=
vailable 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.
>=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
Well, there you have it. If you think that this sentence indicates an FD {=
L,T} -> {room}, then you are wrong ! This statement per se does not prohib=
it the same lecturer being in two distinct rooms at the same time. (Physic=
s does, perhaps, but that really is another issue. My issue is correct log=
ical inferences from given requirements as stated.)
The correct conclusion here is the FD {room,T} -> {L}. 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 bein=
g 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 b=
e and looking back on the natural language formulation) I find those altern=
atives only slightly less convoluted than your original.
(Your example being "temporal" is very tempting to go drifting off into the=
temporal arena. In fact, the temporal proposals by Darwen/Date/Lorentzos =
talk about keys almost all the time, but normalization theory isn't mention=
ed even once. My feeling is the current normalization theory is insufficie=
nt to underpin their approach soundly, and although I very much like their =
approach altogether, I'm amazed I never see any complaint about this.)
(...leaving the ASSERTIONs example for another post)
>=20
> (this is absolutely off the top of my head: don't take it as a serious=20
> attempt).
>=20
> >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.
>=20
> Could you provide a small example?
>=20
> Nicola
>=20
> --- news://freenews.netfront.net/ - complaints: ---
-- end of forwarded message --
----- End forwarded message -----
|
|
