Advantages of enterprise beans in a federated system

By using enterprise beans and federated system objects, programmers can perform database operations and access multiple data sources. Programmers can create applications that integrate disparate data through Enterprise JavaBeans technology.

Accessing disparate data sources

Without a federated system, accessing disparate data sources requires multiple steps:
  1. You must connect to each data source individually.
  2. You must extract the necessary data by using different native application programming interfaces.
  3. You must filter, sort, and consolidate the data manually.

A federated system is a type of distributed database management system that makes it possible for you to send distributed requests to multiple data sources by issuing a single SQL statement. With a federated system, you simply query the nicknames of the data sources by using SELECT, INSERT, UPDATE, and DELETE statements.

In a federated system, you have transparent access to data that spans multiple heterogeneous sources. Federated systems complement the built-in database support that is provided by Web application servers and enterprise beans.

Federated views

By using the Db2® view objects, database administrators can create views of data that span multiple tables from different data sources. You begin the process of building a view in a federated system by creating nicknames for the remote data objects. Then you issue an SQL statement that creates a view that joins the nicknames. Even though the views that join multiple data sources are read-only views, you can map container-managed persistence entity beans to these read-only views. The container-managed persistence entity beans are read-only beans.

Materialized query tables

You can incorporate materialized query tables into your application to improve performance. With materialized query tables, you can precompute whole or parts of each query and then use the computed results to answer future queries. Materialized query tables help to avoid redundant scanning, aggregating, and joining of data

With materialized query tables, you can process queries when the remote data source is not available (such as when the network is not available). A materialized query table on a remote table is perceived as a cache for that table, which enhances system availability.

A materialized query table can increase the scalability of the overall system by reducing the work on the primary database. You can use several local databases to perform the work. Each database contains a copy of a subset of the frequently used primary data.

By using materialized query tables, you can avoid some connections to remote systems for some queries. The overall system throughput can potentially increase, and your total response time can decrease.