Re: Questions on possreps

From: Hugh Darwen <hughdarwen_at_gmail.com>
Date: Mon, 13 Jun 2011 04:40:04 -0700 (PDT)
Message-ID: <9e8a55fb-0ae3-4cbe-953b-fafd100439a1_at_m10g2000yqd.googlegroups.com>


On May 26, 5:04 am, David BL <davi..._at_iinet.net.au> wrote:
> On page 116 of An Introduction to Database Systems (8th edition) Chris
> Date [...]

David BL cites an example from that book and asks a lot of questions about possreps, sometimes using phrasing such as "Does Date think that ...", "Is it Date's position that ...".

The possrep concept arose in a joint work by me and Chris Date: "The Third Manifesto", which Erwin Smout has correctly referred to in his responses, both in this thread and the earlier one on David BL's alternative proposal. I have not had time to study the entire discussions in detail but I know Erwin understands our work very well and I doubt whether I would disagree with any of his responses.

David: I'm just wondering if you've actually been able to study The Third Manifesto, our proposed Inheritance Model, and the detailed rationales and discussions we have given in our books on this subject. The official versions of TTM and the IM are now in "Database Explorations" (Trafford, 2010) but "Databases, Types, and The Relational Model" (Addison-Wesley, 2007) is probably more useful because it contains the detailed discussions whereas the later book just explains why we made certain minor changes in the latest versions. If you haven't, you may find that those discussions give you answers to many of your questions. Also, my website www.thethirdmanifesto.com contains some material you might find useful, include the bare bones of TTM and the IM.

For now, I just hope the following points about possreps and selectors are clear:

  1. A selector S for type T is an operator that has certain special properties that we regard as required--and I mean required in a welldesigned computer language, and I realise that opinions as to what "well-designed" entails may differ. The special properties are, quite simply, (a) every invocation of S denotes a value of type T, and (b) for every value V of type T there is an invocation of S that denotes V.
  2. A possrep declaration is a way of defining a signature for a selector, along with a constraint (just like your own proposed definition for numerical division, which includes a constraint to the effect that the divisor, a value of type real, must not be zero). (Btw, your idea of applying a constraint on the parameters of any operator is one that I don't think occurred to me and Date, and I find it interesting.)
  3. At least one selector must be available for every type, from which it follows that for every value V of every type there will be at least one selector invocation that denotes V.
  4. If a selector S is defined by a possrep declaration, then the parameters for S correspond to the components of the possrep. We assume that if two invocations of S differ in at least one argument, then those two invocations denote different values. Thus, if we take possrep CARTESIAN(X REAL, Y REAL) for type POINT, then the operators THE_X(P POINT) and THE_Y(P POINT) are well defined: every point has exactly one X value and exactly one Y value. We assume that the declaration of such a possrep guarantees that users of the type in question will be able to develop whatever operators they desire for that type. (So, yes, a canonical form is needed in cases like the numerator/denominator possrep for type RATIONAL. That could be addressed in the physical representation, such that THE_NUM(RATIONAL(2,4)) and THE_DEN((RATIONAL(2,4)) yield 1 and 2, respectively--a bit of a tall order! It could also be addressed by a constraint on the possrep.

Some people have argued that selectors aren't always needed--in other words, they don't mind allowing a type to contain values that cannot be denoted by a single expression in the language. We admit that in practice nobody would want to invoke a selector to denote the entire content of the film "Gone with The Wind", a value of type Video, but we still think a well-designed language should make that a theoretical possibility. I don't think we could disagree with an alternative model that meets the same objectives as I have outlined above, nor would we necessarily disagree with one that fails to meet them but is perhaps intended for rather less general use, so long as its deficiencies and advantages are clear.

Hugh Darwen Received on Mon Jun 13 2011 - 13:40:04 CEST

Original text of this message