Results 1 -
9 of
9
An Equational Chase for Path-Conjunctive Queries, Constraints, and Views
- In ICDT
, 1999
"... We consider the class of path-conjunctive queries and constraints (dependencies) defined over complex values with dictionaries. ..."
Abstract
-
Cited by 41 (11 self)
- Add to MetaCart
We consider the class of path-conjunctive queries and constraints (dependencies) defined over complex values with dictionaries.
Designing OQL: Allowing objects to be queried
- Information Systems
, 1998
"... Abstract | This paper tells the story of OQL, the standard query language of the Object Database Management Group (ODMG) [30]. The story starts in 1988, at INRIA in the Alta r Group y. The objective of that group was to develop an object-oriented database system [41]. This objective was reached: in ..."
Abstract
-
Cited by 25 (2 self)
- Add to MetaCart
Abstract | This paper tells the story of OQL, the standard query language of the Object Database Management Group (ODMG) [30]. The story starts in 1988, at INRIA in the Alta r Group y. The objective of that group was to develop an object-oriented database system [41]. This objective was reached: in September 1991 the O2 database system started its commercial career as the main product of a company called O2Technology [6]. As opposed to its competitors, O2 featured a full- edged query language named O2SQL [22]. The story goes on with the creation of the ODMG in 1991 and the adoption of O2SQL as the standard object query language under its new and nal name: OQL. During the following years, OQL went through some modi cations, the most important ofwhich resulted in OQL 1.2 that o ers some level of compliance with SQL92. On top of providing the expressive power of the SQL92 query language [54], OQL allows objects to be queried. This is a claim also supported by the upcoming SQL3. However, due to its adequacy to the object oriented type system and its functional nature, OQL is much simpler to learn, use and implement. A goal of this paper is to demonstrate this. This paper tells about the mistakes and pertinent choices we made while designing and implementing OQL. I hope it also conveys the great pleasure I had to be part of this adventure. Key words: Object-oriented database, query language 1.
Containment of Nested XML Queries
- In VLDB
, 2004
"... Query containment is the most fundamental relationship between a pair of database queries: a query Q is said to be contained in a query Q if the answer for Q is always a subset of the answer for Q , independent of the current state of the database. Query containment is an important problem in ..."
Abstract
-
Cited by 18 (2 self)
- Add to MetaCart
Query containment is the most fundamental relationship between a pair of database queries: a query Q is said to be contained in a query Q if the answer for Q is always a subset of the answer for Q , independent of the current state of the database. Query containment is an important problem in a wide variety of data management applications, including verification of integrity constraints, reasoning about contents of data sources in data integration, semantic caching, verification of knowledge bases, determining queries independent of updates, and most recently, in query reformulation for peer data management systems. Query containment has been studied extensively in the relational context and for XPath queries, but not for XML queries with nesting.
Semantics for Null Extended Nested Relations
- ACM TODS
, 1993
"... this paper we define the semantics of nested relations, which may contain null values, in terms of integrity constraints, called null extended data dependencies, which extend functional dependencies and join dependencies encountered in flat relational database theory. We formalise incomplete informa ..."
Abstract
-
Cited by 14 (1 self)
- Add to MetaCart
this paper we define the semantics of nested relations, which may contain null values, in terms of integrity constraints, called null extended data dependencies, which extend functional dependencies and join dependencies encountered in flat relational database theory. We formalise incomplete information in nested relations by allowing only one unmarked generic null value,
Object/Relational Query Optimization with Chase and Backchase
, 2000
"... Traditionally, query optimizers assume a direct mapping from the logical entities modeling the data (e.g. relations) and the physical entities storing the data (e.g. indexes), each physical entity corresponding precisely to one logical entity. This assumption is no longer true in non-traditional app ..."
Abstract
-
Cited by 12 (0 self)
- Add to MetaCart
Traditionally, query optimizers assume a direct mapping from the logical entities modeling the data (e.g. relations) and the physical entities storing the data (e.g. indexes), each physical entity corresponding precisely to one logical entity. This assumption is no longer true in non-traditional applications (object-oriented and semi-structured databases, data integration), which often exhibit a mismatch between the logical view and the actual storage of data. In addition, there is an increased amount of redundancy, even at the logical level, that can greatly enhance optimization opportunities, if exploited. To deal with all this, we propose a novel architecture for query optimization, in which physical optimization is leveraged at the level of query rewriting. As a consequence, the other important aspect of query optimization, semantic optimization (that takes advantage of the redundancy at the logical level), can be naturally incorporated. The optimizer can then make global decisions based on both semantic and physical knowledge, leading to plans of higher quality than those obtainable by a traditional two-level approach. The main idea
Extensions to the Relational Data Model
- Conceptual Modelling, Databases and CASE: An Integrated View of Information Systems Development. Jon
, 1992
"... this paper we give an overview of research on extensions of relational database technology. In order to systematically classify different ways to extend the data model we take a programming language point of view of data models: a data model consists of a set of basic (predefined) types, a set of ty ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
this paper we give an overview of research on extensions of relational database technology. In order to systematically classify different ways to extend the data model we take a programming language point of view of data models: a data model consists of a set of basic (predefined) types, a set of type constructors (or structuring primitives), and a set of operators (for the predefined as well as constructed types). Extensions to each of of these data model constituents are possible and have indeed been investigated in the past. Our presentation focuses on extensions to the type system (primitives and constructors) and those extensions to the operators that are implied by them. During the 1980's, there has been a significant trend in database research addressing the problem of supporting non-traditional database applications. Though relational database systems (RDBMSs) entered the commercial marketplace in the early eighties, it seemed clear that, at least without major enhancements, they would not be appropriate for non-business applications. Several research groups started out to either enhance RDBMS technology in several ways or to develop completely different models and systems. Throughout this paper we limit our scope to those investigations that tried to keep some of the characteristics of the relational model and/or systems. Attempts to make semantic data models operational, for instance, Entity-Relationship models, have already been discussed in this volume before. Also, extensions in query languages' expressive power to deal with recursion, will be surveyed in a subsequent series of articles, as will the object-oriented approaches. Therefore, we will take a more "conservative" approach, that is, stay closer within the original relational framework. The relationa...
The Nested Universal Relation Data Model
"... this paper we propose to alleviate the usability problem by providing logical data independence to the nested relational model. To this end we extend the (classical) UR model to nested relations by defining the nested universal relation model (nested UR model). In particular, we extend the weak inst ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
this paper we propose to alleviate the usability problem by providing logical data independence to the nested relational model. To this end we extend the (classical) UR model to nested relations by defining the nested universal relation model (nested UR model). In particular, we extend the weak instance approach to the UR model to the nested weak instance approach to the nested UR model. EXAMPLE 1.1. Schemas of nested relations are represented graphically by scheme trees [17], such as T shown in Fig. 1.1. The nested relation scheme (NRS) of T, denoted by R(T), is: 6 AIRLINE AIR_CODE (FLIGHT_NO (PASSENGER)* (CREW)*)* (AIRPORT PORT_CODE)*, where the higher order attributes are marked with * in order to distinguish them from the zero order attributes [1]. ################## ################## ################## # # # # ################## # # # # ################# ################# ############################### ############################### # # # # ############################### # # # # ############################### # # # # AIR_CODE AIRLINE CREW PASSENGER FLIGHT_NO AIRPORT PORT_CODE FIG. 1.1. The scheme tree T. A null extended nested relation (abbreviated to nested relation), r*, over the NRS, R(T), for the scheme tree, T, of Fig. 1.1, is shown in Fig. 1.2. We note that null denotes a generic null value, whose semantics are represented by the partial ordering, null is less informative than any non-null value [17]. The semantics of r* can be expressed by a set of null functional dependencies (NFDs) and a set of null extended functional dependencies (NEFDs), both of which are members of the class of null extended data dependencies [17]. The NFDs that are satisfied in r* are: AIRLINE AIR_CODE, AIR_CODE AIRLINE, AIRPORT PORT_CODE and PORT_CODE AIRPORT. That is,...
Supervisor of Dissertation
, 2000
"... I am indebted to Val Tannen, my advisor. This dissertation would not have been possible without his invaluable ideas, support, and advice. His deep insight into both elds of databases and programming languages, as well as his crucial advice in the experimental issues, made direct contributions to th ..."
Abstract
- Add to MetaCart
I am indebted to Val Tannen, my advisor. This dissertation would not have been possible without his invaluable ideas, support, and advice. His deep insight into both elds of databases and programming languages, as well as his crucial advice in the experimental issues, made direct contributions to this work. I have learned a great deal from him: where to look for ideas, how to solve problems, how to present them. I also have learned from him that most rewarding results are obtained by taking the path of investigating the foundations, even though this may not be the shortest path. Iamvery grateful to Peter Buneman and Susan Davidson, for their help, support, advice, suggestions and encouragement. I am thankful to Alin Deutsch who was always a source of inspiration. Many ideas coming from fruitful discussions with him have entered in this dissertation. I would like togivespecial thanks to Arnaud Sahuguet who always provided me with valuable suggestions and comments, as well as with expert help regarding system and implementation issues. Iwould like to thank the members of my thesis committee for their insightful comments, suggestions, questions and criticism: Peter Buneman, Susan Davidson, Daniela Florescu, Jean Gallier and Alon Levy. This work has also bene ted greatly from the discussions at the weekly Penn database seminar, whose members include (or included during my veyears of PhD study) Peter
A PC Chase
, 1998
"... PC stands for path-conjunctive, the name of a class of queries and dependencies that we define over complex values with dictionaries. This class includes the relational conjunctive queries and embedded dependencies, as well as many interesting examples of complex value and oodb queries and integrity ..."
Abstract
- Add to MetaCart
PC stands for path-conjunctive, the name of a class of queries and dependencies that we define over complex values with dictionaries. This class includes the relational conjunctive queries and embedded dependencies, as well as many interesting examples of complex value and oodb queries and integrity constraints. We show that some important classical results on containment, dependency implication, and chasing extend and generalize to this class.

