26

Relational databases and beyond

M F WORBOYS

This chapter introduces the database perspective on geospatial information handling. It

begins by summarising the major challenges for database technology. In particular, it notes
the need for data models of sufficient complexity, appropriate and flexible human-database
interfaces, and satisfactory response times. The most prevalent current database paradigm,
the relational model, is introduced and its ability to handle spatial data is considered. The
object-oriented approach is described, along with the fusion of relational and object-
oriented ideas. The applications of object-oriented constructs to GIS are considered. The
chapter concludes with two recent challenges for database technology in this field:
uncertainty and spatio-temporal data handling.

1 INTRODUCTION TO DATABASE SYSTEMS variation in their requirements. Data should be

retrieved as effectively as possible. It should be
1.1 The database approach possible for users to link pieces of information
Database systems provide the engines for GIS. In the together in the database to get the benefit of the
database approach, the computer acts as a facilitator added value from making the connections. Many
of data storage and sharing. It also allows the data users may wish to use the store, maybe even the
to be modified and analysed while in the store. For a same data, at the same time and this needs to be
computer system to be an effective data store, it controlled. Data stores may need to be linked to
must have the confidence of its users. Data owners other stores for access to pieces of information not
and depositors must have confidence that the data in their local holdings.
will not be used in unauthorised ways, and that the
system has fail-safe mechanisms to cope with 1.2 Database history
unforeseen events. Both data depositors and data
users must be assured that, as far as possible, the Database management systems have grown out of file
data are correct. There should be sufficient flexibility management systems that perform basic file handling
to give different classes of users different types of operations such as sorting, merging, and report
access to the store. Most users will not be concerned generation. During the 1950s, as files grew to have
with how the database works and should not be increasingly complex structures, an assortment of
exposed to low-level database mechanisms. Data data definition products came into use. These became
retrievers need flexible methods for establishing what standardised by the Conference on Data Systems and
is in the store and for retrieving data according to Languages (CODASYL) in 1960 into the Common
their requirements and skills. Users may have Business-Oriented Language, that is the COBOL
different conceptions of the organisation of the data programming language, which separates the definition
in the store. The database interface should be on file structure from file manipulation. In 1969, the
sufficiently flexible to respond equally well to both DataBase Task Group (DBTG) of CODASYL gave
single-time users with unpredictable and varied definitions for data description and definition
requirements, and to regular users with little languages, thus paving the way for hierarchal and

373
M F Worboys

network database management systems. The example the relational model, and data models whose
underlying model for these systems is navigational, primary roles are to represent the meaning of the
that is connections between records are made by application domains as closely as possible (so-called
navigating explicit relationships between them. These semantic data models, of which entity-relationship
relationships were ‘hard-wired’ into the database, thus modelling is an example: see also Martin, Chapter 6;
limiting the degree to which such databases could be Raper, Chapter 5). It might be that a semantic data
extended or distributed to other groups of users. model is used to develop applications for a database
The acknowledged founder of relational database system designed around another model: the
technology is Ted Codd, who in a pioneering paper prototypical example of this is the use of the entity-
(Codd 1970) set out the framework of the relational relationship model to develop relational database
model. The 1970s saw the advent of relatively easy- applications. The three currently most important data
to-use relational database languages such as the modelling approaches are record-based, object-based
Structured Query Language, SQL, originally called and object-relational.
the Structured English Query Language, SEQUEL
(Chamberlin and Boyce 1974) and Query Language, 1.4 Human database interaction
QUEL (Held et al 1975), as well as prototype
relational systems such as IBM’s System R Humans need to interact with database systems to
(Astrahan et al 1976) and University of California at perform the following broad types of task:
Berkeley’s Interactive Graphics and Retrieval 1 Data definition: description of the conceptual and
Systems, INGRES (Stonebraker et al 1976). logical organisation of the database, the database
From the latter part of the 1970s, shortcomings schema;
of the relational model began to become apparent 2 Storage definition: description of the physical
for particular applications, including GIS. Codd structure of the database, for example file
himself provided extensions to incorporate more location and indexing methods;
semantics (Codd 1979). Object-oriented notions 3 Database administration: daily operation of the
were introduced from programming languages into database;
databases, culminating in prototype object-oriented 4 Data manipulation: insertion, modification,
database systems, such as O2 (Deux 1990) and retrieval, and deletion of data from the database.
ORION (Kim et al 1990). Today, object-oriented
systems are well established in the marketplace, as The first three of these tasks are most likely to be
are object-oriented extensions of relational systems, performed by the database professional, while the
which may be where the future really is. Early fourth will be required by a variety of user types
developments in object-relational systems are possessing a range of skills and experience as well as
described in Haas et al (1990) and Stonebraker variable needs requirements in terms of frequency
(1986). SQL has developed into the international and flexibility of access.
standard SQL-92, and SQL3 is being developed. User interfaces are designed to be flexible enough
to handle this variety of usage. Standard methods for
making interfaces more natural to users include
1.3 Data models menus, forms, and graphics (windows, icons, mice: see
The data model provides a collection of constructs Egenhofer and Kuhn, Chapter 28; Martin 1996).
for describing and structuring applications in the Natural language would be an appropriate means of
database. Its purpose is to provide a common communication between human and database, but
computationally meaningful medium for use by successful interfaces based on natural language have
system developers and users. For developers, the not yet been achieved. For spatial data, the graphical
data model provides a means to represent the user interface (GUI) is of course highly appropriate.
application domain in terms that may be translated Specialised query languages for database interaction
into a design and implementation of the system. For have been devised.
the users, it provides a description of the structure of
the system, independent of specific items of data or 1.5 Database management
details of the particular implementation.
A clear distinction should be made between data The software system driving a database is called the
models upon which database systems are built, for database management system (DBMS). Figure 1

