Title Page
 Table of Contents

Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: A Federated multi-media DBMS for medical research : architecture and functionality
Full Citation
Permanent Link: http://ufdc.ufl.edu/UF00095170/00001
 Material Information
Title: A Federated multi-media DBMS for medical research : architecture and functionality
Series Title: Department of Computer and Information Science and Engineering Technical Report ; 93-006
Physical Description: Book
Language: English
Creator: Chakravarthy, Sharma
Krishnaprasad, V.
Tamizuddin, Z.
Lambay, F.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: January, 1993
Copyright Date: 1993
 Record Information
Bibliographic ID: UF00095170
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

199387 ( PDF )

Table of Contents
    Title Page
        Page i
    Table of Contents
        Page ii
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
Full Text

University of Florida
Computer and Information Sciences

... Department of Computer and Information Sciences
_ ^ Computer Science Engineering Building
SUniversity of Florida
Gainesville, Florida 32611

. V ..

A Federated Multi-redia DBMS for
Medical Research.: Architecture and

S. Chakravarthy
V. Krishnaprasad
Z. Tamizuddin
F. Lambay
email: sharma@snapper.cis.ufl.edu

Tech. Report UF-CIS-TR-93-006
January 1993
(Submnitted for publication)


1 Introduction 1
1.1 Application Scenarios ................... . . . . . .... 2
1.2 Functional Requirements ................. . . . . . .... 2

2 Traditional DBMS Limitations 3

