Federated access

Normally, you can only accelerate queries if a Db2 subsystem is paired with an accelerator and if the tables to be queried exist in that Db2 subsystem. This can be regarded as a security feature; a second Db2 subsystem paired with the same accelerator cannot access tables in the first Db2 subsystem and vice versa.

However, there are situations in which one would like to lift this restriction: Db2 subsystems are often organized alongside geographical boundaries, temporal boundaries, or areas of business.

Geographical boundaries translate into a segmentation of the table data by region. For example, a company does business in the U.S. and in Asia; the tables in subsystem A contain the sales figures for the U.S.; the tables in subsystem B the sales figures for Asia.

If data is temporally segmented, the tables in each subsystem cover different time spans. For example, the tables in subsystem A contain the data related to recent business activities, reaching three months from the present time into the past. Db2 subsystem B, on the other hand, contains business data that is older than three months.

If data is segmented by areas of business, the organization of the database follows a company's key business areas or its product portfolio. Assume that an organization runs a chain of gas stations and also produces cosmetics (both business areas are based on oil). Subsystem A contains the data of the gas station business; subsystem B the data of the cosmetics business.

Frequently, the aim of analytical queries is to capture trends across regions, time lines, or business areas. In accordance with the previous examples, one would like to find out how the business in the U.S. develops against the business in Asia. How do recent sales figures compare with those of the past? What are the growth rates in the gas station business as opposed to those in the cosmetics sector?

Queries that answer these question require access to different data sources. If the data is segmented by the organization of the database, access must be extended to tables in other Db2 subsystems, and this is what the federated access feature is about.

An access extension to tables in a Db2 subsystem is achieved through the following steps:

1. A user with sufficient rights on the Db2 subsystem that owns the tables (remote Db2 subsystem) grants the right to access a set of tables to a Db2 subsystem that normally cannot access these tables (called the referencing Db2 subsystem).
2. A user with sufficient rights on the referencing subsystem runs a command to create reference tables. These reference tables contain metadata and pointers to accelerator-shadow tables on the accelerator. They are implemented as accelerator-only tables on the shared accelerator, with corresponding entries in the catalog of the referencing Db2 subsystem.
3. Queries from the referencing Db2 subsystem can now access these referencing accelerator-only tables.

See the following figure:

It is possible for the administrator of the owning Db2 subsystem to revoke the access privileges at any time.

It is also possible (for the administrator of the referencing Db2 subsystem) to remove the reference tables. This is mostly done when the data in these tables has become obsolete. To obtain results on more recent data, the administrator might want to delete the existing reference tables and create new ones.