Spatial database design

7/30/2019 Spatial database design

1/12

Principles of spatial database analysis and design

Y BDARD

This chapter covers the fundamentals of spatial database analysis and design, It begins by

defining the most important concepts: spatial database, analysis, design, and model;and continues with a presentation of the rationale supporting the use of formal methods

for analysis and design. The basic elements and approaches of such methods are

described, in addition to the processes used. Emphasis is placed on the particularities of

spatial databases and the improvements needed for non-spatial methods and tools in

order to enhance their efficiency. Finally, the chapter presents a set of tools, called CASE

(computer-assisted software engineering), which are built to support the formal analysisand design methods.

1 INTRODUCTION

This chapter examines the principles of spatialdatabase analysis and design. These two critical phasesof system development remain informal in most smallGIS projects. However, when one needs to build a largesystem, to facilitate its maintenance or to work with a

team of information technolo gy specialists , formalengineering-like methods must be adopted.

Formal methods for database analysis and designhave been developed to master complex problems.They provide fundamental principle s and well-defined steps aimed at improving the efficiency of thedatabase development process and the quality of theresult . These methods have existed since the 1970sand re ly heavily on models and dictionaries. Theyhave been supported for more than ten years bycomputer assisted sof tware engineering (CASE) toolswhich facil i ta te the building of these models and

dictionaries. Although a growing number of GISspecialists master formal methods, they rarely useCASE tools to create their spatia l database schemaand dictionary or to generate GIS code. This is partly

bec au se exist ing me thods an d tool s mu st be exten dedto become truly effective with spatia l databases.

The following sections cover the fundamentals of spatial database analysis and design. After defining

bas ic co nc ep ts, the ra tion al e of for ma l an al ysi s an d

design is presented. This is followed by a discussion of the methods used, and by a descr iption of the processto follow for spatial databases. Characteristics ofspatia l databases are discussed along with examples.Finally, CASE tools are presented and discussed in aspatia l database context.

2 BASIC DEFINITIONS AND CONCEPTS

For the purpose of this chapter, spatial databaserefers to any set of data describing the semantic andspatial properties of real world phenomena (temporal

pro per ti es ar e al so pos sib le ) . Su ch sp at ia l dat ab as escan be implemented in a GIS, in a computer-assisteddesign (CAD) system coupled with a databasemanagement system (DBMS), in a spatia l engineaccessed through an application programminginterface (API) , and si t t ing on top of a DBMS, in a

universal (object-relational) server with spatialextension, in a web server with spatial viewer, etc.These spatial databases can use flat file, hierarchical,network, re la t ional, object-or iented, multidimensionalor hybrid structures. In addition, they can be organisedin very diverse architectures such as stand-alone GIS,client-server solutions, intranets or spatia l datawarehouses. Gone are the days of a spatial databaseimplemented solely on a stand-alone GIS.

413

Bdard, Y., 1999, Principles of Spatial Database Analysis and Design, GIS: Principles, Techniques, Applications &Management, Wiley, Vol. 2nd Ed., No. Chap. 29, p. 413-424


2/12

Many definit ions exist with regards to analysisand design , sometimes in contradiction with eachother , sometimes very specif ic to a full l ife-cyclesystem development method (see Carmichael 1995and Olle 1991 for a comparison of methods). Thischapter uses the most common and intuitivedefinit ions of analysis and design, but a lso

recognises the fuzziness of the dist inction betweenthem (Jacobson and Christerson 1995). In a spatialdatabase context, analysis is the action of understanding and descr ibing what the users needfor their spatial database. Thus, it results in a formaland detailed database requirements specif ication.Similarly, design is the action of defining anddescr ibing how the analysis result will beimplemented in the selected technology. I t is wherewe consider practical issues such as the l imita tions of the technology used to manage the spatia l database,the desired performance and flexibility, the

implementation of security requirements, etc.Design, therefore, results in a formal and detailedprogramming specification.

Another fundamental definition is that ofmodels since formal models are the thinking toolsas well as the final results of database analysis anddesign. In this context, models are formalrepresentations of something that needs to beunderstood, remembered, communicated, andtested; they are purposeful surrogates buil t a t a givenlevel of abstraction to include only what is re levant

to the system being developed. When a model

represents how users reali ty is organised in terms of objects, properties, re la t ionships, and processes, thenit is descr ibed as an analysis model , and representswhat users want to be implemented in their spatialdatabases. The analysis model is a lso called the

busines s mo del , co nce pt ua l mo del , user s mode l, andsometimes specification model. When a modelrepresents the database internal structure and related

processes as imp lem en ted, then i t i s des cr ibed as adesign model . This la t ter is a lso called theimplementation model, internal model, or physical

model, although the level of detail may vary.

3 THE RATIONALE FOR FORMAL ANALYSISAND DESIGN METHODS

For any database, analysis and design modelsdetermine what can be done easily, with diff iculty, or not a t a l l , once the system has been implemented.However, the impact of bad models appears to be

