Re: no names allowed, we serve types only

On Feb 22, 9:10 am, paul c <toledobythe..._at_oohay.ac> wrote:

> While I
> sympathize with Keith D's wish to eliminate the 'name,type' double, I
> think that practical issues require not only so-called 'possreps' but
> also what I think of as a 'name,type,use' triples. What a mess!

Regarding possreps, I think they can be understood very clearly in a typeless setting.

Consider the following from Darwen

(see http://www.dcs.warwick.ac.uk/~hugh/TTM/taamoti.slides.pdf):

  TYPE ELLIPSE
  IS PLANE_FIGURE
  POSSREP { A LENGTH, B LENGTH, CTR POINT   CONSTRAINT A >= B AND B > LENGTH ( 0.0 ) } ;   TYPE CIRCLE
  IS ELLIPSE
  CONSTRAINT THE_A ( ELLIPSE ) = THE_B ( ELLIPSE )   POSSREP { R = THE_A ( ELLIPSE ) ,
  CTR = THE_CTR ( ELLIPSE ) } ; In the following R means the reals.

Let Tellipse be a set of tuples as follows:

  Tellipse =
    { (a,b,ctr) in RxRx(RxR) |
      a >= b and b > 0 }

Let Pellipse be a function that maps each tuple t in Tellipse to a real living ,breathing, ellipse value (i.e. an infinite set of points in RxR):

  for all t in Tellipse,
    Pellipse(t) =

      { (x,y) in RxR |
        ((x-t.ctr.x)/t.a)^2 + ((y-t.ctr.y)/t.b)^2 = 1
      }

Similarly let

  Tcircle = { (r,ctr) in Rx(RxR) | r > 0 }

  for all t in Tcircle,
    Pcircle(t) =

      { (x,y) in RxR |
        (x-t.ctr.x)^2 + (y-t.ctr.y)^2 = t.r^2
      }

Note that range(Pcircle) is a subset of range(Pellipse). This embodies D&D's assertion that type CIRCLE is a subtype of type ELLIPSE. Database systems don't tend to formalise ellipses and circles. Instead they simply parameterise their values using elements of Tellipse and Tcircle and leave the mappings Pellipse, Pcircle unspecified.

In my opinion, we should regard a possrep as formally this (unspecified) mapping such as Pcircle on a given domain Tcircle. Usually we would require such a mapping to be onto (so that all possible circles can be represented) and 1-1 (so that when two tuples are distinct the DBMS can deduce that the circles that they represent are distinct as well).

Note that Tcircle is uncountably infinite so we cannot even define an encoding that can represent each element of Tcircle on a computer. In practise it means we simply deal with some countable subset of Tcircle (and therefore limit ourselves to a corresponding subset of all circles.

The relationship between the two possreps is embodied in the following:

  CtoE = { (t1,t2) in Tcircle x Tellipse |     Pcircle(t1) = Pellipse(t2) }

Since every circle is an ellipse, CtoE is the graph of a function that maps every tuple in Tcircle to a corresponding tuple in Tellipse that represents the same circle/ellipse value.

Since Pcircle, Pellipse aren't specified to the DBMS, we instead need to express CtoE directly. Of course that is very easy

   (ctr,r) |---> (ctr,r,r)

Expressing this using D&D type selectors we could express this as:

   CIRCLE(ctr,r) is-a ELLIPSE(ctr,r,r)

IMO this is cleaner (and indeed more practical) than the D&D syntax which seems to get it arse about. D&D syntax specifies how to map a subset of the ellipse values to matching circle values, by specifying a constraint and by expressing the possrep of CIRCLE in terms of the possrep of ELLIPSE. Received on Mon Feb 22 2010 - 06:20:12 CET