Download Integration Through Data Federation

consolidation to provide support for the lowest drill-down level. In this case the
data warehouse acts as both the consolidated database server and the
federated database server.
򐂰 User needs are repeatable and can be predicted in advance.
When user queries are well-defined, repeated, and require access to only a
known subset of the source data, it may be cheaper to create a copy of the
data for local access and use. This approach also insulates the remote
operational data sources from large, complex, or poorly structured queries.
򐂰 Data transformations or joins needed are complex or long-running.
In cases where significant data transformations are required or where joins
are complex or long-running, it is inadvisable to have them run synchronously
as part of a user query due to potentially poor performance and high costs. In
such cases, creating a copy of the data through data consolidation would
seem to be more advantageous.
Using both data federation and data consolidation
It is likely that there will be cases where a combination of data federation and
data consolidation techniques is the best option.
One case is where a federated query can leverage data consolidation
functionality transparently. This is because sometimes a federated query will not
work. It could be because of network outages, for example. Here, for example,
data federation can use data consolidation to create or manage cached data. On
the other hand, data consolidation tools may be optimized of only a subset of
available data sources. Using data federation along with it can expand that
number, and allow pre-joining of data for a performance impact.
Later on in Chapter 7, “Optimization in a federated environment” on page 193,
we consider exactly such a combination of techniques through the use of
Materialized Query Tables (MQTs). MQTs are data stores of preprocessed data
from the remote data sources stored at the local federated server. We consider a
user query against the federated database where the underlying tables reside in
one or more remote databases. We demonstrate how we can exploit the
federated server to transform the query to instead reference the MQT residing
locally at the federated server.
1.3 Data federation examples
The previous sections have discussed the pros and cons of data federation, and
described it in general terms. In this section we present examples of data
federation in environments where DB2 is the base, and where Informix is the
base. These are simply to provide you with an idea of the capabilities for data
Chapter 1. Data federation overview
23