You can create, alter, and drop wrappers, server definitions,
user mappings, nicknames, and federated stored procedures.
Overview of federated systems
The various
organizations in a large enterprise often use different database management
systems to store and access their data. A federated system transparently
unifies the information from the various sources, which allows the
enterprise to use the full value of the data.
A federated
system is a special type of distributed database management system.
A federated system consists of a DB2® instance
that operates as a federated server, a database that acts as the federated
database, one or more data sources, and clients (users and applications)
that access the database and data sources.
The DB2 server in a federated system is referred
to as the federated server. Any number of DB2 instances can be configured to function as
a federated server. The DB2 instance
that manages the federated system is called a server because it responds
to requests from users and client applications. Users and applications
interface with the federated database that is managed by the
federated server.
A federated system is typically created on
a DB2 for Linux, UNIX,
or Windows system by completing
the following steps:
- Updating the database manager configuration properties for SVCENAME
and FEDERATED
- Creating a DB2 database
to manage federated access
- Installing any prerequisite software that is required by the target
data sources, and configuring network access to the systems on which
those data sources reside
- Creating wrapper, server, and user mapping objects for each data
source that is to be accessed
- Creating nicknames for the objects that are to be accessed at
each data source
Supported federated objects and data sources
With
IBM® Data
Studio,
you can create, alter, and drop wrappers, server definitions, user
mappings, nicknames, and federated stored procedures:
- Wrappers
- The mechanism that the federated database uses to connect to and
retrieve data from a data source. A wrapper must be created for each
type of data source that is to be accessed.
- Server definitions
- Information that identifies and defines the data source to the
federated database.
- User mappings
- The association between the authorization ID on the federated
server and the information that is required to connect to the remote
data source. The user ID and password that you use to access the federated
server are mapped to the user ID and password that you use to access
the data source server.
- Nicknames
- A local name that you create to identify each object at the data
source that you want to access. The object that the nickname identifies
is referred to as a data source object.
Table 1. Data
source objects that can have nicknamesData source |
Object |
DB2 for Linux, UNIX, and Windows |
Nicknames, materialized query tables, tables,
and views |
DB2 for
i |
Tables, views, physical files, logical files,
and table types |
DB2 for z/OS® |
Tables and views |
- Federated stored procedures
- A local stored procedure that is mapped to a stored procedure
at the data source.
When creating these objects for a federated
system, you must create the objects in the following order:
- The wrapper
- The server definition
- The user mapping
- The nicknames and federated stored procedures
The definitions of the federated objects are stored in the federated
database.
Restriction: You can define and deploy changes for these supported
federated objects only for these data sources that use DRDA® wrappers: DB2 for Linux, UNIX, and Windows, DB2 for i, and DB2 for z/OS.
Generated change commands for federated objects
As
with any changes that you make by using a change plan, you generate
change commands for your federated object changes that you then run
against the federated system.
When you alter a nickname, an
ALTER NICKNAME statement is generated only if you change the constraint
for the nickname or change the data type of the column. For all other
nickname changes, a DROP NICKNAME statement and a CREATE NICKNAME
statement are created.
Data preservation and data maintenance
commands are not included in the generated change commands. Data does
not need to be preserved because the federated object changes do not
affect remote tables. You can use always update statistics by using
the utility actions that are available by right-clicking an object
in the Object List.