Before designing database tables for a civic asset register, what modeling step should come first?
Select an answer to reveal the explanation.
Short Explanation
You do not pour concrete before you know rooms and doors. For an asset register, name the things and how they relate—assets, locations, work orders—before physical table design.
Full Explanation
Before designing database tables for a civic asset register, modeling should begin by identifying core entities, attributes, and relationships in a conceptual model. That step clarifies what the city manages—assets, locations, custodians, work orders—before physical choices lock in. Picking index types and partition keys before naming business entities optimizes storage for an undefined subject and invites costly rework. Generating random column names and assigning meanings afterward abandons shared language. Implementing triggers and procedures with no entity list embeds process logic without a coherent domain model. Exam sequencing favors conceptual clarity first for shared registers. Caveat: conceptual models stay technology-neutral; do not confuse them with physical DDL even when delivery is iterative. Operationally, facilitate a short workshop with asset stewards to approve the entity-relationship sketch, then proceed to logical attributes and only then to table design keyed to that approved conceptual baseline. Conceptual work also surfaces shared identifiers and ownership early, which later logical and physical models inherit—reducing the chance that each department invents incompatible asset keys during table design.