scispace - formally typeset
Search or ask a question
Journal ArticleDOI

Maximal objects and the semantics of universal relation databases

TL;DR: In this article, the authors propose maximal objects, which modifies the universal relation concept in exactly those situations where it appears to go awry when the underlying relational structure has "cycles".
Abstract: The universal relation concept is intended to provide the database user with a simplified model in which he can compose queries without regard to the underlying structure of the relations in the database. Frequently, the lossless join criterion provides the query interpreter with the clue needed to interpret the query as the user intended. However, some examples exist where interpretation by the lossless-join rule runs contrary to our intuition. To handle some of these cases, we propose a concept called maximal objects, which modifies the universal relation concept in exactly those situations where it appears to go awry—when the underlying relational structure has “cycles.” We offer examples of how the maximal object concept provides intuitively correct interpretations. We also consider how one might construct maximal objects mechanically from purely syntactic structural information—the relation schemes and functional dependencies—about the database.
Citations
More filters
Proceedings ArticleDOI
09 Jun 2008
TL;DR: A new schema-mapping technique for multi-tenancy called Chunk Folding is described, where the logical tables are vertically partitioned into chunks that are folded together into different physical multi-Tenant tables and joined as needed.
Abstract: In the implementation of hosted business services, multiple tenants are often consolidated into the same database to reduce total cost of ownership. Common practice is to map multiple single-tenant logical schemas in the application to one multi-tenant physical schema in the database. Such mappings are challenging to create because enterprise applications allow tenants to extend the base schema, e.g., for vertical industries or geographic regions. Assuming the workload stays within bounds, the fundamental limitation on scalability for this approach is the number of tables the database can handle. To get good consolidation, certain tables must be shared among tenants and certain tables must be mapped into fixed generic structures such as Universal and Pivot Tables, which can degrade performance.This paper describes a new schema-mapping technique for multi-tenancy called Chunk Folding, where the logical tables are vertically partitioned into chunks that are folded together into different physical multi-tenant tables and joined as needed. The database's "meta-data budget" is divided between application-specific conventional tables and a large fixed set of generic structures called Chunk Tables. Good performance is obtained by mapping the most heavily-utilized parts of the logical schemas into the conventional tables and the remaining parts into Chunk Tables that match their structure as closely as possible. We present the re sults of several experiments designed to measure the efficacy of Chunk Folding and describe the multi-tenant database testbed in which these experiments were performed.

321 citations

Journal ArticleDOI
TL;DR: The universal relation model aims at achieving complete access-path independence in relational databases by relieving the user of the need for logical navigation among relations, and the assumptions underlying it are clarified.
Abstract: The universal relation model aims at achieving complete access-path independence in relational databases by relieving the user of the need for logical navigation among relations. We clarify the assumptions underlying it and explore the approaches suggested for implementing it.The essential idea of the universal relation model is that access paths are embedded in attribute names. Thus attribute names must play unique “roles.” Furthermore, it assumes that for every set of attributes there is a basic relationship that the user has in mind. The user's queries refer to these basic relationships rather than to the underlying database.Two fundamentally different approaches to the universal relation model have been taken. According to the first approach, the user's view of the database is a universal relation or many universal relations, about which the user poses queries. The second approach sees the model as having query-processing capabilities that relieve the user of the need to specify the logical access path. Thus, while the first approach gives a denotational semantics to query answering, the second approach gives it an operational semantics. We investigate the relationship between these two approaches.

308 citations

Journal ArticleDOI
TL;DR: FLEX as discussed by the authors is a user interface to relational databases that adapts flexibility and transparently to their level of correctness and well-formedness, providing interpretations of corresponding accuracy and specificity.
Abstract: FLEX a user interface to relational databases, can be used satisfactorily by users with different levels of expertise. FLEX is based on a formal query language, but is tolerant of incorrect input. It never rejects queries; instead, it adapts flexibility and transparently to their level of correctness and well-formedness, providing interpretations of corresponding accuracy and specificity. The most prominent design feature of FLEX is the smooth concatenation of several independent mechanisms, each capable of handling input of decreasing level of correctness and well-formedness. Each input is cascaded through this series of mechanisms until an interpretation is found. FLEX is also cooperative. It never delivers empty answers without explanation or assistance. By following up each failed query with a set of more general queries, FLEX determines whether an empty answer is genuine, in which case it suggests related queries that have nonempty answers, or whether it reflects erroneous presuppositions on the part of the user, in which case it then explains them. >

286 citations

Proceedings Article
01 Jan 1987
TL;DR: FLEX is a user interface to relational databases that is tolerant of incorrect input and salvages incorrect queries if they include enough clues on their intended meaning; suggests educated guesees if it recognizes metadata tokens in the input.
Abstract: FLEX is a user interface to relational databases that is tolerant of incorrect input. FLEX never rejects a query; instead, it adjusts to the level of technical expertise its users seem to possess (as judged from their input). In particular, FLEX understands formal queries; salvages incorrect queries if they include enough clues on their intended meaning; suggests educated guesees if it recognizes metadata tokens in the input; or else, it issues browsing requests for recognized data tokens. FLEX is also cooperative. It never delivers null results without explanation and assistance. By following up each failed query with a set of more general queries, FLEX determines whether a null result is genuine (it then suggests related queries that have non-null results), or whether it reflects erroneous presuppositions on behalf of the user (it then explains them).