374
 Relational databases and beyond

shows schematically the place of some of these The logical atom of interaction with a database is
components in the processing of an interactive query, the transaction, broadly classified as create, modify
or an application program that contains within the (update), and delete. Transactions are either executed
host general-purpose programming language some in their entirety (committed) or not at all (rollback
database access commands. The DBMS has a query to previous commit). The sequence of operations
compiler that will parse and analyse a query and, if contained in transactions is maintained in a system
all is correct, generate execution code that is passed to log or journal, hence the ability of the DBMS to
the runtime database processor. Along the way, the roll back. When a ‘commit’ is reached, all changes
compiler may call the query optimiser to optimise the since the last commit point are then made
code so that performance on the retrieval is permanent in the database. Thus, a transaction may
improved. If the database language expression had be thought of as a unit of recovery. The DBMS
been embedded in a general-purpose computer seeks to maintain the so-called ACID properties of
language such as C++, then an earlier precompiler transactions: Atomicity (all-or-nothing),
stage would be needed. To retrieve the required data Consistency (of the database), Isolation (having no
from the database, mappings must be made between side-effects and unforeseen effects on other
the high-level objects in the query language statement concurrent transactions), and Durability (ability to
and the physical location of the data on the storage survive even after system crash).
device. These mappings are made using the system
catalogue. Access to DBMS data is handled by the
stored data manager, which calls the operating system 2 RECORD-BASED DATA MODELS:
for control of physical access to storage devices. RELATIONAL DATABASES
2.1 Introduction to the relational model
Interactive Application A record-based model structures the database as a
query program collection of files of fixed-format records. The
records in a file are all of the same record type,
Host containing a fixed set of fields (attributes). The early
Precompiler language
network and hierarchical database systems,
compiler
mentioned earlier, conform to the record-based data
model. However, they proved to be too closely linked
Query to physical implementation details, and they have
compiler been largely superseded by the relational model.
A relational database is a collection of tabular
relations, each having a set of attributes. The data in a
Run-time relation are structured as a set of rows. A row, or
database System
tuple, consists of a list of values, one for each
processor catalogue
attribute. An attribute has associated with it a
domain, from which its values are drawn. Most
Stored current systems require that values are atomic – for
data example they cannot be decomposed as lists of
manager further values – so a single cell in a relation cannot
Concurrency contain a set, list or array of values. This limits the
control/backup/ possibilities of the pure relational model for GIS.
recovery units A distinction is made between a relation schema,
which does not include the data but gives the
structure of the relation (its attributes, their
corresponding domains, and any constraints on the
Stored data data) and a relation, which includes the data. The
relation schema is usually declared when the
Fig 1. DBMS components used to process user queries. database is set up and then remains relatively

