Rigel(ID:1519/rig002)Database language based on Pascal, used generators to produce tuples UC Berkeley "Rigel is a bright bluish star - the most luminous in the constellation Orion. We have followed a tradition of naming languages after mathematicians and astronomical bodies. Besides, it seemed such a nice name..." Structures: Related languages
References: RIGEL is an experimental general-purpose programming language for expressing relational database applications. The language, which is named after the brightest start in the constellation Orion, was developed at the Computer Science Department of the University of California at Berkeley, It is designed to overcome a perceived mismatch between conventional procedural languages and database "sublanguages." Specifically, RIGEL incorporates a number of database-oriented data types such as relation, view, and "tuple (the latter is not a tuple of a relation, but rather a reference to a tuple). The language also provides facilities to simplify the handling of collections of database structures, such as a for statement for iterating over sets of relational tuples, and a method for designating sets of tuples as arguments to procedures. The latter facilities are similar in spirit to the array facilities found in many general-purpose languages. In addition, RIGEL incorporates a number of features which have proven useful in database programming. An "external schema" mechanism is provided for interfacing the program to the database system and for defining the subset of the database to be accessed by the program. RIGEL borrows from MODULA the module construct for defining external schemata. A "view" mechanism is provided for defining and manipulating "views," that is, virtual relations which are derived from real or "base" relations. Views are defined through modules which specify a set of views and their relationship to base relations, as well as the set of operations to be allowed on views and their implementation via base relations. The problem of incorrect or ambiguous view updating is solved by restricting view update operations to those defined in a module, and by requiring the programmer to define the implementation of these operations in a manner which preserves database semantics. This solution, one of several considered by the designers, is pragmatic but seemingly contrary to the spirit of implementation independence for the programmer. A "database transaction" construct is provided which permits the programmer to delimit sequences of database update statements which are to be executed automatically. While cited as an aid to maintaining database integrity in the presence of multiple concurrent updating programs (a problem with which, ideally, programmers should not be concerned), the database transaction construct seems usable for delimiting sequences of statements for which database consistency constraints must be temporarily suspended. In RIGEL, database consistency constraints are maintained across single update statements, and it is not clear whether the database transaction construct was meant to extend this function to sequences of update statements. The term "data abstraction" in the title refers to the use of modules (a form of data abstraction) for defining external schemata and views. The use of conventional abstract data type definitions (i.e., one definition per abstract data type and all its associated operations) is considered for this purpose, but deemed not as useful to database programming as modules, for reasons explained in the paper. W. McGee, Los Altos, Calif. in ACM Computing Reviews 20(11) November 1979 view details INTRODUCTION Previous attempts at providing data base access in a programming language were based on embedding data base constructs into an existing language. This embedding was accomplished by calling subroutines to execute data base functions directly, by using a preprocessor to translate queries into subroutine calls. or by modifying an existing compiler. Although each of these attempts succeeded in providing access to the data base, the resulting programming environment was less than satisfactory. The data base constructs are not integrated into the language because the designers were constrained by the existing languages. RIGEL is an experimental general-purpose programming language designed for the development of data base applications. It offers a better programming environment because it was designed from the start with an emphasis on the language mechanisms needed to develop data base applications. These include relations, views. and tuples as built-in data types, a flexible notation for expressing relational queries which is integrated with the iteration constructs in the language, and a data abstraction facility which handles the interface between a program and a data base well. RIGEL is the language component of a sophisticated programming environment which provides interactive program development, intermixed interpretive and compiled execution of program components, and interactive debugging. Such an interactive programming environment gives a programmer powerful tools to support the rapid development of programs. By the time this paper appears, the first version of the system will be implemented. Other new languages designed expressly for data base applications are TAXIS and PLAIN. TAXIS seeks to make the development of applications easier by limiting the kinds of application which can be written in the language and by supporting a rigidly structured programming environment. The alternative is to code applications in a good general- purpose programming language using a Library of predefined abstractions designed specifically for the class of applications (e.g., procedures to display menus on a video terminal and to process user requests). As with many application-specific languages, it is not certain that TAXIS offers a clear advantage in program development time. In addition, the general-purpose language can be used to program a wider range of data base applications. PLAIN, on the other hand, is a general-purpose programming language which takes a different approach to both the expression of queries and data abstraction than the approach taken in RIGEL. In PLAIN, the programmer specifies how a high-level query is to be processed which means that programs may have to be recoded to take advantage of execution efficiencies resulting from a change to the data base storage structure. A more important difference is that, as will be shown, the data abstraction facility provided in RIGEL is better suited to defining the interface between a program and a data base than that provided in PLAIN. This paper presents the design of language constructs provided in RIGEL to express data base queries, to specify the interface between a program and a data base, and to use views. The notation for expressing queries is based on expressions which produce a sequence of values similar to that used in Relational PASCAL and discovered independently by Prenner. The use of these expressions has been generalized to allow sequences of values other than tuples (e.g., real) to be specified and to allow their use in contexts other than relation constructors (e.g., as parameters to procedures). This generalization results in a convenient, well-integrated notation for expressing queries which, for example, leads naturally to programmer-defined aggregate functions (e.g., standard deviation). The virtues of data abstractions as notations to describe interfaces to a data base have been extolled by researchers in programming languages and data base systems. Several language proposals exist with a data abstraction facility based on the concept of abstract data types. RlGEL has a data abstraction facility, based on a program structuring concept developed by Wirth which provides a better notation for specifying a data base interface that consists of several relations, views, and high-level abstract operations. Finally, the language supports views as a built-in data type. Both retrieval and update operations are provided on views. The view and data abstraction mechanisms were designed together so that views can be specified in an abstraction in such a way as to separate the view representation as seen by a user of the view from its implementation and to allow updates on views to be specified as high-level abstract operations. This approach enhances data independence because the implementation of view updates is isolated from the program. Moreover, view updates are specified explicitly so that a programmer knows precisely what set of updates are allowed, eliminating the uncertainty present in approaches based on automatically translating view updates in [ACM SIGMOD] Proceedings of the 1979 ACM SIGMOD international conference on Management of Data, Boston, Mass., May 30-June 1, 1979 view details in [ACM SIGMOD] Proceedings of the 1979 ACM SIGMOD international conference on Management of Data, Boston, Mass., May 30-June 1, 1979 view details in [ACM SIGMOD] Proceedings of the 1979 ACM SIGMOD international conference on Management of Data, Boston, Mass., May 30-June 1, 1979 view details in [ACM SIGMOD] Proceedings of the 1979 ACM SIGMOD international conference on Management of Data, Boston, Mass., May 30-June 1, 1979 view details |