First step when given legacy tables: what should you do before creating the new database?

Introduction / Context:
When handed legacy tables or files and asked to build a new database, it can be tempting to jump straight into creating a new database instance. However, sound methodology begins with analysis and modeling, ensuring the resulting schema accurately represents entities, relationships, and constraints before any physical implementation.

Given Data / Assumptions:

• You have existing data, possibly messy or denormalized.
• Business rules and dependencies might not be documented.
• Performance and security requirements are still being gathered.

Concept / Approach:
The first step is discovery and modeling: profile the data, identify candidate keys and dependencies, detect anomalies, and draft the conceptual and logical models. Only after the logical design is validated should you create the physical database, define tables and constraints, and load cleansed data. This reduces rework and prevents propagating legacy flaws.

Step-by-Step Solution:

Verification / Alternative check:
Teams that begin with modeling typically perform fewer disruptive refactors later. Comparing project timelines shows that early design prevents costly rebuilds post-implementation.

Why Other Options Are Wrong:

• “Immediately create the database” risks locking in a poor structure.
• Whether the legacy source is relational or whether backups exist is orthogonal to the proper first step.

Common Pitfalls:
Migrating column-for-column without understanding semantics; skipping constraints; overlooking hidden dependencies.

Final Answer:
Invalid (first create a conceptual/logical design and profile the data)