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

The most complete version of your geodatabase design is the physical data model, which includes many of the bells and whistles a geodatabase can supply. Classes are more precisely specified, as are their attributes. As with the transition from conceptual model to logical model, changes in the design may occur as you construct or test the physical data model.

The core of any physical geodatabase model will be object and feature classes. Relationships may be implied by foreign keys or explicitly included as relationship classes. An implicit relationship is called a join relationship and represents association. Explicit relationships may include attributes or merely enforce cardinality rules.

Domain classes may be added to control data entry by limiting the available choices to a defined set. An enumeration of representative values included in a logical data model must be converted to a fully defined list of values for the physical data model if it is to be reflected in a domain class.

The geodatabase has rich capabilities that ease the transitional leap from a conceptual to a physical data model. In the past, you would have been required to break down entities in the conceptual model into component parts when you made the transition. The implementation environments for which the physical data model is designed required you to provide the behaviors and data structures necessary to express the full range of characteristics and actions embodied in each entity. For example, with a relational database implementation, you have to create lookup tables for domain control and manage association relationships with software you write. In contrast, the underlying geodatabase data model allows you to implement such behaviors by simply declaring the domain of valid values and stating the rules you want to enforce, all without writing any code at all. At the end of the day, the geodatabase classes you define in the physical data model for a geodatabase implementation look very much like the entities in the original conceptual data model.

Figure 2.13 Physical data model The physical data model exists to embrace the implementation environment and mold it to the form required by the logical data model. This example is for an ArcSDE geodatabase that includes road centerlines in a polyline feature class, plus states and the routes they contain in two tables. An attributed relationship class handles the many-to-many relationship between State and Route: a state can contain many routes and given route can traverse many states. Four coded-value domains have been included to manage data inputs.

The next chapter describes the geodatabase and how it works. It also presents some basic techniques of geodatabase design.

All the data models included in this book were created using Microsoft Visio, which is also supported by ArcGIS for loading database designs into ArcCatalog so as to create classes automatically. Instructions for how to do this are contained in the online ESRI Support Center.

There are many tools you can use to create data models. If you have a copy of Visio, you will notice that it contains many templates for software and database design following a wide variety of published “standards.” Use the ones that work for you.