diseÑo e implementaciÓn de una soluciÓn business

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

DISEÑO E IMPLEMENTACIÓN DE UNA SOLUCIÓN BUSINESS INTELLIGENCE

PARA UNA AGENCIA DE ADUANAS

OSCAR CUETO OSSANDÓN

INFORME FINAL DEL PROYECTO PARA OPTAR AL TÍTULO PROFESIONAL DE INGENIERO CIVIL EN INFORMÁTICA

DICIEMBRE DE 2009

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

DISEÑO E IMPLEMENTACIÓN DE UNA SOLUCIÓN BUSINESS INTELLIGENCE

PARA UNA AGENCIA DE ADUANAS

OSCAR CUETO OSSANDÓN

Profesor Guía: Broderick Crawford Labrín.

Profesor Correferente: Guillermo Cabrera Guerrero.

Carrera: Ingeniería Civil en Informática.

DICIEMBRE DE 2009

A Dios, a mis padres y hermano, a mi amada y mi hija, a mi familia y amigos por todo su apoyo incondicional…

i

Índice de contenidos

CAPÍTULO 1 INTRODUCCIÓN..................................................................................................................................1

1.1 INTRODUCCIÓN....................................................................................................................................................1

1.2 OBJETIVO GENERAL.............................................................................................................................................3

1.2.1 Objetivos específicos ..................................................................................................................................3

CAPÍTULO 2 ESTADO DEL ARTE ............................................................................................................................4

2.1 DATA WAREHOUSE..............................................................................................................................................4

2.1.1 Definición...................................................................................................................................................4

2.1.2 Modelado dimensional ...............................................................................................................................6

2.2 COMPONENTES DE UN DATA WAREHOUSE............................................................................................................9

2.2.1 Operational source systems .......................................................................................................................9

2.2.2 Data staging area.....................................................................................................................................10

2.2.3 Data presentation area.............................................................................................................................10

2.3 METODOLOGÍA DE MOSS...................................................................................................................................12

2.3.1 Etapa 1: Justificación...............................................................................................................................13

2.3.2 Etapa 2: Planificación .............................................................................................................................13

2.3.3 Etapa 3: Análisis del negocio...................................................................................................................14

2.3.4 Etapa 4: Diseño........................................................................................................................................14

2.3.5 Etapa 5: Construcción .............................................................................................................................15

2.3.6 Etapa 6: Despliegue.................................................................................................................................15

2.4 METODOLOGÍA DE K IMBALL .............................................................................................................................17

2.4.1 Seleccionar el proceso de negocio ...........................................................................................................17

2.4.2 Declarar la granularidad.........................................................................................................................17

2.4.3 Escoger las dimensiones ..........................................................................................................................18

2.4.4 Escoger los hechos...................................................................................................................................18

2.4.5 Modelo multidimensional.........................................................................................................................18

2.5 REPORTING........................................................................................................................................................22

CAPÍTULO 3 METODOLOGÍA.................................................................................................................................24

CAPÍTULO 4 ANÁLISIS DEL NEGOCIO.................................................................................................................26

4.1 DEFINICIÓN DE LOS REQUISITOS.........................................................................................................................26

4.1.1 Proceso de ventas.....................................................................................................................................26

4.1.2 Proceso de cuentas corrientes..................................................................................................................26

4.3 PROTOTIPO DE LA APLICACIÓN..........................................................................................................................27

4.3.1 Visión integrada .......................................................................................................................................27

ii

CAPÍTULO 5 DISEÑO................................................................................................................................................28

5.1 DISEÑO DEL REPOSITORIO DE METADATA..........................................................................................................28

5.1.1 Selección de los procesos de negocio.......................................................................................................28

5.1.2 Declaración de granularidad...................................................................................................................28

5.1.3 Identificación de dimensiones ..................................................................................................................29

5.1.4 Identificar los hechos ...............................................................................................................................31

5.1.5 Diseño del modelo dimensional ...............................................................................................................31

5.2 DISEÑO DE REPORTES........................................................................................................................................33

5.2.1 Reportes comerciales ...............................................................................................................................33

5.2.3 Reportes contables ...................................................................................................................................34

CAPÍTULO 6 CONSTRUCCIÓN ...............................................................................................................................36

6.1 DESARROLLO DEL REPOSITORIO DE LA METADATA............................................................................................36

6.2 DESARROLLO DEL PROCESO DE ETL..................................................................................................................37

6.3 DESARROLLO DE LA APLICACIÓN.......................................................................................................................42

6.3.1 Creación del cubo OLAP .........................................................................................................................42

6.3.2 Construcción de reportes .........................................................................................................................49

CONCLUSIONES........................................................................................................................................................53

REFERENCIAS ...........................................................................................................................................................55

ANEXO A – TABLAS DEL DATA MART ...............................................................................................................57

ANEXO B – CONSULTA REPORTE TOP 5 CLIENTES .........................................................................................63

ANEXO C – ESQUEMA XML REPORTE TOP 5 CLIENTES .................................................................................64

APÉNDICE – EXTRACTO LICENCIA ORACLE.....................................................................................................68

iii

Glosario de Términos Business Intelligence Conjunto de estrategias enfocadas a la

administración y creación de conocimiento, mediante el análisis de datos.

Cubos OLAP Bases de datos multidimensionales que permiten manejar de mejor forma la información para su posterior análisis.

Dashboard Panel en el cual se insertan los principales componentes de una solución Business Intelligence para su posterior análisis.

Data Mart Subconjunto de un Data Warehouse, con datos que describen un proceso de negocio.

Data Warehouse Almacén de datos orientado a la consulta de información, como apoyo a la toma de decisiones.

Drill Down Técnica empleada en la explotación de cubos OLAP, que permite ir desde los datos agregados hasta su detalle.

Holding Compañía que controla las actividades de otras, formando un conglomerado.

Join Unión física entre dos tablas de una base de datos, mediante la comparación de registros.

iv

Lista de Abreviaturas BD: Base de Datos

BI: Business Intelligence. Inteligencia de Negocios.

CIF: Cost, Insurance and Freight. Costo, seguro y flete.

E-R: Entidad Relación.

ERP: Enterprise Resource Planning. Planificación de recursos empresariales.

ETL: Extract, Transform and Load. Extracción, Transformación y Carga.

FOB: Free On Board. Franco a bordo.

OBI: Oracle Business Intelligence.

OLAP: On-Line Analytical Processing. Procesamiento analítico en línea.

PIB: Producto Interno Bruto

TI: Tecnologías de la Información.

UML: Unified Modelling Language. Lenguaje unificado de modelado

XML: Extensible Markup Language. Lenguaje de marcas extensible.

v

Índice de Ilustraciones

FIG. 1.1: GRÁFICO DE EVOLUCIÓN ANUAL DEL APORTE DEL COMERCIO EXTERIOR AL PIB................................................................... 1

FIG. 2.1: CUBO OLAP ......................................................................................................................................................... 5

FIG. 2.2: SLICE ................................................................................................................................................................... 5

FIG. 2.3: DICE.................................................................................................................................................................... 6

FIG. 2.4: COMPONENTES DE UN DATA WAREHOUSE [10] .......................................................................................................... 9

FIG. 2.5: ETAPAS PROYECTOS DE INGENIERÍA ......................................................................................................................... 12

FIG. 2.6: PASOS ETAPAS PROYECTOS DE INGENIERÍA................................................................................................................ 13

FIG. 2.7: FRENTES DE DESARROLLO ...................................................................................................................................... 16

FIG. 2.5: MODELO ESTRELLA .............................................................................................................................................. 19

FIG. 2.6: MODELO COPO DE NIEVE ...................................................................................................................................... 20

FIG. 2.7: MODELO CONSTELACIÓN ...................................................................................................................................... 21

FIG. 2.8: REPORTE QUE MUESTRA TENDENCIAS ...................................................................................................................... 23

FIG. 2.9: REPORTE CON PINBOARD Y SEMÁFOROS................................................................................................................... 23

FIG. 3.1: PASOS ETAPAS PROYECTOS DE INGENIERÍA................................................................................................................ 25

FIG. 4.1: DIAGRAMA DE ACTIVIDADES PROCESO DE VENTA ....................................................................................................... 27

FIG. 5.1: MODELO DIMENSIONAL ........................................................................................................................................ 32

FIG. 5.2: EJEMPLO REPORTE DE VENTAS ............................................................................................................................... 33

FIG. 5.3: EJEMPLO REPORTE DE EVOLUCIÓN DE VENTAS........................................................................................................... 34

FIG. 5.4: EJEMPLO REPORTE CONTABLE ................................................................................................................................ 35

FIG. 6.1: HERRAMIENTA DE ADMINISTRACIÓN BD ORACLE SQL DEVELOPER ................................................................................ 37

FIG. 6.2: SQL DEVELOPER, IMPORT DATA............................................................................................................................. 38

FIG. 6.3: SELECCIÓN DEL ARCHIVO CSV................................................................................................................................. 38

FIG. 6.4: OBTENCIÓN DE LAS COLUMNAS DEL ARCHIVO EXCEL ................................................................................................... 39

FIG. 6.5: SELECCIÓN DE COLUMNAS DEL ARCHIVO EXCEL .......................................................................................................... 39

FIG. 6.6: MAPEO DE COLUMNAS DE ORIGEN HACIA LA TABLA DESTINO ........................................................................................ 40

FIG. 6.7: VERIFICACIÓN DE PARÁMETROS DEL IMPORTE DE DATOS.............................................................................................. 40

FIG. 6.8: CONFIRMACIÓN DE INSERCIONES............................................................................................................................. 41

FIG. 6.9: VISUALIZACIÓN DE DATOS INSERTADOS .................................................................................................................... 42

FIG. 6.10: IMPORTE DEL MODELO RELACIONAL EN LA CAPA FÍSICA .............................................................................................. 43

vi

FIG. 6.11: REVISIÓN DEL MODELO RELACIONAL IMPORTADO. .................................................................................................... 44

FIG. 6.12: MAPEO DE CAMPOS. .......................................................................................................................................... 45

FIG. 6.13: CONFECCIÓN DEL MODELO DE NEGOCIOS............................................................................................................... 46

FIG. 6.14: TRANSFORMACIONES SOBRE NOMBRES DE TABLAS Y CAMPOS. .................................................................................... 47

FIG. 6.15: CREACIÓN DE DIMENSIONES, JERARQUÍAS Y CLAVES LÓGICAS....................................................................................... 48

FIG. 6.16: CAPA FÍSICA...................................................................................................................................................... 49

FIG. 6.17: CONFECCIÓN DE CONSULTA PARA REPORTE ............................................................................................................. 50

FIG. 6.18: AGREGACIÓN DE TABLA PIVOT Y GRÁFICO EN EL REPORTE .......................................................................................... 51

FIG. 6.19: PRESENTACIÓN DE REPORTES EN DASHBOARD ......................................................................................................... 52

vii

Resumen Este trabajo describe una solución de Business Intelligence, la cual organiza la información

de una Agencia de Aduanas de la región, para facilitar el proceso de toma de decisiones. Para ello, se ha creado un Data Warehouse respecto de los procesos que se desean apoyar, para visualizar su información a través de reportes dinámicos. Esto permite un procesamiento más óptimo de la información, visualizando las tendencias de ésta, desde los datos agregados hasta su detalle.

Palabras-claves: Data Warehouse, Data Mart, cubos OLAP, Reporting, Modelos Dimensionales, Business Intelligence.

Abstract This work describes a Business Intelligence solution, which is organizing the information

from a Customs Agency near the region, to support the making decision process. In order to this, a Data Warehouse has been created, about the process needed to support, for visualizing its information through dynamics reports. This allows an optimal information processing, viewing tendencies, from aggregate data to detail.

Key-words: Data Warehouse, Data Mart, OLAP cubes, Reporting, Dimensional Models, Business Intelligence.

1

Capítulo 1 Introducción

1.1 Introducción El comercio exterior de Chile es el principal motor del crecimiento del país. El año 2008,

por ejemplo, más de un 69% del PIB (Producto Interno Bruto) se debió a las actividades relacionadas con el comercio exterior, fundamentalmente exportaciones e importaciones [1]. Esto se debe principalmente a la globalización, a los grandes avances tecnológicos que han permitido un aumento en los flujos comerciales mundiales y a los tratados comerciales que ha firmado nuestro país, permitiendo la inserción de Chile en el comercio internacional. Por este motivo, el papel de la aduana es facilitar el comercio.

Fig. 1.1: Gráfico de Evolución Anual del aporte del comercio exterior al PIB

