Re: Domains as relations

From: David Cressey <david_at_dcressey.com>
Date: Tue, 08 Oct 2002 13:45:40 GMT
Message-ID: <8kBo9.173$0I3.13779_at_petpeeve.ziplink.net>


Paul,

I think you are really onto something.

> For example, the integers (in a certain range maybe) would be
> represented by a table with just one column that includes every
> integer. This need not be stored phyically of course, it would just be
> a logical thing.

What this suggests to me is the following: there are two ways to define a relation: by list or by rule.
In the DB world, we tend to think of all relations as being defined by list. Basically the state of any given
relation at a given point in time is determined by a list of tuples. The list of tuples is stored in a table, one tuple to a row.

Those of us who work with DBs tend to think this way so much that we don't think of rule based relations. Please correct me, someone, if there is an accepted mathematical term for what I'm calling "rule based relations".

The closest thing I've got, in practical terms to a rule based relation is a view. I can think of the view as representing a relation, subject to some restrictions on views, and the selection rule in the view definition as being the rule that defines this relation. The problem is, with existing RDBMS products, the views all finally devolve down into tables, one way or another. So in the final analysis, rule based relations incarnated as views, end up being list driven behind the scenes.

What if the rule on views were relaxed at little. What if the system contained a few "primitive views" that defined such relations as "the set of all integers that will fit in a given word size". That's finite, but you really don't want to make a list of them. Or a primitive view "the set of a character strings of length 5". What now?

You could define views based on the primitive views, and/or key columns of tables, in combination with each other.

You could require that every column be based on a view, using that view as its domain. In the case of foreign keys, that would resolve down to the column where the key values are listed, something I still have the habit of calling a "primary" key.
In the case of many columns, the "domain view" of that column would resolve down to one of the primitive views of the system, together with constraints.

I don't know where this leads, but it could be interesting. Received on Tue Oct 08 2002 - 15:45:40 CEST

Original text of this message