Real Time Databases in Wireless Sensor Networks

Real Time Databases in Wireless Sensor Networks Priya Sajesh 1, Preethy Chand 2, Vidya Menon 3 Department of Computer Science, BITS Pilani, Dubai Campus-345055, UAE Guided by Dr. M. Madiajagan Ph.D. Assistant Professor in Computer Science Abstract: Wireless Sensor Networks (WSN s) have been the focus of many research works. WSN s are widely deployed for various applications. A variety of useful data are generated by these deployments. Since WSN s have limited resources and unreliable communication links, traditional data management techniques are not suitable. Several WSN s have time critical tasks and needs data processing with temporal constraints in their tasks; so one of the new challenges faced by WSN s is handling real time storage and querying. Three approaches to storage and querying is considered in this paper: - warehousing, distributed and hybrid approach. The data collected by sensors must represent the current state of environment; for this reason, they are subject to logic and time constraints. This is the real time database management on WSN and it deals with time constrained data, time constrained transactions and limited resources of wireless sensors. This paper also aims at describing the need for real time data management on WSN s. The aim of this paper is to describe the different specifications of real time data management and various indexing mechanisms for real time data management in WSN s and also various real time embedded database technologies and to present a model for real time database management on WSN that uses a distributed approach. Keywords: Wireless Sensor Networks, Real-Time Database Management Model. 1. Introduction 1.1 Wireless Sensor Networks Wireless sensor networks (WSNs) may be defined as a set of smart devices, called sensors, which are able to sense, process and transmit information about the environment on which they are deployed. These devices, distributed in a geographical area, collect information for users interested in monitoring and controlling a given phenomenon. The main components of a typical sensor network system, given in Figure 1, are sensors connected in a network that is serviced by a sensor access node. A slightly different but compatible view of a sensor network is to view sensors as being of three types of node: (1) common nodes mainly responsible for collecting sensor data; (2) sink nodes that are responsible for receiving, storing, processing, aggregating data from common nodes; and (3) gateway nodes that connect sink nodes to external entities. Common nodes are equivalent to sensors, and access nodes combine the functionality of sink and gateway nodes. The sink node makes the information available to a gateway where the users can access via Internet. So as to obtain information, users use applications that communicate with the network through queries. This sort of network generally has a large number of nodes communicating and distributed on a given area to measure a physical quantity or an event monitoring. Each network node is considered intelligent and is equipped with an acquisition module, which provides a measure of environmental data (such as temperature, humidity, pressure, acceleration, sound, etc.), processing capacity, storage, communication, and energy. How- ever, these resources are generally very limited, especially those of storage and energy, and the sensor nodes energy consumption is sometimes not negligible. Systems based on sensor networks are more and more used in many areas providing various types of WSNs. These different WSNs involved the development of many applications, which are generally connected to databases treating the amount of data collected from sensors. However, the processing time becomes increasingly critical for certain applications. These applications must query and analyze the data in a bounded time in order to make decisions and to react as soon as possible. Some examples of the most popular applications are the following: the control of network traffic, transactional analysis (web, banking or telecommunication transactions), human motion tracking application, the tracking of actions on dynamic Web pages, monitoring of urban or environmental phenomena, and the sensors data management. Figure 1-Illustrating Wireless Sensor Network Architecture 1.2 Data Storage and querying in WSN Once the sensors perform their measurement, the problem of data storing and querying arises. Indeed, the sensors have restricted storage capacity and the ongoing interaction between network devices and environment results huge P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 17

