Unido M Bd2.pdf

Módulo 1 Inteligencia de Negocios

1. Introducción a los SSD y a DW 1.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, http://www.gartner.com/it-glossary/businessintelligence-bi, s.f.)

Introducción El objetivo de Business Intelligence (BI), también conocida como Inteligencia de Negocios en español, 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 quién 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 (http://goo.gl/9bNho4, s.f.): “Business Intelligence (BI) es un término genérico que incluye las aplicaciones, infraestructura y herramientas y las

1

mejores prácticas que permiten el acceso y análisis de información para mejorar y optimizar las decisiones y el desempeño”. En tanto, Olivia Parr Rud (2009) considera a BI como un conjunto de teorías, metodologías, arquitecturas y tecnologías que transforman datos en información útil y significativa para los objetivos de negocios. Así, BI puede manejar grandes cantidades de datos desestructurados para ayudar a identificar, desarrollar y crear nuevas oportunidades. BI, en definitiva, permite interpretar los datos voluminosos de manera amigable, facilitando el aprovechamiento de potenciales nuevas 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. Entre las funciones más comunes de las tecnologías de BI podemos encontrar: reporting, OLAP, minería de datos, entre otras. Boris Evelson, de la consultora especializada Forrester Research, sostiene que: 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.

(http://goo.gl/oIeCU, 2008)

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.

2



La comunidad de negocios debe aceptar al sistema de BI para que sea exitoso.

Por otro lado, Ralph Kimball (2013) sostiene que estos 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.

1.2 Evolución de los SSD Historia Si bien el término BI fue popularizado a partir de 1989, fue en el año 1958 cuando Hans Peter Luhn, investigador de IBM, definió a la inteligencia de negocios haciendo referencia a “la capacidad de comprender las interrelaciones de hechos presentados de una manera tal que guía la acción hacia una meta deseada” (BCW, http://goo.gl/LEiSV0, 2012). Incluso las primeras empresas de software especializadas en lo que hoy denominamos BI surgen en la década de 1970, como por ejemplo: Information Builders (1975) o SAS (1976). Sin embargo, el término BI, tal como lo conocemos hoy, ha evolucionado significativamente desde los originales Sistemas de Soporte de Decisión (DSS, Decision Support Systems en inglés). William Inmon (2005) sostiene que en la década de 1980 aparecieron los Sistemas de Información Gerencial (MIS, Management Information Systems en inglés); posteriormente, ya más conocidos como DSS, los primeros MIS comenzaron a usarse como software para tomar decisiones. Anteriormente, 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 software 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.

3

Los Sistemas de Gestión de Bases de Datos (DBMS, Database Management Systems en inglés) que surgieron en la década de 1970, verdaderamente iniciaron una nueva era informática con el advenimiento del denominado procesamiento transaccional en línea (OLTP, Online Transaction Processing). 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 masivos sistemas operacionales/transaccionales (OLTP, OnLine Transaction Processing en inglés), hacia el año 1985 surgieron los primeros sistemas de extracción de datos (ETL, Extract, Transform and Load en inglés), que posibilitaban transferir 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 al proceso de toma 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 multi-usuario, 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, Executive Information Systems en Inglés), software con capacidades adicionales para navegar sobre información más detallada, extraordinarias interfaces y, sobre todo, intensivos en el acceso a bases de datos integradas y unificadas, pero a la vez carentes, en muchos casos, de herramientas avanzadas de modelado. Information Builders en 1991 anuncia su primer software EIS, pero es en 1992 cuando la empresa MicroStrategy lanza al mercado el primer producto de software de BI completo. En los '90 también surgieron las herramientas de Minería de Datos (Data Mining, en inglés) orientadas a la búsqueda de patrones y relaciones ocultas en los datos. Gracias a la implementación de enormes Almacenes de Datos (más conocidos como Data Warehouses en inglés) se podía obtener conocimiento de grandes volúmenes de datos. William Inmon (2005) menciona que a partir de 1994 surgieron otros conceptos ligados a BI tales como las bases de datos multidimensionales

4

(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 en que el software BI logra gran inserción en las organizaciones hasta la actualidad. Además, cabe destacar la impresionante convergencia de tecnologías surgidas en las últimas dos décadas, tales como: 

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 concepto de Software como Servicio (SaaS, Software as a Service en Inglés) y Computación en la Nube (Cloud Computing en Inglés) 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 le 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 u otras);



El boom de la tecnología Mobile a través de Smartphones y Tablets, que logró 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;



Big Data y la evolución hacia grandes volúmenes de datos desde algunos terabytes hasta varios petabytes en único repositorio;



Aplicaciones Analíticas: dada la gran proliferación de herramientas de BI, algunas de ellas se focalizaron en especializarse en la gestión de métricas o Indicadores Claves de Negocio (KPI, Key Performance Indicator en Inglés) para determinadas industrias verticales; es decir, BI para el sector finanzas, BI para el sector salud, BI para el sector manufacturero, entre otras.

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.

5

1.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, en cambio, permiten explotar o visualizar esos datos convirtiéndolos 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 y monitoreando el estado de las actividades, entre otros). 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. Pero dado su enfoque operativo, generalmente no guardan datos históricos con gran precisión, sino que, por el contrario, sus estructuras de datos frecuentemente 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, etc. 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 generalmente están optimizados para consultas de alto desempeño, teniendo en cuenta que las consultas de los usuarios frecuentemente requieren 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 hacen. Ahora, ¿quién necesita de BI? En este sentido, Josep Lluís Cano (2007, p. 30) sostiene que “la información que podemos generar a partir de Business

6

Intelligence es útil para todos los departamentos de nuestra organización”. Esto incluye a los responsables o gerentes de departamentos tales como: 

Compras



Ventas / Comercial



Finanzas



Marketing



Recursos Humanos



Operaciones



entre otros.

Es decir, para todas aquellas personas que deban tomar decisiones.

1.4 Problemática Ralph Kimball (2013) sostiene que los problemas típicos de los usuarios pueden sintetizarse en algunas de las demandas que mencionamos a continuación: 

Recolectamos toneladas de datos, pero no podemos acceder a ellos.



Los directivos necesitan obtener los datos fácilmente.



Sólo 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.

7

Por otro lado, William Inmon (2005) expresa que la inexistencia de una solución BI lleva a los siguientes problemas: 

Falta de credibilidad en los datos



Problemas con la Productividad



La 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 de los cuales experimentó un incremento en las ventas del 10% y el otro 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 racionalmente dada la falta de credibilidad en las fuentes. Las diferencias pueden surgir por varios factores: 

No existe una misma base (tiempo) de cálculo



Algoritmos diferentes



Niveles de extracción disímiles



Datos externos tenidos (o no) en cuenta



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 produce una fuerte pérdida de productividad al tener que, por cada análisis requerido, revisar distintos archivos, bases de datos, etc., 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. Hay una evidente sobrecarga de trabajo al tener que producir un reporte o informe manualmente.

8

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 es 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 es que no hay suficientes datos históricos almacenados en las aplicaciones. Es decir, son sistemas que fueron diseñados para responder rápidamente, con altos niveles de performance, y muchas veces esto se consigue guardando sólo los últimos doce meses de trabajo en la base de datos, sin grandes registros históricos.

1.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. Actualmente, 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 adecuado proceso 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 costes, generación de ingresos y reducción de tiempos para las distintas actividades del negocio.

9



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 (2007, p. 37) “la principal razón de un proyecto de Business Intelligence es el análisis de un problema o problemas interrelacionados”.

Cálculo del ROI en Proyectos de BI: Porqué 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 esperada del mismo. Por lo tanto es necesario: 

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

10

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:

(Cano, 2007, p. 45)

Metodología para el Cálculo del ROI Josep Lluís Cano, en base a 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 de negocio. 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:

11

En donde NPV es el Valor Neto Actual, es decir, la suma actualizada de los beneficios esperados del proyecto. 8) 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, de acuerdo con 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”.

1.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. De acuerdo con Kennet Laudon (2004), el proceso de toma de decisiones consta de cuatro etapas: 

Inteligencia



Diseño



Selección



Implementación.

12

A continuación veremos 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)

13

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 (http://goo.gl/Xy2REl, 2004), debemos tener en cuenta que un DSS no es más que un sistema de información gerencial que permite “resolver problemas semi-estructurados y no estructurados, involucrando al usuario a través de una interfaz amigable”. Mónica 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” (http://goo.gl/Xy2REl, 2004).

1.7 CIF 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 u OLAP o Multidimensional)

14



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 de datos:



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, de alta performance requerida. En este nivel generalmente no se mantienen registros históricos ya que los datos se actualizan y se pierden los valores anteriores.



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) procesan datos a este nivel y corren sobre una PC.

15

Imagen 1: Niveles de Datos

Fuente: Elaboración propia en base a William 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 (bases de datos transaccionales y analíticas, entre otras), conjuntamente con todos aquellos procesos y herramientas utilizados en las distintas etapas para poder generar información y lograr que la misma se encuentre disponible en tiempo y forma para todos los niveles de la organización. Como señalan Josep Lluís Cano (2007), William Inmon (2005) y Ralph Kimball (2013), los distintos componentes del CIF y, por ende, de una solución de BI, son (aunque no siempre encontraremos todos ellos): 

Fuentes de Información



Procesos ETL de Extracción, Transformación y Carga de datos en el Data Warehouse



Data Warehouse



Data Mart

16



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.

En el siguiente gráfico podemos ver estos componentes del CIF y las relaciones entre ellos:

Imagen 2: Componentes del CIF

Fuente: Josep Lluís Cano (2007, p. 93)

17

Fuentes de Información Según Josep Lluís Cano (2007), las fuentes de información hacen referencia a los lugares (bases de datos, etc.) de donde se extraerán los datos para alimentar el Data Warehouse.

Principales Fuentes de Datos Las principales fuentes de información son: 

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 así también productos “enlatados” o grandes sistemas corporativos, como por ejemplo: los sistemas de Gestión de las Relaciones con los Clientes (CRM, Customer Relationship Management), sistemas de Gestión Financiera y Planificación de Recursos Empresariales (ERP, Enterprise Resource Planning), sistemas de Gestión de la Cadena de Abastecimiento (Supply Chain Management) y sistemas de Gestión de Recursos Humanos o del Capital Humano (HCM, Human Capital Management), entre otros.



Sistemas de Información Departamentales, muchas veces basados en planillas de cálculo Excel, etc.



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 por ejemplo: 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, a población y número de habitantes, entre otros. Podemos acceder a información de este tipo en la correspondiente web del Instituto Nacional de Estadísticas.

18

Pero también existen otras fuentes de información de las cuales se pueden llegar a tomar datos según las necesidades, tales como: 

Otras fuentes de Internet: Muchas veces es necesario poder realizar comparaciones en los indicadores con otras compañías u organizaciones; es lo que se denomina una actividad de Benchmarking. Esto es fundamental dado que para saber si determinado valor es bueno o malo - en realidad se trata de un valor relativo a cómo 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 a Considerar Según Josep Lluís Cano (2007), hay distintos factores que contribuyen a la complejidad de la carga de información; entre ellos el autor destaca la cantidad de fuentes diferentes de información, teniendo en cuenta que en las grandes corporaciones es natural hablar de una media de 8 bases de datos hasta llegar incluso a 50. A medida que se requiere acceder a un número creciente de fuentes de información, la complejidad de todo proyecto de creación de un Data Warehouse se incrementa notablemente dado que probablemente algunas bases de datos están en SQL Server, otras en Oracle, otras en IBM DB2, etc.; además de la propia complicación inherente al modelo de datos subyacente de cada aplicación. Otro problema es el que 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

19

información no estructurada tenemos: correos electrónicos, cartas, informes, videos, etc.

(Cano, 2007, pp. 96-97)

Calidad de Datos De acuerdo con Josep Lluís Cano (2007), 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 es un aspecto esencial. Consecuentemente, es necesario asegurar que la calidad de los datos es máxima. Si en el Data Warehouse hay errores, éstos 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 expresa que: 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

20

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, Josep Lluís Cano determina que la misma: No pertenece sólo 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, con el objeto de que alcancen un nivel de calidad elevado son: 1) Precisión: ¿Representan los datos con precisión una realidad o una fuente de datos que se pueda verificar? 2) Integridad: ¿Se mantienen 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?

21

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)

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 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, re-codificarla, limpiarla, explicitar reglas de negocio ocultas, formatearla y organizarla de manera de poder incorporarla en el Data Warehouse. A estos procesos se los conoce con la sigla ETL (Extract, Transform and Load, en inglés). De acuerdo con William 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.

22

Proceso ETL en el Proyecto de BI El diseño de los procesos ETL insume gran parte del tiempo de un proyecto BI. Se trata de una tarea compleja, pero para poder aprovechar los beneficios del Data Warehouse es fundamental que se logre 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 5 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)

23

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 fueron diseñados esos sistemas 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.

Imagen 3: Problema de Integración de Datos

Fuente: Elaboración propia en base a William Inmon (2005, p. 73)

Algunos ejemplos de falta de integración que comúnmente podemos encontrar son: 

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.

24

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 haya 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: 

Extraer los datos que tienen marca temporal en las bases de datos operacionales. Sólo se traen los datos desde la última fecha y hora de actualización.



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.



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.

25

Desafíos en los Procesos ETL De acuerdo con William Inmon (2005), los procesos ETL encaran varios desafíos complejos: 

La extracción de datos desde los sistemas transaccionales hacia el Data Warehouse generalmente requiere un cambio de tecnología (por ejemplo: leer desde una base de datos Microsoft SQL Server y cargar un Data Warehouse en Oracle).



La selección de datos a extraer puede ser muy compleja, tal como se describió anteriormente.



Los campos claves en las bases de datos operacionales frecuentemente deben ser reestructurados y convertidos 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 introduce 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.

26

Enterprise Data Warehouse El Data Warehouse es el núcleo del Corporate Information Factory; 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 a otras estructuras de datos como Data Marts, Exploration Warehouses, Data Mining Warehouses, Operational Data Stores (ODS) y, en definitiva, construidos con el objetivo de ser explotados por diferentes Sistemas de Soporte de Decisión (DSS). De acuerdo con William Inmon (2005), el Data Warehouse está en el corazón del CIF y es el fundamento de todo DSS. El Data Warehouse contiene datos corporativos con alta granularidad (alto nivel de detalle). 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 son la respuesta a las necesidades de los usuarios que necesitan información consistente, integrada, histórica y preparada para ser analizada para 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), los aspectos más importantes de un Data Warehouse son: 

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 ser para el procesamiento de

27

seguros de autos, vida, casa, salud, etc. Las principales áreas de interés podrían ser: cliente, póliza, etc. Cada tipo de empresa tiene sus propias áreas de interés. 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, etc.); 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, generalmente se encuentran inconsistencias de datos entre los distintos orígenes o bases de datos, ya sea a nivel de nomenclatura, codificación, atributos físicos y 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 (usualmente 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

28

año, mes o día, pero el Data Warehouse siempre contiene algún elemento de tiempo.

Data Mart De acuerdo con William Inmon (2005), 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)

29

Repositorio de Metadatos De acuerdo con William Inmon (2005), un componente central del Data Warehouse es el Repositorio de Metadatos ya 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 o cómo encontrar los datos correctos, ni cómo interpretar los datos encontrados. 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, almacenan el seguimiento de: 

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 Data 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 expresa que: 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 homogeneícen entre los distintos departamentos, filiales, etc. Obliga a que todos los componentes de la organización hablen

30

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:

Imagen 4: Metadatos

Fuente: Elaboración propia

31

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. Existe un componente tecnológico, los Operational Data Store (ODS) que 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 cuatro clases de ODS cuya clasificación depende de la rapidez con que llegan los datos a la estructura del ODS: 

Clase I, en 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

32

económicamente. Mayormente se opta simplemente por pasar datos del entorno operacional al ODS sin integrarlos. 

Clase II, en 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, en donde la sincronización de las actualizaciones se produce cada 24 horas, generalmente de noche. Es similar a la clase II, aunque con una implementación marcadamente más económica.



Clase IV, en donde las actualizaciones del ODS son frecuentemente a partir del Data Warehouse pero no están calendarizadas; es decir, existe un largo período de tiempo (incluso meses o años) entre la coordinación del ODS y su fuente. Generalmente 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, debe emplearse 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. Pero a diferencia del Data 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 siempre queda la foto histórica. 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.

33

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 De acuerdo con William Inmon (2005), 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á 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 velocidad de respuesta. Otra explicación para la creación de un Exploration Warehouse es que 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, otra razón es el 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 pre-calculados. Debido a la naturaleza de los requerimientos de explotación, sus datos se encuentran también altamente indexados. Los Exploration Warehouses generalmente están enfocados en proyectos; es decir, una vez terminado un proyecto, desaparecen. Por tanto, tienen una existencia transitoria, lo cual contrasta con un Data Warehouse, ya que éste es de vida permanente. Además, a diferencia de un Data Warehouse, en ocasiones se puede “congelar” la información, sin actualizarla con los datos más nuevos. Dado a que se prueban distintos algoritmos, conviene hacerlos sobre los mismos datos, sin actualizarlos con tanta frecuencia. En algunas situaciones, el Exploration Warehouse puede estar asociado con el Data Mining Warehouse.

34

Data Mining Warehouse De acuerdo con William Inmon (2005), un Data Mining Warehouse es similar en distintos aspectos a un Exploration Warehouse, pero con algunas diferencias: 

El objetivo primario de un Exploration Warehouse es la creación de afirmaciones, hipótesis y observaciones. Un Data Mining Warehouse 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.



Sin embargo, 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.

Herramientas de Business Intelligence Las principales herramientas de Business Intelligence son: 

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.

35



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: Permite 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, p. 132-133)

Herramientas OLAP Josep Lluís Cano expresa 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 sostiene 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

36

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, en Inglés) pensamos en un cubo, puesto que es la representación gráfica habitual del mismo. Como puede verse en el siguiente ejemplo de Josep Lluís 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, cliente 3) y en cada uno de los distintos años (año 1, año 2, año 3):

Imagen 5: Cubo OLAP

Fuente: Josep Lluís Cano (2007, p. 127)

37

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 un Hecho. A su vez, las dimensiones son: 

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 del tipo: 

Año



Mes



Día.

Aunque, dependiendo el modelo de negocio, puede requerirse el análisis por semestre, trimestre, semana, intervalos horarios, día de la semana (lunes, martes, etc.). Por otra parte, las Herramientas OLAP permiten realizar diferentes operaciones sobre los cubos: 

Slice



Dice



Roll-Up



Drill-Down



Roll-Across



Drill-Across



