Object-oriented DBMSs Research Articles

GOMS: Large‐scale ontology management system using graph databases

Large-scale ontology management is one of the main issues when using ontology data practically. Although many approaches have been proposed in relational database management systems (RDBMSs) or object-oriented DBMSs (OODBMSs) to develop large-scale ontology management systems, they have several limitations because ontology data structures are intrinsically different from traditional data structures in RDBMSs or OODBMSs. In addition, users have difficulty using ontology data because many terminologies (ontology nodes) in large-scale ontology data match with a given string keyword. Therefore, in this study, we propose a (graph database-based ontology management system (GOMS) to efficiently manage large-scale ontology data. GOMS uses a graph DBMS and provides new query templates to help users find key concepts or instances. Furthermore, to run queries with multiple joins and path conditions efficiently, we propose GOMS encoding as a filtering tool and develop hash-based join processing algorithms in the graph DBMS. Finally, we experimentally show that GOMS can process various types of queries efficiently.

What database management system(s) should be employed in bioinformatics applications?

1. No DBMS: Although most computer scientists would dismiss this alternative as ridiculous, I would wager that a significant number of the hundreds of molecular biology DBs that now exist are not constructed using any DBMS. This should make us all stop and think. Either the biologists who are constructing these DBs know something that computer scientists don’t know, or they don’t know something that computer scientists do know. I believe the latter is the case—I believe that the vast majority of biologists have not received even the most elementary education in DBs, and have little idea of how DBMSs can help them, nor of how to go about using a DBMS. Note that the situation today is far improved over that of ten years ago. Today most large DB projects do employ a DBMS, whereas 10 years ago virtually none did so. Bioinformatics is still suffering from those mistakes. 2. Open-source DBMSs: Many of the molecular-biology DB projects that are employing DBMSs are employing open-source DBMSs to save money and because they believe that access to the source code will be useful in fixing any DBMS bugs that are discovered, or in extending the DBMS. My limited understanding of these DBMSs is that they have significant technical limitations compared to commercial DBMS product, yet little hard information about this issue is circulating in the bioinformatics community. We should obtain and circulate such information, whether from the literature or by empirical study. I also believe that the DBMSs are sufficiently complex that access to their source code is essentially useless to any but the most experienced DBMS hacker (and perhaps not even to them), and that this point must be articulated to the community. 3. Commercial DBMSs: Many projects use commercial relational DBMSs, specifically, Oracle. Virtually no projects use commercial object-oriented DBMSs (OO DBMSs). Why? OO DBMSs were developed to overcome limitations of relational DBMSs, and have now existed for about a decade. Little hard information about this issue is circulating in the bioinformatics community. We should obtain and circu-

Query execution techniques for caching expensive methods

Object-Relational and Object-Oriented DBMSs allow users to invoke time-consuming ("expensive") methods in their queries. When queries containing these expensive methods are run on data with duplicate values, time is wasted redundantly computing methods on the same value. This problem has been studied in the context of programming languages, where "memoization" is the standard solution. In the database literature, sorting has been proposed to deal with this problem. We compare these approaches along with a third solution, a variant of unary hybrid hashing which we call Hybrid Cache. We demonstrate that Hybrid Cache always dominates memoization, and significantly outperforms sorting in many instances. This provides new insights into the tradeoff between hashing and sorting for unary operations. Additionally, our Hybrid Cache algorithm includes some new optimization for unary hybrid hashing, which can be used for other applications such as grouping and duplicate elimination. We conclude with a discussion of techniques for caching multiple expensive methods in a single query, and raise some new optimization problems in choosing caching techniques.

An object-oriented data model for distributed office applications

The object-oriented paradigm is becoming very popular for database applications and several object-oriented DBMSs have been developed. A basic notion in this paradigm is the inheritance hierarchy that allows the users to define objects and the associated operations starting from already defined objects. However, in database applications the inheritance hierarchy must provide a conceptual modeling function, in addition to the re-usability function. Another important requirement is to provide support for data distribution in (possibly) heterogeneous environments. This means that object implementation may differ depending on the object location. This paper presents a model that decouples these two aspects, modeling vs implementation, by using the concept of abstract and implementation classes. An abstract class specifies properties and methods for a set of similar objects, like in other object-oriented data models. An abstract class is however independent of the object implementation and location. An implementation class defines the implementation of an abstract class. In our model an abstract class may have several implementations. This allows the user to provide different implementations for the same set of objects, without requiring the objects to change class.