To Use or Not to Use Relationship Classes?

Question

I am building a government database from a massive amount of data. Now I am following the standard approach of the ESRI Local Government Data Model, but modified to fits the needs and wants of a specific government.

I've noticed that in the Local Government Data Model ESRI uses a lot of relationship classes. I've used relationship classes in the past, but tend to steer clear of them. This is because I usually don't see a reason why I would want attributes about a shape in a separate table from the feature class.

For almost all of the data I am assembling I still cannot see a reason for this. For Parcel Fabric I can see some reasons where it would be helpful, but still I believe it would be best to still keep the attributes directly in the feature class.

Now to be clear I am going to use relationship classes to reference feature classes to feature classes, this question is more specified to why I would store data in a non-spatial table that could just as easily be store in a feature class.

Anyways thanks for any input folks!

Answer 1

The reason that people organize data in separate tables is because of Database Normalization principles (follow the link, all the rationale is there). That being said, ESRI Relationship Classes are a GeoDatabase-level implementation of a those principles. Honestly, I would personally only use them in two instances:

• when you have some data that is normalized in the DB and you want to leveraging ArcMap editing tools. ArcMap allows you to (arguably) easily traverse the relationships in their tools.

• when you are using a GeoDatabase abstraction that is in need of the GeoDatabase messaging (e.g feature-linked annotation, custom feature classes, etc).

Although people may claim that referential integrity is one of the benefits, the truth is that it can be circumvented with a SQL prompt, so the benefit of this really depends in the workflow that you have for modifying that (i.e do people use only ArcMap to edit vs do people also edit with SQL queries or non-ESRI tools).