higher for spatia l databases than i t is for non-spatia ldatabases. Consequently, and especially whenconsider ing the high cost of spatia l data and thelong delays in acquir ing them, an organisationsreturn on investment is very sensit ive to goodanalysis and design.

Using a formal method to complete such tasks

provides guidance, supports the thinking pro ces s andencourages consistent communication anddocumentation. There are several such methods. Themost recent are based on the object-orientedparadigm (Worboys, Chapter 26;Booch 1994; Coadand Yourdon 1991a, 1991 b; Cook and Daniels1994a; Jacobson et al 1993; Martin and Odell l993;Rumbaugh et a l 1991; Shlaer and Mellor 1991) .Although these methods have been created tosupport any type of sof tware development and buil tto support object-oriented (OO) programming, theycan be used eff ic iently for database development.

They all re ly on solid theoretical concepts and haveall been tested over and over again so they haveacquired formal rigourand proved their uti l i ty. Oncea formal method is mastered, it is faster and betterresults are delivered, especially when supported byCASE tools (see section 5) . Master ing a method alsohelps developers to solve the most important

pro blem s bef ore computerisation; the soo ner thepro blem s are sol ved, the les s ex pen sive they ar e tosolve. Finally, good documentation facil i ta tesmaintenance (e.g. adding new data types and new

pro ce sses , mi gr at ing to ne w equ ipme nt) as we ll as

sof tware reuse; i t a lso frees the system from itsdepe nde ncy upon ind ivi dual s. It has been recognisedfor several years that the higher cost of such a formalapproach is lower than the continuous hidden costsof chaotic data and processes. Figure 1 i l lustra tes theimpact of good analysis and design methods on theeffor ts to build and maintain a spatia l database.

Use of formal analysis and design methods is a lsobei ng pushed by the incr ea sing comp lexity of thespatial database development process. The recentevolution of the sof tware industry indicates thatspatial databases are becoming mainstream

solutions seamlessly integrated with non-spatia lcorporate data. This is happening more and more,with new categories of tools outside the tradit ionalGIS packages. In comparison to non-spatialdatabases, these solutions offer a higher level of diversi ty both within and across categories. Thecomplexity of spatial objects is also inherentlyhigher; issues such as geometry, spatial referencesystems, movement, spatia l precision, spatia l

414


3/12

Formal A & D-Informal A & D -------

Less and fasterprogramming

1=Analysis of the requirements 3=Programming of the spatial database2=Design of the spatial database 4=Maintenance of the spatial database

Time

Fig 1. Impact of formal analysis and design methods on efforts to build and maintain a spatial database.

in tegrat ion, metadata management, databaseversioning, data qual i ty analysis , and so on may

have a t remendous impact when designing adatabase for spat ial querying, spat ial analysis , spat ialdata exchange, and system interoperabil i ty(Oosterom, Chapter 27). A look at the IS0SQL3/MM spatial standard (IS0 1996a), the IS0TC211 document - Rules for Appl icat ion Schema (IS0 1996b), and the Open GISVirtual Geodata Model (OGC 1996) rapidlyconvinces the reader of this inherent complexity of

spat ial data (see Sondheim et al , Chapter 24) . Suchcomplexity adds to the omnipresent need for veryhigh performance, a need which encourages databasestructures which are denormalised and dif f icul t tounderstand. Thus, spat ial database analysis anddesign must rely more than ever on formal methodsto cope efficiently with such levels of complexity,especial ly in large projects . Consequently, spat ialdatabase developers have a higher need to split thepr ob lem between ana lys is and desi gn and to deli verseparate models . According to previous def ini t ions,analysis focuses on real-wor ld issues independent of

the technology, while design focuses and dependscompletely on the technology selected. Such aseparation helps to bet ter understand users needs,to structure the database, to facilitate maintenance,

and to encourage metadata management andsoftware reuse. T his split is essen tial for multi-platform envi ron ments and syst ems interop erabil i ty-one of todays most chal lenging issues for spat ialdatabases (Sondheim et al , Chapter 24) . Such adivide and conquer strategy has been used for over20 years in database design (ANSI/SPARC 1975). I tis clear ly defined in most formal methods, includingOO methods, in spite of a different claim in their

first years. (The initial claim stated that there is ape rf ec t on e-t o- on e ma pp in g be twe en the ob ject s of

the analysis model and the objects implemented withOO programming tools. However, with real andlarg e project s, it became obvio us that the analysis-to-design t ranslat ion was not s traightforward, evenwith the best OO systems. In addition, most oftodays commercial database technologies s t i l l relyon the relational approach, with or without OOextensions, thus offering only limited and indirectcapability to support OO concepts; this is especiallytrue for spatial databases.) As clearly stated by Cookand Daniels (1994b), an important question is theextent to which the act ivi t ies of analysis and designcan be merged. The simplistic approach is to say thatobject-or iented development is a process requir ingno transformations, beginning with the constructionof an object model and progressing seamlessly intoobject-oriented code . . . While superficiallyappealing, this approach is seriously flawed. Itshould be clear to anyone that models of the worldare completely different from models of software.

