Normalización vs Desnormalización

Dos filosofías de organización de datos

Normalizar un modelo de datos es como organizar tu armario en cajones 🗂️: cada tipo de ropa en su sitio, sin duplicados, todo ordenadito. Si cambias el nombre de una categoría, lo cambias en un solo lugar y el cambio se propaga a todas partes automáticamente.

Desnormalizar es como preparar una maleta para un viaje 🧳: juntas todo lo que necesitas para un propósito concreto, aunque repitas algún dato. Es menos "perfecto" en papel, pero más práctico para lo que necesitas hacer ahora mismo.

Ninguno de los dos enfoques es mejor en absoluto — depende del contexto de uso. La clave es saber cuál aplicar y cuándo.

La filosofía del dato único y consistente

La normalización busca que cada dato exista en un único lugar. Sus objetivos son:

• Eliminar redundancia (cada dato se guarda una sola vez)
• Garantizar integridad (una actualización se propaga correctamente)
• Reducir anomalías de inserción, modificación y borrado
• Optimizar el almacenamiento en bases de datos relacionales clásicas

¿Cuándo normalizar?

• Cuando diseñas el Data Warehouse o Data Lakehouse de origen (capa de almacenamiento)
• Cuando los datos se actualizan con frecuencia — sistemas OLTP o transaccionales
• Cuando el equipo de datos necesita mantener la consistencia a largo plazo
• Cuando el modelo tiene millones de filas con mucha repetición de texto largo
• En Microsoft Fabric Warehouse, SQL Server o PostgreSQL como capa de base de datos

Ejemplo — modelo normalizado (copo de nieve):

  'Familias'
  ┌──────────────────┐
  │ IDFamilia     PK │
  │ NomFamilia       │
  └──────────────────┘
           ▲ FK
  'Categorias'
  ┌──────────────────┐
  │ IDCategoria   PK │
  │ NomCategoria     │
  │ IDFamilia     FK │
  └──────────────────┘
           ▲ FK
  'SubCategorias'
  ┌──────────────────┐
  │ IDSubCat      PK │
  │ NomSubCat        │
  │ IDCategoria   FK │
  └──────────────────┘
           ▲ FK
  'Productos'
  ┌──────────────────┐
  │ IDProducto    PK │
  │ NomProducto      │
  │ IDSubCat      FK │
  └──────────────────┘
           │ 1:N
           ▼
  'Ventas'
  ┌──────────────────┐
  │ IDProducto    FK │
  │ Importe          │
  └──────────────────┘

  ✦ Sin duplicados · 4 tablas de dimensión · 4 relaciones

La filosofía del modelo rápido y simple

La desnormalización acepta cierta redundancia de datos a cambio de:

• Reducir el número de relaciones y JOINs necesarios en el modelo
• Acelerar las consultas analíticas (OLAP) al evitar cruces costosos
• Simplificar el modelo para que sea más intuitivo para el negocio
• Aprovechar la compresión de VertiPaq, que gestiona muy bien los datos repetidos

¿Cuándo desnormalizar?

• Cuando diseñas el modelo semántico de Power BI / Fabric Semantic Model
• Cuando los datos son de solo lectura y se refrescan en bloque (no fila a fila)
• Cuando la prioridad es el rendimiento de las queries analíticas
• Cuando quieres simplificar el modelo para que el equipo de negocio lo use con autonomía
• En Power BI Desktop, Azure Analysis Services o Fabric Semantic Model

Ejemplo — modelo desnormalizado (estrella):

  'DimProductos'
  ┌──────────────────────────────┐
  │ IDProducto        PK         │
  │ NomProducto                  │
  │ NomSubCategoria              │  ← antes en SubCategorias
  │ NomCategoria                 │  ← antes en Categorias
  │ NomFamilia                   │  ← antes en Familias
  └──────────────────────────────┘
           │ 1:N
           ▼
  'Ventas'
  ┌──────────────────────────────┐
  │ IDProducto        FK         │
  │ Importe                      │
  └──────────────────────────────┘

  ✦ 1 sola tabla de dimensión · 1 relación · queries más rápidas

