1. Overview of Mobile databases…………………………………….

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 TemporalData…9

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 2

1. Overview of Mobile databases

Wireless devices such as cellular phones, personal digital assistants, and laptop
computers are widely popular; currently there are an estimated 200 million users of
some form of wireless network and it is anticipated that there will be 1 billion
subscribers in the next five years. Users of mobile devices communicate with other
(larger and more powerful) systems in order to use remote data or services. Application
areas include electronic mail, field audit, public safety, stock trading, airline activities,
weather information, bill paying, warehouses, healthcare, and the transportation
industry. Most of these applications access databases, digital libraries, online services,
and location-dependent information provided by mobile databases.

Mobile database environments where objects (users or data) are not static have raised
many new challenges that are not faced by traditional static databases. Two of the most
important aspects of databases are query processing and transaction management; also
face new challenges in a mobile database environment.

For example, query processing has to deal with location dependent queries for instance,
Which is the closest restaurant to me? And assuming that data is mobile, it must find a
dynamic way to localize the object where information is located.

For the wireless applications, many special aspects, different from those of the wired
world are necessary to be considered carefully. Wireless devices have limited power
supply, small-size memory, less powerful CPU, low bandwidth for communication and
many other limitations. The mobility of wireless devices brings the convenience as well
as the problem of localization. These special characteristics of the mobile computing
environment also pose interesting issues in mobile databases. These issues cause
significant changes to the mobile databases from regular distributed databases.

Mobile databases provide information to a mobile user. The term mobile database
does not necessarily mean that the database itself is mobile. Sistla and others propose a
centralized and distributed mobile database architecture where some data is present at
the central server and other data is present at mobile nodes. In a distributed
architecture there is a possibility of nodes being disconnected and thus unavailable to
answer a request at all times.

In a centralized wireless architecture the whole geographical area is divided into cells
where each cell mimics a circle. At the center of each cell is a Base Station (BS) that
communicates with the Mobile Stations (MS) in its cell area through a wireless link.
The BS is also referred to as a server and the MS as a mobile unit, device, or simply a
mobile. BSs serving an area are connected by a wired network. When a MS moves from
one cell to another the wireless link with the old BS is broken and a new link is
established with another BS. In a centralized mobile database the database resides in
the central server (or BS).

There are two ways the server can provide data for a mobile user:

Sushiltry@yahoo.co.in
Sushil Kulkarni 3

* 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.

Sushiltry@yahoo.co.in
Sushil Kulkarni 4

Transaction management: Limited power supply causes frequent disconnections for

wireless devices. Low bandwidth brings high transmission delay and may even lead to
severe data loss sometimes. These kinds of problems would block transactions for a long
time if the traditional concurrency control is used. Therefore, modifications in traditional
transaction management models should be done to fit mobile databases. Most of them
adopt a longer transaction model with a relaxation of ACID properties.

2. Overview of Temporal databases

We will first look at Non-Temporal Databases and then discuss Temporal databases

2.1 Non-Temporal Databases

Commercial database management systems (DBMS) such as Oracle, Sybase, Informix

and O2 allow the storage of huge amounts of data. This data is usually considered to be
valid without considering the time component. Past or future data is not stored. Past
data refers to data, which was stored in the database at an earlier time instant and
which might has been modified or deleted in the meantime. Past data usually is
overwritten with new (updated) data. Future data refers to data, which is considered to
be valid at a future time instant (but not now).

A DBMS stores the data in a well-defined format. A relational DBMS, for example, stores
data in tables (also called relations). Thus, a relational database actually contains a set
of tables. Each table contains rows (tuples) and columns (attributes). A row contains
data about a specific entity, for example, an employee. Each column specifies a certain
property of these entities, for example, the employee's name, salary etc. The following
table stores data about employees:

EmpID Name Department Salary

10 John Sales 12000
12 George Research 10500
13 Ringo Sales 15500

Table: non - temporal table

Object-oriented DBMS store data about entities in objects. So each employee is actually
an object. The type of an object specifies the properties the object has. An employee
object thus has properties such as a name, a salary etc. Sets of objects of the same type
are called collections. Thus - in an object-oriented DBMS - a database contains a set of
collections.

2.2 What is Temporal Databases?

Temporal data strored in a temporal database is different from the data stored in
non-temporal database in that a time period attached to the data expresses when it was

Sushiltry@yahoo.co.in
Sushil Kulkarni 5

valid or stored in the database. As mentioned above, conventional databases consider

the data stored in it to be valid at time instant now, they do not keep track of past or
future database states. By attaching a time period to the data, it becomes possible to
store different database states.

A first step towards a temporal database thus is to timestamp the data. This allows the
distinction of different database states. One approach is that a temporal database may
timestamp entities with time periods. Another approach is the time stamping of the
property values of the entities. In the relational data model, tuples are time stamped,
where as in object-oriented data models, objects and/or attribute values may be time
stamped.

What time period do we store in these timestamps? As we mentioned already, there are
mainly two different notions of time, which are relevant for temporal databases. One is
called the valid time, the other one is the transaction time.

Valid time denotes the time period during which a fact is true with respect to the real
world. Transaction time is the time period during which a fact is stored in the
database. Note that these two time periods do not have to be the same for a single fact.

Imagine that we come up with a temporal database storing data about the 18th century.
The valid time of these facts is somewhere between 1700 and 1799, where as the
transaction time starts when we insert the facts into the database, for example, January
21, 1998.

Assume we would like to store data about our employees with respect to the real world.
Then, the following table could result:

EmpID Name Department Salary ValidTimeStart ValidTimeEnd

10 John Research 11000 1985 1990
10 John Sales 11000 1990 1993
10 John Sales 12000 1993 INF
11 Paul Research 10000 1988 1995
12 George Research 10500 1991 INF
13 Reena Sales 15500 1988 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.

