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

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 any other relationship between those same classes. Third, relationship classes established between members of a geometric network can produce unexpected results during editing because both the relationship class and the requirements of a geometric network are trying to control referential integrity.

Recursive relationships where members of a class have relationships with each other are not currently supported by ArcGIS. Neither are complex primary and foreign keys. You can only use one field to define a primary or foreign key for a relationship. Custom software can be written to use complex keys. Lastly, if you put a relationship class within a feature dataset, at least one member of the relationship must be in the feature dataset.

By the way, you can have more than one simple relationship between the same two classes. This technique can be used to enforce cardinalities that differ depending on the situation. For example, the multiplicity for a node to the various links it may terminate is one to many with a minimum value of 1, but the multiplicity of a link to its terminal nodes is always 2.