that allows the handling of temporal data. Within the last years
a range of temporal models were also developed in the field of
object-relational (OR) and object-oriented (OO) databases.
GIS are more and more based on a DBMS with spatial and
temporal extensions. The design and implementation of modern
GIS systems for cadastre should pay special attention to the
temporal aspects and include long transaction, versioning,
lineage and querying multiple spatio-temporal datasets.
In GIS environment, database is highly shared resource that is
accessed concurrently by many applications programs and
interactive users. This demands a control component that
governs the access to shared data in order to avoid undesired
interference between concurrently executing processes. The
basic concept of this control component is transaction. The
properties of the classical transaction lead not only to the
concurrency control concepts required in order to avoid the
unwanted interference but also to the recovery concepts
required to diminish the harm of failures. Transaction is a group
of operations against database. In traditional DBMSs,
transactions serve three distinct purposes: (1) They are logical
units that group together operations comprising a complete task;
(2) they are atomicity units whose execution preserves the
consistency of the database; and (3) they are recovery units that
ensure that either all the steps enclosed within them are
executed or none are. It is thus by definition that if database is
in consistent state before a transaction starts executing, it will
be in a consistent state when the transaction terminates. In a
multi-user system, users execute their transactions concurrently.
The DBMS must provide a concurrency control mechanism to
guarantee that consistency of data is maintained in spite of
concurrent accesses by different users. The conventional model
of transactions in DBMS is based on the notions of
serializability and atomicity. This transaction model has served
quite well in conventional data-processing applications, where
transactions typically terminate within a few seconds.
Transactions and concurrency control in GIS are different from
those in conventional database applications; in particular, there
is a need to support nonserializable cooperation among users
whose transactions are long-lived and interactive and to
integrate concurrency control mechanisms with version control.
The specific purpose of this paper is to propose a standard way
of designing and implementing temporal GIS for cadastre in
specific, standard and commercially available DBMS/GIS
environment. It presents related work in Section 1.1. The
temporal framework and long-transaction support is introduced
in Section 2. The database model and overall system
architecture is presented in Section 3. The paper ends with a
conclusion and a list of references.
1.1 Related work
Time is probably one of the most essential and paradoxical
concepts that human beings face. It is very difficult concept to
describe and formalise, as it has no obvious physical
characteristics and properties. The relationship between time
and space is a consequence of the observation of changes as the
perception of spatial alterations denotes the existence of time.
Since more and more spatial functionality is available within
DBMSs (IBM Inc., 2002, Oracle Inc, 2003), a more generic
GIS approach is required, which can work with spatio-temporal
data in a model not controlled by the GIS. Over the past years,
the representation of spatio-temporal data has been extensively
106
discussed by different research communities such as the
Artificial Intelligence domain that provides a mathematical
foundation to the representation of changes in space (Allen,
1983), temporal database approaches that develop database
models and query languages for the description and
manipulation of temporal objects (Al-Taha, 1992; Snodgrass,
1995; Skjellaug, 1996, Bohlen, Jensen and Skjellaug, 1998;
Jensen and Snodgrass, 1999) and studies oriented to the
temporal extension of current spatial data models within GIS
(Claramunt and Thériault, 1995; Wachowicz, 1999; Horsby and
Egenhofer, 2000).
Quite a lot of attention has been paid to methods of modelling,
storing, indexing, editing, manipulating, analysing and
visualizing spatio-temporal data. Good overviews of handling
spatio-temporal data can be found in (CHOROCHRONOS: A
Research Network for Spatiotemporal database Systems, 1996-
2000; Claramunt and Thériault, 1995; Skjellaug, 1996; Jensen
et aL, 1998). Some papers specifically focus on temporal
aspects in the cadastral domain (Chen and Jiang, 1998; Galic,
2002; Hartmannn, 2002; van Oosterom, 1997; van Oosterom
and Lemmen, 2002a; van Oosterom et al., 2002b).
Concurrency control has been thoroughly studied in the context
of traditional database applications such as banking, airline
reservation systems, and successfully implemented in cadastre
(legal and other administrative data related to parcels) as well.
A GIS for cadastre requires a significantly different model of
transaction form. Early proposals attempted to define a model of
CAD transactions (Korth et al., 1988) and engineering design
databases (Kim et al., 1984). An overview of the characteristics
of data and operations in some advanced database applications,
including concurrency control requirements and the surveys of
the mechanisms to address these requirements can be found in
(Barghouti and Kaiser, 1991). The version mechanism for GIS
is described in (Medeiros and Jomier, 1994), and concepts of
transaction processing in the Internet are described in (Mohan,
1998).
2. TEMPORAL FRAMEWORK
2.1 Notions of time
For temporal databases, the existence of more than one time line
was proposed in order to capture different aspects of the
relationship between time and data. The following subsections
introduce different notions of time denoting different time lines.
These are then used to distinguish different forms of temporal
databases in terms of their ability to model the various forms of
temporal properties of data.
User-defined Time: A distinction can be made whether or not
the timestamp added to data is interpreted by the DBMS. An
uninterpreted timestamp, for example, a value in an attribute
day of surveying, is called user-defined time, because the
user himself interprets the given time information, whereas
DBMS treats this temporal data as just another attribute. User-
defined time is an uninterpreted time value. Data models
support user-defined time by offering, for example, a type date
or timestamp. User-defined time values are supplied by the
user/application and may be updated.
Valid Time: when a fact was true with respect to the real
world. A valid-time interval thus records the time period when a
fact is true. It is interpreted by a DBMS supporting valid time,
for exar
Valid ti
adding ©
Transac
Besides
is also n
are store
changes
can also
database
transacti
constraii
timestan
These k
with nc
Underst:
present
Unfortui
only foi
whatsoe
2.2 Ta
Accordi
categori
the val
(Snodgr
Snapshe
world, u
is done
update,
support.
valid tir
current s
denoted
successf
state.
Valid
À
now
Historic
the real
axis. Pa:
This car
With res
where e
historica
leads to
time of {