CI PA 2003 XIX th International Symposium, 30 September - 04 October, 2003, Antalya, Turkey
43
Subsequently to this conceptual modelling process there
follows the system choice, in which the used computer systems
and programs are selected, for example the GIS or the database
system. The system choice depends on application and the
conceptual model.
For Implementation a logical model is developed from the
conceptual model considering the characteristics of the selected
computer programs and database system.
3.2.1 Conceptual model with UML
The current quasi-standard UML for the diagram of conceptual
data model was used to stay abreast of the object-oriented
extensions. UML stands for Unified Modelling Language and
offers different features during the object oriented design of
application. In the illustration in Figure 4 only class diagrams
have been used. Further possibilities of UML are e.g. use case
diagrams or features to represent dynamic aspects of object
behaviour (Booch et al, 1998).
UML class diagrams mainly consist of single classes with their
attributes and methods.
In Figure 4 a clearly simplified fragment from the UML class
diagram of the data model for a temporal GIS is shown. Here
was considered that an object of application can have thematic,
spatial as well as differentiated temporal characteristics.
Figure 4. Fragment of the UML class diagram
Several classes have relationships. For example there is a 1 to n
relationship between the classes DATA OBJECT and MAIN.
Aggregation and composition are special kinds of relationships.
The aggregation ( -o ) expresses only a “ is part of’ -
relationship. That means that an object can exists of other
objects, however without bringing in additional semantics
restricting the object.
The composition ( —) restricts the object and its com
ponents in such form that an individual component of the
object, which participates in this composition may not exist
alone.
3.2.2 Implementation in Oracle 8i
The data model was implemented into the object-relational
database management system Oracle 8i. Therefor in the
conceptual model it was already considered that no sufficient
means of inheritance have been available and so a hierarchical
structure was simulated by the use of the table MAIN as a super
object.
The class TIME offers the possibility to differentiate as well as
to combine points and periods of time with different accuracy.
For example the storage could be made as a snapshot or as a
development over larger periods.
The time was modelled in such way, that the limits of an
interval of time can be unknown or can determined as
intentionally open, e.g. if a development has not finished.
In addition different advanced thematic data has to be
provided in the several classes of DATA OBJECT, e.g. content
of the official monument list, which is associated to the object
or specialised information for certain target groups.
Vector geometries are stored in the data model on a data type
GEOMETRY, which is present in Oracle 8i in connection with
the spatial cartridge. With the help of this data type the
connection is made between the database model and a GIS. The
column ID stores, like the table MAIN, a generic ID, which
represents a simple possibility of accessing single spatial
objects without to produce complete spatial inquiries. This is
particularly helpful regarding the production of references in
the Nested Table TABLE(MAIN. GEOM_REF). The storage of
instances of the class SPATIOJTYP takes place in the object
table GEOMETRY. Especially newer GIS of the large
manufacturers in the geo information market enables the direct
access to the Oracle data type SDOjGEOMETRY for the
storage of spatial information in the database. Thereby it is also
ensured that the data model can be used in different GIS
systems.
4. REALISATION AND GIS-TECHNOLOGY
The structural differences between spatial and non-spatial
information led in the past to a separate data management. The
dual organisational structure was gradually given up in the last
decade in favour of an integrated data management.
In this context geo information systems have been developed,
which store spatial data not in the form of files but in databases.
The implementation of such information systems was realised
with special external database extensions, which are also known
as "GIS middleware".
This development has promoted and certainly initiated the
spreading of a new generation of database systems: Now
geographical database systems can be regarded as relational
database systems with object-oriented extensions and have
internal auxiliary modules for the access to georeferenced data.
Examples of these auxiliary modules are "Oracle Spatial", "IBM
Spatial Extender" and the "Informix Spatial DATA Blade".
These software products enable an integrated data management
of spatial and non-spatial data and offer uniform (however
usually manufacturer-specific) database interfaces - the supplied
possibilities offer thereby certain basic functionality for
complex geo information systems.
4.1 Architecture
The prototypic GIS solution at Techn. University of Munich is
based on an object-relational alphanumerical data model
implemented in the database system Oracle and the storage of
the spatial data with the spatial data engine (SDE) of ESRI.
For the input of the alphanumerical data and pictures an input
module was developed on the basis of Oracle Objects for OLE
(Visual basic). For inquiry and visualisation of historically
interesting geometric and alphanumerical data a platform
independent request module (see
Figure 5) on basis of Oracle Extensions for JDBC (Java) was
developed.
