ACADEMIA LATINOAMERICANA DE BUSINESS INTELLIGENCE (ALBI) Contenido del curso

Convenciones
Para ubicar rpidamente los diferentes puntos desarrollados a travs de las unidades, se llev a cabo un diseo de grficos que harn referencia a cada tema. De esta manera el participante podr ubicar cada contenido sin la realizacin de un esfuerzo extra en la bsqueda y aprovechando al mximo el tiempo dedicado al estudio de cada una de las Unidades presentadas. En siguiente tabla se podr apreciar cada grfico y su significado: Convencin Descripcin Objetivos Son las metas a las que apunta el curso o el mdulo.

Conceptos clave Es el contenido que, por su relevancia de significado, propone definiciones, descripciones o informacin a la que como participante se le debe prestar especial atencin.

Riesgos Cualquier situacin que amenaza el xito del proyecto en general o afecta la capacidad del equipo de trabajo. Un problema que no ha sucedido, pero que podra causar prdidas o amenazar el xito del proyecto, si sucede. (Wiegers, 1998) Ejemplos Son situaciones conceptuales, reales o hipotticas de aplicacin de los conceptos tratados y su propsito es apoyar a la comprensin de los conceptos al asociarlos con posibles formas de aplicacin o de interpretar las que se proponen.

Pgina 1 de 94

Convencin

Descripcin 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.

Estadsticas 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 reflexin, detonan la asociacin del contenido conceptual con entornos de aplicacin del aprendizaje. Preguntas de Reflexin Son formulaciones que sirven como gua para controlar el desarrollo del proyecto. Al final de la ltima unidad, estas preguntas se renen formando un Check List.

Lecciones aprendidas Son frases o afirmaciones que al final de cada captulo sintetizan lo que el participante debi aprender y permiten parafrasear la informacin clave.

Diagramas, esquemas, fotografas, tablas, negritas y color en las fuentes

Son recursos que facilitan la lectura y la comprensin porque destacan, organizan, clasifican, jerarquizan, ilustran y/o representan el contenido con el propsito de facilitarte como participante la interaccin con el curso.

Pgina 2 de 94

Objetivos
Quin participe en la presente propuesta educativa, obtendr los conceptos tericos necesarios de Business Intelligence, formando una base consistente para adquirir posteriormente los conocimientos y as perfeccionarse en esta tecnologa. Al final del curso tendr los conocimientos suficientes para comprender qu es Business Intelligence, su necesidad, utilidad, desarrollo e implementacin.

Contenido
Las siguientes Unidades y temticas son las que se desarrollarn 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 solucin BI, su potencialidad en la toma de decisiones y por qu en la actualidad las empresas estn apostando a ello.

Unidad 2. Definiendo Soluciones OLAP

La Unidad 2 se recordarn los conceptos bsicos de un sistema OLTP con sus ejemplos, pasando posteriormente a la explicacin de un sistema OLAP. Se mencionarn y explicarn las caractersticas 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 cmo estos comienzan a transformarse en informacin del negocio. Hacia el final de la unidad, se vern algunos de los posibles procesos de seleccin y transformacin de datos (ETL) que permiten alimentar las tablas auxiliares que soportarn la estructura multidimensional.

Unidad 3. Diseando una solucin 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 solucin OLAP

En la Unidad 4 se vern consideraciones especficas de la construccin y procesamiento de un cubo.

Unidad 5. Implementando Cubos OLAP

En la Unidad 5 se ver como un usuario puede acceder a la informacin en un sistema de BI, teniendo en cuenta la seguridad y el tipo de herramienta de consulta utilizada.

Pgina 3 de 94

Unidad 1

Qu es Business Intelligence? 1.1 1.2 1.3 1.4 1.5 Introduccin A qu empresas les interesa BI? Qu es Business Intelligence? Qu puede hacer Business Intelligence? Quin necesita soluciones Business Intelligence? 1.5.1 Obtencin catica de informacin 1.5.2 Quin necesita analizar la informacin? 1.6 1.7 Primeros pasos? El futuro de Business Intelligence

Unidad 2

Definiendo Soluciones OLAP 2.1 Sistema Transaccional (OLTP) 2.1.1 Caractersticas 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. Informacin de Negocio 2.3.1 Convirtiendo Datos en Informacin 2.3.2 Transformacin y agrupacin de datos ETL

Unidad 3

Diseando una solucin OLAP 3.1 3.2 3.3 Introduccin Construyendo el data mart Esquema Estrella Tabla de Hechos Dimensiones Relaciones y Estructura de una dimensin Esquema Estrella Esquema Copo de Nieve

3.3.1 3.3.2

3.3.2.1 3.3.2.2 3.3.2.3

Pgina 4 de 94

3.3.2.4 3.3.2.5 3.3.2.6 3.4 Medidas 3.4.1 3.4.2

Padre Hijo (Parent- Child) Dimensiones Virtuales La dimensin Tiempo

Medidas Naturales Medidas Calculadas

Unidad 4

Construyendo una solucin OLAP 4.1. 4.2. Introduccin Tipos de Almacenamiento 4.2.1. MOLAP 4.2.2. ROLAP 4.2.3. HOLAP 4.3. 4.4. 4.5. 4.6. 4.7. Definicin de Agregaciones Procesamiento de cubos Cubos Virtuales Particiones La difcil bsqueda del equilibrio

Unidad 5

Implementando Cubos OLAP 1.8 1.9 Introduccin Seguridad

1.10 Consultas 1.11 Herramientas de visualizacin 5.4.1 La Tabla Pivotal 5.4.2 El Tablero de Control 1.12 Conclusiones 1.13 Check List

Pgina 5 de 94

Unidad 1. Introduccin a Business Intelligence

Objetivos
Dar una visin acerca del por qu se debe contar con un sistema de apoyo para la toma de decisiones: Conocer qu sistemas informatizados actan 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 solucin Business Intelligence.

Introduccin
Los rpidos cambios que se viven en el mercado actual junto a las competencias que se generan cada da, hacen que las empresas no puedan postergar las decisiones relacionadas directamente con el negocio; una demora en este sentido puede llevar la gestin 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 rpida, con informacin precisa para poder aprovechar las oportunidades: estar en el lugar indicado, en el momento oportuno, con la informacin correcta. Los sistemas orientados para la toma de decisiones son los englobados por el trmino 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 segn los objetivos y hasta crecer, pero en cuanto algo falla, los procesos se descontrolan, la coordinacin desaparece y, en el mediano plazo, la empresa se desploma sobre s misma. Esta puede parecer una visin apocalptica, pero, quin se arriesgara a llevar adelante una gestin basndose en la buena suerte?

Pgina 6 de 94

Contenido de la unidad
1.14 Introduccin 1.15 A qu empresas les interesa BI? 1.16 Qu es Business Intelligence? 1.17 Qu puede hacer Business Intelligence? 1.18 Quin necesita soluciones Business Intelligence? 1.5.1 Obtencin catica de informacin 1.5.2 Quin necesita analizar la informacin? 1.19 Primeros pasos? 1.20 El futuro de Business Intelligence

1.1 Introduccin
Tanto en empresas pequeas 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 segn 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 informacin que monitorean las actividades y transacciones elementales de la organizacin. Son sistemas que han cobrado un auge importante en la ltima dcada 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 ncleo de operaciones tradicionales de captura masiva de datos y servicios bsicos de tratamiento de datos, con tareas predefinidas. Nivel de administracin: Se realizan tareas de administradores de nivel intermedio apoyando las actividades de anlisis, de seguimiento, de control y toma de decisiones, realizando consultas sobre informacin almacenada en el sistema, proporcionando informes y facilitando la gestin de la informacin por parte de los niveles intermedios. Nivel estratgico: Tiene como objetivo realizar las actividades de planificacin a largo plazo, tanto del nivel de administracin como de los objetivos que la empresa posee.

Pgina 7 de 94

La informacin que se genera en la organizacin se consume en diferentes momentos segn el nivel: Plazo Corto plazo Mediano plazo Largo plazo Nivel Operacional y Administrativo De Conocimientos Estratgico Uso Obtencin y control de datos Decisiones tcticas Decisiones estratgicas

Las bases de datos transaccionales sirven como herramienta para los dos niveles bsicos de la pirmide, 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 pirmide, el Nivel de Administracin y el Nivel Estratgico, se tiene por tarea la toma de decisiones, tareas que estn estrechamente vinculadas con los objetivos del negocio.

Un sistema es un conjunto de elementos organizados que interactan entre s. Representa el conjunto de reglas de negocio que la organizacin define para llevar a cabo los procesos y procedimientos funcionales y operativos

Pgina 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 sistemticamente 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 organizacin 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 caractersticas tales como: Est orientada a la aplicacin. Tiene estructuras normalizadas. Contiene los datos de las operaciones. Los datos se almacenan con el mximo nmero de detalle. Se actualiza en lnea. 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 Pases Provincias Ciudades Etctera Cada una de las tablas y la base en s, estarn normalizadas para asegurar la integridad de los datos, minimizar el espacio ocupado y maximizar el rendimiento del mantenimiento de los datos.

Pgina 9 de 94

1.2 A qu empresas les interesa BI?

Gasto total, para Argentina, en soluciones de BI, por Mercado

Variacin del Presupuesto de BI 2006 vs. 2005