Pivot.

38

Herramientas de Visualización por Lógica Asociativa De acuerdo con 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 realiza 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 fi las) 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.

39

Bibliografía Lectura 1 

Harris, H. (2014, 30 de Abril). The History of Business Intelligence [post de la web]. Recuperado de: http://www.businesscomputingworld.co.uk/the-history-ofbusiness-intelligence-infographic/



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 el 30 de Abril de 2014: http://www.forrester.com/Topic+Overview+Business+Intelligence//E-RES39218?objectid=RES39218



Gartner (s.f.). IT Glossary - Business Intelligence. Recuperado el 30 de Abril de 2014: http://www.gartner.com/it-glossary/businessintelligence-bi



Inmon William (2005). Building the Data Warehouse (4º Edición). Estados Unidos: Wiley Publishing.



Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º Edición). Estados Unidos: Wiley Publishing.



Laudon Kenneth, L. J. P. (2004). Sistemas de Información Gerencial: administración de la empresa digital (8º Edición). 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 2014: http://goo.gl/Xy2REl



Parr Rud, O. (2009). Business Intelligence Success Factors: Tools for Aligning Your Business in the Global Economy. Hoboken, New Jersey: John Wiley & Sons.

www.uesiglo21.edu.ar

40

Módulo 2 Arquitectura de Soluciones de BI

2. Arquitectura de Soluciones “Un Data Warehouse es una colección de información creada para soportar las aplicaciones de toma de decisiones” (Cano, 2007, p. 114)

2.1 Data Warehouse: Definición En el Módulo 1 definimos el concepto de 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, la cual se refiere al 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,

1

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 siempre se almacena en las bases de datos a un bajo nivel de granularidad, es decir, máximo detalle. Sin embargo, en el Data Warehouse (si bien 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 poder responder distintos tipos de consultas.

Imagen 1: Granularidad

Granularidad El nivel de Detalle

Nivel Alto de Detalle Bajo Nivel de Granularidad

Nivel Bajo de Detalle Alto Nivel de Granularidad

Ejemplo: El detalle de cada llamada telefónica realizada por un cliente para un mes

Ejemplo: El resumen de llamadas telefónicas realizadas por un cliente para un mes

Fuente: Elaboración propia en base a William Inmon (2005, p. 42)

2

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 reusabilidad, 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).



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.



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.



Pero el principal beneficio es que 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.



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.

3

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 la necesidad de 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, puede tenerse una tabla detallada y una o más tablas sumarizadas que favorecen determinadas consultas al estar ya precalculadas; es decir, además de contar con una estructura de tablas con todos los registros históricos detallados, 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 sólo un 5% 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 -cómo van las ventas, por ejemplo-, 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. Según William Inmon (2005), y en función de lo anterior, contar con niveles duales de granularidad es la mejor opción arquitectónica para un Data Warehouse.

4

Particionamiento De acuerdo con William Inmon (2005), después de la granularidad, un segundo aspecto de importancia 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



Monitoreadas.

El particionamiento puede hacerse a nivel del motor de Base de Datos (DBMS, DataBase Management System en inglés) o incluso del sistema operativo y a nivel de aplicación. Cada enfoque tiene sus ventajas y sus desventajas. Cuando se hace a nivel de aplicación, presenta un mayor grado de flexibilidad. Los datos pueden dividirse por muchos criterios, tales como: 

Por Fecha



Por Unidad de negocios



Por Región Geográfica



Por Unidad organizacional



Por todo lo anterior.

5

Aunque definitivamente la fecha es un criterio mandatorio, casi siempre es empleado. Incluso, en ocasiones puede ser 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. Imagen 2: Particionamiento

2009 -------------------

2010 -------------------

2011 ------------------2013 -------------------

2012 -------------------

Fuente: Elaboración propia en base a William Inmon (2005, p. 42)

6

2.2 Datawarehouse: Comparación con OLTP Según William Inmon (2005), es importante hacer la 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 en realidad una transformación de los mismos para poder ser usados por los DSS con el objeto de tomar decisiones. Las diferencias son las siguientes: Tabla 1: Comparación con OLTP Datos Primitivos / Operacionales (OLTP)

Datos Derivados / Decisionales (DSS)

Están orientados y organizados según las necesidades de cada aplicación

Esta orientados y organizados por área de interés

Detallado

Detallado y Sumarizado

Preciso al momento del acceso (valores actuales)

Representa valores en el tiempo, históricos, snapshots

Sirve a la comunidad operativa de la organización

Sirve a la comunidad directiva de la organización

Pueden actualizarse

No se actualizan

Las aplicaciones corren repetitivamente sobre ellos

Las aplicaciones corren heurísticamente sobre ellos

Requerimientos de procesamiento comprendidos a priori

Requerimientos de procesamiento NO comprendidos a priori

Compatibles con el ciclo de vida de desarrollo de software

Ciclo de vida completamente diferente

Sensible a la performance

Relajado en cuanto a performance

Accedidos una unidad por vez

Se accede a un conjunto por vez (valores sumarizados)

7

Datos Primitivos / Operacionales (OLTP)

Datos Derivados / Decisionales (DSS)

Gestionado por la transacción

Gestionado por el análisis de información

Control de las actualizaciones en términos de propiedad o dueño del dato

El control de las actualizaciones no interesa

Alta disponibilidad

Disponibilidad más relajada

Gestionado en su completitud

Gestionado por subconjuntos

Sin redundancias

Se permiten las redundancias

Estructura estática, contenido variable

Estructura flexible

Pequeñas cantidades de datos usados en un proceso

Grandes cantidades de datos usados en un proceso

Soporta las operaciones diarias

Soporta las necesidades gerenciales de la organización

Alta probabilidad de acceso a un dato en particular

Baja probabilidad de acceso a un dato en particular

Naturaleza dinámica de los datos

Naturaleza estática hasta el próximo refresh de datos

Se usan para el procesamiento repetitivo de los datos, altamente estructurado

Se usan para el procesamiento analítico de los datos, altamente desestructurado

Estructura con muchas tablas altamente normalizadas

Estructura con pocas tablas denormalizadas

Fuente: Elaboración propia en base a William Inmon (2005, p. 15)

8

En definitiva, según William Inmon (2005) las principales diferencias entre ambos esquemas son: 

Los datos primitivos son datos detallados, usados para ejecutar las operaciones diarias de la organización. Los datos derivados han sido sumarizados o pre-calculados para satisfacer las necesidades de la gerencia.



Los datos primitivos pueden actualizarse. Los datos derivados no pueden re-calcularse 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.

2.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)



El Modelo Multidimensional (propuesto y defendido por Ralph Kimball).

De acuerdo con William Inmon (2005): 

En el Modelo Relacional, los datos están altamente normalizados (tercera forma normal). Esta normalización implica 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 es 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

9

normalizados bajo la tercera forma normal. Así, el modelo Relacional produce un diseño muy flexible. Flexibilidad en términos de que el diseño puede adaptarse a distintas vistas. Esta es la mayor fortaleza junto con la versatilidad, 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, de-normalizados, y alrededor de ella 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: 

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 al servir las necesidades de una comunidad de usuarios en particular, pero no es bueno en cuanto a su flexibilidad.



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 óptimo. En estos términos, el

10

modelo Multidimensional ofrece una performance similar con un acceso directo a los datos.

2.4 Arquitectura La Arquitectura de William Inmon William Inmon (2005) sentó las bases de la primera definición arquitectónica de BI en base al Corporate Information Factory, tal como ya vimos en la Unidad 1 (Módulo 1). Además, sostiene que el modelo Relacional es mucho mejor para el diseño de un Data Warehouse dado 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. Debido al 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 deriva de que: 

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. Según William Inmon (2005), este modelo no garantiza la optimización para todos los usuarios para todos sus requerimientos.

11

La ventaja del modelo Relacional apunta a 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 se deriva de que si para otro usuario se requiere otro cálculo, no es necesario tocar el modelo base, ya que simplemente se agrega 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, al tener que cambiar la misma estructura. Debido a estas causas 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á 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 los cuales se enfocan en el procesamiento de las tablas de dimensión, mientras que 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 debieran cargarse primero en una estructura normalizada previo a 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

12

presentación implican 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, insiste 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 con 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.

13

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 este rol, 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), centrado en procesos, y dentro del Enterprise Data Warehouse Bus Architecture. Este enfoque trae lo mejor de los dos mundos, pero este esquema híbrido sólo puede ser apropiado si la empresa ya invirtió en un Enterprise Data Warehouse normalizad, porque iniciar desde cero implica más costos y más tiempo, tanto en desarrollo como operación continua, dados los múltiples movimientos de datos y almacenamiento redundante de datos detallados.

Desarrollo Iterativo del Data Warehouse De acuerdo con William Inmon (2005), es conveniente construir un Data Warehouse de manera iterativa ya que el usuario es incapaz de articular muchos requerimientos hasta que la primera iteración finalice, además de que la gerencia generalmente no se compromete por completo hasta ver algunos resultados tangibles. Ralph Kimball (2013) sostiene desde su enfoque que usando el Enterprise Data Warehouse Bus Architecture puede desarrollarse un Data Warehouse de manera iterativa, gradual, ágil, descentralizada.

14

2.5 Datamart 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 Data Marts Independiente consiste en diseñarlos directamente desde 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 de un sector en particular, por ello es relativamente fácil, rápido y económico de construir, a la vez que 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 e integrar información a lo largo de la empresa. Generalmente, un único departamento identifica los requerimientos de datos desde un sistema operacional. Así, se construye una base de datos que satisface sus necesidades departamentales, pero este Data Mart departamental refleja sólo los requerimientos analíticos del departamento al trabajar en forma aislada. 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

15

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 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 proporcionan una base para la reconciliación de datos.



No proporcionan 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 es redundante con otros Data Marts independientes de la misma empresa.

Ralph Kimball (2013) también sostiene que es una estrategia de desarrollo rápida, de bajo costo en el corto plazo; pero 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 en una gran cantidad de aplicaciones aisladas y vistas incompatibles del desempeño organizacional. Kimball también desaconseja este enfoque.

Imagen 3: Data Marts Independientes

Fuente: Josep Lluís Cano (2007, p. 118)

16

Data Marts Dependientes Según William 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 se plantea en el Corporate Information Factory). Es decir, el Data Mart dependiente no depende de los datos operacionales, sino del Data Warehouse. Esta estrategia requiere, desde luego, de una mayor inversión, planificación, perspectiva a largo plazo y cooperación y coordinación en la definición de los requerimientos entre los diferentes departamentos de la organización. De acuerdo con William Inmon (2005), un aspecto clave es cómo transferir los datos desde el Data Warehouse hacia el Data Mart. Los datos en un Data Warehouse están muy detallados, con bajo nivel de granularidad. Los datos en un Data Mart suelen estar más compactos y sumarizados. Periódicamente deben enviarse 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 requieren distinto nivel de granularidad. Ahora, para poder alimentar a los distintos Data Marts se requiere que el Data Warehouse tenga el nivel más bajo de granularidad que cualquiera de los Data Marts que alimentará. Imagen 4: Data Marts Dependientes

Fuente: Josep Lluís Cano (2007, p. 118)

17

Modos de Implementación Existen dos modos de implementación de 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. Como afirma el Profesor Hugh J. Watson, 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

18

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.6 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 que se trata de un proceso que utiliza 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.

19

