MESSAGE
| DATE | 2015-02-26 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] [mrbrklyn@panix.com: (fwd) Role of functional dependencies in
|
From owner-learn-outgoing-at-mrbrklyn.com Thu Feb 26 07:10:52 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id E2616161174; Thu, 26 Feb 2015 07:10:51 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id CDB3C161186; Thu, 26 Feb 2015 07:10:51 -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 52001161174
for ; Thu, 26 Feb 2015 07:10:51 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 2A70110901
for ; Thu, 26 Feb 2015 07:10:51 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 2279833C79; Thu, 26 Feb 2015 07:10:51 -0500 (EST)
Date: Thu, 26 Feb 2015 07:10:51 -0500
From: Ruben Safir
To: learn-at-nylxs.com
Subject: [LIU Comp Sci] [mrbrklyn-at-panix.com: (fwd) Role of functional dependencies in
database design]
Message-ID: <20150226121051.GG7105-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) 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!goblin3!goblin.stu.neva.ru!news.netfront.net!nvitacolonna
From: Nicola
Newsgroups: comp.databases.theory
Subject: Role of functional dependencies in database design
Date: Thu, 12 Feb 2015 17:02:14 +0100
Organization: ---
Lines: 74
Message-ID:
NNTP-Posting-Host: 158.110.144.157
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Trace: adenine.netfront.net 1423756936 48464 158.110.144.157 (12 Feb 2015 16:02:16 GMT)
X-Complaints-To: news-at-netfront.net
NNTP-Posting-Date: Thu, 12 Feb 2015 16:02:16 +0000 (UTC)
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Xref: panix comp.databases.theory:75523
I hope you won't mind if I start a new thread for the subject. The other
thread has got quite long and somewhat off-topic.
So, the question is: what is the role of FDs (and possibly other types
of dependencies) in database design? My personal take:
In general, I don't think that it is possible for them to inform the
design activity since the early stages or that they should be used as
the main design tool. I do think, however, that when a system is
understood sufficiently well (e.g., by means of a conceptual design),
they offer an aid (are my schemas well-designed according to certain
criteria?) and insight (allowing us to possibly find alternative ways to
design a database, for example).
>> Nicola wrote:
>> FDs do not come out of void, they follow from your requirements. They
>> are just a formal version of a very special (and relatively simple)
>> type
>> of requirement. I don't arbitrarily decide to assume that {desert
>> island} -> {can opener}, unless you tell me that there cannot be two
>> can
>> openers in the same desert island, in the world of desert islands you
>> are interested in.
> Erwin wrote:
>There you have it. When people tell you "there can only be one can
>opener on any given desert island", then what do you see ?
>
>A table {desert island, can opener} with (a.o.) a key "desert island",
>or
>A relation schema of whatever set of attributes in which you must add
>the FD desert island -> can opener ? Where this then tells you "the
>identity of a desert island is a determinant factor to the identity of
>the can opener that is on it" or "the relation over {desert island, can
>opener} is a function from desert island to can opener" ?
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
which 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.
>> 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
(this is absolutely off the top of my head: don't take it as a serious
attempt).
>And besides, avoiding redundancy was only a relevant topic in database
>design as long as there were no feasible ways to control the
>redundancies, e.g. via ASSERTIONs. Those days are gone.
Could you provide a small example?
Nicola
--- news://freenews.netfront.net/ - complaints: news-at-netfront.net ---
-- end of forwarded message --
----- End forwarded message -----
|
|