3 Our Approach 4
3.1 Architecture ................ .. ................... 4
3.1.1 Federated Server .................. . . . . . .... 5
3.1.2 M editor ................... . . . . . ... 6
3.1.3 C(li.1. .. ...................................... 6
3.2 Functionality Supported by Regular C ... . . . ......... . .. 8
3.2.1 Integrated multi-media interface ................... . . ... 8
3.2.2 Customized Graphical User Interface .................. . . 9
3.2.3 Support for Scientific Experiments .................. . . 9
3.2.4 Knowledge Discovery and Scientific Analysis ....... . . . . . 9
3.2.5 Case-based matching, retrieval, and reasoning . . . . . . ..... 10
3.2.6 Image Processing, VDA, and Perspectives ..... . . . . . .. 10

4 Prototype Client DBMS Implementation 11

5 Conclusion 11

A Federated Multi-media DBMS for Medical Research:

Architecture and Functionality

S. Chakravarthy
V. Krishnaprasad
Z. Tamizuddin
F. Lambay

Database Systems Research and Development Center
Computer and Information Sciences Department
University of Florida, Gainesville, FL 32611
email:{sharma, vk, ztO, fal}@cis.ufl.edu

January 31, 1993

This paper identifies two critical problems in providing Database Management System sup-
port for medical research environments in general and for research requirements of individual
disciplines. The problems identified are that of maintaining multimedia data and providing a
uniform interface for various clients. Based on our analysis of the current setup and future
requirements, we propose a client-server architecture consisting of a cluster of heterogeneous
systems as server and two types of clients -regular and real-time -with different functional and
throughput requirements. We envision the regular client as a workstation based environment
supporting multimedia capabilities. The server is a federation of pre-existing heterogeneous sys-
tems that provides uniform and transparent access to multi-media information from the client.
Specifically, this paper discusses a client-server architecture that provides multi-media capability
at the client side for various purposes. This paper also discusses some of the functionality re-
quired at the client and proposes viable approaches for supporting them. The mediator concept
is used for supporting a federated server.

Index terms: Federated multi-media server, integrated multi-media user interface, real-time
client DBMS and experiment-based client DBMS, active functionality, knowledge discovery/scientific

1 Introduction

The functionality supported by extant database management systems (DBMSs) is mostly derived
from the requirements of business applications. There is a clear need for collecting, organizing, and
managing large amounts of disparate data in a number of other applications that have different sets
of requirements than traditional database applications. Although there has been some progress in
extending database support for engineering applications (such as computer aided design, geograph-
ical information systems), and medical diagnostic systems, there is very little or no research on
databases that meets the requirements of scientific disciplines.
In this paper we have identified the requirements of a real life medical (scientific) application. We
have identified two critical problems in providing Database Management System (DBMS) support

for medical research environments in general and for generic research requirements of individual
disciplines, such as neuro-oncology, radiology, and neo-natal care. The first problem is that of
an architecture for accessing multimedia data that are in pre-existing repositories and the second
problem is that of providing specific functionality for the user to use the system effectively. In this
paper we propose an architecture and identify core functionality to meet the requirements of this

1.1 Application Scenarios

A number of scientific disciplines -neuro-oncology, neuroscience, and radiology -within the Health
Science Center (HSC) at the University of Florida (UF) were analyzed to derive the database
requirements for supporting medical research and clinical evaluation. Both the current usage of
information technology and the perceived needs were studied to identify requirements in terms
of database functionality, data types and their storage needs, user-interfaces, database as well as
applications processing needs, and other special needs for this environment (e.g., image processing
and visual data analysis).
The Neuro-Oncology Program (NOP) at UF encompasses a full range of therapeutic studies and
clinical trials as well as analysis and integration of all the relevant factors at diagnosis and on the
determination of prognosis for a given patient. The Radiology department requires special access
to information for clinical support, research, and educational support within the department, for
other departments in the HSC and for other institutions and group meetings.
Currently, HSC and Shands Hospital use three systems -RIS (Radiology Information System),
HIS (Hospital Information System including the online medical record system) and PACS (Picture
Archival and Communications System). HIS stores patient demographics, patient location, history,
physical reports, laboratory results, surgery notes, radiology schedules whereas RIS stores digitized
X-rays and their interpretations. The HIS and RIS are currently under conversion to ORACLE
database with network based SQL capabilities over TCP/IP. A Sybase database currently supports
the PACS system (a Kodak jukebox) where all the scan images are stored. There is little or no
interaction among the three1 primary databases used. Much of the data used for neurology and on-
cology research is contained in these three databases. However, clinical scientists and practitioners
need a multimedia database that combines some information from each. For example, it is desirable
to plot the size of a tumor of a patient over a period of time and show images to demonstrate the
tumor's progress and effectiveness of therapies. Radiologists also need to locate studies with similar
characteristics from multiple patients, identified by text evaluation, lab results and image feature
analysis. When special image processing is performed on images for analysis, the results need to be
stored for comparison with other results for a specific patient as well as results of other patients.

1.2 Functional Requirements

From the above real life situation it is clear that the features supported by the extant databases
do not adequately meet the requirements of the medical research community. Specifically we have
1In addition to these three, there are several other databases (e.g., pharmacy database, cancer database etc.).

culled the following as generic requirements that are useful to a number of disciplines/groups within

a uniform, integrated approach for accessing and managing disparate data types (e.g., patient
data, demographic data, clinical data, textual data, various types of imaging data, audio
data), i.e., need for an integrated multi-media database;

ad hoc search, display, browsing, and context-based navigation through multi-media databases;
search on images is likely to be based upon description of image content (either derived or pro-
vided by an expert). Browsing interface requires the basic notion of time (if not a full-fledged
temporal database);

database support for setting up and conducting controlled experiments as well as analyzing
collected and derived/interpreted data for correlation with scientific hypotheses;

flexible, friendly, and customizable user interfaces to set up experiments, browse, and navigate
through multi-media databases;

integrated support for image processing and visual data analysis to derive interpreted/abstracted
information and storing them for further retrieval and analysis;

support for knowledge discovery techniques for substantiating scientific analysis/views;

support for case-based matching of complex subdatabase, retrieval, and reasoning.

The primary drawback of the current usage is that the tools that are being used were developed
to meet the requirements of a totally different class of applications and as a result do not suit
the requirements of these scientific applications. As a consequence, a large portion of the work
is done manually to compensate for the lack of functionality/support in the systems/tools used.
Another major problem is the fragmented nature of stored information and the difficulty involved
in extracting a subdatabase of interest.

2 Traditional DBMS Limitations

Since traditional DBMSs focused primarily on business applications, they do not lend themselves
readily to scientific applications. The first limitation is with the type of data handled by the
DBMS. The need to move beyond primitive data types such as unformatted data in the form of
text, graphics, image and voice becomes vitally important if we intend to use database technology
in scientific and other non-business environments. The second limitation is in the way in which
several data types are managed from the users' point of view. In the presence of new data types,
the traditional DBMS ways of managing formatted data becomes very clumsy and unnatural. The
final limitation is in the functionality/operations supported by traditional DBMSs. In the presence
of disparate data types, the operations need to include new data types as well as new operations
suited to the application at hand.

In recent years, development and use of computer-based tools is becoming almost common-
place, but in most cases, the tools have been developed independently, and the applications are
implemented in a largely autonomous fashion. The result is all too often a "Tower of Babel" with
each application having its own problem definition language and means for representing informa-
tion, thus making sharing of information among users or application subsystems almost impossible.
It has become increasingly clear that these computer-based systems should not be viewed sim-
ply as autonomous tools but need to be integrated to achieve broad information-processing and
decision-making capabilities to support business, health-care and manufacturing activities.
To summarize, a DBMS that meets the requirements of the scientific application at hand needs
to provide: 1) storage managers) to manage disparate data, effective utilization of the secondary
(and tertiary) storage, and ability to store image fragments and reconstruct an entire image when
needed, 2) capability to model complex multimedia applications including extensions to database
operations (like union, join etc) for multimedia data, 3) integrated multi-media user interface
that shows each data type in a medium appropriate for it (e.g. text in a formatted manner, CT
scan as pictorial data etc.), 4) reasonable level of performance, and 5) Lastly, a comprehensive
set of techniques and tools to provide an integrated applications environment for a multi-media
information system.

