Databases and Systems

246
This central role of flat-files has several disadvantages. The most obvious problem
is that flat-files are difficult to use. Writing a parser is a non-trivial task, which is
further complicated by imprecisely specified and frequently changing formats.
Previous attempts to establish a standard flat-file format have failed because
biologists do not agree on a single model of their data. Another major draw back is
that flat-files can lead to an immense waste of computing resources. Different
programs often expect different flat-file formats so that the same site needs to keep
multiple copies of the same data (for example FASTA and BLAST). Finally, the wish
of human readability results in the attempt to keep all information associated with an
entry together. Since this attempt conflicts with the goal of normalization, flat-files
tend to be redundant. For instance the classification of a virus might be repeated in
all entries from that virus.
Strategy
It would not be realistic to abolish the usage of flat-files in general, but it is
necessary to allow for alternative solutions to overcome the problems discussed
above. This can be achieved only if the dependency on flat-files and their formats is
removed. The task for which flat-files are least suited - providing a programming
interface to application programs - demonstrates this point. A sequence comparison
program, which depends on a flat-file format, violates the principle of data
independence (see for example [6]). In an ideal world it should make no difference
whether an application accesses a local flat-file or a remote relational database as
long as both serve the same data. The concept of interfaces helps to achieve this goal.
Data source and application programs interact through interfaces, which hide the
underlying implementation details. A piece of software, which can be used in
different contexts through a defined interface, is called a component. But
componentry can work only if used together with a widely accepted standard for
defining interfaces and invoking methods through them. CORBA is such a standard.
CORBA
In 1989, the Object Management Group (OMG) was formed [19]. It now has more
than 700 members, including practically all major software vendors, hardware
vendors and large end-users. OMG’s stated goal is to standardize and promote object
technology. The core specification adopted by the OMG is the Common Request
Broker Architecture – CORBA; references [ 12] [ 14] give good introductions.
CORBA combines the concept of interfaces with the object oriented distributed
programming paradigm. Among other things it specifies:
the Interface Definition Language (IDL), which provides a language-independent
way of describing the public interface of objects.