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:10:44 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id F09BB161174; Thu, 26 Feb 2015 07:10:44 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id E476F161186; Thu, 26 Feb 2015 07:10:43 -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 6B097161174
for ; Thu, 26 Feb 2015 07:10:43 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 456E010896
for ; Thu, 26 Feb 2015 07:10:43 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 3E69C33C79; Thu, 26 Feb 2015 07:10:43 -0500 (EST)
Date: Thu, 26 Feb 2015 07:10:43 -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: <20150226121043.GF7105-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 --
Path: reader1.panix.com!panix!goblin3!goblin.stu.neva.ru!news.netfront.net!nvitacolonna
From: Nicola
Newsgroups: comp.databases.theory
Subject: Re: Role of functional dependencies in database design
Date: Mon, 23 Feb 2015 17:34:06 +0100
Organization: ---
Lines: 19
Message-ID:
References: <80f34c94-e62e-4d02-8244-7e928acdf476-at-googlegroups.com> <64b9cd98-8a5e-4f95-a805-a8ab8c80ed70-at-googlegroups.com>
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 1424709247 95448 158.110.144.157 (23 Feb 2015 16:34:07 GMT)
X-Complaints-To: news-at-netfront.net
NNTP-Posting-Date: Mon, 23 Feb 2015 16:34:07 +0000 (UTC)
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Xref: panix comp.databases.theory:75571
In article <64b9cd98-8a5e-4f95-a805-a8ab8c80ed70-at-googlegroups.com>,
Erwin wrote:
> Well, even if you can manage to get that formalism fully specced (a tall
> order imo), the main problem will still remain that if you apply that
> formalism to any given input, the output produced will only be as reliable as
> the input it is applied to.
That is the unsolvable problem of every specification: you may be
guaranteed that the output is correct wrt the specs, but how do you
ensure that the specs are correct? In principle, they should be easier
to write and understand than the system you want to verify, but it
doesn't mean that they do not require a good deal of thought and
technical competence. Still, formal specifications are arguably useful:
safety-critical software would not be as reliable, for example.
Nicola
--- news://freenews.netfront.net/ - complaints: news-at-netfront.net ---
-- end of forwarded message --
----- End forwarded message -----
|
|
