A relational database organizes data into one or more tables of columns and rows. It's called "relational" because it establishes specific, predefined relationships between these tables. The core idea is to break complex information into smaller, manageable pieces, avoiding the need to store the same information multiple times.

Imagine a simple database for an online store. You'd have a table for Customers (name, address, phone) and another for Orders (date, total). When a customer places an order, you don't have to copy their entire address into the Orders table; you just use their unique Customer ID to connect the order back to the customer's full details.

If the customer moves and changes their address, you only have to update it in one place: the Customers table. If you copied it to 100 order records, you'd have to update all 100, which would likely lead to messy, inconsistent data. This problem of needing to update information in many places is called a data anomaly.

However, you do want to copy the price of a product into the order record at the time of purchase. Why? Because the price of the product might change in the future in your main Products table, but the order record needs to reflect the price the customer actually paid on the date of the transaction. In this case, copying and freezing the data (or creating a snapshot) is the correct design choice.

Normalization is the systematic process of designing your relational tables and the relationships between them to eliminate these inconsistencies and save storage space. The "normal forms" (1NF, 2NF, 3NF, etc.) are a series of prescriptive rules. They are a solution to data redundancy and the data anomalies it creates, providing a clear path to organizing data efficiently and reliably based on your application needs.

Denormalization is the intentional addition of redundant data to a database, often to improve query performance for reporting or analysis. It's a trade-off: you sacrifice some integrity and increase storage space for faster data retrieval. However, in scenarios like a legal contract, you may want this intentional redundancy to create a snapshot of the data that's independent of future changes. This ensures that the terms, names, and prices recorded at the time of the contract signing remain permanently fixed and available, even if the primary customer or product data is later updated.