Empresas que invertirn Ms en BI (2006 vs. 2005)

Pgina 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 ingls de On-Line Transaction Processing, queriendo significar en su traduccin Procesamiento de Transacciones en Lnea.

Bajo el nombre de Business Intelligence (Inteligencia de Negocios) se cobijan diferentes acrnimos, 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 informacin calculando previamente todas las combinaciones de todos los niveles de todas las aperturas de anlisis. Es, por decirlo llanamente, un producto cartesiano que almacena todas las combinaciones. Se puede decir que este mtodo es exagerado o salvaje y en parte esta afirmacin es real. Lo que no debe perderse de vista es que esta salvajada es el precio que paga la organizacin para poder tomar decisiones correctas. Siempre va a ser ms barato el

Pgina 11 de 94

gasto que conlleva la adquisicin de SW o HW que el costo que representa una decisin tomada a destiempo. Data Mart: El almacn de datos de un hecho en particular se denomina Data Mart (DM). Data Mining: Est asociado al escaln ms alto de la pirmide (Nivel Estratgico) 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 Minera 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 definicin de BI tienen tres caractersticas comunes: Primera: Proveen informacin 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 caracterstica ms importante. Tercera: La capa semntica. 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 extraccin, transformacin y agregacin, lo verdaderamente importante es que la informacin le debe servir a los usuarios finales en un lenguaje de negocios comprensible por ellos sin la necesidad de intrpretes. 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 anlisis de la informacin para la correcta toma de decisiones que le permita a la organizacin 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 Objetivos Orientacin Operacionales A la aplicacin DW Informacin para la toma de decisiones Al sujeto

Pgina 12 de 94

Vigencia de los datos Granularidad de los datos Organizacin Cambios en los datos

Actual Detallada Organizacin normalizada Continuos

Actual + histrico Detallada + resumida Organizacin estructurada en funcin del anlisis a realizar Estable

A continuacin 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. Orientacin: Un sistema OLTP est orientado a la Aplicacin, 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 histricos para poder realizar anlisis comparativos, de tendencias, etctera. La cantidad de perodos almacenados depender exclusivamente de la necesidad de anlisis 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 organizacin como por las normas legales vigentes. En un OLAP estar dada por el tipo de anlisis que se quieran realizar. Si el anlisis del trfico se realiza analizando el nmero 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. Organizacin: Un sistema OLTP es normalizado, mientras que un sistema OLAP se basa en estructuras jerrquicas desnormalizadas modeladas de acuerdo a la forma en que se analizarn 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 presentacin de los datos en lnea y, menos an, pretende modificar los datos originales, solo consultarlos. La frecuencia de actualizacin de los datos en un sistema OLAP est definida por la granularidad.

Pgina 13 de 94

Datos vs. Informacin Diariamente manejamos datos sobre los nmeros telefnicos de las personas con las que tenemos contacto (amigos, familiares, el plomero, el delivery de pizzas, etctera). Estos telfonos nos llegan de distintas fuentes y podramos anotarlos en una libretita de telfonos o en un cuaderno comn. Entonces, Cul es la ventaja de anotar los nmeros de telfono que nos interesan en una libretita en lugar de utilizar un cuaderno? Es evidente, vamos a encontrar ms rpido los nmeros en la libretita que en el cuaderno ya que los tenemos organizados por la inicial del nombre. Y si adems pudiramos contar en nuestra libretita con una divisin para nuestras amistades, otra para nuestra familia y otra para servicios, cada una de ellas en diferentes colores de hojas? Tendramos nuestra informacin telefnica organizada de tal manera que al necesitar de ella sera rpidamente accesible. Si queremos llamar a un amigo, tendramos que identificar el grupo de pertenencia segn el color, luengo por el ndice buscamos el nombre y apellido y obtenemos el nmero de telfono.

Este sencillo ejemplo muestra conceptualmente la diferencia que existe entre datos e informacin y representa la semilla de un DW.

1.4 Qu puede hacer Business Intelligence?

Histricamente, para realizar un anlisis: Se deba llamar a una Mesa de Ayuda para solicitarle los datos necesarios ya que era el personal de Sistemas la que saba dnde se

Pgina 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 das. Luego de la larga espera, se reciban los ansiados datos, procedindose al anlisis. Era muy posible que el analista se diera cuenta que en realidad necesitaba contar con ms informacin, lo cual significaba repetir el ciclo mencionado.

En un DW se pueden reunir los elementos de datos apropiados desde diversas fuentes de aplicacin en un ambiente integral y centralizado, simplificando el problema de acceso a la informacin y en consecuencia, acelerando el proceso de consultas y anlisis. Las aplicaciones para soporte de decisiones basadas en warehousing, pueden hacer ms prctica y fcil la explotacin de datos para una mayor eficacia del negocio tanto desde el punto de vista de la disponibilidad como de la confiabilidad.

1.5 Quin necesita soluciones Business Intelligence?

Es posible que an 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 solucin BI. Vayamos por partes.

Pgina 15 de 94

1.5.1 Obtencin catica de informacin: Uno de los problemas ms comunes cuando se necesita consolidar informacin o realizar tareas de anlisis, es que hay que saber dnde 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 aplicacin que los soporte y por consiguiente el usuario lleve parte del negocio en planillas de clculo almacenadas en su computadora. Tambin puede pasar que los datos histricos slo se mantengan en informes impresos ubicados en armarios ya sea en el lugar de trabajo o en un depsito externo. El recolectar este universo de datos dispersos en todos los sectores y lugares de la empresa, hace catica la obtencin de la informacin que se necesita. El disparador de las soluciones de BI son las Killer Queries (Consultas asesinas). Si se quiere saber cunto debo producir en el segundo trimestre del ao, tal vez deba conocer la previsin de ventas y la tendencia de las ventas en el ao actual y las ventas reales de los ltimos 5 aos. Si se ejecuta esta consulta directamente contra un sistema OLTP, la respuesta puede que tarde varias horas y este no sera el mayor problema. El autntico peligro es que colapse todo el sistema de informacin y nadie en la empresa pueda trabajar mientras tanto, con las prdidas que esto ocasiona.

Pgina 16 de 94

1.5.2 Quin necesita analizar la informacin? El xito de una organizacin y de la gestin de la empresa se centra en el uso que se hace de la informacin. No se puede gestionar lo que no se controla. No se puede controlar lo que no se mide, si no se tiene informacin para controlar los procesos ocurrir el caos.

La informacin reduce la incertidumbre y facilita la toma de mejores decisiones. Entonces, podemos concluir que si existe una organizacin, si esta organizacin 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 tambin dentro de la empresa un sistema basado en BI.

Tomar decisiones sin la informacin adecuada, sobre todo cuando sta se encuentra disponible en la organizacin, es un riesgo que ninguna empresa debera correr.

Finalmente surgen dos interrogantes: Cundo necesita la empresa hacer uso de esta informacin? Cundo puede la empresa hacer uso de esta informacin? La respuesta para los dos casos es la misma: Es necesario decidir ahora y se debe tener la informacin ahora!

Suponer que desarrollar un sistema basado en la tecnologa Business Intelligence es algo lujoso, de costos muy elevados o que es un elemento de Marketing es una concepcin errnea de la idea.

1.6 Primeros pasos

Pgina 17 de 94

Aceptando que se reconoce la necesidad de contar con un sistema basado en BI, se plantean las preguntas: Cmo comienzo? Hasta dnde debo llegar en una primera etapa? La creacin 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 unificacin de los datos que se usan en la toma de decisiones en un repositorio nico. Una experiencia desalentadora es la de llegar a una reunin y ver que cada expositor porta una planilla de clculo propia, con datos propios que no coinciden con ninguna de las dems e iniciarla con una discusin sobre la validez de las distintas fuentes de datos. Implementar una capa semntica til. Que todos entiendan con claridad el significado de la informacin. Una vez cumplidos estos objetivos bsicos, el resto del camino depender de las necesidades propias de cada organizacin. 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 estn 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 obtendrn 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 informacin 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 crculo: se podrn definir las previsiones, los objetivos, la planificacin, la consolidacin presupuestaria, etctera.

Caso de Estudio

Pgina 18 de 94

Escenario La Distribuidora Latinoamericana de Alimentos (DLA), se dedica a la comercializacin de productos comestibles y bebidas a travs de sus Hipermercados y Supermercados.

Si bien cuenta con una amplia e importante cantidad de locales en la Repblica Argentina, Brasil y Uruguay, un claro objetivo a mediano plazo es inaugurar locales en el resto de los pases 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 pases 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 informacin, requiere que sea presentada por zona geogrfica 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 categora 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 anlisis, 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 ao fiscal (El premio ser distinto si se cumple con los objetivos globalmente para el

Pgina 19 de 94

ao o si, adems, se cumplen los objetivos en todos los meses en particular).

Se tiene distincin entre un sistema basado en lo operacional y un sistema que apoya la toma de decisiones. Comprendemos Intelligence. ahora qu es Business

Se comprenden las ventajas de una solucin Business Intelligence. Se comprende y se puede decidir cundo aplicar una solucin Business Intelligence. Se puede especificar quines necesitan una solucin Business Intelligence.

