# Third Normal Form (3NF)

## Purpose
Third Normal Form is a relational data modeling methodology used for enterprise data
warehouses (Inmon-style). Apply this skill when a normalized integration layer (Silver
equivalent) is required instead of Data Vault or Lean Data Vault.

## Normalization Rules

### 1NF — First Normal Form
- Each column contains only atomic (indivisible) values.
- No repeating groups, arrays, or multi-valued attributes.

### 2NF — Second Normal Form
- Satisfies 1NF.
- Every non-key attribute is fully functionally dependent on the entire primary key.
- Eliminates partial dependencies (relevant only for composite primary keys).

### 3NF — Third Normal Form
- Satisfies 2NF.
- Every non-key attribute depends only on the primary key — not on other non-key attributes.
- Eliminates transitive dependencies.

## Design Approach for Integration Layers

In a 3NF integration layer:
- Entities become normalized tables with surrogate primary keys.
- Relationships are modeled as foreign key constraints.
- History is tracked via effective dating (`ValidFrom` / `ValidTo`) or separate history tables.
- The schema may closely mirror the normalized structure of the source systems.

## When to Use 3NF

- When source systems are highly normalized and the integration layer should reflect that structure.
- When complex transactional queries are required at the integration layer.
- When the team has strong relational modeling expertise and DV overhead is not justified.
- When regulatory requirements demand a well-documented, provable data lineage in relational form.

## 3NF vs. Star Schema

3NF is used in the **integration layer (Silver)**. Star Schema is used in the **consumption layer (Gold)**.
Never use 3NF in the Gold layer — it requires too many joins for BI tools and degrades query performance.

## 3NF vs. Data Vault / Lean Data Vault

| Aspect | 3NF | LDV / Data Vault |
|---|---|---|
| Structure | Mirrors business entities | Separates identity from attributes |
| History | Effective dating per table | Insert-only Hist tables |
| Multi-source | Requires careful merge design | Native multi-source support |
| Best for | Single-source, structured domains | Multi-source, auditable enterprise data |

## Anti-Patterns
- **Using 3NF in the Gold/consumption layer**: Causes poor BI performance; use Star Schema there.
- **Over-normalization (4NF, 5NF)**: Adds complexity without meaningful benefit for data warehousing.
- **Business keys as primary keys**: Breaks when business keys change; always use surrogate keys.
- **No effective dating**: Without `ValidFrom`/`ValidTo`, historical changes are lost.
