Design and Implementation of Object-Oriented Spatial Views* Sang-Ho Moon and Bong-Hee Hong Department of Computer Engineering, Pusan National University 30 Changjeon-Dong, Kumjeong-Ku, Pusan, 609-735, Korea e-mail:
[email protected] Abstract The objective of this paper is to propose an extension of the object-oriented view concepts for providing a variety of user’s perspective views on spatial databases. This paper deals with the issues of design and implementation of materialized spatial views in object-oriented spatial databases. The semantics of object-oriented spatial views and the functionalities for implementing spatial views are proposed. We also present incremental spatial view maintenance by using view derivation relationships.
1 Introduction Spatial views allow the virtual structures and behaviors of spatial objects to be defined for adapting the spatial objects to different applications. For spatial views, it should be able to view one geometric model for a set of spatial objects with different geometric representation according to different user’s perspectives [8]. For example, a traffic management may regard roads as a set of lines, while a road management may see roads as a set of areas. We define a spatial view as a virtual class that is derived by a spatial query on one or more stored base classes which define spatial objects and/or other spatial views. The definition of a stored base class includes a list of spatial attributes, non-spatial attributes, a list of methods, and a list of superclasses. A virtual class in objectoriented databases(OODBs) is a class whose objects are not actually stored. Many works on the view concepts for OODBs have done in [1, 6, 9, 10, 16], but little work has been done on the support of spatial views in object-oriented spatial databases [12, 14]. Most previous works focus on the semantics of object-oriented views [1, 9, 16], view materialization [6, 9, 10], and view updates [5, 6]. However, the spatial characteristics necessary for the support of spatial views have not been discussed so far. We have identified certain differences between object-oriented views and spatial views. The differences include the semantics of spatial views, materialization of spatial views, and incremental update of materialized spatial views. In this paper, we discuss the design and implementation of object-oriented spatial *
This work was supported in part by the Ministry of Science and Technology of Korea under the National GIS project and in part by Research Institute of Computer and Information Communication in Pusan National University.
views built on top of the object-oriented spatial database system Gothic [11]. We present the semantics of spatial views, and then identify the requirements for materializing the instances of a spatial view. Our materialization techniques include incremental view maintenance using view derivation relationships between materialized spatial view objects and their source objects. This paper is organized into 6 sections. In Section 2, we discuss related works. The formal definition of our spatial view model is presented in Section 3. In Section 4, we briefly describe the implementation of materialized spatial views. Section 5 presents an incremental view maintenance for updating materialized spatial views. We show an example of materialization of spatial views in Section 6. In Section 7, a conclusion and future work are described.
2 Related Works The first work on the spatial view concept is the proposal of an extension of the relational view [14]. Claramunt points out that the spatial view concepts provide a graphic database view adapted to spatial application requirements. However, our work on the spatial view concept differs from [14] in that we focus on the extension of object-oriented views to spatial data. Our spatial view modeling scheme is an extension of the object-oriented views [1, 6, 9, 10, 16]. However, there are certain differences between object-oriented views and spatial views. The data type of an attribute in an object-oriented view is the same as that of the corresponding attribute of its source class, or its superclass or subclass [16]. In a spatial view, however, the data type of the view’s attribute may be different from that of the source class’s attribute. Since view materialization has been proven to improve query execution time, an object-preserving or an objectgenerating materialized view can be used in OODBs. Our spatial view approach only supports object-generating views. Object-preservation provides the advantage of eliminating duplication of the attribute value of an instance of a source class, but requires a great deal of overhead to produce a new geometry which should be derived from source classes, whenever a query on a spatial view is re-executed.
3 Object-Oriented Spatial View Modeling 3.1 A Basic Spatial Data Model In this paper, spatial object refers to a collection of spatial primitives that represent the spatial characteristics of a geographic feature, and spatial primitive refers to elements used in describing the geometric attributes of a geographic feature. Thus, we define point, line, and area classes as the subclasses of a class Spatial_Primitive. Two approaches to modeling spatial objects in spatial databases have been proposed: the object-centered data model and the geometry-centered data model [13]. In the object-centered data model, any user-defined class can be declared as a subclass of the abstract class Spatial_Object which is the root class for spatial objects (Figure1 (a)). In the geometry-centered data model, a user-defined class can be declared as a subclass of the class Spatial_Primitive, as shown in Figure1(b).
Spatial_Object
Spatial_Prmitive
… geom :
Spatial_Prmitive … geom :
…
Highway
Town
Point
Line
Area
Point
Line
Area
…
…
…
…
…
…
…
…
(a) object-centered data model
inheritance (is-a) link attribute / domain link
Town
Highway
…
…
(b) geometry-centered data model
Figure 1. Two Kinds of Spatial Data Models The object-centered data model gives users flexibility to dynamically define a spatial view adapted to spatial application requirements. SQL3 proposes the Abstract Data Types like spatial primitives of the object-centered data model [17]. However, the object-centered data model is not directly supported by Gothic. To implement the spatial view concept based on the object-centered data model, the object-centered representation of spatial objects must be simulated in Gothic as shown in Figure2(b). Class Highway superclass: Spatial_Object, name: string … geom: Line methods … end (a) object-centered data model
Class Highway superclass: Line, name: string, … geom: set of coordinates methods … end (b) geometry-centered data model
Figure 2. Inherited Attributes of a Base Class Let BC, SVC, and SPC denote a set of base classes, a set of spatial view classes, and a set of spatial primitive classes, respectively. In the object-centered data model, the domain of the attribute geom of a user-defined class should be one of spatial primitive classes as follows, dom( BCi , geom) Î SPC where BCi Î BC .
3.2 Spatial View Definition . Spatial_View spatial-view-name (view-attributes, geom) // schema elements [ Methods ( methods_list ); ] AS SELECT Attributes, GeometryMappingFunction // query description FROM SourceClasses [WHERE Predicates] Figure 3. Syntax for defining spatial views The definition of a spatial view consists of schema elements and a view-defining query. The schema elements include a list of view attributes, a derived geometry, and a list of methods. The list of view attributes is a list of non-spatial attributes of a spatial view. The derived geometry is denoted as the attribute geom in order to represent its spatial representation. We refer the base classes and/or view classes on
which a certain spatial view has been defined to source classes. The list of methods may be the methods of source classes, or be newly defined for a spatial view. The view defining query consists of three components: geometry mapping function, source classes, and predicates. Figure 3 shows the syntax for defining a spatial view
3.3 Semantics of Spatial Views Given a spatial view class SVCi, SourceClasses(SVCi) refers to a set of source classes from which SVCi is derived. From now on, we make use of the following notation ‘derived-from’ to describe a derivation relationship between a view class and its source classes, and the dot notation to refer to the attributes of a class: Cj.Ai denotes the attribute Ai of a class Cj. Definition 1 A spatial view class SVCi is derived from its underlying source classes SC j (where j is the index number of source classes) by its view defining query, denoted as query(SVCi). SVCi derived-from SC j if SVCi Î SVC and SC j Î SourceClasses(SVCi) We classify the source classes of a spatial view into two types: geometry-source classes and nongeometry-source classes. A geometry-source class is a class that is directly used to derive the spatial view’s geometry. A nongeometry-source class is a class that is not a geometry-source class of a view. Definition 2 Given a spatial view class SVCi Î SVC, its source classes are geometrysource classes, denoted as Geom_SourceClasses(SVCi), and/or nongeometry-source classes, denoted as Nongeom_SourceClasses(SVCi). SourceClasses(SVCi) = Geom_SourceClasses(SVCi) È Nongeom_SourceClasses(SVCi) Like source classes, a view object may be related to one or more geometry- and/or nongeometry-source objects. Let SourceObjects(SVOj) be the set of source objects from which a spatial view object SVOj is derived. We use the following notation [Ci] to refer to the set of object instances of a class Ci, i.e., the extent of the class. Definition 3 Given a spatial view object SVOj, its source objects are geometrysource objects, denoted as Geom_SourceObjects(SVOj), and/or nongeometry-source objects, denoted as Nongeom_SourceObjects(SVOj). SourceObjects(SVOj) = Geom_SourceObjects(SVOj) È Nongeom_SourceObjects(SVOj) if SVOj Î [SVCi] and SVCi Î SVC, where Geom_SourceObjects(SVOj) Î [Geom_SourceClasses(SVCi)] and Nongeom_SourceObjects(SVOj) Î [Nongeom_SourceClasses(SVCi)] In the following, let GMF and SOP be a set of geometry mapping functions and a set of spatial operators such as buffer, overlap, and merge which create a new geometry, respectively. Definition 4 The geometry of a spatial view can be derived without any change of geometry or newly computed from its geometry-source classes according to the geometry mapping functions described in the view-defining query. SVCi.geom = GMFj(Geom_SourceClasses(SVCi)) if GMFj Î query(SVCi) and GMFj Î GMF and SVCi Î SVC
Definition 5 A geometry mapping function may be a non-spatial operator, denoted by Pgeom, which projects the attribute geom of source classes, and/or a spatial operator which computes a new geometry. GMF = {Pgeom} È SOP Let A(Cj) denote the set of attributes of a class Cj. We use a function dom(Ai, Cj), Ai Î A(Cj), which returns the domain of the attribute Ai in the class Cj. Let value(Ai, Oj), where Oj Î [Ck] and Ai Î A(Ck), be a function which returns the value of the attribute Ai in a object Oj. With respect to the geometry, we classify spatial views into two groups: a geometry-preserving spatial view and a geometry-generating spatial view. Let GP_SVC and GG_SVC be a set of geometry-preserving spatial view classes and a set of geometry-generating spatial view classes respectively, thus SVC = GP_SVC È GG_SVC. Definition 6 A geometry-preserving spatial view is a view whose geometry is identical to that of its geometry-source class. A geometry-generating spatial view is a view whose geometry is different from that of its geometry-source class. The domain of the attribute geom of a spatial view may be identical to or different from the domain of the corresponding geometry-source class, which is determined by the applied geometry mapping function. 1. SVCI Î GP_SVC iff GMFj = Pgeom, or SVCI Î GG_SVC iff GMFj Î SOP, where GMFj Î query(SVCi) and GMFj Î GMF 2. if SVCi Î GP_SVC, then dom(SVCi, geom) Î {dom( SC k , geom) | SC k Î Geom_SourceClasses(SVCi)} 3. if SVCi Î GG_SVC, then dom(SVCi, geom) Î {dom( SC k , geom) | SC k Î Geom_SourceClasses(SVCi)}, or dom(SVCi, geom) Ï {dom( SC k , geom) | SC k Î Geom_SourceClasses(SVCi)} Definition 7 For a geometry-preserving spatial view, the value of the attribute geom in an instance of the corresponding virtual class should be an instance of the spaital primitive class. Moreover, the value of the attribute geom of the view object is a spatial primitive object which is referenced by a geometry-source object. Let SPO be a set of spatial primitive objects. value(SVOj, geom) = SPOk if SVOj Î [SVCi] and SVCi Î GP_SVC and SPOk = value(Geom_SourceObjects(SVOj), geom) and SPOk Î SPO Definition 8 The value of the geom attribute in a geometry-generating spatial view should be a newly generated spatial primitive object. A spatial view’s geometry produced by evaluating its view-defining query is stored as an instance of a spatial primitive class. value(SVOj, geom) = SPOk and SPOk Î SPO if SVOj Î [SVCi] and SVCi Î GG_SVC and GMFl Î query(SVCi) and GMFl Î GMF and SPOk = GMFl(Geom_SourceObjects(SVOj))
4 Implementation of Materialized Spatial Views From the viewpoint of materialization, two kinds of spatial views should be differently materialized. A geometry-preserving spatial view object does not have different geometries from its source objects. To materialize geometry-generating spatial views, we have to create a spatial primitive object for representing a new geometry which is derived from the geometries of source objects. The OID of a newly created spatial primitive object should be stored in the attribute geom of a materialized spatial view object. In order to implement materialized spatial views in our prototype, we design a special class, called Spatial_View, which has the functionalities common in all spatial view classes. The abstract superclass Spatial_View resembles the class virtual_object [10] in implementing the view definition. Once defined, a virtual class definition is compiled, and then stored as a subclass of the abstract class Spatial_View. Figure 4 shows the definition of the abstract class Spatial_View, where the keyword class denotes class attributes for representing the definition of a spatial view. Class Spatial_View class view_attrib: array class src_attrib: array
// stores the names of the attributes of a view // stores the names of the attributes of the source classes corresponded to the attributes of a view class src_class : array // stores the source classes of a view class geom_src_class: array // stores the geometry-source classes of a view class geom_map_fun: string // stores the geometry mapping function of a view class condition: string // stores the WHERE clause of the view-defining query methods make_virtual_class(view_definition: string), add_view_attrib(), populate_view_extents(), is_geom_preserving():boolean, …. end
Figure 4. Definition of the class Spatial_View As mentioned before, Gothic offers a geometry-centered data model to provide fast graphic display, as shown in Figure 1(b). To implement a spatial view on top of Gothic, we have to automatically generate a virtual class which is designated as a subclass of the special class Spatial_View. At the same time, the virtual class should be designated as a subclass of the class Spatial_Primitive. The functionalities for the implementation of materialized spatial views are provided by the class Spatial_View through its methods. When a spatial view is defined, a virtual class is thus created as a subclass of the class Spatial_View by applying the method make_virtual_class. The method add_view_attrib is used for describing the list of attributes of the virtual class in the class attribute view_attrib. The domain of an attribute of an instance of the virtual class may be determined by the corresponding attribute described in the class attribute src_attrib.
Spatial_Prmitive
Spatial_View
…
…
Point
Line
Area
…
…
…
Town
Highway
…
…
Regions_Town_ In_Highway …
Spatial_View Regions_Town_In_Highway (name, type, geom) As Select Town.name, Town.type, buffer(Town, 10) From Town, Highway Where contains(Highway, Town)
inheritance (is-a) link view derivation link base class virtual (view) class
Virtual Class Regions_Town_In_Highway superclass: {Spatial_View, Area} , class view_attrib: {name, type}, class src_attrib: {Town.name, Town.type}, class src_class: {Town, Highway}, class geom_src_class: {Town}, class geom_map_fun: buffer(Town, 10), class condition: contains(Highway, Town), /* instance attributes on the view’s structure */ name: string, type: string methods …. /* methods inherited from the class Spatial_View */ end
Figure 5. An example of a spatial view and its corresponding virtual class The method populate_view_extents allows a virtual class to populate its extents. The method is_geom_preserving is invoked to test whether a view is the geometry-preserving spatial view or the geometry-generating spatial view. Figure 5 shows the definition of a geometry-generating spatial view Regions_Town_In_Highway and the generated virtual class.
5 Incremental Spatial View Maintenance 5.1 Definition of View Derivation Relationships To quickly find all of the materialized view objects related to the updated source object, we propose a view derivation relationship type between spatial view objects and source objects. Suppose that virtual OIDs are generated for identifying the materialized instances of a spatial view. Object identity of spatial views makes it possible to establish view derivation relationships. A view derivation relationship type VDR is defined as a set of relationship instances VDRi between materialized spatial view objects SVOm and their source objects SOjn , where j represents the index number of source classes. For example, consider a spatial view Regions_Town_In_Highway derived from two source classes: Highway and Town. Let SVOm be a spatial view object, and Toidi and Hoidi be source objects of Highway and Town, respectively. As shown in Figure 6(a), assume that four spatial view objects are given. In this case, a number of view
derivation relationships are generated as in Figure 6(b). Now, we can generate the view derivation relationship as follows. “ VDR i = < SVO m , SOn11 , SOn22 > where SOn11 = {Toidi } and SOn22 = {Hoidi } ”. source class
: Class Highway
spatial view
: Regions_Town_In_Highway
: Class Town
Hoid1
Hoid2
view derivation relationships Toid3
Regions_Town_In_Highway
Toid4 SVO2
Toid2
SVO3
view object
source object
SVO1
{Toid1}, {Hoid1}
SVO2
{Toid2}, {Hoid1}
...
Toid5
SVO1
SVO4
...
Toid1
(b) view derivation relationships
(a) creation of spatial view objects
Figure 6. An example of view derivation relationships
5.2 Cardinality Ratios of View Derivation Relationships Relationship types usually have certain cardinality constraints that limit the possible combinations of spatial view objects and source objects. The number of relationship instances between spatial view objects and source objects is defined as cardinality ratio. Common cardinality ratios for binary relationships are 1:1, N:1, 1:N, and M:N. It is because the semantics of incrementally updating materialized spatial views differ from each other according to cardinality ratios that we classify view derivation relationships into four kinds of cardinality ratios. Figure 7(a) shows that the cardinality ratio of the view derivation relationship between Regions_Town_In_Highways and Towns is 1:1. The binary relationship between Regions_Town_In_Highways and Highways is of cardinality ratio N:1, as shown in Figure 7(b). This means that each Highway can be related to numerous Regions_Town_In_Highways, but a Regions_Town_In_Highway can be related to only one Highway. source classes
source object
: Class Town : Class Highway
spatial view object spatial view definition Spatial_View Regions_Town_In_Highway (name, type, geom) As Select Town,name, Town,type, buffer(Town, 10)
(a) 1 : 1
(b) N : 1
From Town, Highway Where contains(Highway, Town)
:
:
Figure 7. An example of a 1:1 and an N:1 relationship A 1:N relationship indicates that each view object is derived from several source objects, but a source object is only related to one view object. An M:N relationship is the combination of both a 1:N and an N:1 relationship. That is, one spatial view object is derived from several source objects, and vice versa.
5.3 Update Semantics of Materialized Spatial Views The most important thing to be considered in maintaining materialized spatial views is that the update semantics of materialized spatial view objects are different from each other according to the cardinality constraints of view derivation
relationships. After updating the materialized spatial view objects, view derivation relationships will be changed. However, some updates of source objects may result in only updating view derivation relationships without changing materialized spatial view objects themselves. As shown in Figure 8, the cardinality ratio of the relationships between spatial view objects SVOm and source objects Hi is N:1. In these relationships, the update of Hi causes both the derived spatial view objects and the related view derivation relationships to be updated. source object :
deletion of C3 ‚deletion of H1
H1 C1
C2
SVO3 SVO2
SVO1
C3
view derivation relationships
spatial view object :
after deletion of C3
view derivation relationships ( SVO1, {C1}, {H1} )
( SVO1, {C1}, {H1} ) ( SVO2, {C2}, {H1} )
after deletion of H1 view derivation relationships
( SVO2, {C2}, {H1} ) ( SVO3, {C3}, {H1} )
Figure 8. Updating of view derivation relationships in a 1:1 and an N:1 The update semantics of a 1:N relationship are different from those of an N:1 relationship. For 1:N, it is sufficient only to update the view derivation relationships for propagating the update of a source object. We omit to describe the update semantics of a 1:1 and M:N relationship. A complete set of incremental update algorithms to keep materialized spatial view objects in a consistent state was designed and implemented on top of Gothic which is an object-oriented GIS software [11]. Space limitation, however, prohibits detailed descriptions on the whole implementation.
6 A Spatial View Example 6.1 An Example of Materialized Spatial Views
Figure 9. Display of the basic spatial objects
Figure 10. Display of the materialized spatial view Regions_Town_In_Highway
Suppose that a sample spatial database contains three base classes: Highway with a line geometry, Town with a point geometry, and Forest with an area geometry. Figure 9 displays the spatial representation of highways, towns, and forests. The spatial view class Regions_Town_In_Highway is defined in Figure 5. This spatial
view example shows the visualization of buffering towns intersected with any highway in Figure 11. The materialized spatial view corresponds to a geometrygenerating spatial view.
6.2 An Example of Incremental Spatial View Maintenance To the best of our knowledge, little work has been done regarding the implementation and evaluation of incrementally updating algorithms for maintaining materialized spatial views. The update of a source object highway having a line geometry in the right upper side is shown in Figure 11. Figure 12 shows the result of updating materialized spatial views, which are affected by the updated source object. After updating the highway, two materialized view objects having an area geometry disappear, and a new materialized view object is inserted.
update times (microsec)
Figure 12. Update of the materialized Figure 11. Update of a source object, spatial views highway We evaluate our incremental update algorithms of materialized spatial views. Our experiments demonstrate the benefit of using view derivation relationships. However, our approach has the overhead of creating view derivation relatonships. As shown in Figure 13, the update times of the materialized spatial views affected by the updated source object almost do not increase when our view update algorithms are applied. However, when the other incremental view maintenance using a registration service [5] is applied, the update times of materialized view objects increase in proportion to the number of materialized spatial view objects. This is because the existing view maintenance method has to look through all the materialized spatial view objects to find the directly affected objects. 4.2 3.6 3 2.4 1.8 1.2 0.6 0
incremental view update using view derivation relationships incremental view update using a "registration" service
9
288
432
576
720
864
the number of materialized view objects
Figure 13. Comparison of two incremental view update schemes
7 Conclusion and Future Work This paper discusses the semantic issues of object-oriented spatial views. To
implement the spatial view concepts on top of Gothic, we propose an abstract superclass Spaital_View which defines all the functionalities common in all spatial views. Finally, we presented an incremental spatial view maintenance scheme, which keeps materialized spatial views up to date. Our experiments on incremental view update algorithms demonstrate the benefit of using view derivation relationships. As future work, we will study updatable spatial views which can update source objects through spatial views, and also spatial schema view which represents virtual schema derived from the underlying base schema.
References 1. Serge Abiteboul and Anthony Bonner, "Objects and Views", Proc. of ACM-SIGMOD Int’l Conf. on Management of Data, pp 238-247, May 1991. 2. Jose A.Blakeley, Per-Ake Larson, and Fank Wm Tompa, “Efficiently Updating Materialized Views”, Proc. of ACM-SIGMOD Int’l Conf. on Management of Data, pp 61-71, May 1986 3. Ashish Gupta, Inderpal Singh Mumick, and V. S. Subrahmanian, “Maintaining Views Incrementally”, Proc. of ACM-SIGMOD Int’l Conf. on Management of Data, pp 157-166, May 1993 4. Ashish Gupta and Inderpal Singh Mumick, “Maintenance of Materialized Views: Problems, Techniques, and Applications”, Proc. of IEEE Int’l Conf. on Data Engineering, pp 3-18, 1995 5. Harumi A. Kuno and Elke A. Rundensteiner, “Using Object-Oriented Principles to Optimize Update Propagation to Materialized Views”, Proc. of IEEE Int’l Conf. on Data Engineering ’96, 1996. 6. Harumi A. Kuno and Elke A. Rundensteiner, “The MultiView OODB View System: Design and Implementation”, Theory and Practice of Object Systems, vol. 2 no. 3, pp 203225, 1996. 7. Z. Peng and Y. Kambayashi, “Deputy Mechanisms for Object-Oriented Databases”, Proc. of IEEE Int’l Conf. on Data Engineering ’95, 1995. 8. Robert Laurini and Derek Thompson, “Fundamentals of Spatial Information Systems”, Academic Press, 1992. 9. Giovanna Guerrini, Elisa Bertino, Barbara Catania, and Jesus Garcia-Molina, “A Formal Model of Views for Object-Oriented Database Systems”, Technical Report, DISI-96-2, 1996. 10. C. Souza dos Santos, “Design and Implementation of Object-Oriented Views”, Proc. of Int’l Conf. on DEXA ’95, pp 91-102, 1995. 11. Laser-Scan, “Writing and Developing Applications using GOTHIC ADE”, Issue 2.0, 1995. 12. Sang-Ho Moon and Bong-Hee Hong, “Incremental Update Algorithms for Materialized Spatial Views by Using View Derivation Relationships”, Proc. of Int’l Conf. on DEXA ’97, September 1997. (will be published) 13. Richard G. Newell, “Practical Experiences of Using Object-Orientation to Implement a GIS”, Proc. of GIS/LIS 92, pp 624-629, 1992. 14. Claramunt C. and Mainguenaud M., "Dynamic and Flexible Vision of a Spatial Database", Proc. of Int’l Conf. on DEXA ’95, pp 483-493, 1995. 15. X. C. Delannoy, Ana Simonet, and Michel Simonet, “Database Views with Dynamic Assertions”, Proc. of Int’l Conf. on OOIS ’96, pp 333-339, 1996. 16. Won Kim and W. Kelley, "On View Support in Object-Oriented Database Systems”, Modern Database Systems, ACM Press, pp 108-129, 1995. 17. ISO/IEC 13249-3:199x, “SQL Multimedia and Applications Packages – Part 3: Spatial”, 1997.
