Introduction to IBM DB2 Connect (1) _db2

The DB2 tutorial you are looking at is: IBM DB2 Connect Introduction (1).
In part 1th of this series, we initially talked about the different programming interfaces provided by DB2 Connect and the drivers that implement those interfaces. In the last few sections, we describe roughly the communication infrastructure provided by DB2 Connect and see how this infrastructure can significantly reduce the use of large host resources, How to allow distributed applications to take advantage of the benefits of a large host platform (for example, easily managing mixed workloads and providing continuous application availability).
You may still remember figure 1, in this picture, DB2 Connect consists of a programming interface (implemented as jdbc™, SQLJ, ODBC, DB2 CLI, OLE DB,. NET®, and Embedded SQL drivers) and a communications infrastructure.
Figure 1. DB2 Connect consists of a programming interface and a communications infrastructure that enables client server applications and web-based applications to take advantage of large hosts





In this article, we will discuss one of the functions of the above communication infrastructure, that is, how DB2 Connect provides a unified access to heterogeneous distributed data.
Before we discuss the specifics of this solution in terms of unified access, distribution, and heterogeneity, we need to turn our attention to the communications infrastructure itself. DB2 Connect provides this communication infrastructure in the form of a communications server that can be deployed on Windows®, Linux (for example, Linux for zSeries) and UNIX® servers. This communication server is built using the same code base that was used to build the DB2 UDB database server, so it inherits all the qualities that are in the architecture of the DB2 UDB server.
In fact, the functionality we describe in this article requires that you create a database on the DB2 Connect server itself (where you do not need DB2 universal database™ (UDB)). At first glance, this seems to contradict the statement in part 1th of this series where we say that DB2 Connect simply connects the application to the DB2 for z/Os and DB2 for iseries® database, and DB2 Connect does not manage the data. It should be clarified, however, that the database that we are creating on the DB2 Connect server does not store data. It is used only as a single connection point to provide uniform or single database mirroring to the application. As a result, the DB2 connect server simply routes requests for data to different database servers that actually manage the data.
While in part 1th you understand some of the features of the communication pipeline that really makes DB2 connect different from other competitors, you probably already know that DB2 Connect has at least done its job (connecting applications to large hosts). Now that you have a better understanding of the underlying architecture of DB2 Connect, the next step is to provide a further content than the 1th part of this series (subtitle-Within the Universe)-we'll start with the 2nd part.
In the 2nd part, we'll talk about DB2 Connect as a data access platform, where we're not just talking about DB2 on a mainframe. For example, do you know that the DB2 connect workstation can execute a distributed connection (join) between a DB2 for z/OS database and a informix®ids on a Windows database in the same transaction, and it can also use the built-in two-stage reference within the same commit scope To update these data sources with the support of two-phase commit,2pc. I mentioned that you will find some ingenious features, which is one of them! If that sounds like a federation, or more like Websphere®information Integrator (formerly DB2 Information Integrator), that's right. In fact, all DB2 UDB and DB2 Connect servers are shipped with WebSphere Information Integrator Federated support for the entire DB2 UDB family and the Informix IDS built into the engine. Products such as WebSphere Information Integrator extend the scope of the federated engine to include other relational data sources (Oracle, Microsoft®sql Server), non-relational data sources (Adabas, VSAM), OLE DB, XML, and any other data source in the enterprise.
Unified access to heterogeneous distributed data sources
You may know what the meaning of Unification (unified), distribution (distributed), and heterogeneous (heterogeneous) means, but it may not be clear how DB2 Connect implements these concepts. You may be familiar with IBM WebSphere information Integrator products and will think that these words describe these products well. Please continue reading this article so that the interrelationships between these products will become clearer.
Unified access is a great way to reduce the complexity of opening applications in a heterogeneous environment. Although application programmers can always build connections to individual 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 driver). If you use multiple different connections in your application, you cannot treat data as if it were managed by a single database (for example, an application programmer must fetch data from multiple data sources before you can perform a connection operation). Also, when multiple different connections are used, the location of the code in the application is fixed so that the data architect is not free to modify the location of the data to accommodate the changing business requirements.
In contrast, the unified data access mechanism provides application programmers with a single point of connection to all data assets of the enterprise. It allows you to use a single API (driver) that allows you to use a style of SQL (you don't have to worry about SQL Server using currency data types while DB2 UDB does not use this type), it also abstracts the data location so that you can change the data location without affecting existing applications. Finally, it allows programmers to treat all data consistently as if they were from the same relational database, and that database can manage the connection, sorting, and filtering of data in a way that guarantees transactional integrity-and, thanks to an extension of the basic features of DB2 Connect, The backend data source does not necessarily have to be a relational data source (for example, it can be a VSAM or Adabas data source).
I hope you've made it clear that using a single database is much simpler than coordinating access to multiple data sources. But what's different about our IBM information management solutions is that we don't expect you to cancel your existing applications and migrate them all to the DB2 database because that's not realistic.
DB2 Connect uses one of the following three different mechanisms to achieve a simple and intuitive access method:
Federal database
Stored Procedures
SQL functions
DB2 Connect and Federated database
DB2 Connect comes with a built-in base-level federated database feature. You may be familiar with this feature, as previously IBM Datajoiner products also provide this functionality. Starting with Version 8, federated database support has become part of the DB2 Connect and DB2 UDB server, and anyone who does not need to buy additional products can use this feature. In other words, when you deploy the DB2 Connect server on Linux, Windows, and UNIX servers, you can create a federated database, and the application can connect to the federated database. When a connection to the federated database is established, the request is routed to the real data source-but the complexity of function compensation, data type conversion, and optimization of efficient data retrieval is transparent to the user.
The federated components of DB2 Connect include the DB2 udb for Linux, DB2 udb for UNIX, DB2 udb for Windows, DB2 udb for VSE/VM, DB2 udb for z/OS, DB2 UDB F Read/write support for or iSeries and Informix IDS database servers.
You can use the federated features in DB2 Connect to perform 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