Você está na página 1de 6

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 inbetween 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 segments
from Database
where 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, Database
where 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 platformindependent 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 Selfmanagement", 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

Você também pode gostar