Client/Server Data Systems

There is a tremendous and constantly changing variety of client/server data systems. We'll illustrate the possibilities with two examples—the data warehouse and computer telephony integration.

Data Warehouses

The concept of a data warehouse is usually attributed to IBM. The idea is that information from all of a company's operations are aggregated into a single central database that can be used for decision support. The data warehouse doesn't replace the other databases; rather, it is a replica of portions of them, organized to create reports that span some defined period of time. An example would be a company with a series of transactional databases that are constantly working hard selling airline tickets or whatever. At least daily, perhaps more often, managers want to know what's selling and what's not. It would be very inefficient, perhaps dangerously so, to run queries against these transactional databases. Instead, at regular intervals their data is copied over to the data warehouse. Queries run against the warehouse don't provide up-to-the-minute data, but they don't need to. The purpose is to understand trends, not sell seats. Figure 13.1 illustrates a data warehouse.

The extra dimension of a data warehouse comes into play when the managers want to make changes as a result of their analyses. Airlines have lots of other databases—plane and crew scheduling, gate availability, fuel and maintenance, and so forth. If these are also integrated into the data warehouse (via regular copying), it will be possible for the managers to do dynamic "what if" scenarios about changes to routes or crew scheduling. Once decisions have been made in this comparatively secure environment, changes can be made to the main business system.

Computer Telephony Integration

There are two general ways in which systems developers are planning to integrate telephones and computers. The first is to combine the PC and the telephone on the desktop. In this scenario, your network connection would handle voice as well as data, and the PC would be able to assume the functions of a very sophisticated an swering machine. On the server side, things would be simplified because one machine (or cluster of machines) would be both network server and office telephone switching system (private branch exchange, or PBX).

This approach has a lot of promise, but is not yet widely used. The major barrier is that LAN technology doesn't handle voice well. Neither Ethernet nor Token Ring networks, which comprise all but a small percentage of LANs, can handle time-dependent communications. While packets that get there when they feel like it are OK for normal data connections, they make telephone conversations jerky and awkward. There is some progress in improving existing protocols; for example, there is a form of Ethernet (called isochronous Ethernet) that is designed to prevent latency, but the real transition to combined voice/data LANs will have to wait for improved LAN switching or for ATM to be cheap enough for the desktop (some standards work needs to be done as well). So expect to wait a few years to see this technology widely available and, more important, widely adopted. One the other hand, it could be cheaper and more effective to keep the two separate, especially if ATM fails in its move to the LAN.

The second kind of telephone/computer integration is connecting phones to databases. Given its tremendous business potential, this still immature technology is quite popular with small, medium, and large companies. A major reason for progress is the availability of the TAPI (Telephony API) protocol for Windows NT/2000. TAPI defines a set of APIs that programmers can use to connect digital telephones and telephone systems (PBXs) to network servers. For some time now, there has been a similar protocol (TSAPI) for Unix systems, but it has suffered from the usual Unix problems; it isn't really standard and many smaller businesses are reluctant to undertake the software maintenance associated with Unix—they don't want to have to hire one of those weirdo "wizards" to make it all work. By contrast, Windows NT/2000 is perceived to be much simpler because it has the familiar Windows interface.

To illustrate what telephone/computer database integration can mean to a small operation, we'll give you three examples, one before and two afters.

Before

Mrs. Jones calls RX Pharmacy to see if her prescription has been filled and is ready to pick up. After a few rings, the phone is answered by a clerk or the pharmacist. Mrs. Jones asks her question and the employee goes to look through the stack of filled prescriptions, then returns to the phone to say, "Yes, it's ready," or "No, it isn't." A very inefficient process no matter how you look at it.

Automated Option 1

Mrs. Jones gave her home phone number when she left the prescription and was told that if she called from that number, she could get an immediate response about her prescription's status. When she calls, the digital telephone uses caller ID to associate the number with a name—this is usually accomplished by the telephone device, but for a large business, an attached computer would have to do it. This takes just a few seconds and is done when the phone is picked up. A prerecorded voice says, "Good evening, Mrs. Jones. We're checking on the status of your prescription." The pharmacist earlier gave the prescription a number and entered it in the computer (something that all modern pharmacies have to do, in any case) and the computer printed a bar code to attach to the label; when it was filled, the pharmacist simply passed the package by a scanner and the computer knew it was filled (the computer could also know exactly what the prescription was and how much it cost). After, at most, a second or two, Mrs. Jones is told by the recorded voice that the prescription is ready and can be picked up at any time. It might also offer an option for her to listen to a description of precautions associated with the medication. Computer assistance of this kind is simple, effective, and efficient; it will make it much easier for businesses to keep staffing levels low and/or provide better personal customer service when needed.

Automated Option 2

In this approach, the pharmacy (or any business) is more interested in selling additional stuff to the customer than in saving staff time, so a real person answers the phone and looks at the computer terminal to find the status of the prescription. While this is going on, the local computer is querying a remote system, a data warehouse that includes information from all of the chain's pharmacies in the city, the region, and perhaps the nation. The query from the local computer takes information about Mrs. Jones and asks the data warehouse for information about preferences, recent purchases, and so forth. This information is also flashed on the screen so that the real person talking to the customer can say something like, "By the way, Mrs. Jones, I see that you've tried just about every weight loss formula ever made—presumably with no success. You might want to know that we carry some new products that are even more expensive than the old ones. Can I add some to your package?"

Businesses believe that this kind of selling, because it connects to an individual customers' preferences, can be very effective. Of course, our pharmacy could use both—Option 1 when they were busy and Option 2 when they weren't. Needless to say, there are a lot of variations that will be used—perhaps including employee training.

While most people don't like automated voices and telephone systems that present them with a baffling series of requests to push different numbers, reasonable people appreciate that it saves a lot of time. Think about the old days of calling an airline to find out if a flight was on time. In effect, you're waiting for someone to punch a few keys on a computer terminal and tell you what it says. If you can cut out the middleman, everyone will be happier (including the clerks, who would almost certainly prefer other employment).