Todays pract ice is to use at least two levels of models, separating the what from the how andleading to more robust and reusable resul ts .Depending on the formal method being used, theselevels are based either on different modelling

techniques (e.g . ent i ty /relat ionship schema for theconceptual level, relational schema for the logicallevel, structured query language, SQL, code for theph ysi cal lev el) or on th e sa me tech niq ue (e .g. th eadditive approach where more details are introducedwhile going f rom the analysis level to theimplementation level). Batini et al (1992) offer anexcellent description of the common three-levelsapproach used with the ent i ty/relat ionship

415


4/12

paradigm. Cook and Daniels (1994b) explain theirthree levels in an OO paradigm. Rumbaugh (1996)clearly presents the layered additive approachcommon in the OO community (Worboys, Chapter26). When applied correctly, the multi-level approachis quite powerful since i t a l lows developers to workat different levels of abstraction for different

pu rp os es . In teg rat ing al l the ab ov e me nt ione d issu esinto only one model makes the work much lessefficient and the result less reusable. Consequentlythe GIS community is also embracing the multi-level

approach in major efforts such as the OGIS ObjectModel (OGC 1996) and the ISO-TC211 rules forapplication schema (IS0 1996b).

While doing analysis and design, spatia l database

developers benefit from a method with a higherpower of expression than traditional methods.Research in recent years has made high-level

modelling more efficient and semantically complete,including for spatial databases (e.g. Bdard et al1996; Caron and Bdard 1993; Golay 1992; IS01996b; Pantazis and Donnay 1996). However, spatialdatabase analysts st i l l need to improve their modell ing techniques to depict better the spatia l andtemporal properties of geographic features (e.g.

Figure 2) and to include geometr ic considerationsbet ter . Th is is nee de d to he lp the de vel op er toconvince the user that he or she understands howevery piece of information is semantically and

geometrically defined and related to the others, howit is used, what are the allowed values, where itcomes from, how reliable it is, etc. Similarly, spatialdatabase designers must convince users that they

have created a solution offering the best way to mapevery element of the analysis model into a piece of

code supported by the c lients technology. To do so

~SEGMENT DE ROUTE @JNUMERO_SEGMENT_ID

VITESSE-PERMISE @IARGEUR-SEGMENT@TYPE -SURFACE@

CLASSIF ICAT ION-FONCT IONNELLE @

suivre

contenir ICARREFONUMERO

ETAGEMEN

UR-ECHAN

T -II II Entities Business Uni+/J Unique Identifier Entr DEROUTE:ributes

NUMERO-SEGMENTLARGEUR_SEGMENT

TYPE -SURFACE 0CLASSIFICATION-FO

TYPE - E L EMENT

Name VITESSE_PERMISE @

O p t i o n a lkDomain

Fig 2. Extract of an analysis model made with Oracle Designer 2000 (Oracle Corporation 1996) where spatial and temporalpictograms (see Figures 4 and 5) are added to indicate the geometry and temporality of geographical features (model in developmentfor Quebec Ministry of Transportation at the time of writing the present chapter).

416


5/12

efficiently and to facili tate communication,especially in the multipurpose context of manyspatial databases, one must extend the traditionalmethods, as explained in the next sect ion.

Finally, database developers rely more and moreon CASE packages. The arrival of such tools has

be en a bi g in cen ti ve for da ta ba se s de ve lo pe rs toembrace formal methods, especially when the toolsautomatically generate code from the models andvice versa (cf. reverse engineering). In the GIS arena,a similar movement has started. For example, therealready exist graphical schema builders with anintegrated data dictionary for the design of thespatial database (e.g. Intergraph MGE). However,we need to go further and to automate this processright from the analysis model . Al though nocomplete tool exists for spatial databases outsideuniversity laboratories (e.g. Orion, developed in 1992

by th e au th or ) , we ca n ex pe ct th at th e pr es en tinternational standardisation efforts and the strongdemand for GIS interoperability will push thedevelopment of such extended methods and tools .

4 FORMAL METHODS FOR SPATI AL DATABASEANALYSI S AND DESI GN

A formal analysis and design method is a set ofguidelines and rules to capture the semantics ofusers reality and to build a spatial databasesupport ing i t . I t i s used for th inking, document ing,and communicating in a consistent and coherentmanner via models. Thus, modelling is thefoundation of analysis and design. Any model is

