MESSAGE
| DATE | 2015-02-26 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [mrbrklyn@panix.com: (fwd) Re: [LIU Comp Sci] Need tutoring on
|
From owner-learn-outgoing-at-mrbrklyn.com Thu Feb 26 07:11:52 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id E629D161174; Thu, 26 Feb 2015 07:11:51 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id D98AF161186; Thu, 26 Feb 2015 07:11: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 685FB161174
for ; Thu, 26 Feb 2015 07:11:51 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 459D410ACB
for ; Thu, 26 Feb 2015 07:11:51 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 3EE7F33C79; Thu, 26 Feb 2015 07:11:51 -0500 (EST)
Date: Thu, 26 Feb 2015 07:11:51 -0500
From: Ruben Safir
To: learn-at-nylxs.com
Subject: [mrbrklyn-at-panix.com: (fwd) Re: [LIU Comp Sci] Need tutoring on
Relational Calculus]
Message-ID: <20150226121151.GQ7105-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:07:18 -0500 (EST)
From: Ruben Safir
To: mrbrklyn-at-panix.com
Subject: (fwd) Re: [LIU Comp Sci] Need tutoring on Relational Calculus
User-Agent: tin/2.2.1-20140504 ("Tober an Righ") (UNIX) (NetBSD/6.1.5 (i386))
-- forwarded message --
Path: reader1.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!ottix-news.ottix.net!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 02 Jan 2015 17:02:33 -0600
Date: Fri, 2 Jan 2015 18:02:33 -0500
From: "James K. Lowden"
Newsgroups: comp.databases.theory
Subject: Re: [LIU Comp Sci] Need tutoring on Relational Calculus
Message-ID: <20150102180233.fa0f3f4c.jklowden-at-speakeasy.net>
References:
<20141221174830.17907dd8.jklowden-at-speakeasy.net>
<20141231172312.ea580d34.jklowden-at-speakeasy.net>
X-Newsreader: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64--netbsd)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 109
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 209.166.36.60
X-Trace: sv3-7SD9L/3QY0QJc/LWrlfOn+/FtrrtZFOR1STQDYYV9s8SLQc+gSJCvFhxQnNDPHoAZYp64UPbE4Zwsf8!n4DoihgjJpQGu9Wp6UHinRRZkHir0CM6AzU3raddRgxK01GSfoPr878Iwd/+w9lwjQ8UVCYuuJyJ!sVgK9rwJrLWF3WdhgBrQRHkjB9KZzzDC
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6786
Xref: panix comp.databases.theory:75310
On Fri, 2 Jan 2015 04:24:35 +0000 (UTC)
ruben wrote:
> On Wed, 31 Dec 2014 17:23:12 -0500, James K. Lowden wrote:
>=20
> > I can think of no way in which "normalization is a failure".
>=20
> well, think harder about it then=20
I am sorry to have left the impression I have not thought long and hard
about it. =20
> because just this morning its failure was facing me, eye to eye when
> some expert normalized our database and exhausted the system
> resources and dropped productivity through the floor, killing a good
> part of my new year.
Normalization is a logical concept. It cannot affect physical
resources. That said, it is of course possible and usually desirable
to implement a normalized physical design. When that is not done,
extra care must be taken to ensure the database remains internally
consistent. =20
Whether or not "some expert" in fact produced a BCNF design is not an
assertion I would accept at face value. I have seen many terrible
designs declared "normalized" that were nothing of the kind. Like most
things, normalization is easier said than done. =20
The easiest steps are the removal of repeating groups (1NF) and
determination of keys (functional dependency, 2NF). If your design
meets those criteria and performs badly under the intended workload, the
usual reason is underpowered hardware. While it's always possible to
craft a purpose-built system that outperforms a DBMS, it's usually not
economical. That's why it's a $30 billion annual market. =20
Regarding, http://lambda-the-ultimate.org/node/3762, we left the
reservation at:
"Nowadays it is accepted that ORM (Object-Role Modeling),
Object Oriented (OO) and other post-OO methodologies, such as Agile
Modeling, Agile Development (Erickson, Lyytinen, & Siau, 2005) are most
appropriate not only for programming, but also for analyzing and
designing information systems, including, of course, database design."
Far from being "accepted" for the purpose, software development
methodologies have exactly nothing to say about database design. The
author doesn't seem to know that that "OO databases" rest on the very
same theoretical void that the hierarchical and network models did
before them. =20
If you want to use UML or whatever to help you identify attributes and
their keys, fine. Just recognize that what you're doing *is*
normalization, albeit informally and likely sufficiently. =20
The article is a bit polemic and contains many factual errors or
oversights. For example, while it's true that atomicity and nested
relations have been subject to some to-and-fro over the years, the
*theorectical* concerns cannot be divorced from implementation: because
SQL has (almost) no recursion, nested relations cannot be defined and
manipulated. Because any such relationship can be defined in unnested
form -- and manipuated with a first-order predicate logic language like
SQL (mostly) -- that's how SQL-based designs are implemented. =20
Two others, briefly: addresses *do* require decomposition if their
components are to be used or verified. If you don't care if you
have a zip code or otherwise an address that can be delivered to, and
you have no need to collate by zip code or city etc., then fine, use a
blob. The need will make itself apparent in time, and the mistake is
not fatal. And the whole professor-department dustup is really just a
failure to understand the problem's own terms. Professor's have
departments & offices, and departments have offices. That does not
imply that a professor's office's department determines the professor's
department. =20
None of that, by the way, has any bearing at all on your two-day
experiment with normalization. Yes, you can find articles that seem to
support your opinion. One of the problems with database theory is the
average quality of the literature you find online. Maybe that's
because SQL is so widely used and tables seem to so easy to
understand. Be that as it may, I caution you not to accept the gloss
if you can't analyze the content. =20
I'm sympathetic to what I guess the author's point: that normalization
is not the mechanical process it was hoped (hyped?) to be, and that the
simple practitioner (or, gee, student) looking for guidance may be led
astray by pointy-headed logicians on one hand and know-nothings on the
other. The former bury you in language like "relation R(A, B, C) where
FDs (A, B) ? C and C ? B hold", and the latter fail to acknowledge the
reasons for and value of eliminating redundancy in the database. =20
Yet if we discard the fancy language and mathematical exactitude, the
basic problem is embarrasingly easy. Most normalization issues can be
tested with two questions:
1. If I know X do I know Y? (functional dependency)
2. Is there more than one Y for X? (repeating groups)
You don't need a degree or a class or a book to understand those
questions or (if you know the universe of discourse) their answers.
That's part of the beauty of the model and why Codd developed it:
relations are easy to understand and develop intuition for. It takes
practice to find all the attributes and ask those questions for every
one and, sure, there's more to it. But those two questions, asked
repeatedly of the right person, will carry you a long way in the right
direction. =20
HTH. =20
--jkl
-- end of forwarded message --
----- End forwarded message -----
|
|
