En el día a día las organizaciones van automatizando procesos y registrando datos de manera separada, pero de cara al mundo analítico es necesario adquirir una visión única. Aquí es donde entra en juego la integración de datos, una de las claves de la gestión de datos en proyectos de Data Warehouse, que logra correlacionar las diferentes áreas y procesos de la empresa como un todo, para dotar al análisis de esa imprescindible unificación de criterios transmisora de consistencia y completitud.
Para lograr integrar los datos origen en el Data Warehouse, es necesario actuar a dos niveles:
- Definiendo el ciclo de transición de los datos.
- Estableciendo la frecuencia de refresco de cada uno de ellos.
Créditos fotográficos: "Business Man With Laptop,mobile Phone,touch Screen Device" by jannoon028
El primer paso para conseguirlo es mediante la definición del proceso de extracción. En este caso, suele haber dos prácticas habituales: la invasiva y la de abstracción, aunque es mucho más recomendable el uso de la segunda, sobre todo si se apela a la responsabilidad. Además, hay que tener en cuenta que el mundo de los sistemas transaccionales es muy dinámico y el método invasivo puede no dar los resultados esperados si se han producido transformaciones.
La práctica invasiva, consistente en plantear los procesos de extracción atacando de forma directa a los orígenes de datos y procediendo al siguiente paso (transformación) en la misma operación, tiene el inconveniente de provocar que el conjunto del proceso quede excesivamente ligado a las estructuras del sistema origen. La desventaja es que si éste cambia de estructura, como suele ocurrir, por ejemplo, al actualizar su versión; se produce un impacto directo en todo el proceso.
La práctica abstracta, la que Lantares recomienda, consta de generar una independencia a través de ficheros. Ello implica que, desde los sistemas origen, se producirá la generación de ficheros de datos (que pueden ser ficheros de texto plano, csv, o incluso xml), los cuales se depositarán en un recurso compartido para su posterior transformación y carga.
Esta práctica, proporciona la garantía que, si el sistema origen cambia de estructura, por una actualización o cambio del ERP, por ejemplo; este hecho no causará impacto directo en los procesos de integración ni en la estructura del Data Warehouse, ya que sólo habrá que procurar que los ficheros mantengan la misma estructura.
Una vez que la fase de extracción ha concluido con éxito, da comienzo el proceso de transformación. En esta etapa, se realizan cambios de los datos origen para lograr que terminen adecuándose al destino en el DWH. Existen muchas formas de lograrlo y algunas de las más frecuentes son:
- Aplicando filtros: por ejemplo introduciendo el comando de recoger únicamente registros con datos mayores de cero.
- Cambiando el formato: la manera de hacerlo podría ser transformando el formato americano en que las fechas han sido recogidas en origen (M/D/A) para establecer el europeo (D/M/A) como definitivo para todos los sistemas.
- Llevando a cabo agregaciones: que permitan que, aunque los datos sean recogidos con una periodicidad diaria, se puedan extraer del DWH como agregados por meses.
- Estableciendo uniones: por ejemplo, al recoger ventas de diferentes tiendas que, en el DWH, serán volcadas en una misma tabla de hechos.
- Disponiendo transformaciones: para hacer posible la normalización de códigos de cliente, por ejemplo, a 4 dígitos.
Si la transformación se ha llevado a cabo correctamente y así lo demuestran los ciclos de prueba, puede dar comienzo la fase de carga, que consiste en el volcado de los datos procesados a las estructuras finales de los Datamarts que componen el DWH. Es importante definir la estrategia de carga y para ello hay que escoger si tendrá lugar de forma:
- Total: se borra todo el contenido y se recarga completo todo el histórico.
- Incremental: sólo se cargan las novedades.
No hace mucho tiempo, el proceso de diseño se llevaba a cabo en papel, para posteriormente proceder a programar sentencias SQL. Con la aparición de herramientas ETL (Extract Transformation Load), es posible realizar tanto el diseño como la construcción, en una única operación.
ETL es la alternativa óptima a codificar SQL. SQL (Standar Query Language) es un lenguaje de programación empleado para hacer consultas a base de datos. Su rasgo más característico es que se hace manualmente por lo que puede contener errores y además puede también conducir a errores... ETL es la opción ya que está automatizada, de hecho la manera en que permite proceder a la construcción de los procesos de integración es simplemente arrastrando iconos (stages) que representan una función. Esta forma de diseño implica numerosos beneficios como:
- Mejorar la arquitectura y reducir los costes de mantenimiento.
- Reutilizar los perfiles profesionales y procedimientos.
- Gestionar los Meta Datos.
- Hacer foco en el negocio, en vez de programación y foco en interfaces.
- Construir gestión dentro de las aplicaciones.
- Ganar en seguridad.
- Tener acceso a los sistemas de gestión y programación de eventos.
- Disminuir notablemente el tiempo de desarrollo.