All 7 Normalization questions
More in Normalization
What is the second normal form, and how does it build on the requirements of the first normal form? What is the third normal form, and what kind of dependency does it specifically eliminate? What practical problems, such as update anomalies, can occur in a poorly normalized database, and how does normalization address them? When would it make sense to intentionally denormalize a database design, and what specific tradeoffs come with that decision?
Advertisement
SQL Server › Normalization

How would you approach normalizing an existing, poorly designed legacy database without breaking the applications that currently depend on it?

Advanced

Answer

You would carefully analyze the current schema and its actual usage patterns, design the properly normalized target schema, migrate the data into the new structure, and often create views that mimic the old table structure temporarily, letting existing application code continue to function correctly while you gradually update it to work directly with the new, properly normalized tables.
-- A compatibility view can mimic the old denormalized structure
-- while the underlying tables have already been normalized
CREATE VIEW LegacyOrdersView AS
SELECT o.OrderId, c.Name AS CustomerName, o.Amount
FROM Orders o JOIN Customers c ON o.CustomerId = c.CustomerId;
Real-world example A company migrating a legacy application to a properly normalized database creates temporary compatibility views that mimic the old table structure, allowing the existing application to keep working correctly while the team gradually updates it to use the new schema directly.

Common follow-ups: What risks come with running a compatibility view long term instead of updating the application?;How do you thoroughly test that a normalization migration has not introduced any data integrity issues?

Views;Data Types & Schema Design
All 7 Normalization questions