ArcGIS for Desktop Cookbook

Chapter 1. Designing Geodatabase

In this chapter, we will cover the following recipes:

Creating a file geodatabase
Creating a feature dataset
Creating a feature class
Creating subtypes
Creating domains
Using subtypes and domains together
Creating a relationship class

Introduction

Real-world objects can be represented in Geographic Information Systems (GIS) using geographic data. In the context of the Esri ArcGIS technology, a database that stores geographic data is a geodatabase. The geodatabase is a native ArcGIS format that allows you to store, edit, and manage spatial data and non-spatial data. Before you start adding data to a geodatabase, it is important to think about how your data will be organized in the geodatabase. Another important step is to create an empty but structured schema of your geodatabase (data model). Paul A. Longley (Geographical Information Systems and Science, 2nd Edition, 2005, John Wiley & Sons, Inc , p.178) has mentioned three steps in creating a geospatial data model:

Conceptual schema
Logical schema
Physical schema (geodatabase schema)

In this chapter, you will skip steps 1 and 2, and you will manually create the physical schema or the geodatabase structure.

Note

There are three types of geodatabases: personal geodatabase, file geodatabase, and multiuser geodatabase. For more information about geodatabases, please refer to http://www.esri.com/software/arcgis/geodatabase.

For comprehensive definitions of specific elements and terms such as geodatabase, file geodatabase, feature dataset, spatial domain, resolution, tolerance, subtype, domain, feature class, relationship, or referential integrity, please refer to the ESRI GIS Dictionary online at http://support.esri.com/en/knowledgebase/GISDictionary.

In this chapter, you will work with the most common geodatabase elements, such as feature dataset, feature class, table, and relationship class. You will test the main advantages of using a geodatabase by performing the following actions:

Define the common spatial reference using feature datasets
Organize the features with the same geometry and spatial reference in feature classes
Define attribute constraints to eliminate edit errors using subtypes, domains, and default values
Define spatial and non-spatial relationships using relationship classes
Add supplementary spatial and attribute behaviors by defining relationship rules for relationship classes

Creating a file geodatabase

In this chapter, all exercises will refer to the single-user file geodatabase format. A file geodatabase is suited to ArcGIS for Desktop users and is stored in a filesystem folder. The main advantages of a file geodatabase are:

Editing of different feature classes or tables at the same time by multiple users
A maximum size of up to 1 terabyte (TB) for the individual datasets stored in a file geodatabase

Note

If you decide to use a single-user geodatabase for your project, but you are still thinking about the two options, personal geodatabase and file geodatabase, then please read the paper The Top Nine Reasons to Use a File Geodatabase: http://www.esri.com/news/arcuser/0309/files/9reasons.pdf.

Getting ready

In the next step, you will create a file geodatabase named Topo5k.gdb for a topographic map corresponding to the scale 1:5,000.

How to do it...

Follow these steps to create a new file geodatabase in ArcCatalog using the context menu:

Start ArcCatalog. Select Connect To Folder from the Standard toolbar. Go to <drive>:\PacktPublishing\Data, and click on OK.
In Catalog Tree, select <drive>:\PacktPublishing\Data, and right-click to choose New | Folder. Rename New Folder as MyGeodatabase.
In Catalog Tree, select MyGeodatabase, and right-click to choose New | New File Geodatabase. Rename New File Geodatabase.gdb as Topo5k.

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

How it works...

You have created an empty file geodatabase using the context menu in ArcCatalog. You will use Topo5k.gdb in the later steps. Open Windows Explorer to see the structure of the filesystem folder created for your file geodatabase.

There's more...

Follow these steps to create a new file geodatabase in ArcCatalog using ArcToolbox:

Select ArcToolbox from the Standard toolbar. Go to Data Management Tools | Workspace, and double-click on the Create File GDB tool.
For File GDB Location, select Folder Connections, go to <drive>:\PacktPublishing\Data, and select the MyGeodatabase folder. For File GDB Name, type Topo5000. For File GDB Version (optional), select the CURRENT option to create a file geodatabase compatible with ArcGIS Version 10.2, and click on OK.

Creating a feature dataset

A feature dataset is a container for feature classes that have the same spatial reference, Coordinate Reference System (CRS), spatial domain, resolution, and tolerance. In the case of importing features with the same CRS, the feature dataset will accept only the features that have their coordinates between the minimum and maximum values defined for the x, y, z and m values of spatial domain extent. A feature dataset cannot contain other feature datasets or non-spatial tables.

Note

For more details about the feature dataset, please refer to the online ArcGIS help (10.2) by navigating to Geodata | Data types | Feature datasets from http://resources.arcgis.com/en/help/main/10.2.

Getting ready

You will create seven feature datasets: Buildings, GeodeticPoints, Hydrography, LandUse, Relief, Transportation, and Boundaries. In your file geodatabase, Topo5k.gdb, all feature datasets will have the same CRS.

How to do it...

Follow these steps to create feature datasets in a file geodatabase using the ArcCatalog context menu:

