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.

 

DB2 v9.7 Tabla en estado pendiente


DB2 v9.7 Tabla en estado pendiente.
     Problema: 

  1.      Deseas realizar una consulta a una tabla y el error que te aparece es el siguiente:
    SQL0668N Operation not allowed for reason code "1" on 
    table "<table-name>". SQLSTATE=57016
  2.      Deseas correr un ETL  y no corre.

Por cualquiera de las  razones expuestas anteriormente, no bastará con bajar el servicio de base de datos, ni el servidor entero, hay que hacer un pequeño truquito para liberar la tabla.
Lo primero que se debe hacer es identificar la tabla, su esquema y usuario/contraseña de conexión.
Luego abrir la consola de administración de db2 vía MSDOS se debe seguir la siguiente Ruta:
  
Inicio>IBM DB2>ISWCOPY01(Valor por omisión)>Herramientas de línea de mandatos>Procesador de línea de mandatos como se visualiza en la Figura 1.



Figura 1 Ruta para el Procesador de línea de mandatos
Al hacer click sobre el procesador de línea de mandatos aparecerá la ventana de MSDOS  Figura 2.

Figura 2. Ventana de conexión de DB2
se ingresan los siguientes comandos:
db2 connect to schema user user_id using password
db2 set integrity for table_name immediate checked
Donde,
  • user_id   es el ID del usuario del usuario de la base de datos.
  •  password  es el password del usuario.
  • table_name  es la table que quedó en estado pendiente.
  • Schema es el esquema donde se encuentra la tabla que quedó en estado pendiente.
Correr el proceso ETL de nuevo, y todo funciona correctamente.