bu i l t out of a de l ibe rately li mit ed but su ffic ient lypo we rfu l an d cris pl y de fi ne d se t of con st ruc ts . Th eseconstructs , along with a s imple notat ion and a smal lset of rules, constitute a formal language (alsocalled a formalism). Such a formalism can have atextual notation, a graphical notation, or a mix ofthe two. Human cognitive research and psychologyhave shown that graphical languages are moreefficient for synthetic views and textual languages fordetailed descriptions (see Figure 2 which shows bothgraphical and textual notations). Cognitive scienceshave also shown that combining both graphical andtextual languages is necessary to achieve clearunders tanding. This fact i s recognised by formalmethods, since they offer graphical notations tocreate, present, validate, and manipulate models anduse textual detai ls in dict ionaries and programmingcede. However, the graphical notations are the most

visible part of a method and may mistakenly bethought of as the method. This is mis leading s incegraphical notations only reflect a part of theunderlying constructs proposed by a method.

The basic constructs are very similar in nature

across formal methods of the same type but differamong types (relational, entity relationship, and objectoriented). The relational approach relies on one basicconstruct called a relation which is a table of colurrms

(attributes) and rows (occurrences of a phenomenon)manipulated with a relational algebra. The elegance ofthe relational approach lies with its simplicity, while its

po pul ar it y re li es on th e fac t tha t mo st co mme rc ia lDBMS have implemented the relational structure.However, i t is widely known that the relational model

is l imited with respect to semantic content (i .e.expressive power) and there are many design problemswhich are not naturally expressible in terms of

relations. Spatial systems are a case where thelimitations become clear. (Worboys et al 1990)The entity/relationship approach utilises more

constructs, such as entity, attribute, and

relationship. This provides a better expressivepo we r; ho we ve r, fe w DB MS su pp or t th e

entity/relationship structure. Also, anentity/relationship schema must be translated into a

relational schema to be implemented in a relational

DBMS. Worboys et al (1990) mention that manysystems may be modelled using entit ies, attributesand relat ionships , including systems with a

dominating spatial component . . . However,experience has shown that for many systems theinitial set of modelling constructs (entity, attribute,

and relationship) is inadequate. In fact, the last few

years have witnessed the addition of severalextensions to ent i ty / relat ionship constructs ,

including aggregation, generalisation, geometry, andtemporality (e.g. Modul-R: Bedard et al 1996; Caronand Bedard 1993).

Finally, the OO approach relies on: (1) objectsencompassing properties (or attributes) with theoperations modifying data (also called methodsand procedures); (2) on relationships betweenobjects; (3) on aggregation of objects into morecomplex objects; and (4) on generalisation orspecialisation of the types of objects to more generalor more specific types, respectively. The OOapproach also uses states, events, and messagesto show the behaviour of objects. Such an integrateddescription leads to richer database analysis anddesign (see the Unified Modelling Language for the

417


6/12

most recent and robust constructs: Booch et al1996; Worboys 1995). It is undoubtedly the most

powerful modelling paradigm nowadays. Part ofthe success of the OO approach lies in the fact thatthe object-oriented paradigm, which originatedfrom programming languages, has beensuccessfully applied to the analysis and design and

even earlier phases of system development(Magrogan et al 1996).

increase efficiency (Figure 3). The new constructsmust include abstraction mechanisms powerfulenough to facil i ta te the analysis phase. At the design

phas e they mu st al so ma p to the bu i l t- in propri et arycomponents of GIS, CAD, universal servers, andsimilar tools on the market. It must be rememberedthat these generic structures and operators deal with

geometric primitives, graphic properties, spatialreference systems, topological relationships, spatial

L i ke en t it y /r el at i on sh i p, it is po ss i bl e t o e xt en d o pe ra to rs , a nd so on wh ic h d o n ot ex is t i nOO methods with spatial and temporal plug-ins to traditional DBMS.

11111---1-111111111--

i1/1 RNS Segment iI II2-D Length

II IIII Driven Length iII *Classification :I IIllll-----tl-lllll-l-

: *Type of pavement i: *Status II

IRNS Water Segment

Speed limit*Route Number 0. I-T-

RNS Road Segment

*NumberLanes LeftRight+1/1 Jurisdiction Type XYZ 1 .n1/1 Separated lanes XYZ 0.naSpeed limit XYZ 0.nHTraffic flow left/right XYZ t 0.nc71 Steep slope XYZ 0.nOne/Two way*Route Number 0.3

Road Name 0.n

RNS CloverleafSegment I I

RNS RoundaboutSegment I

Suggested SpeedTraffic flow 0.nNumberLanes

Ramp Y/N

NumberLanes Left/Right tTraffic flow Left/Right 0.n

One/Two way&l CloverleafName 0.7 I= Roundabout II Name 0. I IFig 3. Extract of an object model using spatial plug-ins (Bdard and Sondh eim 1996); see Figure 4 for explanation of pict ograms.

4 1 8


7/12

While at the design level the offered primitives

must be considered, at the analysis level thesecomplexities are hidden from the user; only the

general geometric information is relevant (e.g. doesthe user want to have this type of object representedon the map? using which type of shape?). In fact,during the analysis phase, users do not have to deal

