Glue-Nail(ID:5793/glu004)Hybrid database language, formed by combining Nail with Glue. Has a special target language IGlue (pronounced igloo) Related languages
References: The Glue language grew out of our experiences of designing and implementing the first NAIL! system [3], and of using commercial database systems. From a software engineering point of view, declarative logic based languages offer many advantages over traditional relational databases, primarily due to their simplicity and high-level approach (for example, see the introductions of [4] and [10]). Relational database systems free the programmer from worrying about the physical data representation and access methods. Deductive database systems do the same for views and recursion. One currently unsolved problem with declarative languages is how to integrate them into a full system without becoming tangled in the impedance mismatch problem (described below). This is a problem which has plagued traditional database systems. Glue- Nail is designed to solve it. There is no precise definition of "declarative", although most people would agree that in a declarative language, the programmer states what is desired, not how to do it. Hence declarative languages significantly reduce the amount of code that a programmer must write for a given application. In addition, the code that the programmer must write is more strongly focused on the actual application, rather than on the technical details of a particular solution algorithm. This focusing effect should reduce the number of mismatches between the application specification and the programmer’s implementation. Unfortunately there are certain operations which implicitly have a notion of state, for example Input/ Output (1/0) and EDBl updates. These operations have side effects which cannot be easily captured in logic.2 Any real application language must be able to perform 1/0 and EDB update operations; they cannot be ignored. Computations involving side effects cannot be written declaratively because the programmer must be able to specify the order in which the side effects occur. In other words the programmer must give the intermediate steps in the computation. Procedural languages are well suited to describing such computations, declarative languages are not. We feel that the increase in programming efficiency provided by a declarative language is very important, and so we have preserved the declarative nature of NAIL!. Hence we need another (procedural) language to complement NAIL!. This language is Glue. Embedding a query language in a procedural language is common in databases, for example, embedding SQL in C. Unfortunately we then usually run into the impedance mismatch problem (for an example description, see [4]). This is the name for the collection of problems that arise when we interface two dissimilar languages. It has no formal academic definition, but it is a serious problem in real programming systems. The problems include differing type systems, set oriented versus t uple oriented comput at ion, differing data lifetime, wildly differing syntax, and an inability to carry optimizations across the interface. For example, SQL uses the relation as the basic data type. C uses single valued variables, so C is a tuple oriented language. When SQL is merged with C the concept of a cursor has to be introduced so that C can iterate (or recurse) over all the elements in the SQL relation. SQL has efficient set oriented algorithms for dealing with relations, but C does not. An even more serious efficiency problem is that a two language system has two separate optimizers. Each individual SQL query is optimized independently, without any reference to other nearby SQL queries. To avoid these problems, Glue was designed to resemble NAIL! as closely as possible. Both languages have tuples and relations aa their basic data objects, "all-solution" computation, similar syntaxes, and identical type systems. For example, in Glue a subgoal can be a NAIL! predicate, or an EDB relation or a Glue procedure. The syntax and behavior is the same in all three cases. In each case the subgoal returns a set of tuples. We expect that an application programmer will write the declarative, query oriented sections of the application in NAIL!, using Glue mostly for the interface and for EDB modifying code. Sometimes it might be useful to use Glue for a particularly speed-critical query, for which an especially efficient special purpose algorithm is known. Such a practice is analogous to writing speed critical sections of a C program in assembler; there is an increase in speed, but at the expense of clarity. The remainder of the paper is organized as follows. Section 2 discusses the basic data and predicate types. Section 3 is a tutorial introduction to the basic Glue assignment statement. Section 4 describes Glue procedures. In Section 5 we describe Glue-Nail’s set system. We also discuss higher-order programming in general. Section 6 briefly describes Glue’s module system. Section 8 briefly describes three other deductive database systems (LDL, CORAL, and Aditi), and compares their approaches with Glue-Nail. In Section 9 we describe the current experiment al implementation. Section 10 discusses some known problems with Glue-Nail, and what we are planning to do with Glue-Nail. in Proceedings of the 1991 ACM SIGMOD Conference on Management of Data view details in Proceedings of the 1991 ACM SIGMOD Conference on Management of Data view details A current focus of database systems research is the design of programming languages and systems to support non-traditional database applications such as computer aided design, software engineering, and financial analysis. The Glue-Nail database system, which was developed at Stanford University, provides two complementary languages for programming such applications. The Glue procedural language augments relational-style queries with control structures, update operations, and I/O. The Nail declarative language provides rules for expressing complex recursive queries or views. The purpose of this article is to describe the design and implementation of the Glue-Nail database system. In particular we focus on how we optimized the output or the performance of each major component of the system. We describe a set of benchmark application programs and present performance results that demonstrate the synergetic effects of these optimizations. We also compare a Glue- Nail application with a version written in C and evaluate the design of Glue based on our experiences with the system. We begin by reviewing the background and underlying design philosophy of the Glue-Nail system. Glue-Nail evolved from NAIL! (Morris et al., 1986, 1987), a deductive database system that featured a logic-based query language, Nail. 1 Logic- based query languages such as Nail have proved to be powerful query languages, but have weaknesses as well as strengths. Because logic is side-effect free and declarative (i.e., the execution order is unspecified), queries can be expressed dearly and optimized easily. But the logical basis is also a weakness because there are operations, such as updating the database and performing I/O, which do have side effects, and hence require a procedural language (i.e., a language where the execution order/s specified). To become a useful database language, Nail needs procedural operations, yet these very same operations are at odds with the semantics of Nail. Our solution is the two language architecture of Glue-Nail. Nail provides all the strengths of a logic-based query language. Glue complements Nail with procedural features. The problem with this approach is that it involves the design of yet another programming language. The new language must offer significant advantages over existing languages, C/C+ + and Prolog being the main contenders. Glue was designed to offer such advantages by reducing the impedance mismatch problem with Nail. Glue is much closer in semantics and syntax to Nail than C+ +. Glue has one advantage over Prolog, notably that both Glue and Nail are set-oriented, whereas Prolog is tuple-oriented. A major part of Glue is the Nailog term syntax system (a variant of HiLog). The Nailog term syntax allows a subgoal to have a variable as its predicate name. For example, the term Z(X,Y) has the variable Z as its predicate name. In most other logic-based languages, the predicate name must be known at compile time. The Nailog system gives the programmer additional power and flexibility. in The VLDB Journal, Special Issue on Prototypes of Deductive Database Systems, 3(2) April 1994 view details |