•Sub_Name
•Blk
•Lot_No
•House_Num
•Street_Name
•Street_Type
•ZIP_Code
•Primary_Use
•Secondary_Code
•Georeference
Another data integrity component is the domain. A domain allows you to define a list of values for any text field or a range of values for a numeric field. When data is entered, it is matched against the domain to see if it is a valid value. This designation helps eliminate typos or inventive abbreviations. Imagine 10 data entry clerks all coming up with unique abbreviations for the land-use code Vacant. It might be entered as VAC, V, Vcnt, or any number of misspellings. A query to find all vacant property would be difficult. If a domain is applied to the field Primary_Use that contains only the seven correct category abbreviations, it would be impossible for anyone to enter a value that wasn’t in the domain.
In addition to the defined primary-use codes, there are secondary-use codes associated with each primary-use code. For instance, the primary code Commercial has a set of secondary codes named Light Commercial, Special District, Church, and School. Using a contingent value domain, you can restrict the field selections for a second field on the basis of the first field’s value. The Secondary Land Use Code field will get a domain with all the available land-use descriptions in it, but later you will build a matrix that will pair the Primary Land Use Code with only those values in the domain that are relevant to the selected code. This pairing will prevent the user from selecting a secondary-use code that does not match the category of the primary-use code.
The domain values will be entered on the Domains worksheet, and you will note in the worksheet that it is a domain to avoid confusion with subtype fields that may be entered later.
3.On the Tables worksheet, add an entry on the line for Primary_Use with the name of a domain that will contain the acceptable values for this field. Call it Prim_Use_Codes, and place a (D1) in front of it for “domain number 1.”
4.On the line for Secondary_Code, add the notation (D2) and the name Sec_Use_Code.
5.Now turn to the Domains worksheet (page 3), and write the domain name Prim_Use_Codes, with a description of Primary Use Codes for Parcels, a field type of Text, and the type of domain as Coded Values.
6.In the Code column, write VAC, with a description in the Value column of Vacant Property. Under that, write RES, with a description of Residential Property. Continue down the form, entering the rest of the Prim_Use_Codes values from the accompanying list. Print more worksheets if necessary.
COM Commercial Property
IND Industrial Property
GOV Government Property
PRK Park Land
OTHER Other Uses
Adding this domain will build a validation check for data integrity. You can rest assured that the primary-use code abbreviation entered for any piece of property will fit your normal list. But one concern might be that someone could set the primary-use code to Commercial, and then set the secondary-use code to 35th3. These values don’t match, so a domain for the secondary codes should be designed to include all the detailed codes. In the form, a note can be added to show which primary land-use code each value will pair with, and later you will see how these codes are paired to further constrain the values entered.
7.On the Domains worksheet, add a new domain name (D2) of Sec_Use_Code. Give it a description of Secondary Land Use Codes, with a field type of Text and a domain type of Coded Values. The codes that will go in this domain are as shown in the figure. Print more copies of the worksheet as needed.
Perhaps there are other fields in the table that would benefit from the application of a domain. Most of them, however, such as a subdivision name or a house number, couldn’t be constrained in this way; there would be too many values. But the field street type might be a good candidate. The US Postal Service has a standard set of street type abbreviations, and from time to time, you may be asked to generate a mailing list from this table. So, it would be a good idea to add a domain to this field.
The table includes many acceptable street type abbreviations; you would not want to list all of them on the Domains form, and you wouldn’t want to type them into a domain. So, a command exists to take a file listing of street types and read them into a domain, and a file named Suffix.txt with these abbreviations is provided in the downloaded materials. The abbreviations it contains were found on a US Postal Service website, and the file contains all the recognized suffix names. The process of turning this file into a domain will be demonstrated in tutorial 2-1, but for now you can write the file name Suffix.txt on the design worksheet.
8.On the Tables worksheet, write St_Type_Abbrv as the domain name for the field Street_Type, and add (D3), noting that it is a domain.
9.Next, go to the Domains worksheet, and write the name St_Type_Abbrv, a description of Street Type Abbreviations, a field type of Text, and a domain type of Coded Values. Under Code, write the file name to identify the file holding the domain values.
Now is a good time to investigate other aspects of how the data will be used and see if there are any other data integrity techniques that might be employed—most notably, the subtypes.
Consider the situation with property. It is either platted by a legal survey or unplatted and recorded as a single deed. You might separate property as either platted (divided into developed lots with utilities) or unplatted (raw agricultural land). It is important to know the distinction for legal purposes and for the sale of property. It would be possible to put the platted land into one feature class and the unplatted property in another. If both feature classes were in the same geodatabase, they could both be easily stored and edited at the same time. The symbology and annotation would work well for both, and each feature class could have different data integrity rules. So dividing them into two feature classes would work and might be beneficial.
But consider how the data might be used in a query. If a list of all property owners in a given region was needed, it would have to come from two separate files, and exporting the list would create two tables. Although it would be beneficial in some respects to put property data into two feature classes, using the data would be problematic. That’s where subtypes can be valuable.
Using a subtype is a way to create a virtual subdivision of data within the same feature class, and then apply different data integrity rules to each category. It’s the best of both worlds: the data can be separated into logical categories and be given data integrity rules for each category but keep the convenience of being edited, queried, and managed in a single feature class. You’ll also see later, in tutorial 1-2, how subtypes can be used to set default values, establish unique attribute domains, set connectivity rules, and establish relationship rules for each subcategory created. They’ll even make it easier to symbolize and label data.
A field to contain the subtype code must be added to the table. The field type must be Integer, and the codes will be established along with a description. For this data, you’ll make a code 1 for Platted Property, code 2 for Unplatted Property, and code