amounts of data. There are two different ways in which data from a sensor network might be stored: In Centralized Warehousing approach, each sensor forwards its data to a central server or warehouse connected to the network via an access point. The centralized system collects data from sensors (in stream) and send data to a central database in which user requests are processed as shown in Figure 2. User queries do not incur additional sensor network communication cost since they are processed on the external server. However, there are distinct disadvantages to this centralized approach. The nodes near the access point become traffic hot spots and central points of failure. They also may run out of power very fast. Here, sensors act as collectors. The data gathered by sensors are periodically sent to a central database where user queries are processed. This approach is adequate for historical queries but not for no-historical queries because it involves time delays. Figure 2-Centralized Warehousing Approach An attractive alternative is Distributed Approach, which stores the data within the network, using the so-called in-network storage as in Figure 3. At the center of this design is the appropriate choice of storage points for the data, which act as rendezvous points between data and queries, so that the overhead to store and access the data is minimized and the overall load is balanced access the network. The query time, however, depends strongly on how the data is indexed. Here, each sensor node is considered as a data source and then the WSN forms a distributed database. The sensed data not periodically sent to database server but they remain in the sensor nodes. Queries are injected in the network through base station. These queries are disseminated into the network according to routing techniques. Sensors in this case have both processing and storage capabilities. The sensors send their data to their parent node whenever they correspond to query requirements. The parent nodes combine this coming data with their own data and transmit to their parent nodes and so on until the data reaches the gateway. With this approach, the amount and size of transmitted data and latency is reduced. This aims to locally limit sending of messages in order to save energy consumption. In this approach, the data is stored in a central database server and in the devices themselves, enabling one to query both. On sensors, processing of queries is done on real time. This supports instant and long running queries. Figure 3-Distributed Warehousing Approach The distributed technique treats the information within the sensor nodes. According to the unstable and generally harsh environment, there may be sudden failures of sensors. This can lead to information loss that greatly influences the result analysis or even system blocking. To deal with this approach, one can opt for Hybrid Approach where in addition to innetwork data processing, some data can be kept in the base station database and updating from time to time. After a certain time, these data may gradually lose their freshness. Thus, one can use a generalized database management system to handle different types of applications and user needs. This approach allowed one or the other solution depending on requirements of application that is source of query. This solution will take into account both the time constraints and risks of failure. 1.3 Basic approaches to data management in WSN s First, we introduce some early data management approaches. There is a lot of research addressing various aspects in data management in sensor networks. In an effort to reduce communication costs, query-based systems incorporate in-network processing using techniques such as aggregation, fusion and filtering. They take a view that the sensor network can be considered a database from which information can be requested and retrieved. TinyDB [1], Cougar [2], SINA and DSWare are all systems which take this database view of the network. They boast high level interfaces to the sensor network and allow users to pose queries using a query language similar to SQL. Similar in concept, they all implement in-network processing techniques in different ways. In [3], a scalable and robust communication paradigm, directed diffusion, is proposed. Attribute-value pairs are used to name data generated by sensor nodes. A request node sends its interests of named data to destination sensor nodes or regions. Then, data satisfying the interest are returned along the reverse path of interest dissemination to the request node. To improve the performance and save P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 18