Est preparada la organizacin para trabajar con BI? Se cuenta con el compromiso de la alta gerencia para encarar un proyecto de creacin de un sistema de BI? Tiene presente que deber capacitar a los usuarios en la disciplina asociada a BI? Estn 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 bsicos de un sistema OLTP con sus ejemplos. Comprender las caractersticas de un Data Warehouse junto con los componentes que lo conforman. Reconocer la necesidad de los procesos de seleccin y transformacin de datos (ETL) que permiten alimentar las tablas auxiliares que soportarn

Pgina 20 de 94

la estructura multidimensional. Conocer las diferencias entre un sistema transaccional y un Data Warehouse. Comprender el trmino OLAP y su relacin con la navegabilidad de la informacin. Conocer sobre las transformaciones necesarias para armar un DW a partir de una Base de Datos Operacional.

Introduccin
Para llevar adelante el desarrollo de un DW, deben tenerse en cuenta una serie de pautas que debern 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 tambin identificar los orgenes de datos para luego seleccionarlos, depurarlos, transformarlos e importarlos.

Contenido de la unidad
2.1 Sistema Transaccional (OLTP) 2.1.1 Caractersticas 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. Informacin de Negocio 2.3.1 Convirtiendo Datos en Informacin 2.3.2 Transformacin y agrupacin de datos ETL

2.1 Sistema Transaccional (OLTP)

2.1.1 Caractersticas
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 caractersticas 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.

Pgina 21 de 94

Los sistemas OLTP son los responsables del mantenimiento de los datos, ya sea agregando datos, realizando actualizaciones o bien eliminndolos. 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 diseo. Si se quisiera obtener determinada informacin histrica relativa al negocio consultando un sistema OLTP, se producira un impacto negativo en el funcionamiento del sistema. Normalmente, para el diseo de un sistema OLTP se define un modelo de Diagrama Entidad Relacin (DER). Un DER es una representacin de la realidad a travs de un esquema grfico que contiene los siguientes elementos: Entidades: Una Entidad es un tipo de objeto que puede identificarse de manera nica por algn medio. Este objeto es traducido a la estructura fsica de una base de datos como una tabla. Atributos: Las caractersticas particulares que distinguen a las Entidades se denominan Atributos. Relaciones: vnculos existentes entre las tablas que sirven para asegurar la integridad referencial.

Un ejemplo de Entidades y Atributos es: Persona (IdPersona, IdLocalidad) Nombre, Apellido,

Grupo (IdPersona, Telefono)

Para llegar a esquematizar un DER, se debe realizar un proceso de normalizacin basado en las Formas Normales, lo que adems garantiza una optimizacin del espacio de disco a utilizar.

2.1.2 Usos Comunes de OLTP

Toda organizacin 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 definicin de OLTP se pueden encuadrar a todos los sistemas tradicionales dedicados a la captura, validacin y

Pgina 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 Automticos. 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 lnea 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 manejndola como una transaccin. Emitir comprobante. Saludar al Cliente. La situacin en un Sistema de Ventas por medio de un sitio Web, sera la siguiente: Validar al cliente y autenticarlo en el sistema. Tomar el pedido. Controlar los topes de crditos. Informar los valores parciales de la compra y acumulados. Requerir confirmacin del cliente antes de enviar el pedido. Enviar el pedido. Descontar del stock las cantidades vendidas. Informar el nmero 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 crditos.

Pgina 23 de 94

A su vez, debe mantenerse una integridad en la informacin, 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 electrnico Sistemas de facturacin Sistemas de stock

Pgina 24 de 94

Almacenamiento Transaccional
$

Comercio electrnico

Bancos

Pedidos
$ $
$

Sistemas OLTP

Facturacin

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 visin de los datos orientada hacia el anlisis y una rpida y flexible navegacin por estos. Las siguientes son caractersticas que la tecnologa OLAP posee: Las bases de datos de OLAP tienen un esquema que est optimizado para que las preguntas realizadas por los usuarios sean respondidas rpidamente. 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 ms all del anlisis de dos dimensiones que puede proporcionar una simple planilla de clculo utilizada como tal. Los usuarios pueden cambiar fcilmente las filas, las columnas, y las pginas en informes de OLAP, pudiendo leer la informacin de la manera que se crea ms conveniente para el anlisis.

Pgina 25 de 94

Un Sistema OLAP Los sistemas OLAP son una solucin que devuelve rpidas 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 informacin ejecutivos. Los usuarios y los administradores generalmente de mandos altos y medios, reciben la informacin sobre los indicadores de funcionamiento dominantes del negocio y de las excepciones o las variaciones segn sea de patrones y de estndares preestablecidos. Los Sistemas de Informacin Ejecutivos (EIS) presentan tpicamente datos multidimensionales en formatos grficos. 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 comunicacin, anlisis del mes-cierre, anlisis de lo beneficioso del producto, los presupuestos y pronstico. Los analistas financieros utilizan OLAP extensivamente para el anlisis de datos financieros y operacionales para contestar las preguntas de la gerencia mayor. OLAP en la Actividad Financiera Reportes analticos. Planeamiento. Anlisis.

Pgina 26 de 94

Ventas y aplicaciones de Marketing. Existen diferentes formas de llegar a los clientes para alcanzar los objetivos de venta y de comercializacin propuestos. Por esto, la utilizacin de sistemas OLAP, donde es importante contar con informacin organizada de manera rpida, es aconsejable. Los ejemplos incluyen anlisis de la facturacin, anlisis de producto, anlisis del cliente, y anlisis de ventas regional. OLAP en el Marketing Anlisis de productos. Anlisis de Clientes. Anlisis de Facturacin.

Otros Usos. Las bases de datos de OLAP se adaptan a una amplia gama de anlisis, incluyendo rendimiento de procesamiento y eficacia de la fabricacin, eficacia del servicio de cliente, y anlisis 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 Anlisis de la Produccin. Anlisis de Servicios al cliente. Evolucin del Costo del producto.

2.3 Datos de Origen vs. Informacin de Negocio

El presente esquema representa las distintas etapas que se deben ejecutar para la construccin de un Data Mart, desde que se identifican los datos originales en los sistemas transaccionales hasta que los Usuarios pueden disponer la informacin. A modo de gua, se ir indicando qu parte de estos procesos cubre cada Unidad.

Pgina 27 de 94

Las etapas que deben cubrirse durante el proceso de construccin de un DW cumplen con lo siguiente: 1. Identificacin 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 seleccin, transformacin e importacin 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 informacin identificada en la etapa de requerimientos.

2.3.1 Convirtiendo Datos en Informacin

Para convertir los datos en informacin, 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 cmo estos datos reflejan metas y objetivos que abarcan el negocio involucrado. Un DW, clasifica la informacin en base a los aspectos que son de inters para la empresa. En el ambiente operacional se disea alrededor de las aplicaciones y funciones (ventas, facturacin, stock, etc.). La base de datos combina los

Pgina 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 anlisis del negocio se reconoce como un valor significativo para una organizacin, las peticiones de los datos y de la informacin 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 informacin. En un sistema OLAP, estos temas se resuelven por nica vez, en la etapa de diseo.

2.3.2 Transformacin y agrupacin 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 homogneos 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, transformacin y carga de datos en un DW se denominan ETL, sus siglas en ingls significan Extract Transform Load.

Pgina 29 de 94

Es comn 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 codificacin 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. Bsicamente deben realizarse las siguientes tareas: Establecer las transformacin. reglas que sern utilizadas para realizar la

Detectar las inconsistencias que pueden originarse al tomar los datos desde distintas fuentes. Planificar cuidadosamente y con detalles la transformacin de los datos que den como resultado final conjuntos de datos consistentes.

Convenciones aplicaciones

diferentes

en

el

desarrollo

de

Codificacin: Un claro ejemplo es la codificacin y descripcin 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 transformacin, habr que elegir una convencin nica para el DW, que puede ser M y F y transformar los datos.

Aplicacin A: M y F Aplicacin

B: 1 y 0

M-F

Aplicacin C: Masculino y Femenino

Unidades de medida de los atributos: Las unidades pueden tener distintas unidades de medidas, segn el origen del sistema OLTP. Un ejemplo es hablar de litro, centmetros cbicos o hectolitros. Habr que elegir una nica unidad de medida que sea til para el DW y transformar los datos.

Pgina 30 de 94

Aplicacin A: Litros Aplicacin B: cm3 Aplicacin C: Hectolitros Litros

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 transformacin correspondiente.

Aplicacin A: yyyy/mm/dd Aplicacin B: mm/dd/yyyy Aplicacin C: dd/mm/yyyy dd/mm/yyyy

