Mes: octubre 2006

El salto cualitativo que ha dado Analysis Services es tal, que cuando uno trata de elegir su característica favorita lo puede tener francamente complicado. Hay nuevos algoritmos de minería de datos, tiene la posibilidad de tener cubos con varias tablas de hechos, las "linked measures", los ETL con flujos de datos y flujos de control separados… sin embargo, si me preguntasen cual es para mi la mejor característica de SSAS 2005 no dudaría ni un segundo en responder que en el "UDM".

El UDM, o Unified Dimensional Model, es una capa intermedia que permite a SSAS abstraerse de la fuente de datos en la que se almacenan los hechos y dimensiones de un cubo. De esta forma, ya no necesitamos disponer físicamente de una base de datos con un modelo relacional en estrella, sino que podemos partir de cualquier modelo relacional y construir una "estrella virtual" sobre el UDM. Esta estrella virtual es algo parecido a si organizásemos una estrella en base a vistas sobre una base de datos relacional, pero tiene la ventaja de que puede tomar datos desde distintos orígenes.

 

Parece sencillo, ¿verdad? ¿y por qué es a mi entender, la mejor característica de SSAS2005? Puede que no parezca una característica revolucionaria, pero el UDM nos abre las puertas de la "minería de datos operacional".

Tradicionalmente, las aplicaciones basadas en tecnología OLAP se han utilizado para el análisis de datos históricos: existía un entorno OLTP, un Data Warehouse y un proceso batch, llamado ETL, que transladaba datos de uno a otro. Los cubos OLAP se montaban sobre los datos del Data Warehouse, y por lo tanto estaban disponibles para su análisis únicamente tras la ejecución del ETL (y en el caso de los cubos MOLAP, tras el procesado de los cubos, en los que se cargan los distintos niveles de dimensiones y se construye la base de datos de agregados).

Con UDM, podemos prescindir del Data Warehouse y tomar los hechos directamente del almacén OLTP (de ahí el nombre de "minería de datos operacional"). Incluso podemos tomar datos de varios almacenes OLTP, de una combinación de almacenes OLTP y DataMarts, o por qué no, de datos obtenidos en tiempo real que pudiesen representarse en forma de tabla (cualquier origen OLEDB o ADO.NET puede aportar tablas a nuestro modelo UDM).

 

Una vez configurados todos los orígenes de datos (DataSources) podremos unificarlos y darles el aspecto que queramos utilizando un DataSourceView, en el que podremos:

• Relacionar tablas
• Establecer vistas
• Establecer campos calculados

¿Qué ventaja obtenemos con esto? Sencillo… el UDM nos permite romper con la barrera del tiempo y realizar análisis sobre los datos según se producen. Por supuesto, esto tiene sus implicaciones de rendimiento y su ciencia particular: tendremos que usar ROLAP o HOLAP (configurando adecuadamente la Proactive Cache) para prescindir del procesado de cubos en batch al que nos obliga MOLAP. ¡Uau! ¡Cubos OLAP sin procesos batch! En resumen UDM es una verdadera "revolución silenciosa" que abre las puertas del OLAP en tiempo real.

El otro día, mientras probaba unos cubos OLAP en la oficina, alguien se me acercó y curioseó a mi espalda. Increíble… estaba cruzando dimensiones y generando informes que hasta ahora las aplicaciones corporativas no podían obtener. Por arte de magia, estaba cruzando averías surgidas en un conjunto de máquinas con los operarios que las manejaban en ese momento. Por supuesto se trataba de datos falsos y para mi sólo era una prueba explorando las capacidades de los nuevos cubos… pero quien estaba tras de mí no pudo dejar de recordarme que yo era poco menos que el demonio.

Desde entonces he pensado mucho en el tema. Curiosamente, los grandes volúmenes de información que se tiene de nosotros, garantizan en cierta forma nuestro anonimato. Esta es una afirmación un tanto chocante y que a más de uno le puede hacer chirriar las tuercas, pero no deja de ser por eso menos verdadera. Todos los días generamos cientos de "pedacitos" de información que van quedando en uno y otro lugar, entremezclados con los pedacitos de información que han dejado otros. El volumen de datos es tal, que es imposible obtener información de ellos, sencillamente porque el bosque es tan inmenso y cerrado, que nos es imposible encontrar un árbol concreto. Pero vaya… las tecnologías de Business Intelligence nos facilitan  acceder al árbol que buscamos… ¡y a todos sus parientes genéticos! ¡y con un par de clicks de ratón!

Mi primer pensamiento fue…

Bien, con mi sistema, se puede se puede poner nombre y apellidos a información que de otra forma serían puras estadísticas anónimas. Así que podemos saber que Serapio es más hábil manejando una fresadora que Fulgencio, y que a Fulgencio se le estropea cada dos por tres. ¿Perjudica esta información a Serapio y Fulgencio? Evidentemente, perjudica a Fulgencio y Beneficia a Serapio. ¿Pero es esto malo? ¿Soy el demonio?

