The ArcGIS platform and the geodatabase
ArcGIS is a complete, integrated GIS platform. It is a system for managing information, organizing and visualizing maps and data, and analyzing relationships and patterns over any geography. This allows you to design, plan, and perform predictive analytics. You can make informed decisions based on analysis, take action, and share this information across and between organizations. In this way, the platform both offers a way to manage your system of record and is also a system of insight. ArcGIS is a system of engagement as well, leveraging web services to integrate individuals, teams, departments, and whole organizations with shared knowledge. This promotes collaboration between distributed systems and people, and ultimately the platform is a complete Web GIS: a system of systems.
The ArcGIS platform is flexible and supports multiple implementation patterns based on your needs, from the desktop to a server to an online web experience with enterprise, portal, and ArcGIS Online. Or you can implement any combination of these components. It is a complete cloud-based mapping platform with apps and content. Public APIs are available to develop your own solutions and extend the capabilities of ArcGIS beyond what's available out of the box. The intention of the platform design is to support individuals, teams, and organizations in whatever capacity they need, so it is suitable for one-person shops as well as massive, international organizations.
A core part of the platform, and any GIS, is data management and compilation. ArcGIS Pro uses the geodatabase to manage geographic data. The geodatabase stores spatial and nonspatial data and organizes it into datasets. Examples of the types of datasets that might be maintained in a geodatabase include tables, feature classes, relationship classes, topologies, and utility networks. An enterprise geodatabase stores data in a relational database and leverages its capabilities to support storage of large datasets as well as provide efficient multiuser access to data. It also allows you to share data as services to your portal or online.
A typical life cycle for an enterprise geodatabase involves the following steps:
- Geodatabase design
- Geodatabase creation
- Initial data loading—During this phase, data is loaded for an area of interest. The data being loaded can come from existing corporate databases, portals or map libraries, or online sources such as the Living Atlas, or it can be purchased.
- Editing and data management—During
this phase, existing data is modified, and new data is added to the
database as required.
Examples of changes that might be made to a geodatabase during editing and data management include the following:
- Updating the address of a customer
- Subdividing a parcel to reflect a sale in a parcel fabric database
- Adding a service drop to a new customer in a utility database
- Updating a forest block to reflect a planned cutting operation
- Designing a new substation in a utility database
- Using an app in the field, such as Collector, to modify assets to reflect storm-related damage
- Planning a new subdivision in a land-planning database
- Performing a what-if scenario for a disaster recovery simulation
Each of the above changes corresponds to an application-defined unit of work, or transaction, that is performed against a geodatabase.
What is a transaction?
A transaction is a unit of work performed against a database. A transaction starts, modifications are made against the database, and then the transaction is committed or rolled back. Once the transaction is committed, the changes made by the transaction become visible to other users and applications.
Transactions have the following standard properties, known as ACID properties, on which users and applications have come to rely:
Atomic—A transaction exhibits all-or-nothing behavior. If it is committed, all of its changes apply to the database. If it is rolled back, none of its changes apply.
Consistent—A transaction leaves the database in a consistent state.
Isolation—A transaction can isolate its changes from other transactions until it commits them. Other users do not see the work internal to the transaction while it is in progress.
Durable—Once a transaction commits, its results are persistent.
To achieve these properties, database management systems use a variety of locking mechanisms to ensure that multiple concurrent transactions are shielded or isolated from each other.
Transactions and geographic data
In most applications, each transaction involves a small number of operations that can be completed in a fraction of a second or in a minute or two at the most. Withdrawing money from a bank account, updating hours worked in a payroll application, and entering a medical record are all examples.
In some respects, geographic data is no different. Updating data, such as a customer address or the zoning designation of a parcel, is an operation that could be completed in a short transaction taking one or two minutes.
Often, though, you need to spend one or two hours graphically moving, modifying, and adding data to complete a work order. There are also cases where you need to work on a transaction for days or even months to complete all the edits, such as for an engineering design. Even though you may make a very large number of changes, you still want to perform the workflow in complete isolation and commit them as a single long transaction.
The Enterprise data management strategies topic discusses how you can support transactions of varying complexity and duration against both simple and complex geographic data.