Varias columnas a una: En un sistema OLTP, los datos de una persona, como ser Direccin pueden almacenarse en diferentes campos de la misma tabla (Calle, Nmero, 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.

Pgina 31 de 94

Una columna a varios: los sistemas ms antiguos solan colocar el tipo y nmero 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 nmero 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 mxima a almacenar ene. SW y sumar los datos agrupando segn ese criterio. Al definirse la granularidad se est diciendo, al mismo tiempo: Las aperturas que son de inters. El grado de detalle que se necesita. Es decir, si tomamos como ejemplo la medicin del trfico telefnico, puede definirse que se necesitan los totales de llamados por cliente por da. Vemos que el mximo detalle que es requerido es el da, no interesara 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 Da. 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 da por factura o por boca de expendio, obteniendo el resultado que vemos en el grfico.

Pgina 32 de 94

Una vez que contamos con el plan de trabajo desarrollado segn las reglas de transformacin, 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 transformacin.

Mala interpretacin de los Requerimientos Durante la etapa de relevamiento previo al diseo de un sistema OLAP, es importante entender con precisin la problemtica del negocio. Esto incluye definir el hecho y qu medidas sern necesarias desarrollar en el sistema. Muchos sistemas no llegan a feliz trmino a causa de una etapa de relevamiento en donde los requerimientos planteados no apuntan a los objetivos del negocio.

Pgina 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 travs 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 sern, justamente, las Ventas. Vamos a comenzar analizando cada necesidad y cul es la dimensin o medida que habr que crear para satisfacer la misma. Luego desarrollaremos una tabla en donde resumiremos la informacin obtenida. Esta tabla nos servir en la etapa de diseo. Analizaremos el primer conjunto de necesidades: La cantidad de unidades vendidas en los pases que alcanza el Mercado actual. En esta consigna se detecta como posible medida a las unidades vendidas, la cual necesitamos ver detallada por Pas. Por otro lado, la cantidad de unidades vendidas est referida a los productos: detectamos ya una nueva dimensin, 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 dimensin 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 informacin, requiere que sea presentada por zona geogrfica y sucursal. Aqu tenemos una nueva dimensin 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
Pgina 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 categora 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 segn su categora y los clientes que los adquirieron. De aqu se desprende que necesitamos una nueva dimensin Clientes y que los Productos deben mostrarse agrupados por Categora de Productos, cosa que nos define un nivel en la dimensin Producto. Premiar anualmente a aquellos vendedores que superen los objetivos de venta que les fueran asignados. El anlisis, 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 ao fiscal (El premio ser distinto si se cumple con los objetivos globalmente para el ao o si, adems, se cumplen los objetivos en todos los meses en particular). Sobre estos requerimientos, debemos agregar solamente la dimensin 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, podra ser de suma utilidad el realizar el anlisis de cada una de las medidas por Tipo de Sucursal. Todo sistema DW contiene informacin histrica que la empresa analizar para diferentes perodos, agregaremos una dimensin ms denominada Tiempo. A su vez, es comn que sea necesario que se quieran analizar las ventas obteniendo el promedio de las mismas. Por lo tanto, viendo esta posible necesidad, sera conveniente que desarrollar la medida Ventas Unidades Promedio. Para ver la informacin obtenida en los relevamientos de una manera ms 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 dimensin.
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

Pgina 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 dnde 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 inters? Ha relevado las aperturas por las cuales se analizar la informacin? Ha relevado las medidas o indicadores que se usarn para evaluar los Hechos? Cul es la granularidad con que es necesaria ver la informacin 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 seleccin, transformacin y carga de datos (ETL)?

Unidad 3. Diseando una solucin OLAP

Objetivos

Pgina 36 de 94

Comprender la formacin 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 3.6 3.7 Introduccin Construyendo el data mart Esquema Estrella Tabla de Hechos Dimensiones Relaciones y Estructura de una dimensin Esquema Estrella Esquema Copo de Nieve Padre Hijo (Parent- Child) Dimensiones Virtuales La dimensin Tiempo

3.7.1 3.7.2

3.7.2.1 3.7.2.2 3.7.2.3 3.7.2.4 3.7.2.5 3.7.2.6 3.8 Medidas 3.8.1 3.8.2

Medidas Naturales Medidas Calculadas

Pgina 37 de 94

3.1. Introduccin

Con lo aprendido en las unidades anteriores, podemos comenzar a definir el diseo de nuestra base de datos OLAP. En esta unidad, desarrollaremos el diseo 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 mdulo, el lector comprender cmo definir la tabla de hechos, cmo 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 visin desplegada del cubo.

Pgina 38 de 94

Data Mart: son almacenes de datos con informacin de inters particular para un determinado sector de la empresa Data Warehousing: es el conjunto de almacenes de datos particulares (Data Mart) con informacin de inters para la empresa en general

Cada uno de los siguientes son ejemplos Data Mart (DM) Ventas Recursos Humanos Produccin El Data Warehousing es el conjunto de esos data mart DM de Ventas + DM de Recursos Humanos + DM de Produccin

3.2. Construyendo el data mart

Hasta ahora hemos analizado los requerimientos del usuario, y depuramos sus datos para la formacin del data warehousing, en esta unidad comenzaremos a disear 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 ms pequeas que definirn 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 construccin del modelo.

3.3. Esquema Estrella

Para facilitar el anlisis, 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 dimensin que contienen los atributos de las aperturas que interesan al negocio que se pueden utilizar como criterios de filtro y son relativamente pequeas. Cada tabla de dimensin se vincula con la tabla de hechos por un identificador. Las caractersticas de un esquema de estrella son: El centro de la estrella es la tabla de hecho.

Pgina 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 Admisin de Pacientes (Hecho) por servicio, pacientes y zona geogrfica a lo largo del tiempo.
Dimensin Servicio Dimensin Paciente

Tabla de Hechos Admisin Pacientes

Dimensin Tiempo

Dimensin Zona Geogrfica

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 numricas, 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 sern analizados.

Pgina 40 de 94

Ejemplos de Hechos En un hospital: admisin de pacientes En un operador telefnico: Trfico telefnico

Un hecho es un concepto de inters primario para el proceso de toma de decisiones, corresponde a eventos que ocurren dinmicamente en el negocio de la empresa.

3.3.2

Dimensiones

Disearemos y construiremos cada dimensin basados en los procesos de negocio definidos por el cliente. Las dimensiones organizan los datos en funcin de un rea de inters para los usuarios. Cada dimensin describe un aspecto del negocio y proporciona el acceso intuitivo y simple a datos. Una dimensin provee al usuario de un gran nmero de combinaciones e intersecciones para analizar datos. Las tablas de dimensiones son las compaeras de las tablas de hechos. Cada dimensin 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 dimensin en su esquema.

3.3.2.1

Relaciones y Estructura de una dimensin

Cada nivel de una dimensin debe corresponderse con una columna en la tabla de la dimensin. Los niveles se ordenan por grado de detalle y se organizan en una estructura jerrquica. 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 dimensin existen relaciones, estas se pueden comprender como las relaciones que existen en un rbol genealgico donde los trminos padre, hijo, hermano, primo, etc. indican una correspondencia entre elementos del rbol; y los miembros de la dimensin se comportan como familiares dentro del rbol genealgico. Padre: Es el miembro del nivel inmediatamente superior que se relaciona con el miembro seleccionado. Cada elemento tiene un solo padre.

Pgina 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 dimensin es miembro de ella.

Pgina 42 de 94

Ejemplos de dimensin Dimensin zona geogrfica

* PAIS ** PROVINCIA *** CIUDAD
ARGENTINA BUENOS CORDOB AIRES A MAR VILLA LA del GRAL. PLAT PLAT BELGRA A A NO BRASIL SAN PABLO . URUGUAY MONTEVID EO

Ejemplos de relaciones En una dimensin zona geogrfica tendramos las siguientes relaciones entres niveles y entre miembros: Padre: Argentina es padre de Buenos Aires y de Crdoba Hijo: Buenos Aires y Crdoba son hijos de Argentina Hermano: Buenos Aires y Crdoba son hermanos el uno al otro, tambin son hermanos Argentina, Brasil y Uruguay. Primo: Mar del Plata es primo de Villa General Belgrano. Descendiente: Todos los miembros que estn 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

Pgina 43 de 94

Evitamos duplicar dimensiones locales Aseguramos que los datos analizados estn 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 dimensin deber ser modificada en todos los cubos

Ejemplos de Dimensin Compartida La dimensin Producto puede utilizarse para el Data Mart Ventas y para el Data Mart Produccin. As, la dimensin producto es una dimensin compartida por los dos Data Mart.

Al definir una dimensin debemos prestar especial atencin en los requerimientos del cliente, ya que una mala definicin de la dimensin, o de sus niveles podra implicar que no obtengamos los resultados deseados. Si la definicin de las dimensiones no es la correcta, no sern 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 modificacin o cambio en una dimensin compartida sea vlida para todos los cubos que la empleen

3.3.2.2

Dimensiones: Esquema Estrella

En el esquema estrella cada dimensin 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 dimensin estn desnormalizadas lograremos en el modelo del data mart, una menor cantidad de tablas.

Pgina 44 de 94

Este es un esquema donde las dimensiones tienen un esquema estrella.

Dimensin Servicio Dimensin Paciente

Tabla de Hechos Admisin Pacientes

Dimensin Tiempo

Dimensin Zona Geogrfica

3.3.2.3

Dimensiones: Esquema Copo de Nieve

El esquema copo de nieve es una variacin del esquema estrella donde alguna punta de la estrella se explota en ms tablas. El nombre del esquema se debe a que el diagrama se asemeja a un copo de nieve. En este esquema, las tablas de dimensin copo de nieve se encuentran normalizadas para eliminar redundancia de datos. A diferencia del esquema estrella, los datos de las dimensiones se reparten en mltiples 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 caractersticas de un copo de nieve: La dimensin esta normalizada Los distintos niveles se encuentran almacenados en tablas separadas Se argumenta ahorro de espacio

Pgina 45 de 94

Se muestra un esquema donde la dimensin zona geogrfica presenta un esquema copo de nieve.
Pas

Copo de nieve Dimensin zona Geografica

Provincia

Ciudad

Servicio

Admisin Paciente

Paciente

Tiempo

Ejemplo de Tabla Normalizada y Tabla Desnormalizada En la imagen vemos en la tabla normalizada los datos nombre de pas y nombre de provincia aparecern una sola vez en las tablas Pas y Provincia respectivamente. Si en cambio, la tabla esta desnormalizada tendremos redundancia de datos, ya que se repetirn los datos del Pas y de la Provincia por cada Ciudad.
Normalizada Pas ID_Pas Pas Provincia ID_ Provincia Provincia ID_Pas Zona Geogrfica Desnormalizada

Ciudad ID_ Ciudad Ciudad ID_Provincia

Id _ Pas Pas ID_Provincia Provincia ID_Ciudad Ciudad

Estrella Cantidad de tablas Menor

Copo de nieve Mayor

Pgina 46 de 94

Mejora la performance Consultas Almacenamiento Aumenta el espacio

Aumenta la cantidad de uniones entre tablas provocando baja en la perfomance Ahorra espacio

3.3.2.4

Dimensiones: Padre Hijo (Parent Child)

Una dimensin padre-hijo es una dimensin donde el dato del Padre se relaciona con el Hijo y ambos se encuentran en la misma tabla de dimensin, es decir, la dimensin se relacionan consigo misma. Ejemplos de Dimensin Padre - Hijo La dimensin 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, Crditos 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 fsico en el cubo, se evalan en el momento de la consulta. Funcionan de manera similar a las dimensiones reales y son transparentes para el usuario.

Pgina 47 de 94

Ejemplos de Dimensin Virtual Podemos tener una dimensin Producto organizada de la siguiente manera: Producto (Dimensin real) Fabricante Marca Calibre Producto Si el usuario requiere que sus anlisis de informacin se realicen por Marca, utilizando la dimensin Producto requerir seleccionar a cada fabricante para obtener la informacin de la marca. Para evitar esto, podemos crear una dimensin virtual donde el orden de los niveles Fabricante - Marca estn invertidos, que le permita ver sus datos por Marca sin necesidad de seleccionar a todos los fabricantes. Esta dimensin la construiremos de la siguiente manera: Producto_Marca (Dimensin virtual 1) Marca Fabricante Calibre Producto Otra necesidad del usuario podra ser obtener los totales o filtros de calibre sin importar la marca o el fabricante, entonces construiramos una dimensin virtual que contenga solo la columna calibre. Calibre (Dimensin virtual 2) Calibre

3.3.2.6

La dimensin Tiempo

Mencionaremos esta dimensin ya que ocupa un lugar especial en cada data mart. Recordemos que el tiempo es parte implcita de la informacin que contiene el data mart. Esta dimensin la podemos definir separndola en distintas jerarquas de tiempo: Ao Semestre Mes

Pgina 48 de 94

Ejemplos de Dimensin Tiempo

La definicin de la jerarqua la haremos teniendo en cuenta las necesidades que tiene la organizacin. Debemos contemplar los periodos de tiempo por los cuales la informacin necesita ser analizada y la regularidad con la que se cargaran los datos en el cubo. Consideraciones para esta dimensin: Nombres de los miembros: Cuando construyamos la dimensin tiempo es conveniente que los nombres de los miembros sean nicos. As, si utilizamos una nomenclatura para la jerarqua MES que sea Mes Ao cuando busquemos un periodo debemos identificarlo como Julio 2006. De esta manera nos ahorramos de utilizar dos niveles de la dimensin logrando una mayor calidad en los informes. Si en cambio, el nombre de la jerarqua MES se compone solo del nombre del mes, para identificar el periodo Julio del 2006 primero debemos seleccionar sobre el nivel Ao y luego sobre el nivel Mes. Puede existir mas de una: Cabe aclarar que no necesariamente esta dimensin es nica dentro del cubo, podramos tener que armar ms de una dimensin Tiempo. Si necesitramos analizar la informacin de la empresa en base al ao calendario y realizar otro anlisis basndonos en el ao fiscal, deberamos 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, numrica, 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 numricos porque estos valores son las bases de las cuales el usuario puede realizar clculos. Si la medida fuera un valor no numrico debemos codificarla a un valor numrico en el proceso de obtencin de datos, y luego cuando tengamos que exponer sus valores decodificarla para mostrarla con el valor original. Las siguientes son algunas de las caractersticas de las medidas:

Pgina 49 de 94

Deben ser numricas. 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 Admisin de Pacientes las medidas pueden ser: Pacientes Admitidos Pacientes Atendidos En un operador telefnico, donde el hecho es Trafico Telefnico, las medidas pueden ser: Llamadas Cantidad Llamadas Duracin Ejemplos de Medidas no numricas Supongamos el hecho Recursos Humanos, donde podemos tener la medida Sexo que toma los valores F o M. Estos valores debemos codificarlos en valores numricos durante el proceso de transformacin 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 numricas que queremos analizar que provienen directamente de los sistemas OLTP. Cuando definimos una medida debemos tener en cuenta cual ser la forma de agregacin (agrupacin de la misma) al subir por la estructura dimensional. Estas formas de agregacin pueden ser: Suma: es la operacin que suma los valores de las columnas Cuenta: realiza un conteo de los valores Mnima: devuelve un valor mnimo Mxima: proporciona el mayor de los valores

Pgina 50 de 94

Cuenta de Distintos: cuenta los valores diferentes Las agregaciones son resmenes 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 expresin medidas calculadas es muy amplio y engloba a cualquier manipulacin de las medidas naturales que nos faciliten el anlisis de los hechos. En una medida calculada puede haber: Clculos Matemticos Expresiones condicionales Alertas Estos tres tipos (clculos, condiciones y alertas) usualmente pueden existir juntos dentro de la misma medida calculada.

Pgina 51 de 94

Calculo Matemtico 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 Dotacin. Expresiones condicionales Para la medida calculada anterior, Promedio de Horas Extras, necesitaremos verificar la condicin de numerador diferente de cero para evitar que la divisin nos arroje un error. Si Dotacin es distinto de cero entonces Promedio de Horas Extras ser igual a Horas Extras dividido Dotacin. Si Dotacin 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 vaca. Podemos construir una medida Cumplimiento de Ventas que sea una alerta del tipo semforo 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 ms del 80 % de lo presupuestado.

Pgina 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 Construccin de las Dimensiones Etapa 2 Armado de la Tabla de Hechos Etapa 3 Definicin de las Medidas Construccin de las Dimensiones
Como primer paso definiremos las dimensiones porque estas nos darn 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 segn 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, debera haber una exacta coincidencia entre la definicin 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 estn correctos o bien definimos mal las dimensiones. Comenzaremos por la Dimensin Tiempo ya que, como aprendimos en esta unidad, es la ms importante dentro de cualquier data mart. Nuestro cliente necesita analizar sus datos diariamente, entonces definiremos los niveles: Ao Semestre

Pgina 53 de 94

Trimestre Mes Da La tabla de dimensin quedara formada:

Dimensin Tiempo

* ** *** **** *****

Ao Semestre Trimestre Mes Da

Dimensin Sucursal, usaremos un esquema estrella y su estructura jerrquica ser:

Dimensin Sucursal

*
** *** **** *****

Sucursal Tipo Sucursal Pas Provincia Ciudad

Dimensin Vendedor, al igual que sucursal, tendr un esquema estrella y quedar definida por los niveles:
Dimensin Vendedor

*
** ***

Sucursal Seccin Vendedor

Dimensin Cliente tendr todos los atributos de un cliente.

Dimensin Cliente

*
** *** ****

Pas Provincia Ciudad Razn Social

Dimensin Producto, esta dimensin la construiremos segn un esquema copo de nieve. En estos casos se mantiene la normalizacin propia de los

Pgina 54 de 94

sistemas OLTP. Cada tabla contiene los datos iniciales y su relacin con el resto. La dimensin nos quedar normalizada por lo que usaremos ms tablas para construirla. Nuestro cliente puede clasificar sus productos segn la categora, 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

Definicin de las Medidas

Recordemos que las medidas son los valores numricos que el usuario desea

Pgina 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 tambin 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 das, comprobando la condicin del numerador diferente de cero. Realizadas estas tres etapas, podemos ver el diseo completo de nuestro data mart.

Pgina 56 de 94

Lecciones Aprendidas
Un Data Mart adopta un esquema estrella para maximizar la performance de las consultas. Las dimensiones son categoras descriptivas por las cuales las medidas se pueden separar para el anlisis. La dimensin Tiempo esta implcita en todo Data Mart Las medidas son los datos numricos de inters primario para el cliente Con las medidas calculadas se pueden construir alertas

Pgina 57 de 94

Preguntas de Reflexin
Tenemos claramente definidos los requerimientos? Conocemos los hechos que se quieren analizar, los indicadores y las aperturas por las cuales se quiere hacer el anlisis? Concuerda esta definicin con las tablas auxiliares que creamos y poblamos con datos de los sistemas OLTP? Sabemos si los usuarios utilizarn las dimensiones para navegar o para filtrar? Cubren las dimensiones diseadas 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 agregacin, al salir de la granularidad mnima, para todas las medidas naturales? Estn definidas las frmulas o criterios de todas las medidas calculadas? Estn correctamente definiciones? documentadas todas las

Unidad 4. Construyendo una solucin OLAP

Objetivos
Diferenciar los distintos modos de almacenamiento Comprender qu es y como definir el porcentaje de agregacin 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

Pgina 58 de 94

4.8. 4.9.

Introduccin Tipos de Almacenamiento 4.2.1. 4.2.2. 4.2.3. MOLAP ROLAP HOLAP

4.10. 4.11. 4.12. 4.13. 4.14.

Definicin de Agregaciones Procesamiento de cubos Cubos Virtuales Particiones La difcil bsqueda del equilibrio

4.1. Introduccin

En esta unidad abordaremos los conceptos a tener en cuenta para la implementacin del data mart. Describiremos los distintos tipos de almacenamiento y las consideraciones que debemos analizar para mejorar la performance del sistema. Adems, 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 ms adecuado para los requerimientos de la organizacin, como balancear los distintos factores que intervienen al implementar un cubo.

Pgina 59 de 94

4.2. Tipos de Almacenamiento

Haciendo un pequeo balance de las unidades anteriores, vemos que ya tenemos: un diseo de requerimientos, sabemos de dnde y cmo obtener los datos y ya contamos con la definicin de la estructura multidimensional. Ahora que vamos a armar fsicamente el cubo debemos elegir entre los distintos modos de almacenamiento que podemos utilizar. Para facilitar esta eleccin, desarrollaremos los conceptos de MOLAP, ROLAP y HOLAP y luego haremos una comparacin 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 informacin OLAP no coincida con los datos de origen actuales. Como caracterstica del almacenamiento MOLAP podemos desatacar: Provee excelente rendimiento y compresin 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 mtodo, es muy apropiado para cubos con uso frecuente por su rpida respuesta.

AGREGACIONES Y DATOS

Base de Datos Relacional Base de Datos Multidimensional

Vista de Usuario

4.2.2.

ROLAP

Pgina 60 de 94

En un modelo ROLAP (OLAP Relacional) toda la informacin del cubo, sus datos, su agregacin, 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 ms 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 histricos. 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

Base de Datos Relacional

Base de Datos Multidimensional

Vista de Usuario

4.2.3.

HOLAP

HOLAP (OLAP hbrido) 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 bsqueda que accedan datos sumarizados, HOLAP es equivalente a MOLAP. Por el contrario, si los procesos de consultas accedieran a los mximos niveles de detalle, deberan recuperar los datos de la base de datos relacional y esto no seria tan rpido comparado con una estructura MOLAP. Los cubos almacenados como HOLAP, son ms pequeos que los MOLAP y responden ms rpidos que los ROLAP. Usos comunes de HOLAP Cubos que requieren rpida respuesta Cuando existen sumarizaciones basadas en una gran cantidad de datos de origen.

Pgina 61 de 94

Solucin de compromiso para bajar el espacio ocupado sin perjudicar totalmente el rendimiento de las consultas.

DATOS

AGREGACIONES

Base de Datos Relacional

Base de Datos Multidimensional

Vista de Usuario

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 opcin

Ejemplo del operador telefnico. Supongamos que: Se miden las llamadas realizadas x Da y x Cliente. El tiempo se estructura en Da Mes Ao. Los Clientes se estructuran en Cliente Ciudad Pas. Definicin MOLAP Llamadas para un Da y EM Cliente Suma de llamadas para algn cruce de Cliente Tiempo donde al menos uno de las dos dimensiones EM no est en el mnimo nivel. (Cliente y Mes Ao, Da y Ciudad o Pas, etctera) EM = Estructura Multidimensional BR = Base de Datos Relacional Datos detallados Datos sumarizados ROLAP BR HOLAP BR

BR

EM

Pgina 62 de 94

MOLAP

ROLAP

HOLAP Modelo Multidimensional Base de datos relacional Sencillo Buena para consultas que posean agregaciones, Regular para datos de bajo nivel

Almacenamiento Modelo Base de datos de las Multidimensional relacional Agregaciones Almacenamiento Modelo Base de datos de los datos Multidimensional relacional Facilidad de Creacin Velocidad de respuesta Sencillo Buena Muy Sencillo Regular o Baja

Escalabilidad Recomendados para

Problemas de escalabilidad Cubos con uso frecuente

Son ms escalables Datos que no son frecuentemente usados Si el cubo requiere una rpida respuesta

Ventajas Mejor performance en los tiempos de respuesta

Desventajas Duplica el almacenamiento de datos (ocupa ms espacio) Tiempo de Latencia

MOLAP

ROLAP

Ahorra espacio de almacenamiento. til cuando se trabaja con muy grandes conjuntos de datos. Buen tiempo de respuesta slo para informacin sumarizada

El tiempo de respuesta a consultas es mayor.

HOLAP

Volmenes de datos ms grandes en la base de datos relacional

Pgina 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. Definicin de Agregaciones

Otro factor para considerar en la implementacin del modelo OLAP, adems del modo de almacenamiento, es la definicin del porcentaje de agregaciones. Se denomina agregacin al proceso de precalcular el clculo de los datos a travs de los niveles, para disminuir los tiempos de respuestas en los procesos de bsquedas de informacin. El porcentaje de agregacin da idea de la proporcin o profundidad hasta la que se realizarn los preclculos. Las agregaciones se almacenan en la estructura multidimensional (segn el modo de almacenamiento que escogimos). Las agregaciones son resmenes 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 agregacin, a fin de lograr una buena solucin de compromiso entre el tiempo de respuesta a las consultas y los requisitos de almacenamiento. Si calculramos 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 mnimo, 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 relacin:

Pgina 64 de 94

En el grfico 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 sinnimo 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 mximo porcentaje de agregacin con la menor cantidad de espacio posible. Caractersticas de las agregaciones: Las agregaciones permiten mejorar los tiempos de respuesta Requieren de almacenamiento adicional Si no son controladas pueden provocar una explosin en los requisitos de almacenamiento

A mayor nmero de agregaciones ms procesamiento y ms requerimiento de espacio

tiempo

de

A menor nmero 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 estn actualizando los datos, las estructuras multidimensionales o ambas cosas.

Esta definicin debe considerar los siguientes factores

Pgina 65 de 94

Modo de almacenamiento que escogimos (MOLAP-ROLAP-HOLAP), Tamao 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 (da, mes, etctera) nos fijar la periodicidad de actualizacin de los datos. A diferencia de los sistemas OLTP en los que la actualizacin de los datos se realiza en lnea con las transacciones y la agregacin 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 trfico telefnico, si se reciben los datos de las llamadas una vez por semana, entonces deberamos procesar el cubo un da del fin de semana y de esa manera no afectaramos la tarea del usuario. Si en cambio, la informacin de las llamadas se recibe en forma diaria, el procesamiento se podra realizar una vez al da a ltima hora de la noche, o bien a primera hora de la maana.

4.5. Cubos Virtuales

Los cubos virtuales son vistas de cubos reales. Los cubos virtuales pueden ser utilizados: Cuando el usuario desee ver informacin conjunta de dos cubos diferentes. Cuando se quiere tener una visin parcial de un cubo. Es una forma de simplificar el manejo de la seguridad. En el sistema de trfico telefnico, se pueden querer relacionar las llamadas telefnicas 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 Trfico y de RRHH.

4.6. Particiones
Los cubos estn compuestos por particiones. Como su nombre lo sugiere, una particin es una divisin o fraccionamiento de la informacin que conforma a un cubo. Cada cubo contiene al menos una particin, pero puede estar compuesto por mltiples particiones,

Pgina 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 particin podemos definir la fuente de datos, el modo de almacenamiento y el porcentaje de agregacin de manera independiente de las dems particiones. Adems, una particin 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 parmetros de la manera mas indicada. Particin ms utilizada (Tiempo Actual): Modo de Almacenamiento MOLAP, % de Agregacin: alto Frecuencia de procesamiento: alta Particin medianamente consultada (Tiempos intermedios): Modo de Almacenamiento: HOLAP % de Agregacin: bajo Frecuencia de procesamiento: ocasional Particin poco accedida (Perodos viejos): Modo de Almacenamiento ROLAP, % de Agregacin: nulo Frecuencia de procesamiento: muy baja (normalmente slo al crear la particin)

Desde el punto de vista de la administracin, se puede manejar cada particin como si fuera un cubo independiente. Puede tener fuente de datos, modo de almacenamiento, porcentaje de agregacin y frecuencia de procesamiento propios.

Podemos crear una particin por cada ao que contenga el cubo, (por ejemplo 2004, 2005 y 2006), y almacenar las particiones de la siguiente manera: Ao 2006: En una estructura MOLAP, con un alto porcentaje de agregaciones, para obtener una respuesta rpida a las consultas. Ao 2005: En una estructura HOLAP, con un bajo porcentaje

Pgina 67 de 94

de agregaciones, lo que permitir buenos tiempos de respuesta para consultas de resumen, con un espacio de almacenamiento mnimo. Aos 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.

Disear mal una particin, sin considerar los filtros que habitualmente utiliza el usuario, aumenta la carga de administracin y no mejora la performance de las consultas. Si la lgica que define las particiones no est correctamente diseada, se pueden perder o duplicar datos.

4.7. La difcil bsqueda 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 Preagregacin. Tiempo de Procesamiento. Requerimientos de tiempos de respuesta Tipo de almacenamiento Tipificacin de las consultas (Base para decidir si se manejan particiones) Uso de Particiones Espacio Ocupado Tiempo de Procesamiento Respuesta Tiempo de Respuesta Consultas Cambios

Accin % Preagregaciones

Pgina 68 de 94

Mantenimiento

Almacenamiento

MOLAP

X X X S

Alto Bajo Medio

Alto Bajo Medio

x Agenda Directo x Agenda

Alto Bajo Medio

ROLAP HOLAP

Particiones

Caso de Estudio Veremos como implementamos el diseo del modelo de OLAP que desarrollamos en la unidad anterior.

Como vimos nuestro modelo era:

Dimensin Vendedor Dimensin Producto Subcategora Subcategora

*
** *** Fact_Ventas

*
** o *** **** *****

Familia Departament Categora Subcategora Producto

Sucursal Seccin Vendedor

Categora Categora

Departamento Departamento

ID_Fecha ID_Producto ID_Cliente ID_Vendedor Ventas_Importe Ventas_Costo Ventas_Unidades

Dimensin Sucursal

*
** Sucursal *** **** *****

Sucursal Tipo Pas Provincia Ciudad

Familia Familia

Dimensin Tiempo Dimensin Cliente

*
** *** **** *****

Ao Semestre Trimestre Mes Da

*
** *** **** Social

Pas Provincia Ciudad Razn

A este modelo lo implementaremos sobre un cubo denominado Ventas.

Cubo Ventas

Pgina 69 de 94

Teniendo en cuenta que nuestro cliente analiza su informacin con respecto a los periodos de tiempo, filtrando por ao, construiremos dos particiones dividiendo el cubo en forma anual. As, obtenemos una particin para el ao 2005 y otra para el ao 2006. Esta particin tiene como objeto dar soporte a consultas que se realizan con poca frecuencia, por lo que optamos por definir parmetros que permitan el ahorro de espacio ocupado, aceptando una performance ms baja.

2005

La particin para el ao 2005 tendr: Modo de almacenamiento: HOLAP Porcentaje de agregacin: 10% Frecuencia de procesamiento: La procesaremos en el momento de la creacin y despus solo cuando el cliente lo solicite. Esta particin tiene como objeto dar soporte a las consultas que se realizan habitualmente, uno de los requerimientos bsicos es el tiempo de respuesta de las consultas, por lo que optamos por definir parmetros que apunten a obtener la mejor performance, aceptando el costo en espacio ocupado y tiempo de procesamiento. Modo de almacenamiento: MOLAP Porcentaje de agregacin: 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 creacin 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.

2006

La particin del ao 2006 tendr:

Existen distintos modos de almacenamiento de los datos y agregaciones de un cubo, deberemos seleccionar uno de ellos segn las necesidades y posibilidades de nuestra organizacin. Es conveniente emplear particiones cuando existen grandes volmenes de datos con fin de lograr mejoras en los tiempos de procesamiento y la resolucin de las

Pgina 70 de 94

consultas. Utilizaremos cubos virtuales cuando el data mart necesite relacionar informacin de distintos cubos.

Los tiempos de respuesta de las consultas son un factor clave? Se tienen definidos valores mnimos o mximos 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 crticos? Se cuenta con el equipamiento adecuado para la situacin actual y la estimacin futura? Se consider este factor relacionndolo con el almacenamiento y la velocidad de procesamiento? Existen criterios predefinidos para la definicin del % de pre agregacin? Ser necesaria la creacin de cubos virtuales? Se tiene una clara idea de la cantidad y calidad de las consultas habituales? Existe algn patrn 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 exploracin.

Pgina 71 de 94

Contenido de la unidad
1.21 Introduccin 1.22 Seguridad 1.23 Consultas 1.24 Herramientas de visualizacin 5.4.1 La Tabla Pivotal 5.4.2 El Tablero de Control 1.25 Conclusiones 1.26 Check List

5.1

Introduccin

Como terminacin del curso veremos como los usuarios pueden acceder a la informacin 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 conclusin sobre lo aprendido a lo largo del curso y habremos completado un Check List que nos servir de gua en el proceso de creacin de una solucin de BI.

5.2

Seguridad

A la hora de disear el modelo multidimensional, es fundamental definir la seguridad adecuada sobre los diferentes componentes y niveles de la

Pgina 72 de 94

solucin, debido a lo sensible que puede ser para la organizacin la informacin 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 jerrquica, partiendo del cubo y llegando al nivel de celda dentro del cubo. De este modo, podemos definir los permisos a nivel de: Cubo Dimensin Celda (Medida) Cubo: esta restriccin de seguridad se realiza sobre todo el cubo, se puede permitir o denegar el acceso al cubo.

Permitido

Denegado

Dimensin: Podemos permitir que el usuario vea la dimensin, 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 condicin para acceder a los datos. Otra opcin para limitar los accesos puede ser el uso de cubos virtuales. Podramos 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 podramos definir una restriccin de acceso a nivel celda, sobre la medida Sueldo o crear un cubo virtual que no muestre esta medida.

Pgina 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) Rotacin Consolidacin Drill Down Drill Up: Es una tcnica por la que el usuario puede navegar entre las jerarquas de una dimensin 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 generalizacin, y con el drill down se pasa desde un nivel general al detalle.

