• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Academia latinoamericana de Business Intelligence  albi
 

Academia latinoamericana de Business Intelligence albi

on

  • 3,395 views

Curso de Inteligencia de Negocios de Microsoft.

Curso de Inteligencia de Negocios de Microsoft.

Statistics

Views

Total Views
3,395
Views on SlideShare
2,786
Embed Views
609

Actions

Likes
0
Downloads
16
Comments
0

7 Embeds 609

http://www.dioniciovelasquez.es.tl 270
http://dioniciovelasquez.es.tl 257
http://dpaunpa.wordpress.com 69
http://dpacomputacionunpa.wordpress.com 5
http://www.slideshare.net 4
http://m.dioniciovelasquez.es.tl 3
http://translate.googleusercontent.com 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Academia latinoamericana de Business Intelligence  albi Academia latinoamericana de Business Intelligence albi Document Transcript

    • ACADEMIA LATINOAMERICANA DE BUSINESS INTELLIGENCE (ALBI) Contenido del curso Convenciones Para ubicar rápidamente los diferentes puntos desarrollados a través de las unidades, se llevó a cabo un diseño de gráficos que harán referencia a cada tema. De esta manera el participante podrá ubicar cada contenido sin la realización de un esfuerzo extra en la búsqueda y aprovechando al máximo el tiempo dedicado al estudio de cada una de las Unidades presentadas. En siguiente tabla se podrá apreciar cada gráfico y su significado: Convención Descripción Objetivos Son las metas a las que apunta el curso o el módulo. Conceptos clave Es el contenido que, por su relevancia de significado, propone definiciones, descripciones o información a la que como participante se le debe prestar especial atención. Riesgos Cualquier situación que amenaza el éxito del proyecto en general o afecta la capacidad del equipo de trabajo. “Un problema que no ha sucedido, pero que podría causar pérdidas o amenazar el éxito del proyecto, si sucede.” (Wiegers, 1998) Ejemplos Son situaciones conceptuales, reales o hipotéticas de aplicación de los conceptos tratados y su propósito es apoyar a la comprensión de los conceptos al asociarlos con posibles formas de aplicación o de interpretar las que se proponen. Página 1 de 94
    • Convención Descripción Caso de Estudio Ejemplo que se desarrollará en detalle a lo largo del curso. Al finalizar el curso, el participante podrá reunir estas secciones y tener un ejemplo de desarrollo completo. Estadísticas Son datos cuantitativos provenientes de estudios realizados por fuentes confiables que permiten dimensionar la importancia de los sistemas de BI. Al igual que los Ejemplos y las Preguntas de reflexión, detonan la asociación del contenido conceptual con entornos de aplicación del aprendizaje. Preguntas de Reflexión Son formulaciones que sirven como guía para controlar el desarrollo del proyecto. Al final de la última unidad, estas preguntas se reúnen formando un Check List. Lecciones aprendidas Son frases o afirmaciones que al final de cada capítulo sintetizan lo que el participante debió aprender y permiten parafrasear la información clave. Diagramas, Son recursos que facilitan la lectura y la comprensión esquemas, porque destacan, organizan, clasifican, jerarquizan, fotografías, tablas, ilustran y/o representan el contenido con el propósito negritas y color en de facilitarte como participante la interacción con el las fuentes curso. Página 2 de 94
    • Objetivos Quién participe en la presente propuesta educativa, obtendrá los conceptos teóricos necesarios de Business Intelligence, formando una base consistente para adquirir posteriormente los conocimientos y así perfeccionarse en esta tecnología. Al final del curso tendrá los conocimientos suficientes para comprender qué es Business Intelligence, su necesidad, utilidad, desarrollo e implementación. Contenido Las siguientes Unidades y temáticas son las que se desarrollarán a lo largo del curso, cubriendo las expectativas planteadas en los objetivos que se pretenden que el alumno alcance a lo largo de esta propuesta educativa. Unidad 1. ¿Qué es Business Intelligence? La Unidad 1 contará a modo introductorio el concepto de Business Intelligence, haciendo un repaso de lo que significa contar con una solución BI, su potencialidad en la toma de decisiones y por qué en la actualidad las empresas están apostando a ello. Unidad 2. Definiendo Soluciones OLAP La Unidad 2 se recordarán los conceptos básicos de un sistema OLTP con sus ejemplos, pasando posteriormente a la explicación de un sistema OLAP. Se mencionarán y explicarán las características de un Data Warehouse junto con los componentes que lo conforman. A su vez, se tratará sobre los datos de origen que alimentan al Data Warehouse y cómo estos comienzan a transformarse en información del negocio. Hacia el final de la unidad, se verán algunos de los posibles procesos de selección y transformación de datos (ETL) que permiten alimentar las tablas auxiliares que soportarán la estructura multidimensional. Unidad 3. Diseñando una solución OLAP En la Unidad 3 se describirá el esquema de la base que conformará el plano sobre el que se edificará la estructura multidimensional (cubo) y sus componentes (Tablas de Hechos, Dimensiones y Medidas). Unidad 4. Construyendo una solución OLAP En la Unidad 4 se verán consideraciones específicas de la construcción y procesamiento de un cubo. Unidad 5. Implementando Cubos OLAP En la Unidad 5 se verá como un usuario puede acceder a la información en un sistema de BI, teniendo en cuenta la seguridad y el tipo de herramienta de consulta utilizada. Página 3 de 94
    • Unidad 1 ¿Qué es Business Intelligence? 1.1 Introducción 1.2 ¿A qué empresas les interesa BI? 1.3 ¿Qué es Business Intelligence? 1.4 ¿Qué puede hacer Business Intelligence? 1.5 ¿Quién necesita soluciones Business Intelligence? 1.5.1 Obtención caótica de información 1.5.2 ¿Quién necesita analizar la información? 1.6 ¿Primeros pasos? 1.7 El futuro de Business Intelligence Unidad 2 Definiendo Soluciones OLAP 2.1 Sistema Transaccional (OLTP) 2.1.1 Características 2.1.2 Usos comunes de OLTP 2.2 Sistemas OLAP 2.2.1 Bases de Datos (Estructuras) 2.2.2 Usos Comunes de OLAP 2.3 Datos de Origen vs. Información de Negocio 2.3.1 Convirtiendo Datos en Información 2.3.2 Transformación y agrupación de datos – ETL Unidad 3 Diseñando una solución OLAP 3.1 Introducción 3.2 Construyendo el data mart 3.3 Esquema Estrella 3.3.1 Tabla de Hechos 3.3.2 Dimensiones 3.3.2.1 Relaciones y Estructura de una dimensión 3.3.2.2 Esquema Estrella 3.3.2.3 Esquema Copo de Nieve Página 4 de 94
    • 3.3.2.4 Padre – Hijo (Parent- Child) 3.3.2.5 Dimensiones Virtuales 3.3.2.6 La dimensión Tiempo 3.4 Medidas 3.4.1 Medidas Naturales 3.4.2 Medidas Calculadas Unidad 4 Construyendo una solución OLAP 4.1. Introducción 4.2. Tipos de Almacenamiento 4.2.1. MOLAP 4.2.2. ROLAP 4.2.3. HOLAP 4.3. Definición de Agregaciones 4.4. Procesamiento de cubos 4.5. Cubos Virtuales 4.6. Particiones 4.7. La difícil búsqueda del equilibrio Unidad 5 Implementando Cubos OLAP 1.8 Introducción 1.9 Seguridad 1.10 Consultas 1.11 Herramientas de visualización 5.4.1 La Tabla Pivotal 5.4.2 El Tablero de Control 1.12 Conclusiones 1.13 Check List Página 5 de 94
    • Unidad 1. Introducción a Business Intelligence Objetivos Dar una visión acerca del por qué se debe contar con un sistema de apoyo para la toma de decisiones: Conocer qué sistemas informatizados actúan en cada componente organizacional. Distinguir entre un sistema operacional y un sistema de toma de decisiones. Comprender el concepto de Business Intelligence. Conocer acerca de los beneficios que trae aparejado el uso de Business Intelligence. Comprender los criterios que llevan a una empresa a utilizar una solución Business Intelligence. Introducción Los rápidos cambios que se viven en el mercado actual junto a las competencias que se generan cada día, hacen que las empresas no puedan postergar las decisiones relacionadas directamente con el negocio; una demora en este sentido puede llevar la gestión de la empresa al fracaso. Es necesario entonces contar con un sistema que juegue el papel de soporte para la toma de decisiones, de respuesta ágil y rápida, con información precisa para poder aprovechar las oportunidades: “estar en el lugar indicado, en el momento oportuno, con la información correcta”. Los sistemas orientados para la toma de decisiones son los englobados por el término Business Intelligence. Administrar una empresa sin contar con un sistema de Business Intelligence adecuado se parece mucho a caminar con los ojos vendados: se puede avanzar, ejecutar los procesos operacionales correctamente, progresar aparentemente según los objetivos y hasta crecer, pero en cuanto algo falla, los procesos se descontrolan, la coordinación desaparece y, en el mediano plazo, la empresa se desploma sobre sí misma. Esta puede parecer una visión apocalíptica, pero, ¿quién se arriesgaría a llevar adelante una gestión basándose en la buena suerte? Página 6 de 94
    • Contenido de la unidad 1.14 Introducción 1.15 ¿A qué empresas les interesa BI? 1.16 ¿Qué es Business Intelligence? 1.17 ¿Qué puede hacer Business Intelligence? 1.18 ¿Quién necesita soluciones Business Intelligence? 1.5.1 Obtención caótica de información 1.5.2 ¿Quién necesita analizar la información? 1.19 ¿Primeros pasos? 1.20 El futuro de Business Intelligence 1.1 Introducción Tanto en empresas pequeñas como en grandes organizaciones existen variados sistemas informatizados que tienen como objetivo principal garantizar la persistencia de las operaciones diarias realizadas. Estas operaciones se realizan según reglas de negocios predefinidas y se almacenan en grandes bases de datos. Dentro de las organizaciones se pueden reconocer distintos niveles de uso de los datos: Nivel operacional: Se utilizan sistemas de información que monitorean las actividades y transacciones elementales de la organización. Son sistemas que han cobrado un auge importante en la última década a consecuencia de un desarrollo organizacional orientado al mercado global. Nivel de conocimientos: En este nivel encontramos a los trabajadores de conocimiento y de datos, cubriendo el núcleo de operaciones tradicionales de captura masiva de datos y servicios básicos de tratamiento de datos, con tareas predefinidas. Nivel de administración: Se realizan tareas de administradores de nivel intermedio apoyando las actividades de análisis, de seguimiento, de control y toma de decisiones, realizando consultas sobre información almacenada en el sistema, proporcionando informes y facilitando la gestión de la información por parte de los niveles intermedios. Nivel estratégico: Tiene como objetivo realizar las actividades de planificación a largo plazo, tanto del nivel de administración como de los objetivos que la empresa posee. Página 7 de 94
    • La información que se genera en la organización se consume en diferentes momentos según el nivel: Plazo Nivel Uso Corto plazo Operacional y Obtención y control de datos Administrativo Mediano De Conocimientos Decisiones tácticas plazo Largo plazo Estratégico Decisiones estratégicas Las bases de datos transaccionales sirven como herramienta para los dos niveles básicos de la pirámide, el Nivel Operativo y el Nivel de Conocimientos. En los sistemas OLTP se ingresan, controlan y almacenan los datos. En los niveles superiores de la pirámide, el Nivel de Administración y el Nivel Estratégico, se tiene por tarea la toma de decisiones, tareas que están estrechamente vinculadas con los objetivos del negocio. Un sistema es un conjunto de elementos organizados que interactúan entre sí. Representa el conjunto de reglas de negocio que la organización define para llevar a cabo los procesos y procedimientos funcionales y operativos Página 8 de 94
    • necesarios para alcanzar los objetivos propuestos. Una Base de Datos es un conjunto de datos que pertenecen al mismo contexto y se encuentran almacenados sistemáticamente dentro de alguna estructura que los contiene. El Ambiente Operacional es el espacio en el que conviven el conjunto de reglas de negocio que la organización define para llevar a cabo los procesos y procedimientos funcionales y operativos necesarios para alcanzar los objetivos propuestos y los datos generados por las transacciones realizadas diariamente. Una Base de Datos operacional posee un conjunto de características tales como: Está orientada a la aplicación. Tiene estructuras normalizadas. Contiene los datos de las operaciones. Los datos se almacenan con el máximo número de detalle. Se actualiza en línea. Está en constante cambio. Ejemplo de Base de Datos Operacional La base de datos de una Entidad Financiera puede tener datos de: Clientes Tipos de Clientes Productos Tipos de Productos Operaciones Tipos de operaciones Regiones Países Provincias Ciudades Etcétera Cada una de las tablas y la base en sí, estarán normalizadas para asegurar la integridad de los datos, minimizar el espacio ocupado y maximizar el rendimiento del mantenimiento de los datos. Página 9 de 94
    • 1.2 ¿A qué empresas les interesa BI? Gasto total, para Argentina, en soluciones de BI, por Mercado Variación del Presupuesto de BI 2006 vs. 2005 Empresas que invertirán Más en BI (2006 vs. 2005) Página 10 de 94
    • 1.3 ¿Qué es Business Intelligence? Hasta este momento hemos estado hablando sobre Base de Datos transaccionales, las cuales dan soporte a las operaciones de la empresa. Estas Bases de Datos componen los sistemas OLTP. . OLTP son las iniciales en inglés de On-Line Transaction Processing, queriendo significar en su traducción Procesamiento de Transacciones en Línea. Bajo el nombre de Business Intelligence (Inteligencia de Negocios) se cobijan diferentes acrónimos, herramientas y disciplinas que apuntan a dar soporte a la tarea de toma de decisiones. Fundamentalmente podemos nombrar a: Data Warehousing: Los Data Warehouses o Almacenes de Datos se basan en estructuras multidimensionales (cubos) en las que se almacena la información calculando previamente todas las combinaciones de todos los niveles de todas las aperturas de análisis. Es, por decirlo llanamente, un producto cartesiano que almacena todas las combinaciones. Se puede decir que este método es exagerado o salvaje y en parte esta afirmación es real. Lo que no debe perderse de vista es que esta “salvajada” es el precio que paga la organización para poder tomar decisiones correctas. Siempre va a ser más barato el Página 11 de 94
    • gasto que conlleva la adquisición de SW o HW que el costo que representa una decisión tomada a destiempo. Data Mart: El almacén de datos de un hecho en particular se denomina Data Mart (DM). Data Mining: Está asociado al escalón más alto de la pirámide (Nivel Estratégico) y tiene por objeto eliminar los errores cometidos por las personas al analizar los datos debido a prejuicios y dejar que sean los datos los que muestren los modelos subyacentes en ellos. La Minería de Datos ayuda a crear nuevos modelos no percibidos por el analista hasta ese momento pero que realmente existen en los datos. Todas las herramientas o disciplinas que pueden contenerse en la definición de BI tienen tres características comunes: Primera: Proveen información para el control del proceso de negocio, independientemente de la fuente en la que los datos se encuentran almacenados. Segunda: Dan soporte a la toma de decisiones, siendo esta la característica más importante. Tercera: La capa semántica. No se pueden tomar decisiones de negocio si no se habla el lenguaje propio del negocio. Independientemente del origen de los datos o de la forma de extracción, transformación y agregación, lo verdaderamente importante es que la información le debe “servir” a los usuarios finales en un lenguaje de negocios comprensible por ellos sin la necesidad de intérpretes. La idea es que el analista se concentre en la toma de decisiones, las tome con rapidez y seguridad, lo que le ofrece una ventaja competitiva a la empresa y la acerca al cumplimiento de los objetivos. Business Intelligence (BI) es una disciplina que, junto con sus correspondientes herramientas, hacen centro en el análisis de la información para la correcta toma de decisiones que le permita a la organización cumplir con los objetivos de negocio. En la siguiente tabla se muestran las diferencias que son clave entre un sistema OLPT y un DW. OLPT DW Información para la Objetivos Operacionales toma de decisiones Orientación A la aplicación Al sujeto Página 12 de 94
    • Vigencia de los datos Actual Actual + histórico Granularidad de los Detallada Detallada + resumida datos Organización Organización Organización estructurada en función normalizada del análisis a realizar Cambios en los datos Continuos Estable A continuación se comentan cada una de las diferencias mencionadas para comprender con mayor detalle el concepto de DW. Objetivos: Un sistema OLTP debe garantizar la consistencia de los datos, mientras que un OLAP consolida datos ya validados y los adecua a las necesidades propias de la toma de decisiones. Orientación: Un sistema OLTP está orientado a la Aplicación, debe hacer cumplir las Reglas de Negocio. En cambio un sistema OLAP está orientado al Sujeto, se define en base a lo que el analista necesita ver. Vigencia de los Datos: En un sistema OLTP los datos se usan en la medida que se van produciendo y dejan de ser importantes en el corto plazo (un diario de ventas se lista para el mes que finaliza y, en el mismo momento comienzan a ser importantes los datos del mes actual). En un sistema OLAP se guardan los datos actuales y los históricos para poder realizar análisis comparativos, de tendencias, etcétera. La cantidad de períodos almacenados dependerá exclusivamente de la necesidad de análisis de la empresa y de la capacidad de almacenamiento. Granularidad de los Datos: En un sistema OLTP la granularidad está dada por los controles que deban realizarse, ya sea controles definidos por la organización como por las normas legales vigentes. En un OLAP estará dada por el tipo de análisis que se quieran realizar. Si el análisis del tráfico se realiza analizando el número de llamadas en el mes, no tiene sentido guardar el detalle diario en el OLAP, mientras que en el OLTP tal vez no tenga la libertad de decidir el nivel de granularidad. Organización: Un sistema OLTP es normalizado, mientras que un sistema OLAP se basa en estructuras jerárquicas desnormalizadas modeladas de acuerdo a la forma en que se analizarán los datos. Cambios en los datos: Un sistema OLTP modifica sus datos en forma constante porque maneja las transacciones de la empresa. Un sistema OLAP no tiene como objetivo la presentación de los datos en línea y, menos aún, pretende modificar los datos originales, solo consultarlos. La frecuencia de actualización de los datos en un sistema OLAP está definida por la granularidad. Página 13 de 94
    • Datos vs. Información Diariamente manejamos datos sobre los números telefónicos de las personas con las que tenemos contacto (amigos, familiares, el plomero, el delivery de pizzas, etcétera). Estos teléfonos nos llegan de distintas fuentes y podríamos anotarlos en una “libretita de teléfonos” o en un cuaderno común. Entonces, ¿Cuál es la ventaja de anotar los números de teléfono que nos interesan en una libretita en lugar de utilizar un cuaderno? Es evidente, vamos a encontrar más rápido los números en la libretita que en el cuaderno ya que los tenemos organizados por la inicial del nombre. ¿Y si además pudiéramos contar en nuestra libretita con una división para nuestras amistades, otra para nuestra familia y otra para servicios, cada una de ellas en diferentes colores de hojas? Tendríamos nuestra información telefónica organizada de tal manera que al necesitar de ella sería rápidamente accesible. Si queremos llamar a un amigo, tendríamos que identificar el grupo de pertenencia según el color, luengo por el índice buscamos el nombre y apellido y obtenemos el número de teléfono. Este sencillo ejemplo muestra conceptualmente la diferencia que existe entre datos e información y representa la semilla de un DW. 1.4 ¿Qué puede hacer Business Intelligence? Históricamente, para realizar un análisis: Se debía llamar a una Mesa de Ayuda para solicitarle los datos necesarios ya que era el personal de Sistemas la que sabía dónde se Página 14 de 94
    • almacenaban y de qué forma. El pedido pasaba a formar parte de la cola de incidentes. Obtener los datos demandaba un tiempo importante, pudiendo ser medido en días. Luego de la larga espera, se recibían los ansiados datos, procediéndose al análisis. Era muy posible que el analista se diera cuenta que en realidad necesitaba contar con más información, lo cual significaba repetir el ciclo mencionado. En un DW se pueden reunir los elementos de datos apropiados desde diversas fuentes de aplicación en un ambiente integral y centralizado, simplificando el problema de acceso a la información y en consecuencia, acelerando el proceso de consultas y análisis. Las aplicaciones para soporte de decisiones basadas en warehousing, pueden hacer más práctica y fácil la explotación de datos para una mayor eficacia del negocio tanto desde el punto de vista de la disponibilidad como de la confiabilidad. 1.5 ¿Quién necesita soluciones Business Intelligence? Es posible que aún para un grupo importante de personas esta pregunta no tenga una respuesta fundamentada o, lo que consideramos peor, que existan empresas que piensen que no necesitan contar con una solución BI. Vayamos por partes. Página 15 de 94
    • 1.5.1 Obtención caótica de información: Uno de los problemas más comunes cuando se necesita consolidar información o realizar tareas de análisis, es que hay que saber dónde está almacenado cada dato, con qué formato y qué nivel de consistencia tiene. Todo esto sin mencionar siquiera las complicaciones que trae el tema del acceso a los datos por cuestiones de seguridad. Un sistema operacional puede estar compuesto por varias aplicaciones, estas aplicaciones pueden haber sido desarrolladas por diferentes proveedores y con diferentes herramientas. Puede darse el caso de que haya determinados procesos que no tengan una aplicación que los soporte y por consiguiente el usuario lleve parte del negocio en planillas de cálculo almacenadas en su computadora. También puede pasar que los datos históricos sólo se mantengan en informes impresos ubicados en armarios ya sea en el lugar de trabajo o en un depósito externo. El recolectar este universo de datos dispersos en todos los sectores y lugares de la empresa, hace caótica la obtención de la información que se necesita. El disparador de las soluciones de BI son las Killer Queries (Consultas asesinas). Si se quiere saber cuánto debo producir en el segundo trimestre del año, tal vez deba conocer la previsión de ventas y la tendencia de las ventas en el año actual y las ventas reales de los últimos 5 años. Si se ejecuta esta consulta directamente contra un sistema OLTP, la respuesta puede que tarde varias horas y este no sería el mayor problema. El auténtico peligro es que colapse todo el sistema de información y nadie en la empresa pueda trabajar mientras tanto, con las pérdidas que esto ocasiona. Página 16 de 94
    • 1.5.2 ¿Quién necesita analizar la información? El éxito de una organización y de la gestión de la empresa se centra en el uso que se hace de la información. No se puede gestionar lo que no se controla. No se puede controlar lo que no se mide, si no se tiene información para controlar los procesos ocurrirá el caos. La información reduce la incertidumbre y facilita la toma de mejores decisiones. Entonces, podemos concluir que si existe una organización, si esta organización tiene un servicio o producto que está comercializando, si existen objetivos a corto y largo plazo que deben ser alcanzados y si existe, por sobre todas las cosas, ideales de competencia y crecimiento, debe existir también dentro de la empresa un sistema basado en BI. Tomar decisiones sin la información adecuada, sobre todo cuando ésta se encuentra disponible en la organización, es un riesgo que ninguna empresa debería correr. Finalmente surgen dos interrogantes: ¿Cuándo necesita la empresa hacer uso de esta información? ¿Cuándo puede la empresa hacer uso de esta información? La respuesta para los dos casos es la misma: ¡Es necesario decidir ahora y se debe tener la información ahora! Suponer que desarrollar un sistema basado en la tecnología Business Intelligence es algo lujoso, de costos muy elevados o que es un elemento de Marketing es una concepción errónea de la idea. 1.6 Primeros pasos Página 17 de 94
    • Aceptando que se reconoce la necesidad de contar con un sistema basado en BI, se plantean las preguntas: ¿Cómo comienzo? ¿Hasta dónde debo llegar en una primera etapa? La creación de un sistema de BI puede verse como una obra de muy largo aliento y provocar temores. Lo importante, al principio es crear la base sobre la que podamos obtener los primeros resultados para, con el tiempo, seguir creciendo. Lo esencial es Lograr la unificación de los datos que se usan en la toma de decisiones en un repositorio único. Una experiencia desalentadora es la de llegar a una reunión y ver que cada expositor porta una planilla de cálculo propia, con datos propios que no coinciden con ninguna de las demás e iniciarla con una discusión sobre la validez de las distintas fuentes de datos. Implementar una capa semántica útil. Que todos entiendan con claridad el significado de la información. Una vez cumplidos estos objetivos básicos, el resto del camino dependerá de las necesidades propias de cada organización. 1.7 El futuro de Business Intelligence Como en casi todas las actividades humanas, en BI se da una mezcla de necesidad y moda. Por estos tiempos están tomando cuerpo los proyectos BAM y CPM: BAM: Los Business Activity Monitoring plantean el uso de indicadores de cuadro de mando, pero a muy corto plazo. Son indicadores estrictamente operacionales que se obtendrán de los sistemas transaccionales. En algunos casos se los menciona como BI Operacional, porque responden a la necesidad de tomar decisiones a nivel operacional, en el aquí y ahora. CPM: Los Corporate Performance Management completan el enfoque global del proceso de flujo de información que da soporte a las decisiones en la empresa. Con las herramientas actuales se puede monitorear el negocio, analizar los problemas o aciertos. Se controlan los KPI (Key Performance Indicador – Indicador Clave de Rendimiento) pero no se tienen herramientas para crear y gestionar los KGI (Key Goal Indicador – Indicador Clave de Objetivo). Con CPM se pretende cerrar el círculo: se podrán definir las previsiones, los objetivos, la planificación, la consolidación presupuestaria, etcétera. Caso de Estudio Página 18 de 94
    • Escenario La Distribuidora Latinoamericana de Alimentos (DLA), se dedica a la comercialización de productos comestibles y bebidas a través de sus Hipermercados y Supermercados. Si bien cuenta con una amplia e importante cantidad de locales en la República Argentina, Brasil y Uruguay, un claro objetivo a mediano plazo es inaugurar locales en el resto de los países que conforman el MERCOSUR. Necesidad: Los analistas de DLA, por pedido de sus directivos, necesitan realizar informes en donde se pueda analizar: La cantidad de unidades vendidas en los países que alcanza el Mercado actual. El coste inducido en cada unidad vendida El valor de venta de cada producto. La ganancia obtenida en la venta de cada producto. Esta información, requiere que sea presentada por zona geográfica y sucursal. A su vez, la empresa quiere: Armar canastas de productos de acuerdo al perfil de compra de los clientes de cada ciudad en la que tienen una boca de expendio. Para esto requieren un estudio de las ventas realizadas abiertas por categoría de producto (con la posibilidad de obtener el detalle por producto), por ciudad, por mes, para los últimos 13 meses (para detectar estacionalidades) Premiar anualmente a aquellos vendedores que superen los objetivos de venta que les fueran asignados. El análisis, en este caso deberá incluir a los vendedores, las ventas realizadas, los objetivos de venta y el indicador de cumplimiento detallados por mes para el año fiscal (El premio será distinto si se cumple con los objetivos globalmente para el Página 19 de 94
    • año o si, además, se cumplen los objetivos en todos los meses en particular). Se tiene distinción entre un sistema basado en lo operacional y un sistema que apoya la toma de decisiones. Comprendemos ahora qué es Business Intelligence. Se comprenden las ventajas de una solución Business Intelligence. Se comprende y se puede decidir cuándo aplicar una solución Business Intelligence. Se puede especificar quiénes necesitan una solución Business Intelligence. ¿Está preparada la organización para trabajar con BI? ¿Se cuenta con el compromiso de la alta gerencia para encarar un proyecto de creación de un sistema de BI? ¿Tiene presente que deberá capacitar a los usuarios en la disciplina asociada a BI? ¿Están claramente definidos los objetivos de negocio que se asocian al sistema de BI? Unidad 2. Definiendo Soluciones OLAP Objetivos Al cabo de esta Unidad, el participante: Recordará los conceptos básicos de un sistema OLTP con sus ejemplos. Comprenderá las características de un Data Warehouse junto con los componentes que lo conforman. Reconocerá la necesidad de los procesos de selección y transformación de datos (ETL) que permiten alimentar las tablas auxiliares que soportarán Página 20 de 94
    • la estructura multidimensional. Conocerá las diferencias entre un sistema transaccional y un Data Warehouse. Comprenderá el término OLAP y su relación con la navegabilidad de la información. Conocer sobre las transformaciones necesarias para armar un DW a partir de una Base de Datos Operacional. Introducción Para llevar adelante el desarrollo de un DW, deben tenerse en cuenta una serie de pautas que deberán estar alineadas con los objetivos del negocio y los hechos que necesitan analizarse, incluyendo el alcance que tendrá el sistema, la granularidad de los datos y la navegabilidad que se desea. Debemos también identificar los orígenes de datos para luego seleccionarlos, depurarlos, transformarlos e importarlos. Contenido de la unidad 2.1 Sistema Transaccional (OLTP) 2.1.1 Características 2.1.2 Usos comunes de OLTP 2.2 Sistemas OLAP 2.2.1 Bases de Datos (Estructuras) 2.2.2 Usos Comunes de OLAP 2.3 Datos de Origen vs. Información de Negocio 2.3.1 Convirtiendo Datos en Información 2.3.2 Transformación y agrupación de datos – ETL 2.1 Sistema Transaccional (OLTP) 2.1.1 Características Los sistemas de OLTP (On-Line Transaction Processing) son los sistemas operacionales que capturan las transacciones de un negocio y las persisten en estructuras relacionales llamadas Base de Datos. Las características principales de los sistemas OLTP son: Realizan transacciones en tiempo real del proceso de un negocio, con lo cual los datos almacenados cambian continuamente. Los sistemas OLTP en sus transacciones conducen procesos esenciales del negocio. Página 21 de 94
    • Los sistemas OLTP son los responsables del mantenimiento de los datos, ya sea agregando datos, realizando actualizaciones o bien eliminándolos. Las estructuras de datos deben estar optimizadas para validar la entrada de los mismos, y rechazarlos si no cumplen con determinadas reglas de negocio. Para la toma de decisiones, proporciona capacidades limitadas ya que no es su objetivo, por lo tanto no es prioridad en su diseño. Si se quisiera obtener determinada información histórica relativa al negocio consultando un sistema OLTP, se produciría un impacto negativo en el funcionamiento del sistema. Normalmente, para el diseño de un sistema OLTP se define un modelo de Diagrama Entidad Relación (DER). Un DER es una representación de la realidad a través de un esquema gráfico que contiene los siguientes elementos: Entidades: Una Entidad es un tipo de objeto que puede identificarse de manera única por algún medio. Este objeto es traducido a la estructura física de una base de datos como una tabla. Atributos: Las características particulares que distinguen a las Entidades se denominan Atributos. Relaciones: vínculos existentes entre las tablas que sirven para asegurar la integridad referencial. Un ejemplo de Entidades y Atributos es: Persona (IdPersona, Nombre, Apellido, IdLocalidad) Grupo (IdPersona, Telefono) Para llegar a esquematizar un DER, se debe realizar un proceso de normalización basado en las Formas Normales, lo que además garantiza una optimización del espacio de disco a utilizar. 2.1.2 Usos Comunes de OLTP Toda organización o empresa, lleva adelante sus objetivos diarios realizando un conjunto de tareas que se encuentran cuidadosamente agrupadas dentro de procesos, estos últimos estrechamente relacionados entre sí. Los procesos pueden pertenecer al área Industrial, al departamento de Marketing, al departamento de Ventas o al sector Administrativo, mencionando solo algunos. Decimos entonces, que en la definición de OLTP se pueden encuadrar a todos los sistemas tradicionales dedicados a la captura, validación y Página 22 de 94
    • almacenamiento de datos de manera estructurada y que corresponden a los procedimientos. Sistema OLTP Imaginemos que estamos frente a un Sistema de Cajeros Automáticos. El sistema, al ser operado por un cliente pasará por las siguientes situaciones: Tomar la tarjeta del Cliente. Validar el Cliente. Consultar a la Base de Datos si el Cliente existe y, de existir, confirmar que se encuentra en una línea de cajeros habilitada. Autenticar el cliente en el sistema. De querer realizar una transferencia: Verificar que está autorizado para realizarla. Verificar que tiene saldo. Inicializar la transferencia manejándola como una transacción. Emitir comprobante. Saludar al Cliente. La situación en un Sistema de Ventas por medio de un sitio Web, sería la siguiente: Validar al cliente y autenticarlo en el sistema. Tomar el pedido. Controlar los topes de créditos. Informar los valores parciales de la compra y acumulados. Requerir confirmación del cliente antes de enviar el pedido. Enviar el pedido. Descontar del stock las cantidades vendidas. Informar el número de venta y la fecha de entrega. Saludar al cliente. Vemos que el sistema transaccional asegura un conjunto de reglas de negocio, como ser en el ejemplo del sistema de Ventas Web, antes de realizar la venta se controla que el cliente no haya superado el tope de los créditos. Página 23 de 94
    • A su vez, debe mantenerse una integridad en la información, es decir, si en una tabla manejo el stock de los productos y en otra llevo los movimientos que realizo de estos productos, las cantidades que muevo en la tabla de movimientos tienen que ser descontadas en igual medida que las que tengo en la tabla de productos. Las organizaciones se ven entonces en la necesidad de registrar las transacciones que ocurren durante sus procesos operacionales, para su control y posterior consulta. Un sistema OLTP es utilizado en: Sistemas bancarios Procesamiento de pedidos Comercio electrónico Sistemas de facturación Sistemas de stock Página 24 de 94
    • Almacenamiento Transaccional $ Comercio electrónico Bancos Pedidos $ $ $ Sistemas OLTP Facturación Stock 2.2 Sistemas OLAP 2.2.1 Bases de Datos (Estructuras) Los sistemas OLAP (On-Line Analytical Processing) proporcionan una alternativa a los sistemas transaccionales, ofreciendo una visión de los datos orientada hacia el análisis y una rápida y flexible navegación por estos. Las siguientes son características que la tecnología OLAP posee: Las bases de datos de OLAP tienen un esquema que está optimizado para que las preguntas realizadas por los usuarios sean respondidas rápidamente. Las preguntas que se le hacen a un OLAP, deben permitir un uso interactivo con los usuarios. Los cubos de OLAP almacenan varios niveles de datos conformados por estructuras altamente optimizadas que responden a las expectativas de negocio de la empresa. Un sistema OLAP está preparado para realizar informes complejos de una manera simple. OLAP proporciona una vista de datos multidimensional. Los cubos proporcionan una vista de los datos multidimensional que se extiende más allá del análisis de dos dimensiones que puede proporcionar una simple planilla de cálculo utilizada como tal. Los usuarios pueden cambiar fácilmente las filas, las columnas, y las páginas en informes de OLAP, pudiendo leer la información de la manera que se crea más conveniente para el análisis. Página 25 de 94
    • Un Sistema OLAP Los sistemas OLAP son una solución que devuelve rápidas respuestas a las consultas que le son realizadas. En base a los sistemas OLAP, se pueden obtener informes de negocios sobre Ventas ó Marketing, entre otros. 2.2.2 Usos Comunes de OLAP Los sistemas OLAP, son utilizados por las empresas para conocer la historia del negocio y poder realizar la toma de decisiones. Podemos enunciar entonces las siguientes áreas en donde el uso de un sistema OLAP está difundido: Sistemas de información ejecutivos. Los usuarios y los administradores generalmente de mandos altos y medios, reciben la información sobre los indicadores de funcionamiento dominantes del negocio y de las excepciones o las variaciones según sea de patrones y de estándares preestablecidos. Los Sistemas de Información Ejecutivos (EIS) presentan típicamente datos multidimensionales en formatos gráficos. OLAP en EIS Alertas. Toma de decisiones. Aplicaciones financieras. Para diversos usos de tipo financiero se utilizan las bases de datos de OLAP como ser para comunicar, planear, y analizar. Los ejemplos de usos financieros incluyen la comunicación, análisis del mes-cierre, análisis de lo beneficioso del producto, los presupuestos y pronóstico. Los analistas financieros utilizan OLAP extensivamente para el análisis de datos financieros y operacionales para contestar las preguntas de la gerencia mayor. OLAP en la Actividad Financiera Reportes analíticos. Planeamiento. Análisis. Página 26 de 94
    • Ventas y aplicaciones de Marketing. Existen diferentes formas de llegar a los clientes para alcanzar los objetivos de venta y de comercialización propuestos. Por esto, la utilización de sistemas OLAP, donde es importante contar con información organizada de manera rápida, es aconsejable. Los ejemplos incluyen análisis de la facturación, análisis de producto, análisis del cliente, y análisis de ventas regional. OLAP en el Marketing Análisis de productos. Análisis de Clientes. Análisis de Facturación. Otros Usos. Las bases de datos de OLAP se adaptan a una amplia gama de análisis, incluyendo rendimiento de procesamiento y eficacia de la fabricación, eficacia del servicio de cliente, y análisis de coste del producto. En definitiva, un sistema OLAP es útil para todo proceso en el que sea necesario tomar decisiones. OLAP en Otros Usos Análisis de la Producción. Análisis de Servicios al cliente. Evolución del Costo del producto. 2.3 Datos de Origen vs. Información de Negocio El presente esquema representa las distintas etapas que se deben ejecutar para la construcción de un Data Mart, desde que se identifican los datos originales en los sistemas transaccionales hasta que los Usuarios pueden disponer la información. A modo de guía, se irá indicando qué parte de estos procesos cubre cada Unidad. Página 27 de 94
    • Las etapas que deben cubrirse durante el proceso de construcción de un DW cumplen con lo siguiente: 1. Identificación de las necesidades y requerimientos. 2. Reconocimiento de las fuentes de datos originales y sus estructuras. 3. En base a los requerimientos, definir las tablas auxiliares y los procesos de selección, transformación e importación de datos. 4. Construir el esquema multidimensional. Debe controlarse que este esquema concuerde con los requerimientos y las tablas auxiliares, como primera forma de testeo. 5. Acceso al sistema desde las estaciones de trabajo de los analistas obteniendo la información identificada en la etapa de requerimientos. 2.3.1 Convirtiendo Datos en Información Para convertir los datos en información, se debe entender de qué manera pueden interpretarse los datos almacenados en sistemas operacionales, determinando: Como los hechos que deseamos medir se relacionan con los datos que podemos obtener. Entendiendo cómo estos datos reflejan metas y objetivos que abarcan el negocio involucrado. Un DW, clasifica la información en base a los aspectos que son de interés para la empresa. En el ambiente operacional se diseña alrededor de las aplicaciones y funciones (ventas, facturación, stock, etc.). La base de datos combina los Página 28 de 94
    • procesos en una estructura que responde a las necesidades de las reglas del negocio. En cambio en un DW, estos elementos se organizan alrededor de sujetos clientes (vendedores, productos, sucursales, etc.). Una vez que el análisis del negocio se reconoce como un valor significativo para una organización, las peticiones de los datos y de la información llegan a ser numerosas y frecuentes. Satisfacer estas peticiones puede ser una tarea muy compleja en un sistema OLTP, se debe bucear por grandes cantidades de datos obtenidos de distintas fuentes, procurando seleccionar, adecuar y consolidar la información. En un sistema OLAP, estos temas se resuelven por única vez, en la etapa de diseño. 2.3.2 Transformación y agrupación de datos – ETL Los datos que alimentan a un sistema DW provienen de diferentes fuentes, estas fuentes son los distintos sistemas operacionales que la empresa posee, generalmente ni son homogéneos entre sí ni concuerdan exactamente con lo que se necesita, por lo que será necesario realizar todas las adaptaciones pertinentes. ETL Los diferentes procesos que se concentran en el concepto de toma, transformación y carga de datos en un DW se denominan ETL, sus siglas en inglés significan Extract – Transform – Load. Página 29 de 94
    • Es común que los sistemas operacionales que se encuentran en las organizaciones hayan sido desarrollados por diferentes equipos de programadores o empresas de software, y en su desarrollo, hayan adoptado diferentes convenciones en la codificación de variables, nombres de los atributos de las tablas, diferentes tipos de datos o formatos de fechas. Al reunir datos de los diferentes sistemas, se debe definir una norma única para el DW y realizar las transformaciones que sean necesarias en cada caso. Básicamente deben realizarse las siguientes tareas: Establecer las reglas que serán utilizadas para realizar la transformación. Detectar las inconsistencias que pueden originarse al tomar los datos desde distintas fuentes. Planificar cuidadosamente y con detalles la transformación de los datos que den como resultado final conjuntos de datos consistentes. Convenciones diferentes en el desarrollo de aplicaciones Codificación: Un claro ejemplo es la codificación y descripción del sexo del individuo. Este pudo haber sido almacenado de diferentes maneras. Por ejemplo, puede encontrarse como “M” y “F”, “1” y ”0”, “Hombre” y “Mujer” ó “Masculino” y “Femenino.” En la transformación, habrá que elegir una convención única para el DW, que puede ser “M” y “F y transformar los datos. Aplicación A: M y F Aplicación B: 1 y 0 M-F Aplicación C: Masculino y Femenino Unidades de medida de los atributos: Las unidades pueden tener distintas unidades de medidas, según el origen del sistema OLTP. Un ejemplo es hablar de litro, centímetros cúbicos o hectolitros. Habrá que elegir una única unidad de medida que sea útil para el DW y transformar los datos. Página 30 de 94
    • Aplicación A: Litros Aplicación B: cm3 Litros Aplicación C: Hectolitros Formatos: Otro claro ejemplo son los formatos de fecha que encontramos en los diferentes sistemas operacionales. Las fechas pueden estar almacenadas como yyyy/mm/dd, mm/dd/yyyy ó dd/mm/yyyy. En el desarrollo del sistema DW, debemos elegir alguna de ellas y realizar la transformación correspondiente. Aplicación A: yyyy/mm/dd Aplicación B: mm/dd/yyyy dd/mm/yyyy Aplicación C: dd/mm/yyyy Varias columnas a una: En un sistema OLTP, los datos de una persona, como ser Dirección pueden almacenarse en diferentes campos de la misma tabla (Calle, Número, Piso y Departamento). Al transformar estos datos para que puedan ser utilizados en un sistema DW, es posible que los almacenemos en una única columna. Lo mismo puede suceder con el Nombre y Apellido. En el sistema OLTP puede estar almacenado en dos columnas y en OLAP ser requerido en una sola. Página 31 de 94
    • Una columna a varios: los sistemas más antiguos solían colocar el tipo y número de documento en el mismo campo de la tabla. En un DW, es muy posible que necesitemos colocar el tipo de documento en un campo y el número de documento en otro. Granularidad En el momento de importar los datos desde la fuente de origen se deben realizar las sumarizaciones que sean requeridas. Se debe definir la granularidad máxima a almacenar ene. SW y sumar los datos agrupando según ese criterio. Al definirse la granularidad se está diciendo, al mismo tiempo: Las aperturas que son de interés. El grado de detalle que se necesita. Es decir, si tomamos como ejemplo la medición del tráfico telefónico, puede definirse que se necesitan los totales de llamados por cliente por día. Vemos que el máximo detalle que es requerido es el día, no interesaría la hora de la llamada ni el tiempo de cada una de las llamadas. Por ende habrá que agrupar y sumar utilizando el criterio por Cliente y Día. Si se desea tener la cantidad e importe de ventas por mes, cliente y producto, se debe agrupar por estas tres aperturas, dejando en el sistema OLTP el detalle por día por factura o por boca de expendio, obteniendo el resultado que vemos en el gráfico. Página 32 de 94
    • Una vez que contamos con el plan de trabajo desarrollado según las reglas de transformación, tomamos los datos desde el sistema operacional y los importamos dentro de nuestra área de datos. Usaremos para almacenar los datos de origen tablas auxiliares que nos ayudaran durante la transformación. Mala interpretación de los Requerimientos Durante la etapa de relevamiento previo al diseño de un sistema OLAP, es importante entender con precisión la problemática del negocio. Esto incluye definir el hecho y qué medidas serán necesarias desarrollar en el sistema. Muchos sistemas no llegan a feliz término a causa de una etapa de relevamiento en donde los requerimientos planteados no apuntan a los objetivos del negocio. Página 33 de 94
    • Caso de estudio Relevando los Requerimientos En la Unidad 1, hemos anotado las necesidades de la Distribuidora Latinoamericana de Alimentos (DLA) y qué factores se quieren analizar para la toma de decisiones. Ahora debemos identificar de qué manera, a través de las aperturas y las medidas, vamos a medir los hechos que la empresa necesita analizar. Teniendo en cuenta que cada punto mencionado en los requerimientos está referido a las Ventas de la Empresa, podemos decir que el hecho de nuestro DW serán, justamente, las Ventas. Vamos a comenzar analizando cada necesidad y cuál es la dimensión o medida que habrá que crear para satisfacer la misma. Luego desarrollaremos una tabla en donde resumiremos la información obtenida. Esta tabla nos servirá en la etapa de diseño. Analizaremos el primer conjunto de necesidades: La cantidad de unidades vendidas en los países que alcanza el Mercado actual. En esta consigna se detecta como posible medida a las unidades vendidas, la cual necesitamos ver detallada por País. Por otro lado, la cantidad de unidades vendidas está referida a los productos: detectamos ya una nueva dimensión, el Producto. El coste inducido en cada unidad vendida. De este requerimiento se desprende la medida costo de ventas. El valor de venta de cada producto. Aquí necesitaremos contar con la medida Importe de ventas, sabiendo que utilizaremos la dimensión Producto para obtener el Valor de la Venta de cada Producto. La ganancia obtenida en la venta de cada producto. La medida Ganancia obtenida, se obtendrá de la diferencia entre el Importe de la venta y el costo del producto. Esta información, requiere que sea presentada por zona geográfica y sucursal. Aquí tenemos una nueva dimensión que llamaremos Sucursal. Ahora analizaremos el segundo conjunto de requerimientos: A su vez, la empresa quiere: Armar canastas de productos de acuerdo al perfil de compra de los Página 34 de 94
    • clientes de cada ciudad en la que tienen una boca de expendio. Para esto requieren un estudio de las ventas realizadas abiertas por categoría de producto (con la posibilidad de obtener el detalle por producto), por ciudad, por mes, para los últimos 13 meses (para detectar estacionalidades). Vemos que se nos pide analizar los productos según su categoría y los clientes que los adquirieron. De aquí se desprende que necesitamos una nueva dimensión Clientes y que los Productos deben mostrarse agrupados por Categoría de Productos, cosa que nos define un nivel en la dimensión Producto. Premiar anualmente a aquellos vendedores que superen los objetivos de venta que les fueran asignados. El análisis, en este caso deberá incluir a los vendedores, las ventas realizadas, los objetivos de venta y el indicador de cumplimiento detallados por mes para el año fiscal (El premio será distinto si se cumple con los objetivos globalmente para el año o si, además, se cumplen los objetivos en todos los meses en particular). Sobre estos requerimientos, debemos agregar solamente la dimensión Vendedor, ya que las medidas que utilizaremos son las mismas que hemos relevado anteriormente. Teniendo en cuenta que la empresa llega a los clientes tanto por Supermercados como por Hipermercados, podría ser de suma utilidad el realizar el análisis de cada una de las medidas por Tipo de Sucursal. Todo sistema DW contiene información histórica que la empresa analizará para diferentes períodos, agregaremos una dimensión más denominada Tiempo. A su vez, es común que sea necesario que se quieran analizar las ventas obteniendo el promedio de las mismas. Por lo tanto, viendo esta posible necesidad, sería conveniente que desarrollar la medida Ventas Unidades Promedio. Para ver la información obtenida en los relevamientos de una manera más clara y comprensible, es conveniente armar una tabla de doble entrada en donde colocaremos en las filas las medidas y en las columnas las dimensiones. Luego, en las intersecciones de medidas y columnas, colocaremos una cruz si es necesario ver la medida por esa dimensión. Hecho a medir: Venta de Productos Dimensiones Medidas Tiempo Sucursal Vendedor Cliente Producto Ventas_Importe X X X X X Ventas_Costo X X X X X Ventas_Unidades X X X X X Ventas_ImporteTotal X X X X X Ventas_Ganancia X X X X X Ventas_Promedio X X X X X Esta tabla resumen es de suma utilidad para ver con claridad los Página 35 de 94
    • requerimientos, agrupar por apertura y comenzar a definir los cubos a crear. Se conoce con mayor profundidad la estructura de un sistema OLTP. Se comprende dónde se utiliza un sistema OLTP. Se conoce de qué manera se estructura un sistema OLAP. Se conoce con detalles en qué áreas se utiliza un sistema OLAP. Se conocen las inconsistencias que puede haber cuando se alimenta un sistema OLAP desde un sistema operacional. Se comprende la manera en que los datos son transformados antes de llegar al sistema OLAP. ¿Ha relevado los Hechos que son de interés? ¿Ha relevado las aperturas por las cuales se analizará la información? ¿Ha relevado las medidas o indicadores que se usarán para evaluar los Hechos? ¿Cuál es la granularidad con que es necesaria ver la información en el sistema OLAP? ¿Tiene definidas las fuentes de donde va a extraer los datos? ¿Tiene definidos los formatos de los archivos de transferencia y de los datos que éstos incluyen? ¿Diseñó los procesos de selección, transformación y carga de datos (ETL)? Unidad 3. Diseñando una solución OLAP Objetivos Página 36 de 94
    • Comprender la formación de la tabla de hechos Entender que son las medidas Conocer que son las dimensiones y como se organizan Distinguir la diferencia entre los esquemas estrella y copo de nieve. Diferenciar las medidas naturales de las calculadas Contenido de la unidad 3.5 Introducción 3.6 Construyendo el data mart 3.7 Esquema Estrella 3.7.1 Tabla de Hechos 3.7.2 Dimensiones 3.7.2.1 Relaciones y Estructura de una dimensión 3.7.2.2 Esquema Estrella 3.7.2.3 Esquema Copo de Nieve 3.7.2.4 Padre – Hijo (Parent- Child) 3.7.2.5 Dimensiones Virtuales 3.7.2.6 La dimensión Tiempo 3.8 Medidas 3.8.1 Medidas Naturales 3.8.2 Medidas Calculadas Página 37 de 94
    • 3.1. Introducción Con lo aprendido en las unidades anteriores, podemos comenzar a definir el diseño de nuestra base de datos OLAP. En esta unidad, desarrollaremos el diseño de las tablas que conforman el plano de un data mart (DM) que nos servirá de estructura para el posterior armado del cubo. Al final de este módulo, el lector comprenderá cómo definir la tabla de hechos, cómo se pueden organizar las dimensiones, y qué son las medidas. La estructura que forman la Tabla de Hechos y las Dimensiones puede verse como el plano o la visión desplegada del cubo. Página 38 de 94
    • Data Mart: son almacenes de datos con información de interés particular para un determinado sector de la empresa Data Warehousing: es el conjunto de almacenes de datos particulares (Data Mart) con información de interés para la empresa en general Cada uno de los siguientes son ejemplos Data Mart (DM) Ventas Recursos Humanos Producción El Data Warehousing es el conjunto de esos data mart DM de Ventas + DM de Recursos Humanos + DM de Producción 3.2. Construyendo el data mart Hasta ahora hemos analizado los requerimientos del usuario, y depuramos sus datos para la formación del data warehousing, en esta unidad comenzaremos a diseñar el modelo del data mart. Este modelo, será el paso previo al armado de nuestra base de datos OLAP. En esta etapa vamos a modelar las tablas relacionales en una gran estructura desnormalizada, compuesta por tabla de hechos, y tablas más pequeñas que definirán las n-dimensiones o aperturas de nuestro cubo, llamadas tablas de dimensiones. Para ello, primero debemos conocer algunos conceptos que tendremos en cuenta en la construcción del modelo. 3.3. Esquema Estrella Para facilitar el análisis, el data mart organiza los datos en una estructura llamada esquema de estrella. Esta estructura esta compuesta por una tabla central - tabla de hechos - y un conjunto de tablas organizadas alrededor de ésta - tablas de dimensiones. En las puntas de la estrella se encuentran las tablas de dimensión que contienen los atributos de las aperturas que interesan al negocio que se pueden utilizar como criterios de filtro y son relativamente pequeñas. Cada tabla de dimensión se vincula con la tabla de hechos por un identificador. Las características de un esquema de estrella son: El centro de la estrella es la tabla de hecho. Página 39 de 94
    • Los puntos de la estrella son las tablas de dimensiones. Cada esquema esta compuesto por una sola tabla de hechos Generalmente es un esquema totalmente desnormalizado, pudiendo estar parcialmente normalizado en las tablas de dimensiones. En el ejemplo construimos un esquema estrella considerando que se necesita analizar como evoluciona la Admisión de Pacientes (Hecho) por servicio, pacientes y zona geográfica a lo largo del tiempo. Dimensión Dimensión Servicio Paciente Tabla de Hechos Admisión Pacientes Dimensión Dimensión Tiempo Zona Geográfica 3.3.1 Tabla de Hechos El modelo dimensional divide el mundo de los datos en dos grandes tipos: las medidas y las dimensiones de estas medidas. Las medidas, siempre son numéricas, se almacenan en las tablas de hechos y las dimensiones que son textuales se almacenan en las tablas de dimensiones. La tabla de hechos es la tabla primaria del modelo dimensional, y contiene los valores del negocio que se desea analizar. Cada tabla de hechos contiene las claves externas, que se relacionan con sus respectivas tablas de dimensiones, y las columnas con los valores que serán analizados. Página 40 de 94
    • Ejemplos de Hechos En un hospital: admisión de pacientes En un operador telefónico: Tráfico telefónico Un hecho es un concepto de interés primario para el proceso de toma de decisiones, corresponde a eventos que ocurren dinámicamente en el negocio de la empresa. 3.3.2 Dimensiones Diseñaremos y construiremos cada dimensión basados en los procesos de negocio definidos por el cliente. Las dimensiones organizan los datos en función de un área de interés para los usuarios. Cada dimensión describe un aspecto del negocio y proporciona el acceso intuitivo y simple a datos. Una dimensión provee al usuario de un gran número de combinaciones e intersecciones para analizar datos. Las tablas de dimensiones son las compañeras de las tablas de hechos. Cada dimensión se define por su clave primaria que sirve para mantener la integridad referencial en la tabla de hechos a la que se relaciona. Un cubo requiere que se defina al menos una dimensión en su esquema. 3.3.2.1 Relaciones y Estructura de una dimensión Cada nivel de una dimensión debe corresponderse con una columna en la tabla de la dimensión. Los niveles se ordenan por grado de detalle y se organizan en una estructura jerárquica. Cada nivel contiene miembros, los miembros son los valores de la columna que define el nivel. Entre los miembros y entre los niveles de una dimensión existen relaciones, estas se pueden comprender como las relaciones que existen en un árbol genealógico donde los términos padre, hijo, hermano, primo, etc. indican una correspondencia entre elementos del árbol; y los miembros de la dimensión se comportan como familiares dentro del árbol genealógico. Padre: Es el miembro del nivel inmediatamente superior que se relaciona con el miembro seleccionado. Cada elemento tiene un solo padre. Página 41 de 94
    • Hijo: Son los elementos del siguiente nivel inferior que se relacionan con el miembro seleccionado. Pueden existir varios hijos para un mismo miembro. Hermano: Son los miembros que se encuentran en el mismo nivel que el miembro seleccionado y poseen el mismo padre. Primo: Son los miembros que se encuentran en el mismo nivel que el miembro seleccionado, pero que tienen diferentes padres. Los primos tiene padres que son hermanos. Descendientes: Son todos los miembros que se encuentran debajo del nivel del miembro seleccionado. independientemente de la cantidad de niveles que los separen. Ancestros: Son todos los miembros que se encuentran por encima del nivel del miembro seleccionado. Un miembro es independiente de las relaciones. Cada integrante de la dimensión es miembro de ella. Página 42 de 94
    • Ejemplos de dimensión Dimensión zona geográfica * PAIS ARGENTINA BRASIL URUGUAY ** BUENOS CORDOB SAN MONTEVID PROVINCIA AIRES A PABLO EO MAR VILLA LA del GRAL. *** CIUDAD PLAT PLAT BELGRA …. … A A NO Ejemplos de relaciones En una dimensión zona geográfica tendríamos las siguientes relaciones entres niveles y entre miembros: Padre: Argentina es padre de Buenos Aires y de Córdoba Hijo: Buenos Aires y Córdoba son hijos de Argentina Hermano: Buenos Aires y Córdoba son hermanos el uno al otro, también son hermanos Argentina, Brasil y Uruguay. Primo: Mar del Plata es primo de Villa General Belgrano. Descendiente: Todos los miembros que estén por debajo de Argentina son sus descendientes, por ejemplo Buenos Aires, Mar del Plata y Villa General Belgrano son alguno de sus descendientes. Ancestro: Mar del Plata tiene dos antepasados Buenos Aires y Argentina. Las dimensiones pueden ser: Locales Compartidas Las dimensiones locales son las que se definen y se utilizan dentro de un mismo cubo. Las dimensiones compartidas son aquellas dimensiones que se definen independientes de los cubos y pueden ser utilizadas por varios de ellos. Ventajas de las dimensiones compartidas Página 43 de 94
    • Evitamos duplicar dimensiones locales Aseguramos que los datos analizados estén organizados de la misma forma en todos los cubos, lo que implica un menor costo de mantenimiento. Desventajas de las dimensiones compartidas Deben emplearse del mismo modo en los cubos que las usen. Un cambio implica que la dimensión deberá ser modificada en todos los cubos Ejemplos de Dimensión Compartida La dimensión Producto puede utilizarse para el Data Mart Ventas y para el Data Mart Producción. Así, la dimensión producto es una dimensión compartida por los dos Data Mart. Al definir una dimensión debemos prestar especial atención en los requerimientos del cliente, ya que una mala definición de la dimensión, o de sus niveles podría implicar que no obtengamos los resultados deseados. Si la definición de las dimensiones no es la correcta, no serán correctos ni útiles las agrupaciones, las sumarizaciones o los filtros. Probablemente se termine copiando datos a una planilla de calculo como sino existiera el DM. Riesgos de Dimensiones Compartidas Es importante que nos aseguremos que cualquier modificación o cambio en una dimensión compartida sea válida para todos los cubos que la empleen 3.3.2.2 Dimensiones: Esquema Estrella En el esquema estrella cada dimensión esta compuesta por una sola tabla, esta tabla esta desnormalizada. El esquema se denomina así debido a que el diagrama se parece a una estrella. Debido a que las tablas de dimensión están desnormalizadas lograremos en el modelo del data mart, una menor cantidad de tablas. Página 44 de 94
    • Este es un esquema donde las dimensiones tienen un esquema estrella. Dimensión Dimensión Servicio Paciente Tabla de Hechos Admisión Pacientes Dimensión Dimensión Tiempo Zona Geográfica 3.3.2.3 Dimensiones: Esquema Copo de Nieve El esquema copo de nieve es una variación del esquema estrella donde alguna punta de la estrella se explota en más tablas. El nombre del esquema se debe a que el diagrama se asemeja a un copo de nieve. En este esquema, las tablas de dimensión copo de nieve se encuentran normalizadas para eliminar redundancia de datos. A diferencia del esquema estrella, los datos de las dimensiones se reparten en múltiples tablas. Como ventaja del esquema destacamos el ahorro de espacio de almacenamiento en disco, pero en perjuicio de un aumento en la cantidad de tablas. Los siguientes son las características de un copo de nieve: La dimensión esta normalizada Los distintos niveles se encuentran almacenados en tablas separadas Se argumenta ahorro de espacio Página 45 de 94
    • Se muestra un esquema donde la dimensión zona geográfica presenta un esquema copo de nieve. Copo de nieve País Dimensión zona Geografica Provincia Servicio Ciudad Admisión Paciente Paciente Tiempo Ejemplo de Tabla Normalizada y Tabla Desnormalizada En la imagen vemos en la tabla normalizada los datos nombre de país y nombre de provincia aparecerán una sola vez en las tablas País y Provincia respectivamente. Si en cambio, la tabla esta desnormalizada tendremos redundancia de datos, ya que se repetirán los datos del País y de la Provincia por cada Ciudad. Normalizada Desnormalizada País ID_País Zona Geográfica Provincia País ID_ Provincia Provincia Id _ País ID_País País ID_Provincia Provincia ID_Ciudad Ciudad Ciudad ID_ Ciudad Ciudad ID_Provincia Estrella Copo de nieve Cantidad de tablas Menor Mayor Página 46 de 94
    • Mejora la performance Aumenta la cantidad de uniones entre tablas Consultas provocando baja en la perfomance Almacenamiento Aumenta el espacio Ahorra espacio 3.3.2.4 Dimensiones: Padre – Hijo (Parent – Child) Una dimensión padre-hijo es una dimensión donde el dato del Padre se relaciona con el Hijo y ambos se encuentran en la misma tabla de dimensión, es decir, la dimensión se relacionan consigo misma. Ejemplos de Dimensión Padre - Hijo La dimensión Cuenta Contable donde una cuenta imputable forma parte de un Sub Rubro y el Sub Rubro a su vez forma parte de un Rubro. Estos datos se encuentran en un solo Plan de Cuentas. La cuenta Activo, contiene los rubros Inversiones, Créditos y Caja, y el rubro Caja a su vez contiene Caja y Fondo Fijo. 3.3.2.5 Dimensiones Virtuales Las dimensiones virtuales, no requieren un almacenamiento físico en el cubo, se evalúan en el momento de la consulta. Funcionan de manera similar a las dimensiones reales y son transparentes para el usuario. Página 47 de 94
    • Ejemplos de Dimensión Virtual Podemos tener una dimensión Producto organizada de la siguiente manera: Producto (Dimensión real) …… Fabricante Marca Calibre Producto Si el usuario requiere que sus análisis de información se realicen por Marca, utilizando la dimensión Producto requerirá seleccionar a cada fabricante para obtener la información de la marca. Para evitar esto, podemos crear una dimensión virtual donde el orden de los niveles Fabricante - Marca están invertidos, que le permita ver sus datos por Marca sin necesidad de seleccionar a todos los fabricantes. Esta dimensión la construiremos de la siguiente manera: Producto_Marca (Dimensión virtual 1) …… Marca Fabricante Calibre Producto Otra necesidad del usuario podría ser obtener los totales o filtros de calibre sin importar la marca o el fabricante, entonces construiríamos una dimensión virtual que contenga solo la columna calibre. Calibre (Dimensión virtual 2) Calibre 3.3.2.6 La dimensión Tiempo Mencionaremos esta dimensión ya que ocupa un lugar especial en cada data mart. Recordemos que el tiempo es parte implícita de la información que contiene el data mart. Esta dimensión la podemos definir separándola en distintas jerarquías de tiempo: Año Semestre Mes Página 48 de 94
    • Ejemplos de Dimensión Tiempo La definición de la jerarquía la haremos teniendo en cuenta las necesidades que tiene la organización. Debemos contemplar los periodos de tiempo por los cuales la información necesita ser analizada y la regularidad con la que se cargaran los datos en el cubo. Consideraciones para esta dimensión: Nombres de los miembros: Cuando construyamos la dimensión tiempo es conveniente que los nombres de los miembros sean únicos. Así, si utilizamos una nomenclatura para la jerarquía MES que sea “Mes – Año” cuando busquemos un periodo debemos identificarlo como Julio – 2006. De esta manera nos ahorramos de utilizar dos niveles de la dimensión logrando una mayor calidad en los informes. Si en cambio, el nombre de la jerarquía MES se compone solo del nombre del mes, para identificar el periodo Julio del 2006 primero debemos seleccionar sobre el nivel Año y luego sobre el nivel Mes. Puede existir mas de una: Cabe aclarar que no necesariamente esta dimensión es única dentro del cubo, podríamos tener que armar más de una dimensión Tiempo. Si necesitáramos analizar la información de la empresa en base al año calendario y realizar otro análisis basándonos en el año fiscal, deberíamos construir dos dimensiones de tiempo para el mismo data mart. 3.4. Medidas Las medidas son los valores de datos que se analizan. Una medida es una columna cuantitativa, numérica, en la tabla de hechos. Las medidas representan los valores que son analizados, como cantidad de pacientes admitidos o llamadas efectuadas. Las medidas son: Valores que permiten analizar los hechos Valores numéricos porque estos valores son las bases de las cuales el usuario puede realizar cálculos. Si la medida fuera un valor no numérico debemos codificarla a un valor numérico en el proceso de obtención de datos, y luego cuando tengamos que exponer sus valores decodificarla para mostrarla con el valor original. Las siguientes son algunas de las características de las medidas: Página 49 de 94
    • Deben ser numéricas. Cruzan todas las dimensiones en todos los niveles. Las medidas pueden clasificarse en: Naturales Calculadas Ejemplos de Medidas En un hospital, donde el hecho es Admisión de Pacientes las medidas pueden ser: Pacientes Admitidos Pacientes Atendidos En un operador telefónico, donde el hecho es Trafico Telefónico, las medidas pueden ser: Llamadas Cantidad Llamadas Duración Ejemplos de Medidas no numéricas Supongamos el hecho Recursos Humanos, donde podemos tener la medida Sexo que toma los valores “F” o “M”. Estos valores debemos codificarlos en valores numéricos durante el proceso de transformación de datos (ETL). Así, por ejemplo tendremos 0=”F” y 1=”M”. Cuando el usuario visualice esta medida, debemos volver los datos a sus valores originales (decodificarlos) para mostrar “F” o “M”. 3.4.1 Medidas Naturales Son las columnas numéricas que queremos analizar que provienen directamente de los sistemas OLTP. Cuando definimos una medida debemos tener en cuenta cual será la forma de agregación (agrupación de la misma) al subir por la estructura dimensional. Estas formas de agregación pueden ser: Suma: es la operación que suma los valores de las columnas Cuenta: realiza un conteo de los valores Mínima: devuelve un valor mínimo Máxima: proporciona el mayor de los valores Página 50 de 94
    • Cuenta de Distintos: cuenta los valores diferentes Las agregaciones son resúmenes de datos precalculados que mejoran el tiempo de respuesta por el simple hecho de tener preparadas las respuestas antes de que se planteen las preguntas. 3.4.2 Medidas Calculadas Son las medidas que se calculan en el cubo en base a los valores de las medidas naturales. El sentido de la expresión medidas calculadas es muy amplio y engloba a cualquier manipulación de las medidas naturales que nos faciliten el análisis de los hechos. En una medida calculada puede haber: Cálculos Matemáticos Expresiones condicionales Alertas Estos tres tipos (cálculos, condiciones y alertas) usualmente pueden existir juntos dentro de la misma medida calculada. Página 51 de 94
    • Calculo Matemático En un sistema de RRHH, podemos querer medir el promedio de horas extras por mes. Definimos la medida calculada Promedio de Horas Extras que será el resultado de hacer Horas Extras dividido Dotación. Expresiones condicionales Para la medida calculada anterior, Promedio de Horas Extras, necesitaremos verificar la condición de numerador diferente de cero para evitar que la división nos arroje un error. Si Dotación es distinto de cero entonces Promedio de Horas Extras será igual a Horas Extras dividido Dotación. Si Dotación es igual a cero entonces Promedio de Horas Extras se mostrara vació. Alertas En un hospital, podemos definir la medida calculada Sobrecarga de Pacientes que tomara el valor 1 si los Pacientes Admitidos (medida natural) es mayor a 100, de lo contrario permanecerá vacía. Podemos construir una medida Cumplimiento de Ventas que sea una alerta del tipo semáforo y nos indique Rojo: Si las unidades vendidas son menores a las unidades presupuestadas dividido 5, es decir, vendimos menos que el 20 % de lo presupuestado. Amarillo: Si el valor de las unidades vendidas está entre unidades presupuestadas dividido 3 y unidades presupuestadas dividido 5 (el valor vendido esta entre el 20 % y el 80 % de lo presupuestado). Verde: Si no se cumple ninguna de las condiciones anteriores, es decir, vendimos más del 80 % de lo presupuestado. Página 52 de 94
    • Caso de Estudio Ilustraremos los conceptos que aprendimos en esta unidad con nuestro ejemplo de La Distribuidora Latinoamericana de Alimentos (DLA). Construiremos el modelo del data mart de ventas en tres etapas: Etapa 1 Construcción de las Dimensiones Etapa 2 Armado de la Tabla de Hechos Etapa 3 Definición de las Medidas Construcción de las Dimensiones Como primer paso definiremos las dimensiones porque estas nos darán las aperturas del cubo. En base a definiciones surgidas de los reuniones de trabajo con los representantes de DLA, vimos que necesitan analizar sus datos según el siguiente cuadro: Hecho a medir: Venta de Productos Dimensiones Medidas Tiempo Sucursal Vendedor Cliente Producto Ventas_Importe X X X X X Ventas_Costo X X X X X Ventas_Unidades X X X X X Ventas_ImporteTotal X X X X X Ventas_Ganancia X X X X X Ventas_Promedio X X X X X Si trabajamos en forma correcta, debería haber una exacta coincidencia entre la definición de las dimensiones y los datos que estamos extrayendo de las fuentes transaccionales. Si esa coincidencia no ocurre, en alguna de las dos etapas tenemos un error, o bien los datos de origen no están correctos o bien definimos mal las dimensiones. Comenzaremos por la Dimensión Tiempo ya que, como aprendimos en esta unidad, es la más importante dentro de cualquier data mart. Nuestro cliente necesita analizar sus datos diariamente, entonces definiremos los niveles: Año Semestre Página 53 de 94
    • Trimestre Mes Día La tabla de dimensión quedara formada: Dimensión Tiempo * Año ** Semestre *** Trimestre **** Mes ***** Día Dimensión Sucursal, usaremos un esquema estrella y su estructura jerárquica será: Dimensión Sucursal * Sucursal ** Tipo Sucursal *** País **** Provincia ***** Ciudad Dimensión Vendedor, al igual que sucursal, tendrá un esquema estrella y quedará definida por los niveles: Dimensión Vendedor * Sucursal ** Sección *** Vendedor Dimensión Cliente tendrá todos los atributos de un cliente. Dimensión Cliente * País ** Provincia *** Ciudad **** Razón Social Dimensión Producto, esta dimensión la construiremos según un esquema copo de nieve. En estos casos se mantiene la normalización propia de los Página 54 de 94
    • sistemas OLTP. Cada tabla contiene los datos iniciales y su relación con el resto. La dimensión nos quedará normalizada por lo que usaremos más tablas para construirla. Nuestro cliente puede clasificar sus productos según la categoría, el departamento y la familia de producto a la que pertenece. Armado de la Tabla de Hechos Ahora que tenemos definidas las dimensiones y sus niveles, conformaremos la tabla de Hechos. La tabla de hechos debe tener las columnas claves de las tablas de las dimensiones y las columnas de las medidas. Primero colocaremos las columnas claves de la tabla cada una de las tablas de dimensiones. Fact_Ventas ID_Fecha ID_Producto ID_Cliente ID_Vendedor Definición de las Medidas Recordemos que las medidas son los valores numéricos que el usuario desea Página 55 de 94
    • analizar. Vimos que nuestro cliente necesita medir: El coste inducido en cada unidad vendida El valor de venta de cada producto. La ganancia obtenida en la venta de cada producto. Agregaremos a nuestra tabla de hechos ventas estas medidas: Fact_Ventas ID_Fecha ID_Producto ID_Cliente ID_Vendedor Ventas_Importe Ventas_Costo Ventas_Unidades La medida “ganancia obtenida en la venta de cada producto” no la agregamos a la tabla porque esta medida puede ser calculada a partir de las medidas naturales ventas importe y ventas costo. Nuestro modelo contará también con las medidas calculadas: Ventas_Ganacia que tendrá la formula Ventas_Importe menos Ventas_Costo Ventas_Promedio que será el resultado de la suma de Ventas_Unidades dividido cantidad de días, comprobando la condición del numerador diferente de cero. Realizadas estas tres etapas, podemos ver el diseño completo de nuestro data mart. Página 56 de 94
    • Lecciones Aprendidas Un Data Mart adopta un esquema estrella para maximizar la performance de las consultas. Las dimensiones son categorías descriptivas por las cuales las medidas se pueden separar para el análisis. La dimensión Tiempo esta implícita en todo Data Mart Las medidas son los datos numéricos de interés primario para el cliente Con las medidas calculadas se pueden construir alertas Página 57 de 94
    • Preguntas de Reflexión ¿Tenemos claramente definidos los requerimientos? ¿Conocemos los hechos que se quieren analizar, los indicadores y las aperturas por las cuales se quiere hacer el análisis? ¿Concuerda esta definición con las tablas auxiliares que creamos y poblamos con datos de los sistemas OLTP? ¿Sabemos si los usuarios utilizarán las dimensiones para navegar o para filtrar? ¿Cubren las dimensiones diseñadas las necesidades de los usuarios intuitivamente y con facilidad de manejo? ¿Se tienen todas las medidas naturales con las aperturas requeridas? ¿Está definida la forma de agregación, al salir de la granularidad mínima, para todas las medidas naturales? ¿Están definidas las fórmulas o criterios de todas las medidas calculadas? ¿Están correctamente documentadas todas las definiciones? Unidad 4. Construyendo una solución OLAP Objetivos Diferenciar los distintos modos de almacenamiento Comprender qué es y como definir el porcentaje de agregación Conocer la posibilidad del uso particiones Entender el manejo de los Cubos Virtuales Mejorar los tiempos de procesamiento Optimizar el espacio de almacenamiento Contenido de la unidad Página 58 de 94
    • 4.8. Introducción 4.9. Tipos de Almacenamiento 4.2.1. MOLAP 4.2.2. ROLAP 4.2.3. HOLAP 4.10. Definición de Agregaciones 4.11. Procesamiento de cubos 4.12. Cubos Virtuales 4.13. Particiones 4.14. La difícil búsqueda del equilibrio 4.1. Introducción En esta unidad abordaremos los conceptos a tener en cuenta para la implementación del data mart. Describiremos los distintos tipos de almacenamiento y las consideraciones que debemos analizar para mejorar la performance del sistema. Además, veremos con que frecuencia es conveniente procesar nuestros cubos y explicaremos el uso de los cubos virtuales y particiones. Al final de este modulo, el lector conocerá qué modo de almacenamiento será el más adecuado para los requerimientos de la organización, como balancear los distintos factores que intervienen al implementar un cubo. Página 59 de 94
    • 4.2. Tipos de Almacenamiento Haciendo un pequeño balance de las unidades anteriores, vemos que ya tenemos: un diseño de requerimientos, sabemos de dónde y cómo obtener los datos y ya contamos con la definición de la estructura multidimensional. Ahora que vamos a armar físicamente el cubo debemos elegir entre los distintos modos de almacenamiento que podemos utilizar. Para facilitar esta elección, desarrollaremos los conceptos de MOLAP, ROLAP y HOLAP y luego haremos una comparación de los mismos. 4.2.1. MOLAP En el modo de almacenamiento MOLAP (OLAP Multidimensional) una copia de los datos de origen del cubo, junto con sus agregaciones, es almacenada en una estructura multidimensional. Debemos tener en cuenta que mientras los datos de origen cambian directamente con las operaciones, los objetos con almacenamiento MOLAP deben ser procesados para incorporar estos cambios. El tiempo comprendido entre un procesamiento y el siguiente, crea un periodo de latencia durante el que puede que la información OLAP no coincida con los datos de origen actuales. Como característica del almacenamiento MOLAP podemos desatacar: Provee excelente rendimiento y compresión de datos. Tiene mejor tiempo de respuesta, dependiendo solo del porcentaje de las agregaciones del cubo. La estructura está muy optimizada para maximizar el rendimiento de las consultas. En general este método, es muy apropiado para cubos con uso frecuente por su rápida respuesta. AGREGACIONES Y DATOS Vista de Base de Datos Usuario Relacional Base de Datos Multidimensional 4.2.2. ROLAP Página 60 de 94
    • En un modelo ROLAP (OLAP Relacional) toda la información del cubo, sus datos, su agregación, sumas, etc., son almacenados en una base de datos relacional. A diferencia del modo de almacenamiento MOLAP, ROLAP no almacena copia de la base de datos, accede a las tablas originales cuando necesita responder a las consultas, generalmente es mucho más lenta que las otras estrategias de almacenamiento (MOLAP o HOLAP). ROLAP se utiliza para ahorrar espacio de almacenamiento cuando se trabaja con grandes conjuntos de datos que se consultan con poca frecuencia; por ejemplo, datos exclusivamente históricos. Los usos comunes de este esquema son: Cuando los clientes desean ver los cambios inmediatamente. Cuando contamos con grandes conjuntos de datos que no son frecuentemente buscados AGREGACIONES Y DATOS Vista de Base de Datos Usuario Relacional Base de Datos Multidimensional 4.2.3. HOLAP HOLAP (OLAP híbrido) combina atributos de MOLAP y ROLAP. Al igual que MOLAP, HOLAP hace que las agregaciones se almacenen en una estructura multidimensional, y los datos a nivel de detalle, en una base de datos relacional como lo hace el almacenamiento ROLAP. Para procedimientos de búsqueda que accedan datos sumarizados, HOLAP es equivalente a MOLAP. Por el contrario, si los procesos de consultas accedieran a los máximos niveles de detalle, deberían recuperar los datos de la base de datos relacional y esto no seria tan rápido comparado con una estructura MOLAP. Los cubos almacenados como HOLAP, son más pequeños que los MOLAP y responden más rápidos que los ROLAP. Usos comunes de HOLAP Cubos que requieren rápida respuesta Cuando existen sumarizaciones basadas en una gran cantidad de datos de origen. Página 61 de 94
    • Solución de compromiso para bajar el espacio ocupado sin perjudicar totalmente el rendimiento de las consultas. DATOS AGREGACIONES Vista de Base de Datos Usuario Relacional Base de Datos Multidimensional Debemos tener en cuenta que si los usuarios generan consultas que deben utilizar los datos del nivel mas bajo HOLAP no suele ser la mejor opción Ejemplo del operador telefónico. Supongamos que: Se miden las llamadas realizadas x Día y x Cliente. El tiempo se estructura en Día – Mes – Año. Los Clientes se estructuran en Cliente – Ciudad – País. Definición MOLAP ROLAP HOLAP Datos Llamadas para un Día y EM BR BR detallados Cliente Datos Suma de llamadas para sumarizados algún cruce de Cliente – Tiempo donde al menos uno de las dos dimensiones EM BR EM no esté en el mínimo nivel. (Cliente y Mes ó Año, Día y Ciudad o País, etcétera) EM = Estructura Multidimensional BR = Base de Datos Relacional Página 62 de 94
    • MOLAP ROLAP HOLAP Almacenamiento Modelo Base de datos Modelo de las Multidimensional relacional Multidimensional Agregaciones Almacenamiento Modelo Base de datos Base de datos de los datos Multidimensional relacional relacional Facilidad de Sencillo Muy Sencillo Sencillo Creación Velocidad de Buena Regular o Baja Buena para respuesta consultas que posean agregaciones, Regular para datos de bajo nivel Escalabilidad Problemas de Son más escalabilidad escalables Recomendados Cubos con uso Datos que no Si el cubo requiere para frecuente son una rápida frecuentemente respuesta usados Ventajas Desventajas Mejor performance en los tiempos Duplica el de respuesta almacenamiento de datos MOLAP (ocupa más espacio) Tiempo de Latencia Ahorra espacio de El tiempo de respuesta almacenamiento. Útil cuando se a consultas es mayor. ROLAP trabaja con muy grandes conjuntos de datos. Volúmenes de datos Buen tiempo de respuesta sólo HOLAP más grandes en la base de para información sumarizada datos relacional Página 63 de 94
    • MOLAP es un OLAP basado en el acceso a una base de datos multidimensional ROLAP es un OLAP basado en el acceso a una base de datos relacional HOLAP es un OLAP situado entre ROLAP y MOLAP, accede a la Multidimensional y a la Relacional. 4.3. Definición de Agregaciones Otro factor para considerar en la implementación del modelo OLAP, además del modo de almacenamiento, es la definición del porcentaje de agregaciones. Se denomina agregación al proceso de precalcular el cálculo de los datos a través de los niveles, para disminuir los tiempos de respuestas en los procesos de búsquedas de información. El porcentaje de agregación da idea de la proporción o profundidad hasta la que se realizarán los precálculos. Las agregaciones se almacenan en la estructura multidimensional (según el modo de almacenamiento que escogimos). Las agregaciones son resúmenes de datos precalculados que mejoran el tiempo de respuesta por el simple hecho de tener preparadas las respuestas antes de que se planteen las consultas. Cuando definamos agregaciones debemos tener en cuenta de especificar las restricciones de almacenamiento y de porcentaje de agregación, a fin de lograr una buena solución de compromiso entre el tiempo de respuesta a las consultas y los requisitos de almacenamiento. Si calculáramos todas las agregaciones posibles necesitaremos gran cantidad de tiempo de procesamiento y espacio de almacenamiento. Si por el contrario, no se precalculan agregaciones (0%), la cantidad de espacio de almacenamiento que se necesita se reduce al mínimo, pero el tiempo de respuesta aumenta. Por lo tanto, suele existir un equilibrio entre el espacio de almacenamiento, el porcentaje de posibles agregaciones que se precalculan y la performance requerida. En la figura mostramos la grafica de esta relación: Página 64 de 94
    • En el gráfico podemos observar que llega un punto en el cual ya no se consigue un aumento significativo en las agregaciones (debemos recordar que, en este contexto, aumentar las agregaciones el sinónimo de mejorar la performance en las consultas), a pesar de aumentar la cantidad de espacio de almacenamiento. Debemos escoger un porcentaje situado en la zona del punto A, donde logramos el máximo porcentaje de agregación con la menor cantidad de espacio posible. Características de las agregaciones: Las agregaciones permiten mejorar los tiempos de respuesta Requieren de almacenamiento adicional Si no son controladas pueden provocar una explosión en los requisitos de almacenamiento A mayor número de agregaciones más tiempo de procesamiento y más requerimiento de espacio A menor número de pre agregaciones peor tiempo de respuesta de las consultas 4.4. Procesamiento de cubos En esta etapa debemos definir cuando y con que frecuencia procesar los cubos. Cuando se procesan Dimensiones o cubos se están actualizando los datos, las estructuras multidimensionales o ambas cosas. Esta definición debe considerar los siguientes factores Página 65 de 94
    • Modo de almacenamiento que escogimos (MOLAP-ROLAP-HOLAP), Tamaño de la tabla de hechos (cantidad de registros) Numero de dimensiones del modelo Porcentaje de agregaciones Para determinar la frecuencia con que procesaremos el cubo debemos tener en cuenta lo analizado con el cliente respecto de la granularidad de los datos para el tiempo. EL nivel de detalle (día, mes, etcétera) nos fijará la periodicidad de actualización de los datos. A diferencia de los sistemas OLTP en los que la actualización de los datos se realiza en línea con las transacciones y la agregación de los datos se realiza en el momento en que el usuario realiza una consulta, en OLAP el procesamiento de los cubos se realiza a contra turno, en los horarios en que no se afecta la tarea de los usuarios. En el sistema de tráfico telefónico, si se reciben los datos de las llamadas una vez por semana, entonces deberíamos procesar el cubo un día del fin de semana y de esa manera no afectaríamos la tarea del usuario. Si en cambio, la información de las llamadas se recibe en forma diaria, el procesamiento se podría realizar una vez al día a última hora de la noche, o bien a primera hora de la mañana. 4.5. Cubos Virtuales Los cubos virtuales son vistas de cubos reales. Los cubos virtuales pueden ser utilizados: Cuando el usuario desee ver información conjunta de dos cubos diferentes. Cuando se quiere tener una visión parcial de un cubo. Es una forma de simplificar el manejo de la seguridad. En el sistema de tráfico telefónico, se pueden querer relacionar las llamadas telefónicas con la cantidad de horas trabajadas. Una forma simple de cumplir con este requisito es crear un cubo virtual que tome datos de los cubos de Tráfico y de RRHH. 4.6. Particiones Los cubos están compuestos por particiones. Como su nombre lo sugiere, una partición es una división o fraccionamiento de la información que conforma a un cubo. Cada cubo contiene al menos una partición, pero puede estar compuesto por múltiples particiones, Página 66 de 94
    • Las particiones de un cubo son invisibles para el usuario, pero su uso aumenta la carga de trabajo del administrador del modelo multidimensional. Para cada partición podemos definir la fuente de datos, el modo de almacenamiento y el porcentaje de agregación de manera independiente de las demás particiones. Además, una partición de datos puede ser actualizada independientemente de las otras. Esta propiedad es muy importante ya que nos brinda la ventaja de mejorar los tiempos de procesamiento si dividimos correctamente las particiones y las procesamos adecuadamente. Así, si dividimos nuestro cubo en particiones definiremos cada unos de estos parámetros de la manera mas indicada. Partición más utilizada (Tiempo Actual): Modo de Almacenamiento MOLAP, % de Agregación: alto Frecuencia de procesamiento: alta Partición medianamente consultada (Tiempos intermedios): Modo de Almacenamiento: HOLAP % de Agregación: bajo Frecuencia de procesamiento: ocasional Partición poco accedida (Períodos viejos): Modo de Almacenamiento ROLAP, % de Agregación: nulo Frecuencia de procesamiento: muy baja (normalmente sólo al crear la partición) Desde el punto de vista de la administración, se puede manejar cada partición como si fuera un cubo independiente. Puede tener fuente de datos, modo de almacenamiento, porcentaje de agregación y frecuencia de procesamiento propios. Podemos crear una partición por cada año que contenga el cubo, (por ejemplo 2004, 2005 y 2006), y almacenar las particiones de la siguiente manera: Año 2006: En una estructura MOLAP, con un alto porcentaje de agregaciones, para obtener una respuesta rápida a las consultas. Año 2005: En una estructura HOLAP, con un bajo porcentaje Página 67 de 94
    • de agregaciones, lo que permitirá buenos tiempos de respuesta para consultas de resumen, con un espacio de almacenamiento mínimo. Años anteriores: En una estructura ROLAP, con porcentaje de agregaciones cero, lo que nos ahorrará espacio de almacenamiento. Este ahorro se paga con el aumento del tiempo de respuesta, pero no es caro, porque las consultas son ocasionales. Diseñar mal una partición, sin considerar los filtros que habitualmente utiliza el usuario, aumenta la carga de administración y no mejora la performance de las consultas. Si la lógica que define las particiones no está correctamente diseñada, se pueden perder o duplicar datos. 4.7. La difícil búsqueda del equilibrio En el momento de implementar el cubo, debemos analizar en conjunto los siguientes factores, tratando de llegar a un punto de equilibrio. % de Preagregación. Tiempo de Procesamiento. Requerimientos de tiempos de respuesta Tipo de almacenamiento Tipificación de las consultas (Base para decidir si se manejan particiones) Uso de Particiones Respuesta Tiempo de Respuesta Ocupado Procesa- Manteni- Espacio Tiempo miento miento de Consultas Cambios Acción % Preagregaciones Página 68 de 94
    • MOLAP Almacenamiento X Alto Alto x Agenda Alto ROLAP X Bajo Bajo Directo Bajo HOLAP X Medio Medio x Agenda Medio Particiones Sí Caso de Estudio Veremos como implementamos el diseño del modelo de OLAP que desarrollamos en la unidad anterior. Como vimos nuestro modelo era: Dimensión Vendedor Dimensión Producto * Sucursal ** Sección Subcategoría * Familia *** Vendedor ** Subcategoría Departament Fact_Ventas o *** Categoría **** Subcategoría Dimensión Sucursal Categoría ID_Fecha ***** Producto ID_Producto Categoría ID_Cliente ID_Vendedor * Sucursal Ventas_Importe ** Tipo Ventas_Costo Sucursal Departamento Ventas_Unidades *** País **** Provincia Departamento ***** Ciudad Dimensión Tiempo Familia Familia Dimensión Cliente * Año ** Semestre * País *** Trimestre ** Provincia **** Mes *** Ciudad ***** Día **** Razón Social A este modelo lo implementaremos sobre un cubo denominado Ventas. Cubo Ventas Página 69 de 94
    • Teniendo en cuenta que nuestro cliente analiza su información con respecto a los periodos de tiempo, filtrando por año, construiremos dos particiones dividiendo el cubo en forma anual. Así, obtenemos una partición para el año 2005 y otra para el año 2006. Esta partición tiene como objeto dar soporte a consultas que se realizan con poca frecuencia, por lo que optamos por definir parámetros que permitan el ahorro de espacio ocupado, aceptando una performance más baja. 2005 La partición para el año 2005 tendrá: Modo de almacenamiento: HOLAP Porcentaje de agregación: 10% Frecuencia de procesamiento: La procesaremos en el momento de la creación y después solo cuando el cliente lo solicite. Esta partición tiene como objeto dar soporte a las consultas que se realizan habitualmente, uno de los requerimientos básicos es el tiempo de respuesta de las consultas, por lo que optamos por definir parámetros que apunten a obtener la mejor performance, 2006 aceptando el costo en espacio ocupado y tiempo de procesamiento. La partición del año 2006 tendrá: Modo de almacenamiento: MOLAP Porcentaje de agregación: 40% Frecuencia de procesamiento: El procesamiento se realizará diariamente a partir de las 22:00 hs. ya que sabemos que los usuarios no realizan consultas en ese horario. No es necesaria la creación de un cubo virtual para poder visualizar las dos particiones. Desde el punto de vista del acceso para las consultas, las particiones son transparentes para el usuario, quien define al cubo como su fuente de datos sin tener en cuenta la forma en que está construido. Existen distintos modos de almacenamiento de los datos y agregaciones de un cubo, deberemos seleccionar uno de ellos según las necesidades y posibilidades de nuestra organización. Es conveniente emplear particiones cuando existen grandes volúmenes de datos con fin de lograr mejoras en los tiempos de procesamiento y la resolución de las Página 70 de 94
    • consultas. Utilizaremos cubos virtuales cuando el data mart necesite relacionar información de distintos cubos. Los tiempos de respuesta de las consultas ¿son un factor clave? ¿Se tienen definidos valores mínimos o máximos a cumplir? ¿Está estimado el volumen de datos a manejar, tanto en la actualidad como en el futuro? La frecuencia y el tiempo de procesamiento, ¿son factores críticos? ¿Se cuenta con el equipamiento adecuado para la situación actual y la estimación futura? ¿Se consideró este factor relacionándolo con el almacenamiento y la velocidad de procesamiento? ¿Existen criterios predefinidos para la definición del % de pre agregación? ¿Será necesaria la creación de cubos virtuales? ¿Se tiene una clara idea de la cantidad y calidad de las consultas habituales? ¿Existe algún patrón de filtrado que se repita, como el mes o la ciudad? Unidad 5. Implementando Cubos OLAP Objetivos Comprender la importancia del correcto manejo de la seguridad en los datos. Conocer las operaciones que se pueden realizar en la consulta de un cubo. Entender el uso de la tabla pivotal como herramienta de exploración. Página 71 de 94
    • Contenido de la unidad 1.21 Introducción 1.22 Seguridad 1.23 Consultas 1.24 Herramientas de visualización 5.4.1 La Tabla Pivotal 5.4.2 El Tablero de Control 1.25 Conclusiones 1.26 Check List 5.1 Introducción Como terminación del curso veremos como los usuarios pueden acceder a la información del cubo, para ello primero describiremos algunos aspectos de seguridad para mostrar los datos y luego expondremos los diferentes modos que existen para navegar un cubo. Al final del modulo daremos una conclusión sobre lo aprendido a lo largo del curso y habremos completado un Check List que nos servirá de guía en el proceso de creación de una solución de BI. 5.2 Seguridad A la hora de diseñar el modelo multidimensional, es fundamental definir la seguridad adecuada sobre los diferentes componentes y niveles de la Página 72 de 94
    • solución, debido a lo sensible que puede ser para la organización la información que suelen manejar este tipo de aplicaciones. Al igual que ocurre con las bases de datos de los sistemas transaccionales, en OLAP pueden manejarse distintos niveles de seguridad. La seguridad en OLAP tiene una arquitectura jerárquica, partiendo del cubo y llegando al nivel de celda dentro del cubo. De este modo, podemos definir los permisos a nivel de: Cubo Dimensión Celda (Medida) Cubo: esta restricción de seguridad se realiza sobre todo el cubo, se puede permitir o denegar el acceso al cubo. Permitido Denegado Dimensión: Podemos permitir que el usuario vea la dimensión, que acceda solo a una parte de ella, o que no tenga permiso de visualizarla. Permitido Solo una parte Denegado Celda: En una celda o medida podemos permitir el acceso, o bien personalizarlo utilizando expresiones que verifiquen alguna condición para acceder a los datos. Otra opción para limitar los accesos puede ser el uso de cubos virtuales. Podríamos crear un cubo virtual solo con las medidas que deseamos que tenga acceso el usuario y luego otorgar los permisos sobre el cubo virtual, y denegar o no otorgar permiso sobre el cubo original. Por ejemplo, si solo un grupo de usuarios puede visualizar el importe de los sueldos de los empleados, entonces podríamos definir una restricción de acceso a nivel celda, sobre la medida Sueldo o crear un cubo virtual que no muestre esta medida. Página 73 de 94
    • 5.3 Consultas Una vez que tenemos armado el cubo, los usuarios pueden realizar diferentes operaciones para poder visualizar y analizar sus datos. Las operaciones que se pueden realizar son: Drill - Down Drill - Up Slice y Dice. (Filtrado) Rotación Consolidación Drill Down – Drill Up: Es una técnica por la que el usuario puede navegar entre las jerarquías de una dimensión agrupando (Drill-up) o desagrupando (Drill-down) los datos. El drill down y el dril up sirven para navegar el cubo sobre sus dimensiones, con el drill up se pasa desde el detalle a la generalización, y con el drill down se pasa desde un nivel general al detalle. Drill - Down Drill - Up Slice: Al seleccionar un miembro en particular de una dimensión se forma una especie de rebanada (slice) del cubo original. Página 74 de 94
    • Dice: Al seleccionar varios miembros de varias dimensiones se forma sub- cubo, cubo más pequeño o dado (dice). Tanto Slice como Dice son formas particulares de Filtrado. Rotación: Selecciona el orden de visualización de las dimensiones, rota o gira el cubo según sus dimensiones. Consolidación (Roll-Up): Calcula las medidas en función de agrupamientos, realiza el re-cálculo de la medida de acuerdo a los ajustes de escala. Página 75 de 94
    • 5.4 Herramientas de visualización La navegación es un término que usamos para describir la posibilidad que tienen los usuarios de recorrer las distintas dimensiones y sus cruces, visualizando para cada caso los valores resultantes de las medidas. Estas son algunos tipos de herramientas que se pueden utilizar para navegar el cubo: Planillas de Cálculo: Las planillas de cálculo pueden conectarse a la estructura dimensional y alimentar una tabla pivotal con la información que extraen de los cubos. Tablero de Control: Los tableros de control se conectan a la estructura dimensional y generan indicadores que permiten una rápida visión del estado actual de las variables básicas y su relación con los objetivos de la empresa. Desarrollos propios: Soluciones o aplicaciones desarrolladas a medida, especialmente para la organización. Estas soluciones puede desarrollarlas el área de Sistemas de la empresa o un Proveedor externo, pero siempre en base a los requerimientos propios de la organización. Software especializado: Soluciones o aplicaciones creadas por empresas dedicadas principalmente al desarrollo de visualizadores de información orientada al análisis. Existe una gran variedad de herramientas con diversidad de prestaciones y costos, pudiendo ser tanto genéricas como orientadas a algún mercado en particular. Reporteadores: Herramientas especializadas en la construcción de informes que pueden conectarse a la estructura dimensional y generar reportes con la información que extraen de los cubos. Existe una gran variedad de Herramientas de visualización de la información almacenada en una estructura multidimensional. Se debe estudiar cada conjunto necesidad – recurso para decidir cual de ellas usar. En general, los factores que influyen el la elección de una Página 76 de 94
    • herramienta son: Tipo de consultas o análisis. Presupuesto. Valor del desarrollo o de las licencias. Usuario al que va destinada la herramienta. Otras herramientas existentes en la empresa. Capacidad de desarrollo de aplicaciones propias. Si no se incluye el análisis de la herramienta de visualización a utilizar entre las tareas de diseño, se corre el riesgo de tener la información correcta y a tiempo, pero a los usuarios desconformes. 5.4.1 La Tabla Pivotal La tabla pivotal es una herramienta gráfica que permite a los usuarios explorar fácilmente las dimensiones y medidas del cubo. De esta manera el usuario puede construir sus propios informes. La tabla pivotal se utiliza a través de una planilla de cálculo que se conecta al modelo multidimensional. Con ella se pueden realizar todas las operaciones que vimos en el punto 5.3 Consultas. Una Tabla Pivotal consta de las siguientes áreas: Área de Filtros: En la parte superior de la tabla. Se puede incluir una o más dimensiones. Se puede filtrar la información seleccionando niveles en general o miembros en particular. Cuando se realizan selecciones múltiples dentro de una dimensión, éstas se relacionan mediante el operador OR. Si las selecciones se realizaron en varias dimensiones, se vinculan con el operador AND. En esta área se implementa exclusivamente la operación Filtrado; en base a las selecciones realizadas se forma un conjunto reducido de datos que cumplen con los valores elegidos. Área de Filas: A la izquierda, define qué dimensiones cruzan la tabla como filas. En esta zona se pueden arrastrar las dimensiones, se puede navegar por ellas y decidir qué niveles mostrar y el grado de apertura de la información. También se puede seleccionar qué información se muestra. En esta área se implementan las operaciones Drill-Up, Drill- Down y Filtrado. Página 77 de 94
    • Área de Columnas: En la parte superior de la tabla debajo del área de filtros. Se define qué dimensiones cruzan la tabla como columnas. En esta zona se pueden arrastrar las dimensiones, se puede navegar por ellas y decidir qué niveles mostrar y el grado de apertura de la información. También se puede seleccionar qué información se muestra. En esta área se implementan las operaciones Drill-Up, Drill-Down y Filtrado. Área de Datos: En el centro de la tabla, se pueden incluir sólo medidas. Cuando arrastramos una medida tendremos el resultado de la intersección con las dimensiones que escogimos como filas y columnas, para el subconjunto que define el Filtrado. Lista de de Campos: Contiene la lista de las dimensiones y las medidas del cubo. Notas: o Una dimensión puede estar en Filtros, Filas o Columnas, pero sólo en un área a la vez. o En general, en el área de Filtros no se muestra la selección realizada. Si se desea filtrar por un nivel o miembro y, a la vez mostrarlo, se lo debe incluir en Filas o Columnas. En este ejemplo se quieren ver las unidades vendidas (Ventas Unidades), para el mes de Mayo de 2006, de Cuadernos cuadriculados, detalladas por Sucursal. Página 78 de 94
    • Caso de estudio Restricciones de seguridad Cada Sucursal puede ver únicamente sus datos, no pueden acceder a los que corresponden al resto de las sucursales. Los Vendedores pueden ver las ventas por Sección o Sucursal, pero no deben poder acceder al detalle por Vendedor. Página 79 de 94
    • Los Vendedores no pueden tener acceso al costo de las unidades vendidas. Operaciones sobre el cubo Veremos algunas de las operaciones que se pueden hacer sobre el cubo, ejemplificándolas con nuestro cubo de Ventas de la empresa DLA. Para la visualización usaremos una tabla pivotal, por tratarse de una herramienta de fácil manejo y disponibilidad. Drill Down: Si el usuario está analizando los datos de las ventas de Argentina y desea ver cómo están compuestos, podrá hacer drill-down en la dimensión de la Sucursal, la que exhibiría Buenos Aires, Capital Federal, Entre Ríos, La Pampa y Santa Fe. Si desea explotar Buenos Aires, con otro drill-down la tabla mostrará La Plata, Mar del Plata y Necochea. Página 80 de 94
    • Drill Up: Si el usuario esta viendo en detalle el nivel Ciudad (La Plata, Mar del Plata y Necochea) y quiere ver un nivel más general, podrá hacer drill up. Esta operación agrupará la información por País y mostrará el total de Argentina. La ventaja de tener estructuras definidas previamente, reside en que no es necesario que el analista sepa a qué país corresponde cada provincia o a qué provincia corresponde una ciudad para agregar o detallar. La estructura le dice el camino. Dice: con esta operación armamos un SubCubo de tres dimensiones, tomando las dimensiones Producto, Sucursal y Tiempo, dejamos fuera de nuestra selección a las dimensiones Cliente y Vendedor. Slice: Seleccionando la dimensión tiempo definimos una tajada del cubo. Página 81 de 94
    • Filtrado: Un ejemplo de filtrado podría ser seleccionar para la dimensión Producto el valor “Temperley Cristal Para x 1 Lt”. Rotación: en este ejemplo tomamos las dimensiones productos y sucursal y las rotamos. Reportes: A continuación se verán algunos informes simples orientados al análisis de la información. a- Se desea ver la evolución de la ganancia en las ventas de los Hipermercados, para los totales de los años 2005 y 2006, detalladas por País. Filtro: Tipo de Sucursal Hipermercado. Filas: Dimensión Sucursal Columnas: Dimensión Tiempo Datos: Medida Ventas Ganancia Obtenemos el siguiente resultado: Página 82 de 94
    • b- Ahora se desea comparar el Importe de las Ventas del Mes de Septiembre de 2006, por País y Familia de Productos, explotando cada familia por Departamento y Categoría. Filtro: Septiembre 2006 Filas: Dimensión Producto, y sus niveles Familia, Departamento y Categoría Columnas: Sucursal Datos: Medida Ventas Importe El resultado que obtuvimos fue: c- Si queremos conocer como se distribuye la ganancia de las ventas en cada país podemos construir un grafico que nos permite visualizar claramente esta distribución: Filtro: - Filas: Dimensión Sucursal Columnas: - Datos: Medida Ventas Ganancia Ventas Ganancia Página 83 de 94
    • d- Ahora queremos comparar las unidades vendidas de cada producto durante los años 2005 y 2006 en un gráfico de barras. Filtro: - Filas: Dimensión Producto Columnas: Dimensión Tiempo Datos: Medida Ventas Unidades 5.4.2 El Tablero de Control El Tablero de Control es una herramienta gráfica que le permite a los directivos concentrarse en indicadores fundamentales que tienen relación directa con los objetivos de negocio de la empresa. El Tablero de Control no es un repositorio de datos, básicamente es una herramienta que muestra indicadores relacionando los resultados esperados con los reales, es una manera de analizar la evolución del negocio. Página 84 de 94
    • Un Tablero de Control muestra, en pocos indicadores, datos trascendentes que extractan la naturaleza de la empresa y su porvenir. Estos indicadores deben mostrar la información en forma oportuna, sencilla e integrada, y ser claros y confiables. Un Tablero de Control no garantiza el éxito de una empresa, debe comprometerse el esfuerzo necesario para su efectiva utilización y generar una transformación en la cultura de trabajo empresarial. Finalmente, se debe tener perfectamente en claro que un Tablero de Control no gerencia ni gestiona; los indicadores le muestran los problemas a los directivos, pero el análisis de las causas y la forma de solucionarlos depende de las decisiones que ellos tomen. El Tablero de Control le indica a los directivos si la organización está cumpliendo con los objetivos o no, pero en ningún momento genera una solución automática. ¿Para qué sirve, entonces, el Tablero de Control? Básicamente, el Tablero de Control permite una rápida lectura del estado actual de las variables básicas y su relación con los objetivos de la empresa, alerta sobre la existencia de problemas actuales y facilita la visión de la evolución esperada, con lo cual ayuda a detectar los desvíos en los objetivos y tomar decisiones oportunas para corregirlos a tiempo. El Tablero de Control es una muy buena herramienta, pero sólo el cambio de la cultura empresarial puede hacer exitoso el camino. En este ejemplo se muestran dos modelos de Semáforo, siendo éstos indicadores gráficos característicos de los Tableros de Control. Para definir los semáforos se manejan, básicamente, las siguientes variables: Modelo del Semáforo: Existen varios estilos con diferentes cantidades de niveles. El número de niveles que posea un semáforo está directamente relacionado con la sensibilidad o capacidad de detalle que tiene el mismo. Valor Real: Es la variable que se desea monitorear. Valor Destino: Es el elemento de contraste contra el cual se van a monitorear los valores reales, y a partir del cual se calculan las diferencias o desvíos. Umbrales: Valores porcentuales que definen el Página 85 de 94
    • paso de un estado del semáforo al otro (Del verde al amarillo, por ejemplo). Según sea la cantidad de niveles del modelo de semáforo, será la cantidad de umbrales a definir. Semáforo tradicional de 3 colores: Es un semáforo con la forma, los colores y la lógica tradicional. El color Verde indica la situación ideal, mientras que el Rojo señala el peor extremo. Semáforo de cinco niveles: Es un semáforo que combina una barra, en el estilo de las barras de progreso, con un índice. La barra completa, con el índice en el cuadro de la derecha, representa la situación ideal, mientras que la barra con sólo el cuadro de la izquierda y el índice sobre éste último, señala el peor extremo. Página 86 de 94
    • Caso de estudio Tablero de Control A continuación se verán dos ejemplos de Tablero de Control aplicados a nuestro Caso de Estudio. a- Se desea ver la evolución del Importe de las Ventas, para los meses de Enero, Febrero y Marzo del 2006, detallada por Producto. Se desean ver los datos agrupados por Familia y Departamento. Lo primero que se ve en el Tablero de Control son los semáforos. Con el primer golpe de vista, sobre todo si la persona cuenta con la experiencia suficiente en el uso de estas herramientas, se puede saber el grado de cumplimiento de las Ventas respecto de los Objetivos para cada mes y la evolución que se está dando en el trimestre. En forma complementaria se tienen los valores numéricos como elemento de soporte. b- Se desea ver la evolución de las Ventas (Importe y Unidades), para los meses de Enero, Febrero y Marzo del 2006, detallada por Provincia. Lo primero que se ve en el tablero de Control es que se pueden analizar, en forma simultánea, varios aspectos del negocio. Se pueden combinar distintas variables a analizar y semáforos de distinta sensibilidad. En este caso se puede ver la evolución de las ventas comparando cómo varían las unidades y los importes, a lo largo del tiempo, con un solo golpe de vista. Página 87 de 94
    • Debemos considerar las restricciones de seguridad para proteger la información de los cubos. Los permisos de acceso los podemos otorgar sobre diferentes elementos del modelo (cubos, dimensiones, celdas). Las consultas de un cubo involucran diferentes operaciones (rotación, drill-down, slice, etcétera). La tabla pivotal es una planilla de cálculo que permite navegar los cubos. Página 88 de 94
    • ¿Existe una política de seguridad institucional? ¿Se pueden definir grupos de usuarios con roles similares para facilitar la administración de la seguridad? ¿Todos los requerimientos de control de acceso a los datos se van a manejar administrando la seguridad o se va a tener en cuenta estos puntos en el diseño de los objetos de la estructura multidimensional? ¿Existen herramientas corporativas para la visualización de los cubos? ¿Existe capacidad (habilidades y tiempo disponible) de desarrollar herramientas propias? Las herramientas del Mercado, ¿cubren las necesidades de la empresa? ¿Son accesibles? 5.5 Conclusiones Las principales conclusiones obtenidas a lo largo del curso son: Un sistema de BI constituye una necesidad para el correcto manejo del negocio. Los sistemas de BI son una muy buena herramienta para sustentar la evolución y el crecimiento del negocio y deben estar diseñados de forma tal que puedan seguir esa evolución y crecimiento. Los sistemas de BI influyen en toda la empresa, no son una facilidad de un sector. Cualquier empresa que se proponga cumplir con sus objetivos debe tener un sistema de BI. Los sistemas de BI no son sólo para las grandes empresas. Los sistemas de BI no son máquinas de fabricar informes. El tener un sistema de BI no es un lujo para la empresa, es responder a una necesidad. Los sistemas de BI son válidos para cualquier proceso en el que deban tomarse decisiones, no son propiedad de las áreas comerciales o financieras. Los sistemas de BI no son máquinas de fabricar resúmenes, brindan la información con el grado de detalle necesario para cada análisis. Los sistemas de BI no son una herramienta del área de Sistemas para mantener cautivos a los usuarios. Por el contrario, con un sistema de BI los usuarios consiguen más independencia al poder realizar las consultas en forma intuitiva y flexible. Construir un sistema de BI tiene como valor agregado el tener que revisar dónde y cómo se están almacenando los datos de los sistemas transaccionales (OLTP). Es una muy buena oportunidad de incluir en Página 89 de 94
    • los procesos manejos de datos que se estén haciendo manualmente y sin soporte alguno. El desarrollo de un sistema de BI no se comienza por la elección de la herramienta de visualización. Como en todo desarrollo hay que relevar las necesidades de la empresa, consultar a los usuarios, fijar el alcance y las restricciones y, finalmente, diseñar, desarrollar y probar cada etapa. El desarrollo de un sistema de BI no termina con la creación de un cubo multidimensional. Se deben definir e implementar los trabajos de procesamiento de los cubos (periodicidad, horario, manejo de errores, etcétera). Existe una gran variedad de herramientas de visualización de datos. Debe brindarse a cada usuario la que más le convenga, sin descuidar el presupuesto. La herramienta de visualización no debe ser una barrera entre el usuario y el sistema de BI. Página 90 de 94
    • 5.6 Check List ¿Está preparada la organización para trabajar con BI? ¿Se cuenta con el compromiso de la alta gerencia para encarar un proyecto de creación de un sistema de BI? ¿Tiene presente que deberá capacitar a los usuarios en la disciplina asociada a BI? ¿Están claramente definidos los objetivos de negocio que se asocian al sistema de BI? ¿Ha relevado los Hechos que son de interés? ¿Ha relevado las aperturas por las cuales se analizará la información? ¿Ha relevado las medidas o indicadores que se usarán para evaluar los Hechos? ¿Cuál es la granularidad con que es necesaria ver la información en el sistema OLAP? ¿Tiene definidas las fuentes de donde va a extraer los datos? ¿Tiene definidos los formatos de los archivos de transferencia y de los datos que éstos incluyen? ¿Diseñó los procesos de selección, transformación y carga de datos (ETL)? ¿Tenemos claramente definidos los requerimientos? ¿Conocemos los hechos que se quieren analizar, los indicadores y las aperturas por las cuales se quiere hacer el análisis? ¿Concuerda esta definición con las tablas auxiliares que creamos y poblamos con datos de los sistemas OLTP? ¿Sabemos si los usuarios utilizarán las dimensiones para navegar o para filtrar? ¿Cubren las dimensiones diseñadas las necesidades de los usuarios intuitivamente y con facilidad de manejo? ¿Se tienen todas las medidas naturales con las aperturas requeridas? Página 91 de 94
    • ¿Está definida la forma de agregación, al salir de la granularidad mínima, para todas las medidas naturales? ¿Están definidas las fórmulas o criterios de todas las medidas calculadas? ¿Están correctamente documentadas todas las definiciones? Los tiempos de respuesta de las consultas ¿son un factor clave? ¿Se tienen definidos valores mínimos o máximos a cumplir? ¿Está estimado el volumen de datos a manejar, tanto en la actualidad como en el futuro? La frecuencia y el tiempo de procesamiento, ¿son factores críticos? ¿Se cuenta con el equipamiento adecuado para la situación actual y la estimación futura? ¿Se consideró este factor relacionándolo con el almacenamiento y la velocidad de procesamiento? ¿Existen criterios predefinidos para la definición del % de pre agregación? ¿Será necesaria la creación de cubos virtuales? ¿Se tiene una clara idea de la cantidad y calidad de las consultas habituales? ¿Existe algún patrón de filtrado que se repita, como el mes o la ciudad? ¿Existe una política de seguridad institucional? ¿Se pueden definir grupos de usuarios con roles similares para facilitar la administración de la seguridad? ¿Todos los requerimientos de control de acceso a los datos se van a manejar administrando la seguridad o se va a tener en cuenta estos puntos en el diseño de los objetos de la estructura multidimensional? ¿Existen herramientas corporativas para la visualización de los cubos? ¿Existe capacidad (habilidades y tiempo disponible) de desarrollar herramientas propias? Página 92 de 94
    • Las herramientas del Mercado, ¿cubren las necesidades de la empresa? ¿Son accesibles? Página 93 de 94
    • Documentación Consultada: Kimball Ralph, "The Data Warehouse Toolkit " - John Wiley & Son, Inc. Thomsen E., Spofford G., Chase D., “Microsoft OLAP Solutions“ - John Wiley & Son, Inc. Laudon Kenneth C.; Laudon Jane Price. “Sistemas de información gerencial : administración de la empresa digital” - Pearson Educación Curso 2074A: Designing and Implementing OLAP Solutions with Microsoft SQL Server 2000. Facultad de Ciencias Exactas – UNICEN http://www.exa.unicen.edu.ar/catedras/dwhouse/ Facultad de Ingeniería – Universidad de la República de Uruguay http://www.fing.edu.uy/inco/grupos/csi/esp/Cursos/cursos_act/2003/DA P_SistDW Facultad Tecnología Informática - Universidad Abierta Interamericana Cátedra: Base de Datos Aplicada I Articulo “Bajo el paraguas Business Intelligence”, Jorge Fernández González, Abril 2006. Página 94 de 94