Attribute domains
An attribute domain is a rule that limits users’ data entries to a specific set of valid choices. A domain is a declaration of acceptable values for a field. Data quality is improved if you can keep obviously bad data out. Someone may still make a bad choice, but at least it is not something completely unexpected.
Figure 3.7 Domain control To ensure that only valid data gets into the database, you must control data entry. A common approach is to convert relatively limited value domains to a list of valid choices, each of which is represented by an abbreviation, called a code. The coded value can be put in a data table as a foreign key that points to a “lookup table” that stores what the value really means. (The code attribute is a candidate key, so it meets the requirements for this one-to-many relationship.) This operation requires software that can check an entry against the legitimate values stored in the look-up table. Attrib2 contains foreign key values tied to Lookup Table : Code. Every person who writes a computer program to utilize the same lookup table must provide the same code.
A lookup table is the traditional way to control a domain consisting of a finite list of choices. You create a column in the entity attribute table that includes a foreign key to the lookup table that contains the meaning of various coded values. Your data entry application builds a pick list from the lookup table’s rows, and users pick one of the available selections. This process requires you to create a table for each domain you want to control and write the software needed to get the input screen to go to the lookup table for the values of each field it controls.
Figure 3.8 Geodatabase domain control classes The geodatabase supports two domain control methods: numeric range and coded values. Domains are named and apply to an entire workspace, even across datasets within that workspace.
The geodatabase greatly reduces your workload when using attribute domains. You need only tell ArcGIS what you want to do and it takes care of the work. The earlier geodatabase conceptual class model showed the abstract Domain class. Figures 3.8 and 3.9 show the details. There are two specializations of the Domain class, one for numeric range domains and one for coded-value domains. Using the domain control function in ArcGIS is fairly simple.
First, specify a domain name. You also can enter a small description for what the domain contains. You will enter the domain name in the data dictionary row describing a field each time you use this domain.
Next, specify the data type, which must be the same as any field to which you apply the domain. You can use text, short integer, long integer, float, double, and date data types in a domain class.
Then tell ArcGIS which kind of domain you want to use: numeric range or coded value. For a numeric range domain, specify the minimum and maximum values. For a coded-value domain, list the code and (optionally) its description. The data type of the code value must match that of the domain class.
The last thing you tell ArcGIS is the split and merge policies to employ. A split policy will control what value is entered in the new child objects when the parent is split. Specify one of three choices: default value, duplicate, or geometry ratio. The default value policy means that the default value for the field specified in the data dictionary will be placed in both child objects. The general expectation of this policy is that the user will need to enter an appropriate value. The duplicate policy will place the parent’s value in both child objects. The geometry ratio policy will proportionately divide the parent value among the child objects. This option only applies to feature classes. It is useful for such attributes as area, where each child feature will get the quantity determined by its size as a percentage of the parent.
Figure 3.9 Domain control in the geodatabase ArcGIS saves you all the programming required for domain control using lookup tables by supplying the required software in the geodatabase itself. Coded value and numeric range domains can be defined for a geodatabase workspace. Since these domain controls are established at such a high level in the geodatabase, they will be applied globally across the dataset of tables and feature classes by reference to the domain’s name.
The merge policy you specify will control what happens for the field controlled by the domain class when you put two features together. Merge policies are similar: default value, sum values, and geometry weighted. The default value policy works the same as for a split; the default value defined for the field is placed in the resulting combined feature. The sum values policy will add the value in this field for the two contributing features and place the total in the field for the resulting feature. The geometry weighted policy will take the weighted average of the values supplied by the two contributing features based on the ratio of the two features’ geometry. For lines, the weight is determined by relative length. For polygons, the weight is determined by relative area.
Valid value tables
Sometimes using a domain class is not enough to reflect the rich mix of attribute controls you need to employ. In such cases, you can use a structure called the valid value table. Such a table includes rows that reflect the combinations of values that are legitimate.
Figure 3.10 Valid value tables In this illustration, we need to control RouteType, which is based on a combination of urban type, functional class, and jurisdiction type. Each of these three variables is separately controlled by a coded value domain, but only certain combinations are valid. For instance, “rural minor collector” is valid but “urban minor collector” is not. The RouteType_VVT table stores the legitimate combinations and can serve to control Route table entries for the RouteType column using custom tools.
The example in figure 3.10 is one you have may have faced in dealing with the domain of functional classes used by the Highway Performance Monitoring System (HPMS). In some states, functional classification determines jurisdiction. Higher functional classes—those that emphasize mobility over land access—are assigned to the state DOT and lower functional classes to various levels of local government. An urban type field makes the example more interesting.
Domain classes can be used to control the values placed in each of these three fields individually, but cannot control combinations of the three fields. For example, you may want to prohibit a combination consisting of interstate highway, rural land use, and local government jurisdiction. There are only certain combinations that are allowable for urban type, functional class, and jurisdiction. For example, the route type representing a combination of rural interstate highway and city jurisdiction may not be valid. The valid route types are contained in the rows of the RouteType_VVT table. By linking the RouteType field in the Route table to the same field in the RouteType_VVT table, you can check the data through an on-the-fly join to see if all the entries are a valid route type.