with the intricacies of points vs nodes vs vertices, linesvs arcs vs polylines, metric vs topology, and so on;they should only deal with houses, lo ts , s t reets , and

similar concepts of interest. Accordingly, methodsshould be extended with the proper geometricconstructs and coding rules . Their avai labi l i ty in

commercial CASE tools will improve the efficiencyof analysis and design for spatial databases.

All of the constructs mentioned above result fromthe fundamental abstraction concepts used byhumans to understand the world where they live:

classification, association, aggregation, and

generalisation. These are used by the system analystwho tries to understand the users perceptions of their reality (e.g. the types of objects they deal with, their

pr op er t ie s, ho w th ey re la te to eac h ot he r, ho w th ey ar egeometrically represented, how they behave, how they

are used to provide new information, how they arespatially related). These are also the abstractionmechanisms used by the system designer to build

efficient programming code on the selected spatialdatabase technology. The process used when applyingthese abstraction mechanisms is a subtle one. I t callsfor creativity as well as observation and rigour. When

a formal method is used it adds an engineering-likerationality to a work of art. The next paragraphs

explain some technical elements of the analysis anddesign processes for spatial databases.

To start the analysis phase, the different types of

features which are of interest to the users (e.g. house,street, owner, contract) must be identified; thesefeatures may or may not exist in their present

systems. Then the semantic properties and identifiersof these features (e.g. the value, style, and address ofthe feature house) should be selected. In the case of

geographical features, the types of geometry must be

identified as well as a spatial reference system.Bdard et al (1996) present such geometries. Theycombine a dimensional pat tern (0-dimensional ,

l-dimensional, 2-dimensional, 3-dimensional) with acomposition pattern (simple, complex, alternate,multiple). More specifically, the simple pattern is

used when a geographic feature is geometricallyrepresented by only one occurrence of a given

dimension (e.g. a park represented by a singlepo ly go n, i. e. a 2-dimensional pr imit ive) ; th is is themost frequent situation. The complex patternindicates geometric aggregations (e.g. hydrographicnetworks made of l-dimensional rivers and

2-dimensional lakes). The alternative patternindicates mutually exclusive geometries (e.g. parks

digi t ised as points i f smaller than 500 square metresor as polygons if larger) . Final ly , the mult iplepattern is the rarest of all. It indicates that more thanone shape must be digitised for each occurrence of ageographical feature; this happens when the desired

shapes cannot be deduced from each other. Consider,for example, the feature city which is represented by

a polygon on certain maps and by a point locateddowntown on other maps; the point cannot bederived from the polygon and thus requires its owndigi t is ing. Figure 4 shows the graphical notat ion used

for these pat terns in the Modul-R method while

Figure 2 i l lustrates their use in a model .For spatio-temporal databases (e.g. temporal

GIS), the types of temporality needed for each typeof feature must be added. These temporalitiesfollow the same logic as the spatial patterns, i .e.

dimensional pattern (instantaneous 0-dimensional,durable 1 -dimensional) and composition pattern(simple, complex, alternate, multiple). These

patterns apply to the existence of the feature, itspr ese nc e, i ts fu nc t ion al i ty , and i ts ev ol ut ion(semantic and geometric). (See Figures 2 and 5.)

Once the desired features are defined with their

semantic, geometric and temporal properties, theanalyst must identify the relat ionships of in terest

be tw ee n th ese fe at ur es. Th ese in clu de se ma nt icrelationships (e.g. house is owned by owner) as wellas semant ical ly s ign if icant spa t ia l and temporalrelationships (e.g. house is on lot) . Integrity

Simple (e.g. O-dimensional) LllComplex (e.g. 1 -dimensional

and Z-dimensional)Alternative (e.g. O-dimensional

or 2-dimensional)

Multiple (e.g. O-dimensionalor2-dimensional) q Bl

Fig 4. Graphical notation used for spatial patterns.

419


8/12

Simple (e.g. O-dimensional)

Complex (e.g. O-dimensionaland 1 -dimensional) 8

Alternative (e.g. O-dimensional

or 1 -dimensional) a3Multiple (e.g. O-dimensional,

O-dimensional plus em1 -dimensional)

Fig 5. Graphical notation used for temporal patterns; anexample of a spatio-temporal pattern is also presented, thatis one of a O-dimensional object (e.g. an emergency vehicle)with a posit ion which sometimes varies continuously andsometimes remains stable.

constraints must also be specified as they restrict

the content of the spatial database. There areattribute rules (e.g. lists of values for nominalattributes, ranges for numeric attributes), inter-attribute rules (e.g. building.area smaller thanlot.area), and inter-object rules (e.g. lot existedbefore building). The latter include the cardinalities

of relationships (e.g. houses built on only one lot,but a lot ma y hav e 0 to N hous es).

Al l a long th is process the ana lys t must bu i ld a

schema and dictionary which are sufficiently

complete for the programmers while keeping theresult understandable to the users. Such acompromise between two contrasting objectives can

