ArcGIS Server Banner

How geodatabases are stored in a DBMS

How geodatabases are stored in a DBMS
Release 9.3 E-mail This TopicPrintable VersionGive Us feedback
The primary purpose of this document is to describe the table structure used in each database management system (DBMS) to physically store and work with geodatabases. This section describes some of the underlying physical storage concepts for ArcSDE geodatabases.

Many geodatabases utilize relational databases such as Oracle, IBM DB2, or Microsoft SQL Server for data storage and management of geographic information. This enables the geodatabase to be scaled to extremely large sizes and to support a large number of users and editors. ArcSDE geodatabases also support a number of critical data management workflows such as versioning, replication, and historical archival.

Physical storage of geodatabases

The primary mechanism for geodatabase storage is via tables. Tables are stored either as files on disk or within the contents of a DBMS as follows:


Type of geodatabase Data storage method
Personal geodatabase

 Microsoft Access
File geodatabase

 A file system folder containing data files
ArcSDE for SQL Server Express (included with ArcGIS Desktop [ArcEditor or ArcInfo], ArcGIS Engine, and ArcGIS Server Workgroup)

Microsoft SQL Server 2005 Express Edition

ArcSDE geodatabase support included with ArcGIS Server Enterprise; requires that you acquire your own DBMS, except in the case of ArcSDE for PostgreSQL, which includes an installation of PostgreSQL 8.3.0
  • IBM DB2—Enterprise Server Edition.

  • IBM Informix Dynamic Server—Workgroup or Enterprise Edition.

  • Oracle—Standard One, Standard, or Enterprise Edition. Oracle Spatial or Oracle Locator can be used as an option to store geometry, as can the ISO spatial type.

  • PostgreSQL 8.3.0.

  • Microsoft SQL Server—Workgroup, Standard, or Enterprise Edition.

Storing and managing spatial data

Geodatabase storage in a DBMS contains two sets of tables—system tables and dataset tables (also called user-defined tables).

For example, a simple feature class stored in a geodatabase within a SQL Server DBMS is made up of a business table, an associated feature (f) table, and a spatial index (s) table. These tables work with a set of system tables: the i table, the gdb_objectclasses, sde_table_registry, sde_layers, and sde_spatial_references system tables. These are used to track information about the feature class.

Each DBMS has a slight variation in the set of tables and columns used to store and manage a geodatabase. The type of DBMS you are using to store your geodatabase will impact the physical storage schema.

The topics in the book "Feature geometry and raster data storage" explain the different storage options available for spatial data in each DBMS. The books "Inside a geodatabase in <DBMS>" compare the way data appears in ArcCatalog, the DBMS, and XML documents.

In the table diagrams, relationships between tables are shown with either a solid or dashed line. The solid line indicates an explicit relationship. That means this relationship is defined in the database. The dashed lines denote implicit relationships. Implicit relationships are not enforced by the DBMS; the relationships are noted to let you know when the value in one table is the same or derived from a value in another table.