From: LA

To: Editor

Date: 10 Feb 2004

 

I love your website.

 

In THE THIRD MANIFESTO, you outline the use of relation-valued attributes. The example that springs to mind (the book is not in front of me) is the polygon example.

 

I am just wondering what happens when we take this a step further, for instance we wish to represent a graph (in the mathematical sense - a set of edges and vertices) - obviously we can't do this with a single relation we need two. These two relations need constraints defined between them to ensure consistency. So the graph "type" that I am trying to formulate here is more than just a tuple with two relations, it is a database in it's own right.

 

So where I am headed is using the model that you present in THE THIRD MANIFESTO recursively to define the types that you mention may need to be implemented in something other than D.

 

I would like to hear your thoughts on this, do you exclude this in the model? I can't seem to find a place that you mention it. Am I barking mad? Is it a bad idea?

 

One other point - if this line of thinking is followed further there is the potential for the internal relations of a given type to be related to relations in the database in which the type is housed. I can definitely see danger here, as the type is no longer transparent and encapsulated. However if I outline a scenario where it would be useful, maybe you can show me the error of my ways and suggest a better alternative.

 

Imagine we are in the electronic document business, we have created a type that represents our electronic documents (it is a database in its own right, so we used the relational model and our D to implement it as outlined above) now we have created a relation that holds various aspects of the document like creator and date of creation and the document itself etc. The document type has the facility to record a set of references - let's just say it is a bibliography for now. And for the sake of simplicity, the bibliography of all documents we store in this fictitious database contain only documents already within the database. Would it not be advantageous that the bibliography stored within the document type reference the document relation in our database to maintain the internal consistency of the type itself?

 

I can see that traditionally there would be a bibliography relation in the database itself that holds this information. I am just exploring the idea of allowing complex types to become reusable units.

 

 

C. J. Date Responds: Thank you for your kind remarks.  What follows is a response to your thoughts and questions regarding THE THIRD MANIFESTO.  I think those thoughts and questions betray some confusion on your part, but I don't know if I can exactly put my finger on them!  Anyway, let me give it a try. 

 

The key point to understand is that a type is a set of all possible values of some particular kind: e.g., the set of all integers, or at least the set of all integers that are capable of representation in some particular computer system.  It's not the set of all values of some particular kind that happen to be in use in some particular computer--or database, or whatever--at some particular time.  (Incidentally, this latter perception seems to me to be akin to some of the muddles we observe in the OO world.) 

 

Given the foregoing, consider now your remark to the effect that a certain "graph type" is "more than just a tuple" but is "a database in its own right."  A type is not a tuple, nor is it a database:  A tuple is a value, a database is--sloppily--either a value or a variable, and a type is not a value and not a variable. Now, it's true that a type has one or more possible representations ("possreps"), and it's also true that a possrep looks like a tuple (of a certain special kind), but they are logically distinct concepts.  Note in particular that we would never want to join two possreps, though we certainly might want to join two tuples!  See THE THIRD MANIFESTO book, 2nd edition, page 134. 

 

Aside: At the risk of confusing you, I remark that a database can be regarded as a tuple, however!  This is a topic I plan to write more about sometime soon.  End of aside. 

 

To continue: It seems to me that your graph type simply has a possrep with two components C1 and C2, each of which is of some relation type, and there's a type constraint in effect that limits the values that C1 and C2 can take.  That's all.  Please note too that there's no possibility that C1 and C2 might "be related to the relations [better: relvars] in the database in which the type is housed," because type constraints are not permitted to mention any variables.  Note too that types aren't "housed" in databases, anyway!  (Which database "houses" type INTEGER?) 

 

You also say:  "So where I am headed is using the model presented in THE THIRD MANIFESTO recursively to define the types that might need to be implemented in something other than D" (slightly reworded).  I don't see how this is a consequence of what you've said previously, but I suspect it's wrong, anyway. 

 

By the way, your "type that represents electronic documents" looks like type XMLDOC to me!  See AN INTRODUCTION TO DATABASE SYSTEMS, 8th edition, pages 925-926.  As for creating "the bibliography of all documents we store":  All you need is the ability for some type to represent document names, that's all.  Surely the situation is precisely analogous to what we do today with database catalogs, which (among other things) contain a "bibliography" of all relvars in the database?

 

 

Posted 04/09/04