EMBL Nucleotide Sequence Database
Object Model

The EBI has now begun to make use of the Common Request Broker Architecture (CORBA) for the distribution and querying of biological data. The Radiation Hybrid Database is already available through CORBA. The next project is to make the EMBL Nucleotide Sequence Database accessible.

The primary goal of this project is to create an object model of the EMBL database, that defines the data in detail as a basis for an IDL interface to a CORBA server. A secondary goal is to develop a more general model of annotated sequence databases, that can be re-used for othere databases maintained at EBI. Such a general model will not be described in this document, however.

The EMBL Nucleotide Sequence Database is implemented in Oracle. To reflect the database precisely, the object model will inevitably contain legacy from the relational schema. For instance, features have been organized into groups, based on their biological meaning. We have not considered alternative grouping, but are aware that the assignment of features to groups can be debated.

Although the UML supports full object oriented systems design, we have mainly used its static, data structuring parts in this project. Thus most classes described so far do not yet contain methods. To define how to access data, methods need to be provided as well, and most likely also new classes representing factory objects that are able to create instances of the "data classes" which are results of queries.

• full version (postscript)
• short version - without full explicit feature model (postscript)

Class documentation is extracted from the RationalRose *.mdl file and converted to html format.

• Classes have capitalized names (e.g. Book). For composite terms, each word of the term is capitalized (e.g. JournalArticle).
• Attributes, methods, associations and roles have lowercase names (e.g. id). For composite terms, the first word is in lower case and the following words are capitalized (e.g. scientificName).
• Roles of an association are normally given the same name as the class at that end of the association, but not capitalized. If misunderstandings can arise, e.g. in reflexive relationships like node links in a tree, the roles are given other suitable names (e.g. parent, children).

• A structured (composite) data type is represented as a class (as usual in OO modeling). A class is used as an attribute type mainly if its role is solely to bundle simple data into a composite type (e.g. Date). A link to another class instance is usually represented using an association. An important exception to this rule occurs in the feature meta model, where associations are replaced by attributes representing cross-references to other classes/parts of the model.
• Multi-valued attributes are represented by instances of a parameterized class Coll{Type} (e.g. Coll{string}). Alternatively, an association can represent a multi-valued attribute. This would, however, "drown" the model in many extra classes, that are only present for the sake of attributes being multi-valued.

• Sequence Info
  classes representing biological sequences, general information about those sequences and administrative data associated with database entries

• Feature Info
  classes representing detailed sequence annotation (i.e. sequence features)

• Reference Info
  classes representing literature and other references that hold information about the sequences

• Taxonomy Info
  classes representing the taxonomy of the organisms from which the sequences were obtained

• Location Info
  classes representing locations on sequences

There is one additional package, Types, that holds classes representing all the special data types used in various parts of the model.

Each package contains a relatively isolated part of the entire object model, and is a clear candidate for re-use in models for other databases.

As a consequence of the rapid developments in molecular biology, the definition is prone to change and the collaboration revises it accordingly at the annual meetings. This poses a challenge to the object model. Any change made to the structure of the model needs to be propagated to both the IDL defining the CORBA server interface and the underlying relational schema. This increases the maintenance work for database management, and also for client programs that have to be updated accordingly. Our solution to this problem is to define two models for the feature table:

The Explicit Model

This model represents the feature table definitions explicitly in classes with attributes and associations. Each feature is represented by a class, and qualifiers are class attributes or associations to other classes. Biologically similar features inherit from the same superclass, that defines their common attributes. Thus the set of valid features and qualifiers, as well as the rules defining which qualifiers can be used with which features are represented explicitly through the model structure. This makes the model unstable, and therefore unsuitable for defining an IDL. Also, the model is very big: with 63 feature classes plus their superclasses the IDL would become difficult to manage and require a lot of casting operations. The model is useful, however, for understanding the structure and constraints present in the data and to see how the model maps onto the existing relational schema.

The Meta Model

This model defines only one class for all features and one class for all qualifiers and an association between them to represent the feature table. Meta data is used to describe the rules for combining features and qualifiers as shown in the following table:

max / min	0	1
0	invalid	invalid
1	optional single-valued	mandatory single-valued
2	optional multi-valued	mandatory multi-valued

For each feature/qualifier combination the minimum and maximum number of qualifier values for that feature is given. This setup covers all possible cases of validity (valid / invalid), participation (optional / mandatory) and multiplicity (single-valued / multi-valued) constraints that can exist between features and qualifiers. The structure of this model is not affected by changes to the feature table definition, which makes it suitable for defining a stable IDL.