Hoy en día, el Servicio Nacional de Aduanas ha instado a las Agencias de Aduanas a incorporar Tecnologías de Información (TI), como una medida para facilitar el comercio internacional. Esta medida ha desencadenado un exceso de información en las empresas aduaneras. Esto se debe a la masificación tanto de ERPs [2], como también de softwares a la medida, que se han encargado de registrar las operaciones que las empresas realizan día a día. Por eso, hoy en día la automatización de los procesos de negocio de una empresa ya es una etapa casi superada.

Capítulo 1: Introducción

2

Sin embargo, ahora la transformación y el análisis de toda esta información que las empresas generan se convierte en un verdadero problema y, por lo tanto, la toma de decisiones se vuelve lenta. He aquí el problema, dado que en la actualidad, el entorno cambia bruscamente, lo cual hace que una toma de decisiones lenta pueda desembocar en decisiones obsoletas, y por ende, decisiones erradas. Así, las empresas que poseen un enorme flujo de información, y que son capaces de organizar dicha información para poder realizar gestión sobre ella, claramente marcan una diferencia sobre aquellas que no han sido capaces de obtener información y conocimiento a partir de este enorme conjunto de datos que sus sistemas transaccionales han venido entregando.

Para resolver esta problemática real es que ha surgido el concepto de Business Intelligence (BI) [3], el cual es un concepto que trata de englobar todos los sistemas de información de una organización para obtener no sólo información o conocimiento de ellos, si no una verdadera inteligencia que le confiera a la empresa una ventaja competitiva por sobre sus competidores. La información es el activo más importante en los negocios actuales. Esto debido a que el éxito de una empresa depende de factores como el hecho de qué tan bien conozca a sus clientes, el qué tan bien entienda sus procesos internos y el qué tan efectiva sea ésta para realizar todas sus operaciones. Para conseguir estos propósitos, la información adecuada es el único medio por el cual una organización puede solucionar tales inquietudes. Las empresas de la actualidad (sea cual sea su rubro) son juzgadas no únicamente por la calidad de sus productos o servicios, sino también por el grado en el que comparten información con sus clientes, empleados y socios. Entre más disponible esté la información de una empresa, más valiosa se vuelve ésta. Por ejemplo, cuando un departamento de marketing tiene información precisa de la base instalada de productos y servicios, la empresa está mejor capacitada para desarrollar promociones mejor enfocadas. Cuando los clientes pueden verificar con facilidad que un producto está disponible en el inventario, es mucho más probable que éstos realicen la compra. Cuando los gerentes generales tienen acceso instantáneo a datos de tendencias, éstos son capaces de dar un giro de apenas 100 dólares hacia una dirección, desencadenando una ganancia de miles de dólares a la empresa. Y así, hablando sobre estos diversos ejemplos, existen diversas soluciones BI enfocadas a resolver las inquietudes anteriormente planteadas. Para manejos de clientes existen soluciones conocidas como CRM (Costumer Relationship Management) [4], para disponibilizar la información y organizar grandes volúmenes de datos en información agregada que a la vez es capaz de llegar hasta el detalle, existen soluciones conocidas como cubos OLAP [5], para mostrar tendencias en la información, existen soluciones de Data Mining [6].

Este proyecto se centra en una solución de Data Warehouse para una agencia de aduanas, calificada como una mediana empresa. Esta empresa ofrece un buen servicio a sus clientes, teniendo mucha información operacional, lo cual permite desarrollar una solución que se encargue de organizar esta información y transformarla en conocimiento. Como todo proceso de BI, este proyecto está orientado a solucionar los problemas de la alta gerencia de la empresa, los cuales surgen a partir del alto volumen de información existente. Al tener mucha información, las herramientas tradicionales dificultan el proceso de reportes, impidiendo que la información muestre lo que la gerencia desea ver, en un determinado instante. Teniendo esto en cuenta, la solución debe organizar y estructurar la información, de manera de que lo que se desee consultar esté disponible en un nivel macro, visualizando las tendencias de las operaciones de la agencia de

Capítulo 1: Introducción

3

aduanas, pudiendo además llegar al detalle de esta información, cuando se desee analizar algún punto dentro de las tendencias mostradas.

Concretando lo anterior, la solución contempla la implementación de un cubo OLAP para el proceso comercial de la agencia de aduanas, así como un set de reportes que permita visualizar y consultar la información almacenada en el cubo.

1.2 Objetivo general Diseñar e implementar una solución de Business Intelligence para una agencia de aduanas

de la región.

1.2.1 Objetivos específicos

• Comprender los requisitos y necesidad de información de la agencia de aduanas.

• Comprender los procesos de negocio involucrados en la solución.

• Desarrollar un Data Mart que permita almacenar la información y desarrollar un cubo OLAP a partir de éste.

• Diseñar reportes que permitan visualizar la información.

4

Capítulo 2 Estado del arte

2.1 Data warehouse

2.1.1 Definición

Una de las primeras personas que empieza a hablar de Data Warehouse, introduciendo el tema y muchos de los conceptos actuales, es Bill Inmon, el cual define un Data Warehouse como “a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions. The data warehouse contains granular corporate data” [7].

De esta definición, se pueden desprender algunas afirmaciones que dan forma a los aspectos esenciales del Data Warehouse. Primero, Inmon dice que un Data Warehouse es Orientado a Temas, debido a que dentro de un Data Warehouse, todos los datos existentes tienen relación entre sí, organizándose para que cada uno de los datos, relativos al mismo evento u objeto del mundo real, queden unidos entre sí. Segundo, un Data Warehouse es Integrado, debido a que la base de datos almacena los datos de cada uno de los sistemas operacionales de la organización, que están involucrados en el proceso o tema que se desea modelar, persiguiendo la consistencia de los datos. Tercero, un Data Warehouse es No Volátil, debido a que los datos ingresados no se modifican ni se eliminan, una vez que son almacenados, convirtiéndose en información de “sólo lectura”, y manteniéndose para futuras consultas. Cuarto, un Data Warehouse es Variante en el Tiempo, pero no porque su información se vaya modificando en el tiempo (de ser así, no se cumpliría la afirmación anterior), sino que, precisamente gracias a que sus datos no se modifican, cada cambio producido en los datos a lo largo del tiempo queda registrado para que los informes que se puedan generar reflejen esas variaciones, guardando así, la historia de la información. Finalmente, en su definición Inmon afirma que un Data Warehouse es una colección de datos en apoyo de las decisiones de gestión, dejando en claro que el enfoque de un Data Warehouse no son las decisiones operacionales ni de mediano plazo. Pese a que un Data Warehouse se carga con la información transaccional de la empresa, ésta es organizada de manera que permita mostrar información macro, identificando tendencias, y siendo capaz de llegar desde lo macro, hasta los datos corporativos de más bajo nivel.

Todo esto se logra organizando los datos en tablas conocidas como dimensiones, lo cual permite realizar el ejercicio de imaginarse un Data Warehouse de 3 tablas o dimensiones, como un cubo, donde cada cara del cubo es una dimensión. De ahí que un Data Warehouse es conocido como cubo OLAP (On Line Analytical Process), pese a que más adelante se verá que un Data Warehouse está compuesto por uno o más Data Marts, y que en el fondo, un cubo OLAP es una aplicación surgida a partir de estos Data Mart.

Capítulo 2: Estado del arte

5

Fig. 2.1: Cubo OLAP

Al imaginarse los datos organizados en un cubo, se puede entender que la obtención de los datos se lleva a cabo cruzando los sectores del cubo. En los procesos reales de cada empresa, una solución OLAP suele tener más de 3 dimensiones, sin embargo, para introducir el concepto de Slice and Dicing, es necesario continuar con este ejercicio de imaginarse el cubo tridimensional.

La traducción de Slice es rebanada o tajada, y en un Data Warehouse hace referencia a obtener una tajada del cubo. Esto se logra fijando una dimensión en un subconjunto de valores, para uno o más miembros de otras dimensiones fuera del subconjunto [8]. Por ejemplo, en la figura 2.2, se fija un periodo en particular (el mes de Junio), formando la rebanada con todas las otras dimensiones, que en este caso son las ventas de todos los productos para todos los clientes.

Fig. 2.2: Slice


6

La traducción de Dice es dado, y en un Data Warehouse hace referencia a obtener una tajada del cubo, pero fijando más de una dimensión. En terminos OLAP, una operación Dice [8] es equivalente a realizar un Slice con más de una dimensión. La figura 2.3 muestra un esquema de una operación Dice.

Fig. 2.3: Dice

De este modo, los cubos OLAP permiten invertir menos tiempo en descubrir patrones y hacer reportes de excepción, gracias a este análisis multidimensional intuitivo y a sus modelos simples, rápidos, y flexibles a modificaciones. Facilita sintetizar información a través de vistas comparativas y personalizadas; y analizar información tanto histórica (pasado) como estimada (futura). Permite un análisis eficiente que sería muy lento en un sistema de bases de datos tradicional. Además, aísla al usuario de lenguajes y tecnologías complejas, mejora el desempeño de las consultas y la capacidad de cálculos de negocios, como también soporta una gran cantidad de herramientas clientes con un despliegue rápido, con bajo riesgo y costo.

Para poder crear un cubo OLAP, dado el despliegue multidimensional que engloba el concepto, se requiere como primera cosa el diseño de un modelo dimensional, por lo que es necesario interiorizarse en la técnica del modelado dimensional, y entender sus conceptos.

2.1.2 Modelado dimensional

Plenamente convencido de que un Data Warehouse debe ser diseñado para ser entendible y veloz, Ralph Kimball diseñó una metodología denominada “Dimensional Modelling”, la cual él mismo define como “una disciplina específica para modelar datos y que es una alternativa al modelado de Entidad-Relación”[9].

Un modelo dimensional es similar a un modelo Entidad-Relación, pero que a diferencia de éstos, persigue agrupar a todos los elementos de un mismo tipo, dentro de una tabla. Debido a esto, y contrariamente a los modelos E-R, un modelo dimensional es altamente desnormalizado,


7

permitiendo un alto rendimiento a la hora de acceder a él. Cada modelo dimensional está compuesto por una tabla con una llave combinada, llamada tabla de hechos, y un conjunto de tablas más pequeñas llamadas tablas de dimensiones.

2.1.2.1 Tabla de hechos

Una Tabla de Hechos, o bien, Fact Table por su nombre en inglés [9] es una colección de piezas de datos y datos de contexto. Cada hecho representa una parte del negocio, una transacción o un evento. Generalmente los hechos son colecciones de medidas numéricas que definen un evento o transacción en particular, por lo que es normal considerar los valores numéricos (especialmente si poseen decimales) como métricas de la tabla de hechos y no como atributos. Las métricas son atributos numéricos de un hecho que representan el comportamiento del negocio relativo a una dimensión. Por ende, una tabla de hechos es una tabla que posee métricas que permiten describir un evento o transacción (el hecho en sí), por ejemplo, las ventas de un producto, los niveles de inventario de una tienda retail, un contrato de arriendo de una inmobiliaria, o un despacho aduanero, por mencionar algunos.

2.1.2.2 Dimensiones

Los atributos, por el contrario, suelen ser campos de texto que normalmente describen características de un objeto tangible. Por ejemplo, uno de los atributos más obvios suele ser el nombre de un cliente. No se mide el nombre del cliente, es más, si aparece un nuevo nombre de un cliente, se crea un nuevo registro para el cliente en general.

Estos atributos que describen objetos están organizados dentro de tablas denominadas dimensiones [9]. Por lo tanto, todos los atributos de un cliente (por ejemplo: nombre, dirección, teléfono, contacto) estarán dentro de una dimensión Cliente; todos los atributos de una fecha (por ejemplo: año, nombre y número del mes, número del día, nombre del día de la semana, es festivo o no) estarán dentro de una dimensión Fecha, y así con cada elemento que permita describir los hechos.

Para identificar cada instancia de una dimensión, como cualquier tabla de una base de datos, es necesario asignarle una clave primaria. Para el modelado dimensional, Kimball sugiere utilizar “surrogated keys” o claves subrogadas [9], las cuales son números enteros asignados de manera secuencial en la medida que se va poblando la dimensión. Estas claves son las que se encargan de unir las dimensiones con la tabla de hechos a la cual describen.

En una base de datos relacional, se suelen utilizar las claves naturales del negocio para identificar cada tabla (Rut de personas, números de documentos, códigos de productos, etc.), sin embargo, y dado que un Data Warehouse almacena información histórica, existen distintas instancias de un mismo elemento a través del tiempo, por lo que estas claves dejan de ser únicas, siendo necesario incluir las claves subrogadas para identificar de manera única a cada instancia. Éste es el principal beneficio de este tipo de claves: la posibilidad de manejar el historial de cambios dentro de los elementos del Data Warehouse. Por ejemplo, en algunas organizaciones, los códigos operacionales que permanecen inactivos por un largo tiempo, o los códigos obsoletos,


