CHAPTER 11 Modeling and Querying Current Movement
11.2 MOST—A Data Model for Current and
We now introduce the moving objects spatiotemporal (MOST) data model used in the remainder of the chapter.
11.2.1 Basic Assumptions
First, let us recall some standard assumptions. A database is a set of object classes.
Each object class is given by its set of attributes. It is also assumed that spatial data types, such as point, line, and polygon with suitable operations, are available.
Some object classes are designated as spatial , which means they have an attri- bute representing a spatial value, such as a point or a polygon. The object itself is then called a point object or a polygon object . Also, the operations on the spatial values are applied to the objects directly. So, for example, if we have two point objects p 1 and p 2 and a polygon object pol , we can apply spatial operations such as DIST( p 1 , p 2 ), returning the distance between the point attribute values of p 1 and p 2 , or INSIDE( p 1 , pol ), testing whether the point attribute value of p 1 lies inside the polygon attribute value of pol . For all of this to work, it is necessary that each object has exactly one spatial attribute. More specifi cally, we assume that each spatial object class is either a point class, a line class, or a polygon class.
Of particular interest in this model are point objects. A fi rst way of modeling point objects lets them have a special attribute called pos , which, in turn, has two
1 We assume that updates are executed instantaneously (i.e., there is no time difference between sending the update and performing the update in the database). In other words, valid time and transaction time are equal.
components, called subattributes , denoted pos.x and pos.y (in case of a two- dimensional coordinate system). The data types of the subattributes may be int or real .
Besides object classes, a database contains a special object called Time , which yields the current time at every instant. Time is discrete (i.e., the time domain is the natural numbers, represented as int ), and the value of the Time object increases by one at each clock tick.
11.2.2 Dynamic Attributes
The fundamental new idea in the MOST model is the so-called dynamic attributes . Each attribute of an object class is classifi ed to be either static or dynamic . A static attribute is as usual. A dynamic attribute changes its value with time auto- matically. For example, the schema for an object class describing cars moving freely in the xy -plane might be given as:
car (license _ plate: string,
pos: (x: dynamic real, y: dynamic real))
Not all attribute types are eligible to be dynamic. It is assumed that such a type has a value 0 and an addition operation. This holds for numeric types such as int or real but could be extended to types such as point .
Formally, a dynamic attribute A of type T (denoted A:T ) is represented by three subattributes, A.value , A.updatetime , and A.function , where A.value is of type T , A.updatetime is a time value, and A.function is a function f : int → T such that at time t = 0, f ( t ) = 0. The semantics of this representation are called the value of A at time t and defi ned as:
value A t( , ) =A. value+A. function(t−A. updatetime)fort≥A. upddatetime An update sets A.updatetime to the current time value and changes A.value ,
A.function , or both.
If a query refers to the attribute A , its dynamic value is meant and used in the evaluation. Therefore, the result depends on the time when the query is issued.
It is also possible to refer to the subattributes directly and so access the represen- tation of a dynamic attribute. For example, a user can ask for objects for which
pos.x.function = 5 (meaning f ( t ) = 5 t ) to fi nd objects whose speed in x - direction is 5. While dynamic attributes are intended to support description of movement, they may be used to describe other time-dependent values (e.g., temperature).
11.2.3 Representing Object Positions
We have already seen the fi rst method to describe moving point objects by dynamic x and y subattributes of the position attribute pos . This is appropriate for objects moving freely in the xy -plane.
For vehicles, a more realistic assumption is that they move along road net- works. The second method of modeling uses an attribute loc with six subattrib- utes, called loc.route , loc.startlocation , loc.starttime , loc.direction ,
loc.speed , and loc.uncertainty . Here, loc.route is (a pointer to) a line spatial object, which describes the geometry of a path over the traffi c network (i.e., the route along which the object is moving). Loc.startlocation is a point on loc.
route , the location of the moving object at time loc.starttime . Loc.direction is a Boolean indicating the direction along the route (relative to east – west, north – south, or the end points of the route). Loc.speed is a function f giving the distance (along the route) from the loc.startlocation as a function of the time elapsed since the last location update — that is, since loc.starttime . It is assumed that every update sets loc.starttime and loc.startlocation to the position at that time. Again, we require f (0) = 0. In the most simple form, loc.speed stores a constant v , therefore, the distance from loc.startlocation at time loc.start- time + t is v × t . Loc.uncertainty is either a constant or a function of the number of time units elapsed since the last location update. It represents a threshold on the deviation of the object; whenever the threshold is reached, the object will send a location update. Loc.uncertainty is used and further discussed later in Section 11.4 .
The semantics of the loc attribute are again a time-dependent position ( x, y ) in the plane, which also happens to lie on the network. At time loc.start- time , it is loc.startlocation ; at time loc.starttime + t , it is the position on
loc.route at distance loc.speed × t from loc.startlocation in the direction
loc.direction . Query evaluation may take the uncertainty into account. That is, the answer to a query for the location of object m at time t may be: The object is on the route loc.route at most loc.uncertainty before or behind position ( x, y ).
The uncertainty subattribute is, of course, not specifi c to the network model- ing; it might be added to the pos attribute as well. In this case, the answer to the query would be: The object is within a circle of radius uncertainty around position ( x, y ).
11.2.4 Database Histories
Queries in traditional database systems refer to the current state of the database.
Queries in the MOST model may also refer to future states that are given implicitly by the dynamic attributes. First, we need to be more precise about what is meant by a database state.
A database state is a mapping that associates each object class with a set of objects of the appropriate type and associates the Time object with a time value.
For any object o in a database, we denote its attribute A as o . A ; if A has a subat- tribute B it is denoted as o . A.B . The value of o . A in the database state s is denoted by s ( o . A ), and s ( Time ) gives the time value of database state s . For each dynamic attribute A , its value in state s is value ( A , s ( Time )).
A database history is an infi nite sequence of database states, one for each clock tick. It starts at some time u and extends infi nitely into the future — there- fore, it is s u , s u + 1 , s u + 2 , and so on. We denote the history starting at time u by H u . The value of an attribute A in two consecutive database states s i , s i + 1 can be dif- ferent, either due to an explicit update of A or because A is a dynamic attribute whose value has changed implicitly. At any time t the database states with a lower timestamp than t are called past database history ; the infi nite remainder of the sequence with higher timestamps is called future database history .
Note that an explicit update at a time t > u affects all states from t on of a given history H u . Suppose until t − 1, the history H u is:
su,su+1,su+2, . . . ,st−1, ,s st t+1,st+2, . . . Then, from time t on, the history is:
su,su+1,su+2, . . . ,st−1, ,s st′ ′t+1,st′+2, . . .
Therefore, with each clock tick, we get a new database state, and with each update, we get a new history. We denote a history starting at time u and as of time u + k (i.e., updates have been performed until and including time u + k ) by H u, k . Therefore, H u ,0 = H u , and with t = u + k the history before the update is H u, k – 1 , and after the update it is H u, k .
Note that database histories are just a concept to defi ne the semantics of queries; they are not stored or manipulated explicitly, which obviously would be impossible.
11.2.5 Three Types of Queries
Queries are predicates over database histories rather than just a single state. This leads to a distinction between three different types of queries, called instanta- neous, continuous , and persistent . The same query can be posed in each of the three modes, with different results; these are explained next.
As we will see in Section 11.3 , a query has an implicit concept of the current time. For example, there will be language constructs to express a condition “ within the next ten time units, ” which means within ten time units from the current time. If nothing is said about time, the database state at the current time is meant. The current time is normally the time when the query is issued. We denote by Q ( H , t ) a query Q evaluated on a database history H assuming a current time t .
A query Q posed at time t as an instantaneous query is evaluated as:
Q H t( t, ) (instantaneous query)
That is, it is evaluated on the history starting at t , assuming t as the current time.
For example, a query issued at time t by a car driver — “ Find all motels within fi ve miles from my position ” — will return all the motels within fi ve miles from the car ’ s position at time t .
It is important to observe that the concept of an instantaneous query does not imply that only the current database state is used. For example, the driver might also pose the query “ fi nd all motels that I will reach within ten minutes, ” and this query refers to all database states having a timestamp between the current time and ten minutes later.
The second type of query is the continuous query. Query Q posed at time t as a continuous query is evaluated as a sequence of queries:
Q H t( t, ),Q H( t+1,t+1),Q H( t+2,t+2), . . . (continuous query)
In other words, it is reevaluated on each clock tick as a new instantaneous query.
The answer to the query also changes over time; at instant u the result of the instantaneous query Q ( H u , u ) is valid. If the result of the continuous query is displayed to the user, the contents of the display may change without user inter- action. For example, the car driver may decide to run the query, “ Find all motels within fi ve miles from my position, ” as a continuous query in order to be informed when suitable motels become available.
Of course, reevaluating the query on each clock tick is not feasible. Instead, an evaluation algorithm is given that computes the answer to a continuous query just once, in the form of a set of tuples annotated with timestamps. For each tuple, its timestamp indicates the period of time during which it belongs to the result.
When time progresses, tuples whose time period is entered are added to the answer set, and tuples whose time period has expired are removed from the answer set.
As already discussed in this chapter as introduction, the answer to a future query is tentative. For a continuous query, this means that the result set (tuples with timestamps) may become invalid due to an explicit update. Therefore, a continuous query needs to be reevaluated on an update that may change its result set.
The third type of query, persistent query, is motivated by the fact that so far with continuous queries it is impossible to recognize certain kinds of develop- ments over time. As an example, consider the query, “ Q = Find all cars whose speed has doubled within fi ve minutes. ” Suppose this is posed as a continuous query at time t = 20 (and let time units be minutes). Let o be a car with o.loc.
speed = 40. Further, let the speed of o be explicitly updated to 60 at time 22 and to 80 at time 24.
When the continuous query is evaluated as Q ( H 20 , 20), in all future states the speed of o is 40; therefore, it is not in the result. When it is evaluated as Q ( H 22 , 22), in all future states the speed is 60. Similarly, when evaluated as an instanta- neous query at time 24, in all future states the speed is 80. So o is never in the result.
Query Q posed at time t as a persistent query is evaluated as a sequence of queries:
Q H( t, ,0 t) (,Q Ht, ,1t) (,Q Ht, ,2 t), . . . (persistent query)
Therefore, a persistent query is continuously evaluated on the history starting at time t and its answer changes when that history changes due to explicit updates.
Considering our example, when the fi fth query in the previous sequence, Q ( H 24 , 20), is evaluated, the fact that the speed of o has doubled from time 20 to time 24 is recognized, and o is returned as a result. Again, reevaluation does not really occur on each clock tick; instead, it is done on each update that might affect its result, as is done for continuous queries.
We have included persistent queries in the discussion in order to show the different kinds of continuous queries that are possible from a semantic point of view. However, to evaluate persistent queries, it is necessary to keep information about past contents of the database (i.e., to use a kind of temporal version of the MOST data model). So far, the MOST model is nontemporal, in the sense that values of subattributes are rewritten on updates and the previous values are lost.
Extending the MOST model in this way is beyond the scope of this chapter, and we will not consider the evaluation of persistent queries further.