Designing Geodatabases for Transportation. J. Allison ButlerЧитать онлайн книгу.
alt="image"/>
Figure 2.8 Relationship types Data models at all levels of abstraction include relationships. This minitutorial explains the five primary types that you see in ArcGIS: association, type inheritance, instantiation, aggregation, and composition. All relationships are illustrated using a line and endpoint symbols.
Composition and aggregation are similar to each other with one important difference. A composition relationship is created when one class is composed of one or more instances of other classes. For example, a building may be seen as being composed of at least three walls, one floor, and one roof. Remove the building and its components cease to exist, at least as far as the database is concerned. Thus, a composition relationship tells you that when the sum of the parts is deleted from the database, you will also need to delete the objects of which it is composed. A thin black line with a solid-black diamond at the end adjacent to the composite class represents this kind of relationship.
Aggregation is not so particular. An aggregation relationship specifies that a class is a collection of other classes. For example, a baseball team may be a collection of players. If you express this relationship through aggregation, then you are saying the players will continue to exist in the database even when they do not belong to a team. If you instead use composition, then the players must be deleted from the database when the team is dissolved. Aggregation symbology is similar to that for composition, except that the diamond is outlined in black and white filled.
The data-modeling process
You need a good data model to produce a good geodatabase design. Developing a geodatabase design is a six-step process that follows the flow of the agile methods discussed in chapter 1:
Step 1—Define user requirements. First, you need to know the purpose of the data, the application requirements to be supported. Many users attempt to develop a complete set of requirements as the first step, but that cannot be done. Even for a small project, the agile method instead encourages you to create a good first effort that has the primary objective of identifying the major components. For an enterprise geodatabase that will support a wide variety of existing and yet-to-be-created applications, seeking a complete set of requirements as the first step is an impossible goal. No, your task here is to identify the general requirements.
Step 2—Develop conceptual data model. Once you have specified the general requirements for the final product, you will need to identify the basic elements of a geodatabase that meets the requirements. Such elements consist of entities and their relationships. An entity may eventually be reflected in a class, but at this point in the process, you cannot establish a one-to-one equivalency between entities and classes.
Step 3—Develop a logical data model. Once the general structure of the database—the skeleton—is established, the next step is to add some meat to the bones by specifying attributes for the geodatabase. Entities may change at this point, as attributes are assigned and new relationships discovered. The logical model is independent of the planned implementation platform.
Step 4—Develop a physical data model. Here is where entities become classes and the implementation platform makes a difference. Your RDBMS, network structure, and organizational behaviors will influence the way you translate the logical design into a physical implementation. The added benefits of the geodatabase and ArcGIS will become apparent at this stage. The geodatabase can perform many functions that would normally have to be handled by user-developed software. For many geodatabase projects, the first task will be to split entities into tables and feature classes. You will also need to decide which fields can be supported by domain classes and which relationships need to be instantiated as a relationship class, not just an implicit relationship established by foreign keys you use when you desire. You need to be alert to the difference between layers on a map and components of the geodatabase. The next task is to specify the details of each class and create the domains, rules, and other elements of a geodatabase. The physical data model specifies the data type, default value, domain, and other characteristics of each attribute. The logical data model tells you about the classes and their attributes, although you may not implement the whole model at one time, and tests may motivate changes to get the desired performance.
Step 5—Test the data model. Next, you can load the physical data model into ArcGIS and generate a prototype database for testing. Many central elements of a transport geodatabase can be implemented in more than one way. Testing the prototype before you put it into production is a good way to evaluate the efficiency of the implementation choices you made. Testing should include typical editing operations and involve a sample dataset equivalent in size to the one you will use. If the design does not pass this test, it may be necessary to go back to step 3 or 4 to make other choices, but it is much better to find out now than after you put it into production use.
Step 6—Production implementation. Now you can reap the rewards of your work. Load the geodatabase and create the default version. It is time to put everyone else to work.
These steps are generally sequential but you may move backward whenever necessary to redesign a portion of the geodatabase. You may also choose to prototype parts of the design at points well before step 5 so as to test key components. What works great for one agency may be a bad idea at another because of an organizational difference or the combination of applications to be supported. It is much cheaper to debug a paper design than an implemented geodatabase. Modeling will not eliminate all chance of error, but it certainly improves the odds of success. The balance of this chapter will explore the differences between conceptual, logical, and physical data models at one time, and tests may motivate changes to get the desired performance.
The help section of ArcGIS online presents an 11-step geodatabase design process rather than the six shown here. The difference is due to how transportation datasets are structured. The 11-step process is oriented toward feature classes and map display. It starts with a discussion of the key thematic layers and selection of geometric abstractions. In contrast, transportation datasets are typically oriented toward object classes (tables), with geometry being a secondary consideration. While map outputs may be useful, most people editing and using a transportation dataset do so outside the map interface typically associated with GIS.
The six steps shown here are in the 11 steps of the traditional geodatabase design method, which also includes such tasks as specifying the scale range and spatial representation of each data theme at each scale; designing edit workflows and selecting map display properties; and documenting your geodatabase design. You may, indeed, want to use some of these additional steps at points in the process, except documenting the design, which you’d better be doing continuously! You will certainly want to make sure that someone is assigned to putting every piece of data into the geodatabase and keeping it current. You can add spatial-display details when you decide how to geometrically represent some of the entities in your data model, but this not required until you get to the physical data model.
Conceptual data models
Data models typically go through three phases of increasing specificity, starting with conceptual modeling. This phase is primarily concerned with identifying the entities about which you will need to retain data and the relationships between those entities, including some that will also need descriptive data. Conceptual modeling considers the application the data is to support and defines database terms. For example, if you are developing a geodatabase for a transportation agency, you will need unambiguous definitions for terms that will appear in the model. This set of definitions is called an ontology.
Here is where you should expect your