Trends in Database Research

Microcomputers for data-base applications are available in a wide range of prices. At the low-end, the minimum configuration for any serious Data Base work would be a processor and memory unit, two floppy diskette drives, a keyboard, a video display unit, and a printer [2]. This configuration would be adequate for small applications. As an example, an Apple II computer with two floppy disk drives, video display, and printer retails for approximately $3000.00.The availability of Data Base Management Systems for low-end microcomputers is very limited [1,2]. There appear to be only two relational systems commercially available for low-end configurations - RQL (Relational Query Language) and RMS (Relational Menu System). Both of these systems are available from Hello Software, 8380 Roanne Drive, Orlando, Florida 32817, U.S.A. The RQL system runs on the Apple II microcomputer. Although it was designed for use in a classroom environment, RQL may also be suitable in a small business environment.RQL is a relationally complete system [3,4]. Through a combination of automatic navigation and a relational processing query language, the RQL system allows the unsophisticated user direct interaction with data bases. Furthermore, RQL can manage multiple data bases with each data base extending across a maximum of eight volumes (floppy diskettes) [4]. However, since low-end configurations are inherently slow, the RQL system is unavoidably sluggish at times.The purpose of this paper is to demonstrate features of the RQL system and discuss its recent use in a learning environment and its potential use in a small business environment. For demonstration purposes a real-world situation typical of a small business organization will be used and a data base will be established for it using the RQL system (Release 3).

The future of computer aided design is in object oriented programming. If the database community hopes to participate in this future, it must reexamine some basic assumptions about the architecture of database systems. Database system functionality can be added to object systems but if the performance cost is too high, it will never survive. Below are some suggestions for what can be done at a reasonable performance cost. The object oriented paradigm provides a more practical approach to the partitioning of the global database than horizontal and vertical partitioning of relational tables. Each partition should itself be an independent database containing related data such as the geometry of a part or the spacial relationship of parts in an assembly. A meta-database would be used to control access to collections of these partitions. A collection of partitions comprise the database for a user's design session. The overhead of traditional database transaction management is not acceptable for high performance CAD systems. With the partitioning scheme described above, transaction management can be performed at a partition/session granularity. Once the user has composed the collection of partitions, he has a single user database. There is no need for concurrency control or transaction logging except at the meta-database level. This type of transaction management can in fact be more functional than traditional transaction management, allowing for versioning, long transactions, integrity checking and archival. Object oriented databases need a message model, not a data model. Any object which responds to the same messages as an object of “Duck” class (walk and quack) is, for all intents and purposes, a duck. An attempt to design a data model based on instance variables of an object or based on collections of objects of like class violates the data abstraction facilities of object oriented languages and diminishes their power. An attempt to implement a relational database system with an object oriented language yields a relational database system where you get abstract data types for free. It does not yield an object oriented database system. For object oriented queries, the message is the media. A query can be transformed into an execution plan consisting of messages sent to database objects. Optimization decisions can be made by sending messages to referenced objects. Collection classes can be implemented for new access methods with cost and selectivity methods to provide optimization information. In this way, the query language can grow with the application. Data representation is an important aspect of object oriented systems. Most object systems are typeless in that all instance variables of an object are object references. For performance sake, object systems should provide enough of a type mechanism to allow simple data items (integers, floats, characters … ) to be represented in the form intrinsic to the machine. Methods can then be compiled for access to typed data. In conclusion, object systems provide enormous potential for the development of CAD systems. Performance influences the approach taken to an application. WYSIWYG publishing applications were not attempted until performance was adequate. Functionality is what sells CAD systems. Database system functionality can be added to object systems at a reasonable cost.

A Fuzzy Query Language (FQL) for relational databases is proposed. FQL, developed as an extension of relational domain calculus, has sufficient capabilities to express all five types of fuzzy statements distinguished and represented in a meaning representation language PRUF by 7aieh. The main idea for developing FQL lies in a method that harmoniously integrates relational domain calculus and PRUF, together with a natural determination method of matching degrees of domain values in relational databases against FQL queries. Effects of FQL are twofold. One is practical. We expect that FQL will add a human-oriented interface to currently widespread relational databases all over the world that have already stored a vast amount of useful information. In addition, fuzzy expert systems currently under development can be designed to support FQL so that they can make use of fact data stored in some relational database in their processing. The other but principal effect is theoretical. FQL provides a theoretical framework that can play a kernel role in integrating many previous-and-future fuzzy extensions of relational database query languages systematically into a unified fuzzy query language.KeywordsRelational databasesquery languagefuzzy propositionsfuzzy well-formed formulasrelational domain calculusmatching degrees

