Table to Relationship Class - anthonyblackham/GIS-Wiki GitHub Wiki
Generally you'll want to use relationship classes when you have a many to many relationship between two tables.
For example I have a map of properties and I have a database of documents that correspond to the properties on my map.
- Some documents correspond to one property
- Some documents correspond to multiple properties
- Some properties correspond to one document
- Some properties correspond to many documents
because multiple properties can correspond to multiple documents and vice versa, we have a many to many relationship.
The following tables are an example of the data. The Document Table has all of my documents, the Property Table is the attribute table of my property feature class, and I've created an intermediate table showing which documents correspond to which properties (though the intermediate table could also be automatically generated as part of making a relationship class assuming the tables had the relevant fields to match.)
(1) Document Table:
OBJECTID | DOCUMENT |
---|---|
1 | doc1 |
2 | doc2 |
3 | doc3 |
4 | doc4 |
(2) Property Table:
OBJECTID | PARCELNUM |
---|---|
1 | 3600 |
2 | 3700 |
3 | 3800 |
4 | 3900 |
(3) Intermediate Table:
OBJECTID | PARCELNUM | DOCUMENT |
---|---|---|
1 | 3600 | doc1 |
2 | 3700 | doc1 |
3 | 3800 | doc3 |
4 | 3800 | doc4 |
5 | 3900 | doc5 |
Toolboxes
>>System Toolboxes
>>Data Management Tools
>>Relationship Classes
>>Table to Relationship Class
(or you can just search for Table to Relationship class, its faster)- Origin table will generally be your feature
- Destination table is the table you want to be returned when identifying the feature
- Output relationship class is the file geodatabase where you want it saved
- Relationship type in this case will be simple
- Forward path label (Destination Table)
- Backward path label (Origin Table)
- Message direction (if you want edits propagated to the other tables you'll want something other than none)
- Cardinality (many to many)
- Relationship Table: this is our intermediate table we defined
- Attribute fields. check the attributes you wish to keep
- Origin Primary Key (unique field from Origin Table (feature))
- Origin Foreign Key (Unique field from Intermediate table (feature))
- Destination Primary Key (Unique field from destination table (docs))
- Destination Foreign Key (Unique field from Intermediate Table (document))
Unlike when we created a query table, this time the features aren't duplicated, rather one feature shows a related table of both documents that correspond to that property.