Subrrogates Keys

 Por Rut Almoguera Poggi

¿Te estás iniciando en el desarrollo de ETLs?

¿Quieres saber que es un Surrogate Key y cuáles son las ventajas de su uso?

Si contestaste que SI a estas  preguntas, este post es para ti.

Al inicio, cuando estamos aprendiendo a desarrollar un DataWarehouse, nos enfrentamos con algunos conceptos que nos resultan confusos.  Uno de los que generan más dificultad es el de “Surrogate Key”.

Un “Surrogate Key” o “Clave Surrogada” es una clave que sustituye a la original en las dimensiones de un DataWarehouse.  Es un identificador único que se asigna a cada registro de una tabla de dimensión, y que sería el nuevo “Primary Key” de la tabla de la dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio y son siempre de tipo numérico. Preferiblemente un entero auto incremental.

Veamos un ejemplo para ver claramente como sería un “Surrogate Key” en una dimensión.  Imaginemos que en nuestro sistema fuente tenemos una tabla PRODUCTO, cuyo “Primary Key” es el campo “Codigo_Producto” y con las siguientes filas:

 

Nuestra dimensión de Productos, DIM_PRODUCTO, además de los campos de la tabla PRODUCTO, tendría un campo llamado SK_PRODUCTO, el cual es la “Surrogate Key” y “Primary Key” de la dimensión, la cual quedaría de la siguiente manera:

  

El concepto es sencillo, sin embargo podrían surgir las siguientes preguntas:

 ¿Por qué hay que sustituir la clave original de las dimensiones? ¿Acaso la clave que tienen las dimensiones en los diferentes sistemas fuentes NO son suficientemente buenas? ¿Acaso no eran “Primary Keys” en las tablas de donde se están extrayendo y con eso sería suficiente para ser la clave de la dimensión?  La respuesta a estas preguntas es NO.

Algunas de las razones por las que es mejor sustituir la clave del negocio de una dimensión por una “Clave Surrogada” o “Surrogate Key” son las siguientes:

Fuentes heterogéneas: el DWH suele alimentarse de diferentes fuentes, cada una de ellas puede tener sus propias claves, con su propia semántica, inclusive pueden repetirse en diferentes orígenes una misma clave pero que tienen significados diferentes. 

Cambios en las aplicaciones origen: puede ocurrir que cambie la lógica operacional de alguna clave y que el formato ya no sea el mismo en el sistema origen.

Rendimiento: en la base de datos ocupa menos espacio un entero que una cadena. Identificar una ciudad con cinco bytes, o una persona con nueve bytes es un desperdicio considerable de espacio. Además, no solo debe preocuparnos el espacio que ocupa, sino también el tiempo que se invierte en leerlo. Recordemos que las claves subrogadas las llevaremos a las tablas Facts, por lo que cada código es susceptible de repetirse cientos de millones de veces. Por lo tanto, conviene optimizarlo al máximo. Lo mejor es crear entonces claves subrogadas para las dimensiones del Data Mart. 

También se usa para permitir la aplicación del concepto de Slowly Changing Dimension, el cual será explicado en la siguiente entrega.