Re: Dawn doesn't like 1NF
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 --
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
> 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.
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.
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