Читать книгу Designing Geodatabases for Transportation - J. Allison Butler - Страница 11

Geodatabase design is normally expressed through a data model, which is a graphical way of describing a database. A data model is essentially a set of construction plans for a database. Some data models are very conceptual, others extremely detailed. Fortunately, all data models use a few very simple symbols. You need no prior experience with data models or geodatabase design to understand and apply the suggestions in this book.

All geodatabases form a set of abstract representations of things in the real world. The process of abstraction is called modeling. You may geometrically represent linear transport facilities in your abstract geodatabase world as lines. In the real world, of course, transport facilities are areas, which may be less abstractly represented by polygons. Unfortunately, many of the analytical techniques you will want to employ, such as pathfinding, do not exist in the polygon world. This is not really a problem, though, because the central aspect of a linear transport facility is its linearity, so points and lines form the abstract world of most transport geodatabases.

Whether you formally draft a data model or not, one exists inside each geodatabase. It may also exist externally as a set of requirements, a list of class properties, or some other description of the geodatabase’s contents and structure. ESRI’s ArcGIS software comes with tools to produce a data model from an existing geodatabase. As geodatabases grow from supporting isolated workgroups to major portions of a complete enterprise, the complexity of geodatabase design normally increases in proportion to the number of data uses. Explicit data models and other documentation become more important as the scope of a geodatabase expands or it begins to serve a critical function within the organization. As a result, many organizations have invested significant resources into developing a good data model before moving forward with geodatabase development and migration projects. More comprehensive and ambitious projects seek to deploy at the enterprise level.

Building a good enterprise geodatabase starts with an enterprise data model. Accordingly, this book expands and enhances the previous ESRI transportation data model, UNETRANS (Unified Network for Transportation), developed by the University of California at Santa Barbara (UCSB) with financial support from ESRI. The “new and improved” UNETRANS is designed to provide a full structure that embraces all of a large organization’s data and access mechanisms. This enterprise data model also takes advantage of technological advances in the ArcGIS family since the original UNETRANS was developed several years ago.

However, developing an enterprise data model need not be the first step in creating an enterprise geodatabase. Your organization may first want to construct a workgroup prototype to gain experience with the geodatabase structure and how to use it. Effective geodatabase design and deployment is an ongoing process. The needs of the organization and the capabilities of the technology both evolve. You will need an enterprise architecture that describes the computing environment and its business rules. Everything else will be somewhat reactive because you cannot possibly anticipate all data uses. You must be agile.