In previous papers [SC05, SBC+07], some of us predicted the end of “one size fits all ” as a commercial relational DBMS paradigm. These papers presented reasons and experimental evidence that showed that the major RDBMS vendors can be outperformed by 1-2 orders of magnitude by specialized engines in the data warehouse, stream processing, text, and scientific database markets. Assuming that specialized engines dominate these markets over time, the current relational DBMS code lines will be left with the business data processing (OLTP) market and hybrid markets where more than one kind of capability is required. In this paper we show that current RDBMSs can be beaten by nearly two orders of magnitude in the OLTP market as well. The experimental evidence comes from comparing a new OLTP prototype, H-Store, which we have built at M.I.T. to a popular RDBMS on the standard transactional benchmark, TPC-C. We conclude that the current RDBMS code lines, while attempting to be a “one size fits all ” solution, in fact, excel at nothing. Hence, they are 25 year old legacy code lines that should be retired in favor of a collection of “from scratch ” specialized engines. The DBMS vendors (and the research community) should start with a clean sheet of paper and design systems for tomorrow’s requirements, not continue to push code lines and architectures designed for yesterday’s needs. 1.

In this paper, we motivate and present a data model for conceptual design of structural and behavioural aspects of databases. We follow an object centered design paradigm in the spirit of semantic data models. The specification of structural aspects is divided into modelling of object structures and modelling of data types used for describing object properties. The specification of object structures is based on an Extended Entity--Relationship (EER) model. The specification of behavioural aspects is divided into the modelling of admissible database state evolutions by means of temporal integrity constraints and the formulation of database (trans)actions. The central link for integrating these design components is a descriptive logic-- based query language for the EER model. The logic part of this language is the basis for static constraints and descriptive action specifications by means of pre- and postconditions. A temporal extension of this logic is the specification language for tem...

Abstract not found

We survey the fundamental problems of designing general purpose, descriptive query languages for object-oriented database systems. Structural aspects of object models are investigated and their implications on the query language capabilities are analyzed and summarized as requirements that should be met by a `good' object-oriented query language. The type system of an OODB model has to distinguish atomic types (such as basic data types -- numbers, strings, -- or abstract object types) and constructed types (such as sets and tuples). Each of the type constructors should be supported by an adequate set of generic access and manipulation operators. The query language should allow orthogonal combination of operators according to the nesting structure of type constructors, the model should be closed against its operators, and the language should be adequate. The latter criterion ensures, for instance, that queries can be expressed that return objects instead of just data about objects ("object preservation"). Several recent proposals for query languages are evaluated against these criteria.

Kleisli is a modern data integration system that has made a significant impact on bioinformatics data integration. This paper contains a brief introduction to the Kleisli system and an example to illustrate its uses in the bioinformatics arena. The primary query language provided by Kleisli is called CPL, which is a functional query language whose surface syntax is based on the comprehension syntax. Kleisli is itself implemented using the functional language SML. So this paper also describes the influence of functional programming research that benefits the Kleisli system, especially the less obvious ones at the implementation level. Availability. Kleisli has been commercialized under the name "KRIS". It is available from Kris Technology Inc., 713 Santa Cruz Ave, #2, Menlo Park, CA 94025. Direct email to info@kris-inc.com and web browser to http://www.kris-inc.com. 1 Introduction The Kleisli system (Davidson et al., 1997) is an advanced broad-scale integration technology that has pro...

. Currently much effort is being spent on providing objectoriented databases with ad hoc query facilities. In this paper we present a SQL-like query calculus whose major contribution lies in its inherent orthogonality and rigorous mathematical foundation. The calculus is essentially a calculus of complex values but it is defined independently of any concrete database model. The calculus can be used to formulate queries in value-based and object-based data models. Moreover it provides a general facility for the manipulation of complex values. 1 Introduction Object-oriented database systems (OODB) are usually embedded in a programming language environment providing full computational power. Consequently, designers of OODB at first did not feel the need to integrate ad hoc query facilities into their systems. However, it has been recognized that some associative retrieval is of importance even for OODB [8, 12, 13]. A well-tried ad hoc query language is SQL. SQL came up with relational da...

We present a proposed query language for extended entity relationship schemas. The language improves on previous proposals by using only concepts explicitly in a given schema. It includes quantifiers and aggregates to allow complex queries to be expressed, and it allows derived subtypes, attributes and relationships to be defined and used in queries. Further extensions are discussed. 1

First and foremost, I'd like to thank my family, Chris and Nigel, who were always there for me. Chris resonated with my angst especially well. I'd like to thank my advisor, Don Batory, who alternately provided encouragement and impetus. Finally, I'd like to thank the folks of the Computer Science Department atCalPoly State University in San Luis Obispo, who generously provided computing and lab facilities. The University ofTexas at Austin

It is common knowledge that relational calculus and even SQL are not expressive enough to express recursive queries such as the transitive closure. In a real database system, one can overcome this problem by storing a graph together with its transitive closure and maintaining the latter whenever updates to the former occur. This leads to the concept of an incremental evaluation system, or IES. Much is already known about the theory of IES but very little has been translated into practice. The purpose of this paper is to ll in this gap by providing a gentle introduction to and an overview of some recent theoretical results on IES. The introduction is through the translation into SQL of three interesting positive maintenance results that have practical importance { the maintenance of the transitive closure of acyclic graphs, of undirected graphs, and of arbitrary directed graphs. Interestingly, these examples also allow ustoshow the relationship between power and cost in the incremental maintenance of database queries. 1

We present general principles of modern programming languages and discuss requirements which have to be observed during the development of integrated object-oriented query/programming languages and their theories. The requirements stem mostly from aesthetic criteria, but we argue they have the fundamental meaning for pragmatic aspects of such languages. We propose a basis for building systems satisfying these requirements. In this basis the role of an environment stack and naming-scoping-binding issues is central. Object-oriented database query/programming languages require modifications of the construction of the classical programming languages' stack. In particular, they need the separation of the stack from an object store, as well as macroscopic binding. This makes it possible to define query operators directly by operations on the stack. Such a query language can be easily integrated with macroscopic imperative statements, programming abstractions (procedures, views, modules), and...