Note:This topic was updated for 9.3.1.
At the core of the geodatabase is a standard (that is, not exotic) relational database schema (a series of standard DBMS tables, column types, indexes, and so on). This simple physical storage works in concert with, and is controlled by, a set of higher-level application objects hosted in the application tier, which can be an ArcGIS Desktop, embedded ArcGIS Engine logic, or an ArcGIS server.
Each of these include geodatabase objects that define a generic GIS information model that is shared by all ArcGIS applications and users. The purpose of the geodatabase objects is to expose a high-level GIS information model to clients and to persist the detailed implementation of this model in any appropriate storage model—for example, in standard DBMS tables, in file geodatabases, and as XML streams.
Geodatabase storage includes both the schema and rule base for each geographic dataset plus simple, tabular storage of the spatial and attribute data.
The geodatabase schema includes the definitions, integrity rules, and behavior for each geographic dataset. These include properties for feature classes, topologies, networks, raster catalogs, relationships, domains, and so forth. The schema is persisted in a collection of geodatabase meta tables in the DBMS that defines the integrity and behavior of the geographic information.
The spatial representations are most commonly stored as either vector features or as raster datasets along with traditional tabular attributes. For example, a DBMS table can be used to store a feature class where each row in the table represents a feature. A shape column in each row is used to hold the geometry or shape of the feature. The shape column holding the geometry is typically one of two column types:
A BLOB column type
A spatial column type, if the DBMS supports it
A homogeneous collection of common features, each having the same spatial representation, such as a point, line, or polygon, and a common set of attribute columns, is referred to as a feature class and is managed in a single table.
Raster and imagery data types can be managed and stored in relational tables as well. Raster data is typically much larger in size and requires a side table for storage. For DBMS storage and access, each raster is cut into smaller pieces, or blocks, and stored in individual rows in the separate block table.
The column types that hold the vector and raster geometry can vary from database to database. Recently, most DBMSs have added support for spatial type extensions, and the geodatabase can readily use them to hold the spatial geometry. ESRI was closely involved in efforts to extend SQL for spatial as the primary authors of the SQL 3 MM Spatial and the OGC Simple Features SQL specifications. ESRI has focused on support for these types, as well as the independent Oracle Spatial and PostGIS (in PostgreSQL) types, in the persistence of geodatabases using DBMS standards.
Presently, all DBMSs include spatial type support for geodatabases using ArcGIS as follows:
Oracle using the ArcSDE Spatial Type (ST_Geometry) or optionally the Oracle Spatial type
IBM DB2 using the Spatial Extender Geometry Object
Informix using the Spatial DataBlade Geometry Object
PostgreSQL using the ArcSDE Spatial Type (ST_Geometry) or PostGIS geometries
Microsoft SQL Server using Microsoft spatial types, geometry and geography