Slice: Al seleccionar un miembro en particular de una dimensin se forma una especie de rebanada (slice) del cubo original.

Drill - Up

Drill - Down

Pgina 74 de 94

Dice: Al seleccionar varios miembros de varias dimensiones se forma subcubo, cubo ms pequeo o dado (dice). Tanto Slice como Dice son formas particulares de Filtrado.

Rotacin: Selecciona el orden de visualizacin de las dimensiones, rota o gira el cubo segn sus dimensiones.

Consolidacin (Roll-Up): Calcula las medidas en funcin de agrupamientos, realiza el re-clculo de la medida de acuerdo a los ajustes de escala.

Pgina 75 de 94

5.4

Herramientas de visualizacin

La navegacin es un trmino 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 Clculo: Las planillas de clculo pueden conectarse a la estructura dimensional y alimentar una tabla pivotal con la informacin que extraen de los cubos. Tablero de Control: Los tableros de control se conectan a la estructura dimensional y generan indicadores que permiten una rpida visin del estado actual de las variables bsicas y su relacin con los objetivos de la empresa. Desarrollos propios: Soluciones o aplicaciones desarrolladas a medida, especialmente para la organizacin. 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 organizacin. Software especializado: Soluciones o aplicaciones creadas por empresas dedicadas principalmente al desarrollo de visualizadores de informacin orientada al anlisis. Existe una gran variedad de herramientas con diversidad de prestaciones y costos, pudiendo ser tanto genricas como orientadas a algn mercado en particular. Reporteadores: Herramientas especializadas en la construccin de informes que pueden conectarse a la estructura dimensional y generar reportes con la informacin que extraen de los cubos. Existe una gran variedad de Herramientas de visualizacin de la informacin 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 eleccin de una

