Introduction to IBM DB2 Connect (1)

The db2 tutorial is: IBM DB2 Connect introduction (1 ).

In part 1 of this series, we initially talked about the different programming interfaces provided by DB2 Connect and the drivers that implement these interfaces. In the last few sections, we roughly describe the communication infrastructure provided by DB2 Connect and see how this infrastructure greatly reduces the use of large host resources, how to allow distributed applications to take full advantage of the advantages of a large host platform (for example, easily managing hybrid workloads and providing continuous application availability ).

You may still remember Figure 1. In this figure, DB2 Connect is implemented by programming interfaces (JDBC, SQLJ, ODBC, DB2 CLI, ole db ,. NET and Embedded SQL drivers) and a communication infrastructure.

Figure 1. DB2 Connect consists of a programming interface and a communication infrastructure. The communication infrastructure enables client server applications and Web-based applications to take advantage of the advantages of large hosts.

We will discuss in this article how DB2 Connect provides unified access to Heterogeneous Distributed Data, one of the features of the communication infrastructure above.

Before discussing the details of such a solution in terms of unified access, distributed and heterogeneous features, we need to focus on the communication infrastructure. DB2 Connect provides this communication infrastructure as a communication server, which can be deployed on Windows, Linux (such as Linux for zSeries), and UNIX servers. This communication server is built based on the same code used to build the DB2 UDB database server. Therefore, it inherits all the qualities of the DB2 UDB server architecture.

In fact, the feature we described in this article has a requirement that you create a Database on the DB2 Connect server itself (you do not need DB2 Universal Database (UDB) here )). At first glance, this seems to be in conflict with the statement in section 1st of this series, where we say that DB2 Connect only connects applications to the DB2 for z/OS and DB2 for iSeries databases, DB2 Connect does not manage data. However, it should be clarified that the database we create on the DB2 Connect server does not store data. It is used only as a single connection point to provide a unified or single database image for applications. Therefore, the DB2 Connect server only routes data requests to different database servers that actually manage data.

Although you have learned some features of the communication pipeline that really distinguishes DB2 Connect from other competitors in part 1, you may already know that, DB2 Connect is at least responsible for connecting applications to large hosts ). Now you have a better understanding of the underlying architecture of DB2 Connect. Next, we will provide part 1 of this series of articles (Subtitle: Qian Kun) further content-we will start Part 1 from here.

In part 2, we will talk about DB2 Connect as a data access platform. Here we are not just talking about DB2 on large hosts. For example, do you know that the DB2 Connect workstation can execute a distributed join between a DB2 for z/OS database and Informix IDS on a Windows database in the same transaction ), it can also use built-in support for two-phase commit (two-phase commit, 2 PC) In the same submission scope to update these data sources. I mentioned that you will find some clever features. This is one of them! If it sounds like Federation, or more like WebSphere Information Integrator (formerly DB2 Information Integrator), that's right. In fact, all DB2 UDB and DB2 Connect servers come with WebSphere Information Integrator's federal support for the entire DB2 UDB family and Informix IDS built in the engine. Products such as WebSphere Information Integrator extend the scope of the federal engine to include other relational data sources (Oracle, Microsoft SQL Server), non-relational data sources (ADABAS, VSAM), ole db, XML, and any other data sources in the enterprise.

Unified Access to Heterogeneous Distributed Data sources

You may know what unified, distributed, and heterogeneous means, but you may not know how DB2 Connect implements these concepts. You may be familiar with IBM WebSphere Information Integrator and may think that these terms describe these products well. Continue to read this article so that the relationships between these products become clearer.

Unified Access is a good way to reduce the complexity of opening applications in heterogeneous environments. Although application programmers can always establish connections to various data sources, it is easier to use only one database connection in the application. Different connections to different data sources require multiple drivers (for example, a separate DB2 and Informix JDBC drivers ). If multiple different connections are used in an application, data cannot be treated as managed by a single database (for example, the application programmer must retrieve data from multiple data sources before performing the connection operation ). In addition, when multiple different connections are used, the location of the Code in the application is fixed, so that the data architect cannot freely modify the data location, to adapt to changing business needs.

On the contrary, the Unified Data Access Mechanism provides application programmers with a single point of connection to all data assets of the enterprise. It allows the use of a single API (driver), allows the use of a style of SQL (you do not have to worry that SQL Server uses the currency data type while DB2 UDB does not use this type ), it also abstracts data locations so that data locations can be changed without affecting existing applications. Finally, it allows programmers to treat all data in a consistent manner, as if they come from the same relational database, in addition, the database can manage the connection, sorting, and filtering of data while ensuring transaction integrity-and because of the expansion of the basic features of DB2 Connect, the backend data source does not have to be a relational data source (for example, it can be a VSAM or ADABAS data source ).

I hope you know that it is much easier to use a single database than to coordinate access to multiple data sources. However, the difference between our IBM information management solution is that we do not expect you to cancel the existing applications and port them all to the DB2 database, because that is unrealistic.

DB2 Connect provides simple and intuitive access methods through one of the following three mechanisms:

Federated database

Stored Procedure

SQL Functions

DB2 Connect and federated database

DB2 Connect comes with a built-in basic level federated database feature. You may be familiar with this feature because it was also provided by IBM DataJoiner. Since Version 8, federal database support has become part of DB2 Connect and DB2 UDB servers. This feature can be used by anyone who does not need to buy additional products. In other words, when you deploy the DB2 Connect server on Linux, Windows, and UNIX servers, you can create a federated database and applications can Connect to it. After establishing a connection with the federated database, requests are routed to the real data source. However, the complexity of function compensation, data type conversion, and effective data retrieval is transparent to users.

The federated components of DB2 Connect include DB2 UDB for Linux, DB2 UDB for UNIX, DB2 UDB for Windows, DB2 UDB for VSE/VM, DB2 UDB for z/OS, and DB2 UDB for iSeries. and read/write support for the Informix IDS Database Server.

You can use the federal function in DB2 Connect to execute distributed requests across these servers, as shown in Figure 2:

Figure 2. federated database functions of DB2 Connect

For example, the following statement:

SELECT * FROM T1, T2 where T1.C1