Generating Queries from Complex Type Definitions (original) (raw)

Typed query languages for databases containing queries

Information Systems, 1999

This paper introduces and studies the relational meta a@ebm, a statically typed extension of the relational algebra to allow for meta programming in databases. In this meta algebra one can manipulate database relations involving not only stored data values (as in classical relational databases) but also stored relational algebra expressions. Topics discussed include modeling of advanced database applications involving "procedural data"; desirability as well as limitations of a strict typing discipline in this context; equivalence with a first-order calculus; and global expressive power and non-redundancy of the proposed formalism.

Between Types and Tables - Using Generic Programming for Automated Mapping between Data Types and Relational Databases

In today's digital society, information systems play an im- portant role in many organizations. While their construction is a well understood software engineering process, it still requires much engineer- ing eort. The de facto storage mechanism in information systems is the relational database. Although the representation of data in these databases is optimized for ecient storage, it is less suitable for use in the software components that manipulate the data. Therefore, much of the construction of an information system consists of programming translations between the database and a more convenient representation in the software. In this paper we present an approach which automates this work for data entry applications, by providing generic versions of the elementary CRUD (Create, Read, Update, Delete) operations. In the spirit of model based development we use Object Role Models, which are normally used to design databases, to derive not only a database, but also a set of data...

Integrating Programming Languages & Databases: What’s the Problem

The problem of integrating databases and programming languages has been open for nearly 45 years. During this time much progress has been made, in exploring specialized database programming languages, orthogonal persistence, object-oriented databases, transaction models, data access libraries, embedded queries, and object-relational mapping. While new solutions are proposed every year, none has yet proven fully satisfactory. One explanation for this situation is that the problem itself is not sufficiently well defined, so that partial solutions continue to be proposed and evaluated based upon incomplete metrics, making directed progress difficult. This paper is an attempt to clarify the problem, rather than propose a new solution. We review issues that arise on the boundary between programming languages and databases, including typing, optimization, and reuse. We develop specific criteria for evaluating solutions and apply these to the solution approaches mentioned above. The analysis shows that progress has been made, yet the key problem of meeting all the criteria simultaneously remains open. Updated 10/12/2005. So the solution's easy enough; each of us stays put in his or her corner and takes no notice of the others. You here, you here, and I there. Like soldiers at our posts. Also, we mustn't speak. Not one word. That won't be difficult; each of us has plenty of material for self-communings. -Huis Clos (No Exit) by Jean Paul Sartre

On type systems for object-oriented database programming languages

2002

Abstract The concept of an object-oriented database programming language (OODBPL) is appealing because it has the potential of combining the advantages of object orientation and database programming to yield a powerful and universal programming language design. A uniform and consistent combination of object orientation and database programming, however, is not straightforward.

The sol object-oriented database language

Lecture Notes in Computer Science, 1992

SOL is a language for databases with tuples, sets, lists, object-identity and multiple inheritance. Other features of SOL are: The existence of a generic type which allows the definition of the schema by stepwise refinements, and the use of null values to express incomplete information in objects. A uniform way of coding both methods and programs is provided through an algebra for objects. The algebra is used both for querying and updating a SOL database. SOL has been defined and implemented as part of the Esprit-lI project 2443 "Stretch". 1 INTRODUCTION This paper presents an overview of SOL (Stretch Object-Oriented database Language). The main features of SOL am summarized as follows: 9 The SOL data model is a typical object-oriented data model, with inheritance hierarchies and object sharing. A novel feature of the SOL data model is existence of a generic type which allows the definition of a SOL schema by step-wise refinements. 9 Null values are used to express incomplete information for objects. 9 An algebra for objects, called EREMO, is used both for coding methods and programs. EREMO is used both for expressing SOL queries and updates. In this way, in contrast to other object-oriented database languages, for example the one of O2 [Lecluse et a189], and ORION [Kim89], there is no need to distinguish between the language for implementing methods (in most cases an imperative language) and the language for expressing nonprocedural queries (in most cases an SQL-like set-oriented language). The SOL approach solves the "impedance mismatch" problem which still exists, despite all, in many of the proposed object-oriented database languages [BCD89], [CDLR89], [Kim89], [OOP88]. The EREMO algebra respects the encapsulation principle and takes advantage of inheritance hierarchies and object identifiers. SOL has been implemented on top of the ALGRES advanced nested-relational system. ALGRES is a powerful rapid prototyping platform which offers an extended nested relational data-model and a language for data definition and manipulation based on an extended algebra for nested relations [Ceri et al.88], [CCLLZ90]. This paper presents the main features of SOL: The data model in Section 2, and the algebra for objects in Section 3. Each of the two sections also includes a comparison with recent similar proposals. The conclusions are reported in section 4. In Appendix we show a simplified version of an application implemented in SOL in the context of the STRETCIt project.

