An approach to object-relational mapping in bioscience domains.

Abstract

Object-relational mapping (mapping object-oriented software systems to relational databases) remains a challenging undertaking because of the inherent differences between these two technologies. Effective application of this technique in biomedical informatics applications can provide robust, adaptive solutions but requires careful attention to specific issues in the bioscience domain. Mapping from a single, fixed, stably defined object to a table is straightforward, and several standard patterns have been described for mapping inheritance trees to tables. However, mapping becomes more problematic when it involves complex, evolving inheritance trees, sparse, dynamic attributes, or associations and aggregations whose requirements and definitions change frequently during development. All of these seem to be inherent, inescapable facts in the development of biological information systems. Here we describe modifications of the basic patterns of object-relational mapping that are being applied to two systems in ongoing collaborations between biomedical investigators and informaticians. In this approach a small set of objects for each entity collaborates to provide the usual required services of an object-relational implementation including query capacity, transaction management, object relationships (associations, aggregation, composition, many-many relations) and persistence functions. This set of objects also allows dynamic attributes for a selected set of entities by merging an entity-attribute-value approach for data storage with the object-relational approach to managing relationships among objects. Templates are used for class generation to allow flexibility and synchronization of schema/object during design evolution, facilitating changing persistence strategies across the whole system for testing and development. The entity-attribute-value details as well as all database access are encapsulated in a persistence layer which would allow change of this layer to a conventional storage model, if the design evolution is stabilized or for performance requirements, with no change to the domain or presentation layers.