3 Our Approach

In this application, two broad community of users -clinical and research -can be identified and sev-
eral instances of each with their own perspective and goals. However, the commonality that binds
all of these groups is their need to share disparate data (and where necessary create their own
private data) collected at various stations (in the hospital, the HSC, and sometimes data collected
regionally), that reside in autonomous repositories. The fragmented storage and management of
data makes it difficult for viewing a meaningful subset of this data (e.g., retrieve all X-rays, their
interpretations, scan images, and lab reports of patients with ischemia who were treated at the
Shands hospital between January 1992 and December 1992) from a particular perspective. Apart
from the need for multiple perspectives, there are other requirements, such as image processing
and visualization of large images, that may require specialized hardware to perform image trans-
formation, feature extraction, and segmentation in a timely manner. In summary, we have, on
the one hand different collection of users with different requirements and on the other we have
pre-existing autonomous databases which act as the source of various types of data. This entails
that we provide an architecture that can support the required functionality at the individual group
level by providing uniform access to shared data from autonomous databases.

3.1 Architecture

The above requirements lead us to the client-server architecture which, as we substantiate below,
can provide the functionality requirements of the individual groups as well as uniform access to data
stored in several databases. The client-server architecture under development at the University of
Florida is shown in Figure 1.

Figure 1 is a client-server architecture [Sin92, RK86, RD90] where the server consists of a cluster

of systems that are used for storing various types of data collected at different stations. Note that

the server in this architecture is not a conventional server but is a cluster of heterogeneous systems.

Although there is some connectivity among the elements in the cluster and each element in the

cluster can be selected individually, the cluster as such does not provide uniform view for extracting

a subdatabase of interest. The autonomy of each system needs to be maintained. Hence the server

in our approach could be classified as a loosely coupled federation of heterogeneous database systems

as in [LMR90]. However, we should emphasize that, in the future, each element in the cluster may

not necessarily be a DBMS but may include expert systems and knowledge bases. We can identify

