Sei sulla pagina 1di 2

Using ArcGIS Desktop

Specify whether
one record in the
origin relates to
only one record in
the destination; one
record can relate to
more than one record
in the destination; or
multiple records in the
origin can relate to
multiple records in the
destination.

Specify whether the relationship


class will have attributesthat
is, whether each linked pair of
records has associated elds,

such as the percentage of a


parcel owned by a particular
owner. If Yes, an intermediary
table is created, and the Next
button displays a dialog box in
which you dene the elds. Each

record in the table represents a


linked pair of records.

Lastly, specify the


elds in the origin and

destination feature
class/table containing
the common values
used to relate records.
These are known as
keys.

If you specied that the

relationship class contain


attributes or you specied

a many-to-many relate, or
both, an intermediary table
is created. In addition to the
origin and destination keys,
you specify the eld(s) in

the intermediary table that


correspond to the origin
and destination keys.

The nal panel displays

a summary of the

options you specied.

Click Back to make


changes, or Finish to
create the relationship
class.

126

2 Geographic Data Management


On the rst panel of the wizard, you choose one feature class/table to be the origin and another to be the destination.
An edit made to the origin will affect the destination. For example, in the landuse code example above, youd set the

code table as the origin and the parcel feature class as the destination. Deleting a parcel (a destination object) will have

no effect on the code table, and deleting a landuse code (an origin object) will set the value of the code eld in the
matching parcel records to Null, which is as it should be, because they no longer have a matching code table record. If
you set the parcels as the origin, deleting a parcel would set the value for that code to Null in the code table; all other
parcels having that code would no longer have a match in the code table.

When you create a relationship class, you specify whether it is simple or composite. In a simple relationship class, if
you delete a record in the origin table, the value for the corresponding record in the related table is set to Null. In a
composite relationship, destination objects cant exist independently of origin objects, so when the origin is deleted, the

related destination objects are also deleted.

You can have origin and destination objects send messages to notify one another when they are changed, allowing
related objects to update appropriately. For example, updating an origin can require related destination objects to
update. If updating an origin requires related destination objects to update, set the message notication direction to
Forward; specify Backward for the reverse. Or, specify Both. Once youve created the relationship, you must then set
up rules for the objects that receive the messages so they can respond.
The type of relateone-to-one, one-to-many, or many-to-manyis known as cardinality. The parcel/owner example
earlier describes a many-to-many relate (one or more parcels can relate to one or more owners); the landuse code
example is a one-to-many relate (one landuse code relates to many parcels); and the county health statistics example is a
one-to-one relate (each county in the feature class has a corresponding record in the health statistics table).
The common elds that relate the feature classes/tables are called keys. The key eld in the origin class of a relationship
is called the primary key; the key eld in the destination class is called the foreign key. It contains values that match
those of the primary key eld in the origin class. The key elds may have different names but must be of the same data
type and contain the same kind of information, such as parcel IDs.
In one-to-one and one-to-many relationships, values in the primary key of the origin class directly relate to values in the
foreign key of the destination class. Many-to-many relationships, on the other hand, create an intermediate table to map
the associations. When the intermediate table is created, only the elds are generated for you. ArcGIS does not know
which origin objects are associated with which destination objects, so you must manually create the rows. Each row

associates one origin object with one destination object.

The intermediate table of a many-to-many relationship can optionally serve a second purposestoring attributes of the
relationship itself. For example, in a parcel database you may have a relationship class between parcels and owners,

where owners own parcels and parcels are owned by owners. An attribute of each relationship could be the percentage

of ownership. If you need to store such attributes, you can add them to the intermediate table when you create the
relationship or anytime after. When youre setting up a one-to-one or one-to-many relationship, you may have the same
need to store attributes of the relationship. If this is the case, you must specify this when you create the relationship so
an intermediate table is created for you.

Specifying the number of allowed linked records


Once youve created the relationship, you can specify rules to rene the cardinality. In a relationship of parcels and
buildings, for example, you might specify that each building must be associated with a parcel, or that a parcel can
contain a maximum of three buildings. This prevents a user from forgetting to associate a building to a parcel or from
associating too many buildings to a parcel when editing data, and ensures the integrity of the relationships between

feature classes and tables.

127

Potrebbero piacerti anche