8

vuelven a ser asignados, “pisando” la información histórica. Esto trae problemas en la consolidación de los datos, o bien, genera inconsistencias en la información.

También existen beneficios en cuanto a rendimiento. Generalmente los códigos naturales son cadenas alfanuméricas, mientras que una clave subrogada es un entero tan pequeño como sea posible, asociado a la cardinalidad de la dimensión. Pequeñas claves se traducen en tablas de hechos más pequeñas, por lo que generalmente es suficiente con enteros de 4 bytes. 2

En general, un modelo dimensional bien diseñado tendrá tablas dimensionales con muchos atributos. Estos atributos describen las filas de la dimensión, por lo que en lo posible, se deben incluir la mayor cantidad de textos descriptivos significativos. Los atributos de las tablas dimensionales, van a servir a posterior, como las fuentes principales para las restricciones y filtros en las queries, agrupadores, o bien, como las etiquetas de los reportes, por lo que son la clave para que el Data Warehouse cumpla con su cometido de ser entendible y usable. Por lo tanto, la fortaleza de un Data Warehouse es directamente proporcional a la calidad y profundidad de los datos.

2.1.2.3 Data mart

Existen varias alternativas de diseño tradicionales para un Data Warehouse, siendo la más conocida aquella postulada por Ralph Kimball [10], quien propone un Data Warehouse formado a través de un conjunto de Data Marts. En este enfoque se van construyendo los Data Marts de manera progresiva hasta abarcar toda la organización.

Por Data Mart entendemos un subconjunto lógico de un Data Warehouse, generalmente orientado a un proceso de negocio o un conjunto de procesos de negocios relacionados. El diseño más habitual y efectivo para éste se considera el llamado modelo multidimensional también conocido como modelo estrella, donde se definen las métricas del proceso de negocio y toda la metadata que permite describirla. Las métricas se guardan en una tabla central llamada tabla de hechos y la metadata se guarda en diversas tablas satélites llamadas tablas dimensionales, cada una asociada a la tabla de hechos.

Antes de describir la metodología de Kimball, es necesario conocer los componentes de un Data Warehouse que éste describe, para conocer el rol que éstos juegan en su metodología.


9

2.2 Componentes de un data warehouse Cada componente de un Data Warehouse cumple una función específica [10], por lo cual es

importante tener claro el rol de cada uno para evitar confundirlos.

Fig. 2.4: Componentes de un Data Warehouse [10]

2.2.1 Operational source systems

El primer componente son los sistemas operacionales [10] que se encargan de registrar la información de todas las transacciones del negocio. Estos sistemas fuentes poseen un pequeño registro histórico de la información, por lo cual, si se cuenta con un buen data warehouse, esta característica deja de ser responsabilidad de los sistemas fuentes, concentrándolos en un buen desempeño, procesamiento y disponibilidad, que es para lo que realmente están hechos.

El proceso de toma de decisiones se basa en la información obtenida a partir de los datos disponibles al interior de la organización. Sin importar que tan buenos sean estos sistemas de apoyo a la toma de decisiones, la calidad de las decisiones dependerá de manera directa de la calidad de los datos disponibles. Datos erróneos o imprecisos pueden llevar a una decisión errónea que tenga un impacto negativo directo sobre los ingresos de la empresa, llegando a costar millones.

A partir de la década de los 80, se viene desarrollando todo un cuerpo teórico y práctico relacionado con la gestión y explotación de los datos de la empresa, considerando que por motivos históricos, el desarrollo de estos sistemas transaccionales departamentales ha llevado a una arquitectura empresarial marcada por silos de información. Estos silos corresponden a unidades aisladas unas de otras cada una con sus propios datos e información.

Esto trae consigo varios problemas, entre los cuales vale mencionar:


10

Muchas veces estos silos replican información que de otra manera estaría contenida en un solo lugar. Por ejemplo, los datos respectivos a los clientes muchas veces residen de manera independiente en los departamentos de finanzas, contabilidad, u operaciones.

Muchas veces una efectiva toma de decisiones implica considerar datos provenientes de varias unidades de negocios, lo que se ve dificultado por la existencia de estos silos de información.

Muchas veces, considerando que los silos contienen información replicada, ocurre que un silo contiene información errónea, pero debido a que no existen mecanismos adecuados de gestión de los datos, es imposible saber qué información es la correcta, lo que lleva a gastar una enorme cantidad de tiempo consolidando y corrigiendo la información, proceso previo a la toma de decisiones.

Para dar solución a este problema, integrando los distintos departamento que forman parte de un proceso de negocio en particular, se requiere reunir estos datos y almacenarlos en conjunto, para facilitar su acceso.

2.2.2 Data staging area

El Data Staging Area [10] de un data warehouse es tanto un área de almacenamiento, como también un conjunto de procesos conocido como ETL (Extract, Transform and Load). En él se encuentra contenido todo lo que está entre los sistemas operacionales y el área de presentación de datos, donde a grandes rasgos, se toman los datos “crudos” provenientes de los sistemas operacionales, para transformarlos en datos consistentes que puedan ser utilizados para las consultas de los usuarios finales de un data warehouse.

El primer proceso es la extracción, que consiste en la lectura de los datos desde una fuente de datos, copiando aquellos que se requieren para el data warehouse en sus siguientes procesos.

Luego que la data se ha obtenido, esta pasa por diversos procesos de transformación, como la limpieza de los datos (corregir errores de escritura, resolver conflictos de dominio o estandarizar los datos), combinación de datos de múltiples fuentes y asignar las claves del data warehouse.

Finalmente, la data ya procesada se carga en el data warehouse, para ser publicada y accedida desde el área de presentación.

2.2.3 Data presentation area

El área de presentación de los datos [10] es donde éstos son organizados, almacenados y puestos a disposición para consultas directas por parte de los usuarios, o para herramientas de reportes u otras aplicaciones analíticas. Por ende, para los usuarios finales, éste vendría a ser el Data Warehouse en sí, puesto que es todo lo que ven y es donde se encuentra todo lo que pueden acceder y consultar.

Debido a que los usuarios finales acceden a esta parte de los datos, es muy importante hacer que tanto los datos, como los modelos sean entendibles. Por eso, una base de datos en tercera


11

forma normal es poco deseable aquí. Éstas persiguen asegurar la consistencia de los datos y aumentar el rendimiento al momento de interactuar con la base de datos (inserciones, modificaciones y eliminaciones), eliminando todo tipo de redundancias, por lo cual, son mucho más útiles para los sistemas operacionales. Para un Data Warehouse, una base de datos en tercera forma normal es más compleja al momento de consultarla, entenderla o navegarla. Esto va totalmente en contra del propósito de un Data Warehouse, el cual debe ser intuitivo y con un alto rendimiento al momento de hacer consultas. Es por este motivo que un Data Warehouse utiliza modelos dimensionales en esta área, puesto que éstos son más entendibles, y definitivamente, mucho más navegables.

Respecto de los Data Marts existentes en el área de presentación, otro aspecto importante es que éstos deben contener datos atómicos. Este aspecto se debe a que en la medida en que mayor sea la granularidad de los datos, mejor responde el Data Mart frente a preguntas imprevistas, provenientes de análisis ad hoc. Respecto a la granularidad, se hablará de este concepto cuando se describa la metodología de Kimball para diseño de Data Marts. Volviendo al tema, la información agregada debe estar sustentada en datos atómicos, de manera de facilitar la técnica de drill down utilizada por los usuarios en herramientas de análisis y reportes, más aún teniendo en cuenta que los requerimientos de los usuarios son imprevisibles y constantemente cambiante.

La técnica de drill down es utilizada en el Reporting, sin embargo, como bien se ha mencionado, para llevarla a cabo es preciso contar con datos atómicos que puedan agregarse a niveles más altos. El ejemplo más claro de esto es la información referente al periodo o fecha. La información más atómica de una dimensión de fecha es el día mismo, conocido como fecha contable (por ejemplo: 31 de julio del 2009, 31-07-09, 31-jul-2009). Esto permite agregar la información hacia un nivel superior, que para este caso pueden ser los meses (por ejemplo: Julio, Octubre, Enero). Así, en un reporte, se podrá ver la evolución de las ventas de la empresa a nivel mensual, de modo que si el usuario final de ese reporte hace click sobre un mes en particular, recién allí se despliega el detalle de todos los días que componen ese mes. Esto es muy útil para la gerencia, y es lo que les permite tomar decisiones, puesto que ven la información agregada, visualizando el comportamiento de sus procesos de negocio, sin tener que ver columnas con más de 100 datos, y accediendo al detalle de éstos, sólo en los casos en que se estime conveniente. El drill down permite mostrar la información que a un gerente le interesa ver.


12

2.3 Metodología de Moss Larissa T. Moss [11] dice en su metodología que casi cualquier proyecto de Ingeniería, en

particular la de Software, pasa por seis etapas entre la creación y la aplicación, donde éstas son iterativas, tal como lo muestra la flecha de la figura 2.5. Una vez desarrollado un producto, éste vive en continuo mejoramiento, según el feedback de los usuarios finales de este producto.

Fig. 2.5: Etapas Proyectos de Ingeniería

Justificación: Evaluación de la necesidad que da origen al proyecto.

Planificación: Desarrollo de planes estratégicos y tácticos mediante los cuales se llevará a cabo el desarrollo del proyecto.

Análisis del Negocio: Se analiza detalladamente el problema de la empresa o las oportunidades de negocio, para obtener un conocimiento sólido del negocio, para una posible solución.

Diseño: Se concibe un producto que solucione los problemas de la empresa y entregue valor agregado a ésta.

Construcción: En esta etapa se construye el producto, lo que debería proporcionar un retorno de la inversión dentro de un marco de tiempo predefinido.


13

Despliegue: En esta etapa se comienza a utilizar la solución diseñada y se evalúa si cumple con los objetivos esperados.

Dentro de las etapas mencionadas, el autor incluye una serie de pasos que se muestran a continuación en la figura 2.6.

Fig. 2.6: Pasos Etapas Proyectos de Ingeniería

2.3.1 Etapa 1: Justificación

Evaluación del Caso de Negocio: Lo primero es definir el problema y proponer una solución BI. Cada aplicación BI debe justificar el costo incurrido, dejando en claro los beneficios que conlleva el resolver el problema.

2.3.2 Etapa 2: Planificación

Evaluación de la Infraestructura de la Empresa: En este paso, se debe evaluar la infraestructura tecnológica que posee la empresa, ya que será ésta la que tendrá que soportar el


14

sistema final, para lo cual se debe tener en cuenta el hardware existente versus el necesario para la aplicación del proyecto, además del estado de las redes, mecanismos de seguridad y finalmente el software. Además, se debe tener en cuenta los aspectos no técnicos, como los estándares en el nombre de los datos, metodologías, o control de cambios.

Planificación del Proyecto: Dado que los proyectos BI suelen ser muy dinámicos, es importante planificar detalladamente, observando y reportando el progreso del proyecto, debido a que cualquier cambio de alcance, equipo, presupuesto, tecnología u otro, puede impactar severamente en el éxito del proyecto.

2.3.3 Etapa 3: Análisis del negocio

Definición de los Requisitos del Proyecto: Es una etapa crítica, puesto que acá se debe indicar el alcance del proyecto. Además, los requerimientos suelen cambiar rápidamente, por lo que una buena definición del alcance, podrá indicar cuál de estos cambios queda dentro del alcance del proyecto y cuáles deben ser renegociados para un nuevo proyecto.

Análisis de los Datos: Esta etapa suele ser utilizada por las empresas para corregir los problemas de inconsistencias de datos que poseen. Es importante analizar los datos, para poder dar solución a tiempo a problemas de inconsistencia de datos, puesto que en un proyecto BI, datos erróneos conllevan a decisiones erróneas.

Prototipo de la Aplicación: Los prototipos pueden ser un método eficaz para la validación de los requisitos del proyecto, así como de la búsqueda de partes faltantes o discrepancia entre dichos requisitos. Un prototipo permite a los usuarios finales dimensionar la funcionalidad de la herramienta utilizada, comprendiendo sus funcionalidades y limitantes.

Análisis del Repositorio de Meta Data: Los metadatos están diseñados para almacenar la información contextual de los datos de la empresa. Esta información existe en cada organización, mas no así la documentación al respecto de éstos. Cuando la información contextual está documentada, se conoce como metadato. A menudo en las organizaciones se inventan nuevas reglas de negocios creando sus propios datos redundantes sin darse cuenta que muchas veces los datos que necesitan ya existen, es por eso que este análisis es de suma importancia para ordenar los metadatos y asegurar consistencia. Lo metadatos toman especial importancia en los proyectos de BI debido a que los usuarios del negocio no tienen el conocimiento técnico necesario que les permita entender el funcionamiento de la aplicación. La meta data les permite entender y buscar de forma sencilla lo que necesitan.

