none
Cargar una tabla de hechos con SSIS utilizando componente Lookup Transformation RRS feed

  • Pregunta

  • Hola, que tal amigos !

    Deseo realizar  carga de una tabla de hechos en su forma mas simple, partiendo de los valores que tengo de mi clave de negocio que traigo de consulta del  mi origen, para ubicar las claves surrogadas que corresponden a la dimensiòn y finalmente hacer el proceso  de inserciòn en la tabla de hechos previamente validando si la clave fue encontrada o no para colocarle el valor por defecto de la dimensiòn (Ejemplo: miembro desconocido).Para esto empecè utilizando el componente Loookup de Integration Services, pero he tenido algunas dudas con respecto a la lògica final luego de la salida de éste que me ha generado un encadenamiento de componentes que SSIS que temo este dando muchas vueltas para hacer la operacion final que es la inserciòn.

    Explico lo que tengo:

    1.- OLE DB Source con la consulta construida de mi origen donde me traigo las claves de negocios de las dimensiones y el hecho.

    2.- Multicast Component cuya salida va a un componente lookup por cada clave de negocio que traigo de mi origen

    3.- Lookup Component POR CADA clave de negocio donde indico la columna por la que voy a buscar en la dimensiòn (la clave de negocio de mi origen) y obtengo mi clave surrogada de la dimensiòn.

    4.- Un Derived Column Component que toma como origen los valores que NO hacen MATCH del lookup component y asigna un valor por defecto, por lo general, el primer miembro de la dimensiòn (No Aplica, Desconocido, Otros, etc). Tal como esta definido para cada lookup component, tengo su correspondiente Derived Column.

    5.- Un Union All Component que recoge el resultado del Derived Column del paso anterior  Y los valores que SI hacen MATCH del Lookup Component y asigna un nombre a la columna final de salida. esto me recoge los valores que si hicieron match con su clave surrogada correspondiente y los valores que no hicienron match asignando el valor por defecto.

    IMPORTANTE destacar que esto es para cada Lookup component de cada clave de negocio (Dimension)

    Tengo aproximado 16 Dimensiones y esta lògica por cada una de ellas me parece ya de por si complejo el paquete, con la impresion de que en algo redundo. Pero bien, no encuentro otra lògica y AUN me falta el paso definitivo:

    Deseo unir todas las salidas de cada clave de negocio, es decir, ya la obtenciòn de las claves surrogadas en una una sola fila y finalmente hacer la inserciòn, pero no hallo como hacer esto!!! Pues colocando al final de estos componentes un Union ALLv oy a tener repetido muchas veces  (o multiplicado por 16) el numero de filas que me estoy leyendo de mi origen para al final hacer la inserciòn.

    Por favor, alguno de ustedes me puede sugerir una forma optima de como hacer o finalizar esta logica para la carga de hechos (?) Que es lo correcto o lo ma ssano para estos casos.

    De antemano muchisimas gracias por la colaboracion ;)

    Mary.-

    Nota: si e sposible mantener la logica con el componente lookup.

    miércoles, 18 de enero de 2012 13:28

Respuestas

  • Hola, que tal!!

    Bueno, después de unos cuantos cabezazos y revisiones, di con algo bastante parecido a la solución y ya lo tengo hecho. Muchas gracias por la atención y por el deseo de ayudar.

    El planteamiento básico tal como lo tenìa para resolver la carga de la tabla de hechos no estaba mal:

    Obtienes la consulta del Origen con las claves de negocio y el hecho medible

    Te basas en un componente lookup  para buscar la clave surrogada de esas claves de negocio.

    Puedes usar un Derived Column para el tratamiento de los que no hagan match o no encuentre y  un Union All donde van los que si hacen match y los que finalmente salen del tratamiento de los que no hacen match.

    La diferencia en mi planteamiento  la tenía con respecto al uso de un componente Multicast luego de la consulta donde vienen los datos del origen usando un Ole DB source ya que con el Multicast paralelizas en muchos buffers las filas que vienen del origen para cada lookup (que en mi caso eran muchas y muchos) y luego al final de todo verte obligado a usar un Agregate Component para obtener la fila inicial ya con las claves surrogadas asignadas y poder insertar en la tabla de hechos.  Esto puede resultar muy penalizador para la memoria de la màquina por la cantidad de hilos que generas para cada lookup y luego el aggregate por cada columna. En este sentido, lo mas apropiado y para no castigar tanto es colocar todos los lookups que necesites en forma secuencial, uno tras otro hasta hacer la inserciòn final en la tabla de hechos , asi usas y reciclas siempre el mismo buffer por donde viajan los datos en cada componente. A nivel de rendimiento esto va mucho mejor y quizás lo único es organizar visualmente un poco el paquete, depende lo que tengas que hacer y la cantidad de búsquedas que tengas que hacer.

    Asi fue como lo resolví y me fue mejor.

    De nuevo, muchas gracias por todo!

    Mary.-

     

    viernes, 27 de enero de 2012 14:23

Todas las respuestas

  • Hola.

    Lo primero, por favor no publiques el mismo hilo en varios foros porque no es práctico, sólo generas trabajo de gestión a los moderadores. He dejado únicamente el hilo de este foro que es donde creo que debe estar.

    En cuanto a tu cuestión, creo que el error está en que no incluyes el valor por defecto en la consulta con la que obtienes cada clave subrogada. De esa manera, todos los registros harían match y no sería necesario el union all ni el derived column. Si nos pasas un ejemplo concreto de sentencia de lookup y lo que no haría matching, te damos la forma de construirlo.

     


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    miércoles, 18 de enero de 2012 14:32
    Moderador
  • Hola.

    ¿Resolviste el problema?


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    viernes, 27 de enero de 2012 11:24
    Moderador
  • Hola, que tal!!

    Bueno, después de unos cuantos cabezazos y revisiones, di con algo bastante parecido a la solución y ya lo tengo hecho. Muchas gracias por la atención y por el deseo de ayudar.

    El planteamiento básico tal como lo tenìa para resolver la carga de la tabla de hechos no estaba mal:

    Obtienes la consulta del Origen con las claves de negocio y el hecho medible

    Te basas en un componente lookup  para buscar la clave surrogada de esas claves de negocio.

    Puedes usar un Derived Column para el tratamiento de los que no hagan match o no encuentre y  un Union All donde van los que si hacen match y los que finalmente salen del tratamiento de los que no hacen match.

    La diferencia en mi planteamiento  la tenía con respecto al uso de un componente Multicast luego de la consulta donde vienen los datos del origen usando un Ole DB source ya que con el Multicast paralelizas en muchos buffers las filas que vienen del origen para cada lookup (que en mi caso eran muchas y muchos) y luego al final de todo verte obligado a usar un Agregate Component para obtener la fila inicial ya con las claves surrogadas asignadas y poder insertar en la tabla de hechos.  Esto puede resultar muy penalizador para la memoria de la màquina por la cantidad de hilos que generas para cada lookup y luego el aggregate por cada columna. En este sentido, lo mas apropiado y para no castigar tanto es colocar todos los lookups que necesites en forma secuencial, uno tras otro hasta hacer la inserciòn final en la tabla de hechos , asi usas y reciclas siempre el mismo buffer por donde viajan los datos en cada componente. A nivel de rendimiento esto va mucho mejor y quizás lo único es organizar visualmente un poco el paquete, depende lo que tengas que hacer y la cantidad de búsquedas que tengas que hacer.

    Asi fue como lo resolví y me fue mejor.

    De nuevo, muchas gracias por todo!

    Mary.-

     

    viernes, 27 de enero de 2012 14:23