Re: Domains as relations

"David Cressey" <david_at_dcressey.com> wrote in message news:<8kBo9.173$0I3.13779_at_petpeeve.ziplink.net>...
> I think you are really onto something.

onto something or on something? :)  

> 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.

Well you could think of relations defined at two different levels: one in the usual way at the logical level which would be ultimately list-driven. The other at a lower physical level which internally would be rule-driven, but which would manifest itself as list-driven at the logical level. So if your DBMS had a table for integers (or a subset) it wouldn't actually store them all but create the relation/view on the fly whenever you did "SELECT * FROM integers" or whatever.

Actually just thought maybe if you had a table with just 0 and 1 in it in the same column then cross join it with itself enough times you'd get a view that could be interpreted as a subset of the integers in binary form. (if you concatenate the digits together). So perhaps your only "built-ins" would be 0 and 1? But then it would be like implementing a model of a computer in your DBMS so kind of chasing your own tail.

> 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?

I'm going to look into constraint databases a bit more as mentioned elsewhere in this thread - maybe they provide a way that you wouldn't even need these "primitive" or "physically defined" views? I get the impression from a brief look that they are basically there to provide a way to extend relational theory from finite to infinite sets.  

Separate from the issue of infinite sets though, it would be nice to have everything in a DBMS stored in relations - domains, DML, DDL, DCL, constraints, etc. So it becomes completely a closed (self-referential) system instead of having a query language as a distinct thing perched on top of the relational database, and domain systems slotted in underneath it somehow as well.

Is this just a theoretical niceness though? I noticed an article along similar lines on the www.dbdebunk.com website (On variables and values) coincidentally just after posting here. The point was that it might actually be a good thing to separate things out and group together things like queries & domains as distinct from plain "data" relations. Kind of like how we don't program in machine code, or like set theory defining numbers in terms of the empty set e.g 0={}, 1={{}}, 2={{},{{}}}, ... n=union(0,1,...,n-1) but it being more useful to *not* think of numbers as sets.

Maybe Codd was wrong when he stipulated that everything in a DBMS should be accessed via relations. Or maybe there is a distinction made between data and programs - is this a valid or useful distinction though? I get the feeling that I'm thinking in circles.

Paul. Received on Thu Oct 10 2002 - 17:52:29 CEST