DBPL(ID:1393/dbp001)Procedural language with relational database constructs. A successor to Pascal/R and Modula/R. Hamburg 1988 DBPL is a type-complete modular database programming language that extends Modula-2 orthogonally by a data type relation, access abstractions, persistent modules and transactions. Structures: Related languages
References: This fist part of this document is intended for users of the DBPL system and gives an introduction into the DBPL language concepts and illustrates their use in a larger modular database application. The second part gives some insight into the implementation of the DBPL system. As of today, the DBPL system exists in two fully source code compatible implementations, VAX/VMS DBPL and Sun DBPL. Both are written entierly in Modula-2 and consist of a compilation and a run time environment. The multi-user run time system is highly portable and runs under VAX/VMS 6.1, SunOS 4.1, IBM AIX 3.2 and IBM OS/2. Both DBPL systems can be integrated deeply into commercially available software development environments (NSE, SCCS, CMS) and provide optimized transactional multi-user access not only to type-complete DBPL databases but also to external relational databases via a fully transparent SQL gateway. This fist part of this document is intended for users of the DBPL system and gives an introduction into the DBPL language concepts and illustrates their use in a larger modular database application. The second part gives some insight into the implementation of the DBPL system. As of today, the DBPL system exists in two fully source code compatible implementations, VAX/VMS DBPL and Sun DBPL. Both are written entierly in Modula-2 and consist of a compilation and a run time environment. The multi-user run time system is highly portable and runs under VAX/VMS 6.1, SunOS 4.1, IBM AIX 3.2 and IBM OS/2. Both DBPL systems can be integrated deeply into commercially available software development environments (NSE, SCCS, CMS) and provide optimized transactional multi-user access not only to type-complete DBPL databases but also to external relational databases via a fully transparent SQL gateway. 1 The Rationale behind DBPL The DBPL language orthogonally integrates sets and first-order predicates into the strongly and statically typed programming language Modula-2. The DBPL environment supports the language with full database functionality including persistence, query optimization and transaction management. The application of modern language technology to database concepts results in new insights into the relationship between types and schemas, expressions/iterators and queries, selectors and views, or functions and transactions. Furthermore, it allows the exploitation of type theory and formal semantics of programming languages and thus connects database application development with results from program specification and verification. Section 1 reviews the rationale behind the design of the language and the implementation of the DBPL environment. The subsequent sections define the elements of the language. This definition is not intended as a programmer's tutorial (see [SM91a, MS92, MSS91]). It is intentionally kept concise, and in a sense, minimal. Its function is to serve as a reference for programmers, implementors, and manual writers, and as an arbiter, should they find disagreement. The first DBPL language definition was published in [EEK + 85]. A later revision [SEM88] removed several limitations on the orthogonality of language constructs. The current version of the report corrects minor ambiguities and errors of its predecessor and is based on the Modula-2 Report by N. Wirth as published in N. Wirth: Programming in Modula-2, Springer-Verlag, Berlin, Heidelberg, New York, 3rd Edition, 1985. All modifications to the Modula-2 Report are indicated at the margins. 1.1 On Data-Intensive Applications The development of data-intensive applications, such as information systems or design applications in mechanical or software engineering, involves requirements modeling, design specification, and, last but not least, the implementation and maintenance of large database application programs. Although the database programming language DBPL concentrates on the last issue and offers a uniform and consistent framework for the efficient implementation of entire database applications, DBPL was designed, extended and evaluated with a declarative style in mind. Data-intensive applications may be characterized by their needs to model and manipulate heavily constrained data that are long-lived and shared by a user community. These requirements result directly from the fact that databases serve as (partial) representations of some organizational unit or physical structure that exist in their own constraining context and on their own time-scale independent of any computer system. Due to the size of the target system and the level of detail by which it is represented, such representational data may become extremely voluminous -- in current data-intensive applications up to O(10 9 ) or even higher. In strong contrast to the need for global management of large amounts of representational data, data-intensive applications also have a strong demand to process small amounts of local computational data that implement individual states or state transitions. In essence, it is that broad spectrum of demands -- the difference in purpose, size, lifetime, availability etc. of data -- and the need to cope with all these demands within a single conceptual framework that has to guide the design of a database programming language. DBPL is a successor of Pascal/R [Sch77] and addresses the above issues by incorporating a set- and rule-based view of extended relational database modelling into the well-understood system programming language Modula-2. DBPL extends Modula-2 into three dimensions:
1.2 Conceptual Foundations of DBPL The leitmotiv behind the DBPL design was simplicity and power by orthogonality. DBPL aims at exploiting and integrating a solid, well-understood conceptual framework capable to consistently capture the wide range of data-intensive application requirements outline above --- and not the desire to implement new theoretical concepts in isolation. Classical type systems and the relational data model constitute the cornerstones of the DBPL language design. Both contributions provide an enlightening foundation from a technological as well as from a theoretical point of view. However, the exciting new experiences are made at the borderline where types (and expressions, selectors, functions : : : ) and data models (and queries, views, transactions : : : ) meet and have to be understood, one in the light of the other. During DBPL development, several, mostly unnecessary and ad-hoc restrictions on the programming language as well as on the data model became obvious. Some limitations, as, for example, the lack of data type orthogonality (i.e. the restriction to first normal form relations) had already been realized, others, like orthogonal persistence (providing persistence for all types, not just for relations) were new for the database community (but already discovered by the persistent programming language people). Other insights as, for example, the relationship between abstract access expressions and queries, iterators and views, or between recursive access expressions and deductive databases, came as surprises, at least to us. Globally speaking, the DBPL language and system both heavily rely on conceptual and theoretical input from following areas:
In summary, one can say that the DBPL project stayed more or less inside the boundaries drawn by conventional language technology (e.g. by mathematical typing schemes) and concentrated on improving the linguistic support for state-of-the-art database technology. Currently, however, we are heavily intrigued by novel programming language concepts (e.g. by taxonomical typing schemes [Car88]) and are quite positive that they provide the basis for substantial extensions of database technology [MS91]. The DBPL language design is also influenced by requirements of the DAIDA environment for database application development [SWBM89, BJM + 89, JMW + 90] that asks for a target language that makes extensive use of sets and first-order predicates, and provides a complete separation of typing and persistence. The main guideline for the design of DBPL can be characterized by the slogan "power through orthogonality". Instead of designing a new language from scratch (with its own naming, binding, scoping and typing rules), DBPL extends an existing language and puts particular emphasis on the interoperability of the new "database" concepts with those already present in the programming language. In particular, DBPL aims to overcome the traditional competence and impedance mismatch between programming languages and database management systems by providing
Implementation details (e.g., storage layout of records, clustering of data, existence of secondary index structures, query evaluation strategies, concurrency and recovery mechanisms) are deliberately hidden from the DBPL programmer. A key idea in the design and implementation of DBPL is to let the runtime system choose appropriate implementation strategies based on "high-level" information extracted from the application programs. As it turns out, the widespread use of access expressions (i.e. first-order logic abstractions of bulk data access) in typical DBPL programs facilitates such an approach. DBPL also follows Modula-2 by occasionally sacrificing "language orthogonality" out of engineering and efficiency considerations. For example, DBPL does not support persistence of pointers and procedure variables. This was not only motivated by the predominance of associative identification mechanisms in the classical Relational Data Model, but also by the far-reaching consequences of this identification mechanism on the concurrency control and distribution support [BJS86, JLRS88]. Modula-2 was chosen as the basis for DBPL because of its software engineering qualities. It provides a clear module concept and a strict type system and is further excelled by its balance between simplicity and expressive power. Finally, our group had a long tradition in Modula-2 compiler construction. A design decision with far-reaching consequences is the compatibility between DBPL and Modula-2. DBPL is designed to be fully upward compatible with Modula-2, i.e. every correct Modula-2 program has to be correct DBPL program. This decision not only limits the freedom in language extensions (e.g. the keyword SET is already used for bit sets in Modula-2 and is not available for "true" sets in DBPL), but also forces adherence to language mechanisms (e.g. variant records, string handling, local modules) for which nowadays "better" solutions are available. The main advantage of our compatibility decision is to lower the conceptual and technological burden for DBPL users since they do not have to learn yet another language. Furthermore, this decision allows to smoothly integrate DBPL into existing, fully-fledged software development environments (e.g. debuggers, profilers or version managers), to benefit from software libraries and from the interfaces to a variety of other languages and systems. In contrast to some persistent programming languages, the evolution of database schemata and of application programs is left outside the scope of DBPL. This was based on the insight that this is a complex issue in itself that should be delegated to a specific environment (see DAIDA environment, e.g. [JMW + 90]). To summarize, the most prominent feature of the DBPL language is the type-complete integration of sets and first-order predicates into a strongly typed, monomorphic language with persistence as an orthogonal property of individual compilation units. The DBPL system is further characterized by covering a wide range of operational database demands, such as query optimization, transaction and distribution management and computer-aided support for database application development. Readers interested in specific language and system aspects are referred to the following publications [JLS85, JGL + 88, MS89, SGLJ89, SM89, SM90a, SM90b, SM91b] |