Spatial Database in Object Oriented ApproachN. Balaji Raja Lecturer, Department of Computer Applications JJ College of Engineering and Technology Tiruchirappalli —620 009 Tamil Nadu India. nbalajiraja@yahoo.co.in Abstract. The successful development of any geographic information system project needs the careful design of spatial databases via conceptual data modeling. This involves understanding the underlying spatial data model. Conventional entity-relationship diagrams have limitations for conceptual spatial data modeling, since they get cluttered with numerous spatial relationships. In this paper we present an extension to ER diagrams using pictograms for entities and as well as relationships. This approach effectively reduces the cluttering, as spatial relationships will become implicit. We have provided a complete grammar to translate the pictogram-extended ER diagram. 1 Introduction 1.1 Spatial Databases Spatial database [11], [12], [13] management systems aim at the effective and efficient management of geographic data, which consists of images, points, lines, polygons, their topological relationships, and attribute data. In recent years, spatial databases have been applied to diverse application domains including forestry, agriculture, urban planning, geology, mining, water resource allocation, transportation, tourism, land use management, etc. With advancements in other areas like remote sensing, photogrammetry, Global Positioning System, etc., the data in Spatial databases is becoming diverse and there is a “growing need for conceptual data modeling”. A conceptual data model is a type of data abstraction that hides the details of data storage [10]. It uses logical concepts, which may be easier for most users to understand. Conceptual data modeling is usually carried out using graphical or visual tools. Users find that visual data-modeling approaches help them to understand and describe the contents of the database in an intuitive way. From the system perspective, visual approaches help to improve the processes of programming and system maintenance. Visual modeling tools allow users to model the data and their relationships in an intuitive way. Modeling is the key to the successful implementation of any project, and this is especially true for spatial data management projects, e.g. Geographical Information Systems(GIS). Models of spatial information are usually grouped into two broad categories [12], Field and Object. We illustrate this dichotomy with the help of an example (see Fig 1). Imagine an idealized forest consisting of clusters of three area species. One area of the forest is by “Reserved Forest (RF),” another by “Reserved Land (RL),” and yet another by “Under construction Reserved Land (URL) ”. What is the best way of modeling the Forest and capturing its aggregate nature? Consider a function ?, which maps the underlying geographic space of the forest onto a set consisting of three values: {RF, RL, and URL}. Then ? is a field whose varying spatial distribution captures the diversity of the Forest. The function ? itself is like a “step” function: constant over the area where the RF, RL, URL are alike, and sharply jumping into a different value where the area species changes. Now consider the places where function ? changes values .In an idealized forest situation where the demarcation between the area species is clearly defined, we should get the boundaries of polygons. Each polygon can be assigned a unique identifier and can be considered as a spatial entity having at least one non-spatial attribute associated with it, specifically the name of the area species. So now we can conceptualize the Forest as a collection of polygons, each one corresponding to a different area (RF, RL, URL) species. This is the object viewpoint. While the Forest example was amenable to both field and object models, there are situations where one choice is more popular. For instance, if we want to model the elevation of the earth’s surface, then one often adopt the field model, while the object view seems more appropriate if one wants to track land-parcels for legal owner-ships and taxation purposes [10].  Fig. 1. Field vs. Object Dichotomy The most important problem in modeling spatial database is concerned with the geometry of the spatial objects, the geometric relationships between the objects, their representation at multi-resolutions, their geometric evolution over time, and their spatial integrity constraints. 1.2 Database Design and Entity-Relationship Model Database Design: Database applications are modeled using a three-step design process [3]. In the first step, all of the available information related to the application is organized using a high-level conceptual data model .At the conceptual level, the focus is on the data types of the application, their relationships and their constraints. The actual implementation details are left out at this step of the design process. Plain text combined with simple but consistent graphic notation is often used to express the conceptual data model. The Entity-Relationship(ER) model is one of the most prevalent of all conceptual design tools. Entity-Relationship Model: The Entity-Relationship (ER) model [1] is one of the most popular conceptual data-modeling tools in the relational database management (RDBMS) world. An ER diagram provides a good overview of database design. The ER model may be used for different purposes, including analysis–i.e, for modeling a mini-world and for design–i.e, for describing the database schema. It has long been recognized that it is difficult to capture spatial semantics with ER diagrams. The first difficulty lies with geometric attributes which are continuous, and the second difficulty lies with spatial relationships. When modeling the spatial aspects, the numerous spatial relationships tend to obscure and clutter, otherwise, intuitive and easy-to-comprehend diagrams. Hence some users either tend to ignore the spatial relationships in their ER diagrams or to supplement the ER diagrams with textual descriptions of spatial aspects. As a result, the mapping of ER diagrams to logical data models is often not direct, and users have to perform manual edits 1.3 Related Work and Our Contribution Several researchers have proposed extensions [1], [9] to the existing modeling languages to support spatial data-modeling. The GERM model [10] provides a set of concepts as an add-on to the ER model for modeling GIS. Recently [4] proposed a Plug-in for Visual Languages and implemented a CASE tool, Perceptory, which supports spatial data-modeling. Perceptory is an extension of UML using the UML’s stereotype construct. The stereo types are presented as pictograms to model the spatial data types. The pictograms can be inserted into the object-class boxes using simple graphical user interface provided by the Perceptory. 1.4 Scope and Outline The role of the spatial database component is dependent on the type of database management system (DBMS) involved: relational, object-oriented or object relational. Object-relational databases are increasingly becoming the choice for spatial database implementation, as they provide extension capabilities to the traditional databases. As a result, geometric data types can be efficiently implemented in ORDBMS. Here we focus on conceptual data-modeling using pictogram extended ER diagrams, The remainder of this paper is organized into 4 sections. In section 2, we discuss about the conceptual data-modeling and the limitations of the ER model; we introduce the pictogram concept with its grammar and its use in conceptual data-modeling via ER diagrams. In section 3, we discuss object-oriented data modeling support for spatial data types, and Finally, in section 5 we summarize the results 2 Conceptual Data Modeling Using Spatial Pictogram Extension 2.1 The Entity-Relationship(ER) Model and Its Limitation The ER model is one of the most popular high level conceptual data models. This model is graphical in nature, with boxes and arrows representing essential data elements and their connections. The ER model integrates seamlessly with the Relational data model, which in turn is one of the most prevalent logical data model, the second step in the three-step design paradigm. The ER diagrams have three principal components – entity sets, attributes and relationships. In the ER model, the “miniworld” is partitioned into entities, which are characterized by attributes and interrelated via relationships. Entities are ’things’ or ’objects’ which have an independent physical or conceptual existence. Entities are characterized by attributes. An attribute, or a set of attributes which uniquely identifies instances of an entity, is called the key. Entities interact or connect with each other through relationships. There are three kinds of relationships: one-one – where each instance of one entity can only relate to one instance of the other participating entity; many-one – potentially connects many instances of one entity with one instance of the other entity participating in the relationship; many-many – many instances of one entity can be related to many instances of the other entity participating in the relationship We introduce an example, Mountain Area, which will be used throughout this paper to illustrate the different concepts in spatial data modeling. A Mountain Area consists of Hills, which are a collection of forests, which correspond to different species of forest Areas. The Mountain Area is accessed by Roads and it has a Ranger .There are Fire-Stations which are directly responsible for monitoring fires in the Mountain Area. The Mountain Area is providing Facilities like camping groups and offices. Finally, there are water which supply to the different facilities. The Mountain Area database contains many spatial layers and images and much attribute data. The layers considered in this example are hill, forest, village, road, water, minerals, soil, RF, RL, URL, fire station and fire-image. These layers are translate into entities in the ER diagram. The properties of the entities are translated into attributes; for example the village entity has attributes including its name, Dry land, wetland, No. of House, House holder and geometry. The attributes of these layers are easily captured in the ER diagram, as shown in the Mountain Area example (see Fig 2). Note that the conventional ER approach does not distinguish between spatial and non-spatial attributes, and as a result geometry will be modeled as an attribute. Similarly, the inherent spatial relationships associated with the spatial data need to be explicitly modeled in the conventional ER approach. These limitations are summarized below.  Fig .2. An ER Diagram for Mountain Area Example Limitations of the ER Model: As the above discussion shows, the ER is unable, at least intuitively, to capture some important semantics inherent in spatial modeling. The ER model was originally designed with the implicit assumption of an object-based model. Therefore, a field model cannot be naturally mapped using the ER model. For example, there is no notion of key attributes and unique OID’s in a field model. Although in traditional ER, the relationships between entities are derived from the application under consideration, in spatial modeling there are always inherent relationships between spatial objects. For example, all of the topological relationships discussed above are valid instances of relationships between two spatial entities. Then the question is, how can these be incorporated into the ER model without cluttering the diagram? The type of entity used to model a spatial object depends on the scale of the “map”. A city can be mapped as a point or a polygon, depending on the resolution of the map. The problem is, how should multiple representations of the same object be represented in a conceptual data model?    2.2 Pictograms for Spatial Conceptual Data-Modeling Many extensions have been proposed to extend ER to make the conceptual modeling of spatial applications easier and more intuitive. The idea is to provide more constructs, which capture the semantics of spatial applications and at the same time to keep the graphical representation simple. In this section we define pictograms with grammar and their use in conceptual data modeling using the ER diagrams. The pictograms introduced in this section are not limited to extending ER diagrams, but they can also be used with the object-oriented modeling languages like UML [6], an emerging standard for data-modeling. In rest of this section we show how pictograms can be used to capture concepts related to spatial geometry, spatial relationships and multiple spatial representations. We define the pictograms for both entities and the spatial relationships. The grammar is presented in graphical form. Pictogram: A pictogram is generally represented as a miniature version (icon) of an object inserted inside of a box. These pictograms are used to extend ER diagrams by inserting them at appropriate places in the entity boxes. A pictogram can be of a basic shape, a user-defined shape, or any other possible shape (see fig. 3-A).  Fig: 3 Grammar for Pictograms and Spatial pictogram examples Shape: Shape is the basic graphical element of a pictogram, which represents the geometric types in the spatial data model. It can be a basic shape, a multi shape, a derived shape, or an alternate shape. Most objects have simple (basic) shapes (see fig. 3-B). Basic Shape: In a vector model the basic elements are point, line and polygon. In a forestry example, the user may want to represent a facility as a point (0-D), a water supply or road network as lines (1-D) and forest areas as polygons (2-D) (see fig.3-D). Multi-Shape: To deal with objects, which cannot be represented by the basic shapes, we have defined a set of aggregate shapes. Cardinality is used to quantify multi-shapes. For example, a water supplies network is represented as “a line pictogram with its cardinality n”. Similarly, features that cannot be depicted at a certain scale will have cardinality 0 (see fig. 3-E). Derived Shape: If the shape of an object is derived from the shapes of other objects, its pictogram is italicized. For example, we can derive a forest boundary (polygon) from its “forest type” boundaries (polygon), or a country boundary from the constituent state boundaries (see fig.3-G). Alternate Shape: Alternate shapes can be used for the same object depending on certain conditions; for example, objects of size less than x units are represented as points while those greater than x units are represented as polygons. Alternate shapes are represented as a concatenation of possible pictograms. Similarly, multiple shapes are needed to represent objects at different scales; for example, at higher scales lakes may be represented as points, and at lower scales as polygons (see fig. 3-H). Relationship Pictograms: The relationship pictograms are used to model the relationship between the entities. For example, part_of is used to model the relationship between a route and a network, or it can be used to model the partition of a forest into Village (see fig. 3-C). 2.3 Extending ER Diagrams with Spatial Pictograms Spatial pictograms defined above are used here to extend the Mountain Area ER diagram shown in fig.4. The appropriate pictograms have been inserted in to the entity boxes. For example, the forest can best be described by a polygonal layer, while Road can best be represented a line layer. The spatial pictogram extend ER diagram for the Mountain Area example is given in fig.4. The major advantages of this approach are that, geometry is no more modeled as an attribute and relationships become implicit. The entity pictograms inserted into the entity boxes.  Fig.4. An ER Diagram for Mountain Area with Pictograms 3 Unified Modeling Language with Pictograms Several researchers [9], and [10], have defined and developed data models for GIS based on object-oriented technology, which provides an attractive alternative environment and lends itself to modeling the semantics and processes of the real-world in a more integrated manner than the relational model. There are several object-oriented analysis and design approaches, with the most commonly used methodologies developed by [8], [5], etc. Recent efforts by industry and researchers have resulted in a Unified Modeling Language [6]. The UML is fast becoming a standard conceptual data modeling language for object-oriented or object-relational database management systems (OODBMS/ORDBMS). Unified Modeling Language (UML) [6] is an emerging standard for conceptual data modeling, in object-oriented domain. It is a comprehensive language to model structural schema and dynamic behavior at conceptual level. As far as database design is concerned we are only interested in modeling the static structure of the system. In some ways the UML is quite similar to the ER model we introduced earlier. Instead of ER diagrams, we now have class diagrams. Fig. 5 is the equivalent UML representation of the Mountain Area example shown in Fig. 2.  Fig. 5.The Mountain Area example in UML We now briefly describe the UML notations with reference to the Mountain Area example: Class is the encapsulation of all objects, which share common properties in the context of the application. It is the equivalent of the entity in the ER model. For example Region is an example of a class which, at least abstractly, captures functioning units within the Mountain Area like village, reserve land, reserve forest, under constructer reserve forest and minerals resource. We have extended the class diagrams with pictograms as in the case of the ER diagrams. This way it is clear that instances of the class Region are spatial objects. More specifically, their spatial geometry is represented as points. This way all the spatial properties, relationships and operations that are valid for point objects are applicable to the class Region. Attributes characterize the objects of the class. Unlike in ER notation, there is no notion of a key attribute in UML. This is because in OO systems, all objects have a system-generated unique identification. This lack of explicit uniqueness does have profound ramifications when a UML diagram is mapped onto a relational or object-relational schema. Attributes also have a scope or visibility associated with them. The scope regulates access to the attribute from within or outside of the class. This in turn is essential to control the degree of modularity of the database design. There are three levels of scope, and each has a special symbol: 1. + Public: This allows the attribute to be accessed and manipulated from any class. 2. - Private: Only the class that owns the attribute is allowed to access the attribute. 3. # Protected: Classes that are derived (“subtyped”) from a Parent class have access to the attribute. We have chosen to make all the attributes in the Mountain Area example Protected. Methods are functions and are part of the class definition. They are responsible for modifying the behaviour or “state” of the class. The “state” of the class is embodied in the current values of the attributes. In object-oriented design, attributes should only be accessed through methods. In the Facility class, the Name attribute of the class is accessed through the method GetName(). Relationships relate one class to the other or to itself. This is similar to the concept of relationship in the ER model. For database modeling, UML has two important categories of relationships: generalization and association: Generalization is best described in the context of the spatial hierarchy. For example, the class Geometry is a generalization of its subclasses Point, Line and Polygon Associations show how objects of different classes are related. Like relationships in the ER model, associations can be binary if they connect two classes, or ternary if they connect three classes. The supplies-water to is an example of an association between the classes Village and Water Notice that there is a class Pump, Pond (Supplies-water-to) connected to the Pump, Pond (supplies-water-to) association via a line. This is because the association itself has an attribute volume Comparison between ER and UML: The above discussion highlights the similarities between the ER and UML, for conceptual data modeling using pictogram extensions. These similarities are summarized here. ER Diagrams UML Entity Set Class Attribute Attribute Inheritance Inheritance Aggregation AggregationHowever there are subtle differences between these two approaches which are summarized below. – It is difficult to add relationship pictograms to UML.. – There is no notion of methods in ERD. – Translation of UML into Object Oriented constructs/Java classes is easier. 4 Conclusion and Future Work A pictogram-extended ER model is presented as a conceptual data-modeling tool for spatial databases. We have introduced relationship pictograms is a novel aspects of pictograms in our work. Then, Spatial pictogram extension for conceptual data modeling is not limited to ER diagrams. The same approach can be used to extend object diagrams using UML. Our future work will be to extend and develop a recursive grammar for pictograms to provide a formal syntax and facilitate automatic translation to OGIS spatial data types and visual-data modeling of spatial databases. Reference
|