be acc omp lished thro ugh the bu ilding of view s, thatis, exact or modified-but-compatible subsets of theglobal model and dictionary. Views also help to

divide the problem into smaller and moremanageable parts. The analyst must also decide thelevel of detail for the model and dictionary:

i t is not a lways possible or desirable to capture everynuance and restriction in a model: similarly, there isalways a danger in producing a convoluted model

that captures every small detail at the expense ofgeneral understandabil i ty. As a basic pr inciple ,therefore, we follow the maxim: If you must choose

bet wee n unde rm odel l ing an d over mo dell ing, cho ose

the undermodel and add textual commentary.(Booch et al 1996)

The analyst verifies the logic, coherence, andcompleteness of his or her model, dictionary, and

views. At this point the model is normalised if theapproach is relational or entity/relational.Normalisation is used to eliminate data

redundancies and dependencies, to facilitate themaintenance of the integrity of the database, and to

build app lica tion -i ndep en den t struc tur es . If theanalyst works with an extended enti ty/re la tionship

or an OO approach, then objects can be generalisedwith common properties and re la tionships to createsupertypes. In the case of OO methods, operationsmay be added and the dynamic models may be buil t .

The last verifications are made with additionalinterviews and si te visi ts , with formal walk- throughswith the users, or with test ing scenarios.

With regard to the design phase, one needs newbas ic co nst ruc ts. Th es e co nst ru ct s var y wide lyamong spatia l database management systems, since

they depend on their primitives. For example,rela tio nal sy stem s requ ire for eign k eys to materialise

rela tionships, object-or iented systems requiremessages to activate operations, and commercial

GIS require specific links between geometricpr imi tives an d sema nt ic obj ec ts. As sta ted byGunther and Lamberts (1994), for the geometricrepresentation there exists a large variety of spatialdata structures that each support a certain class of

spatial operators. It may also be required tooptimise the database structure with careful

denormalisations of re la t ional tables or with proper fusion and separation of objects. In particular,denormalisation is a very popular technique for

spatial databases because of the large amount ofspatia l data handled for every single request ,

coupled with the need for very high performance(Egenhofer and Frank 1992). This is especially truewhen one wants to accelerate spatial analysis.

However , a l ternative ways should be investigated toimprove the performance of the system, either

through better programming of queries andpro ce du res or thr oug h be tter index ing , c lus teri ng,

and buffer management.To facil i ta te the preceding steps of analysis and

design, different techniques may be used, likebuilding thro w-a wa y an d evolved prototypes tovalidate user requirements. One may also include

use cases or scenarios (Jacobson and Christerson1995) and CRC Cards (Wilkinson 1995) whichdetail how users interact with a database. Finally,

database patterns offer well-documented and testedsolutions to common problems (Coplien 1996;Fowler 1995; Gamma et al 1995).

420


9/12

In spite of such aids, cer ta in steps of analysis anddesign lead to revisiting the models, redefining

objects, adding attr ibutes, e tc . Such tr ips back happennaturally because the more we advance into thedetails , the more we understand the subtle t ies. Thus,

analysis and design are not clear-cut sequential

pr oce sse s, but ra the r ar e in cr em en tal an d i ter at iv eproces ses . In the past , most me thods and CA SE toolsforced the developer to create very definite breaks

be twe en ph as es , an d goi ng ba ck was difficult.Nowa day s , with CA SE tools off eri ng rev erseengineering, and OO methods suggesting addit ive

models, i t has become natural to i tera te . In spite of this i tera tive nature and the result ing fuzzy boundary

be tw ee n th e an al ys is an d des ign pro ce sses , ther e

remain two clearly distinct results: the technology-independent analysis model descr ibing the usersspatia l reali ty as understood once the project is

complete , and the design model descr ibing the spatia ldatabase as developed on the selected technology.

5 SOFTWARE SUPPORTING SPATIAL

In the first years of formal methods, all schemas and

dictionaries were made by hand. As a result, thedrawing and edit ing process took more t ime than thethinking process, and manually keeping the

coherence among evolving models, views, and

dictionary proved to be an a lmost impossible task.This problem was solved by the new category of software created in the mid- 1980s, namely CASE.

These packages offered drawing, dictionary,checking, and reporting functions which acceleratedthe creation and modif ication of the schemas, views,

and reports suggested by formal methods. Using

such tools greatly increased productivity, especiallywhen one CASE could import and export results toanother CASE used in the preceding or subsequent

step (Bdard and Larrive 1992). According to Roux(199l), the objectives of CASE tools are, in order ofimportance: to reduce maintenance considerably, to

prov ide re al qual i ty, to speed up del iver y, to dev elopat less cost (authors transla tion) . Figure 6 i l lustra testhe impact of CASE tools on formal methods ofdatabase development.

