Overview of Mobile Databases 2. Overview of Temporal Databases
Overview of Mobile Databases 2. Overview of Temporal Databases
2
2. Overview of Temporal databases.4
2.1 Non-Temporal Databases..4
2.2 What is Temporal Databases?...5
2.3 Different Forms of Temporal Databases.6
2.4 What are Temporal Database Management
Systems?..7
2.5 Application Domains dealing with TemporalData9
2.6 What kinds of Solutions are available today?...9
3. Overview of Spatial databases.10
3.1 Spatial objects and relationships..10
3.2 Relational schema...10
3.3 Queries.11
3.4 Graphical I/O issue.12
3.5 R -trees..12
Sushil Kulkarni
Sushil Kulkarni
* Pull-based method
* Push-based method
In a pull-based method the user sends a request for data on an uplink channel and
the server processes the request and sends the data to the client on a downlink channel.
An uplink channel is a channel on which a mobile can send its query to the server. The
downlink channel or pull channel is the channel on which an answer to a query is sent
to an individual mobile. Other mobiles cannot access the downlink information. Uplink
channel bandwidth is used to send queries and downlink channel bandwidth is required
to send the answers to the queries.
In a push-based method the server broadcasts the data on a broadcast channel and
the mobiles tune to that particular channel to retrieve the information. In this approach
the server continuously and repeatedly broadcasts data to the clients. The broadcast
channel becomes a disk from which clients can retrieve data. The broadcast is created
by assigning data items to different disks of varying sizes and speeds and then
multiplexing the disks on the broadcast channel. In this mode there is a wait for the
data but there is a reduction in the channel bandwidth that is used since the data need
not be sent to each client separately.
The architecture that is the backbone for a distributed mobile computing system is as
follows:
Stationary hosts (SH), also called fixed hosts (FH), and base stations (BS) are
connected via a high-speed wireline (not wireless) network. The wireless devices that
issue the transactions are called mobile hosts (MH). Mobile hosts are also called mobile
units (MU) or mobile stations (MS). The distributed database is stored on the stationary
hosts and accessed via the mobile units through the base stations. A mobile unit may
change locations and even connections while continuing to process transactions.
A transaction is a set of database operations such as insertions, deletions, updates or
retrievals of data that are applied to a database. The transaction can be written in a
query language such as SQL or embedded in a program. A mobile transaction is a
transaction where at least one mobile host is involved in the transaction.
Data Management: In the mobile environment, mobile devices can also be the units
to store data. However, due to the limited sources of the wireless devices, it becomes a
more complex problem to decide some problems such as which part of data can be kept
in wireless devices, which part need replica in case of devices failure and so on.
Query Processing: The mobility of the wireless environment brings the location
dependent queries such as Find the hotels within 5 miles, Find the local popular news
paper here, etc. Sometimes the results are different at different places. There are
different approaches for query processing on these kinds of problems. Many aspects
such as location and time are considered by different approaches to deal with the query
processing.
Sushil Kulkarni
EmpID
10
12
13
Name
John
George
Ringo
Department
Sales
Research
Sales
Salary
12000
10500
15500
Sushil Kulkarni
Name
John
John
John
Paul
George
Reena
Department
Research
Sales
Sales
Research
Research
Sales
Salary
11000
11000
12000
10000
10500
15500
ValidTimeStart
1985
1990
1993
1988
1991
1988
ValidTimeEnd
1990
1993
INF
1995
INF
INF
The above valid-time table stores the history of the employees with respect to the real
world. The attributes ValidTimeStart and ValidTimeEnd actually represent a time
interval, which is closed at its lower and open at its upper bound. Thus, we see that
during the time period [1985 - 1990), employee John was working in the research
department, having a salary of 11000. Then he changed to the sales department, still
earning 11000. In 1993, he got a salary raise to 12000. The upper bound INF denotes
that the tuple is valid until further notice. Note that it is now possible to store
information about past states. We see that Paul was employed from 1988 until 1995. In
the corresponding non-temporal table, this information was (physically) deleted when
Paul left the company.
Sushil Kulkarni
On the other hand, a bitemporal DBMS such as TimeDB stores the history of data
with respect to both valid time and transaction time. Note that the history of when data
was stored in the database (transaction time) is limited to past and present database
states, since it is managed by the system directly which does not know anything about
future states.
A table in the bitemporal relational DBMS TimeDB may either be a snapshot table
(storing only current data), a valid-time table (storing when the data is valid w.r.t.the
real world), a transaction-time table (storing when the data was recorded in the
database) or a bitemporal table (storing both valid time and transaction time). An
extended version of SQL allows specifying which kind of table is needed when the table
is created. Existing tables may also be altered (schema versioning). Additionally, it
supports temporal queries, temporal modification statements and temporal
constraints.
The states stored in a bitemporal database are sketched in the picture below. Of course,
a temporal DBMS such as TimeDB does not store each database state separately as
depicted in the picture below. It stores valid time and/or transaction time for each tuple,
as described above.
[email protected]
Sushil Kulkarni
TimeDB supports SQL, however in an extended form. Basically, two keywords are added
VALIDTIME and TRANSACTIONTIME.
a. Temporal Data Definition Language
In TimeDB, a bitemporal table can be created as follows:
CREATE TABLE Employees (
EmpID INTEGER,
Name CHAR(30),
Sushil Kulkarni
Department CHAR(40),
Salary INTEGER)
AS VALIDTIME AND TRANSACTIONTIME;
b. Temporal Data Manipulation Language
The following statement inserts temporal data about John:
VALIDTIME PERIOD '1985-1990'
INSERT INTO Employees VALUES (10, 'John', 'Research', 11000);
VALIDTIME PERIOD '1990-1993'
INSERT INTO Employees VALUES (10, 'John', 'Sales', 11000);
VALIDTIME PERIOD '1993-forever'
INSERT INTO Employees VALUES (10, 'John', 'Sales', 12000);
c. Temporal Query Language
To query the data, the same keywords are used:
VALIDTIME
SELECT * FROM Employees;
This query returns the history of the employees with respect to valid time (when were
they employed). The following query finds out when the tuples in table Employees were
stored in the database:
TRANSACTIONTIME
SELECT * FROM Employees;
To find out both valid time and transaction time, a combination of the keywords can be
used:
VALIDTIME AND TRANSACTIONTIME
SELECT * FROM Employees;
In fact, any legal standard SQL query can be extended with one of the combinations
VALIDTIME, TRANSACTIONTIME or VALIDTIME AND TRANSACTIONTIME.
c. Temporal Constraints
Temporal integrity constraints can be expressed similarly. For example, a referential
integrity constraint demanding that at each time instant an employee is a member of
a department, the corresponding department itself must exist, can be expressed the
following way:
CREATE TABLE Employees (
EmpID INTEGER,
Name CHAR(30),
Sushil Kulkarni
Sushil Kulkarni
10
A spatial database system is a DBMS with additional capabilities for handling spatial
data that offers spatial data types (SDTs) in its data model and query language. It
provides the following:
* Structure in space: e.g., POINT, LINE, REGION
* Relationships among them: (l intersects r)
* Providing at least spatial indexing (retrieving objects in particular area without
scanning the whole space)
* Efficient algorithm for spatial joins (not simply filtering the cartesian product)
3.1 Spatial objects and relationships
In spatial DBMS a single object means:
a. Point: It is an object that represents only the location in space, e.g., center of a
state.
b. Line: It is an object that represents actually a curve or ployline. In otherworlds, it is
a representation of moving through or connections in space, e.g., road, river.
c. Region: It is an object that represents an extent in 2d-space, e.g., lake, and city.
Spatial relationships between spatial objects are:
Sushil Kulkarni
11
3.3 Queries
Using the following relations we will define different spatial algebra operations
relation states (sname: STRING; area: REGION; spop: INTEGER)
relation cities (cname: STRING; center: POINT; ext: REGION; cpop:
INTEGER);
relation rivers (rname: STRING; route: LINE)
a. Spatial selection: It returns those objects satisfying a spatial predicate.
For example,
Query 1: Locate All cities in Maharashtra
SELECT sname
FROM cities c
WHERE c.center
inside Maharashtra .area
Query 2: Locate All rivers intersecting a query window
SELECT *
FROM rivers r
WHERE r.route intersects Window
Query 3: Locate All big cities no more than 100 Kms from Pune
SELECT cname
FROM cities c
WHERE dist(c.center, Pune.center) <100 and c.pop > 500k
(Conjunction with other predicates and query optimization)
b. Spatial join: A join, which compares any two joined objects, based on a predicate
on their spatial attribute values.
For example,
Query : For each river pass through Maharashtra, find all cities within less than 50
Kms.
SELECT r.rname, c.cname, length(intersection(r.route, c.area))
FROM rivers r, cities c
WHERE r.route intersects Maharashtra.area and
dist(r.route,c.area) < 50 Km
Let us consider another relations as shown below:
relation Roads(id, name, location: LINE);
relation Areas(id, name, usage, location: REGION)
[email protected]
Sushil Kulkarni
12
The following query finds the names of all roads that pass through the Dadar area
SELECT R.name
FROM Roads R, Areas A
WHERE A. name = Dadar AND intersects(R. location, A. location)
and the following query finds all areas that are adjacent to parks
SELECT A. location
FROM Areas A1, Areas A2
WHERE A1.usage = Park AND touches (A1. location, A2.location)
3.4 Graphical I/O issue
The question is how to determine Window or Maharashtra in previous examples
(input); or how to show intersection (route, Maharashtra.area) or r.route (output)
The results are usually a combination of several queries.
The requirements for spatial querying are as follows:
* Spatial data types
* Graphical display of query results
* Graphical combination (overlay) of several query results (start a new picture,
add/remove layers, change order of layers)
* Display of context (e.g., show background such as a raster image (satellite image) or
boundary of states)
* Facility to check the content of a display (which query contributed to the content)
*3.5 R- trees
R- tree indexes can be used to support both point- based and region-based queries.
An R- tree is a height-balanced tree similar to a B- tree with the records in its leaf nodes
containing pointers to spatial objects. Each node of the tree is stored in one disk page.
The index is designed so that a spatial search requires visiting only a small number of
nodes.
Leaf nodes in an R- tree contain records of the form
(I, tuple identifier)
Where tuple identifier is a pointer to a spatial object and I is an n- dimensional rectangle
which is the bounding box of this spatial object i.e.
(I
1,
I 2 , I 3 ,. I n)
Sushil Kulkarni
13
Where child pointer is the address of a node at the next level down in the R-tree and I
cover all rectangles in this lower nodes entries.
Let m be the minimum number of entries in a node and let M be the maximum number
of entries in a node (these numbers are chosen according to physical page sizes)
An R-tree satisfies the following properties:
* Every leaf node contains between m and M index records, unless it is the root, which
may have less than m records;
* For each record (I, tuple identifier) in a leaf node, I is the smallest rectangle that
spatially contains the n- dimensional spatial object represented by the indicated
tuple;
* Every non-leaf node has between m and M children unless it is the root, which may
have less than m children;
* For each entry (I, child pointer) in a non-leaf node, I is the smallest rectangle that
spatially contains the rectangles in the child node;
* The root node has at least two children unless it is a leaf;
* All leaves appear on the same level
The worst case height of an R-tree is O ( log m N) where N is the number of index
records. The worst case space utilization of all nodes, except the root is m/ M.
In the following, we denote the rectangle part of an index entry E by E.I and the tuple
identifier or child-pointer part by E.p.
(a) Search Algorithm
Given an R-tree whose root is T, this finds all index records whose rectangles overlap a
search rectangle S:
S1: [Search subtrees] If T is not a leaf, check each entry E to determine whether E.I
overlaps S. For all overlapping entries, invoke Search on the tree whose root node is
pointed to by E.p.
S2: [Search leaf node] If T is a leaf, check all records E to determine whether E.I
overlaps S. If so, E is a qualifying record. The actual spatial object is then inspected to
see if it indeed overlaps S.
(b) Insert Algorithm
This inserts a new record E into an R-tree:
I1: [Find position for new record] Invoke Chooseleaf to select a leaf node L in
which to place E.
I2: [Add record to leaf node] If L has room for another entry, install E. Otherwise
invoke Split node to obtain L and LL containing E and all the old entries of L.
Sushil Kulkarni
14