energy, intermediate nodes can cache data and might aggregate the data. TinyOS[4] is a free and open source operating system designing for WSNs. TinyOS is an embedded operating system which is written in the nesc. The component library of TinyOS consists of sensor drivers, network protocols, distributed services, and data acquisition tools. Therefore, TinyOS can support basic data requests. Moreover, users can develop their own applications based on TinyOS. TinyDB is a data management system for WSNs based on TinyOS. It can extract information from WSNs by sending queries. Importantly, TinyDB allows users describe the data they want to acquire by writing a simple, SQL-like query. For answering a query, TinyDB requests the data from sensor nodes in the network and routes it back to a PC. In the phase of processing queries, filtering and aggregation algorithms might be used. TinyDB uses intelligent innetwork energy-efficient processing algorithms to prolong the network lifetime. For instance, tree-based routing is used for query delivery, data collection, and in-network aggregation, and is used to processing aggregation in innetwork manner. Also, TinyDB supports metadata management, in-network persistent storage, and multiple concurrent queries. REED extends TinyDB with the ability to process joins operations between sensing data and static tables which is built outside the WSN. Filter conditions is stored in static tables, and then those tables are distributed throughout the network. Join operation is executed in innetwork manner. REED is also suitable for various event detection applications which TinyDB and data collection systems cannot handle. Cougar [10] is another distributed database system to sensor networks. It considered query languages, aggregation processing, query optimization, catalog management, and multi-query optimization. When a new query is coming, query optimizer of Cougar either merge it with an existing query or generate a new query plan. A leader is chosen to control the execution of the query plan. SINA uses hierarchical clustering of low-level information in the network to increase efficiency. Clusters are formed from aggregations of sensors based on their power levels and proximity with cluster heads, performing key functions like information filtering, fusion as well as aggregation. DSWare is aimed at handling real-time events and integrates a number of real-time data services while providing a database-like abstraction. DSWare uses SQL-like statements for registering and cancelling events. The main contributions of this paper are the following: -Description of the characteristics of data and transactions in RT database systems -Need of RT data management in WSN -Real time data management techniques in WSN - Real Time database technologies -Real Time database simulation model for WSN's The remainder of this paper is organized as follows. Section 2 presents the various basic approaches to data managements in WSN. Section 3 discusses various real time database technologies. Finally, Section 4 concludes the paper with a brief description of a model for distributed system implemented in Java. 2. Literature of Related Research Issues In this section the literature of related research issues are discussed. 2.1 Characteristics of data and transactions in real-time database systems The first purpose of a real-time system is the respect of the temporal constraints. For a database, this does not mean that the transactions execution must be fast, but that transactions must run in well-defined time intervals. Real time databases use timing constraints that represent a certain range of values that are valid. This range is known as temporal validity. A conventional database cannot work under these conditions. The inconsistencies between the real world objects and the data that represent them is huge and difficult to work with. An effective system should be able to handle time sensitive queries and return valid data. The RT-DBMS should process transactions and ensure the logical consistency is not violated. Unlike traditional DBMS, the RT-DBMS can work with temporal validity of the data and the time constraints or deadlines for transactions. The temporal consistency expresses the need to maintain consistency between the current state of the targeted environment and the state as reflect by the database contents. To satisfy the temporal constraints, the structure of the data must include these attributes: (i) Timestamp (indicates the instant when the observation relating the data was made) (ii) Absolute validity interval (indicates the time interval following the timestamp during which the data are considered valid) In order to satisfy logical consistency, ACID (Atomicity, Consistency, Isolation and Durability) properties must be followed. But this constraint is more relaxed in case of RT- DBMS compared to conventional databases. 2.2 Need of RT data management in WSN A real time system can be seen as a controlling system and a controlled system. Consider the example of an automated manufacturing unit. Here, the controlling system is composed by a computer and human interfaces that manage and coordinate the activities, while the controlled system is the manufacturing system with its robots, assembling stations, parts, and conveyers. In the case WSN, the controlled system represents the targeted environment. The controlling system interacts with its environment according to the data available, for example, provided by various sensors about the environment. The real-time database data must represent the current state of the environment on which they were captured. This is particularly important especially for applications that monitor areas of risk. In this context, a good data structure for real-time access is very important. The data collected by the WSN and perceived by the controlling system must closely reflect the current state of P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 19

