Databases and Systems

249
Every database entry is represented by a “struct”. In contrast to CORBA objects,
structs are passed by value. Access to the individual fields is therefore local and very
fast. On the other hand the application has to get the whole struct even if it is only
interested in the sequence field. Structs are nearly as convenient to use as CORBA
objects with one subtle difference. Structs can’t be referenced physically. In this
example the SwissProt entry contains the accession number of an EMBL entry. The
client has to know itself how to get the EMBL sequence given the accession number.
The upcoming CORBA 3.0 specification will address the pass-by-value issue and
make the definition of structs unnecessary in some cases.
Generic
In this approach the data model is not represented in IDL. The objects are instead
encoded in generic types like strings. The main advantage of this approach is ease of
maintenance. Using IDL, clients and servers have to be compiled together with the
classes, which are generated from the IDL definition. This can become a burden if
the data model is large or changes frequently. Generic representations are well suited
for generic applications, which are not interested in the semantics of the data. For
end-user applications (e.g. an alignment program) generic representations are very
cumbersome to use. An example of a syntax of this sort is the object interchange
format OIF, defined in the ODMG 2.0 standard [4].
Queries
The ability to express queries is important for all databases. This aspect is
standardized in CORBA through the query service specification [10]. The central
element is a CORBA object of the type query evaluator. A query evaluator takes a
query string as input and returns a reference to a result collection. This collection is
another CORBA object, which can itself implement the query evaluator interface.
Because the query service does not specify the elements of the result collection, it can
be combined with any of the above listed representations. Furthermore the query
service can be used with every possible query language depending on the underlying
database management system.
Conceptual Data Model
Even though Interface-Based and Struct-Based representations can have a very
strong similarity to the conceptual data model, it is important not to confuse them.
The purpose of the conceptual model is to model the data as they really are, using
concepts close to humans. Neither the database schema nor the IDL can replace such
a high level model. The database schema is specific to the used DBMS and may
contain optimizations. The IDL is independent from implementation details but it
represents merely an application specific view.