Dimensión de cambio lento

Un cliente cambia de ciudad. Un producto cambia de categoría. Un vendedor cambia de región.

La pregunta no es técnica, es de negocio: las ventas del año pasado, ¿a qué región pertenecen — a la de entonces o a la de ahora? Las dos respuestas son válidas y llevan a implementaciones distintas.

Tipo 1: sobrescribir

Actualizas el valor y la historia se pierde. Todos los reportes, viejos y nuevos, muestran el valor actual.

UPDATE dim_cliente SET ciudad = 'Monterrey' WHERE id_cliente = 42;

Sirve para corregir errores de captura: si el nombre estaba mal escrito, no quieres conservar la falta de ortografía como dato histórico.

Tipo 2: versionar

Cierras la fila vigente y abres una nueva. El cliente pasa a tener dos renglones, cada uno válido en un periodo. Es el que se usa cuando la historia importa.

-- 1) Se cierra la versión vigente.
UPDATE dim_cliente
SET valido_hasta = CURRENT_DATE - 1, es_vigente = FALSE
WHERE sk_cliente = 8801 AND es_vigente;

-- 2) Se abre una nueva con llave sustituta distinta.
INSERT INTO dim_cliente
  (sk_cliente, id_cliente, ciudad, valido_desde, valido_hasta, es_vigente)
VALUES
  (9427, 42, 'Monterrey', CURRENT_DATE, '9999-12-31', TRUE);

Aquí se ve para qué sirve de verdad la llave sustituta. La tabla de hechos guarda sk_cliente, no id_cliente. Las ventas viejas siguen apuntando a 8801 —con Guadalajara— y las nuevas apuntan a 9427 —con Monterrey—. La historia queda correcta sin tocar un solo renglón de hechos.

Tipo 3: guardar el anterior

Una columna extra con el valor previo. Sirve cuando solo necesitas comparar contra el valor inmediatamente anterior —una reorganización de territorios, por ejemplo— y no toda la historia.

Cuál elegir

Pregúntale al negocio, no al equipo técnico. La pregunta exacta es: "cuando esto cambie, ¿los reportes del año pasado deben cambiar también?". Si la respuesta es no, es tipo 2. Si es sí, tipo 1.