Attribute domains are rules that describe the legal values of a field type. They are used to constrain the values allowed in any particular attribute for a table or feature class. They provide a method for enforcing data integrity by limiting what can be placed on a field to a valid list or range of choices. If the features in a feature class or nonspatial objects in a table have been grouped into subtypes, different attribute domains can be assigned to each of the subtypes. Whenever a domain is associated with an attribute field, only the values within that domain are valid for the field. In other words, the field will not accept a value that is not in that domain.
Attribute domains can be shared across feature classes, tables, and subtypes in a geodatabase.
For example, a feature class for water mains and a feature class that stores water laterals can use the same domain for the ground surface type field.
Domains view
Domains are created and edited within their own tabular-style view called the domains view.
The domains view can be opened by clicking the Domains button found in the Design group on the Data tab, or on the Fields and Subtypes tabs available with the fields and subtypes views.
Within the domains view you can view existing domains, edit their properties and values, and create new domains.
You can filter the domains listed in the view using the Filter Text text box on the Domains tab available with the domains view. As you enter text, the view updates with only those domains that have matching text in the domains view fields.
In the image below, you can see the domains view displaying some of the domains associated with the Campus Editing data model.
Each row in the view is an existing domain and they all share common properties such as a name, description, field type, domain type, and split and merge policies.
Domain properties
When creating or modifying a domain, you must edit the following properties.
Name and description
When creating a new domain, you specify a name that will describe the parameter it governs. The characters ' and `, a single quote and an apostrophe, may not be used when naming a domain. After a domain is created, the domain name is displayed in the domain drop-down menu when choosing a domain to associate with a given field in fields view or subtypes view.
The description is a small sentence describing the purpose of the domain.
Field type
The field type is the type of attribute field with which the domain can be associated.
The field type can be set to any of the following:
- Short—Short integers
- Long—Long integers
- Float—Single-precision floating point numbers
- Double—Double-precision floating point numbers
- Text (Coded domains only)—Alphanumeric characters
- Date—Date and time data
Once the field type is set, the name of the domain will appear in the domain drop-down list for any field of that type in fields view and subtypes view.
Domain type
When you create a domain, you must specify which type of domain you want to use.
There are two types of attribute domains:
- Range domains—A range domain specifies a valid range of values for a numeric attribute. When creating a range domain, you enter a minimum and maximum valid value. A range domain can be applied to short-integer, long-integer, float, double, and date attribute types. For example, in a feature class for water mains, you could have subtypes for transmission, distribution, and bypass water mains. Distribution water mains can have a pressure between 50 and 75 psi. For a distribution water main object to be valid, its pressure value must be entered as some value between 50 and 75 psi.
- Coded domains—A coded value domain can apply to any type of attribute, be it text, numeric, date, and so on. Coded value domains specify a valid set of values for an attribute. For example, water mains may be buried under different types of surfaces as signified by a GroundSurfaceType attribute field: pavement, gravel, sand, or none (for exposed water mains). The coded value domain includes both the actual value that is stored in the database (for example, 1 for pavement) and a more user-friendly description of what that value actually means. Validation for coded value domains is accomplished by restricting the user to choose field values from a drop-down list.
Split and merge policies
Often, when editing data, a single feature is split into two features or two separate features are combined, or merged, into a single feature. For example, in a landbase database, a land parcel may be split into two separate land parcels due to rezoning. Similar zoning changes may require two adjacent parcels to be merged into a single parcel.
While the results of these types of edit operations on the feature's geometry are easily predictable, their effects on the attribute values are not. The behavior of an attribute's values when a feature is split, if that attribute has a domain applied, is controlled by the domain's split policy. When two features are merged, any attribute with a domain applied will have its value controlled by the domain's merge policy.
Note:
If there is no domain assigned to a field, the attribute values are copied from the original feature to the new feature.Note:
If the original field has a value of NULL, the new feature will also have a value of NULL.Each attribute domain has both a split policy and a merge policy. When a feature is split or merged, the geodatabase looks to these policies to determine what values the resulting feature or features have for a particular attribute.
Split policies
An attribute for any given table, feature class, or subtype that has a domain applied can have one of three split policies, set on the domain's properties, that control the value of an attribute in the output objects:
- Default value—The attributes of the two resulting features take on the default value for the attribute of the given feature class or subtype.
- Duplicate—The attribute of the two resulting features takes on a copy of the original object's attribute value.
- Geometry ratio—The attributes of resulting features are a ratio of the original feature's value. The ratio is based on the ratio in which the original geometry is divided. If the geometry is divided equally, each new feature's attribute gets one-half of the value of the original object's attribute. Geometry ratio policies only apply to domains for numeric field types.
Merge policies
When two features are merged into a single feature, merge policies control the value of attributes in the new feature.
An attribute for any given table, feature class, or subtype that has a domain applied can have one of three merge policies, set on the domain's properties, that control the value of an attribute in the output objects:
- Default value—The attribute of the resulting feature takes on the default value for the attribute of the given feature class or subtype. This is the only merge policy that applies to nonnumeric fields and coded value domains.
- Sum values—The attribute of the resulting feature takes on the sum of the values from the original features' attributes.
- Geometry weighted—The attribute of the resulting feature is the weighted average of the values of the attributes from the original features. This average is based on the original feature's geometry.