Start ArcCatalog. In Catalog Tree, go to <drive>:\PacktPublishing\Data\MyGeodatabase, and select Topo5k.gdb.
Right-click on Topo5k.gdb, and navigate to New | Feature Dataset for the Name type Buildings. Click on Next. Navigate to Projected Coordinate Systems | National Grids | Europe | Pulkovo 1942 Adj 1958 Stereo 1970. Select the active yellow star Add To Favorites to add the selected projected coordinate system to the Favorites section. You will use this projected coordinate system later in this book.
Click on Next. Navigate to Vertical Coordinate Systems | Europe | Constanta. Click on Next. Accept the XY, Z, and M tolerance values. Keep checked the option Accept default resolution and domain extent (recommended).
If you want to see the default values for resolution and domain extent, uncheck them and click on Next. Examine the default values, and click on the Finish button.
If you want to examine the default values for domain, resolution, and tolerance, right-click on Buildings feature datasets and navigate to the Properties | Domain, Resolution and Tolerance tabs.
Repeat the previous steps to create the following feature datasets: GeodeticPoints, Hydrography, LandUse, Relief, and Transportation, as shown in the following screenshot:
To inspect the results, return to the Feature Dataset Properties dialog.

How it works...

After you have created a feature dataset, ArcCatalog allows you to change only the XY and Z coordinate system. If you take the decision to change the XY coordinate system for a feature dataset, you should know that you cannot modify the values for domain, resolution and tolerance. If you still need to change the CRS for a feature dataset, it will be more proper to create the feature dataset from the beginning. In conclusion, when you are thinking about a feature dataset, think twice and act once.

There's more...

In ArcCatalog, you can use Copy and Paste from the context menu in the file geodatabase to duplicate the first feature dataset. In the Data Transfer window, you can change the name of the feature dataset by typing in the Target Name section. In this case, the newly resulted feature dataset will have the same coordinate reference system as the source feature dataset.

Creating a feature class

Features are representations of the real-word objects in a geodatabase. Features are grouped in classes based on their common components: shape (geometry) and attributes. Features from a feature class share the same spatial reference. A feature class stores simple features (for example, point, multipoint, line, and polygon) or non-simple features (for example, dimension and annotation). When a feature class is created, the user can add two optional geometry properties for features: z value (3D data) and m value (used for linear referencing). The feature class table contains some default attribute fields, which are managed by ArcGIS: OBJECTID and SHAPE. The OBJECTID field has the Object ID type property and stores the unique identifier for each feature. The SHAPE field refers to the Geometry type property and stores the x and y coordinates of the features and optionally z and m values if the feature class has the z and/or m properties enabled. The feature class that stores line or polygon features has two supplementary fields: SHAPE_Length (length of the feature line) and SHAPE_Area (area of the feature polygon).

Note

For more details about the feature class and field data types, please refer to Geodata/Data types/Feature Class and Geodata/Geodatabases/Defining the properties of data in a geodatabase/Geodatabase table properties/ArcGIS field data types from ArcGIS help (10.2) online.

Usually, feature classes are stored inside a feature dataset and automatically inherit the spatial reference of the feature dataset. A feature class that is stored at the root level of a geodatabase is a standalone feature class and has its own spatial reference.

Getting ready

You will continue to work at the geodatabase structure by creating four feature classes: Buildings (polygon features), Watercourse (polygon features), WatercourseL (polyline features), and LandUse (polygon features).

How to do it...

Follow these steps to create feature classes using the ArcCatalog context menu:

Start ArcCatalog. In Catalog Tree, go to <drive>:\PacktPublishing\Data\MyGeodatabase\Topo5k.gdb.
Right-click on the Buildings feature dataset, and choose New | Feature Class. For Name, type Buildings and for Alias, type Buildings. For Type, choose Polygon Feature. Leave the Geometry Properties options unchecked. Click on Next. Select Default for the Configuration Keyword section. Click on Next. There are two default attribute fields: OBJECTID and SHAPE. You will create five new attribute fields: BD (Alias=Destination), BM (Alias=Material), Stories (Alias=Number of stories), BS (Alias=State of buildings) and LandUseID. For Field Name, in the first empty cell below SHAPE, type BD, and for Data Type, select Long Integer from the drop-down list. In the Field Properties section, for the Alias, type Destination and for Allow NULL values, select Yes. Leave empty the Default Value property. You will add the default value later on in this chapter. You should see something similar to the following screenshot:
Repeat step 2 for BM (Default Value: 0), Stories, and LandUseID.
For the BS attribute field, choose Text from the drop-down list. Notice that the Field Properties options have changed according to the data type. For Alias, type State of buildings, and for the Length property, type 4. Click on OK to close the Feature Class Properties dialog. To inspect the results, return to the Feature Class Properties dialog. Right-click on the Buildings feature class, and navigate to Properties | Fields. Notice the two geometry attribute fields: SHAPE_Length and SHAPE_Area.
Right-click on the Hydrography feature dataset, and navigate to New | Feature Class. For Name, type Watercourse, and for Alias, type Watercourse. For Type, choose Polygon Feature. Leave the Geometry Properties options unchecked. Click on Next. Select Default for the Configuration Keyword section. Click on Next, and add the following attribute fields:

Name

Data type

Alias

Allow NULL values

Default Value

HType

Long Integer

Water category

Yes

<none>

HYC

Long Integer

Hydrologic category

