Mainframe Mobile Communications: Relational Database Management on Mobile Devices

by Pat Brans
February 1, 2010

Any application that involves a large amount of data can benefit from using a Relational Database Management System (RDMS). This is true of desktop systems and it’s true of mobile systems.

There are several reasons why the relational model is so powerful. First of all, ordering the data is easier and searches are faster. Second, RDMSs allow you to minimize data redundancies by storing data in logical entities and “relating” the logical entities in a way that’s consistent with the reality you’re representing. For example, patient history is one logical entity, and patient credit information is a separate logical entity. The two are related by patient name or number.

In almost all cases, you need to have the data stored on the device for faster access. You might get away with accessing enterprise servers from time to time, but the more data-intensive your applications become, the more the user feels the overhead of communicating over public wireless networks. To ensure fast and reliable access, a copy of the data has to be stored on the mobile device.

Just as you can have multiple applications using the same database in a desktop environment, sometimes you have more than one mobile application running on the same device and using some of the same data. This means there has to be a central process on the mobile device that acts as a traffic cop to order the different data requests. In fact, you actually run a scaled down RDMS on the mobile computer and synchronize the data on the device with the data on enterprise servers and mainframes.

There are several mature products that allow you to replicate data from a DB2 database onto mobile devices. Most consist of software that runs on the device (usually this includes software that’s linked to an application to become part of a single executable) and a synchronization server that performs bi-directional synchronization at either preset times or on demand. There’s usually logic to resolve conflicts and to ensure transactional integrity. Data encryption is generally provided, because as mobile devices are being carried around outside the office, there’s a higher risk of data getting into the wrong hands.

Another important feature to look for in data synchronization servers is the ability to partition information. Mobile users should be able to view different subsets of data, and their views of the information might be quite different from the views a desktop user would need. Consider the case where a doctor makes house calls and needs access to patient records on her mobile device. You certainly wouldn’t want to download all patient records to her device; instead, you would want to provide the records for those patients she plans to see.

Mobile applications have a different look and feel from their desktop counterparts, and the workflow is usually different to conform to the various usage scenarios inherent to road warriors. Sometimes these variations call for a separate database schema for the mobile device. The synchronization server then maps the two different databases.