by Peter M. Batty
Abstract
Data modelling for AM/FM is more complex than for traditional applications for
a variety of reasons, in particular because of the need to model spatial and topological
relationships. This paper examines the general differences between data modelling
for AM/FM and other applications, and looks at a range of common modelling issues
in utility applications, including the efficient handling of various types of tracing
and network analysis, outage management, and generation and maintenance of schematics.
Introduction
There are some significant differences between data modelling for traditional
applications and GIS or AM/FM, which arise from the need to model spatial and topological
relationships. Utility applications have some additional complications compared
to many GIS applications, due to the need to model complex networks, and these
complications are not well handled by traditional GIS data models (the term GIS
data model is used in two different contexts in this paper: one is the system data
model used by the GIS vendor to model spatial and topological aspects of data stored
in the system, and the other is the user-specific data model developed on top of
the core system for a specific application).
This paper starts by discussing the general differences between data modelling
for GIS and other applications, from a user application perspective. It goes on
to look at a variety of modelling issues relevant to utility applications, primarily
from a system data model point of view. In particular a number of non-traditional
modelling techniques which offer benefits for utility applications are examined.
A more detailed look is then taken at a fairly complex application which is common
to most utilities, outage management, considering how the system data model features
which have been discussed can be applied in practice, and what sort of trade-offs
need to be considered in the design. Finally, the creation and maintenance of the
user-specific data model is discussed, and in particular the use of CASE tools
is examined.
Why Is GIS Data Modelling Different?
A traditional data modelling exercise goes through two major stages: the production
of a logical model, and then a physical model. The logical model represents a model
of the real world and is completely independent of how the system is physically
implemented. The physical model represents the actual data structures (typically
tables) which are used to implement the logical model. By far the most common way
of representing a data model is using some form of entity-relationship diagram
in which the objects (or entities) which need to be modelled are displayed as boxes,
and the relationships between them are represented by lines.
Dangers in Trying to Represent Spatial Relationships
A data model for a traditional application explicitly records all relationships
between entities which may be of interest to the application. This provides a big
trap for the unwary person producing a GIS logical data model, because in a typical
GIS application there are many relationships which will be derived implicitly from
the spatial characteristics of objects. For example, in a utility application you
might want to know which facilities are in a given work area, which are in a given
tax area, which cables are underneath roads, and so on. In a traditional logical
model this would result in defining relationships between work area and all facilities,
between tax area and all facilities, between cable and road, and so on. It is possible
to very quickly end up with a logical model in which almost everything is related
to everything, like the following:
[ Figure not available ]
It should be fairly obvious that this is not a very helpful model, although the
author has seen a number of logical models like this. The second variant of the
not terribly useful logical model is the following, which again the author has
seen in real situations:
[ Figure not available ]
In this case the designer has realised that the previous logical model is not
useful, and has tried to show that objects are related by their location. While
this model represents a little better what we are trying to model, it is still
not very helpful. Firstly, objects are in the majority of cases not related because
they have exactly the same location, but because their locations have some more
complex relationship between them, such as one crosses the other, one is inside
the other, or one is within 100 feet of the other. This could in theory be modelled
by defining suitable relationships between locations, but in practice it is totally
impractical to maintain explicit relationships between all locations. Secondly,
since all objects are shown as having a relationship to location on this diagram,
this again clutters things up (if non-spatial relationships were also shown on
this diagram it would be very confusing). If we understand that any object may
have a spatial component to it, and that through this it can be related to any
other object with a spatial component, then it is generally clearer not to try
to show this on our logical model.
Although the previous two models were somewhat simplified examples, as a general
rule it makes sense to omit spatial relationships from a logical model. This is
not an absolute rule though. In particular there are some relationships which could
be derived spatially but which could also be regarded as more explicit. A common
example is a hierarchical aggregation of areas. For example, in a utility there
is usually a hierarchy of organiz- ational areas, such as local office areas, which
are aggregated into districts, which are aggregated into regions (use of the terms
district, division and region, and their position in the hierarchy, seems to vary
from one utility to another). Since a district is always the aggregation of a number
of local office areas, this is quite a strong relationship and it may be useful
to show this on the logical model (whether this relationship is modelled explicitly
in the GIS is a separate implementation decision which will be discussed later).
Representation of Topological Relationships
Similar issues apply to the representation of topo-logical relationships: which
objects can be connected to which other objects? As with spatial relation-ships,
topological relationships can be quite exten-sive, especially in a utility application,
and show-ing them explicitly may clutter up the data model diagram. However, there
is a better case for explicitly showing topological relationships than spatial
relationships. The main one is that in a utility application there are usually
definite rules which are associated with topological relationships, for example
a cable can be connected to a trans-former but not to a gas main. This is not generally
the case with spatial relationships, for example you would typically not prohibit
a cable from crossing a gas main (there may be some such spatial constraints, but
they are normally far fewer, and too complex to represent on a data model diagram).
It is very important to make sure that topol-ogical relationships (or connectivity
rules) are documented in some form, but this does not necessarily need to be done
by showing them on the data model diagram. There are various other options, such
as creating a separate entity-relationship type diagram just showing topol-ogical
relationships, using a matrix or table to show which pairs of objects can be connected,
or just listing the valid connections for an object with the rest of the documentation
about that object.
A diagrammatic or tabular representation of connectivity rules can generally only
convey high level information about the rules. Rules can be quite complex, so it
is often necessary to include some additional description in addition to a diagram.
For example, a rule might be that it is only valid to connect two primary electrical
conductors if the phases of one are a subset of the other – so a cable with phase
BC could be connected to a cable with phase B, but not to a cable with phase AB.
Another rule might be that it is not possible to connect two gas mains with different
diameters unless they have a suitable fitting in between them.
Some people might debate whether defining these sort of complex rules is part
of the data model or part of the application. There is a strong argu-ment for including
these as part of the data model, since enforcing them is fundamental to the integrity
of the database. Also, when using an object-oriented approach to design and development,
which is widely recognized as being of benefit in complex applications like GIS,
the behaviour of an object is an important part of its definition and when taking
this approach, connectivity rules should definitely be regarded as part of the
data model.
In summary, it is difficult to give a hard and fast rule for how to document connectivity
rules. In many cases it may be appropriate to display the high level rules on the
data model diagram (ignoring complex constraints), if this can be done without
detracting from the clarity of the diagram. Whether this is practical depends on
the number of topological relationships and the number of explicit relationships
which need to be shown on the diagram. In any case, it is likely that addit-ional
documentation will be required for each object to explain more complex aspects
of the rules.
Constraints Imposed by the System Data Model
We have already mentioned that we are really discussing two separate types of
data model in this paper: the application-specific or user data model, which has
been the main topic of discussion so far, and the system data model which is provided
by the GIS vendor.
It is the system data model which handles fundamental issues such as how spatial
data and topological relationships are modelled. When implementing a GIS, you typically
cannot change the system data model. This puts constraints on the way that you
do data modelling, which at times may hinder you but at other times (hopefully
most of the time!) should help you. It helps you because the GIS vendor has implemented
a model and functionality which handles the most complex fundamental aspects of
the system. It also gives you a frame of reference in which to think about how
to specify spatial and topological relationships, which as we have seen already
can be difficult to do if you start with a blank sheet of paper. For example, most
systems use some variant on the traditional GIS model in which an object can be
a point, line or area. As you define the objects in your data model, you categorise
each one as a point, line or area, which makes the modelling process much simpler
than if you did not have this framework to work within.
However, while this simplification generally helps you, there is a danger that
the system data model may not be sufficiently rich to handle the complexity of
what you want to model. The experience of this author is that the traditional point-line-area
model has a number of shortcomings, especially for modelling utility networks.
The next section of this paper looks at various aspects of the system data model,
and in particular looks at some examples of non-traditional modelling approaches
which offer benefits for utility applications.
System Data Model Issues
This section considers various aspects of the system data model provided by the
GIS vendor which are important in being able to model utility networks effectively.
Sheet-based Versus Continuous Models
At a fundamental level, it is very important that the database is seamless, so
that an object like a cable is always stored as a single object regardless of how
long it is, and it does not have to be split into mul-tiple objects because it
crosses arbitrary map sheet or tile boundaries. This significantly simplifies application
development and data maintenance.
Most systems now provide this capability at a basic level. However, it is important
to consider how you can access these objects as a user or application developer.
Because of the very large data volumes in typical GIS databases, most systems only
allow you to work on a subset of the database at one time for analysis or update
purposes. Being able to access the whole database at once without constraints offers
significant advantages for many applications, such as network analysis and outage
management.
Providing this seamless access to a database which may be tens or even hundreds
of gigabytes in size, and obtaining good performance, is obviously not a simple
task. There are two key issues in achieving this. The first is a good spatial indexing
mechanism. The most common approach is to use some form of quadtree index. There
is extensive literature on this topic – for example see Samet, 1990. The second
key issue is the under-lying DBMS architecture. The server-oriented archi-tecture
used by standard commercial DBMSs like Oracle, Ingres and Sybase is fundamentally
unsuitable for providing the required performance in a networked environment with
many users. A client-oriented DBMS architecture can provide an order of magnitude
better performance for this sort of application. This DBMS architecture is actually
far more important in achieving good performance in multi-user networked environments
than the spatial indexing mechanism used, but it has recei-ved far less attention
in the literature. See Newell and Batty, 1993, for more details on this topic.
In summary, the important things to look for in a system data model in this area
are that it is seam-less, that it allows unconstrained access to the whole database
for update or analysis, and that it delivers good performance in a production environment.
Spatial Object Versus Spatial Attribute Model
As we mentioned earlier, most system data models are based on some variant of
the point-line-area model, in which each object belongs to one of these categories.
Some systems have extended this model, for example by adding a “control point
feature” which is like a point, but has two connection nodes. This is suitable
for modelling certain electrical objects like transformers and simple switches.
However, the basic approach is still that each object has a (single) spatial type.
Each object will then have a number of alpha-numeric attributes defined for it
(size, material, equipment number, etc.).
A much more flexible model, especially for utility applications, can be obtained
by looking at the spatial aspects of an object in a different way. Instead of insisting
that an object has a single spatial type, we can allow an object to have multiple
spatial attributes, each of which has a spatial type such as point, line or area.
This simple step of moving spatial information from an object level to an attribute
level gives lots of new modelling possibilities. We will look at some examples
to illustrate this.
Depending on the application, you may wish to regard a road either as a line or
as an area. If doing some kind of route analysis, you will be interested in tracing
along its centreline. If looking at access to properties along the road, you will
be interested in the right of way area associated with the road. With the traditional
spatial object model you would need to model these two things as separate objects,
and typically you would need to write some specific code to create and maintain
the relationship between these two objects. With the spatial attribute model, you
can simply give the road two spatial attributes, a centerline which is linear,
and a right of way which is an area.
A very common requirement in utility applicat-ions is to be able to display an
object at a location which is offset from the location where it really exists.
For example, many electric utilities display transformers offset from the cable
to which they are attached. This can be very simply handled by the spatial attribute
model: one spatial attribute can be used to store the actual location, and another
spatial attribute can store the location where its picture is to be displayed.
This applies to many situations, for example where multiple conductors are running
through the same duct, and you may want to dis-play each conductor offset by a
different amount.
Another area in which the spatial attribute model greatly simplifies modelling
is in the hand-ling of multiple representations of the same object. It is particularly
common in utility applications for the same object to appear on multiple different
types of map, including various schematics. Again this can be handled simply by
defining multiple spatial attributes on an object: one which repres-ents the actual
location, and additional ones which represent the position of the object in each
type of schematic representation. There are additional modelling techniques which
can be useful in handling schematics, such as the use of multiple worlds: we will
return to this subject later.
Basic Network Topology Modelling
The way in which network topology is modelled is obviously of fundamental importance
to utility applications. With the traditional model, a linear object typically
has two nodes, one at each end. Connected objects are defined as those sharing
a node, so other objects can only be connected to the end of a linear object. If
an new service line needs to be connected in the middle of a cable, for example,
the cable must be split into two separate cables to model the connectivity correctly.
This can lead to having to split something which is really a single object into
many different objects, typically replicating the attributes on every instance,
which causes problems in terms of data storage, data maintenance and performance.
The following diagram shows the sort of situation we are talking about:
[ Figure (drawing) not available ]
These issues can be overcome by using a two level linear network model. With this
approach, every high level linear object – we call this a chain – is made up of
one or more (continuous) low level linear objects – we call these links. In the
above drawing, the main (secondary) cable geometry would be a single chain consisting
of nine links, and each service cable geometry would be a chain with just a single
link. The links define the connectivity, but the chains are the spatial attributes
associated with an object – so we can just have a single secondary cable object
with one set of attributes, rather than having to create nine secondary cable objects.
This approach obviously allows points to be connected in the middle of a chain
too, for example a single primary conductor could have many transformer connection
points along its length.
Modelling Complex Network Topology
Tracing through a linear network is a fundamental requirement for many utility
applications. Common requirements for controlling a trace include stopp-ing at
specified objects, possibly qualified by attribute, for example stopping at all
open valves or switches. Another important requirement for electrical networks
in particular is being able to do directional tracing – upstream or downstream.
For simple networks, these requirements can be met by the traditional linear network
model consisting of links and nodes, where a link runs between two nodes, and two
links are connected if they share a common node. However, utility networks often
include objects whose connectivity cannot be easily modelled using this simple
model, in particular various types of switching or control facilities. For example,
consider the following diagram of a transfer switch:
[ Figure (diagram) not available ]
This switch has three connections, one input and two outputs. The switch can be
in one of two positions. In position 1, shown in the drawing, current from the
input goes out on output 1, and in position 2 it goes out on output 2.
There are several things which can help us produce an elegant solution to the
problem of modelling these complex objects. The first is the spatial attribute
model: we could model our transfer switch with three point geometries (spatial
attributes), to represent the input connection and the two output connections.
The second is that we need some way of defining the behaviour of this object within
a trace – the trace needs to know that if it reaches the input connection point,
then if the position attribute of the transfer switch is equal to “Position
1” then it should continue tracing from the output 1 connection point, and
otherwise it should continue tracing from the output 2 connection point.
This is a situation where object-oriented programming is very useful. With conventional
procedural programming, we would need to modify our tracing code each time we wanted
to handle a special case object like this, which makes it impossible to create
a general purpose trace routine, and causes support and maintenance problems. In
an object-oriented system, we define the trace behaviour on each object, so that
the general trace code does not need to be modified and new object behaviour can
be introduced very easily. For example, our trace code could be set up to check
whether any object it hit had a special method defined called trace_outputs, and
if it did then it would call this method to get a list of nodes from which it continue
the trace (a method is similar to a function in a procedural programming language
– see Batty, 1993, for more information on object-oriented programming in GIS).
The following is an example of what this method would look like for the transfer
switch:
method transfer_switch(trace_input)
if trace_input = input_connection
then
if self.position = 1
then
return {output_connection1}
else
return {output_connection2}
endif
elif trace_input = output_connection1 and
self.position = 1
then
return {input_connection}
elif trace_input = output_connection2 and
self.position = 2
then
return {input_connection}
else
return {}
endif
endmethod
This method can contain any kind of program-ming logic, so the behaviour can be
extremely sophisticated if necessary. This gives us an elegant way of handling
the transfer switch.
The transfer switch is a fairly simple example – we also need to model more complex
devices such as the following switch cabinet (this particular example is an S&C
model PMH9):
This is displayed as a single object on the map, but internally it contains four
switches which can be operated independently. Each switch controls current on three
phases (A, B and C). The left hand diagram shows all three phases combined, and
the right hand diagram shows the phases separately. The two switches on the left
hand side are group operated switches, which means that they are either open on
all three phases or closed on all three phases, and the two switches on the right
hand side are fuse switches, which can be independently open or closed on each
phase. The trace behaviour we want needs to recognise the positions of all these
switches and derive the correct output for a given input appropriately.
The behaviour of the PMH9 switch cabinet is significantly more complex than that
of the transfer switch, so we really need something more to help us model that.
For this we will introduce another couple of new concepts: multiple worlds and
hypernodes.
[ Figure (diagram) not available ]
A good approach to this problem is to model the internal structure of the switch
cabinet as a separate set of GIS objects with their own attributes and topology
– in this case we need to model bus- bars, fuse switches and group operated switches.
We will lay these out in a schematic representation as in the diagram above (the
simpler left hand representation is sufficient providing that we store separate
attributes for the switch position on each phase, and that the tracing function
used can stop based on complex predicates involving these attributes). An issue
we need to resolve is where to place these objects – they provide more detail than
we really want in our main geographic data-base. This is one area where the concept
of multiple worlds is useful. A world is an independent coordinate system within
the same database. Many different worlds can be created, and it is possible for
a world to be related to an object. In this case we create a new world which we
think of as being owned by the switch cabinet. We then create the objects representing
the internals of the switch cabinet in its internals world. These can be created
from a list of standard templates, or objects can be created and edited individually.
These objects are connected using ordinary topological rules, and normal trace
constraints will apply, like not going through open switches.
The one thing which is still missing is a link between the cables which are connected
to the switch cabinet, which exist in the main GIS world, and the internal switches
and busbars, which exist in a separate world belonging to the switch cabinet. This
is where the hypernode comes in. A hyper-node is an object which has two point
geometry attributes, and special tracing behaviour defined on it, similar to that
which we defined on the transfer switch. In this case the special behaviour is
quite simple – it just says that if the trace hits a point belonging to a hypernode,
then it should continue tracing from the other point belonging to the hyper-node.
In this way a hypernode can be used to make a trace jump (“through hyperspace” –
hence the name!) from one point to another. The two points (or “ends”) of a hypernode
can be in different worlds. Hence we can add hypernodes
which connect the cables coming into the switch cabinet to the appropriate connection
points in the internal model. The nice thing about this approach is that we do
not have to define any special trace behaviour on any objects, even though we are
modelling some very complex behaviour. We simply specify that the switch cabinet
is an object which has internals, and all the special behaviour we need is already
defined on the hypernode, which is a standard system object. For a more detailed
discussion of the use of multiple worlds, see Newell and Doe, 1994.
Schematics
We have already mentioned that it is a common requirement in utility applications
for an object to have multiple representations, appearing not only on one or more
types of geographical map, but also potentially on various types of schematic diagram.
Several of the modelling techniques which have already been discussed are very
useful in handling schematics. Multiple spatial attributes can be used to store
the location of the object in each schematic. The geometry for each different schematic
can be stored in a different world, to provide a clean separation between each
schematic and the geographic representation.
In some types of schematic there may not be a one to one correspondence between
objects in the geographic world and objects in a schematic. For example, many cables
shown in the geographic world may be combined into a single line section in a schematic.
The spatial attribute model is not sufficient to handle this case: we need to be
able to handle (explicit) relationships between objects. The ability to define
and maintain explicit relation-ships of various types (such as one to many and
many to many) is important for many aspects of data modelling. The system should
be able to automatically enforce rules relating to relationships, like referential
integrity, or more complex rules. For example, in the case of a schematic line
section which is related to multiple cables there must be a mechanism for ensuring
that the schematic is updated appropriately if any of the cables are modified.
These data modelling require-ments can be met using a DBMS feature known as a trigger,
which is discussed in the next section.
Maintaining a Complex Model
In a GIS there are often complex relationships which need to be maintained, and
complex rules which need to be validated whenever certain objects are updated.
It is difficult to consistently validate rules via specific code in the application,
because we need to ensure that validation is always done, whichever mechanism is
used to update the record. For example, whether the record is created or updated
by a data translator, or via one of a number of interactive menus, we always want
to make sure that the same validation is done. This can be implemented by the use
of a DBMS which supports triggers. A trigger is a function (or method in object-oriented
terms) which is invoked whenever a specified object or attribute is inserted, updated
or deleted. Ideally, it should be possible to invoke the full range of GIS functions
from within a trigger, and it should be possible to cause the current transaction
to be rolled back if an invalid condition is found within a trigger.
Triggers can be used for a wide variety of functions. At a very simple level,
for example, a trigger could be defined to create a given anno-tation at a standard
offset from a certain type of point whenever the point was inserted or updated.
A trigger could also be used to implement complex connectivity rules, for example
checking that the phases of two connected cables are compatible, and returning
an error condition which will roll back the current transaction if they are not.
A trigger could also implement more complex functionality such as updating an associated
schematic geometry when the geographical representation of a record is updated.
An Application Example
This section looks briefly at some design issues involved in a common utility
application, outage management, as an example of the sort of trade-offs which need
to be considered when designing a data model.
Outage Management
We will consider the design of an outage management system for a radial electricity
network. The basic idea of this application is to record calls from customers whose
power is out and from this information predict which device is most probably causing
the outage. The customer calls may be entered into a separate system by the telephone
operators, and then passed on to the GIS for outage analysis. In a hierarchical
network, several customers will be fed from a single transformer. A number of transformers
will typically be on a section of network which is isolated by a fuse switch (i.e.
if that fuse switch is out, all customers served from all transformers downstream
of that fuse switch will be out). Further up the hierarchy there will be other
devices such as reclosers which are possible causes of an outage.
In order to predict which device or devices are the likely cause of an outage,
we need to look at the pattern of calls. If we receive several calls from customers
served by the same transformer, then we would predict that the transformer was
the probable cause of the outage. However, if we had predicted several transformers
beneath the same fuse switch, then we would change our prediction to say that it
was most likely that the fuse switch was out rather than all of the individual
transformers. Exactly how many devices need to be predicted before a device further
upstream is predicted depends on the type of device upstream and a range of other
factors. A detailed discussion of all the design requirements is beyond the scope
of this paper. However, it is sufficient to know that for any predictable device
on the network, we need to be able to efficiently identify the switchable devices
immediately downstream of that device, the transformers directly fed from this
device, and if the device is predicted as being out we need to be able to calculate
the number of customers and the total load (kVA) downstream of that device.
To meet the requirement of being able to efficiently identify the immediately
downstream predictable devices and transformers from a given device, we have several
options. We could dynamically trace downstream each time we needed this information.
This could potentially involve tracing downstream for some distance, which could
be a performance issue. A second possibility is that we could construct a separate
network, using a similar approach to that which was discussed for schematics, which
contained only the devices we were interested in for outage management, connected
by linear objects which could be formed from an aggregation of several cables in
the detailed geographic network. We would still have to do a trace each time we
needed the downstream devices, using the “outage network” but performance should
be better as the network is simpler. However, creating a separate network has a
data storage overhead, and we need to write some application code (probably a set
of triggers), which creates and maintains the second network automatically. A third
option is that we could maintain a set of explicit relationships which models the
hierarchy of predictable devices. This would again have some storage overhead,
and would need some triggers writing to maintain the hierarchy, but would probably
give the best performance of any of the approaches.
So we have (at least) three possible approaches to this problem. The simplest
one in terms of the data model and application development require-ments is likely
to be the least efficient in terms of performance. This is a case where prototyping
is very useful to try the different approaches. This application was recently implemented
by the author, and the first approach which was tried as a prototype was the first
option described, which was most attractive because of its simplicity. The performance
obtained with this approach was tested and found to be good, so it was decided
that it was not worth prototyping the other options. This sort of situation occurs
quite frequently, where you have a choice of deriving complex relationships between
objects on the fly, or of creating more explicit relationships which will give
you better performance when querying the relationship, but which has overheads
in terms of data storage, application development and performance of updates. On
a case by case basis you need to evaluate the pros and cons of the different options,
and this may often involve prototyping some of the options.
Managing The Data Model
This section briefly discusses technology which can help in the development and
maintenance of a data model, in particular the use of CASE technology.
Problems in Designing and Maintaining a Data Model
One of the largest costs in most large GIS implementations is the cost of customising
the system to meet an organisation’s specific requirements. In turn, designing
and maintaining the data model for the GIS is typically one of the most significant
elements of this customisation. Data modelling is a complex task for most applications,
but this is particularly true for GIS as we have seen already. GIS projects typically
have quite long life cycles, and the technology is relatively new to most users,
which means that at the outset of the project they typically do not realise the
full capabilities of the system. Both of these things contribute to the fact that
requirements are very likely to change during the course of the project, and these
often require the data model to change. Also as new applications are developed
and added to the system, there may well be requirements for further changes to
the data model. Since GIS projects involve capturing large amounts of data, it
is critical that these changes to the data model can be made without losing any
data which is already stored in the system.
With most traditional GIS software, it has been very difficult to address these
issues. Typically the design of the data model takes a long time and is difficult
to subsequently change. This usually means that a very long period of time is spent
at the beginning of the project doing requirements analysis and data model design
to try to make sure that it is exactly right (which of course it never will be)
before any other work begins, as it is so difficult to make changes subsequently.
This section briefly discusses how a CASE tool can be used to address these issues,
and how this in turn radically changes the way in which one can approach the problem
of customising a GIS.
What is a CASE Tool?
The acronym CASE stands for Computer Aided Software Engineering, and it is used
to describe a variety of computer-based tools which can be used to assist in the
design and development of computer programs. Such tools have been developed for
various purposes, including the analysis and documentation of procedures and data
flows, and the design and documentation of a data model. It is the latter function
which we consider here: the use of a tool which can be used to define a graphical
representation of a data model, in the form of an entity-relationship diagram which
we discussed earlier. By clicking on individual objects it is possible to define
more detailed information about them, such as what attributes they have, what the
types of these attributes are, and so on. With some CASE tools, it is possible
to automatically generate code which will create the data structures which have
been designed.
Compatibility Between the CASE Tool and the DBMS
For doing a high level conceptual design, you do not necessarily need a close
correspondence between the CASE tool being used and the DBMS which will eventually
be used to implement the actual system. However, if the CASE tool is to be used
to do the physical database design and to actually generate code, then clearly
a much closer link is required between the CASE tool and the DBMS, and application
development environment, used to implement the actual system.
This requirement can really be split into two. The first is that the CASE tool
supports all the data modelling concepts supported by the DBMS: all its datatypes,
all the types of relationships it supports, and other concepts which we have discussed
such as triggers. In particular for GIS the CASE tool needs to understand the way
in which spatial information and relationships are stored in the DBMS. The CASE
tool may extend to covering aspects of the user interface of the application, such
as which fields are visible to the user and what sort of interface is used to edit
objects and their individual fields.
The second requirement is that the CASE tool must be able to generate code in
an appropriate format which will implement the data model which has been designed.
Providing that common data modelling concepts are supported, it is obviously technically
possible for one CASE tool to output code in multiple formats suitable for different
DBMSs.
These requirements are to a certain extent independent of each other. If the first
one is met but not the second then it is at least possible to use the CASE tool
to do the physical design for the system, but the code to implement this then has
to be written manually. On the other hand, it is possible to have a CASE tool which
supports a subset of the concepts supported by the DBMS (with GIS, for example,
a CASE tool which supports alphanumeric datatypes but not spatial datatypes), which
could be made to output code in an appropriate format for the DBMS, but further
development work would then be required in the DBMS environment (outside the CASE
tool) to incorporate any of these additional concepts in the application. In this
situation it is likely to be much more difficult to usefully maintain the data
model using the CASE tool after its initial creation, since the CASE tool does
not know about any of the changes which have been made to the data model within
the DBMS environment. Clearly, the CASE tool is much more useful if it meets both
of these requirements in full.
Maintenance of the Data Model
While the requirements in the previous section demand a very close link between
the CASE tool and the DBMS, the biggest benefits the author has found from the
use of a CASE tool come from taking this integration one stage further and providing
the ability to update the data model of an existing DBMS which is already populated
with data, without losing any existing data. This is particularly important in
GIS projects, since as we mentioned, they tend to last for a long time, requirements
are particularly prone to change during the course of the project, and typically
the database will contain large amounts of data when these changes have to be made.
It is highly desirable to be able to make data model changes on a test version
of the database so that they can be tested before applying them to the production
version. Ideally one would like to be able to do this without replicating data
in the master database.
Use of an Incremental Development Methodology
If suitable tools are available to allow the data model of a populated database
to be easily changed, this can significantly change the approach which is taken
to an application development project. Instead of taking the traditional approach
of trying to completely design the data model at the beginning of the project,
which typically takes a very long time, it is possible to start with a much simpler
core data model and develop it over time in parallel with the development of application
prototypes. This allows benefits to be delivered to users much more quickly. For
a more detailed discussion of the use of CASE tools with GIS, see Kendrick and
Batty, 1994.
Conclusion
This paper has covered a range of issues relating to GIS and AM/FM data modelling.
We started by considering how best to represent spatial and topological relationships
when designing an application data model, which is not specifically covered by
any of the common approaches to data model design. We then considered how new features
in the GIS system data model could help the user model certain things more easily.
From this perspective it is important that GIS vendors continue to look at enhancing
their system data models rather than just continuing to use the simple point-line-area
spatial object model which is still the most commonly used approach. It is also
important for users to consider the system data model of any system which they
are evaluating. Finally, we discussed CASE technology which can simplify the creation
and maintenance of a data model, and which in doing so can radically change the
approach which is taken to a GIS development project, by allowing the data model
to be developed incrementally rather than having to completely design it at the
beginning of the project.
References
Batty, P.M, 1993: Object-Orientation – some objectivity please!: Proceedings of
GIS 93 Conference, Birmingham, UK.
Kendrick, G., and Batty, P.M., 1994: Use of an Integrated Case Tool for GIS Customisation:
Proceedings of EGIS 94.
Newell, R.G., and Batty, P.M., 1994: GIS databases are different: Proceedings
of AM/FM Conference XVII, pp 279-288.
Newell, R.G., and Doe, M., 1994: Discrete Geometry with Seamless Topology in a
GIS.
Samet, H., 1990: The design and analysis of spatial data structures: Addison-Wesley,
Reading, Massachussetts, 493 p.