A new team is taking over a fifteen-year-old database that has no current documentation. The original developers have left, and the team must make schema changes next quarter. What should the team do first?
Select an answer to reveal the explanation.
Short Explanation
You wouldn't renovate a house without first sketching where the walls and pipes are. Reverse-engineering an ERD and data dictionary gives you that sketch before you start swinging the hammer. Changing things first and documenting later is how you cut through a load-bearing wall.
Full Explanation
Design documentation for an undocumented system is produced by reverse engineering the existing schema: extracting tables, columns, data types, keys, constraints, indexes, views, procedures and triggers from the catalog, generating an ERD that shows relationships and building a data dictionary that records types and, after investigation with users and code, the meaning of each column. Reviewing these artifacts with stakeholders exposes undocumented dependencies before any change is made and gives the team a baseline for impact analysis. Refactoring first and documenting afterward reverses the order; without understanding dependencies, the team risks breaking applications, reports and integrations it does not know exist. Informal interviews are useful input, but memories are incomplete and inconsistent, and unrecorded knowledge leaves the next team in the same position. A backup file protects data and can recreate the database, but it is not readable documentation of meaning, relationships or business rules. Exam caveat: reverse-engineered relationships include only declared foreign keys; implicit relationships enforced in application code must be found through analysis of queries and code. Operational check: compare the generated ERD against actual join patterns found in query logs to uncover relationships the schema does not declare.