Mmm… el sistema beneficia a quien lo hace bien, y perjudica a quien lo hace mal. Además lo hace basándose en una enorme cantidad de variables, y de forma totalmente imparcial. A mi me parece bastante justo, ¿no? Ese día pude dormir tranquilamente, a sabiendas de que mi sistema, en buenas manos, sería una herramienta que permitiría impartir justicia.

Pero esa noche tuve una pesadilla… ¿En buenas manos?

Al día siguiente, al llenar el depósito de mi coche, pasé la "Travel" en mi gasolinera habitual… y pensé, ¡allá va mi pedacito de información!. Pero me quedé inquieto. ¿Irá ese pedazo de información a buenas manos? ¿Qué se podría hacer con esa información? Amigos míos… ¿imagináis qué se puede hacer con las tecnologías actuales de business intelligence sobre la base de datos de "Travel Club"? Y por supuesto, no es sólo la Travel… son mis "tracking cookies" cuando navego por Internet, mi "historial" en los distintos sitios web en los que me autentico con un Microsoft Passport (o Windows Live Id) y un montón de actividades que realizo a diario. Muchos, muchos, muchos pedacitos de información.

No me considero el demonio… ¡pero estoy seguro de que la misma tecnología sobre la que escribo en este blog, es un arma de destrucción masiva en manos del Demonio! De hecho, me pregunto qué sería de las empresas que desarrollan spyware sin la ayuda del "business intelligence".

Y llegamos al punto que quería atacar… ¿quién, y sobre todo cómo, me protege de los abusos? Más de uno dirá, ¡para eso está la legislación, amigo! Entonces comparo mi trabajo con el de quien explota información obtenida del spyware, y… ¡vaya! Realmente en algunos casos los hechos pueden ser tremendamente similares, y las tecnologías que empleamos muy parecidas. Realmente nos diferencian las intenciones… ¡pero es que se juzgan los hechos, y no las intenciones!

Bueno, todo esto me ha hecho empatizar con los legisladores… uff, ¡qué difícil tiene que ser legislar contra el spyware! Y me surge otra pregunta… ¿y si alguien utiliza un sistema creado con buena fe, para obtener información que se podría emplear con mala fe… el desarrollador del sistema es responsable en parte?

No me ha quitado demasiado el sueño, porque sigo pensando que la tecnología es éticamente neutra, y que lo moral o inmoral es el uso que se hace de ella. Seguro que los metereólogos podrían sacar chispas al "business intelligence". Mi conciencia está tranquila. Pero los años me recuerdan que habitualmente, las leyes van tres pasos por detrás de la moral.

Uno de los aspectos más molestos de SSIS, es el hecho de que no permita utilizar rutas relativas en las cadenas de conexión a archivos. Esto es un problema si queremos realizar un ETL que se vaya a desplegar en una ruta distinta a la utilizada en tiempo de diseño… pero por fortuna, aunque un poco rebuscado, hay un truco que permite utilizar paths relativos.

Atended pues, a esta receta con la que podréis desarrollar un ETL rico, rico, rico… que os permita:

• Utilizar archivos como orígenes de datos sin tener que colocarlos en rutas fijas
• Lanzar archivos "dtsx" que se almacenen en el directorio en el que se está ejecutando el ETL
• … etc, etc, etc…

Vamos pues, paso a paso con el truquillo:

1. Lo primero que hay que hacer es definir una variable con el path en el que se desplegará el ETL. Definidla de forma que sea global al archivo "dtsx" principal en el que se haya implementado el ETL. Ya sabéis, se va a la pestañita de "Control Flow" y se define la varible desde allí.
2. Cuando creamos una conexión a un archivo, Integration Services nos obliga a establecer como cadena de conexión, la ruta absoluta a un archivo existente. Pues bien, satisfaremos los deseos de SSIS haciendo que la conexión apunte a un archivo existente.
3. Seleccionamos “Propiedades” de la conexión sobre la que queremos establecer la ruta relativa.
4. Seleccionar “Expresiones” (pinchamos en los tres puntitos al lado de "expressions" en la ventana de propiedades).

   

5. Seleccionar “ConnectionString”

   

6. Establecer una expresión que construya un path absoluto en función de la variable con el path de despliegue: en mi ejemplo, @[User::DeploymentPath] + "\Data\DayOfWeekNameValues.txt". Esta expresión, se resolverá en tiempo de ejecución y sobreescribirá el valor de la propiedad que hubiésemos establecido en tiempo de diseño.

   

7. Por último, deberemos propagar el valor de la variable a paquetes hijos, por medio de la opción "SSIS-> Package Configurations". De todas la opciones disponibles, seleccionaremos la opción de tomar una configuración de una variable desde el paquete padre.

   

   

8. La variable que marca la ruta al paquete, también puede configurarse desde "SSIS-> Package Configurations". La opción más adecuada en este caso, es tomar su valor de una entrada de registro, o de una variable de entorno (consultad los libros en pantalla, que las entradas de registro tienen que tener un formato específico).

Bueno, espero que os haya gustado mi primer post tras la vuelta de vacaciones. Os deseo un buen comienzo de curso, y ya sabéis… ¡felices transformaciones!