139 citations

Journal ArticleDOI
TL;DR: The complexity results and the algorithmic approaches given in this paper should allow for the construction of cooperative facilities which identify MFSs and XSSs for database systems and are relevant to a number of problems outside of databases too, and may find further application.
Abstract: When a query fails, it is more cooperative to identify the cause of failure, rather than just to report the empty answer set. When there is not a cause per se for the query's failure, it is then worthwhile to report the part of the query which failed. To identify a Minimal Failing Subquery (MFS) of the query is the best way to do this. (This MFS is not unique; there may be many of them.) Likewise, to identify a Maximal Succeeding Subquery (XSS) can help a user to recast a new query that leads to a non-empty answer set. Database systems do not provide the functionality of these types of cooperative responses. This may be, in part, because algorithmic approaches to finding the MFSs and the XSSs to a failing query are not obvious. The search space of subqueries is large. Despite work on MFSs in the past, the algorithmic complexity of these identification problems had remained uncharted. This paper shows the complexity profile of MFS and XSS identification. It is shown that there exists a simple algorithm for finding an MFS or an XSS by asking N subsequent queries, in which N is the length of the query. To find more MFSs (or XSSs) can be hard. It is shown that to find N MFSs (or XSSs) is NP-hard. To find k MFSs (or XSSs), for a fixed k, remains polynomial. An optimal algorithm for enumerating MFSs and XSSs, ISHMAEL, is developed and presented. The algorithm has ideal performance in enumeration, finding the first answers quickly, and only decaying toward intractability in a predictable manner as further answers are found. The complexity results and the algorithmic approaches given in this paper should allow for the construction of cooperative facilities which identify MFSs and XSSs for database systems. These results are relevant to a number of problems outside of databases too, and may find further application.

131 citations

References
More filters
01 Jan 1980
TL;DR: A large part of as mentioned in this paper is a description of relations, their algebra and calculus, and query languages that have been designed using these concepts, and explanations of how the theory can be used to design good systems.
Abstract: A large part is a description of relations, their algebra and calculus, and the query languages that have been designed using these concepts. There are explanations of how the theory can be used to design good systems. A description of the optimization of queries in relation-based query languages is provided, and a chapter is devoted to the recently developed protocols for guaranteeing consistency in databases that are operated on by many processes concurrently

1,934 citations

Book
01 Mar 1983
TL;DR: The method of operating a water-cooled neutronic reactor having a graphite moderator which comprises flowing a gaseous mixture of carbon dioxide and helium, in which the helium comprises 40-60 volume percent of the mixture, in contact with thegraphite moderator.

1,609 citations

Journal ArticleDOI
TL;DR: In this paper, the relational model is extended to support atomic and molecular semantics, which is a synthesis of many ideas from the published work in semantic modeling plus the introduction of new rules for insertion, update, and deletion.
Abstract: During the last three or four years several investigators have been exploring “semantic models” for formatted databases. The intent is to capture (in a more or less formal way) more of the meaning of the data so that database design can become more systematic and the database system itself can behave more intelligently. Two major thrusts are clear. (1) the search for meaningful units that are as small as possible—atomic semantics; (2) the search for meaningful units that are larger than the usual n-ary relation—molecular semantics. In this paper we propose extensions to the relational model to support certain atomic and molecular semantics. These extensions represent a synthesis of many ideas from the published work in semantic modeling plus the introduction of new rules for insertion, update, and deletion, as well as new algebraic operators.

1,489 citations

Book
01 Jan 1983
TL;DR: In this article, the graphite moderator is replaced by a gaseous mixture of carbon dioxide and helium, in which the helium comprises 40-60 volume percent of the mixture.
Abstract: 1. The method of operating a water-cooled neutronic reactor having a graphite moderator which comprises flowing a gaseous mixture of carbon dioxide and helium, in which the helium comprises 40-60 volume percent of the mixture, in contact with the graphite moderator.

1,440 citations

Journal ArticleDOI
TL;DR: The currently operational (March 1976) version of the INGRES database management system is described in this article, which gives a relational view of data, supports two high level nonprocedural data sublanguages, and runs as a collection of user processes on top of the UNIX operating system for Digital Equipment Corporation PDP 11/40, 11/45, and 11/70 computers.
Abstract: The currently operational (March 1976) version of the INGRES database management system is described. This multiuser system gives a relational view of data, supports two high level nonprocedural data sublanguages, and runs as a collection of user processes on top of the UNIX operating system for Digital Equipment Corporation PDP 11/40, 11/45, and 11/70 computers. Emphasis is on the design decisions and tradeoffs related to (1) structuring the system into processes, (2) embedding one command language in a general purpose programming language, (3) the algorithms implemented to process interactions, (4) the access methods implemented, (5) the concurrency and recovery control currently provided, and (6) the data structures used for system catalogs and the role of the database administrator.Also discussed are (1) support for integrity constraints (which is only partly operational), (2) the not yet supported features concerning views and protection, and (3) future plans concerning the system.

915 citations