The f irst CASE tools copied what was done byhand and specialised in one type of schema or in onetask of the development process (e .g. an enti ty/relationship tool, a data flow diagram drawer, a screenpainter). Most of them were not compatible withother CASE tools automating the preceding andfo l lowing ta sks , r e su l t ing in l imi ted produc t iv i ty ga ins .

Nowadays , most CASE tools support a l l the schemas,views, and reports suggested by a formal method, andthe result of a task si tuated ear ly in the development

pro ces s ca n be use d by an oth er task si tuat ed lat er inthe process. This is done via a common dictionary(als o called encyclopaedia, repo sit ory, or i nfor mati onresources dic tionary system) which maintains thecoherence among models.

As opposed to diagramming, drawing, and CADpac ka ge s su ch as Vis io, Co re 1 Dr aw and AutoCADrespectively, CASE tools store the meaning of eachconstruct of a method and of each piece of a model(e.g. objects, properties, relations). They use thisintelligence to enforce the rules of a method and tocontrol the behaviour of the constructs. For example, a CASE tool may refuse an object in thedictionary which is not depicted in a schema, or mayautomatically fill parts of the dictionary from aschema. When an object is moved in a diagram, thesoftware keeps intact i ts re la t ionships with the other objects. When one tr ies to draw a re la tionship

Easier programming

and faster delivery

Easiermaintenance

4

1 =Analysis of the requirements 3=Programming of the spatial database2=Design of the spatial database 4=Maintenance of the spatial database

Time

Fig 6. Impact of CASE tools on formal methods of spatial database analysis and design.

421


10/12

bet we en two ot he r re lat ions hip s, the so ft wa re ref use sth is ope ra t ion i f i t i s no t a l lowed by the me thod.When one uses the same name for different objects,

the software requires a change, and so on. Productssuch as ERWin, S-Designor , Sylverrun, IEF,Designer2000, OMTool, and Rational Rose are a few

examples of intelligent CASE tools covering the

entire development and maintenance cycle. Like GIS,some CASE tools cos t thousands of dol la r s whi le

others cost a few hundreds, and the la test trend is toembed limited CASE engines within programmingenvironments (e .g. Delphi, Visual Basic) .

In the case of spatial databases, presentcommercial CASE tools can be used. However,extensions for spatia l constructs, rules, and code

generation are needed. Therefore, spatial database

developers must turn towards a more advancedcategory of CASE tools: metaCASE tools. These arespecialised developme nt pac kages w orking at t he

metamodel level; they can be programmed to acceptthe new constructs and rules of a new method andafterwards to run like a CASE tool for that method.

Several large organisations re ly on such a solution to

have a CASE tool adapted to their proprietarymethod. This was used to build our spatial CASEtool called Orion (Figure 7). ObjectMakerandParadigm Plus are such products. In comparison totraditional CASE tools, they offer a large number ofmethods. Some recent CASE tools offer similar but

limited extension capabilities. MetaCASE andextensible CASE products represent the best choicefor spatia l databases.

~ =Ii numro_segment, numro_segment,vitesse-permise, largeur-segment,

$:AA

en-construction. route-transcanadienne, bticlassification-camionage, code-routier, - : , +nun-&o-segment, chainage-fin, , : . ;*?chainage-d&but, pente-max. $;chaussle sip&e, type-&ment,classification-carte_rartiire, y: * , ,type-surface

> . .


11/12

6 CONCLUSION

This chapter has presented the fundamental

elements of spat ial database analysis and design.Good analysis and design rely on formal methods.Such methods help us to work in a more rigorous

manner directed by principles, techniques, andguidelines. This is particularly important for theanalysis phase: al though i t represents only a small

proportion of the total development effort, itsimpact on the final system is probably greater thanany other phase . . . Analysts est imate that a changethat costs $1 to fix in the requirements s tage wil l cost$10 in design, $100 in construction, and $1000 inimplementat ion! (Moody 1996) .

Formal methods rely on specif ic constructs ,models , and processes l ike the ones presented in this

chapter. The most recent methods are based on the

object-oriented paradigm, and they are the mostpo werf ul. Li ke ot he r me th od s, the y are su pp ort ed by

CASE tools to facilitate the building of models,dict ionar ies , documentat ion, and maintenance.

Present methods and tools may already be used for the analysis and design of spat ial databases.

However, recent research and standardisation efforts

wil l help to adapt these methods and tools to spat ialinformation technology. This should fur ther

encourage the development of spatial databaseswhich are robust and flexible, faster to build, easier

to maintain, and closer to interoperability. Finally,

th is wil l help GIS developers to enter themainstream of information technologies which is a

natural evolut ion.

References

ANSI/SPARC 1975 ANSI/X3/SPARC Study Group on database management systems, interim report. ACM SIGFIDET

7: 3-139

Batini C, Ceri S, Navathe S B 1992 Conceptual database

design, an entity-relationship approach. Redwood City,

Benjamin Cummings

Bdard Y,Caron C, Maamar Z, Moulin B, Valliere D 1996Adapting data models for the design of spatio-temporal