375
M F Worboys

Table 1 Tuples from the Country relation. Table 3 Tuples from the Country relation after a project operation.

Name Population Land area Capital Name Population

(millions) (thousand sq. miles) (millions)

Austria 8 32 Vienna Austria 8

Germany 81 138 Berlin Germany 81
Italy 58 116 Rome Italy 58
France 58 210 Paris France 58
Switzerland 7 16 Bern Switzerland 7

Table 2 Tuples from the City relation. Table 4 Tuples from the City relation after a restrict operation.

Name Country Population Name Country Population

(thousands) (thousands)

Vienna Austria 1500 Berlin Germany 3400

Berlin Germany 3400 Rome Italy 2800
Hamburg Germany 1600 Paris France 2100
Rome Italy 2800
Milan Italy 1400
Paris France 2100 Table 5 Tuples from the joined Country and City relations.
Zurich Switzerland 300
Bern Switzerland 100 Name Country Land area Capital Country City
population (thousand sq. city population
(millions) miles) (thousands)

unaltered during the lifespan of the system. A Austria 8 32 Vienna Austria 1500
relation, however, will typically be changing Germany 81 138 Berlin Germany 3400
frequently as data are inserted, modified and Italy 58 116 Rome Italy 2800
deleted. A database schema is a set of relation France 58 210 Paris France 2100
schemata and a relational database is a set of Switzerland 7 16 Bern Switzerland 100

relations, possibly with some constraints. An

example of a database schema, used throughout this
chapter, comprises two relations Country and City, relation projected onto its Name and Population
along with their attributes, as shown: attributes. The restrict operation acts on a relation to
Country (Name, Population, Land Area, Capital) return only those tuples that satisfy a given
City (Name, Country, Population). condition. For example, Table 4 shows a restriction
Tables 1 and 2 show part of an example database of the City relation, retrieving from the City relation
according to this schema. Each row of a relation in a those tuples containing cities with populations
relational database is sometimes called a tuple. greater than two million. The join operation makes
The primitive operations that can be supported connections between relations, taking two relations
by a relational database are the traditional set as operands, and returns a single relation. The
operations of union, intersection, and difference, relation shown in Table 5 is a join of the Country
along with the characteristically relational and City relations, matching tuples when they have
operations of project, restrict, join, and divide. The the same city names.
structure of these operations and the way that they
can be combined is provided by relational algebra, 2.2 Relational database interaction and SQL
essentially as defined by Codd (1970). The set
operations union, intersection, and difference work From the outset, there has been a collection of
on the relations as sets of tuples. The project specialised query languages for database interaction.
operation applies to a single relation and returns a For relational databases, the Structured or Standard
new relation that has a subset of attributes of the Query Language (SQL) is a de facto and de jure
original. For example, Table 3 shows the Country standard. SQL may either be used on its own as a

376
 Relational databases and beyond