Section 3.1 describes the relational data model, which is a particular data abstraction that uses relations or tables to represent the data in a database. Section 3.2 introduces the relational algebra query language, while Section 3.3 introduces the Structured Query Language (SQL) for relational databases. Finally, Section 3.4 discusses the evaluation of relational database queries.KeywordsRelational DatabaseQuery LanguageRelational AlgebraSocial Security NumberStructure Query LanguageThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Hierarchical part-of relationships/aggregation structures and related queries are essential parts of information systems. However, relational database query languages do not explicitly support hierarchical relationships and queries. A hierarchical query may require a great number of join operations, which increases the effort in query formulation. Therefore, we propose path expressions in formulating hierarchical views over relational data because path expressions are a conventional and compact way to represent hierarchical relationships. We embed path expressions within SQL queries and compile them to standard SQL. This ensures that the path expressions can straightforwardly be implemented on the top of standard relational database systems. The compilation of a path expression is given by an attribute grammar, a conventional formalism to define the semantics of a language.

The relational database query language SQL (originally, SEQUEL) was first developed as a non-procedural language: the user should specify only what data is desired, leaving it to the the system's query optimizer to determine how the data is accessed [ASTR 75]. IBM pioneered the development of query optimizer technology that would achieve this ideal, beginning with the well-known optimizer of System R [SELI 79], the prototype relational database management system (DBMS) developed at IBM Research Laboratory in San Jose, California during the late 1970's. The IBM products SQL/DS [SQL 84] and DB2 [CHEN 84], as well as the experimental distributed DBMS prototype R∗ [LOHM 85], contain optimizers that are based upon the System R prototype.

Numerous proposals have been made to extend the relational database query language SQL to serve as a spatial query language and currently efforts are under way to establish a standardized spatial SQL. Here it is argued that the SQL framework is inappropriate for an interactive spatial query language and an extended spatial SQL is at best a short-term solution. The serious deficiencies of any spatial SQL are divided into two groups: the severe difficulties to incorporate necessary spatial concepts into SQL such as graphical display and its specification and the lack of power within the relational framework with missing support for complex objects, object identity, meta queries, and non-first-order logic—all crucial when dealing with spatial data.

The article provides an overview of research and development of databases since their appearance in the 60s of the last century to the present time. The following stages are distinguished: the emer- gence formation and rapid development, the era of relational databases, extended relational data- bases, post-relational databases and big data. At the stage of formation, the systems IDS, IMS, Total and Adabas are described. At the stage of rapid development, issues of ANSI/X3/SPARC database architecture, CODASYL proposals, concepts and languages of conceptual modeling are highlighted. At the stage of the era of relation-al databases, the results of E. Codd’s scientific activities, the theory of dependencies and normal forms, query languages, experimental research and development, optimization and standardiza- tion, and transaction management are revealed. The extended relational databases phase is devot- ed to describing temporal, spatial, deductive, ac- tive, object, distributed and statistical databases, array databases, and database machines and data warehouses. At the next stage, the problems of post-relational databases are disclosed, namely, NOSQL-, NewSQL- and ontological databases. The sixth stage is devoted to the disclosure of the causes of occurrence, characteristic properties, classification, principles of work, methods and technologies of big data. Finally, the last section provides a brief overview of database research and development in the former Soviet Union.

We define a language G for querying data represented as a labeled graph G. By considering G as a relation, this graphical query language can be viewed as a relational query language, and its expressive power can be compared to that of other relational query languages. We do not propose G as an alternative to general purpose relational query languages, but rather as a complementary language in which recursive queries are simple to formulate. The user is aided in this formulation by means of a graphical interface. The provision of regular expressions in G allows recursive queries more general than transitive closure to be posed, although the language is not as powerful as those based on function-free Horn clauses. However, we hope to be able to exploit well-known graph algorithms in evaluating recursive queries efficiently, a topic which has received widespread attention recently.

