Hasta ahora, hemos visto las diferentes herramientas y técnicas que podemos utilizar para explotar nuestros sistemas de Business Intelligence, para analizar la información y obtener conocimiento de los datos.
En algunos casos, desde esas mismas herramientas podríamos estar accediendo a nuestros sistemas transaccionales para analizar la información (lease ERP, CRM u otros sistemas), pero seguramente tendriamos problemas en cuanto a tiempos de respuesta; información repartida en diferentes sistemas que no son homogeneos, lo que dificulta el proceso de análisis; complejos reportes poco flexibles, etc, etc.
Para solucionar esto surgío el concepto de Dawarehouse o Almacen de Datos. Es una base de datos orientada al análisis y que es el CORAZON de todo proyecto de Business Intelligence. Esta base de datos deberá de poder soportar todos los tipos de herramientas de analisis que podamos utilizar.
Antes de continuar, os recomiendo visualizar el video elaborado por Josep Curto para sus alumnos de la UOC. En el se explican todos los concenptos referentes a DW, el Modelo Dimensional y todos sus componentes. También os recomiendo la serie de articulos temáticos publicados en su blog, gran trabajo.
Veamos un poco mas a fondo en que consiste:
(Definiciones extraidas del Consejo Superior de Informatica, del documento Manual para la adquisición de un sistema de Data Warehouse).
3.1. Justificación histórica
En la actualidad, las tecnologías de la información han automatizado los procesos de carácter típicamente repetitivo o administrativo, haciendo uso de lo que llamaremos sistemas de información operacionales.Entendemos por aplicaciones operacionales, aquellas que resuelven las necesidades de funcionamiento de la empresa. En este tipo de sistemas, los conceptos más importantes son la actualización y el tiempo de respuesta. Una vez satisfechas las necesidades operacionales más acuciantes, surge un nuevo grupo de necesidades sobre los sistemas de la empresa, a las cuales vamos a calificar como necesidades informacionales. Por necesidades informacionales, entendemos aquellas que tienen por objeto obtener la información necesaria, que sirva de base para la toma de decisiones tanto a escala estratégica como táctica. Estas necesidades informacionales se basan en gran medida en el análisis de un número ingente de datos, en el que es tan importante el obtener un valor muy detallado de negocio como el valor totalizado para el mismo. Es fundamental también la visión histórica de todas las variables analizadas, y el análisis de los datos del entorno. Estos requerimientos no son, a priori, difíciles de resolver dado que la información está efectivamente en los sistemas operacionales. Cualquier actividad que realiza la empresa está reflejada de forma minuciosa en sus bases de datos.
La realidad, sin embargo, es distinta, puesto que al atender las necesidades de tipo informacional, los responsables de sistemas se tropiezan con múltiples problemas. En primer lugar, al realizar consultas masivas de información (con el fin de conseguir el ratio, valor agrupado o grupo de valores solicitados), se puede ver perjudicado el nivel de servicio del resto de sistemas, dado que las consultas de las que estamos hablando, suelen ser bastante costosas en recursos. Además, las necesidades se ven insatisfechas por la limitada flexibilidad a la hora de navegar por la información y a su inconsistencia debido a la falta de una visión global (cada visión particular del dato está almacenada en el sistema operacional que lo gestiona).
En esta situación, el siguiente paso evolutivo ha venido siendo la generación de un entorno gemelo del operativo, que se ha denominado comúnmente Centro de Información, en el cual la información se refresca con menor periodicidad que en los entornos operacionales y los requerimientos en el nivel de servicio al usuario son más flexibles. Con esta estrategia se resuelve el problema de la planificación de recursos ya que las aplicaciones que precisan un nivel de servicio alto usan el entorno operacional y las que precisan consultas masivas de información trabajan en el Centro de Información. Otro beneficio de este nuevo entorno, es la no inferencia con las aplicaciones operacionales.
Pero no terminan aquí los problemas. La información mantiene la misma estructura que en las aplicaciones operacionales por lo que este tipo de consultas debe acceder a multitud de lugares para obtener el conjunto de datos deseado. El tiempo de respuesta a las solicitudes de información es excesivamente elevado. Adicionalmente, al proceder la información de distintos sistemas, con visiones distintas y distintos objetivos, en muchas ocasiones no es posible obtener la información deseada de una forma fácil y además carece de la necesaria fiabilidad.
De cara al usuario estos problemas se traducen en que no dispone a tiempo de la información solicitada y que debe dedicarse con más intensidad a la obtención de la información que al análisis de la misma, que es donde aporta su mayor valor añadido.
3.2.- ¿QUÉ ES UN DATA WAREHOUSE?
Tras las dificultades de los sistemas tradicionales en satisfacer las necesidades informacionales, surge el concepto de Data Warehouse, como solución a las necesidades informacionales globales de la empresa. Este término acuñado por Bill Inmon, se traduce literalmente como Almacén de Datos. No obstante si el Data Warehouse fuese exclusivamente un almacén de datos, los problemas seguirían siendo los mismos que en los Centros de Información.
La ventaja principal de este tipo de sistemas se basa en su concepto fundamental, la estructura de la información. Este concepto significa el almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y en un entorno diferenciado de los sistemas operacionales. Según definió Bill Inmon, el Data Warehouse se caracteriza por ser:
Integrado: los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.
Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.
Histórico: el tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones.
No volátil: el almacén de información de un Data Warehouse existe para ser leído, y no modificado. La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.
E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio. Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para lo que vamos a mostrar, para un sistema de gestión de expedientes, las jerarquías que se podrían manejar para el número de los mismo para las dimensiones: zona geográfica, tipo de expediente y tiempo de resolución.
La visión general de la información de ventas para estas dimensiones definidas, la representaremos, gráficamente como el cubo de la derecha:
Un gerente de una zona estaría interesado en visualizar la información para su zona en el tiempo para todos los productos que distribuye.
Un director de producto, sin embargo querría examinar la distribución geográfica de sus productos, para toda la información histórica almacenada en el Data Warehouse.
O se podría también examinar los datos en un determinado momento o una visión particularizada. A su vez estas dimensiones tienen una jerarquía, interpretándose en el cubo como que cada cubo elemental es un dato elemental, del que se puede extraer información agregada.
Y así por ejemplo se podría querer analizar la evolución de las ventas en Galicia de libros de Física por meses desde Febrero del 1996 hasta Marzo del 1997.Ello es fácil de obtener (incluso a “golpe de ratón”) si la información de ventas se ha almacenado en un Data Warehouse, definiendo estas jerarquías y estas dimensiones de negocio.
En este sentido citamos las palabras de D. Wayne Calloway Director Ejecutivo de Operaciones de Pepsico en una asamblea general de accionistas:
“Hace diez años les pude decir cuántos Doritos vendimos al Oeste del Mississipi. Hoy no sólo les puedo decir eso mismo, sino cuántos vendimos en California, en el Condado de Orange, en la ciudad de Irvine, en el Supermercado local Von’s, en una promoción especial, al final del pasillo 4, los jueves”.
Otra característica del Data Warehouse es que contiene datos relativos a los datos, concepto que se ha venido asociando al término de metadatos. Los metadatos permiten mantener información de la procedencia de la información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc., relativa a los datos de nuestro almacén.Estos metadatos serán los que permitan simplificar y automatizar la obtención de la información desde los sistemas operacionales a los sistemas informacionales.
Los objetivos que deben cumplir los metadatos, según el colectivo al que va dirigido, serían:
• Soportar al usuario final, ayudándole a acceder al Data Warehouse con su propio lenguaje de negocio, indicando qué información hay y qué significado tiene. Ayudar a construir consultas, informes y análisis, mediante herramientas de navegación.
• Soportar a los responsables técnicos del Data Warehouse en aspectos de auditoría, gestión de la información histórica, administración del Data Warehouse, elaboración de programas de extracción de la información, especificación de las interfaces para la realimentación a los sistemas operacionales de los resultados obtenidos, etc.
Para comprender el concepto de Data Warehouse, es importante considerar los procesos que lo conforman. A continuación se describen dichos procesos clave en la gestión de un Data Warehouse:
Extraccion: obtención de información de las distintas fuentes tanto internas como externas.
Elaboracion: filtrado, limpieza, depuración, homogeneización y agrupación de la información.
Carga: organización y actualización de los datos y los metadatos en la base de datos.
Explotacion: extracción y análisis de la información en los distintos niveles de agrupación.
Desde el punto de vista del usuario, el único proceso visible es la explotación del almacén de datos, aunque el éxito del Data Warehouse radica en los tres procesos iniciales que alimentan la información del mismo y suponen el mayor porcentaje de esfuerzo (en torno a un 80%) a la hora de desarrollar el almacén.
Las diferencias de un Data Warehouse con un sistema tradicional las podríamos resumir en el siguiente esquema:
Una de las claves del éxito en la construcción de un Data Warehouse es el desarrollo de forma gradual, seleccionando a un departamento usuario como piloto y expandiendo progresivamente el almacén de datos a los demás usuarios. Por ello es importante elegir este usuario inicial o piloto, siendo importante que sea un departamento con pocos usuarios, en el que la necesidad de este tipo de sistemas es muy alta y se puedan obtener y medir resultados a corto plazo.
Terminamos este apartado, resumiendo los beneficios que un Data Warehouse puede aportar:
• Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en información integrada y global del negocio.
• Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha información.
• Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios.
• Simplifica dentro de la empresa la implantación de sistemas de gestión integral de la relación con el cliente.
• Supone una optimización tecnológica y económica en entornos de Centro de Información, estadística o de generación de informes con retornos de la inversión espectaculares.
3.3.Data Warehouse vs. Data Mart
La duplicación en otro entorno de datos es un término que suele ser mal interpretado e incomprendido. Así es usado por los fabricantes de SGBD en el sentido de simple réplica de los datos de un sistema operacional centralizado en sistemas distribuidos. En un contexto de Data Warehouse, el término duplicación se refiere a la creación de Data Marts locales o departamentales basados en subconjuntos de la información contenida en el Data Warehouse central o maestro.
Según define Meta Group, “un Data Mart es una aplicación de Data Warehouse, construida rápidamente para soportar una línea de negocio simple”. Los Data Marts, tienen las mismas características de integración, no volatilidad, orientación temática y no volatilidad que el Data Warehouse. Representan una estrategia de “divide y vencerás” para ámbitos muy genéricos de un Data Warehouse.
Esta estrategia es particularmente apropiada cuando el Data Warehouse central crece muy rápidamente y los distintos departamentos requieren sólo una pequeña porción de los datos contenidos en él. La creación de estos Data Marts requiere algo más que una simple réplica de los datos: se necesitarán tanto la segmentación como algunos métodos adicionales de consolidación.
La primera aproximación a una arquitectura descentralizada de Data Mart, podría ser venir originada de una situación como la descrita a continuación.
El departamento de Marketing, emprende el primer proyecto de Data Warehouse como una solución departamental, creando el primer Data Mart de la empresa. Visto el éxito del proyecto, otros departamentos, como el de Riesgos, o el Financiero se lanzan a crear sus Data Marts. Marketing, comienza a usar otros datos que también usan los Data Marts de Riesgos y Financiero, y estos hacen lo propio. Esto parece ser una decisión normal, puesto que las necesidades de información de todos los Data Marts crecen conforme el tiempo avanza.
Cuando esta situación evoluciona, el esquema general de integración entre los Data Marts pasa a ser, la del gráfico anterior. En esta situación, es fácil observar cómo este esquema de integración de información de los Data Marts, pasa a convertirse en un rompecabezas en el que la gestión se ha complicado hasta convertir esta ansia de información en un auténtico quebradero de cabeza. No obstante, lo que ha fallado no es la integración de Data Marts, sino su forma de integración.
En efecto, un enfoque más adecuado sería la coordinación de la gestión de información de todos los Data Marts en un Data Warehouse centralizado. En esta situación los Data Marts obtendrían la información necesaria, ya previamente cargada y depurada en el Data Warehouse corporativo, simplificando el crecimiento de una base de conocimientos a nivel de toda la empresa.
Esta simplificación provendría de la centralización de las labores de gestión de los Data Marts, en el Data Warehouse corporativo, generando economías de escala en la gestión de los Data Marts implicados.
Según un estudio de IDC ( International Data Corporation ) tras analizar 541 empresas, la distribución de las implantaciones de Data Warehouse y Data Marts en la actualidad, y sus opiniones respecto a esta distribución en el futuro, nos muestra los siguientes datos:
La proporción actual de implantaciones de Data Warehouse es casi el doble que el de Data Mart. No obstante, seguramente tras la andadura inicial de alguno de estos proyectos de Data Mart, se ve como más adecuado para el futuro este enfoque “divide y vencerás”, previéndose una inversión de estos papeles y duplicando la implantación de Data Marts a los Data Warehouse.
Probablemente, el 5% de usuarios que disponen de tecnología de Data Warehouse y piensan renunciar a ella en el futuro, no han realizado previamente un estudio de factores implicados en un Data Warehouse, o han pasado por la situación inicial de partida, y no se han planteado una reorganización del mismo.
3.4.COMPONENTES A TENER EN CUENTA A LA HORA DE CONSTRUIR UN DW
3.4.1.Hardware
Un componente fundamental a la hora de poder contar con un Data Warehouse que responda a las necesidades analíticas avanzadas de los usuarios, es el poder contar con una infraestructura Hardware que la soporte. En este sentido son críticas, a la hora de evaluar uno u otro hardware, dos características principales:
Por un lado, a este tipo de sistemas suelen acceder pocos usuarios con unas necesidades muy grandes de información, a diferencia de los sistemas operacionales, con muchos usuarios y necesidades puntuales de información. Debido a la flexibilidad requerida a la hora de hacer consultas complejas e imprevistas, y al gran tamaño de información manejada, son necesarias unas altas prestaciones de la máquina.
Por otro lado, debido a que estos sistemas suelen comenzar con una funcionalidad limitada, que se va expandiendo con el tiempo (situación por cierto aconsejada), es necesario que los sistemas sean escalables para dar soporte a las necesidades crecientes de equipamiento. En este sentido, será conveniente el optar por una arquitectura abierta, que nos permita aprovechar lo mejor de cada abricante.
En el mercado se han desarrollado tecnologías basadas en tecnología de procesamiento paralelo, dan el soporte necesario a las necesidades de altas prestaciones y escalabilidad de los Data Warehouse. Estas tecnologías son de dos tipos:
• SMP (Symmetric multiprocessing, o Multiprocesadores Simétricos): Los sistemas tienen múltiples procesadores que comparten un único bus y una gran memoria, repartiéndose los procesos que genera el sistema, siendo el sistema operativo el que gestiona esta distribución de tareas. Estos sistemas se conocen como arquitecturas de “casi todo compartido”. El aspecto más crítico de este tipo de sistemas es el grado de rendimiento relativo respecto al número de procesadores presentes, debido a su creciente no lineal.
• MPP (Massively parallel processing, o Multiprocesadores Masivamente Paralelos): Es una tecnología que compite contra la SMP, en la que los sistemas suelen ser casi independientes comunicados por intercambiadores de alta velocidad que permiten gestionarlos como un único sistema. Se conocen por ello como arquitecturas de “nada compartido”. Su escalabilidad es mayor que la de los SMP.
Según Meta Group, las tendencias de mercado indican que las arquitecturas SMP aportan normalmente suficientes características de escalabilidad, con una mayor oferta y un menor riesgo tecnológico. Sin embargo, cuando las condiciones de escalabilidad sean extremas, se puede plantear la opción MPP. No obstante, se están produciendo avances significativos en arquitecturas SMP, que han ogrado máquinas con un crecimiento lineal de rendimiento hasta un número de 64 procesadores.
3.4.2.-Software de almacenamiento (SGBD)
Como hemos comentado, el sistema que gestione el almacenamiento de la información (Sistema de Gestión de Base de Datos o SGBD), es otro elemento clave en un Data Warehouse. Independientemente de que la información almacenada en el Data Warehouse se pueda analizar mediante visualización multidimensional, el SGBD puede estar realizado utilizando tecnología de Bases de Datos Relacionales o Multidimensionales.
Las bases de datos relacionales, se han popularizado en los sistemas operacionales, pero se han visto incapaces de enfrentarse a las necesidades de información de los entornos Data Warehouse. Por ello, y puesto que, como hemos comentado, las necesidades de información suelen atender a consultas multidimensionales, parece que unas Bases de Datos multidimensionales, parten con ventaja. En este sentido son de aplicación los comentarios que realizamos en el apartado de hardware, por requerimientos de prestaciones, escalabilidad y consolidación tecnológica.
Al igual que en el hardware, nuevos diseños de las bases de datos relacionales, las bases de datos post-relacionales, abren un mayor abanico de elección. Estas bases de datos post-relacionales, parten de una tecnología consolidada y dan respuesta al agotamiento de las posibilidades de los sistemas de gestión de bases de datos relacionales, ofreciendo las mismas prestaciones aunque implantadas en una arquitectura diseñada de forma más eficiente.
Esta mayor eficiencia se consigue instaurando relaciones lógicas en vez de físicas, lo que hace que ya no sea necesario destinar más hardware a una solución para conseguir la ejecución de las funciones requeridas. El resultado es que la misma aplicación implantada en una BD postrelacional requiere menos hardware, puede dar servicio a un mayor número de usuarios y utilizar mecanismos intensivos de acceso a los datos más complejos. Asimismo, esta tecnología permite combinar las ventajas de las bases de datos jerárquicas y las relacionales con un coste más reducido. Ambos sistemas aportan como ventaja que no resulta necesario disponer de servidores omnipotentes, sin que puede partirse de un nivel de hardware modesto y ampliarlo a medida que crecen las necesidades de información de la compañía y el uso efectivo del sistema.
Dejamos fuera del ámbito de esta guía el detallar cómo los proveedores de bases de datos han optimizado los accesos a los índices, o las nuevas posibilidades que ofrece la compresión de datos (menos espacio para la misma información lo que implica, entre otras ventajas, que más información se puede tener en caché), para lo que remitimos a la prensa especializada o a las publicaciones de los fabricantes.
3.4.3.- Software de extracción y manipulación de datos
En este apartado analizaremos un componente esencial a la hora de implantar un Data Warehouse, la extracción y manipulación. Para esta labor, que entra dentro del ámbito de los profesionales de tecnologías de la información, es crítico el poder contar con herramientas que permitan controlar y automatizar los continuos “mimos” y necesidades de actualización del Data Warehouse.
Estas herramientas deberán proporcionar las siguientes funcionalidades:
• Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.
• Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.
• Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.
• Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.
• Acceso a una gran variedad de fuentes de datos diferentes.
• Manejo de excepciones.
• Planificación, logs, interfaces a schedulers de terceros, que nos permitiran llevan una gestión de la planificación de todos los procesos necesarios para la carga del DW.
• Interfaz independiente de hardware.
• Soporte en la explotación del Data Warehouse.
A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo.
3.4.4.- Herramientas Middleware
Como herramientas de soporte a la fase de gestión de un Data Warehouse, analizaremos a continuación dos tipos de herramientas:
• Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse.
• Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuestas en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse.
Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. Tambien deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. Estarán abiertas a todo tipos de entornos de almacenamiento de datos, tanto mediante estándares de facto (OLE, ODBC, etc.), como a los tipos de mercado más populares (DB2, Access, etc.). La conectividad, al menos en estándares de transporte (SNA LU6.2, DECnet, etc.) debe estar tambien asegurada.
Con el uso de estas herramientas de Middleware lograremos:
• Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada.
• Integrar los datos y aplicaciones existentes en una plataforma distribuida.
• Automatizar la distribución de datos y aplicaciones desde un sistema centralizado.
• Reducir tráfico en la red, balanceando los niveles de cliente servidor (mas o menos datos en local, mas o menos proceso en local).
• Explotar las capacidades de sistemas remotos sin tener que aprender multiples entornos operativos.
• Asegurar la escalabilidad del sistema.
• Desarrollar aplicaciones en local y explotarlas en el servidor.
Los analizadores y aceleradores de querys trabajan volcando sobre un fichero de log las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc). Este log se analiza, bien automáticamente o mediante la supervisión del administrador de datos, para mejorar los tiempos de accesos.
Estos sistemas de monitorización se pueden implementar en un entorno separado de pruebas, o en el entorno real. Si se ejecutan sobre un entorno de pruebas, el rendimiento del entorno real no se vé afectado. Sin embargo, no es posible optimizar los esfuerzos, puesto que los análisis efectuados pueden realizarse sobre consultas no críticas o no frecuentemente realizadas por los usuarios.
El implantar un sistema analizador de consultas, en el entorno real tiene además una serie de ventajas tales como:
• Se pueden monitorizar los tiempos de respuesta del entorno real.
• Se pueden implantar mecanismos de optimización de las consultas, reduciendo la carga del sistema.
• Se puede imputar costes a los usuarios por el coste del Data Warehouse.
• Se pueden implantar mecanismos de bloqueo para las consultas que vayan a implicar un tiempo de respuesta excesivo.
3.4.5.Conclusiones y consideraciones de interes.
El Data Warehouse va a ser el elemento principal en nuestro sistema de Inteligencia de Negocio. De su correcta definición, procesamiento y carga de datos va a depender el exito posterior del proyecto.
Aunque el usuario al final solo vea un conjunto de herramientas de analisis que utilizar para “atacar” a los datos, por delante hay una serie de procesos que hacen que toda la información proveniente de diferentes sistemas haya sido identificada, extraida, procesada, homogeneizada, depurada y cargada en el Datawarehouse. Esto es posible a través de las herramientas ETL y Middleware. Y esta es la parte que normalmente mas tiempo lleva en cualquier proyecto.
Muchas veces conviene elegir un departamento piloto para implantar sistemas de este tipo que luego nos permitan vender internamente dentro de la organización los proyectos.
Habrá que dar siempre importancia a la formación como eje fundamental al uso de las herramientas.
Los proyectos de BI y DW no van a ser solo proyectos tecnológicos, hay mucho mas detras, y aunque en ellos se utilize la tecnología tiene que haber conocimiento empresarial para poder reflejar en el lo que realmente se necesita, desde los niveles mas bajos hasta los superiores de toma de decisiones. En este momento el consultor de BI también tiene que ser capaz de aportar no solo su conocimiento tecnológico, sino también conocimiento de las area de negocio y de los diferentes elementos que se van a utilizar en el diseño, desarrollo y explotación de un sistema de BI (ver el artículo de Jorge Fernández en su blog: El consultor de Bi, ese bicho raro ).
3.4.6. Nuevas tendencias en el mundo DW. El Datawarehouse 2.0.
Los sistemas DW han evolucionado en los ultimos años conforme han surgido nuevas necesidades. Los motivos de esta evolución son varios, y los podemos resumir en:
- Uso de herramientas de analisis que obligaban a estructuras diferentes optimazadas al uso de determinadas tecnologías (por ejemplo el data mining o el uso de herramientas estadísticas).
- Simplificación de la gestión de sistemas DW complejos formados por multiples datamarts orientados a cada departamento en los que se pierde el concepto de Corporativo (que hace que se pierdan oportunidades ).
- De la unión de multiples aplicaciones pequeñas (Datamarts o Datawarehouse), no surge toda la información corporativa. Sería necesario construir este Centro a partir del cual se van a generar todos los DW necesarios para todos los ambitos de análisis.
- Proceso Online: los procesos de actualización hacían que hubiera muchos momentos en los que no se podía acceder a los datos. Igualmente, podría haber cierto retardo en la disponibilidad de la información, lo que nos impedia poder hacer análisis inmediatos (analisis mas orientados a la operacion del negocio).
- Evolución tecnologica en las herramientas ETL, costes de la tecnología (los costes han bajando de tal forma que permiten abordar los proyectos de una forma mas amplia), etc.
Por todo esto surge el concepto de CIF ( Corporate Information Factory), que podría incluir todos los elementos que vemos en la imagen siguiente:
El Corporate Information Factory (CIF) es una arquitectura conceptual que describe y categoriza los almacenes de informacion usados para operar y gestionar con exito una infraestructura de BI robusta.
El uso de esta arquitectura o de otras mas sencillas va a depender del tipo de compañia, los requerimientos de analisis y hasta donde se quiera llegar en el uso del BI. Los elementos que forman el CIF, de forma resumida, son los siguientes:
Data Warehouse: es el almacen de datos, según las definiciones vistas hasta ahora. Pero ademas, en esta arquitectura, es el punto central de la integración de datos. Centraliza toda la información, nos da una vision en comun de la información de toda la organización y proporciona los datos para llenar de contenido el resto almacenes de datos especificos, a través de los procesos de Data delivery (extracción de datos con condiciones de filtrado, sumarización, etc para otros tipos de analisis).
Operational Data Store: es un almacen de datos, como el DW, pero orientado a las toma de decisiones tacticas. Se alimenta de datos actuales de los sistemas operacionales, nos es un sistema historico, tiene la información mucho mas en detalle y los tiempos de actualización suelen ser mucho mas rápidos para permitir la toma de decisiones rápidas sobre los datos de operación del negocio. Sería un sistema cercano al tiempo real y suele incluir información sobre clientes, materiales, stocks, ventas, etc.
Data Acquisition: son todas las herramientas y sistemas de gestión que nos permite la extracción, transformación y carga de los datos provenientes de los diferentes sistemas origen (sistemas externos, ERP, sistemas internos, ficheros, etc), en nuestro Datawarehouse. Serian las herramientas ETL y los sistemas de gestión de la adquisición de datos (Data Acquisition Management).
Data Delivery: son las operaciones de agregacion de la información, filtrado por dimensiones especificas o requerimientos de negocio, reformateo o procesamiento de la información para soportar el uso de herramientas de BI especificas, y finalmente, la transmisión de la información a través de la organización (para dar contenido a los Datamarts o Warehouse especificos).
A partir del DW podremos construir subconjuntos de el orientados al uso de tecnicas especificas de BI:
Exploration Warehouse: almacen de exploración para utilizar herramientas de tipo estadistico y de exploracion.
Data Mining Warehouse: almacen para el uso de tecnicas de datamining.
Olap Data Mart: almacen de datos para el uso de analisis multidimensionales (tipo OLAP).
Operational Mart: subconjunto del ODS (operational Data Store), para permitir analisis operacional restringido a un ambito menor.
Si quereis saber mas sobre las nuevas arquitecturas, os recomiendo los libros:
The data warehouse toolkit : the complete guide to dimensional modeling
Ralph Kimball, Margy Ross. — 2nd ed.
ISBN 0-471-20024-7
Mastering data warehouse design
Imhoff, Claudia
Galemmo, Nicholas
Geiger, Jonathan G.
ISBN:978-0-471-32421-8
DW 2.0: The Architecture for the Next Generation of Data Warehousing
William Inmon
Derek Strauss
Genia Neushloss
ISBN: 978-0-12-374319-0