Re: no names allowed, we serve types only

On 20 feb, 03:40, David BL <davi..._at_iinet.net.au> wrote:
> On Feb 20, 12:36 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:
>
>
>
> > The more I read, the more I find myself warming up to this idea.
>
> > Dave, could your SUPPLIERLOCATIONCITY vs SUPPLIERDISPATCHCITY (and
> > other such objections) be resolved by having two kinds of subtyping -
> > one allowing implicit coersion and the other not - e.g.
>
> > TYPE CITYNAME SUBTYPE STRING EXPLICIT COERSION
> > TYPE SUPPLIERLOCATIONCITY SUBTYPE CITYNAME IMPLICIT COERSION
> > TYPE SUPPLIERDISPATCHCITY SUBTYPE CITYNAME IMPLICIT COERSION
>
> > Which might be a way of allowing various types of cities to be joined,
> > while still flagging direct comparisons of SUPPLIERLOCATIONCITY to,
> > say, COUNTRYNAME?
>
> I find it strange that there can be two distinct types T1, T2, and yet
> implicit conversions are allowed in both directions, as if they
> subtype each other.
>
> Since type systems are the source of so much controversy I would
> rather not add fuel!
>
> > Admittedly, SUPPLIERDISPATCHCITY seems quite verbose for a type name -
> > but perhaps that's just based on us having put up with (attribute
> > name, simple type) pairings for so long.
>
> > In fact, it's a bit surprising that Date wouldn't have pushed more in
> > this direction himself - in his "Database in Depth (pg 24)", one
> > begins to notice a distinct lack of elegance as he uses rich typing:
> > PARTS = {PNO PNO, PNAME PNAME, COLOR COLOR, WEIGHT WEIGHT, CITY CHAR}
>
> > (one wonders why he chose type CHAR for CITY, when CITY should only
> > naturally, without explicit coersion, be comparable to other CITY
> > values, not any arbitrary strings of characters)
>
> I agree this provides some motivation, but it doesn't seem sufficient
> justification to "conflate" concerns (as Bob says).  The crucial point
> is this:  The attribute domains are part of the relation-type, whereas
> the attribute names are part of the relation-value.  What happens with
> your suggestion?
>
> It's very important to keep a clear separation between a value and its
> declared type, in order to understand equality.  Your suggestion ends
> up conflating relation-type and relation-value.
>
> How do you support sub-typing of relation-types according to sub-
> typing of the attribute domains, and still allow for addressing the
> attributes by type name?

That's actually no problem at all. The formal definition of a relation type / relation header in Keith's approach would be a set of types (*). For those types you can define a subtyping relation as follows: a relation header H1 is said to be a subtype of H2 if for every type in R2 there is a subtype in R1. It's even possible to have a matching semantics with that that follows the subtype=subset principle. So no notion of coercion is really needed here.

(*) Note there would / should be an additional requirement that a header can only contain incomparable types, i.e., it cannot contain t1 and t2 such that t1 is a proper subtype of t2.

> It seems you are forced to support multiple
> typenames for an attribute.  E.g. a relation has an attribute
> containing circles and you must allow it to be addressed using either
> circle or ellipse.

Indeed. But the header would contain only Ellipse, and all subtypes, including Circle, would be implied. On a related note: relation projection could be slightly generalized such that you could not only project on types in the header but also on subtypes of them.

Btw. was the typing rule for equality already discussed? That's not as straightforward as some might think. One proposal could be that t1 = t2 is allowed if t1 and t2 have at least one common supertype. Or should that be subtype? Or both? :-) The right answer depends on several things such as the chosen semantics of your types; two types would be semantically incomparable if the intersection of their semantics is empty. I can easily imagine that the schema designer should be able to indicate explicitly that two types are incomparable, even though they would be semantically comparable.

• Jan Hidders