Pgina 76 de 94

herramienta son: Tipo de consultas o anlisis. 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 anlisis de la herramienta de visualizacin a utilizar entre las tareas de diseo, se corre el riesgo de tener la informacin correcta y a tiempo, pero a los usuarios desconformes.

5.4.1 La Tabla Pivotal

La tabla pivotal es una herramienta grfica que permite a los usuarios explorar fcilmente las dimensiones y medidas del cubo. De esta manera el usuario puede construir sus propios informes. La tabla pivotal se utiliza a travs de una planilla de clculo 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 ms dimensiones. Se puede filtrar la informacin seleccionando niveles en general o miembros en particular. Cuando se realizan selecciones mltiples dentro de una dimensin, 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 operacin 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 informacin. Tambin se puede seleccionar qu informacin se muestra. En esta rea se implementan las operaciones Drill-Up, DrillDown y Filtrado.

Pgina 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 informacin. Tambin se puede seleccionar qu informacin 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 slo medidas. Cuando arrastramos una medida tendremos el resultado de la interseccin 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 dimensin puede estar en Filtros, Filas o Columnas, pero slo en un rea a la vez. o En general, en el rea de Filtros no se muestra la seleccin 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.

Pgina 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 Seccin o Sucursal, pero no deben poder acceder al detalle por Vendedor.