Comparativa honesta entre los dos enfoques

Aquí no hay respuestas universalmente correctas — solo contextos. Esta tabla resume los trade-offs reales para ayudarte a decidir:

Sin jerga académica innecesaria

Las formas normales son reglas que, si sigues, garantizan que tu modelo no tiene redundancias problemáticas. Aquí van las tres más relevantes para el trabajo con Power BI.

Cuatro preguntas para tomar la decisión correcta

La regla de oro para Power BI:

• Tablas de hechos (Ventas, Pedidos, Transacciones): muy normalizadas — solo FKs y métricas, sin atributos descriptivos
• Tablas de dimensiones (Productos, Clientes, Calendario): desnormalizadas — todos los atributos directamente en la tabla, sin sub-tablas

Ejemplo 1 — Jerarquía de productos con familia, categoría y subcategoría

Enfoque normalizado (DWH en SQL Server):

  Familias      (IDFamilia, NomFamilia)
  Categorias    (IDCategoria, NomCategoria, IDFamilia FK)
  SubCategorias (IDSubCat, NomSubCat, IDCategoria FK)
  Productos     (IDProducto, NomProducto, Precio, IDSubCat FK)

  Query SQL para obtener el nombre completo de la jerarquía:
  SELECT p.NomProducto, sc.NomSubCat, c.NomCategoria, f.NomFamilia
  FROM   Productos p
  JOIN   SubCategorias sc ON p.IDSubCat     = sc.IDSubCat
  JOIN   Categorias    c  ON sc.IDCategoria = c.IDCategoria
  JOIN   Familias      f  ON c.IDFamilia    = f.IDFamilia
  → 3 JOINs necesarios para cada consulta

Enfoque desnormalizado (DimProductos en Power BI):

  DimProductos  (IDProducto, NomProducto, Precio,
                  NomSubCat, NomCategoria, NomFamilia)
  → 0 JOINs necesarios · 3 relaciones menos en el modelo semántico ✅

Código Power Query (M) para aplanar la jerarquía en una sola tabla:

let
    Productos     = ...,  // tabla de origen
    SubCategorias = ...,
    Categorias    = ...,
    Familias      = ...,

    // Paso 1: unir Productos con SubCategorias
    Join1   = Table.NestedJoin(Productos, "IDSubCat",
                SubCategorias, "IDSubCat", "SubCat", JoinKind.Left),
    Expand1 = Table.ExpandTableColumn(Join1, "SubCat",
                {"NomSubCat", "IDCategoria"}),

    // Paso 2: unir con Categorias
    Join2   = Table.NestedJoin(Expand1, "IDCategoria",
                Categorias, "IDCategoria", "Cat", JoinKind.Left),
    Expand2 = Table.ExpandTableColumn(Join2, "Cat",
                {"NomCategoria", "IDFamilia"}),

    // Paso 3: unir con Familias
    Join3   = Table.NestedJoin(Expand2, "IDFamilia",
                Familias, "IDFamilia", "Fam", JoinKind.Left),
    Expand3 = Table.ExpandTableColumn(Join3, "Fam", {"NomFamilia"}),

    // Limpiar: quitar FKs intermedias que ya no son necesarias
    QuitarFKs = Table.RemoveColumns(Expand3,
                  {"IDSubCat", "IDCategoria", "IDFamilia"})
in
    QuitarFKs

Ejemplo 2 — Gestión de clientes con dirección

¿Vale la pena desnormalizar aquí?

• Si un cliente tiene una sola dirección: desnormaliza — es una relación 1:1, no hay ganancia en separarla
• Si un cliente puede tener múltiples direcciones: NO desnormalices — necesitas una tabla puente o una dimensión de dirección separada

Los 5 puntos que debes llevarte