La minería de datos es parte de un proceso iterativo mayor llamado descubrimiento de conocimiento en base de datos (KDD, Knowledge Discovery in Databases en Inglés). Es importante destacar que la minería de datos no reemplaza a las técnicas de estadísticas tradicionales, sino que, 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 (On-Line 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.

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; por ejemplo, los clientes masculinos que compran pañales, viven en el centro y tienen entre 20 y 27 años, generalmente también compran cerveza. De esta forma, los vendedores pueden diagramar la distribución en góndolas (poner estos productos más cerca o más lejos) y planificar su publicidad, entre otras estrategias basadas en este conocimiento.



Control de Calidad: aquí la aplicación se basa en procesar la información de seguimiento de los procesos productivos en busca de desviaciones anormales de los mismos, tendencias y demás indicadores de un proceso fuera de control.



Retención de Clientes: esta área se avoca a la tarea de conservar los clientes y, si es posible, hacerlos leales. En dicho proceso las

20

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 puede informar sobre las características particulares de nuestros clientes leales para obtener un perfil de los mismos y luego focalizar las campañas de incorporación de nuevos clientes en personas con el mismo perfil, es decir, con 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. Es la tarea de conseguir nuevos clientes, es decir, de 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á el blanco de la misma.



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 realizar marketing dirigido es necesario poder 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: 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 los valores de las mismas se correspondan con los riesgos asociados; es decir que no se debe sobrevalorar una póliza que implica un riesgo pequeño y, de la misma forma, tampoco se debe 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

21

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 Entre las principales operaciones de Minería de Datos, podemos mencionar las siguientes: 

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 (entiéndase por el 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 y otras), como así 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, caso en el cual 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, definidos o categorizados en ordinales, los

22

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: 

Clustering: divide o segmenta una base datos en diferentes grupos. El objetivo del Clustering es encontrar grupos que son muy diferentes uno del otro 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, o bien por cuáles atributos los datos serán segmentados. Consecuentemente, alguien que tenga un gran conocimiento del negocio es quien debe 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 (ó simplemente conocido como análisis del ‘changuito’) es un ejemplo bastamente 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, puede ser deseable predecir si los individuos serán clasificados como aquellos que probablemente responderán a un envío de correo o se someterán a un procedimiento quirúrgico, entre otros. 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 (explicada

23

anteriormente), predicciones.

usa

resultados

conocidos

para

guiar

sus

Imagen 5: Aplicaciones, Operaciones y Técnicas de Minería de Datos

Fuente: Elaboración Propia

24

2.7 Balanced Scorecard “Cuando una persona puede medir aquello sobre lo que está hablando y expresarlo con números, sabe alguna cosa sobre la cuestión; pero cuando no puede medirlo, cuando no puede expresarlo con números, lo que sabe es escaso e insatisfactorio” Lord Kelvin (en Paul Niven, 2002, p. 23)

La Insuficiencia de los Indicadores Financieros Paul Niven sostiene en su descripción del Balanced Scorecard que “desde que existen las organizaciones empresariales, el método tradicional para medir los resultados ha sido fijarse en los aspectos financieros” (2002, p. 29). Sin embargo, los indicadores financieros no pueden ser la única forma de medir el desempeño de una empresa. En los últimos años han aparecido numerosas críticas al uso excesivo de indicadores pura y estrictamente financieros: 

Los indicadores financieros muchas veces no son del todo compatibles con la realidad empresarial actual en el sentido de que muchas actividades de valor agregado no se encuentran reflejadas en los activos fijos y tangibles (valores monetarios) de una empresa.



Los indicadores financieros proporcionan una excelente revisión histórica de los resultados pasados de la organización, pero no tienen poder de predicción para el futuro (por ejemplo, si la empresa fue o no rentable el año pasado no significa que sí lo será el próximo año).



Tendencia a reforzar los silos funcionales. Los estados financieros generalmente están discriminados por área o departamento funcional de la empresa, pero no tienen en cuenta el valor y el costo asociado a las interrelaciones entre los departamentos.



Sacrificio del pensamiento a largo plazo. Muchas veces, los esfuerzos por la reducción de costos pueden ser muy útiles para mejorar determinados indicadores financieros en el corto plazo, pero pierden de vista el largo plazo y la capacidad para crear valor

25

agregado en la empresa (ejemplo: reduciendo el presupuesto de investigación y desarrollo). 

Los indicadores financieros no son los adecuados para muchos niveles de la empresa. Los empleados de todos los niveles de la empresa necesitan datos sobre resultados con los que puedan trabajar.

Concepto de Cuadro de Mando Integral Como sostiene Paul Niven (2002, p. 33), “se necesita un sistema que equilibre la exactitud histórica de las cifras financieras con los impulsores de los resultados futuros, al mismo tiempo que ayude a las empresas a poner en marcha sus estrategias diferenciadoras”. En el año 1992, Robert Kaplan y David Norton plantearon el concepto de Cuadro de Mando Integral (BSC, Balanced Scorecard en Inglés). El Balanced Scorecard no es más que un conjunto cuidadosamente seleccionado de indicadores derivados de la estrategia de una empresa, es decir, es una herramienta para medir el desempeño de la empresa.

Perspectivas El Balanced Scorecard está compuesto de cuatro grandes perspectivas: 

Clientes



Procesos Internos



Aprendizaje y Crecimiento



Financiera

Perspectiva Clientes Según Paul Niven (2002, p. 38), “al elegir las medidas (indicadores) que formarán parte de la perspectiva del cliente dentro del cuadro de mando, las empresas deben responder a dos preguntas fundamentales: ¿Quiénes

26

son nuestros clientes? y ¿cuál es nuestra proposición de valor al servirlos?”. Entre los indicadores de clientes generalmente usados en las organizaciones, podemos encontrar los siguientes: -

Satisfacción de los clientes

-

Fidelidad de los clientes

-

Cuota de mercado

-

Quejas de los clientes

-

Quejas resueltas al primer contacto

-

Tasa de rentabilidad

-

Tiempo de respuesta por solicitud de cliente

-

Precio directo

-

Precio en relación con la competencia

-

Costo total para el cliente

-

Duración media de la relación

-

Clientes perdidos

-

Retención de clientes

-

Tasa de adquisición de clientes

-

Clientes por empleado

-

Porcentaje de ingresos por nuevos clientes

-

Número de clientes

-

Ventas anuales por cliente

-

Tasa de ganancia (ventas cerradas / contactos de ventas)

-

Visitas de clientes a la empresa

-

Horas pasadas con los clientes

-

Costo comercial como porcentaje de las ventas

-

Número de anuncios publicados

27

-

Número de propuestas hechas

-

Reconocimiento de marca

-

Tasa de respuesta

-

Número de ferias con participación

-

Volumen de ventas

-

Gastos compartidos por cliente objetivo con clientes

-

Ventas por cada canal

-

Tamaño medio económico de los clientes

-

Gastos por servicios a los clientes por cliente

-

Rentabilidad de los clientes

-

Frecuencia (numero de transacciones de venta)

(Niven, 2002, p. 174)

Perspectiva Procesos Internos En esta perspectiva, de acuerdo con Paul Niven (2002, p. 39), “se identifican los procesos claves en los que la empresa debe destacar para continuar añadiendo valor para los clientes y finalmente para los accionistas”. Para poder satisfacer a los clientes, es necesario que los procesos de negocio internos de la organización funcionen eficaz y eficientemente y de esa manera cumplir con los objetivos de la empresa. Según Paul Niven (2002, p. 39), “nuestra tarea en esta perspectiva es identificar esos procesos y desarrollar las mejoras medidas (indicadores) posibles con las que hacer el seguimiento de nuestros avances”. Entre los indicadores de procesos internos generalmente usados en las organizaciones podemos encontrar los siguientes: -

Costo medio por transacción

-

Entrega a tiempo

28

-

Tiempo de espera medio

-

Rotación de inventario

-

Emisiones medioambientales

-

Gasto de investigación y desarrollo

-

Participación de la comunidad

-

Patentes pendientes

-

Edad media de las patentes

-

Relación productos nuevos / oferta total

-

Falta de existencias

-

Tasas utilización mano de obra

-

Tiempo de respuesta a solicitudes de clientes

-

Porcentaje de defectos

-

Repetición del trabajo

-

Disponibilidad base de datos clientes

-

Momento de equilibrio

-

Mejora de los tiempos cíclicos

-

Mejoras continuas

-

Reclamaciones de garantías

-

Identificación usuario destacado

-

Productos y servicios en la red

-

Tasa de rentabilidad interna de proyectos nuevos

-

Reducción desperdicios

-

Utilización del espacio

-

Frecuencia de compras devueltas

-

Tiempo muerto

-

Exactitud de la planificación

29

-

Tiempo necesario para salir al mercado de nuevos productos / servicios

-

Introducción de nuevos productos

-

Número de historias positivas en los medios

(Niven, 2002, p. 183)

Perspectiva Aprendizaje y Crecimiento En esta perspectiva, de acuerdo con Paul Niven (2002, pp. 39-40), “si se quieren alcanzar resultados ambiciosos con respecto a los procesos internos, los clientes y también los accionistas, ¿qué se puede hacer? Las medidas concernientes a la perspectiva de aprendizaje y crecimiento son verdaderos facilitantes de las otras tres perspectivas”. Debido a lo anterior, también suele decirse que esta perspectiva representa de algún modo los “cimientos” sobre los cuales se estructura el edificio organizacional. Entre los indicadores de aprendizaje y crecimiento generalmente usados en las organizaciones, podemos encontrar los siguientes: -

Participación de los empleados en asociaciones profesionales o comerciales

-

Inversión en formación por cliente

-

Promedio años de servicio

-

Porcentaje de empleados con estudios avanzados

-

Número de empleados con formación cruzada

-

Ausentismo

-

Tasa de rotación

-

Sugerencias de los empleados

-

Satisfacción de los empleados

-

Participación en planes de propiedad de acciones

-

Accidentes y tiempo perdido

30

-

Valor añadido por empleado

-

Índice de motivación

-

Número de solicitudes de empleo pendientes

-

Tasas de diversidad

-

Índice de empowerment (número de directivos)

-

Calidad del entorno laboral

-

Calificación de las comunicaciones internas

-

Productividad de los empleados

-

Números de cuadros de mando producidos

-

Promoción de la salud

-

Horas de formación

-

Tasa de cobertura de competencias

-

Realización de metas personales

-

Oportuna conclusión de valoración de actividades

-

Desarrollo de liderazgo

-

Planificación de la comunicación

-

Accidentes dignos de mención

-

Porcentaje de empleados con ordenadores

-

Ratio de información estratégica

-

Tareas interfuncionales

-

Gestión del conocimiento

-

Violaciones de la ética

(Niven, 2002, p. 191)

31

Perspectiva Financiera Los indicadores financieros siguen siendo, desde luego, un componente central del Balanced Scorecard, pero ya no son las únicas métricas que usaremos. De acuerdo con Paul Niven (2002, p. 40), “las medidas de esta perspectiva nos dicen si la ejecución de nuestra estrategia, detallada a través de medidas elegidas en las otras perspectivas, nos está llevando a resultados finales mejores”. Así, los indicadores financieros tradicionales se encuentran en esta perspectiva. Entre los indicadores financieros generalmente organizaciones, podemos encontrar los siguientes: -

Activo total

-

Activo total por empleado

-

Beneficio como % del activo total

-

Rentabilidad del activo neto

-

Rentabilidad del activo total

-

Ingresos / activo total

-

Margen bruto

-

Beneficio neto

-

Beneficio como % de las ventas

-

Beneficio por empleado

-

Ingresos

-

Ingresos por productos nuevos

-

Ingresos por empleado

-

Rentabilidad de los recursos propios (ROE)

-

Rentabilidad del capital empleado (ROCE)

-

Rentabilidad de la inversión (ROI)

usados

en

las

32

-

Valor económico añadido (EVA)

-

Valor añadido de mercado (MVA)

-

Valor añadido por empleado

-

Tasa de crecimiento compuesta

-

Dividendos

-

Valor de mercado

-

Precio de las acciones

-

Mix de accionistas

-

Fidelidad de los accionistas

-

Flujo de caja

-

Costos totales

-

Calificación crediticia

-

Deuda

-

Relación capital ajeno / capital propio

-

Intereses ganados

-

Días ventas en cuentas a cobrar

-

Facturación cuentas a cobrar

-

Días en cuentas a pagar

-

Días en inventario

-

Ratio rotación de existencias

(Niven, 2002, p. 164)

33

Iniciativas

Iniciativas

Metas

¿Cómo debemos aprender a cambiar, innovar y mejorar para alcanzar nuestros objetivos?

Indicadores

Perspectiva Aprendizaje y Crecimiento

Metas

¿En qué procesos debemos ser excelentes para satisfacer a nuestros accionistas y clientes?

Visión y Estrategia

Objetivos

Iniciativas

Metas

Indicadores

Objetivos

¿Qué necesidades de los clientes debemos satisfacer para tener éxito?

Objetivos

Perspectiva Procesos Internos

Perspectiva Clientes

Indicadores

Iniciativas

Metas

¿Qué objetivos financieros debemos alcanzar para ser exitosos?

Objetivos

Perspectiva Financiera

Indicadores

Imagen 6: Perspectivas del Balanced Scorecard

Fuente: Elaboración propia en base a Paul Niven (2002, p. 37)

Equilibrio en el Cuadro de Mando Integral Como destaca Paul Niven (2002, pp. 47-48), el equilibrio en el sistema del Balanced Scorecard se refiere a tres aspectos: 

“Equilibrio entre indicadores financieros y no financieros.



Equilibrio entre constituyentes internos y externos de la empresa.



Equilibrio entre indicadores posteriores (pasados) y futuros de los resultados”.

34

Desarrollo del Cuadro de Mando Integral Los pasos principales para el desarrollo de un Balanced Scorecard son los siguientes: 

Paso 1: Reunir y distribuir material informativo de fondo.



Paso 2: Desarrollar o confirmar misión, valores, visión y estrategia.



Paso 3: Entrevistarse con la dirección.



Paso 4: Desarrollar objetivos y medidas (indicadores) en cada una de las perspectivas del Cuadro de Mando Integral.



Paso 5: Desarrollar relaciones de causa – efecto.



Paso 6: Establecer metas para las medidas (indicadores).



Paso 7: Desarrollar el plan en marcha para implementar el Cuadro de Mando Integral.

(Niven, 2002, pp. 94-96)

Desde luego, de los pasos anteriores debe quedar claro que la Misión, Visión, Valores y la Estrategia de la empresa seguramente ya existen. El trabajo se concentrará, por lo tanto, en definir los objetivos de resultados para cada una de las cuatro perspectivas. Como sostiene Paul Niven (2002, p. 149): “las declaraciones de objetivos son declaraciones concisas que describen las cosas concretas que hay que hacer bien para poder implementar la estrategia con éxito”. Dichos objetivos deberán estar alineados con la Visión y Misión empresarial. Y por cada objetivo, posteriormente, debemos definir los indicadores. Según Niven (2002, pp. 157-158), “las medidas (o indicadores) de los resultados son las herramientas que usamos para determinar si estamos cumpliendo con nuestros objetivos”. Es decir, los indicadores deben ser cuantificables, con el objeto de poder medir su grado de avance hacia el cumplimiento de los objetivos pautados.

35

Modelización del Negocio Respecto a esta temática, Josep Lluís Cano expresa lo siguiente: Cuando definíamos Business Intelligence […] decíamos que se refiere a un área concreta del negocio: clientes, productos, costes, etc. Cuando nos referimos a un área de negocio siempre pretendemos “medir” un resultado, bien sean ingresos, costes, ventas, etc. La razón que nos lleva a ello está ampliamente desarrollada en la literatura empresarial y se podría resumir como “aquello que no se mide, no se puede gestionar”. El primer paso, por tanto, es definir qué queremos medir, cómo lo vamos a hacer. Para ello debemos definir cuál es nuestro modelo de negocio y cuáles son las métricas que vamos a utilizar. Construir un modelo nos permite analizar qué está sucediendo y para poder construirlo debemos documentar, probar, y desarrollar nuestras teorías acerca de cómo funciona el negocio. Los modelos nos ayudan a experimentar de que manera afectarán los cambios que introduzcamos al resultado. Es importante construir modelos de negocio, ya que en algunos casos no siempre la mejor solución para un departamento es la mejor para toda la organización. Hablamos de “silos de información” cuando entre distintos departamentos no fluye la información necesaria, bien para la gestión o bien para el análisis, dando lugar tanto a problemas de operaciones, como de optimización del negocio. Los “silos de información” pueden ser originados por la no integración de los sistemas de información de los distintos departamentos o por razones políticas dentro de nuestra organización. Los modelos de negocio son simplificaciones de la realidad que nos sirven para comprender qué está sucediendo. Para definirlos podemos acudir a distintas metodologías: Contabilidad Analítica o de Costes, EFQM (European Foundation for Quality Management), SixSigma, Análisis de procesos, Modelos Financieros, Análisis de ratios, etc.

36

Si el modelo de negocio está bien definido nos permitirá responder preguntas clave de la gestión de nuestra organización.

(Cano, 2007, pp. 59-61 y 65)

Indicadores Claves del Negocio (KPI) Los Indicadores Claves del Negocio (KPI, Key Performance Indicator en Inglés) representan una herramienta esencial para saber si la organización está alcanzando o no sus objetivos. Una vez que han analizado su misión, han identificado los grupos de poder y han definido sus objetivos, las organizaciones necesitan un sistema para medir su progreso hacia la consecución de los objetivos. Los KPI son los instrumentos adecuados para llevarlo a cabo. Los KPI deben ser cuantificables y deben medir las mejoras en aquellas actividades que son críticas para conseguir el éxito de la organización. Los KPI deben estar relacionados con los objetivos y con las actividades fundamentales de nuestra organización (aquellas que nos permiten obtener los resultados). Distintas empresas de un mismo sector pueden tener distintos KPI’s en función de sus modelos de negocio, objetivos o su propia idiosincrasia. Los KPI’s que escojamos deben: 

Reflejar los objetivos del negocio.



Ser críticos para conseguir el éxito.



Ser cuantificables y comparables.



Permitir las acciones correctivas.

Si establecemos KPI’s por departamentos deberán estar alineados entre ellos y con los objetivos de la organización. Los KPI’s deben ser establecidos involucrando a los responsables de cada una de las áreas de la organización. Debemos seleccionar aquellos KPI’s que estén relacionados con la consecución de los

37

resultados en la organización, es decir, aquellos que son esenciales para conseguir los objetivos. Debemos escoger un número reducido de KPI’s para facilitar que los distintos miembros de nuestra organización nos centremos en conseguirlos. A tal fin, debemos darles un nombre, una definición, establecer como calcularlos y los valores a conseguir.

(Cano, 2007, pp. 65-67)

Scorecards Como vimos en la Unidad 1 (Módulo 1), una de las herramientas de visualización de Business Intelligence consiste en los denominados ‘Scorecards’. Los mismos están basados en el concepto de Balanced Scorecard. Consisten, básicamente, en herramientas o pantallas de Tableros de Comando en donde se refleja la estructura del Cuadro de Mando Integral: la visión y misión de la empresa, objetivos, indicadores, etc. En un Scorecard puede analizarse la evolución de cada uno de los KPI definidos dentro de un Mapa Estratégico de Balanced Scorecard. A diferencia de un Dashboard (en donde puede verse la evolución de distintos indicadores), en el Scorecard los KPI están clasificados por objetivos a los que pertenecen y éstos enmarcados dentro de cada una de las cuatro perspectivas. Sin lugar a dudas, el desarrollo de un Scorecard es mucho más complejo que un simple Dashboard puesto que implica haber llevado adelante previamente una estrategia de definición del Cuadro de Mando Integral de la organización.

38

Bibliografía Lectura 2 

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º Edición). Estados Unidos: Wiley Publishing.



Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º Edición). Estados Unidos: Wiley Publishing.



Niven, P. (2002). El Cuadro de Mando Integral Paso a Paso. España: Ediciones Gestión 2000.



Two Crows Corporation (1999). Introduction to Data Mining and Knowledge Discovery (3º Edición). Recuperado el 5 de Mayo de 2014: http://www.stanford.edu/class/stats315b/Readings/DataMining.pd f

www.uesiglo21.edu.ar

39

Módulo 3 Modelado Multidimensional

3. Análisis Multidimensional El análisis multidimensional nos facilita 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)

3.1 Introducción al modelado ¿Qué es un Modelo? Un modelo es una abstracción de la realidad que, como sabemos, suele ser muy compleja. En particular, podemos hablar de un modelo de datos, que no es otra cosa que la representación de la estructura de los datos almacenados en un Sistema de Gestión de Bases de Datos (DBMS). El paradigma de modelado de datos por excelencia en los sistemas transaccionales/operacionales es el Relacional. Si bien se utiliza también en las bases de datos analíticas o decisionales, el modelado Multidimensional es, por lejos, el más usado.

1

Modelado Relacional De acuerdo con Josep Lluís Cano (2007, p. 71), “una vez definido el modelo de negocio debemos determinar qué información tenemos para analizarlo”. Para ello, la clave está en comprender el modelo Entidad - Relación de la base de datos origen o fuente de datos. Se trata del modelo relacional desarrollado por E. F. Codd en el año 1970: Está formado por tablas y relaciones entre las mismas. La mayoría de las aplicaciones de gestión utilizan bases de datos fundamentadas en el modelo relacional. El modelo relacional utiliza un lenguaje de interrogación conocido por Standard Query Language (SQL). El modelo relacional se basa, pues en tablas con distintos atributos o campos y las relaciones entre las tablas. Cada tabla tiene una Clave Primaria (“Primary Key” o PK) formada por uno o más atributos y las tablas se relacionan entre ellas mediante las Claves Externas o Foráneas (“Foreign Key” o FK) que actúan como claves primarias en sus propias tablas.

(Cano, 2007, p. 71)

Es decir, en el modelo Relacional tenemos Tablas (Entidades) y Relaciones entre ellas. Cada tabla tiene N atributos o campos, de los cuales los más importantes son la Clave Primaria (PK) y las Claves Foráneas (FK). Y el lenguaje por excelencia para la consulta de datos es el SQL. En el Anexo del libro de referencia de Josep Lluís Cano (2007) se puede encontrar un resumen con las características principales del lenguaje SQL (páginas 353 a 379 inclusive). Una base de datos relacional es una base de datos que es percibida por el usuario como una colección de tablas. Cada tabla está formada por filas (registros o tuplas) y columnas (atributos o campos). Las tablas están compuestas por registros o tuplas y cada uno de los registros tiene distintos atributos o campos. Las tablas o relaciones deben cumplir varios requisitos: 

No existen registros repetidos.

2



El orden de los registros no es significativo.



El orden de los atributos no es significativo.



Los valores de los atributos son atómicos.

Codd propuso las bases de datos relacionales en 1970, pero fue posteriormente, en 1974, cuando Chanberlin y Boyce publicaron un artículo proponiendo un lenguaje estructurado que llamaron SEQUEL, que es el origen del SQL. El modelo relacional fue desarrollado posteriormente por C.J. Date y H. Darven, entre otros. Las bases de datos relacionales tienen al menos dos características: 

La información está integrada, generalmente en un solo lugar de la base de datos. Los usuarios de los distintos procesos acceden a la misma información en una sola ubicación, lo que minimiza las redundancias de información.



La información es relacional, está interrelacionada con otras informaciones en otras partes de la base de datos.

(Cano, 2007, pp. 354-355)

Modelado Multidimensional Como sostiene Josep Lluís Cano (2007), a partir del esquema entidadrelación, original de los sistemas transaccionales, se deberá construir el esquema multidimensional (usualmente tipo estrella, como veremos más adelante en esta misma Lectura) que nos permitirá analizar la información en la base de datos analítica. A pesar de algunas desventajas que ya vimos en la Unidad 2 (según la opinión de William Inmon), de acuerdo con el enfoque de Ralph Kimball (2013) el modelado multidimensional es ampliamente aceptado como la técnica preferida para presentar datos analíticos ya que trata dos requerimientos simultáneos: 

Entregar datos que sean comprendidos por los usuarios del negocio.

3



Responder consultas con rápida performance.

El Modelado Multidimensional es una técnica que permite simplificar el diseño de bases de datos. La simplicidad es crucial porque asegura que los usuarios entienden los datos, además de permitirle al software navegar y entregar resultados rápida y eficientemente. Muchas personas encuentran intuitivo pensar en un negocio en términos de un cubo de datos con los ejes: producto, mercado y tiempo. Los puntos dentro del cubo contienen las métricas tales como volumen de ventas o ganancias. Es decir, el modelado Multidimensional es una técnica que permite representar los requerimientos de datos de forma simple y entendible, ya que se puede ver la información (hechos/indicadores/métricas, generalmente numéricos) desde diferentes puntos de vista (dimensiones). Según Ralph Kimball (2013), si bien los modelos multidimensionales frecuentemente se diseñan también en RDBMS (Sistemas de Gestión de Bases de Datos Relacionales), difieren de los modelos en tercera forma normal en tanto que se permiten eliminar las redundancias. Las estructuras normalizadas dividen los datos en muchas entidades discretas, cada una de las cuales se convierte en una tabla relacional. La industria se refiere a los modelos en tercera forma normal como modelos entidad-relación (o simplemente Modelos Relacionales). Los Diagramas de Entidad-Relación (DER) permiten comunicar las relaciones entre tablas. Tanto los modelos Relacionales como los modelos Multidimensionales pueden representarse con DER porque consisten en tablas relacionadas; la diferencia clave es el grado de normalización. Las estructuras normalizadas son útiles en el procesamiento operacional porque un ‘update’ o un ‘insert’ toca la base de datos en un solo lugar. Los modelos normalizados, sin embargo, son demasiado complicados para las consultas de BI. Los usuarios no pueden comprender, navegar o recordar modelos normalizados. Por otra parte, muchos RDBMS no pueden consultar eficientemente un modelo normalizado; la complejidad de las impredecibles consultas de los usuarios supera los optimizadores de bases de datos causando mala performance. En otras palabras, un modelo multidimensional contiene la misma información que un modelo relacional normalizado, pero empaqueta los datos en un formato tal que permite entregar al usuario un mayor grado de comprensibilidad y performance en las consultas.

