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

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 notation shows a finished product. What you are creating is a work in progress. You need to add notes that explain what the model says and callouts to describe specific entities and relationships. Business rules and definitions are not generally part of published conceptual models, but you will need them. The only important consideration is that the team members developing the model understand the model. Do not try to adhere to a particular external documentation standard for everything. This is not the time to try to teach everyone about the details of data modeling. There is no extra credit for pretty pictures. Use what works best for you. This book shows you the part that probably should be fairly uniform across teams and will be consistently used in this book.