Database Issues

 3.1 Hoarding Techniques:

A database is a collection of systematically stored records or information. Databases store data in a particular logical manner. A mobile device is not always connected to the server or network; neither does the device retrieve data from a server or a network for each computation. Rather, the device caches some specific data, which may be required for future computations, during the interval in which the device is connected to the server or network. Caching entails saving a copy of select data or a part of a database from a connected system with a large database. The cached data is hoarded in the mobile device database. Hoarding of the cached data in the database ensures that even when the device is not connected to the network, the data required from the database is available for computing.

Database hoarding may be done at the application tier itself. The following figure shows a simple architecture in which a mobile device API directly retrieves the data from a database. It also shows another simple architecture in which a mobile device API directly retrieves the data from a database through a program, for ex: IBM DB2 Everyplace (DB2e).

      

Both the two architectures belong to the class of one-tier database architecture because the databases are specific to a mobile device, not meant to be distributed to multiple devices, not synchronized with the new updates, are stored at the device itself. Some examples are downloaded ringtones, music etc.IBM DB2 Everyplace (DB2e)is a relational database engine which has been designed to reside at the device. It supports J2ME and most mobile device operating systems. DB2e synchronizes with DB2 databases at the synchronization, application, or enterprise server.

The database architecture shown below is for two-tier or multi-tier databases. Here, the databases reside at the remote servers and the copies of these databases are cached at the client tiers. This is known as client-server computing architecture.

A cache is a list or database of items or records stored at the device. Databases are hoarded at the application or enterprise tier, where the database server uses business logic and connectivity for retrieving the data and then transmitting it to the device. The server provides and updates local copies of the database at each mobile device connected to it. The computing API at the mobile device (first tier) uses the cached local copy. At first tier (tier 1), the API uses the cached data records using the computing architecture as explained above. From tier 2 or tier 3, the server retrieves and transmits the data records to tier 1 using business logic and synchronizes the local copies at the device. These local copies function as device caches.

The advantage of hoarding is that there is no access latency (delay in retrieving the queried record from the server over wireless mobile networks). The client device API has instantaneous data access to hoarded or cached data. After a device caches the data distributed by the server, the data is hoarded at the device. The disadvantage of hoarding is that the consistency of the cached data with the database at the server needs to be maintained.

           

 3.2 Caching invalidation mechanisms

A cached record at the client device may be invalidated. This may be due to expiry or modification of the record at the database server. Cache invalidation is a process by which a cached data item or record becomes invalid and thus unusable because of modification, expiry, or invalidation at another computing system or server. Cache invalidation mechanisms are used to synchronize the data at other processors whenever the cache-data is written (modified) by a processor in a multiprocessor system, cache invalidation mechanisms are also active in the case of mobile devices having distributed copies from the server.

A cache consists of several records. Each record is called a cache-line, copies of which can be stored at other devices or servers. The cache at the mobile devices or server databases at any given time can be assigned one of four possible tags indicating its state-modified (after rewriting), exclusive, shared, and invalidated (after expiry or when new data becomes available) at any given instance. These four states are indicated by the letters M, E, S, and I, respectively (MESI). The states indicated by the various tags are as follows:

The E tag indicates the exclusive state which means that the data record is for internal use and cannot be used by any other device or server.

The S tag indicates the shared state which indicates that the data record can be used by others.

The M tag indicates the modified state which means that the device cache

The I tag indicates the invalidated state which means that the server database no longer has a copy of the record which was shared and used for computations earlier.

The following figure shows the four possible states of a data record i at any instant in the server database and its copy at the cache of the mobile device j.

       

Another important factor for cache maintenance in a mobile environment is cache consistency (also called cache coherence).This requires a mechanism to ensure that a database record is identical at the server as well as at the device caches and that only the valid cache records are used for computations.

3.3 Client server computing with adaptation

Client-server computing is a distributed computing architecture, in which there are two types of nodes, i.e., the clients and the servers. A server is defined as a computing system, which responds to requests from one or more clients. A client is defined as a computing system, which requests the server for a resource or for executing a task.

The client can either access the data records at the server or it can cache these records at the client device. The data can be accessed either on client request or through broadcasts or distribution from the server. The client and the server can be on the same computing system or on different computing systems. Client-server computing can have N-tier architecture (N= 1, 2 ...). When the client and the server are on the same computing system then the number of tiers, N = 1. When the client and the server are on different computing systems on the network, then N = 2. A command interchange protocol (e.g., HTTP) is used for obtaining the client requests at the server or the server responses at the client.

The following subsections describe client-server computing in 2, 3, or N-tier architectures. Each tier connects to the other with a connecting, synchronizing, data, or command interchange protocol.

      