the targeted environment. However, the environment changes constantly and there are usually delay throughout the process of collecting, storing, and exploiting of the information characterizing the environment. This delay can generate huge inconsistent values. Hence, the use of traditional databases can create a lot of issues and reduce the scope of the system in fulfilling the desired functionalities. As the RT-DBS is capable of considering temporal variants and deadlines, it can succeed very well when used with WSN. In addition, it also provides several tools to deal with the temporal restrictions of data and transactions which is needed in this application. 3. Solutions of Real-Time Database Techniques for WSNs A good data structure for real-time access is very important. 3.1 Po-tree structure Po-tree is a database spatiotemporal access method [5]. The Po-tree, is based on the differentiation of temporal and spatial data, with a focus given to the latter. The spatial aspect is indexed through a Kd-tree, while the temporal aspect uses modified B+-trees. 3.1.1 Spatial component Figure 4-Po-Tree Structure Within a Kd-tree, entries take the from<left-pointer; reference-point; right-pointer>. In order to create a Kd- tree, a reference dimension D and a reference point Pi are taken. Then, all points with a greater value for the dimension D than Pi shall fall to the right part of the branch, and those with a lesser value to the left. At the next level of the tree, other reference points Pi+1 and Pi+2 are taken, and the reference dimension becomes D+1. In the Po-tree, each spatial point is composed of a spatial definition of the point and a link to a temporal sub-tree. It does not directly record the temporal components. Therefore, a whole definition of a spatial sub-tree entry would be <left-pointer; point-position; link-to-temporaltree; right pointer>. As spatial deletes should not occur, there shall not be empty spatial nodes. 3.1.2 Temporal component The temporal components to index are held within modified B+-trees. The tree records the measurement times and links to the actual measured values. Each spatial object is linked to a different temporal sub-tree. The temporal sub-tree has been modified to add a direct link between the root and the last node. While maintaining this link requires minimum computation from the system, a simple test during query processing prevents being forced to traverse the whole tree so as to append or to find the requested data. 3.1.3 Process Queries are sent to the root of the spatial sub-tree that supports querying of different temporal sub-trees and provides the results. Indeed, a query is divided into two phases: if a query arrives, a first search is performed in the spatial sub-tree to determine the sub-trees of sensors concerned by the query. Subsequently, the spatial sub-tree forwards the query, having only temporal dimensions, to the sub-structures of the sensors involved and collects the results (ID sensor, measurements and time markers) to present to the user. 3.2 PasTree In real-time databases, in addition to logic constraints, data must also be consistent with the time constraints. So, it is necessary to efficiently store new arriving information into databases, to fast search of data and to manage the memory to avoid overload that can lead several miss deadline of transactions. This is particularly important for applications that need to query in real-time and access to the most recent data. To deal with these challenges, a real-time spatiotemporal indexing scheme for agile sensors called PasTree can be used. The PasTree is an improved version of the PoTree. The structure is based to a multi-version spatial sub-tree; which keep tracks of the sensor location changes. Thus, each node keeps information about the past positions sensors and the actual ones. Moreover, PasTree includes two other access structures; the sensor tree for referencing sensor ID and the temporal object tree for each recorded sensor, allowing thus queries based on sensors identifiers or spatiotemporal characteristics. This proposal includes an interface located above the sub-trees of access and enables centralized management of queries. This interface allows hiding the user the multi-criterion access. If a query arrives, it redirects it depending on the type of access (spatial or identifiers criteria). 3.3 StH Another indexing method for real-time management of main memory is StH. The StH, spatiotemporal/heat, is an indexing system for centralized spatiotemporal databases in RAM memory, working on data from a agile sensor network and taking into account the memory saturation of the database. The StH further allows multi- criteria access to the data. Indeed, it is based, on parity, in the construction of the PasTree: spatial sub-tree and identifiers sub-tree. In addition, it incorporates new sub-structures in order to prevent from the memory saturation of the database. Thus, in addition to spatial and identifiers sub-trees, each sensor is associated with a dedicated sensor sub-structure called staircase because of its shape. This dedicated sub-structure contains all information relative to a sensor (id, history of positions and links to the measures). This index allows the resolution of queries based on spatial criteria or sensor identifiers. The management of the memory saturation is done by using a heat-function associated with each staircase, i.e., each sensor. Thus, the coldest data are regularly transferred from the sensor stairs to the data warehouse. P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 20

