ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS”, Bangkok, May 23-25, 2001 
storing the one-to-many relationship. One object is represented 
by a number of rows as FID is repeated in each record. Oracle 
DBMS offers two options to overcome this disadvantage i.e. 
object-oriented views and object-relational implementation. 
5.2 Object-oriented views 
Object-oriented views do not change the relational type of the 
data structure but provide certain facilitation in maintenance of 
objects. The employment of object-oriented views gives 
advantages in several directions: 1) the view is processed 
entirely on the database level that results in significantly fewer 
SQL statements and thus round trips (query-respond); 2) the 
data can be extracted from a single view table instead of writing 
complex joins for multiple tables; 3) the extracted data can be 
straightforward used by object-oriented languages for further 
processing. Views are especially appropriate for retrieval of 
standard data sets, e.g. the geometry needed for composing a 
VRML file. To assess the performance of the object-oriented 
views, we have created an object type vrml_export (that contains 
the data for the VRML scene graph) and an object view using 
this type. The syntax of the SQL commands is given bellow: 
create type VRML_EXPORT as object (FID number (5), SEQF 
number (3), NID number (5), 
XC number(12), YC number (12), ZC number(12)); 
create view VRML of VRMLJEXPORT with object identifier (FID) 
as 
select FACE.FID, SEQF, NODE.NID, X, Y, Z 
from FACE, NODE, PHED 
where PHED.FIDB=FACE.FID and FACE.NIDF=NODE.NID 
ordered by FID, SEQF 
5.3 Object-relational implementation 
A step further is the object-relational implementation. While the 
object-oriented views provide a mechanism to encompass data 
from relational tables in an object, the object-relational 
implementation allows an object to be stored in a relational 
table. There are basically two approaches, i.e. an object can be 
stored in a row or in a column. The retrieval of the object then is 
based on referencing to only one row or column. The row 
objects are stored in an object table that practically is very 
similar to the relational table but allows an additional object 
identifier column and index. The object identifier is automatically 
generated and indexed for efficient lookups. The row 
representation of objects is not explored yet. 
Our 3D topological model make use of the column 
representation. The data of an object of lower dimension (used 
to describe the higher dimensional object) is stored in a single 
column. This means that the number of rows in the object table 
will be reduced to the actual number of the higher dimensional 
object. The advantage is compact representation and hence a 
reduction of the number of rows to be traversed. 
Object-oriented implementation is a two-step procedure, i.e. 
creating objects and creating tables. We use two extended 
Oracle data types that are intended for representing the one-to- 
many relationship, i.e. varrays and nested tables. While varrays 
are recommended for objects which elements are always 
retrieved in their completeness, nested tables are said to be 
suitable for cases that require accessing and retrieving individual 
elements of an object. According to Oracle manuals, the better 
performance is the major advantage of varrays compare to 
nested tables. Although most of the operations (i.e. retrieval of 
geometry and spatial relationships) can be classified as retrieval 
of objects with their complete set of elements, we utilised both 
data types. The syntax of the commands is given bellow: 
Varrays: 
create type NodeArray AS varray (30) OF number (5); 
Nested tables: 
create type NodeTable AS table OF number(5); 
Utilising the newly created data types NodeArray and 
NodeTable, the FACE object can be stored in the database in 
two ways as follows: 
FACE_A ({FID, NUM, NLISTA}, {FID}), where NLISTA is of data 
type NodeArray 
FACE_T ({FID, NUM, NLISTT), {FID}), where NLISTT is of data 
type NodeTable 
Note that a second column (giving the actual number of nodes 
per face) is introduced in both tables. Similar tables are created 
for LINE, SURFACE and POLYHEDRON, e.g. the tables using 
varrays are given bellow: 
LINE_A ({LID, NUM, NLISTA}, {LID}) 
SURF_A ({SID, NUM, NLISTA}, {SID}) 
PHED_A({BID,NUM,NLISTA},{BID}) 
5.4 Using the spatial data types of Oracle 
Currently Oracle Spatial has implemented only the geometry 
object model as it is specified in Open GIS specifications. This 
means that all the supported shapes (i.e. geometric objects in 
Oracle Spatial) are represented by their co-ordinates. 
Consequently, if two objects share co-ordinates, they are stored 
two times in the database. The topological operations are then 
explicitly computed when it is necessary. Furthermore the 
implemented topological operations are limited to cases in 2D 
space. Hence, the utilisation of the spatial objects for our model 
is rather limited. The only straightforward possibility is to 
represent NODE object by the Oracle shape SDO_POINT. The 
description of the shape SDO_POINT and NODE are identical. 
The advantages and disadvantages of such representation are 
to be further explored. 
6 OPERATORS TO RETRIEVE THE GEOMETRY 
The model presented in the previous sections does not have a 
direct link to the geometry of the objects, i.e. the co-ordinates of 
objects have to be derived. The operators to convert topology to 
geometry depend on the geometric model and the implemented 
mapping. It is possible to utilise the geometric model for spatial 
objects defined in OpenGIS specification. However, within the 
UbiCom project there is an agreement on adopting the 
geometric model of VRML. This model (known also as a scene 
graph) preserves the topology of each individual object or group 
of objects. In this respect, the operators to create a VRML file 
can be considered as operators for transformation from one 
topological data structure to another and therefore they are more 
sophisticated. For example, the SQL queries to retrieve the 
geometry (co-ordinates) of a POLYHEDRON with identifier 23 
from relational and object-relational (varrays) mappings are: 
Relational: 
select FID, SEQF, NID, X, Y, Z 
from FACE, NODE, PHED 
where PHED=23 and PHED.FIDB=FACE.FID and 
FACE.NIDF=NODE.NID 
ordered by FID, SEQF 
Varrays (part of a PL/SQL script): 
inid arra:= arra(0); 
jj number (5); 
t1 number(5); 
t2 number(5); 
begin 
select NUM, NLIST into t1, inid from FACE_A 
where FID-23; 
jj:=1; 
while jj< t1 loop 
select NID into t2 from NODE 
where inid(jj) = nid; 
jj:=jj+1; 
end loop;