Yes

<none>
Click on OK to close the Feature Class Properties dialog.
Right-click on the Hydrography feature dataset, and choose New | Feature Class. For Name, type WatercourseL and for Alias, type WatercourseL. For Type, choose Line Feature. Leave the Geometry Properties options unchecked. Click on Next. Select Default for the Configuration Keyword section. Click on Next. You will add field definitions by selecting the Import button. Navigate to Topo5k.gdb | Hydrography, and select the Watercourse polygon feature class. Click on Add. You now have two attribute fields: HType (Water category), HYC (Hydrologic category), along with Name. Click on OK.
Right-click on LandUse, and choose New | Feature Class. For Name, type LandUse and for Type, choose Polygon Feature. Click on Next twice, and add the following attribute fields:

Name

Data type

Alias

Allow NULL values

Default Value

CAT

Long Integer

Category

Yes

<none>

SCAT

Text with Length 5

SubCategory

Yes

<none>
Click on OK to close the Feature Class Properties dialog. Return to the Feature Class Properties dialog for every feature class to inspect the results.

How it works...

For every feature class, you defined different attribute fields. Because the WatercourseL feature class has the same attribute fields as Watercourse, you imported the field definitions from Watercourse at step 7. For all attribute fields, you have selected Yes for Allow NULL values. When you add a new feature in ArcMap, the attribute field will have a NULL value or an empty value that will be ignored by the functions in ArcMap. To enforce data integrity, you can specify that a field cannot contain empty or null values by setting Allow NULL values to No. This condition can be validated in the ArcMap edit session using the Validate Features option from Editor in Editor toolbar. You have another option to enforce field values by setting the Default Value property. A default value is automatically assigned to an attribute field when a new feature is being created in the ArcMap edit session.

There's more...

Regarding spatial reference of the feature class, if you want to move WatercourseL in the LandUse feature dataset, you simply select the feature class and drag and drop it into the LandUse feature dataset. You will succeed because both feature datasets have the same spatial reference. If you drag and drop the WatercourseL feature class into the root of the geodatabase, you will have a standalone feature class.

Creating subtypes

Subtypes are properties of feature classes or non-spatial tables. The subtypes gather the features from a feature class or records from a non-spatial table that share the same attribute values using an attribute field. The attribute field that groups the features must be of the data type Short or Long integer, and it will be named the subtype field. A feature class can have only one subtype field. You can assign different behaviors to individual subtypes from a feature class/table. Generally speaking, the behavior is defined by the actions or characteristics of features in a geodatabase. A subtype has a code and a description. After you have defined the subtypes for a subtype field, you can change everything related to a subtype: change the value or description of code, add more codes, and delete code. The subtypes help you in the geometry editing process and prevent errors when editing feature attribute values. The subtypes maintain the integrity in a geodatabase.

Getting ready

You will continue to work with geodatabase schema by grouping features from the feature classes that you created in the previous Creating a feature class recipe. The integer subtype fields are the following: BD for Buildings, HType for Watercourse and WatercourseL, and CAT for LandUse.

How to do it...

Follow these steps to define subtypes using the context menu in ArcCatalog:

Start ArcCatalog. In Catalog Tree, go to <drive>:\PacktPublishing\Data\MyGeodatabase\ Topo5k.gdb\Buildings.
Right-click on the Buildings feature class, and navigate to Properties | Fields. You will define five subtypes for the BD attribute field. Select the Subtypes tab in the Feature Class Properties window. For Subtype Field, select the drop-down arrow and choose BD. In the Subtypes section, you have a default subtype with Code with the value 0 and Description with the value New Subtype. Change Description of the first subtype by typing Unknown.

Continue to create subtypes as shown in the following table:

Code	Description	Code	Description
`0`	`Unknown`	`3`	`Industrial and municipal`
`1`	`Dwelling`	`4`	`Historical sites, monuments, statues`
`2`	`Administrative buildings and socialcultural`	`5`	`Dwelling annex`

For Default Subtype, choose the Dwelling subtype. Click on Apply and on OK. Open the Feature Class Properties dialog for the Buildings feature class to check the subtypes you just added. Right-click on the Buildings feature class, and choose Properties | Subtypes. You should see something similar to the following screenshot:
In Catalog Tree, select the Hydrography feature dataset. Right-click on the Watercourse feature class, and choose Properties | Fields. Select the Subtypes tab in the Feature Class Properties window. You will define five subtypes for the HType attribute field. For Subtype Field select the drop-down arrow, choose HType, and add the following subtypes:

Code

Description

Code

Description

0

Unknown

3

Creek

1

River

4

Canalized stream

2

Stream
For Default Subtype choose the River subtype. Click on Apply and on OK. Open the Feature Class Properties dialog for the Watercourse feature class to check the subtypes you just added.
Repeat step 4 to create subtypes for the WatercourseL feature class using the same codes and descriptions.

Repeat step 4 to create subtypes for the LandUse feature class using the CAT (Description: Category) attribute field and the following subtypes:

Code	Description	Code	Description
`0`	`Unknown`	`21`	`Forest`
`11`	`Arable`	`31`	`Hydrography`
`12`	`Pasture`	`41`	`Transportation`
`13`	`Meadow`	`42`	`Other terrains`
`14`	`Vineyard`	`51`	`Unproductive`
`15`	`Fruit orchard`

