Designing Geodatabases for Transportation. J. Allison Butler

Чтение книги онлайн.

      The most complete version of your geodatabase design is the physical data model, which includes many of the bells and whistles a geodatabase can supply. Classes are more precisely specified, as are their attributes. As with the transition from conceptual model to logical model, changes in the design may occur as you construct or test the physical data model.

      The core of any physical geodatabase model will be object and feature classes. Relationships may be implied by foreign keys or explicitly included as relationship classes. An implicit relationship is called a join relationship and represents association. Explicit relationships may include attributes or merely enforce cardinality rules.

      Domain classes may be added to control data entry by limiting the available choices to a defined set. An enumeration of representative values included in a logical data model must be converted to a fully defined list of values for the physical data model if it is to be reflected in a domain class.

      The geodatabase has rich capabilities that ease the transitional leap from a conceptual to a physical data model. In the past, you would have been required to break down entities in the conceptual model into component parts when you made the transition. The implementation environments for which the physical data model is designed required you to provide the behaviors and data structures necessary to express the full range of characteristics and actions embodied in each entity. For example, with a relational database implementation, you have to create lookup tables for domain control and manage association relationships with software you write. In contrast, the underlying geodatabase data model allows you to implement such behaviors by simply declaring the domain of valid values and stating the rules you want to enforce, all without writing any code at all. At the end of the day, the geodatabase classes you define in the physical data model for a geodatabase implementation look very much like the entities in the original conceptual data model.

      Figure 2.13 Physical data model The physical data model exists to embrace the implementation environment and mold it to the form required by the logical data model. This example is for an ArcSDE geodatabase that includes road centerlines in a polyline feature class, plus states and the routes they contain in two tables. An attributed relationship class handles the many-to-many relationship between State and Route: a state can contain many routes and given route can traverse many states. Four coded-value domains have been included to manage data inputs.

      The next chapter describes the geodatabase and how it works. It also presents some basic techniques of geodatabase design.

       All the data models included in this book were created using Microsoft Visio, which is also supported by ArcGIS for loading database designs into ArcCatalog so as to create classes automatically. Instructions for how to do this are contained in the online ESRI Support Center.

       There are many tools you can use to create data models. If you have a copy of Visio, you will notice that it contains many templates for software and database design following a wide variety of published “standards.” Use the ones that work for you.

       Notes

      ¹ A computer scientist will tell you that these structures are called relations, not tables, and they consist of tuples (rows) and vectors (columns). These terms were chosen to avoid the impression that the data is physically stored as rows and columns in a separate piece of the database. In most RDBMS implementations, all the records in all the tables are stored in one big file. From a database design perspective, it is much better to work with tables containing rows and columns than the more ephemeral concepts of tuples and vectors contained in a table space.

      ² Date, C.J. 1995. An introduction to database systems. Reading, MA: Addison-Wesley Publishing Co.

      ³ See, e.g., Zeiler, Michael. 1999. Modeling our world: The ESRI guide to geodatabase design, pages 81 and 98-99. Redlands, CA: ESRI Press.

       Geodatabases

      • The geodatabase

      • The geodatabase framework

      • The data dictionary view

      • Geodatabase field types

      • Attribute domains

      • Valid value tables

      • Subtypes

      • Relationship classes

      • Origin and destination tables

      • Normalization

      • Tracking events

      This book shows how to build geodatabases that can be easily edited. In chapter 2, the geodatabase was shown to be an object-relational database that the user customized to provide the data and behavior desired. The object-oriented foundation of a geodatabase offers advantages, such as extra functionality, over a purely relational database. Many of the functions you would normally have to program, like domain checking and rule enforcement, are already part of the geodatabase.

      Other geodatabase benefits that are especially useful for transportation datasets are:

      • The dataset is continuous. In the past, traditional spatial data structures needed to subdivide their spatial data into tiles of relatively uniform density. Transportation datasets can be quite large. The geodatabase is continuous regardless of database size so a tiling scheme is unnecessary to efficiently manage data.

      • The data is uniformly managed. Data with and without geometry can be managed in a single repository, assuring that both kinds of data are integrated and internally consistent. This book will show you how to asynchronously edit feature and object classes to preserve referential integrity.

      • Many users can edit the data simultaneously. In larger transport agencies, several workgroups likely would be responsible for editing various portions of the enterprise dataset. The geodatabase can handle simultaneous editing cycles located at multiple sites.

      • Data entry quality assurance is built in. СКАЧАТЬ