When you query your database using database management system or SQL tools, you'll see geodatabase dataset tables. All the tables that compose a single dataset are owned by the database user who created the dataset.
The tables created for each type of dataset supported in an enterprise geodatabase are listed here so you can identify them. These tables should be altered using SQL.
Feature datasets are objects that allow you to implement specific geodatabase dataset types, such as networks or topologies. A feature dataset is not a separate table in the database; it is a virtual collection of feature classes and controller (or extension) datasets that are grouped by a common ID. The ID is maintained in the gdb_items system table. Each feature class is identified as part of the feature dataset through the gdb_itemrelationships system table.
Geometric networks are collections of line (edge) and point (junction) feature classes in a feature dataset that possess a connectivity relationship. Geometric networks are legacy dataset types used to model utility infrastructure, such as electric lines and sewer systems.
The number of tables varies depending on the elements the network contains. A maximum of 21 tables can be created for a geometric network that contains turns and weights.
The asterisk (*) in the following list denotes tables that are always created for a geometry network. The ID in the table names is the logical network ID, which is stored in the gdb_items system table.
Network datasets are collections of feature classes that possess a connectivity relationship. Network datasets are created using three types of sources-edge feature sources, such as street centerlines; junction feature sources, such as point feature classes containing railroad crossings; and turn feature sources. They are used to model transportation.
The following tables store network dataset information. The ID in the first six tables is the logical network identifier. The itemID in the last two tables is the object ID of the network in the gdb_items system table.
Schematic datasets are similar to feature datasets, but they contain a collection of schematic diagram templates and schematic feature classes. They are used to graphically visualize and manipulate network data.
The ID in the table names is the schematic dataset identifier stored in the sch_dataset table. An asterisk (*) indicates that tables are created when the schematic dataset is created.
- sch<id>_eltclass*—For every row in this table, one sch<id>e_<feature_class_name> and one sch<id>a_<feature_class_name> table are created.
- sch<id>d_<diagram_template_name>—This table is created when a diagram template is created in the schematic dataset.
- sch<id>r_<diagram_template_name>—This table is created when a diagram template is created in the schematic dataset.
Parcel fabrics are a type of dataset in the geodatabase that is created and maintained using data from survey plans. The fabric is a continuous, integrated surface of connected parcels representing the complete survey record for an area of land. The dataset contains several feature classes. These feature classes represent the boundaries, endpoints, and other physical attributes of parcels.
ArcMap parcel fabrics
These parcel fabrics are accessed in the geodatabase directly from ArcMap. Access to these parcel fabrics is read-only in ArcGIS Pro.
The following tables in the database are part of an ArcMap parcel fabric:
Topologies are rules that enforce data integrity and manage the behavior of spatially related feature classes. A geodatabase topology stores information about the feature classes that participate in the topology, the cluster tolerance assigned to the topology, the relative rank of each feature class in the topology, and a list of the rules that apply to that topology.
When you validate a topology, the dirty areas and topology errors identified for the topology are stored in a set of tables owned by the user connected to the geodatabase when topology validation is performed.
The following are the tables that compose a topology. The ID in the table names is the topology identifier stored in the gdb_items system table.
Terrain datasets are surfaces that represent three-dimensional space. They use measurements (stored as feature classes) and rules to generate triangular irregular network (TIN) pyramids to represent elevation. The source feature classes can either be referenced by the terrain dataset or embedded in the terrain dataset.
The following internal tables are part of a terrain dataset:
- dtm_<objectID>_embed_#—Only present if the terrain dataset contains embedded data. There will be one table per embedded feature class in the terrain dataset.
Multiple tables that store information about the imagery that is stored on disk are used to implement mosaic datasets. A set of properties and rules in the tables defines a real-time mosaic view of the imagery data.
There can be up to 12 tables in a mosaic dataset. Some of the tables are generated the first time you perform an operation that requires the table's existence. Referenced mosaic datasets only have two tables: the BND and LOG tables. The tables are as follows:
Raster datasets and raster catalogs
Raster data is spatial data represented in an array of equally sized cells arranged in rows and columns. Raster data is composed of one or more raster bands. When you create or import a raster dataset, a raster column is added to the base table when it is created in the database. Each cell of the raster column contains a reference to a raster stored in a separate raster table.
Each raster dataset or raster catalog contains a base table that stores attributes, a raster column, and the footprint (the area) of the raster.
Raster images and properties are stored in the following tables:
- sde_vat_<raster_column_ID>—Optional table to define attributes for raster cell values of a raster dataset.
- sde_vat_<raster_column_ID>_<ObjectID>—Optional tables to define attributes for raster cell values of a raster catalog. Each raster catalog can have several of these tables.
Toolboxes store geoprocessing tools and scripts. You can create a toolbox in your geodatabase to store system geoprocessing tools you use often and custom scripts that you create.
There will be one table per toolbox. The table name corresponds to the name of the toolbox.