Designing Geodatabases for Transportation. J. Allison ButlerЧитать онлайн книгу.
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.
Agile methods
Since modern geodatabase design should be based on data modeling, this book includes a review of that process in chapter 2. But it is important to note that data modeling fits within a larger information technology process. Years ago, data modeling and application development were separate processes. Now, it is generally recognized that the speed of database access determines, to a large degree, application performance. This change is partly the result of application intelligence being built into the database management system, and partly the product of larger datasets with more data types. As a result of the stronger role for databases in application performance, data modeling is now central to application development with both following a common design process.
The agile data modeling and application design approach has been described by many practitioners, such as Scott W. Ambler, a Canadian consultant who has written several books on the subject. It is the key to surviving the changing needs of an organization and the potential solutions offered by technology. Attempting to define all the requirements up front is much riskier than following an agile methodology that can accommodate change. Thus, Designing Geodatabases for Transportation presents an enterprise data model only to demonstrate how all the pieces may be put together, not because the enterprise data model is a necessary first step to implementation. Again, the solutions offered here are more like the choices in a cafeteria: you can pick the ones you want. This book also guides you on making your selections. One size does not fit all.
Figure 1.1 Geodatabase design process The agile geodatabase design process illustrated here starts with a draft design based on a set of user requirements. Design components are tested through prototypes to ensure that the overall architecture and its key parts work and then the design is revised to correct any observed problems. A pilot is tested for scalability to ensure the design’s performance meets requirements under production load. (The Geodatabase Tool available as a free download from ESRI can help here.) The design is revised and tested again before the system is put into production. Although the figure stops there, the reality is that new user requirements are likely to be imposed following production deployment and the cycle begins again.
The agile method uses an iterative, team-based approach. Members of the team are not given separate assignments; all team members work together on each assignment. The ideal team member will have broad knowledge of the organization and its operational needs, the general requirements of the agile method, and expertise in one or more areas required for design development and implementation. The hallmarks of the agile method are its use of “good enough” documentation, which includes data models; frequent deliveries of solution components to get user feedback; and structured performance testing at the planned scale of deployment (number of users, transaction types and volumes, etc.). The number of and execution time for database queries and related operations determine geodatabase performance and, thus, application performance. While there may be several ways to reach the same result, you will want to use the one that provides the greatest performance. No one likes to wait. The only way to know which approach provides suitable performance is to test it under real-world conditions. Performance testing must be part of the geodatabase design process.
Figure 1.2 Agile design process at the enterprise level This figure shows the agile design process with extra structure when applied to an entire enterprise. The box on the right includes four of the eight components shown in figure 1.1. The four boxes on the left side provide the enterprise context for the agile process. High-level requirements define the overall scope. The system architecture defines the deployment environment, such as which relational database management system (RDBMS) product will be used, who will have responsibility for system maintenance, where the hardware will be located, and other constraints. Proof-of-concept prototypes may be necessary to ensure that the system architecture will perform as expected under production loads.
When you seek to apply the agile method to an entire enterprise, you need to break the project into deliverable components that fit within an overall framework. The enterprise framework allows the organization to balance the needs of various internal and external communities competing for limited development resources and to test fundamental aspects of the overall system architecture vital to major parts of the final system.
It has not been assumed that the enterprise of interest is a transport agency. This book takes into account the fact that many transportation data users do not actually care that much about transportation per se. These users need transportation data as a reference plane for other information, such as situs addresses tied to relative position along a transportation facility (street address). Map making is generally placed in this category. Thus, this book will show how to build transportation-oriented geodatabases that can support the editing of data needed by a variety of applications. The focus will not be solely on the more extensive data models suitable for larger organizations. The book starts with simple problems and solutions, growing in complexity in response to application requirements until it reaches the most complex problems posed by large transport agencies and transit operators. Some chapters, such as those on navigable waterways and railroads, are actually directed to users outside these industries.
Designing Geodatabases for Transportation also does not assume you are starting from scratch. The more common starting point today is the migration of a transportation dataset based on the coverage or shapefile structure to a geodatabase, often in the midst of making other changes. A common concurrent technology change is adopting a relational database management system (RDBMS) for overall data storage. Indeed, the migration to the geodatabase structure often marks the point where spatial data goes from being concentrated in workgroup datasets to becoming an enterprise resource available to the entire organization. In any event, you probably are not starting with a blank sheet of paper but rather are dealing with a number of prior decisions you need to identify in the requirements analysis and system architecture steps. You will rely on your agility to work within an existing data structure serving a number of existing applications and within a prescribed set of constraints and resources.
Building the agile geodatabase
Your task will be made much easier if you build an agile geodatabase. This starts by separating the editing geodatabase environment from the published dataset. The purpose of any GIS application is to create information. You have to put data into an application in order to get information out. No single book can show you the answer to every geodatabase design problem given the vast range in possible applications, even if the scope is restricted to a single data theme. So, instead of trying to solve all transportation application problems, Designing Geodatabases for Transportation seeks to solve only one: creating information out of original data sources, which is data editing. The data thus maintained is then used to populate datasets supporting other applications, each of which presents its own data structure and content requirements. The outputs of the editing process are defined by all the other applications.
Many of the applications’ data requirements are likely to suggest geodatabase design characteristics that work against the data-editing process. What you really need to do is view data editing as its own application, one that creates the inputs to all the other applications, and then follows the mantra that the application determines the geodatabase design. For example, eliminating data redundancies greatly benefits data editing by keeping each piece of information in a single location so you do not have to enter it multiple times. Thus, a geodatabase optimized for editing will eliminate data redundancies