Mobile database processing is a dynamic and exciting topic. Terms such as "tetherless computing" and "anywhere access" open up the world to you. You are no longer bound by the four walls of your office. Ancient Egypt, historic Europe, exotic East, here we come! Terms such as "empowered users" and "personalized data marts" imply more autonomy and independence for end users than ever before. Their struggle has paid off; they have been liberated. However romantic and exciting this newfound mobility may sound, we must keep in mind that mobile database processing usually takes place in the context of a larger enterprise. In the enterprise environment, user autonomy and independence may introduce additional issues, complexities, and problems that must be addressed in order to achieve the envisaged goals.
I will investigate mobile databases from various angles in a four-part miniseries. In this part, I illustrate a few case studies and explore the technologies required for mobile databases. In part two, I will investigate the replication requirements for mobile databases. The third part will be a review of some of the available products, and in the fourth part I will cover the relationship between mobile database applications and the World Wide Web.
The second case study is a real-life example of mobile databases in action. The International Mission Board (IMB) of the Southern Baptist Convention, based in Richmond, Virginia, attends various public relations events to promote missions around the world. They use a full multimedia, touch-screen application to access their mobile databases. The application contains video clips, audio help in multiple languages, various photographs, maps, and other graphical objects. From time to time, when the staff members return to their home office, they synchronize their desktop databases with a master desktop database, which is regularly refreshed from a central database. They have also proposed to extend the system to cater to their 125 field offices. The field agents travel regularly to as many as 131 countries. They take desktop databases in which they will keep data on the allocated and available financial grants as well as the personal details of all the missionaries working for them throughout the world. Personal details of the missionaries and requests for grants will be updated in the desktop databases when the agents visit the missionaries.
The third case study is of a botanist who regularly makes field trips to locations all over the world to search for new plants or for exotic varieties of known plants. She must be able to record, augment, and process her research data, no matter how far or how long she is away from the base laboratory. Sightings and the details of the samples she takes are recorded in her mobile database. She also keeps data on previous sightings because she may want to return to those locations to investigate the progress of some plant as the seasons change, or she may need to get a new sample. Locality data, for example, is sometimes quite extensive; she must describe the exact locations and the routes to these locations so that her colleagues and other scientists may also find the plants. A geographic coordinate (x,y,z) doesn't tell you the exact location of a plant. With the advances made in multimedia technology, our intrepid botanist also records digital photographs and GEOSTAT locality data of the sighted plants into the database. From time to time she can link via satellite to her remote laboratory and file her sighting data -- that is, if she trusts her colleagues not to publish her findings in her absence. An interesting problem in our botanist's world is that the plants aren't always immediately identified. Sometimes she can only identify a variation of a known species after extensive research back in the base laboratory. A new plant -- every botanist's dream -- can only be labeled after it has been registered, which takes a few months and much communication.
Our final case study is another real-life example. Stolt Parcel Tankers transports various liquids in carrier and tanker ships across the globe. The company uses a Microsoft Windows-based mobile database application called Stolt Tanker Operator Workstation (STOW) for cargo management. STOW is a client/server application that pulls cargo reservations off of a central AS/400-based cargo booking system and enables the operator to assign the reservations to specific tanks on the ship by dragging and dropping icons representing the cargo into icons representing the tanks. STOW runs through thousands of checks to ensure that the cargo can be placed in the designated tanks. For example, it checks for previous cargo restrictions (certain cargoes can not be stored sequentially in the same tank, even though the tanks get cleaned between voyages), it checks for tank coating (each tank is lined with a type of protective coating, and some cargoes react adversely to some coatings), and it checks for heating adjacency (each tank can be individually heated, but it's not a good idea to put a cargo that needs heat next to one that should not be heated because the heat will dissipate through the common wall over a long voyage). The STOW plans are then sent via satellite to the individual ships. A version of STOW also runs on board so that employees can manipulate the cargo arrangement based on current information. STOW also has a Dynamic Data Exchange link to a load/stress program that verifies that no unsafe structural stress is being placed on the ship. Payroll, personnel, and scheduling data are also replicated to the ships where they are applied. The OnBoard system logs transactions and sends a batch once a day via satellite. The same technique is used for logs that are received from the ships.
Advances in hardware technology are not only addressing, but actually encouraging these phenomena, however. Five years ago, we carried a minimally configured portable 286, which was twice the size and four times the weight of a briefcase. We used it to take our word-processing and spreadsheet tasks home for a long weekend or to a hotel room if we were on the road. Today, we hide a notebook with dual Pentium processors, a color screen, two 1.2GB disks, and a CD-ROM inside our briefcase. We do extensive decision-support processing on a short flight between two cities. Modem speeds have also increased, but not as fast as hard disk capacity or processor speeds.
For extensive applications you want to run against the desktop database, you must be able to create all of the database objects that you can create on a state-of-the-art, multiuser, server-based database. Ideally you require a complete implementation of the relational data model. Although no major relational DBMS today meets all of E.F. Codd's rules, a mobile DBMS must at least provide the same functionality as a server-based DBMS. In addition to relational tables, this functionality includes full support for domains and the relational integrity constraints -- namely the domain, key, column, referential, and user-defined integrity constraints -- which should all be defined declaratively. You must also be able to create, drop, and maintain views, indexes, stored procedures, triggers, and event alerters. Just like in a server-based database, you must be able to group these diverse and interrelated objects into schemas.
The fact that mobile applications usually have a single user doesn't mean that you don't need full transaction control. The transactions performed by this user still must be atomic -- either all the actions of a transaction must be committed to the database, or none at all: Our traveling salespeople cannot place an order without ordered items; our botanist cannot have a complete sighting of a plant without locality details. In addition, with the event-driven nature and the ad hoc flow of GUI applications, you need transaction isolation as well. The results of an incomplete transaction -- a transaction still in progress -- must be hidden from other transactions through proper concurrency control mechanisms, such as locking or timestamps. If our salespeople want a report of the placed orders, the report cannot include the details of an order that hasn't been committed yet.
Just as for any server-based database, you require the facilities to perform full and partial backups of your desktop databases and facilities to restore them should any problems arise. The backup facilities must cater to all the problems that can happen to a database, such as machine failures, disk failures, software failures, and user errors. There are three additional requirements for mobile databases. First, the backup and restore facilities must be easy to use. Our botanist must be able to restore her research database on the desktop to the most recent usable and correct state after she let the laptop PC's battery run flat while she was busy with an uncommitted transaction on an open database. (It is not that she does this often, but she was busy taking a video of the fertilization process of an exotic plant by a rare insect -- a phenomenon she may only witness once in her life.) She must be able to restore her database without any assistance from the DBA at the office because the problem may occur after hours or she may not be reachable by telephone or radio. Second, the backup data should also take up as little space as possible -- on a portable laptop PC, you rarely have as much disk space for all of the backup data as on the database server at the office. You also usually do not have all the secondary storage devices, such as digital audio tapes and cartridge tapes, that you have on your database server at the office. Finally, the backups should not take long to run, and it must be possible to schedule them at ad hoc times. It must also be easy to remember to do them. The usage patterns of mobile databases are much more erratic than those of server-based databases. They also do not necessarily have scheduled downtimes -- when the machine is on but the database is not being used -- to allow for offline backups. Our traveling salespeople may easily leave their laptop PC switched on while they go to dinner in the hotel's dining room, but our botanist must remember to leave her laptop PC running off the Land Rover's battery at the campsite (while she gets the fire going to cook her makeshift dinner and keep the wild animals at a distance). In both cases, the backup process must still be activated, whether automatically or manually.
The performance of the applications on the mobile database is important: Our botanist may still be prepared to wait a few minutes while an online digital photograph is stored in the database, but our traveling insurance agent wants an instant response when calculating a portfolio for a prospective client. The problem is that the performance of most databases degrades over time as the data content changes, data is deleted, and new data is added. Although often just a small reindexing or statistic refreshment run is required to overcome the slow performance, you must still determine the cause of the bad performance. In addition, similar to the backups I just mentioned, the performance run must be scheduled and activated. It is quite far-fetched to expect our missionary agents to become performance monitor and tuning experts, in addition to performing their real tasks. Again, because a mobile DBMS typically has only one user, or at most a few users at a time, it doesn't need to provide the same performance as a server-based DBMS for a large number of users.
In the context of mobile databases, security may not seem so important because the database usually has only one user. However, the database may contain varying types of information. For example, it may contain information that the user entered that the user may change (such as an order for a customer). It may also contain information entered by the user that may not change (such as the time the user spent with his or her clients). In addition, it may also contain information that the user is not allowed to change (such as the selling prices or delivery schedules of the available products). Some mobile databases are also used by multiple users. The agents of the IMB often set up mobile offices at remote missionary centers. The agents use one application to enter new personnel data and funding requests, but the missionaries themselves use another application on the same database to query and browse through the data on the available grants and how the grants are requested and allocated.
Therefore, although full-function DBMSs are required on the laptop PC, these DBMSs must also be as easy to use and manage as possible. You cannot expect desktop database users to be DBAs too. Many DBMS vendors include the term "self-managing databases" in their sales and marketing literature. Although few of the desktop DBMSs satisfy this requirement at this stage, it is encouraging to see that they are moving in the correct direction (or at least thinking of doing that).
You often hear about "occasionally connected" mobile application users. These users are typically not connected to the enterprise network for long periods of time. During the short periods of connectivity, they want the information exchange to take place, preferably, with as little interaction as possible. In many of these cases, you must deal with unreliable communication media. Dial-up and radio links are not always as fast and reliable as we would want them. Even satellite links can have intermittent failures.
There are many fast-developing technologies that are making mobile communications more feasible than in the past. Hardware improvements, such as high-speed modems, cellular telephones, and other wireless links (including satellites, infrared, and radio-based links), make communication to remote locations more feasible. To this you can add the improvements of the remote access software: asynchronous messaging facilities, more robust communication protocols, file transfer mechanisms, email, and various other protocols that are available on the Internet.
These advances make communication in the mobile database world easier and more usable for our intermittently connected users. However, some of these technologies have yet to find wide acceptance in the enterprise world in which our mobile database users often operate.
The applications executed against the mobile databases should be "full function." People will not use the applications if they are so watered down that they do not help in the users' day-to-day tasks. For example, if our traveling insurance agent's personalized data mart cannot give him summary statistics about the products his clients have purchased, as well as drill-down capabilities for specific policies of interest, he will call the head office for up-to-date statistics and detailed service information before visiting a client, rather than powering up his mobile database application to retrieve information that is only half useful.
With the current hype around the World Wide Web, mobile database applications should be Web-enabled, or at least have a browser-like look-and-feel; users are now all getting used to browser functions. The challenge for application interface designers is to provide easy-to-use, natural interfaces that function efficiently over an intranet, or even over the Internet.
Mobile applications should be lightweight; they should not consume exorbitant resources to run. Although you can get a laptop computer with dual Pentium processors, 64MB memory, and 4GB disk space, you should keep in mind that this same machine must also run the database server software. A computer that runs both the client software and the database server needs more power than a computer that only runs the client software. You don't want to compromise on the database server's functionality, manageability, and control, either. Similarly, you do not want to compromise on the replication facilities. However, not all the mobile users can afford the luxury of using the most powerful portable computer on the market.
The bottom line is that it is no longer necessary for database application users who must sometimes work in isolated environments or remote locations to be powerless or database-less. They can take their databases and their applications with them on the road. Stay tuned for further discussion of other issues related to mobile databases, such as replication, available products, and the influence of the World Wide Web.
What did you think of this article? Send a letter to the editor.