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:29 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 686E8161174; Thu, 26 Feb 2015 07:11:29 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 56222161186; Thu, 26 Feb 2015 07:11:29 -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 BE003161174
for ; Thu, 26 Feb 2015 07:11:28 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 9534F10A3F
for ; Thu, 26 Feb 2015 07:11:28 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 8AB9A33C79; Thu, 26 Feb 2015 07:11:28 -0500 (EST)
Date: Thu, 26 Feb 2015 07:11:28 -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: <20150226121128.GM7105-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.68.241.163 with SMTP id wj3mr5176663pbc.8.1423769142286;
Thu, 12 Feb 2015 11:25:42 -0800 (PST)
X-Received: by 10.140.43.10 with SMTP id d10mr77882qga.26.1423769142021; Thu,
12 Feb 2015 11:25:42 -0800 (PST)
Path: reader1.panix.com!panix!usenet.stanford.edu!hl2no15119363igb.0!news-out.google.com!n6ni6qar.0!nntp.google.com!j7no151813qaq.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.databases.theory
Date: Thu, 12 Feb 2015 11:25:41 -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: <91803a70-ff44-43d8-ab9b-09c994df292a-at-googlegroups.com>
Subject: Re: Role of functional dependencies in database design
From: Erwin
Injection-Date: Thu, 12 Feb 2015 19:25:42 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 47
Xref: panix comp.databases.theory:75525
Op donderdag 12 februari 2015 17:02:19 UTC+1 schreef Nicola:
> >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?
I overplayed my hand, slightly.
Take an example relvar DBR {A B C} subject to the FD {A} -> {B} (and its ke=
y thus being {AC}).
Rewind 40 years.
Enforcing this FD in that design involves extra checks, and in the time whe=
n all that theory originated, this meant : extra coding work, precisely in =
the update process that was exposed to the update "anomaly" involved. As f=
ar as I can tell, all that theory was developed so that the update "anomali=
es" implied by a given design, could be _identified_, so that after that an=
_informed_ decision could be made regarding how to deal with it : (a) elim=
inate it through redesign, or (b) live with it and keep the update processe=
s that are exposed to the "anomaly" "guarded","monitored","under supervisio=
n",... But in that day and age, (b) was almost never a viable option, simp=
ly because the _means_ for doing so (which is "if a program gets it wrong, =
make sure it won't leave its devastating effects persisted in the database"=
, or iow, "declare a constraint") simply weren't available.
Fast forward 40 years.
This day and age, I can simply do the (equivalent of the) following (hypoth=
etical SQL) :
CREATE VIEW PROJ AS SELECT DISTINCT A,B FROM DBR CONSTRAINT UNIQUE (A) ;
That is, I have a system to my avail where I simply declare the view (proje=
ction on all the attributes mentioned anywhere in an FD), and declare a con=
straint to the effect that the LHS portion of the FD constitutes a key to t=
hat view. And if a program fails to obey the FD, it won't get any updates =
through (unless it is accidentally a good one).
Where I "overplayed my hand", is that introducing the constraint to enforce=
the FD to be obeyed, will not help in simplifying the potentially more com=
plex proceedings a program has to follow to get the database updated. That=
is, while there is no possibility that the update "anomaly" will lead to i=
ncorrect data, the "anomaly" is still there and must still be dealt with by=
the programs that are exposed to it.
-- end of forwarded message --
----- End forwarded message -----
|
|