This transfer is triggered after the account of a maximum number of data input by the sensor. 3.4 RTSTREAM Considering the real-time approach, the main idea is to answer queries in their time constraints; real-time applications need predictable responses. Queries should be process in accord with their deadline. So, RTSTREAM try to comply with this constraint in huge amount of sensor data stream. RTSTREAM is a real-time data stream management system (DSMS) that supports a real-time data stream query model, named PQuery. The PQuery model improves upon the Continuous Query Language (CQL) as it allows applications to specify the query frequencies and deadlines; which in turn is used to deal with the queries time constraint. Instead of always- reinitiated query instance by the incoming data stream (like in others continuous query model), PQuery model does not allow the change of the input during the course of the instance execution, i.e. if a query is registered, its instances are periodically initiated by the DSMS system and a newly arrived data stream are processed by the next query instance. Moreover, RTSTREAM includes an overload protection mechanism named data admission for better deal with query deadline miss ratio. The data admission uses sampling and shedding strategies to reduce the incoming data volume during periods of high load. This system produces periodic responses in real time without interrupting the query instance execution, but it does not provide the latest result of the incoming data stream because of the incoming data stream reported to next query instance. 3.5 QMF In these applications, it is also important to access fresh data that effectively reflect the current status of the targeted environment. Considering these problems, a real-time main memory database architecture, named QMF (QoS management architecture for deadline Miss ratio and data Freshness) has been proposed to improve the quality of service (QoS). This proposal attempt to balance the deadline miss ratio compared with data freshness in considering the applications requirements. Indeed, this model allows specifying the desired miss ratio and data freshness for a specific application. To deal with the miss ratio, QMF use a feedback controller. It includes a controller that periodically measures the miss ratio, calculates the error miss ratio, i.e, the difference between the values of miss ratio desired and the actual measured value and react to correct the error. 4. RT database technologies Database technologies for real time are useful in applications having real time data management needs. 4.1Main Memory Databases Real-time processing environments are often constrained by external factors, but the trend is towards larger memories. Real-time databases can be very large, but there should be any cases for which a database that is fully or mostly resident in main memory is appropriate. The researches suggest that algorithms specialized for main memory databases offer considerably improved performance over conventional DBMS with very large buffer pools. However, the engineering work in determining cost-benefit tradeoffs is yet to be done. Much of the work in main memory databases addresses recovery techniques and recovery must be reconsidered for the real-time case, and hence real-time recovery of main memory must likewise be reconsidered. 4.2 Database Machines Although there are usually good reasons to avoid specialized hardware in production systems, the performance constraints of real-time systems may be impossible to meet in conventional architectures. Research into DBMS-specific hardware architectures is quite well established and has resulted in several commercial offerings, include Britton-Lee s Intelligent Database Machine (IDM) and Terradata s Database Computer (DBC). These products are disk-based associative memories, possibly unsuitable for the rugged environments of many real-time systems. There is at least one proposal, by the English firm Software Sciences, for a microprocessor (transputer) network-based database machine, DIOMEDES, specifically designed to operate under such conditions. A database machine is used by applications in much the same way as a database server is used by its application clients. The server-client architecture is ubiquitous on local area networks. Real-time systems implemented in such networks, e.g., ship and aircraft systems, can exploit that architecture at no added risk. Database machine insertion is accomplished through the substitution of a special purpose DBMS machine for a general purpose database server. The effect on application engineering, on the general purpose host machines, is minimal. The future of real-time database applications is likely to include a role for specialized database hardware. 4.3 Active Databases and Knowledge-Based Systems Knowledge-based and expert systems are becoming increasingly common in real-time systems. Even if the deductive, inferential tasks of the system have lax timing constraints, the interface between the database and knowledge base paradigms must not impose excessive overhead. The database component may act as a scheduler for the expert system by monitoring the enabling conditions for rules."rule processing" is an active area of database research. The particular needs of real-time rule processing have had some attention. The area may not yet be ready for transition into practice, but the pressure to do so is already evident. In building a real time application-specific DBMS, it might be necessary to customize: storage handling and mapping functions (e.g., main or secondary storage schemes) concurrency control paradigms and schedulers buffer management and disk scheduling recovery schemes for various classes of faults and of data The lesson to be learned is that database building blocks must be integrated with operating system and other runtime P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 21

