Site Map | Contact Us

StorHouse/UDB Link

Extending IBM DB2 Universal Database (UDB) Capabilities with StorHouse/UDB Link

StorHouse/UDB Link, also called the FileTek wrapper, implements the connection between DB2 UDB release 7.1 (with fix pack 3) or later and StorHouse databases. It enables IBM DB2 UDB users to enjoy the benefits of StorHouse scalability, manageability, and economic savings while protecting their investments in DB2 applications.

Federated Systems
A federated system is a relational database management system (RDBMS) that supports applications and users who submit SQL statements that reference two or more RDBMSs or databases in a single statement (for example, a join between tables in different databases).

The components of a federated DB2 UDB system with StorHouse/UDB Link are:

How a Federated System Works
In a federated system, a client communicates with a federator, a software component that coordinates SQL processing. DB2 is both a federator and an RDBMS. The federator appears to the client as a database.

The federator:

• Accepts and parses a query from the client

• Breaks a query into smaller queries

• Submits these queries to one or more data sources, which are databases or servers in the federated system

• Receives the results from the data sources

• Assembles the results into a single answer set

• Returns the answer set to the client

The federator maintains a local data dictionary. This dictionary contains descriptions of the data sources and their available data. (Each StorHouse database is a separate data source.) The federator uses information in the data dictionary to decide which portions of the original query will be processed by StorHouse and DB2 UDB. The dictionary also contains user mappings, which associate DB2 authorization IDs with StorHouse account IDs.

Partitioning data
In a federated system, you must determine where you partition, or distribute, data between DB2 and StorHouse. Criteria for partitioning data include frequency of access, volume of data, and volatility of data. Partitioning models that work well with StorHouse are:

Horizontal partitioning. Horizontal partitioning divides rows into sets. Within each set, the rows remain intact. Partitioning criteria are usually range-based, like date. For instance, rows with the current month could be stored in DB2 and rows with past months could be stored in StorHouse. Or rows with pending orders could be stored in DB2, and rows with filled orders could be stored in StorHouse.

Vertical partitioning. Vertical partitioning splits rows into two or more sets of columns, and bases the data placement decision on the use of columns rather than rows. Columns that are frequently accessed, smaller, or more volatile could be stored in DB2. Those columns that are infrequently accessed, larger, or more stable could be stored in StorHouse.

Summary–Detail partitioning. A third data model places summary data in DB2 and detailed data in StorHouse. This can be effective if you can divide users into groups based on data access patterns. Frequently, summary data is sufficient for most users, while only a small number of users need access to the full detail.

Duplication. In some cases, it may be beneficial to duplicate data between DB2 and StorHouse. This can be full duplication of all data or duplication of a subset. Full duplication turns StorHouse into a disaster recovery facility.

Continue

More Information
- StorHouse
- Oracle Access
- SQL Server 7
- Database Interconnect

Copyright © FileTek, Inc. 2002-2008
All rights reserved.

Webmaster@filetek.com
Legal notices and trademark attributions