Pgina 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, ejemplificndolas con nuestro cubo de Ventas de la empresa DLA. Para la visualizacin usaremos una tabla pivotal, por tratarse de una herramienta de fcil manejo y disponibilidad. Drill Down: Si el usuario est analizando los datos de las ventas de Argentina y desea ver cmo estn compuestos, podr hacer drill-down en la dimensin de la Sucursal, la que exhibira Buenos Aires, Capital Federal, Entre Ros, La Pampa y Santa Fe.

Si desea explotar Buenos Aires, con otro drill-down la tabla mostrar La Plata, Mar del Plata y Necochea.

Pgina 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 ms general, podr hacer drill up. Esta operacin agrupar la informacin por Pas 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 pas corresponde cada provincia o a qu provincia corresponde una ciudad para agregar o detallar. La estructura le dice el camino. Dice: con esta operacin armamos un SubCubo de tres dimensiones, tomando las dimensiones Producto, Sucursal y Tiempo, dejamos fuera de nuestra seleccin a las dimensiones Cliente y Vendedor.

Slice: Seleccionando la dimensin tiempo definimos una tajada del cubo.

Pgina 81 de 94

Filtrado: Un ejemplo de filtrado podra ser seleccionar para la dimensin Producto el valor Temperley Cristal Para x 1 Lt.

