avepoints 
nilestone, 
cel merge 
to which 
mplished 
changes. 
id named 
< changes 
zo to the 
including 
matically 
/epoint is 
space get 
e of the 
) all rows 
either all 
| row. If 
1abling a 
all row 
in time to 
e of that 
nsactions, 
primarily 
vorkspace 
or if we 
es. When 
spaces in 
d or to 
ion of the 
kspace is 
ese locks 
no other 
1e session 
jled for a 
sively. In 
clusively. 
| conflicts 
sers in the 
it. Shared 
row, thus 
red locks 
where the 
al use for 
flicts with 
n of users 
participating in a group project. Shared locking must be 
individually enabled for each session in the workspace. 
4. ARCHITECTURE OF TEMPORAL GIS 
An overall system architecture is shown in Figure 4.1. All 
cadastre-specific functions, as well as user interface for long- 
transaction and temporal management are integrated in standard 
GIS desktop software (GeoMedia Professional) ^ Spatio- 
temporal and long-transaction support and management are not 
implemented in GIS, but in standard DBMS (Oracle object- 
relational model). 
  
  
Oracle Object Long Transaction Read/Write GDatabase 
Objects - GDO 
  
  
  
  
Oracle 9/ Database Engine 
  
ISTIS 
  
  
  
  
Figure 4.1. An overall architecture 
Workspace manager (Oracle Inc., 2003b) implements version- 
enabled user tables in the database. When a table is version- 
enabled, all rows in the table can support multiple versions of 
the data. The versioning infrastructure is not visible to the users 
of the database, and application SQL statements for selecting, 
inserting, modifying, and deleting data continue to work in the 
usual way with version-enabled tables. It uses a series of short 
transactions and multiple data versions to implement a complete 
long-transaction event that maintains atomicity and 
concurrency. 
All changes made in a workspace are made by conventional 
short transactions Changes are stored in the database as 
different workspaces. Users are permitted to create new versions 
of data to update, while maintaining a copy of the old data. The 
ongoing results of the long transaction are stored persistently, 
assuring concurrency and consistency. 
According to the taxonomy of temporal databases (Section 2.2), 
our database could be classified as a rollback database. DBMS 
records data along the transaction time line, using savepoints 
concept discussed in Section 3.2 
4.1 Temporal and Long Transaction Operations in DBMS 
After a table is version-enabled (Fig. 4.2), users in a workspace 
automatically see the correct version of the record in which they 
are interested. Storage expansion and row proliferation is 
109 
minimized by versioning only changed rows and by placing the 
new versions in the same tablespace. 
  
  
DBMS WM.ENABLEVERSIONING('PARCEL'); | 
  
  
  
  
  
  
  
  
A 
UPDATE parcel 
SET ... 
» e 
m mn um un mn um un un um » 
RENAME.. 
PARCEL PARCEL LT PARCEL 
base table renamed and view with 
extended INSTEAD OF 
base table triggers 
Figure 4.2. Version-enable a table (simplified) 
Let's suppose that base table parcel has been defined as 
follows: 
CREATE TABLE parcel 
(gdo gid NUMBER (10,0), 
number: VARCHAR2 (10), 
geometry: SDO GEOMETRY; 
); 
Executing the following PL/SQL procedure performs table 
versioning: 
EXECUTE dbms wm.EnableVersioning 
(M5:oarcol^ ‘view wo overwrite'); 
This procedure creates the necessary structures to enable the 
table (GIS feature) to support multiple versions of rows. The 
value of parameter view wo overwrite means that 
parcel hist view will be created to contain history 
information, and it will show all modifications to the same 
version of the table. A history of modifications to the version is 
maintained; that is, subsequent changes to a row in the same 
version do not overwrite earlier changes. We will summarise the 
effect of this procedure, using simplified SQL statements, as 
follows: 
RENAME parcel to parcel 1t; 
ALTER TABLE parcel 1t ADD 
(Let feature id: NUMBER, 
lec status: VARCHAR (2), 
itt current rovset' ids NUMBER, 
Itt version: NUMBER, 
itt commit revset id: NUMBER, 
itt retire revset id: NUMBER, 
ite unique id. NUMBER, 
Ttt version: NUMBER, 
createTime: DATE, 
retireTime: DATE, 
nextVer: VARCHAR2 (500), 
delStatus: NUMBER, 
VARCHAR2 (100) 
Itiock: 
)? 
CREATE VIEW parcel base AS 
SELECT 
gdo gid,number,geometry,ltt feature id, 
Ire status, Ith current revset id, EL 
ltt version,ltt commit revset id, 
let retire revset id,1tt unique id,rowid 
rid,version,nextver,delstatus,ltlock,createTime, 
retireTime 
FROM parcel Jt It 
WHERE …}