2.3.4 Etapa 4: Diseño

Diseño de la Base de Datos: Para tener éxito en el proyecto de BI, la Base de Datos debe ser acorde a lo que la solución plantea, por lo que es necesario conocer las herramientas comprometidas en el proyecto, y diseñar la base de datos acorde al uso que se le va a dar a estos.

Diseño del Proceso de ETL: La fuente de datos para un proyecto BI puede ser más de una (por el problema de los silos de datos ya descrito), por lo cual se hace necesaria la construcción de ETL como proceso para fusionar los datos de las diferentes plataformas logrando un formato


15

estándar para la base de datos del proyecto. Además, los modelos relacionales suelen estar en 3era forma normal, mientras que los modelos dimensionales son desnormalizados. Por esto, es necesario realizar un mapeo de datos de origen y datos destino.

Diseño del Repositorio de Meta Data: Este paso tiene como objetivo diseñar el repositorio de metadatos, lo que incluye la base de datos que guardará la información y la aplicación que permitirá a los usuarios del negocio navegar por los metadatos. Este repositorio debe lograr la gestión de los metadatos de forma rápida y certera, a través de las diferentes técnicas y herramientas que están disponibles.

2.3.5 Etapa 5: Construcción

Desarrollo del Proceso de ETL: La complejidad de este paso siempre dependerá de los datos a utilizar. Si la calidad de los datos es buena, el ETL puede limitarse a un simple mapeo. Sin embargo, si existen datos replicados, distintos nombres para un mismo dato (Rut, CI), mismo dato con distintos valores (ocueto, Oscar Cueto, Oscar C), el proceso ETL puede complicarse, por lo que su desarrollo pasa a ser clave en el éxito del proyecto..

Desarrollo de la Aplicación: Luego de que el prototipo haya confirmado los requerimientos funcionales, se puede empezar a desarrollar la aplicación. Este proceso puede ser tan simple como finalizar el prototipo con las observaciones que hayan salido en cada iteración, como también puede llegar a involucrar más esfuerzos en el desarrollo, incluyendo nuevas herramientas de análisis. De todas maneras, esta es una actividad que puede desarrollarse en paralelo al desarrollo del repositorio de datos y del ETL.

Minería de Datos: muchas empresas han acumulado a través de los años, grandes cantidades de datos en sus sistemas, datos que constituyen una fuente potencial de información valiosa para la empresa. A través de modelos analíticos se pueden encontrar patrones en los datos, generando así información que proporcione una ventaja competitiva. Esto entrega a los gerentes de las organizaciones información necesaria para la toma de decisiones aumentando así los beneficios, reduciendo costos y ampliando la cuota de mercado.

Desarrollo del Repositorio de Meta Data: este paso es el esqueleto de un proyecto de Data Warehouse. Una vez implementado el repositorio, este debe ser mantenido en el tiempo, consolidando los datos en cada ciclo de carga de los ETL.

2.3.6 Etapa 6: Despliegue

Puesta en Marcha: Una vez que la aplicación está construida, ésta puede ser implementada en el entorno de producción. Esta implementación se puede hacer de dos formas, la primera es en etapas, dando de alta uno por uno los diferentes módulos, o bien en forma total.

Evaluación de la Entrega: Este paso tiene como objetivo planificar y ejecutar las revisiones necesarias para una correcta evaluación del resultado del proyecto.


16

Es posible reconocer a lo largo del proyecto tres frentes de desarrollo paralelos que pueden trabajar de manera simultánea, donde cada uno requiere un conjunto especial de conocimiento y habilidades:

Fig. 2.7: Frentes de Desarrollo

El primer grupo se encarga del desarrollo de las aplicaciones de análisis de información con las que interactuará el usuario del negocio. Las herramientas que se conectarán al repositorio para obtener la información, herramientas de query y Reporting.

El segundo grupo se encarga del desarrollo del repositorio de la meta data asociada al proyecto.

El tercer grupo se encarga del desarrollo de las bases de datos, el ETL y todo lo que guarda relación con el soporte sobre el que funcionan las aplicaciones de análisis de información.


17

2.4 Metodología de Kimball Esta metodología es la más utilizada para el diseño e implementación de Data Marts y se

compone de 4 pasos esenciales [10]:

Seleccionar el proceso de negocios que se desea modelar

Declarar la granularidad del proceso de negocios

Escoger las dimensiones que describen cada fila de la tabla de hechos

Identificar los hechos numéricos que poblaran cada fila de la tabla de hechos

2.4.1 Seleccionar el proceso de negocio

Seleccionar el proceso de negocio nos permite delimitar la información que estará contenida en el Data Mart. Todos los datos que se consideren importantes para el proceso de negocio deben ser incorporados en el Data Mart.

Como ya se mencionó en el capítulo 2.2 al hablar de los sistemas operacionales, al hablar de un proceso de negocio no se está haciendo referencia al departamento de una organización o una función en particular. Por ejemplo, se crea un Modelo Dimensional para registrar el proceso de Ventas, y no dos modelos para el área comercial y el área de marketing respectivamente. El enfocarse en procesos de negocio, en lugar de departamentos de negocio, permite crear un modelo dimensional transversal a la organización, permitiendo la integración de todos los departamentos y áreas que participan en el proceso que se desea modelar, asegurando así, la consistencia en la información. Múltiples flujos de información, a través de múltiples modelos dimensionales, conducen indudablemente a la duplicidad de la información, y por ende, a su inconsistencia. La mejor manera de asegurar la consistencia es publicar los datos una sola vez.

2.4.2 Declarar la granularidad

Cuando hablamos de granularidad, nos referimos al nivel máximo de detalle de los datos relacionados con el proceso de negocios. Por ejemplo, en un proceso de negocio relacionado a la venta de productos en una tienda, el nivel de detalle podría ser la venta diaria de cada tipo de producto o a un nivel más detallado la venta de cada tipo de productos por cada cliente cada día o incluso podríamos considerar la venta de cada tipo de producto en cada boleta o factura emitida.

La importancia de la granularidad radica en que define el nivel máximo de detalle que estará disponible para realizar el análisis, lo que permite dimensionar además la cantidad de datos que contendrá el Data Mart. Es decir, si la granularidad corresponde a las ventas diarias de cada tipo de producto, no podremos saber el detalle de lo que se vendió por tipo de cliente, y menos lo que se vendió en cada boleta. Existe un trade-off entre nivel de granularidad y cantidad de datos a guardar.

Este es un paso crítico, y que a la vez facilita el desarrollo de los pasos 3 y 4. Sin embargo, si estando en cualquiera de los pasos siguientes, se observa que la declaración de granularidad es


18

errónea, siempre se puede volver al paso 2 y re definir la granularidad del modelo, para continuar con los siguientes pasos.

2.4.3 Escoger las dimensiones

Cada proceso de negocio está determinado por datos numéricos que permiten hacer el análisis del proceso (cantidad de dinero involucrada, cantidad de elementos, etc.) y datos sobre estos otros datos numéricos, que permiten describir el contexto del proceso (metadata del proceso). El tercer paso se refiere a seleccionar las dimensiones que se van a aplicar a cada fila en la tabla de hechos. Las dimensiones surgen después de realizar la pregunta “¿Cómo la gente del negocio describe los datos que resultan del proceso de negocios?”. Se persigue acompañar la tabla de hechos con un conjunto robusto de dimensiones que puedan representar todas las posibles descripciones que toman los valores simples, en el contexto de cada métrica. Si se tiene clara la granularidad del modelo, entonces las dimensiones pueden ser identificadas muy fácilmente. Al escoger cada dimensión, se listarán todos los atributos discretos y de tipo texto que permitirán rellenar la dimensión con la información descriptiva que las métricas requieren. Ejemplos de dimensiones comunes son “Fecha”, “Producto”, “Cliente”, “Tipo de Transacción”.

2.4.4 Escoger los hechos

El cuarto paso se refiere a seleccionar los valores numéricos sobre los que se realizará el análisis del proceso de negocio. Estas métricas son fácilmente identificables, respondiendo a la pregunta “¿Qué estamos midiendo?”. Todos los candidatos a métrica en el diseño del modelo, deben estar acorde a la granularidad definida en el paso 2. Por lo tanto, los hechos que claramente se encuentren en un nivel granular distinto, deben ser incluidos en una nueva tabla de hechos.

2.4.5 Modelo multidimensional

Luego de cumplir estos pasos el modelo resultante se implementa como un modelo multidimensional, para el cual existen dos tipos: modelo estrella y modelo copo de nieve. En un modelo dimensional, los hechos numéricos del proceso de negocio se incluyen en las tablas de hechos, las cuales se relacionan con un conjunto de tablas que corresponden al contexto del proceso mismo, descritas en la sección 2.1.2.2 como dimensiones.

2.4.5.1 Modelo estrella

El modelo Estrella consiste en ubicar una tabla de hechos en el centro del modelo, relacionándose con el resto de las tablas dimensionales, de tal modo que todas ellas se relacionen sólo a través de esta tabla de hechos.

El tema principal en un modelo estrella es el diseño de las dimensiones, puesto que para que éstas se relacionen sólo con la tabla de hechos y así evitar la relación con otras dimensiones, es estrictamente necesario ubicar en una sola tabla, todo aquello que se pueda deducir del


19

elemento más granular de la tabla considerado por la dimensión, así como también las jerarquías que podrían surgir en torno a este elemento.

Fig. 2.5: Modelo Estrella

Por ejemplo, si se considera una dimensión de productos (bastante común en modelos para Retail), el elemento más granular será el producto mismo. Pero además, existen otros elementos que se pueden deducir en base al producto, como lo son la marca de éste, su presentación (botella de vidrio, caja, bolsa, etc.), la familia (lácteos), la subfamilia (leches descremadas), la categoría (leches), sabor, contenido neto, etc. De este modo, todos estos atributos se ubican en una misma tabla formando así un modelo desnormalizado.

Dentro de las ventajas de un esquema estrella, se encuentra su simplicidad y velocidad para ser utilizados en análisis multidimensionales, permitiendo acceder a datos agregados como también a datos de detalle [12].

La simplicidad de este esquema es una ventaja muy apreciada por los usuarios finales. Las consultas no son complicadas, puesto que sólo involucran a la tabla de hechos y las dimensiones de manera directa, evitando encadenar uniones y condiciones a dos o más niveles. Por otra parte, este esquema optimiza la velocidad al permitir indexar las dimensiones de forma individualizada, sin que esto impacte en el rendimiento de la base de datos.

2.4.5.2 Modelo copo de nieve

El modelo de Copo de Nieve está basado en un modelo estrella, donde las dimensiones se normalizan en múltiples tablas. Esta normalización se basa en las jerarquías que presenta cada dimensión, dejando cada nivel jerárquico explicitado en una nueva tabla dimensional [13].


20

Con esto, la tabla de hechos deja de ser la única vía para relacionar tablas, lo cual dificulta la comprensión del modelo para los usuarios finales, además de disminuir el rendimiento, debido a los Joins que se deben emplear para realizar las consultas.

A favor de este esquema, como todo modelo normalizado, disminuye la redundancia de datos, ahorrando espacio y contribuyendo a su mantención. El ahorro de espacio es un tema que se debe evaluar con el usuario final, puesto que con los avances en Hardware, esta preocupación ha disminuido. Este esquema se recomienda cuando se tienen grandes dimensiones, y donde sus registros presentan distintos comportamientos. Por ejemplo, una tabla de clientes podría llegar a considerar como tal, a todos aquellos que realizan una compra como visitantes (para los cuáles no se tienen muchos datos), y a aquellos que se encuentran registrados como clientes (para los que se tiene toda la información). En este caso, sin ser una jerarquía para la dimensión, conviene separar la dimensión de acuerdo a estos perfiles, para evitar tener un registro de cliente para los visitantes, donde la mayoría de los campos de la tabla estarían vacíos [14].

Otro caso donde se suelen tener campos vacíos, es para algunas dimensiones de productos financieros, dado que éstos, más que productos son servicios, y suelen tener características propias que los diferencian de los otros servicios. Por ejemplo, un certificado de depósito no se parece a una hipoteca. En estos casos, para evitar tener una dimensión producto que va llenando registros con campos vacíos según sea la instancia, conviene dejar como base una tabla dimensional con todos los atributos en común que presentan los productos, creando nuevas dimensiones que surgen de ésta base, para cada producto.

Fig. 2.6: Modelo Copo de Nieve


21

Un último ejemplo donde conviene normalizar, es para una tabla de calendario de una empresa retail con presencia en distintos países. En estos casos, cada país posee distintos calendarios, basados en su forma de ver la semana, de acuerdo a los días festivos, etc. Por este motivo, se recomienda dejar en la dimensión base todos los campos en común, dejando los atributos particulares de cada calendario en nuevas dimensiones para cada calendario.

