Field names are the names you give to the columns in a table. The names should give an indication of what data is contained in that particular column. For example, when you create a new feature class in ArcCatalog, the table is already populated with an ObjectID field and a Shape field. The ObjectID field contains the unique ID number for each object in the feature class. The Shape field defines what type of shape is stored in the feature class—point, line, polygon, multipoint, or multipatch.

You might also consider using set phrases to indicate the type of column. For example, if you create a separate unique ID on a table that you will use for indexing purposes, you might name the field ID_UK—the UK indicating this is a unique key.

Field names in the same table must be unique; for instance, you can't have two columns with the name ObjectID. Field names must also start with a letter and not contain spaces or reserved words. Field names are limited to 31 characters (30 characters in geodatabases in Oracle and DB2).

As mentioned in the table name section, certain field names will appear in ArcGIS with their fully qualified names for tables stored within an ArcSDE geodatabase. For example, if you create or import a polygon feature class that contains a field named Area, the database, schema, and table name will be appended to it. This is the name you will see in the attribute table of the feature class. That means for a polygon feature class named archsites stored in the prof schema of the museum database, the Area field would look like this:

MUSEUM.PROF.ARCHSITES.AREA

The following list contains all the field names which will be fully qualified within an ArcSDE geodatabase:

FID, AREA, LEN, POINTS, NUMOFPTS, ENTITY, EMINX, EMINY, EMAXX, EMAXY, EMINZ, EMAXZ, MIN_MEASURE, MAX_MEASURE

For cases such as this, you might consider using a different field name or a field alias.

Field aliases

Field aliases allow you to assign an alternate name for a field. You will normally use field names that are as short as possible to convey what data is stored in that field. You also cannot use spaces or special characters in the field name and, as shown above, certain fields show up in the table with their fully qualified names. In these cases, you could use a field alias to give the field a more descriptive name. For example, if you had a field named ST_SUFX that stored the type of street, which was indicated by the suffix used on the street name, you could give this field an alias of Street name suffix.

Since field names themselves cannot be changed, if you later decide you want the name to appear differently, you can use an alias to "change" the field name users see. If you created the ST_SUFX field and populated it, then decided SUFX wasn't useful, you could use a field alias so the users see Street type instead of ST_SUFX.

Learn how to set a field alias.

Tip

• Geoprocessing methods exist to let you validate table and field names. See the topic "Validating table and field names" for more information.

Attribute domains are rules that indicate valid values for a field. They enforce data integrity by restricting what data values a user can add to a particular field.

You would apply attribute domains to fields only if there was a definable set or range of specific values possible for that field. For example, a field that stores the answer to the survey question "What is your favorite food?" would be difficult to apply a domain to, since there is a large number of responses that can be given. However, a field storing data on eye color could have an attribute domain assigned to it, because there are only a few possible valid values.

• Black
• Brown
• Blue
• Green
• Hazel
• Gray
• Violet

Using an attribute domain for a field storing eye color data would ensure consistency of the values. If data collectors were allowed to type any color into a text field for eye color, you might end up with any of the following for "blue" eyes:

• Azure
• Navy
• Sky blue
• Cobalt
• Aquamarine

Attribute domains also prevent misspellings or typographical errors. Even if data collectors knew only to use the term blue for blue eyes, they might misspell the word (bleu) or mistakenly strike the wrong key when typing "blue" (vlue) into a text field.

Types of attribute domains

There are two types of attribute domains you can use to restrict field values:

Coded value domain—Uses codes to define a set of allowed values for a field that stores discrete data

You can use a coded value domain for any data type. For the eye color field, you could create a coded domain. Examples of two possible code sets are

Blk = Black

Brn = Brown

Blu = Blue

Grn = Green

Hzl = Hazel

Gra = Gray

Vlt = Violet

Or

1 = Black

2 = Brown

3 = Blue

4 = Green

5 = Hazel

6 = Gray

7 = Violet

Range domain—Defines a range of allowed numeric values for a field

The field must be a numeric or date data type to use a range domain. An example of a field to which you might apply a range domain is one that stores data on birth weights for single live births of western lowland gorillas in zoos. The range would run from the lowest weight (1 kg) to the highest (2.5 kg).

For additional information on attribute domains, see An overview of attribute domains.

To learn how to create an attribute domain, see Creating new attribute domains.

Subtypes are classifications within a feature class or table. They allow you to logically group features based on a unique characteristic or behavior of the data. This characteristic or behavior is represented by the values of one field in the table. For example, for a table of hydrology, you could have subtypes for different types of waterways, such as creeks, streams, channels, canals, and rivers. For each of these subtypes, you could apply different topology rules, connectivity rules, default values, and relationships rules.

Using subtypes to store groups of related features can improve query performance. If you stored the different types of data in separate feature classes instead of utilizing subtypes, you would have a greater number of feature classes in the database and it could take longer to search.

Rules about subtypes

• Only one field in a table or feature class can have subtypes applied to it.
• To use subtypes, the field on which you base the subtype must be a long or short integer field.
• You can apply different topology and relationship rules to different subtypes. You can also apply different attribute or coded domains to other fields in the table based on subtypes. Note: You apply the domain to a field for a specific subtype.

To apply subtypes

1. Make sure the field to which you want to apply the subtype is a short or long integer field. If it is not, add a short or long integer field to the table or feature class. In most cases, short integer should suffice. However, if there is any possibility your subtype values could exceed 32,767, use a long integer field.
For example, for a feature class of rivers, you could add a short integer field called Watershed to create subtypes based on the watershed to which the river contributes.
2. On the Subtypes tab of the Properties dialog box for the table or feature class, specify the subtype field by choosing it from the first drop-down list.
For the rivers example, you would choose the Watershed field from the Subtype Field list.
3. A new subtype is automatically added to the Subtypes table. This default subtype has a code of 0 and a Description of New Subtype. You can double-click in each of these fields to type the subtype code and description that you want.
You could change the first code to 1 and the description to the name of the first watershed.
4. To add more subtypes, continue adding subtype codes and descriptions to the Subtypes table.
In the field below code 1, you could add a code 2 with a corresponding watershed name in the Description field, then below that, add a code 3 with a corresponding watershed name, until you had created codes and descriptions for all the watersheds represented in your rivers feature class.
5. To specify different default values or domains per subtype, click a subtype in the Subtypes list. In the Default Values and Domains list, you can type a default value for any of the fields in the list. You can also apply a coded or attribute domain to fields in the list by clicking in the Domain field and choosing a domain from the drop-down list. If no domains exist yet, you can create a new one by clicking the Domains button at the bottom of the Properties dialog box, which will take you to the Workspace Domains dialog box.
The default values and domains you specify apply only to the subtype you chose from the Subtypes list. If you click on another subtype in the Subtypes list, the default values and domains will either be empty (if you haven't specified default values and domains for this subtype) or will contain different values.

Learn more about subtypes.