Biomedical Engineering Reference
In-Depth Information
included in a data warehouse have been identified, the data from each application are cleaned (typos
and other errors are identified and removed or corrected) and merged with data from other
applications. In addition, there are the usual issues of database design, provision for maintenance,
security, and periodic modification.
Figure 2-13. Centralized Database Architecture. A centralized database,
such as a data warehouse, combines data from a variety of databases in
one physical location.
A data warehouse isn't simply a large hard disk, but a database system implemented on a tiered
storage system that reflects access time, cost, and data longevity constraints. For example, some
data may reside on fast magnetic media, such as hard disks, and other data may reside on slower
optical media. The goal is to keep the right information flowing to the right people in the most
intelligent form as quickly and efficiently as possible, which includes making provision for the storage
of both frequently and seldom-accessed data.
In contrast to a centralized architecture, distributed database architecture is characterized by
physically disparate storage media. One advantage of using a distributed architecture is that it
supports the ability to use a variety of hardware and software in a laboratory, allowing a group to use
the software that makes their lives easiest, while still allowing a subset of data in each application to
be shared throughout the organization. Separate applications, often running on separate machines
and using proprietary data formats and storage facilities, share a subset of information with other
applications. A limitation of this common interface approach, compared to a central database, is that
the amount of data that can be shared among applications is typically limited. In addition, there is
the computational overhead of communicating data between applications.
A challenge of using an integrated approach is developing the interfaces between the databases
associated with each application. When there are only a few different applications and operating
systems to contend with, developing custom interfaces between different databases may be tenable.
However, with multiple applications and their associated databases, the number of custom interfaces
that must be developed to allow sharing of data becomes prohibitive. For example, with 5 different
databases, 9 different custom interfaces would have to be developed. For 6 different databases, 11
interfaces would be needed. Because of the work involved, a typical scenario is incomplete
integration, as shown in
Figure 2-14
.