4

3.2 RDM vs. MDM Como hemos visto en el Módulo 2, punto 2.3: Tipos de Implementación, existen dos modelos básicos para el diseño de la base de datos de un Data Warehouse: el modelado Relacional (RDM) y el modelado Multidimensional (MDM). Si bien cada uno tiene sus ventajas y desventajas, en la actualidad el modelado Multidimensional, tal como señalábamos en el apartado anterior, se ha convertido en el enfoque más utilizado para el diseño de un Data Warehouse (y/o un Data Mart). Ralph Kimball (2013) establece que existen cinco mitos sobre el modelado Multidimensional: 

Mito 1: Los modelos multidimensionales solamente son para datos sumarizados



Mito 2: Los modelos multidimensionales son departamentales, no empresariales



Mito 3: Los modelos multidimensionales no son escalables



Mito 4: Los modelos multidimensionales sólo son para uso predictivo



Mito 5: Los modelos dimensionales no pueden ser integrados

A continuación, veremos en detalle cada uno de estos falsos mitos, según lo que establece este mismo autor (Kimball, 2013).

Mito 1: Los modelos multidimensionales solamente son para datos sumarizados Dado que no se pueden predecir todas las consultas que harán los usuarios, es necesario que se acceda a los datos detallados. Los datos sumarizados deberían complementar los datos detallados para una mejor performance de consultas comunes, pero no reemplazarlos. Por otra parte, no hay límites en cuanto a la cantidad de registros históricos que pueda tener un modelo multidimensional. 5

Mito 2: Los modelos multidimensionales son departamentales, no empresariales En lugar de tener en cuenta los límites en términos de departamentos organizacionales, los modelos multidimensionales deberían organizarse en términos de los procesos de negocio. Múltiples departamentos frecuentemente quieren analizar las mismas métricas del mismo proceso de negocio. Múltiples extracciones ETL de la misma fuente de datos, que crean múltiples e inconsistentes bases de datos analíticas, deberían evitarse.

Mito 3: Los modelos multidimensionales no son escalables Los modelos multidimensionales son extremadamente escalables; las tablas de hechos frecuentemente tienen millones de filas. Los proveedores de soluciones de BI continúan incorporando capacidades en sus productos para optimizar la escalabilidad y performance de los modelos multidimensionales. Ambos modelos, normalizado y multidimensional, contienen la misma información y relaciones de datos, el contenido lógico es idéntico. Cada relación de datos expresada en un modelo puede ser precisamente expresada en el otro, y ambos modelos pueden responder exactamente las mismas preguntas, aunque varía la dificultad.

Mito 4: Los modelos multidimensionales sólo son para uso predictivo Los modelos multidimensionales no deberían diseñarse enfocados en reportes o análisis predefinidos, sino que el diseño debería centrarse en procesos de medición. Si bien es importante considerar los requerimientos de filtros de las aplicaciones de BI, no debería basarse solo en ello porque esto varía a menudo haciendo al modelo multidimensional muy cambiante. La clave es enfocarse en los eventos de medición de la organización, que

6

generalmente son estables, excepto por los análisis que están continuamente evolucionando. Debido a su simetría, las estructuras multidimensionales son flexibles al cambio. El secreto está en diseñar las tablas de hechos con el máximo nivel de detalle, ya que esto da más flexibilidad y extensibilidad.

Mito 5: Los modelos multidimensionales no pueden ser integrados Los modelos multidimensionales sí pueden ser integrados. Las dimensiones compartidas se diseñan de manera centralizada, persistentes y son reutilizadas entre los distintos modelos multidimensionales para permitir la integración de datos y asegurar una consistencia semántica. La integración de datos depende de etiquetas, valores y definiciones estandarizadas, lo cual requiere de consenso organizacional.

3.3 Componentes MDM Principales Componentes de un Modelo Multidimensional De acuerdo con Ralph Kimball (2013), los principales componentes de un modelo Multidimensional son: 

Hechos



Dimensiones



Elementos



Atributos



Miembros



Tablas de Hechos



Tablas de Dimensión



Esquemas.

7

Hechos Un Hecho es un atributo que representa una métrica del negocio respecto a una o más dimensiones. Se almacenan en las Tablas de Hechos. Ejemplo: Ventas en $.

Dimensiones Una Dimensión hace referencia a los distintos puntos de vista (o perspectivas) a través de los cuales se puede analizar un Hecho. Se almacenan en las Tablas de Dimensión. Ejemplos: Tiempo (año, mes, día, entre otros), Zona Geográfica (país, provincia/estado, localidad, entre otros), etc., lo cual permite analizar, por ejemplo, las Ventas Totales por Provincia y por Mes.

Elementos de Dimensión Un Elemento de Dimensión es un componente de una Dimensión, que permite agrupar lógicamente determinados atributos del negocio. Generalmente, tienen una organización jerárquica para que se pueda navegar la información por distintos niveles de detalle. Ejemplo: la Provincia dentro de la dimensión Zona Geográfica.

Atributos de Dimensión Un Atributo de Dimensión contiene la descripción y otros datos relacionados con cada Elemento de Dimensión. Es decir, un mismo Elemento de Dimensión puede tener varios Atributos. Ejemplo: el elemento Provincia dentro de la dimensión Zona Geográfica tiene varios atributos tales como: Código, Descripción y Región (Sur, Norte, Este, Oeste).

8

Miembro de Dimensión Un Miembro de Dimensión representa cada una de las instancias reales y concretas de una Dimensión en particular. Ejemplo: para la dimensión Zona Geográfica, un miembro es la ciudad de Mendoza en la provincia de Mendoza, en el país Argentina.

Tablas de Hechos para Mediciones Según Ralph Kimball (2013), la tabla de Hechos en un modelo multidimensional almacena las mediciones resultantes de los eventos de los procesos de negocio de una organización. Cada medición debería almacenarse en un único modelo multidimensional. Permitir a usuarios de múltiples departamentos acceder a un repositorio centralizado asegura el uso de datos consistentes. En una tabla de Hechos cada fila se corresponde con un evento de medición y los datos en cada fila están en un nivel específico de detalle/granularidad (por ejemplo: un producto vendido en una transacción de venta). Además, todas las filas deben tener la misma granularidad. Con la disciplina de crear tablas de hechos con igual nivel de detalle se asegura que las mediciones sean correctas. Los hechos más útiles son numéricos y aditivos, como por ejemplo, las ventas en pesos. La aditividad es crucial, porque las aplicaciones de BI rara vez consultan una sola fila de la tabla de hechos; por lo general, consultan miles de filas para traer un valor sumarizado. Sin embargo, hay hechos no aditivos, como el precio unitario, que nunca pueden ser sumados; en cambio, se podrá hacer cuentas o promedios. No se debe almacenar información textual redundante en una tabla de hechos, excepto que el texto sea único por cada fila, caso en el cual debería ir a una tabla de dimensión. Por otro lado, si no hubo ventas para un producto, no debe incluirse una fila con ceros en la tabla de hechos. No obstante, las tablas de hechos consumen el 90% de espacio de una base de datos multidimensional. Dichas tablas tienden a ser profundas en cantidad de filas, pero generalmente de pocas columnas.

9

Todas las tablas de hechos tienen 2 o más claves foráneas (FK) que las conectan con las tablas de dimensión. La tabla de hechos generalmente tiene su propia clave primaria, compuesta por un subconjunto de las FK de las dimensiones. Toda tabla que tenga clave compuesta es una tabla de hechos, dado que expresan relaciones muchos a muchos; las restantes son tablas de dimensión. Por ejemplo, podemos tener una tabla de Hechos con los siguientes campos:

Imagen 1: Tabla de Hechos

Fuente: Elaboración propia

En este ejemplo, por cada combinación de tres Dimensiones distintas: Tiempo (año, mes, día, etc.), Zona Geográfica (país, provincia, localidad, etc.) y Producto (categoría y descripción), contamos con dos Hechos: la Cantidad de Unidades Vendidas del Producto (en cada día y localidad) y el Precio Unitario al cual se vendió. En definitiva, la Tabla de Hechos es el núcleo de un modelo multidimensional. Cada registro de la tabla representa una combinación de los valores claves de las dimensiones, representando, por lo tanto, un evento o una transacción del negocio.

10

Tablas de Dimensión para Contexto Descriptivo De acuerdo con Ralph Kimball (2013), las tablas de Dimensión acompañan a una tabla de Hechos. Aquellas contienen el contexto textual asociado con un evento de medición del proceso de negocio; describen el "quién, qué, dónde, cuándo, cómo y por qué" asociados al evento. Frecuentemente, dichas tablas tienen muchas columnas o atributos. A veces hasta 50 o 100 atributos, aunque algunas tablas de dimensión naturalmente tienen solo unos cuantos. Además, tienden a tener menos filas que una tabla de hechos. Cada tabla se define por una clave primaria (PK) simple, lo que permite integridad referencial con cualquier tabla de hechos. Los atributos de dimensión sirven como la fuente primaria de restricciones de las consultas, agrupamientos y etiquetas de reportes. En una consulta, los atributos se identifican con la palabra "por". Ejemplo: cuando un usuario quiere ver las ventas por marca, las marcas deben estar disponibles como un atributo de dimensión. Los atributos de dimensión juegan un rol clave en un sistema de BI. Deben estar escritos con palabras reales y no abreviaturas. Debe minimizarse el uso de códigos, reemplazándolos por atributos textuales. Cuando los códigos tienen significancia real para los usuarios, deben aparecer como atributos explícitos. El poder analítico de un Data Warehouse es directamente proporcional a la calidad y profundidad de los atributos de dimensión. Las tablas de dimensión suelen representar relaciones jerárquicas. Por ejemplo: los productos podrían agruparse en marcas, y las marcas en categorías. De este modo, por cada fila de la dimensión Producto deberían almacenarse las descripciones de la marca y categorías asociadas. Esta información redundante permite una mayor facilidad de uso y mejor performance de las consultas. Es decir, la característica principal de las tablas de dimensión es la de-normalización. Debería evitarse crear una tabla Marcas y otra Categorías. Cuando se aplica la normalización, se llama copo de nieve. En lugar de usar la tercera forma normal, las tablas de dimensión generalmente están altamente de-normalizadas con relaciones muchos a uno dentro de una misma tabla de dimensión. Dado que tienen un tamaño menor que las tablas de hechos, mejorar la eficiencia de almacenamiento a través de la normalización o copo de nieve casi no tiene impacto sobre el tamaño total de la base de datos. Siguiendo con el ejemplo anterior, tenemos las tablas de dimensión correspondientes a las tres dimensiones mencionadas:

11

Imagen 2: Tabla de Dimensión Tiempo

Fuente: Elaboración propia

Imagen 3: Tabla de Dimensión Zona Geográfica

Fuente: Elaboración propia

Imagen 4: Tabla de Dimensión Producto

Fuente: Elaboración propia

12

Hechos y Dimensiones relacionados en un Esquema Estrella Cada proceso de negocios se representa por un modelo multidimensional que consiste en una tabla de hechos que contiene las mediciones numéricas del evento, rodeada de varias tablas de dimensiones que contienen el contexto textual que fue correcto o verdadero en el momento en que ocurrió el evento. Esta estructura particular se denomina Esquema Estrella. Una de las características de este modelo es su simplicidad: los datos son más fáciles de comprender y navegar gracias al número reducido de tablas y descripciones amigables; además, es beneficiosa en cuanto a la performance, al necesitar las consultas menos joins. Por otra parte, se adapta mejor a los cambios. Es un modelo simétrico. Cuanto más granulares o atómicos sean los datos, mayor dimensionalidad habrá. Los datos detallados deberían ser el fundamento para cada diseño de tablas de hechos. Con los modelos multidimensionales se pueden agregar nuevas dimensiones y hechos, suponiendo que el nivel de detalle es consistente con la tabla existente. Mientras los hechos proveen los valores numéricos de un reporte, los atributos de dimensión proveen los filtros de un reporte.

13

A continuación, podemos ver cómo nos quedó el ejemplo con el esquema Estrella:

Imagen 5: Esquema Estrella

Fuente: Elaboración propia

Como puede deducirse, la consulta SQL escrita o utilizada por una herramienta BI es muy simple. En el SELECT se ubican los atributos de dimensión que se quieren leer, seguida por la métrica correspondiente sumarizada, por ejemplo un SUM (CANTIDAD). La cláusula FROM identifica todas las tablas de dimensión involucradas. En el WHERE se identifica el filtro solicitado en el reporte por el usuario, además de los joins correspondientes, y en el GROUP BY se establecen las distintas sumarizaciones o agrupaciones. Para poder obtener las Ventas Totales es necesario multiplicar los campos CANTIDAD y PRECIO_UNITARIO.

14

3.4 Esquema de Implementación Como adelantamos en los apartados anteriores, pueden establecerse distintos esquemas de implementación de un modelo Multidimensional: 

Estrella (cuando un modelo está de-normalizado, con una sola tabla de hechos y varias tablas de dimensión).



Copo de Nieve (semejante al anterior, pero existen varias tablas normalizadas por cada dimensión, por ejemplo: para la dimensión Zona Geográfica tendríamos tres tablas: País, Provincia y Localidad).



Constelación (cuando se unen varios modelos Estrella a través de dimensiones compartidas).

Esquemas Estrella Según Josep Lluís Cano (2007, p. 75), “para la construcción del esquema estrella debemos distinguir entre las tablas de hechos (aquello que queremos medir o analizar) y las tablas de dimensiones (cómo lo queremos medir)”. Las características del esquema estrella son: 

Una tabla de hechos que contiene los datos sin redundancias.



Una sola tabla por dimensión.



La tabla de hechos (Fact table) tiene un atributo columna que forma la clave de cada dimensión.



Cada tabla de dimensión (Dimension table) es una tabla simple desnormalizada.

(Cano, 2007, p. 79)

El esquema Estrella (Star, en inglés) es el más común y, en general, el más recomendado.

15

Esquemas Copos de Nieve Generalmente, se tiende a no utilizar esquemas Copos de Nieve (también conocidos como Snowflake en inglés). En el esquema “copo de nieve” aparecen relaciones entre las tablas de dimensiones, mientras que en el esquema “estrella” sólo hay relaciones entre la tabla de hechos y las de dimensiones. En este caso, las tablas de dimensiones están totalmente normalizadas, lo que reduce el espacio que ocupan, aunque en algunos casos esta diferencia no es significativa.

(Cano, 2007, p. 80) Para el ejemplo anteriormente mencionado, tendríamos el siguiente modelo de esquema Copo de Nieve, en el cual la dimensión Zona Geográfica es dividida en tres tablas distintas para almacenar las Localidades, Provincias y Países; mientras que la dimensión Producto es dividida en dos tablas distintas, una para almacenar los Tipos de Productos y otra para las Categorías de Productos: Imagen 6: Esquema Copo de Nieve

16 Fuente: Elaboración propia

Esquemas Constelación Es frecuente ver un esquema Constelación (Constellation en inglés) en grandes sistemas de BI en donde hay varias tablas de hechos (es decir, varios modelos multidimensionales unidos a través de dimensiones compartidas). Como indica Josep Lluís Cano, «Cuando unimos distintos esquemas “estrella” que tienen distintas tablas de hechos, pero comparten las de las dimensiones, hablamos de constelaciones de hechos; algunos autores hablan incluso de esquema “galaxia”» (2007, p. 79). Si bien puede haber una Constelación de esquemas Estrella, también podría suceder que se trate de una Constelación de esquemas Copos de Nieve.

Multidimensionalidad Según Josep Lluís Cano (2007, p. 84), “al poder utilizar las distintas dimensiones a la vez estamos utilizando la funcionalidad de la multidimensionalidad. La multidimensionalidad nos permite analizar la información por distintas dimensiones a la vez”. Así, para el ejemplo anterior, podemos analizar las Ventas Totales por varias dimensiones en simultáneo, es decir, ver la evolución de las ventas por cada una de las Provincias de Argentina, para el 3º Trimestre de 2012 y la categoría de Productos de Alta Gama. La multidimensionalidad es un aspecto clave y, desde luego, de muy frecuente consulta por parte de los usuarios finales.

17

3.5 Conceptos relacionados Esquemas Estrella vs. Cubos OLAP Según Ralph Kimball (2013), los modelos multidimensionales implementados en RDBMS son denominados esquemas Estrella por su estructura similar. En cambio, los modelos multidimensionales implementados en bases de datos multidimensionales (MDBMS) son llamados cubos OLAP. Tanto una arquitectura como la otra incluyen modelos multidimensionales, es decir, un diseño lógico común; la diferencia está en la implementación física. Cuando los datos se cargan en un cubo OLAP, se almacenan e indexan usando formatos y técnicas diseñadas para datos multidimensionales. Además, los datos pre-calculados o sumarizaciones son calculadas por el motor OLAP. Por ello, los cubos OLAP tienden a tener mejor performance de consulta. Los usuarios de negocio pueden hacer drill-down o drill-up, agregando o eliminando atributos de sus análisis con excelente performance sin hacer nuevas consultas. Los cubos OLAP también proveen funciones analíticas más robustas que las disponibles en el lenguaje SQL. La desventaja es que se paga un precio en performance de carga, especialmente en grandes volúmenes de datos. Aunque las capacidades de la tecnología OLAP están continuamente mejorando, generalmente se recomienda que la información atómica y detallada se cargue en un esquema estrella sobre un RDBMS. Los cubos OLAP, de desarrollo opcional, luego se cargan a partir del esquema estrella inicial. Hay que tener en cuenta que un cubo OLAP contiene atributos dimensionales y hechos, pero se accede a través de lenguajes con más capacidades analíticas que el SQL; entre ellos, podemos mencionar XML for Analysis (XMLA) y MDX. Estos lenguajes tienen su propia sintaxis, diferente del SQL tradicional.

18

Consideraciones sobre el Despliegue en Cubos OLAP Según Ralph Kimball (2013): 

Un esquema Estrella hosteado en una RDBMS es un buen fundamento físico para diseñar un cubo OLAP, y generalmente es una base más estable para backup y recuperación de datos.



