Geodatabase Relationships & Relationship Classes

1. Geodatabase Relationships & Relationship Classes GIS 458 Spring 2006 Larry Clamp

2. Geodatabase Relationships • Relationships are associations between geodatabase objects • Can exist between spatial objects • Features in feature classes • Can exist between non-spatial objects • Rows in tables

3. Major Types of Relationships • Topological • Built into data when networks or topologies are built • Spatial • Operations that help determine locations • Intersect, coincidence, overlap, inside of… • General • Explicitly defined to form a persistent tie between objects • Our topic tonight

4. Relationship Classes • Feature Classes: Spatial Objects • Tables: Non-Spatial Objects • Relationship Classes: Relationships

5. Relationship Classes • Link objects between classes in GDB • All combinations of tables & FCs supported • RCs are persisted in GDB • Joins & relates only in map document • Have advanced capabilities • Read-write access • All cardinalities • Simple or composite • Relationship rules • Referential integrity • Versioning supported

6. Advanced Capabilities • Read-write access • Can edit attributes in related classes • All cardinalities • 1-1, 1-many, many-many • May have attributes • Simple or composite • Simple: peer-to-peer • Composite: parent-to-child • Relationship Rules • Rules to refine cardinality based on subtypes • Referential integrity • Performs “cascade delete” • Versioning supported • Allows multiple users in ArcSDE environment

7. Table Relationships • One is the “Origin” • One is the “Destination” – the one linked to • Key Fields • Matching or linking fields in both tables • May have different names • Must be of same data type • Origin Primary Key • Key field in origin class • Destination Foreign Key • Key field in destination class

8. Relationship Class Properties • Name • Labels • Type • Cardinality • Notification • Origin/Destination Classes • Key Fields

9. Names & Labels • Relationship Class names must be unique in the GDB • Relationships may be navigated either direction • Each end need a label for navigation • Labels must be unique only for relationship, not GDB • Visible in ArcMap • Should describe the nature of the relationship

10. Type • Determines how referential integrity is enforced • Simple • “Peer-to-Peer” • Related objects exist independently • Composite • “Parent-child” • Existence of destination objects controlled by origin • Delete origin (parent) and destination (child) ceases to exist • Spatial effect • Moving or rotating origin moves or rotates destination • Feature linked annotation is an example

11. Cardinality • Number of objects in origin that are related to a number of objects in destination • One-to-one • One origin object to one destination object • A parcel can have only one legal description • Also covers many-to-one • One origin object still only matches one destination • One-to-many • One origin object can relate to many destination objects • A parcel can have many buildings • Many-to-many • One origin object can relate to multiple destination objects • One destination object can relate to many origin objects • A property can have many owners and an owner can have many properties

12. Many-to-Many • Requires an intermediate “key” table • Associate key values between classes • ArcGIS generates the fields • User populates records • May choose to store attributes about the relationship • i.e. percentage of ownership

13. Relationship Messages • Primarily used by programmers • AKA “Notification” • Related objects notify each other when they are changed • Can control behavior of composite relationships • Have no effect on simple relationships • Choices: • None: Cascade delete, no feature following • Forward: Cascade delete, feature following, and annotation update • Backward: Cascade delete, no feature following • Both: Cascade delete, feature following, and annotation update

14. Relationship Rules • Rules make cardinality more specific • Set between subtypes • Can make some relationships illegal • Help maintain integrity in the geodatabase

15. Setting Rules • In the properties of an existing relationship class • Set between subtypes • If one rule is set, then others must also be set • No set rule = invalid relationship

16. Referential Integrity • RI manages values of keys fields • Choice of origin and destination is important • When you delete a record in origin, the RC finds related records in destination and sets value of key field to Null • Incorrect choice may damage database

17. RI Examples • Case 1: WRONG • Parcel (origin) to Zoning (destination) • Delete a parcel and the corresponding zone key field is set to Null • Other parcels that have that zoning code no longer have a match • Case 2: RIGHT • Zoning (origin) to Parcel (destination) • Delete a parcel and there is no effect on the zoning • Deleting a zoning code sets parcel key field to Null, which is how it should be • It needs to be re-zoned

18. Creating Relationship Classes • ArcCatalog context menu • Specify name, participating classes, type,a nd other properties • Geoprocessing framework • ArcToolbox>Data Management Tools toolbox>Relationship Classes toolset

19. Relationship Classes in ArcMap • Use them to: • Query • Analyze • Edit • Make Reports • Can view properties of all related objects • To label or symbolize using related records, a join is required • Join based on relationship class