Transformaciones PowerCenter, Pasivas

BI Geek / Business Intelligence  / Transformaciones PowerCenter, Pasivas
imagen_blog

Transformaciones PowerCenter, Pasivas

Completamos con esta entrada la clasificación y descripción de las transformaciones PowerCenter iniciada en el capítulo introductorio y profundizada posteriormente con el análisis de las activas.

En esta ocasión se describe el funcionamiento de las principales transformaciones pasivas, algunos de sus casos de uso más frecuentes así como algunos consejos útiles a la hora de enfrentarnos al desarrollo de una ETL usando esta herramienta.

De igual manera a como ocurre con las activas, las transformaciones pasivas ocupan un lugar muy importante en cualquier ETL desarrollada con PowerCenter. Entre las más importantes se encuentran:

  •  Expression

Es quizá la transformación más usada. Es necesaria siempre que se requiere hacer cualquier operación o cálculo a nivel de registro. Esto es, operaciones matemáticas, asignación de valores o parámetros, creación de variables o indicadores de filtrado o estrategia, adecuación de campos, validaciones, etc.

En ella pueden crearse tantos campos y tan complejos como se desee, pero el flujo siempre permanece constante. No importa si creamos cien nuevas columnas con valores fijos, calculados, fechas o indicadores, puesto que el número de filas a la salida será el mismo de la entrada.

Pese a esto, su versatilidad no tiene límites, ya que permite la creación de variables internas, las cuales permiten generar contadores, comparar registros entre sí o mejorar el rendimiento separando los cálculos más complejos en pasos intermedios.

  • Lookup

Se utiliza para realizar consultas sobre ficheros o tablas y recuperar el valor de uno o varios campos a través de la coincidencia de una o varias columnas.

La principal característica, según los intereses de este artículo, es que en ningún caso la volumetría se ve afectada. Independientemente de si se trata de una lookup conectada o desconectada, de si se recupera uno o varios campos o de si se implementa una query o filtro previo sobre los datos de consulta,  los registros en la salida son los mismos que en la entrada.

En el caso de no encontrar una coincidencia en los datos de consulta, los campos recuperados aparecerán vacíos. Si por el contrario un registro obtiene múltiples coincidencias, los campos informarán los valores de alguna de ellas. Esto puede configurarse en Properties -> Lookup policy on multiple match, eligiendo así coger los valores de la primera ocurrencia (Use First Value), de la última (Use Last Value) o de cualquiera (Use Any Value), si no existe diferencia entre ellas o no es relevante para el propósito.  

Podemos encontrar toda la información necesaria para la configuración de las lookups en la entrada correspondiente

  • Sequence Generator

Esta transformación permite únicamente numerar cada registro de entrada añadiendo un contador incremental a cada uno de ellos. Lo que si podemos es determinar el valor de comienzo para esta secuencia (generalmente 1), el valor final y el incremento entre una fila y otra (generalmente 1 también).

En términos de volumetría, entra el mismo flujo que sale, aunque añadiendo una columna numérica con la posición de la fila dentro de la secuencia generada.

Puede ser de utilidad cuando necesitamos generar un id único para cada registro, cuando queremos mostrar una ordenación en un fichero de salida o cuando necesitamos separar parte del flujo y queremos recuperarlo después mediante un cruce. En cualquier caso, su necesidad dependerá siempre del diseño elegido para lograr el resultado deseado. 

  • Sorter

Aunque se incluyó esta transformación como excepción en el bloque de activas, resulta imprescindible mencionarla ahora por su comportamiento natural como elemento pasivo del desarrollo.

Recalcar una vez más que cuando se utiliza con la finalidad de ordenar un flujo, ya sea por necesidad o rendimiento, su procesado no varía la volumetría procesada. La acción que realiza sobre el flujo de entrada se limita a su ordenación en función del criterio seleccionado, ascendente o descendente, de una o más variables.

Suele usarse como elemento previo a joiners y aggregators para mejorar el rendimiento de éstos últimos, ahorrando caché y facilitando el procesamiento de sus operaciones. 

  • Union

Esta transformación es la opuesta al router, recibe diferentes flujos de entrada (todos ellos con los mismos campos) y los unifica en un mismo flujo de salida. La diferencia en términos de volumetría es que el router puede descartar o incrementar los registros, mientras que en la unión todo lo que entra forma parte de la salida.

Se utilización es sencilla puesto que lo único que hay que configurar es el número de grupos en la entrada y los campos, todos iguales, que tendrá cada uno de ellos.

La unión tiene sentido cuando, o bien se quieren juntar para un mismo tratamiento flujos con distinto origen, o bien cuando queremos volver a unir datos que fueron separados previamente,  generalmente mediante un router.

Es posible encontrarla también al final de un proceso, juntando todas las trazas y estadísticas de errores que se van obteniendo en diferentes puntos para el monitoreo del mismo.

  • Update Strategy

Esta transformación se utiliza siempre previamente a un target conectado a una tabla de una base de datos para determinar la operación a realizar con cada registro, inserción, actualización, borrado o rechazo. Por tanto, no tiene aplicación alguna cuando trabajamos con targets a ficheros de texto. Es necesario mencionar que no es siempre necesaria. Por ejemplo, cuando realizamos una carga total en una tabla se realiza un volcado directo, es innecesario contemplar las actualizaciones o borrados.

Mediante la opción Properties -> Update Strategy Expression establecemos la estrategia deseada, la cual puede incluir condiciones de tantas variables como se desee, siendo recomendable, como ya os podéis imaginar, el cálculo previo en una expression para favorecer la asignación de la operación durante la ejecución. Las cláusulas DD_INSERT, DD_UPDATE, DD_DELETE y DD_REJECT determinarán la acción a realizar con cada registro en la base de datos.

Se trata de una transformación pasiva que asigna la estrategia de carga a cada fila sin variar la volumetría de entrada. Si bien es cierto, que el uso de la operación DD_REJECT causará el rechazo posterior del registro en la carga de la tabla correspondiente.


Aquí termina la descripción y clasificación de las transformaciones pasivas de PowerCenter desde el punto de vista de variación en la volumetría. Como resumen, podemos interpretar siempre de manera generalizada, que las transformaciones pasivas realizan operaciones a nivel de registro.

Podemos volver desde aquí a los artículos previos que conforman este hilo:

Introducción

Transformaciones activas