054 Status of support for non-programmers

Associated with the relational approach is the concept of a relationally complete data sublanguage. Such a sublanguage has at least the retrieval power of a first order predicate calculus when applied to a collection of n-hierarchic relations of assorted degrees [14]. For users with interaction of unpredictable scope and complexity, such a capability is a basic one and should be augmented by a library of functions. For example, the functions COUNT, TOTAL, AVERAGE, MAXIMUM, MINIMUM, would be needed in almost any application environment, while functions that entail data-conditioned termination of iterated joins of a relation with itself are needed in product structure or family tree applications.

    • For non-programmers (abbreviated NP) it is essential that such an augmented, relationally complete, retrieval capability (abbreviated ARC) be provided without branching, explicit iteration, and cursors. When this condition is fulfilled, we refer to the retrieval capability as NP/ARC. A language will be said to have the NP/ARC capability if it not only provides relational completeness without branching, explicit iteration, and cursors, but includes provision for function invocation to condition the selection of data and to transform the data selected from the data base.

Examples of NP/ARC languages are ALPHA [13], the relational algebra [14,10], and SQUARE [17]. Examples of data sublanguages which do not possess the NP/ARC capability are GAMMA ZERO [12] and the DBTG data manipulation language. The effectiveness of this capability is illustrated in the appendix, where we re-code in ALPHA a sample data base and application which was originally coded in COBOL-DBTG by Frank and Sibley [9]. The re-coding in ALPHA results in the elimination of all GO TO statements (15 of them), all PERFORM UNTIL statements (one of them), and all currency indicators (i0 of them). We do not claim that the NP/ARC capability will always yield reductions of this magnitude. A payroll procedure, for example, might not be reduced at all by expressing it in an NP/ARC language. We can, however, expect the NP/ARC capability:

  1. to put many applications within the non-programmer’s reach, where programmers were previously a necessity;
  2. to increase the productivity of programmers on many, but not all, data base applications.

[…]

The architecture of RENDEZVOUS itself (Fig. 4) is based on the assumption that casual users will frequently misformulate their queries. Accordingly, the subsystem is designed to engage the user in clarification dialog about his query. At appropriate times, it can re-state in precise system English what it presently understands the user’s query to be.

[Fig. 4]

    1. User makes initial statement of his query (unrestricted English)
    2. System interrogates user about his query (to obtain information which is missing or hidden in language the system does not understand, and to resolve ambiguities)
    3. User responds to system interrogation
    4. System provides a re-statement of user’s query in system English (in a very precise way, based on the n-ary relational calculus)
  1. Codd, Edgar Frank/ Date, Christopher J. (1975). Interactive Support for Non-Programmers: The Relational and Network Approaches. Working Paper. In Proceedings of the 1974 ACM SIGFIDET workshop on Data description, access and control: Data models: Data-structure-set versus relational (SIGFIDET ’74). New York: Association for Computing Machinery. S.25.