Los cubos OLAP tradicionalmente han sido destacados por presentar grandes ventajas en performance sobre los RDBMS tradicionales; sin embargo, esta distinción se ha vuelto cada vez menos importante con los últimos avances en hardware, BD ‘inmemory’, etc.



Las estructuras de datos de cubos OLAP (MDBMS) son más variables entre los diferentes proveedores de bases de datos que los tradicionales RDBMS, por lo tanto, el despliegue final depende de qué motor OLAP se seleccione. Usualmente es más difícil portar aplicaciones BI entre diferentes herramientas OLAP que entre diferentes RDBMS.



Los cubos OLAP, por lo general, ofrecen opciones de seguridad más sofisticadas que los RDBMS, limitando el acceso a datos detallados pero dando más acceso abierto a datos sumarizados.



Al no tener las restricciones del SQL, los cubos OLAP ofrecen capacidades de análisis significativamente más ricas que los RDBMS. Esta es la principal justificación para utilizar un producto OLAP.



Los cubos OLAP necesitan frecuentemente ser re-procesados parcial o totalmente.



Los cubos OLAP soportan complejas jerarquías de profundidad indeterminada, tales como un organigrama, usando sintaxis de consulta nativa, superior a los enfoques para RDBMS.



Los cubos OLAP pueden imponer restricciones detalladas en la estructura de las claves de dimensión que implementan jerarquías drill-down en comparación con los RDBMS.



Algunos productos OLAP no permiten roles o alias dimensionales, sino que requieren dimensiones físicas separadas para poder ser definidas.

En definitiva, según Ralph Kimball (2013) –y como puede apreciarse en los puntos anteriores-, sólo en determinadas situaciones es recomendable avanzar hacia la inclusión de un MDBMS y un producto OLAP en particular. 19

3.6 Mejoras de Performance Indexación, Tablas Sumarizadas y Particionamiento en el Data Warehouse Como destaca William Inmon (2005), existen diferentes formas para mejorar la performance de las aplicaciones de BI. Puntualmente, podemos mencionar las siguientes técnicas que se pueden aplicar en el Data Warehouse: 

Indexación



Tablas Sumarizadas



Particionamiento

El caso del Particionamiento ya lo hemos analizado en detalle en la Unidad 2 (Módulo 2). Así, para ejemplo de esta unidad, podríamos particionar la tabla de Hechos que contienen las Ventas con una tabla separada por cada año; esto impactará, lógicamente, en el tiempo de respuesta de las consultas que accederán a una cantidad menor de registros. El ítem Indexación es esencial. Al menos las claves primarias de las distintas tablas (especialmente la tabla de hechos) deberían contar con su índice respectivo; pero también es conveniente crear índices para aquellas columnas que generalmente se usan como filtros en los reportes o sobre las cuales hay búsquedas frecuentes por parte de los usuarios. En cuanto a las Tablas Sumarizadas, pueden ser determinantes para la performance de algunas consultas cuando la tabla de hechos contiene una gran cantidad de registros. En estos casos puede haber un procedimiento/algoritmo que se encargue de llenar, por ejemplo, una tabla sumarizada todas las noches con las ventas totales por Categoría de Producto y otra por cada una de las Provincias. En definitiva, la búsqueda de una mejor performance es una actividad de tuning permanente por parte de un especialista en Business Intelligence puesto que aquí se juega, en muchas ocasiones, el prestigio de una solución de BI en términos de performance apropiada.

20

Business Intelligence In-Memory y Visualización por Lógica Asociativa Sin lugar a dudas, el surgimiento en los últimos años de herramientas de BI de lógica asociativa con bases de datos in-memory ha mejorado sustancialmente la performance de las aplicaciones, aunque ello implique dejar de lado algunos de los principios tradicionales en cuanto a diseño arquitectónico. El procesamiento in-memory es una tecnología emergente que habilita a los usuarios a contar con acceso inmediato a los datos con tiempos de respuesta óptimos. Esto se debe a que la tecnología tradicional de BI almacena la información en disco -ya sea tablas o cubos OLAP-. Sin embargo, la tecnología in-memory, como lo indica su nombre, permite que los datos se carguen directamente en memoria RAM. Este tipo de herramientas no sólo obtiene ganancias en performance, sino también en tiempos de desarrollo de aplicaciones de BI; por ejemplo, al evitar la construcción de cubos OLAP. No obstante, si bien algunos proveedores recomiendan el acceso directo a los datos transaccionales por parte de estas innovadoras herramientas, se aduce que no es lo suficiente aconsejable, puesto que si no existe un adecuado proceso ETL que alimente el Data Warehouse podemos perder significativamente niveles de calidad en los datos al no realizarse una apropiada integración y transformación de los datos primitivos operacionales. Muchas organizaciones cometen el error de aplicar la tecnología de BI inmemory sin construir un Data Warehouse. Vale decir, el approach más aconsejable (en caso de optar por este tipo de herramientas) consiste en seguir todos los pasos del Corporate Information Factory hasta la construcción del Data Warehouse/Data Mart, y utilizar las herramientas de BI in-memory/lógica asociativa solamente para la visualización/explotación de los datos. Según uno de los productos líderes en este mercado, las claves para la mejor performance de las aplicaciones de BI in-memory con lógica asociativa están dados por los siguientes aspectos: 

Tiene un motor de inferencia que mantiene las asociaciones entre los datos automáticamente.



Calcula las agregaciones sobre la marcha, según se van necesitando, para una experiencia de usuario ultra rápida.

21



Comprime los datos hasta un 10% de su tamaño original para optimizar la potencia de los procesadores.

(QlikTech, http://goo.gl/BMi8Mr, s.f.)

En este tipo de productos toda la información necesaria se carga inicialmente en la memoria del servidor, lo cual en principio elimina la necesidad de aplicar algún tipo de optimización de bases de datos (tal como la indexación o el particionamiento, por ejemplo). Este repositorio in-memory permanece en memoria hasta que algún usuario realice actividad alguna. Así, se puede cargar en memoria un Data Mart completo o un pequeño Data Warehouse incluso. Por otra parte, muchas de estas herramientas utilizan algoritmos de compresión de datos que reducen el tamaño que los datos ocupan en memoria. El acceso por parte de los usuarios finales a estos datos es más rápido, puesto que no es necesario buscar la información en disco. La mayor demanda de estas herramientas se dio a partir de la confluencia de varios factores, entre ellos: 

Costos reducidos en hardware.



Arquitectura de procesador multi-núcleo.



Memoria flash.



Técnicas y algoritmos de compresión de datos que permiten minimizar el espacio de almacenamiento de los datos una vez que están en memoria.



Sistemas de gestión de bases de datos orientados a las columnas (Column-Oriented DBMS, en inglés).



Sistemas operativos de 64 bits.



Grandes volúmenes de datos que dificultan la ejecución de los procesos ETL (ya sea por aspectos de complejidad de los algoritmos o, más frecuentemente, por la cantidad de tiempo requerido para movilizar datos desde un esquema transaccional hacia el Data Warehouse).

22



Necesidad de analizar la información en tiempo real, dado que de manera frecuente las aplicaciones de BI se usan para tomar decisiones inmediatas a base de los perfiles históricos.



Lógica de Consulta Asociativa (AQL, Associative Query Logic en inglés), que permite relacionar o asociar un determinado campo con cualquier otra columna de la base de datos.



Otros aspectos.

La Lógica de Consulta Asociativa (AQL), mencionada en el párrafo anterior, realmente configura una innovación no solo en términos de performance, sino también en permitir análisis más desestructurados. Por ejemplo, con la tecnología OLAP se diseñan dimensiones preestablecidas; es decir, la lógica de explotación de los datos por parte de un usuario final es muy estructurada en el sentido de que debe seguir la jerarquía de la dimensión, mientras que con AQL es posible detectar todo tipo de cruce de datos sin seguir una jerarquía de navegación preestablecida. Esto se debe a que AQL mantiene todas las asociaciones existentes entre los datos.

Imagen 7: AQL

Fuente: QlikView (2010). QlikView Architectural Overview. Pág. 3

23

4. Administración del Modelo “Las herramientas OLAP permiten a los usuarios finales tratar la información de forma multidimensional para explorarla desde distintas perspectivas y períodos de tiempo.” (Cano, 2007, p. 132)

4.1 Herramientas OLAP En la parte final de la lectura de la Unidad 1 (Módulo 1), pudimos analizar las principales características de una herramienta OLAP. En términos generales, una herramienta OLAP puede ser Cliente/Servidor o Web Enabled: Cliente / Servidor, lo que significa tener las instalaciones locales en los ordenadores de los usuarios. Acceso Web: cliente, cliente ligero, o solo con el navegador. En este tipo de acceso el navegador se comunica con un servidor web, el cual habla con la aplicación del servidor, que es la que conecta con el Data Warehouse. En el caso de acceder con el navegador sin ningún tipo de cliente o con cliente ligero (por ejemplo JAVA), normalmente se descargan pequeñas aplicaciones para aumentar la funcionalidad. Algunos autores también hablan del Virtual o Desktop OLAP (DOLAP). En este caso creamos un cubo con las dimensiones que le interesan al usuario, lo cargamos en memoria en su ordenador, trabaja y, cuando acaba, lo eliminamos de la memoria. La ventaja

24

es que el usuario sólo recibe los hechos y las dimensiones en los que está interesado y los analiza en forma local.

(Cano, 2007, pp. 130-131)

4.2 FASMI De acuerdo con Josep Lluís Cano (2007, p. 126), “el OLAP Council sumarizó las 12 reglas de Codd en lo que ellos llamaban el concepto FASMI y que los productos OLAP deben cumplir”. FASMI es una sigla compuesta por los siguientes anglicismos: 

Fast



Analysis



Shared



Multidimensional



Information

A continuación, vemos lo que representa cada una de ellas: FAST (Rápido): Debe ser rápido, necesitamos lanzar consultas y ver los resultados inmediatamente. ANALYSIS (Análisis): Debe soportar la lógica de negocio y análisis estadísticos que sean necesarios para los usuarios. SHARED (Compartido): Tiene que actualizaciones de forma segura y rápida.

manejar

múltiples

MULTIDIMENSIONAL (Multidimensional): Tiene que proveer de una visión conceptual de la información a través de distintas dimensiones. INFORMATION (Información): Debe poder manejar toda la información relevante y la información derivada.

(Cano, 2007, pp. 126-127)

25

4.3 Almacenamiento OLAP Existen diferentes tipos de herramientas OLAP según su grado de almacenamiento: 

ROLAP



MOLAP



HOLAP

Con las siguientes características principales: ROLAP: Relational OLAP Las capacidades OLAP acceden directamente a la base de datos relacional. Se accede por tanto a una base de datos relacional (RDBMS). Accede habitualmente sobre un modelo “estrella”. La principal ventaja es que no tiene limitaciones en cuanto al tamaño, pero es más lento que el MOLAP, aunque algunos productos comerciales nos permiten cargar cubos virtuales para acelerar los tiempos de acceso. MOLAP: Multimensional OLAP La implementación OLAP accede directamente sobre una base de datos multidimensional (MDBMS). La ventaja principal de esta alternativa es que es muy rápida en los tiempos de respuesta y la principal desventaja es que, si queremos cambiar las dimensiones, debemos cargar de nuevo el cubo. HOLAP: Hybrid OLAP Accede a los datos de alto nivel en una base de datos multidimensional y a los atómicos directamente sobre la base de datos relacional. En esencia, utiliza las ventajas del ROLAP y del MOLAP.

(Cano, 2007, p. 130)

26

4.4 Conceptos Avanzados Proceso de Diseño Dimensional en 4 Pasos De acuerdo con Ralph Kimball (2013), las cuatro decisiones clave que se toman durante el diseño de un modelo multidimensional incluyen los siguientes pasos: 

Seleccionar el proceso de negocio



Declarar la granularidad



Identificar las dimensiones



Identificar los hechos.

Las respuestas a estos interrogantes se determinan considerando las necesidades del negocio junto con las realidades de los datos fuente subyacentes durante las sesiones de modelado colaborativas. Luego de los cuatro pasos, el equipo de diseño determina los nombres de tablas y columnas, valores de dominio de muestra y reglas de negocio. Representantes del negocio deben participar en esta actividad detallada para garantizar su compromiso.

1. Procesos de Negocio Los procesos de negocio son las actividades operativas realizadas por una organización, como por ejemplo: tomar una orden o solicitud, procesar una queja o reclamo, registrar estudiantes en un curso, y otros. Los eventos de un proceso de negocio generan o capturan métricas de desempeño que se traducen en hechos en una tabla de hechos. Muchas tablas de hechos se enfocan en los resultados de un proceso de negocio en particular. Seleccionar el proceso es importante porque define un objetivo de diseño específico y permite declarar la granularidad, las dimensiones y los hechos.

27

2. Granularidad Declarar la granularidad es el paso principal en un diseño dimensional. La granularidad establece exactamente qué representa una fila de una tabla de hechos, y debe declararse antes de seleccionar las dimensiones o hechos, ya que cada uno de estos debe ser consistente con la granularidad. Esta consistencia fuerza a una uniformidad en todos los diseños dimensionales que es crítica para la performance y facilidad de uso de una aplicación BI. La granularidad atómica se refiere al nivel más bajo, en el cual los datos son capturados por un proceso de negocio dado. Ralph Kimball (2013) recomienda iniciar enfocándose en datos de granularidad atómica porque permite resistir el surgimiento de consultas de usuario impredecibles. La granularidad sumarizada es buena para la performance, pero presupone las consultas comunes de los usuarios. Cada granularidad de tabla de hechos propuesta resulta en una tabla física separada; diferentes niveles de granularidad no deben mezclarse en la misma tabla de hechos.

3. Dimensiones para la Descripción del Contexto Las dimensiones proporcionan el contexto: quién, qué, dónde, cuándo, por qué y cómo, circundante a un evento de proceso de negocio. Las tablas de dimensión contienen los atributos descriptivos usados por las aplicaciones BI para filtrar y agrupar los hechos. Con la granularidad de una tabla de hechos en mente, todas las dimensiones posibles pueden ser identificadas. Cada vez que sea posible, una dimensión debería ser valuada cuando se asocia a una fila de un hecho dado. Las tablas de dimensión son algunas veces llamadas el ‘alma’ del Data Warehouse porque contienen los puntos de entrada y etiquetas descriptivas que le permiten a un sistema BI habilitar el análisis del negocio.

28

4. Hechos para Medición Los hechos son las mediciones que resultan de un evento de proceso de negocio y son casi siempre numéricos. Una fila de una tabla de hechos tiene una relación uno a uno con un evento de medición, en función de la granularidad de la tabla de hechos. Por lo tanto, una tabla de hechos corresponde a un evento observable físico y no a la demanda de un reporte particular. Dentro de una tabla de hechos sólo son permitidos los consistentes con la granularidad detallada.

Técnicas Básicas para Tablas de Hechos A continuación, veremos un conjunto de técnicas básicas para las Tablas de Hechos, de acuerdo con los lineamientos de Ralph Kimball (2013).

Estructura de la Tabla de Hechos Una Tabla de Hechos contiene las mediciones numéricas producidas por un evento de medición operacional en el mundo real. En el más bajo nivel de granularidad, una fila de tabla de hechos corresponderá a un evento de medición y viceversa. Por lo tanto el diseño fundamental de una tabla de hechos está completamente basado en una actividad física y no está influenciado por los reportes eventuales que puedan producirse. Además de las métricas numéricas, una Tabla de Hechos siempre contiene claves foráneas (FK) para cada una de sus dimensiones asociadas, así como opcionales claves de dimensiones degeneradas y columnas de fecha/hora. Estas tablas son el objetivo primario de cálculos y sumarizaciones dinámicas en las consultas.

29

Hechos Aditivos, Semi-Aditivos y No Aditivos Las métricas numéricas en una tabla de hechos caen dentro de tres categorías: 

Los hechos más flexibles y útiles son totalmente aditivos. Las métricas aditivas pueden sumarse a lo largo de cualquiera de las dimensiones asociadas con la tabla de hechos.



Las métricas semi-aditivas pueden sumarse a lo largo de algunas dimensiones, pero no todas; por ejemplo, las cantidades de un balance contable pueden sumarse para todas las dimensiones, excepto el tiempo.



Finalmente, algunas métricas son completamente no aditivas, como por ejemplo, los ratios. Un buen enfoque para los hechos no aditivos es, donde sea posible, almacenar los componentes totalmente aditivos de las métricas no aditivas y sumar estos componentes en la respuesta final antes de calcular el hecho no aditivo. Este cálculo final frecuentemente se realiza en la aplicación BI o cubo OLAP.

Valores NULL en Tablas de Hechos Las mediciones que tienen valores NULL se comportan correctamente en las Tablas de Hechos. Las funciones de agregación (SUM, COUNT, MIN, MAX y AVG) se comportan bien con hechos que tienen valores NULL. Sin embargo, los NULL deben evitarse en las claves foráneas de las tablas de hechos porque los mismos causarían automáticamente una violación de la integridad referencial. En lugar de una clave foránea NULL, las tablas de dimensión asociadas deben tener una fila por default que represente un valor desconocido o una condición no aplicable.

Hechos Ajustados Si la misma medición aparece en Tablas de Hechos separadas, deben tomarse resguardos para asegurar que las definiciones técnicas de los hechos sean idénticas si son comparadas o computadas conjuntamente.

30

Si las definiciones de hechos separadas son consistentes, los hechos ajustados deberían ser nombrados idénticamente; pero si son incompatibles, deberían ser nombrados de manera diferente para alertar a los usuarios y aplicaciones BI.

Tablas de Hechos de Transacción Una fila en una Tabla de Hechos de transacción corresponde a un evento de medición en un punto en espacio y tiempo. Las Tablas de Hechos cuyo nivel de granularidad es de transacción atómica/detallada son las tablas más dimensionales y expresivas. Esta dimensionalidad robusta permite el máximo nivel de slicing y dicing de datos de las transacciones. Estas tablas pueden ser o no densas porque las filas solo existen si las mediciones toman lugar. Además, siempre contienen una clave foránea por cada dimensión asociada, y opcionalmente contienen timestamps precisos y claves de dimensiones degeneradas. Los hechos numéricos medidos deben ser consistentes con la granularidad de la transacción. Tablas de Hechos de Snapshots Periódicos Una fila en una Tabla de Hechos de snapshot periódica sumariza muchos eventos de medición que ocurren sobre un período estándar, como por ejemplo: un día, una semana o un mes. La granularidad es el período, no la transacción individual. Estas tablas frecuentemente contienen muchos hechos, ya que cualquier evento de medición consistente con la granularidad de la tabla de hechos es permisible. Además, son uniformemente densas en sus claves foráneas porque aún si ninguna actividad toma lugar durante el período, una fila es típicamente insertada en la tabla conteniendo un cero o NULL por cada hecho.

31

Tablas de Hechos de Snapshots de Acumulación

Una fila en una Tabla de Hechos de Snapshots de Acumulación sumariza los eventos de medición que ocurren en pasos predecibles entre el comienzo y fin de un proceso. Los procesos de workflow, que tienen un punto de inicio determinado, pasos intermedios estándares y punto final definido, pueden ser modelados con este tipo de tablas. Existe una clave foránea de tipo Fecha en la Tabla de Hechos por cada hito crítico en el proceso. Una fila individual en una Tabla de Hechos de Snapshots de Acumulación corresponde, por ejemplo, a una línea en una solicitud o factura (inicialmente se inserta cuando la línea se crea). Cada vez que hay un avance en el workflow, la fila de la tabla de hechos se actualiza. Además de las claves foráneas de fechas asociadas con cada paso crítico del proceso, las Tablas de Hechos de Snapshots de Acumulación contienen claves foráneas para otras dimensiones, y opcionalmente contienen dimensiones degeneradas. Es frecuente que este tipo de tablas incluya mediciones de retraso numérico consistentes con la granularidad, junto con contadores de completitud de los hitos. Tablas de Hechos sin Hechos Aunque muchos eventos de medición capturan resultados numéricos, es posible que el evento solamente registre un conjunto de entidades dimensionales que vienen juntas en un determinado momento. Por ejemplo, un evento de un estudiante asistiendo a clases en un día dado puede que no tenga un hecho numérico registrado, pero que una fila de hechos con clave foránea para el día calendario, estudiante, profesor, ubicación y clase, esté bien definida. Asimismo, las comunicaciones con los clientes son eventos, pero podría no haber métricas asociadas. Las tablas de hechos sin hechos pueden también ser usadas para analizar qué no sucedió. Estas consultas siempre tienen dos partes: una tabla sin hechos que contiene todas las posibilidades de eventos que podrían suceder y una tabla de actividades que contiene los eventos que sucedieron. Cuando la actividad se extrae de la primera, el resultado es el conjunto de eventos que no sucedió.

32

Tablas de Hechos Sumarizadas o Cubos OLAP Las Tablas de Hechos Sumarizadas son simples rollups numéricos de Tablas de Hechos atómicas construidas para acelerar la performance de las consultas. Estas tablas deberían estar disponibles en la capa BI al mismo tiempo que las Tablas de Hechos atómicas, de modo que las herramientas BI seleccionen el nivel de sumarización apropiado en el tiempo de consulta. Este proceso, conocido como agreggate navigation, debe ser abierto de manera tal que cada herramienta de consulta, reporte y/o aplicación BI entre otros- tenga los mismos beneficios de performance. Un conjunto apropiadamente diseñado de sumarizaciones debería comportarse como índice de bases de datos que acelere la performance de las consultas. Las Tablas de Hechos Sumarizadas contienen claves foráneas a dimensiones ajustadas reducidas, así como hechos sumarizados creados sumando métricas de tablas de hechos más atómicas. Finalmente, los cubos OLAP sumarizados con métricas sumarizadas son frecuentemente construidos de la misma manera que los relacionales, pero los usuarios pueden acceder directamente a los cubos OLAP. Tablas de Hechos Consolidados Es frecuentemente conveniente combinar hechos de múltiples procesos juntos en una simple tabla de hechos consolidada si pueden ser expresados a la misma granularidad. Por ejemplo, las ventas actuales pueden consolidarse con las predicciones de ventas en la misma Tabla de Hechos para permitir análisis más simples y rápidos en comparación con ensamblar una aplicación que use tablas separadas. Estas tablas agregan procesamiento adicional a los ETL, pero también facilitan el análisis en la aplicación BI. Además, dichas tablas deben considerarse para métricas de procesos cruzados que frecuentemente se analizan conjuntamente.

33

Técnicas Básicas para Tablas de Dimensión A continuación, veremos un conjunto de técnicas básicas para las tablas de dimensión, de acuerdo con los lineamientos de Ralph Kimball (2013).

Estructura de Tablas de Dimensión Cada tabla de dimensión tiene una única columna PK. Esta clave primaria está embebida como una FK en cualquier tabla de hechos asociada, donde el contexto descriptivo de la fila de la dimensión es exactamente correcto para esa fila de la Tabla de Hechos. Las tablas de dimensión generalmente son tablas de-normalizadas con muchos atributos de texto de baja cardinalidad. Estos atributos son el objetivo primario de restricciones y agrupamientos en las consultas y aplicaciones BI.

Claves Subrogadas de Dimensiones Una tabla de dimensión se diseña con una columna que sirve como única PK; esta no puede ser la clave natural del sistema operacional porque habrá múltiples filas de dimensión para esa clave natural cuando los cambios se sigan en el tiempo. Además, las claves naturales para una dimensión pueden ser creadas por más de un sistema fuente y pueden ser incompatibles o pobremente administradas. El sistema BI necesita tener control de las PK de todas las dimensiones en lugar de usar claves naturales con fechas agregadas; deberían crearse PK enteras anónimas para cada dimensión. Estas Claves Subrogadas de Dimensiones son números enteros, asignados en secuencia, iniciando con el valor 1. La dimensión Tiempo está exenta de esta regla, ya que es una dimensión altamente predecible y estable y puede usar una PK más significativa.

34

Claves Naturales, Durables y Sobrenaturales Las claves naturales creadas por los sistemas operacionales están sujetas a reglas de negocio fuera del control del sistema BI. Cuando el Data Warehouse desea tener una única clave, debe crearse una nueva clave durable, persistente y que no cambie. En ocasiones, se hace referencia a la misma como ‘clave sobrenatural durable’. Generalmente son secuencias numéricas iniciando en 1. Mientras múltiples claves subrogadas pueden estar asociadas, por ejemplo, con un registro de un empleado a lo largo del tiempo, aunque sus datos cambien, la clave durable nunca cambia. Drill Down Drill Down es la forma de análisis fundamental. Significa agregar un encabezado de fila a una consulta existente en la que el nuevo encabezado es un atributo de dimensión añadido a la expresión GROUP BY en una consulta SQL. El atributo puede venir de cualquier dimensión adjunta a la Tabla de Hechos, no requiere la definición de jerarquías predeterminadas.

Dimensiones Degeneradas En algunas ocasiones una dimensión se define porque no tiene contexto, excepto para su PK. Una dimensión degenerada es aquella que no tiene tabla de dimensión asociada. Por otro lado, las Dimensiones Degeneradas son más comunes en las tablas de hechos de snapshot acumulativas y transaccionales.

Dimensiones Aplanadas De-normalizadas En general, los diseñadores dimensionales deben resistir a la normalización, de-normalizando dimensiones con dos objetivos: simplicidad y velocidad.

35

Múltiples Jerarquías en Dimensiones Muchas dimensiones contienen más de una jerarquía natural. En estos casos, las jerarquías separadas pueden coexistir en la misma tabla de dimensión. Por ejemplo: en una dimensión tiempo, jerarquía día-semanames-año fiscal y otra de día-mes-año.

Banderas e Indicadores como Atributos Textuales Las abreviaturas crípticas, banderas verdadero/falso y los indicadores operacionales deberían ser suplementados en las tablas de dimensión con palabras de texto completas que tengan significado cuando se visualicen independientemente. Los códigos operacionales con significado embebido dentro del valor del código deberían ser fragmentados en cada parte del código, expandiéndose en distintos atributos descriptivos de dimensión separados. Atributos NULL en las Dimensiones Los atributos de dimensiones con valor NULL resultan cuando una fila de dimensión dada no ha sido totalmente llenada o cuando hay atributos que no son aplicables a todas las filas de la dimensión. En ambos casos, Ralph Kimball (2013) recomienda sustituir un string descriptivo, tal como por ejemplo: Desconocido o No Aplica, en lugar del valor NULL. Los valores NULL en los atributos de dimensión deberían evitarse porque diferentes bases de datos manejan el agrupamiento o restricciones sobre los NULL de manera inconsistente.

Dimensiones de Fecha Calendario (Tiempo) Las dimensiones de fecha calendario (Tiempo) están adjuntas virtualmente a cada Tabla de Hechos para permitir la navegación a través de fechas familiares, meses, períodos fiscales y días especiales del calendario. La dimensión Tiempo generalmente tiene muchos atributos que describen características tales como nº de semana, nombre del mes, período fiscal o vacaciones nacionales.

36

Para facilitar el particionamiento, la PK de una dimensión Fecha o Tiempo puede ser más significativa, como un entero que representa AAAAMMDD, en lugar de dimensión Tiempo necesita una fila especial para representar fechas desconocidas o a ser determinadas. Cuando se necesita mayor precisión, un timestamp separado puede agregarse a la tabla de hechos. El timestamp no es una FK relacionada con una tabla de dimensión, sino que es una columna aislada. Por otra parte, si los usuarios del negocio restringen o agrupan los datos en base a atributos de la hora del día, debería agregarse una FK separada con los rangos horarios a la tabla de hechos.

Dimensiones ‘Role-Playing’ Una única dimensión física puede ser referenciada múltiples veces en una tabla de hechos, con cada referencia enlazada a un rol lógicamente distinto para la dimensión. Por ejemplo, una tabla de hechos puede tener distintas fechas, cada una de las cuales estará representada por una FK a la dimensión Tiempo. Es esencial que cada FK se refiera a una vista separada de la dimensión Tiempo, de modo que las referencias sean independientes. Estas vistas de dimensión separadas son llamadas roles.

Dimensiones Inútiles Los procesos de negocio transaccionales producen normalmente un número de banderas e indicadores misceláneos de baja cardinalidad. En lugar de hacer dimensiones separadas para cada bandera y atributo, puede crearse una única dimensión inútil combinándolas conjuntamente. Esta dimensión, frecuentemente etiquetada como una dimensión de perfil transacción en un esquema, no necesita ser el producto cartesiano de todos los valores posibles del atributo, sino que debería solo contener la combinación de valores que actualmente están presentes en los datos fuente.

37

Dimensiones Copos de Nieve Cuando una relación jerárquica en una tabla de dimensión es normalizada, los atributos de baja cardinalidad aparecen como tablas secundarias conectadas a la tabla de dimensión base por una clave de atributo. Cuando este proceso es repetido con todas las jerarquías de la tabla de dimensión, una estructura multinivel característica es creada, la cual es llamada copo de nieve. Aunque el copo de nieve representa los datos jerárquicos precisamente, deberían evitarse los copos de nieve porque es difícil para un usuario comprenderlos y navegarlos; a su vez, pueden impactar negativamente en la performance de las consultas. Una tabla de dimensión de-normalizada aplanada contiene exactamente la misma información que una dimensión en copo de nieve. Dimensiones de Refuerzo Una dimensión puede contener una referencia a otra tabla de dimensión. Por ejemplo, una dimensión de Cuenta Bancaria puede referenciar una dimensión separada que represente la Fecha en la cual se abrió la cuenta. Estas referencias a dimensiones secundarias se denominan Dimensiones de Refuerzo; si bien están permitidas, deberían usarse con moderación. En muchos casos, las correlaciones entre dimensiones deben llevarse a una tabla de hechos en donde las dimensiones se representan como FK separadas.

38

Bibliografía Lectura 3 

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º Edición). Estados Unidos: Wiley Publishing.



Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º Edición). Estados Unidos: Wiley Publishing.



