Extending ROCK & ROLL with Spatial Data Types: Part 1 Alvaro A.A. Fernandes, M. Howard Williams Department of Computing and Electrical Engineering Heriot-Watt University Riccarton, Edinburgh EH14 4AS, UK e-mail: @cee.hw.ac.uk Norman W. Paton Department of Computer Science University of Manchester Oxford Road, Manchester M13 9PL, UK e-mail:
[email protected] November 20, 1995 Abstract
The ROCK & ROLL deductive object-oriented database system has been used to develop applications that involve the querying and manipulation of spatial data. The approach to the development of these applications has hitherto required that a suitable set of spatial data types is de ned and handed over to applications as a class library for reuse. While this approach is functionally adequate, it leaves open the way to potential inconsistencies in the treatment of geometries and to computational ineciency, especially due to the absence of built-in spatialindexing facilities and spatial-query optimization. Part 1 of this paper describes the embedding of a spatial algebra into the imperative language of ROCK & ROLL. This provides users with geometrically consistent, computationally ecient built-in support for spatial data types and operations, thereby lessening the burden associated with the development of complete spatial data handling applications in ROCK & ROLL. In Part 2, the same spatial algebra is embedded into the declarative, deductive language of ROCK & ROLL, thus allowing users to bene t from a deductive, declarative mode of expression in addition to built-in support for spatial query optimization.
1 Introduction The ROSE algebra [7, 8, 9] is an algebra of spatial objects de ned with the speci c intention of facilitating its integration with general-purpose database management systems (DBMSs), so as to yield spatial DBMSs with the following desirable characteristics:
The spatial DBMS loses none of its general-purpose
1
database functionality. The ROSE algebra formalizes and makes explicit all the assumptions about the underlying DBMS functionality required to integrate it with the DBMS. These assumptions are not at all stringent in the light of current DBMS technology. The spatial component of the extended DBMS is de ned over an approach to the modelling of geometry that, in a consistent manner, both addresses the limitation that computers can only represent numbers discretely and facilitates the design of more ecient algorithms that implement operations on spatial data. This document describes the integration of the ROSE algebra with the imperative language ROCK of the ROCK & ROLL [2, 3, 5] deductive object-oriented database (DOOD) system. It assumes familiarity with the above cited references to the ROSE algebra and to ROCK & ROLL, but brief overviews are provided. The integration of the ROSE algebra with the declarative language ROLL is addressed in Part 2 of this paper. The remainder of this document is structured as follows. Sections 2 and 3 provide brief overviews of ROCK & ROLL and the ROSE algebra, respectively. Section 4 introduces some notions and terminology that are used throughout the paper. Sections 5 and 6 detail the extensions needed, respectively, in the syntax and the semantics of ROCK, in its role of data-de nition language (DDL) and data-manipulation language (DML) of ROCK & ROLL. Section 7 summarizes the main contributions of this work.
2 The ROCK & ROLL DOOD System: A Brief Overview This section provides an overview of the ROCK & ROLL DOOD system. A detailed description can be found in [2, 3, 5]. The ROCK & ROLL system implements a DOOD using a persistent-language approach. Architecturally, it consists of three components: 1. The OM (for Object Manager) store, which implements the object-oriented data model underlying ROCK & ROLL as a set of persistent classes. 2. The ROCK (for Rule-Object Computational Kernel) interpreter, which processes the datade nition language (DDL) and imperative data-manipulation language (DML) of the system. 3. The ROLL (for Rule-Object Logic Language) interpreter, which processes the deductive query language (DQL) of the system. The OM is written in E [4] over EXODUS [12] (as are the two other software components of ROCK & ROLL) and its main function is to provide a uni ed view of the structures and behaviours de nable in ROCK & ROLL to both the ROCK and the ROLL interpreters. As a DDL, ROCK provides a set of primitive types with which complex application-speci c types can be speci ed. These prescribe not only structure but also behaviour. For example, the following code declares an application-speci c type composite part that is a subtype of part (which is not shown):
2
type composite_part: specialises: part; properties: private: assembly_cost : real, mass_increment: real; public [ part ]; ROCK: compute_mass(): real, compute_cost(): real, print(), readcp(), new(N: string, A_C: real, M_I: real) ROLL: is_component(part); end-type
Structurally, the type has two public properties of its own, viz. assembly cost and mass increment, plus the property it inherits from its supertype, viz. name. All the property names in the example above are aliases of primitive types of ROCK & ROLL. Thus, the declaration assembly cost : real stipulates that real values are the only legal values of the assembly cost property of composite part. The type is a constructed type, i.e., its instances are composite objects. This is denoted by the declaration [ part ], where the square brackets indicate a list-like construction (curly braces would have indicated a set-like construction, and angle brackets would have been used for a record-like construction). Thus, each object of type composite part contains in its state a list of objects of type part that are used for its manufacturing. Behaviourally, the type has an interface involving both ROCK-de ned and ROLL-de ned methods. The implementation of these methods is provided in the unique, mandatory class declaration that corresponds to each declared application type. As a DML, ROCK allows classes to be de ned, within which each interface declared in the corresponding type speci cation is paired with a method that implements it. A comprehensive set of built-in operations and control structures is made available with which users can program very expressive methods. For example, the next few exhibits show the implementation of the compute mass(): real, the print() and the is component(part) operations: ... compute_mass(): real begin var tot: real; foreach p in self do begin tot := tot + compute_mass@p; end tot + get_mass_increment()@self end ...
The excerpt above illustrates several features of ROCK. Local variables, e.g., tot, can be declared and used. The foreach hcontrolV ari in hcollectioni do hblocki can be used to iterate over components of an object. A special denotation, viz. self, is provided for the recipient of the message being attended to. The only statement in the hblocki part of the construct shows that the language has destructive assignment (using the := operator), has built-in operators for arithmetic (such as +), and supports recursion (as in the message send compute mass@p. For each property prop the system generates two methods with name get prop and put prop that allow retrieval and update. respectively, of the value assigned to prop. One such method is invoked in the last statement above. The value of the last evaluated statement is the value returned as an answer to the method invocation. 3
... print() begin write nl,"NAME: ", get_name@self; write nl,"MASS: ", compute_mass@self; write nl,"COST: ", compute_cost@self, nl; end ...
The special symbol nl includes a newline character in the output string. In the context of a write statement, a comma can be interpreted as a concatenation operator. ... readcp() begin ... end new(n: string, a: real, m: real) begin ... end ...
Although their de nition is not shown, the two methods above have the following purpose. The method readcp() prompts the user to enter values for the properties and construction of an instance of composite part. The method new() has a special interpretation in ROCK. It creates a new instance of the type referenced in the invocation. For example, the following code creates an instance of composite part and stores it in the ROCK variable cp (which is presumed to have already been declared): ... cp := new composite_part(); ...
As a DQL, ROLL allows implicit data, views, queries and methods to be de ned using Datalogequivalent rules. ROLL evaluation bene ts from query optimization and evaluation techniques adapted from a relational context into an object-oriented one. The following code shows an example of a ROLL-de ned method. The syntax resembles that of Prolog in many respects, although ROLL is a very di erent language in important ways. Note that arguments to method invocations in ROLL code are logical variables whose values are not destructively assigned but rather get bound by uni cation in the tradition of logic-programming languages. ... is_component(part) begin is_component(P1)@Self :isin(P1)@Self; is_component(P1)@Self :isin(P1)@P2:composite_part, is_component(P2)@Self; end ...
The ROCK & ROLL system, without the extensions described in this paper, is fully implemented and publicly available through the Internet using the URL http://www.cee.hw.ac.uk/Databases/rnr.html. The distribution les contain, among other documents, a user manual that provides examples covering the full range of functionalities of ROCK & ROLL. 4
3 The ROSE Algebra: A Brief Overview This section provides an overview of the ROSE algebra that summarizes a large part of the contents of [8, 9]. The reader is referred to the above sources for formal details and, in particular, the redrawing-based construction of realms. The ROSE algebra uses the notion of a realm as the geometric domain underlying spatial data types. A realm can be thought of as a nite grid built from integer values which describes the complete geometry of an application. Figure 1 is an example of a realm.
Figure 1: A Realm Every instance of a ROSE-algebraic data type is de ned in terms of realm structures, themselves de ned in terms of points and line segments present in the realm. The mode in which a spatial value is constructed is by selecting points and line segments in a realm, i.e., spatial values are never directly created or updated, rather creation and updating is only of points and line segments in a realm with automatic propagation to the spatial values de ned with reference to the a ected points and line segments. Figure 2 depicts two polygonal objects A and B, one polyline object C and one point object D de ned by reference to the realm depicted in Figure 1.
C
A
B
D
Figure 2: Objects De ned over a Realm Realm objects are de ned in terms of nite representations, rather than an abstract notion of Euclidean space, and all primitive operations are de ned in error-free integer arithmetic. 5
User geometry, which potentially contains intersecting line segments is mapped into a set of nonintersecting segments (as stipulated by a de ning property of realms) using the redrawing-based approach to nite resolution geometry of [6]. This approach guarantees that the unavoidable distortion of user geometry remains bounded. The de nition of the ROSE algebra consists of several layers with each successive layer relying on concepts de ned in preceding layers. The base (i.e., bottom) layer de nes arithmetic operations on a nite integer interval. The ROSE algebra is the top layer. The remainder of this section overviews each of these layers from the bottom to the top. The typographical conventions (such as underlines, italics, boldface, etc.) follow [8, 9].
3.1 Integer Arithmetic This layer simply de nes the standard arithmetic operations over a nite integer interval. The standard implementation of this algebra by compilers of modern programming languages suces for the purpose at hand. The main purpose of this layer is to stress the fact that, at the bottom, the ROSE algebra stands upon a nite set of integer numbers.
3.2 Robust Geometry This layer introduces a nite discrete space N N, where N = f0; 1; : : :; n ? 1g N, so as to provide the primitives used in the characterization of realms in terms of integer arithmetic. The entities in this layer are N point and N segment. An N point is an ordered pair (x; y) 2 N N and an N segment is an ordered pair (p; q) of distinct N points, with (p; q) = (q; p). The operations required to de ne realms and realm structures are the following: aligned, disjoint, equal, meet, in, intersect, intersection, on, overlap and parallel. Informally, two N segments meet if they share exactly one end point. Two N segments overlap if they are collinear and share a (partial) N segment. They intersect if they share exactly one point but do not meet. If they are neither equal nor meet nor overlap nor intersect, then they are disjoint. If an N point is located in an N segment then the N point is said to be on the N segment. If it is on but does not coincide with one of the end points, then the N point is said to be in the N segment. The intersection operation applied to two N segments computes their point of intersection, rounds the result to the nearest N point and returns the latter as the result. Figure 3 illustrates some of the relations above. Thus, in Figure 3, A and B meet (at q), A and A0 overlap (between p0 and q0 ), C and B intersect (where the arrow is pointing at), E is disjoint from every other segment, q is on A, while q0 is in A but not in A0 .
3.3 Realm Structures This layer is the core of the ROSE-algebraic approach to geometric modelling. It introduces the notion of a realm. A realm represents a nite, user-de ned set of points and non-intersecting line segments over a discrete domain. Given a set N with the properties de ned above, let PN and SN denote, respectively, the set of all N points and the set of all N segments, A realm over N is a set R = P [ S such that: 1. P and S are subsets of PN and SN , respectively. 2. For every segment (p; q) in S, p and q belong to P. 3. No point p 2 P is in a segment s 2 S. 6
q’’
q
q’ p’’ A’
B
C
E
p’ A r
p
r’’
D
Figure 3: Relations at the Robust Geometry Layer 4. No two segments in S intersect or overlap The elements of P are called R points, and those of S are called R segments. A realm can be construed as a spatially-embedded planar graph whose node set is P and whose edge set is S. Three main additional structures are de ned in terms of these primitive entities, viz. R block, R cycle and R face. An R block is a connected graph all of whose edges are R segments. An R cycle is a cycle all of whose edges are R segments. Finally, an R face is a pair whose rst component is an R cycle and whose second component is a possibly empty set of R cycles. This layer introduces a large number of operations that are exported, so to speak, to upper layers. Between an R point and an R cycle, the on, in, and out relations are basic. They have rather complex de nitions that succeed, nevertheless, in formalizing their intuitive meaning. These relations determine three R point sets, viz., that of R points on, inside and outside a given R cycle C, respectively. Figure 4 illustrates the relations above. Thus, in Figure 4, p is in C, p0 is on C and p00 is out C. C
p
p’
p’’
Figure 4: Relations at the Realm Structures Layer (I) 7
These relations and sets are used to de ne the following relations between two R cycles: area inside, edge inside, vertex inside, area disjoint, edge disjoint, and vertex disjoint. They are better understood by examples such as those in Figure 5.
D’ C’
C’’’
D C’’
D’’
D’’’
C
Figure 5: Relations at the Realm Structures Layer (II) Thus, in the left-hand part of Figure 5, C 0, C 00 and C 000 are area inside C; C 00 and C 000 are edge inside C; and C 000 is vertex inside C. In the right-hand part of Figure 5, D0 , D00 and D000 are area disjoint with D, D00 and D000 are edge disjoint with D, and D000 is vertex disjoint with D. There are two other relations that hold between two R cycles. C1 and C2 are adjacent if they are area disjoint and share at least one edge. C1 and C2 meet if they are edge disjoint and share at least one vertex. Similar relations, illustrated in Figure 6, are established between R cycles and R points and between R cycles and R segments. Thus, in Figure 6, s0 , s00 and s000 are area inside C; s00 and s000 are C s’’’ s’
p’’
s’’
p’
Figure 6: Relations at the Realm Structures Layer (III) edge inside C; s000 is vertex inside C; p0 and p00 are area inside C; and p00 is vertex inside C, R faces are de ned in terms of R cycles. An R face is a pair (c; H) where c is an R cycle and H = fh1 ; : : :; hm g is a (possibly empty) set of R cycles (thought of as holes circumscribed by the boundary c). The conditions that must be satis ed by (c; H) are the following: every R cycle in H must be edge disjoint with c, every pair of R cycles in H must be edge disjoint with one another, 8
and, nally, no R cycle other than c and h1; : : :; hm can be formed using the R segments in (c; H). All the relations above involving R cycles have corresponding versions involving R faces. There is one additional primitive: an R face encloses another if the latter is edge inside the former. The relations de ned on R blocks are the following. Two R blocks b1 and b2 are vertex disjoint if all the R segments in b1 and b2 are pairwise disjoint. The relations meet and intersect between two blocks are illustrated in Figure 7. Thus, in Figure 7, b and b0 meet, while b00 and b000 intersect. The b’ b
b’’’ b’’
Figure 7: Relations at the Realm Structures Layer (IV) relations area inside, meet and intersect are also de ned between an R block and an R face. Finally, by embedding R points in the Euclidean plane, the distance between two R points, the length of an R segment, and the area inside an R cycle and an R face are also de ned.
3.4 Spatial Abstract Data Types This is the layer that actually de nes the spatial abstract data types which the ROSE algebra (as the next layer up) makes use of. The entities in this layer are the same as those of the next layer up. There is also a great deal of overlap in the operations since every operation in this layer is also an operation in the layer above, where it appears as a primitive in terms of which the more complex operations of the ROSE algebra can be de ned. The entities in this layer are spatial data types. Three such types are de ned: a points value is a set of R point values, a lines value is a set of pairwise vertex disjoint R block values and a regions value is a set of pairwise edge disjoint R face values. Among the operations that rst appear in this layer are set operations on realm structures, i.e., union, intersection and di erence, whose de nitions rely on the fact that realm structures can be seen as point sets or as planar graphs. Two other operations, also set-theoretically de ned, that are introduced in this layer are on border of and border in common. The relations expressed by them holds, in the case of the former, between a points value and either a lines value or a regions value, and in the case of the latter, between two lines values, between a lines value and a regions value, and between two regions values.
9
3.5 ROSE Algebra This is the layer that is exported, so to speak, to users. The entities in this layer are inherited from the layer below, viz. points, lines and regions. Similarly, all the operations in the layer below are inherited by this layer. In [9] the link between the spatial abstract data type layer and the ROSE algebra is via an object model interface. This notion highlights the following facts:
The layers up to, and including, the spatial abstract data type layer, are independent of
any particular model of data. Coupling the spatial abstract data types de ned over realm structures to a particular model of data is achieved via an object model interface. The layers up to, and including, the spatial abstract data type layer, are independent of any particular language. The object model interface must provide: 1. A set of concepts with which the ROSE algebra can be de ned. 2. A set of language constructs and notations needed to embed the ROSE algebra for it to become usable in practice. Note that, strictly speaking, what Guting and Schneider [9] refer to as the ROSE algebra is more precisely, a ROSE algebra, insofar as di erent object model interfaces determine di erent ROSE algebras over the spatial abstract data type layer. In fact, the object model interface adopted in [9] is di erent from the one described in this paper in two respects:
The concepts part of the object model interface adopted in [9] is slightly slanted towards
relational DBMSs, whereas the ROCK & ROLL model is object-oriented. The language-constructs part of the object model interface adopted in [9] is slightly slanted towards an SQL-like, relational-algebraic language, whereas ROCK & ROLL is equipped with both an imperative, state-based language and a declarative, deductive one.
The reader is referred to [9] for the details of the object model interface adopted in Guting and Schneider's formulation of the ROSE algebra. In the light of the remarks above, this paper and its companion can be understood as describing an alternative object model interface to that of [9], insofar as they show how the same spatial abstract data types give rise to a di erent, ROCK & ROLL-embedded ROSE algebra. It is important to note that, like classical relational algebra, the ROSE algebra is strictly an algebra of set values, and, in the same way that an individual tuple in a relation value is not denotable within classical relational algebra (and hence cannot be accessed, updated or otherwise manipulated within it), the individual elements in values of type points, lines or regions are not denotable within the ROSE algebra and, consequently, not within ROCK & ROLL either. The reader may have noticed that, in its current stage of development, the ROSE-algebraic approach con nes itself to two-dimensional entities. The proponents of the ROSE algebra have not expressed any intention of extending the approach to three-dimensional entities, and the question of whether such an extension is possible and practical remains open. Since the fact that realms can be seen as planar graphs is crucial to their being an ecient way of modelling geometric entities, it seems very likely that moving from two to three dimensions may require a fundamental rethink of the whole 10
approach with little assurance of a succesful outcome. On the other hand, the less ambitious goal of adding elevation data to realm points seems to present less complex challenges. Notice, however, that such the latter kind of extension would still require a comprehensive revision of the current ROSE algebra. The ROSE algebra is best seen as the summing up, from the viewpoint of computer science, of several years of e ort and interaction involving researchers in spatial modelling and database systems. It is important to note that, from the viewpoint of contemporary research in spatial modelling, the ROSE algebra is not meant to advance the state-of-the-art. For example, the ROSE algebra does not address the fuzziness of many geographical phenomena (consider the fact that the boundary between soil types is often not de nite, i.e., although one can say that inside a region R there are points in R in which the soil type is de nitely A and in others de nitely B, it is often the case that the most one can say about a third subset of points in R is that the soil type is not de nitely A or de nitely B). Similarly, the temporal dimension of geographical phenomena is not addressed in the ROSE algebra. >From the view point of contemprary computer science, the appeal of the ROSE algebra lies in the fact that it allows mainstream database research to take advantage of advances in spatial modelling achieved in the recent past in a sound, well-de ned and eminently practical way.
4 Preliminary De nitions This section introduces notions, terminology and acronyms that are used in the rest of the paper. The types de ned by the ROSE algebra are referred to as spatial types (STs). An instance of an ST is a ROSE-algebraic entity referred to as a spatial value (SV). Let the user geometry (UG) be the geometric data supplied by the user to populate the spatial-data space. When UG is submitted to the system for insertion in the spatial-data space, it is, in general, subject to a redrawing. This redrawing yields the realm geometry (RG) that corresponds to the UG in the current state of the spatial-data space. An ST is de ned by reference to the underlying RG, and hence an SV is a structure containing RG elements of the following realm types (RTs): R point, R segment, R block, R cycle, and R face. An instance of an RT is a realm entity referred to as a realm value (RV). A realm entity is not a ROSE-algebraic entity. An RT is not an ST and an RV is not an SV. This means that ROCK & ROLL does not provide DDL and DML constructs to de ne and manipulate RTs and RVs. Some observations about the relationship between UGs and RGs now follow:
Because the redrawing of a UG into an RG may cascade and cause the redrawing of the RG
of other UGs already stored, it follows that the RG that corresponds to a UG may vary over time independently of any action by users. The redrawing process guarantees that, at all times, the RG that represents a particular UG remains within bounds computed from that UG, but it does not guarantee that there is one and only one valid RG for that UG. The minimum bounding rectangle (MBR) of any UG necessarily contains the RG that represents it. This means that if an MBR-based indexing method is used, then an index search returns both geometries. In general, the original UG cannot be computed from the RG that currently represents it, therefore the two geometries must be stored as a pair. The relationship between UGs and RGs has the following membership and cardinality constraints: an UG has at least one and possibly many RGs that represent it (but exactly one at 11
any one time). An RG may have many UGs (and possibly none) of which it is a representation. The stored RG is sensitive to the order of insertion and deletion, i.e., two di erent sequences of insertions involving the same UG elements into the spatial-data space may pair di erent RG elements with each UG element. points values are an exception to the above observations, in that the UG and the RG of every points value are identical. Every RG is well-formed as a UG, but not vice-versa, since the UG may contain intersection points whereas RGs never do. The syntactic and semantic treatment of an ST and its instances is very similar to that of ROCK & ROLL primitive types and their instances. In particular:
STs can neither be re ned nor rede ned within the ROCK DDL. Instances of STs are treated as values in ROCK & ROLL. Instances of STs only persist if they occur in the state of an instance of a user-de ned persistent
class. Instances of STs are neither created nor destroyed using ROCK & ROLL constructs explicitly. It is not possible to iterate over the extension of an ST in ROCK & ROLL.
A space-referring type (SRT) is a ROCK & ROLL type in whose de nition there is a reference to an ST or an SRT as a property or as a component type. An instance of an SRT is a ROCK & ROLL object referred to as a space-referring object (SRO). A ROCK & ROLL expression which denotes an SRT (respectively, ST) is referred to as an SRTexpression (respectively, ST-expression). A ROCK & ROLL expression which denotes an SRO (respectively, SV) is referred to as an SRO-expression (respectively, SV-expression).
5 Syntactic Extensions to ROCK This section describes by speci c examples how the syntax of ROCK, both as a DDL and a DML, is extended with ST-expressions, SRT-expressions, SV-expressions and SRO-expressions so as to provide the means for users to store and operate upon the entities induced by the ROSE algebra. Section 6 discusses the semantics of these extensions to ROCK programs.
5.1 ST- and SRT-expressions 5.1.1 ST-expressions The primitive types of ROCK & ROLL are boolean, integer, string and real, denoted by the reserved words bool, int, string, real, respectively. Similarly, STs are denoted by the following STexpressions, which enlarge the set of reserved words of ROCK & ROLL: points, lines, and regions. These denote the STs points, lines and regions, respectively.
12
5.1.2 SRT-expressions: Types with ST Properties An application object can have zero or more spatial properties. If the latter is the case, then its type is an SRT and the object is an SRO. Consider the following example SRT-expression: type road_network: properties: public: configuration : lines; maintenance_districts: regions; maintenance_budget : real; end-type
The example above shows that the state of instances of an application type (e.g., road network) can be modelled using aspatial and spatial properties. The former is exempli ed by maintenance budget, the latter by configuration and maintenance districts. Note that, by analogy with the de nition of an aspatial property as an alias of primitive type (e.g., maintenance budget: real), a spatial property can also be de ned as an alias of an ST (e.g., configuration: lines). Thus, configuration and maintenance districts denote the STs lines and regions, respectively.
5.1.3 SRT-expressions: Types with ST Components As the next example SRT-expressions show, an application object can also be a composite object whose construction is de ned by zero or more references to SVs (or SROs). If there is at least one such reference, then its type is an SRT and the object is an SRO. type contractor: properties: public: name : string; address : string; telephone: string; public: { maintenance_contract }; ... end-type type maintenance_contract: properties: public: number : int; date : int; public: { maintenance_task }; end_type type maintenance_task: properties: public: value : deadline : coverage : completed: end_type
real; integer; maintenance_districts; bool;
type maintenance_tasks: public: { maintenance_task }; end_type
13
In the examples above, an application object of type contractor is identi ed with the set of maintenance contracts for which it is responsible. An application object of type maintenance contract is identi ed with the set of maintenance tasks it involves and has as properties an identifying number and the date on which it was signed. An application object of type maintenance task has a value, a deadline, a coverage (indicating which maintenance districts in the road network are covered), and an indicator that the task has been completed. Finally, an association of maintenance tasks is declared as an application type denoted by maintenance tasks.
5.1.4 SRT-expressions: User-De ned Operations with Spatial Parameters ST-expressions and SRT-expressions can appear in interface declarations in the expected way, as the next example (complementing the declaration above of the SRT contractor) shows. type contractor: ... ROCK: balance() : real; to_do(maintenance_contract) : maintenance_tasks; end-type
Assuming C to be a variable that stores an SRO of type contractor and MC one that stores an SRO of type maintenance contract, the interface declarations above indicate that the message balance()@C returns the amount that remains to be paid to C, presumably taking into account, within each maintenance contract held by C, only those maintenance tasks that have not been completed. Both the arguments to and the result of invoking the message to do(MC)@C are SROs. Since the message evaluates to an SRO, it is an SRO-expression. The message presumably returns the maintenance tasks that have not been completed by C in the context of the maintenance contract MC. Since STs are treated as primitive types, the notion of a \spatial class" does not arise. Later in this section, the ROCK & ROLL built-ins for operating on SVs are presented. In contrast, the notion of a space-referring class (i.e., the unique, obligatory class that corresponds to each SRT) is valid, although not interesting in itself.
5.2 SV- and SRO-expressions 5.2.1 Declaring Variables to Denote SVs and SROs As implied by the previous paragraphs, one can declare a variable to store an SV or an SRO, as shown in the next examples. ... var R: regions; var C: contractor; var MC: maintenance_contract; ...
The above lines declare R to store SVs of type regions, and contractor and maintenance contract, respectively.
C
and
MC
to store SROs of type
5.2.2 Reading and Writing SVs, Deleting SROs Existing ROCK & ROLL syntax is used to input and output an SV to and from a variable. The read operation accepts from the input stream a string representation of an SV and stores the internal representation of the SV in a variable of appropriate type. Conversely, the write operation 14
converts the internal representation of an SV stored in a variable into its corresponding string representation and places the latter in the output stream. Existing ROCK & ROLL syntax is also used to remove an SRO from the spatial-data space. Note that, while the read and write operations act on SVs, the delete operation acts on SROs. This is because the spatial-data space only contains objects, and hence a request for the removal of an SV makes no sense, in the same way that a delete request to an integer (or any other value of a primitive type) makes no sense. Assuming the declarations in the previous group of examples, the next examples show how these actions can be speci ed. ... read R; # read an SV from the input stream into R write R; # write the SV in R to the output stream delete C; # remove the SRO C from the data space ...
Apart from input, the other way of binding an SV to a variable x is by evaluating an SV-expression and assigning the result to x, as the next example indicates: ... var MT := to_do(MC)@C; ...
Note that because an SV v is actually a pair consisting of a UG u and an RG r, it can be argued that the read and write statements should take this fact into account. The description above implicitly assumes that read and write operate on UGs only. This is also the implicit assumption in [8, 9].
5.2.3 Spatial Literals The most basic kind of SV-expression is that of spatial literals (SLs). An SL is a string representation of an SV, and hence the input data of a read operation and the output data of a write operation. SLs can also, of course, appear in source texts. Other SV-expressions are variables whose type is an ST and messages that invoke ROSE-de ned spatial operations yielding an SV. To describe the syntax of SLs a further distinction is needed. Recall that when users supply data they supply UG elements. In other words, a string provided by a user in a source text or as input data to a read statement is UG that needs to be converted into RG before the SV denoted by the SL is fully determined. This observation brings out the fact that an SV is a pair of geometries, i.e., neither the UG alone nor the RG alone suces to determine an SV. Although the UG and the RG are technically distinct, no terminology has yet been introduced to refer to UG elements. For each of the RG notions that make up a ROSE-algebraic SV, a corresponding UG notion can be postulated. A slanted typeface is used to denote the UG versions of the RG notions as follows: point for R point, segment for R segment, block for R block, cycle for R cycle, and face for R face. This facilitates the characterization of SLs in terms of UG notions and of SVs in terms of both UG and RG notions. Since SVs are very complex structures, SLs may be quite long strings. For this reason, the syntax supports the writing down of an SL spanning across more than one line in the source text. A points SL is an expression of the form
fp1; : : :; png
points
where each pi ; 0 i n; is a point . Each point is represented as a pair of integer literals separated by a colon. Examples of points SLs are:
15
points{} points{0:0} points{ 0:0, 0:4, 2:1, 4:5, 7:2, 7:6, 11:3, 12:4, 12:6 }
3:3, 8:5,
The rst SL in the examples above denotes the empty-points SV. The second SL denotes a singleton value. The last SL spans several lines of source text. Its UG (which is identical to the RG, as previously remarked) is depicted in Figure 8.
points
Figure 8: A points UG A lines SL is an expression of the form
fb1; : : :; bmg
lines
where each bi ; 0 i m is a block . Recall that a block is a connected graph. Each block is an expression of the form [s1 ; : : :; sn] where each si ; 1 i n; is a segment . Each segment is represented a pair of point s (represented as described above) separated by an underscore. Examples of lines SLs are: lines{} lines{[0:0_0:4]} lines{ [ 0:0_ 0:4, 2:1_ 0:4, 3:3_ 0:4 ], [ 7:2_ 4:5, 7:2_ 8:5 ], [ 7:6_12:6, 12:6_12:4, 12:4_11:3, 11:3_12:6 ] }
The rst SL in the example above denotes the empty-lines SV. The second SL denotes a singleton value. The last SL spans several lines of source text. Its UG (which may not be identical to the RG that corresponds to it) is depicted in Figure 9. A regions SL is an expression of the form
lines
ff1 ; : : :; fm g
regions
16
Figure 9: A lines UG where each fi ; 0 i m; is a face . Each face is represented as a pair of components separated by the keyword inner. The left-hand component is a cycle representing the boundary of the regions value and the right-hand component is a set of cycle s representing the inner regions within the regions value, if any. A cycle is an expression of the form [s1 ; : : :; sn] where each si ; 1 i n; is a segment represented as above. A set of cycle s is an expression of the form fc1; : : :; co g where each ci ; 0 i o; is a cycle represented as above. If an face has no inner regions then only the left-hand component needs to be written. Examples of regions SLs are: regions{} regions{[ 0:0_2:1, 2:1_3:3, 3:3_0:4, 0:4_0:0 ]} regions{ [ 0:0_2:1, 2:1_3:3, 3:3_0:4, 0:4_0:0 ] inner {[ 6:4_7:4, 7:4_8:4, 8:4_7:5, 7:5_6:4 ]} } regions{ [ 0:0_2:1, 2:1_3:3, 3:3_0:4, 0:4_0:0 ] inner {}, [ 3:3_ 4:5, 4:5_7:6, 7:6_12:6, 12:6_12:4, 12:4_11:3, 11:3_7:2, 7:2_ 3:3 ] inner {[ 6:4_7:4, 7:4_8:4, 8:4_7:5, 7:5_6:4 ]} }
The rst SL in the examples above denotes the empty-regions SV. The second denotes a singleton regions value, the only face in which has no inner regions inside it (and hence only the left-hand component of the face is written). The third SL spans several lines of source text and denotes another singleton regions value, but this time the face has a hole inside it (and hence the vertical bar and the right-hand component are also written). The last SL also spans several lines of source text. Its UG (which may not be identical to the RG that corresponds to it) is depicted in Figure 10. Examples of statements involving SLs are the following. 17
Figure 10: A regions UG ... var P: points; P := points{0:0, 0:4, 2:1, 3:3}; begin var L: lines; var R: regions; L := lines{[0:0-0:4], [7:2-4:5]}; R := regions{[0:0-2:1, 2:1-3:3, / 3:3-0:4, 0:4-0:0]}; ... end ...
The initialization of a variable at the point of its declaration is also supported, so that the last four statements in the previous example can be equivalently written as two, as the next example shows. ... begin var L := lines{[0:0-0:4], [7:2-4:5]}; var R := regions{[0:0-2:1, 2:1-3:3, / 3:3-0:4, 0:4-0:0 ]}; ... end ...
5.2.4 Representational Choices for SVs The characterization of SVs from integers is central to the ROSE-algebraic approach to geometric computations. This feature, however, raises the issue of using other representations for geometric entities. For example, users might want to supply SVs expressed in terms of real numbers, or latitude-longitude pairs, etc. For this to be possible, a transformation function (parameterized to an origin and a scale) must be applied to the supplied values so as to yield the corresponding integer values from which an SV is ultimately built. For each representational choice a triple of functions could be supplied to allow the construction of points, lines and regions from values supplied in the chosen representation. The input argument to such functions is a ROCK & ROLL object of a type whose construction is speci ed by the function, e.g., pairs of reals, pairs of triples of integers standing for latitude and longitude, etc. The ROCK & ROLL programmer can declare and construct such an object and then send it a message invoking the appropriate transformation function so as to obtain the required SV 18
(i.e., with integer values replacing the supplied ones). For example, assume that the representational choices in addition to integers are real-number coordinates and latitude-longitude pairs. Each of these could be supported by a triple of functions, as follows:
real numbers Operation Signature reals to points reals to lines reals to regions
: T1 ! points : T2 ! lines : T3 ! regions
In the above signature schemas, the user-de ned ROCK & ROLL type T1 models a set of pairs of reals, the user-de ned ROCK & ROLL type T2 models a set of sets of pairs of reals, and the user-de ned ROCK & ROLL type T3 models a pair the rst element of which is a set of sets of pairs of reals and the second element of which is a set of sets of sets of pairs of reals. latitude-longitude pairs - Let a user-de ned ROCK & ROLL type L model a triple of integers (standing for degrees, minutes and seconds of a latitude or longitude value). Let a user-de ned ROCK & ROLL type LL model a pair L L. Then, the following functions could be supported: Operation Signature latlong to points latlong to lines latlong to regions
: T4 ! points : T5 ! lines : T6 ! regions
In the above signature schemas, the user-de ned ROCK & ROLL type T4 models a set of pairs of LLs, the user-de ned ROCK & ROLL type T5 models a set of sets of pairs of LLs, and the user-de ned ROCK & ROLL type T6 models a pair the rst element of which is a set of sets of pairs of LLs and the second element of which is a set of sets of sets of pairs of LLs. In similar fashion, other transformation functions could be provided so as to cater for other representational choices, e.g., national-grid coordinates, polar coordinates, etc. In other for SVs to be made available to other functions (especially outside the ROCK & ROLL environment), the inverse transformation functions (e.g., points to reals, regions to latlong, etc.) also would come in triples. This approach implies that users are responsible for constructing the recipient objects of messages that invoke transformation functions. This is likely to be done using the range of ROCK & ROLL primitive types and built-in functions for reading values in from les and operating upon them. Once the recipient object has been constructed, a message invoking the appropriate transformation functions can be sent to it, thereby yielding the desired SV. The origin and scale that parameterizes transformation functions can be set (preferably with global scope) by directives of the form: ... origin(1000:1000); scale(1:2000); ...
Defaults, e.g., origin(0:0) and scale(1:1), apply if no directive of the corresponding form has been executed. This is exible enough to allow data sets with di erent origins or di erent scales to be manipulated by the same program. 19
5.3 Operations on Spatial Data Values In addition to variables and SLs, another important class of SV-expressions are messages invoking ROSE-algebraic operations that return instances of STs. The ROSE algebra [9] de nes all the spatial operations that can be performed on instances of points, lines and regions. These are integrated into the syntax of ROCK & ROLL by: 1. associating a reserved word with each operation name de ned by the ROSE algebra, 2. choosing a distinguished argument for each operation, and 3. providing a mapping from each ROSE-de ned signature onto a method-invoking expression in ROCK. The spatial operations provided by ROCK & ROLL are formally de ned in [8, 9]. Algorithms in Modula-2 that implement the spatial operations de ned in the references above are given in [7]. Tables 1 to 3 gives, in alphabetical order, the chosen reserved words and the signatures of such operations. Note that the parameter-types are written using ROCK & ROLL reserved words. Note also that many operations are overloaded. Choosing the rst argument to be the distinguished argument, the operations can be grouped as in Tables 1 to 3. Operation Signature count : points vertex disjoint : points points distance : points lines distance : points points distance : points regions equal : points points area inside : points regions intersection : points points minus : points points not equal : points points plus : points points
! int ! bool ! real ! real ! real ! bool ! bool ! points ! points ! bool ! points
Table 1: ROSE-De ned Operations on points As previously discussed, in the ROSE algebra the individual elements in a SV cannot be denoted. This explains why classical operations on a Set ADT, such as insert, remove and member, are not de ned in Tables 1 to 3, while others, such as plus (i.e., intersection) and minus (i.e., di erence), are. Operations on individual elements are, of course, implemented by the ROCK & ROLL system for its internal workings, but they are not made visible in ROCK & ROLL, i.e., the ROCK & ROLL programmer declares and manipulates SVs as sets only. Any operation f : t1 t2 : : : tn?1 ! tn in Tables 1 to 3 can be invoked in a ROCK program as f (o2 , : : : ,on?1)@o1 and if o1 ; o2; : : :; on?1 are expressions denoting an instance of type t1; t2 ; : : :; tn?1, respectively, then f (o2 , : : : ,on?1 )@o1 denotes an instance on of type tn, otherwise a typing error is raised. If tn 2 fpoints; lines; regionsg then f (o2 , : : : ,on?1)@o1 is an SV-expression. The following are examples: 20
Operation Signature common : lines lines common : lines regions border : lines lines border : lines regions count : lines diameter : lines vertex disjoint : lines lines distance : lines lines distance : lines regions equal : lines lines area inside : lines regions interior : lines intersection : lines lines intersects : lines lines intersects : lines regions length : lines meets : lines lines meets : lines regions minus : lines lines not equal : lines lines on border of : lines points plus : lines lines vertices : lines
border in border in common common
! bool ! bool ! lines ! lines ! int ! real ! bool ! real ! real ! bool ! bool ! regions ! lines ! bool ! bool ! real ! bool ! bool ! lines ! bool ! bool ! lines ! points
Table 2: ROSE-De ned Operations on lines Operation Signature adjacent : regions regions area : regions area disjoint : regions regions contour : regions count : regions diameter : regions vertex disjoint : regions regions distance : regions regions edge disjoint : regions regions edge inside : regions regions encloses : regions regions equal : regions regions area inside : regions regions intersection : regions lines intersection : regions regions intersects : regions regions meets : regions regions minus : regions regions on border of : regions points not equal : regions regions perimeter : regions plus : regions regions vertex inside : regions regions vertices : regions
! bool ! real ! bool ! lines ! int ! real ! bool ! real ! bool ! bool ! bool ! bool ! bool ! points ! regions ! bool ! bool ! regions ! bool ! bool ! real ! regions ! bool ! points
Table 3: ROSE-De ned Operations on regions 21
... var var var var
P: C: L1 L2
points; configuration; := lines{ [0:0_0:4], [7:2_4:5] }; := lines{ [0:0_0:4] };
P := vertices()@L1; P := plus(vertices()@L2)@P; C := plus(L1)@L2; ...
The rst statement assigning an SV to P in the example above uses the built-in vertices to compute the set of all vertices of the lines value stored in L1. In the following statement, P becomes the union of P with the result of invoking vertices on the lines value stored in L2. In the last statement, the union of the SVs stored in L1 and L2 is stored in C, a variable of type configuration, which is an alias for the ST lines.
5.4 Operations on Application Objects The proposed object-model interface in [9] includes operations on sets of application (as opposed to spatial) objects. The operations are sum, closest, decompose, overlay and fusion. These are aggregation-like functions which may take schema-level entities (such as a property name) and may update schema-level entities (for example, by creating a new property). They also have a secondorder avour (like an apply operator in functional languages) insofar as they wrap operations such as plus, intersection and distance. The proposed approach in [9] is slanted towards a relationallike DBMS and a relational-algebraic SQL-like query language, without being strictly dependent on either. The context for operations on application objects in ROCK & ROLL is very di erent from the one assumed in [9]. It is object-oriented, strongly typed and statically type-checked. The DML is imperative rather than SQL-like. The construction and manipulation of sets of application objects is achieved by altogether di erent means (as exempli ed in Section 2) than those assumed in [9]. The approach to database programming that underlies ROCK & ROLL is to allow the programmer to build applications up from a lean set of built-in primitives on primary types rather than attempting to guess which of these more complex built-ins are most useful. The relational slant in [9] has led to the assumption that the DQL and the DML are one single, SQL-like language, thus explaining their proposal of aggregation-like functions. However, ROCK is a computationally-complete language in which not only the operations discussed in [9] can be built from the primitive spatial operations described in the previous subsection, but many other aggregation-like operations that wrap up primitive spatial operations. For this reason, these operations that are only introduced in the object model interface of [9] are not embedded as ROCK & ROLL built-ins. ROCK & ROLL programmers can, of course, write code that implements equivalent operations. For example, sum iterates over a set ofSapplication objects fo1; : : :; ong, one of whose attributes, say a, is an SV v, and returns the SV v0 = ni=1 vi where vi is the SV of a in oi . Assuming fo1 ; : : :; on g to be the construction (by association or sequentiation) of a variable Objects and a to be the property Property: points, the sum operation can be written in ROCK & ROLL as follows:
22
sum (Objects: points): points begin var S := points{}; foreach O in Objects do begin S := plus(get_Property()@O)@S; end S end
Notice that, as expected, the code above resembles other iterative blocks (e.g., the one used in the implementation of the compute mass(): real method in Section 2). This indicates how the aggregation-like functions in the object model interface of [9] can be captured by existing ROCK & ROLL idioms. Notice also that an SQL-like language does not have equivalent idioms.
6 Semantic Extensions to ROCK Section 5 described how the syntax of ROCK, both as a DDL and a DML, is extended with STexpressions, SRT-expressions, SV-expressions, SRO-expressions and a range of primitive built-in spatial operations. These extensions allow users to store and operate upon the entities induced by the ROSE algebra. This section discusses the semantics of these extensions within ROCK programs. The most important semantic aspect of the integration described in this document can be expressed as follows: when the spatial abstract data types of the ROSE algebra are turned into concrete data types of ROCK & ROLL they are treated, within ROCK & ROLL, as primitive data types. Note, however, that being a set of realm values, an SV is a structure, as are the realm values themselves, as described in Section 3. The implication of these observations is that the view that a ROCK & ROLL programmer has of an SV is more akin to that of a string value than that of, e.g., an int value. In terms of the internal workings of the ROCK & ROLL system, the implication is that work must be done behind the scenes to manage SVs internally as complex structures while guaranteeing that, as far as is feasible, ROCK & ROLL programmers can declare and operate upon SVs in as unencumbered a manner as they declare and operate upon values of, e.g., the standard numerical types. Note that an SV v is a pair (u; r) where u is an UG and r is an RG. As argued in Section 4, both u and r are needed to determine v. The indexing of the UG and the RG of SVs is done with an R-tree [10]. Each persistent ROCK & ROLL environment that contains SVs has an associated R-tree that, for every storage location v0 that represents an SV v = (u; r) in the environment, given the MBR of v0 returns a pointer to v0 . This section does not give details of what each operation in Tables 1 to 3 means. The reader who wishes to go beyond the intuitive meaning conveyed by an operation's name and signature is advised to consult [8, 9], the Modula-2 implementation described in [7], or the implementation described in [11] which was carried out in the same software environment as the ROCK & ROLL system, i.e., EXODUS/E [4, 12].
6.1 Equality of SVs Two SVs are equal i their constituent elements are equal, i.e., SV-equality is set equality. It is part of the layered de nition of the ROSE algebra that the formal de nition of equality for entities in one layer relies on the equality predicate for the entities in the preceding layer. This chain of de nitions is well-formed and bottoms out as identity of integers in the base layer. Recall the last exhibit of Section 5, which is repeated here for convenience. 23
... var var var var
P: C: L1 L2
points; configuration; := lines{ [0:0_0:4], [7:2_4:5] }; := lines{ [0:0_0:4] };
P := vertices()@L1; P := plus(vertices()@L2)@P; C := plus(L1)@L2; ...
Since there is an element in L1 that is not in L2, L1 is not equal to L2. On the other hand, as with set equality, duplicates and enumeration order are irrelevant, i.e., the following holds: lines{ [0:0_0:4], [7:2_4:5] } is equal to lines{ [0:0_0:4], [7:2_4:5], [7:2_4:5] } and to lines{ [7:2_4:5], [0:0_0:4] }
6.2 Evaluation of SV-expressions The following steps describe how the ROCK interpreter reacts to source text that stipulates the (possibly recursive) evaluation of an SV-expression e to yield the SV v denoted by it: 1. If e is a variable y (e.g., L1), then the contents of the storage location y0 that is bound to y are returned as the SV v denoted by e. 2. If e is an SV-denoting method-invoking expression which accesses the state of an object (e.g., get configuration()@RoadNetwork), then the contents of the relevant part of the state of the object are returned as the SV v denoted by e. 3. Or else the UG u and RG r that constitute the SV v denoted by e are determined as follows: (a) If e is an SL (e.g., lines{[0:0_0:4]}, then the u = e and the RG r that corresponds to u in the current spatial-data space can be computed (as de ned in [8] and implemented as described in [11]). (b) If e is an SV-denoting method-invoking expression that corresponds to a spatial operation (e.g., vertices()@L1), then its implementation (as described in [11]) can be invoked to yield the UG u (which may be an empty set) and RG r of v. (c) Otherwise e is a complex SV-expression expression (e.g., plus(L1)@L2), in which case each of its component expressions e1 ; : : :; en is recursively evaluated.
6.3 Variable Declaration and Initialization Again with reference to the last code exhibit, the rst line is a declaration of a variable P to store SVs of type points without providing an initialization SV to go into P. The default behaviour in such cases is to store in the newly-declared variable the empty SV of the appropriate ST. For example, after the rst line is executed, the SV stored in P is that denoted by the SL points{}, i.e., the empty-points SV. The second line, like the rst, is initialized with the empty SV of the appropriate ST, in this case the empty-lines SV denote by the SL lines{}. The third and fourth lines declare variables L1 and L2 to store lines SVs and at the same time provide initialization SVs to be stored in them. The following steps describe how the ROCK interpreter reacts to source text stipulating the creation and initialization of a variable x of ST t. 1. A storage location x0 within the state of the interpreter is allocated and bound to x. 24
2. The following rule determines the expression e that is used as the initial SV to be stored in x0: if e has been explicitly supplied as an argument to the variable declaration in the source text, then it is used, otherwise the SL denoting the empty SV of ST t is used. 3. If the expression e determined in the previous step is a nonempty SL, then a test is carried out to ascertain that it is well-formed according to the structural constraints de ned in [8, 9]. If the test fails, then an error is raised. 4. The expression e is evaluated (as described earlier) and the resulting SV v is copied into x0 . After the ROCK interpreter carries out these actions, the ROCK & ROLL variable x stores the SV v of ST t denoted by the initialization expression e. For example, if the source is var C: configuration then a storage location x0 is created in the rst step above. The second step determines e to be lines{}. The third step does not apply. In the fourth step, the SV v = (u; r) that is denoted by this expression is obtained (as described earlier) and copied into x0. As an alternative example, suppose that the source text is var L1 := lines{ [0:0_0:4], [7:2_4:5] }. Then a storage location x0 is created in the rst step above. The second step determines e to be var L1 := lines{ [0:0_0:4], [7:2_4:5] }. In the third step, the expression succeeds in satisfying the structural constraints, and the SV v = (u; r) that is denoted by this expression is obtained (as described earlier) in the fourth step and copied into x0 .
6.4 Variable Assignment After being declared and initialized, a variable can, of course, be used as an SV-expression, for the SV it stores, and as a name for a location that can store SVs of the appropriate ST. A special form of the assignment statement illustrates the two uses, as the next exhibit shows: ... L1 := L2; ...
In the above statement, the left-hand variable L1 is being used as an l-value, i.e., as a name for a location that can store SVs of ST lines, while the right-hand variable L2 is being used as an r-value, i.e., as an SV-expression, for the SV it stores. Before the statement is executed L1 stores the value lines{[0:0_0:4], [7:2_4:5] } and L2 stores the value lines{ [0:0_0:4] }. As expected, after the statement is executed L2 is unchanged and L1 stores the lines value previously (and currently) stored by L2. Assignment uses the so-called copy semantics, i.e., the value v stored in the r-value is copied into the location denoted by the l-value. As a consequence, there are at least two complete copies of the value v in the data space, viz., the one in the location denoted by L1 and the one in the location denoted by L2. The following steps describe how the ROCK interpreter reacts to source text stipulating the assignment of a SV-expression e of ST t to a previously-declared variable x of compatible ST t0: 1. If e is a nonempty SL, then a test is carried out to ascertain that it is well-formed according to the structural constraints de ned in [8, 9]. If the test fails, then an error is raised. 2. The expression e is evaluated (as described earlier) and the resulting SV v is copied into x0 . 3. The spatial index is updated to make the MBR of v return a pointer to x0 and the MBR of v0 (assuming this to be the value previously stored in x0 ) not return a pointer to x0. After the ROCK interpreter carries out these actions, the ROCK & ROLL variable x stores the SV v of ST t denoted by the expression e. 25
6.5 Scope, Extent and Destruction of Objects The rules for scope and extent of variables of STs are the same as those for all other ROCK & ROLL variables, as described in [2, 3]. While x is in scope, x can store any SV v of the ST declared for x. When x goes out of scope its extent terminates, which implies that the existence of the storage locations bound to x has to be reconsidered. The ROCK interpreter reacts to this termination of extent as follows: 1. The spatial index is updated to make the MBR of v0 (assuming this to be the value stored in the storage location x0 that is bound to x) not return a pointer to x0 . 2. The storage space allocated at x0 is reclaimed. After the ROCK interpreter carries out these actions, the variable x is no longer referrable in the program (unless, of course, in the scope just entered another variable x is also de ned).
6.6 Assignment within the State of SROs ROCK provides built-in operations which side-e ect the state of an application object. The most commonly used are those methods pre xed with put . The other methods in this category are the methods used to insert (viz., ++) and to remove (viz., --) elements of an association or a sequentiation. The following steps describe how the ROCK interpreter reacts to source text stipulating the update of a property or construction element of ST t in the state of an application object o with the SV denoted by the expression e passed as argument to the update: 1. If the expression e is a nonempty SL, then a test is carried out to ascertain that it is wellformed according to the structural constraints de ned in [8, 9]. If the test fails, then an error is raised. 2. The expression e is evaluated (as described earlier) and the resulting SV v is copied into the relevant part of the state of o. 3. The spatial index is updated to make the MBR of v (assuming this to be the value being put, or added) return a pointer to o and the MBR of v0 (assuming this to be the value being written over, or removed) not return a pointer to o. After the ROCK interpreter carries out these actions, the application object o stores in the relevant part of its state the SV v of ST t denoted by the expression e. For example, if the source is put_configuration(lines{})@RoadNetwork then in the rst step above the test on lines{} trivially succeeds, then the SV v = (u; r) that is denoted by lines{} is obtained (as described earlier) in the second step and copied into the relevant part of the state of the road-network object o denoted by RoadNetwork, and nally the index is updated to make the MBR of v point to o. As an alternative example, let StorageFacilities have type [points]. In other words, StorageFacilities is a sequentiation of points values. If the source text is StorageFacilities ++ points{2:1, 3:3}, then in the rst step above the test on points{2:1, 3:3} succeeds. The SV v = (u; r) that is denoted by this expression is obtained (as described earlier) in the second step and added to the construction of the object o denoted by StorageFacilities. Finally the index is updated to make the MBR of v point to o. 26
6.7 Reading and Writing SVs The read operation has the semantics of assignment except that the user-supplied SL e is taken from the input stream and not from the source text. Conversely, write takes an SV v = (u; r), converts the UG u to an SL e and places e in the output stream. The following steps describe how the ROCK interpreter reacts to source text stipulating that an expression e of ST t is to be read into a previously-declared variable x of compatible ST t0: 1. The input stream is read to obtain the expression e. 2. If e is a nonempty SL, then a test is carried out to ascertain that it is well-formed according to the structural constraints de ned in [8, 9]. If the test fails, then an error is raised. 3. The expression e is evaluated (as described earlier) and the resulting SV v is copied into x0 . 4. The spatial index is updated to make the MBR of v return a pointer to x0 and the MBR of v0 (assuming this to be the value previously stored in x0 ) not return a pointer to x0. After the ROCK interpreter carries out these actions, the ROCK & ROLL variable x stores the SV v of ST t denoted by the expression e. The following steps describe how the ROCK interpreter reacts to source text stipulating that the SV v stored in a previously-declared variable x of ST t is to be written out as an expression e: 1. The UG u of v is converted to an SL e. 2. The SL e is written onto the output stream. After the ROCK interpreter carries out these actions, the UG u of the SV v of ST t stored in the ROCK & ROLL variable x is in the output stream as an SL e. The variable x is not a ected. Note that, as for primitive types, read and write are de ned for SVs, but not for SROs. As usual, if a ROCK & ROLL type is more than an alias for a type with embedded support, then the input and output of values for its instances must be coded in such a way that all input and output operations bottom out as calls to read and write on instances of types with embedded support. In particular, this would be the case if alternative representational choices described in Section 5 were used.
6.8 Explicit Deletion of SROs ROCK & ROLL has no mechanism to automatically reclaim storage taken up by instances of persistent classes. The built-in delete used for explicit removal of such instances is likewise used for the removal of an SRO from the spatial-data space. In addition to the normal actions associated with a delete request, the ROCK interpreter takes the following actions in the case that the object to be deleted is an SRO o: for every SV vi ; 1 i n in the state of o, the spatial index is updated to make the MBR of vi not return a pointer to o.
7 Summary This document, which is Part 1 of a two-part paper, described the embedding of the ROSE spatial algebra into the imperative language of ROCK & ROLL. In the context of the development of spatial 27
data handling applications in ROCK & ROLL, this ensures a consistent treatment of geometries and the kind of computational eciency ensured by the presence of built-in spatial-query optimization. The most salient features of the work described in this paper are the following:
The treatment of the ROSE-algebraic spatial data types as embedded types of ROCK & ROLL,
thereby allowing developers of spatial-data handling applications to conceive of geometric entities in the same level as they conceive of truth values, number values and string values. The smooth integration of the additional syntax with the syntax adopted in the current, publicly-available implementation of ROCK & ROLL. The de nition of an approach to the semantic treatment of the syntactic extensions, including a strategy for the indexing of spatial values using R-trees.
In Part 2 of this paper the ROSE algebra is embedded into the declarative, deductive language of ROCK & ROLL, thereby completing the task of specifying the transformation of the current version of the ROCK & ROLL DOOD system into a spatial DBMS, i.e., a specialized platform for the development of spatial-data handling applications, such as geographical information systems.
Acknowledgments The work that resulted in this paper is part of the ODESSA: Objectoriented Deductive Spatial Systems Architecture project funded by the Engineering and
Physical Sciences Research Council through the AIKMS programme, and their support is gratefully acknowledged. We would like to thank Mr Neil Smith and Mr Glen Hart of Ordnance Survey as the industrial partners in the ODESSA project. We also thank our colleagues Andrew Dinn and Volker Muller for many useful discussions on the subjects addressed in this paper.
References [1] David Abel and Beng Chin Ooi, editors. Advances in Spatial Databases { 3rd International Symposium SSD'93, number 692 in LNCS, Singapore, June 1993. Springer-Verlag. ISBN 3-540-56869-7. [2] Maria L. Barja, Alvaro A.A. Fernandes, Norman W. Paton, M. Howard Williams, Andrew Dinn, and Alia I. Abdelmoty. Design and Implementation of ROCK & ROLL: A Deductive Object-Oriented Database System. Information Systems, 20(3):185{211, 1995. [3] Maria L. Barja, Norman W. Paton, Alvaro A.A. Fernandes, M. Howard Williams, and Andrew Dinn. An E ective Deductive Object-Oriented Database Through Language Integration. In Jorge Bocca, Matthias Jarke, and Carlo Zaniolo, editors, Proceedings of the Twentieth International Conference on Very Large Data Bases, pages 463{474, Santiago, Chile, September 1994. Morgan Kaufmann Publishers, Inc. [4] Michael J. Carey, David J. DeWitt, Goetz Graefe, David M. Haight, Joel E. Richardson, Daniel T. Schuh, Eugene J. Shekita, and Scott L. Vanderberg. The EXODUS Extensible DBMS Project: An Overview. In [14], pages 474{499. 1990. [5] Andrew Dinn, Norman W. Paton, M. Howard Williams, Alvaro A.A. Fernandes, and Maria L. Barja. The Implementation of a Deductive Query Language Over an Object-Oriented Database, 1995. To appear in Proceedings DOOD'95. [6] Daniel H. Greene and F. Frances Yao. Finite-Resolution Computational Geometry. In Proceedings of the 27th Annual Symposium on Foundations of Computer Science, pages 143{152. IEEE, 1986. [7] Ralf Hartmut Guting, Thomas de Ridder, and Markus Schneider. Implementation of the ROSE Algebra: Ecient Algorithms for Realm-Based Spatial Data Types. Technical Report 170, FernUniversitat, Fachbereich Informatik, Postfac 940, D-58084 Hagen, Germany, February 1995. [8] Ralf Hartmut Guting and Markus Schneider. Realms: A Foundation for Spatial Data Types in Database Systems. In [1], pages 14{35. 1993.
28
[9] Ralf Hartmut Guting and Markus Schneider. Realm-Based Spatial Data Types: The ROSE Algebra. VLDB Journal, 4:243{286, 1995. [10] Antonin Guttman. R-Trees: A Dynamic Index Structure for Spatial Searching. In [13], pages 47{57. 1984. [11] Volker Muller. Spatial Object Management, 1995. Final-Year Dissertation. Department of Computing and Electrical Engineering, Heriot-Watt University, Edinburgh, Scotland, UK. [12] Joel E. Richardson, Michael J. Carey, and Daniel T. Schuh. The Design of the E Programming Language. ACM Transactions on Programming Languages and Systems, 15(3):494{534, July 1993. [13] Beatrice Yormack, editor. SIGMOD'84, Proceedings of Annual Meeting, Boston, Massachusetts, USA., June 1984. ACM Press. SIGMOD Record 14(2). [14] Stanley B. Zdonik and David Maier, editors. Readings in Object-Oriented Database Systems. Morgan Kaufmann Publishers, Inc., San Mateo, CA, USA., 1990. ISSN 1046-1698, ISBN 1-55860-000-0.
29
