Geodatabase storage in relational databases
At the core of the geodatabase is a standard (that is, not exotic) relational database schema (a series of standard database tables, column types, indexes, and other database objects). 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 for Desktop, embedded ArcGIS Engine logic, or ArcGIS for Server.
Each of these includes geodatabase objects that define a generic geographic information system (GIS) 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 database management system (DBMS) tables, in file geodatabases, and as extensible markup language (XML) streams.
Geodatabase storage includes both the schema and the 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 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 binary large object (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 Structured Query Language (SQL) for spatial types as the primary author of the SQL/MM Part 3 Spatial and the Open Geospatial Consortium, Inc. (OGC) Simple Features SQL specifications. Esri has focused on support for these types, as well as the independent Oracle Spatial, PostGIS (in PostgreSQL), and Microsoft SQL Server spatial 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 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 ST_Geometry or PostGIS geometries
- Microsoft SQL Server using Microsoft spatial types, geometry and geography
For detailed information about the storage schema used by the geodatabase in each DBMS, refer to How are geodatabases stored in a DBMS?