QlikTech (2010). QlikView architectural overview (White Paper). Recuperado el 7 de Mayo de 2014: http://www.swbi.co.uk/pdf/QlikView_Architectural_Overview.pdf



QlikTech (s.f.). QlikView es pionero del BI en memoria. Recuperado el 7 de Mayo de 2014: http://www.qlik.com/es/explore/products/overview

www.uesiglo21.edu.ar

39

Módulo 4 Soluciones de BI

5. Herramientas y Soluciones de BI “Existen cuatro tipos de usuarios de una solución de Business Intelligence (BI): Granjeros, Exploradores, Mineros y Turistas”. (William Inmon, 2005)

5.1 Tipos de Usuarios Clasificación de William Inmon De acuerdo con William Inmon (2005), no existe un único tipo de usuario de una solución de BI, sino cuatro tipos distintos, cada uno con sus propias características: 

Granjeros



Exploradores



Mineros



Turistas.

Demográficamente, hay más granjeros que otros tipos de usuarios. Sin embargo, debe aclararse que el mismo usuario puede variar en distintos tipos, comportándose según la ocasión o la tarea. A continuación, analizaremos las principales características de cada uno de estos cuatro tipos de usuarios.

1

Granjeros 

Es el tipo de usuario más predominante.



Es una persona predecible. Hace la misma actividad en forma rutinaria.



Los tipos de consultas varían solo en el tipo de dato de la consulta. Repite el mismo tipo de consulta siempre.



Las consultas tienden a ser cortas; dado que sabe lo que quiere, va directamente a donde están los datos.



Sus consultas tienen un patrón de acceso similar (ejemplo: una vez por semana los lunes a la tarde).



Tiene un alto ratio de probabilidad de encontrar lo que busca.



Acceden a los datos activamente usados en el Data Warehouse.



En el Corporate Information Factory generalmente acceden a Data Marts.

Exploradores 

Es una persona que no sabe lo que quiere. Opera en un modo de completa impredecibilidad. Quizás pasen 6 meses sin que haga una sola consulta y luego haga varias en pocos días.



Tiene el hábito de navegar en grandes volúmenes de datos. No sabe lo que quiere antes de iniciar el proceso de exploración. Busca patrones en los datos que pueden o no existir.



Opera en modo heurístico, es decir, no sabe el próximo paso de análisis hasta completar los resultados del paso actual.



También opera en el marco de proyectos. Cuando se termina un proyecto, el proceso de exploración finaliza.



Muchas veces busca algo y nunca lo encuentra, pero en otras ocasiones, encuentra un diamante del que nadie se había percatado.



Acceden a todos los datos del Data Warehouse.

2



En el Corporate Information Factory, generalmente acceden al Data Warehouse y al Exploration Warehouse.

Mineros 

Es el individuo que navega en pilas de datos y determina si los datos dicen algo o no. A partir de un supuesto, determina su validez a través de herramientas estadísticas.



Opera en proyectos.



Crea consultas enormes en tamaño.



Opera de modo heurístico.



Frecuentemente trabaja en cooperación con un Explorador. El Explorador crea los supuestos e hipótesis y el Minero determina su validez.



Tiene habilidades especiales en matemática que lo diferencia de otros técnicos.



En el Corporate Information Factory, generalmente acceden al Data Mining Warehouse o al Exploration Warehouse.

Turistas 

Es un individuo que sabe dónde encontrar cosas. Tiene una gran amplitud de conocimientos, pero no gran profundidad.



Está familiarizado con los sistemas formales e informales.



Sabe cómo usar Internet.



Conoce sobre metadatos, sabe dónde encontrar índices y cómo usarlos.



Conoce sobre datos estructurados y desestructurados.



Conoce de código fuente, cómo leerlo e interpretarlo.



En el ‘Corporate Information Factory’ generalmente accede al Repositorio de Metadatos.

3

5.2 Tipos de Soluciones Clasificación de Wayne Eckerson y Cindi Howson Por otra parte, de acuerdo con Josep Lluís Cano (2007), en base a la clasificación de Wayne Eckerson y Cindi Howson (2005), podemos identificar dos grandes tipos de usuarios: 

Los productores de información



Los consumidores de información

Para cada uno de los cuales podemos también identificar qué tipo de soluciones son las más apropiadas: Los productores de información: Normalmente se trata del 20% de los usuarios y utilizan herramientas desktop para crear informes o modelos. […] se trata de estadísticos que utilizan herramientas Data Mining o autores de informes que utilizan herramientas de diseño o de programación para crear informes específicos. Habitualmente los autores de informes son: técnicos de sistemas de información no usuarios de negocio avanzados que son capaces de entender la información y la informática. Los usuarios avanzados pueden crear o utilizar informes, por lo que en el gráfico están a medio camino entre los productores y los consumidores de información. Usualmente utilizan hojas de cálculo, herramientas de consulta y de informes para acceder y analizar la información. Los consumidores de información: La mayoría de los consumidores de información son usuarios no habituales que regularmente consultan informes para la toma de decisiones, pero no acceden a los números o hacen análisis detallados diariamente. Los usuarios no habituales son directivos, gestores, responsables, colaboradores y usuarios externos. Este numeroso grupo está bien servido con cuadros de mando con análisis guiados, informes interactivos (por ejemplo: OLAP, informes parametrizados, vinculados) e informes de gestión estandarizados. La mayoría de estas herramientas proveen ahora acceso vía web para promover

4

el acceso desde cualquier lugar y facilitar el uso y minimizarlos costes de administración y mantenimiento.

(Cano, 2007, p. 140) Imagen 1: Tipos de Usuarios y Soluciones según Eckerson y Howson

Fuente: Josep Lluís Cano (2007, p. 141)

Es importante señalar que se diferencian los roles, no los individuos. La mayoría de los usuarios no se adecuan absolutamente a una de las dos categorías. Un ejecutivo podría querer ver información financiera utilizando un informe estático publicado semanalmente, pero ver información operacional en tiempo real utilizando un cuadro de mando. De esta manera, es crítico conocer la información a la que acceden los usuarios y las funcionalidades que necesitan en función de los roles.

(Cano, 2007, p. 141)

5

6. Ciclo de Vida del Business Intelligence “El ciclo de vida de un proyecto de Business Intelligence abarca desde la planificación del proyecto hasta el despliegue, crecimiento y mantenimiento de la solución.” (Ralph Kimball, 2013, p. 404)

6.1 Etapas del Ciclo de Vida Diagrama del Ciclo de Vida de BI De acuerdo con Ralph Kimball (2013), el ciclo de vida de un proyecto de Business Intelligence atraviesa un conjunto de etapas: 

Planificación y Gestión del Proyecto



Definición de los Requerimientos del Negocio



Diseño de la Arquitectura Técnica



Selección e Instalación de Productos



Modelado Multidimensional



Diseño Físico



Diseño y Desarrollo de Procesos ETL



Especificación / Diseño de la Aplicación de BI



Desarrollo de la Aplicación de BI



Despliegue



Crecimiento



Mantenimiento.

6

A continuación, se presenta un diagrama del ciclo de vida en donde se aprecia cómo se interrelacionan las distintas etapas / tareas:

Imagen 2: Diagrama del Ciclo de Vida de un Proyecto de BI

Fuente: Elaboración propia en base a Ralph Kimball (2013, p. 404)

