Domains as relations
Date: 8 Oct 2002 02:04:23 -0700
Message-ID: <51d64140.0210080104.f79cbee_at_posting.google.com>
I've been thinking that what often complicates database theory is that the underlying domains have their own separate theory. But maybe it is possible to express the structure of the domains in a relational form.
Fo example, a foreign key constraint is basically just saying that the domain of a column is dynamic and is represented by the values in the column of the "lookup table". So why not extend this concept and require all domains to be defined in this way i.e. in a relation. A problem will be that then how do you define the domains of the tables that define domains for other tables. You'd have to have some fundamental domains built-in to the DBMS but the difference would be that they would have a relational interface.
Then things like addition, which is a relation between two integers could be represented by a table with three columns. Again, it wouldn't have to be physical. Maybe you'd only need two columns and just "store" tuples of (n,n+1) since the others can be deduced by associativity a+(b+c)=(a+b)+c. Even so you could also have a view that stored every sum of two integers, so it's kind of a moot point I guess.
Now you have brought the domain operations into the realm of relational algebra, you can do things like aggregate functions in a relational way. But for example to find the sum of an integer-valued column you'd need to join the table to itself once for every row in the table and I'm not sure if this is easily expressed in current query languages. e.g. in SQL the query would change with the number of rows in the table which isn't what we want. Is there some way of resolving this for a generic binary operator instead of having specific ones like SUM?
This line of thought was triggered by thinking about how to represent,
in relational form, the ordering "<" for some set S={a,b,c,d,e} say
such that a<b<c<d<e.
One way might be to store the tuples (a,b), (a,c), (a,d), (a,e),
(b,c), (b,d)... etc. But it would be more efficient to just store
(a,b), b,c), (c,d), (d,e) and deduce the rest from "(x,y) and (y,z)
implies (x,z)" (which would have to be stored somewhere - maybe in a
view definition?). I'm assuming here that our DBMS has no knowledge of
integers so we can't represent ordering by a mapping to the integers.
Again this is perhaps not important because we should be able to have
a view of the smaller table that represents every inequality.
[it that maybe the difference between views and tables - that views can contain redundant information but tables can't?]
I'm wondering how far you can go with eliminating every non-relational part of a DBMS? I guess Godel would imply that a totally relational system would be "incomplete" in some sense - so at some point we'd have to accept that the relational model is in fact embedded within a larger "meta-model" which we'd have to use to answer some questions about the system. My knowledge of this area is a bit sketchy so maybe someone else could put me right here.
Paul. Received on Tue Oct 08 2002 - 11:04:23 CEST