means of direct interaction with the database, or restrict condition. Relational joins are effected by
may be embedded in a general-purpose allowing more than one relation (or even the same
programming language. The most recent SQL relation called twice with different names) in the
standard is SQL-92 (also called SQL2: ISO 1992 ). FROM clause. For example, to find names of
There is a large effort to move forward to SQL3. countries whose capitals have a population less than
two million people, use the expression:
2.2.1 Schema definition using SQL
The data definition language component of SQL SELECT Country.Name
FROM Country, City
allows the creation, alteration, and deletion of
WHERE Country.Capital = City. Name
relation schemata. It is usual that a relation schema
AND City. Population < 2000000
is altered only rarely once the database is
operational. A relation schema provides a set of In this case, the first part of the WHERE clause
attributes, each with its associated data domain. provides the join condition by specifying that tuples
SQL allows the definition of a domain by means of from the two tables are to be combined only when
a CREATE DOMAIN expression. the values of the attributes Capital in Country and
A relation schema is created by a CREATE Name in City are equal. Attributes are qualified by
TABLE command as a set of attributes, each prefixing the relation name in case of any ambiguity.
associated with a domain, with additional properties Most of the features of SQL have been omitted
relating to keys and integrity constraints. For from this very brief summary. The documentation
example, the relation schema City may be created by on the SQL2 standard is about 600 pages in length.
the command: The reader is referred to Date (1995) for a good
survey of the relational model and SQL2.
CREATE TABLE City
(Name PlaceName,
Country PlaceName, 2.3 Relational technology for geographical
Population Population, information
PRIMARY KEY (Name)
There are essentially two ways of managing spatial
This statement begins by naming the relation schema
data with relational technology: putting all the data
(called a table in SQL) as City. The attributes are
(spatial and non-spatial) in the relational database
then defined by giving each its name and associated
(integrated approach), or separating the spatial from
domain (assuming that we have already created
the non-spatial data (hybrid approach). The benefits
domains PlaceName and Population). The primary
of using an integrated architecture are considerable,
key, which serves to identify a tuple uniquely, is next
allowing a uniform treatment of all data by the
given as the attribute Name. There are also SQL
DBMS, and thus not consigning the spatial data to a
commands to alter a relation schema by changing
less sheltered existence outside the database, where
attributes or integrity constraints and to delete a
integrity, concurrency, and security may not be so
relation schema.
rigorously enforced. In theory, the integrated
approach is perfectly possible: for example,
2.2.2 Data manipulation using SQL
Roessel (1987) provides a relational model of
Having defined the schemata and inserted data into
configurations of nodes, arcs, and polygons.
the relations, the next step is to retrieve data. A
However, in practice the pure relational geospatial
simple example of SQL data retrieval resulting in the
model has not up to now been widely adopted
relation in Table 4 is:
because of unacceptable performance (Healey 1991).
SELECT * Essentially, problems arise because of:
FROM City
1 slow retrieval due to multiple joins required of
WHERE Population > 2000000
spatial data in relations;
The SELECT clause indicates the attribute to be 2 inappropriate indexes and access methods, which
retrieved from the City relation (* indicates all are provided primarily for 1-dimensional data
attributes), while the WHERE clause provides the types by general-purpose relational systems;

377
M F Worboys

3 lack of expressive power of SQL for spatial queries. Population

The first problem arises because spatial data are Land area Name
fundamentally complex – polygons being sequences
of chains, which are themselves sequences of points.
Country
The object-oriented and extended relational models
are much better able to handle such data types. With
regard to the second problem, extended relational

Capital of
models allow much more flexibility in declaring

has city
indexes for different types of data. For the third
problem, the limitations of SQL have been apparent
for some time in a number of fields (for example,
CAD/CAM, GIS, multimedia databases, office
City
information systems, and text databases). SQL3,
currently being developed as a standard, promises
much in this respect. Name Population

Fig 2. Example of an ERA diagram.

3 OBJECT-BASED DATA MODELS
further here.
3.1 Introduction and the entity–relationship–
attribute approach
3.2 The object-oriented approach
The primary components of an object-based model
are its objects or entities. The entity–relationship– 3.2.1 Objects, classes, encapsulation, and identity
attribute (ERA) model and the object-oriented For many application domains, including GIS, ERA
(OO) models are the two main object-based modelling has proved too limited and is being
modelling approaches. The ERA approach is superseded by the OO approach. The OO approach
attributed to Chen (1976) and has been a major is in use both as a method of semantic data
modelling tool for relational database systems for modelling and as a model of data handled by object-
about 20 years. In the ERA approach, an entity is a oriented programming and database management
semantic data modelling construct and is systems. From the database systems viewpoint, the
something (such as a country) that has an OO model adapts some of the constructs of object-
independent and uniquely identifiable existence in oriented programming languages to database
the application domain. Entities are describable by systems. The fundamental idea is that of
means of their attributes (for example, the name, encapsulation which places a wrapper around an
boundary, and population of a country). Entities identifiable collection of data and the code that
have explicit relationships with other entities. operates upon it to produce an object. The state of
Entities are grouped into entity types, where an object at any time is determined by the value of
entities of the same type have the same attribute the data items within its wrapper. These data items
and relationship structure. The structure of data in are referred to as instance variables, and the values
a database may be represented visually using an held within them are themselves objects. This is an
important distinction between objects (in the OO
ERA diagram. Figure 2 shows an ERA diagram
sense) and entities (in the ERA sense) which have a
representing the structure of these data in the
two-tier structure of entity and attribute.
example database schema in Tables 1 and 2. Entity
The American National Standards Institute
types are represented by rectangles with offshoot
(ANSI 1991) Object-Oriented Database Task Group
attributes and connecting edges showing
Final Technical Report describes an object as
relationships. The ERA approach is fully discussed
something ‘which plays a role with respect to a
by Bédard (Chapter 29), and so is not considered

378
 Relational databases and beyond

request for an operation. The request invokes the that object to execute a method in response. This
operation that defines some service to be performed.’ highly active environment is another feature that
The code associated with a collection of data in an distinguishes between OO and ERA, which is
object provides a set of methods that can be essentially a collection of passive data. An object has
performed upon it. As well as executing methods on both state, being the values of the instance variables
its own data, an object may as part of one of its within it, and behaviour, being the potential for
methods send a message to another object, causing acting upon objects (including itself). Objects with
the same types of instance variables and methods are
said to be in the same object class. Figure 3 shows
some instance variables and methods associated with
Country classes Country and Polygon and the manner in
Population: Integer
which the class Polygon is referenced as an instance
Name: String variable by the class Country. Figure 4 shows in
Capital city: City schematic form an object encapsulating state and
Extent: Polygon methods, receiving a message from another object

Update City: City → City

Insert City: → City
Delete City: City →
a ge
Mess
Messag
e
Polygon State Message

Boundary: Set (Segment) Methods

Area: Polygon → Real

Fig 3. Part of the class descriptions for Country and Polygon. Fig 4. State, methods, and messages of an object.

Fig 5. Messages between objects.

379
M F Worboys

and executing methods which result in two messages As an illustration of some of these constructs,
output. Figure 5 shows the interaction of several Figure 6 shows the object class Country (as an
objects in response to a message to one of them. abstract object class, represented as a triangle) with
With encapsulation, the internal workings of an three of its instance variables Name, Population,
object are transparent to users and other objects, and Area. Variables Name and Population reference
which can communicate with it only through a set of printable object class Character String (represented
predefined message types that the object can as an oval) and Area references abstract class
understand and handle. To take an example from the Polygon. The class Polygon has instance variable
real world, I usually do not care about the state of Boundary referencing an association of class
my car under the bonnet (internal state of object Segment (the association class shown in the figure as
class Car) provided that when I put my foot on the a star and circle). Each segment has a Begin and
accelerator (send message) the car’s speed increases End Point, and each Point has a Position which is an
(change in the internal state leading to a change in aggregation (shown as a cross and circle) of
the observable properties of the object). From the printable classes X-coordinate and Y-coordinate.
viewpoint external to the object, it is only its
observable properties that are usually of interest. 3.3 Object-oriented database management systems

3.2.2 Inheritance and composition of objects 3.3.1 Making OO persistent

Inheritance is an important system and semantic Object-Oriented Programming Languages (OOPLs)
modelling construct, and involves the creation of a such as C++ and Smalltalk provide the capabilities to
new object class by modifying an existing class. support the OO approach described above, including
Inheritance in an object-oriented setting allows the creation, maintenance, and deletion of objects,
inheritance of methods. Thus, Triangle and object classes, and inheritance hierarchies. Object-
Rectangle are subclasses of Polygon. The subclasses Oriented Database Management Systems (OODBMS)
inherit all the instance variables and methods from supplement these capabilities with database
the superclass as well as adding their own. In this functionality, including the ability to support:
example, Triangle and Rectangle may have 1 persistent objects, object classes, and inheritance
specialised methods, for example the algorithm hierarchies;
implementing the operation Area may be different 2 non-procedural query languages for object class
for Rectangle and Triangle, and each will be definition, object manipulation, and retrieval;
different from an Area algorithm for Polygon. This 3 efficient query handling, including query
phenomenon, where an operator with the same optimisation and access methods;
name has different implementations in different 4 appropriate transaction processing (ACID
classes, is called operator polymorphism. An example properties), concurrency support, recovery,
of an inheritance hierarchy of spatial object classes integrity, and security.
is given below (see Figure 8).
Object composition allows the modelling of There are essentially two choices for the developer
objects with complex internal structures. There are of an OODBM system: extend a relational system to
several ways in which a collection of objects might handle OO, or build a database system around an
be composed into a new object. Aggregation OO programming language. Both choices have been
composes a collection of object classes into an tried, and section 3.4 on object-extensions to
aggregate class. For example, an object class relational technology explores the former. With
regard to the latter, object-oriented features will
Property might be an aggregate of object classes
already be supported by the OOPL, so there is the
Land Parcel and Dwelling. To quote Rumbaugh et
need to add persistency, query handling, and
al (1991), ‘an aggregate object is semantically an
transaction processing. An approach to persistency
extended object that is treated as a unit in many
is to add a new class Persistent Object and allow all
operations, although physically is made up of several
database classes to inherit from this class. The class
lesser objects’. Association groups objects all from
Persistent Object will include methods to:
the same class into an associated class. For example,
an object class Districts might be an association of 1 create a new persistent object;
individual district object classes. 2 delete a persistent object;

380
 Relational databases and beyond

dary
Boun

Area
Polygon

Country

Segment
Population
Name

Begi n

End
Character string
Point

io

n
Posit

X-coordinate Y-coordinate

Fig 6. Complex objects.

3 retrieve the state of a persistent object; 3.3.2 Standardisation of OO systems

4 provide concurrency control; The OO approach is more complex than the
5 modify a persistent object. relational model and has not yet crystallised into a
A key benefit of an OODBMS is the support it set of universally agreed constructs; even basic
provides for a unified programming and database constructs like inheritance have been given
environment. However, most current OODBMS several different interpretations. Nevertheless, there
treat persistent and non-persistent data differently. A has been considerable work to arrive at some
fundamental distinction between RDBs and OODBs common definitions.
is that between call-by-value and call-by-reference. The Object Management Group (OMG) is a
In an RDB, relationships are established by value
consortium of hardware and software vendors,
matching. In our example, to retrieve the population
founded in 1990 with the aim of fostering standards
of the capital of Germany, a join between Country
and City is made using the value of the Capital field, for interoperability of applications within the OO
Berlin. In an OODB (see Figure 7), the connection is approach. To this end, it has defined the OMG
made by navigation using the object identifiers Object Model (see, for example, Kim 1995) many of
(OIDs). The Capital instance variable of Country the concepts of which have been discussed above. An
points to the appropriate City object. important component of the OMG work is the

381
M F Worboys

database functionality around an OO programming

language. Enhancements include complex, possibly
user-defined data types, inheritance, aggregation,
Country City and object identity. Early work at the University of
OID: 001 OID: 101 California at Berkeley on the inclusion of new data
Name: Austria Name: Vienna types in relational database systems (Stonebraker
Population: 8 Country: 001
1986) led to the POSTGRES DBMS (Stonebraker
Land Area: 32 Population: 1500
Capital: 101 and Rowe 1986). Parallel developments at the IBM
Research Laboratories at San Jose, California
resulted in the STARBURST project (reported in
Haas et al 1990). These developments have led to
contemporary proprietary object-relational systems
Country City as well as to the addition of object features to new
OID: 002 releases of widely used proprietary relational
OID: 102 systems. With regard to query languages that
Name: Gemany
Name: Berlin
Population: 32 support OO extensions to the relational model,
Country: 002
Land Area: 138 SQL3 is currently under development as an
Population: 3400
Capital: 102 international standard. SQL3 is upwardly
compatible with SQL-92, and adds support for
objects, including multiple inheritance and
operators. The goal for object-relational systems is
to provide the wide range of object-oriented
City functionality that has proved so useful for semantic
OID: 103 data modelling and programming systems, while at
Name: Hamburg the same time giving the efficient performance
Country: 002 associated with the relational model.
Population: 1600
Objects are structured by the relational model as
tuples of atomic values such as integers, floats,
Booleans, or character strings. This provides only a
Fig 7. Navigation using object identifiers. limited means to define complex data types.
Object-relational systems allow non-atomic types.
A common extension of the relational model to
Common Object Request Broker Architecture provide for complex data types is to allow nested
(CORBA) standard, which specifies an Interface relations. In a nested relation, values of attributes
Definition Language for distributed access to objects need not be atomic but may themselves be relations.
(see Sondheim et al, Chapter 24). The Object Relational database systems provide hashing and
Database Management Group (ODMG) is a B-tree indexes for access to standard, system-
consortium of OODBMS vendors, founded in 1990 provided data types. A major extension that an
with the aim of arriving at a commonly agreed OO object-relational system allows is the provision of
database interface. The ODMG has defined object more appropriate indexes for user-defined types.
definition, manipulation, and query languages, Object-relational systems provide for the definition
corresponding to data definition and manipulation of a range of indexes appropriate to a heterogeneous
languages in relational systems. collection of object classes.

3.4 Object extensions to relational technology 3.5 OOGIS

Object-relational models combine features of object- A basic requirement for any OO approach to GIS is a
based and record-based models. They enhance the collection of spatial object classes. Figure 8 uses the
standard relational model with some object-oriented notation of Rumbaugh et al (1991) to represent an
features, as opposed to OODBMS, that build inheritance hierarchy of some basic classes. Class
Spatial is the most general class, which is specialised

382
 Relational databases and beyond

into classes Point and Extent (sets of points). Spatial

Spatial
extents may be classified according to dimension, and
examples of classes in one dimension (Polyline) and
two dimensions (Polygon) are given. Class Polyline is
further specialised into classes Open Polyline and
Point Extent
Closed Polyline, the former having two distinct end-
points while the latter is joined and has no end-points.
Of course, this is just an example of some basic
spatial object classes. Table 6 shows some sample Polyline Polygon
methods that will act upon these classes. The name of
the method is given, along with the classes upon
which it acts and the class to which the result belongs.
The OO approach to geospatial data management Open Closed
is now well established. For some time there have Polyline Polyline
been innovatory proprietary GIS that provide OO
programming language support, including spatial
Fig 8. Spatial object class inheritance hierarchy.
object classes, overlaying flat-file, or relational
databases. There now exist proprietary GIS that
incorporate a full OODBMS. Papers that survey the 1 the relational model has not provided a
sufficiently rich set of semantic constructs to
Table 6 Inheritance hierarchy of spatial object classes. allow users to model naturally geospatial
application domains;
Method Operand Operand Result
2 relational technology has not delivered the
Equals? Spatial Spatial Boolean necessary performance levels for geospatial data
Belongs? Point Extent Boolean management.
Subset? Extent Extent Boolean
Intersection Extent Extent Extent This chapter has argued that the OO approach
Union Extent Extent Extent provides part of the solution to these difficulties.
Difference Extent Extent Extent It might be that the rapprochement between OO
Boundary Polygon ClosedPolyline and relational technologies offers the best possible
Connected? Extent Boolean way forward.
Extremes OpenPolyline Set(Point)
There are still significant challenges for the
Within? Point ClosedPolyline Boolean
database community in this area, and the chapter
Distance Point Point Real
Bearing Point Point Real concludes by mentioning two of them. First,
Length Polyline Real handling uncertain information has always played a
Area Polygon Real major part in GIS, because many phenomena in the
Centroid Polygon Point geographical world cannot be represented with total
precision and accuracy (Fisher, Chapter 13).
Reasoning with uncertain information and managing
the associated data in a database remains an
application of OO to GIS include Egenhofer and important research topic. Deductive databases
Frank (1992); Worboys (1994); Worboys et al (1990). incorporate logical formalisms, usually subsets of
first-order logic, into databases, thereby increasing the
expressive power of the query languages and allowing
4 CONCLUSIONS AND CHALLENGES richer semantics for the data models (see, for example,
Ceri et al 1990). There has also been work on the
The purpose of a database is to serve a user fusion of deductive and object technologies for GIS
community as a data store for a particular range of (Paton et al 1996).
applications. Regarding geospatial applications, Second, the world is in a continual state of
relational databases have fallen short of effectively change. Classical database technology provides only
achieving that purpose for two main reasons: the capability to manage a single, static snapshot of
the application domain. There are two ways in which

383
M F Worboys

this can be extended: temporal databases manage Engineering 2: 91–108

multiple snapshots (history) of the application Egenhofer M J, Frank A 1992 Object-oriented modeling for
domain as it evolves; and dynamic databases where a GIS. Journal of the Urban and Regional Information Systems
single snapshot changes in step with a rapidly and Association 4: 3–19
continuously changing application domain. There Haas L M, Chang W, Lohman G M, McPherson J, Wilms P F,
are many geospatial applications for both types of Lapis G, Lindsay B, Piransesh H, Carey M J, Shekita E 1990
extension. Temporal GIS are required to handle Starburst mid-flight: as the dust clears. IEEE Transactions on
such diverse applications as spatio-temporal patterns Knowledge and Data Engineering 2: 143–60
of land ownership and use, navigation, and global Healey R G 1991 Database management systems. In Maguire
environmental modelling (see Peuquet, Chapter 8). D J, Goodchild M F, Rhind D W (eds) Geographical
Dynamic systems are required to model such rapidly information systems: principles and applications. Harlow,
Longman/New York, John Wiley & Sons Inc. Vol. 1: 251–67
changing contexts as transportation networks.
Problems with development of such systems include Held G D, Stonebraker M R, Wong E 1975 INGRES: a
relational database system. Proceedings AFIPS 44, Montvale.
the enormous volumes of data required for temporal
AFIPS Press: 409–16
databases and real-time transaction processing
requirements in dynamic systems. These matters are ISO 1992 Database language SQL. Document ISO/IEC 9075.
International Organisation for Standardisation
covered in more detail by Bédard (Chapter 29).
Kim W (ed) 1995 Modern database systems: the object model,
interoperability, and beyond. New York, ACM Press
References Kim W, Garza J, Ballou N, Woelk D 1990 Architecture of the
ANSI 1991 Object-Oriented Database Task Group final report. ORION next-generation database system. IEEE
Transactions on Knowledge and Data Engineering 2: 109–25
X3/SPARC/DBSSG OODBTG. American National
Standards Institute Martin D J 1996 Geographic information systems:
socioeconomic applications, 2nd edition. London, Routledge
Astrahan M, Blasgen M, Chamberlin D, Eswaran K, Gray J,
Griffiths P, King W, Lorie R, McJones P, Mehl J, Putzolu G, Paton N, Abdelmoty A, Williams M 1996 Programming
Traiger I, Wade B, Watson V 1976 System R: a relational spatial databases: A deductive object-oriented approach. In
approach to database management. ACM Transactions on Parker D (ed.) Innovations in GIS 3. London, Taylor and
Database Systems 1: 97–137 Francis: 69–78
Ceri S, Gottlob G, Tanca L 1990 Logic programming and Roessel J W van 1987 Design of a spatial data structure using
databases. Berlin, Springer the relational normal forms. International Journal of
Geographic Information Systems 1: 33–50
Chamberlin D, Boyce R 1974 SEQUEL: a structured English
query language. Proceedings ACM SIGFIDET Workshop Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W
Conference, New York. ACM Press: 249–64 1991 Object-oriented modeling and design. Englewood Cliffs,
Prentice-Hall
Chen P P-S 1976 The entity–relationship model – toward a
unified view of data. ACM Transactions on Database Stonebraker M 1986 Inclusion of abstract data types and
Systems 1: 9–36 abstract indexes in a database system. Proceedings 1986
IEEE Data Engineering Conference, Los Alamitos. IEEE
Codd E 1970 A relational model for large shared data banks. Computer Society: 262–9
Communications of the ACM 13: 377–87
Stonebraker M, Rowe L 1986 The design of POSTGRES.
Codd E 1979 Extending the relational database model to ACM SIGMOD International Conference on Management of
capture more meaning. ACM Transactions on Database Data, New York. ACM Press: 340–55
Systems 4: 397–434
Stonebraker M, Wong E, Kreps P 1976 The design and
Date C J 1995 An introduction to database systems, 6th edition. implementation of INGRES. ACM Transactions on
Reading (USA), Addison-Wesley Database Systems 1: 189–222
Deux O 1990 The story of O2. Institute of Electrical and Worboys M F 1994b Object-oriented approaches to
Electronics Engineers Transactions on Knowledge and Data georeferenced information. International Journal of

384