Database Management System Query Research Articles

Achieving sequenced SQL with log-segmented timestamps

In a period-timestamped, relational temporal database, each tuple is timestamped with a period. The timestamp records when the tuple is “alive” in some temporal dimension. Sequenced semantics is a special semantics for evaluating a query in a temporal database. The semantics stipulates that the query must, in effect, be evaluated simultaneously in each time instant using the tuples alive at that instant. Previous research has proposed changes to a database management system's query evaluation engine to support sequenced semantics. We show how to achieve sequenced semantics without modifying a query evaluation engine. Our technique has two pillars. First we use log-segmented timestamps to record a tuple's lifetime. A log-segmented timestamp divides the time-line into segments of known length. Any temporal period can be represented by a small number of such segments. Second, by taking advantage of the properties of log-segmented timestamps, we translate a sequenced query to a non-temporal query, using the operations already present in an unmodified, non-temporal query evaluation engine. The paper provides translations for both relational algebra and SQL. We experimentally evaluate the SQL translation. The primary contribution of this paper is how to implement sequenced semantics using log-segmented timestamped tuples in a generic SQL DBMS.

Data Base Management Systems Query Optimization Techniques for Distributed Database Systems

Abstract: The fundamental goal of this postulation is to introduce various models for single also as numerous inquiry handling in the Distributed data set framework which brings about less question handling cost. One of the significant issues in the plan and execution of Distributed Information Base Management Systems (DDBMS) is productive inquiry handling. The objective of dispersed inquiry improvement decreases to minimization of measure of information to be communicated among destinations for handling a given inquiry. The issue of question handling in DDBS (1 1) has been concentrated broadly in writing. In the greater part of calculations, the capability of the question will contain a grouping of tasks. In such cases, while executing tasks from right to left, as per the request for tasks in arrangement, the aftereffect of an activity might be an operand to the next activity. Since the tasks are subject to each other, at a moment in particular one activity at one site will be executed despite the fact that the climate is dispersed. Then frameworks at any remaining locales will be inactive for this inquiry. Another model, Totally Reducible Relation Model (CRK Medel), which permits parallelism and processes numerous tasks all the while at all important locales is introduced. It is expected that the tasks are in the type of conjunctions. So every activity can be handled freely. In this model at some moment, relations at every single significant site will be totally diminished by relating sets of every appropriate activity (Determinations, Semijoins and Joins) all the while. Thus, every connection will be checked just a single time to deal with all appropriate tasks by decreasing VO cost.

DBFIRE: USING DATABASE QUERIES FOR INFORMATION RETRIEVAL

Databases and documents are normally controlled by different systems, which usually do not communicate with each other: Database Management Systems (DBMS) and Information Retrieval Systems (IRS), respectively. Still, it is very likely that they store information about the same entities, which is a strong appeal for their integration. In this paper, we present an approach for DBMS/IRS integration that uses top-ranked terms in a DBMS query as keywords for an IRS search, in order to retrieve documents somehow related to the query. These terms “expand” an initial keyword set provided by the user, and are ranked according to a measure of their diffusion over the database query result. Experiments show that the approach presents significant improvements compared to other integration methods.

PET

Energy conservation is a growing important issue in designing modern database management system (DBMS). This requires a deep thinking about the tradeoffs between energy and performance. Despite the significant amount of efforts at the hardware level to make the major components consume less energy, we argue for a revisit of the DBMS query processing mechanism to identify and harvest the potential of energy saving. However, the state-of-art architecture of DBMS does not take energy usage into consideration in its design. A major challenge in developing an energy-aware DBMS is to design and implement a cost-based query optimizer that evaluates query plans by both performance and energy costs. By following such a strategy, our previous work revealed the fact that energy-efficient query plans do not necessarily have the shortest processing time. This demo proposal introduces PET -- an energy-aware query optimization framework that is built as a part of the PostgreSQL kernel. PET, via its power cost estimation module and plan evaluation model, enables the database system to run under a DBA-specified energy/performance tradeoff level. PET contains a power cost estimator that can accurately estimate the power cost of query plans at compile time, and a query evaluation engine that the DBA could configure key PET parameters towards the desired tradeoff. The software to be demonstrated will also include workload engine for producing large quantities of queries and data sets. Our demonstration will show how PET functions via a comprehensive set of views from its graphical user interface named PET Viewer . Through such interfaces, a user can achieve a good understanding of the energy-related query optimization and cost-based plan generation. Users are also allowed to interact with PET to experience the different energy/performance tradeoffs by changing PET and workload parameters at query runtime.

An effective representation of complex clauses in a relational database

A mechanism for storing and retrieving arbitrary complex PROLOG clauses from a relational database is presented. This mechanism can be used to implement a filter module that sits on top of the database management system (DBMS) and offers clause retrieval functions to the PROLOG interpreter. The filter module accepts arbitrary complex goal literals as input and returns all clauses (potentially) matching the goal. The presented mechanism is able to handle ground and non-ground facts as well as rules. For clause retrieval it derives search predicates from the constants of goal literals as well as multiple occurrences of goal variables. The presented method is flexible enough to support a wide range of filter selectivity, i.e. it can be used to implement highly-selective as well as arbitrary coarse filters. The structures needed to represent clauses in the DBMS are simple: each clause is entirely stored in a single tuple, which also contains all information needed for selection purposes. To retrieve the clauses matching a given goal, one DBMS query operating on a single table is to be executed, independent of the complexity of the stored clauses and the degree of selectivity provided by the filter.