14.2 Geodatabase Schema Architecture: Feature Datasets, Subtypes & Attribute Domains

Geodatabase Schema Architecture: Feature Datasets, Subtypes & Attribute Domains

Quick Summary: In modern GIS systems, the geodatabase provides a comprehensive object-relational model for spatial data management. Beyond storing simple geometries, geodatabases enforce advanced organizational and behavioral rules. Feature datasets enforce a shared spatial reference for contained classes, attribute domains constrain permitted values, and subtypes partition a feature class into logical groups with distinct defaults and business rules. These controls improve integrity but do not replace validation and governance.

---

Enterprise vs. File Geodatabase Architecture

The geodatabase architecture provides two distinct deployment models designed for different institutional scales: File Geodatabases (FGDB) and Enterprise Geodatabases (EGDB).

+-----------------------------------------------------------------------------------+
| FILE GEODATABASE (.gdb)               | ENTERPRISE GEODATABASE (RDBMS)            |
+---------------------------------------+-------------------------------------------+
| • Stored in a file system directory   | • Stored within an RDBMS (PostgreSQL,     |
| • Binary proprietary tables (.gdbtable|   Oracle, SQL Server, SAP HANA)           |
| • 1 TB default capacity per table     | • Unlimited capacity (governed by DBMS)   |
| • Single-user editing per table       | • Concurrent multi-user editing           |
| • File system read/write locks        | • Traditional and Branch Versioning       |
| • No native user permissions          | • DBMS roles, privileges, row-level security|
| • Standalone desktop workstations     | • Enterprise client-server & web services |
+---------------------------------------+-------------------------------------------+

File Geodatabase Architecture

A File Geodatabase is stored as a folder in the file system with the .gdb extension, containing binary files that store schema definitions, vector geometries, attribute tables, indexes (.spx, .atx), and transaction locks (.lock).

• Storage Capacity: Each table or feature class has a default capacity of 1 TB, which can be expanded to 256 TB using custom configuration keywords.
• Concurrency & Locking: Supports unlimited concurrent readers, but only one active editor per feature class or table at any given time. Editing places a shared lock on the geodatabase and an exclusive write lock on the target table, preventing other users from editing that specific dataset simultaneously.
• Portability: Highly portable across operating systems (Windows, Linux, macOS) without requiring database server software or client licensing.

Enterprise Geodatabase Architecture

An Enterprise Geodatabase (historically referred to as ArcSDE) stores spatial datasets inside a commercial or open-source relational database management system (such as PostgreSQL, Microsoft SQL Server, Oracle, or SAP HANA). Rather than operating as standalone files, the geodatabase logic is integrated directly into the database engine via system repository tables and dynamic link libraries.

• Client Direct Connect: Modern GIS applications connect directly to the underlying RDBMS using native database client drivers, eliminating the legacy ArcSDE application server middleware.
• System Metadata Tables: System catalog tables (prefixed with sde_ or gdb_, such as sde_layers, sde_table_registry, sde_spatial_references, and sde_versions) maintain schema relationships, coordinate reference metadata, and versioning states.
• Enterprise Capabilities: Supports high-concurrency multi-user editing, long-running transactional versioning, point-in-time database recovery, automated archival tracking, and fine-grained role-based permissions.

Detailed Comparison: File vs. Enterprise Geodatabase

---

Feature Datasets: Purpose, Rules, and Structural Enforcements

A Feature Dataset is an organizational and behavioral container within a geodatabase designed to group spatially related feature classes. It is fundamentally different from a standard file system folder because it imposes strict spatial and structural constraints.

+-----------------------------------------------------------------------------------+
| FEATURE DATASET: Water_Distribution_Network                                       |
| Coordinate System: NAD 1983 State Plane Texas Central FIPS 4203 (US Feet)        |
| XY Tolerance: 0.00328 ft | XY Resolution: 0.000328 ft | Z & M Domains: Enabled    |
+-----------------------------------------------------------------------------------+
|  CONTAINED FEATURE CLASSES (Inherit Exact Spatial Reference & Tolerances):        |
|  • Water_Mains (Polyline)                                                        |
|  • Water_Valves (Point)                                                          |
|  • System_Hydrants (Point)                                                       |
|  • Storage_Tanks (Polygon)                                                       |
+-----------------------------------------------------------------------------------+
|  CONTAINED SPATIAL INTEGRITY RULES & ADVANCED MODELS:                             |
|  • Geodatabase Topology: "Water_Mains Must Not Self-Intersect"                    |
|  • Geodatabase Topology: "Water_Valves Must Be Covered By Boundary Of Water_Mains"|
|  • Geometric Network / Utility Network Connectivity Rules                        |
+-----------------------------------------------------------------------------------+

The Spatial Reference Mandate

The defining rule of a Feature Dataset is that every feature class within it must share the identical spatial reference system. This encompasses:

1. Horizontal Coordinate System: Identical projection, datum, spheroid, and central meridian.
2. Vertical Coordinate System: Identical vertical datum (if Z-values are enabled).
3. XY, Z, and M Tolerances: The spatial clustering threshold within which coordinates are considered geometrically coincident during topological validation.
4. XY, Z, and M Resolutions: The grid interval representing the minimum numerical precision of stored vertices.

[!IMPORTANT] Once a Feature Dataset is created, its spatial reference and tolerance parameters are permanently locked. If an existing feature class was created in a different coordinate system, it cannot be imported or moved into the feature dataset without undergoing coordinate reprojection.

Advanced Models Dependent on Feature Datasets

Feature Datasets are not merely organizational; they are structural prerequisites for several advanced geospatial models that require strict coordinate coincidence:

• Geodatabase Topologies: Topological validation rules (e.g., "Parcels Must Not Overlap", "County Boundaries Must Not Have Gaps") can only be established across feature classes that reside within the same Feature Dataset.
• Utility Networks & Geometric Networks: Network connectivity models governing flow, valves, pipes, and electrical distribution lines must be modeled within a single Feature Dataset.
• Parcel Fabrics: Cadastral parcel modeling systems require shared boundaries and control point networks constrained to a Feature Dataset.
• Terrain Datasets: Multiresolution TIN-based elevation models built from mass points, breaklines, and clip polygons require unified tolerance structures within a Feature Dataset.

Standalone Feature Classes

A Standalone Feature Class resides directly at the root level of the geodatabase, outside of any Feature Dataset. Standalone feature classes:

• Maintain their own independent spatial reference and tolerance settings.
• Cannot participate in geodatabase topologies, geometric networks, or parcel fabrics.
• Introduce lower system overhead and are preferred for independent thematic layers (e.g., satellite footprints, base imagery grids, standalone demographic census tables).

---

Attribute Domains: Enforcing Schema-Level Tabular Integrity

Attribute Domains are geodatabase-level rules that define the legal values allowed in attribute fields. Domains are defined at the geodatabase level and can be applied across multiple feature classes, subtypes, and tables.

                    ATTRIBUTE DOMAINS IN THE GEODATABASE

         +-------------------------------------------------------+
         |             GEODATABASE DOMAIN REPOSITORY             |
         +---------------------------+---------------------------+
                                     |
             +-----------------------+-----------------------+
             |                                               |
             v                                               v
   [CODED VALUE DOMAIN]                              [RANGE DOMAIN]
   • Discrete enumerated list                        • Continuous numeric bounds
   • Stores Code, displays Description               • Defines Min and Max thresholds
   • Example: Pipe_Material                          • Example: Operating_Pressure
     Code: 1 -> "Ductile Iron"                         Min: 20.0 psi
     Code: 2 -> "PVC"                                  Max: 120.0 psi
     Code: 3 -> "Cast Iron"                            Type: Float / Double / Integer

Coded Value Domains vs. Range Domains

Split and Merge Policies

When spatial features are edited in GIS desktop clients, geometries are frequently split or merged. Domain policies dictate what happens to attribute values during these geometric operations:

Split Policies

• Default Value: Attributes on both resulting features revert to the predefined default value for that field.
• Duplicate: The original attribute value is copied identically to both resulting features (standard for categorical codes like material type or county name).
• Geometry Ratio: The attribute value is divided proportionally based on the geometric ratio of the split features. For example, if a 10-acre parcel with an estimated yield of 100 bushels is split into 7-acre and 3-acre parcels, the yield is divided into 70 and 30 bushels.

Merge Policies

• Default Value: The attribute of the newly merged feature reverts to the field default.
• Sum: The numeric attribute values of the merged features are added together (useful for population counts or square footages).
• Weighted Average: The resulting attribute is calculated as the average of the merged features' values, weighted by their respective lengths or areas.

---

Subtypes: Partitioning Feature Classes for Performance and Flexibility

Subtypes are subsets of features within a single feature class that are partitioned based on an integer attribute field (Short Integer or Long Integer). Subtypes allow features that share the same geometry type and general schema to behave differently without requiring separate tables.

+-----------------------------------------------------------------------------------+
| FEATURE CLASS: water_distribution_mains (Line Feature Class)                      |
| Subtype Field: asset_subtype (Long Integer)                                       |
+-----------------------------------------------------------------------------------+
| SUBTYPE 1: Transmission Mains                                                     |
| • Default Diameter: 24.0 inches                                                   |
| • Diameter Domain: Range_Transmission_Diameter (16.0 to 72.0 inches)              |
| • Material Domain: Coded_Steel_Concrete_Only                                      |
| • Topology Rule: Must Not Cross Other Transmission Mains                          |
+-----------------------------------------------------------------------------------+
| SUBTYPE 2: Distribution Mains                                                     |
| • Default Diameter: 8.0 inches                                                    |
| • Diameter Domain: Range_Distribution_Diameter (4.0 to 12.0 inches)               |
| • Material Domain: Coded_Ductile_PVC_HDPE                                         |
| • Topology Rule: Must Connect to Valves or Fittings at Dead Ends                  |
+-----------------------------------------------------------------------------------+
| SUBTYPE 3: Service Laterals                                                       |
| • Default Diameter: 1.0 inch                                                      |
| • Diameter Domain: Range_Service_Diameter (0.75 to 2.0 inches)                    |
| • Material Domain: Coded_Copper_PEX_Only                                          |
| • Topology Rule: Must Connect to Distribution Main and Water Meter                |
+-----------------------------------------------------------------------------------+

Why Use Subtypes Instead of Separate Feature Classes?

Creating separate feature classes for every asset variation (e.g., transmission_mains, distribution_mains, service_laterals) introduces severe database overhead:

1. Table Proliferation: Triples or quadruples the number of database tables, spatial indexes, and layers that must be maintained.
2. Slow Query Performance: Running queries or spatial overlays across the entire pipeline network requires complex UNION operations across multiple tables.
3. Cluttered Map Documents: Each feature class must be added, symbolized, and labeled independently.

Using Subtypes consolidates all features into a single physical database table, maximizing spatial index efficiency and query performance, while preserving tailored behaviors:

• Each subtype can have its own default values for each attribute column.
• Each subtype can bind to different attribute domains for the same field (as shown above, where diameter domains differ across subtypes).
• Each subtype can enforce unique topological and connectivity rules.

Subtype Field Requirements

[!CAUTION] The subtype field MUST be an integer data type (either Short Integer or Long Integer). Text (string), floating-point, or date fields cannot be configured as subtype fields. Each subtype is formally identified by a unique integer code (e.g., 1, 2, 3) paired with a descriptive label.

---

Summary of Common Exam Traps

[!CAUTION] Exam Trap 14.2.1: The Misconception That Feature Datasets Are Simple Folders. Never treat a Feature Dataset as a simple folder or catalog group. It is an active spatial constraint. Every feature class inside it MUST share the exact same spatial reference, XY tolerance, and resolution. You cannot place a WGS84 feature class and a State Plane feature class into the same Feature Dataset.

[!CAUTION] Exam Trap 14.2.2: Invalid Data Types for Subtype Fields. Exam questions often present scenarios where an analyst attempts to create subtypes based on a text field like asset_category containing strings ("Residential", "Commercial"). This operation will fail. A subtype field must be defined as a Short or Long Integer.

[!CAUTION] Exam Trap 14.2.3: Applying Duplicate Split Policy to Extensive Attributes. If an extensive quantitative attribute (such as parcel acreage, construction cost, or total building square footage) is assigned a Duplicate split policy, cutting a feature in half will assign the entire original value to both resulting pieces, artificially doubling the total reported asset value. Extensive attributes must be assigned a Geometry Ratio split policy.