Data Management
Data Management tests whether you can design and maintain a geodatabase that enforces integrity, performs well, and survives schema change. Expect questions on schema objects, domains and subtypes, relationship classes, topology, coordinate systems, versioning, archiving, and metadata, not just importing data.
Schema objects and integrity
A feature dataset groups feature classes that share a spatial reference and participate in topology or a network. Domains are reusable value lists or ranges; subtypes partition one feature class and can assign default domains. Attribute rules enforce constraints and calculations at edit time. Relationship classes can be simple or composite: a composite relationship deletes destination rows when the origin is deleted; a simple relationship does not. Topology rules validate spatial relationships inside a feature dataset, and exceptions record legitimate violations.
Coordinate systems and storage
Geographic coordinate systems use angular units; projected coordinate systems use linear units. ArcGIS Pro can project on the fly for display, but analysis should use a projected coordinate system with suitable units. A feature dataset fixes its coordinate system, so all members must match. File, mobile, and enterprise geodatabases differ in capacity, behavior, and collaboration. Versioning and archiving are enterprise geodatabase workflows: versioning supports multiple edit sessions and reconcile/post; archiving records historical states in history tables.
Worked example
A water utility needs one asset class for hydrants and valves, plus inspections. Put the asset class in a State Plane feature dataset. Add a subtype field AssetType with values Hydrant and Valve, and a coded domain for status. Add a range domain for pressure. Create a one-to-many relationship from asset to inspection. Make it simple, not composite, because inspection records must remain auditable after an asset is retired. Add a constraint attribute rule preventing future installation dates. Validate the topology that valves must not overlap; review exceptions. Reasoning: the subtype keeps one schema, domains limit invalid values, the simple relationship preserves history, and the rule prevents bad edits at the source.
Traps
Do not confuse domains with subtypes: a domain constrains values; a subtype categorizes and can set defaults. Do not put feature classes with different coordinate systems in one feature dataset. Do not use a composite relationship when child records must survive parent deletion. Do not assume topology fixes data automatically; it flags errors until you validate and correct them. Versioning is not archiving, and neither is available in a file geodatabase. Check field lengths and reserved words before loading data.