Database Integration: Criteria and Techniques
Application Level Integration
The second technique performs the integration at the application level. This is shown in Figure
2. When
the applications have the capability to directly communicate with multiple databases, they can be modified
to retrieve information directly from the other systems.
This technique rates well against the data currency, administration and side-effects criteria. Since the
applications access the data directly in their “native” databases, the data is always current. The integrated
applications should behave like any other applications so typically there are no changes in administration.
Since this technique requires little or no changes to the database, the side-effects are minimal and existing
users and applications of the external systemsare not affected by the applications integrated with multiple
databases.
The disadvantages to this technique include the encapsulation, data synthesis, data integrity and scalabiltiy
criteria. This technique has very poor encapsulation and every application wi II have embedded
dependencies on the location of data. Since the integration is at the application level, any data synthesis
has to be implemented within the application. Similarly, if the integrated application is updating multiple
databases, the application has the added complexity of managing transactions that apply across databases.
Finally, this approach does not scale well. It works well for a few databases, but quickly becomes
cumbersome and expensive as the number of applications and databases increases.
Figure 2: Integration at the application level
The costs for this technique are back-loaded unlike the other techniques where the costs are front-loaded.
The initial implementation costs are low because many AM/FM/GIS products and database client
application tools such as PowerBuilder, Delphi and SQLWindows can simultaneous y communicate with
multiple databases. The initial implementation cost is usually somewhat higher than the previous
technique because extra work may need to be done in the applications for them to access the external
systems. Another increased cost is often in the network and communications. Since the applications are
communicate ng directly with the other databases, more network infrastructure is required for this technique
than for the file transfer level of communication needed in the previous technique. However, while the
implementation costs are second-lowest of the techniques, the costs for this technique increase over time
because the problems in encapsulation, data synthesis and data integrity all add complexity to the
applications which significantly increases their development and maintenance costs. In the long run, this
can be the most expensive technique to implement.
Data access and performance are rated as average for this technique. While the integrated applications
wi II have create, read, update, and delete access to the data, access to data in multiple databases is limited
to only those integrated applications. Performance is also rated as average and is primari Iy dependent on
how the applications work with the multiple databases. Performance can be quite fast for simple
operations Ii ke queries, but because the application has to handle al I the data synthesis, performance can
be quite slow for functionality such as summary reports and on-line analysis. Applications that do a lot of
data synthesis are also going to require more client resources.
Application Level Integration with Middleware
The third technique also integrates the databases at the appl ication level. It differs from the previous
approach by adding the use of middleware. Depending on the DBMSes used by the external systems,
sometimes applications may not be able to communicate directly with an external system. Middleware
provides a mechanism for appl ications to communicate with a database that are not inherently supported
by the application.
This technique behaves very similarly to the previous one since it only differs in the use of middleware. It
is Iisted separately in order to focus on the effect middleware can have on performance, cost, encapsulation
and data synthesis. Since applications are now one more layer removed from directly working with the
data, there is some performance penalty. With some middleware products, this performance penalty can
be quite significant.
Figure 3: Integration at the appl ication level using middleware
