An Overview of Mobile Databases

For

C487 Database Systems

by Benjamin Sommers

Abstract

This paper will provide a basic overview of mobile databases, using SQL Anywhere and IBM DB2 Everyplace as examples, and will show the necessity of using a specialized database for mobile database scenarios. It describes the different approaches to handling access of data when multiple devices at varying degrees of access are involved. It will then talk about the necessity for a large variety of device support for this type of system. It will also detail how security is changed and handled by this type of database, as well as how synchronization of data is completed. The final part of the paper will state example queries and possible application areas.

Introduction

As technology grows in its power and complexity, it has also been shrinking in the physical space required for a certain amount of that complexity. One major consequence of this is that mainstream computing devices are becoming more and more portable, with smart phones and tablets appearing in the workplace along the older laptop. Furthermore, these devices can be running a wide array of operating systems, and host to development by many different languages.

A traditional database management system is usually intended for minimal interaction at a centralized "always-online" location, with a small amount of concurrent users and the ability to enact changes right when they are made. However, with this proliferation of mobile devices being used in the workforce, the amount of users and their dependence on having data available to access, especially in conditions without constant connection to a central database, necessitates a specialized database solution being implemented.

In order to provide a solution to this type of environment, mobile databases have been developed to fill this niche. There have been systems developed to allow for data to be reserved by separate mobile devices for access and editing, as well as secure and widely accessible means to transfer and interact with the database. There are many commercial solutions on the marketplace, as well as a large amount of simpler ones, but this paper will limit specific description to the SQL Anywhere and IBM DB2 Everyplace databases for examples.

Overview

Mobile database systems are similar to regular databases when it comes to the process and framework of storing data. The main way they are different from traditional databases is that they allow for different methods of storing and accessing data remotely.

Instead of having a single central physical database to store data, many mobile databases use a model where the database is copied across multiple devices, often all of the devices that access the database. Then, the data is accessible to be read by any user, even if they lose connection to the rest of the devices. If a user wants to be able to edit data while removed from access, they can "check out" a portion of the database so that only they can edit it, and then "check in" that portion when they return, to avoid the problem of overlapping data. [1] Synchronization is also crucial, with multiple devices storing and uploading data. These systems have two-way synchronization, which allows for accessing and updating database information between all members of the database from one location. [5]

Since there are a large amount of possible devices that could be used for mobile access, a good mobile database is able to be accessed from many different types of systems and operating systems. Both SQL Anywhere and IBM DB2 Everyplace have a large variety of operating systems and languages that they support, in order to meet this demand for accessibility. [2] [3]

With a database system that supports so many devices, security and synchronization are major issues. Both SQL Anywhere and IBM DB2 Everyplace use optional security plugins that can be added to the software, that will encrypt data and add extra user authentication. [2] [4]

Mobile databases have many crucial applications. They allow users to have copies of the data along with them as they travel, and provide a system for them to check out data in instances of disconnect. The database is decentralized, so the system can handle any users to be disconnected from the database without issues. This usefulness is relevant for any jobs involving lots of travel and users not being directly connected to the database at all times.

Decentralization and Synchronization

In many mobile databases, like SQL Anywhere, the database is defined by its ability to be decentralized and flexible as to which users are connected or disconnected. The database exists and is synchronized between any of the involved devices that are connected over the database's network of communication, whether that is local or internet based connections. Each additional device that connects is synchronized with the rest, and any device that disconnects can take with it a readable copy of the data as it was last viewable. [1] [5]

If a user has to go off of the network, but still desires to be able to edit a portion of the database while he is off, that user can "check out" a part of the database. While this portion is checked out, he will be able to edit those parts of the database from his device, as well as reading any other parts of the database for reference. While this part of the database is checked out, no other users that are connected can edit it, to prevent clashes in database

information. When the user has finished their task and returns to the connected network, any changes that they have made are synched across the connected units forming the database. [1]

The IBM DB2 Everyplace server uses the Sync-Server method to enact this. Sync-Server continually looks at update times for records, and uses special logical operations to determine what data is saved across the database, depending on uploading time and user. This syncing uses a standard API call, and therefore can be easily called by the database management system like any other database application. [2]

SQL Anywhere uses a data synchronization server called Mobilink for management of data being checked out and synchronized. It acts as an in-between for the connected clients and the recently connected client, making sure they are similar, and any changes are properly updated. [3]

Flexibility

These mobile databases have to be as system-independent as possible, in order to work on a wide variety of devices. This is crucial for a mobile database, because it is mainly useful for devices that can go off of the network. Since there are a wide variety of smartphones, tablets, and laptops, that all have different hardware and specialties for different jobs, a mobile database is better the more of these it can operate on.

IBM DB2 Everyplace is very mobile, being accessible on systems that run Windows or Linux flavor operating systems. It has also been ported to Palm OS, Symbian OS, and Pocket PC, to add availability for smart phones and tablets running those mobile operating systems. Unfortunately, it has not been updated to run on newer mobile operating systems, like Android and iOS.[2][4][6]