three key components of the architecture -a federated server, the mediator layer and ('1i. iI We

briefly describe each component in the following subsections.

E PACS Picture archiving and Communication
E MA System
A dIail PACS D
Federated T Sybase/Kodak HIS Hospital Information System
E Juke box A
Server L OLMR Online Medical Records


E M DBMS Multimedia Database Management
E M AE Multimedia Medical application
S Environment
M M'RTDBMS -- Multimedia Real-time DBMS

I M RT AE -Multimedia medical real-time
application environment


Extended Workstation (EWS) EWS + Large Cache (RAD-Unify) architecture

Figure 1: Federated ('i. Ii/Server DBMS Architecture for Medical Research

3.1.1 Federated Server

The server can be viewed as a federation of heterogeneous systems that provides a uniform interface

to the outside world (in our case to the client DBMSs) and at the same time preserves their local

autonomy and stand-alone access. Both local autonomy and stand-alone access are extremely

important as the data collection is distributed and the groups that are using the data are not

always the groups that generate data.

Traditionally, two approaches have been used for developing a federated DBMS. The first ap-

proach provides a globally unified view of all databases in the federation by generating a global/unified

schema (by integrating local schema of participating databases) in which structural, semantic, and

other types of inconsistencies have been resolved [SL90]. This is also referred to as a tightly coupled

federated system. The second approach is to have a loosely coupled federation or a multidatabase
system [LMR90] in which there is no unified schema but an extended language is provided to re-
trieve information from a collection of databases. For the application described in this paper, the
primary drawback of the first approach is that the integration of schemas (there may not be schemas
in some cases) is a complex problem and further does not scale well with respect to the number
of participating databases and the disparity of data (media and conventional data). Also, the
language for expressing global schema needs to be semantically richer than the individual models
which in itself could be a problem.
Since our approach is driven by the viability of the approach to a practical problem, we adopt a
variation of the multidatabase approach. This approach addresses the interoperability between the
various heterogeneous systems without requiring an integrated schema. In this application, as the
information is well partitioned based on the data type, we propose to develop a language interface
that does not require the user to specify the repository from which the data is retrieved. This can
be done either using some key words or using the context information from the query itself.

3.1.2 Mediator

The primary function of the mediator layer is to provide a view of the server that matches closely the
perspective of the research and clinical groups that access the server. It facilitates each user group
to develop suitable multimedia applications utilizing the data available on the server components.
In providing such an environment the layer should ensure transparent access to various components
for requests from clients on behalf of the user. The mediator layer is also shown in Figure 1. It
consists of the following two major layers:

Mapping layer This module of the Mediator uses an Index/Directory mechanism (which pro-
vides information as to where different types of data exist) and translates user queries/interactions
into corresponding queries/interactions on component databases. This layer provides the user
with an integrated view of the data. It fosters the use of high level constructs in data ma-
nipulation languages of the client DBMS's. This layer may have to assemble data retrieved
from component databases before presenting it to the client. For this purpose a database is
shown as part of the mediator layer.

Access layer This is an interface layer which would render physical access to each of the
independent databases. It accepts the queries/interactions generated by the mapping layer
and translates these queries into autonomous access calls to the component databases and
returns the results to the mediator layer. This layer will also be capable of interfacing with
non-dbms systems, if such a need should arise. We intend to use the available interface
(e.g., SQL*NET on TCP/IP for Oracle) where possible from the access layer and leave the
optimization issues for the component systems where they are adequately supported.

3.1.3 Clients

In the literature, three architectures have been proposed for a client DBMS [RD90]. Briefly, they
are: i) standard client-server architecture in which the client has no secondary storage or large

cache and every request is sent to the server and the server processes user data requests and sends
retrieved data, ii) RAD-Unify architecture in which the client has no secondary storage, but data
from the server is cached in a large main memory as much as possible and processed in the client,
and iii) extended workstation architecture (EWS) in which the client has secondary storage into
which a subset of data from the server is obtained and processed locally by the client.
As shown in Figure 1, in the medical research environment, two types of clients can be identified:
i) real-time clients and ii) regular clients.
Real-time clients: Real-time clients are those which are typically used in operating rooms,
wards, and other places where it is critical that a small portion of the database is displayed on
demand in almost real-time. The throughput and response time requirements on reasonably large
volumes of data is critical but there is very little manipulation other than browsing through data
associated with a patient. Many a time (as in the case of surgery), the subdatabase that needs
to be accessed can be specified in advance providing for advanced staging/caching (using active
capability [CAL93]).
Among the three client-server DBMS architecture proposed in the literature, a combination
of EWS and RAD-Unify seems to be appropriate for the real-time client. The caching of data
at the client site in this context would mean downloading data on to disks. Since some of the
operations are scheduled well ahead of time it is possible to download the entire medical history of
the patient at the client site. This method has distinct advantages. First, large cache (or array of
disks at the client providing parallel I/O) will help in providing good response time for browsing
and displaying. This architecture eliminates requests for the same data from the server and if there
are lot of real-time clients it also boosts the overall performance because client DBMSs access in
parallel local copies. This also reduces the load on the server I/O manager and since there are
no update operations from these type of clients the clients can disconnect themselves from the
server temporarily and work with the cached data even when the server is down. This sort of
temporary disconnection is particularly very useful in a medical environment as performing the
medical functions need not be disturbed by non-availability of data. The functional architecture of
a regular client is shown in the Figure 2.
Regular clients: Regular clients, on the other hand, are those which need to access and
manipulate reasonably large multi-media subdatabases used by individual groups, such as neuro-
oncology, radiology, and neuroscience. These clients need to access a reasonably large multi-media
subdatabase (for several patients) and manage this information over a period of time and process
them in various ways that are specific to the research objectives of that group or discipline. Among
the client-server DBMS architectures proposed in the literature, EWS is appropriate for the regu-
lar client. The client subsystem must ensure a close linkage between its components: multi-media
DBMS(M2DBMS) and the multi-media medical application environment (M3AE). M2DBMS
includes active functionality [C'\:.'l.: CHS93, sil.,l''-], supports multiple transactional stores, the
notion of time, in an object-oriented framework. The integrated M3AE consists of several interde-
pendent modules for viewing and browsing, tools for knowledge discovery, case based matching and
reasoning and scientific analysis. Experimentation is an integral component of medical research
and needs to be supported as part of the client multi-media medical applications environment.
Staging of data from the server is necessary for regular clients to reduce heavy load on the

