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.
However, adding spatial types and SQL support for spatial attributes to a DBMS 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, raster datasets, topologies, networks, and much more.
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 DBMS 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 DBMSs 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 DBMS that defines the integrity and behavior of the geographic information. These tables are stored either as files on disk or within the contents of a DBMS such as Oracle, IBM DB2, PostgreSQL, IBM Informix, or Microsoft SQL Server.
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 internal structure of these tables was restructured beginning with the ArcGIS 10 release. The information related to the schema in the geodatabase, which prior to ArcGIS 10 was stored in over 35 geodatabase system tables, was consolidated into four main tables:
- GDB_Items: Contains a listing of all items contained within a geodatabase such as feature classes, topologies and domains
- GDB_ItemTypes: Contains a predefined list of recognized item types, such as Table
- GDB_ItemRelationships: Contains schema associations between items such as which feature classes are contained within a feature dataset
- GDB_ItemRelationshipTypes: Contains a predefined list of recognized relationship types such as DatasetInFeatureDataset
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 simply a table with a spatial column. However, when accessed through ArcGIS, all of the rules stored in the system tables are combined with the underlying data to present it as a feature class with all of the defined behavior.
Additional tables
Depending on what type of geodatabase you are using and in which DBMS 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. For Enterprise geodatabases, the different system tables are defined in the System tables of a geodatabase topics for each specific DBMS. The different tables stored in file and personal geodatabase are not detailed, since you would not need to interact with most of these tables.