Sushiltry@yahoo.co.in
Sushil Kulkarni 6

2.3 Different Forms of Temporal Databases

The two different notions of time - valid time and transaction time - allow the distinction
of different forms of temporal databases. A historical database stores data with
respect to valid time, a rollback database stores data with respect to transaction time.
A bitemporal database stores data with respect to both valid time and transaction
time.

As we mentioned above, commercial DBMS are said to store only a single state of the
real world, usually the most recent state. Such databases usually are called snapshot
databases. A snapshot database in the context of valid time and transaction time is
depicted in the following picture:

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.

Sushiltry@yahoo.co.in
Sushil Kulkarni 7

2.4 What are Temporal Database Management Systems?

Commercial database management systems (DBMS) such as Oracle, Sybase,

Informix and O2 are non-temporal DBMS since they do not support the
management of temporal data. A temporal DBMS should support temporal data
definition language, a temporal data manipulation language and a temporal query
language, temporal constraints.

Although some of the DBMS support data types for dates and time, they cannot be
considered to be temporal DBMS. For example, the specification of a query considering
several different database states (the history of data) is left to the user, without any
support by the system.

A temporal DBMS such as TimeDB supports

a. a temporal data definition language,

b. a temporal data manipulation language, and
c. a temporal query language,
d. temporal constraints (such as temporal referential integrity).

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),

Sushiltry@yahoo.co.in
Sushil Kulkarni 8

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),

Sushiltry@yahoo.co.in
Sushil Kulkarni 9

Department CHAR(40) VALIDTIME REFERENCES

Departments(department),
Salary INTEGER)
AS VALIDTIME AND TRANSACTIONTIME;

2.5 Application Domains dealing with Temporal Data

Following are examples of application domains dealing with temporal data:

* Financial Applications (e. g. history of stock market data)

* Insurance Applications (e. g. when were the policies in effect)
* Reservation Systems (e. g. when is which room in a hotel booked)
* Medical Information Management Systems (e. g. patient records)
* Decision Support Systems (e. g. planning future contingencies)
...
In fact, it is difficult to identify application domains that do not involve the management
of temporal data.

2.6 What kinds of Solutions are available today?

Following are different possible solutions to manage temporal data:

* Use a type date supplied in a non-temporal DBMS and build temporal

support into applications
* Implement an abstract data type for time
* Extend a non-temporal data model to a temporal data model
* Generalize a non-temporal data model into a temporal data model

The first two solutions do not involve any changes to existing database technology, the
later two may only be used if the currently available database technology is adapted to
the changes done to the underlying data models.

Today, only the first two approaches are available. The second one is based on object-
relational or object-oriented DBMS. An approach, which is based on the third possibility
listed above, is TimeDB. TimeDB cannot be considered as a Temporal DBMS, however,
since it translates Temporal SQL statements into standard SQL statements, which then
are executed on a commercial DBMS such as Oracle, Sybase etc. The advantage of this
approach is that an existing database can partly be migrated to a temporal database
while all the legacy applications still run without any changes.

3. Overview of Spatial databases.

Spatial databases support spatial attributes such as points, lines, polygons and higher
dimensional spatial objects as well as conventional data types. Spatial objects deal with
large collections of relatively simple geometric objects.

Sushiltry@yahoo.co.in
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:

a. Topological relationships: This relationship finds whether one spatial object is

adjacent, inside, disjoint to another spatial object. One can also rotate, scaling the
spatial object.
b. Direction relationships: This relationship finds the spatial object, which is above,
below, or north-of, south west of, … from another spatial object.
c. Metric relationships: This relationship finds the distance between spatial objects.

DBMS data model extends by SDTs at the level of atomic data types (such as integer,
string), or better be open for user-defined types (such as OR-DBMS approach):

3.2 Relational schema

The scheme of a relation can consist of both non-spatial and spatial attributes. Non-
spatial data is stored in conventional database relations while spatial data is stored in
special purpose spatial data structures such as R-trees.

Bi-directional links relate the non-spatial and spatial parts of each tuple e.g. the key or
record id is stored with the spatial part of the tuple, while some uniquely identifying
spatial information is stored with the non-spatial part of the tuple.

Comparison operations on spatial attributes are supported. For example, point within
region, line within region, line intersects region, region1 intersects region2, region1
touches region2, objects within distance d of a given object, the n nearest neighbors of
a given object.

Conventional query languages can be extended to operate on spatial attributes.

Sushiltry@yahoo.co.in
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)

Sushiltry@yahoo.co.in
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)

Non-leaf nodes contain entries of the form

(I, child pointer)

Sushiltry@yahoo.co.in
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 node’s 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.

Sushiltry@yahoo.co.in
Sushil Kulkarni 14

I3: [Propagate changes upward] Invoke Adjust Tree on L, also passing to it LL if L

was split.

I4: [Grow tree taller] If node split propagation caused the root to split, create a new
root whose children are the two resulting nodes.

(c) Chooseleaf Algorithm

This selects a leaf node in which to place a new index entry E:

CL1: [Initialize] Set N to be the root node.

CL2 : [ Leaf check] If N is a leaf_ return N.

CL3 : [Choose subtree] If N is not a leaf, let F be the entry in N whose rectangle F.I
needs least enlargement to include E.I. Resolve ties by choosing the rectangle with the
smallest area.

CL4 : [Descend until a leaf is reached] Set N to be the child node pointed to by F.p
and repeat from CL2

AdjustTree Algorithm: This ascends from a leaf node to the root, adjusting covering
rectangles and propagating node splits upwards as necessary.

Sushiltry@yahoo.co.in