For Default Subtype, choose the Arable subtype. Click on Apply and on OK. Open the Feature Class Properties dialog for the LandUse feature class to check the subtypes you just added.
Inspect the results in Subtypes in the Feature Class Properties dialog.

How it works...

The subtypes will help you to edit feature geometry and attribute fields faster. The default subtype is used as the default edit target for the Watercourse feature class when you start an edit session in ArcMap. In the Feature Class Properties dialog, you can add more subtypes for the BD attribute field, and you can delete a subtype or change Code and Description.

Note

If you delete all code, your feature class will not have subtypes anymore, and all rules and behaviors related to subtypes will be corrupt or lost for the feature class.

Sometimes, when you are establishing codes and descriptions for a subtype field, it is impossible to anticipate correctly all possible values. It is good practice to add code that covers all unforeseen values: Code: 42 and Description: Other terrains. Another good practice is to add code that refers to the situation in which you know the values for all other attribute fields, but you are not sure about the subtype, and it will be defined later: Code: 0 and Description: Unknown.

Creating domains

The domains define the valid values for the attribute fields of feature classes or non-spatial tables. The domains are properties of a geodatabase, and obviously are stored at the geodatabase level. In a feature class/table, an attribute field can have one or many domains associated with it. The multiple domains associated with a field are based on the existing subtypes that you have already defined for a feature class. A domain can be associated with one or many attribute fields of one or more feature classes from a geodatabase.

There are two domain types: Range and Coded Values. A range domain defines minimum and maximum values and can be used only by the numeric and date field types. A coded domain can be used by the numeric, date, and text field types and defines an explicit list of valid values. Every valid value has a code and a description. A domain defines the attribute behavior when a feature is split or merged in ArcMap using the Split policy and the Merge policy.

Note

For more details about domains, please refer to Geodata/Data types/Domains from ArcGIS help (10.2) online.

Getting ready

Let's continue to work with geodatabase schema by defining valid values for the attribute fields of feature classes that you created in the Creating a feature class recipe. You will create the domains in the geodatabase Properties.

In the Database Properties dialog, the Domains section has three main sections:

Domain Name | Description: This defines domain name and description
Domain Properties: This sets the domain properties, such as the data type, domain type and split/merge policy
Coded Values: This defines the codes and descriptions

How to do it...

Follow these steps to create domains using the ArcCatalog context menu:

Start ArcCatalog. In Catalog Tree, go to <drive>:\PacktPublishing\Data\MyGeodatabase\Topo5k.gdb. Right-click on the Topo5k.gdb file geodatabase, and select Properties | Domains.
In the first cell from the Domain Name column, type dBM. For the Description column, type Building material. In the second section, Domain Properties, for the Field Type tab, choose Long Integer from the drop-down list. For Domain Type, select Coded Values from the drop-down list. For Split policy, select Duplicate and for Merge policy, leave Default Value. You will establish the default values later in this recipe. In the Coded Values section, add the following codes and descriptions:

Code

Description

Code

Description

0

Unknown

4

Clay

1

Concrete

5

Mixture

2

Brick

6

Metal

3

Wood

100

Other
To save changes, click on Apply from time to time. You should see something similar to the following screenshot:
Create a new domain named dStories with Description of Number of stories. In the Domain Properties section, for the Field Type option, choose Long Integer. For Domain Type, select Range from the drop-down list. For Minimum value, type 1, and for Maximum value, type 6. For Split policy, select Duplicate, and for Merge policy, leave Default Value.
Create a new domain named dState with Description: State of building. In the Domain Properties section, for the Field Type option, choose Text. For Domain Type, select Coded Values from the drop-down list. For Split policy, select Duplicate, and for Merge policy, leave Default Value. You will establish the default values later in this recipe. In the Coded Values section, add the following code and description:

Code

Description

Code

Description

fb

Very good

r

Bad condition

b

Good

i

Insanitary

s

Satisfactory

c

Construction
To save changes, click on Apply from time to time.
The next domain is dHYC. For the Description column, type Hydrologic category. In the Domain Properties section, for the Field Type option, choose Long Integer. For Domain Type, select Coded Values from the drop-down list. For Split policy, select Duplicate, and for Merge policy, leave Default Value. In the Coded Values section, add the following code and description:

Code

Description

Code

Description

0

Unknown

2

Intermittent

1

Perennial

3

Ephemeral
Create a last domain dUnkn. For the Description column, type Unknown Text. In the Domain Properties section, for the Field Type option, choose Text. For Domain Type, select Coded Values from the drop-down list. For Split policy, select Duplicate, and for Merge policy, leave Default Value. In the Coded Values section, you will add the code and description. For the Code column, type Unkn, and for Description, type Unknown.
Click on Apply to save changes. Click on OK to close the Database Properties window.
Right-click on Topo5k.gdb, and navigate to Properties | Domains to inspect the results.

How it works...

