Working with subtypes

Subtypes are records in a table or feature class that have been grouped based on an attribute field. Subtypes are implemented by creating coded values and, therefore, must be associated with fields of the data type short or long integer. These integer values each represent a feature in the subtype. For example, the following codes in a subtype named RoadClass could represent valid classes in a feature class for streets:

0 - Local Streets

1 - Secondary Streets

2 - Main Streets

Each subtype can have its own set of default values. In the above example, the local streets subtype could have the default value for a speed limit attribute set to 25 miles per hour, while the default value for the main streets subtype could be 35 miles per hour. Whenever a local street is added to the streets feature class, its speed limit attribute will automatically be set to 25 miles per hour. Whenever a main street is added, the speed limit will automatically be set to the default of 35 miles per hour.

Each subtype can also have its own range or coded attribute domain for a given field. For example, in a feature class for water mains, a range domain for water pressure can be implemented. The subtype representing transmission water mains can have a pressure between 40 and 100 psi, while the subtype for distribution water mains can have a pressure between 50 and 75 psi.

Each subtype may also have different connectivity, relationship, or topology rules associated with it.

Feature class versus subtype

An important geodatabase design issue arises when you must decide where it is appropriate to use subtypes and where additional feature classes are required. Keep the following in mind when deciding between creating subtypes or new feature classes:

3/4/2014