Geodatabase Relationships & Relationship Classes

GIS 458Spring 2006Larry Clamp

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

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

Relationship Classes

Feature Classes: Spatial Objects Tables: Non-Spatial Objects Relationship Classes: Relationships

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

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

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

Relationship Class Properties

Name Labels Type Cardinality Notification Origin/Destination Classes Key Fields

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

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

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

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

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

Relationship Rules

Rules make cardinality more specific Set between subtypes Can make some relationships illegal Help maintain integrity in the

geodatabase

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

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

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

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

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