2.4.5.3 Modelo constelación

El modelo denominado Constelación es un caso especial, donde existen múltiples tablas de hechos, las cuales comparten tablas dimensionales [13]. Estos modelos suelen utilizarse para modelar más de un proceso de la organización, con el fin de utilizar (compartir) las mismas tablas dimensionales que ya han sido creadas para un proceso en particular.

Dicho esto, su principal ventaja es la reutilización de las tablas dimensionales. Además, permite agregar aspectos adicionales del negocio, con un mínimo esfuerzo de diseño.

Fig. 2.7: Modelo Constelación


22

2.5 Reporting Actualmente la generación de reportes de apoyo a la gestión de las organizaciones es una

práctica habitual y necesaria para una correcta toma de decisiones. El problema es que en la mayoría de las organizaciones este proceso se realiza de manera manual o a través de un equipo de técnicos en el área de sistemas. Este enfoque trae consigo problemas de flexibilidad, de tiempos de respuesta y de incapacidad para satisfacer la demanda creciente por reportes individuales para cada ejecutivo.

En el último tiempo se han desarrollado soluciones de Reporting que permiten automatizar el proceso de generación y distribución de reportes permitiendo incluso el auto-servicio por aquellos encargados de tomar las decisiones, pudiendo éstos buscar y analizar la información que consideren importante en el momento oportuno.

Las soluciones de Reporting en general forman parte de una solución de Inteligencia de negocios global que considera la integración de la información empresarial en uno o más repositorios de datos.

Una solución de Reporting completa permite:

Ver tendencias y problemas de negocio tempranamente con dashboards gráficos, altamente intuitivos

Navegar y hacer drill-through a través de datos multidimensionales para entender causas fuente

Obtener análisis sofisticado combinando fuentes de datos diferentes

Utilizar un amplio rango de tipos de visualizaciones, incluyendo grillas, gráficos, pinboards, semáforos, y personalización de los mismos

Generar reportes de excepción, análisis de tendencias y simulaciones de manera rápida y fácil


23

Fig. 2.8: Reporte que muestra Tendencias

Fig. 2.9: Reporte con Pinboard y Semáforos

24

Capítulo 3 Metodología

Para el desarrollo de este proyecto, es necesario seguir una metodología, para lo cual se utilizará aquella propuesta por Larissa T. Moss [11], descrita en la sección 2.3.

Sin embargo, para este proyecto en particular, existen etapas de esta metodología que no aplican a la solución, por lo cual a continuación se indican cuáles de todas las etapas se realizarán en este proyecto.

Etapa 1 – Justificación: La agencia de aduanas busca aprovechar una oportunidad de negocio, probando la solución de Business Intelligence, con el fin de reducir los tiempos de reunión y organización de la información, preparación de reportes y toma de decisiones. Dado que no hay mayor justificación que eso, esta etapa no aplica para este proyecto en particular.

Etapa 2 – Planificación: Esta etapa se llevó a cabo en el plan de trabajo de este proyecto, en las asignaturas Proyecto 1 y 2. Dado que para esta etapa no se requiere más que eso en este proyecto, no se llevará a cabo de manera formal.

Etapa 3 – Análisis: De esta etapa se realizará el paso 4, donde es necesario comprender los procesos de negocio a cubrir por la solución. Además, el proyecto consiste en implementar un prototipo que muestre las funcionalidades de una herramienta BI, para lo cual se utilizará el paso 6 (Prototipo).

Etapa 4 – Diseño: Esta etapa se realizará, llevando a cabo el diseño del Data Mart, según la metodología de Kimball descrita en la sección 2.4. Por lo tanto, sólo se contempla el paso 10. El paso 9, relativo a diseño de procesos ETL, se descarta en este proyecto, puesto que los datos vienen entregados en formato .xls, para llegar y cargar al repositorio.

Etapa 5 – Construcción: De esta etapa, a llevarse a cabo durante la asignatura Proyecto 2, se construirá el cubo OLAP, se cargará con datos (ETL) y se utilizarán aplicaciones de Query y Reporting, utilizando la suite Oracle Standard Edition 1 (Oracle BD, OBI). En resumen, se llevarán a cabo los pasos 11, 12 y 14.

Etapa 6 – Despliegue: Finalmente en esta etapa se utilizará el Paso 15 (Implementación) donde se realizará la carga de los datos, la publicación de los modelos en el servidor y la validación de los modelos, liberando parcialmente dichos modelos hasta lograr la solución final. Esta etapa es posterior a la evaluación de este proyecto, para presentar el prototipo final a la Agencia de Aduanas.

Capítulo 3: Metodología

25

Fig. 3.1: Pasos Etapas Proyectos de Ingeniería

26

Capítulo 4 Análisis del negocio

Para la fase de análisis es preciso centrarse en los procesos de negocio a los cuales se pretende dar solución. Estos son vistos por la agencia de aduana como 2 procesos distintos, producto del enfoque que tiene cada uno. Sin embargo, ambos procesos están muy ligados.

4.1 Definición de los requisitos

4.1.1 Proceso de ventas

El proceso de ventas es el primer proceso citado por la agencia al momento de querer realizar gestión. Este es un proceso que les permite revisar su gestión, analizando cuánto se ha vendido, a quiénes se les ha vendido más y qué se ha vendido (operaciones).

Las operaciones son realizadas por un ejecutivo, el cual pertenece a un grupo de ejecutivos. Como contraparte del proceso, se encuentra el cliente, a quien se le realiza la operación solicitada. Una operación es el trámite aduanero que el cliente solicita realizar, los cuales se agrupan en operaciones de entrada y salida. Cada operación está registrada en un despacho, el cual posee un número de despacho y todo el detalle de la operación. Los despachos son “gestiones, trámites y demás operaciones que se efectúen ante el Servicio en relación con las destinaciones aduaneras” [15].

Existe un par de términos que implican montos registrados en el proceso de venta. El primero de éstos es el valor CIF (Cost, Insurance and Freight, Costo, Seguro y Flete), para el cual el vendedor debe hacer el despacho de la mercancía para su exportación, pagando los Costos, el Flete y el Seguro Marítimo necesario para transportarla al destino indicado [16]. El otro término es el valor FOB (Free On Board, Franco a Bordo), y se registra cuando el vendedor se responsabiliza de colocar la mercancía a bordo de una nave en el puerto indicado en el contrato de venta [16].

4.1.2 Proceso de cuentas corrientes

El proceso de Cuentas Corrientes es similar al proceso anterior, puesto que consiste en analizar valores. Sin embargo, la diferencia está en el enfoque contable que se le da al análisis de los valores asociado a este proceso.

Este proceso surge del proceso de ventas, puesto que consiste en analizar el estado de cuenta de cada cliente. Para esto, un cliente debe haber solicitado una operación, a modo de tener ventas asociadas a él. El hecho de que un cliente tenga ventas asociadas a él, implica

Capítulo 4: Análisis del negocio

27

inmediatamente que éste debe cancelar los valores de cada operación solicitada, por lo que, además de las ventas, en este proceso se visualizan los pagos que cada cliente ha hecho.

El foco del análisis de este proceso es el saldo que el cliente mantiene, de manera de poder observar qué clientes cumplen con sus pagos y cuáles son los clientes en calidad de morosos.

Hoy en día, realizan análisis de saldo a nivel de operación, como también a nivel acumulado, por lo que el mantener la historia de manera eficaz es un tema no menor.

4.3 Prototipo de la aplicación

4.3.1 Visión integrada

Como se dijo al comienzo de este capítulo, los 2 procesos revisados en las secciones anteriores están muy ligados, pese a tener distintos enfoques al momento de analizarlos. Por este motivo, para la construcción del prototipo, estos procesos serán integrados al momento de crear la solución, por el hecho de contar con las mismas métricas. La tarea de analizar los distintos enfoques, se cubrirá con herramientas de Reporting, generando reportes comerciales y reportes contables, atacando así las necesidades de análisis que la agencia de aduanas posee.

La figura 4.1 muestra, a través de un Diagrama de Actividades UML, el funcionamiento de estos procesos de forma integrada.

Fig. 4.1: Diagrama de Actividades Proceso de Venta

28

Capítulo 5 Diseño

5.1 Diseño del repositorio de metadata El diseño del repositorio de la Metadata, en este caso el Data Mart, se va a llevar a cabo

utilizando la metodología de Kimball descrita en el capítulo 2. El Data Mart es la parte fundamental del proyecto, puesto que será la base para crear el cubo OLAP, al cual se accederá mediante las herramientas de Reporting.

5.1.1 Selección de los procesos de negocio

A la administración le interesa entender mejor el proceso de compras del cliente, capturado en sus sistemas transaccionales. Por ende, los procesos a incorporar en el Data Mart son los procesos de Ventas y el proceso de Cuentas Corrientes, levantados en la fase de análisis. Estos datos permitirán analizar cuáles son las operaciones realizadas, por qué clientes, con qué ejecutivos y en qué día.

5.1.2 Declaración de granularidad

Una vez los procesos de negocios han sido identificados, continúa una decisión importante respecto de la granularidad. ¿Qué nivel de detalle en los datos debería estar disponible en el modelo dimensional? La respuesta viene dada por un tip de diseño muy importante, por parte de Ralph Kimball [10]. Éste dice que los modelos dimensionales a desarrollar deben ser para la información más atómica capturada en el proceso de negocios. Los datos atómicos son la información más detallada que ha sido capturada, por lo cual ésta no podrá ser subdividida.

Tomando los datos en su nivel más bajo, la granularidad atómica tiene sentido en diversos frentes. Los datos atómicos son altamente dimensionales. Mientras más detalladas y atómicas sean las métricas, más serán las cosas que se tendrá por seguro. Todas esas cosas que se pueden saber por seguro se traducen en dimensiones. Bajo esta consideración, los datos atómicos son perfectos para el enfoque dimensional.

Los datos atómicos proveen una flexibilidad máxima de análisis, porque se les puede aplicar restricciones y agrupaciones hacia niveles jerárquicos superiores (Rolled Up), en todas las maneras posibles. Los datos detallados en un modelo dimensional están listos para el análisis ad hoc de los usuarios finales.

Obviamente, siempre se puede declarar niveles más altos de granularidad para los procesos de negocio que representan agregaciones de los datos más atómicos. Sin embargo, apenas se seleccione un nivel granular más alto, se estará limitando a una menor cantidad de dimensiones, y

Capítulo 5: Diseño

29

potencialmente menos detalladas. El modelo menos granular queda vulnerable inmediatamente hacia requerimientos de usuario inesperados, para realizar el drill down hacia un mayor detalle. Los datos agregados juegan un rol importante como herramienta de optimización del rendimiento, pero esto no sustituye el hecho de darles a los usuarios el acceso hacia los niveles más bajos.

En este caso, los datos más granulares están a nivel de operación. Para asegurar el máximo de dimensionalidad y flexibilidad, se procederá a aplicar esta granularidad.

Teniendo acceso a la información transaccional, se puede obtener una vista detallada de las ventas. Mientras que a los usuarios probablemente no les interesa analizar aspectos simples asociados a las transacciones, no se puede predecir cada una de las formas en que ellos querrán acceder a los datos.

La mayoría de las veces un data warehouse exigirá datos expresados al más bajo nivel de granularidad posible para cada dimensión. Esto no se debe a que las consultas querrán ver las filas más bajas, sino porque las consultas necesitan cortar a través de los detalles de manera precisa.

5.1.3 Identificación de dimensiones

Luego de que se ha escogido la granularidad de la tabla de hechos, las dimensiones se deducen inmediatamente, viendo qué información complementa la información respecto de las operaciones.

5.1.3.1 Dimensión periodo

Esta dimensión es la primera en deducirse, puesto que una operación es realizada durante un determinado día. Además, se requiere conocer las fechas de los despachos, por lo que es una dimensión imprescindible. Su jerarquía se compone por:

-----Año

-----Trimestre

-----Mes

-----Fecha Contable


30

5.1.3.2 Dimensión operación

Esta dimensión permite describir las operaciones que generan las ventas de la agencia de aduanas. Las operaciones se agrupan en operaciones de entrada (Importaciones, Admisiones Temporales, otras) y operaciones de salida (Exportaciones, Salidas Temporales, otras). Esta dimensión se conforma de la siguiente manera:

-----Tipo de Operación

º-----Operación

5.1.3.3 Dimensión cliente

Esta dimensión es necesaria para describir a qué cliente se le está realizando la operación. Los clientes, en esta agencia de aduana, también son vistos a un nivel más agregado, donde se ven los Holdings, o bien empresas Administradoras, que reúnen un número de clientes y se encargan de gestionar sus trámites. La dimensión queda conformada por:

-----Grupo de Clientes

-----Rut Cliente

-----Razón Social

5.1.3.4 Dimensión ejecutivo

Esta dimensión permite describir a la persona que se encarga de llevar a cabo la operación solicitada por el cliente. Los ejecutivos pertenecen a un grupo de ejecutivos, lo que permite crear un nivel jerárquico que agrega a los ejecutivos. Esta dimensión se conforma por:

-----Grupo de Ejecutivos

-----Rut Ejecutivo

-----Código Ejecutivo

-----Nombre Ejecutivo

5.1.3.5 Dimensión despacho

Esta dimensión guarda los detalles del despacho, como el número de este, un campo de referencia utilizado por la agencia, y un código conocido como pedidor. Esta dimensión se conforma por:

-----Número de Despacho

-----Referencia

-----Pedidor


31

5.1.3.6 Dimensión aduana

Esta dimensión indica en qué aduana se está tratando el despacho. Esta dimensión se conforma por:

-----Código Aduana

-----Sucursal Aduana

5.1.3.7 Dimensión movimiento

Esta dimensión se utiliza para el proceso contable. Agrupa los distintos tipos de movimientos del cliente, ubicándolos como pagos o cobros, además de describir los movimientos. Esta dimensión se conforma por:

-----Tipo Movimiento

-----Descripción Movimiento

5.1.4 Identificar los hechos

El cuarto paso en el diseño es determinar cuidadosamente cuáles son las métricas que aparecerán en la tabla de hechos. Una vez más, la declaración de granularidad ayuda a tomar la decisión. En simples palabras, los hechos deben ser ciertos para la granularidad: la operación solicitada. Cuando se consideran hechos potenciales, se puede ver la necesidad de ajustar las afirmaciones en la declaración de granularidad o en la elección de las dimensiones.

Los hechos recogidos por el sistema transaccional de la agencia de aduanas incluyen las cantidades de los montos de la venta y los montos pagados por el cliente, por cada operación realizada por un ejecutivo en una aduana, durante un determinado período. Estos montos corresponden al valor FOB y al valor CIF.

Además, el proceso contable agrupa los montos involucrados de manera distinta. Las platas se separan en haberes (dinero cancelado por el cliente) y deberes (dinero adeudado por el cliente), de acuerdo a los distintos movimientos del cliente.

Cada uno de los montos registrados es aditivo a través de todas las dimensiones. Esto permite realizar operaciones de slice y dice sobre la tabla de hechos con toda libertad.

Sin embargo, el proceso contable sólo registra los movimientos de un cliente asociado a un ejecutivo, durante cierto periodo. De este modo, al tener menor granularidad que la ya definida, es necesario crear una tabla de hechos distinta para el proceso contable, para reflejar así la granularidad de ésta de una manera efectiva.

5.1.5 Diseño del modelo dimensional

Para modelar ambos procesos, se creará un modelo basado en el esquema de constelación, considerando dos modelos estrella (uno para cada proceso) que comparten algunas dimensiones


32

en común. Este modelo recoge cada una de las dimensiones y tablas de hecho identificadas en los pasos anteriores.

La decisión de utilizar esquemas estrellas que convergen en un esquema de constelación, se basa principalmente en buscar una fácil lectura de la solución por parte del usuario final. Además, con esto se prioriza el rendimiento del modelo, por sobre el ahorro de espacio.

Finalmente, el modelo dimensional se muestra en la figura 5.1.

Fig. 5.1: Modelo Dimensional


33

5.2 Diseño de reportes La agencia de aduanas desea ver la información bajo 2 enfoques. Un primer enfoque

comercial, el cual consiste en la revisión de las ventas y las distintas métricas incorporadas en el modelo. El segundo enfoque para la información es el enfoque contable, el cual consiste en analizar la información referente a los pagos de los clientes.

5.2.1 Reportes comerciales

Bajo este punto de vista, a la agencia de aduanas le interesa conocer aspectos que permitan analizar su desempeño. Los reportes deseables son:

Clientes con mayores ventas.

Clientes con mayor cantidad de operaciones.

Ejecutivos que más operaciones realizan.

Fig. 5.2: Ejemplo Reporte de Ventas

Estos son los reportes básicos, los cuáles pueden ser explotados de acuerdo a la información guardada en el cubo. Por ejemplo, se puede jugar con los períodos, mostrando evolución de ventas por cliente, analizar los meses con más operaciones, etc.


34

Fig. 5.3: Ejemplo Reporte de Evolución de Ventas

Además, de acuerdo al diseño de las jerarquías de cada dimensión, en la sección 5.1.3, estos reportes son navegables, pudiendo visualizar desde información agregada, hasta el máximo de detalle.

5.2.3 Reportes contables

Bajo este punto de vista, a la agencia de aduanas sólo le interesa conocer los detalles de los pagos de cada cliente. A la agencia le interesa revisar el saldo de cada cliente, por lo que el reporte deseable en este análisis es uno solo, el cual consiste en mostrar las ventas para con el cliente, junto a los pagos que éste ha realizado, entre dos fechas ingresadas. Además de mostrar los montos incurridos durante esas fechas, la agencia desea visualizar la venta acumulada.


35

Fig. 5.4: Ejemplo Reporte Contable

36

Capítulo 6 Construcción

6.1 Desarrollo del repositorio de la metadata La construcción del Data Mart consiste en crear las tablas que permiten guardar la

información necesaria para desarrollar el cubo. Para este proyecto, se ha diseñado un modelo estrella en el capítulo 5, el cual se implementó en una base de datos Oracle.

Oracle es un sistema de base de datos poderoso, objeto-relacional, posicionado como uno de los líderes dentro del mercado de base de datos, y aún más, dentro de los líderes de BI gracias a la adquisición de Hyperion. Puede funcionar con Windows, entre otros SO. Oracle es la base de datos número 1, con un 47,1% de participación en el mercado, según el Informe Gartner 2006 [17].

Dentro de sus características de motor de base de datos, se puede mencionar el soporte de claves foráneas, joins, vistas, triggers, y procedimientos almacenados. Incluye la mayoría de los tipos de datos en SQL92 y SQL99, incluyendo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, y TIMESTAMP. También puede almacenar datos de tipo BLOB (Binary Large OBjects,largos objetos binaries) como lo son las imágenes, sonidos, o videos.

La elección de este motor de Base de Datos se basa en el hecho de que su licencia permite desarrollar prototipos, en la medida que éstos no sean comercializados, y sólo se utilicen para mostrar la capacidad de la herramienta. En caso de querer comercializar dicha solución, es necesario comprar licencias que permitan instalar la solución dentro de los procesos productivos de una empresa, o bien como sistemas de procesamiento de información real. En el Apéndice de esta tesis se pueden leer los términos de licencia.

Para la construcción del Data Mart se ha utilizado una herramienta de administración de bases de datos Oracle, llamada Oracle SQL Developer, la cual ha permitido llevar a cabo la creación de un esquema para almacenar las tablas del modelo estrella.

Esta herramienta permite interactuar con la base de datos Oracle, mediante una interfaz gráfica. Así, se pueden realizar las acciones que Oracle soporta, como la creación de tablas, vistas, procedimientos entre otros, la indexación y el particionamiento de tablas, insertar datos, truncar tablas. En general, se puede revisar y ajustar cualquier código SQL y PL/SQL en la aplicación [18].

Para este proyecto, esta herramienta fue utilizada para crear las tablas y cargarlas con datos, proceso que se detalla a continuación.

Capítulo 6: Construcción

37

6.2 Desarrollo del proceso de ETL Para el Desarrollo del Proceso de ETL, se ha utilizado la misma herramienta con la que se

creó el repositorio de la metadata, Oracle SQL Developer, la cual permite cargar los datos de manera simple.

Para poder cargar los datos dentro de una tabla, es necesario contar con éstos en algún formato soportado por la herramienta (.xls, .csv, .xml entre otros). Para este proyecto, el cliente decidió entregar la información solicitada en formato .xls o .csv, con el fin de resguardar el acceso a su Base de Datos, por lo cual, la decisión de utilizar la herramienta, se justifica aún más.

Fig. 6.1: Herramienta de administración BD Oracle SQL Developer

Para importar datos dentro de una tabla, se debe hacer click sobre el botón de acciones y elegir la opción Import Data, como se ve en la figura 6.2.


38

Fig. 6.2: SQL Developer, Import Data

A continuación, las siguientes figuras detallan el proceso de selección de archivo csv, mapeo de columnas y carga de datos.

Fig. 6.3: Selección del archivo CSV


39

Fig. 6.4: Obtención de las columnas del archivo Excel

Fig. 6.5: Selección de columnas del archivo Excel


40

Fig. 6.6: Mapeo de columnas de origen hacia la tabla destino

Fig. 6.7: Verificación de parámetros del Importe de Datos


41

Fig. 6.8: Confirmación de inserciones


42

Fig. 6.9: Visualización de Datos insertados

6.3 Desarrollo de la aplicación

6.3.1 Creación del cubo OLAP

Después de haber construido el Data Mart y haberlo cargado con datos, el siguiente paso es construir el cubo OLAP.

Para la implentación de cubos, Oracle ofrece una herramienta llamada Administration Tool, dentro de la suite OBI (Oracle Business Intelligence), la cual permite crear un repositorio de datos (Data Warehouse) o archivo .rpd para su posterior explotación.

Para la creación de este repositorio, la herramienta trabaja las 3 capas descritas en el punto 2.2. Esto permite construir el cubo a partir de un modelo relacional.

Lo primero es el trabajo en la capa física, donde se mapea el modelo estrella creado en el punto anterior, y donde se encuentran los campos que se desea desplegar en los cubos OLAP.


43

Fig. 6.10: Importe del modelo relacional en la capa física

Una vez que se ha importado la fuente de datos operacionales (en este caso, el Data Mart preparado previamente para ello), se puede visualizar el modelo importado, para verificar las tablas y sus relaciones.


44

Fig. 6.11: Revisión del modelo relacional importado.

Luego de verificar que la capa física esté correcta, se debe continuar con la siguiente capa conocida como Data Staging Area. Esta etapa de preparación de la información a desplegar, se conoce como Capa de Negocio, en la herramienta.

Acá se mapean los campos que se desean crear en el cubo, ya sea para las tablas de hechos o para las dimensiones.


45

Fig. 6.12: Mapeo de campos.

Una vez que se han mapeado todos los campos que se desean cargar a los cubos, se debe acceder al modelo de negocios (similar a la visualización del modelo relacional en la capa física). Esto permite relacionar las tablas de manera lógica, lo que permitirá reconocer a la herramienta cuáles son las tablas de hechos, y cuáles serán tablas dimensionales.


46

Fig. 6.13: Confección del Modelo de Negocios

Además, en esta capa se pueden cambiar los nombres de las tablas y campos mediante transformaciones, para así generar nombres más familiares para los usuarios finales.


47

Fig. 6.14: Transformaciones sobre nombres de tablas y campos.

Finalmente, en esta capa se crean las dimensiones, sus jerarquías y claves lógicas, las cuales permitirán la navegabilidad de los cubos.


48

Fig. 6.15: Creación de dimensiones, jerarquías y claves lógicas.

La tercera y última capa corresponde a la Capa de Presentación, donde se deben colocar los datos que se van a disponibilizar para los usuarios finales, pudiendo realizar agrupaciones de éstos.


49

Fig. 6.16: Capa Física

6.3.2 Construcción de reportes

Finalmente, cuando ya se ha construido el repositorio de datos, existe una herramienta dentro de la suite de OBI, que permite explotar dicho repositorio, accediendo a él de manera gráfica, para generar reportes. Esta herramienta se conoce como Presentation Services

Presentation Services es una herramienta web y está pensada para usuarios finales, por lo cual, la construcción de los reportes se realiza mediante interfaz Drag and Drop, evitando exponer al usuario ante generaciones de código engorrosas.

Para generar un reporte, se accede a la sección Answers, seleccionando el repositorio creado. De este modo, se obtiene el listado de todas las tablas existentes en el repositorio, con todos los campos disponibilizados previamente en la Capa de Presentación del repositorio, para seleccionarlos y confeccionar la consulta.


50

Fig. 6.17: Confección de consulta para reporte

Una vez que se ha confeccionado la consulta, se puede crear una tabla pivot con los resultados de ésta, para visualizar y ordenar mejor los datos. También se pueden agregar gráficos, para complementar la información del reporte.


51

Fig. 6.18: Agregación de Tabla Pivot y Gráfico en el reporte

Finalmente, estos reportes se pueden agrupar para ser presentados en una sola pantalla, conocida como Dashboard. Cabe destacar que estos reportes son navegables, de acuerdo a la lógica definida en la Capa de Negocios del repositorio.