Query Language Construction

The book presents the Stack-Based Approach (SBA) which is a formal methodology addressing database query and programming languages. In SBA we reconstruct query languages' concepts from the point of view of programming languages (PL). The approach is motivated by our belief that there is no definite border line between querying and programming; thus there should be a universal theory that uniformly covers both aspects. SBA offers a unified and universal conceptual and semantic basis for queries and programs involving queries, including programming abstractions such as procedures, functions, classes, types, methods and views. SBA assumes a semantic specification method that is referred to as abstract implementation. It is a kind of operational semantics where one has to determine precisely on an abstract level all the data structures that participate in query/program processing, and then, to specify the semantics of all the languages' operators in terms of actions on these structures. SBA introduces three such structures that are well-known in the specification of PLs: (1) an object store, (2) an environment stack, (3) a query result stack (thus the stack-based approach). These structures are fundamental for precise semantic description of everything that may happen in database query/programming languages. In particular, classical query operators, such as selection, projection, joins and quantifiers, can be generally and precisely specified using the above abstract structures, with no references to classical database theories such as relational/object algebras or calculi. SBA introduces a model query and programming language Stack-Based Query Language (SBQL). It plays the same role as the relational algebra for the relational model, but SBQL is incomparably more powerful. The power of SBQL concerns a wide spectrum of data structures that is able to serve and complete algorithmic power of querying and manipulation capabilities. At the same time, SBQL is fully precise with respect to the specification of semantics. SBQL has been carefully designed from the pragmatic (practical) point of view. We were struggling severely with parasite syntactic sugar, redundant operators and semantic reefs (when human intuitive semantics does not match machine semantics). The pragmatic quality of SBQL is achieved by orthogonality of introduced data/object constructors, orthogonality of all the language constructs, object relativism, orthogonal persistence, typing safety, introducing all the classical and some new programming abstractions and following commonly accepted programming languages' principles. SBA and SBQL are neutral to database models. SBA covers all the database models that we are aware of, starting from the relational model, through XML-oriented data model, RDF-oriented data model, up to sophisticated object-oriented models with static and dynamic inheritance, collections, associations, polymorphism, etc. Our fundamental assumption is that SBA and SBQL address data structures rather than data models. Once we determine how particular concepts in a data model are to be mapped as abstract data structures, we can propose a corresponding SBQL variant that will be able to handle these structures with full algorithmic universality and precision. In this way we have shifted the discussion of query language to another level: we can talk about how particular features of data structures are to be served by SBQL rather than sticking to a concrete query language with a concrete data model. For instance, when we determine how XML files are to be mapped as abstract data structures, we can propose an SBQL variant to address them. In this way, we achieve a unique universality, flexibility and performance optimization potential. In particular, SBQL is the first and only query language that deals with dynamic object roles and dynamic inheritance. Moreover, powerful query optimization methods that are developed for SBQL are prepared to work with such advanced features. This book is a specification of the SBA theory and the SBQL language. It contains general observations on syntax, semantics and pragmatics of query and programming languages for objectoriented database models. General assumptions for the SBQL semantics are also presented. Then, the book deals with abstract object store models as main components of the concept of state, in particular: AS0 store model (complex objects and pointer links), AS1 store model (classes, methods and inheritance), AS2 store model (dynamic object roles and dynamic inheritance) and AS3 store model (encapsulation and information hiding). In the following the environment stack (ENVS), query results and query result stack (QRES) and the function nested are introduced. These concepts form the formal basis for SBQL semantics which is defined in the operational style through abstract implementation. The core of the semantics are so-called non-algebraic operators (selection, projection, navigation, join, quantifiers, etc.), which remain algebraic operators from the relational algebra, but their general

Types and persistence in database programming languages

ACM Computing Surveys, 1987

Traditionally, the interface between a programming language and a database has either been through a set of relatively low-level subroutine calls, or it has required some form of embedding of one language in another. Recently, the necessity of integrating database and programming language techniques has received some long-overdue recognition. In response, a number of attempts have been made to construct programming languages with completely integrated database management systems. These languages, which we term database programming languages , are the subject of this review. The design of these languages is still in its infancy, and the purpose of writing this review is to identify the areas in which further research is required. In particular, we focus on the problems of providing a uniform type system and mechanisms for data to persist. Of particular importance in solving these problems are issues of polymorphism, type inheritance, object identity, and the choice of structures to r...

A Framework for Comparing Type Systems for Database Programming Languages

1989

Several proposals have been published in recent years for database programming languages (DBPLs), many of which have been object-oriented. Our goal in this paper is not to argue for or against specific solutions, but simply to provide a framework for comparing certain critical points of type system design. This framework may be used in the description of a DBPL. It is our hope that the framework will promote clear communication among designers and developers of DBPLs.