At step 2, for Split policy, you selected Duplicate. When you split a building made of Brick material (domain code: 2) during the edit session in ArcMap, you will have two buildings made from bricks. For Merge policy, you selected Default Value. Let's suppose you already established the Default Value option for the BM (Building material) field to 0. When you merge two buildings made of Brick material (domain code: 2) during the edit session in ArcMap, you will have two buildings made of Unknown material (domain code: 0). The range and coded values can be validated in the ArcMap edit session using the Validate Features option from Editor present in the Editor toolbar. The Validate Features option helps you to find mistaken attribute values in the sense that it is not a valid value.

There's more...

To create a new coded value domain for a file geodatabase, based on a table that contains the defined codes and descriptions for a domain, you can use the Table To Domain tool from ArcToolbox. In ...\Data\DesigningGeodatabase\LandUseDomains folder, you have five dBASE tables corresponding to the following domains: dArable, dPasture, dMeadow, dVineyard, and dFruitOrchard.

Follow these steps to create more domains for your file geodatabase using ArcToolbox:

Select ArcToolbox from the Standard toolbar. Navigate to Data Management Tools | Domains, and double-click on the Table To Domain tool. Set the following parameters:
- Set the Input Table parameter as ...\Data\DesigningGeodatabase\ LandUseDomains\Arable.dbf
- Set the Code Field option as CodeArable
- Set the Description Field option as Descript
- Set the Input Workspace field as ...\Data\MyGeodatabase\Topo5k.gdb
- Set the Domain Name field as dArable
- Set the Domain Description (optional) field as Land Use domain from table
- Accept default option for the Update Option (optional) field
Click on OK to close the Table To Domain dialog.
Open the Database Properties dialog for the Topo5k.gdb feature class to check the subtypes you just added. Repeat step 1 to add the dPasture, dMeadow, dVineyard, and dFruitOrchard domains.

Using subtypes and domains together

In this recipe, you will use both subtypes and domains to better control, constrain, and partially automate the editing processes of the field values.

Getting ready

In this section, you will assign default values and domains to fields and subtype fields for the following feature classes: Buildings, Watercourse, WatercourseL, and LandUse.

The exercise tests three cases:

A simple domain assigned to the BM (Material), Stories (Number of stories), and BS (State of buildings) attribute fields for the Buildings feature class.
Two feature classes will share the same domain. The dHYC domain will be assigned to the HYC (Hydrologic category) attribute field for the Watercourse and WatercourseL feature classes.
Six domains will be assigned to a single attribute field based on the subtypes of the LandUse feature class. The dUnkn, dArable, dPasture, dMeadow, dVineyard, and dFruitOrchard domains will assign to the SCAT (SubCategory) attribute field for the LandUse feature class based on the subtypes defined for the CAT (Category) subtype field.

How to do it...

Follow these steps to assign domains to attribute fields of the feature classes:

Start ArcCatalog. In Catalog Tree, go to ...\Data\MyGeodatabase\ Topo5k.gdb\Buildings.
Right-click on the Buildings feature class, and navigate to Properties | Fields. Select the BD attribute field. In Field Properties, the Default Value field is 1 because Default Subtype is Dwelling with code with a value of 1. To see the subtypes, select the Subtypes tab. For every subtype, you will assign three different domains to the following fields: BM, Stories, and BS.
In the Subtypes section, select the Unknown subtype by clicking the small box on the left-hand side of the row with code the value of which is 0. The rows will become black. In the Default Values and Domains section, set the Default Value and Domain columns, as shown in the following screenshot:
The default value 0 for the BM field corresponds to the Unknown description. The default value 1 for the Stories field corresponds to a building with one storey. The default value b for the BS field corresponds to a Good state of building. Click on Apply to save changes.
Select the Dwelling subtype. In the Default Values and Domains section, set the Default Value and Domain columns, as shown in the following screenshot:
When you define values in the Default Value field, you must think what the most common value used for the Dwelling subtype is. For example, most of the dwellings are made of brick (domain code: 2). During an edit session, when a feature is added, split, or merged, the default value will be assigned to the attribute field value.
Continue to assign the same domains to the next four subtypes. Click on Apply and on OK to save and close the Feature Class Properties dialog.
In Catalog Tree, select the Hydrography feature dataset. Right-click on the Watercourse feature class, and navigate to Properties | Fields. Select the HType attribute field. In Field Properties, the Default Value field is 1 because the Default Subtype field is River, where Code is 1.
For every subtype, you will assign a single domain to the HYC attribute field. In the Subtypes section, select the Unknown subtype, and set the Default Value and Domain columns, as shown in the following screenshot:

Continue to assign values to the Default Values and Domain section for the rest of the subtypes, as shown in the following table:

Subtype code	Code description	Field	Default Value	Description	Domain
`1`	`River`	`HYC`	`1`	`(Perennial)`	`dHYC`
`2`	`Stream`	`HYC`	`2`	`(Intermittent)`	`dHYC`
`3`	`Creek`	`HYC`	`3`	`(Ephemeral)`	`dHYC`
`4`	`Canalized stream`	`HYC`	`1`	`(Perennial)`	`dHYC`

Click on Apply and on OK to save and close the Feature Class Properties dialog.

In Catalog Tree, select the LandUse feature dataset. Right-click on the LandUse feature class, and navigate to Properties | Subtypes. You have 10 subtypes. For every subtype, you will assign a domain and a default value for the SCAT field, as shown in the following table:

Subtype code	Description	Field	Default Value	Domain
`0`	`Unknown`	`SCAT`	`Unkn`	`dUnkn`
`11`	`Arable`		`A`	`dArable`
`12`	`Pasture`		`P`	`dPasture`
`13`	`Meadow`		`F`	`dMeadow`
`14`	`Vineyard`		`V`	`dVineyard`
`15`	`Fruit orchard`		`L`	`dFruitorchard`

Click on Apply and on OK to save and close the Feature Class Properties dialog.

How it works...

The domains have been assigned to subtypes in the Subtypes section in the Feature Class Properties dialog. If your feature class doesn't have subtypes, you will assign the domains in the Fields section in the Feature Class Properties dialog box.

At step 8, the Arable subtype has been assigned the dArable domain for the SCAT attribute field. A good practice is to have similar names for subtypes and related domains. To be easier to read and make a distinction between the field name, subtype name, and domain name, put a small d, such as dArable, in front of the domain name. It is intuitive and easy to combine subtypes with different domains.

At step 3, choosing the right domain was a little tricky because the field is BS and the domain is dState. Another good practice is to keep your own documentation regarding the data type, code, and description for domains and subtypes. Another aspect is the default value for domains.

At step 7, you defined the default value for BM (Material), Brick value. When you add a Dwelling feature, the default values of the Material field will be Brick. Probably this will help the editing process, but sometimes it can be an illusory value. The user will not be more preoccupied with the correctness of this value. It would be a good idea to define as the default value for the Material field, code 0 (Unknown). This value will warn the user that it should be changed to this value according to the reality. There is no perfect solution for a default value, but your experience and the context of using geodatabase will help you to make the most appropriate decision.

There's more...

In the last step, you assigned only six domains to the LandUse feature class only if it defined 11 subtypes. There is another way to complete the domain list—by importing a feature class from another file geodatabase. When a feature class is imported, all the domains used by the imported feature class will also be added. Follow these steps to import the LandUse feature class from another file geodatabase, TOPO5000.gdb.

In Catalog Tree, right-click on the LandUse feature dataset, and navigate to Import | Feature Class (single). For Input Features, go to ...\Data\TOPO5000.gdb\LandUse, and select the LandUse feature class. Click on Add. For Output Feature Class, type LandUseImport.
You will keep only two attribute fields: CAT (long) and SCAT (text). These fields are important because the first is a subtype field and the second field uses the subcategory domains for the Landuse feature class. You will delete all other attribute fields from the source feature class. In the Field Map (optional) section, select Zone (long), and select the X button on the right-hand side. Repeat the step for the remaining fields. Click on OK to close the Feature Class to Feature Class dialog.
Inspect the newly added domains in the Database Properties dialog for Topo5k.gdb. You now have five new domains: dForest, dHydrography, dTransportation, dOtherTerrains, and dUnproductive. Because you don't want to have a duplicate feature class, delete the LandUseImport feature class in ArcCatalog. The added domains still remain as file geodatabase properties.

Repeat step 12 from the How to do it... section to continue to add domains for the SCAT field, as shown in the following table:

Subtype code	Description	Field	Default Value	Domain
`21`	`Forest`	`SCAT`	`PD`	`dForest`
`31`	`Hydrography`		`H`	`dHydrography`
`41`	`Transportation`		`D`	`dTransportation`
`42`	`Other terrains`		`Cc`	`dOtherTerrains`
`51`	`Unproductive`		`N`	`dUnproductive`

You can find the results of this section at ...\Data\DesigningGeodatabase\Topo5k.gdb.

Creating a relationship class

Relationships describe how the spatial/nonspatial objects are linked. In a geodatabase, the relationships are stored in relationship classes. In a relationship class, you can relate only two classes (table/feature class) from a geodatabase. Just as with a feature class, a relationship class can be created at the root level of a geodatabase or within a feature dataset.

In a relationship class, you have to decide the followings properties:

Name of the relationship class
Origin table and destination table
Type of relationship, which can be as follows:
- Simple: The objects can exist independently of each other and can have any type of cardinality.
- Composite: The objects from a destination table/feature class (child) cannot exist without the objects from an origin table/feature class (parent); define the feature following and cascade, deleting behaviors (if an origin object is moved, rotated, or deleted, the destination object suffers the same actions); it can have only one-to-one or one-to-many cardinality.
Label for origin and destination
Message propagation (controls relationship behavior) with specific effects on composite relationships:
- Forward: This includes cascade delete, feature following, and annotation update
- Backward: This includes cascade delete and no feature following
- Both: This includes cascade delete, feature following, and annotation update
- None: This includes cascade delete and no feature following
Cardinality (one-to-one, one-to-many, and many-to-many)
Add an attribute in a relationship class to describe the relationship between objects
The origin primary key (PK) and the destination foreign key (FK)
The primary key and foreign key columns must have the same data type.

For more information about annotation concepts in the geodatabase context, please refer to Chapter 6, Building Better Maps.

Note

You cannot modify the properties of an existing relationship class. You can delete and define it once again. If you delete one class (table/feature class) that participates in a relationship class, the relationship class will be deleted too.

A table/feature class can be involved in more than one relationship class. Those multiple relationships for a table/feature class work well as long as they are coherently defined and don't generate contradictory behaviors. The last step in creating a relationship class is to define rules in order to refine the cardinality based on the subtypes of the feature classes/tables. All types of cardinality support the relationship rules. A relationship rule is a property of the relationship class.

Getting ready

In this section, you will create two simple relationship classes and one composite relationship class between the LandUse feature class, BuildingsR feature class, and Owners table. Those relationships compose a stacked relationship because they link three classes in an open loop, as shown in the following screenshot:

When you define the cardinality, remember that term one can mean zero. For example, in the schema shown in the preceding screenshot, the Buildings (origin) are related to Owners (destination). The cardinality is many-to-many. The relationship allows the following situations:

Building with no owner (1..0)
Building with different owners (1..*)
Owner with no building (0..1)
Owner with any number of buildings (*..1)

How to do it...

Follow these steps to create two simple, many-to-many relationship classes:

Start ArcCatalog. In Catalog Tree, navigate to ...\Data\DesigningGeodatabase\Topo5k.gdb\LandUse.
Right-click on the LandUse feature dataset, and select New | Relationship Class. For Name of the relationship class, type LandUseToOwners. For Origin table/feature class, select the plus sign on the left-hand side of the LandUse feature dataset to see the LandUse feature class. Select the LandUse feature class. For Destination table/feature class, select the Owners table. Click on Next.
Select Simple (peer to peer) relationship, and click on Next. For the first relationship label, type ToOwners. For the second relationship label, type ToLandUse. Select the None (no messages propagated) option, and click on Next. Select the cardinality M-N (many-to-many) and click on Next. Select Yes, I would like to add attributes to this relationship class, and click on Next.
For FieldName, type OwnerProcent in the first empty row. Select Long Integer from the drop-down list. Select Yes for the Allow NULL values option, in the Field Properties section. As the primary key for the origin table, choose OBJECTID from the drop-down list, and as the foreign key, type LandUseID. As the primary key for the origin table, choose OBJECTID, and for foreign key, type OwnerID.
Click on Next to see a summary of your options, and select Finish to close the New Relationship Class wizard.

Right-click on the Buildings feature dataset, and select the New | Relationship Class. For Name of the relationship class, type BuildingsRToOwners. Repeat the previous steps, and set the relationship according to the following table:

Relationship	Value
Origin table/feature class	`BuildingsR`
Destination table/feature class	`Owners`
Type of relationship	`Simple`
Origin to destination label	`ToOwners`
Destination to origin label	`ToBuildingsR`
Message propagation	None
Cardinality	M-N (many to many)
Additional attributes	NO
Origin Table/Feature Class	Primary Key: `OBJECTID` Foreign Key: `BuildingsRID`
Destination Table/Feature Class	Primary Key: `OBJECTID` Foreign Key: `OwnerID`

Follow these steps to create a composite one-to-many relationship class between LandUse (as parent objects) and BuildingsR (as child objects):

Right-click on the LandUse feature dataset, and select New | Relationship Class. For Name of the relationship class, type LandUseToBuildings. For Origin table/feature class, select the LandUse feature class. For Destination table/feature class, select the plus sign on the left-hand side of the Buildings feature dataset, and select the BuildingsR feature class.
Click on Next. Select Composite relationship (peer to peer) relationship and click on Next.
For the first relationship label, type ToBuildingsR. For the second relationship label, type ToLandUse. Select the Forward (origin to destination) option and click on Next. Select the cardinality 1-M (one-to-many), and click on Next.
Select NO, I do not want to add attributes to this relationship class and click on Next.
As the primary key, choose OBJECTID from the drop-down list, and as the foreign key, choose LandUseID.
Click on Next to see a summary of your options, and select Finish to close the New Relationship Class wizard.
Follow these steps to add rules for the LandUseToBuildings relationship class:

In ArcCatalog, double-click on the LandUseToBuildings relationship class to open a Relationship Class Properties dialog box. Select the Rules tab to see the subtypes for the LandUse and BuildingsR feature classes. You will define relationship rules, as shown in the following table:

BuildingsR subtypes	Cardinality (M) `Other terrains`: `42`	Cardinality (M) `Unproductive`: `51`
Unknown	0..10	0..*
Dwelling	0..2	0
Administrative buildings and socialcultural	0..3	0
Industrial and municipal	0..10	0..2
Historical sites, monuments, statues	0..2	0..*
Dwelling annex	0..3	0..1