environment building blocks in order to avoid wasteful duplication. Research on database building blocks for real-time applications carries substantial risk. In order to succeed, it may be necessary to: Discover or invent "the" real-time DBMS architecture, if such a thing exists. Determine a good packaging material for the building blocks. If the blocks are constructed directly from source code, can they be both general and efficient enough to be reused in real-time applications? Show how to compose performance (or complexity) information for the building blocks into performance information for the complete system. It is not certain that these things can be done but these are among the problems confronting the application of "megaprogramming" to any real-time domain. 5. RT database simulation model for WSN's One of the challenges faced by WSNs is handling real-time storage and querying the data they process. This is the realtime database management on WSN and it deals with timeconstrained data, time-constrained transactions, and limited resources of wireless sensors. Developing, testing, and debugging this kind of complex system are time-consuming and hard work. The deployment is also generally very costly in both time and money. Therefore in this context, the use of a simulator for a validation phase before implementation and deploying is proved to be very useful. The design of the simulator involves the development of a library of models from which it will be possible to build our architecture of real-time databases management for WSN. These models are descriptions of behaviors and functions supported by each component of the system and can replace, in the simulation, the actual components of the architecture to be modeled. Many researchers argue that the objectoriented model is more suitable than the relational model to model real-time data, because of the nature of several realtime applications, which handle complex real-world objects with time constraints. Thus, many projects on real-time databases have chosen the object-oriented model for their systems. However, the relational model is the most used on real-time or distributed databases modeling. The global architecture of our simulator model of real-time database management techniques on WSNs (see Figure 1) uses the distributed data storage and the query approach. Thus, this model considers the gateway more general by integrating into it a database warehousing (DBW) that stores real-time data and a real-time database management system (RT-DBMS) that handles real-time transactions. The model of the wireless sensor network (WSN) nodes is built by using an event-based model, particularly an event advance design. Thus, the nodes are programmed as follow: each time an event (user transaction) occurs in the network; all the nodes are triggered to compute the previous acquisitions, store the sensor data, and send all the underlying periodic update transactions to the database server. Moreover, each node targeted by the user transaction at the same time, after completion of its previous works, sends the results on required time. All these actions are scheduled on time based on the instant time that the network was initialized, the periodicity of acquisition and database update transactions, and the instant time that the user transaction arrives in the network. Therefore, the devices act as local databases, including a software component that manages the data storage and user queries with time constraints. The database server incorporates also an application that deals with time-constrained data and time and logic constrained transactions. We distinguish two kinds of transactions: update transactions and user transactions. The update transactions can be local updates for periodically updating the local sensor databases or server updates that periodically update the real-time data in the database server. The user transactions are real-time user queries that only read real-time data or historical queries that may read or write historical data. Figure 5-Components of the Simulator Model for Real-Time Database Management Techniques on WSNs 5.1 RT-DB SensNetSim This simulator named RT-DB SensNetSim is an objectoriented model mainly built for a simulation framework of Real-Time Database (RT-DB) techniques for WSNs implemented in Java. The model is based on the distributed approach and uses the Earliest Deadline First (EDF) protocol to schedule transactions and the Epsilon Serializability techniques to allow conflicting transactions to execute simultaneously and control the imprecision on the data. However, the simulator is at early stages of software development and, although it was built for RT-DB protocols for WSN, it may be improved by adding the simulation of protocols or incorporating it in another existing simulator with acceptable characteristics of network protocols, layout, task scheduling by the operating system, GUI, etc. 5.1.1 Configurations The simulator is for applications that use firm real-time transactions and is implemented in Java programming language. In the file containing the MainSimulation class, a practitioner can configure almost all the parameters of the simulation as follows: P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 22

