Keith H Duggar wrote:

Yes. We gain control over natural join.


But you haven't really done that. Your "copy" declaration must still
track the underlying type.

On Feb 13, 12:53*pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
The more I study relational model, the less I appreciate the concept
of type (domain). This is consistent with dbms vendors failed to
deliver genuine rdbms extensibility via user defined types: when did
you last time program a new type? It looks like the only important
operation on any domain is equality, and the other ones are just
predicates in disguise.

Tegiri Nenashi wrote:
And users must be aware of types so that when a 'double' in one header
matches the name but not the type of a double in another header, they
will understand why join might produce an empty relation. (I may have
misunderstood Keith D's idea, but I have the impression that it is just
a substitute for '<rename>'. I think one could just ask what would
happen if all 'doubles' had the same type - some kind of <rename> would
still be needed.)

In the old mainframe days, say up to about 1985, the OS'es and add-on
products usually provided tons of 'exits'. (I suppose the modern term
might be 'driver' points.) Usually they needed to be coded in some
low-level language or assembler. Customers soon learned not to let any
old programmer code them, but often they saved tremendous amounts of
appl'n developer work-arounds (sometimes they amounted to just 'jobs for
the boys'.)

Builtin types such as 'integer' and 'char' and even 'utf8' seem rather
puerile to me, or at least beside the point as far as application
relations are concerned, being related more to physical machines than to
what Codd called 'domains'. It is a bloody shame that the mainstream
so-called-relation products haven't done this, by now there might be a
sizeable body of types that had been well shaken down. I imagine some
of the current product developers are aware of D&D's work which could
give them some fairly safe theory for guidelines to customers, indeed a
whole sub-industry would be possible. I knew at least one product
developer who put lots of secret exits in his code. When he was fired,
he made a great living for several years, travelling the world and
exploiting those secret exits (this wasn't a 'relational' product,
rather one that could be called a fairly advanced 4GL, since programmers
had to code their own joins, nevertheless it was good enough to beat the
mainstream sql products in many purchase decisions for mainframe, unix
and windows platforms).

Maybe I'm wrong, but I get the impression that many pretty smart people
mistakenly think that 'user-defined' types means defineable by any old
user and that product developers think this poses huge
compiler/interpreter problems and big optimization problems. Although
I've never seen them refer to this, I have the impression that D&D
tacitly encourage that misperception, but I doubt if they really intend
it, since they were both present during the 'old days'. I believe their
motive is to establish principles that dictate implementation results,
not ones that dictate implementation techniques.

On Feb 15, 8:07*pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
It seems to me operators only apply to types of entities in a defined
algebraic structure like a field (I hope that's right, I'm no
mathematician). Still, they're absolutely necessary for those cases -
how else could we do things like number arithmetic, string slicing,
point translation, shape scaling and rotation, line intersection,
color mixing, matrix multiplication, polynomial addition, regexp
concatenation, and so on in a database? Granted, we can't do most of
those things now because of lack of vendor domain support, but I'm not
ready to give up on types yet.

I agree with your point about predicates, though. Most entities
require no operators except equality (and perhaps constructors). I
just wish those teaching programming and databases knew this. The
database design module I completed last year was pure ER diagrams,
everything-is-an-attribute-of-an-object and not a single mention of
predicates. So too the OO design patterns module, and the OOAD
modules the year before.

On Feb 14, 4:53 am, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:

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

On Feb 17, 1:29*pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:
Thanks for the introduction, I haven't seen the typeless model
before. I don't see how such a system would handle arithmetic
operators (e.g. + and <) and string operators like concatenation and
search - could you perhaps give an example?

On Feb 17, 9:15 pm, Nilone <rea... (AT) gmail (DOT) com> wrote:
In a typeless system a unary function could for example be formalised
as a triple (D,C,G) where D is the domain, C is the co-domain and G is
the graph of the function (a subset of DxC). This is typeless in the
sense that a function value doesn't formally have any concept of a
defined type. Rather the domain and co-domain are formally part of
the function's value as a triple (D,C,G). For example two functions
can have the same domain and graph but different co-domains. That
makes them distinct. This is actually conventional, as when one
determines whether a given function is surjective (i.e. its range
equals its co-domain). It wouldn't make sense to ask whether a
function is surjective if its co-domain isn't part of its value.

Alternatively a typeless system could instead formalise a unary
function as a set of pairs (i.e. what we above called its graph). In
that case the domain and range is determined from the graph using
projection, but there is no concept of a co-domain.

Similarly a typeless system could formalise a relation in two
different ways. One allows for attributes to have domains specified
independently of the graph (or "body") of the relation, and these
domains represent part of the relation's value. That means that two
distinct relations can have exactly the same graph.

Alternatively a relation can be identified with its graph. In that
case the domains are determined as the projection of each attribute.

In a typeless formalism one is very clear about what it means for two
functions or two relations to be equal. It seems to require more
effort to understand what equality means in a typed formalism.

In a D&D type system, a value has a MST, but this actually depends on
the prevailing type system. E.g. two different databases could use
different type systems. Putting it another way, the MST of a value
depends on who you ask :-).

D&D want to ensure that equality of values is independent of declared
types. That's why they say that a selector for an ellipse value that
happens to specify equal width and height actually returns a value
which has an MST of circle. It's like a "magic downcast". They point
out that OO systems don't normally work that way. E.g. an OO
constructor for ellipse never returns a circle.

I think D&D end up treating relations with the same body and attribute
names as equal. i.e. in essence the declared attribute domains are
not part of the relation's value. I think they define subtyping of
relation types accordingly.

It seems to me that D&D spend a lot of effort discussing ideas that
are either eliminated or trivialised in a typeless formalism of the
RM.

On Feb 17, 10:14*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:
Formalization is less of an issue here. I interpret the question as
how to make a working system operating predicates such as Plus(x,y,z)
and Concat(x,y,z). Logical programming provides sort of an answer.

On Feb 17, 8:51*pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
You're right. I'm a programmer rather than a mathematician. As such,
infinite sets can only be approximated and every value has a cost in
space and time. So I'm interested in how operators would be
effectively (and hopefully, efficiently) defined in a software version
of such a model.

The operators in a typed system are based on inspecting and
manipulation the representation of values. I don't see how anything
similar is possible in an untyped relational model. There's
exhaustively generating all operands and results, which is
impractical. With a successor operator defined (again,
exhaustively?), we can define plus inductively, which would be highly
inefficient. Is there a way to define these operators without
resorting to hidden types or an actor-like model of delegating the
work to the operand?

On Feb 17, 11:36*am, Nilone <rea... (AT) gmail (DOT) com> wrote:
I'm not sure what hidden types or actor-like model of delegating the
work to the operand, and why it is undesirable. Predicates such as
"Plus" do have a set of functional dependencies, so why not to allow
these dependencies be implemented in procedural language? These could
be considered implementation details, pretty much as indexes belonging
to physical layer of relational model. This idea is explored in

http://vadimtropashko.wordpress.com/...rings-in-qbql/