Re: relations aren't types?

From: Dawn M. Wolthuis <>
Date: Sat, 20 Dec 2003 22:48:46 -0600
Message-ID: <bs38nn$oqm$>

"Adrian Kubala" <> wrote in message
> Bob Badour <> schrieb:
> > [...] Thus "relation" refers to values of a generic type and not to a
> > specific type, per se. [...]
> I understand what a relation is. If anything, I'm fuzzy on the
> definition of "type".
> Consider the type "student" which is defined as as the set of tuples:
> {<"joe", "schmoe">, <"sally", "strauss">}. In what way is this not a
> type, or not a relation?

You are correct that a relation, such as Student could be a type, although Date & Darwin argue against seeing them as such. Most relations in an RDBMS can also be viewed as functions (that is, they map a "key" value in the domain of the function/relation/set to exactly one value in the range of the function -- which can be a set that includes tuples as elements or any number of types of elements). So, you can look at a Student relation as a Student function that maps an ID to a tuple, for example.

Java classes define types. Often these types are nouns. The objects that instantiate these classes are typically passed as parameters (actually their reference ID is) to functions (methods in classes). However, functions themselves can be objects of the type "function". In your example, a class "Student" could define a type of function. Instances of this class would be Student functions (which, by definition are relations). There could also be a class called Student that defines a type and is a single element in the function. An instance of this might be similar to a single row in a table. [I hope you can get past the fact that I am working with a Functional Databases model rather than Relational Databases. Functions ARE relations, although not all relations are functions.]

While there are some purists who argue that classes should not define functions, but rather only domains for the parameters or resulting value of a function. You might folks suggest that classes should always be nouns and not verbs, but most design pattern discussions include "do"type classes or classes that are functions themselves.

For example, if we take the relation Student and write it as a function that maps the key StudentID to a set with demographic and other information about the student, then the type Student could be the function that holds all of our student information (for both students in our sample school below)

{ ("12345", "Dave", "Madden", "(616) 555-2637", "M"}, ("22222", "George", "Bush", "(666) 123-4567", "M") }

Alternatively, Student could be a class that defines a type that is only one of these two elements, relating to a single "row" in our "table" (element in our function).

To distinguish these, I prefer to name type definitions (classes) that define entire relations (shown as functions in my example) as plural, so such a class would be named Students. If defining a type that is instantiated by objects that are single elements of a relation/function, I then use singular names.

I have read and re-read Date & Darwin's rationale for using classes to define types that are domains of attributes in a relation. I completely agree that is an appropriate use of a class. But the reasons for not using a class to define a type that is either a relation (or, my preference -- a function) or an element of the same are not at all satisfying. That is, I've read the rationale and I don't buy it. So, I'm with you -- one can define types that are domains, relations, rows, etc -- these are all valid classes.

Just my two cents. Go ahead, Bob, remind me how stupid I am if it helps you in some way -- otherwise feel free to counter my argument with logic. Cheers! --dawn Received on Sun Dec 21 2003 - 05:48:46 CET

Original text of this message