Object query Customizable Image processing
and temporal Graphical & Visual data Support for
query processor User Interface analysis Expenments

SApplications Integration

Type Manager Active & Multimedia
Object Manager

Persistant Object Object Object Translation

Multiple Transactional
Message passing Bus

Figure 2: Functional Diagram of a Regular C'I. iII node

network and also to improve response time. However, we do not recommend that the entire medical
record data of all patients be staged. Since multimedia data requires lot of storage, it is not
advisable to cache the entire multimedia data at the client site. For this client, we have to consider
the problem of update propagation. As there will be a number of clients who can access the same
data and update them, it is necessary to first propagate the updates to the server before updating
the local copies. Periodically the server can transmit the relevant modifications to all other clients
having that data.

3.2 Functionality Supported by Regular Clients

In this section, we briefly describe the functionality support required as part of the multi-media
applications environment (M2AE).

3.2.1 Integrated multi-media interface

An integrated interface for browsing and displaying multi-media information is extremely impor-
tant. Techniques need to be developed for retrieving images based on descriptive data as well
as image features. Also, the basic notion of time for querying purposes and selective versioning
capability will also be part of the model as our analysis did not indicate the need for a full-fledged
temporal database functionality. Ability to customize interfaces on clients to suit the needs of
user's (varying from experts to novices) will be an important component that will be addressed as
part of this problem.

3.2.2 Customized Graphical User Interface

Though the kind of interface necessary varies from group to group in a medical research environ-
ment, it is important that the interfaces not be hard wired for a particular group or discipline,
since there is a clear need to provide for flexibility in creating new displays [HK92, CC(.I'i-'].
Current multimedia authoring systems [RK91], such as Macromind Director, are oriented toward
literal data, linking specific images, text, sounds, etc. together in a hypermedia network. The au-
thoring systems, and indeed the entire field, lack the concept of a database-driven multi/hypermedia
presentation of information. In a medical application, for example, not all patients have the same
set of tests, CAT scans, MRI scans, etc. This means that the user interface designer must be able
to create a presentation which has links whose existence depends on things like the type of illness
the patient has, or the number of imaging procedures, or whether there are any imaging procedures
at all. These dependencies are sometimes at the schema level, but in other cases may be at the
individual patient level. Many navigation approaches exist, as seen in Hypercard, TIES, Owl, and
others. Hence the task of examining several navigational approaches (such as hierarchical, fish-eye
lens view, 3D graphs) and developing one that is most suitable for implementation needs attention.
For this problem, we plan on developing a user interface that works not only with literal data as
do the current systems, but also with navigational schemas defined over objects in an OODBMS
(object-oriented database management system). The system will then be used to support a variety
of tools that are part of the applications environment.

3.2.3 Support for Scientific Experiments

Almost all scientific disciplines, unlike business applications, rely on experimentation. Currently,
there is very little database support for the management of scientific experiments and data associ-
ated with it. Maturation of database technology and its use for non-traditional applications entails
extensions to the technology in various ways. The major stages of the experiment life cycle consist
of: i) experiment design, ii) data collection, and iii) data exploration. Data exploration involves
data analysis along the lines mentioned under knowledge discovery functionality. Recently, there
have been several attempts at providing this support, namely, MOOSE [IL89, YLH92], the "lab-
oratory No-. 1.....1. effort at the Los Alamos National Laboratory [Nel90], and the "Chromosome
Information System" (CIS) database in LBL supported by the SDT [MF90], and ERDRAW design
tools [s:.1' II]
For supporting this functionality, we propose a subsystem for the management of an experiment
and the data produced throughout its life cycle. Unlike current practice, our goal is to provide an
integrated environment to medical researchers that will support a uniform user interface that will
support the entire life cycle of an experimental study. Emphasis is on the system being intuitive
to scientists, whose expertise on computer usage may be minimal.

3.2.4 Knowledge Discovery and Scientific Analysis

Knowledge discovery is the process of uncovering information that one is unaware of prior to the
discovery. This covers a broad spectrum -from discovering information that was unexpected to

a simple confirmation of a well known fact. The process of knowledge discovery [KI91] can be
summarized as follows: i) pose a query to the system, ii) peruse and absorb the answer, iii) refine
or reformulate the query, and iv) repeat posing the query until the knowledge is discovered. Our
approach will not attempt to transfer the burden of discovery to the system but will attempt to
amplify the role of the human in the loop by complementing the experts' ability to make effective