6.2 Pasos de cada Etapa A continuación, describiremos las características principales de cada etapa de acuerdo con lo enunciado por Ralph Kimball (2013).

Etapa de Planificación y Gestión del Proyecto Todo proyecto de Business Intelligence inicia con una serie de actividades ligadas a la planificación del proyecto, incluyendo: 

Evaluación de si la organización está preparada para iniciar un proyecto de BI, en base a tres factores críticos: -

Contar con el apoyo de los directivos;

-

contar con una motivación comercial que justifique el proyecto de BI;

-

que exista factibilidad tanto técnica como a nivel de recursos, pero especialmente la factibilidad para acceder a los datos transaccionales / operacionales.



Definición del Alcance del proyecto (por ejemplo, iniciar con un sólo proceso de negocio) y la justificación del mismo, lo cual está relacionado con realizar una estimación de los beneficios y costos asociados al proyecto.



Conformación de un equipo de personas que sea multi-disciplinario preferentemente. El equipo estará constituido por varios perfiles; entre ellos podemos encontrar: -

Sponsor del Negocio (cliente): correspondiente al directivo que promueve el proyecto

-

Líder del Negocio (quién conoce más sobre el negocio y quién será el referente con el que se comunicará el líder del proyecto)

-

Usuarios Finales

-

Analistas del Negocio / Analistas Funcionales

-

Administrador de Datos (Data Steward)

-

Arquitecto / Diseñador de BI



-

Desarrollador de Aplicaciones de BI

-

Project Manager

-

Arquitecto Técnico

-

Arquitecto de Datos

-

Modelador de Datos

-

Administrador de Bases de Datos (DBA)

-

Coordinador de Metadatos

-

Arquitecto / Diseñador ETL

-

Desarrolladores de Procesos ETL.

Desarrollo y mantenimiento del plan del proyecto de BI, el cual identifica todas las tareas necesarias del ciclo de vida. Aquí es clave la estimación del esfuerzo requerido en cada tarea así como los criterios de aceptación e hitos del proyecto.

Etapa de Definición de los Requerimientos del Negocio Incluye: 

Pre-planificación de los requerimientos, que consiste básicamente en seleccionar el lugar adecuado para llevar adelante las sesiones/entrevistas de captura de requerimientos. Además, se debe identificar y preparar el equipo que realizará el relevamiento y captura de requerimientos, al igual que seleccionar apropiadamente los responsables del negocio/usuarios que serán entrevistados, si esto fuera posible.



Captura de los requerimientos del negocio.



Conducción de entrevistas centradas en los datos, es decir, teniendo sesiones con los expertos en los sistemas transaccionales/operacionales.



Documentación de los requerimientos.



Priorización de los requerimientos.

9

Etapa de Diseño de la Arquitectura Técnica Incluye: 

Establecer un mini-equipo dedicado y enfocado en el diseño de la arquitectura. Generalmente está compuesto por el Arquitecto Técnico junto con el Arquitecto ETL y el Arquitecto BI.



Captura de los requerimientos relacionados con la arquitectura técnica.



Documentación de los requerimientos de arquitectura.



Creación del modelo de arquitectura técnica del proyecto.



Determinación de las fases de implementación de la arquitectura.



Diseño y especificación de los sub-sistemas.



Creación del plan de arquitectura técnica.



Revisión y finalización de la arquitectura técnica.

Etapa de Selección e Instalación de Productos Incluye las siguientes tareas: 

Comprensión del proceso corporativo interno de compras.



Desarrollo de una matriz de evaluación de productos.



Conducción de investigaciones de mercado.



Evaluación de productos a partir de una lista reducida preseleccionada de opciones.



Diseño de un prototipo, si fuera necesario.



Selección de los productos.



Instalación de versiones trial de los productos.



Negociación comercial con los proveedores de los productos.

10

Etapa de Modelado Multidimensional Esta etapa corresponde al modelado de las estructuras multidimensionales del Data Warehouse y/o Data Mart.

Etapa de Diseño Físico Los modelos multidimensionales desarrollados y documentados necesitan traducirse en una base de datos física. Con el modelado multidimensional, los diseños lógico y físico suelen ser bastante similares. Los detalles de implementación de la base de datos física pueden variar ampliamente por plataforma y proyecto. Esta etapa incluye: 

Desarrollo de estándares de bases de datos, como por ejemplo, nombres de tablas y columnas.



Desarrollo del modelo físico de base de datos.



Desarrollo del plan de indexación inicial.



Diseño de sumarizaciones, incluyendo el diseño de los cubos OLAP, si es que se incluyen en el proyecto de BI.



Finalización del almacenamiento físico (bloques, archivos, discos, particiones y tablespaces, entre otros aspectos).

Etapa de Diseño y Desarrollo de Procesos ETL En esta etapa se lleva adelante el diseño arquitectónico general de cada uno de los procesos ETL y posteriormente el desarrollo propiamente dicho de los mismos.

11

Etapa de Especificación / Diseño de la Aplicación de BI Una vez definidos los requerimientos del negocio, se necesita establecer un conjunto inicial de aproximadamente 10 a 15 reportes y aplicaciones analíticas de BI. Antes de proceder a desarrollar las aplicaciones de BI, es necesario también establecer ciertos estándares tales como el look & feel que tendrán los distintos dashboards, por ejemplo.

Etapa de Desarrollo de la Aplicación de BI La actividad de desarrollo puede iniciarse cuando el diseño de la base de datos esté finalizado, las herramientas BI instaladas y un subconjunto de datos históricos se carguen en la base de datos.

Etapa de Despliegue El despliegue depende de la convergencia exitosa entre la tecnología, los datos y las aplicaciones de BI. Es claro que las tareas relacionadas con los procesos ETL suelen ser las más impredecibles, puesto que podemos encontrarnos con cualquier tipo de complejidad en los datos, muchas de las cuales pueden no haber sido contempladas. También en el despliegue es necesario realizar un testing end-to-end final, incluyendo el aseguramiento de la calidad de los datos, el procesamiento correcto de las distintas operaciones y procedimientos, issues de performance y, por supuesto, un testing de usabilidad. También un punto crítico en esta etapa consiste en la capacitación de los usuarios finales de las nuevas herramientas de BI.

12

Etapas de Crecimiento y Mantenimiento Luego de la implementación en producción será necesario un trabajo de mejora continua incluyendo: 

Soporte técnico



Soporte funcional



Capacitación



Nuevas funcionalidades.

A diferencia de los sistemas tradicionales, el cambio en los proyectos de BI debe visualizarse como una medida del éxito de su despliegue y uso.

6.3 Core Team De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy y Bob Becker (2008), el Core Team soporta el grueso de la responsabilidad en el diseño y desarrollo del sistema de BI.

Analista de Negocio / Analista Funcional El Analista de Negocio o Analista Funcional es el responsable de liderar las actividades de definición de requerimientos del negocio, como así también de representar estos requerimientos en la especificación de arquitectura técnica, modelo multidimensional y aplicaciones de BI. El rol del Analista de Negocio generalmente se cubre con una persona de Sistemas que esté extremadamente centrada en el usuario y conozca del negocio. Alternativamente, podría cubrirse también con una persona de la organización que conozca bastante del negocio y que no sea del Departamento de Sistemas, pero debe contar con sólidos fundamentos técnicos. En proyectos más pequeños, el propio Project Manager o el Líder del Proyecto del Negocio puede cubrir esta misma posición. El Analista del

13

Negocio debe contar con fuertes habilidades comunicacionales. Por otro lado, ser respetado por los clientes/usuarios resulta un plus adicional, teniendo en cuenta que dicho Analista estará representando al resto del equipo del proyecto en cuanto a la definición de requerimientos.

Administrador de Datos / Analista de Aseguramiento de la Calidad (QA) El Administrador de Datos, o Data Steward en Inglés, es el responsable de gestionar el acuerdo organizacional en cuanto a las definiciones, reglas de negocio, valores de dominio permitidos para el Data Warehouse, además de la posterior publicación de estas definiciones y reglas. Históricamente se refirió a este rol como el DBA (DataBase Administrator en Inglés), una función dentro de Sistemas. Sin embargo, es conveniente que este rol sea cubierto por un experto en la materia/área de interés de la aplicación de BI por parte del propio negocio/cliente. Además, este es un rol políticamente cambiante. Deben ser líderes altamente respetados, comprometidos con el trabajo a través de inevitables cruces inter-funcionales y apoyados por alta gerencia, especialmente cuando se requiere del compromiso organizacional. Algunas veces trabaja en conjunto con los Analistas de Aseguramiento de la Calidad (QA) quienes garantizan que los datos cargados en el Data Warehouse sean precisos y completos, identifican potenciales errores en los datos y buscan su resolución. En ciertas ocasiones, el Analista QA también es responsable de verificar la integridad funcional de las aplicaciones de BI. Además, tiene una carga de trabajo significativa durante la carga de datos inicial para asegurar que los procesos ETL trabajen correctamente. Dada la necesidad de una verificación continua de los datos, el rol no finaliza aunque el Data Warehouse entre en producción.

14

Arquitecto de Datos/Modelador de Datos/Administrador de Bases de Datos (DBA) El Arquitecto de Datos es responsable de desarrollar la estrategia arquitectónica de datos general del sistema de BI asegurando la reusabilidad, la integración y la optimización. El Modelador de Datos es responsable de realizar el análisis detallado de los datos y de desarrollar el modelo de datos multidimensional. Su rol tiene gran influencia en el éxito del proyecto, los modelos bien diseñados son más fáciles de implementar al mismo tiempo que satisfacen los requerimientos de los usuarios. Para este rol se requiere de gran conocimiento de las estructuras de datos de los sistemas corporativos como así también de las reglas del negocio. Si bien es valiosa su experiencia previa en modelado de estructuras de datos, es clave que no esté demasiado "atado" al pensamiento ligado al modelo relacional y al diseño normalizado tradicional para poder seguir las técnicas de diseño multidimensional. En caso de usarse OLAP, esta persona frecuentemente diseña tanto el modelo multidimensional sobre el RDBMS como sobre el MDBMS, en conjunto con el desarrollador de la aplicación de BI. El Modelador de Datos participa en la actividad de definición de requerimientos en un rol secundario. El Administrador de Bases de Datos (DBA, Data Base Administrator en inglés) se encarga de traducir el modelo multidimensional en una estructura física de tablas. En algunos casos también está involucrado en el proceso de modelado multidimensional; por lo tanto, las personas que cubran este rol deben estar, como mínimo, familiarizadas con estas técnicas de diseño. El DBA es responsable del diseño físico general, incluyendo aspectos tales como particionamiento, plan de índices y otros. Además, el DBA también es responsable del soporte operativo diario de la base de datos asegurando la integridad de datos, disponibilidad y performance.

15

Coordinador de Metadatos Es necesario que alguien tome la responsabilidad de coordinar los metadatos, puesto que pueden estar ubicados en cualquier parte del sistema de BI. En este rol de Coordinador de Metadatos no se es responsable de cargar los metadatos, sino de asegurar que todos los componentes contribuyen a su carga, desde los sistemas transaccionales fuente, pasando por el ETL y hasta las herramientas de visualización de BI. Esta persona tiene la última palabra sobre qué metadatos se conservan, dónde se ubican y cómo se publican a los usuarios.

Arquitecto ETL/Desarrollador ETL El Arquitecto/Diseñador ETL es responsable del diseño end-to-end del proceso ETL. El desarrollo de procesos ETL requiere de fuertes habilidades en diseño modular de sistemas. Este rol muchas veces no se cubre y el desarrollador debe codificar sin plan alguno. El Arquitecto/Diseñador ETL debería estar involucrado en la captura de requerimientos y tener una relación laboral permanente con el equipo de la aplicación de BI. Los Desarrolladores ETL construyen, prueban y automatizan los procesos ETL bajo la dirección del Arquitecto ETL. Quien asuma este rol debe tener un conocimiento íntimo de los sistemas transaccionales/operacionales para ayudar en el mapeo, así como un conocimiento básico de los modelos multidimensionales destino.

Arquitecto BI/Desarrollador de Aplicación BI El Arquitecto BI tiene la responsabilidad general del sistema BI asegurando que todo el entorno de BI esté optimizado para tratar los requerimientos del negocio. El Arquitecto BI establece el framework y refuerza los estándares que son usados por los desarrolladores BI.

16

El Desarrollador de Aplicaciones de BI crea y mantiene las aplicaciones de BI, generalmente usando software de Query & Reporting; además es responsable de configurar la capa semántica de la herramienta de BI. Este rol requiere de conocimientos en bases de datos y también habilidades en programación, junto con una profunda comprensión del negocio y sus requerimientos.

6.4 Extended Team De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy y Bob Becker (2008), el Extended Team está conformado por roles adicionales que contribuyen al proyecto de BI, pero sobre aspectos muy especializados o temas puntuales. Desde luego, los roles que aquí mencionamos también pueden ser llevados a cabo por las personas que conforman el Core Team.

Arquitecto Técnico/Arquitecto de Seguridad El Arquitecto Técnico/Arquitecto de Seguridad es responsable del diseño de la infraestructura técnica y la estrategia de seguridad para soportar el Data Warehouse. Para desempeñar este rol no se necesita ser un experto en todas las tecnologías de infraestructura y seguridad, sino que más bien debe proveer cohesión general para asegurar que los componentes se ajusten entre sí.

Especialistas en Soporte Técnico Dependiendo de la organización, puede haber especialistas enfocados en sistemas cliente/servidor, redes, comunicaciones, etc. Estos Especialistas en Soporte Técnico están involucrados en las etapas iniciales del proyecto para realizar un análisis de recursos y capacidad de equipos. Además, durante la selección de los productos aseguran la compatibilidad con el entorno tecnológico existente. Una vez seleccionada la tecnología, proceden a la instalación y configuración de los nuevos componentes; también proveen de soporte continuo en producción. 17

Programador de Data Staging El Programador de Data Staging es un programador cuyo rol puede ser cubierto incluso por el desarrollador ETL, pero en este caso, si se usa alguna estructura de Preparación de Datos (Data Staging, en inglés) se requerirá entonces de un rol especializado para esta etapa intermedia entre el ETL y antes de que los datos lleguen al repositorio definitivo del Data Warehouse.

Consultores Externos Desde luego, en más de un proyecto se requerirá de uno o más Consultores Externos especializados en alguno de los roles mencionados anteriormente.

18

7. Taller “Escoger aquella herramienta de Business Intelligence que mejor satisfaga las necesidades de los usuarios en cuanto a las funcionalidades, con la mejor arquitectura y al mejor coste, no es una tarea fácil” (Cano, 2007, p. 163)

7.1 Elección herramienta Múltiples Alternativas Uno de los primeros puntos a definir a la hora de encarar un proyecto de Business Intelligence consiste en identificar qué herramientas vamos a utilizar. Se debe tener en cuenta que existen múltiples opciones, puesto que hay muchas empresas que proveen este tipo de software (como puede verse en el capítulo VI de Josep Lluís Cano, 2007). Para poder seleccionar correctamente las herramientas de BI que vamos a utilizar, es importante tener en cuenta las características de nuestros usuarios. Josep Lluís Cano (2007), en base a un trabajo de Jonathan Wu (2000), establece que el proceso de selección de las herramientas puede ser formal o informal.

Proceso de Selección Informal Según Josep Lluís Cano (2007, p. 164), “Comúnmente, las organizaciones no establecen un proceso formal de selección de software y, desafortunadamente, en la mayoría de los casos este procedimiento no produce los resultados esperados”.

19

Es posible, por lo tanto, que una organización haya adquirido inapropiadamente un software porque no ha destinado los suficientes recursos en tiempo y dinero para seleccionar la solución. La elección de una solución de Business Intelligence no se puede tomar de cualquier manera: Algunas organizaciones se ven obligadas a cambiar de proveedor al cabo de uno o dos años. Los costes para la organización no son tan sólo los de adquisición de las licencias, sino también los del proyecto de implementación, que incluyen tanto los de formación de los usuarios como los de conseguir el conocimiento necesario por parte de la organización para que la solución sea utilizada. Debemos tener en cuenta el coste, los requerimientos funcionales y la arquitectura tecnológica.

(Cano, 2007, p. 165)

Proceso de Selección Formal Según Josep Lluís Cano (2007, p. 165), “Con un proceso formal de selección de software la probabilidad deseleccionar la mejor herramienta para la organización se incrementa sustancialmente”. El autor describe un conjunto de etapas y tareas a seguir para la selección formal de software de BI, en base a dos metodologías distintas: la de Jonathan Wu y la de Wayne Eckerson y Cindi Howson:

Metodología de Jonathan Wu 1. Inicio del proyecto: 1.1. Alcance y objetivos. 1.2. Equipo. 1.3. Comunicación del inicio. 2. Análisis de los procesos de negocio: 2.1. Comprender los procesos actuales y su información asociada.

20

2.2. Identificar las mejores prácticas que apoyan a los objetivos de negocio. 2.3. Análisis de las diferencias. 2.4. Desarrollar como deberían ser los procesos en el futuro. 3. Definir los requerimientos: 3.1. De negocio: 3.1.1. Presupuesto y plazos. 3.1.2. Requerimientos de información directiva. 3.2. Funcionales: 3.2.1. Estado de las necesidades de negocio. 3.3. Técnicos: 3.3.1. Estándares de sistemas. 3.3.2. Diagramas de flujo. 3.3.3. Interfaces de sistemas. 4. Punto de decisión: Construir (¿realmente queremos construir la solución en lugar de utilizar uno de los productos disponibles en el mercado?) versus comprar. 5. Gestión de los proveedores: 5.1. Demostraciones. 5.2. Análisis de sus ofertas. 5.3. Ranking de las soluciones de los proveedores. 5.4. Negociación

(Cano, 2007, pp. 165-166)

21

