A geographic data model is a representation of the real world that can be used in a GIS to produce maps, perform interactive queries, and execute analysis. Contemporary developments in database and software technology are enabling a new generation of geographic data models. The purpose of a Geographic Information System (GIS) is to provide a spatial framework to support decisions and to manage the spatial data. The way to display and analysis information depends upon how geographic objects are modeled in GIS from the world. A data model is an abstraction of the real world that employs a set of data objects that support map display, query, editing and analysis. Geodatabase data model is an object-oriented data model with the benefit of representing natural behaviors and relationships of features (Zeiler, 1999).
The primary phase of the GIS development process is to specify "how" the GIS will perform the required applications. Database planning and designing involve defining how graphics will be symbolized (i.e., color, weight, size, symbols, etc.), how graphics files will be structured, how nongraphic attribute files will be structured, how file directories will be organized, how files will be named, how the project area will be subdivided geographically, how GIS products will be presented (e.g., map sheet layouts, report formats, etc.)., and what management and security restrictions will be imposed on the files access. This is done through completing the following activities:
• Select a source (document, map, digital file, etc.) for each entity and it's attributes
• Set-up the actual database design (logical/physical design)
• Define the procedures for converting data from source media to the database
• Define procedures for managing and maintaining the database
This report describes the process of the design and implementation of a geographic information system (GIS) for “Monitoring and modeling of coastal parts of Sistan-Baluchestan and Bushehr provinces” the project will be called “ Monitoring” for short in this report.
2. Fundamentals of spatial database design
Generating a data model is one of the most important steps to create a database. The main purpose of a data model is to identify all required spatial and attributes data. Since any analysis or modifications on data must be performed on the model. In other words, a data model is a powerful tool to describe information systems abilities and requirements. The most important factor to evaluate a data model is its similarities to real requirements. The standard evaluation is done based on:
• How much data model cover system requirements
• Whether database is normal and avoid data duplications
• Data structure flexibility
This project focuses on marine geographic data model design and implementation. So, the differences between geographic data model and other data models are highlighted first.
Geographic data describe entities which have a location. The geographic data includes the location information and other information about the entity of interest. This other information will be referred to as attributes of the entities. Historically, several terms have been used to describe the data in a GIS database, among them features, objects, or entities.
A good GIS database design requires the use of terms in a clear and unambiguous manner. This report will use the term entity to represent objects to be included in the database and attribute will be the term for representing the characteristics or measurements to be recorded for the entities. In addition to a clear and concise definition of entities and their attributes, data modeling describes relationships between entities. An example of a relationship between a "Port" and a "dock" would be "Has". An important aspect of a relationship is "cardinality". Cardinality defines the numeric relationships between occurrences of the entities on either end of the relationship line. For example, one Port usually has many Buildings whereas one Building belongs to only one Port. The possible cardinalities are: one-to-one; one-to-many; and many-to-many. Thus:
Port (One) <--- Has ------ (Many) Building
Geographic, or spatial data, differs from other "regular" data that are included in computer databases in how entities are defined and in the relationships between entities. Entity identification for spatial data includes the definition of a physical or abstract entity (e.g., a building) and the definition of a corresponding spatial entity (i.e., a polygon to represent the building footprint)
2.1. Spatial Data Modeling Steps
Data model design consists of four stages, increasing in abstraction as one goes from human orientation to implementation in a computer: (Wright, 2003)
1. External design: where the real world is simplified according to application requirements.
2. Conceptual design: (the focus of this document) where a model is populated with spatial objects and attributes in the form of entity-relation (ER) diagrams.
3. Logical design: where ER diagrams are converted to some kind of schema, such as a table.
4. Physical or internal design: where the functions of actual hardware and software are considered for actual implementation of the model.
Designing Monitoring database begins with the identification of data requirement analysis. Conceptual design which shall be described in detail, specify the information entities and their attributes. Conceptual design will dictate database structure. Analysis will be performed on the data through the implemented model. Object oriented modeling has been selected to do data analysis. Reasons for this choice are:
• According to research and experiences on software engineering and due to similarity of object oriented concepts and structure to the real world, it has the capability to address many of the previous challenges in a more realistic way. Geographic information system is no exception; hence object orient concepts can be adjusted for GIS analysis.
• In order to create relational structured Geodatabase, first the necessary information of conceptual model will be transferred to object oriented model. The next step is to design physical model. Changes will easily be done to model, because of similarities of object oriented model to real world. Such changes will be hard to implement in other models.
• Object oriented concepts can be implemented in the production of geodatabase software.
Accordingly, this project follows object oriented database design. Hence, Unified Modeling Language (UML) as a standard object oriented modeling language has been used. ESRI; the products of which are used in this project; is also supporting UML.
Finally physical model will be generated through the analyzed data. Due to its scalability, and flexibility, ArcCatalog is used to transfer the physical model to a Geodatabase. The software has the ability to be modified even after system implementation.
Arc Marine (or the ArcGIS Marine Data Model - MDM), is used in this project. ArcMarine is a geodatabase model tailored specifically for the marine GIS community. ArcMarine template, like all geodatabases, is an organized hierarchy of data objects. These data objects are a collection of feature data sets, feature classes, object classes and relationship classes. To make use of the newly created ArcMarine geodatabase, data must be loaded into the appropriate feature classes and tables.
2.2. Conceptual Design
The conceptual design of a GIS is primarily an exercise in database design. Here, the solutions will be generated from requirements. Conceptual modeling will specify the entities, their types, attributes and relation between them. So, a primary schema of the model will be generated. In fact, designing conceptual model of GIS is a simple example of a database design. The purpose of developing conceptual model is to prepare components which describe real phenomenon. (Brooch, 2000)
In conceptual model design phase of this project all required information of system was identified and entity of interests and their relations were determined. Then, they were uploaded in tables. As an example, Table1 shows an empty table.
Table 1. A Sample for feature table
2.3. Logical Design
Logical design will start when entities are identified and conceptual model is designed. In his phase, data will be analyzed. This will help designers to obtain a clear view of system details. UML which is a standard data modeling language is used in this project. The factors to choose this language are (Brooch, 2000):
UML is more than just a bunch of graphical symbols. Rather, behind each symbol in the UML notation is a well-defined semantics. In this manner, a developer can write a model in the UML, and another developer, or even another tool, can interpret that model unambiguously (Booch, 2000).
The UML addresses the documentation of a system's architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management (Booch, 2000).
The UML is sufficiently expressive and unambiguous to permit the direct execution of models, the simulation of systems, and the instrumentation of running systems (Booch, 2000).
Specification means building models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made in developing and deploying a system (Booch, 2000).
2.4. Physical Design
The next step in the GIS developing process is physical design. The goal is to logically combine the results in analyze phase with Geodatabase concepts introduced by ESRI Company. As previously mentioned in design phase, ArcMarine is the used model of this project. The model is modified to address all the project requirements.
3. Spatial Data Management
The initial object of developing a GIS for marine application was the need to automate the production of nautical charts and to more efficiently manage the huge amounts of data that are routinely collected at sea. But the extension is made from applications that merely collect and display data to complex simulations, modelings, and the development of new coastal and marine research methods and concepts (Wright, 2003).
The domain has triumphed by successfully adapting to a technology originally designed for land-based applications, and structured in a 2-dimensional framework that has never perfectly matched the ocean environment. However, many challenges remain, such as addressing the multiple dimensionality and dynamism of oceanographic data, handling the temporal and dynamic properties of shoreline and coastal processes, dealing with the inherent fuzziness of boundaries in the ocean (Wright, 2003).