Rotacin: en este ejemplo tomamos las dimensiones productos y sucursal y las rotamos.

Reportes: A continuacin se vern algunos informes simples orientados al anlisis de la informacin. a- Se desea ver la evolucin de la ganancia en las ventas de los Hipermercados, para los totales de los aos 2005 y 2006, detalladas por Pas. Filtro: Tipo de Sucursal Hipermercado. Filas: Dimensin Sucursal Columnas: Dimensin Tiempo Datos: Medida Ventas Ganancia Obtenemos el siguiente resultado:

Pgina 82 de 94

b- Ahora se desea comparar el Importe de las Ventas del Mes de Septiembre de 2006, por Pas y Familia de Productos, explotando cada familia por Departamento y Categora. Filtro: Septiembre 2006 Filas: Dimensin Producto, y sus niveles Familia, Departamento y Categora 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 pas podemos construir un grafico que nos permite visualizar claramente esta distribucin: Filtro: Filas: Dimensin Sucursal Columnas: Datos: Medida Ventas Ganancia
Ventas Ganancia

Pgina 83 de 94

d- Ahora queremos comparar las unidades vendidas de cada producto durante los aos 2005 y 2006 en un grfico de barras. Filtro: Filas: Dimensin Producto Columnas: Dimensin Tiempo Datos: Medida Ventas Unidades

5.4.2 El Tablero de Control

El Tablero de Control es una herramienta grfica que le permite a los directivos concentrarse en indicadores fundamentales que tienen relacin directa con los objetivos de negocio de la empresa. El Tablero de Control no es un repositorio de datos, bsicamente es una herramienta que muestra indicadores relacionando los resultados esperados con los reales, es una manera de analizar la evolucin del negocio.

Pgina 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 informacin 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 utilizacin y generar una transformacin 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 anlisis 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 organizacin est cumpliendo con los objetivos o no, pero en ningn momento genera una solucin automtica. Para qu sirve, entonces, el Tablero de Control? Bsicamente, el Tablero de Control permite una rpida lectura del estado actual de las variables bsicas y su relacin con los objetivos de la empresa, alerta sobre la existencia de problemas actuales y facilita la visin de la evolucin esperada, con lo cual ayuda a detectar los desvos en los objetivos y tomar decisiones oportunas para corregirlos a tiempo.

El Tablero de Control es una muy buena herramienta, pero slo el cambio de la cultura empresarial puede hacer exitoso el camino.

En este ejemplo se muestran dos modelos de Semforo, siendo stos indicadores grficos caractersticos de los Tableros de Control. Para definir los semforos se manejan, bsicamente, las siguientes variables: Modelo del Semforo: Existen varios estilos con diferentes cantidades de niveles. El nmero de niveles que posea un semforo est directamente relacionado con la sensibilidad o capacidad de detalle que tiene el mismo. Valor Real: monitorear. Es la variable que se desea

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 desvos. Umbrales: Valores porcentuales que definen el

Pgina 85 de 94

paso de un estado del semforo al otro (Del verde al amarillo, por ejemplo). Segn sea la cantidad de niveles del modelo de semforo, ser la cantidad de umbrales a definir. Semforo tradicional de 3 colores: Es un semforo con la forma, los colores y la lgica tradicional. El color Verde indica la situacin ideal, mientras que el Rojo seala el peor extremo. Semforo de cinco niveles: Es un semforo 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 situacin ideal, mientras que la barra con slo el cuadro de la izquierda y el ndice sobre ste ltimo, seala el peor extremo.

Pgina 86 de 94

Caso de estudio

Tablero de Control A continuacin se vern dos ejemplos de Tablero de Control aplicados a nuestro Caso de Estudio. a- Se desea ver la evolucin 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 semforos. 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 evolucin que se est dando en el trimestre. En forma complementaria se tienen los valores numricos como elemento de soporte.

b- Se desea ver la evolucin 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 simultnea, varios aspectos del negocio. Se pueden combinar distintas variables a analizar y semforos de distinta sensibilidad. En este caso se puede ver la evolucin de las ventas comparando cmo varan las unidades y los importes, a lo largo del tiempo, con un solo golpe de vista.

Pgina 87 de 94

Debemos considerar las restricciones de seguridad para proteger la informacin 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 (rotacin, drill-down, slice, etctera). La tabla pivotal es una planilla de clculo que permite navegar los cubos.

Pgina 88 de 94

Existe una poltica de seguridad institucional? Se pueden definir grupos de usuarios con roles similares para facilitar la administracin 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 diseo de los objetos de la estructura multidimensional? Existen herramientas corporativas para la visualizacin 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
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 evolucin y el crecimiento del negocio y deben estar diseados de forma tal que puedan seguir esa evolucin 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 slo para las grandes empresas. Los sistemas de BI no son mquinas 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 vlidos para cualquier proceso en el que deban tomarse decisiones, no son propiedad de las reas comerciales o financieras. Los sistemas de BI no son mquinas de fabricar resmenes, brindan la informacin con el grado de detalle necesario para cada anlisis. 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 ms independencia al poder realizar las consultas en forma intuitiva y flexible. Construir un sistema de BI tiene como valor agregado el tener que revisar dnde y cmo se estn almacenando los datos de los sistemas transaccionales (OLTP). Es una muy buena oportunidad de incluir en

Las principales conclusiones obtenidas a lo largo del curso son:

Pgina 89 de 94

los procesos manejos de datos que se estn haciendo manualmente y sin soporte alguno. El desarrollo de un sistema de BI no se comienza por la eleccin de la herramienta de visualizacin. Como en todo desarrollo hay que relevar las necesidades de la empresa, consultar a los usuarios, fijar el alcance y las restricciones y, finalmente, disear, desarrollar y probar cada etapa. El desarrollo de un sistema de BI no termina con la creacin de un cubo multidimensional. Se deben definir e implementar los trabajos de procesamiento de los cubos (periodicidad, horario, manejo de errores, etctera). Existe una gran variedad de herramientas de visualizacin de datos. Debe brindarse a cada usuario la que ms le convenga, sin descuidar el presupuesto. La herramienta de visualizacin no debe ser una barrera entre el usuario y el sistema de BI.

Pgina 90 de 94

5.6

Check List
Est preparada la organizacin para trabajar con BI? Se cuenta con el compromiso de la alta gerencia para encarar un proyecto de creacin de un sistema de BI? Tiene presente que deber capacitar a los usuarios en la disciplina asociada a BI? Estn claramente definidos los objetivos de negocio que se asocian al sistema de BI? Ha relevado los Hechos que son de inters? Ha relevado las aperturas por las cuales se analizar la informacin? Ha relevado las medidas o indicadores que se usarn para evaluar los Hechos? Cul es la granularidad con que es necesaria ver la informacin 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 seleccin, transformacin 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 anlisis? Concuerda esta definicin con las tablas auxiliares que creamos y poblamos con datos de los sistemas OLTP? Sabemos si los usuarios utilizarn las dimensiones para navegar o para filtrar? Cubren las dimensiones diseadas las necesidades de los usuarios intuitivamente y con facilidad de manejo? Se tienen todas las medidas naturales con las aperturas requeridas?

Pgina 91 de 94

Est definida la forma de agregacin, al salir de la granularidad mnima, para todas las medidas naturales? Estn definidas las frmulas o criterios de todas las medidas calculadas? Estn correctamente definiciones? documentadas todas las

Los tiempos de respuesta de las consultas son un factor clave? Se tienen definidos valores mnimos o mximos 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 crticos? Se cuenta con el equipamiento adecuado para la situacin actual y la estimacin futura? Se consider este factor relacionndolo con el almacenamiento y la velocidad de procesamiento? Existen criterios predefinidos para la definicin del % de pre agregacin? Ser necesaria la creacin de cubos virtuales? Se tiene una clara idea de la cantidad y calidad de las consultas habituales? Existe algn patrn de filtrado que se repita, como el mes o la ciudad? Existe una poltica de seguridad institucional? Se pueden definir grupos de usuarios con roles similares para facilitar la administracin 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 diseo de los objetos de la estructura multidimensional? Existen herramientas corporativas para la visualizacin de los cubos? Existe capacidad (habilidades y tiempo disponible) de desarrollar herramientas propias?

Pgina 92 de 94

Las herramientas del Mercado, cubren las necesidades de la empresa? Son accesibles?

Pgina 93 de 94

Documentacin 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 informacin gerencial : administracin de la empresa digital - Pearson Educacin 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 Ingeniera Universidad de la Repblica de Uruguay http://www.fing.edu.uy/inco/grupos/csi/esp/Cursos/cursos_act/2003/DA P_SistDW Facultad Tecnologa Informtica - Universidad Abierta Interamericana Ctedra: Base de Datos Aplicada I Articulo Bajo el paraguas Business Intelligence, Jorge Fernndez Gonzlez, Abril 2006.

Pgina 94 de 94