ACADEMIA LATINOAMERICANA DE BUSINESS
              INTELLIGENCE (ALBI)
Contenido del curso

Convenciones
      Para ubicar...
Convención          Descripción

                       Caso de Estudio
                       Ejemplo que se desarrollará...
Objetivos
               Quién participe en la presente propuesta educativa, obtendrá
               los conceptos teórico...
Unidad 1   ¿Qué es Business Intelligence?

           1.1   Introducción
           1.2   ¿A qué empresas les interesa BI?...
3.3.2.4        Padre – Hijo (Parent- Child)
                  3.3.2.5        Dimensiones Virtuales
                  3.3.2...
Unidad 1. Introducción a Business Intelligence

Objetivos
                Dar una visión acerca del por qué se debe contar...
Contenido de la unidad
1.14 Introducción
1.15 ¿A qué empresas les interesa BI?
1.16 ¿Qué es Business Intelligence?
1.17 ¿Q...
La información que se genera en la organización se consume en diferentes
momentos según el nivel:

Plazo            Nivel ...
necesarios para alcanzar los objetivos propuestos.

             Una Base de Datos es un conjunto de datos que pertenecen
...
1.2 ¿A qué empresas les interesa BI?



             Gasto total, para Argentina, en soluciones de BI, por
             Me...
1.3 ¿Qué es Business Intelligence?
Hasta este momento hemos estado hablando sobre Base de Datos
transaccionales, las cuale...
gasto que conlleva la adquisición de SW o HW que el costo que
      representa una decisión tomada a destiempo.
      Data...
Vigencia de los datos     Actual                     Actual + histórico

Granularidad de los
                          Det...
Datos vs. Información
             Diariamente manejamos datos sobre los números telefónicos
             de las personas ...
almacenaban y de qué forma. El pedido pasaba a formar parte de la
      cola de incidentes.
      Obtener los datos demand...
1.5.1 Obtención caótica de información: Uno de los problemas más
comunes cuando se necesita consolidar información o reali...
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...
Aceptando que se reconoce la necesidad de contar con un sistema basado
en BI, se plantean las preguntas: ¿Cómo comienzo? ¿...
Escenario


                               La Distribuidora Latinoamericana de Alimentos
                               (D...
año o si, además, se cumplen los objetivos en todos los meses en
     particular).



                      Se tiene disti...
la estructura multidimensional.
                      Conocerá las diferencias entre un sistema
                      tran...
Los sistemas OLTP son los responsables del mantenimiento de los
      datos, ya sea agregando datos, realizando actualizac...
almacenamiento de datos de manera estructurada y que corresponden a los
procedimientos.


                Sistema OLTP
   ...
A su vez, debe mantenerse una integridad en la información, es decir, si en
una tabla manejo el stock de los productos y e...
Almacenamiento Transaccional

                                                                         $




             ...
Un Sistema OLAP
              Los sistemas OLAP son una solución que devuelve rápidas
              respuestas a las consu...
Ventas y aplicaciones de Marketing. Existen diferentes formas de
      llegar a los clientes para alcanzar los objetivos d...
Las etapas que deben cubrirse durante el proceso de construcción de un DW
cumplen con lo siguiente:
   1. Identificación d...
procesos en una estructura que responde a las necesidades de las reglas del
negocio.
En cambio en un DW, estos elementos s...
Es común que los sistemas operacionales que se encuentran en las
organizaciones hayan sido desarrollados por diferentes eq...
Aplicación A: Litros

Aplicación B: cm3                         Litros

Aplicación C: Hectolitros



       Formatos: Otro...
Una columna a varios: los sistemas más antiguos
      solían colocar el tipo y número de documento en el
      mismo campo...
Una vez que contamos con el plan de trabajo desarrollado según las reglas
de transformación, tomamos los datos desde el si...
Caso de estudio




Relevando los Requerimientos
En la Unidad 1, hemos anotado las necesidades de la Distribuidora
Latinoa...
clientes de cada ciudad en la que tienen una boca de expendio. Para
      esto requieren un estudio de las ventas realizad...
requerimientos, agrupar por apertura y comenzar a definir los cubos a crear.



                         Se conoce con may...
Comprender la formación de la tabla de hechos
                     Entender que son las medidas
                     Conoc...
3.1. Introducción




Con lo aprendido en las unidades anteriores, podemos comenzar a definir el
diseño de nuestra base de...
Data Mart: son almacenes de datos con información de
                interés particular para un determinado sector de la e...
Los puntos de la estrella son las tablas de dimensiones.
      Cada esquema esta compuesto por una sola tabla de hechos
  ...
Ejemplos de Hechos
                       En un hospital: admisión de pacientes
                       En un operador tele...
Hijo: Son los elementos del siguiente nivel inferior que se relacionan
  con el miembro seleccionado. Pueden existir vario...
Ejemplos de dimensión
                         Dimensión zona geográfica

                    * PAIS               ARGENTI...
Evitamos duplicar dimensiones locales
      Aseguramos que los datos analizados estén organizados de la misma
   forma en ...
Este es un esquema donde las dimensiones tienen un esquema
                    estrella.

                     Dimensión  ...
Se muestra un esquema donde la dimensión zona geográfica
                     presenta un esquema copo de nieve.

        ...
Mejora la performance       Aumenta la cantidad de
                                                 uniones entre tablas
C...
Ejemplos de Dimensión Virtual
                 Podemos tener una dimensión Producto organizada de la
                 sigu...
Ejemplos de Dimensión Tiempo




La definición de la jerarquía la haremos teniendo en cuenta las necesidades
que tiene la ...
Deben ser numéricas.
      Cruzan todas las dimensiones en todos los niveles.

Las medidas pueden clasificarse en:
      N...
Cuenta de Distintos: cuenta los valores diferentes


                       Las agregaciones son resúmenes de datos
      ...
Calculo Matemático
En un sistema de RRHH, podemos querer medir el
promedio de horas extras por mes. Definimos la medida
ca...
Caso de Estudio




Ilustraremos los conceptos que aprendimos en esta unidad con nuestro
ejemplo de La Distribuidora Latin...
Trimestre
      Mes
      Día

La tabla de dimensión quedara formada:

                                  Dimensión Tiempo
...
sistemas OLTP. Cada tabla contiene los datos iniciales y su relación con el
resto.
La dimensión nos quedará normalizada po...
analizar.
Vimos que nuestro cliente necesita medir:
       El coste inducido en cada unidad vendida
       El valor de ven...
Lecciones Aprendidas
                       Un Data Mart adopta un esquema estrella para
                       maximizar ...
Preguntas de Reflexión
                 ¿Tenemos claramente definidos los requerimientos?
                 ¿Conocemos los ...
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Academia latinoamericana de Business Intelligence  albi
Upcoming SlideShare
Loading in …5
×

Academia latinoamericana de Business Intelligence albi

3,599
-1

Published on

Curso de Inteligencia de Negocios de Microsoft.

Published in: Education, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,599
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Academia latinoamericana de Business Intelligence albi

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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
  56. 56. 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
  57. 57. 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
  58. 58. 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

×