Commercial Relational Database Management System Research Articles

The Catalog Archive Server Database Management System

The multiterabyte Sloan Digital Sky Survey's (SDSS's) catalog data is stored in a commercial relational database management system with SQL query access and a built-in query optimizer. The SDSS catalog archive server adds advanced data mining features to the DBMS to provide fast online access to the data.

A Retrospection On Niche Database Technologies.

Today commercial relational database management systems (RDBs) and supporting tools (database design tools, graphical database browsers, application generators, query tools, etc.) from several major vendors are used to suit most data management needs around the world. The database market is now dominated by the Big Three: IBM, Microsoft, and Oracle. Initially, commercial RDBs supported the first normal form relational data model and SQL query language, along with basic transaction management and access authorization facilities. They mostly ran on a few UNIX platforms. The scope and sophistication of the functionality they support, and the performance they deliver have all substantially matured during the past twenty years. They have also been made to run on most computers and operating systems. However, the often frustratingly long periods that it took major vendors to shore up various shortcomings of RDBs have led to the introduction of what I will call “niche database” technologies during this period of maturation. Each niche database technology came about to address typically one major shortcoming in then-existing RDBs. The technologies the vendors introduced and the efforts they made to market the technologies often provided a key incentive to major vendors to upgrade their RDBs with the same technologies. The financial wherewithal, customer loyalty, and marketing prowess of the major RDB vendors have simply overpowered vendors of niche database technologies. For these and other reasons, except for about a dozen vendors, niche database technology vendors have generally failed to grow into sustained large business entities. Today the maturity of RDBs, the expectation of the customer base, and the domination of the market by the Big Three make it very difficult for the entry of new niche database technology vendors.

The role of declarative querying in bioinformatics.

THE RECENT PUBLICATION of a draft of the entire human genome (McPherson et al., 2001; Venter et al., 2001) has served to fuel an already explosive area of research in bioinformatics that is involved in deriving meaningful knowledge from proteins and DNA sequences (Alberts et al., 2002). Even with the full human genome sequence now in hand, scientists still face the challenges of determining exact gene locations and functions, observing interactions between proteins in complex molecular machines, and learning the structure and function of proteins, just to name a few. The progress of this scientific research is closely connected to the research in the database community in that analyzing large volumes of biological data sets involves being able to maintain and query large databases (Moussouni et al., 1999; Davidson, 2002). Database management systems (DBMSs) could help support life sciences applications, in a number of different ways. A partial list of tasks that such applications require is: querying large structured databases (such as sequence and graph databases), querying semi-structured (such as published manuscripts), managing data replication, querying distributed data sources, and managing parallelism in high-throughput bioinformatics. Unfortunately, current DBMSs have largely ignored supporting life sciences applications, and consequently, the life sciences researches have been forced to write tools and scripts to perform these tasks. An interesting parallel can be drawn between the state of data management tools in life sciences, and the state of data management tools for business applications, such as a banking application, about three decades ago. Prior to the advent of the relational data model, business data was managed and queried using customized programs/scripts that were developed for each application. Reusing programs, and the algorithms for querying the data, involved rewriting application program and logic, which was very time consuming and expensive. In addition, the querying programs were closely tied to the format that was used to represent the data. Any change in the format of the data representation often would break the querying programs. Furthermore, writing complex queries, such as querying over multiple data sets or posing complex analytical queries, was a daunting task. One of the critical contributions of the relational data model (Codd, 1970) was the introduction of a declarative querying paradigm for business data management, instead of the previously used procedural paradigm. In a declarative querying paradigm, the user expresses the query in a high-level language, like SQL, and the DBMS determines the best strategy for evaluating the query. In addition, the DBMS only presents to the user a logical view of the data against which queries are posed. The physical representation of the data, either on disk or in-memory, can be very different from the logical view. For example, in a relational database management system (RDBMS), indices may be created, and the user doesn’t have to query against the index. The user still queries against logical relations, and the system automatically determines if it is faster to use the indices to answer a query. The user is thus insulated from worrying about various details such as physical organization of data on disk, the exact location of the data, tuning the representation for better performance, and choosing the best plan for evaluating a query. This declarative querying paradigm has been a huge success for relational DBMSs, and today commercial RDBMSs manage terabytes of data, and allow very complex querying on these databases. Database management systems can provide similar benefits to the life sciences community, just as it did three decades ago to the business data management community. Many of the data sets that are used in life sciences are growing at an astonishing rate (such as sequence data at NCBI’s GenBank (NCBI, 2002)), and the queries