Initialize the real-time-update-query transactions: configuration of the number of local and server updates and their parameters. LocalUpdate(long liberationtime, long period) ServerUpdate(long id, long liberationtime, long period, long executiontime, long deadline, int limitexport) Initialize the network: initialize the network with the number of sensor nodes composing the network and their parameters. SensorNetworkNode(int identification, float energy, LocalUpdate l, ServerUpdate s) network= {number of nodes} Initialize the Gateway: for informing the gateway about the topology of the network. Gateway(SensorNetwork, int sizedb) Initialize the instant-query transactions Transactions(int idtransaction, targetednodes) Initialize the long-running-query transactions Transactions(int idtransaction, String type, long periode, String initialize, String terminate, targetednodes) Initialize the real-time-read-only-query transactions: initialize the number of real-time-read-only-query transactions and their parameters. RTreadTransaction(long idtransaction, long executetime, long deadline, int limitimport, targetednodes) Compilation and execution The compilation and execution is simple. The practitioner can use any IDE for Java, such as NetBeans, import the packages as simple project, built and execute the simulation. Conclusion and Future RT Database systems Traditional databases are persistent but are incapable of dealing with dynamic data that constantly changes [20]. Therefore, another system is needed. Real-time databases may be modified to improve accuracy and efficiency and to avoid conflict, by providing deadlines and wait periods to insure temporal consistency. Real-time database systems offer a way of monitoring a physical system and representing it in data streams to a database. A data stream, like memory, fades over time. In order to guarantee that the freshest and most accurate information is recorded, there are a number of ways of checking transactions to make sure they are executed in the proper order. An online auction house provides an example of a rapidly changing database. Now database systems are faster than they were in the past. In the future, we can look forward to even faster database systems. Although we have faster systems now, an effort to reduce misses and tardy times will still be beneficial. The ability to process results in a timely and predictable manner will always be more important than fast processing. Fast processing that is misapplied is not helpful for real-time database systems. Transactions that run faster still sometimes block in such a way that they have to be aborted and restarted. In fact, faster processing affects some realtime applications because increased speed brings more complexity and more of a chance for problems caused by a variance of speed. Faster processing makes it harder to determine which deadlines have been met successfully. With future database systems running even faster than ever, there is a need to do more studies so we can continue to have efficient systems. The amount of research studying real-time database systems will increase because of commercial applications such as web based auction houses like e-bay. More developing countries are expanding their phone systems, and the number of people with cell phones in the United States as well as other places in the world continues to grow. Also likely to spur real-time research is the exponentially increasing speed of the microprocessor. This also enables new technologies such as web-video conferencing and instant messenger conversations in sound and highresolution video, which are reliant on real-time database systems. Studies of temporal consistency result in new protocols and timing constraints with the goal of handling real-time transactions more effectively. References [1] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, Tinydb: An Acquisitional Query Processing System for Sensor Networks, ACM Trans. Database System, Vol. 30, No. 1, pp. 122 173, 2005 [2] Y. Yao and J. Gehrke, The Cougar Approach to In Network Query Processing in Sensor Networks, SIGMOD Rec., Vol. 31, No. 3, pp. 9 18, 2002 [3] J. Heidemann, F. Silva, C. Intanagonwiwat, R. Govindan, D. Estrin, and D. Ganesan, Building Efficient Wireless Sensor Networks with Low-Level Naming, in SOSP 01: Proceedings 8 th ACM symposium on Operating Systems Principles, New York, USA, pp. 146 159, 2001 [4] TinyOS Website, http://www.tinyos.net/ [5] G. Noël, S. Servigne and R. Laurini, The Po-tree, A Real-Time Spatiotemporal Data Indexing Structure [6] https://en.wikipedia.org/wiki/real-time_database [7] http://en.wikipedia.org/wiki/wireless_sensor_network [8] E. H. Callaway, Wireless Sensor Networks: Architectures and Protocols, CRC Press, 2004 [9] O. Diallo, Joel J. P. C. Rodrigues and J. Lloret, Distributed Database Management Techniques for Wireless Sensor Networks [10] M. Mokashi and A. S. Alvi, Data Management in Wireless Sensor Network: A Survey, in International Journal of Advanced Research in Computer and Communication Engineering, Vol. 2, Issue 3, March 2013 [11] A. Burns and A. Wellings, Real-Time Systems and their Programming Languages Addison-Wesley Publishing Company, Wokingham, England, 1990 P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 23

Authors Profile Priya Sajesh received the B.Tech (Computers) degree from M.G University in 2007 and pursuing M.E. (Software Systems) degree in BITS Pilani, Dubai Campus. Preethy Chand received the B.Tech (Computers) degree from Cochin University and pursuing M.E. (Software Systems) degree in BITS Pilani, Dubai Campus. Vidya Menon received the BE (Computers) degree from Mumbai University in 2013 and currently pursuing M.E. (Software Systems) degree in BITS Pilani, Dubai Campus. P. Sajesh, P. Chand, V. Menon, IJRCSIT Volume-1,Issue-1, Sep-Oct 2015 Page 24