Re: A good book

From: David Cressey <dcressey_at_verizon.net>
Date: Tue, 11 Jul 2006 12:06:17 GMT
Message-ID: <ZuMsg.1044$qd3.444_at_trndny05>


"Chris Smith" <cdsmith_at_twu.net> wrote in message news:MPG.1f18aa623adf093d98975d_at_news.altopia.net...
> Bob Badour <bbadour_at_pei.sympatico.ca> wrote:
> > Chris Smith wrote:
> > > I'm suggesting that you've yet to establish the connection between:
> > >
> > > (a) predicate calculus and elegant code
> > > (b) databases and predicate calculus
> >
> > Relational calculus = 1st order predicate calculus
> >
> > Am I missing something?
>
> No, you're almost certainly not missing something. Nevertheless, what
> I'm asking for ought to be relatively simple, so I'll try to explain it
> another way.
>
> As is pointed out here several times every five minutes (okay, not that
> often...), database design and programming is rather frequently and
> unfortnuately performed from very little theoretical basis at all. At
> the same time, it's frequently stated that relational databases operate
> on a solid mathematical foundation. That's a useful statement if and
> only if that mathematical foundation provides tools that are useful in
> practice for reasoning about behavior, transformations, correctness,
> etc. of the code written in relational languages. If this connection is
> not made, then all this talk about predicate calculus is pointless. I
> am looking for the sources that explain how this connection is made.
> Are there theorems of relational theory that suggest certain program
> transformations, or certain criteria for correctness? You made a
> comment in another thread that suggested that features added to
> relational databases can be traced back to the mathematical model;
> where's a source that explains how? Although it's not a specialty of
> mine, I have a pretty solid layman's knowledge of systems of logic,
> including predicate calculus, but it's entirely non-obvious to me how
> this would effect my use of or implementation of a database system.
> This is what I'm asking for. Or at least, that's the theoretical part
> of what I'm asking for, which I called (b). The practical part is (a),
> but I imagine it will largely follow from the theoretical understanding.

I agree with Bob. The place to start is Codd's 1970 paper.

However, there is something in what you just said that suggests that your real interest liest outside of purposes for which the 1970 paper was written.

The solid mathematical foundation is much more necessary for the formulation of a new kind of database, different than the ones already built, than it is for competent design and programming using a tool that is already built, and provided along with some support. Codd was writing for readers who would have to assess the value of a relational DBMS, without being able to play with one that's already built.

Let me quote part of your post again:

> As is pointed out here several times every five minutes (okay, not that
> often...), database design and programming is rather frequently and
> unfortnuately performed from very little theoretical basis at all. At

For any given design problem, there are usually multiple designs that are logically correct, and all satisfactory up to some minimal level. Sometimes it's worth while to select carefully among these designs. Sometimes it's not.

For any given programming situation, there are multiple programs that will yield correct answers. Sometimes, it's necessary to pick one that performs well, or one that easier to read. Sometimes it's not.

In any event, it's fairly easy to write good queries against a well designed database that contains good data. You don't have to know much theory to do that. However, if your first experiences at writing queries is on a database that was poorly designed and contains data that's poorly managed, you'll acquire some habits and attitudes that will be profoundly counterproductive later on, when you begin to do things like write applications that update the database or design new databases from scratch.

You need more theory to write good database update applications. You need even more theory to design databases well. You need even more theory to dream up a new RDBMS. You need even more theory to come up with a new data model.

Unfortunately, many neophytes attack the above set of problems in precisely the opposite order. Their learning is then undermined by their own mistakes.

This turned into a long ramble. If it's irrelevant to your concerns, Chris, then I apologize for wasting your time. Received on Tue Jul 11 2006 - 14:06:17 CEST

Original text of this message