SQL Anywhere, however, has been able to stay current. It runs on all major PC and Mobile operating systems, such as: Windows, Linux, Mac OSX, iOS, Android, Blackberry, and many others. This allows for a wide application of the database software, able to work across more devices. [5][6]

Security

Security for mobile databases is more vital than regular databases, for the sole fact that mobile databases will encompass more network connections, and therefore more avenues that that the database could be broken into from. Also, the individual devices used in these connections could be hacked into or incapacitated through viruses, which threatens the integrity of the database through the integrity of the system. Because of this, extra steps have to be taken by the software in order to assure as best as possible that no matter where the data is being used by the user, it will remain safe and valid.

IBM DB2 Everyplace has two main areas of built in security, user management and encryption. It requires connections to be authenticated before user access, which then still requires a login. Each user can also be assigned privileges as to what sort of data they are allowed to see or modify, and a user with appropriate permissions can modify the permissions of another. Tables in the database can also be encrypted, and while they can be stored unencrypted in cache for faster performance, will always be encrypted upon write-back to storage memory. [2]

SQL Anywhere does not offer automatic encryption protocols; rather, some can be purchased alongside the SQL Anywhere software. Either RSA or ECC encryption can be purchased, and will offer file encryption for the database based on either method. [6]

Applications and Example Queries

There are many possible applications for mobile queries. One example would be a business that has to gather data in an area that is remote and will be disconnected from the network, for example making weather measurements out in an area away from any sort of network connection. If a user were to go and collect data remotely, first they would want to check out relevant parts of the database. A query that would resolve that might look something like this:

select segmentsfrom Databasewhere Location(Remote Area 1) and Information(weather, time)Offload Table

Where Offload Table represents taking the previous data, and offloading it from the database on the network to one on a specific device to go take to the work site for measurement. A user can specifically single out what sort of data he intends to be updating, in order to leave the smallest footprint in unchangeable data in the central database as possible.

Once the user returns from measurement, he will be able to use specific program specific syntax to upload and synchronize the collected data back into the database. A SQL Anywhere-like query would look something like this:

select segments from Table, Databasewhere Insert(recent) and Table(Update) is not Database(Update)Calibrate Database

This will find all of the information that was recently updated, and where the update time is not the same between the local database and the common database. The query will then run synchronization between the two databases, leading to an update in information.

Conclusion

Mobile databases have many potential applications, requiring certain tools that cannot be properly provided by a traditional database. There are many obstacles that mobile databases have to overcome. The obstacles that this paper mentions are decentralization and synchronization, flexibility, and security.

Mobile databases have to be able to operate flexibly depending on which users are connected at any point in time, and synchronize changed data between two copies of the database. This can be done via having each device hold a copy of the database, and using synchronizing tools to check for differences in data when a device is brought back into the network. Mobile databases also have to be easily transferrable between software environments. The databases looked at both satisfy this by being platform-independent enough to work on a wide variety of systems. These mobile databases must also be secure, so that attempts to compromise the connections or devices involved will not compromise the database. This security is accomplished by adding extra authentication checks upon login, and multiple methods of encryption of the data in the database.

Many types of mobile databases exist, all with unique features and solutions to the unique problems that mobile databases present. IBM DB2 Everywhere has strong security, and has a syncing service that is easily incorporated into queries. SQL Anywhere runs on almost every current type of operating system, mobile or desktop based, and has a central utility to handle check outs and re-synchronization of data. Other mobile databases have additional helpful features, and as research into types of mobile database work continues, more seamless methods of security and synchronization will be developed, and the use of mobile databases in our society will continue to rise.

References

[1] J. Holliday, D. Agrawal, and A. Abbadi, "Disconnection Modes for Mobile Databases", Wireless Networks, vol. 8, pp 391-402, 2002 [Online] Available http://www.springerlink.com/content/pt7yrmvd7e3lvjn0/fulltext.pdf

[2] T. Fanghanel, J. Karlsson, and C. Leung, "DB2 Everyplace Database Release 8.1: Architecture and Key Features", Datenbank-Spektrum, vol. 5, pp 9-15, 2003

[3] E. Giguere, "Mobile Data Management: Challenges of Wireless and Offline Data Access", IEEE Database, 2001 [Online] Available http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=914831

[4]J. Karlsson, A. Lal, C. Leung, T. Pham, "IBM DB2 Everyplace: A Small Footprint Relational Database System", IEEE Database, 2001 [Online] Available http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=914833

[5] I. Bowman, P. Bumbulis, D. Ferrar, A. Goel, B. Lucier, A. Nica, G. Paulley, J. Smirinos, M. Young-Lai, "SQL Anywhere: A Holistic Approach to Database Self-management", IEEE Database, 2007 [Online] Available http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4401024

[6] "Mobile Development Platform Comparison Matrix", DevX.com [Online] Available http://www.devx.com/wireless/Article/45208/0/page/2