52

Fig. 6.19: Presentación de reportes en Dashboard

53

Conclusiones Las empresas que han implementado sistemas transaccionales para manejar sus

operaciones, poseen grandes volúmenes de datos registrados por estos sistemas de acuerdo a sus operaciones diarias. El hecho de tener una gran cantidad de datos, dificulta el poder ver la información precisa y concisa para poder tomar decisiones oportunas, sin tener las herramientas que faciliten esto. Las herramientas BI permiten abordar estos problemas, permitiendo una correcta visualización de la información necesaria para la toma de decisiones.

El objetivo principal de una solución BI es apoyar a la gestión de la empresa donde se está desarrollando el proyecto. Por este motivo, es de suma importancia involucrar a los gerentes y a todo aquel que posea la capacidad de tomar decisiones dentro de la empresa, de modo que la información que se trabaje sea la que ellos esperan analizar.

Respecto de un proyecto BI, queda clara la envergadura de éstos, destacando su gran utilidad para resolver problemas relacionados a la toma de decisiones de una empresa. La amplia gama de técnicas y herramientas, permite atacar la mayoría de problemáticas a las que las empresas se enfrentan al momento de contar con grandes volúmenes de datos y no saber qué hacer con ellos.

Toda técnica o herramienta de BI tiene un carácter de integración. Las soluciones BI persiguen resolver problemas en los procesos de negocios, o bien optimizar éstos, a través de toda la organización. Es importante entonces, evitar tratar la información a nivel de departamentos o áreas comerciales, buscando la integración de estas áreas de manera de asegurar la consistencia de toda la metadata almacenada.

Implementar un proyecto BI permite revisar la calidad de los datos existentes en una organización, permitiendo identificar problemas de inconsistencia de datos y/o información duplicada. Es una buena instancia para fijar estándares de nombres en caso de que no los hubiera. Estos problemas, para efectos de implementación de herramientas BI, pueden ser corregidos con un buen desarrollo de ETL.

El desarrollo de un Data Warehouse es una solución robusta, que permite organizar los datos y mostrar eficientemente, la información que a la alta gerencia de las empresas les interesa analizar. Es una buena herramienta de apoyo a la toma de decisiones.

Un Data Warehouse debe tener la información con el mayor nivel de detalle posible. El contar con información atómica permite anticiparse a nuevos requerimientos y análisis ad hoc imprevistos por parte de los usuarios finales. A la vez, la información atómica puede ser agregada hacia niveles jerárquicos superiores, pudiendo agrupar la información y acotando las tablas con largos resultados difíciles de leer. La gran fortaleza de las herramientas de BI es que, a pesar de mostrar la información agregada que la alta gerencia de una empresa desea visualizar, siempre existe la opción de realizar drill down hasta la información más detallada.

Conclusiones

54

La metodología de Kimball, para el diseño de un Data Mart permite desarrollar modelos dimensionales consistentes, permitiendo atacar los problemas de granularidad en la información, desarrollando modelos para todos aquellos datos que estén a un mismo nivel de granularidad.

Las herramientas de Reporting están orientadas a facilitar el análisis a los usuarios finales, por lo que es importante la presentación de la información. Es necesario preocuparse de detalles como el hecho de que la metadata tenga nombres claros, para facilitar su lectura. Si existe un código cuyos valores aluden a otros campos, es preferible incluir esos campos en las dimensiones correspondientes. La metadata almacenada en un Data Warehouse siempre debe estar pensada para ser consultada por usuarios finales y por usuarios que no están acostumbrados a los códigos provenientes de las operaciones transaccionales.

55

Referencias

[1] Servicio Nacional de Aduanas, Chile. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.aduana.cl.

[2] Esteves, J., y Pastor, J. “Enterprise Resource Planning Systems Research: An Annotated Bibliography”, Communications of AIS, Volume 7, Article 8. August, 2001.

[3] SINNEXUS: Business Intelligence + Informática Estratégica. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.sinnexus.com/business_intelligence/index.aspx

[4] Goldenberg, B. "¿Qué es CRM y cuál es el verdadero significado?”. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.tress.com.mx/boletin/Noviembre2002/crm.html

[5] Mailvaganam, H. "Introduction to OLAP - Slice, Dice and Drill". DWreview. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.dwreview.com/OLAP/Introduction_OLAP.html.

[6] Xingquan, Z., Davidson, I. “Knowledge Discovery and Data Mining: Challenges and Realities”. IGI Global. Abril, 2007.

[7] Inmon, William H. “Building the data warehouse”. Wiley & Sons, 2002. 3a Edición. Capítulo 2: The Data Warehouse Environment. Pág. 31

[8] “OLAP and OLAP Server Definitions”, The OLAP Council 1995. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.olapcouncil.org/research/glossaryly.htm#SLICE

[9] Kimball, R., Reeves, L., Ross, M., y Thornthwaite, W. “The Data Warehouse Lifecycle Toolkit”. Wiley & Sons, 1998. 1a Edición.

[10] Kimball, R., y Ross, M. “The Data Warehouse Toolkit”. Wiley & Sons, 2002. 2a Edición.

[11] Larissa T. Moss, Shaku Atre, Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications, Addison Wesley, 2003.

Referencias

56

[12] “Haciendo Cubos, un blog acerca de Data Warehousing, cubos, Artus y BI”. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://haciendocubos.com/2007/08/01/el-modelo-estrella/

[13] Chaudhuri, S., y Dayal, U. “An Overview of Data Warehousing and OLAP Technology”. ACM Sigmod Record. Marzo, 1997.

