DB Modulo 1.pdf

Bloque 1Bloque 2Bloque 3Bloque 4Bloque 5Bloque 6Referencias Business intelligence 1. Concepto de business intelligence “Business Intelligence (BI) es un término genérico que incluye las aplicaciones, infraestructura y herramientas y las mejores prácticas que permiten el acceso y análisis de información para mejorar y optimizar las decisiones y el desempeño” (Gartner, s. f., https://gtnr.it/3AtTIyN). Introducción El objetivo de business intelligence (BI), también conocida como “inteligencia de negocios”, consiste en “apoyar de forma sostenible y continuada a las organizaciones para mejorar su competitividad, facilitando la información necesaria para la toma de decisiones” (Cano, 2007, p. 22). Howard Dresner, de Gartner, la reconocida empresa de consultoría en tecnologías de la información, fue quien utilizó por primera vez el concepto de BI en el año 1989. Casualmente, la definición más actualizada y apropiada del concepto la podemos ubicar en el actual glosario de términos del sitio web de Gartner (https://gtnr.it/3AtTIyN, s. f.): “Business Intelligence (BI) es un término genérico que incluye las aplicaciones, infraestructura y herramientas y las mejores prácticas que permiten el acceso y análisis de información para mejorar y optimizar las decisiones y el desempeño”. BI puede manejar grandes cantidades de datos desestructurados para ayudar a identificar, desarrollar y crear nuevas oportunidades. La inteligencia de negocios, en definitiva, permite interpretar los datos voluminosos de manera amigable y facilitar el aprovechamiento de potenciales oportunidades, implementando una estrategia efectiva que le provea una ventaja competitiva a la empresa. Las tecnologías de BI proporcionan vistas históricas y predictivas de las operaciones comerciales de las compañías. Algunas de las funciones más comunes de las tecnologías de BI son reporting, OLAP (online analytical processing) y minería de datos. Boris Evelson, de la consultora especializada Forrester Research, sostiene lo siguiente: BI es un conjunto de metodologías, procesos, arquitecturas y tecnologías que transforman los datos en información útil y significativa tal que permite una toma de decisiones estratégica, táctica y operativa más efectiva, con datos en tiempo real que le posibilitan a una empresa superar de manera eficaz a sus demás competidores en el mercado. (2008, https://bit.ly/2XJXaHm) Ralph Kimball (2013) define que un sistema de BI debe satisfacer varios requerimientos, entre los cuales podemos citar los siguientes: Debe hacer que la información sea fácilmente accesible. Debe presentar la información de manera consistente. Debe adaptarse al cambio. Debe presentar la información de manera oportuna. Debe ser un resguardo seguro que proteja los activos de información. Debe servir como el fundamento autorizado y confiable para la toma de decisiones. La comunidad de negocios debe aceptar al sistema de BI para que sea exitoso. Kimball (2013) sostiene que los dos últimos requerimientos son los más críticos y frecuentemente los más desatendidos por las organizaciones a la hora de implementar un sistema de BI. 2. Evolución de los SSD Historia Si bien el término business intelligence empezó a hacerse popular a partir de 1989, fue en el año 1958 cuando Hans Peter Luhn, investigador de IBM, definió a la inteligencia de negocios como “la capacidad de comprender las interrelaciones de hechos presentados de una manera tal que guía la acción hacia una meta deseada” (White, 2019, https://bit.ly/3kskWAn). Incluso, las primeras empresas de software especializadas en lo que hoy denominamos “BI” surgen en la década de 1970, como Information Builders (1975) o SAS (1976). Sin embargo, el concepto de “BI”, tal como lo conocemos hoy, ha evolucionado significativamente desde los originales sistemas de soporte de decisión (DSS, por sus siglas en inglés —decision support systems—). William Inmon (2005) sostiene que en la década de 1980 aparecieron los sistemas de información gerencial (MIS, por sus siglas en inglés —management information systems—). Tiempo más tarde, ya más conocidos como “DSS”, los primeros MIS comenzaron a usarse como software para tomar decisiones. Antes, tanto los datos como las tecnologías existentes se usaban exclusivamente para tomar decisiones operativas detalladas, y, hasta entonces, ningún motor de bases de datos podía llegar a servir para propósitos de procesamiento operacional/transaccional y analítico en forma simultánea. Los softwares MIS, que, generalmente, contaban con una interfaz de usuario poco amigable, tampoco tenían grandes capacidades de modelado y estaban más bien orientados a la integración de información para la toma de decisiones. Los sistemas de gestión de bases de datos (DBMS, por sus siglas en inglés —database management systems—), que surgieron en la década de 1970, verdaderamente dieron origen una nueva era informática con el advenimiento del procesamiento transaccional en línea (OLTP, por sus siglas en inglés). William Inmon (2005) alega que los primeros almacenes de datos (más conocidos como data warehouses en inglés) nacen en 1983. Tras la implementación de sistemas operacionales/transaccionales masivos (OLTP —Online transaction processing—), hacia el año 1985 surgieron los primeros sistemas de extracción de datos (ETL, por sus siglas en inglés —extract, transform and load—), que hacían posible la transferencia de datos hacia otra base de datos o archivo. Estos programas de extracción comenzaron a ser muy populares en su época, ya que permitían que los análisis de información para la toma de decisiones se ejecutaran sobre una base de datos distinta, diferente de la que usaban los sistemas transaccionales u operacionales. Naturalmente, estos OLTP son fundamentales para la operación exitosa de cualquier negocio. Los DSS nacieron también en la década de 1980. Estos sistemas fueron creados para asistir en el proceso de toma de decisiones y planificación. Con mayores capacidades de modelado y mejor interfaz de usuario que los tradicionales MIS, pronto tuvieron un gran éxito y en pocos años evolucionaron en sistemas multiusuario, es decir, permitieron la toma de decisiones en grupo. Posteriormente, a comienzos de la década de 1990, nacen los sistemas de información ejecutivos (EIS, por sus siglas en inglés —executive information systems—): softwares con capacidades adicionales para navegar sobre información más detallada, con extraordinarias interfaces y, sobre todo, intensivos en el acceso a bases de datos integradas y unificadas, aunque, a la vez, carentes, en muchos casos, de herramientas avanzadas de modelado. Information Builders anunció su primer software en el año 1991 EIS. Sin embargo, fue en el siguiente año cuando la empresa MicroStrategy lanzó al mercado el primer producto de software de BI completo. En los 90, también surgieron las herramientas de minería de datos (en inglés, data mining), orientadas a la búsqueda de patrones y relaciones ocultas en los datos. Gracias a la implementación de enormes almacenes de datos, se podía obtener conocimiento de grandes volúmenes de datos. William Inmon (2005) afirma que a partir de 1994 surgieron otros conceptos ligados a BI, tales como las bases de datos multidimensionales, OLAP, exploration warehouses, ODS, entre otros conceptos que veremos más adelante en esta misma unidad. En definitiva, si bien el concepto actual de BI fue propuesto en 1989 por Howard Dresner, fue recién a fines de la década de 1990 que el software BI logró una importante inserción en las organizaciones, que se mantiene en la actualidad. Además, cabe destacar la impresionante convergencia de tecnologías surgidas en las últimas dos décadas. Algunas de ellas son las siguientes: La aparición de Internet, que posibilitó que el software BI estuviera disponible a través de la visualización de información en un navegador o browser. El surgimiento de los conceptos de “software como servicio” (SaaS, por sus siglas en inglés — software as a service—) y “computación en la nube” (en inglés, cloud computing), que permitió disminuir drásticamente los costos de implementación de grandes sistemas de BI, al contratar por usuario un abono mensual. Bases de datos in-memory y técnicas de lógica asociativa, que les proveen a los usuarios de BI la posibilidad de analizar grandes cantidades de datos sin necesidad de generar costosas estructuras analíticas por separado (como herramientas OLAP). El bum de la tecnología mobile a través de smartphones y tablets, que hizo que los usuarios BI pudieran trabajar muchas veces en forma remota accediendo a información crítica del negocio para la toma de decisiones en forma descentralizada. El advenimiento de big data y la evolución hacia grandes volúmenes de datos desde algunos terabytes hasta varios petabytes en único repositorio. Aplicaciones analíticas, algunas de las cuales, dada la gran proliferación de herramientas de BI, se focalizaron en la gestión de métricas o indicadores claves de negocio (KPI, por sus siglas en inglés —key performance indicators—) para determinadas industrias verticales: BI para el sector finanzas, BI para el sector salud, BI para el sector manufacturero, etcétera. Evidentemente, esta convergencia tecnológica está generando una constante evolución del software BI para adaptarse a nuevos requerimientos de los usuarios, a nuevas tecnologías, a nuevas metodologías y a nuevas formas de acceder a los datos. 3. Necesidades Ralph Kimball (2013) considera que uno de los activos más importantes de cualquier organización es su información. Este activo es casi siempre usado para dos propósitos: la preservación de los registros operativos/transaccionales y la toma de decisiones analítica. Así, mientras los sistemas operacionales/transaccionales se ocupan de incorporar datos a las bases de datos, los sistemas de BI permiten explotar o visualizar esos datos y los convierten en información para la toma de decisiones. Los usuarios de los sistemas operacionales/transaccionales son los que realmente mueven las ruedas de la organización (generando solicitudes, dando de alta clientes, monitoreando el estado de las actividades, entre otras formas). De esta manera, estos sistemas están optimizados para procesar las transacciones rápidamente. Casi siempre, los sistemas transaccionales trabajan con un registro o una transacción por vez en un momento dado. En definitiva, automatizan los procesos de negocio de la empresa. Sin embargo, dado su enfoque operativo, generalmente, no guardan datos históricos con gran precisión; por el contrario, con frecuencia, sus estructuras de datos solo guardan el estado actual. En cambio, los usuarios de un sistema de BI se encargan de vigilar y controlar el movimiento de las ruedas de la organización, con el objeto de evaluar su desempeño. Así, cuentan la cantidad de solicitudes generadas y las comparan con las del mes o año anterior. Se preocupan por que los procesos operativos estén trabajando correctamente. Aunque necesitan datos detallados para soportar sus requerimientos, los usuarios BI casi nunca se enfocan en una transacción en un momento dado. Los sistemas BI, por lo general, están optimizados para consultas de alto desempeño, teniendo en cuenta que las consultas de los usuarios requieren habitualmente la agregación o sumarización de cientos, miles o incluso millones de registros diferentes. Por lo tanto, el contexto histórico (y principalmente el período o tiempo asociado) es vital para la evaluación del desempeño que presentan. Ahora bien, ¿quién necesita de BI? Josep Lluís Cano (2007, p. 30) sostiene que “la información que podemos generar a partir de Business Intelligence es útil para todos los departamentos de nuestra organización”. Esto incluye a los responsables o gerentes de estos departamentos: Compras. Ventas/Comercial. Finanzas. Marketing. Recursos humanos. Operaciones. (Otros). Es decir, BI es útil para todas aquellas personas que deban tomar decisiones. 4. Problemática Ralph Kimball (2013) sostiene que los problemas típicos de los usuarios pueden sintetizarse en algunas de las dificultades que mencionamos a continuación: Recolectamos toneladas de datos, pero no podemos acceder a ellos. Los directivos necesitan obtener los datos fácilmente. “Solo muéstrame lo que es importante”. Desperdiciamos reuniones completas discutiendo quién tiene los números correctos, en lugar de tomar decisiones. Queremos que la gente use la información para mejorar su proceso de toma de decisiones. Por otro lado, William Inmon (2005) expresa que la inexistencia de una solución BI puede dar lugar a los siguientes problemas: Falta de credibilidad en los datos. Problemas con la productividad. Incapacidad de convertir datos en información. ☰ Falta de credibilidad en los datos Cuando no existe un único origen de información, puede suceder que en una misma organización encontremos dos departamentos, por ejemplo, uno que haya experimentado un incremento en las ventas del 10 % y el otro que haya experimentado un decremento del 5 %. Conciliar la información de ambos puede ser difícil o incluso imposible. Cuando la Gerencia recibe esta información contradictoria, no puede tomar decisiones de manera racional dada la falta de credibilidad en las fuentes. Las diferencias pueden surgir como consecuencia de varios factores: Distinta base (tiempo) de cálculo. Algoritmos diferentes. Niveles de extracción disímiles. Datos externos que son tenidos en cuenta (o no). Distinta base de datos, fuente de la información. ☰ Problemas con la productividad Del mismo modo que en el caso anterior, si no existe una base de datos única e integrada para el análisis de la información, se deberá enfrentar una fuerte pérdida de productividad, pues, por cada análisis requerido, será preciso revisar distintos archivos, bases de datos, etcétera, compilando información muchas veces contradictoria y sin una regla explícita de integración, que puede depender de lo que hace cada analista en un momento dado. Y hacer un informe manualmente supone una sobrecarga de trabajo evidente. ☰ La incapacidad de convertir datos en información Lo primero que descubrieron los analistas de los sistemas DSS a la hora de satisfacer la solicitud de información fue que ir a los sistemas transaccionales para obtener los datos necesarios era el peor escenario, puesto que estos sistemas y sus bases de datos subyacentes se construyeron sin tener en cuenta una futura integración de datos entre sí. Otro obstáculo que hallaron es que no hay suficientes datos históricos almacenados en las aplicaciones. Es decir, se trata de sistemas que fueron diseñados para responder rápidamente, con altos niveles de performance, y, muchas veces, esto se consigue guardando solo los últimos doce meses de trabajo en la base de datos, sin grandes registros históricos. 5. Beneficios Beneficios tangibles, intangibles y estratégicos De acuerdo con Josep Lluís Cano (2007, p. 32), “uno de los objetivos básicos de los sistemas de información es que nos ayuden a la toma de decisiones. Cuando un responsable tiene que tomar una decisión pide o busca información, que le servirá para reducir la incertidumbre”. Por lo tanto, un sistema de información de BI es clave para transformar los datos en información y la información en conocimiento. Hoy en día, las empresas, ante una dinámica de cambios casi permanente en los mercados, están sometidas a fuertes presiones competitivas, y sus directivos requieren del conocimiento que puede brindar un sistema de BI para poder soportar un proceso adecuado de toma de decisiones. Los beneficios que se pueden obtener a través del uso de BI pueden ser de distintos tipos: Beneficios tangibles, por ejemplo: reducción de costos, generación de ingresos y reducción de tiempos para las distintas actividades del negocio. Beneficios intangibles: el hecho de que tengamos disponible la información para la toma de decisiones hará que más usuarios utilicen dicha información para tomar decisiones y mejorar la nuestra posición competitiva. Beneficios estratégicos: Todos aquellos que nos facilitan la formulación de la estrategia, es decir, a qué clientes, mercados o con qué productos dirigirnos. (Cano, 2007, pp. 32-33) Este mismo autor también sostiene que “la principal razón de un proyecto de Business Intelligence es el análisis de un problema o problemas interrelacionados” (2007, p. 37). Cálculo del ROI en proyectos de BI: por qué es importante calcular el ROI De acuerdo con Josep Lluís Cano (2007), al plantear cualquier proyecto de sistema de información, es imprescindible calcular cuál es la rentabilidad que se espera de este. Por lo tanto, es necesario llevar a cabo las siguientes tareas: Definir el valor esperado, es decir, tratar de estimar cuál es el beneficio o valor agregado total que aportará el proyecto a la empresa. Determinar la inversión total requerida del proyecto con el objetivo de asegurar los fondos necesarios para su concreción, identificando los distintos retornos que se podrán conseguir. Implementar el proyecto y evaluar si se ha logrado alcanzar el valor y retorno esperados. Medir los resultados del proyecto e implementar un plan de acción correctivo alternativo. La medida comúnmente utilizada en el entorno empresarial para comprobar la rentabilidad de un proyecto es el retorno de la inversión (ROI). El ROI pone en relación el valor aportado al negocio con las inversiones necesarias para obtenerlo. Una forma simplificada del cálculo del ROI es la siguiente: Figura 1: Fórmula simplificada para calcular el ROI Fuente: Cano, 2007, p. 45 Metodología para el cálculo del ROI Josep Lluís Cano, sobre la base de un artículo de Bill Whittemore, propone la siguiente metodología paso a paso para el cálculo del ROI de un proyecto de BI: 1. Definir cuál es el problema u oportunidad de negocio y los objetivos del mismo. Los objetivos deben ser específicos, medibles, alcanzables, adecuados y referidos a un periodo de tiempo. 2. Recoger los requerimientos de negocio. 3. Construir el proyecto de Business Intelligence. 4. Identificar y cuantificar los beneficios (tangibles, estratégicos e intangibles). 5. Establecer el punto de partida de medida, tanto de los costos como de los ingresos. 6. Calcular el costo total de propiedad (TCO): incluye el hardware, software, los servicios de consultoría, los costos de los recursos internos (costos de personal) y los costos de lanzamiento, mantenimiento y formación. 7. Calcular el ROI. Para ello se aplica la siguiente fórmula: Figura 2. Fórmula Fuente: elaboración propia. En donde NPV es el Valor Neto Actual, es decir, la suma actualizada de los beneficios esperados del proyecto. Una vez aprobado e implementado el proyecto, deberemos hacer un seguimiento tanto de la inversión como de los costos y de los beneficios que realmente se han conseguido, para poder tomar las medidas correctivas que sean necesarias. (2007, pp. 47-49). Además, según Josep Lluís Cano (2007, p. 52), “los proyectos de Business Intelligence tienen un ROI elevado, su comportamiento es mucho mejor que en el resto de proyectos de Sistemas de Información”. 6. Proceso de toma de decisiones Podemos denominar “proceso de toma de decisiones” al proceso de tener que elegir entre distintos cursos de acción alternativos con el propósito de alcanzar un objetivo en particular. Kennet Laudon (2004) divide este proceso consta de cuatro etapas: Inteligencia. Diseño. Selección. Implementación. A continuación, veremos en detalle cada una de estas fases: ☰ Fase de inteligencia La etapa de inteligencia consiste en: identificar y entender los problemas que se presentan en la organización: el por qué ocurre un problema, dónde y cuáles son sus efectos. Los sistemas MIS tradicionales que suministran una gran variedad de información detallada pueden ayudar a identificar problemas, especialmente si los sistemas reportan excepciones. (Kennet Laudon, 2004, p. 88) ☰ Fase de diseño La etapa de diseño, según Kennet Laudon, es aquella durante la cual “el individuo genera posibles soluciones para los problemas. Los DSS más pequeños son ideales en esta etapa de la toma de decisiones, porque trabajan sobre modelos sencillos, es posible desarrollarlos rápidamente y pueden operar con datos limitados” (2004, p. 88). ☰ Fase de selección La etapa de selección consiste en elegir entre alternativas de solución. Aquí el encargado de la toma de decisiones podría necesitar un sistema DSS más grande para obtener datos más extensos a partir de varias alternativas y modelos complejos, o bien, herramientas de análisis de datos para recabar todos los costos, consecuencias y oportunidades. (Kennet Laudon, 2004, p. 88) ☰ Fase de implementación La etapa de implementación se lleva a cabo cuando la decisión se pone en práctica. En ella, los gerentes pueden utilizar un sistema que elabore informes de rutina sobre el progreso de una solución específica. Los sistemas de apoyo pueden abarcar desde sistemas MIS con características avanzadas hasta sistemas mucho más pequeños, así como software de planeación de proyectos que se ejecute en computadoras personales. (Kennet Laudon, 2004, p. 88) Tal como destaca Mónica López Gutiérrez (2004, https://acortar.link/ZqOjn4), debemos tener en cuenta que un DSS no es más que un sistema de información gerencial que permite “resolver problemas semiestructurados y no estructurados, involucrando al usuario a través de una interfaz amigable”. López Gutiérrez también sostiene que un DSS permite “mejorar el Proceso de Toma de Decisiones a lo largo de las etapas del mismo: inteligencia, diseño, selección e implementación... Los DSS principalmente se utilizan para decisiones estratégicas y tácticas en la gestión a nivel superior” (2004, https://acortar.link/ZqOjn4). Referencias Cano J. L. (2007). Business Intelligence: Competir con Información. España: Banesto Fundación Cultural y ESADE. Evelson, B. (2008). Topic Overview: Business Intelligence. Recuperado de http://www.forrester.com/Topic+Overview+Business+Intelligence/-/E-RES39218?objectid=RES39218 Gartner (s. f.). IT Glossary - Business Intelligence. Recuperado de http://www.gartner.com/itglossary/business- intelligence-bi Inmon, W. (2005). Building the Data Warehouse (4.ta. ed.). Estados Unidos: Wiley Publishing. Kimball, R. (2013). The Data Warehouse Toolkit (3.ra. ed.). Estados Unidos: Wiley Publishing. Laudon Kenneth, L. J. P. (2004). Sistemas de Información Gerencial: administración de la empresa digital (8.va ed.). México: Pearson Educación. López Gutiérrez, M. (2004, 30 de abril). El lugar de los DSS en el proceso de toma de decisión. GestioPolis [post de la web]. Recuperado de https://web.archive.org/web/20100418185043/https://www.gestiopolis.com/canales2/gerencia/1/ddsmlopez.htm Parr Rud, O. (2009). Business Intelligence Success Factors: Tools for Aligning Your Business in the Global Economy. New Jersey, Estados Unidos: John Wiley & Sons. White, N. (2019). Business The History Of Business Intelligence (Infographic). Recuperado de https://businesscomputingworld.co.uk/the-history-of-business-intelligence-infographic/ Bloque 1Bloque 2Bloque 3Bloque 4Referencias CIF 1. Niveles de datos De acuerdo con William Inmon (2005), podemos diferenciar cuatro niveles de datos: Nivel operacional. Nivel atómico (o data warehouse). Nivel departamental (o data mart, OLAP o multidimensional). Nivel individual. Estos niveles son la base del concepto del corporate information factory (CIF). A continuación, describiremos las principales características de cada uno de estos niveles: ☰ Nivel operacional El nivel operacional de datos mantiene solamente datos primitivos (es decir, operacionales, transaccionales), orientados a la aplicación y sirve específicamente a la comunidad de usuarios de procesamiento OLTP, que requiere alta performance. En este nivel, por lo general, no se mantienen registros históricos, ya que los datos se actualizan y los valores anteriores se pierden. ☰ Nivel del data warehouse El nivel de datos atómico o de data warehouse mantiene datos primitivos pero históricos e integrados que no pueden actualizarse, además de algunos datos derivados/analíticos. ☰ Nivel departamental El nivel de datos departamental contiene datos derivados que son formateados especialmente en función de los requerimientos de análisis de datos de los usuarios, ajustados a las necesidades de un departamento de la organización en particular. ☰ Nivel individual El nivel de datos individual es donde mayor análisis heurístico se realiza. Generalmente, aquí hay datos temporales. Como regla general, típicamente los sistemas de información ejecutivos (EIS, por sus siglas en inglés) procesan datos a este nivel y corren sobre una PC. Figura 1: Niveles de datos Fuente: elaboración propia con base en Inmon, 2005, p. 16. Componentes del CIF Resulta evidente que los tipos de consultas que se pueden efectuar en cada nivel de datos son distintos. Así, los diferentes niveles de datos requieren un conjunto de entidades arquitectónicas diferenciadas. Estas entidades constituyen el corporate information factory (CIF). El CIF es un concepto que hace referencia al conjunto de todas las estructuras de datos que posee una determinada organización (por ejemplo, bases de datos transaccionales y analíticas) junto con todos aquellos procesos y herramientas utilizados en las distintas etapas para poder generar información y lograr que esta se encuentre disponible en tiempo y forma para todos los niveles de la organización. Como señalan Cano (2007), Inmon (2005) y Kimball (2013), los distintos componentes del CIF y, por ende, de una solución de BI, son los siguientes: Fuentes de información. Procesos ETL de extracción, transformación y carga de datos en el data warehouse. Data warehouse. Data mart. Repositorio de metadatos. Operational data store (ODS). Exploration warehouse. Data mining warehouse. Herramientas de business intelligence para la visualización y explotación de datos. (Cabe aclarar que no siempre encontraremos todos ellos). En el siguiente gráfico, podemos ver estos componentes del CIF y las relaciones entre ellos: Figura 2: Componentes del CIF Fuente: Cano, 2007, p. 93 2. Fuentes de información Josep Lluís Cano (2007) indica que las fuentes de información hacen referencia a los lugares (como las bases de datos) de donde se extraerán los datos para alimentar el data warehouse. Principales fuentes de datos Estas son las principales fuentes de información: Bases de datos de cada uno de los sistemas operacionales/transaccionales, que pueden incluir tanto aplicaciones desarrolladas a la medida de la organización como productos “enlatados” o grandes sistemas corporativos, por ejemplo, los sistemas de gestión de las relaciones con los clientes (CRM, por sus siglas en inglés —customer relationship management—), los sistemas de gestión financiera y planificación de recursos empresariales (ERP, por sus siglas en inglés —enterprise resource planning—), sistemas de gestión de la cadena de abastecimiento (en inglés, supply chain management) y sistemas de gestión de recursos humanos o del capital humano (HCM, por sus siglas en inglés —human capital management—), entre otros. Sistemas de información departamentales, muchas veces basados en planillas de cálculo Excel. Fuentes de información correspondientes a bases de datos externas a la empresa, que, en algunos casos, pueden haber sido compradas a terceras organizaciones, como consultoras de investigación de mercado. Las fuentes de información externas son fundamentales para enriquecer la información que tenemos de los clientes. En algunos casos, es interesante incorporar información referente, por ejemplo, la población y el número de habitantes. Podemos acceder a información de este tipo en el sitio web del Instituto Nacional de Estadísticas. Sin embargo, también existen otras fuentes de información de las cuales se pueden obtener datos según las necesidades. A continuación, algunas de estas: Otras fuentes de Internet: Muchas veces, es necesario hacer comparaciones en los indicadores con otras compañías u organizaciones; es lo que se denomina benchmarking. Esto es fundamental, dado que, para saber si determinado valor es bueno o malo (que, en realidad, se trata de un valor relativo al modo en que les va a otras empresas) pueden obtenerse datos públicos de Internet e incorporarlos al data warehouse. Datos aportados por analistas expertos, especializados en alguna temática en particular. (Otros). Factores que se deben considerar Según Josep Lluís Cano (2007), hay distintos factores complejidad de la carga de información; entre ellos, el autor fuentes diferentes de información, teniendo en cuenta corporaciones es natural hablar de una media de 8 bases incluso, a 50. que contribuyen a la destaca la cantidad de que en las grandes de datos hasta llegar, A medida que se torna necesario acceder a un número creciente de fuentes de información, se incrementa notablemente la complejidad de todo proyecto de creación de un data warehouse, pues es probable que algunas bases de datos estén en SQL Server, otras en Oracle, otras en IBM DB2, etcétera, además de la propia complicación inherente al modelo de datos subyacente de cada aplicación. Otro problema deviene de la falta de documentación de estas bases de datos, correspondientes, en muchas ocasiones, a aplicaciones que han sido modificadas a lo largo de los años por distintos programadores sin seguir ningún tipo de estándares y con criterios sumamente heterogéneos. La información que cargamos en un Data Warehouse normalmente es estructurada, es decir, aquella que se puede almacenar en tablas: en la mayoría de los casos es información numérica. Cada vez más, la tecnología nos permite trabajar con información no estructurada, y se espera que este tipo de información sea cada vez más importante. Dentro de la información no estructurada tenemos: correos electrónicos, cartas, informes, videos, etc. (Cano, 2007, pp. 96-97). Calidad de datos Cano (2007) enuncia que, una vez que ya se han establecido cuáles serán las fuentes de información, debe procederse a verificar la calidad de los datos del data warehouse, lo cual constituye un aspecto esencial. Consecuentemente, es necesario asegurar que la calidad de los datos es máxima. Si en el Data Warehouse hay errores, éstos [sic] se propagarán a lo largo de toda la organización y son muy difíciles de localizar. Además, pueden ocasionar que se tomen decisiones erróneas que afecten a los resultados de la organización. Los costes derivados de que la calidad de los datos no sea la correcta pueden llegar a ser muy elevados. (Cano, 2007, p. 98) Por otro lado, el autor también afirma lo siguiente: Asumir que la calidad de los datos es buena puede ser un error fatal en los proyectos de Business Intelligence. Normalmente, cuando se construye un Data Warehouse la mayoría de las organizaciones se focalizan en identificar los datos que necesitan analizar, los extraen y los cargan en el Data Warehouse. Generalmente no se piensa en la calidad de los datos, permitiendo que los errores sean cargados al Data Warehouse. Debería por tanto establecerse un control o conjunto de controles en el proyecto que localizara los errores en los datos y no permitiera la carga de los mismos. Las comprobaciones se deberán llevar a cabo, de forma manual o automatizada, teniendo en cuenta distintos niveles de detalle y variando los periodos de tiempo, comprobando que los datos cargados coinciden con los de las fuentes de datos origen. En algunos casos se detectan errores que se originan por fallos en los sistemas transaccionales, lo que debería provocar proyectos de mejora en los mismos. Muchos de estos casos se deben a que los usuarios pueden introducir datos sin ningún tipo de control. Siempre que se pueda, es recomendable que los usuarios elijan entre distintos valores, en lugar de introducirlos libremente ellos. No es una buena opción corregirlos en el proceso ETL y no modificar las aplicaciones origen. Esta alternativa es mucho más rápida inicialmente, pero mucho más costosa a largo plazo. Los errores también se pueden producir, por ejemplo, en el proceso de ETL o al integrarlos en el Data Warehouse. (Cano, 2007, p. 99) Respecto de la responsabilidad de la calidad de los datos, Cano determina que esta no pertenece sólo [sic] a los departamentos de tecnología: Debe asumirse la parte correspondiente en cada uno de los propietarios de los procesos y de las aplicaciones que los soportan. Desde el proyecto debemos velar por la calidad de los datos, puesto que si la calidad no es la adecuada nunca podremos obtener los beneficios esperados del proyecto. Debemos entender que la problemática de la calidad de datos no es un problema de los departamentos de tecnología, sino un problema estratégico al que debemos asignar objetivos, recursos y planificación. (2007, p. 100) Finalmente, las principales características que deben satisfacer los datos para que alcancen un nivel de calidad elevado son la siguientes: 1. Precisión: ¿Representan los datos con precisión una realidad o una fuente de datos que se pueda verificar? 2. Integridad: ¿Se mantiene constantemente la estructura de los datos y las relaciones a través de las entidades y los atributos? 3. Coherencia: ¿Son los elementos de datos constantemente definidos y comprendidos? 4. Totalidad: ¿Están todos los datos necesarios? 5. Validez: ¿Son los valores aceptables en los rangos definidos por el negocio? 6. Disponibilidad: ¿Están los datos disponibles cuando se necesitan? 7. Accesibilidad: ¿Se puede acceder a los datos fácil y comprensiblemente? (Cano, 2007, p. 102). 3. Procesos de Extracción, Transformación y Carga Concepto de ETL El ETL se trata del proceso correspondiente a La extracción, transformación y carga de los datos en el Data Warehouse. Antes de almacenar los datos en un Data Warehouse, éstos [sic] deben ser transformados, limpiados, filtrados y redefinidos. Normalmente, la información que tenemos en los sistemas transaccionales no está preparada para la toma de decisiones. (Cano, 2007, pp. 93-94). Es decir, es el proceso que consiste en extraer información de las fuentes de datos, transformarla, recodificarla, limpiarla, explicitar reglas de negocio ocultas, formatearla y organizarla de manera que sea posible incorporarla en el data warehouse. A estos procesos se los conoce con la sigla ETL (por sus siglas en inglés ─Extract, Transform and Load─). De acuerdo con Inmon (2005), el proceso ETL se encarga de transferir datos desde el entorno operacional al entorno del data warehouse, integrando las distintas fuentes de información. Proceso ETL en el proyecto de BI El diseño de los procesos ETL insume gran parte del tiempo de un proyecto BI, pues se trata de una tarea compleja. Para poder aprovechar los beneficios del data warehouse, es fundamental lograr la integración de datos desde los distintos orígenes. Josep Lluís Cano señala que “el proceso de ETL consume entre el 60 % y el 80 % del tiempo de un proyecto de Business Intelligence, por lo que es un proceso clave en la vida de todo proyecto” (2007, p. 103). Pasos del proceso ETL El proceso ETL se divide en cinco subprocesos: 1. Extracción: Este proceso recupera los datos físicamente de las distintas fuentes de información. En este momento disponemos de los datos en bruto. 2. Limpieza: Este proceso recupera los datos en bruto y comprueba su calidad, elimina los duplicados y, cuando es posible, corrige los valores erróneos y completa los valores vacíos, es decir se transforman los datos -siempre que sea posible- para reducir los errores de carga. En este momento disponemos de datos limpios y de alta calidad. 3. Transformación: Este proceso recupera los datos limpios y de alta calidad y los estructura y sumariza en los distintos modelos de análisis. El resultado de este proceso es la obtención de datos limpios, consistentes, sumarizados y útiles. 4. Integración: Este proceso valida que los datos que cargamos en el Data Warehouse son consistentes con las definiciones y formatos del Data Warehouse; los integra en los distintos modelos de las distintas áreas de negocio que hemos definido en el mismo. Estos procesos pueden ser complejos. 5. Actualización: Este proceso es el que nos permite añadir los nuevos datos al Data Warehouse. (Cano, 2007, pp. 104-105) Problema de integración de datos De acuerdo con William Inmon (2005), se extraen datos desde distintas fuentes/sistemas/aplicaciones, datos que no están integrados; incluirlos en el data warehouse sin integrarlos sería un gran error. Ocurre que, cuando esos sistemas fueron diseñados, nadie pensó en futuras integraciones. Cada una tuvo sus propios requerimientos. Por lo tanto, extraer datos de distintos lugares e integrarlos en una base de datos única es un problema complejo. Figura 3: Problema de integración de datos Fuente: elaboración propia con base en Inmon, 2005, p. 73. A continuación, algunos ejemplos de falta de integración que comúnmente podemos encontrar: Valores que se encuentran codificados de manera distinta. Valores con distintas unidades de medida. Campos que tienen distintos nombres, pero representan lo mismo. Formatos diferentes. Eficiencia en el acceso a los sistemas transaccionales William Inmon (2005) destaca, sin embargo, que la integración no es la única dificultad en la transformación de datos desde los sistemas transaccionales: otro problema es la eficiencia en el acceso a los datos de los sistemas existentes. No tiene sentido cargar todos los datos de los sistemas operacionales en el data warehouse cada vez que hay una extracción. Podemos identificar, entonces, tres tipos de carga en el data warehouse: Datos antiguos, archivados (carga única, de una sola vez). Datos actualmente contenidos en el entorno operacional. Cambios continuos al data warehouse a partir de cambios (actualizaciones) que ocurrieron en los sistemas operacionales desde la última actualización. (Esto presenta el mayor desafío para un arquitecto de datos, puesto que no es fácil identificar dichos cambios). Según William Inmon (2005), existen cinco técnicas que comúnmente se usan para limitar la cantidad de datos operacionales extraídos: Hacerlo a través de un archivo delta que contenga solo los cambios hechos en una aplicación como resultado de las transacciones ejecutadas sobre las bases de datos operacionales. El proceso es muy eficiente, pero muy pocas aplicaciones cuentan con un archivo delta. Extraer los datos que tienen marca temporal en las bases de datos operacionales. Solo se traen los datos desde la última fecha y hora de actualización. Escanear un archivo log (similar al archivo delta, pero con mayor información). Modificar el código de la aplicación. Tomar una imagen o snapshot de la base de datos operacional, antes y después de cada extracción; luego, se comparan ambas versiones para identificar las diferencias. Desafíos en los procesos ETL De acuerdo con William Inmon (2005), los procesos ETL encaran varios desafíos complejos: Cambio de tecnología para la extracción de datos desde los sistemas transaccionales hasta el data warehouse (por ejemplo, leer desde una base de datos Microsoft SQL Server y cargar un data warehouse en Oracle), tarea que puede volverse muy compleja. Reestructuración y conversión de los campos claves en las bases de datos operacionales antes de escribirlos en el data warehouse. Reformateo de campos no claves como, por ejemplo, el formato de las fechas. Limpieza de datos (formato, verificación de clave foránea, etc.), a medida que se introducen en el data warehouse. Consolidación de datos de distintas fuentes. Provisión de valores por default. Sumarización de datos. Renombre de datos. Conversiones en los formatos de datos. Registro de cantidad de datos extraídos, transformados y cargados en el data warehouse (tema clave de auditoría/metadatos cuando se cargan grandes volúmenes de datos). (Otros). Enterprise data warehouse El data warehouse es el núcleo del CFI; contiene datos históricos, integrados, de toda la organización, generalmente con alto nivel de detalle (granularidad), actualizado a partir de los procesos ETL. Además, es una colección de información corporativa que alimenta otras estructuras de datos como data marts, exploration warehouses, data mining warehouses, operational data stores (ODS), en definitiva, construidos con el objetivo de ser explotados por diferentes sistemas de soporte de decisión (DSS). Para William Inmon (2005), el data warehouse está en el corazón del CIF y es el fundamento de todo DSS. Por diversas razones (implicancias en performance, integración y transformación de datos, entre otras), es conveniente que los sistemas DSS realicen las consultas analíticas sobre un data warehouse aislado de las bases de datos operacionales. La aparición de los data warehouse o almacenes de datos es la respuesta a las necesidades de los usuarios que necesitan información consistente, integrada, histórica y preparada para ser analizada y poder tomar decisiones. Al recuperar la información de los distintos sistemas, tanto transaccionales como departamentales o externos, y almacenándolos en un entorno integrado de información diseñado por los usuarios, el Data Warehouse nos permitirá analizar la información contextualmente y relacionada dentro de la organización. (Cano, 2007, p. 113) Según William Inmon (2005), estas son las características más importantes de un data warehouse: Orientado a una materia o área de interés: los sistemas transaccionales se organizan alrededor de las aplicaciones funcionales de la organización; por ejemplo, para una compañía de seguros las aplicaciones pueden darse para el procesamiento de seguros de autos, vida, casa, salud, etcétera. Cada tipo de empresa tiene sus propias áreas de interés (dos de las áreas principales de interés pueden ser Cliente y Póliza). A su vez, cada área de interés está físicamente implementada como una serie de tablas relacionadas en el data warehouse. Por ejemplo, para el Área Clientes, podría haber una tabla con todos los clientes de la empresa y varias tablas con la actividad de estos clientes, algunas con los eventos detallados y otras con sumarizaciones o agregaciones (como cantidad de transacciones realizadas por mes, promedio de accidentes por año, entre otros datos); todas las tablas estarán relacionadas por el ID del cliente. Integrado: de todos los aspectos del data warehouse, este es el más importante. Los datos provienen de múltiples orígenes. Antes de insertarse, se convierten, reformatean, e incluso pueden sumarizarse. Dado que cada aplicación en su momento fue desarrollada en forma aislada, sin tener en cuenta futuras integraciones, usualmente se encuentran inconsistencias de datos entre los distintos orígenes o bases de datos, a nivel de nomenclatura, codificación, atributos físicos, unidad de medida, entre otros. No volátil: los datos operacionales son generalmente accedidos y manipulados de a un registro por vez. Los datos operacionales son actualizados regularmente, no así en el data warehouse, donde los datos se cargan (por lo general, en forma masiva) en un formato estático o snapshot y se consultan, pero no se actualizan. Cuando hay un cambio en los sistemas transaccionales, en el data Warehouse se graba un nuevo registro o snapshot; esto permite tener un registro histórico de datos. Variable con el tiempo: esto implica que cada unidad de datos en el data warehouse es precisa y en un momento dado. Generalmente, cada registro está asociado a una fecha de transacción en particular o a una marca de tiempo. Habitualmente, el data warehouse tiene un horizonte de tiempo almacenado de 5 a 10 años, aunque a veces puede extenderse mucho más. En cambio, las bases de datos transaccionales contienen datos de valor actual, es decir, datos cuya precisión solo es válida en el momento en que se consulta o se accede. Por ejemplo, un banco sabe exactamente cuánto dinero tiene un cliente en su cuenta hoy; este valor se actualiza cada vez que hay un depósito o una extracción. En el data warehouse, la serie de snapshots provee una secuencia histórica de actividades y eventos; la estructura clave de los datos operacionales puede o no contener un elemento de tiempo como año, mes o día, pero el data warehouse siempre contiene algún elemento de tiempo. Data mart William Inmon (2005) sostiene que un data mart es una estructura de datos que está dedicada a servir las necesidades analíticas de un grupo de personas, como el Departamento de Finanzas, por ejemplo. El trabajo de construir un Data Warehouse corporativo puede generar inflexibilidades, o ser costoso y requerir plazos de tiempo que las organizaciones no están dispuestos a aceptar. En parte, estas razones originaron la aparición de los Data Mart. Los Data Mart están dirigidos a una comunidad de usuarios dentro de la organización, que puede estar formada por los miembros de un departamento, o por los usuarios de un determinado nivel organizativo, o por un grupo de trabajo multidisciplinar con objetivos comunes. Los Data Mart almacenan información de un número limitado de áreas; por ejemplo, pueden ser de marketing y ventas o de producción. Normalmente se definen para responder a usos muy concretos. Normalmente, los Data Mart son más pequeños que los Data Warehouses. Tienen menos cantidad de información, menos modelos de negocio y son utilizados por un número inferior de usuarios. Los Data Mart pueden ser independientes o dependientes. Los primeros son alimentados directamente de los orígenes de información, mientras que los segundos se alimentan desde el Data Warehouse corporativo. Los Data Mart independientes pueden perpetuar el problema de los “silos de información” y en su evolución pueden llegar a generar inconsistencias con otros Data Mart. (Cano, 2007, pp. 117-118) Repositorio de metadatos Según Inmon (2005), el repositorio de metadatos es un componente central del data warehouse, dado que le permite al usuario final de un DSS navegar entre distintas posibilidades. Cuando el usuario se acerca a un data warehouse sin metadatos, no sabe dónde iniciar su análisis ni cómo encontrar los datos correctos, y si los encuentra, no sabe cómo interpretarlos. Con la ayuda de metadatos, el usuario puede ir rápidamente a los datos principales. Así, los metadatos actúan como un índice de los contenidos del data warehouse. Generalmente, estos repositorios almacenan el seguimiento de los siguientes elementos: Estructuras de datos importantes para un desarrollador. Estructuras de datos importantes para un analista de BI. Fuentes de datos que alimentan el data warehouse. Transformación de datos en el wata warehouse. Modelo de datos. Relaciones entre el modelo de datos y el data warehouse. Historia de extracciones (ejecuciones de los procesos ETL). Josep Lluís Cano declara lo siguiente: Un componente crítico de un Data Warehouse es el Metadata. El Metadata es el repositorio central de información de la información. Nos da el significado de cada uno de los componentes y sus atributos que residen en el Data Warehouse (o Data Mart). La información que contiene el Metadata es útil para los departamentos de tecnología y los propios usuarios. Puede incluir definiciones de negocio, descripciones detalladas de los tipos de datos, formatos y otras características. La construcción del Metadata supone que se defina el significado de cada una de las tablas y cada uno de los atributos que se cargan en el Data Warehouse. Este es un punto complejo de todo proyecto, ya que obliga a que se definan los conceptos de negocio y se homogeneicen entre los distintos departamentos, filiales, etc. Obliga a que todos los componentes de la organización hablen utilizando la misma terminología y con el mismo significado, lo cual no siempre es sencillo. Cuando alguien hable de “margen bruto” o “margen de contribución” deberá estar absolutamente definido para la organización. Evidentemente, organizaciones distintas tendrán normalmente definiciones distintas. (Cano, 2007, pp. 120-121) En el siguiente gráfico, podemos ver distintos aspectos involucrados al repositorio de metadatos: Figura 4: Repositorio de metadatos Fuente: elaboración propia. Operational data store (ODS) El ODS, como estructura de datos, da soporte a la toma de decisiones operativas, rutinarias y diarias de los niveles más bajos de la organización. De acuerdo con William Inmon (2005), con los ODS fue posible hacer procesamiento en tiempo real contra datos integrados. Estos componentes tecnológicos a veces se confunden con los data warehouses. Los ODS son una extensión de la tecnología de los data warehouses. Los ODS consolidan datos de múltiples fuentes provenientes de distintos sistemas de información no integrados y facilitan un acceso online integrado sobre esa información. Su objetivo es proporcionar información integrada, con el fin de facilitar la toma de decisiones en entornos operacionales. Algunas veces se utilizan para evitar integraciones o implementaciones de soluciones ERP. La información que reside en los ODS es volátil y normalmente tiene, como máximo, una antigüedad de dos o tres meses. La principal diferencia con los Data Warehouses es que los datos de los ODS son volátiles y se actualizan en tiempo real. Los ODS habitualmente se convierten en una fuente de datos para el Data Warehouse. (Cano, 2007, pp. 121-122) Clases de ODS Siguiendo a William Inmon (2005), enunciamos a continuación cuatro clases de ODS cuya clasificación depende de la rapidez con que llegan los datos a la estructura del ODS: Clase I, donde las actualizaciones de datos desde los sistemas transaccionales hacia el ODS son síncronas. En general, podemos hablar de que pasan milisegundos entre una actualización en el entorno operacional y en el ODS; el usuario, por lo tanto, no se da cuenta de la diferencia entre un esquema y el otro. Esta clase de ODS es cara y tecnológicamente desafiante; casi nunca se justifica económicamente. Por lo general, se opta simplemente por pasar datos del entorno operacional al ODS sin integrarlos. Clase II, donde las actualizaciones ocurren dentro de un marco temporal de 2 a 3 horas. Esta clase de ODS es común. El mayor tiempo de sincronización permite la integración de los datos, es decir, que se ejecuten procesos ETL con mayor nivel de procesamiento y transformación de datos. Clase III, donde la sincronización de las actualizaciones se produce cada 24 horas, generalmente de noche. Es similar a la clase II, aunque tiene una implementación marcadamente más económica. Clase IV, donde las actualizaciones del ODS se dan con frecuencia a partir del data warehouse, pero no están calendarizadas. Es decir, existe un largo período de tiempo (a veces, hasta años) entre la coordinación del ODS y su fuente. Habitualmente, la fuente aquí es el data warehouse, aunque puede provenir de otras fuentes. De acuerdo con William Inmon (2005), un data warehouse nunca puede accederse en milisegundos. Debido a la naturaleza de sus datos, no está preparado para soportar procesos de tipo OLTP. Sin embargo, poder obtener tiempos de respuestas tan óptimos es algo muy valioso. Cuando se requieren tiempos de respuesta óptimos y a su vez debe accederse a datos integrados, consolidados en una plataforma BI, hay que emplear el ODS, que es el repositorio para procesamiento de alta performance. A diferencia del data warehouse, el ODS es opcional. Así, ambas estructuras son complementarias, ya que las dos residen fuera del entorno operacional, soportan procesamiento DSS o BI y usan datos integrados. Además, los flujos de datos entre ambos son bidireccionales. En algunas situaciones, el ODS alimenta el data warehouse; en otras, el data warehouse alimenta el ODS. Sin embargo, a diferencia del wata Warehouse, el ODS está diseñado para procesamiento en tiempo real. Las actualizaciones de datos en el ODS son normales, a diferencia del data warehouse, donde la foto histórica siempre queda. Es decir, mientras en el data warehouse se almacenan valores históricos, en el ODS se almacenan valores actuales; esto implica que las aplicaciones BI que necesitan visualizar datos actuales corren sobre el ODS y no sobre el data warehouse. Generalmente, un ODS no contiene más de un mes de histórico. El diseño del ODS sigue un modelo híbrido: puede hacerse siguiendo modelo relacional en una parte y multidimensional en otra parte; dependerá de los requerimientos en cuanto a flexibilidad y performance. El ODS suele contar con un volumen de datos muy inferior al data warehouse. Exploration warehouse William Inmon (2005) explica que el exploration warehouse es una forma especial de data warehouse. El objetivo de esta estructura consiste en proporcionar un fundamento para el análisis estadístico “pesado”. Una vez construido, se pueden ejecutar sobre él análisis estadísticos sin problemas, ya que estarán en una máquina separada de donde ocurre el procesamiento regular del data warehouse. Es decir, el exploration warehouse permite satisfacer requerimientos de procesamiento temporal y desestructurado con altas velocidades de respuesta. Otro dato que tiene lugar en la creación de un exploration warehouse es el siguiente: la tecnología de análisis estadístico es tan diferente de otros estilos de análisis, que tiene sentido ejecutarla sobre entornos separados. Además, en cuanto al diseño de bases de datos, el exploration warehouse casi nunca es una copia directa de los datos encontrados en el data warehouse: en lugar de ello, el exploration warehouse inicia con un subconjunto de los datos del data warehouse; incluso, pueden agregarse algunos campos precalculados. Debido a la naturaleza de los requerimientos de explotación, sus datos se encuentran también altamente indexados. Los exploration warehouses, por lo general, están enfocados en proyectos; es decir, una vez terminado un proyecto, desaparecen. Por lo tanto, tienen una existencia transitoria, a diferencia de un data warehouse, que es de vida permanente. Además, en contraposición a un data warehouse, en ocasiones se puede “congelar” la información, sin actualizarla con los datos más nuevos. Puesto que se prueban distintos algoritmos, conviene hacerlo sobre los mismos datos, sin actualizarlos con tanta frecuencia. En algunas situaciones, el exploration warehouse puede estar asociado con el data mining warehouse. Data mining warehouse De acuerdo con William Inmon (2005), un data mining warehouse es similar en diversos aspectos a un exploration warehouse, pero guardan algunas diferencias: El objetivo primario de un exploration warehouse es la creación de afirmaciones, hipótesis y observaciones. Un data mining warehouse, en cambio, tiene el objetivo de probar dichas hipótesis. Un exploration warehouse está optimizado en amplitud de información, mientras que el data mining warehouse está optimizado en profundidad de información. No obstante, dado que las diferencias son sutiles, salvo en grandes corporaciones, pueden estar bajo la misma estructura. Hay que tener en cuenta que se trata de un almacén de datos creado específicamente para contener las entradas y las salidas de los procesos de data mining, de manera que no interfieran ni con los sistemas operacionales ni con los DSS. 4. Herramientas de business intelligence Las principales herramientas de business intelligence son las siguientes: Generadores de reportes/informes: utilizados por desarrolladores profesionales para crear informes estándar para grupos, departamentos o la organización. Herramientas de Usuario Final de Consultas e Informes (Query & Reporting): empleadas por usuarios finales para crear informes para ellos mismos o para otros; no requieren programación. Herramientas OLAP: permiten a los usuarios finales tratar la información de forma multidimensional para explorarla desde distintas perspectivas y periodos de tiempo. Herramientas de dashboard y scorecard: permiten a los usuarios finales ver información crítica para el rendimiento con un simple vistazo, utilizando iconos gráficos y con la posibilidad de ver más detalle para analizar información detallada e informes si así lo desean. Herramientas de planificación, modelización y consolidación: permiten a los analistas y a los usuarios finales crear planes de negocio y simulaciones con la información de Business Intelligence. Se utilizan para elaborar la planificación, los presupuestos, las previsiones. Estas herramientas proveen a los dashboards y los scorecards con los objetivos y los umbrales de las métricas. Herramientas de Data Mining: Permiten a estadísticos o analistas de negocio crear modelos estadísticos de las actividades de los negocios. Data Mining es el proceso para descubrir e interpretar patrones desconocidos en la información mediante los cuales resolver problemas de negocio. Los usos más habituales del Data Mining son: segmentación, venta cruzada, sendas de consumo, clasificación, previsiones, optimizaciones, entre otros. (Cano, 2007, pp. 132-133) Herramientas OLAP Josep Lluís Cano explica que “existen distintas tecnologías que nos permiten analizar la información que reside en un Data Warehouse, pero la más extendida es el OLAP” (2007, p. 125). El autor también afirma que los usuarios necesitan analizar información a distintos niveles de agregación y sobre múltiples dimensiones: Por ejemplo, ventas de productos por zona de ventas, por tiempo, por clientes o tipo de cliente y por región geográfica. Los usuarios pueden hacer este análisis al máximo nivel de agregación o al máximo nivel de detalle. OLAP provee de estas funcionalidades y algunas más, con la flexibilidad necesaria para descubrir las relaciones y las tendencias que otras herramientas menos flexibles no pueden aportar. A estos tipos de análisis les llamamos multidimensionales, porque nos facilitan el análisis de un hecho desde distintas perspectivas o dimensiones. Esta es la forma natural que se aplica para analizar la información por parte de los tomadores de decisiones, ya que los modelos de negocio normalmente son multidimensionales. (Cano, 2007, p. 126) Generalmente, al hablar de análisis multidimensional u OLAP (online analytical processing) pensamos en un cubo, puesto que es la representación gráfica habitual de este. Como puede verse en el siguiente ejemplo de Cano, tenemos un cubo con la cantidad de unidades vendidas de cada uno de los libros (libro 1, libro 2 y libro 3), para cada uno de los clientes (cliente 1, cliente 2 y cliente 3) y en cada uno de los distintos años (año 1, año 2 y año 3): Figura 5: Cubo OLAP Fuente: Cano, 2007, p. 127 En el ejemplo anterior, la cantidad de unidades vendidas de cada uno de los libros por cliente y por año es lo que se denomina “hecho”. A su vez, las dimensiones son las siguientes: Clientes. Libros. Años (Tiempo). Incluso, una dimensión dada puede tener una jerarquía específica. Por ejemplo, generalmente, la dimensión Tiempo tiene una jerarquía de estos tipos: Año. Mes. Día. Sin embargo, según el modelo de negocio, puede que se requiera el análisis por semestre, trimestre, semana, intervalos horarios, día de la semana. Por otra parte, las herramientas OLAP permiten llevar a cabo diferentes operaciones sobre los cubos: Slice. Dice. Roll-Up. Drill-Down. Roll-Across. Drill-Across. Pivot. Herramientas de visualización por lógica asociativa Según Josep Lluís Cano, “una alternativa al OLAP son las herramientas que utilizan consultas de lógica asociativa” (2007, p. 131). En este tipo de herramientas, cuando se hace una consulta, se accede directamente a los datos (ya sea de la base de datos transaccional o al data warehouse preferentemente) pero sin diseñar un cubo, sin dimensiones ni jerarquías predefinidas y sin restricciones en cuanto al volumen de información. El modelo de almacenamiento interno proporciona una visión “vertical” (basada en columnas) de los datos, así como una visión “horizontal ampliada” (basado en filas) que va más allá de la tecnología de bases de datos relacionales. Cada columna almacena cada valor diferente de forma separada con la frecuencia y usos de cada valor. Las consultas son altamente eficientes por el nuevo modelo de almacenamiento y el conjunto de operaciones utilizados para resolver las consultas. Se indexan automáticamente el 100% de los datos y se eliminan automáticamente los datos redundantes y los valores nulos, lo que significa un menor uso de espacio de disco y menores tiempos de escritura y lectura. (Cano, 2007, p. 132) Este tipo de herramientas ha tenido un gran auge en los últimos años, en detrimento de las soluciones OLAP, puesto que las primeras reducen drásticamente los tiempos de desarrollo e implementación de una solución BI. Referencias Cano, J. L. (2007). Business Intelligence: Competir con Información. España: Banesto Fundación Cultural y ESADE. Inmon, W. (2005). Building the Data Warehouse (4.ra. ed.). Estados Unidos: Wiley Publishing. Kimball, R. (2013). The Data Warehouse Toolkit (3.ra. ed.). Estados Unidos: Wiley Publishing. Bloque 1Bloque 2Bloque 3Bloque 4Referencias Data warehouse 1. Data warehouse: definición “Un Data Warehouse es una colección de información creada para soportar las aplicaciones de toma de decisiones” (Cano, 2007, p. 114). En el módulo 1 definimos el data warehouse o almacén de datos como el componente central dentro del corporate information factory (CIF) y, en general, de toda solución de business intelligence (BI). A continuación, analizaremos dos aspectos fundamentales en la construcción de un data warehouse: Granularidad Particionamiento Granularidad De acuerdo con William Inmon (2005), el aspecto más importante en el diseño de un data warehouse es la granularidad, es decir, el nivel de detalle o sumarización de las unidades de datos dentro del data warehouse. Mientras más detalle tenga el data warehouse, más bajo será el nivel de granularidad; a menor detalle, mayor nivel de granularidad. Por ejemplo, una única transacción estaría en el nivel más bajo de granularidad, mientras que un resumen de todas las transacciones realizadas durante el mes en curso estaría en un nivel más alto de granularidad. En los sistemas operacionales/transaccionales, en las bases de datos, siempre se almacena un bajo nivel de granularidad, es decir, máximo detalle. Sin embargo, en el data warehouse, aunque es recomendable, no siempre es así. Se dice que la granularidad es el principal aspecto de diseño de un data warehouse debido a que afecta profundamente el volumen de datos general que reside en el data warehouse y el tipo de consultas que se pueden ejecutar. Mientras más bajo sea el nivel de granularidad, más versátil será el data warehouse a la hora de responder distintos tipos de consultas. Figura 1: Granularidad Fuente: Elaboración propia con base en Inmon, 2005, p. 42 Según William Inmon (2005), los beneficios de un bajo nivel de granularidad son los siguientes: Los datos granulares del data warehouse son la clave para la responsabilidad, dado que pueden ser usados por distintas personas y de diversas maneras (un usuario quizás quiera ver los datos sumarizados por mes, otro por año, otro por región geográfica, entre otras dimensiones posibles). Brinda la capacidad para conciliar datos. Si hay discrepancias entre dos o más departamentos sobre un determinado valor de una métrica o cálculo, existe un sólido y único fundamento detallado sobre el cual indagar. Tiene la flexibilidad para formatear los datos según las necesidades de los usuarios de distintos departamentos. Contiene una historia detallada de las actividades y eventos de la corporación. Permite acomodarse a los requerimientos futuros. Con un data warehouse de bajo nivel de granularidad, se logra mejorar sustancialmente la adaptación al cambio frente a nuevos requerimientos. Este es el principal beneficio. Permite, además, responder con precisión a determinadas consultas o requerimientos, lo cual no podría ser posible si los datos estuvieran sumarizados. Permite la construcción de data marts o tablas sumarizadas a partir de los datos detallados. Permite la optimización de los procesos de visualización/exploración y data mining, que requieren de datos detallados e históricos para descubrir patrones ocultos en los datos. Niveles duales de granularidad y tablas sumarizadas Sin embargo, William Inmon (2005) destaca que cuando una organización tiene gran necesidad de eficiencia en el almacenamiento y acceso a los datos, y, a la vez, precisa contar con la capacidad de analizar datos en detalle sobre un data warehouse de gran volumen de datos, debería considerarse la posibilidad de contar con dos o más niveles de granularidad en simultáneo. De esta manera, podemos tener una tabla detallada y una o más tablas sumarizadas que favorezcan determinadas consultas porque ya están precalculadas; es decir, además de contar con una estructura de tablas con todos los registros históricos detallados, es importante contar también con tablas que sumaricen esos registros para facilitar las consultas y mejorar la performance de las aplicaciones DSS que usen el data warehouse como fuente. Estas tablas sumarizadas tienen, notoriamente, menos registros. Según William Inmon (2005), hay que tener en cuenta que aproximadamente el 95 % del procesamiento de un DSS corre sobre datos sumarizados y que solo un 5 % corre sobre datos detallados (esto se debe a que, por lo general, los directivos de una organización están interesados en conocer los grandes números, por ejemplo, la situación de las ventas, y no el detalle completo de cada transacción en particular). Por lo tanto, contar con niveles duales de granularidad puede permitir procesar la mayoría de los requerimientos de manera eficiente, accediendo generalmente a la tabla sumarizada y solo en casos puntuales a los casos detallados. En función de esto, Inmon (2005) explica que tener niveles duales de granularidad es la mejor opción arquitectónica para un data warehouse. Particionamiento De acuerdo con William Inmon (2005), después de la granularidad, el segundo aspecto importante en el diseño de un data warehouse es el particionamiento, el cual se refiere a la división o partición de los datos en tablas o unidades físicas separadas que pueden ser manejadas independientemente. Un particionamiento apropiado permite mejorar el data warehouse en cuanto a la carga, acceso, archivado, eliminación, monitoreo y almacenamiento de los datos. Las pequeñas unidades o tablas pueden ser reestructuradas, indexadas, secuencialmente escaneadas, reorganizadas, recuperadas o monitoreadas. El particionamiento puede llevarse a cabo a nivel del motor de base de datos (DBMS, por sus siglas en inglés ─database management system─), del sistema operativo y a nivel de aplicación, y cada enfoque tiene sus ventajas y sus desventajas. Cuando el particionamiento se hace a nivel de aplicación, presenta un mayor grado de flexibilidad. Los datos pueden dividirse por muchos criterios, tales como los siguientes: Por fecha. Por unidad de negocios. Por región geográfica. Por unidad organizacional. Por todo lo anterior. Aunque ─definitivamente─ la fecha es un criterio mandatorio, casi siempre es empleado. De hecho, en ocasiones, puede volverse necesario hacerlo, ya que la definición o estructura de los datos puede variar de un año a otro. Por ejemplo, en lugar de tener una tabla con gran cantidad de registros, podríamos tener varias tablas con las actividades de los años 2009, 2010, 2011, 2012 y 2013 por separado. Figura 2: Particionamiento Fuente: elaboración propia con base en Inmon, 2005, p. 42 2. Data warehouse: comparación con OLTP William Inmon (2005) cree que es importante establecer una distinción entre datos primitivos y datos derivados. Los datos primitivos son los que se almacenan en las bases de datos por los propios sistemas transaccionales (OLTP), mientras que los datos derivados son una transformación de estos para poder ser usados por los DSS con el objeto de tomar decisiones. Las diferencias son las siguientes: Tabla 1: Comparación entre data warehouse y OLTP Fuente: elaboración propia con base en Inmon, 2005, p. 15 En definitiva, según William Inmon (2005), las principales diferencias entre ambos esquemas son las siguientes: Los datos primitivos son datos detallados, usados para ejecutar las operaciones diarias de la organización. Los datos derivados han sido sumarizados o precalculados para satisfacer las necesidades de la gerencia. Los datos primitivos pueden actualizarse. Los datos derivados no pueden recalcularse porque no pueden ser actualizados directamente. Los datos primitivos son datos de valor actual. Los datos derivados son datos históricos. Los datos primitivos son operados por procedimientos repetitivos. Los datos derivados son operados por programas heurísticos, no repetitivos. Los datos de los sistemas transaccionales OLTP son datos primitivos. Los datos de los sistemas DSS son datos derivados. Los datos primitivos apoyan las tareas operativas. Los datos derivados soportan la toma de decisiones gerenciales. 3. Tipos de implementación Existen dos modelos básicos para el diseño de la base de datos de un data warehouse: El modelo relacional, propuesto y defendido por William Inmon (2005). El modelo multidimensional, propuesto y defendido por Ralph Kimball (2013). Esto es lo que dice William Inmon (2005) respecto de ambos modelos: En el modelo relacional, los datos están altamente normalizados (tercera forma normal). Esta normalización hace que el diseño de la base de datos genere un muy bajo nivel de granularidad. El valor del modelo relacional para el data warehouse consiste en que hay disciplina en la forma en que se construye el diseño de la base de datos, claridad del significado y uso del nivel detallado de datos normalizados bajo la tercera forma normal. Así, el modelo relacional produce un diseño muy flexible, pues este puede adaptarse a distintas vistas. La flexibilidad y la versatilidad son las mayores fortalezas de este modelo, dado que los datos detallados pueden combinarse: pueden soportarse muchas vistas distintas. En cambio, el modelo multidimensional, también conocido como esquema estrella (o star join), tiene una tabla fact (tabla de hechos) en el centro del modelo, que contiene gran cantidad de registros, denormalizados, y, alrededor de ella, hay una serie de tablas de dimensiones que describen cada uno de los campos de la tabla fact. Generalmente, las dimensiones tienen pocos registros (sobre todo, en comparación con la fact) y contienen información relevante separada (ubicación de sucursales, calendario, etc.). La tabla fact y las tablas de dimensiones están asociadas por un campo referencial en común. La gran ventaja del modelo multidimensional es su eficiencia de acceso. Su estructura se basa en los requerimientos del usuario. En la unidad 3 (módulo 3), dedicaremos más tiempo a trabajar con el modelado multidimensional. Las principales diferencias entre ambos modelos, según William Inmon (2005), son las siguientes: El modelo relacional es altamente flexible, pero no está optimizado en términos de performance para ningún usuario en particular. El modelo multidimensional es altamente eficiente, porque sirve a las necesidades de una comunidad de usuarios en particular, aunque no es bueno en cuanto a su flexibilidad. Por su parte, el modelo multidimensional tiene un alcance más limitado, en el sentido de que el diseño se optimiza para un conjunto de requerimientos de usuarios, se ajusta mejor a los requerimientos de un departamento. En cambio, el modelo relacional está orientado a un alcance mayor (modelo empresarial). El modelo relacional está basado en un modelo de datos corporativo o empresarial, mientras que el modelo multidimensional lo está en función de un modelo basado en los requerimientos de procesamiento para satisfacer las demandas del usuario. Si bien el modelo relacional no es óptimo en performance para el acceso directo a los datos, debido a su diseño flexible, pueden generarse estructuras especiales (tablas sumarizadas) para un acceso indirecto a los datos más óptimos. En estos términos, el modelo multidimensional ofrece una performance similar con un acceso directo a los datos. 4. Arquitectura La arquitectura de William Inmon William Inmon (2005) sentó las bases de la primera definición arquitectónica de BI sobre el corporate information factory, como ya vimos en la unidad 1 (módulo 1). Además, el autor sostiene que el modelo relacional es mucho mejor para el diseño de un data warehouse, puesto que se necesita soportar el acceso de muchos usuarios distintos con diferentes requerimientos. Es decir, considera que el data warehouse no debe estar optimizado para el acceso de un usuario en particular. Para William Inmon (2005), la clave está en el reshaping del modelo relacional. Dado el nivel de granularidad que provee este modelo, es relativamente fácil crear tablas sumarizadas, que se elaboran a partir de necesidades específicas de un conjunto único de usuarios. De esta manera, esta tabla sumarizada se encuentra lista para su acceso directo, altamente eficiente en términos de performance. Se pueden crear tantas tablas sumarizadas como sean necesarias. La sencillez de su creación se debe a lo siguiente: Los datos están almacenados al nivel más granular, más normalizado. Las relaciones entre tablas relacionales ya están identificadas. Nuevas tablas pueden contener nuevas sumarizaciones, nuevos criterios de selección y nuevas agregaciones. En el caso del modelo multidimensional, dado que está optimizado para un grupo único de usuarios, cualquier otro usuario debe pagar el precio de una performance que no es la óptima. Inmon (2005) asegura que este modelo no garantiza la optimización para todos los usuarios para todos sus requerimientos. La ventaja del modelo relacional tiene que ver con su flexibilidad al cambio, hacia nuevos requerimientos o nuevos grupos de usuarios que tienen necesidades distintas. Las tablas sumarizadas proveen agregaciones de los datos a nivel granular, es decir, cualquier combinación de átomos. Además, otra ventaja consiste en que, si para otro usuario se requiere un cálculo diferente, no es necesario tocar el modelo base, ya que simplemente se debe agregar una nueva tabla sumarizada. Se reduce y aísla el impacto al cambio. En el modelo multidimensional, en cambio, el impacto puede ser mucho más profundo, pues se tiene que cambiar la misma estructura. Debido a lo expuesto, William Inmon (2005) sostiene que el modelo relacional es ideal para el diseño de un data warehouse, mientras que el modelo multidimensional es ideal para el diseño de un data mart. William Inmon (2005) alega que los data warehouses se diseñan a partir de los requerimientos de información corporativos de toda la organización, y no desde los requerimientos departamentales (como un data mart). Por lo tanto, crear un data warehouse con un modelo multidimensional sería un error, ya que el resultado sería un data warehouse optimizado para una comunidad de usuarios a expensas de otros usuarios. La arquitectura de Ralph Kimball Ralph Kimball (2013), en cambio, sostiene que el data warehouse debería basarse sobre un modelo multidimensional, también con datos detallados. Según su enfoque, el paso final de los procesos ETL consiste en la carga de los datos en la estructura física bajo un modelo multidimensional, tablas que luego serán la base del área de presentación de BI (las aplicaciones DSS). Estos subsistemas ETL son críticos; muchos de ellos se enfocan en el procesamiento de las tablas de dimensión. Por su parte, las tablas de hechos, si bien tienen muchos registros, no suelen demandar gran preparación. Una vez actualizadas, indexadas y con la calidad de datos asegurada, estas tablas son publicadas para los usuarios. Existe un debate respecto de si los datos deberían cargarse primero en una estructura normalizada antes de cargarlos en un modelo dimensional para la consulta y reporting. Si bien esto es aceptable, la creación de estructuras normalizadas para el ETL y estructuras dimensionales para el área de presentación implica doble proceso de ETL, lo cual requiere más tiempo e inversión para el desarrollo, mayor tiempo de actualización de los datos y más capacidad para almacenar las múltiples copias de datos. Aunque la consistencia de datos a nivel empresarial es un objetivo fundamental de un data warehouse, puede ser más efectivo y menos costoso no incluir en el ETL estas estructuras normalizadas. El área de presentación BI es aquella donde los datos se organizan, almacenan y están disponibles para la consulta de los usuarios y aplicaciones analíticas. Dado que las herramientas ETL están fuera de sus límites, esta área es todo lo que ven los usuarios. Ralph Kimball (2013) insiste en que los datos sean presentados, almacenados y accedidos en esquemas multidimensionales. Además, hace hincapié en que el área de presentación debe tener datos detallados, atómicos, los cuales se requieren para responder a consultas de usuarios ad hoc, impredecibles. Aunque contenga datos sumarizados con alta performance, no es suficiente entregar esta información sin contar con los datos granulares en una forma dimensional. Es decir, es inaceptable guardar datos sumarizados en modelos dimensionales teniéndolos en estructuras normalizadas. El área de presentación BI debería ser estructurada alrededor de los eventos de medición del proceso de negocio. Este enfoque se alinea con los sistemas operacionales. Los modelos dimensionales deberían corresponderse a los eventos de captura de datos físicos, no deben diseñarse para entregar el reporte del día. Los procesos de negocio cruzan los límites de los departamentos de la organización. Debe construirse una sola tabla de hechos con los datos atómicos de las ventas, en lugar de generar estructuras separadas similares. Todas las estructuras dimensionales deben diseñarse usando dimensiones comunes. Esta es la base del enterprise data warehouse bus architecture. Sin dimensiones compartidas, un modelo dimensional se vuelve una aplicación standalone. Los datos aislados generan vistas incompatibles de la empresa. Con dimensiones compartidas, los modelos dimensionales pueden ser compartidos. En una gran empresa, podemos encontrar una docena de modelos dimensionales combinados con tablas de dimensión compartidas. Aunque la arquitectura de Kimball habilita normalización opcional para soportar el procesamiento ETL, el enterprise data warehouse normalizado es un requisito obligatorio en el corporate information factory de Inmon. Al igual que el enfoque de Kimball, el corporate information factory subraya la coordinación e integración de datos empresariales. El corporate information factory dice que el enterprise data warehouse normalizado satisface esta función, mientras que la arquitectura de Kimball recalca la importancia de un enterprise data warehouse bus architecture con dimensiones compartidas. La arquitectura híbrida Inmon – Kimball Según Ralph Kimball (2013), se puede plantear una arquitectura híbrida que integre los conceptos tanto de uno como de otro enfoque. Esta arquitectura carga un enterprise data warehouse al estilo del corporate information factory, que está completamente fuera de alcance para los usuarios para reporting y análisis. Es solo la fuente para cargar un área de presentación tipo Kimball en la cual los datos son multidimensionales, atómicos/muy detallados (complementados por sumarizaciones), centrados en procesos y dentro del enterprise data warehouse bus architecture. Este enfoque híbrido trae lo mejor de los dos mundos, pero solo puede ser apropiado si la empresa ya invirtió en un enterprise data warehouse normalizado, porque, dados los múltiples movimientos de datos y el almacenamiento redundante de datos detallados, iniciar desde cero implica más costos y más tiempo, tanto en desarrollo como operación continua. Desarrollo iterativo del data warehouse Inmon (2005) afirma que es conveniente construir un data warehouse de manera iterativa, puesto que el usuario es incapaz de articular muchos requerimientos hasta que la primera iteración finaliza, además de que la gerencia generalmente no se compromete por completo hasta ver algunos resultados tangibles. Desde su enfoque, Kimball (2013) sostiene que, usando el enterprise data warehouse bus architecture, es posible desarrollar un data warehouse de manera iterativa, gradual, ágil y descentralizada. Referencias Cano, J. L. (2007). Business Intelligence: Competir con Información. España: Banesto Fundación Cultural y ESADE. Inmon, W. (2005). Building the Data Warehouse (4.ta. ed.). Estados Unidos: Wiley Publishing. Kimball, R. M. (2013). The Data Warehouse Toolkit (3.ra. ed.). Estados Unidos: Wiley Publishing. Bloque 1Bloque 2Bloque 3Bloque 4Bloque 5Bloque 6Bloque 7Referencias Data mart, data mining y balanced scorecard 1. Data mart Arquitecturas disponibles En cuanto al diseño de los data marts, también podemos destacar distintos tipos de arquitecturas disponibles. Data marts aislados/independientes. Data marts interconectados/dependientes. Data marts independientes De acuerdo con William Inmon (2005), la arquitectura de los data marts independientes consiste en un diseño que parte directamente de las aplicaciones fuente (sistemas transaccionales). Un data mart independiente puede ser creado por un departamento, sin consideración alguna de otros departamentos ni la participación del Área centralizada de Sistemas. Un data mart independiente representa el conjunto de requerimientos de BI (business intelligence) de un sector en particular, por ello, es relativamente fácil, rápido y económico de construir, y, a la vez, le permite a ese sector o departamento manejar por sí mismo su política de BI. Es por esto que son tan populares. Con este enfoque, los datos analíticos se despliegan en una base departamental sin consideraciones de compartir o integrar información a lo largo de la empresa. Generalmente, un único departamento identifica los requerimientos de datos desde un sistema operativo. Así se construye una base de datos que satisface las necesidades departamentales, pero este data mart departamental, al trabajar en forma aislada, refleja solo los requerimientos analíticos del departamento. Mientras tanto, otro departamento se interesa en los mismos datos fuente, pero, dado que no tiene acceso al data mart inicialmente construido por el otro, procede de manera similar construyendo una solución departamental aislada. De esta manera, cuando los usuarios se reúnen a discutir sobre una misma métrica, encontramos dos visiones distintas porque el cálculo no necesariamente dio el mismo resultado al usar distintas fórmulas o reglas de negocio. Algunos de los defensores del modelo multidimensional favorecen esta estrategia. Por su parte, William Inmon (2005) sostiene que se trata de una estrategia de corto plazo, de enfoque limitado, ya que no provee una base firme para la consolidación de la información corporativa. En su análisis, los data marts independientes presentan varias desventajas: No proporcionan una plataforma para la reusabilidad. No proveen una base para la reconciliación de datos. No brindan un único conjunto de programas de interfaz (ETL) con las aplicaciones transaccionales. Requieren que cada data mart independiente construya su propio pool de datos detallados, lo cual resulta redundante con otros data marts independientes de la misma empresa. Ralph Kimball (2013) también cree que se trata de una estrategia de desarrollo rápida y de bajo costo en el corto plazo; sin embargo, múltiples extracciones de datos no coordinadas y el almacenamiento redundante de datos analíticos son ineficientes y de alto costo en el largo plazo. Sin una perspectiva empresarial, este enfoque termina con una gran cantidad de aplicaciones aisladas y vistas incompatibles del desempeño organizacional. Kimball también desaconseja este enfoque. Figura 1: Data marts independientes Fuente: Cano, 2007, p. 118 Data marts dependientes Para Inmon (2005), la arquitectura de data marts dependientes se basa en un data warehouse centralizado; los datos de los data marts provienen de allí (tal cual ocurre el corporate information factory). Es decir, el data mart dependiente no se somete a los datos operacionales, sino a data warehouse. Esta estrategia requiere, desde luego, de una mayor inversión, planificación, perspectiva a largo plazo, como también de cooperación y coordinación en la definición de los requerimientos entre los diferentes departamentos de la organización. Inmon (2005) explica que un aspecto clave para considerar es el modo en que se transfieren los datos desde el data warehouse hasta el data mart. Los datos en un data warehouse están muy detallados, tienen bajo nivel de granularidad; por otro lado, los datos en un data mart suelen estar más compactos y sumarizados. Deben enviarse periódicamente los datos de una estructura a la otra: este movimiento es análogo a un proceso ETL. Además, los data marts se diseñan, generalmente, siguiendo un modelo multidimensional. Asimismo, la estructura de datos multidimensional en cada uno de los data marts está especialmente diseñada para cada uno de los requerimientos departamentales. Así, cada departamento requerirá una estructura de data mart distinta. Todas estas estructuras se alimentarán desde el mismo data warehouse y pueden estar en una base de datos relacional (esquema multidimensional conocido como star join) o en una base de datos multidimensional (cubos OLAP). De acuerdo con William Inmon (2005), diferentes data marts precisan un distinto nivel de granularidad. Ahora bien, para poder alimentar los distintos data marts, es necesario que el data warehouse tenga un nivel más bajo de granularidad que cualquiera de los data marts que alimentará. Figura 2: Data marts dependientes Fuente: Cano, 2007, p. 118 Modos de implementación Existen dos modos para implementar un data warehouse y los respectivos data marts: Top down, estrategia propuesta por William Inmon (2005). Como afirma Josep Lluís Cano, propone definir un Data Warehouse corporativo y a partir de él ir construyendo los modelos de análisis para los distintos niveles y departamentos de la organización; es decir, una estrategia de arriba abajo, desde la estrategia a lo más operativo (2007, p. 118). Bottom up, estrategia inicialmente propuesta por Ralph Kimball (2013). Como afirma Josep Lluís Cano, propone “construir distintos Data marts que cubran las distintas necesidades de la organización, sin la necesidad de construir un Data Warehouse” (2007, p. 119). Es evidente que ambas alternativas pueden ser viables en función de las características de cada proyecto. Cada una de ellas presenta sus propias ventajas y desventajas. El profesor Hugh J. Watson (citado en Cano, 2007) expone que, cuando se desarrollan correctamente, las dos estrategias son válidas. Con la estrategia de definir un Data Warehouse corporativo, el Data Warehouse es desarrollado en fases y cada una de las mismas debe ser diseñada para generar valor para el negocio. Se construye un Data Warehouse corporativo, del que se cuelga un Data Mart dependiente con una parte de la información del Data Warehouse. En fases posteriores, se van desarrollando Data Marts usando subconjuntos del Data Warehouse. Igual que los proyectos complejos, es caro, necesita mucho tiempo y es propenso al fracaso. Cuando tenemos éxito, conseguimos un Data Warehouse integrado y escalable. Si optamos por la estrategia más común, la de construir distintos Data Marts, el proyecto comienza con un Data Mart único al que posteriormente se irán añadiendo otros Data Marts que cubrirán otras áreas de negocio. Normalmente no requiere de grandes inversiones y es fácil de implementar, aunque conlleva algunos riesgos; de entre ellos, cabe destacar fundamentalmente dos: puede perpetuar la existencia del problema de “silos de información” y posponer la toma de decisiones que conciernen a la definición de criterios y modelos de negocio. Si seguimos esta estrategia, debemos tener claro el plan de acción, es decir, qué áreas cubriremos y la integración de los distintos modelos. Esta estrategia se utiliza a veces como un paso previo al desarrollo de un Data Warehouse corporativo. Las dos aproximaciones abogan por construir una arquitectura robusta que se adapte fácilmente a los cambios de las necesidades de negocio y que nos proporcione una sola versión de la verdad. (Cano, 2007, p. 119) 2. Data mining Definición Según un informe de Two Crows Corporation (1999), la minería de datos —más conocida por el término data mining, en inglés— consiste en la búsqueda de patrones y relaciones ocultas en los datos de las organizaciones. Data mining no es más que la aplicación de algoritmos específicos al data warehouse para obtener resultados útiles. En otras palabras, consiste en la aplicación de técnicas matemáticas, estadísticas y principalmente de inteligencia artificial para descubrir relaciones, patrones y tendencias en los datos almacenados por una organización. Actualmente, existen enormes bases de datos en donde se encuentra oculta información estratégica de gran relevancia, a la que no se puede acceder a través de las técnicas tradicionales de recuperación de información. Para revelar esta información, es necesario hacer uso de la minería de datos, un proceso que emplea una amplia variedad de herramientas de análisis de datos para descubrir patrones y relaciones en los datos, los cuales son utilizados posteriormente para realizar predicciones válidas. La minería de datos es parte de un proceso iterativo mayor llamado “descubrimiento de conocimiento en base de datos” (KDD, por sus siglas en inglés —knowledge discovery in databases—). Es importante destacar que la minería de datos no reemplaza las técnicas de estadísticas tradicionales; por el contrario, muchas de las técnicas más utilizadas en la minería de datos tienen sus raíces en las aplicaciones estadísticas, como los modelos utilizados para clustering y segmentación. Generalmente, no se distingue la diferencia entre OLAP (online analytical processing) y data mining. El análisis OLAP es esencialmente un proceso deductivo: el analista OLAP genera una serie de patrones y relaciones hipotéticas y utiliza consultas contra la base de datos para verificarlas o refutarlas. La minería de datos difiere del análisis OLAP, puesto que, en lugar de verificar patrones hipotéticos, utiliza los datos para descubrir patrones y es esencialmente un proceso inductivo. La minería de datos y OLAP se pueden complementar entre sí, ya que OLAP puede ser usado antes de la minería de datos para ayudar a explorar los datos, focalizar la atención sobre las variables importantes, identificar excepciones o encontrar interacciones, contribuyendo de esta manera a un mayor entendimiento de los datos. 3. Aplicaciones de minería de datos Entre las principales aplicaciones de minería de datos, podemos detallar las siguientes: ☰ Venta cruzada (cross selling) Las técnicas de minería se utilizan para identificar productos que se venden bien juntos. Los clientes masculinos que compran pañales, viven en el centro y tienen entre 20 y 27 años, en general, también compran cerveza; los vendedores pueden, por ejemplo, diagramar la distribución en góndolas (poner estos productos más cerca o más lejos) y planificar su publicidad, como una de las estrategias basadas en este conocimiento. ☰ Control de calidad En este caso, la aplicación de minería de datos consiste en procesar la información de seguimiento de los procesos productivos en busca de desviaciones anormales de estos, tendencias y demás indicadores de un proceso fuera de control. ☰ Retención de clientes Esta área se encarga de conservar a los clientes y, si es posible, hacerlos leales. En dicho proceso, las técnicas de minería nos ayudan a identificar los aspectos característicos de nuestros servicios que han hecho leales a algunos de nuestros clientes para tratar de replicarlos con los demás clientes. Además, nos pueden informar sobre las características particulares de nuestros clientes leales para obtener un perfil y luego focalizar las campañas de incorporación de nuevos clientes en personas con el mismo perfil, es decir, que presenten una alta probabilidad de tener una relación a largo término con la empresa. ☰ Adquisición de nuevos clientes Se complementa con la anterior. La tarea consiste en conseguir nuevos clientes, es decir, utilizar minería para determinar estrategias dirigidas a ganar nuevos clientes. La minería nos ayudará a definir la mejor estrategia de adquisición, analizando campañas anteriores y el mejor grupo de personas que serán el blanco. ☰ Análisis de la lealtad del cliente Consiste en minar los datos de los consumidores para extraer modelos de lealtad que muestren el grado de lealtad a un determinado producto o marca. De esta manera, la compañía puede determinar niveles de lealtad y diseñar estrategias diferenciadas para cada nivel. ☰ Marketing dirigido Para llevar a cabo esta aplicación, es necesario identificar subconjuntos de la población que responderán más probablemente a una campaña publicitaria: en el caso de la adquisición de nuevos clientes, será la población en general; si se trata de lanzamiento de nuevos productos, estarán incluidos también los clientes actuales. Mientras mejor seleccionados estén los miembros del subconjunto elegido, más efectiva será la campaña, y esto se traducirá en mejores beneficios y menores costos, debido a la focalización de los recursos. ☰ Prevención de fraude Consiste en el uso de la minería de datos para detectar patrones de fraude. ☰ Administración del riesgo Las aseguradoras deben poder calcular en forma precisa los riesgos asociados a cada una de las pólizas que otorgan y verificar que sus valores se correspondan con los riesgos asociados. Es decir, no se debe ni sobrevalorar una póliza que implica un riesgo pequeño ni infravalorar una póliza que tiene un riesgo muy alto. Muchos de los factores que afectan el riesgo asociado a un evento son claros, pero pueden existir algunas relaciones más sutiles, no intuitivas, entre las variables, que son difíciles de discernir si no se les aplican herramientas de análisis más perfeccionadas. Las técnicas modernas de minería ofrecen un modelo más preciso y más eficiente que las tecnologías anteriores. Los algoritmos de minería permiten echar luz sobre tendencias y relaciones que no son evidentes en los grandes cúmulos de datos, y las nuevas técnicas gráficas permiten visualizar complejos modelos de información que facilitan el análisis y la comparación. Las técnicas de minería ayudan a los aseguradores a segmentar sus clientes para poder tratarlos de forma diferenciada y dividirlos en subconjuntos con un riesgo asociado a cada grupo. Operaciones de minería de datos Estas son algunas de las principales operaciones de minería de datos: Modelado predictivo. Análisis de relaciones. Segmentación de bases de datos. Detección de desviaciones. Técnicas de minería de datos Antes de poder diseñar buenos modelos predictivos, es necesario, en primer lugar, llegar a una comprensión (conocimiento) de los datos. En primera instancia, el proceso se inicia recuperando una variedad de resúmenes numéricos (incluyendo estadísticas descriptivas tales como promedios, desviaciones estándar, entre otras), como también observando cuidadosamente la correspondiente distribución de los datos. En algunos casos, incluso, es deseable producir tabulaciones cruzadas (o pivot tables) para datos de carácter multidimensional. Los datos pueden, desde ya, ser continuos —en cuyo caso pueden asumir cualquier valor numérico (por ejemplo, la cantidad vendida)— o discretos, incluidos dentro de clases discretas (como azul, verde, rojo, etc.). Los datos discretos pueden ser, además, categorizados en ordinales, los cuales tienen un orden significativo (por ejemplo: alto, medio, bajo), o nominales, los que están desordenados (por ejemplo, los códigos postales). Entre las principales técnicas, encontramos las siguientes: ☰ Clustering Divide o segmenta una base de datos en diferentes grupos. El objetivo del clustering es encontrar grupos que son muy diferentes y cuyos miembros son muy similares entre sí. A diferencia de la clasificación (minería de datos predictiva), en el clustering uno no es capaz de conocer los clusters a priori ni de saber por cuáles atributos los datos serán segmentados. Como consecuencia, quien tenga un gran conocimiento del negocio deberá interpretar los clusters. ☰ Asociaciones Se trata de una aproximación descriptiva para la exploración de datos que puede ayudar en la identificación de relaciones entre valores en una base de datos. Las dos aproximaciones más comunes para el análisis de relaciones son el descubrimiento de asociación y el descubrimiento de secuencia. El primero encuentra reglas sobre ítems que aparecen conjuntamente en un evento como una transacción de compra. El análisis de la canasta de mercado (comúnmente conocido como “análisis del changuito”) es un ejemplo conocido de descubrimiento de asociación. Por su parte, el descubrimiento de secuencia es muy similar al anterior, con la diferencia de que se analiza una secuencia que es una asociación relacionada a lo largo del tiempo. ☰ Clasificación Los problemas de clasificación ayudan a identificar las características que indican el grupo al cual pertenece cada caso específico. Este patrón puede ser usado tanto para comprender los datos existentes como para predecir el comportamiento que tendrán las nuevas instancias. Por ejemplo, se puede querer predecir si los individuos serán clasificados como aquellos que probablemente responderán a un envío de o como aquellos que se someterán a un procedimiento quirúrgico. La minería de datos crea modelos de clasificación examinando los datos ya clasificados (llamados “casos”) e inductivamente encuentra un patrón de predicción. ☰ Regresión Usa los valores existentes para pronosticar qué otros valores habrá. En el caso más simple, la regresión emplea técnicas estadísticas tales como la regresión lineal. ☰ Series de tiempo Los pronósticos de series de tiempo predicen valores desconocidos en el futuro, basados sobre una serie variante en el tiempo de predictores. Al igual que la regresión, usa resultados conocidos para guiar sus

Document Details

Tags

Related

Full Transcript

Upgrade to continue