Designing Geodatabases for Transportation. J. Allison ButlerЧитать онлайн книгу.
example in figure 3.10 is one you have may have faced in dealing with the domain of functional classes used by the Highway Performance Monitoring System (HPMS). In some states, functional classification determines jurisdiction. Higher functional classes—those that emphasize mobility over land access—are assigned to the state DOT and lower functional classes to various levels of local government. An urban type field makes the example more interesting.
Domain classes can be used to control the values placed in each of these three fields individually, but cannot control combinations of the three fields. For example, you may want to prohibit a combination consisting of interstate highway, rural land use, and local government jurisdiction. There are only certain combinations that are allowable for urban type, functional class, and jurisdiction. For example, the route type representing a combination of rural interstate highway and city jurisdiction may not be valid. The valid route types are contained in the rows of the RouteType_VVT table. By linking the RouteType field in the Route table to the same field in the RouteType_VVT table, you can check the data through an on-the-fly join to see if all the entries are a valid route type.
Subtypes
There will be instances when you need to use subtypes for a class. For example, you may want to use different line symbology for interstate highways and surface streets. But you can also use subtypes to specify a different domain or default value for a field.
Figure 3.11 Subtypes Feature class subtypes can be used to control object behavior. All subtypes share the same attributes and geometry type, but can employ different domains, default values, and rules. Subtypes can improve performance because the speed of most drawing functions is determined by the number of feature classes. Here, we use functional class subtypes to control the default value for RouteDesignator.
In figure 3.11, we use subtypes for a Route table based on the value of the RouteType field. Each subtype will have a different default value for the Route Designator field. This field stores the value representing the entity that can designate a route of that type. For example, the U.S. Route system is managed by the American Association of State Highway and Transportation Officials (AASHTO).1 When we select a route type for a given row in the Route table, ArcGIS will insert the corresponding route designator value, which saves us a little work. Do this for a whole state, and the ArcGIS subtype function has saved us a lot of work.
Relationship classes
If the workspace and dataset ArcObjects structure is the geodatabase’s engine, the relationship portion of the structure is the transmission. ArcGIS supports several kinds of association relationships with explicit geodatabase classes. The conceptual ArcObjects class model shown in figure 3.12 is somewhat misleading. By one classification method, ArcGIS supports simple and composite relationships, but there is no class called “CompositeRelationship”; only a SimpleRelationship class is included. A different classification method would split relationships into those with attributes and those without, but, again, the model only shows an AttributedRelationship class.
The AttibutedRelationship and SimpleRelationship classes are specializations of the abstract Relationship class. Notice that the Relationship class is related through association to the Object class. You know from the earlier examination of the geodatabase’s “engine” that an object is like a row in a table in that it represents one member in an object class. What the association relationship says is that there is one Relationship class entry for each row in each table or feature class involved in a relationship. Through its composition relationship with SimpleRelationship, you can see that a RelationshipClass instance contains all the pointers that tie members of one table or feature class to members of another table or feature class. Attributed relationships work the same way, only they actually include a table to store the additional attributes you can define for such a relationship. (Most attributed relationships are used to resolve many-to-many relationships.) Simple relationships without attributes can be of the one-to-one or one-to-many type. Simple relationships of the many-to-many type require an attributed relationship.
So, where are composite relationships? A composite relationship class is one that enforces the composition relationship. A composite relationship is always of the one-to-many type. In a simple relationship, the two related classes are independent of each other. Deleting a row in the destination table has no impact on the origin table. Deleting a row in the origin table will replace the corresponding foreign key field in the affected rows of the destination table with a null value.
Figure 3.12 Relationship classes The SimpleRelationship class is related to an Object class instance. This association relationship reveals that each row in a table is tied to one or more Relationship class instances when a relationship has been formally established in the geodatabase between two tables, a table and a feature class, or two feature classes. The figure shows that each end in a cardinality relationship has its own Relationship class instance, because the relationship between Object and Relationship is one-to-many. This cardinality is required to support messaging between classes through an explicit relationship and to apply multiplicity rules, among other things. An attributed relationship includes a table to store additional attributes that go beyond merely establishing the relationship of one row to another.
If, however, you have defined a composite relationship, origin table objects are closely tied to their components in the destination table. Deleting a row in the origin table will delete the corresponding rows in the destination table. This process is called a cascade delete.
You can also go the other way in a composite relationship. The composition dependency rule can be enforced by the ArcMap Validate Features command you can run in an edit session to test referential integrity. This check will identify any instance where you create a destination table row (component) without linking it to the class of which it was a component (origin table).
Figure 3.13 Geodatabase relationship classes ArcGIS offers two basic relationship classes, the difference based on whether the relationship itself has attributes. An attributed relationship is normally used to resolve a many-to-many relationship, which requires the class to store foreign keys pointing to each involved class’s members. Both relationship classes support simple and composite types, and require specification of origin and destination tables and the foreign key field. A composite relationship class enforces the one-to-many composition relationship, which means that deleting an origin class row will result in a cascading deletion of all related destination class rows.
The difference between relationship and attributed relationship classes is that the data dictionary view of an attributed relationship will reveal the table it contains. The type of relationship is shown at the top in the data dictionary view. You will also notice that two field parameters are missing from an attributed relationship table: default value and domain.
Each relationship class has a name. You should use a name that tells you what the relationship represents. Below the name is a set of three relationship parameters. Type can be either simple or composite. Cardinality for a simple relationship can be one to one, one to many, or many to many. A composite relationship can only have the cardinality of one to many. The notification parameter tells ArcGIS whether it needs to send a message to a class to make an update triggered by a change in the other class. Notification sets the direction for messages between