Geo-DBMS Development

Although designed for non-spatial data, DBMS has been linked with spatial data.Initially GIS vendors used DBMS mainly to store thematic, i.e.non-spatial data.Few GIS vendors (e.g.ESRI) went the way to store both non-spatial and spatial data into DBMS.Such solutions can be referred to as 'top-down' approaches, because from an architectural point of view, the DBMS functionality has been constructed 'under' the GIS application and the GIS application accesses 'top-down' to the geodata stored in the DBMS.

The second way and more interesting development within DBMS was the support of spatial data types.This solution is called a 'bottom-up approach,' because it extends 'low level' DBMS data types and indexes to use them in the upper level of GIS applications.Data analysis on the spatial and non-spatial parts of objects can be executed.Since the nineties more and more commercial DBMSs provide such spatial extensions to offer support of spatial objects.

Geo-DBMSs provide spatial data types and spatial functions (and operations) on them that define the spatial functionality of a Geo-DBMS.A Geo-DBMS knows primitive and composed geometric data types in the same way as its primitive standard data types such as character, string, integer, real etc. A Geo-DBMS is a 3D Geo-DBMS if it:
Supports 3D data types, i.e.point, line, surface and volume in 3D Euclidean space based on 3D (topological or geometrical) models.
Offers 3D spatial functionality, i.e.spatial operations and functions embedded in its query language that can operate with the 3D data types.
Geometry and topology are often used in Geo-DBMS terminology (in contrast to OpenGIS specifications) as synonyms to denote the two ways of describing spatial data types.Geometry data types are described by the x,y,z coordinates of the points composing a data type.Topology data types have references to the unique identifiers of low-dimensional objects.

Although there is a belief that a topological model might be sufficient (geometry can be derived from topology), in the same way one could argue that the same is true for a geometry model, because topology can be derived from geometry.In this respect, one can choose between three different options.
Storing the topological model in the 3D Geo-DBMS (and deriving geometry from it)
Storing the geometric model in the 3D Geo-DBMS (and deriving topology from it)
Storing both models in the 3D Geo-DBMS
In the first approach the topological relationships between object parts, such as 'all surfaces belonging to the boundary of a 3D volume object' are stored in a topology model.The location of objects, i.e. the x,y,z coordinates of its defining points, are not part of the topology model.This approach can quickly identify topological properties, e.g. 'find neighboring walls,' but it is inefficient in queries needing coordinates, e.g. 'visualize the object'.

The second approach prevents the disadvantage of the first approach.However, topological queries have higher computational complexity.

The third approach seems to be the best solution: it allows flexible topological and geometric database queries executed efficiently by accessing the topology and geometry model in the Geo-DBMS.With these two models all relevant types of spatial database queries can be executed:
topological database queries (neighborhoods etc.),
metric database queries (distances),
geometric database queries (e.g.spatial search inside a 3D box).