Designing Geodatabases for Transportation. J. Allison Butler
Чтение книги онлайн.
Читать онлайн книгу Designing Geodatabases for Transportation - J. Allison Butler страница 20
Название: Designing Geodatabases for Transportation
Автор: J. Allison Butler
Издательство: Ingram
Жанр: Базы данных
isbn: 9781589482913
isbn:
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 classes. A forward notification goes from the origin class to the destination class. A backward notification goes from the destination class to the origin class. You can also use “Both” and “None” as values for the notification parameter.
Although ArcGIS handles the notification, you will need to supply the software that understands what to do with the message when it is received by a class that does not participate in a composite relationship. For a composite relationship, ArcGIS provides referential integrity behaviors. Deleting an origin class will delete the destination class regardless of the notification setting. Forward notification of an action that moves or rotates a member of the origin class will move or rotate the related members of the destination class. Using “Both” as a notification setting has the same effect.
You should be aware of a few limitations on relationship classes. First, a given class cannot be the destination of more than one composition relationship. Second, if a composition relationship exists between two classes, you cannot establish СКАЧАТЬ