3.2.5 Case-based matching, retrieval, and reasoning

Both experimentation and treatment of patients result in cases that are useful for teaching as well as
classification. Often, the results of an experiment are classified and separated into cases and stored
so that incoming data/cases are matched against them. The fundamental strategy of case-based
reasoning systems is to address new situations by re-using applicable portion of prior experiences.
Although there are a number of techniques developed [Lea91, Ham89] for case-based reasoning in
AI (for law and non-multi-media medical diagnostics), the problem at hand is more complex and
has different characteristics than those studied in the literature.
To address this problem, we will concentrate on indexing strategies for efficient retrieval of
both formatted and unformatted data. Both descriptive data associated with an image as well as
extracted features will be used for indexing images. The notion of "similarity" needs to be included,
lest it reduces to an exhaustive search strategy, whereas appropriate discriminant needs to be
developed to keep the search space small. The use and applicability of meta-data and appropriate
discriminant will be organized into a hierarchy to avoid unnecessary search and retrieval.

3.2.6 Image Processing, VDA, and Perspectives

A common theme of our research is a database integrated interactive environment. However, with
image processing and visualization, the computational requirements for processing large image
matrix sizes often requires specialized hardware platforms to carry out the various techniques in
a timely fashion. For example, algorithms for computing image transforms, feature extraction,
enhancement, segmentation, area and volume analysis, geometric properties may require distinct
processing platforms to satisfy our interface performance demands.
To achieve this we need to first identify the minimal functional requirements for accomplishing the
visual display and analysis (VDA) of both 2-D (radiographs) and 3-D (MR and CT) data. Existing
software packages should be examined in consideration of these requirements and evaluated. Our
essential functional requirements includes: i) image processing and volume rendering ii) quantitative
measure of 2-D and 3-D shapes, and iii) geometric analysis and morphologic description. Remote
access to specialized hardware platforms needed to support these requirements shall be managed
within the context of a prototype client. The anticipated improvements in digital sensor resolution
should also be taken into account.

4 Prototype Client DBMS Implementation