Two-tier Client-Server Architecture: The following figure shows the application server at the second tier. The data records are retrieved using business logic and a synchronization server in the application server synchronizes with the local copies at the mobile devices. Synchronization means that when copies of records at the server-end are modified, the copies cached at the client devices should also be accordingly modified. The APIs are designed independent of hardware and software platforms as far as possible as different devices may have different platforms.

3.4 context-aware computing  

The context of a mobile device represents the circumstances, situations, applications, or physical environment under which the device is being used. For example, let us assume that a mobile phone is operating in a busy, congested area.

 If the device is aware of the surrounding noises, then during the conversation, it can raise the speaker volume by itself and when the user leaves that area, the device can again reduce the volume. Also, if there is intermittent loss of connectivity during the conversation, the device can introduce background noises by itself so that the user does not feel discomfort due to intermittent periods of silence.

 This is one example in which the computing system is aware of the surrounding physical context in which the conversation is taking place.

A context-aware computing system is one which has user, device, and application interfaces such that, using these, the system remains aware of the past and present surrounding situations, circumstances, or actions such as the present mobile network, surrounding devices or systems, changes in the state of the connecting network, physical parameters such as present time of the day, presently remaining memory and battery power, presently available nearest connectivity, past sequence of actions of the device user, past sequence of application or applications, and previously cached data records, and takes these into account during computations.

Context-aware computing leads to application-aware computing. This is so because the APIs are part of the context (implicit or explicit contexts). For example, if context is a contact, the phone-talk application will adapt itself to use of the telephone number from the ‘contact’ and to the use of GSM or CDMA communication.

 Use of context in computing helps in reducing possibility of errors. It helps in reducing the ambiguity in the action(s). It helps in deciding the expected system response on computations. For example, if name is input in personal biodata context, then the address, experience, and achievements, which correspond to that name, are also required for computations.

 This is because all four are related and needed in biodata context. When name is input in telephone directory context, then the address and phone number, which correspond to that name, are also required for computations.

 This is because all three are related in context to telephone directory. The name in two different contexts (personal biodata and telephone directory) during computations needs computations to perform different actions.

3.5 Transaction Model

A transaction is the execution of interrelated instructions in a sequence for a specific operation on a database. Database transaction models must maintain data integrity and must enforce a set of rules called ACID rules

These rules are as follows:

1. Atomicity: All operations of a transaction must be complete. In case, a transaction cannot be completed; it must be undone (rolled back). Operations in a transaction are assumed to be one indivisible unit (atomic unit).

2. Consistency: A transaction must be such that it preserves the integrity constraints and follows the declared consistency rules for a given database. Consistency means the data is not in a contradictory state after the transaction.

3. Isolation: If two transactions are carried out simultaneously, there should not be any interference between the two. Further, any intermediate results in a transaction should be invisible to any other transaction.

4. Durability: After a transaction is completed, it must persist and cannot be aborted or discarded. For example, in a transaction entailing transfer of a balance from account A to account B, once the transfer is completed and finished there should be no roll back.

3.5 Query Processing

Query processing means making a correct as well as efficient execution strategy by query decomposition and query-optimization. A relational-algebraic equation defines a set of operations needed during query processing. Either of the two equivalent relational-algebraic equations given below can be used.

     

This means first select a column Contacts.cTelNumin a row in Contacts in which Contacts.cTelNumcolumn equals a column DialledNumbers.dTelNumby crosschecking and matching the records of a column in Contacts with all the rows of DialledNumbers. Then in the second step select the row in which Contacts. firstChar = “R” and the selected cTelNumexists. Then in the third step project cNameand CTelNum.

     

This means that in first series of step, crosscheck all rows of Contacts and DialledNumbersand select, after AND operation, the rows in which Contacts.firstchar =“R” and Contacts.cTelNum = DialledNumbers.dTelNum. Then in the next step project cNameand cTelNumform the selected records.

3.5 Data Recovery

Data is non-recoverable in case of media failure, intentional attack on the database and transactions logging data, or physical media destruction. However, data recovery is possible in other cases. Figure below shows recovery management architecture. It uses a recovery manager, which ensures atomicity and durability. Atomicity ensures that an uncommitted but started transaction aborts on failure and aborted transactions are logged in log file.

     

Durability ensures that a committed transaction is not affected by failure and is recovered. Stable state databases at the start and at the end of transactions reside in secondary storage. Transaction commands are sent to the recovery manager, which sends fetch commands to the database manager.

 The database manager processes the queries during the transaction and uses a database buffer. The recovery manager also sends the flush commands to transfer the committed transactions and database buffer data to the secondary storage. 

The recovery manager detects the results of operations. It recovers lost operations from the secondary storage. Recovery is by detecting the data lost during the transaction.