Lesson 6	Limitations of First Normal Form (1NF)
Objective	Describe the limitations of first normal form and explain why databases in 1NF alone are still prone to redundancy and anomalies.

Limitations of First Normal Form (1NF)

First Normal Form (1NF) is the foundational level of database normalization. It ensures that:

Every column contains only atomic (indivisible) values,
There are no repeating groups or arrays within a single row (no Phone1, Phone2, no comma-separated lists, no multi-valued attributes).

While these rules eliminate the most obvious structural problems, 1NF says nothing about redundancy, functional dependencies, or data anomalies. A table can be perfectly compliant with 1NF yet still suffer from severe maintenance issues.

Example: An Order Table That Satisfies 1NF but Is Problematic

Consider a typical “flat” order table that many beginners (and legacy systems) use:

Order (
    CustID, CustName, CustAddress, CustPhone,
    OrderNo, OrderDate,
    ItemNo, ItemTitle, ItemPrice, Qty, LineTotal, ShippedVia, ShippedDate
)

This schema has no repeating groups and every cell holds a single value → it is in 1NF. Yet it exhibits all classic normalization problems:

Problem	Description	Consequence
Insertion Anomaly	Cannot add a new customer without placing an order. Cannot add a new inventory item until someone orders it.	Limits legitimate data entry.
Update Anomaly	Changing a customer’s phone number requires updating every row for that customer.	Risk of inconsistent data if some rows are missed.
Deletion Anomaly	Cancelling an order deletes the only record of the customer (if it was their only order) and of the item details.	Accidental loss of important master data.
Redundancy	Customer and item information is duplicated across hundreds or thousands of rows.	Wasted storage and slower queries.

Partial Dependencies and Composite Keys

In practice, the primary key for order-line data is usually composite: (OrderNo, ItemNo). Examine the functional dependencies:

OrderNo → OrderDate, CustID, CustName, CustAddress (depends only on the order part)
ItemNo → ItemTitle, ItemPrice (depends only on the item part)
CustID → CustName, CustAddress, CustPhone (transitive dependency)

These are called partial dependencies (a non-prime attribute depends on part of a composite key) and transitive dependencies (a non-prime attribute depends on another non-prime attribute). 1NF does nothing to eliminate them—they are resolved in 2NF and 3NF respectively.

How Higher Normal Forms Fix These Issues

Decomposing the table into separate entities eliminates the problems:

Customer (CustID PK, CustName, CustAddress, CustPhone)

Item (ItemNo PK, Title, CurrentPrice, ...)

Order (OrderNo PK, OrderDate, CustID FK → Customer)

OrderLine (
    OrderNo FK → Order,
    ItemNo  FK → Item,
    Qty,
    PriceAtSale,      -- preserves historical price
    ShippedVia,
    ShippedDate,
    PRIMARY KEY (OrderNo, ItemNo)
)

Benefits of this 3NF-compliant design:

Customer data stored once → update in one place.
Item master data stored once → consistent pricing info.
Historical prices preserved via PriceAtSale.
Can insert customers and items independently.
No risk of losing master data when orders are deleted.
Full support for referential integrity constraints.

When Is 1NF Alone Acceptable?

In very rare cases—such as simple logging tables, data warehouse fact tables with no updates, or temporary staging tables—staying in 1NF may be justified for performance reasons. In virtually all transactional OLTP systems, stopping at 1NF is considered poor design.

Quick Diagnostic Checklist

✓ No repeating groups or multi-valued attributes → 1NF achieved
✗ Data about multiple real-world entities mixed in one table → needs decomposition
✗ Composite primary key with columns that depend on only part of it → needs 2NF
✗ Non-key column determining another non-key column → needs 3NF
✗ Frequent update/delete operations cause many rows to change or risk data loss → definitely normalize further

Conclusion

First Normal Form is an essential starting point, but it is only the first step. It guarantees atomicity and removes repeating groups, yet it leaves the door wide open to redundancy, anomalies, and maintenance headaches. Moving to 2NF (eliminating partial dependencies) and 3NF (eliminating transitive dependencies) is almost always necessary for robust, maintainable relational databases.

The next lesson formally defines Second Normal Form and shows exactly how to eliminate partial dependencies.