ArcMap

The architecture of a geodatabase

The geodatabase storage model is based on a series of simple yet essential relational database concepts and leverages the strengths of the underlying database management system (DBMS). Simple tables and well-defined attribute types are used to store the schema, rule, base, and spatial attribute data for each geographic dataset. This approach provides a formal model for storing and working with your data. Through this approach, structured query language (SQL)—a series of relational functions and operators—can be used to create, modify, and query tables and their data elements.

You can see how this works by examining how a feature with polygon geometry is modeled in the geodatabase. A feature class is stored as a table, often referred to as the base or business table. Each row in the table represents one feature. The shape column stores the polygon geometry for each feature. The contents of this table, including the shape when stored as a SQL spatial type, can be accessed through SQL.

Example polygon feature class business table

However, adding spatial types and SQL support for spatial attributes to a database is not enough on its own to support GIS. ArcGIS employs a multitier application architecture by implementing advanced logic and behavior in the application tier on top of the geodatabase storage model. This application logic includes support for a series of generic geographic information system (GIS) data objects and behaviors such as feature classes, mosaic datasets, topologies, networks, and replication.

The geodatabase is object relational

The geodatabase is implemented using the same multitier application architecture found in other advanced DBMS applications; there is nothing exotic or unusual about in its implementation. The multitier architecture of the geodatabase is sometimes referred to as an object-relational model. The geodatabase objects persist as rows in database tables that have identity, and the behavior is supplied through the geodatabase application logic. The separation of the application logic from the storage is what allows support for several different database management systems and data formats.

Geodatabase storage in relational databases

At the core of the geodatabase is a standard relational database schema (a series of standard database tables, column types, indexes, and other database objects). The schema is persisted in a collection of geodatabase system tables in the database that defines the integrity and behavior of the geographic information

Well-defined column types are used to store traditional tabular attributes. When the geodatabase is stored within a DBMS, spatial representations, most commonly represented by vectors or rasters, are generally stored using an extended spatial type.

Within the geodatabase, there are two primary sets of tables; system tables and dataset tables.

  • Dataset tables—Each dataset in the geodatabase is stored in one or more tables. The dataset tables work with the system tables to manage data.
  • System tables—The geodatabase system tables keep track of the contents of each geodatabase. They essentially describe the geodatabase schema that specifies all dataset definitions, rules, and relationships. These system tables contain and manage all the metadata required to implement geodatabase properties, data validation rules, and behaviors.

The dataset and system tables work together to present and manage the contents of a geodatabase. For example, when viewed in the underlying storage format, a feature class is a table with a spatial column. However, when accessed through ArcGIS, all the rules stored in the system tables are combined with the underlying data to present it as a feature class with all the defined behavior.

Additional tables

Depending on what type of geodatabase you are using and in which database management system it is stored, the set of system tables may vary. Enterprise geodatabases have a different set of system tables than file geodatabases, which have a slightly different set than personal geodatabases. See the topics listed below for enterprise geodatabase system tables per database.

The system tables stored in personal geodatabase are not detailed, since you would not need to interact with most of these tables. File geodatabases are composed of files on disks, not tables, and you should interact with those system files.