Re: no names allowed, we serve types only
Date: Wed, 17 Feb 2010 03:29:41 -0800 (PST)
Message-ID: <f5af0e07-42e5-4ed7-9d8e-8bea1e483a8f_at_u19g2000prh.googlegroups.com>
On Feb 14, 4:53 am, Keith H Duggar <dug..._at_alum.mit.edu> 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).
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.
David Received on Wed Feb 17 2010 - 12:29:41 CET