Processing OLAP queries in hierarchically clustered databases

On-Line Analytical Processing (OLAP) is a technology that encompasses applications requiring a multidimensional and hierarchical view of data. OLAP applications often require fast response time to complex grouping/aggregation queries on enormous quantities of data. Commercial relational database management systems use mainly multiple one-dimensional indexes to process OLAP queries that restrict multiple dimensions. However, in many cases, multidimensional access methods outperform one-dimensional indexing methods. We present an architecture for multidimensional databases that are clustered with respect to multiple hierarchical dimensions. It is based on the star schema and is called CSB star. We focus on processing OLAP queries over this schema using multidimensional access methods. Users can still formulate their queries over a traditional star schema, which are then rewritten by the query processor over the CSB star. We exploit the different clustering features of the CSB star to efficiently process a class of typical OLAP queries. We detect cases where the construction of an evaluation plan can be simplified, and other cases where additional processing techniques can be applied.

Semantic integrity support in SQL:1999 and commercial (object-)relational database management systems

The correctness of the data managed by database systems is vital to any application that utilizes data for business, research, and decision-making purposes. To guard databases against erroneous data not reflecting real-world data or business rules, semantic integrity constraints can be specified during database design. Current commercial database management systems provide various means to implement mechanisms to enforce semantic integrity constraints at database run-time.In this paper, we give an overview of the semantic integrity support in the most recent SQL-standard SQL:1999, and we show to what extent the different concepts and language constructs proposed in this standard can be found in major commercial (object-)relational database management systems. In addition, we discuss general design guidelines that point out how the semantic integrity features provided by these systems should be utilized in order to implement an effective integrity enforcing subsystem for a database.

A distributed, heterogeneous computing environment for multidisciplinary design and analysis of aerospace vehicles

A framework for rapid applications development is described that implements an object-oriented computational environment in which the Common Object Request Broker Architecture and the Java programming language are used to encapsulate discipline codes as reusable “objects”. The environment exploits the parallelisms inherent in the application and distributes the disciplines on machines most appropriate to their needs, while insulating the developer and the user from the complexity of the underlying communications constructs. Data and file management are accomplished using Java's database connectivity to access a commercial relational database management system. Java's Beans Development Kit (BDK) is used to implement the disciplines and sub-tasks as reusable components and to provide a graphical interface for user input as well as to facilitate interactive and visual object connectivity and monitor problem execution progress. The advantages of this approach have been demonstrated through the implementation of a standalone aerodynamic optimizer and the analysis of a large-scale high speed civil transport design optimization problem in this framework.

An overview of the Object Protocol Model (OPM) and the OPM data management tools

In this paper, we overview the Object-Protocol Model (OPM) and a suite of data management tools based on OPM. OPM is a data model that allows specifying database structures and queries in terms of objects and protocols specific to scientific (e.g., molecular biology laboratory) applications. Thus, scientific experiments and their resources can be described using OPM in a unified way. OPM data management tools provide facilities for specifying and querying relational databases in terms of OPM constructs, and automatically generate database specifications and queries for implementing OPM on top of commercial relational database management systems (DBMSs). OPM tools increase the efficiency of developing scientific databases using relational DBMSs, while insulating scientists from the underlying DBMSs.

Software architecture of the SSC accelerator systems string test

The software architecture is described for the data acquisition and control systems implemented to support a full cell test of collider arc section lattice components. The discussion is divided into descriptions of the software applications for process controls, operator interfaces, and data acquisition, archiving, and analysis. Specifics are presented for the distributed implementation of the acquisition, archiving, and analysis services, and their integration with a commercial Relational Database Management System (RDBMS). The relational table structure used in the RDBMS is explained. Finally, system performance, lessons learned, and future plans are summarized.

The Intelligent Monitoring System

