Tài liệu Advances in Database Technology- P19 ppt

46 315 0
Tài liệu Advances in Database Technology- P19 ppt

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

832 K Y. Lam and H.C.W. Pang Due to the dynamic properties of sensor data, the probability of satisfying the condition in a sub-query at a node may change with time. Therefore the coordinator node needs to reorder the sequence of the participating nodes periodically. The reorder procedure is performed when the following condition is satisfied: the evaluation is stopped at the same node, called the false node, consecutively for a pre- defined period of time, and the false node is not the first node. Satisfaction of these conditions suggests that the sensor data values generated at the false node may have a high probability to be false in next evaluation. Hence the coordinator node will reorder the sequence of the nodes using the following procedure: a. The false node is now the first node in the sequence. b. All the nodes following the false node will remain in the same relative order to each other. c. All the nodes in front of the false node remain in their original relative order. They rejoin the node sequence but are now attached after the last node of the original sequence. 4 Implementation CMQES is implemented with MICA Motes [MM]. In CMQES, one of the MSPUs is connected with the base station through a mote interface board. It is the base station MSPU. CMQES contains two main software components: the sensor program in the MPSU, and the server program in the base station. The sensor program is implemented in NesC, which is a C-like language for TinyOS [TINY], and is responsible for capturing sensor data values, evaluating sub-queries, submitting sub- query results to the coordinator nodes, and collecting performance statistics at each MPSU. We have implemented SeqPush in the sensor program. The evaluation results of a CMQ and performance statistics are periodically sent to the base station through the base station MSPU for reporting. The second program is the server program residing at the base station. This program is implemented in Java, with MS Windows 2000 and MS SQL server chosen respectively as the operating systems and database. The server program is responsible for collecting results and performance statistics. In addition, the following parameters can be set using the server program at the base station for submitting a CMQ and controlling the operations at the MPSUs: 1. The sampling rate of the MSPUs. 2. The number of nodes participating in a CMQ. 3. Aggregation functions to be performed at a node, i.e., calculate the mean, maximum and minimum from the values of sub-queries. 4. Condition for the sub-query of a CMQ at an MPSU. 5 Demonstration and Sample Results In the demonstration, through the interface at the base station, we can submit CMQs for processing at the MPSUs, as shown in Figure 1. Currently, the MPSU is programmed to capture the light intensity of its surrounding environment periodically, Aggregation of Continuous Monitoring Queries 833 i.e., every 2 sec, as sensor data values, and a message is sent every 30 sec to the coordinator node. The sampling rate and message reporting period can be varied at the base station. The message size for communication in TinyOS is 34 bytes. Five bytes are reserved for the message header and the message contains the results from 10 evaluations with each reading taking up 2 bytes. The remaining 9 bytes are for cycle number, message type and the destination address. Currently, the transmission delay of a single message from a MSPU to another one in the testing environment is between 300ms and 700ms. As TinyOS only provides best effort message delivery service. A lost message will be considered a missed evaluation cycle and logged accordingly by the coordinator node. Fig. 1. Program at the base station Fig. 2. Real time display of received messages and statistics Our experiment results show that the number of messages submitted in central aggregation scheme (CAS), i.e. all the participating MSPU submits sub-query result to a central MUPU for data aggregation periodically, is much larger than that in SeqPush. Two ammeters are connected to one of the participating nodes and the coordinator node to measure the energy consumption rates of the nodes when different operations are performed at the nodes. The result captured by the base station is displayed in real time as shown in Fig. 2. The statistics include: (1) Number of message transmitted, including sending and receiving messages. (2) Number of successful evaluations and number of missed query results due to loss of messages. (3) Number of reorder of nodes in SeqPush. References [MM] www.xbow.com [TINY] http://today.cs.berkeley.edu/tos/ eVitae: An Event-Based Electronic Chronicle Bin Wu, Rahul Singh, Punit Gupta, Ramesh Jain Experiential Systems Group Georgia Institute of Technology 30308 Atlanta, USA {binwu,rsingh,jain}@ece.gaetch.edu punit@cc.gatech.edu Abstract. We present an event based system for storing, managing, and presenting personal multimedia history. At the heart of our approach is information organization using the concept of an event. Events allow modeling of the data in a manner that is independent of media. To store events, a novel database called EventBase is developed which is indexed by events. The unique characteristics of events make multidimensional querying and multiple perspective explorations of personal history information feasible. In this demo we present the major functions of eVitae. 1 Introduction Personal history systems electronically record important activities from a person’s life in the form of photographs, text, video, and audio. Examples of some existing systems such as [3] have shown that there are a number of salient challenges in this domain. First, information is fundamentally anchored to space and time and people often exploit them as cues for querying information. Second, the data as the carrier of information stays in respective silos. This fragments meaningful information across data. Third, to break down these silos, an information model independent of media is required to depict the content of information. Lastly, presentation of the information must be dynamically generated according to individual users’ preferences. We have developed a personal eChronicle [1] called eVitae [4]. In eVitae we utilize a novel generative theory based upon the concept of event to design an information system [2]. In this paper, we show how eVitae system as an access environment ingests heterogeneous data into meaningful information conveyed by events, aids the user to quickly focus on what is of interest and presents a multidimensional environment for exploration of events with their details stored in appropriate media. 2 Event-Based Data Modeling The approach we employ to design and implement eVitae is based on the notion of events [6]. An event is an occurrence or happening of significance that can be defined as a region or collection of regions in spatial-temporal-attribute space. Given k events, E. Bertino et al. (Eds.): EDBT 2004, LNCS 2992, pp. 834–836, 2004. © Springer-Verlag Berlin Heidelberg 2004 eVitae: An Event-Based Electronic Chronicle 835 the event is formally denoted as and uniquely identified by eID (event identifier). In this notation t characterizes the event temporally, s denotes the spatial location(s) associated with the event, and are the attribute associated with the event. An event is defined by its event models, which includes the mandatory attributes: space, time, transcluded-media, event-name, and event-topic, and a finite set of free attributes. Events can be grouped together in collections, called event categories. Formally, an event category can be represented as: where is the set of events that comprise the category. Event categories provide a powerful construct to support the multiple ways of organizing information, definition of complex queries and notification, personalized views of information space where the user is interested. According to the definition of the event, the information layer implemented by events breaks down the data silos. This layer uses an event-based data model to construct a new index that is independent of data type. The organization, indexing, and storage of events conveying potentially changing information are accomplished by parsing the data as it is entered, and storing all events in a database of events called EventBase. The data is parsed by the system and events are produced using the event model. The EventBase also stores links to original data sources, which means the system can only present the appropriate media in the context of a particular event. EventBase is the extension of traditional database. In the implementation of prototype eVitae system, we use MySQL as the database to store and index events. 3 System Architecture The architecture of eVitae system comprises three modules, namely, Event Entry, EventBase, and What-You-See-Is-What-You-Get (WYSIWYG) query and exploration environments. The key features of the system are briefly discussed as following. EventBase. EventBase is the backend of eVitae system which stores the Events. The transclusion of media is maintained by storing links between an event and the data it is based upon. EventBase uses the eID attribute of events as the unified index and is supported by MySQL. WYSIWYG query and exploration environment. This is an integrated interaction environment to explore electronic chronicle of a person, as shown in figure 1. By using temporal and spatial relationship as cues and by defining event categories to organize events, we create an exploratory environment for the user. The event exhibit panel (Fig. 1) presents an overall picture of events. Options for zooming, filtering, extraction, viewing relations, history keeping, and details-on-demand make the environment appealing and powerful. Event Entry. An event may include multifarious data from different sources, such as video, audio, sensors, texts. The Event Entry module of the system is designed to produce events using event models, and record the link between events and related data. 836 B. Wu et al. Fig. 1. WYSIWYG Query and Exploration Environment 4 Conclusion eVitae system demonstrates an event-based approach for organization, storage, management, and querying of personal history information comprising of multifarious data. The system provides an event entry module for importing data from heterogeneous data sources and assimilating them into events. This information is stored in EventBase which is indexed by events. Event-based modeling allows multidimensional querying and exploration of personal history information. Furthermore, flexibility in event definition and organization allows exploration of the data from multiple perspectives. Preliminary results indicate that an event-based system not only offers significant advantages in information organization, but also in exploration and discovery of information from data. References R. Jain. “Multimedia Electronic Chronicles”, IEEE MultiMedia, pp. 102-103, Volume 10, Issue 03, July 2003. R. Jain, “Events in Heterogeneous Data Environments”, Proc. International Conference on Data Engineering, Bangalore, March 2003. J. Gemmell, G. Bell, R. Lueder, S. Drucker, and C. Wong. “MyLifeBits: fulfilling the Memex vision”, ACM Multimedia, pp. 235-238, ACM, 2002. R. Singh, B. Wu, P. Gupta, R. Jain. “eVitae: Designing Experiential eChronilces”, ESG Technical Report Number : GT-ESG-01-10-03, http://www.esg.gatech.edu/report/GT- ESG-01-10-03.pdf 1. 2. 3. 4. CAT: Correct A nswers of Continuous Queries Using Triggers Goce Trajcevski 1 , Peter Scheuermann 1 *, Ouri Wolfson 2 , and Nimesh Nedungadi 2 1 Department of Electrical and Computer Engineering, Northwestern University, Evanston, Il 60208, {goce,peters}@ece.northwestern.edu 2 Department of Computer Science, University of Illinois at Chicago, Chicago, Il 60607, {wolfson,nnedunga}@cs.uic.edu 1 I ntroduction and Motivation Consider the query Q1: Retrieve all the motels which will be no further then 1.5 miles from my route, sometime between 7:00PM and 8:30PM, which a mobile user posed to the Moving Objects Database (MOD). Processing such queries is of interest to wide range of applications (e.g. tourist information systems and context awareness [1,2]). These queries pertain to the future of a dynamic world. Since MOD is only a model of the objects moving in the real world, the accuracy of the representation has to be continuously verified and updated, and the answer-set of Q1 has to be re-evaluated in every clock-tick 1 . However, the re-evaluation of such queries can be avoided if an update to the MOD does not affect the answer-set. The motion of the moving object is typically represented as a trajectory – a sequence of 3D points and its projection in the X- Y plane is called a route. The details of the construction based on electronic maps and the speed-profiles of the city blocks are given in [5]. After a trajectory is constructed, a traffic abnormality may occur at a future time-point, due to an accident, road-work, etc , and once it occurs, we need to: identify the trajectories that are affected, and update them properly (c.f. [5]). In the sequel, we focus on the impacts of the abnormalities to the continuous queries. Figure 1 shows three trajectories – and and their respective routes and If a road-work starts at 4:30PM on the segment between A and B which will last 5 hours, slow down the speed between 4:30PM and 9:30PM. enters that segment after 4:30PM, and its future portion will need to be modified. As illustrated by the thicker portion of instead of being at the point B at 4:50, the object will be there at 5:05. A key observation is that if the object, say whose trajectory is issued the query Q 1 , we have to re-evaluate the answer. * Research partially supported by NSF grant EIA-000 0536 1 Hence the name continuous queries – formally defined for MOD in [3]. E. Bertino et al. (Eds.): EDBT 2004, LNCS 2992, pp. 837–840, 2004. © Springer-Verlag Berlin Heidelberg 2004 838 G. Trajcevski et al. Fig. 1. Trajectories, Routes and Updates 2 System Architecture Figure 2 illustrates the main components and behavioral aspects of the CAT system: There are tables which: store the trajectories (MOT) and landmarks of inter- est (BUILDINGS); keep track of the queries posed and their answers (PEND- ING-QUERIES and ANSWERS); and store the information about the traffic abnormalities (TRAFFIC_ABN). The trajectories and the landmarks were ob- tained using the real maps of Cook County, Chicago. In the heart of the CAT system is the set of Triggers, part of which we illustrate in the context of the example query Q 1 . I f posed the query Q1 at 3:30PM, its answer contains the motels and to which should be close at 7:55PM and 8:20PM, respectively. When an abnormality is detected, its relevant parameters are inserted in the TRAFFIC_ABN table. This, however, “awakes” whose event is: ON INSERT TO TRAFFIC_ABN checks if the abnormality affects some of the trajectories stored in the MOT and, if so, updates their future part. However, the action part of which updates the MOT, in turn, is the event for ON UPDATE TO MOT IF HAS_PENDING_QUERIES checks if the corresponding moving object has posed some queries which are still of interest (i.e. their time has not “expired”). The condition of is satisfied by and its action part will re-evaluate the query Q 1 , based on the new future-portion of Due to the delay, trajectory will CAT: C orrect A nswers of Continuous Queries Using T riggers 839 Fig. 2. Behavioral Aspects of the CAT be near at 8:35PM, which is a bit too late for the user. On the other hand, will be near the motel at 7:05PM. Before the traffic incident was not part of the answer, (it would have had the desired proximity at 6:50PM). 3 Demonstration All the back-end components are implemented using Oracle 9i as a server. We used User-Defined Types (UDT) to model the entities and User-Defined Func- tions (UDF) to implement the processing, exploiting the Oracle Spatial predi- cates. The front-end client, which is the GUI presented to the end-user, is imple- mented in Java. The GUI gives the options of specifying the queries (i.e. time of submission; relevant time interval; objects of interest; etc ). Once the user clicks the SUBMIT button, the query is evaluated and its answer is displayed. In the server, the query is assigned an id number and it is stored in the PEND- ING_QUERIES table. Clearly, in a real MOD application, the client will be either a wireless (mobile) user of a web browser-based one, properly interfaced to the server. To test the execution of the triggers and the updates of the answer(s) to the continuous queries posed, the GUI offers a window for generating a traffic ab- normality. The user enters the beginning and the end times of the incident as well as its “type” (which determines the impact on the speed-profile). He also enters the route segments along which the traffic incident is spread. The moment this information is submitted to the server, the affected trajectories are updated AND the new answer (s) to the posed continuous queries are displayed back to the user. 840 G. Trajcevski et al. References A. Hinze and A. Voisard. Location-and time-based information delivery in tourism. In SSTD, 2003. A. Pashtan, R. Blatter, A. Heusser, and P. Scheuermann. Catis: A context-aware tourist information system. In IMC, 2003. A. P. Sistla, O. Wolfson, S. Chamberlain, and S. Dao. Modeling and querying moving objects. In ICDE, 1997. G. Trajcevski and P. Scheuermann. Triggers and continuous queries in moving objects databases. In MDDS, 2003. G. Trajcevski, O. Wolfson, B. Xu, and P. Nelson. Real-time traffic updates in moving object databases. In MDDS, 2002. 1. 2. 3. 4. 5. Hippo: A System for Computing Consistent Answers to a Class of SQL Queries Jan Chomicki 1 , Jerzy Marcinkowski 2 , and Slawomir Staworko 1 1 Dept. Computer Science and Engineering, University at Buffalo {chomicki,staworko}@cse.buffalo.edu 2 Instytut Informatyki, Wroclaw Uniwersity, Poland Jerzy.Marcinkowski@ii.uni.wroc.pl 1 Motivation and Introduction Integrity constraints express important properties of data, but the task of pre- serving data consistency is becoming increasingly problematic with new database applications. For example, in the case of integration of several data sources, even if the sources are separately consistent, the integrated data can violate the in- tegrity constraints. The traditional approach, removing the conflicting data, is not a good option because the sources can be autonomous. Another scenario is a long-running activity where consistency can be violated only temporarily and future updates will restore it. Finally, data consistency may be neglected because of efficiency or other reasons. In [1] Arenas, Bertossi, and Chomicki have proposed a theoretical framework for querying inconsistent databases. Consistent query answers are defined to be those query answers that are true in every repair of a given database instance. A repair is a consistent database instance obtained by changing the given instance using a minimal set of insertions/deletions. Intuitively, consistent query answers are independent of the way the inconsistencies in the data would be resolved. Example 1. Assume that an instance of the relation Student is as follows: Assume also that the functional dependency is given. The above instance has two repairs: one obtained by deleting the first tuple, the other - by deleting the second tuple. A query asking for the address of Jones returns Chicago as a consistent answer because the third tuple is in both repairs. However, the query asking for the address of Smith has no consistent answers because the addresses in different repairs are different. On the other hand, the query asking for those people who live in Los Angeles or New York returns Smith as a consistent answer. This conservative definition of consistent answers has one shortcoming: the number of repairs. Even for a single functional dependency, the number of repairs E. Bertino et al. (Eds.): EDBT 2004, LNCS 2992, pp. 841–844, 2004. © Springer-Verlag Berlin Heidelberg 2004 [...]... Querying Inconsistent Databases In International Symposium on Practical Aspects of Declarative Languages (PADL), pages 208–222 Springer–Verlag, LNCS 2562, 2003 5 L Bertossi and J Chomicki Query Answering in Inconsistent Databases In J Chomicki, R van der Meyden, and G Saake, editors, Logics for Emerging Applications of Databases Springer-Verlag, 2003 6 J Chomicki and J Marcinkowski Minimal-Change Integrity... even with large databases [7] Currently, our application computes consistent answers to SJUD queries in the presence of denial constraints (a class containing functional dependency constraints and exclusion constraints) Allowing union in the query language is crucial for being able to extract indefinite disjunctive information from an inconsistent database (see Example 1) Future work includes the support... Query Answers in Inconsistent Databases In ACM Symposium on Principles of Database Systems (PODS), pages 68–79, 1999 2 M Arenas, L Bertossi, and J Chomicki Answer Sets for Consistent Query Answering in Inconsistent Databases Theory and Practice of Logic Programming, 3(4–5):393–424, 2003 3 M Arenas, L Bertossi, J Chomicki, X He, V Raghavan, and J Spinrad Scalar Aggregation in Inconsistent Databases Theoretical... privacy policies The server-centric implementation has several advantages including: setting up the infrastructure necessary for ensuring that web sites act according to their stated policies, allowing P3P to be deployed in thin, mobile clients that are likely to dominate Internet access in the future, and allowing site owners to refine their policies based on the privacy preferences of their users 3 Demonstration... Execution Engine provides interface for receiving a query request from end-users and invoking the appropriate synopsis (or synopses), as determined by the Synopses Manager in order to process such query The Updates Logger provides all data updates to the registered synopses by intercepting data updates information in the data sources The Workload Manager captures, maintains and analyzes workload information... building, maintaining and testing synopses Fig 2 Synopses Integration Figure 2 depicts the integration process of a remote synopsis within the framework The External Synopsis host is responsible for all communication with the system and is transparent to the synopsis This design enables an unconstraint deployment A remote synopsis can be integrated into the system by deploying or adapting such host into... (poset) that captures query subsumption as in [1] A sophisticated index that exploits commonalities between continuous queries is maintained at each super-peer, enabling the quick identification of the continuous queries that match incoming resource metadata In this area, our work extends and improves the indexing algorithms of SIFT [6] and it is reported in [2] References 1 A Carzaniga and D.S Rosenblum... each page scheme, the distinction between temporal and non-temporal attributes; since the model is nested, this distinction is allowed at various levels in nesting Temporal pages and attributes can have additional pieces of information attached, including the following: LAST MODIFIED: the date (at the granularity of interest) of the last change; VALIDITY INTERVAL: the interval during which the element... demonstrate that using consistent query answers we can extract more information from an inconsistent database than in the approach where the input query is evaluated over the database from which the conflicting tuples have been removed Secondly, we will show the advantages of our method over competing approaches by demonstrating the expressive power of supported queries and integrity constraints And finally,... schema in DB2 for storing policy data in the relational tables This schema contains a table for every element defined in the P3P policy The tables are linked using foreign keys reflecting the XML structure of the policies We extend IBM Tivoli Privacy Wizard (a web-based GUI tool for web site owners to define P3P policies) with the functionality of parsing and shredding P3P policies as a set of records in . are true in every repair of a given database instance. A repair is a consistent database instance obtained by changing the given instance using a minimal. constraints and exclusion constraints). Allowing union in the query language is crucial for being able to extract indefinite disjunctive information from an inconsistent

Ngày đăng: 21/01/2014, 08:20

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan