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;
