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 first philosophical debate. You’ll find such common entities as Road, Railroad Track, Bridge, and Airport will often have very different meanings throughout the agency. What do we mean by Route? Is it the continuous piece of pavement that winds through many states, each one assigning its own name to it? Or does the name itself define the extent of a route? If the latter, what happens when the name is changed or the route takes a different path due to construction? How about if the road is realigned in some way so that the length changes? Does Road include Right of Way as an element, or is Road an element of Right of Way? Is Airport a piece of land, a terminal, a collection of runways, or an airspace? Is Railroad Track one set of rails, with a section of double-tracked mainline being two Railroad Track members, or is Railroad Track like Road, where each track is equivalent to a lane of traffic and the number of tracks is an attribute? Is a Bridge across an interstate highway part of the interstate or the road that crosses the Interstate? Answering such questions is intense, emotional, and necessary. You will quickly discover that the most important relationships are those in the room, not those shown in the data model.
A conceptual data model shows entities and their relationships. It does not include attributes. A conceptual data model expresses central concepts, illustrates data structures, and describes components of the ArcGIS object model. You will use conceptual data models to translate user requirements into data structures. Creating the data model usually begins the process of developing the application ontology, which includes formal definitions for all the entities, attributes, and operations that will be part of the final design.
Figure 2.9 Conceptual data models The intent of a conceptual data model is to express the entities and relationships in a highly abstract manner. Attributes and methods are not included in a conceptual model, so the complex notation of UML is not required. Indeed, it may serve to obscure the model’s meaning.
Figure 2.9 illustrates the simple 2D and 3D boxes used for conceptual data models. This is the same graphical standard used for many ArcObjects diagrams contained in ESRI documentation. For our purposes, conceptual data models consist of entities, not classes, and no one-for-one equivalency should be assumed; however, ArcObjects models presented with the same symbology do have equivalencies between entities and classes. In both cases, entities will be shown as one of three types. An abstract entity will be shown with a 2D rectangle and the name in italics. Instances of an abstract entity will not be implemented. Abstract entities form stereotypes for other entities that can be implemented.
Entities that are not abstract will be shown using a 3D cube, with a slight difference in face color between instantiable and creatable entities. This distinction really only applies to conceptual ArcObjects models representing a class structure. All non-abstract ArcObjects classes are instantiable in that members of each class (objects) can be generated. An instantiable class, as that term is used in this context, is one that is creatable only by other ArcObjects classes. Members of a creatable class can be instantiated by the user directly through ArcGIS. True conceptual data models will include only creatable entities, because users cannot generate instantiable entities directly.
The figure does not include notes and callouts, two of the most useful parts of the conceptual data model. ESRI’s standard