Query languages for relational databases have received considerable attention. In 1972 Codd [Cod72] showed that two natural mathematical languages for queries—one algebraic and the other a version of first order predicate calculus—had identical powers of expressibility. Query languages which are as expressive as Codd's Relational Calculus are sometimes called complete. This term is misleading, however, because many interesting queries are not expressible in “complete” languages.

Modern digital life has produced big data in modern businesses and organizations. To derive information for decision-making from these enormous data sets, a lot of work is required at several levels. The storage, transmission, processing, mining, and serving of big data create problems for digital domains. Despite several efforts to implement big data in businesses, basic issues with big data remain (particularly big-data management (BDM)). Cloud computing, for example, provides companies with well-suited, cost-effective, and consistent on-demand services for big data and analytics. This paper introduces the modern systems for organizational BDM. This article analyzes the latest research to manage organization-generated data using cloud computing. The findings revealed several benefits in integrating big data and cloud computing, the most notable of which is increased company efficiency and improved international trade. This study also highlighted some hazards in the sophisticated computing environment. Cloud computing has the potential to improve corporate management and accountants' jobs significantly. This article's major contribution is to discuss the demands, advantages, and problems of using big data and cloud computing in contemporary businesses and institutions.

Deco is a comprehensive system for answering declarative queries posed over stored relational data together with data obtained on-demand from the crowd. In this paper we describe Deco's cost-based query optimizer, building on Deco's data model, query language, and query execution engine presented earlier. Deco's objective in query optimization is to find the best query plan to answer a query, in terms of estimated monetary cost. Deco's query semantics and plan execution strategies require several fundamental changes to traditional query optimization. Novel techniques incorporated into Deco's query optimizer include a cost model distinguishing between "free" existing data versus paid new data, a cardinality estimation algorithm coping with changes to the database state during query execution, and a plan enumeration algorithm maximizing reuse of common subplans in a setting that makes reuse challenging. We experimentally evaluate Deco's query optimizer, focusing on the accuracy of cost estimation and the efficiency of plan enumeration.

Many vendors of multimedia databases and many providers of multimedia search and retrieval services already offer advanced indexing and retrieval techniques for multimedia contents. However, the solutions differ and do not interoperate. The already completed ISO/IEC IS 15938, formally called the multimedia content description interface (better known as MPEG-7), provides a rich model for multimedia content description. We propose a unified query framework for multimedia repositories based on MPEG-7. The framework consists of a query language and a service interface. The query language is based on XML and includes four complementary parts defining a relational-like algebra, an expression language, an input query structure and the output response format. The service interface acts as a set of views over the query language and is based in two different bindings: An extensible web services-based (SOAP) binding and an alternative and simple HTTP (REST-like) interface.

The query optimizer is an important system component of a relational database management system (DBMS). It is the responsibility of this component to translate the user-submitted query - usually written in a non-procedural language - into an efficient query evaluation plan (QEP) which is then executed against the database. The research literature describes a wide variety of optimization strategies for different query languages and implementation environments. However, very little is known about how to design and structure the query optimization component to implement these strategies. This paper proposes a first step towards the design of a modular query optimizer . We describe its operations by transformation rules which generate different QEPs from initial query specifications. As we distinguish different aspects of the query optimization process, our hope is that the approach taken in this paper will contribute to the more general goal of a modular query optimizer as part of an extensible database management system.

Graph analytics is becoming increasingly popular, driving many important business applications from social network analysis to machine learning. Since most graph data is collected in a relational database, it seems natural to attempt to perform graph analytics within the relational environment. However, SQL, the query language for relational databases, makes it difficult to express graph analytics operations. This is because SQL requires programmers to think in terms of tables and joins, rather than the more natural representation of graphs as collections of nodes and edges. As a result, even relatively simple graph operations can require very complex SQL queries. In this paper, we present GRAPHiQL, an intuitive query language for graph analytics, which allows developers to reason in terms of nodes and edges. GRAPHiQL provides key graph constructs such as looping, recursion, and neighborhood operations. At runtime, GRAPHiQL compiles graph programs into efficient SQL queries that can run on any relational database. We demonstrate the applicability of GRAPHiQL on several applications and compare the performance of GRAPHiQL queries with those of Apache Giraph (a popular ‘vertex centric’ graph programming language).