Patrones de Modelado de Datos Temporales e Históricos

La gran mayoría de las bases de datos empresariales reales no solo necesitan almacenar la «foto del presente», sino registrar cómo evolucionaron los datos en el pasado y qué vigencia tendrán en el futuro. Diseñar la dimensión temporal desde la fase conceptual evita graves pérdidas de información contable, legal y operativa.

1. El error común: La «Trampa del Presente» #

Cuando un diseñador novato modela una entidad PRODUCTO con el atributo precio: 10 € y una entidad PEDIDO:

• Si el cliente compró el producto en enero por 10 €, y en marzo el producto sube a 15 € en el catálogo:
• Si la relación solo conecta Pedido con Producto, cualquier consulta de facturación histórica leerá el precio actual (15 €), falseando la contabilidad del año anterior.

Para resolver este y otros problemas de negocio, se utilizan patrones de diseño temporal.

2. Patrón 1: Snapshot o Valor Congelado en la Relación #

Se aplica cuando el valor de un atributo descriptivo de una entidad debe quedar inmutable y fijado en el instante exacto en que se formaliza una transacción o relación.

1┌───────────────┐                             ┌───────────────┐
2│   PRODUCTO    │                             │    PEDIDO     │
3├───────────────┤                             ├───────────────┤
4│ PK id_prod    │─────────( LÍNEA_PEDIDO )────│ PK id_pedido  │
5│    nombre     │           - cantidad        │    fecha      │
6│    precio_cat │           - precio_cobrado  │    cliente    │
7└───────────────┘             (Snapshot)      └───────────────┘

• precio_cat en Producto: Refleja el precio actual de catálogo para nuevas compras.
• precio_cobrado en Línea_Pedido: Atributo propio de la relación que congela el importe exacto pagado en ese pedido concreto.

3. Patrón 2: Relaciones con Intervalo de Vigencia (fecha_inicio, fecha_fin) #

Se utiliza cuando una entidad puede vincularse a diferentes entidades a lo largo del tiempo, pero solo a una (o a un conjunto limitado) en un momento dado, necesitando recordar todo el histórico.

Ejemplo: Asignación de Empleados a Departamentos #

Un empleado trabaja en el departamento de Ventas desde 2021 hasta 2023, y en 2024 pasa a Marketing:

1┌─────────────────┐                               ┌──────────────────┐
2│    EMPLEADO     │                               │   DEPARTAMENTO   │
3├─────────────────┤                               ├──────────────────┤
4│ PK id_empleado  │─────( HISTORIAL_PUESTO )──────│ PK id_depto      │
5│    nombre       │        - fecha_inicio (PK)    │    nombre_depto  │
6│    dni          │        - fecha_fin (NULL=hoy) └──────────────────┘
7└─────────────────┘        - salario_periodo

• Clave de la relación temporal: (id_empleado, id_depto, fecha_inicio) para permitir que el mismo empleado vuelva al mismo departamento en periodos distintos.
• Convenio de vigencia activa: La fila donde fecha_fin IS NULL (o fecha límite $9999\text{-}12\text{-}31$) representa la asignación actualmente vigente.

4. Patrón 3: Histórico de Estados y Auditoría #

En lugar de tener un único campo estado = 'Enviado' que sobreescribe el estado anterior, se modela una entidad dependiente que registra cada transición del ciclo de vida.

Ejemplo: Seguimiento de Envíos de Paquetería #

1┌──────────────┐ 1                            0..* ┌──────────────────────────┐
2│   PAQUETE    │───────────────────────────────────│     HISTORIAL_ESTADO     │
3├──────────────┤              registra             ├──────────────────────────┤
4│ PK id_envio  │                                   │ PK id_historial          │
5│    destinat. │                                   │ FK id_envio              │
6│    peso      │                                   │    estado (Creado/Env/..)│
7└──────────────┘                                   │    fecha_hora_cambio     │
8                                                   │    responsable            │
9                                                   │    ubicacion_actual       │
10                                                   └──────────────────────────┘

• Permite calcular KPIs de negocio (ej: tiempo medio transcurrido entre Empaquetado y Entregado).
• Proporciona trazabilidad completa para auditoría y reclamaciones de clientes.

5. Patrón 4: Entidades Versionadas (Dimensiones de Cambio Lento) #

Cuando los propios datos maestros de una entidad cambian (por ejemplo, la razón social, dirección fiscal o tarifa de un proveedor):

• Se añade un número de versión (id_entidad, num_version, fecha_desde, fecha_hasta).
• Los contratos o documentos emitidos en el pasado permanecen vinculados a la versión histórica correspondiente.