Abstract The Intelligent Monitoring System (IMS) is a computer system for processing data from seismic arrays and simpler stations to detect, locate, and identify seismic events. The first operational version processes data from two high-frequency arrays (NORESS and ARCESS) in Norway. The IMS computers and functions are distributed between the NORSAR Data Analysis Center (NDAC) near Oslo and the Center for Seismic Studies (Center) in Arlington, Virginia. The IMS modules at NDAC automatically retrieve data from a disk buffer, detect signals, compute signal attributes (amplitude, slowness, azimuth, polarization, etc.), and store them in a commercial relational database management system (DBMS). IMS makes scheduled (e.g., hourly) transfers of the data to a separate DBMS at the Center. Arrival of new data automatically initiates a “knowledge-based system (KBS)” that interprets these data to locate and identify (earthquake, mine blast, etc.) seismic events. This KBS uses general and area-specific seismological knowledge represented in rules and procedures. For each event, unprocessed data segments (e.g., 7 min for regional events) are retrieved from NDAC for subsequent display and analyst review. The interactive analysis modules include integrated waveform and map display/manipulation tools for efficient analyst validation or correction of the solutions produced by the automated system. Another KBS compares the analyst and automatic solutions to mark overruled elements of the knowledge base. Performance analysis statistics guide subsequent changes to the knowledge base so it improves with experience. The IMS is implemented on networked Sun workstations, with a 56 kbps satellite link bridging the NDAC and Center computer networks. The software architecture is modular and distributed, with processes communicating by messages and sharing data via the DBMS. The IMS processing requirements are easily met with major processes (i.e., signal processing, KBS, and DBMS) on separate Sun 4/2xx workstations. This architecture facilitates expansion in functionality and number of stations. The first version was operated continuously for 8 weeks in late-1989. The Center functions were then transferred to NDAC for subsequent operation. Later versions will be distributed among NDAC, Scripps/IGPP (San Diego), and the Center to process data from many stations and arrays. The IMS design is ambitious in its integration of many new computer technologies, but the operational performance of the first version demonstrates its validity. Thus, IMS provides a new generation of automated seismic event monitoring capability.

A relational database system architecture based on a vector-processing method

A new relational database system architecture based on a vector-processing method is presented. The similarity between table and vector structures has been studied. This similarity implies that vector processors have high potential for the performance improvement of relational database management systems (RDBMS). In commercial RDBMS, however, data records are internally organized in complex pointer structures, to which vector processing is not directly applicable. We propose a new vectorization method by which data in the pointer structures are dynamically rearranged into the vector form, and collectively processed using a pipelined vector processor. A new pipelined vector processor called an integrated database processor (IDP), which is particularly suitable for our vectorization strategy, has been developed. IDP is designed as an optional hardware for a general-purpose computer. The vectorization method and IDP are applied to Hitachi's recently announced, commercial RDBMS (called RDB1/IDP). In this paper, the vectorization method and the architecture of IDP are described. The performance improvement is also described and analyzed.

LOCUS database system

LOCUS is a database system for creating, manipulating, and interactively investigating databases. LOCUS was written in response to the need to study the data from the experimental devices at the Princeton Plasma Physics Laboratory and is now also used extensively at other fusion laboratories. An example of its use is the determination of scaling laws for tokamak plasmas. To do this, LOCUS allows the user to enter and modify data, define subsidiary variables as arbitrary functions of original data, plot and fit such variables, and perform multiple linear regression analysis. Through a flexible interactive interface the program is easy to learn and largely self-documenting. There are two implementations of LOCUS: one that manipulates data in VAX/VMS ISAM files and another that manipulates data in the commercial relational database management system INGRES.

ISIS: the interactive spatial information system

Spatial display, especially dynamic spatial display, may help the symbiosis between human intuition and computer logic. An interactive spatial information system (ISIS) can be designed to support this symbiosis. It can act as a decision support system both by aiding the user to discover options as well as by assisting in their evaluation. An ISIS should be able to perform intelligent operations on its data, detecting inconsistencies between new and old information, assisting in the evaluation of plans, and so forth. DCIEM has developed a miniature ISIS called SDBMS-1, using an extension of a commercial relational database management system. It allows the user to interact by keyboard, voice, or graphic gesture, and provides output alphanumerically or graphically. The information consists of topographic data from digitized standard maps and synthetic tactical data representing military operations. SDBMS-1 has been implemented using MASCOT technology, to permit easy modification as a consequence of experience. Development of an improved ISIS requires analysis of the nature of the human-computer dialogue and the potential contribution of artificial intelligence. Ideas on “intelligent dialogue”, and better methods for browsing are explored in the context of ISIS.