Some recently proposed extensions to relational database systems, as well as to deductive database systems, require support for multiple-query processing. For example, in a database system enhanced with inference capabilities, a simple query involving a rule with multiple definitions may expand to more than one actual query that has to be run over the database. It is an interesting problem then to come up with algorithms that process these queries together instead of one query at a time. The main motivation for performing such an interquery optimization lies in the fact that queries may share common data. We examine the problem of multiple-query optimization in this paper. The first major contribution of the paper is a systematic look at the problem, along with the presentation and analysis of algorithms that can be used for multiple-query optimization. The second contribution lies in the presentation of experimental results. Our results show that using multiple-query processing algorithms may reduce execution cost considerably.

/pdf/multiple-query-optimization-290dzawdd0.pdf

Multiple-query optimization

Active database systems support mechanisms that enable them to respond automatically to events that are taking place either inside or outside the database system itself. Considerable effort has been directed towards improving understanding of such systems in recent years, and many different proposals have been made and applications suggested. This high level of activity has not yielded a single agreed-upon standard approach to the integration of active functionality with conventional database systems, but has led to improved understanding of active behavior description languages, execution models, and architectures. This survey presents the fundamental characteristics of active database systems, describes a collection of representative systems within a common framework, considers the consequences for implementations of certain design decisions, and discusses tools for developing active applications.

/pdf/active-database-systems-1g8cqg5by3.pdf

Active database systems

We describe the results of developing the GemStone object-oriented database server, which supports a model of objects similar to that of Smalltalk-80. We begin with a summary of the goals and requirements for the system: an extensible data model that captures behavioral semantics, no artificial bounds on the number or size of database objects, database amenities (concurrency, transactions, recovery, associative access, authorization) and an interactive development environment. Object-oriented languages, Smalltalk in particular, answer some of these requirements. We discuss satisfying the remaining requirements in an object oriented context, and report briefly on the status of the development efforts. This paper is directed at an audience familiar with object-oriented languages and their implementation, but perhaps unacquainted with the difficulties and techniques of database system development. It updates the original report on the project [CM], and expands upon a more recent article [MDP].

Development of an object-oriented DBMS

