| Previous | Table of Contents | Next |
In 1994, we decided to name our database. We selected the name DB2 for OS/400 to reflect that it is part of the IBM DB2 family of relational database products.1 The family resemblance among these database products exists primarily in their external tools and their support for distributed database facilities. The underlying support is quite different in each case. The DB2 name does help alleviate the perception that the AS/400 does not have a modern, robust database.
1I was opposed to naming the AS/400 database until I had a meeting with a large manufacturing customer who was moving from another system to the AS/400. In the meeting, the technical people asked me what database I would recommend for the AS/400. I blurted out, “DB2/400,” a name being circulated in internal discussions. Immediately, the people in the room began to nod and make comments such as, “Oh, that’s a very good database.” Considering that these people worked for another division in IBM and they didn’t know the AS/400 had a database, it was obvious to me that we needed to name it.
The integrated database of the AS/400 is well positioned to deliver the information technology needed to solve business problems. The increasing popularity and use of data-warehousing and data-mining technologies among AS/400 customers is demonstrating just how powerful this system has become. With so much business data residing on AS/400s around the world, it is small wonder the AS/400 is rapidly becoming the premier platform for these new technologies. Let’s look at some of these technologies and how they are supported on the AS/400. Then we can examine some of the fundamental concepts of DB2/400.
Earlier, we introduced the idea of operational data and said this type of data is typically contained in a relational database. This data is dynamic, is updated often, and is optimized for transaction processing. Informational data, on the other hand, is summarized operational data. Informational data is infrequently updated (it may even be read-only), and it is stored in a form that is optimized for decision-support systems. Informational data is stored in a database separate from the operational data, often on a separate system to lessen the impact on the operational data. It is this informational data that makes up the data warehouse.
It should be clear that data warehousing is a concept and not a specific product. It is a set of tools you can use to create the informational data, store the data, and analyze the data for business-decision purposes. An AS/400 data warehouse includes four main components that we examine briefly in the following sections. These components are
Building the data warehouse requires transforming the operational data into informational data. We accomplish this with transformation tools, or as they are often called, propagation tools. These tools not only move the data from one or more operational databases, they also manipulate the data into a form more appropriate for the warehouse.
For example, consider the operational data for every purchase made from a wholesale distributor. Each record contains information about which items were purchased, how the items were paid for, and who purchased them. Because this data is in a format suitable for recording each and every transaction, analyzing this data using queries may be very time consuming, especially when most analysis programs do not need to see each transaction.
A business analysis program may want to review data collected by product to forecast inventories or to look at revenues compared to last year. This type of analysis wants the data in a decision-making format. It wants summary information from the operational database to quickly view trends and problem areas that may affect the business. The transformation tools capture the data from the operational systems, transform it into the summarized format, and propagate it to the data warehouse on a timed basis. Notice that, for most analysis programs, the data in the warehouse does not need to be instantly up to date with the operational data. Depending on the business, the data warehouse needs to be refreshed automatically once a week, once a day, or every 10 minutes. Many products are available from IBM and other vendors to extract data from DB2 and non-DB2 databases and to import that data directly into the AS/400 data warehouse.
A few years ago, we at IBM introduced special models of the AS/400 that we called servers. We created these models for database serving, communications serving, and batch-processing applications. Together with enhancements that were added to DB2/400, these servers are intended for the types of workloads used in data-warehousing applications. We look at other server models later, but for now, let’s focus on database serving and the enhancements that have been added to support this type of application. Two of the more important areas for data warehousing are parallel processing and multidimensional databases (MDD).
Various parallel-processing techniques allow the database to take full advantage of the hardware on which it runs. Retrieving and analyzing large amounts of data can be very performance-intensive. Fortunately, database processing is such that independent accesses can be made to the database in parallel, and then the retrieved data from each access can be independently analyzed, also in parallel. Database processing is one of the few practical applications for the massively parallel processing (MPP) systems that we introduced briefly in Chapter 2. IBM has added several enhancements to the AS/400 and to DB2/400 to exploit parallelism in database operations.
The first enhancement occurred back in V3R1 when we introduced parallel I/O processing. This feature allowed parallel processing at the I/O processor (IOP) level for a single job. We were able to take advantage of the AS/400 hardware structure that has both main processors and separate IOPs. I discuss these IOPs in depth in Chapter 10, but suffice it to say that a large AS/400 can have several hundred of these IOPs with separate disk drives attached to different IOPs. Parallel I/O processing lets a single user submit a query to the database and have multiple IOPs process the request in parallel. This overcomes one of the most serious bottlenecks in database processing that prevents many systems from achieving high performance: the I/O processing time.
| Previous | Table of Contents | Next |