Re: no names allowed, we serve types only

Keith H Duggar wrote:

> Of course the conventional definition of a relation's header
> is a set of ordered pairs of "attributes" of the form <A, T>
> where A is the "name" of the attribute (which must be unique
> within the header) and T is a type.
>
> I'm wondering, do we really need A? Can we not simplify this
> header notion to just a set of types?

Remember the adage: "As simple as possible, and no simpler."

> All we need do then is
> supply operators to conveniently "copy" types if or when one
> needs multiples attributes of the "same" type. Often we don't
> even require this. Here are some examples:
>
> no type copy necessary if we already have unique types
>
> DateTime = {Date, Time}
> Inventory = {Supplier, Part, Integer}
>
> type copy used to generate unique types
>
> Point2D = {copy Integer X, copy Integer Y}

Your later clarifications reveal that as well as naming the attributes, your "copy" keyword creates new types. This means one will have to coerce these back to integer to do anything with them that one ordinarily does with integers.

Pretending that the name affects the type turns "(X + Y)" into "(integer(X) + integer(Y))".

Doing so certainly makes queries verbose, and I don't see any benefit to compensate for the increased verbosity. In fact, your idea seems to offer a neglibible one-time benefit to the dbms implementer at the cost of burdening the least sophisticated users in their most common tasks.

> So aren't the "ordered pair" and "attribute names" a perhaps
> sometimes convenient yet always unnecessary complication?

No. You have to have a name to address the attribute. All you have done is conflate the name with the type. Have you really thought this through?

Point2D = {copy Integer X, copy Integer Y} Point3D = {copy Rational X, copy Rational Y, copy Rational Z}

Is the above allowed? If it is, what type does X identify? If not, how can you fully support join?

e.g.

Dept = {DeptID, EmployeeID, Name}
Employee = {EmployeeID, DeptID, Name}

To query the dbms for the names of employees in their respective department names, one will need to use your "copy" keyword in the query somehow:

Employee(copy Name EEName) join Dept(copy EmployeeID ManagerID, copy Name DeptName)

But if type names must be unique, what if someone runs another query and wants to use EEName or DeptName or ManagerID to identify a different type?

> We
> can do all we need to solely with types and sufficiently rich
> type systems.

I disagree. We need to make relations easy to use. We need to make relations easy to implement correctly not just easy to implement.

> One nice result is that now a header is just a
> plain simple set without ordered pairs demanding an auxiliary
> uniqueness constraint on names across all the pairs. What are
> your thoughts?

I think we have used names separate from types when using relations for a very long time:

Cone: {X in Re, Y in Re, R in Re | X*X + Y*Y = R*R } Received on Mon Feb 15 2010 - 16:17:03 CET