Select to view content in your preferred language

Relational Geodatabase

495
1
05-17-2019 09:57 AM
KyleGilmer
New Contributor

Has anybody had any succession with a relational geodatabase?

I set up a relationship class between a feature class and a annotation. Now when I edit the feature class the annotation automatically updates.

I'm trying to accomplish the same process but with two feature classes within a geodatabase.

I want a relationship class between two feature classes so that when I edit on of the feature classes it will automatically edit the other one.

For example: One feature class is a street file, the other feature class is a street file that includes school zone data. When I receive new updates, streets to add, or deletion of streets I want to be able to ONLY edit in the street file and the edits automatically update in the street file that includes school zone data. I don't want to do the same edits in two feature classes as this is redundant and takes times.

I already tried to set up a relationship class between two features and tried editing and it did not work.

Can someone help or walk me through this process? 

Thanks!

0 Kudos
1 Reply
DanaNolan
Frequent Contributor

If the street file has a Composite relationship to the other file, deletes of a deleted street's data in the related table will occur automatically. If your workflow includes deleting streets and then adding them back in from somewhere, keep in mind that the deletes will take out the related data, which you would not want.  Nondelete types of transactions require some processing (not much). I don't think I should get into that, as it is not clear what your data structure is and I don't deal with this much.

A good relational design would have only one redundant field, the foreign key (link) field, that is common to both tables. So if your street has a zone id field and the zone data table has one also, you will have to edit that field if the street's zone changes. And the changed zone's data would likely already be in the zone data table because it is associated with other streets so you would have to do minimal editing. That is assuming the zone table really is just about zones; if it is combining street and zone information, the design probably needs a lot of rethinking. Or perhaps a spatial join to refresh data.

0 Kudos