Metodología de Wayne Eckerson y Cindi Howson 1. Deberíamos constituir el Comité de Selección de la herramienta de Business Intelligence. Debería estar formado por todos los stakeholders de los distintos departamentos, incluido el de Sistemas de Información. En el Comité debería participar algún directivo que actúe como sponsor del proyecto. Si tenemos usuarios con experiencia deben participar en él. Para quesean efectivos, los comités deben estar compuestos por pocos miembros. 2. Definir los usuarios y los escenarios de uso: muchas organizaciones no se preocupan demasiado por los usuarios. Su foco es crear un Data Mart o un informe, y no definir cuál es la información que se necesita y para qué rol y nivel de la organización. Se hace necesario definir quién interactuará con un informe y cómo, ya que los diferentes tipos de usuarios requieren distintas herramientas e interfaces. Comprender los segmentos de usuarios es crítico para gestionar el alcance en la selección y resolver los conflictos de los requerimientos. Siguiendo este proceso, puedes descubrir que distintos grupos de usuarios que tienen los mismos requerimientos quieren soluciones distintas. 3. Refinar los requerimientos de información: Cada herramienta de Business Intelligence soporta modelos y esquemas ligeramente diferentes, lo cual es crítico para incorporar los requerimientos en el proceso de selección. Por ejemplo, los usuarios quizás necesiten analizar las ventas con los inventarios para calcular “inventarios por días de venta” de varios grupos de productos y periodos de tiempo. Este simple requerimiento se convierte en una serie de características técnicas: 1) multi SQL para consultar dos tablas del Data Warehouse; 2) capacidad para agregarlos inventarios por grupos de producto, pero no a través de periodos de tiempo; 3) suma automática de filas individuales de información para poder ver los totales del año o por grupos de productos. Las distintas herramientas de BI solventan estos requerimientos de formas absolutamente distintas. El Comité de Selección debe comprender las diferencias y saber qué aproximación será mejor para la organización. 4. Definir los criterios de selección y su peso. Hay varias metodologías para capturar los requerimientos de los usuarios: Entrevistas individuales, análisis de la diferencia o sesiones de tormenta de ideas. La clave, sin embargo, es trasladar los

22

requerimientos a las capacidades de la herramienta de Business Intelligence. Por ejemplo, es difícil que los usuarios digan: “Queremos una herramienta de BI con una capa de metadata”. Lo que probable mentedirán es que quieren crear sus propios informes sin necesidad de conocer su lenguaje. Los criterios más utilizados son viabilidad del vendedor, estrategia del vendedor, funcionalidades (en consultas, en informes, en entrega de información, integración con hojas de cálculo, cuadros de mando, administración, arquitectura, coste, formación y soporte). Deberemos priorizar cada criterio con un peso. Si se quieren consultar ejemplos de listas de criterios, se pueden consultar en www.BIScorecard.com. 5. Solicitudes de información (RFI). Generan mucho trabajo para el vendedor y poco valor para el comprador; muchos vendedores dicen “sí” a todos los requerimientos. Para ser justos, algunos vendedores son más honestos que otros y los requerimientos están sujetos a interpretación. Por ejemplo, si necesitas una arquitectura tecnológica basada en Unix, los vendedores que no soportan Unix pueden ser eliminados. Para aumentar el valor del RFI, se deben incluir aquellos requerimientos que sean decisivos en la selección o en la estandarización: Preguntar cómo las herramientas específicas solucionan los requerimientos de los usuarios. Las preguntas abiertas, al final, pueden mostrar luz sobre la aproximación del vendedor y el interés que tiene por el proyecto. Los vendedores que atienden cuidadosamente las respuestas en lugar de los que utilizan material preparado y empaquetado por marketing son más validos. 6. Demostraciones: El Comité debe ver las distintas demostraciones de los proveedores y debe prepararse un orden del día para cada vendedor. En el orden del día debe disponerse de tiempo para hablar de las consideraciones estratégicas, así como de las capacidades del producto. Se debe invitar a usuarios que no participan en el Comité a las demostraciones para poder obtener su opinión y asegurar que han participado en el proceso de decisión, preguntándoles cuál es su valoración de la habilidad de los vendedores en cubrir sus requerimientos específicos. Las demostraciones se pueden basar en los datos del vendedor o en los propios de la organización: El uso de los de la organización puede ayudar a comprender mejor las diferencias entre herramientas, aunque requiere una inversión en tiempo mayor para el vendedor y la propia organización. Esta alternativa vale la

23

pena si tenemos pocas alternativas, ya que si el número de productos es muy elevado no es demasiado práctica. 7. Determinar cuál es la herramienta que se ajusta más: Usando los requerimientos definidos en el punto 4, puntuar los criterios y las demostraciones; incorporar consideraciones estratégicas, información cualitativa e información de clientes de la herramienta para saber cuál de ellas y qué proveedor se ajusta mejora corto y largo plazo a nuestra organización. Si la elección está clara, no se deben abandonar las segundas alternativas completamente: Debemos todavía probar el concepto, negociar el contrato o poner a prueba si nuestra primera elección tiene problemas insuperables. 8. Probar el concepto: Sólo deberíamos tener uno o dos proveedores posibles al llegar a esta fase. Es la oportunidad de probarla herramienta en nuestro entorno. Únicamente es una prueba, aunque en este punto es importante conseguir que el Comité esté centrado en los requerimientos críticos más que en jugar interminablemente con la herramienta o intentando crear informes. La prueba del concepto sirve para elegir entre las alternativas, su propósito es confirmar que el producto funciona como se espera. Para ello deberemos escoger un grupo de informes, limitando el alcance, para probar el concepto. Los informes de ejemplo pueden basarse en los requerimientos definidos en el punto 3 y que sean moderadamente complejos (se trata de que no sean simples listados, pero tampoco tan complejos que un programador experimentado tenga que destinar un mes completo para crearlos). La prueba del concepto nos dará la idea de cómo debemos adaptar el resto de nuestra arquitectura de BI, pero no es la clave definitiva para resolver los problemas de implementación.

(Cano, 2007, pp. 166-170)

24

Criterios de Selección de la Herramienta / Producto de BI Josep Lluís Cano (2007) describe un conjunto de criterios a tener en cuenta a la hora de seleccionar la herramienta de BI, en base a un trabajo de Wayne Eckerson y Cindi Howson (2003): 





Evaluar datos financieros sobre del proveedor: -

Total de ingresos de productos de Business Intelligence /total de sus ventas.

-

Ratio entre ingresos por servicios y licencias.

-

Evolución de la venta de licencias.

-

Resultado económico.

-

Evolución de las acciones.

-

Recursos destinados a Investigación y desarrollo.

-

Estrategia de ventas.

-

Fusiones, adquisiciones, etc.

La estrategia del proveedor: -

Si tiene otros productos (por ejemplo de ETL, base de datos propia, etc.).

-

Cuando venden, ¿qué venden?

-

Cuáles son sus principales competidores.

-

Cuál es su origen y hacia donde van.

-

Cuáles son sus diferencias respecto a los otros proveedores.

-

Posibles evoluciones de la herramienta.

La arquitectura tecnológica del proveedor. -

Arquitectura orientada a servicios (SOA).

-

Estructura común a través de todos los productos.

25





-

Procesamiento en el servidor (o en cliente).

-

Desarrollo por capas.

-

Conectividad con terceros.

-

Solidez del sistema.

-

Escalabilidad y rendimiento.

-

Alta disponibilidad.

-

Que soporte estándar.

Las funcionalidades de consultas: -

Proteger a los usuarios de las complejidades del motor de base de datos.

-

Consultas ad hoc.

-

Consultas totalizadas y detalladas.

-

Seleccionar de listas.

-

Acceder a distintas fuentes de datos.

-

Impacto de las consultas en la base de datos.

-

Complejidad del lenguaje de las consultas.

-

Acceso desde cliente servidor o vía web.

Las funcionalidades de informes: -

Estructura de los documentos y flexibilidad.

-

Complejidad del documento (distintas fuentes de datos, tablas combinadas, gráficos).

-

Formatos de tablas.

-

Tipos de gráficos.

-

Cálculos basados en el informe.

-

Diseño del informe, formato rápido.

-

Control de impresión.

-

Formato contextual.

26



-

Capacidades de navegación.

-

Formato WYSIWYG.

-

Entrega de información: o

Planificada (tiempo, eventos, versiones, etc.).

o

Formatos (Excel, PDF, HTML, etc.).

o

Dispositivos impresora).

o

Integración en portales.

(correo

electrónico,

PDA,

Las funcionalidades OLAP: -

Tipo de arquitectura: MOLAP, ROLAP, HOLAP, DOLAP.

-

Uso de particiones.

-

Proceso de construcción de los cubos.

-

Cálculos.

-

Jerarquías alternativas.

-

Análisis de atributos.

-

Soporta otras fuentes OLAP.

-

Valores en un momento del tiempo o agregados en un periodo.

-

Navegar a detalle.

-

Deshacer en análisis que pasaría si (What if).

-

Posibilidad de crear funciones.

-

Número de usuarios, dimensiones, etc.

-

Pivotar cubos, arrastrar y soltar.

-

Tiempo de respuesta.

-

Cálculos a nivel de usuario.

-

Utilizar jerarquías definidas y caminos de navegación.

-

Ranking.

27





-

Alertas y semáforos.

-

Juntar tablas y gráficos y navegar de forma sincronizada.

-

Formatos de impresión.

Las funcionalidades de administración: -

Autentificación de usuarios (LDAP, roles, basados en web).

-

Construcción y mantenimiento del Metadata.

-

Administración del servidor.

-

Información y monitorización del uso.

-

Entornos de desarrollo.

-

Control de cambios.

Los precios: -

Licencias (nominales, concurrentes, por servidor, por CPU).

-

Mantenimiento (importe, actualizaciones y soporte).

-

Soporte (niveles, incidencias).

-

Importe para el proyecto concreto.

-

Coste total de propiedad115 (TCO, “Total Cost of Ownership”).

importe,

base

de

datos

de

(Cano, 2007, pp. 171-174)

28

Criterios de Selección del Implementador de BI Josep Lluís Cano (2007) propone también una serie de criterios que deben tenerse en cuenta a la hora de seleccionar la empresa proveedora que realizará la implementación de la solución de BI. Puntualmente, menciona los siguientes aspectos: 

Historia.



Estabilidad y viabilidad financiera.



Recursos humanos y de gestión.



Cobertura geográfica.



Servicios ofertados.



Experiencia con el producto y en el sector.



Experiencia con clientes afines.



Metodología y herramientas de desarrollo.



Productos y metodologías implementadas.



Grado de confianza.

A estos criterios deberían añadirse algunos de los que propone Forrester Research: 

Especialización vertical.



Facilitar la colaboración con otros proveedores.



Flexibilidad para cambiar las necesidades del cliente.



Soporte para la aparición de nuevas tecnologías o la innovación en los negocios.



Casar los servicios ofrecidos con las necesidades de los clientes.

(Cano, 2007, pp. 174-175)

29

Productos de BI En la Nota Técnica 3 del Capítulo VI (2007, pp. 175-185), Josep Lluís Cano hace una recopilación de distintos proveedores de productos de BI. Es evidente que para el caso de las PyMEs muchas veces los costos pueden resultar definitivamente prohibitivos; en tal caso no queda otra alternativa por la cual optar que por una herramienta Free Open Source, o bien por alguna opción comercial de relativo bajo costo, como por ejemplo, para la visualización de los datos puede ser la planilla de cálculo Microsoft Excel. En este sentido, Josep Lluís Cano (2007) muestra un ejemplo de acceso a bases de datos OLAP con Excel (también en el mencionado capítulo VI, pp. 186-192). Por otro lado, en el capítulo VIII hace un repaso de la evolución de las herramientas de BI y del mercado global de soluciones de BI. Para datos de mercado más actualizados puede accederse al informe de Gartner1, en donde se estima que el mercado global de BI llegó en el año 2012 a un valor de 13.100 millones de dólares en ingresos, con un crecimiento del 7% con respecto a 2011. En el informe de Gartner es interesante observar cuáles son las empresas que tienen mayor participación de mercado, (http://www.gartner.com/newsroom/id/2507915, 2013) lo cual denota el grado de implementación de sus productos por parte de las organizaciones cliente en todo el mundo: 

“SAP: 22,1 %



Oracle: 14,9%



IBM: 12,4 %



SAS: 12,2%



Microsoft: 9,1%”

1

Sitio Web donde se pueden consultar los datos de mercado actualizados: http://www.gartner.com/newsroom/id/2507915

30

7.2 Relevamiento del Negocio Una vez decidida la plataforma tecnológica de soluciones de BI, el relevamiento del negocio es fundamental para poder comprender los requerimientos. Entre los aspectos que debemos tener en cuenta podemos mencionar los siguientes: 

Datos generales sobre la empresa y el área de Sistemas (todo esto en caso de que estemos ofertando o proporcionando una solución de BI a un cliente externo).



Relevamiento de requerimientos de información con los usuarios claves.



Relevamiento de los Sistemas de Información Transaccionales/Operacionales de la empresa que se utilizarán como fuente de datos para la construcción del Data Warehouse.



Otros aspectos.

Josep Lluís Cano (2007) hace, en el capítulo VII, una recorrida de distintos casos de estudio con diferentes experiencias de implementación de soluciones de BI.

7.3 Análisis OLTP Para cada uno de los Sistemas de Información Transaccionales/Operacionales de la empresa será necesario hacer un análisis detallado exhaustivo respecto a sus características, funcionalidades, plataformas tecnológicas y, sobre todo, sus estructuras de datos. Contar con un Diagrama de Entidad-Relación (DER) de cada uno de ellos será fundamental. Josep Lluís Cano (2007) enuncia, en el capítulo VII, distintos casos de empresas con sus respectivos sistemas origen.

31

7.4 Construcción procesos ETL A partir de los datos transaccionales/operacionales se deberá proceder a construir los procesos ETL que terminarán transportando los datos hacia el Data Warehouse. Josep Lluís Cano (2007) denota, en el capítulo VII, en su recorrida de distintos casos de estudio con diferentes experiencias de implementación de soluciones de BI, las características de varios procesos ETL empleados.

7.5 Armado de Datamart Los procesos ETL deberán finalmente llevar datos al Data Warehouse y luego deberá armarse el Data Mart correspondiente. Josep Lluís Cano (2007), en el capítulo VII, expone el modelo multidimensional generado en varios casos de estudio. Así, por ejemplo, podríamos tener un modelo multidimensional como el que sigue, correspondiente a una concesionaria que vende automóviles en todo el país: En el mismo, tenemos 2 hechos: 

Cantidad de unidades vendidas



Precio unitario

Y además las dimensiones: 

Tiempo (año, mes y día)



Producto (marca y modelo de auto)



Sucursal



Cliente.

32

Imagen 3: Modelo Multidimensional de Ejemplo de Concesionaria

Fuente: Elaboración propia

33

7.6 Presentación La capa de Presentación es clave, puesto que por más que hayamos realizado un excelente trabajo de integración y transformación de datos entre otros-, lo mismo no aportará valor agregado al usuario final si no cuenta con una herramienta de visualización/explotación que le sea útil y fácil de usar. También Josep Lluís Cano (2007), en el capítulo VII, muestra diferentes tipos de aplicaciones que se usaron en varias empresas. Siguiendo el ejemplo de la concesionaria de vehículos, podríamos poner en la pantalla cada una de las dimensiones para que el usuario pueda seleccionar los valores que desee para hacer drill-down y ver más detalles. Así, por ejemplo, como puede verse en la imagen 4, ubicamos los valores de la dimensión Tiempo en la parte superior de la pantalla y el resto de las dimensiones en el margen izquierdo de la misma. Sin embargo, aún no hemos incluido ningún gráfico en la pantalla (como puede verse en la Imagen 4), para poder visualizar los indicadores seleccionados.

Imagen 4: Pantalla con Dimensiones sin Indicadores

Fuente: Elaboración propia

34

A continuación, se muestra un gráfico en el que se visualiza el indicador de Cantidad de Unidades Vendidas, que lo definimos como un SUM del campo FACT_VENTAS.CANTIDAD. Este gráfico de ejemplo se elaboró incluyendo la dimensión Producto, de modo tal que podremos ver los autos vendidos por cada una de las marcas (productos). Utilizamos un gráfico de torta ordenando los valores desde el producto más vendido hasta el menos vendido. Los valores se muestran arriba de cada producto.

Imagen 5: Autos Vendidos por Marca

Fuente: Elaboración propia

Sobre el mismo gráfico vamos a hacer una operación de drill-down. Para ello, simplemente seleccionaremos un valor de la Dimensión Sucursal. En este caso, queremos ver para el indicador de Cantidad de Unidades Vendidas cuántos se vendieron en la sucursal "ROSARIO".

35

Imagen 6: Autos Vendidos por Marca por Sucursal

Fuente: Elaboración propia

Ahora aplicamos un ‘drill-across’ seleccionando un valor de la Dimensión Cliente. Queremos ver los autos vendidos por marca en la sucursal "ROSARIO" para el cliente "ABC S.A.". Imagen 7: Autos Vendidos por Marca por Sucursal por Cliente

Fuente: Elaboración propia

36

A continuación, queremos ver la evolución de las ventas usando el mismo indicador, pero por tiempo. Para ello, agregamos otro gráfico, en este caso de barras, para ver los autos vendidos por año, mes y día (es decir, agregamos la dimensión Tiempo). En este caso, y a diferencia de las dimensiones anteriores, la dimensión Tiempo cuenta con una jerarquía (año, mes, día). Imagen 8: Autos Vendidos por Año

Fuente: Elaboración propia

37

Ahora seleccionamos un año: 2012, con lo cual vemos las ventas para dicho año. El gráfico nos muestra la evolución mes por mes (hicimos un drilldown en la jerarquía de la dimensión Tiempo): Imagen 9: Autos Vendidos por Mes del Año

Fuente: Elaboración propia

Luego, aplicamos un nuevo drill-down y seleccionamos el mes de Junio. Vemos la evolución de las ventas por día: Imagen 10: Autos Vendidos por Día del Mes del Año

Finalmente, podemos hacer un análisis combinado. Fuente: Elaboración propia

38

Supongamos que queremos ver las ventas de RENAULT CLIO en el año 2013, para el mes 9:

Imagen 11: Autos Vendidos por Producto (Marca), Año y Mes

Fuente: Elaboración propia

En definitiva, como conclusión final se establece que la capa de Presentación de una Solución de Business Intelligence es lo que realmente termina visualizando el usuario y es con lo que termina interactuando. Por lo tanto, sus capacidades gráficas, posibilidades de navegación, niveles de usabilidad, entre otros, son factores claves para el éxito de cualquier proyecto de BI.

39

Bibliografía Lectura 4 

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º Edición). Estados Unidos: Wiley Publishing.



Gartner (2013). Gartner Says Worldwide Business Intelligence, CPM and Analytic Applications/Performance Management Software Market Grew Seven Percent in 2012. Recuperado el 8 de Mayo de 2014: http://www.gartner.com/newsroom/id/2507915.



Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º Edición). Estados Unidos: Wiley Publishing.



Kimball Ralph, R. M.; Thornthwaite, W. y Mundy Joy, B. B. (2008). The Data Warehouse Lifecycle Toolkit (2º Edición). Estados Unidos: Wiley Publishing.

www.uesiglo21.edu.ar

40