Our prototype design is guided by extensibility/modularity principles. As shown in Figure 2,
multiple transactional stores will be made available to support multimedia data. This requires an
interface which translates front-end objects into underlying storage objects and vice-versa. There
are several advantages to supporting several persistent stores instead of a single monolithic one: i)
it is easy to add new types of stores without disturbing the existing system, ii) the initial design will
be guided by extensibility/modularity principles, iii) allows fine tuning the performance of retrieval
and update of each persistent store independent of the others, and finally iv) maintenance and
management of the system will be simplified. Also, our approach permits the unification of existing
databases into an integrated system. The active capability of the client will be used to i) support
constraints ii) to support asynchronous processing of images using triggers iii) to capture context,
semantics and multiple perspectives for various groups accessing the databases. The open OODB
[WBT92] from Texas Instruments, Dallas is being combined with the functionality of Sentinel
[CHS93, C'A.',.':] to provide active and multiple transactional store capability. This will be further
extended to include other functionality outlined in this paper.

5 Conclusion

In this paper we studied a real life scientific application and proposed an architecture to meet
its requirements. We have adopted a client/server architecture consisting of a federated server, a
mediator for providing suitable level of transparency, and different clients based on the requirements
of classes of users. While the server and the mediator mask the heterogeneity of the environment,
the client DBMS's provide the generic functionality required by each application. An Open OODB
architecture is adapted at the client DBMS keeping in mind the import of extensibility/flexibility
requirement. The client/server architecture provides horizontal as well as vertical scaling which
is extremely important for this application. Also, the range of possibilities for clients -from PCs
to full-fledged DBMSs -is equally important for users' to continue to operate without having to
migrate to new environments. In addition to the architecture, we have identified the functionality
of the multi-media application environment required for this application and sketched our approach
to incorporating them as part of this architecture.


[CAL93] S. Chakravarthy, M. Andraka, and D. W. Lee. Staging data in a client/server architecture: Se-
mantic modeling and client buffer management. Technical Report UF-CIS Tech. Report, Database
Systems R&D Center, CIS Department, University of Florida, E470-CSE, Gainesville, FL 32611,
January 1993. (Under Preparation).
[CAM93] S. Chakravarthy, E. Anwar, and L. Maugis. Design and implementation of active capability for an
object-oriented database. Technical Report UF-CIS TR-93-001, Database Systems R&D Center,
CIS Department, University of Florida, E470-CSE, Gainesville, FL 32611, January 1993.
[CC'\I'-'] M. P. Consens, I. F. Cruz, and A. O. Mendelson. \i-i...i ..1 Queries and Querying Visualiza-
tions". Sigmod Record, 21(1):39-46, March 1992.

[C'll'1..] S. Chakravarthy, E. Hanson, and S.Y.W. Su. Active Database Research at the University of
Florida. To appear in IEEE Quarterly Bulletin on Data Engineering, January 1993.

[Ham89] K. Hammond, editor. Proceedings of the Case-Based Reasoning Workshop. Morgan Kaufmann,
1989. Workshop Proceedings.
[HK92] Kyoji H. and Toshikazu K. Query by Visual Example: Content Based Image Retrieval In Proc.
of 3rd Intl. Conf. on EDBT Vienna, Austria March 1992.
[IL89] Y. E. Ioannidis and Miron Livvny. \IOOSE: Modelling Objects in Simulation Environment".
Information Processing., 1989.
[KI91] Ravi Krishnamurthy and Tomasz Imielinski. "Research Directions in Knowledge D.-
SIC \1OD RECORD., 20(3), 1991.
[Lea91] D. B. Leake. An Indexing Vocabulary fro Case-Based Explanation In Proc. of the 9th Intl. Conf.
Artificial Intelligence, pages 10-15, July 1991.
[LMR90] W. Litwin, L. Mark, and N. Roussopolous. Interoperability of multiple autonomous databases.
AC if Computing Surveys, 22(3):267-293, September 1990.
[MF90] V. M. Markowitz and W. Fang. "SDT- A Database Schema Dessign and Translation Tool".
Technical Report LBL-27843, LBL Berkeley, May 1990.
[Nel90] D. Nelson. "The Laboratory Notebook Technical Manual". Technical Report LA-UR 88-1'-_"..
Los Alamos National Laboratory, March 1990.
[RD90] Nick Roussopolos and Alexis Delis. \I...I.... Client-Server DBMS Ar. II.. .I Proc. of SIG-
MOD RECORD on Management of data, Sept 1990.
I;,1-I.] N. Roussopoulos and H. King. Principles and techniques in the design of adms+/-. Computer,
Dec. 1986.
[RK91] Ney D. R. and Fishman E. K. "Editing Tools For 3D Medical Imaging". IEEE Computer Graphics
and Application, Nov. 1991.
i, ,',-'] A. Sharma. On extensions to a passive dbms to support active and multi-media capabilities.
Master's thesis, Database Systems R&D Center, CIS Department, University of Florida, E470-
CSE, Gainesville, FL 32611, June 1992.
,,',-'] A. Sinha. "Client-Server Computing: Current Technology I;. .. Communications of AC 11
35(7 '-,. i..., July 1992.
[SL90] A. P. Sheth and J. A. Larson. Federated database systems for managing distributed, heteroge-
neous, and autonomous databases. AC if Computing Surveys, 22(3):184-236, September 1990.
5I'li] E. Szeto and V.M. Markowitz. "EDRAW A Graphical Schema Specification Tool". Technical
Report LBL-PUB-3084, LBL Berkeley, Oct. 1990.
[WBT92] D. Wells, J. A. Blakeley, and C. W. Thompson. Architecture of an open object-oriented database
management system. IEEE Computer, 25(10), October 1992.
[YLH92] E. Yannis, Miron Livvny, and Eben M. Haber. "Graphical User Interfaces For The Management
of Scientific Experiments and Data ". SICi \OD RECORD, 21(1), March 1992.

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs