Data maintenance strategies

Transactions against geographic data can vary widely in duration and complexity. The geodatabase supports two data maintenance strategies—maintenance with and without versions—which balance the needs of users and applications to perform short and long transactions on data that is simple or complex.

Each strategy can be applied on a feature-class-by-feature-class or table-by-table basis, so it's possible to make use of both of them in the same geodatabase.

The way you edit data in each of these strategies is similar—you edit within an edit session and work with many of the same tools. What differs is how the underlying data sources are maintained. There are also some differences in which data you can edit and the type of workflows you can perform. This topic explains these differences.

Data maintenance without versions

This strategy does not involve working with multiple versions—it simply makes use of the underlying DBMS transaction model. Nonversioned edits are equivalent to standard database transactions.

To edit data, you enable nonversioned editing from the Editor Options dialog box; start an edit session; then perform the required operations, such as adding, deleting, or moving features and updating attributes. Your first edit in the edit session begins the transaction. When you save, the individual edit operations you've performed are committed to the database as a single transaction. After you save, the next edit you make begins a new transaction. You can save as few or as many operations at a time as required during the edit session, though frequent saving is recommended to avoid locking the data you are editing and blocking other users from accessing or editing the data. Once saved, the changes are available to all other users and applications accessing the data.

If you do not want to commit your edits to the database, stop editing without saving. All the edits in that transaction—all edits since your last save or, if you have not yet saved, all edits since the edit session began—will be eliminated and will not be committed to the database.

Data maintenance without versions

As you edit, any unique indexes, constraints, and triggers defined on the data with the DBMS apply. All the same locking behavior applies as if you were performing transactions on the data with the DBMS directly. Therefore, there is the potential for users or applications that access or modify the same data to block one another. When using nonversioned editing in a multiuser editing environment, you should understand how isolation levels and locking work in your DBMS and, if necessary, set the correct isolation level in the DBMS before you start working with ArcGIS.

This strategy is appropriate for simple features for which you don't need to manage history or multiple representations of the data with versions. Since this strategy doesn't require versions, it's also useful if you require both GIS and non-GIS applications to share access to a common database.

Potential applications

Limitations

Data maintenance with versions

The geodatabase extends the standard DBMS transaction by allowing multiple concurrent states of the databases, known as versions, to exist at the same time. Each version can represent ongoing work, such as a design or a group of work orders, work that can span multiple connections to the database and extend over a period of weeks or months if necessary. Versions allow you to manage past, present, and proposed changes to the data—all in the same geodatabase.

To manage past changes, you save any changes to the data in separate archive tables. You can keep these changes for as long as required, allowing users to see how the database looked at some previous point in time. This capability is referred to as archiving and is built into ArcGIS; no development is required. When you enable this capability, changes to the DEFAULT version, normally used as the published version of the database, are archived automatically.

To manage current changes, editors can modify their private version of the geodatabase so that other users cannot see incomplete work. When you edit a version of the data, you don't apply locks. Therefore, you maximize concurrency, because other users can read and edit the same data you're modifying; you don't block one another from accessing the database. Once an editor has finished his or her changes, he or she can integrate them into the published version.

To manage proposed changes, you can develop a scenario or perform a what-if analysis within a version of the database. The scenario can be managed as a single unit of change, spanning multiple edit sessions and days, weeks, or months. You can freely add proposed features, perform geographic analysis, and produce maps—all without affecting the database other users are accessing. Once the changes are complete and have been approved, you can integrate them into the rest of the geodatabase.

Versions help you manage past, current, and proposed changes

There is no limit to the number of versions a geodatabase can have. Versions can be arranged in various configurations and support a wide variety of workflows. However, for the sake of simplicity and geodatabase management considerations, a recommended best practice is to either maintain a flat version tree or have multiple editors concurrently editing the DEFAULT version.

A geodatabase can have many versions

To support versioning capabilities, ArcGIS doesn't duplicate data. Instead, it leaves each feature class and table in its original format but records any changes in tables known as delta tables. Delta tables consist of an adds table for insertions and updates and a deletes table for deletions. Each time you update or delete a record in any version, rows are added to one or both of these tables. When you query or display a feature class or table in a version, ArcGIS assembles the relevant rows from the delta tables and the original table to present a seamless view of the data.

Delta tables
Editing a versioned feature class

Versioned tables require periodic maintenance by a database administrator. As a geodatabase is edited over time, delta tables increase in size, affecting display and query performance. To maintain performance, the database administrator can periodically compress a versioned database, an operation that removes redundant information from the delta tables. Versioned databases should be compressed whenever a period of high database activity has ended, for example, at the end of a shift or after loading new data. The compression process can be run while other users are connected and using the database.

ArcGIS can manage the underlying delta tables that support versions in one of two ways:

The first way is designed to support ArcGIS applications exclusively. The second way is useful if you need to maintain the data with both ArcGIS and third-party applications.

Maintaining data exclusively with ArcGIS applications

In an environment where you maintain data exclusively with ArcGIS applications, the best way to manage versions is to save all changes in the delta tables. This allows you to take maximum advantage of the capabilities of the geodatabase including archiving, replication, and the ability to edit geometric networks and topologies.

To enable this behavior on a feature class or table, you register the data as versioned without the option to move edits to the base table. Whenever you save changes to a dataset registered this way, changes are saved in the delta tables. With this approach, direct access to the original tables is not possible—users always access a version of the data.

The following example illustrates a configuration in which data is completely managed through the use of versions. Editors require the use of ArcGIS or another Esri application to make changes to the data. Non-GIS applications can access the published version or any other version, provided they are adapted with versioned views.

Maintaining data exclusively with ArcGIS applications

Because of the delta and other tables required to support versions, applications written to directly access data in the DBMS without the use of software libraries from Esri do not have the inherent ability to read versions. ArcGIS provides versioned views that allow these applications to read a given version with SQL. Versioned views can access both tables and feature classes. Access to the geometric attributes of feature classes using a versioned view requires the use of SQL geometry types, which are fully supported by ArcGIS.

This approach provides these benefits:

Potential applications include these:

Versions provide many benefits but have some limitations:

Maintaining data with ArcGIS and other applications

In a heterogeneous computing environment where you have a number of different departmental applications accessing the same database, you may need to support both ArcGIS and third-party applications. An example of this is if you have one department that maintains the geographic data in the database with ArcGIS and another department that maintains customer records in the same database with a custom application. The custom application needs to apply DBMS constraints and triggers as transactions are made and may not recognize versioned tables. At the same time, the other department needs to edit the geographic data in its own isolated version, not sharing the departmental edits until they are complete and approved.

With these requirements in mind, ArcGIS allows you to perform versioned editing on a feature class or table while retaining the ability to share edits with other applications. To enable this capability on a feature class or table, you register the data as versioned with the option to move edits to the base table. This option is available in the registration dialog box.

When you edit data registered this way, versions work the same way as described in the previous approach: changes are saved in the delta tables. The exception to this is the DEFAULT version. Whenever you save edits to the DEFAULT version, either by editing it directly or merging in changes from another version, the edits are saved in the base tables. The edits do not remain in delta tables as is the case when the move edits to base option is unchecked.

This allows all applications to work on the same database.

Maintaining data with ArcGIS and third-party applications

Potential applications

Limitations

When you register a dataset as versioned with the move edits to base option, you are limited in how you can work with versions.

For more information about versions and the capabilities they provide, see Understanding versioning and Version scenarios.

Related Topics

7/30/2013