ion function Dl----~======~====~--·D3 a Aggregation] H x hx ]Aggregation function x x function Abstraction function D2 A D4ion function D2 A D4 Fig. 4.1 Commuting Diagram for Aggregation and Abstraction 64 4. Extending the Entity-Relationship Model If the diagram is not commuting then we can use divergence functions which model divergence of the discrete values and the according values for the continuous scale. Such models could be statistical models based on distribution functions for the case of average or summarization functions. We could use interval models for the case of min/max functions. In both cases, we are using approximation functions for abstractions instead of point-to-point mappings. We introduce now nested attributes with more complex domains. Given a data scheme DD = (U, D, dom) and a set of names N A different from U, a set of labels L now formally defines the set UN of nested attributes with the empty word A. 1. AEUN. 2. UCUN. 3. If X E UN then l: X E UN for l E L. 4. If distinct X1, ... , Xn E UN and X EN A then X(X1, ... , Xn) is a (tuplevalued) nested attribute in UN. This attribute type can also be used in the notion X. 5. If X' E UN and X EN A then X {X'} is a (set-valued) nested attribute in UN. 6. No other elements are in UN. The underlying data domains can be complex. Thus, the domain type can be constructed similar to the construction presented for complex attributes. If, for instance, the attribute ZIPCode is used then it may be useful to separately store the complex domain with check sums and additional information (check tables). The set L is used as an additional naming language. Each attribute can be labeled by names or labels from L. Labels can be used as alias names for attributes. They are useful for shortening expressions of complex attributes. They can carry a meaning but do not carry semantics. They can be omitted whenever it is not confusing. Additionally, other type constructors can be used for defining nested attributes: lists of values, e.g., < X >, vectors or arrays of values, e.g., XR;ff;(Y) with an index attribute Y, minimal and maximal index values and bags of values, e.g., nx~ . Furthermore, we can use optional components, e.g., [X]. For simplicity purposes we restrict the model to tuple and set constructors. However, list and bag constructors can be used whenever type constructors are allowed. Note that in [GPV88] an analogous notion of nested attributes is introduced, but with the following additional condition: for different nested 4.2 Entity and Relationship Types 65 attributes X, Y , the sets AT( X) and AT(Y) of atomic attributes used in X and Y are disjoint. Now we can extend the function dom to Dom on UN. 1. Dom(.X) = 0 . 2. For A E U , Dom(A) = dom(A). 3. For l: X E UN, Dom(l: X)= Dom(X). 4. For X(X1, ... ,Xn) E UN , Dom(X) = Dom(Xl) x ... x Dom(Xn) where M1 X .•• x Mn denotes the Cartesian product of the sets M1, ... , Mn. 5. For X{X'} E UN , Dom(X{X'}) = Pow(Dom(X)) where Pow(M) denotes the powerset of the set M. Two attribute types X, Yare called domain-compatible if Dom(X) = Dom(Y). For the data scheme DD the set Dnn denotes the union of all sets Dom(X) for X E UN. A tuple on X~ UN and on DD = (U, D, dom) is a function t : X -+ Dnn with t(A) E Dom(A) for A E X . Let us now define the key concept based on shallow equality and on the structure [AFT92). To do this we need the definition of the subattribute, which uses the approach of[Yok88). Assume a data scheme DD = (U, D, dom) and the set UN. Let h be the function with the empty graph. 1. For A E U , 0 and A are themselves subattributes of A . For a tuple t on A the function t1. is the restriction oft to 0. 2. For X(X1, ... ,Xn) E UN and {Z1, ... ,Zm} ~ {X1, ... ,Xn} (m:::; n) and subattributes Yi of Z; (1 ::=; i ::=; m), X(Y1, ... , Ym) is a subattribute of X(X1, ... , Xn) . For a tuple ton X(X1, ... , Xn) the restriction tx(Y" ... ,Ym) oft to X(Y1, ... , Ym) is defined by the equality tx(Y1 , ... ,Ym)(Yi) = t(Z;) lv; (1 ::=; i ::=; m) where the restriction of dE Dom(Z;) to Yi is denoted by d IY;· 3. For X {Y} E UN and a subattribute Z of Y, X { Z} is a subattribute of X {Y}. For a tuple t on X {Y}, the restriction tx {Z} oft to X { Z} is defined by the equality tx{z}(X{Z}) = t(X{Y}) lz. For a given set of attributes X = {X1, ... , Xn} and {Z1, ... , Zm} ~ {X1, ... , Xn} and subattributes Yi of Z; ( 1 ::=; i ::=; m ), {Y1, ... , Ym} is a generalized subset of {X1, ... ,Xn}. An entity type Eisa pair (attr(E), id(E)) , where E is an entity set name, attr(E) is a set of attributes and id(E) is a non-empty generalized subset of attr(E) called the key or identifier. The notion of entity types can be extended to entity types with key sets or with sets of constraints: 66 4. Extending the Entity-Relationship Model E = (attr(E), {idj(E) 11 ~ j ~ m}) with m keys or E = (attr(E), E) where Eisa set of integrity constraints. Concrete entities e of E can be now defined as tuples on attr(E). At any fixed moment in time t the present entity set Ec for the entity type E is a set of tuples r on attr(E) for which id(E) is a key, i.e., for two different tuples r, r' from Ec the inequality Tid(E) -=f. rfd(E) is valid. This approach is more general than approaches used in (NF) 2 relations. In order to use a simple semantics in [BRS82] and [Hul90], partitioned normal forms are introduced. An entity set is in partitioned normal form if the atomic attributes are a key of the set and any non-atomic value, a component of a tuple of the relation, is also in partitioned normal form. However, the subclass of entity sets in partitioned normal forms is generally not closed under the algebra of nested relations [PDG89]. Furthermore, it is not natural to restrict entity types to those with key sets consisting only of atomic attributes. For instance, the entity type Person = ( { Name(First,Fam),Addr(Zip, Town, Street(Name, No)), Gender}, { Name(First,Fam) }) would not be allowed. It is possible to use the behavior equality [AFT92] for the key definition. Then the key definition corresponds exactly to the key definition of (NF) 2 relations after flattening with the unnest operation. These two approaches do not differ if the tuple constructor is used but they differ if the set operator is used. The following three tuples defined on Phones= (Person, Telephones{(Rooms{Room}, N umbers{TelN umber})}) r = (a, {( { b}, { c, d}) , ( { e, !} , { d, h})}) , r' =(a, {({b, e, !}, {d}), ({b}, {c}), ({e, !}, {h})}), and r" =(a, {({b}, {d}), ({b}, {c}), ({e}, {d}), ( { e}, { h}), ( {!}, { d}), ( {!}, { h})}) are not shallow-equal but they are behavior-equal. These tuples can carry different semantics. Therefore, sometimes behavior equality or other equality concepts may be useful for the application area. The key definition based on behavior equality is stronger than the key definition based on shallow equality. Furthermore, we can introduce a general key concept using functions. Given a set M and a function f : attr(E) --t M, the function f is called a general key of Ec if the inequality f(r) -=f. f(r') is valid for all distinct r,r' E Ec. This notion is very general. It can be used to represent distinction of tuples by shallow equality, by behavior equality, by reduction systems, by aggregation functions, and by transformation to another type. 4.2 Entity and Relationship Types 67 It also covers the concept of the entropy key. Given an entropy function£ and a query q on E. Then q is called £-key of Ec if £(Ec) = £(q(Ec)). Sometimes, it is necessary to use more general key concepts. For instance, if first names are represented by a set or list of names then subsets or sublists could be considered to be equal to its superset or superlist, respectively. In some cases, a super/subtype relationship with more than one subtype occurs. This choice can be modeled by the union of the subtypes. The construct to be used is called a cluster type. Clusters based on entity types can be defined by the disjoint union of types. The disjointness can be weakened for relationship types. Furthermore, we require that the identification types of the components of a cl':lster are domain-compatible. Take now the set of types {R1, ... , Rk} as given. These types can be clustered by a "category" or a cluster C = R1 + R2 + ... + Rk. For a cluster C = R1 + ... + Rk we can similarly define a set cc as the 'disjoint' union of the sets Rf, ... , Rf. If R1, ... , Rk are entity types (0-order relationship types) then Cis a cluster of entity types. The cluster is defined "fRc Rc d" .. t 1 1 , . . . k are IS JOin . The disjointness is necessary because of identification requirements. The identification types id(Ri) of components R; of R have the same domain. They can be reduced using labels: C = h : R1 + l2 : R2 + ... + lk : Rk for pairwise distinct labels h, 12 , ... , lk. Instead oflabels we may use the component number. However in these cases, each object used in a cluster has a value which is labeled by the corresponding label name or component number. In the case of clusters as components of other types, the disjointness is weakened. Entity types E 1 , ... , Ek are now given. A (first-order) relationship type has the form R = (ent(R), attr(R)) where R is the name of the type, ent(R) is a sequence of entity types and of clusters of these, and attr(R) is a set of attributes from UN. A first-order relationship type R = (R1, ... , Rn, {B1, ... , Bk}) and for a given moment t sets Rf, ... , R<;[ are now given. A first-order relationship r is an element of the Cartesian product Rf x ... x R<;[ x Dom(B!) x ... x Dom(Bk)· We distinguish between entity types and clusters. If all R; are entity types then a first-order relationship set Rc is a set of relationships, i. e. Rc ~ Rf X ... X R<;[ X dom(B!) X ..• X aom(Bk)· 68 4. Extending the Entity-Relationship Model If R; is a cluster R; 1 + ... + R; k then the relationships in Rc are distinct according toR;, i.e., f~r r, r' E Rb either r.R; -:

Entity-Relationship Modeling

Integrating a production rules facility into a database system provides a uniform mechanism for a number of advanced database features including integrity constraint enforcement, derived data maintenance, triggers, alerters, protection, version control, and others. In addition, a database system with rule processing capabilities provides a useful platform for large and effcient knowledge-base and expert systems. Database systems with production rules are referred to as active database systems, and the of active database systems has indeed been active. This chapter summarizes current work in active database systems; topics covered include active database rule models and languages, rule execution semantics, and implementation issues. 0

Relational databases are of increasing interest for applications outside the traditional business data-processing environment We have introduced the notion of complex objects as one extension to a relational database system (System R) to better support these non-business applications, in particular, engineering design In this chapter, we discuss five aspects of complex objects: concepts and semantics, implementation, query optimization, efficient use within application programs, and user interface

Supporting Complex Objects in a Relational System for Engineering Databases

An active database system reacts to a set of external events such as a timer interrupt or access to a particular object in the database. A trigger is a general mechanism for active data management, both in the context of a centralized system or a distributed system (including that of autonomous and cooperating agents). It consists of three parts; event specification, integrity constraint specification, and action specification. The event specification in a trigger is a set of events which will cause the condition in the constraint specification to be checked. If the condition is true, the actions in the action specification will be initiated. In this paper, we develop a framework for supporting triggers in object-oriented database systems. The framework consists of a categorization for each of the three components of a trigger. The framework is first cast in the context of the relational model of data, and is then extended to account for object-oriented concepts that constitute an object-oriented data model, including nested objects, methods, and inheritance hierarchy.

A framework for supporting triggers in object-oriented database systems

In this paper, we outline the current research on query optimization in distributed database systems at the University of Michigan. Specifically, we describe by example our model for representing sets of values of attributes generated while processing a query by a sequence of semijoin operations. This model provides an efficient methodology for deriving the estimates of the cardinalities of these sets which are needed to compute the cost of query processing. Further, we mention the intuitive ideas behind our heuristics for deriving a sequence of semi joins. Comparative results with the existing algorithms are provided.

Some Thoughts on the Future Direction of Query Processing.

Advantages claimed for the relational model in the classical data processing domain include ease of use, data independence, increased productivity, and multi-file correlation. These advantages also hold for design applications. However, engineering applications impose several additional requirements.

A Database System for Engineering Design.

The previous probabilistic retrieval models assume that the relevance probability of a document is independent of the descriptors that are not specified in a query. This is not true in practice because there can be many descriptors that represent the same concept. The probabilistic retrieval model developed in this paper overcomes this unsuitable assumption and incorporates the relationships of descriptors. A learning method is also proposed to figure out the relationships incrementally. Each time retrieval results are available, the method identifies in the relevant documents the descriptors that designate the concepts specified by the query descriptors. Although it employs user feedbacks like relevance feedback, it attempts to capture certain stable relationships of descriptors from many past user queries rather than to distinguish relevant documents from non-relevant ones for a particular query. We show through experiments that the proposed information retrieval method improves retrieval effectiveness over time.

Probabilistic retrieval incorporating the relationships of descriptors incrementally

Handle everyday research tasks with reliable, citation-backed results

Your personal Research Agent to handle research tasks with citation-backed results

Popular Tasks used by Researchers

How can I help with your research?

Meet SciSpace

Get more enhanced response by uploading the PDFs you want me to reference.

No relevant PDFs in your library

SciSpace is the AI research assistant for academics. Run systematic literature reviews on 280M+ papers, and write papers with cited sources. Trusted by 1M+ students, PhDs & researchers.

SciSpace | AI for Research

Analyze PDFs

Code & Manuscripts

Funding & Grants

Literature & Patents

Medical & Clinical Data

Systematic Review

Visualize & Present

Web & Data

Build a Google Scholar-like website for your research.

Build a website

Create charts and images for your research

Create a Chart

Write a paper for submission to a journal

Draft a manuscript

Patent Search

Design eye-catching scientific posters in minutes.

Scientific Poster Generation

Systematic Literature Review

One task is running at the moment. Your messages will be shown right after.

Drag and drop or click here to browse

Loved by <highlight>1 million+</highlight> researchers

Extract a list of specific topics and their sources from unstructured text

Topics

Compare and analyze relevant papers that matches with your search

Papers

Get insights from PDFs and bookmarked papers from your library

My library

Recent searches

Try searching for:

Catch AI-generated content in scholarly and non-scholarly content

{ai} Detector

Ai Writer

Get PDF Summaries, highlighted text explanations 

Chat with PDF

Effortlessly create in-text citations and bibliographies in APA and 2,500 other formats

Citation generator

Get explanations, summaries, and answers on academic papers

Ease up your research workflow with {scispace}'s cohort of exciting AI tools

Elevate your academic writing skills and convey your ideas the way you want

Paraphraser

Explore our range of reading and writing tools

Your file is being prepared and should be ready in a few minutes. If it's a large file, it might take a bit longer. You can close this window, and we'll email you the file when it's done.

You have reached a maximum limit of <strong>{limit}</strong> columns in the table. Remove at least <strong>1</strong> column to add or create another one.

Won Kim

Author Tools

Chat about Author