From: PC
To: Editor
I have enjoyed your debunkings as well as several of your
books and I think that you and Messrs. Date, Darwen and McGoveran are to be
congratulated for your stances on various database issues. IMHO, you are
performing a public service and I hope you won't mind if I mentally associate
your name with one Blaise Pascal in this sense. I often find myself silently
cheering when you take on some of the so-called implementers and I especially
like the simplicity and elegance of yours and your 'cohorts' ideas.
I have some blurry ideas that I would like to try
implementing for my own edification. They have to do with a more declarative
approach to DBMS engines as well as leveraging some of the file system work
that is going on in the Linux world and other Linux and open source
possibilities.
One problem that I am stuck on is how to express numbers in a
purely relational way, without any procedural language baggage. What little I
know of mathematics tells me that the number '3', for example, is often thought
of in that world as the set of all sets that have 3 members. What I would like
to do is be able to express in a program the identity of one of those sets - in
other words to address one of them as a row (I wouldn't care which one). Since
this row would in fact be a table, it would provide me with an internal (not
external) way to iterate. Again, I wouldn't care about, in fact, I don't think
I would even need to define the attributes of that table-within-a-row, as I
would only be taking advantage of its specific cardinality. It seems to me that
I could solve some problems that have to do with cardinality and constraints
without resorting to procedural code, if I had such tables.
I have puzzled over the two tables (DEE and DUM) that have no
columns, but my imagination doesn't suggest how I might be able to build on
them. Of course, I could just predefine an infinite number of tables in my
namespace (I'm inclined to think of them as base tables, but I seem to remember
reading that base tables are stored, which these wouldn't be), such as '#1,
#2...--I'm not keen to do this, because if there is a more inherent way, the
predefinition would seem like a hack and, more importantly, might lead to
complications later. Also, I'm not really interested in performance at this
point.
Have you any thoughts on these lines, especially how a
minimal relational algebra could express them? Or other suggestions?
Chris Date Responds: With respect to your questions
concerning a "minimal relational algebra" and "expressing
numbers in a purely relational way", I'm wondering whether you've seen the
book FOUNDATION
FOR FUTURE DATABASE SYSTEMS: THE THIRD MANIFESTO (2nd ed.) by myself
and Hugh Darwen. (That "2nd edition" is important, by the way; the
2nd edition is meant to replace the 1st edition entirely.) Chapter 4 of that
book presents a relational algebra that we certainly believe is minimal (it can
be defined entirely in terms of just two primitive operators, REMOVE--which is
basically project--and either NAND or NOR). We call it A. To quote from
the text:
"The name is a doubly recursive acronym: It stands for
algebra, which in turn stands for A Logical Genesis Explains Basic
Relational Algebra. As this expanded name suggests, A has been
designed in such a way as to emphasize, perhaps more clearly than has been the
case with previous algebras, its close relationship to, and solid foundation
in, the discipline of predicate logic. In addition, the abbreviated name A has
pleasing connotations of beginning, basis, foundation, simplicity, and the
like--not to mention that it is an obvious precursor to D, [which] is a
relational language proposed elsewhere in the same book."
On pages 92-98 of the same book, we show how the more
conventional operators of the relational algebra can all be expressed in terms
of A. In particular, we show how to deal with numbers and ordinary
arithmetic in that framework.
By the way, I'd like to quarrel with one remark in your note.
You say you "remember reading that base tables are stored." Well,
perhaps you do; you might even have read such a thing in certain (mistaken)
early writings of my own. But it's certainly not a requirement of the
relational model that base tables be physically stored! (The SQL vendors really
let us down on this one.) See the article It's All Relations!in
my book RELATIONAL
DATABASE WRITINGS 1994-1997.
Posted
03/22/02
[ABOUT]
[QUOTES]
[LINKS]