For Origin Table/Feature class subtypes, select Other terrains. For Destination Table/Feature class subtypes, click on the Code checkbox on the left-hand side of the Unknown subtype. Click on Unknown to select the subtype and to enable the Origin Cardinality and Destination Cardinality sections.
In the Destination Cardinality section, check the Specify the range of associated destination objects option. First, set the Max value by typing 10. Leave the Min value at 0.
For Destination Table/Feature class subtypes, click on the Code checkbox to the left of the Dwelling subtype. Click on Dwelling to select subtype and to enable the Origin Cardinality and Destination Cardinality sections.
In the Destination Cardinality section, check the Specify the range of associated destination objects option. First, set the Max value by typing 2. Leave the Min value at 0 according to the previous table. The first rule says that an Other terrains parcel subtype can have a maximum of two dwellings. You should see something similar to the following screenshot:
Select the Administrative buildings subtype, and check the Specify the range of associated destination objects option. For the Max value, type 3. For the Min value, type 0. This rule says that there must be between zero and three administrative buildings in a parcel (Other terrains).
Continue to define the rules in Destination Table/Feature class subtypes for all building subtypes. For Origin Table/Feature class subtypes, select Unproductive. Leave unchecked the Unknown subtypes in the Destination Table/Feature class subtypes section to allow an unlimited number of Unknown buildings.
You will permit a maximum of two Industrial and municipal buildings and one Dwelling annex per Unproductive parcel. Select those subtypes from the Destination Table/Feature class subtypes section, and set the maximum value according to the previous table.
Finally, you will not permit a relationship with the rest of building types, such as Dwelling, Administrative buildings, and Historical sites. Select all those subtypes from the Destination Table/Feature class subtypes section, check the Specify the range of associated destination objects option, and set the maximum values to 0.
For the rest of the LandUse subtypes from Origin Table/Feature class subtypes, set the Max and Min values to 0. This will not permit BuildingsR to associate with parcel subtypes, such as Arable, Pasture, Meadow, Vineyard, Fruit orchard, Forest, Hydrography, and Transportation.
Click on Apply and on OK to save and close the Relationship Class Properties wizard.

You can find the final geodatabase schema at ...\Data\DesigningGeodatabase\ MyGeodatabaseResults\Topo5k.gdb.

How it works...

In the previous exercise, you used OBJECTID as the origin primary key field. But you could define your own primary key. The OBJECTID field guarantees a unique value for each record because it is managed by ArcGIS. You can't modify the OBJECTID values, and this can be inconvenient to maintaining the relationships when you are modifying feature geometry (for example: split, merge) or import features to another feature class.

Note

For more details about the advantages and inconvenience of using the OBJECTID field as the primary key, please refer to Geodata/Data types/Relationships and related objects/Relationship class properties from ArcGIS Help (10.2) online.

There is a performance cost when you are working with relationship classes. The relationship classes will slow down the edit process because they must maintain the referential integrity in the geodatabase. A relationship class will assure that all changes you have made in the origin feature class/table will be reflected in the destination feature class/table according to the type and rules of the relationship.

At step 3, you created a many-to-many, simple relationship class between the BuildingsR feature class and the Owners table. A many-to-many relationship class requires an intermediary table that contains two key fields: origin primary key and destination foreign key. Both fields have a foreign key's role. You can see this table in ArcCatalog if you select the LandUseToOwners relationship class table. Select the Preview tab and the Table preview mode from the bottom of the Preview panel to examine the attribute fields.

There's more...

Follow these steps to test the relationship behavior:

Start ArcMap, and open an existing map document WorkingRelationships.mxd from ...\Data\DesigningGeodatabase. In Table Of Contents, you have two layers (BuildingsR and LandUse), two intermediate tables (LandUseToOwners and BuildingsRToOwners), and one non-spatial table, Owners.
Let's validate the relationship rules for the LandUseToBuildings composite relationship. Zoom in to the full extent of a map by selecting Full Extent in the Standard toolbar. Relationships are active and can be validated during an edit session.
In the Editor toolbar, select Start Editing. Select all features from BuildingsR and LandUse using the Select Features tool.
In the Editor toolbar, navigate to Editor | Validate Features. A message box will appear: 72 features are invalid. Click on OK to close. All invalid features are selected.
Open the Attributes window by selecting the Attributes button in the Editor toolbar. You will see two layers: BuildingsR and LandUse. Select Expand All Relationships In Branch to see all selected features (blue bullets), related tables, and table records.
Let's inspect a relationship error. Click on Bookmarks and choose Error2. With the Select Features tool, select the Others terrains parcel with LandUseID=1262. In the Attributes window, expand the LandUse layer. You should see something similar to the following screenshot:
Right-click on LandUse, and navigate to Selection | Open Table Showing Selected Feature to see the LandUse attribute table in the Show selected records mode. Navigate to Table Options | Related Tables, and choose LandUseToBuildingsR: ToBuildingsR. In the Editor toolbar, navigate to Editor | Validate Features. A message box will appear: The feature LandUse(subtype:Other terrains) has 4 related BuildingsR (subtype:Dwelling) features, thus violating the LandUseToBuildings relationships rule that specifies 0-2. Click on OK to close.
To fix the error, delete two buildings. Select the parcel and the remaining buildings and validate features once again. The message box will tell you: All features are valid.
Let's check the feature following and cascade deleting behaviors of the LandUseToBuildings composite relationship. With the Select Features tool, select the Other terrains parcel with LandUseID=1262. In the Editor toolbar, select Edit Tool. Drag the parcel away from the previous location. The related buildings should follow the parcel. Select Rotate Tool. Rotate the parcel. The building should rotate, too. Delete the parcel using the Delete key. The buildings are deleted, too. Restore the features using Ctrl + Z.
In the Editor toolbar, select Editor | Stop Editing, and save your edit. Select File | Save as to save your map document.