Re: Dawn doesn't like 1NF

From: Laconic2 <laconic2_at_comcast.net>
Date: Thu, 7 Oct 2004 12:36:00 -0400
Message-ID: <RcGdncR7qd4Z7fjcRVn-pQ_at_comcast.com>


"Dan" <guntermann_at_verizon.com> wrote in message news:1Qd9d.12265$na.4447_at_trnddc04...

> I'm looking at it from a perspective of being even more fundamental --
> systems of logic and theory. I am interested in being able to ask a
> question and being able to retrieve a consistent and complete answer, and
> perhaps even deduce new information from facts, whether held in a DBMS or
> not.

Two points with regard to this:

First, "Inference Engines". Inference Engines, or whatever the correct name is, are at the very least expert systems, and perhaps even artificially intelligent systems, that not only know a lot of facts, can make deductions from those facts.

I'm not sure, but I think one such "inference engine" was BASE/BALL, an early precursor to the DBMS engines that came along later. But it isn't just a database. It's really an inference engine that understands a database.

Here's a link to the "Database Hall of Fame" where Base/Ball, IMS, and Nelson/Pick are all credited:

http://ourworld.compuserve.com/homepages/Ken_North/db_hall.htm

Second, when Codd introduced the relational data model in 1970, he didn't claim to thave invented it. He made reference to its prior use in inference engines, although I think he used a different term. What was novel in the 1970 paper was the application of the relational data model to the problems of data storing and data sharing that databases and their management systems were dealing with.

>
> My major issue with non 1NF-attributes, such as nested relations, or
> comma-delimited lists, is that there is no analog that I know of to
> predicate calculus or propositional logic that will give me the same power
> and completeness when forming questions of logic. I am ultimately drawing
a
> clear line in the sand between model and implementation. With predicate
> calculus, values that plug into predicates must be discrete and atomic in
> order to meet the criteria of a correct well-formed forumula. Nested
values
> means higher order logic. If we can find a solution in terms of how we
view
> the world from a system of logic, then it shouldn't be so hard to apply it
> to the DBMS, or think about the implications it has on Codd's original
work.
> So let's start with the foundations, like Codd did I think.

I may be misconstruing your remarks here. But I think the confusion between a "set with only one element" and the element itself is fairly pervasive.

consider the following SQL, just for illustration purposes:

select * from employees where city in

             (select distinct city from employees where employee_id = 12345);

select * from employees where city =

             (select distinct city from employees where employee_id = 12345);

select * from employees where city in

             (select distinct city from employees where first_name = 'JOHN' and last_name = 'SMITH');

select * from employees where city =

             (select distinct city from employees where first_name = 'JOHN' and last_name = 'SMITH');

The ones that use "in" have no problems. Whether there's one row or many in the result table, it comes out ok.
The ones that use "=" can run into grief. In particular, the last one will get a failure if the select turns out not to be what the documentation calls a "SINGLETON SELECT".

Well, the use of "=" in this fashion is unfortunate. A city name of "HARTFORD" is not the same thing as a set of city names, with only one city name, namely "HARTFORD", in it.

Equally inforutnate, in my view, is Dawn's use of sets and elements as being interchangeable in her demonstration that functions are just as expressive as relations. I suspect that what she's done is mathematically illegitimate, although I'm no mathematician. I'm reasonably sure that it plays havoc with any kind of inference engine you might be interested in. Received on Thu Oct 07 2004 - 18:36:00 CEST

Original text of this message