1. ¿Que es Slowly Change Dimension?
Empecemos por definir que es un dimensión hablando de base de datos. Dimensión es un término en
administración de datos (data management) y en data warehouse que hacen referencia al agrupamiento
lógico de datos, tales como: localización geográfica, cliente, productos, etc. La información almacenada
en estas dimensiones puede cambiar con el tiempo y generalmente estos se hacen de mnera gradual, de
ahí el termino Dimensiones de Cambio Lento (Slowly change Dimension).
Por ejemplo, supongamos que tenemos una tabla (dimensión) que almacena el seguimiento a las ventas
hechas por los vendedores. La generación de reportes de seguimiento seria relativamente fácil, pero
¿Qué sucede cuando un vendedor cambia de oficina?, ¿Cómo se registraría este cambio dentro de la
dimensión?
Podríamos generar un reporte que me de la suma o el promedio de ventas por vendedor, pero nos
resultaría inservible para hacer una comparación de rendimiento entre vendedores por zona geográfica.
Si el vendedor antes trabajaba en un área con facilidad para ventas y después fue trasladado a un área
poco amigable o de apertura, la información seria engañosa ya que nos mostraría un declive en las
ventas, sin ser necesariamente una baja en el rendimiento del vendedor; o si comparo al vendedor con
las ventas dentro de la nueva oficina sin tomar en cuenta que viene de otra área geográfica, me
mostraría un total de ventas superior al de sus nuevos compañeros de la nueva región. Una solución
podría ser asignar a este vendedor una nueva clave como si fuera nuevo dentro de la empresa y
empezar de cero sus ventas en la nueva oficina, pero esto no seria practico ya que no nos mostraría la
información real de ventas.
Para poder solucionar problemas como el mencionado, se aplican técnicas de Slowly Change Dimension
(SCD), para poder manejar de forma correcta la información. Dentro de estas técnicas existen los tipos 0,
1, 2, 3 y 4 los cuales se describen a continuación.
Tipo 0
Este método de tipo 0 es pasivo. De hecho no es considerado un SCD. Los valores de la dimensión se
mantienen como fueron registrados la primera vez que se cargaron a la tabla. Este tipo generalmente no
es utilizado.

2. Tipo 1
Este método sobre-escribe el valor viejo u original, con el nuevo valor, perdiendo así el seguimiento a la
historia del registro, en otras palabras es básicamente una actualización al registro (update).
Generalmente es usado para la corrección de nombres o descripciones asumiendo que no se tiene la
necesidad de almacenar los cambios históricos.
Llave_proveedor Codigo_proveedor Nombre_proveedor Estado
35 XYZ Acme Mty
En este ejemplo, se tiene que el Codigo_proveedor es la llave natural y Llave_proveedor es la llave
sustituta (surrogate_key). Tecnicamente en este caso, la llave sustituta no es necesaria ya que la tabla
cuenta on una llave única que es el código del proveedor (primary key). Sin embargo para mejorar el
rendimiento en el caso de uniones(joins) con otras tablas para búsquedas, es mejor usar un valor
numérico (integer) que uno de carácter (char); adicional que la llave sustituta nos será de utilidad para el
manejo de versiones o del seguimiento a la historia en la tabla de la base de datos.
Supongamos que el proveedor cambia de residencia, la tabla actualizaría el campo de estado quedando
de la siguiente manera.
Llave_proveedor Codigo_proveedor Nombre_proveedor Estado
35 XYZ Acme Gdl
La desventaja de utilizar este método, es que no se guarda la historia en el almacén de datos (data ware
house). La principal ventaja de este método es que es fácil de mantener.
Tipo 2
Este método se da el seguimiento a los datos históricos mediante la creación de varios registros para
cada actualización del registro original, manteniendo su llave natural en las tablas de dimensiones por
medio de la creación de una nueva llave sustituta o número de versión.
Por ejemplo, si el proveedor se traslada a Guadalajara el número de versión se incrementa de forma
secuencial:

3. Llave_proveedor Codigo_proveedor Nombre_proveedor Estado Version
35 XYZ Acme Mty 0
36 XYZ Acme Gdl 1
Otro método es agregar una columna que indique el periodo de tiempo en el que el registro es válido
(fechas).
Llave_proveedor Codigo_proveedor Nombre_proveedor Estado Fecha_inicio Fecha_fin
35 XYZ Acme Mty 01-Ene-2010 15-Sep-2011
36 XYZ Acme Gdl 16-Sep-2011
En el caso de que la fecha fin aparezca en blanco (null), indica que ese es el registro actual o valido en
ese momento. Si se requiere normalizar la fecha, se pueden utilizar valores de fecha que difícilmente
sucederán, típicamente el valor aceptado es 31-dec-9999.
Con este método podemos tener la certeza de que mantendremos la historia del registro y el momento
en que fue valida, por ejemplo, sabremos que antes del 16 de Septiembre del 2011, el proveedor se
encontraba en Monterrey, ligando la llave sustituta (SK) a la tabla de hechos (fact) y cada vez que genere
un reporte, este me dará la información correcta en el periodo de tiempo indicado.
Tipo 3
Este método se da el seguimiento a los datos históricos mediante el uso de columnas separadas
preservando de manera “limitada” la historia del registro. El tipo 2 preserva la historia según el número
de campos designados al almacenamiento de datos históricos.
La estructura original de la tabla es la misma en el tipo 1 y 2, pero en el tipo tres se agregan columnas
adicionales. En el siguiente ejemplo se añadió una columna para almacenar el campo estado original del
proveedor almacenado solo el estatus original y actual de la historia, es decir, en caso de que el
proveedor cambie de residencia una vez más, no seria posible contar con la historia completa.
Si se agregara un campo cada vez que el proveedor cambiase de dirección, esto seria difícil de mantener
y romperíamos algunas reglas de bases de datos.
Llave_proveedor Codigo_proveedor Nombre_proveedor Estado_original Fecha_original Estado_actual
35 XYZ Acme Mty 01-Ene-2010 Gdl

4. Una variación que se podría manejar en este caso, es crear los campos estado_previo y estado_actual,
pero nos limitaría a tener solamente el cambio mas reciente.
Tipo 4
El método de tipo 4 se refiere generalmente como el uso de "tablas historicas", donde se mantiene una
tabla con los datos actuales, y una tabla adicional se utiliza para llevar un registro los cambios.
Siguiendo con el ejemplo anterior, podríamos tener una tabla llamada Proveedores y otra llamada
Historia_Proveedores.
Proveedores
Llave_proveedor Codigo_proveedor Nombre_proveedor Estado
35 XYZ Acme Gdl
Historia_Proveedores
Llave_proveedor Codigo_proveedor Nombre_proveedor Estado Fecha_creacion
35 XYZ Acme Mty 01-Ene-2010
Este método es muy similar a mantener tablas de auditorias en los sistemas.
Visita mi blog
http://sesa78.wordpress.com/