databases. Computers, Environment, and Urban Systems 20:

1941

Bdard Y, Larrive S 1992 Developpement des systemes

dinformation rfrence spatiale: vers lutilisation dateliersde gnie logiciel. Journal of the Canadian Institute of

Surveying and Mapping 46: 423-33

Bedard Y, Sondheim M 1996 Road Network System data

model. Technical report. Geographic Data.

http:llwww.env.gov. bc. ca/gdbc/rns

Booch G 1994 Object-oriented analysis and design withapplications, 2nd edition. Redwood City, Benjamin Cummings

Booch G, Rumbaugh J, Jacobson I 1996 The UnifiedModelling Language for object-oriented development,

documentation set version 0.9 addendum. Santa-Clara,

Rational Software Corporation. hhtp:llwww.rational.com/ot./

uml. html

Carmichael A (ed.) 1995 Object development methods. New

York, SIGS Books

Caron C, Bedard Y 1993 Extending the individual formalism

for a more complete modelling of urban spatially referenced

data. Computers, Environment, and Urban Systems 17: 337-46

Coad P, Yourdon E 199 1 a Object-oriented analysis, 2ndedition. Englewood Cliffs, Prentice-Hall

Coad P, Yourdon E 199 1 a Object-oriented design. EnglewoodCliffs, Prentice-Hall

Cook S, Daniels J 1994a Designing object systems: object-oriented

modelling with Syntropy. Englewood Cliffs, Prentice-Hall

Cook S, Daniels J 1994b Software isnt the real world. Journal

of Object-Oriented Programming (May): 2-28

Coplien J 0 1996 Software patterns. New York, SIGS Books

Egenhofer M J, Frank A U 1992 Object-oriented modelling

for GIS. Journal of the Urban and Regional Information

Systems Association: 3-19

Fowler M 1995 Analysis patterns: reusable object models.

Reading (USA), Addison-Wesley

Gamma E, Helm R, Johnson R, Vlissides J 1995 Design

patterns: elements of reusable object-oriented software.Reading (USA), Addison-Wesley

Golay F 1992 Modlisation des systmes dinformation

rfrence spatiale et de leurs domaines dutilisation

spcialiss, aspects mthodologiques, organisationnels ettechnologiques. PhD thesis, cole Polytechnique Fdrale

de Lausanne, Switzerland

Gunther 0, Lamberts J 1994 Object-oriented techniques for

the management of geographic and environmental data. The

Computer Journal 37: 16-25

IS0 1996a SQL multimedia and application packages(SQL/MM) part 3: spatial. SQL/MM: MAD-005.

International Organisation for StandardisationIS0 1996b Geographic information - rules forapplicationschema. IS0 15046-g. IS0 TC2 11: WG2 NO30 Geographic

information-Geomatics, Working group 2. International

Organisation for Standardisation

Jacobson I, Christerson M 1995 Modelling with use cases: a

confused world of OOA and OOD. Journal of Object-

Oriented Programming (September): 15-20

423


12/12

Jacobson I, Christerson M, Jonsson P, Overgaard G 1993

Object-oriented software engineering. Reading (USA),

Addison-Wesley

Magrogan P J, Schardt J A, Chronoles M J 1996 Object-

oriented conceptualisation. Report on object analysis anddesign. Journal of Object-Oriented Programming

(September): 54-63

Martin J, Odell J J 1993 Principles of object-oriented analysisand design. Englewood Cliffs, Prentice-Hall

Moody D 1996 The seven habits of highly effective data

modellers. Database Programming and Design (October): 57-64

OGC (Open GIS Consortium) 1996c The Open GIS abstract

s p e c i f i c a t i o n . http. //www. openings. orglpubli clabstract. h tml

Olle T W ies, 2nd

edition.

1991 Information systems methodolog

Reading (USA), Addison-Wesley

Oracle Corporation 1996 Oracle Designer/2000, Release 1.3

Pantazis D, Donnay J P 1996formalisme. Paris, Hermes

La conception de SIG mthode et

Roux F G 1991 Comment le gnie vient au logiciel.

Linformatique professionnelle 93(April): 19-26

Rumbaugh J 1996 Layered additive models: design as a

process of recording decisions. Journal of Object-Oriented

Programming (March-April): 2 l-48

Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W199 1 Object-oriented modelling and design. Englewood Cliffs,

Prentice-Hall

Shlaer S, Mellor S 199 1 Object lifecycles: modelling the world in

states. Englewood Cliffs, Prentice-Hall

Wilkinson N 1995 Using CRC cards: an informal approach to

object-oriented development. New York, SIGS Books

Worboys M F 1995 GIS: a computing perspective. London,

Taylor and Francis

Worboys M F, Heamshaw H, Maguire D J 1990 Object-

oriented data modelling for spatial databases. International

Journal of Geographical Information Systems 4: 369-8

424

Documents

Spatial database design