The geodatabase storage model is based on a series of simple yet essential relational database concepts and uses 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 data. Through this approach, structured query language (SQL) 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 a geographic information system (GIS). ArcGIS uses 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 GIS data objects and behaviors such as feature classes, raster datasets, topologies, networks, and more.
Geodatabase as an object-relational model
The geodatabase is implemented using the same multitier application architecture as in other advanced DBMS applications; there is nothing unusual about 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, or Microsoft SQL Server.
Well-defined column types are used to store traditional tabular attributes. When the geodatabase is stored in a DBMS, spatial representations, most commonly represented by vectors or rasters, are generally stored using a SQL spatial type.
In a geodatabase, there are two primary sets of tables: system tables and user-defined tables.
- System tables—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. The system tables contain and manage all the metadata required to implement geodatabase properties, data validation rules, and behaviors.
- User-defined tables—Each dataset in the geodatabase is stored in one or more tables. The user-defined tables work with the system tables to manage data.
The information related to the schema in the geodatabase is stored in the following tables:
- GDB_Items—Contains a listing of all items contained in 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 in a feature dataset
- GDB_ItemRelationshipTypes—Contains a predefined list of recognized relationship types such as DatasetInFeatureDataset
The user-defined tables and system tables work together to present and manage the contents of a geodatabase. For example, when viewed in the database, a feature class is 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.