Re: no names allowed, we serve types only

From: David BL <>
Date: Wed, 17 Feb 2010 03:29:41 -0800 (PST)
Message-ID: <>

On Feb 14, 4:53 am, Keith H Duggar <> wrote:

> I'm wondering, do we really need A? Can we not simplify this
> header notion to just a set of types?

I think the RM can be (conceptually) simplified, but you're throwing out the wrong thing! A formulation of the RM could keep attribute names, but drop the whole idea of the type system.

Values can be formalised without types. Just look at ZFC. Note that the equality operator is fundamental to set theory. Values can be compared even though they have no types.

Type theory involves the idea that values have a well defined type (or rather a set of types, one of which is the Most Specific Type). That concept is alien to set theory and most of mathematics. One problem I have with type systems is their adhoc nature. The MST of a value depends on the types that have been declared to the database system. If you instead wanted to be fair and avoid discrimination by allowing every set containing some value x to be considered one of the possible types of x then you would find that the MST of x is {x} and the class of all types of x isn't actually a set (the latter can be proven using the Russell paradox trick).

Operators can be formalised without a type system too. Simply formalise an operator as a function defined on some domain, where a domain is merely a set (not a "type").

The equivalent of the type system (including all conceivable database constraints) can be expressed using normal set theory. Just use a single set to describe the possible values of the (entire) database. What could be simpler?

An un-typed RM is easy to formalise because all the RM operators are *already* defined without reference to type systems. E.g. join only depends on attribute names and the ability to test for equality of attribute values. The attribute domains don't come into it at all. Similarly for the other RM operators such as union, intersection and difference.

I wonder whether there are practical economies for avoiding formalised types in a database schema language. A database schema is no longer a type definition but instead just a set definition. D&Ds concept of subtyping by constaint maps to nothing more revolutionary than subsetting through set comprehension. A relation value can represent the equivalent of a tuple type and a power set over a relation value (i.e. a set of tuples) provides the equivalent of a relation type (as a set of relations). Set comprehension allows arbitrary database constraints to be imposed.

David Received on Wed Feb 17 2010 - 05:29:41 CST

Original text of this message