[14] Kimball, R.“A Trio of Interesting Snowflakes”. Intelligent Enterprise Magazine. Junio 29, 2001[En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://intelligent-enterprise.informationweek.com/010629/warehouse1_1.jhtml?_requestid=237036

[15] Glosario de Términos Comercio Exterior, Servicio Nacional de Aduanas, Chile. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.aduana.cl/prontus_aduana/site/artic/20070228/pags/20070228112848.html

[16] INCOTERMS 2000, Servicio Nacional de Aduanas, Chile. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.aduana.cl/prontus_aduana/site/artic/20070228/pags/20070228113214.html

[17] Database 11g | Oracle Database. [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.oracle.com/lang/es/database/index.html

[18] Sue Harper, “Mejorar el Desempeño de las Aplicaciones”. Oracle Technology Network . [En línea] [Consultado el: 29 de Septiembre de 2010]. Disponible en: http://www.oracle.com/technology/global/lad-es/pub/articles/09-mar/o29sql.html?_template=/ocom/print

Apéndice

57

ANEXO A – Tablas del Data Mart

DIMENSIÓN CLIENTE CREATE TABLE "DB_SMITH"."DIM_CLIENTE"

(

"ID_CLIENTE" NUMBER NOT NULL ENABLE,

"GRUPO_CLIENTE" VARCHAR2(30 CHAR),

"RUT_CLIENTE" VARCHAR2(15 CHAR),

"RAZON_SOCIAL" VARCHAR2(100 CHAR),

CONSTRAINT "DIM_CLIENTE_PK" PRIMARY KEY ("ID_CL IENTE") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORA GE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCRE ASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE

)

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOC OMPRESS LOGGING STORAGE

(

INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTE NTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT

)

TABLESPACE "DBSMITH_USERS" ;

DIMENSIÓN DESPACHO CREATE TABLE "DB_SMITH"."DIM_DESPACHO"

(

"ID_DESPACHO" NUMBER NOT NULL ENABLE,

"DESPACHO" NUMBER,

"REFERENCIA" VARCHAR2(185 CHAR),

"PEDIDOR" VARCHAR2(3 CHAR),

CONSTRAINT "DIM_DESPACHO_PK" PRIMARY KEY ("ID_D ESPACHO") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTI CS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCT INCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE

)


Anexos

58

(


)


DIMENSIÓN EJECUTIVO CREATE TABLE "DB_SMITH"."DIM_EJECUTIVO"

(

"ID_EJECUTIVO" NUMBER NOT NULL ENABLE,

"GRUPO_EJECUTIVO" VARCHAR2(20 CHAR),

"RUT_EJECUTIVO" VARCHAR2(15 CHAR),

"CODIGO_EJECUTIVO" VARCHAR2(30 CHAR),

"NOMBRE_EJECUTIVO" VARCHAR2(50 CHAR),

CONSTRAINT "DIM_EJECUTIVO_PK" PRIMARY KEY ("ID_ EJECUTIVO") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTI CS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCT INCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE

)


(


)


DIMENSIÓN PERIODO CREATE TABLE "DB_SMITH"."DIM_PERIODO"

(

"ID_PERIODO" NUMBER NOT NULL ENABLE,

"AGNO" NUMBER,

"TRIMESTRE" VARCHAR2(10 CHAR),

"NOMBRE_MES" VARCHAR2(10 CHAR),

"NOMBRE_MES_CORTO" VARCHAR2(30 CHAR),

Anexos

59

"NUMERO_MES" NUMBER,

"FECHA_CONTABLE" DATE,

CONSTRAINT "DIM_PERIODO_PK" PRIMARY KEY ("ID_PE RIODO") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORA GE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCRE ASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE

)


(


)


DIMENSIÓN ADUANA CREATE TABLE "DB_SMITH"."DIM_ADUANA"

(

"ID_ADUANA" NUMBER NOT NULL ENABLE,

"CODIGO_ADUANA" NUMBER,

"SUCURSAL_ADUANA" VARCHAR2(15 CHAR),

CONSTRAINT "DIM_ADUANA_PK" PRIMARY KEY ("ID_ADU ANA") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORA GE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCRE ASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE

)


(


)


DIMENSIÓN OPERACIÓN CREATE TABLE "DB_SMITH"."DIM_OPERACION"

(

"ID_OPERACION" NUMBER NOT NULL ENABLE,

Anexos

60

"TIPO_OPERACION" VARCHAR2(8 CHAR),

"CODIGO_OPERACION" NUMBER,

"DESCRIPCION_OPERACION" VARCHAR2(35 CHAR),

CONSTRAINT "DIM_OPERACION_PK" PRIMARY KEY ("ID_ OPERACION") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTI CS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCT INCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE

)


(


)


DIMENSIÓN MOVIMIENTO CREATE TABLE "DB_SMITH"."DIM_MOVIMIENTO"

(

"ID_MOVIMIENTO" NUMBER NOT NULL ENABLE ,

"TIPO_MOVIMIENTO" VARCHAR2(5 CHAR),

"DESCRIPCION_MOVIMIENTO" VARCHAR2(25 CHAR),

CONSTRAINT "DIM_MOVIMIENTO_PK" PRIMARY KEY ("ID _MOVIMIENTO") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTI CS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCT INCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE

)


(


)


TABLA DE HECHOS COMERCIAL CREATE TABLE "DB_SMITH"."FT_COMERCIAL"

(


Anexos

61



"ID_OPERACION" NUMBER NOT NULL ENABLE,

"ID_ADUANA" NUMBER NOT NULL ENABLE,

"ID_DESPACHO" NUMBER NOT NULL ENABLE,

"VALOR_FOB" NUMBER,

"VALOR_CIF" NUMBER,

"FECHA_RECEPCION" DATE,

"FECHA_ACEPTACION" DATE,

"FECHA_LEGALIZACION" DATE,

"FECHA_LLEGADA" DATE,

"FECHA_FACTURA" DATE,

"FECHA_IMPRESION" DATE,

"FECHA_ENVIO" DATE,

"FECHA_AUTORIZACION" DATE,

"FECHA_DOCUMENTO" DATE,

"ESTADO_DESPACHO" VARCHAR2(15 CHAR),

CONSTRAINT "FT_COMERCIAL_PK" PRIMARY KEY ("ID_P ERIODO", "ID_CLIENTE", "ID_EJECUTIVO", "ID_OPERACION", "ID_ADUANA", "ID_DE SPACHO") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTI CS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCT INCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE,

CONSTRAINT "FT_COMERCIAL_DIM_PERIODO_FK1" FOREI GN KEY ("ID_PERIODO") REFERENCES "DB_SMITH"."DIM_PERIODO" ("ID_PERIODO") ENABLE,

CONSTRAINT "FT_COMERCIAL_DIM_CLIENTE_FK1" FOREI GN KEY ("ID_CLIENTE") REFERENCES "DB_SMITH"."DIM_CLIENTE" ("ID_CLIENTE") ENABLE,

CONSTRAINT "FT_COMERCIAL_DIM_EJECUTIV_FK1" FORE IGN KEY ("ID_EJECUTIVO") REFERENCES "DB_SMITH"."DIM_EJECUTIVO" ("ID_EJECUTIV O") ENABLE,

CONSTRAINT "FT_COMERCIAL_DIM_OPERACIO_FK1" FORE IGN KEY ("ID_OPERACION") REFERENCES "DB_SMITH"."DIM_OPERACION" ("ID_OPERACIO N") ENABLE,

CONSTRAINT "FT_COMERCIAL_DIM_ADUANA_FK1" FOREIG N KEY ("ID_ADUANA") REFERENCES "DB_SMITH"."DIM_ADUANA" ("ID_ADUANA") EN ABLE,

CONSTRAINT "FT_COMERCIAL_DIM_DESPACHO_FK1" FORE IGN KEY ("ID_DESPACHO") REFERENCES "DB_SMITH"."DIM_DESPACHO" ("ID_DESPACHO" ) ENABLE

)


(


Anexos

62

)


TABLA DE HECHOS CONTABLE

CREATE TABLE "DB_SMITH"."FT_CONTABLE"

(




"ID_MOVIMIENTO" NUMBER NOT NULL ENABLE,

"DESPACHO" NUMBER NOT NULL ENABLE,

"DEBE" NUMBER,

"HABER" NUMBER,

"FECHA_VENCIMIENTO" DATE,

"FECHA_FACTURA" DATE,

CONSTRAINT "FT_CONTABLE_PK" PRIMARY KEY ("ID_CL IENTE", "ID_EJECUTIVO", "ID_PERIODO", "ID_MOVIMIENTO", "DESPACHO") USING IN DEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 655 36 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 F REELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBSMITH_USERS" ENABLE,

CONSTRAINT "FT_CONTABLE_DIM_CLIENTE_FK1" FOREIG N KEY ("ID_CLIENTE") REFERENCES "DB_SMITH"."DIM_CLIENTE" ("ID_CLIENTE") ENABLE,

CONSTRAINT "FT_CONTABLE_DIM_EJECUTIVO_FK1" FORE IGN KEY ("ID_EJECUTIVO") REFERENCES "DB_SMITH"."DIM_EJECUTIVO" ("ID_EJECUTIV O") ENABLE,

CONSTRAINT "FT_CONTABLE_DIM_MOVIMIENT_FK1" FORE IGN KEY ("ID_MOVIMIENTO") REFERENCES "DB_SMITH"."DIM_MOVIMIENTO" ("ID_MOVIMIE NTO") ENABLE,

CONSTRAINT "FT_CONTABLE_DIM_PERIODO_FK1" FOREIG N KEY ("ID_PERIODO") REFERENCES "DB_SMITH"."DIM_PERIODO" ("ID_PERIODO") ENABLE

)


(


)


Anexos

63

ANEXO B – Consulta Reporte Top 5 Clientes SELECT

"Dim Periodo"."Año" saw_0,

"Dim Periodo"."Nombre Mes" saw_1,

"Dim Cliente"."Razon Social" saw_2,

Comercial."Valor FOB" saw_3

FROM Smith

WHERE

(TOPN(Comercial."Valor FOB",5) <= 5) AND

("Dim Periodo"."Nombre Mes" = 'Enero')

ORDER BY saw_3 DESC

Anexos

64

ANEXO C – Esquema XML Reporte Top 5 Clientes

<saw:report xmlns:saw="com.siebel.analytics.web/rep ort/v1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlVer sion="200705140" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc e" xmlns:sawx="com.siebel.analytics.web/expression/v1" >

<saw:criteria subjectArea="Smith">

<saw:columns>

<saw:column formula=""Dim Periodo&quo t;."Año"" columnID="c1">

<saw:displayFormat suppress="default" i nteraction="default">

<saw:dataFormat xsi:type="saw:number " commas="false" negativeType="minus" minDigits="0" maxDigits="0"/>< /saw:displayFormat>

<saw:columnHeading>

<saw:displayFormat interaction="default"/></saw:columnHeading></saw:co lumn>

<saw:column formula=""Dim Periodo&quo t;."Nombre Mes"" columnID="c5"/>

<saw:column formula=""Dim Cliente&quo t;."Razon Social"" columnID="c0"/>

<saw:column formula="Comercial."Valor FOB"" columnID="c4">

<saw:displayFormat suppress="default" i nteraction="default">

<saw:dataFormat xsi:type="saw:number " commas="true" negativeType="minus" minDigits="0" maxDigits="1"/>< /saw:displayFormat>

<saw:columnHeading>

<saw:displayFormat interaction="default"/></saw:columnHeading></saw:co lumn></saw:columns>

<saw:filter subjectArea="Smith">

<sawx:expr xsi:type="sawx:logical" op="and ">

<sawx:expr xsi:type="sawx:rank" op="top ">

<sawx:expr xsi:type="sawx:sqlExpress ion">Comercial."Valor FOB"</sawx:expr>

<sawx:expr xsi:type="xsd:decimal">5< /sawx:expr></sawx:expr>

<sawx:expr xsi:type="sawx:comparison" o p="equal">

Anexos

65

<sawx:expr xsi:type="sawx:sqlExpress ion">"Dim Periodo"."Nombre Mes"</sawx:expr>

<sawx:expr xsi:type="xsd:string">Enero</sawx:expr></sawx:expr> </sawx:expr></saw:filter>

<saw:columnOrder>

<saw:columnRef columnID="c4" direction="descending"/></saw:columnOrder></saw:cri teria>

<saw:views currentView="0">

<saw:view xsi:type="saw:compoundView" name="c ompoundView!1" rptViewVers="200510010">

<saw:cvTable>

<saw:cvRow>

<saw:cvCell viewName="titleView!1" c olSpan="2">

<saw:displayFormat/></saw:cvCell> </saw:cvRow>

<saw:cvRow>

<saw:cvCell viewName="pivotTableView !1"/>

<saw:cvCell viewName="staticchart!1"/></saw:cvRow></saw:cvTable ></saw:view>

<saw:view xsi:type="saw:titleView" name="titl eView!1" rptViewVers="200510010" includeName="false" started Display="none">

<saw:title>

<saw:caption fmt="text">

<saw:text>Top 5 Ventas a Clientes</saw:text></saw:caption></saw:title></saw: view>

<saw:view xsi:type="saw:tableView" name="tabl eView!1" rptViewVers="200510010"/>

<saw:view xsi:type="saw:pivotTableView" name= "pivotTableView!1" rptViewVers="200510010">

<saw:edge axis="page"/>

<saw:edge axis="section"/>

<saw:edge axis="row">

<saw:edgeLayer type="column" columnID=" c1" insertPageBreak="false"/>

<saw:edgeLayer type="column" columnID=" c5"/>

<saw:edgeLayer type="column" columnID=" c0" insertPageBreak="false">

<saw:columnHeading>

<saw:displayFormat/>

<saw:caption>

Anexos

66

<saw:text>Clientes</saw:text></saw:caption></saw:co lumnHeading></saw:edgeLayer></saw:edge>

<saw:edge axis="column">

<saw:edgeLayer type="labels" insertPage Break="false"/></saw:edge>

<saw:edge axis="measure">

<saw:edgeLayer type="column" columnID=" c4" insertPageBreak="false">

<saw:displayFormat/></saw:edgeLayer> </saw:edge></saw:view>

<saw:view xsi:type="saw:staticchart" name="st aticchart!1" rptViewVers="200510010">

<saw:template tid="charts/bar.cxml"/>

<saw:canvasFormat width="666">

<saw:title mode="custom">

<saw:caption>

<saw:text>Top 5 Ventas a Clientes</saw:text></saw:caption></saw:title></saw: canvasFormat>

<saw:selections>

<saw:categories>

<saw:category position="0">

<saw:column columnID="c5"/></saw: category></saw:categories>

<saw:measures>

<saw:column columnID="c4" position=" 0"/></saw:measures>

<saw:seriesGenerators>

<saw:column columnID="c0"/>

<saw:measureLabels/></saw:seriesGene rators></saw:selections>

<saw:variantSelectors>

<saw:variantSelector name="style" value="cylinder"/></saw:variantSelectors>

<saw:seriesFormats>

<saw:seriesFormatGroup name="series0">

<saw:seriesFormatRule>

<saw:seriesCondition position="1" />

<saw:visualFormats>

<saw:visualFormat className="b arProp" name="normalBar" color="#336666"/></saw:visualFormats></saw:seriesFo rmatRule>



Anexos

67

<saw:visualFormats>




<saw:visualFormats>




<saw:visualFormats>

<saw:visualFormat className="b arProp" name="normalBar" color="#CC9933"/></saw:visualFormats></saw:seriesFo rmatRule>



<saw:visualFormats>

<saw:visualFormat className="b arProp" name="normalBar" color="#008000"/></saw:visualFormats></saw:seriesFo rmatRule></saw:seriesFormatGroup></saw:seriesFormats>

<saw:conditionFormats/></saw:view></saw:vi ews></saw:report>

Apéndice

68

APÉNDICE – Extracto Licencia Oracle

El siguiente texto fue obtenido desde la página de Oracle, el 05 de Noviembre del 2009:

http://www.oracle.com/technology/software/popup-license/standard-license.html

Oracle Technology Network Developer License Terms

LICENSE RIGHTS

We grant you a nonexclusive, nontransferable limited license to use the programs only for the purpose of developing, testing, prototyping and demonstrating your application, and not for any other purpose. If you use the application you develop under this license for any internal data processing or for any commercial or production purposes, or you want to use the programs for any purpose other than as permitted under this agreement, you must obtain a production release version of the program by contacting us or an Oracle reseller to obtain the appropriate license. You acknowledge that we may not produce a production release version of the program and any development efforts undertaken by you are at your own risk. We may audit your use of the programs. Program documentation, if available, may accessed online at http://otn.oracle.com/docs.

Ownership and Restrictions We retain all ownership and intellectual property rights in the programs. The programs may be installed on one computer only, and used by one person in the operating environment identified by us. You may make one copy of the programs for backup purposes.

You may not:

use the programs for your own internal data processing or for any commercial or production purposes, or use the programs for any purpose except the development of your application;

use the application you develop with the programs for any internal data processing or commercial or production purposes without securing an appropriate license from us;

continue to develop your application after you have used it for any internal data processing, commercial or production purpose without securing an appropriate license from us, or an Oracle reseller;

remove or modify any program markings or any notice of our proprietary rights;

make the programs available in any manner to any third party;

use the programs to provide third party training;

Anexos

69

assign this agreement or give or transfer the programs or an interest in them to another individual or entity;

cause or permit reverse engineering (unless required by law for interoperability), disassembly or decompilation of the programs;

disclose results of any program benchmark tests without our prior consent.

No Technical Support:

Our technical support organization will not provide technical support, phone support, or updates to you for the programs licensed under this agreement.

End of Agreement:

You may terminate this agreement by destroying all copies of the programs. We have the right to terminate your right to use the programs if you fail to comply with any of the terms of this agreement, in which case you shall destroy all copies of the programs.

Relationship Between the Parties:

The relationship between you and us is that of licensee/licensor. Neither party will represent that it has any authority to assume or create any obligation, express or implied, on behalf of the other party, nor to represent the other party as agent, employee, franchisee, or in any other capacity. Nothing in this agreement shall be construed to limit either party's right to independently develop or distribute software that is functionally similar to the other party's products, so long as proprietary information of the other party is not included in such software.

Open Source

"Open Source" software - software available without charge for use, modification and distribution - is often licensed under terms that require the user to make the user's modifications to the Open Source software or any software that the user 'combines' with the Open Source software freely available in source code form. If you use Open Source software in conjunction with the programs, you must ensure that your use does not: (i) create, or purport to create, obligations of us with respect to the Oracle programs; or (ii) grant, or purport to grant, to any third party any rights to or immunities under our intellectual property or proprietary rights in the Oracle programs. For example, you may not develop a software program using an Oracle program and an Open Source program where such use results in a program file(s) that contains code from both the Oracle program and the Open Source program (including without limitation libraries) if the Open Source program is licensed under a license that requires any "modifications" be made freely available. You also may not combine the Oracle program with programs licensed under the GNU General Public License ("GPL") in any manner that could cause, or could be interpreted or asserted to cause, the Oracle program or any modifications thereto to become subject to the terms of the GPL.

Entire Agreement:

You agree that this agreement is the complete agreement for the programs and licenses, and this agreement supersedes all prior or contemporaneous agreements or representations. If any

Anexos

70

term of this agreement is found to be invalid or unenforceable, the remaining provisions will remain effective.

Last updated: 01/24/09

Should you have any questions concerning this License Agreement, or if you desire to contact Oracle for any reason, please write: Oracle USA, Inc. 500 Oracle Parkway, Redwood City, CA 94065

Oracle may contact you to ask if you had a satisfactory experience installing and using this OTN software download.

diseÑo e implementaciÓn de una soluciÓn business

Documents