LITMIR.BIZ

Скачать книгу

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.

       Logical data models

      Logical data models presented in this book use a simplified version of the iconic notation typical of Unified Modeling Language (UML) steady-state diagrams. These diagrams present classes and their relationships. You have already seen the UML relationship notation. You also know a class is the encapsulation of software and the data it needs. We only want to model data. ArcGIS and the geodatabase take care of the software part.

      Figure 2.10 Object classes This is the normal form of UML steady-state data models. Visibility defines the degree to which class attributes and methods are accessible by other classes. This standard symbology is modified to create the graphical standards for logical data models. The two primary changes were omitting methods, which the ArcObjects we might include in the database design already provide, and assuming that all attributes (properties) are open for anyone to see (public). All attributes added to geodatabase tables and feature classes are also public.

      Our data model graphical standards represent a compromise between graphical consistency with UML and other ArcGIS documentation standards. UML is actually used by computer programmers to design their software. The notation is adapted here for use as a data modeling language.

       Although it is common to do so, it is really a bit of a stretch and mismatch to use UML steady-state diagrams as a data model. UML is really for application design. Since the data and software that work on the data are tightly bound through encapsulation, steady-state diagrams do show the data, but with a limited view.

       Normally, a class symbol is a rectangular box subdivided into three parts. The upper part of the class box holds the name of the class. The center part of the box holds the various class properties (data). The bottom part holds class methods (software). However, the bottom part is not required since ArcObjects classes already include the operations needed to implement a geodatabase. So, logical data models for geodatabase designs use a rectangular, two-part box that omits the bottom methods section. All class properties that you add will be public, so the visibility indicator is not required. Class properties can be referred to as attributes, fields, or columns, and such terms as class, table, and feature can be used to refer to the entities in logical data models.

       OK, here is the truth: the other sidebar is lying. You do not actually add properties, in the UML sense of the word, to any ArcObjects class when you create a geodatabase. What you are really doing is using properties and methods that are already in the class. The ArcGIS user interface allows you to access those properties and methods by using wizards and other tools to customize classes so they serve your purposes, but you are not really changing those classes. UML steady-state diagrams are for creating software. You are not creating software; you are designing a geodatabase that is constructed of classes provided by ESRI and, perhaps, one or more of its business partners.

       Think of it like using spreadsheet software. When you get started, all you see is a bunch of little boxes into which you can type numbers, text, and formulas. Anything that happens with the contents of a box is already in the spreadsheet software. You are not creating the spreadsheet software. It is the same with the geodatabase you are designing. The geodatabase is already in ArcGIS. You are just telling it which of its capabilities to use and what the inputs and outputs should be.

       So, UML is really a poor way to create data models, but it is the one we have. If we were starting from scratch to create a new language, we could definitely think of something better

Скачать книгу