utilización de información histórica para decisiones empresariales

UTILIZACIÓN DE INFORMACIÓN HISTÓRICA
PARA DECISIONES EMPRESARIALES
Autores:
Juan David Peña Rivera
Jesús Armando Suárez Daza
Proyecto de grado presentado para optar el título de Ingeniero de Sistemas
Director:
Luis Roberto Ojeda
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
SANTAFÉ DE BOGOTA D.C.
Junio de 2005
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
Rector Magnífico: Padre Gerardo Remolina Vargas S.J.
Decano Académico Facultad de Ingeniería: Ingeniero Francisco Rebolledo
Decano del Medio Universitario Facultad de Ingeniería: Padre José Sarmiento Nova S.J.
Director Carrera de Ingeniería de Sistemas: Ingeniera Hilda Cristina Chaparro López
Director Departamento de Ingeniería de Sistemas: Ingeniero Germán Alberto Chavarro
Nota de Aceptación
______________________________________________________
______________________________________________________
______________________________________________________
________________________________________
Director del Proyecto
________________________________________
Jurado
________________________________________
Jurado
Junio, 2005
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en
sus proyectos de grado.
Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque
no contengan ataques o polémicas puramente personales. Antes bien, que se vean en
ellos el anhelo de buscar la verdad y la Justicia”
TABLA DE CONTENIDO
INTRODUCCIÓN ........................................................................................................1
I MARCO TEÓRICO....................................................................................................3
1. DATA WAREHOUSE .........................................................................................................................3
1.1 COMPONENTES DE UN DATA WAREHOUSE ......................................................................4
1.2 BODEGA DE DATOS Y DATAMARTS....................................................................................4
1.2.1 Características de la bodega de datos.........................................................5
1.3 PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA DE LOS DATOS ...........6
1.4 EXPLOTACIÓN...........................................................................................................................6
1.4.1 Análisis OLAP..........................................................................................7
II. HERRAMIENTAS DE DATA WAREHOUSE ......................................................11
2. HERRAMIENTAS DE BASES DE DATOS Y OLAP .......................................................................11
2.1 MOTOR DE BASES DE DATOS MYSQL ...............................................................................11
2.2 MOTOR DE BASES DE DATOS POSTGRESQL....................................................................12
2.2.1 Arquitectura de la herramienta ................................................................12
2.3 HERRAMIENTA DE OLAP JPIVOT – MONDRIAN..............................................................13
2.3.1 Arquitectura de la herramienta ................................................................13
2.3.2 Estrategias de almacenamiento y agregación...........................................14
2.3.3 API .........................................................................................................15
2.3.4 MDX ......................................................................................................15
2.3.5 Esquema Mondrian .................................................................................16
2.3.6 Modelo lógico.........................................................................................16
III. METODOLOGIA PARA EL DESARROLLO DE UN DATA WAREHOUSE.....18
3. METODOLOGIA DE RALPH KIMBALL PARA UN PROYECTO DE DATA WAREHOUSE.....18
3.1 Planeación y administración del proyecto...................................................................................18
3.2 Análisis de requerimientos..........................................................................................................22
3.3 Modelamiento dimensional.........................................................................................................24
3.4 Diseño técnico de la arquitectura ................................................................................................28
3.5 Procesos de extracción, transformación y carga .........................................................................31
3.6 Selección e instalación de productos...........................................................................................36
3.7 CARACTERÍSTICAS DE aplicaciones para usuarios finales....................................................37
3.8 Mantenimiento y crecimiento de un data warehouse ..................................................................39
IV. DESARROLLO DEL PROCESO DE CONSTRUCCIÓN DEL DATAMART .....42
4. PLANEACIÓN Y ADMINISTRACIÓN DEL PROYECTO .............................................................42
4.1 OBJETIVO DEL PROYECTO...................................................................................................42
4.2 DEFINICIÓN DEL PROYECTO ...............................................................................................42
4.3 ALCANCE DEL PROYECTO ...................................................................................................43
4.4 JUSTIFICACIÓN DEL PROYECTO EN EL NEGOCIO..........................................................43
5. ANÁLISIS DE REQUERIMIENTOS ................................................................................................44
5.1 Levantamiento de requerimientos ...............................................................................................44
v
5.2 Documentación de requerimientos..............................................................................................44
5.2.1 Ver ventas por productos.........................................................................45
5.2.2Ver ventas por cliente ..............................................................................45
5.2.3 Ver ventas por tiempos............................................................................45
5.2.4 Ver ventas de productos por cliente.........................................................45
5.2.5 Ver ventas por productos en el tiempo.....................................................45
5.2.6 Ver ventas por cliente en el tiempo .........................................................45
5.2.7 Ver ventas por cliente y producto en el tiempo ........................................46
5.2.8 Ver ventas por ciudad .............................................................................46
5.2.9 Ver ventas por productos en ciudades......................................................46
5.2.10 Ver ventas por ciudad en el tiempo........................................................46
6. MODELAMIENTO DIMENSIONAL ...............................................................................................46
6.1 EL DATAMART ........................................................................................................................47
6.2 DEFINICIÓN DE LA GRANULARIDAD ................................................................................47
6.3 DIMENSIONES .........................................................................................................................48
6.3.1 Dimensión línea ......................................................................................48
6.3.2 Dimensión producto................................................................................48
6.3.3 Dimensión cliente ...................................................................................49
6.3.4 Dimensión sector ....................................................................................49
6.3.5 Dimensión geografía ...............................................................................49
6.3.6 Dimensión tiempo...................................................................................50
6.4 TABLA DE HECHOS ................................................................................................................50
6.5 DISEÑO DEL MODELO DIMENSIONAL...............................................................................51
7. DISEÑO TECNICO DE LA ARQUITECTURA................................................................................52
7.1 DATOS .......................................................................................................................................52
7.1.1 Mapeo de los datos en el modelo dimensional.........................................53
7.2 BACK ROOM ............................................................................................................................56
7.3 FRONT ROOM ..........................................................................................................................56
7.4 INFRAESTRUCTURA DE DATA WAREHOUSE ..................................................................57
8. PROCESO DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA.................................................58
8.1 HERRAMIENTA DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA .............................58
8.1.1 ETL de dimensión sector.........................................................................58
8.1.2 ETL de dimensión línea ..........................................................................58
8.1.3 ETL de dimensión geografía ...................................................................59
8.1.4 ETL de dimensión producto ....................................................................59
8.1.5 ETL de dimensión cliente .......................................................................59
8.1.6 ETL tabla de hechos................................................................................59
9. CONSTRUCCIÓN DEL CUBO .........................................................................................................61
9.1 ARCHVIVOS JSP ......................................................................................................................61
9.2 ESTRUCTURAS XML ..............................................................................................................62
9.2.1 Estructura del cubo .................................................................................63
9.2.2 Estructura de la dimensión Segmento......................................................64
9.2.2 Estructura de la dimensión Ciudad ..........................................................65
9.2.3 Estructura de la dimensión Producto .......................................................65
9.2.4 Estructura de la dimensión tiempo...........................................................66
10. REPORTES IMPLEMENTADOS....................................................................................................67
vi
10.1 VENTAS POR PRODUCTOS .................................................................................................68
10.2 VENTAS POR CLIENTE.........................................................................................................69
10.3 VENTAS POR TIEMPOS ........................................................................................................70
10.4 VENTAS DE PRODUCTOS POR CLIENTE..........................................................................71
10.5 VENTAS POR PRODUCTOS EN EL TIEMPO......................................................................72
10.6 VENTAS POR CLIENTE EN EL TIEMPO.............................................................................73
10.7 VENTAS POR CLIENTE Y PRODUCTO EN EL TIEMPO ..................................................74
10.8 VENTAS POR CIUDAD..........................................................................................................75
10.9 VENTAS POR PRODUCTOS EN CIUDADES ......................................................................76
10.10 VENTAS POR CIUDAD EN EL TIEMPO............................................................................77
9. MANTENIMIENTO Y CRECIMIENTO DEL DATAMART ...........................................................78
CONCLUSIONES ......................................................................................................79
RECOMENDACIONES .............................................................................................81
GLOSARIO ................................................................................................................82
BIBLIOGRAFÍA ........................................................................................................83
vii
INTRODUCCIÓN
Empresas de diferentes sectores buscan incrementar su productividad y ventajas
competitivas proporcionándole a la gerencia información analítica y estratégica para el
negocio. Esto se logra al aprovechar la información que a diario es almacenada en sus
bases de datos operativas.
Al intentar utilizar esta información de las bases de datos operativas para tomar
decisiones, se presentan varios problemas: existe demasiada información, muy genérica
de la cual no se pueden sacar conclusiones. La información muchas veces es irrelevante
para el área interesada en mejorar sus decisiones, y la organización termina por
desaprovechar todos estos datos, perdiendo un proceso de aprendizaje de sus propios
logros e información.
Por lo tanto, se plantea realizar una unión entre el mundo de los datos y el de los
negocios, por medio de la inteligencia de negocios con una solución basada en data
warehousing (bodega de datos). Esta solución permite utilizar los datos operativos de
una empresa para producir información relevante y que soporte la toma de decisiones
empresariales.
Para el proyecto de data warehousing se toman como fuente los sistemas de
información que tenga la empresa, pueden ser varios y en diferentes formatos, como
bases de datos o archivos de texto. Luego de extraer los datos relevantes, son
transformados de ser necesario y son cargados a una nueva base de datos, diseñada para
soportar la inteligencia de negocios, que luego será analizada tridimensionalmente con
análisis OLAP.
Mediante este proceso se producirá información relevante para los ejecutivos de una
empresa. Preguntas como: ¿Se va a lograr una cuota de ventas en un trimestre
determinado?, ¿En cuál ciudad tiene mayor potencial determinado producto?, ¿Qué tal
se está vendiendo un producto con respecto a períodos de tiempo anteriores?, ¿Cual es
el producto más rentable en determinada ciudad? ¿Cuáles son mis mejores clientes? y
por lo tanto, sus decisiones correspondientes se toman a diario en una empresa,
basándose en muchas ocasiones en intuiciones o suposiciones. Mediante el tipo de
análisis proporcionado en este proyecto, estas preguntas serán resueltas con base en
hechos y cifras rescatadas de las fuentes de datos operativas de la organización.
Grandes empresas como EPM, Telmex e IBM han utilizado la inteligencia de negocios
para estos propósitos, permitiéndoles conocer mejor a sus clientes, sus productos,
ventas, costos y otros factores determinantes en sus negocios. Las pymes han estado
ajenas a estas tecnologías por el alto costo que una solución de inteligencia de negocios
como lo es el Data warehouse implica. Es por esto que el proyecto plantea el desarrollo
1
de una solución de data warehouse para una pyme, utilizando herramientas de código
abierto para cada etapa de un desarrollo de este tipo.
Al poner a disposición de las pymes la inteligencia de negocios, se incrementará la
competitividad de estas frente al mercado y les dará la misma capacidad de inteligencia
y análisis que disponen sus grandes competidoras.
Al abordar este documento, se expone un conocimiento teórico del proceso de data
warehousing, describiendo su definición y procesos necesarios para realizarlo. Luego se
da a conocer la metodología utilizada para el desarrollo del proyecto, establecida por
Ralph Kimball, quien es considerado el padre y autoridad en el mundo del data
warehouse. Más adelante se exponen los elementos más importantes de las herramientas
libres utilizadas para la solución, para después entrar a detallar los procesos realizados
en el proyecto, desde la planeación del proyecto hasta su implantación. Finalmente se
exponen las conclusiones y recomendaciones que ha dejado el proyecto para dar
claridad a los conceptos desarrollados y servir de base a futuros desarrollos de la misma
área.
2
I MARCO TEÓRICO
1. DATA WAREHOUSE
El Data Warehouse es un conjunto de procesos y acciones que involucra un
almacenamiento de datos no volátil, orientado a un tema, integrado e histórico para el
soporte al proceso de toma de decisiones de la gerencia.
Es una técnica para consolidar y administrar datos de diversas fuentes con el propósito
de responder preguntas de negocios y tomar decisiones (Ver figura 1). Está constituido
por la correcta organización e interrelación de los desarrollos tecnológicos consistentes
en: consolidar datos desde una variedad de fuentes; manejar grandes volúmenes de
datos de una forma que no era posible, acceder a los datos de una forma más directa, en
"el lenguaje del negocio", y analizarlos para obtener relaciones complejas entre los
mismos.
Figura 1. Necesidad de información que soporte decisiones del negocio.1
1
[4] Fundamentals of Data Warehouse and Business Intelligence for Knowledge Management.
3
Un sistema Data warehouse define un nuevo concepto para el almacenamiento de datos,
integra la información generada en todos los ámbitos de una actividad de negocio
(ventas, producción, finanzas, Marketing, etc.) que proviene de diferentes fuentes,
formatos y tipos en un único depósito y permite un acceso y explotación de la
información contenida en las bases de datos, facilitando un amplio abanico de
posibilidades de análisis multivariables que permitirán la toma de decisiones
estratégicas.
1.1 COMPONENTES DE UN DATA WAREHOUSE
El Data Warehouse tiene varios componentes dentro de su arquitectura. Está
conformado por:
1. El repositorio de datos o bodega de datos
2. Los procesos de:
• Extracción
• Transformación
• Carga
• Explotación
1.2 BODEGA DE DATOS Y DATAMARTS
En 1992, Inmon define la bodega de datos como: " una colección de datos orientados a
temas, integrados, no-volátiles y variante en el tiempo, organizados para soportar
decisiones empresariales"2.
En 1993, Susan Osterfeldt publica una definición que sin duda es la clave de bodega de
datos: "Yo considero la bodega de datos como algo que provee dos beneficios
empresariales reales: Integración y Acceso de datos. La bodega de datos elimina una
gran cantidad de datos inútiles y no deseados, como acierta también el procesamiento
desde el ambiente operacional clásico".
El datamart se ajusta a la definición de una bodega de datos, con la diferencia que su
enfoque es servir a un área específica del negocio. Los procesos y fuentes de datos
necesarios para construir un datamart son iguales que en el caso de la bodega, pero la
información almacenada en el datamart proporcionará información específica, como
información de ventas, o de producción. De todas formas no se puede considerar a un
datamart como una “pequeña bodega”, pues un datamart puede ser más complejo y
contener mayor volumen de datos que toda una bodega, dependiendo del negocio y los
requerimientos de cada caso.
2
[11] Building the Data Warehouse.
4
Figura 2. Datamart, proporciona información a un área específica de la organización
Es así que la bodega de datos y el datamart son un repositorio centralizado que contiene
datos de una o diversas fuentes y que está específicamente diseñado para permitir
consultas y análisis detallado de los datos. En el caso del datamart, este análisis tiene un
enfoque determinado a áreas específicas del negocio.
1.2.1 Características de la bodega de datos
La bodega de datos se caracteriza por ser:
Temático: La bodega de datos está orientada a los principales temas o entidades de la
organización lo cual está en contraste con la mayoría de los sistemas de hoy en día cuya
orientación se basa en los procesos o funciones.
De acuerdo con esta característica, la bodega de datos para una empresa de ventas se
enfocaría en proveedores, clientes, productos, mientras que un subsistema típico lo haría
en proceso de compras, de ventas, de inventario.
Integrada: Los datos almacenados deben integrarse en una estructura consistente. Esto
se refleja en consistencia de nomenclaturas, de variables y medidas, de estructuras y
códigos, de atributos de datos afines, etc.
Histórico: El tiempo es parte implícita de la información contenida en una bodega de
datos. A diferencia de los sistemas transaccionales, que mantienen los datos
actualizados a un instante determinado en el tiempo, una bodega de datos puede
mantener información de más de un instante. La bodega se carga con los distintos
valores que toma una variable en el tiempo y de esta manera los datos pueden ser
analizados y comparados, facilitando las labores gerenciales.
No volátil: La información de la bodega de datos existe para ser leída y no modificada,
por lo tanto, se carga una sola vez y permanece igual en adelante. De esta manera la
actualización de la bodega de datos es la incorporación de los últimos valores que
tomaron las distintas variables, sin ningún tipo de acción sobre lo que ya existía. Esto
5
está en contraste con la información de un sistema transaccional que está sujeta a
permanentes inserciones, actualizaciones, reemplazos o borrados.
1.3 PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA DE LOS
DATOS
Para obtener la bodega de datos se desarrollan en forma secuencial la extracción de los
datos, su transformación y finalmente su carga en la bodega. El proceso de extracción
consiste en la obtención de la información desde las distintas fuentes (bases de datos y
archivos operacionales) tanto internas como externas mediante herramientas de gestión
de datos.
Figura 3. Procesos de extracción, transformación o elaboración y carga. 3
A continuación es necesario transformar los datos en los requeridos para el depósito. El
proceso consiste en filtrado, limpieza, depuración, homogeneización e integración de la
información. Esto debe hacerse, ya que las bases de datos operacionales, diseñadas para
el soporte de varias aplicaciones de producción, frecuentemente difieren en el formato,
entonces, pueden tenerse los mismos elementos de datos, pero nombres y formatos y
codificaciones incoherentes. Todas estas inconsistencias deben resolverse antes de
realizar el último paso de este proceso que corresponde a la carga de los datos en la
bodega.
1.4 EXPLOTACIÓN
Es importante recordar que la Bodega de Datos no es un fin en sí misma, sino que es un
medio para solucionar una necesidad: el análisis de información y la toma de decisiones
a través de los datos de la empresa, objetivo que se logra con el proceso de explotación
de la bodega de datos.
En esta etapa es donde se desarrolla la inteligencia del Negocio y por lo tanto es un
componente esencial del data warehouse, ya que es el punto de contacto directo con el
usuario final, quien es el encargado de tomar decisiones o acciones que redundan en
beneficio de la compañía y en el ROI (Retorno de la Inversión) del Data Warehouse.
3
[12] Diseño de un prototipo de bodega de datos para un modelo de empresa de ventas y aplicación de
herramientas OLAP.
6
Las herramientas utilizadas para el desarrollo de inteligencia del negocio pueden incluir
software de consultas, generadores de reportes, procesamiento analítico en línea,
herramientas de minería de datos, etc., dependiendo de los tipos de usuarios y sus
requerimientos particulares. Sin embargo, se hace necesaria la integración de varias
herramientas puesto que una sola no satisface todos los requerimientos.
Los niveles de aplicaciones típicas en esta etapa son: Consultas e Informes, Olap,
minería de datos, Sistemas de Información Ejecutiva, y Visualización geográfica.
1.4.1 Análisis OLAP
OLAP, (On-Line Analytical Processing). El Procesamiento Analítico en Línea es la
técnica que permite ver y manipular los datos por dimensiones, proveyendo a los
gerentes y analistas fácil acceso a la información con el fin de soportar el proceso de
toma de decisión. En esta técnica de análisis, en lugar de ejecutar múltiples consultas,
los datos son estructurados para permitir un acceso rápido y fácil a las respuestas de las
preguntas que son típicamente formuladas. De esta manera, Olap, brinda flexibilidad en
la visualización de la información.
Las herramientas OLAP pueden soportar requerimientos complejos de análisis, analizar
datos desde diferentes perspectivas y soportar análisis complejos contra un volumen
determinado de datos. Su objetivo fundamental es proveer al usuario final el fácil
análisis de los datos, con la potencia y confiabilidad de una base de datos corporativa, y
con la posibilidad de ver los datos desde diversos puntos de vista o dimensiones.
Permite vistas reformateadas y calculadas sin el riesgo de perder o corromper los datos
originales y hace que la información pueda ser compartida por varios usuarios sin tener
que duplicar archivos. En muchos casos los usuarios pueden adicionar o cambiar datos
sin el riesgo de sobrescribir la información original.
El uso más común de estas herramientas en una empresa se da en el análisis de ventas y
compras de materia prima. Gracias a este análisis se evalúa la rentabilidad de productos,
capacidad de producción o la demanda. Estos aspectos dependen directamente de los
requerimientos del negocio específicos para cada empresa.
Las herramientas OLAP están dirigidas principalmente a los usuarios finales por lo que
requieren de una interfaz simple y deben tener una buena integración con los sistemas
que las alimentan.
1.4.1.1 Conceptos y componentes
1. Cubo
7
OLAP efectúa el almacenamiento lógico de los datos en arreglos ó matrices
multidimensionales denominadas cubos. El cubo contiene los datos que son de interés
para los usuarios; organiza la información dentro de dimensiones y medidas en una
estructura multidimensional para soportar las preguntas que tienen los usuarios acerca
de los datos de su compañía. Además proporcionan un mecanismo para la consulta de
datos con rapidez y con una respuesta uniforme ante diferentes cantidades de datos que
contenga el cubo o por la complejidad de una consulta.
Figura 4. Cubo tridimensional: Geografía, producto, tiempo.4
Un cubo se compone de dimensiones, jerarquías (niveles) y medidas. En el ejemplo de
la figura 4 se tiene un cubo con tres dimensiones: Geografía, Producto y Ciudad.
Además se tienen tres medidas: Unidades, Valor venta y Costo. En la celda de la parte
inferior derecha de la imagen se muestran los datos para una posible pregunta gerencial:
¿Cuántas unidades, a qué valor y con qué costo se vendieron pantalones en la ciudad de
Cali en el tiempo T4? Con su respectiva información.
2. Medida
La medida es el valor que toma determinada variable que se está analizando. Las
medidas son resultados cuantificables, o indicadores clave de desempeño usados para
determinar el éxito de una operación de negocios. Orientan las respuestas a preguntas
relacionadas con cuestiones numéricas como la cantidad, valor o costo.
4
[13] Business Intelligence
8
En el caso de la figura 4 se tienen tres medidas, indicando que se vendieron 1930
unidades, a un valor de venta de 6745 y con costo de 5831. Un cubo puede contener una
o varias medidas, dependiendo del diseño y los requerimientos. Existen dos tipos de
medidas:
Medida regular: toma su dato directamente de una fuente disponible. Es un compendio
de información que ya se tiene, tal como el número de unidades vendidas, ingresos,
gastos, niveles de inventario.
Medida calculada: obtiene como resultado un nuevo dato numérico para medidas que no
están en una fuente directa disponible. Es derivada de otras medidas. Ejemplos de este
tipo de medidas son: ganancia (ingresos – costos), margen de ganancia (ingreso – costo
/ingreso), tiempo promedio de espera ( fecha de entrega – fecha de la orden), etc.
3. Dimensión
Los atributos de tipo texto que describen cosas son organizados en dimensiones. Es
necesario establecer un criterio puramente de diseño y basado en los requerimientos del
negocio para establecer los atributos que se incluyen como dimensiones y los que se
pueden descartar al realizar la bodega de datos.
4. Nivel
Las dimensiones están construidas por niveles. Estos niveles representan la jerarquía
establecida por las estructuras organizacionales y modelos de datos que la organización
usa. Cada nivel inferior provee cada vez datos más detallados que relaciona a la
dimensión. Las herramientas especializadas para análisis OLAP permiten fijar este nivel
de granularidad en forma dinámica mientras el usuario final navega por su reporte. La
dimensión tiempo provee un claro ejemplo del uso de niveles. Se tiene el año en un
nivel superior, luego le siguen el semestre, trimestre, mes y por último en el nivel más
inferior se encuentra el día.
1.4.1.2 Operaciones con OLAP
La información que se analiza con OLAP debe estar estructurada de tal forma que se
puedan realizar las siguientes operaciones:
•
•
•
•
Drill Down y Roll Up (profundizar y escalar): Estas dos operaciones permiten
visualizar la información a un nivel detalle distinto del actual. Drill Down
permite ver un nivel mayor de detalle, es decir de lo general se va a lo particular.
Roll Up permite al usuario desplazarse entre los niveles superiores para obtener
información agregada, ver acumulados y sumarizaciones.
Alterar las filas por columnas (permutar dos dimensiones de análisis). Rotar
(Swap).
Obtener interactivamente respuestas desde diferentes perspectivas.
Realizar consultas que requieren combinación de diferentes fuentes contenidas
en el data warehouse.
9
•
•
Efectuar cálculos relativamente complejos (ranking, porcentajes, sumas, etc.)
Slice and Dice (Cortar y Rotar): Estas dos operaciones permiten navegar a través
de un cubo visualizado. La operación Slice corta el cubo para que el usuario
pueda enfocarse solamente en algunas perspectivas. La operación Dice hace que
el cubo rote para poder apreciar la información desde otra perspectiva. Por
ejemplo si se tiene un reporte que muestra el número de productos vendidos por
cada sucursal al final del último trimestre, se puede cortar y rotar la información
para mostrar los ingresos sobre los últimos dos meses por cada línea de
producto.
10
II. HERRAMIENTAS DE DATA WAREHOUSE
En el proyecto desarrollado están involucradas varias herramientas desarrolladas por
terceros, todas ellas de libre distribución. Se cuenta con herramientas de base de datos y
un servidor OLAP utilizados en el proyecto.
2. HERRAMIENTAS DE BASES DE DATOS Y OLAP
2.1 MOTOR DE BASES DE DATOS MYSQL
MySQL es el servidor de bases de datos relacionales libre más popular, desarrollado y
proporcionado por la compañía Sueca MySQL AB, que mantiene el copyright del
código fuente del servidor SQL, así como también de la marca.
MySQL AB es una empresa cuyo negocio consiste en proporcionar servicios en torno al
servidor de bases de datos MySQL. Una de las razones para el rápido crecimiento de
popularidad de MySQL, es que se trata de un producto Open Source, y por lo tanto, va
de la mano con este movimiento.
MySQL es un sistema de gestión de bases de datos relacional, licenciado bajo la GPL
de la GNU. Su diseño multihilo le permite soportar una gran carga de forma muy
eficiente. MySQL AB distribuye una versión comercial de MySQL, que no se
diferencia de la versión libre más que en el soporte técnico que se ofrece, y la
posibilidad de integrar este gestor en un software propietario, ya que de no ser así, se
vulneraría la licencia GPL.
Este gestor de bases de datos es, probablemente, el gestor más usado en el mundo del
software libre, debido a su gran rapidez y facilidad de uso. Esta gran aceptación es
debida, en parte, a que existen infinidad de librerías y otras herramientas que permiten
su uso a través de gran cantidad de lenguajes de programación, además de su fácil
instalación y configuración.
MySQL es una herramienta Open Source. Es posible descargar el software de MySQL
de Internet y usarlo sin pagar por ello. Inclusive, es posible estudiar el código fuente y
cambiarlo de acuerdo a cualquier necesidad.
MySQL usa la licencia GPL (Licencia Pública General GNU), para definir qué es lo que
se puede y no se puede hacer con el software para diferentes situaciones. Sin embargo,
11
si se quiere tener otra licencia para incorporar código de MySQL en una aplicación
comercial, es posible comprar una versión de MySQL con una licencia comercial.
2.2 MOTOR DE BASES DE DATOS POSTGRESQL
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional (ORDBMS)
basado en el proyecto POSTGRES, de la universidad de Berkeley. El director de este
proyecto es el profesor Michael Stonebraker, y fue patrocinado por Defense Advanced
Research Projects Agency (DARPA), el Army Research Office (ARO), el National
Science Foundation (NSF), y ESL, Inc.
PostgreSQL se coloca en la categoría de las bases de datos conocidas como objetorelacionales. Ha generado algunas características que son propias del mundo de las
bases de datos orientadas a objetos. Esto ha llevado a que algunas bases de datos
comerciales hayan incorporado recientemente estas ventajas en las que PostgreSQL fue
pionera.
Tomando en cuenta esas características y sumando la estabilidad, rendimiento,
disponibilidad y la eficiencia de un sistema operativo como Linux sobre el cual
comúnmente es instalada, muchas empresas e instituciones la están adoptando como
servidor de bases de datos.
PostGreSQL es un sistema objeto-relacional, ya que incluye características de la
orientación a objetos, como puede ser la herencia, tipos de datos, funciones,
restricciones, disparadores, reglas e integridad transaccional. A pesar de esto,
PostGreSQL no es un sistema de gestión de bases de datos puramente orientado a
objetos.
2.2.1 Arquitectura de la herramienta
PostgreSQL utiliza un modelo cliente/servidor. Una sesión de PostgreSQL consiste de
los siguientes procesos:
Proceso Servidor. Administra los archivos de las base de datos, acepta conexiones a las
bases de datos de aplicaciones clientes y realiza acciones sobre las bases de datos por
solicitud de los clientes.
Aplicaciones cliente. Permiten realizar operaciones sobre las bases de datos. Existen
diversos tipos de aplicaciones cliente: un cliente puede ser una herramienta basada en
texto, una herramienta gráfica, un servidor web que accede a la base de datos para sus
páginas web, o herramientas de administración de las bases de datos.
El servidor y clientes pueden estar ejecutándose en diferentes equipos, por lo tanto
PostgreSQL permite la comunicación entre estos procesos a través de conexiones
TCP/IP.
12
El servidor soporte múltiples conexiones concurrentes de clientes. Para este propósito
ejecuta nuevos procesos (forks) para cada conexión. Este proceso es transparente para
los usuarios.
2.3 HERRAMIENTA DE OLAP JPIVOT – MONDRIAN
Mondrian es el primer servidor OLAP de código abierto con la calidad necesaria para
entrar en producción. Su primera versión suficientemente madura fue Mondrian 1.0, que
fue distribuida en agosto de 2003 luego dos años de desarrollo. Esta versión contiene
mejoras en las conexiones JDBC con bases de datos, incorporación de nuevas
características y arreglo de buggs que se presentaban en las versiones Beta anteriores.
Mondrian es un servidor OLAP escrito en Java. Permite analizar grandes cantidades de
registros almacenados en bases de datos SQL. JPivot es una librería JSP que permite
realizar navegación OLAP utilizando como servidor a Mondrian.
2.3.1 Arquitectura de la herramienta
El sistema de Mondrian esta compuesto por cuatro capas muy bien definidas: la capa de
presentación, la capa de cálculo, la capa de agregación, y la capa de almacenaje.
•
Capa de presentación
Determina lo que ve el usuario final en su pantalla, y cómo él puede interactuar con
la herramienta para hacerle consultas. Hay varias formas de presentar los resultados
multidimensionales. Es posible mostrarlos con tablas, graficas de líneas, barras o
pies; además de con herramientas avanzadas de visualización como mapas y
graficas dinámicas. Estas pueden estar escritas en Swing o en graficas en formato
JPEG o GIF o trasmitidas o un aplicación remota vía XML.
•
Capa de cálculo
La capa de cálculo analiza, valida y ejecuta consultas en el lenguaje MDX (Ver
sección 2.3.4). Una consulta es evaluada en múltiples fases. Los ejes se evalúan
primero, luego los valores de las celdas relacionados con los ejes. Por eficiencia, la
capa de cálculo va enviando las repuestas ya procesadas a la capa de agregación en
paquetes para que esta comience a realizar su trabajo. La transformación de
consultas permite a la aplicación manipular los queries existentes en vez de
construir una declaración de MDX desde el principio por cada solicitud. La
metadata describe el modelo dimensional y su mapeo con el modelo relacional.
•
Capa de agregación
Una agregación es un conjunto de valores en memoria (celdas) agrupadas por
columnas dependiendo de valores de las dimensiones. La capa de cálculo envía
13
solicitudes a conjuntos de celdas. Si las celdas solicitadas no están en cache, el
administrador de agregación envía la solicitud a la capa de almacenamiento.
•
Capa del almacenamiento
Es una capa RDBMS, es responsable de proveer agregaciones de datos y atributos
de tablas de dimensión.
Estas capas pueden estar en la misma máquina o distribuidas en diferentes máquinas.
Sin embargo, las capas de cálculo y agregación deben estar en la misma máquina,
porque comprometen al servidor. La capa de almacenamiento puede estar en otra
máquina siendo accedida por una conexión JDBC.
2.3.2 Estrategias de almacenamiento y agregación
Los servidores OLAP son categorizados de acuerdo al almacenamiento de los datos:
-
El servidor MOLAP (MOLAP multidimensional) almacena todos los datos en el
disco utilizando estructuras óptimas para acceso multidimensional. Normalmente
los datos son almacenados en arreglos densos requiriendo de 4 a 8 bytes por
celda.
-
El servidor ROLAP (OLAP relacional) almacena los datos en DB relacionales.
Cada fila de la tabla de hechos tiene una columna para cada dimensión y medida. Se
requiere almacenar 3 tipos de datos: datos de la tabla de hechos (registros
transaccionales), agregaciones y dimensiones.
Las bases de datos MOLAP almacenan hechos en la tabla de hechos en formato
multidimensional pero si hay varias dimensiones los datos serán dispersos y el formato
multidimensional no tendrá un buen rendimiento. Un sistema HOLAP (OLAP hibrido)
resuelve este problema almacenando los datos de mayor granularidad en bases de datos
relacionales, y almacena las agregaciones en formato multidimensional.
Es necesario realizar agregaciones precalculadas cuando hay muchos registros para no
tener que leer todo el contenido de una tabla de hechos en ciertos queries. Comúnmente
las agregaciones MOLAP son una imagen de las estructuras de datos de memoria
divididas por páginas y almacenadas en el disco. Las agregaciones ROLAP son
almacenadas en tablas.
14
El último componente de las estrategias de agregaciones es el cache. Este almacena en
memoria agregaciones precalculadas para que futuros queries puedan acceder a valores
de celdas sin tener que leerlos del disco. El cache es la parte más importante de la
estrategia de agregación gracias a su adaptabilidad. Es difícil escoger el conjunto de
agregaciones para precalcular, las cuales aumentan la velocidad del sistema a costo de
alto espacio en disco, y en sistemas donde los datos cambian continuamente en el
tiempo no es práctico mantener agregaciones precalculadas. Un tamaño de cache
razonable permite al sistema desempeñarse adecuadamente en caso de queries no
predecibles con pocas agregaciones precalculadas.
La estrategia de agregación de Mondrian es la siguiente:
-
Los datos de la tabla de hechos son almacenados en RDBMS. ¿Porqué
desarrollar una estrategia de almacenamiento si RDBMS ya tiene una?
-
Lectura de datos de agregación en cache al utilizar queries en grupo.
-
Si el RDBMS soporta vistas materializadas y el administrador de la base de
datos elige crear vistas materializadas para agregaciones en particular, Mondrian
las utilizará implícitamente. El administrador de agregaciones de mondrian
tendrá en cuenta que estas vistas materializadas existen y por lo tanto que estas
agregaciones son fáciles de calcular.
2.3.3 API
Mondrian provee un API para que las aplicaciones cliente ejecuten queries. El lenguaje
que usa Mondrian para los queries es MDX (Multidimensional Expression) donde
JDBC utiliza SQL. El API también presenta el esquema de base de datos como un
conjunto de objetos: Esquema, cubo, dimensión, jerarquía, nivel, miembro.
Para cumplir con nuevos estándares se están agregando dos APIs a Mondrian:
JOLAP es un estándar del proceso JSR y será parte de J2EE .
XML for analysis, es un estándar para acceder a servidores OLAP vía SOAP( Simple
Object Access Protocol ). Esto permite que componentes que no están basados en java
como Microsoft Excel ejecuten quieries con Mondrian.
2.3.4 MDX
15
MDX es un lenguaje para realizar queries en bases de datos multidimensionales, de la
misma forma análoga al SQL en bases de datos relacionales. Inicialmente fue definido
como parte de la especificación de OLAP OLE DB, y un lenguaje similar, mdXML, es
parte de la especificación XML for Analysis.
Para conocer más detalles del lenguaje MDX ver anexo “Manual de Administrador”.
2.3.5 Esquema Mondrian
Un esquema define una base de datos multidimensional. Contiene un modelo lógico,
que consiste de cubos, jerarquías, atributos y un mapeo de este modelo a un modelo
físico.
El modelo lógico se compone de los constructores usados para escribir queries en
lenguaje MDX: cubos, dimensiones, jerarquías, niveles y atributos.
El modelo físico es la fuente de los datos que es representado por el modelo lógico.
Típicamente es un modelo en estrella, que es un conjunto de tablas en una base de datos
relacional.
Los esquemas de Mondrian son representados en un archivo XML. Actualmente la
única forma de crear este esquema es haciéndolo en un editor de texto, la sintaxis de
XML no es muy complicada y se está desarrollando un editor gráfico para crear y
modificar los esquemas.
2.3.6 Modelo lógico
Los componentes más importantes de un esquema son los cubos, medidas y
dimensiones:
Un cubo es una colección de dimensiones y medidas de un área en particular.
Una medida es una cantidad que se quiere medir, por ejemplo unidades vendidas de un
producto, o costos de inventario.
Una dimensión es un atributo, o conjunto de atributos en los cuales se pueden dividir
medidas en subcategorías. Por ejemplo, es posible dividir las ventas de productos por
sus colores, el género del cliente y la sucursal en donde es hecha la venta. Color, género
16
y tienda son dimensiones.
17
III. METODOLOGIA PARA EL DESARROLLO DE UN DATA WAREHOUSE
3. METODOLOGIA DE RALPH KIMBALL PARA UN PROYECTO DE DATA
WAREHOUSE
La metodología para el desarrollo del proyecto será la establecida por Ralph Kimball,
quien es autoridad en el campo de las bodegas de datos y considerado como uno de los
padres de este concepto. Kimball se ha dedicado al desarrollo de su metodología para
que este concepto sea correctamente aplicado en las organizaciones, y se asegure la
calidad de este tipo de proyectos. Durante su carrera ha innovado, escrito libros,
educado y ha sido consultor en el campo de las bodegas de datos5.
Kimball ha establecido ciertos procesos para llevar al éxito un proyecto de data
warehouse. Para su desarrollo se incluyen varias tareas que pueden ser realizadas en
paralelo o en forma secuencial.
El correcto desarrollo de cada una de las fases planteadas en esta metodología garantiza
la calidad y el correcto proceso de desarrollo.
3.1 PLANEACIÓN Y ADMINISTRACIÓN DEL PROYECTO
Definición del proyecto
Existen varios escenarios posibles en los que surge un proyecto de bodega de datos para
une empresa. Es importante identificar el escenario para determinar el alcance y
definición del proyecto. Los escenarios, originados por una demanda del proyecto en
una empresa son los siguientes:
•
•
•
5
Demanda de un sector del negocio: En este escenario, un ejecutivo del negocio
tiene el propósito de obtener mejor información con un mejor acceso para tomar
mejores decisiones.
Demasiada demanda de información: En este escenario, existen múltiples
ejecutivos del negocio buscando mejor información.
En busca de demanda. En este escenario usualmente está involucrado el
presidente de una empresa, quien no identifica necesidades de una bodega de
[14] About Kimball Group
18
datos para su negocio pero desea incorporar este sistema por razones diferentes a
requerimientos o necesidades del negocio.
Al identificar el escenario, es posible determinar si existe demanda para el proyecto y de
donde proviene esta demanda. El primer caso es el ideal, pues se tienen objetivos claros
y con un alcance determinado de lo que se quiere del proyecto. El segundo escenario es
riesgoso, pues para implementar una bodega de datos que soporte varios requerimientos
de diferentes áreas de la empresa, se necesita mucho tiempo, dinero y soporte interno de
la organización que perdure a largo plazo. En el tercer escenario se deben buscar los
requerimientos que puede implementar la solución y basar en ellos el proyecto.
En todos los escenarios es determinante contar con sponsors o patrocinadores internos
del proyecto para lograr el éxito. Sino se cuenta con un patrocinador interno de la
empresa involucrado en la demanda es preferible posponer el proyecto.
Luego de identificar el escenario es importante conocer si la empresa está lista para
realizar este proyecto.
Determinar la preparación de la empresa para un proyecto de bodega de datos
De acuerdo a Ralph Kimball existen cinco factores que deben existir en una
organización para iniciar un proyecto de bodega de datos.
•
•
•
•
•
Patrocinio de la gerencia del negocio: Al contar con este patrocinio se tiene una
visión del impacto que tendrá la bodega de datos en la empresa. Los gerentes
son líderes influyentes dentro de la organización y determinarán el apoyo y
soporte al proyecto de los de más miembros de la organización. Es preferible
tener varios patrocinadores que uno solo, en caso de cambios en la organización
o necesidad un apoyo más fuerte.
Motivación del negocio: Al implementar una bodega de datos se busca encontrar
un sentido de emergencia por parte de la organización, causado por una
motivación del negocio. Un ejemplo de motivadores son la competencia y la
visión competitiva. Otras organizaciones han encontrado el motivador en una
crisis. Un motivador importante también es un mercado potencial. Lo importante
para un proyecto de bodega de datos es alinearse con uno de estos motivadores
estratégicos del negocio.
Acompañamiento del departamento de tecnología y de negocio: El éxito de un
proyecto de bodega de datos se produce gracias a un esfuerzo de las áreas de
tecnología y de negocio, compartiendo responsabilidades.
Presencia de cultura analítica: Es importante que las decisiones de la
organización se basen en hechos, más que en simples intuiciones. Y que estas
decisiones sean determinantes y recompensadas.
Factibilidad: Es preferible que la infraestructura que soporte la bodega de datos
esté presente y sea robusta. La primera factibilidad debe ser la de los datos. Si
estos se encuentran sucios o no cumplen con estándares, el proyecto tendrá
retrasos respecto al cronograma planeado.
Desarrollo del enfoque preliminar
19
Luego de haber determinado la preparación de la organización para el proyecto, se debe
centrar el proyecto en su enfoque, y justificarlo para recibir el apoyo y presupuesto de
desarrollo. Para determinar el enfoque, se deben responder preguntas como: ¿Se busca
el enfoque y presupuesto para cubrir el levantamiento de requerimientos y diseño? ¿O
para una primera versión de la bodega? ¿O para el proyecto completo?
Para definir este enfoque la base debe ser los requerimientos del negocio, no un
cronograma. Para la definición del enfoque es importante seguir los siguientes
parámetros:
•
•
•
•
•
La definición del enfoque es responsabilidad del departamento de tecnología y
de negocio: El enfoque usualmente se establece para desarrollar requerimientos
específicos del negocio, en un tiempo determinado.
El enfoque inicial del proyecto debe ser factible y manejable: Es preferible
empezar “pequeño”. Luego continuar el proceso de forma iterativa. Lanzando
pequeños y rápidos desarrollos del proyecto.
Enfoque inicial en un solo requerimiento del negocio soportado por una sola
fuente de datos.
Limitar el número de usuarios que tendrán acceso a la bodega de datos
inicialmente.
Establecer criterios de éxito del proyecto mientras se define el enfoque: Se
refiere a entender lo que la gerencia espera del proyecto.
Una vez el área de tecnología y negocios han acordado un enfoque, este se debe
documentar.
Desarrollar la justificación del negocio
Luego de haber definido el enfoque, la justificación debe ser establecida. Esto significa
que se identifican anticipadamente los costos y beneficios asociados al proyecto. Una
forma de hacer esto es con el factor retorno de la inversión (ROI), que consiste en
comparar el retorno financiero esperado (beneficios del negocio) contra la inversión
esperada (costos).
Se deben considerar las siguientes inversiones y costos:
•
•
•
•
•
•
•
Compras de licencias de software y hardware.
Costos de mantenimiento: muchos productos de hardware y software requieren
mantenimiento.
Recursos internos de desarrollo.
Recursos externos requeridos.
Capacitación para desarrolladores y usuarios.
Soporte a usuarios.
Costos de crecimiento: Por cambios en requerimientos y actualizaciones.
Se deben considerar los siguientes retornos y beneficios:
20
Los proyectos de bodegas de datos típicamente tienen un impacto en el incremento de
ingresos y ganancias, más que en reducción de costos.
•
•
•
•
Incremento de ingresos por nuevas ventas a nuevos y antiguos clientes.
Incremento de ganancias por aumento de respuestas a la publicidad.
Incremento de niveles de servicio al cliente.
Descubrimiento de nuevas oportunidades.
Planeación del proyecto
El proyecto de bodega de datos debe tener un nombre. Luego, se identifican roles que
pueden ser cubiertos por uno o varios integrantes del equipo y cada miembro del equipo
también puede desempeñar varios roles, dependiendo de los requerimientos y del
tamaño del proyecto. Los siguientes roles se identifican para el proyecto:
• Patrocinadores de negocio.
• Gerente del proyecto: Responsable de la gerencia de tareas y actividades
cotidianas.
• Líder de negocios del proyecto: Con el gerente del proyecto monitorea el
proyecto y lo comunica a la organización. Tiene un alto entendimiento de los
requerimientos del negocio.
• Analista del sistema de negocios: Lidera las actividades de definición de
requerimientos.
• Modelador de datos: responsable del análisis de datos y el modelo dimensional.
• Administrador de bases de datos de la bodega (DBA): Responsable de
determinar agregaciones, particiones y soporte a la base de datos.
• Diseñador de proceso ETL: Responsable del diseño de la extracción,
transformación y carga de la bodega.
• Desarrolladores de aplicación al usuario.
• Educador de la bodega de datos.
Desarrollo del plan del proyecto
El objetivo de la planeación es proveer el detalle suficiente para hacer seguimiento al
progreso del proyecto. Se identifican actividades, recursos y tiempos para el desarrollo.
También permite monitorear los procesos y tener un plan de riesgos.
Administración del proyecto
Se consideran las reuniones de equipo, monitoreo del estatus, el enfoque y estrategias de
comunicación.
Para las reuniones se debe seguir una agenda y mantener un ambiente de comunicación
entre el equipo. El monitoreo se debe realizar periódicamente, analizando el estado del
proyecto en diferentes estados del tiempo.
21
3.2 ANÁLISIS DE REQUERIMIENTOS
Acercamiento a la definición de requerimientos
Para entender mejor los requerimientos se debe empezar por hablar con los usuarios del
negocio. No se debe preguntar a estos usuarios, qué datos quieren que aparezcan en el
datamart, sino hablar con ellos sobre sus trabajos, objetivos y retos e intentar conocer
cómo toman decisiones, actualmente y en el futuro.
Se debe considerar lo que requiere el negocio comparando estos requerimientos con los
datos disponibles en las bases de datos que servirán como fuente, para lograr el soporte
de estos requerimientos.
Preparación de la entrevista
Se deben determinar roles y responsabilidades en el equipo entrevistador. Es preferible
que el mismo equipo conduzca las entrevistas a usuarios del negocio y al equipo de
tecnología de la empresa.
Los roles que se deben manejar, comprenden a un líder, encargado de dirigir el
cuestionario, debe tener habilidades en el conocimiento del negocio y comunicaciones.
También debe existir un “escribano” encargado de tomar notas durante las entrevistas.
Se debe tomar el mayor detalle posible del contenido. Al finalizar las entrevistas, esta
persona debe hacer preguntas para aclarar dudas y obtener una retroalimentación de los
entrevistados.
Investigación previa a entrevistas.
Antes de iniciar el proceso de levantamiento de requerimientos, se deben analizar los
reportes anuales de la compañía, para determinar las decisiones y hechos estratégicos.
También es útil obtener planes de negocios de la compañía. También se debe analizar la
competencia de la compañía y sus principales fortalezas y debilidades. Si ha existido un
intento anterior de desarrollar una bodega de datos de la compañía, este también se debe
analizar.
Selección de los entrevistados
Se deben seleccionar personas representativas de cada área de la organización. Es
importante observar el organigrama de la compañía para determinar los candidatos a
entrevista. Los principales entrevistados deben ser los administradores ejecutivos del
negocio, para comprender la estrategia en un alto nivel de la empresa. Luego es
importante entrevistarse con los analistas del negocio de cada área quienes conocen el
manejo de información que se lleva a cabo.
Desarrollo del cuestionario
El líder de la entrevista debe desarrollar el cuestionario antes de iniciar la entrevista. Se
deben desarrollar varios cuestionarios que serán aplicados dependiendo del rol de los
entrevistados dentro de la empresa. El cuestionario debe ser de una sola página, para
evitar exceso de tiempo de entrevistas.
22
Es preferible iniciar las entrevistas en un nivel medio de jerarquía de la organización, en
vez de iniciar desde la parte superior con las altas gerencias, pues en los mandos medios
se maneja un mayor nivel de detalle respecto a los datos que sirven para luego definir la
granularidad de la bodega.
Es importante que durante la entrevista se especifique terminología, la definición exacta
de esta tendrá un gran impacto en la granularidad y dimensionalidad del modelo. Es
posible que una palabra signifique muchas cosas, por eso lo importante es identificarlas
y documentar estas inconsistencias en el vocabulario para luego confrontarlas con los
entrevistados.
Inicio y desarrollo de la entrevista
La entrevista debe iniciarse con una introducción, para recordar al usuario sobre el
proyecto y el equipo desarrollador. Los objetivos del proyecto y de la entrevista deben
ser nombrados y los miembros del equipo presentados.
Para documentar información útil se debe preguntar a los usuarios sobre sus trabajos,
por qué los hacen y cómo los hacen. Se deben realizar preguntas en un alto nivel y luego
irse al detalle para obtener respuestas cada vez más específicas.
Al entrevistar ejecutivos, el principal objetivo es obtener una visión y entender
globalmente el negocio. Al entrevistar administradores y analistas de la empresa, se
buscan los objetivos y visión de cada departamento. En el área de auditoria y
administración de datos se busca saber si existen los datos para poder dar soporte a los
requerimientos encontrados en las entrevistas previas. Se debe entender las definiciones
de los campos de las bases de datos, granularidad, volúmenes de datos, y otros detalles
de estas fuentes de información.
Al cierre de las entrevistas se debe preguntar por los criterios de éxito del proyecto, de
esta forma se entienden las actitudes y expectativas frente al proyecto. Estos criterios
deben ser medibles y cuantificables.
Análisis de las entrevistas
Si algún miembro del equipo conoce los sistemas operativos fuente de la empresa, debe
explicarlos al resto del equipo para determinar la factibilidad de implementar los
requerimientos encontrados. Se deben resaltar los descubrimientos y requerimientos
clave para el proyecto.
Se deben analizar y repasar los reportes y análisis reunidos en las entrevistas, lo cual
comúnmente conlleva a una aproximación del descubrimiento de dimensiones para el
modelo.
Para finalizar, es importante documentar los requerimientos obtenidos y comunicarlos a
los usuarios para adquirir su aprobación y compromiso.
23
3.3 MODELAMIENTO DIMENSIONAL
Modelo entidad relación
El modelo entidad relación (ER) es una técnica poderosa para diseñar lógicamente
sistemas para el procesamiento de transacciones OLTP (procesamiento transaccional en
línea). Siempre va encaminado a la eliminación de la redundancia, lo que permite que la
manipulación sobre la base de datos tenga que hacerse en un solo lugar y sea mucho
más rápido ya que en el momento en que la transacción requiera insertar, adicionar,
borrar o modificar un dato es necesario que lo haga en un solo lugar y no en múltiples.
Esto contribuye también al almacenamiento de grandes cantidades de datos dentro de
las bases de datos relacionales, a través del proceso de normalización. Por eso es
perfecto para la inserción y actualización de la información.
Este es un modelo excelente para registrar transacciones y administración de tareas
operativas. Sin embargo, para el modelamiento de una bodega de datos presenta varios
problemas. Los usuarios finales no entienden ni recuerdan un diagrama entidad relación.
Nos es posible que los usuarios finales naveguen sobre el modelo. El uso del modelo
entidad relación va en contra del objetivo principal de una bodega de datos, de
proporcionar datos de forma intuitiva y con un buen desempeño y tiempos de respuesta.
Modelo Dimensional
El modelo dimensional es una técnica de diseño lógico que busca presentar los datos de
una forma intuitiva y que proporcione acceso de alto desempeño. Cada modelo
dimensional se compone de una tabla con múltiples llaves foráneas, llamada tabla de
hechos (fact table), y un conjunto de tablas más pequeñas, llamadas tablas de
dimensión.
Los atributos de las tablas de dimensión son las fuentes de las restricciones de búsqueda
necesarias para consultar una bodega de datos. Son utilizadas como título de atributo de
las filas resultantes de queries de SQL.
Existen dos modelos dimensionales que predominan en las soluciones de bodegas de
datos: el modelo estrella y el modelo copo de nieve. En el modelo estrella, como se ve
en la figura 5 se tiene una tabla de hechos y en ella llaves foráneas a cada una de las
tablas de dimensión que tiene el modelo. Es decir, cada tabla dimensional está
directamente relacionada a la tabla de hechos.
24
Figura 5. Modelo estrella
Una dimensión es modelada de forma copo de nieve cuando los campos de baja
cardinalidad de la dimensión han sido removidos a tablas separadas y unidas a la tabla
original con llaves foráneas6 (ver figura 6). En este modelo la tabla de hechos no tendrá
llaves foráneas a todas las demás tablas como en el caso de la estrella. Las nuevas tablas
no estarán conectadas con la tabla de hechos sino con las dimensionales establecidas.
Figura 6. Modelo copo de nieve
Generalmente el copo de nieve no es recomendado en ambientes de bodegas de datos.
Este modelo será más complejo para los usuarios y la navegación por el modelo será
más lenta.
Diseño de dimensiones y hechos
En el desarrollo de una bodega o un datamart comúnmente es necesario unir datamarts.
Esto se logra creando una arquitectura de bus de datamarts. Como se utilizarán las
mismas tablas de dimensiones, es importante que las tablas de dimensiones y hechos
cumplan con las mismas especificaciones, como su granularidad. Estas dimensiones son
llamadas dimensiones conformes (conformed dimensions). Se caracterizan por cumplir
estas condiciones:
1. Una tabla de dimensión puede ser usada con cualquier tabla de hechos de la
misma base de datos.
6
[1] The Data Warehouse Toolkit
25
2. Las interfaces de usuario y contenido de datos son consistentes para cualquier
uso de la dimensión.
3. Hay una interpretación consistente de atributos, por lo tanto se obtiene la misma
interpretación de la tabla en cualquier datamart.
La granularidad es un factor que se debe tener en cuenta para el diseño de las tablas.
Una bodega de datos debe mantener sus dimensiones basadas en datos con la mayor
granularidad posible. De esta forma se facilita la expansibilidad de los datamarts para
contener nuevos atributos, ya sea en las tablas de dimensiones o en la de hechos.
Además, se permite de esta manera realizar técnicas de minería sobre la bodega, las
cuales comúnmente requieren una alta granularidad.
Figura 7. Modelo de cubo multidimensional
Al diseñar las tablas de hechos y dimensiones, la idea principal es permitir que cada
dato del negocio sea representado como un cubo. Donde las celdas del cubo contienen
valores medidos y los bordes del cubo definen las dimensiones de los datos.
Comúnmente al modelar datos de negocios se obtienen entre 4 y 15 dimensiones. En el
ejemplo de la figura 7 se modela un cubo con las dimensiones Producto, Tiempo y
Ciudad. A la derecha de la figura aparece el modelo dimensional que representa al cubo,
con las tres dimensiones unidas a la tabla de hechos.
Hechos
Los hechos son medidas de las variables que se consideran. Un hecho puede ser el valor
de una factura con sus respectivas relaciones: la factura es generada a un cliente,
correspondiente a un producto, creada en una sucursal.
Al seleccionar los hechos para el diagrama dimensional, se debe sospechar que
cualquier valor numérico, especialmente si es de tipo flotante, es probablemente un
hecho. Es de especial utilidad que cada hecho sea aditivo, para los análisis propios de la
bodega.
26
Dimensiones
Los atributos de tipo texto que describen cosas son organizados en dimensiones. Es
necesario establecer un criterio puramente de diseño y basado en los requerimientos del
negocio para establecer los atributos que se incluyen como dimensiones y los que se
pueden descartar al realizar la bodega de datos.
Los atributos dimensionales, servirán como fuente para las restricciones y encabezados
de filas en los reportes. Todos los atributos dimensionales son igualmente candidatos a
ser encabezados de filas en los reportes.
Al agregar restricciones a una búsqueda o reporte, se está haciendo un drilling down, es
decir se está estableciendo una nueva restricción en una búsqueda para obtener un
mayor nivel de detalle. Un drill down eficiente mezcla atributos de las diferentes
dimensiones, para realizar reportes realmente robustos.
Llaves subrogadas
Todas las llaves de las tablas de la bodega de datos deben ser llaves subrogadas, es decir
no deben significar nada respecto a las características de su contenido ni a su fuente en
los sistemas fuente. No se deben utilizar las llaves originales de un sistema fuente del
cual fueron extraídas. Estas llaves subrogadas se manejan como enteros.
Método de diseño de una tabla de hechos
Para el diseño de la tabla de hechos, de acuerdo a la metodología de Ralph Kimball se
deben seguir los siguientes pasos, de cada paso depende el siguiente. Se deben tomar
decisiones respecto a:
1.
2.
3.
4.
El datamart.
La granularidad de la tabla de hechos.
Las dimensiones.
Los hechos.
1. Selección del datamart.
Para un correcto desarrollo de una bodega, es preferible seleccionar e implementar
primero los datamarts que dependan de una sola fuente y luego continuar con los
que deben extraer datos de múltiples fuentes. En el caso más simple, seleccionar el
datamart es lo mismo que seleccionar la fuente legacy de datos. En casos más
complejos, se puede definir un datamart que deba incluir múltiples fuentes legacy.
2. Declaración de granularidad de la tabla de hechos.
Es necesario definir claramente lo que es un registro de la tabla de hechos en el
diseño dimensional propuesto. La granularidad es la respuesta a la pregunta ¿Qué es
un registro de la tabla de hechos?
27
La granularidad se refiere al nivel de detalle existente en las unidades de los datos
de la bodega. Entre más detalle halla, menor será el nivel de la granularidad. Entre
menos detalle halla, mayor será la granularidad. Es un factor determinante en el
desarrollo de la bodega, debido a que de ella depende el volumen de datos que será
almacenado en la bodega y el tipo de queries que pueden ser realizados7.
Figura 8. Ejemplo de granularidad en una empresa de telefonía.
Generalmente la granularidad de la tabla de hechos es seleccionada como la más
baja o granular posible. Existen varias ventajas para seleccionar este tipo de
granularidad como una transacción individual o una línea de documento. De esta
forma será mas fácil responder a nuevas consultas y agregar nuevos datos.
3. Selección de dimensiones.
Generalmente la granularidad determina unas dimensiones mínimas e iniciales. Al
agregar nuevas dimensiones los atributos de estas deben cumplir con la misma
granularidad que se ha definido. La granularidad de un dimensión no puede ser
menor que la granularidad de la tabla de hechos.
4. Selección de los hechos.
La selección de granularidad de la tabla de hechos también permite seleccionar los
hechos. En el caso de tabla de hechos de transacciones habrá un solo hecho, el monto
de la transacción. Si el caso es una tabla de hechos de snapshot puede contener diversos
resúmenes de las actividades realizadas en la toma del snapshot. Como cantidad
vendida, valor, costo.
Los hechos siempre deben ser específicos a la granularidad de la tabla de hechos.
3.4 DISEÑO TÉCNICO DE LA ARQUITECTURA
7
[11] Building the Data Warehouse
28
En los sistemas de información la definición de una arquitectura permite hacer un
desarrollo más confiable y eficiente. Con la definición de la arquitectura se mejora la
comunicación entre las diferentes áreas del proyecto, el planeamiento del proyecto, la
flexibilidad y el mantenimiento del mismo.
Aspectos de arquitectura
Para hacer el diseño de la arquitectura se debe comenzar analizando los sistemas legacy
actuales, estos deben ser consistentes y manejar de forma correcta sus transacciones,
pues en la metodología del desarrollo del DWH (Data warehouse) se toma como hecho
que estos sistemas son confiables.
Para hacer el diseño de la arquitectura se debe comenzar analizando los sistemas legacy
actuales, estos deben ser consistentes y manejar de forma correcta sus transacciones,
pues en la metodología del desarrollo del DWH se toma como hecho que estos sistemas
son confiables.
NIVEL DE
DETALLE
Auditoria para los
requerimientos del
negocio
Datos (el qué)
Back Room(el
como)
Como se hará el
proceso ETL y como
se tendrán los datos
disponibles para los
usuarios? ¿Cómo se
hace actualmente?
Modelos y
documentos de
Arquitectura
Que información se
necesita para tomar
mejores decisiones
del negocio?, ¿Cómo
se conectarán los
componentes de
datos en la
arquitectura de bus?
Modelo
dimensional:
¿Cuales son las
principales entidades
que componen esta
información y como
se relacionan?,
¿Cómo se deben
estructurar estas
entidades?
¿Que características
especificas se
necesitaran para tener
los datos en una
forma útil en los
lugares apropiados?
¿Cuáles son los
principales
almacenes de datos y
donde deben estar
localizados?
¿Que estándares y
Modelos lógicos y
físicos: ¿Cuales son productos proveen
las características
los elementos
requeridas?, ¿Cómo
individuales, sus
derivaciones y reglas se relacionaran?,
para la derivación?, ¿Cuáles son los
estándares para
¿Cuáles son los
desarrollo,
recursos y como se
administración de
mapear a los
código y nombres?
destinos?
Crear bases de datos, Escritura de
extracciones y
índices, Back up,
cargas,
documentación?.
automatización de
procesos,
documentación.
Especificaciones y
modelos
Implementación
Front Room (el
como)
¿Cuales son los
principales retos que
enfrenta el negocio?
¿Como se quieren
analizar los datos?
Infraestructura (el
donde)
¿Que niveles de
DWH y sistemas se
requieren para tener
éxito? ¿Cuales
existen actualmente?
¿Que requerirán los
usuarios para cargar
la información de una
forma útil?, ¿Qué
clases de análisis y
reportes se deben
proveer y cuales son
las prioridades?
¿Cual es el origen y
destino de los
datos,¿Se tiene
suficiente
capacidades de
procesamiento y
almacenamiento?
¿Cuales son las
especificaciones de
reportes incluyendo
filas, columnas,
secciones,
encabezados, etc..?,
¿Quién las necesita,
que tan a
menudo?,¿Cómo se
distribuirán?
Implementación del
ambiente de reporte y
análisis, Construcción
del conjunto de
reportes inicial,
entrenamiento a
usuario,
Documentación.
¿Como se interactúa
con estas
características?, ¿Qué
utilidades existen en
el sistema, API,s etc?
Instalación y pruebas
de nuevos
componentes de la
infraestructura.
Conexión de las
fuentes a los destinos
y los clientes.
Documentación
Tabla 1. Bases de la estructura de la arquitectura de Data warehouse
29
En la tabla 1 se muestran las bases para la estructura de la arquitectura de un DWH.
Entre las áreas principales se pueden destacar los datos, el área técnica y la
infraestructura. Estas áreas de la arquitectura son interceptadas por filas que nos indican
el detalle del incremento.
Definición de Columnas
Datos: El contenido del DWH son datos. Estos se refieren a todo el contenido físico del
este(DWH) que mas adelante se la hará un tratamiento para permitir ver análisis
multidimensionales y reportes útiles que apoyen la toma de decisiones. Los Datos
guardan toda la información del ambiente del DWH y de las fuentes que surten a este.
Técnica: Esta área corresponde a los procesos y a las herramientas que se aplicaran
sobre los datos. Esta área se encarga a de responder a la preguntas “Como”. Por
ejemplo ¿Cómo vamos a extraer los datos de la fuentes?, ¿Cómo los podemos organizar
de forma que podamos hacer análisis conforme a los requerimientos del negocio?, entre
otras. Esto se enfoca principalmente a las herramientas, al desarrollo del DWH y al
mantenimiento del mismo. Para garantizar un mejor funcionamiento del área técnica
estas se divide en:
• El Back Room : Es el área del DWH responsable de extraer y preparar los datos.
• El Front Room: Es el área del DWH responsable de mostrarle a los usuarios los
resultados con los datos analizados y examinados, listo para que se puedan ser
utilizados.
Infraestructura: Corresponden la las plataformas sobre las que se ejecutan los
servidores de base de datos, los servidores de aplicaciones y donde se ejecutan los
procesos. La infraestructura es la planta física del DWH, se refiere principalmente al
hardware utilizado para el desarrollo del proyecto.
Definición de los niveles de detalle (las filas).
Se comenzará desde los niveles mas altos de detalle. Parte de esa arquitectura trata de
hacer modelos y documentos de diferentes niveles de detalle, algunos cercanos y otro no
tan cercanos a la realidad.
Los mayores niveles de detalle de la arquitectura se usan para diseñar una estructura y
obtener un mejor entendimiento de los niveles de detalle mas bajos. Los modelos
detallados ayudan a tomar rápidamente las especificaciones que se deben tener en
cuenta durante el diseño y que por ningún motivo se pueden pasar por alto, pues de esta
forma no se tendría un entendimiento total del negocio.
Nivel de requerimientos del negocio: Este nivel no trata de ninguna implementación
técnica del DWH, el interés del arquitecto del proyecto se centra en entender el
comportamiento de los negocios, los procesos de la empresa y las limitaciones que
podrían ir en contra del desarrollo del DWH.
Nivel de modelos de arquitectura: Este es el primer donde se piensa en la forma de
responder a los requerimientos.
30
Un modelo de arquitectura, propone los principales componentes de una arquitectura
que se deben implantar para consecución de los requerimientos. Todas las tecnologías
de arquitectura, deben ser justificadas y deben garantizar que funcionan juntas en un
sistema. Se debe definir si los componentes técnicos se comunican unos con otros, si las
suposiciones administrativas para usar la tecnología son razonables y si la organización
tiene recursos para soportar esta tecnología.
Nivel de detalle del modelo: Hace referencia a las especificaciones funcionales de cada
componente de la arquitectura, esto debe incluir suficiente información que sirva como
guía al equipo de desarrolladores para tener una implementación mas confiable y con
menos errores. Esto también sirve en el caso que se quiera establecer un contrato legal,
pues lo establecido en el la especificación es lo mismo que se va implementar y se
puede evitar que el cliente exija mas funcionalidades cuando nunca fueron determinadas
formalmente.
El modelo dimensional y modelo físico de una fact- table corresponden la los modelo
de detalle para el área de datos.
Nivel de implementación: La implementación es realizada a partir de los detalles del
modelo, pues ahí se tiene considerado la arquitectura y detalles para llevar acabo el
desarrollo. El desarrollo del proyecto debe estar documentado.
3.5 PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA
Este proceso comprende varios aspectos determinantes para la bodega de datos. Por lo
tanto se debe seguir un plan para su correcto desarrollo. Se establecen varios pasos que
conducen al desarrollo del proceso y se describen a continuación.
Paso 1. Plan de alto nivel
El proceso de diseño se inicia con un esquema simple de los componentes del plan que
son conocidos: Las fuentes y los destinos de los datos. Se identifica de donde provienen
los datos y las características y problemas con dichas fuentes. Con este esquema es
posible comunicar la complejidad del proyecto a la gerencia y miembros del equipo de
desarrollo del proyecto.
Las aplicaciones de ETL realizan tres pasos: extracción, transformación y carga a la
bodega de datos. Estos pasos se deben ver en un esquema de alto nivel: Tomar los datos
de las fuentes, transformarlos y cargarlos en los destinos.
Paso 2. Herramientas ETL
Las extracciones típicamente se escriben en el lenguaje de la fuente de los datos.
Existen herramientas que realizan todo el proceso de extracción, transformación y carga
que buscan minimizar el tiempo requerido para estas tareas. Estas herramientas implican
31
un costo por licencias y posibles incompatibilidades o dificultades con transformaciones
complejas que fuesen requeridas para el proceso. Ya se haga el proceso con código
desarrollado, o herramientas existentes, es determinante realizar prácticas que mejoren
el rendimiento del proceso, como ordenar los datos o cargarlos de forma rápida para
cargas masivas en las bases de datos.
Paso 3. Plan detallado
El plan se inicia seleccionando la tablas en las que se va a trabajar, en cual orden y
secuenciar las transformaciones para cada conjunto de datos. Se debe graficar un
diagrama con estas estructuras.
Todas las tablas de dimensión deben ser cargadas antes que las tablas de hechos. Se
debe iniciar el desarrollo de la aplicación ETL con la dimensión más simple y continuar
con las demás hasta llegar la tabla de hechos.
Paso 4. Poblar una tabla de dimensión simple
La principal razón para iniciar el proceso con una dimensión estática y simple es la
facilidad para poblar esta tabla. A continuación se presenta información para realizar el
proceso completo de ETL relevante a cualquier tabla destino (dimensiones y hechos).
•
Extracción de una dimensión
Se deben entender las características de la fuente de datos. Si la fuente es
relevante para la dimensión destino, como se actualiza esta fuente, si hay alguna
hora en el día en la cual no se deba acceder a esta fuente, son preguntas que se
deben resolver en esta etapa.
También se deben generar reportes “de extracción”, que permitan extraer
únicamente los campos o datos requeridos de cada fuente.
Existen dos fuentes principales de datos: archivos y bases de datos. Si la fuente
se encuentra en una base de datos, se crea un solo proceso que haga fluir los
datos desde la fuente a la sección de transformación y carga. Si la fuente es un
archivo, se requieren varios pasos en el proceso: extracción al archivo, ubicación
del archivo en el servidor del proceso, transformar los datos del archivo y cargar
el archivo en la base de datos utilizada para transformar y cargar datos.
•
Transformación de una dimensión
Existen transformaciones comunes y sencillas, como el cambio de un tipo de
dato a otro, o cambiar letras minúsculas por mayúsculas, otras más complejas se
indican a continuación.
- Asignación de llaves substitutas (surrogate en inglés)
Las llaves substitutas son las llaves primarias de las tablas del modelo
dimensional, que son diferentes y no deben tener ninguna relación con
las llaves primarias de las tablas fuentes ni de los datos mismos.
Típicamente se utilizan enteros para estas llaves.
- Combinación de diferentes fuentes
32
Si un dato depende de diferentes fuentes se debe mapear el dato destino y
los datos orígenes para controlar esta transformación.
•
Carga
Para mejorar el rendimiento, la primera carga a la bodega se debe hacer con las
características de población masiva de datos del motor de base de datos del
modelo dimensional. Los principales motores de bases de datos tienen esta
característica y su uso depende del producto utilizado.
Otra forma de mejorar el rendimiento de carga es suprimir los índices en la base
de datos, que son costosos para el rendimiento de la carga, y este costo no se
recupera en mejora de rendimiento del análisis multidimensional de la bodega.
Paso 5. Implementación de la lógica del cambio de una dimensión
Al cambiar los datos de una dimensión, ya sean nuevos o actualizaciones a los datos
previos, es preferible construir la extracción de tal forma, que se extraigan únicamente
los datos que han cambiado.
Al determinar los cambios, se debe contar con reglas del negocio que determinen como
manejar estos cambios en los atributos. Si se determina que la modificación es legítima
y es posible actualizar el dato, se utiliza la técnica de una dimensión cambiante.
El primer paso para preparar la dimensión consiste en determinar si ya existe un registro
antiguo del dato. Al encontrar una modificación se aplica alguno de los siguientes tipos
de respuesta al cambio.
Tipo 1: Sobrescribir.
Se toma el nuevo dato de la fuente y se sobrescribe la tabla de la dimensión con
el nuevo contenido.
• Tipo 2: Crear un nuevo registro de la dimensión.
Se crea un nuevo registro de la dimensión con una nueva llave subrogada.
• Tipo 3: Bajar el antiguo valor.
Se crea un nuevo campo en la dimensión que contenga el antiguo valor del dato
modificado y se actualiza la dimensión con el nuevo contenido.
•
Cada tabla de dimensión usará una, dos o las tres técnicas para administrar los cambios
de datos.
Paso 6. Poblar las dimensiones restantes
Para poblar el resto de dimensiones se sigue el proceso del paso 4, y se cargan ya sea
con el uso de una herramienta de carga existente o con el desarrollo de una que soporte
conexiones ODBC o JDBC.
Paso 7. Carga histórica de hechos
33
En el proceso de ETL debe existir un paso para reemplazar las llaves primarias de las
fuentes por las llaves subrogadas que se han asignado a cada dimensión, y que deben ir
como llaves foráneas en la tabla de hechos.
Para mantener una integridad referencial en la bodega, - que significa que por cada llave
foránea en la tabla de hechos exista un registro en la dimensión correspondiente – se
realizan dos búsquedas de llaves subrogadas en el proceso de extracción. Una ocurre
cuando se utiliza la técnica 2 del paso 5, y se ha creado un nuevo registro de una
dimensión que contiene una nueva llave subrogada y un campo modificado con el resto
del contenido original. La segunda búsqueda ocurre cuando se están procesando los
registros de la tabla de hechos. En este momento se debe buscar en todas las
dimensiones los registros que coincidan con el dato que se está buscando relacionar con
la tabla de hechos, y una vez encontrado el registro de la dimensión, agregar su llave
subrogada a la llave foránea de la tabla de hechos.
Este proceso funciona bien para bodegas de datos que no manejan grandes cantidades
de registros, pues al ser grande el tamaño de datos es preferible mantener una tabla de
búsqueda que registre la llave primaria en la fuente y la llave subrogada en la
dimensión. D esta manera se mejora el rendimiento al poblar la tabla de hechos.
Una vez se cuenta con todas las llaves foráneas de la tabla de hechos, esta tabla se
empieza a cargar.
Paso 8. ETL de una tabla de hechos incremental
Al realizar cargas semanales o periódicas a la bodega desde las fuentes, es decir al
actualizar la bodega, se deben extraer y procesar únicamente las transacciones que han
ocurrido luego de la última carga.
Para seleccionar únicamente estas nuevas transacciones se pueden usar los logs de las
bases de datos, y de esta forma identificar los datos que han cambiado en el período
analizado. El log captura cada cambio que haya sido realizado a un registro. También es
posible crear losgs en las bases de datos fuentes que registren únicamente los cambios
que son importantes para la bodega, utilizando triggers.
Paso 9. Operación y automatización de la bodega de datos
Idealmente el proceso ETL de una bodega de datos se ejecuta de manera automática y
no atendida. Las operaciones típicas en la bodega son que se deben tener en cuenta en
este paso son las siguientes:
• Definición de tarea – Flujos y dependencias
• Horarios de tareas – basadas en tiempos y hechos
• Monitoreo
• Logging
• Manejo de excepciones
• Manejo de errores
• Notificaciones
34
Estas características deben ser proporcionadas para que la bodega de datos pueda ser un
sistema de producción.
Procesos automáticos:
Extracción.
Para que todo el proceso ETL sea automático, el paso de extracción debe
notificar al siguiente cuando empezar. Este proceso también debe registrar su
trabajo en una metadata, que contenga el nombre de la tarea realizada, el
usuario, la fecha, tiempo tomado para la tarea y cualquier otro hecho que quiera
ser monitoreado.
• Calidad y limpieza de datos.
En todos los sistemas se encontrarán problemas de calidad y limpieza de datos,
por lo tanto se deben establecer políticas que determinen estándares de calidad
aceptables y procedimientos a realizar cuando estos problemas se identifiquen.
•
Mejoramiento de datos.
Para garantizar el uso de los mejores datos posibles para la bodega, se deben tener en
cuenta los siguientes pasos:
- Identificar la fuente de datos con la mejor calidad: Es posible que se encuentren
varias fuentes con los mismos datos, pero en algunas se tenga mejor calidad de
los mismos.
- Identificar variaciones en palabras: Como errores de ortografía y mayúsculas y
minúsculas.
- Discutir problemas de datos con el equipo.
- Arreglar los problemas de datos en las fuentes cuando sea posible, en vez de
hacerlo en el proceso ETL o directamente a la bodega.
- No arreglar todos los problemas. Si existen muchos problemas en las fuentes,
arreglarlos en el proceso ETL irá en contra del rendimiento, estos problemas
deben ser responsabilidad de los sistemas fuentes.
- Realizar tareas de limpieza sobre los datos.
Aseguramiento de la calidad
Un vez se tienen los datos, es importante determinar si este contenido es realmente
correcto. Se pueden hacer varios procesos para determinar esto:
Cruce de datos.
Se ejecutan varios queries contra las fuentes de datos y se verifica que el
resultado de estos queries sea el mismo que el dado con los datos seleccionados
del proceso ETL
Examen manual.
Si existen varias fuentes para un mismo dato, o eventos de ese tipo, es preferible
examinar los datos manualmente y compararlos con el resultado esperado.
Validación del proceso.
Al utilizar la bodega de datos es posible encontrar diferentes resultados de los
que se harían con simples queries sobre las fuentes. Esto se da debido a la
limpieza y transformaciones hechas a los datos en el proceso ETL. Por lo tanto
35
es importante identificar las causas de las diferencias y determinar cual resultado
es realmente el correcto.
3.6 SELECCIÓN E INSTALACIÓN DE PRODUCTOS
Selección de Productos.
Una vez se tiene completa la arquitectura, se deben tener en cuenta dos componentes
fundamentales para la selección de productos:
• Requerimientos técnicos.
• Requerimientos de negocio.
Mantener el negocio enfocado
Para la selección de la herramienta se debe hacer un riguroso estudio de cada una de
ellas, mirar sus ventajas y desventajas y saber el alcance que se quiere con cada una
para saber las cosas que se pueden y nos se pueden hacer.
Otro punto importante en la escogencia de la herramienta son los requerimientos de los
usuarios: los requerimientos del negocio, mirar el análisis y el grado de procesamiento
que se puede obtener con cada una ya sea un motor de base de datos, una herramienta de
ETL o una herramienta OLAP o de reportes. También de deben mirar las limitaciones
de los usuarios en lo referente al HW, pues no tiene sentido contratar una herramienta
que consume muchos recursos cuando no se tiene la plataforma para soportarla..
Para la escogencia de las herramientas también se debe tener presente el plan del
proyecto, la arquitectura para mirar los alcances técnicos y la documentación de los
requerimientos que seguramente ayudan a la mejor opción.
El momento de la escogencia de las herramientas tiene su momento indicado durante el
desarrollo del proceso de DWH. Si se hace muy temprano no se tendrá un real
entendimiento de los requerimientos del negocio y seguramente no se hará la mejor
opción. Si espera y se hace un tiempo después tendremos mas información acerca los
requerimientos, las plataformas y se puede escoger de esta forma una mejor opción.
Áreas a evaluar para la escogencia de las herramientas
Se tienen cuatro área fundamentales para la evaluación y escogencia de las
herramientas.
•
Plataforma de hardware: Se deben avaluar las diferentes plataformas para
mirar su capacidad y escoger las herramientas teniendo esto en cuenta la
limitaciones que se podrían presentar. La plataformas de servidores donde se
ejecutarán las herramientas de análisis dimensional, la plataforma donde
tenemos los Datamart y los demás servidores de aplicaciones deben ser
analizadas cuidadosamente.
36
•
•
•
Plataformas de Base de Datos: Para proyectos pequeños se puede utilizar un
motor de BD sencillo como mysql que no se muy pesado y que podrán soportar
las plataformas. Para proyectos grandes se debe considerar un motor de BD con
mas características, que me seguridad y que me permita realizar mas y mejores
aplicaciones, por ejemplo PostgreSQL, Oracle, SQL Server, interbase, entre
otras.
Herramientas de Data Staging: Esta es el área de trabajo del DWH donde la
información se extrae de las fuentes, se le hace limpieza a los datos, se hacen las
transformaciones y se envían a los datamarts . Estas son las herramientas mas
costosas y complejas del proyecto.
Herramienta de acceso a los datos: Esta elección es difícil porque en el
marcado no existe un líder, y además se terminan usando varias de estas
herramientas por los gran variedad de requerimientos que de desea cumplir.
Cuando se usa software propietario es fácil la utilización por que se solicita soporte
técnico para que ayude en la capacitación y manejo de la herramienta y aprovechar
algunos beneficios adicionales que pueda ofrecer.
Para la escogencia de la herramienta se debe tomar un tiempo prudente , debemos
recordar que las herramientas tecnológicas cambian continuamente por eso hay que
hacer lo posible para mantenerse siempre actualizado.
Una posibilidad con el software propietario es que se puede tener acceso a versiones
trial por 90 días para tener la oportunidad de conocer el producto y decidir si
definitivamente se ajusta o no a las necesidades del proyecto.
Cuando las herramientas son SW libre se deben manejar recursos como foros on-line y
hacer contacto con otros usuarios del producto para de esta manera tener algo de soporte
técnico.
3.7 CARACTERÍSTICAS DE APLICACIONES PARA USUARIOS FINALES
En los pasos explicados anteriormente, se ha analizado el diseño e implementación;
ahora se profundizará más en el front room.
El objetivo del front room es proporcionar la interfaz que mostrará al usuario reportes y
análisis multidimensionales que tomará como base en la toma de decisiones.
Una aplicación de usuario final, provee un diseño y estructura a los reportes tomando
como base los datos del DWH.
Especificación de aplicaciones para usuario finales
Hay algunos pasos importantes en el proceso de especificación de las aplicaciones de
usuario final:
• Determinar el conjunto inicial de plantillas de reportes
• Determinar la navegación en los reportes.
• Determinar el estándar de plantillas de reportes.
• Determinar la especificación de estas plantillas.
37
Determinar el conjunto inicial de plantillas de reportes: El primer paso es tener la
lista de reportes que se va a desarrollar en la aplicación. Para esto se deben hacer 3
tareas fundamentales:
• Identificar los posibles reportes: mirando la documentación que se tiene del
proyecto, mirando los requerimientos del negocio se encuentra un gran potencial
para determinar los posibles reportes. Con esta información se hace una lista de
reportes a planificar, especificando el nombre, las filas y columnas con los
elementos de datos y las medidas. Por ejemplo, tener la lista de la información
de los departamentos que van a estar involucrados en los reportes y análisis.
•
Consolidar la lista de candidatos: Una vez se tiene la lista de reportes, de debe
categorizar dicha lista. Las categorías se reconocen rápidamente debido a la
forma como están estructuradas las compañías. Para analizar como categorizar
los reportes, se pueden tener en cuenta las siguientes preguntas: ¿Como es el
negocio?,¿Cuál es la tendencia?, entre otras.
•
Priorizar la lista de reportes: Una vez la lista de reportes se tiene establecida, se
debe definir con el usuario final para establecer prioridad en los reportes que
ellos van a utilizar.
Definir la navegación para los reportes: Se debe desarrollar un modelo que permita al
usuario encontrar la información de una manera más rápida y eficiente. Se debe crear un
modelo inicial para la navegación y poder analizar de una manera más fácil los reportes
y análisis multidimensionales.
Definir los estándares de las plantillas de reportes: En esta parte se establecen
estándares en cuanto a los elementos de la BD. Esta estandarización es muy importante
por ayuda para entender la naturaleza de los reportes. La estandarización se enfoca
principalmente a los elementos de datos del DWH que son utilizados para alimentar
los reportes.
Detalles de especificación de la plantillas de reportes: Cada organización tiene un
diferente grado de detalle en la documentación del proyecto. También se debe
determinar si el equipo que trabaja en el proyecto hace formalmente la documentación
de las aplicaciones. Si la respuesta es negativa se debe presionar para que la tenga al día
y a disposición para cualquier usuario que la quiera mirar.
•
Formato de especificación: La especificación del aplicación para el usuario final
tiene 2 partes fundamentales:
- La definición, que provee información básica acerca de la plantillas de
reportes.
- El diseño, provee una representación visual de lo que debería mostrar el
reporte.
La definición de las plantillas de reportes incluye el nombre, la descripción o
propósito, frecuencia con que debe ser actualizado, parámetros, entrada, entre
otros.
38
Tipos de aplicaciones para usuarios finales: Existen varios tipos de aplicaciones:
1. Basadas en Web: Estas aplicaciones son accedidas a través de un browserde
Internet. Los usuarios podrían conectarse y ver los reportes vía intranet o Internet
entrando a la pagina del DWH.
2. Herramienta independiente: Con la herramienta se diseñan algunas plantillas de
reportes que el usuario va a poder acceder a través de una interfaz. Esta
implementación no es muy flexible, pues en el caso que se quiera añadir reportes
sale costoso, pero de igual forma es muy rápida. Estos reportes son muchas veces
almacenados en archivos compartidos para que todas las personas la puedan
acceder.
3. Herramienta de interfaz ejecutiva: Proporciona una estructura de acceso a las
plantillas de reportes a través de una serie de screens. Estas implementaciones
permiten fácilmente la navegación en la plantilla escogida.
4. Interfaz por código: Estas herramientas proporcionan un API que permite diseñar
una interfaz. Esta es una buena posibilidad, pues se utiliza una herramienta de
desarrollo grafico y la navegación se puede ajustar mejor a las necesidades del
usuario.
3.8 MANTENIMIENTO Y CRECIMIENTO DE UN DATA WAREHOUSE
Administración del entorno de data warehouse
Cuando una empresa adquiere sus sistemas de información el cambio que tendrán estos
sistemas es muy poco, sin embargo cuando se desarrolla un proyecto de DWH se debe
pensar en el mantenimiento posterior a la implementación, pues estas aplicaciones
tienen gran tendencia a crecer a medida que crece la información de la organización.
La inversión en el mantenimiento del DWH es bastante importante, sin embargo estas
aplicaciones retornan la inversión que se les hace.
Diagnóstico de resultados incorrectos
Cuando se tienen problemas en el DWH y no se tienen los resultados esperados, se
debe revisar alguno de los pasos anteriores en el ciclo de vida. También se tiene una
serie de preguntas que en el caso de no ser positivas, hay mas razones para revisar los
pasos anteriores.
• ¿El proyecto tiene el apoyo de los altos ejecutivos de la organización?
• ¿El equipo de desarrollo del proyecto entendió correctamente los requerimientos
del usuario?
• ¿Los usuarios finales entienden el modelo dimensional o tienen que recurrir a las
complicada tablas del datamart directamente?
• ¿Para la escogencia de las herramientas análisis de datos, los usuarios finales
fueron considerados en el proceso?
• ¿Los datos utilizados para alimentar el datamart son correctos?
39
•
•
•
•
•
•
•
¿Son coherentes los reportes que se están obteniendo del DWH?, de no ser así, ¿
el equipo de desarrollo entiende la inconsistencias y tiene informado a los
usuarios finales ?
¿Los datos en el DWH se renuevan de manera oportuna?
¿La BD esta bien diseñada o las consultas tardan mucho tiempo para darnos el
resultado?
¿Tiene el DWH un equipo constante para la construcción de plantillas de
reportes que ayuden al usuario a hacer mejores análisis?
¿Los usuarios finales han recibido suficiente entrenamiento en las herramientas
generadoras de análisis multidimensionales o de reportes?
¿Conocen los usuarios del negocio a quien recurrir del equipo del DWH en el
caso que tengan problemas con este?
¿Alguien responde cuando ellos necesitan consultoría para resolver problemas?
Enfoque en usuarios del negocio
Durante las semanas posteriores a la terminación del proyecto, se debe tener en cuenta
que la cercanía del usuario debe ser esencial, pues se le debe prestar la mayor ayuda
posible para que el proyecto comience a mostrar sus resultados rápidamente. No se debe
esperar que los usuarios llamen a los miembros del equipo, los más correcto es estar con
ellos porque si los problemas duran mucho tiempo el usuario se podría sentir
decepcionado con el producto.
Administración de operaciones
Cuando el DWH hace grandes cargas, se debe tener la implementación bien robusta
para que el proceso sea completamente exitoso; se le debe hacer mantenimiento a la
infraestructura técnica, al manejo y mantenimiento de la BD y al manejo de los datos y
mata data.
•
•
•
Manejo de la infraestructura técnica: esta es una de las pocas ares donde el
DWH se parece a los sistemas operacionales de la empresa. Se debe monitorear
frecuentemente la infraestructura técnica para más adelante no tener problemas
con el DWH. Las áreas críticas donde pueden haber problemas son los
servidores de aplicaciones, los servidores de BD, entre otros.
Desempeño de la base de datos: Se pueden sacar indicadores cada vez que se
cargan datos o cuando se ejecuten rutinas que involucren esta plataforma. Con
estos indicadores se puede medir el desempeño de esta plataforma.
Mantenimiento de los datos y meta datos: Los datos en el DWH cambian
mucho, es decir por la gran cantidad de procesos y por la transacionabilidad de
las operaciones diarias, continuamente se están anexando datos al DWH y los
usuarios finales cada vez están necesitando más y más análisis de datos para
mejorar la calidad en la toma de decisiones.
El impacto de estos cambios debe analizarse de forma detenida, y determinar si
tienen algún efecto en contra de la funcionalidad de la plataforma del DWH.
40
Todos estos cambios en la plataforma se deben documentar para tener detallado
el seguimiento que se le hace y además para que todos los miembros del equipo
de desarrollo estén actualizados acerca del estado del proyecto.
41
IV. DESARROLLO DEL PROCESO DE CONSTRUCCIÓN DEL DATAMART
Para el desarrollo de la construcción del datamart se sigue la metodología estudiada de
Ralph Kimball, dado que establece claros procesos para todo el ciclo del desarrollo del
proyecto y garantiza la calidad y eficiencia de la solución de inteligencia de negocios.
Esta metodología fue desarrollada desde el inicio del proceso de construcción, hasta
llegar a las etapas de interacción con el usuario y documentación del proyecto. En las
siguientes secciones se describen los procesos realizados para cada fase del proyecto
que garantizan su calidad y cumplimiento.
4. PLANEACIÓN Y ADMINISTRACIÓN DEL PROYECTO
4.1 OBJETIVO DEL PROYECTO
Construir un datamart que soporte el análisis multidimensional de ventas de la empresa
Ubiquando, utilizando herramientas de libre distribución para mantener una solución
basada en software libre.
4.2 DEFINICIÓN DEL PROYECTO
Para el proyecto desarrollado se identificó un alto interés de la gerencia de la empresa
para el éxito de su implementación. La demanda del proyecto se encuentra en el gerente
de Ubiquando, quien identifica necesidades de obtener mejor información sobre su
negocio para tomar mejores decisiones para la empresa y así mejorar su competitividad.
Esta demanda se satisface al implantar la solución de inteligencia de negocios del
proyecto, con un datamart encargado de transformar los simples datos operativos de la
empresa en información útil de sus ventas, utilizando análisis OLAP. Toda la solución
es basada en software libre y no utiliza ningún componente comercial, tanto en las
etapas de desarrollo como en las de producción. Esto permite reducir costos y poner a
disposición la inteligencia de negocios a PYMES como Ubiquando y empresas que no
cuentan con el soporte financiero de las grandes empresas, históricamente beneficiadas
con las costosas soluciones comerciales de inteligencia de negocios.
42
4.3 ALCANCE DEL PROYECTO
El proyecto contiene todos los componentes de una bodega de datos o datamart. Como
fuentes se tienen una base de datos de contabilidad de la empresa, hecha en Mysql de
forma relacional y varios archivos de texto. Para el proceso de extracción,
transformación y carga, se desarrolló un software en java que permite realizar esta tarea
utilizando las diferentes fuentes de información. La bodega de datos, o datamart es
construida en una base de datos en PostgreSQL. Finalmente, el análisis OLAP es
realizado utilizando el servidor OLAP Mondrian. Todas estas herramientas son
soportadas por varios sistemas operativos, incluyendo Microsoft Windows y Linux.
Esto permite una gran portabilidad y la posibilidad de realizar el análisis OLAP vía
web, gracias a que el análisis OLAP se realiza utilizando un navegador de Internet.
El datamart proporciona información sobre las ventas de Ubiquando, al utilizar las
fuentes mencionadas para producir la información. Se desarrollan e implementan los
requerimientos de ventas determinados luego del levantamiento y análisis de
requerimientos que son acordados con la empresa.
4.4 JUSTIFICACIÓN DEL PROYECTO EN EL NEGOCIO
Además de ser un proyecto académico, el proyecto busca mejorar la productividad y
beneficios económicos de Ubiquando. Como justificación para el negocio se prevén los
siguientes beneficios:
Incrementar el número de negocios
Se establece que al realizar un análisis por segmentos de clientes, la empresa
realizará esfuerzos de marketing más eficientes, al enfocar determinados
productos a los candidatos de compra apropiados.
• Mejorar servicios y productos en temporadas
Se determina que se pueden mejorar las ventas de productos en temporadas de
alta demanda de los mismos, gracias al acceso a mejor información. Se pueden
realizar tácticas de promoción y realizar mejoras al proceso de fijación de
precios para aprovechar la alta demanda de las temporadas encontradas.
• Selección de los mejores clientes
Se establece que al realizar un análisis sobre las ventas de clientes y productos se
determinan preferencias y necesidades de clientes sobre determinados productos.
Se pueden ofrecer productos, que se pronostica que el cliente necesitará, dadas
sus últimas compras, u ofrecer productos que se diagnostiquen como de su
preferencia.
•
43
5. ANÁLISIS DE REQUERIMIENTOS
Para el levantamiento de requerimientos se realizaron entrevistas a personas del área
técnica y de negocio de la empresa. Los requerimientos identificados en esta etapa
(capítulo 5.1), se implementan con la herramienta OLAP Mondrian.
5.1 LEVANTAMIENTO DE REQUERIMIENTOS
Para realizar la recolección de requerimientos se realizaron entrevistas con los futuros
usuarios de la solución y también con personas del área de tecnología de la empresa.
Los requerimientos del negocio se describen a continuación.
•
•
•
•
•
•
•
•
•
•
Ver ventas por productos.
Ver ventas por cliente.
Ver ventas por tiempos.
Ver ventas de productos por cliente.
Ver ventas por productos en el tiempo.
Ver ventas por cliente en el tiempo.
Ver ventas por cliente y producto en el tiempo.
Ver ventas por ciudad en el tiempo.
Ver ventas por productos en ciudades.
Ver ventas por ciudad.
Estos requerimientos fueron los acordados a implementar con la empresa, todos ellos
soportados con datos encontrados en la base de datos con ayuda de archivos que
también funcionan como fuentes.
5.2 DOCUMENTACIÓN DE REQUERIMIENTOS
La documentación de estos requerimientos pretende presentar una descripción de cada
uno y las fuentes de donde se extraerán los datos para producir la información de la cual
cada caso es responsable. El detalle de cada fuente de datos se encuentra en el capítulo
7.
Para conocer la forma como se accede a cada reporte que implementa a cada
requerimiento desde la herramienta, ver el anexo “Manual de administrador”.
44
5.2.1 Ver ventas por productos
Descripción: Esta consulta permite explorar el valor de las ventas de Ubiquando,
discriminando estas ventas por sus líneas de productos. Al hacer drill down se exploran
las ventas por productos individuales.
Fuentes de datos: Base de datos “netcontable” y archivos planos “facturas.txt” y
“productos.txt”.
5.2.2Ver ventas por cliente
Descripción: Esta consulta permite explorar el valor de las ventas de Ubiquando,
discriminando estas ventas por sus sectores de clientes. Al hacer drill down se
exploran las ventas por clientes individuales.
Fuentes de datos: Base de datos “netcontable”, archivo plano “clientes.txt”.
5.2.3 Ver ventas por tiempos
Descripción: Esta consulta permite explorar el valor de las ventas de Ubiquando,
discriminando estas ventas por las fechas de venta. Al hacer drill down se limita más
el criterio del reporte, permitiendo analizar las ventas por año, semestre, trimestre y
día.
Fuentes de datos: Base de datos “netcontable”.
5.2.4 Ver ventas de productos por cliente
Descripción: Se muestran las ventas que se han hecho a los clientes con sus
respectivos productos.
Fuentes de datos: Base de datos “netcontable”, archivos planos “facturas.txt”,
“clientes.txt” y “productos.txt”.
5.2.5 Ver ventas por productos en el tiempo
Descripción: Se muestra el reporte que indica las ventas que se han realizado de los
productos de Ubiquando en el tiempo.
Fuentes de datos: Base de datos “netcontable” y archivo plano “facturas.txt”,
“productos.txt”.
5.2.6 Ver ventas por cliente en el tiempo
Descripción: Permite visualizar las ventas hechas a clientes en períodos de tiempos.
Fuentes de datos: Base de datos “netcontable” y archivo plano “clientes.txt”.
45
5.2.7 Ver ventas por cliente y producto en el tiempo
Descripción: Esta consulta es la más elaborada y compleja del cubo de ventas.
Comprende una unión entre todas las dimensiones del cubo para dar respuesta a una
consulta de tipo ventas por cliente y producto vendido en esa venta en cierto segmento
del tiempo. Es posible analizar las ventas de cierta línea de productos o de un
producto a un segmento de clientes o a un cliente específico en un año, semestre,
trimestre o día determinado.
Fuentes de datos: Base de datos “netcontable”, archivos planos “clientes.txt”,
“productos.txt”, “facturas.txt”.
5.2.8 Ver ventas por ciudad
Descripción: Esta consulta permite ver el valor de las ventas por ciudades en las que
Ubiquando tiene sus clientes.
Fuentes de datos: Base de datos “netcontable”.
5.2.9 Ver ventas por productos en ciudades
Descripción: Esta consulta permite ver el valor de las ventas por cada línea de
producto o productos individuales en las ciudades de venta.
Fuentes de datos: Base de datos “netcontable” y archivo plano “clientes.txt”
5.2.10 Ver ventas por ciudad en el tiempo
Descripción: Esta consulta permite ver el valor de ventas de cada ciudad en diferentes
períodos de tiempo (año, semestre, trimestre, mes o día) dependiendo del criterio del
analista.
Fuentes de datos: Base de datos “netcontable”.
46
6. MODELAMIENTO DIMENSIONAL
Para iniciar el modalamiento dimensional se debe tener en cuenta el principal objetivo
de cualquier bodega de datos o datamart: el análisis de la información. Este análisis es
realizado por medio de reportes, por lo tanto al modelar el datamart se debe tener como
objetivo la información deseada en los reportes.
Dada la definición de los requerimientos se identifican reportes de ventas que contengan
información sobre: ciudades, segmentos de clientes, clientes individuales, líneas de
productos, productos individuales y períodos del tiempo en que se realizan las ventas.
Estas categorías son dimensiones en el modelo dimensional, y la tabla en donde aparece
la medida, que es el valor de las ventas es llamada tabla de hechos. La relación de la
tabla de hechos a las tablas de dimensiones es de uno a muchos. Esto se comprende
lógicamente por el modelo del negocio, que tiene ventas en muchas ciudades, a varios
segmentos de clientes, de varias líneas de productos en diferentes períodos del tiempo.
En las siguientes secciones se detalla cada componente del modelo dimensional.
6.1 EL DATAMART
El modelo diseñado e implementado es un datamart. Este concepto se diferencia al de
bodega de datos en que el datamart busca centrarse en un objetivo único, o en el análisis
de un área específica de la empresa. En el caso de este proyecto el objetivo es analizar
las ventas únicamente. Una bodega de datos sirve a varias áreas de una empresa, y en
muchos diseños es compuesta de varios datamarts.
Sin embargo, no es posible clasificar a un datamart como una “pequeña bodega de
datos”, pues el concepto de datamart o bodega es solo de diseño. Un datamart de un área
de una gran empresa puede ser más complejo y contener un mayor número de datos que
toda una bodega de datos de una empresa de menor tamaño, o con diferentes bases de
datos.
El datamart implementado en este proyecto tiene varias fuentes de datos que poblan el
datamart: una base de datos implementada en MySQL de la contabilidad de la empresa
y varios archivos de texto que complementan la información de la base de datos. Los
detalles de estas fuentes de datos se encuentran en el capitulo 7.
6.2 DEFINICIÓN DE LA GRANULARIDAD
47
Se definió la granularidad de la tabla de hechos como la más baja o granular posible.
Esta granularidad corresponde a una venta de un producto a un cliente en una fecha
determinada, es decir una transacción individual. De esta forma será posible llegar al
grado de detalle de consultar una venta específica, aunque este no sea el objetivo de un
datamart.
La medida, que es el campo de valor de la tabla de hechos es el valor de una venta con
la granularidad establecida.
6.3 DIMENSIONES
Se definen las dimensiones que soportan los requerimientos definidos, cumpliendo con
la granularidad de la tabla de hechos. Las siguientes secciones relacionan las tablas
diseñadas para la base de datos con su dimensión correspondiente.
6.3.1 Dimensión línea
Tabla: dim_linea.
Contiene la información acerca de las líneas de productos para poder hacer una
clasificación por cada uno de estos.
Campo-Nombre
lin_idLinea
Tipo/Tamaño
Descripción
INT8
lin_descripcion Varchar(40)
Llave Primaria
Llave primaria de dim_linea
Si
Nombre de la línea (Instalación,
Desarrollo, Capacitación, Soporte,
Asesoría)
No
Tabla 2. Tabla dim_linea
6.3.2 Dimensión producto
Tabla: dim_producto
Contiene la información de los productos que ofrece la empresa.
Campo-Nombre
pro_idProducto
Tipo/Tamaño
Varchar(20)
Descripción
Llave Primaria
Llave primaria de dim_Producto
Si
pro_descripcion Varchar(100)
Nombre del Producto
No
proidLinea
Llave foránea a la tabla dim_linea,
indica a cual línea pertenece este
producto.
No
INT8
Tabla 3. dim_producto
48
6.3.3 Dimensión cliente
Tabla: dim_cliente
Contiene la información de los clientes que maneja la empresa.
Campo-Nombre Tipo/Tamaño
Descripción
INT8
cli_Nombre
Varchar(100) Nombre del Cliente
No
cliIdSector
IINT8
Llave foránea a la tabla dim_sector,
indica a cual sector pertenece este
cliente
No
Llave foránea a la tabla dim_geografia,
indica a cual ciudad pertenece este
cliente
No
cliIdGeografia Varchar(30)
Llave primaria de dim_Cliente
Llave Primaria
cli_idCliente
Si
Tabla 4. dim_cliente
6.3.4 Dimensión sector
Tabla: dim_sector
Contiene información de los sectores a los que pertenecen los clientes. Cada cliente
pertenece a un sector y a un subsector.
Campo-Nombre
sec_idSector
Tipo/Tamaño
INT8
Descripción
Llave Primaria
Llave primaria de dim_Sector
Si
sec_descripcion Varchar(40)
Nombre del sector
No
sec_subcategoria Varchar(40)
Nombre de la subcategoría
No
Tabla 5. dim_sector
6.3.5 Dimensión geografía
Tabla: dim_geografia
Contiene información sobre la ciudad a la que pertenece un cliente.
Campo-Nombre
Tipo/Tamaño
Descripción
Llave Primaria
geo_idGeografia INT8
Llave primaria de dim_geografia
Si
geo_ciudad
Ciudad a la que pertenece el cliente
No
Varchar(40)
Tabla 6. dim_geografia
49
6.3.6 Dimensión tiempo
Tabla: dim_tiempo
Contiene información de las fechas en que se realizan las ventas. Esta tabla contiene
información sobre el año, semestre, trimestre, mes y día. Se tienen estos diferentes
campos para una misma fecha para permitir al usuario navegar por la dimensión
dependiendo del grado de profundidad de fecha que prefiera.
Campo-Nombre Tipo/Tamaño
Descripción
Llave Primaria
tie_idTiempo
INT8
Llave primaria de dim_tiempo
Si
tie_dia
Varchar(30) Descripción del día en que se realizó la
venta
No
tie_mes
Varchar(30) Contiene información del mes
No
tie_trimestre
Varchar(30) Contiene información del trimestre
No
tie_semestre
Varchar(30) Contiene información del semestre
No
tie_ano
INT4
No
Contiene información del año
Tabla 7. dim_tiempo
6.4 TABLA DE HECHOS
En este datamart hay un solo hecho: el hecho de la transacción. Este hecho es el valor de
una venta; también es llamado una medida. Esta medida cumple con la granularidad
definida, es decir es el valor de una transacción individual de una venta.
Los demás campos son llaves foráneas, para relacionar esta tabla con sus dimensiones.
Tabla: fact_venta
Registra información de las ventas que hace la empresa.
Campo-Nombre Tipo/Tamaño
venIdCliente
INT8
Descripción
Id de la dim_cliente
Llave Primaria
No
venIdProducto Varchar(20) Id de la dim_Producto
No
venIdTiempo
INT8
Id de la dim_Tiempo
No
ven_valor
Float(30)
Medida que muestra el valor de la
venta que hizo a un cliente de un
producto determinado en una fecha
especifica.
No
Tabla 8. Fac._venta
50
6.5 DISEÑO DEL MODELO DIMENSIONAL
Luego de haber determinado las dimensiones y la tabla de hechos se diseña el diagrama
multidimensional implementado en la base de datos PostgreSQL. Este diagrama es un
modelo de copo de nieve, pues algunas dimensiones (producto y cliente) se tienen
asociadas otras dimensiones.
Se prefirió diseñar el modelo en copo de nieve por ofrecer una mayor claridad de diseño
y mejor organización de los datos. El concepto negativo que se tiene de este modelo por
ofrecer un menor rendimiento que el de estrella, no aplica en este caso. El número de
datos manejados por el datamart no compromete su rendimiento; además, gracias a los
bajos costos que el hardware ofrece, cada vez la desventaja del rendimiento se vuelve
más insignificante.
Figura 9. Diagrama multidimensional del datamart
Como aparece en el diagrama de la figura 9 y en el análisis de dimensiones se tienen
seis dimensiones. Para la dimensión cliente se tienen dos asociadas a ella: las
dimensiones sector y geografía. Cada una de ellas clasifica a los clientes de una manera
diferente, agrupándolos por sectores del mercado o por ciudades respectivamente. La
dimensión producto también tiene una dimensión asociada, permitiendo agrupar
productos en líneas de productos.
51
7. DISEÑO TECNICO DE LA ARQUITECTURA
7.1 DATOS
Los datos constituyen la información del DWH, se refieren al componente principal de
los procesos que llevan a la construcción de la aplicación.
Para el análisis de los datos, se comienza por analizar los datos fuentes que manejan los
procesos de la empresa, el tipo de la base de datos y la estructura de las tablas. La
empresa Ubiquando tiene actualmente un modelo E – R en sus sistemas OLTP descrito
en la figura 10. Esta base de datos se encuentra implementada en MySQL y es llamada
netcontable. En el diagrama (figura 10) únicamente se muestran las relaciones entre las
tablas de interés para el datamart (las tablas que se encuentran en negrilla) para dar
claridad al diagrama.
Figura 10. Diagrama entidad relación de la base de datos netcontable
52
Para el datamart desarrollado, se requiere la información relacionada con las ventas.
Para este caso en especial las tablas utilizadas de netcontable fueron:
•
•
•
•
TERCERO: Tiene la información referente a los clientes.
CIUDAD: Tiene la información referente a las ciudades de los clientes.
COMPROBANTE: Tiene información referente a las ventas. Relaciona
el cliente y la fecha en que es realizada una venta.
Detalle: Tiene la información de los productos relacionados con las
ventas y además el valor de la venta.
Adicionalmente tiene los siguientes archivos planos:
•
sectores.txt: maneja la información de los sectores a los que pertenecen los
clientes. Este archivo tiene la siguiente estructura y datos:
ID_Sector
•
clientes.txt: La información del cliente es manejada en la tabla tercero del
modelo E-R. Este archivo tiene la información de los sectores a los que están
asociados los clientes. La estructura del archivo es la siguiente.
ID_Cliente
•
ID_Sector
lineas.txt: tiene la información referente a las líneas a las que pertenecen los
productos. El archivo tiene la siguiente estructura:
ID_Linea
•
Nombre
Nombre
productos.txt: Este archivo tiene la información de los productos que ofrece
la empresa. La información de estos productos se almacenaba inicialmente
en la BD fuente de la empresa y se manejaba a través de los sistemas OLTP,
pero esta (Ubiquando) hizo una labor de limpieza de datos para organizar
mejor los productos que esta ofreciendo actualmente. Estos productos se
registran actualmente en un el archivo “productos.txt”. El archivo tiene la
siguiente estructura:
ID_Producto Nombre
7.1.1 Mapeo de los datos en el modelo dimensional
53
Para cargar de los datos en el modelo dimensional se requiere la información de las
tablas del modelo E-R mencionadas anteriormente, y además, para tener la información
completa se requiere de los archivos planos. En la siguiente tabla se pueden ver las
tablas del modelo dimensional y su respectiva fuente de datos.
Tablas del la Estrella
dim_geografia
dim_sector
dim_cliente
dim_linea
dim_producto
dim_tiempo
fact_venta
Fuente de datos
CIUDAD
sectores.txt
TERCERO, clientes.txt
linea.txt
producto.txt
tiempo.txt
COMPROBANTE, DETALLE,
ventas.txt
Tabla 9. Tabla con destinos y fuentes de datos
Los campos de las tablas del modelo dimensional se deben mapear de la siguiente
forma:
•
En dim_geografia:
geo_idgeografia con el campo codigo de la tabla ciudad.
geo_ciudad con el campo nombre de la tabla ciudad.
•
En dim_sector:
sec_idsector con el primer campo de los datos almacenados en el archivo
sector.txt.
sec_descripcion con el segundo campo de los datos almacenados en el archivo
sector.txt.
sec_subcategoria con el tercer campo de los datos almacenados en el archivo
sector.txt.
•
En dim_cliente :
cli_idcliente con el campo ID de la tabla tercero.
cli_nombre con el campo nombre de la tabla tercero.
cliidgeografia con el campo ciudad de la tabla tercero.
cliidsector con el segundo campo de los datos almacenados en el archivo
clientes.txt
•
dim_linea
lin_idlinea con el primer campo de los datos almacenados en el archivo lineas.txt
lin_descripcion con el segundo campo de los datos almacenados en el archivo
lineas.txt
•
dim_producto
pro_idproducto con el primer campo de los datos almacenados en el archivo
productos.txt
54
pro_descripcion con el segundo campo de los datos almacenados en el archivo
productos.txt.
proidlinea con el primer campo de los datos almacenados en el archivo
productos.txt.
•
dim_tiempo
La información se carga de un archivo que contiene registrados los días, meses,
trimestres, semestres y años correspondientes a los desde el 2004 al 2006. Este
archivo es estático pues es cargado una sola vez en la bodega y no actualiza
temporalmente como los otras tablas de la bodega.
•
fact_venta
venidcliente con el campo tercero de la tabla comprobante
venidproducto con el campo ref de la tabla detalle
venidtiempo con el campo creacion de la tabla comprobante
ven_valor con el campo valor de la tabla detalle.
En la figura 11 se resumen las fuentes y destinos de los datos que componen el datamart
de ventas de Ubiquando. Siguiendo la figura mencionada se puede tener con mayor
claridad en la forma que se realizó el proceso de extracción y carga de la bodega.
Figura 11. Diagrama de mapeo de los datos. Las tablas en negrilla indican archivos o bases de datos
fuentes, las demás son las tablas destino del modelo dimensional
55
7.2 BACK ROOM
Es el área del DWH responsable de extraer y preparar los datos. Aquí se explicará
como se realizo el proceso ETL en la bodega.
Se parte de los datos fuentes en los sistemas de información de la empresa. Una de las
políticas del datawarehousing es no modificar los sistemas de la empresa pues se
estarían alterando sus procesos de negocios y de esta forma los procesos OLTP.
Extracción: La empresa Ubiquando maneja la base de datos Mysql en sus sistemas de
información. En el proyecto se hizo una extracción de las tablas que interesan para el
desarrollo de la estrella, estas tablas fueron : tercero, comprobante, ciudad y detalle.
Además de las tablas, también se hace extracción de los archivos fuentes pues la
información que estos tienen es fundamental para la información que contendrá la
estrella.
La herramienta de ETL fue desarrollada por el grupo del proyecto. Se probaron algunas
herramientas libres de ETL y las pruebas en pilotos fueron exitosas pero al momento de
colocarlas en un ambiente de producción no se adaptaron a las necesidades del sistema
que se necesitaba implementar. Para esta herramienta se utilizaron conexiones JDBC
que me permiten seleccionar los registros y guardarlos en unas tablas temporales, esta
práctica con JDBC permite tener un mejor control de las tablas y así poder obtener solo
los campos que interesan. En los clientes, por ejemplo, solo se requiere guardar en la
temporal cliente el ID y el nombre, datos como el telefono y el email no son necesarios
en la tabla temporal.
Transformación: Para la transformación de los datos se hizo el mapeo descrito en la
sección 7.1.1. Para entender mejor la transformación se puede ver que las tablas
temporales (Figura XXXX) no tienen una estructura exactamente igual a las tablas
fuente pues solo se hizo la extracción de los datos que interesaban, de esta forma se
hicieron las transformaciones.
Carga: Luego de tener los datos transformados en las tablas temporales y los
archivos de texto listos, se hace el proceso de carga en la estrella o modelo
dimensional que consiste en tomar estos datos fuentes y guardarlos en la estrella
de tal forma que queden listos para que se puedan utilizar herramientas OLAP o
de Análisis Multidimensional. Finalmente, los datos extraídos y transformados
son cargados en la base de datos del modelo dimensional de la figura XXXXX.
7.3 FRONT ROOM
El datamart de ventas de Ubiquando está estructurado de forma que se puede ver la
información multidimensional de las ventas con respecto a los clientes, sectores de
clientes, productos, líneas de producto y en medidas de tiempo (por día, mes, trimestre,
semestre y año). Para mayor información de los reportes ver sección 10.
56
Respecto a los reportes también se puede decir que serán actualizados semanalmente,
cuando el usuario ejecute la aplicación de carga para actualizar la información contenida
en la bodega.
7.4 INFRAESTRUCTURA DE DATA WAREHOUSE
Las bases de datos y los servidores OLAP se ejecutan sobre maquinas de configuración
muy similar, por esta razón se puede ver que tanto los servidores de BD como los
servidores OLAP tiene la siguiente configuración:
Sistema Operativo: Fedora Core1.
Memoria RAM: 512 megas con capacidad para correr en maquinas de 256 megas.
Disco Duro: 60 Gb.
Procesador: Pentium 4 de 2.4Ghz.
Una plataforma con esta capacidad tiene la facultad de soportar las BD Postgresql y
MySQL, la herramienta de ETL desarrollada en JAVA y el servidor OLAP JpivotMondrian.
La BD de los sistemas de información de la empresa esta montada sobre MySQL y la
bodega en PostgreSQL.
57
8. PROCESO DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA
El proceso de extracción, transformación y carga (ETL) es el responsable de llevar a
cabo el plan de mapeo descrito en la sección 7.1.1. Para este proceso se extraen los
datos fuente que se encuentran en la base de datos netcontable descrita en la sección 7.1
y de los archivos de texto descritos en la misma sección. Se realizan las
transformaciones requeridas en cada caso y finalmente se cargan los datos en la base de
datos donde se encuentra el modelo dimensional.
8.1 HERRAMIENTA DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA
Para el proyecto se determinó la necesidad de desarrollar una herramienta de ETL
debido a la falta de soporte para las necesidades de extracción y transformación del
proyecto por parte de las herramientas disponibles en la comunidad de software libre.
La herramienta es desarrollada en java y cumple con la única función de extraer los
datos de las fuentes determinadas (sección 7.1), realizar las transformaciones requeridas
a los datos y cargar los datos al modelo dimensional implementado en PostgreSQL.
Para mantener una consistencia en las referencias, primero se procesan las dimensiones
independientes (sector, línea, geografía) que son las que poblan sus respectivas tablas de
la base de datos dimensional (dim_sector, dim_linea, dim_geografia) directamente, sin
realizar ninguna asociación a ninguna otra tabla ni transformaciones necesarias. Luego
se poblan las dimensiones producto y cliente y por último la dimensión tiempo y la tabla
de hechos. En las siguientes secciones se describe el proceso realizado para poblar cada
una de estas tablas. Para más detalles de la herramienta y su proceso realizado ver anexo
“Manual Administrador” sección 6.
8.1.1 ETL de dimensión sector
Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los
datos fuentes, encontrados en el archivo sectores.txt a la dimensión dim_sector. En este
método, lo primero que se hace es borrar de la tabla dim_sector de la bodega todo lo que
halla, para luego cargar en esa misma tabla los datos que se encuentren en el archivo
sectores.txt. Por lo tanto, si se hiciese algún cambio en el archivo de sectores, al realizar
la siguiente carga, la información del archivo sectores.txt actualizada reemplaza a la que
se había cargado previamente.
8.1.2 ETL de dimensión línea
58
Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los
datos fuentes, encontrados en el archivo lineas.txt a la dimensión dim_linea. En este
método, lo primero que se hace es borrar de la tabla dim_linea de la bodega todo lo que
halla, para luego cargar en esa misma tabla los datos que se encuentren en el archivo
lineas.txt. Por lo tanto, si se hiciese algún cambio en el archivo de líneas, al realizar la
siguiente carga, la información del archivo lineas.txt actualizada reemplaza a la que se
había cargado previamente.
8.1.3 ETL de dimensión geografía
Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los
datos fuentes, encontrados en la base de datos netcontable en la tabla ciudad. Los
campos extraídos de esta tabla son codigo y nombre. Estos campos son extraídos y
cargados a una tabla temporal llamada ciudad, encontrada en la base de datos
martVentas (nombre de la base de datos del diagrama multidimensional figura 5) de
PostgreSql. ciudad es independiente y se encuentra aislada del diagrama estrella de la
bodega. En esta tabla se realizan las transformaciones que sean necesarias, para luego
cargar los datos de esta tabla temporal a la tabla dim_geografia. Todos los datos de la
tabla dim_geografia son borrados antes de cargar los nuevos datos de la tabla temporal.
Y los datos de esta tabla temporal son borrados luego de realizar el proceso.
8.1.4 ETL de dimensión producto
Este proceso tiene como objetivo extraer, transformar y cargar los datos fuentes,
encontrados en el archivo productos.txt a la dimensión dim_producto. En este método,
lo primero que se hace es borrar de la tabla dim_producto de la bodega todo lo que
halla. Luego se leen los datos del archivo de texto y se hace la transformación para
asignarle una llave foránea a cada producto, que indique su pertenencia a una línea.
8.1.5 ETL de dimensión cliente
Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los
datos fuentes, encontrados en la base de datos netcontable en la tabla tercero y el
archivo clientes.txt. Los campos extraídos de la tabla tercero son id, nombre y ciudad.
Primero se borran todos los datos existentes en la tabla dim_cliente y luego se insertan
los datos encontrados en las fuentes. Los campos cli_idcliente, cli_nombre y cli_ciudad
de la tabla destino dim_cliente son tomados de netcontable; y el campo cli_idsector que
relaciona a un cliente con un sector, tiene como fuente el archivo clientes.txt. Son
necesarias estas dos fuentes, pues en la base de datos netcontable no se establece
correctamente le pertenencia del cliente a un sector, por lo tanto se requiere este archivo
adicional.
8.1.6 ETL tabla de hechos
59
Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los
datos fuentes a la tabla de hechos fact_venta.
Dado que durante el proceso de desarrollo del proyecto, la empresa Ubiquando realizó
un cambio en su base de datos netcontable para registrar correctamente los productos
asociados a una factura (es decir a una venta), fue necesario realizar dos procesos
distintos para la carga de esta tabla, uno antes de realizar este cambio y otro para
después de haber realizado el cambio.
Para el primer escenario, en el que los productos no están bien relacionados a cada venta
registrada en la base de datos netcontable en la tabla comprobante, se tiene el archivo
ventas.txt. Los campos extraídos de la tabla comprobante son numero, creacion,
tercero y total. Los elementos del archivo de texto son: el número de factura y el código
del producto vendido en esa factura. Para realizar el proceso ETL de esta tabla, se crea
una tabla temporal llamada comprobante en la base de datos martVentas. Esta tabla es
independiente del diagrama estrella de la bodega, solo se utiliza para hacer las
transformaciones requeridas antes de insertar los datos en la tabla fact_venta de la
bodega. En esta tabla temporal se insertan los datos extraídos de todos los registros de la
tabla comprobante de la base de datos netcontable. Luego de haber extraído los datos, se
borran todos los datos de la tabla fact_venta y se poblan con los nuevos.
Para el segundo escenario, en el que los productos sí se relacionan correctamente en la
base de datos con cada venta registrada, no se utiliza el archivo ventas.txt. En su lugar,
se utiliza la tabla detalle de la base de datos netcontable. Esta tabla contiene datos sobre
cada producto incluido en una factura y se extraen los campos: n_comp, secuencial, ref
y valor. Los campos extraídos de la tabla comprobante son numero, creación y tercero.
En este caso el campo total no es extraído de comprobante dado que el dato sobre el
valor del producto vendido se extrae del campo valor de la tabla tercero.
Para realizar el proceso ETL de esta tabla, se crea una tabla temporal llamada
comprobante y una tercero en la base de datos martVentas. Estas tablas son
independientes del diagrama estrella de la bodega; solo se utilizan para hacer las
transformaciones requeridas antes de insertar los datos en la tabla fact_venta de la
bodega. En estas tablas temporales se insertan los datos extraídos de todos los registros
de la tabla comprobante y sus tablas asociadas detalle, que hallan sido ingresados
después de la fecha en que se realizó el cambio en el registro de las ventas con
productos de la base de datos fuente netcontable. Luego de haber extraído los datos, se
borran todos los datos de la tabla fact_venta y se poblan con los nuevos. Los datos de
las tablas temporales son borrados al final del proceso de carga.
60
9. CONSTRUCCIÓN DEL CUBO
El análisis OLAP de la solución es realizado con la herramienta Mondrian (ver sección
2.3). Por lo tanto, el cubo que refleja el diseño del modelo dimensional del datamart
será construido de acuerdo a los requerimientos de Mondrian para tal fin.
Se deben crear dos archivos para utilizar un cubo en Mondrian, en las siguientes
secciones se describen las estructuras de estos archivos. Para conocer más detalles de la
creación de estos archivos, ver anexo “Manual de Administrador”.
Luego de haber establecido las estructuras de estos archivos, un usuario puede navegar
por estas estructuras (dimensiones, atributos y medidas) de forma intuitiva e interactiva,
utilizando únicamente el Mouse desde la interfaz gráfica ofrecida por Mondrian –
Jpivot.
Mondrian maneja dimensiones, niveles, categorías y medidas. Las Dimensiones
(tiempo, producto, etc.) están compuestas por niveles, que representan la jerarquía
establecida por las estructuras organizacionales y los modelos de datos de la
organización.
Estas determinan la ruta posible de drill down y drill up en la herramienta Olap,
Mondrian. Los valores que toma cada nivel son conocidos como las categorías. Las
Medidas representan los indicadores de gestión del negocio para analizar (datos
numéricos).
9.1 ARCHVIVOS JSP
El archivo JSP es utilizado para definir la ruta y una consulta inicial de un cubo
Mondrian. Las siguientes líneas de código son las líneas esenciales para establecer esta
ruta.
<%-- Archivo martVentas.jsp --%>
<jp:mondrianQuery id="query01" jdbcDriver="org.postgresql.Driver" jdbcUrl="jdbc:postgresql://localhost/martVentas"
catalogUri="/WEB-INF/queries/martVentas.xml"
jdbcUser="postgre" jdbcPassword="">
select
{[Measures].[Valor]} on columns,
{[Producto]} ON rows
from cuboVentas
Figura 12. Líneas del archivo jsp
61
La primera línea indica la ruta en donde se encuentra la base de datos dimensional que
soporta el datamart. Esta base de datos, implementada en PostgreSQL se llama
“martVentas” e implementa el modelo de copo de nieve definido en la sección 6.5.
La segunda línea indica la ruta donde se encuentra el archivo XML que define las
estructuras (ver sección 9.2) del cubo. En el caso de este proyecto, este archivo XML es
llamado “martVentas.xml”.
La tercera línea indica el nombre de usuario y contraseña del usuario que tiene acceso a
la base de datos del modelo dimensional.
Las últimas líneas definen una consulta MDX (Ver sección 2.3.4) que será la consulta
predeterminada del datamart. Esta consulta muestra el valor de ventas para el total de
productos.
9.2 ESTRUCTURAS XML
Mondrian, para entenderse con la base de datos diseñada con el modelo dimensional,
usa un archivo xml en el cual se describen las dimensiones, medidas y cubos que se
usan en el proceso de análisis multidimensional del datamart de ventas de Ubiquando.
En estas descripciones se asocian los nombres de los campos de la base de datos.
El archivo XML que define las dimensiones y la medida usados en el cubo que soporta
el datamart de Ubiquando es como sigue:
<%-- Archivo martVentas.xml --%>
<?xml version="1.0"?>
<Schema name="martVentas">
<Cube name="cuboVentas">
<Table name="fact_venta"/>
<Dimension name="Segmento" foreignKey="venidcliente">
<Hierarchy hasAll="true" primaryKeyTable="dim_cliente" primaryKey="cli_idcliente">
<Join leftKey="cliidsector" rightKey="sec_idsector">
<Table name="dim_cliente"/>
<Table name="dim_sector"/>
</Join>
<Level name="Sector" table="dim_sector" column="sec_descripcion"
uniqueMembers="true"/>
<Level name="SubCategoria" table="dim_sector" column="sec_subcategoria"
uniqueMembers="true"/>
<Level name="Cliente" table="dim_cliente" column="cli_nombre"
uniqueMembers="true"/>
</Hierarchy>
</Dimension>
<Dimension name="Ciudad" foreignKey="venidcliente">
<Hierarchy hasAll="true" primaryKeyTable="dim_cliente" primaryKey="cli_idcliente">
<Join leftKey="cliidgeografia" rightKey="geo_idgeografia">
<Table name="dim_cliente"/>
<Table name="dim_geografia"/>
</Join>
<Level name="Ciudad" table="dim_geografia" column="geo_ciudad"
uniqueMembers="true"/>
62
<Level name="Cliente" table="dim_cliente" column="cli_nombre"
uniqueMembers="true"/>
</Hierarchy>
</Dimension>
<Dimension name="Producto" foreignKey="venidproducto">
<Hierarchy hasAll="true" primaryKeyTable="dim_producto" primaryKey="pro_idproducto">
<Join leftKey="proidlinea" rightKey="lin_idlinea">
<Table name="dim_producto"/>
<Table name="dim_linea"/>
</Join>
<Level name="Linea" table="dim_linea" column="lin_descripcion"
uniqueMembers="true"/>
<Level name="Producto" table="dim_producto" column="pro_descripcion"
uniqueMembers="true"/>
</Hierarchy>
</Dimension>
<Dimension name="Tiempo" foreignKey="venidtiempo">
<Hierarchy hasAll="true" primaryKey="tie_idtiempo">
<Table name="dim_tiempo"/>
<Level name="ano" column="tie_ano" uniqueMembers="true"/>
<Level name="semestre" column="tie_semestre" uniqueMembers="true"/>
<Level name="trimestre" column="tie_trimestre" uniqueMembers="true"/>
<Level name="mes" column="tie_mes" uniqueMembers="true"/>
<Level name="dia" column="tie_dia" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
<Measure name="Valor" column="ven_valor" aggregator="sum" formatString="#,###"/>
</Cube>
</Schema>
Figura 13. Código de la estructura del cubo
Este archivo debe estar referenciado en todos los archivos jsp que contengan una
consulta MDX, que estará basada en la información de este archivo. Todas las consultas
MDX que se hacen en el datamart, se hacen sobre los datos almacenados en el cubo
descrito en el documento.
El archivo martVentas.xml une las dos partes básicas de la construcción del cubo: la
definición de dimensiones y la del cubo. Se establecen estas dos partes en la misma
estructura pues en este caso no se comparten las dimensiones con varios cubos, pues se
desarrolla únicamente el de ventas. Se emplea el esquema de “Dimensiones propias de
cubos”.
El esquema de “Dimensiones propias de cubos”, se especifica al interior de los tags
<Cube>, para hacer que solo ese cubo use cada dimensión. El cubo es definido para
soportar el diagrama dimensional. Un cubo es un conjunto de dimensiones y medidas.
Las dimensiones son la forma por la cual se quiere ver la medida, y la medida es un
valor numérico que mide un hecho objeto del análisis.
En las próximas secciones se explicará detalladamente el cubo, dimensiones y medidas
usadas en este archivo xml.
9.2.1 Estructura del cubo
63
En el proyecto y específicamente en los esquemas de Mondrian el cubo diseñado se
define como “martVentas”. Este cubo se compone de varias dimensiones y de una
medida:
Nombre del cubo: martVentas
Nombres dimensiones: segmento, ciudad, linea, producto y tiempo.
Nombre tabla de hechos (fact table): fact_venta
El cubo se basa en la tabla de hechos fact_venta. En este cubo se almacena información
sobre una venta, relacionándola con el producto, cliente y tiempo en el cual ocurre esta
venta. Además existen las dimensiones dim_sector y dim_linea que categorizan a los
clientes y los productos respectivamente.
Este cubo está diseñado para suplir una necesidad de un reporte Diario. Tiene una
granuralidad baja debido a que el registro con menor granuralidad es una sola venta a
un cliente de un solo producto.
La estrategia para poblar este cubo consiste en extraer los datos necesarios de diferentes
fuentes y cargarlos a cada dimensión como se describe en la sección 7.1.1.
9.2.2 Estructura de la dimensión Segmento
La dimensión Segmento es usada para analizar las ventas según los segmentos de
clientes de Ubiquando. Esta dimensión está asociada directamente a la dimensión
cliente, por lo tanto es un tipo de clasificación de clientes, la otra forma de clasificarlos
es por la ciudad. Esta forma se describe en la siguiente sección.
En esta dimensión se manejan tres niveles: sector, subcategoría y cliente. Por lo tanto,
se puede hacer drill down y drill up para navegar a través de los niveles y de esta forma
modificar una consulta, para restringir una búsqueda a una categoría general, una
subcategoría de esta o clientes específicos de las subcategorías.
Esta dimensión se define en el código de la siguiente forma:
<Dimension name="Segmento" foreignKey="venidcliente">
<Hierarchy hasAll="true" primaryKeyTable="dim_cliente" primaryKey="cli_idcliente">
<Join leftKey="cliidsector" rightKey="sec_idsector">
<Table name="dim_cliente"/>
<Table name="dim_sector"/>
</Join>
<Level name="Sector" table="dim_sector" column="sec_descripcion"
uniqueMembers="true"/>
<Level name="SubCategoria" table="dim_sector" column="sec_subcategoria"
uniqueMembers="true"/>
<Level name="Cliente" table="dim_cliente" column="cli_nombre"
uniqueMembers="true"/>
</Hierarchy>
</Dimension>
Figura 14. Estructura dimensión segmento
64
9.2.2 Estructura de la dimensión Ciudad
La dimensión ciudad es usada para analizar las ventas según las ciudades donde se
ubican los clientes de Ubiquando. Esta dimensión está asociada directamente a la
dimensión cliente, por lo tanto es un tipo de clasificación de clientes, la otra forma de
clasificarlos es por el segmento. Esta otra forma se describe en la siguiente anterior.
En esta dimensión se manejan dos niveles: ciudad y cliente. Por lo tanto, se puede hacer
drill down y drill up para navegar a través de los niveles y de esta forma modificar una
consulta, para restringir una búsqueda a una ciudad general o clientes específicos de las
ciudades.
Está definida de la siguiente forma:
<Dimension name="Ciudad" foreignKey="venidcliente">
<Hierarchy hasAll="true" primaryKeyTable="dim_cliente" primaryKey="cli_idcliente">
<Join leftKey="cliidgeografia" rightKey="geo_idgeografia">
<Table name="dim_cliente"/>
<Table name="dim_geografia"/>
</Join>
<Level name="Ciudad" table="dim_geografia" column="geo_ciudad"
uniqueMembers="true"/>
<Level name="Cliente" table="dim_cliente" column="cli_nombre"
uniqueMembers="true"/>
</Hierarchy>
</Dimension>
Figura 15. Estructura dimensión ciudad
9.2.3 Estructura de la dimensión Producto
La dimensión producto permite analizar las ventas por producto. Debido a que
Ubiquando tiene muchos productos, se tiene otro nivel llamado “dim_linea” que
clasifica los productos en líneas de productos.
En esta dimensión se manejan dos niveles: línea, y producto. Por lo tanto, se puede
hacer drill down y drill up para navegar a través de los niveles y de esta forma modificar
una consulta, para restringir una búsqueda a una línea general, o productos específicos
de cada línea.
Está definida de la siguiente forma:
<Dimension name="dim_producto" foreignKey="venidproducto">
<Hierarchy hasAll="true" primaryKeyTable="dim_producto" primaryKey="pro_idproducto">
<Join leftKey="proidlinea" rightKey="lin_idlinea">
<Table name="dim_producto"/>
<Table name="dim_linea"/>
</Join>
<Level name="Linea" table="dim_linea" column="lin_descripcion"
uniqueMembers="true"/>
<Level name="Producto" table="dim_producto" column="pro_descripcion"
uniqueMembers="true"/>
</Hierarchy>
</Dimension>
Figura 16. Estructura dimensión producto
65
9.2.4 Estructura de la dimensión tiempo
La dimensión tiempo es la dimensión más importante de todas las dimensiones en
cualquier proceso de análisis multidimensional. Es decir, todos los analistas por lo
general desean ver su información discriminada por meses, semanas días, o años. Es por
esto que esta dimensión contiene toda la información referente al tiempo. Es decir, un
día determinado a que mes, trimestre, semestre y año pertenece, para poder ser
agrupado por estos niveles.
Tiene cuarto niveles por los que se puede hacer drill down y drill up que son año,
semestre, trimestre, mes y día.
Esta definida de la siguiente forma:
<Dimension name="dim_tiempo" foreignKey="venidtiempo">
<Hierarchy hasAll="true" primaryKey="tie_idtiempo">
<Table name="dim_tiempo"/>
<Level name="ano" column="tie_ano" uniqueMembers="true"/>
<Level name="semestre" column="tie_semestre" uniqueMembers="true"/>
<Level name="trimestre" column="tie_trimestre" uniqueMembers="true"/>
<Level name="mes" column="tie_mes" uniqueMembers="true"/>
<Level name="dia" column="tie_dia" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
Figura 17. Estructura dimensión tiempo
66
10. REPORTES IMPLEMENTADOS
Los reportes implementados cumplen con los requerimientos planteados en el capítulo 5
acordados con Ubiquando. Su implementación está hecha sobre Mondrian, y con el uso
de su interfaz gráfica es posible ver estos reportes y analizar la información con tablas
de datos o gráficas de diversos tipos (barras, pies, líneas, etc).
Para este análisis de información se dan diferentes posibilidades de navegación, como el
drill up y drill down. Además es posible analizar solo algunas dimensiones, o incluir a
varias para un reporte. También es posible restringir en un análisis a determinados
miembros de una dimensión que sean del interés del análisis, en vez de incluir a todos.
Para conocer más detalles de la forma de utilizar el análisis OLAP Mondrian ver anexo
“Manual de administrador”.
En las siguientes secciones se documentan estos reportes en forma gráfica, aunque en la
herramienta también se muestra la tabla de resultados de los datos. Se incluye también
el query MDX necesario para realizar los reportes. Es importante notar que no es
necesario escribir un query MDX para navegar por el cubo OLAP. Esta navegación
puede ser hecha de forma sencilla e interactiva con el usuario usando solo el mouse,
seleccionando las opciones que se quieren (ver anexo Manual de administrador).
Además de los reportes acordados con Ubiquando es posible realizar muchos más,
haciendo uso de las características de Mondrian y de las dimensiones implementadas.
Se mostrará un solo reporte por página para dar claridad al documento.
67
10.1 VENTAS POR PRODUCTOS
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY {[Measures].[Valor]} ON columns,
NON EMPTY Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All
Productos].Children)) ON rows
from [cuboVentas]
Figura 18. Consulta MDX Ventas por productos
Figura 19. Resultados gráficos del reporte Ventas por productos
Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas
ventas por sus líneas de productos. Al hacer drill down se exploran las ventas por
productos individuales. En esta consulta la medida es el valor de la venta en la columna
y los productos en las filas.
68
10.2 VENTAS POR CLIENTE
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY {[Measures].[Valor]} ON columns,
NON EMPTY Hierarchize(Union({[Segmento].[All Segmentos]}, [Segmento].[All
Segmentos].Children)) ON rows
from [cuboVentas]
Figura 20. Consulta MDX Ventas por cliente
Figura 21. Resultados gráficos del reporte Ventas por cliente
Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas
ventas por sus sectores de clientes. Al hacer drill down se exploran las ventas por
clientes individuales. En esta consulta la medida es el valor de la venta en la columna y
los clientes en las filas.
69
10.3 VENTAS POR TIEMPOS
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY {[Measures].[Valor]} ON columns,
NON EMPTY {[Tiempo].[All Tiempos]} ON rows
from [cuboVentas]
Figura 22. Consulta MDX Ventas por tiempos
Figura 23. Resultados gráficos del reporte Ventas por tiempos
Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas
ventas por las fechas de venta. Al hacer drill down se limita más el criterio del reporte,
permitiendo analizar las ventas por año, semestre, trimestre y día. En esta consulta la
medida es el valor de la venta en la columna y los tiempos en las filas.
70
10.4 VENTAS DE PRODUCTOS POR CLIENTE
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY Crossjoin(Hierarchize(Union({[Producto].[All Productos]},
[Producto].[All Productos].Children)), {[Measures].[Valor]}) ON columns,
NON EMPTY Hierarchize(Union({[Segmento].[All Segmentos]}, [Segmento].[All
Segmentos].Children)) ON rows
from [cuboVentas]
Figura 24. Consulta MDX Ventas de productos por cliente
Figura 25. Resultados gráficos del reporte Ventas de productos por cliente
Se Compara el cruce de la dimensión Producto y la dimensión Cliente (con medida
valor, las medidas en mondrian son vistas como una dimensión aparte, que se llama
[Measures]).
71
10.5 VENTAS POR PRODUCTOS EN EL TIEMPO
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY {([Tiempo].[All Tiempos], [Measures].[Valor])} ON
columns,
NON EMPTY Hierarchize(Union({[Producto].[All Productos]},
[Producto].[All Productos].Children)) ON rows
from [cuboVentas]
Figura 26. Consulta MDX Ventas por productos en el tiempo
Figura 27. Resultados gráficos del reporte Ventas por productos en el tiempo
Con esta consulta que utiliza las propiedades “children” y “Crossjoin” descritas en el
numeral 1.4, se permite analizar las ventas de las líneas de producto y los productos
específicamente en los tiempos requeridos por el usuario. Es posible analizar a todos los
productos en el tiempo que varía en año, semestre, trimestre y día. También se explora
el interior de cada línea de producto o por producto individual en estas secciones de
tiempo.
Esta consulta se compone del valor en la columna y de las dimensiones producto y
tiempo en las filas.
72
10.6 VENTAS POR CLIENTE EN EL TIEMPO
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY {([Tiempo].[All Tiempos], [Measures].[Valor])} ON columns,
NON EMPTY Hierarchize(Union({[Segmento].[All Segmentos]}, [Segmento].[All
Segmentos].Children)) ON rows
from [cuboVentas]
Figura 28. Consulta MDX Ventas por cliente en el tiempo
Figura 29. Resultados gráficos del reporte Ventas por cliente en el tiempo
Con esta consulta que utiliza las propiedades se permite analizar las ventas a los
segmentos de cliente y los clientes específicamente en los tiempos requeridos por el
usuario. Es posible analizar las ventas a todos los clientes en el tiempo que varía en año,
semestre, trimestre y día. También se explora el interior de cada segmento de cliente o
por cliente individual en estas secciones de tiempo.
Esta consulta contiene el valor en la columna y la dimensión cliente y tiempo en las
filas.
73
10.7 VENTAS POR CLIENTE Y PRODUCTO EN EL TIEMPO
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY {([Tiempo].[All Tiempos], [Measures].[Valor])} ON columns,
NON EMPTY Hierarchize(Crossjoin({[Producto].[All Productos]}, Union({[Segmento].[All Segmentos]}, [Segmento].[All
Segmentos].Children))) ON rows
from [cuboVentas]
Figura 30. Consulta MDX Ventas por cliente y producto en el tiempo
Figura 31. Resultados gráficos del reporte Ventas por cliente y producto en el tiempo
La consulta comprende una unión entre las dimensiones sector, producto y tiempo del
cubo para dar respuesta a una consulta de tipo ventas por cliente y producto vendido en
esa venta en cierto segmento del tiempo. Es posible analizar las ventas de cierta línea de
productos o de un producto a un segmento de clientes o a un cliente específico en un
año, semestre, trimestre o día determinado.
Esta consulta se compone de las dimensiones producto y cliente en las filas y tiempo y
valor en las columnas.
74
10.8 VENTAS POR CIUDAD
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY {[Measures].[Valor]} ON columns,
NON EMPTY {[Ciudad].[All Ciudads]} ON rows
from [cuboVentas]
Figura 32. Consulta MDX Ventas por ciudad
Figura 33. Resultados gráficos del reporte Ventas por ciudad
Esta consulta permite ver el valor de las ventas en las diferentes ciudades donde
Ubiquando tiene clientes.
Esta consulta se compone de las dimensiones geografía en las filas y valor en las
columnas.
75
10.9 VENTAS POR PRODUCTOS EN CIUDADES
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY Crossjoin(Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All Productos].Children)),
{[Measures].[Valor]}) ON columns,
NON EMPTY Hierarchize(Union({[Ciudad].[All Ciudads]}, [Ciudad].[All Ciudads].Children)) ON rows
from [cuboVentas]
Figura 34. Consulta MDX Ventas por productos en ciudades
Figura 35. Resultados gráficos del reporte Ventas por productos en ciudades
Esta consulta permite ver el valor de las ventas correspondiente a cada línea de producto
o a cada producto individual (al hacer drill down) por cada ciudad.
Esta consulta se compone de las dimensiones geografía en las filas y producto y valor
en las columnas.
76
10.10 VENTAS POR CIUDAD EN EL TIEMPO
La consulta MDX que soporta este reporte es la siguiente:
select NON EMPTY Crossjoin(Hierarchize(Union({[Tiempo].[All Tiempos]}, [Tiempo].[All Tiempos].Children)),
{[Measures].[Valor]}) ON columns,
NON EMPTY Hierarchize(Union({[Ciudad].[All Ciudads]}, [Ciudad].[All Ciudads].Children)) ON rows
from [cuboVentas]
Figura 36. Consulta MDX Ventas por ciudad en el tiempo
Figura 37. Resultados gráficos del reporte Ventas por ciudad en el tiempo
Esta consulta permite ver el valor de las ventas en las ciudades en los diferentes
instantes de tiempo.
Esta consulta se compone de las dimensiones geografía en las filas y tiempo y valor en
las columnas.
77
9. MANTENIMIENTO Y CRECIMIENTO DEL DATAMART
Luego de pasar exitosamente la etapa de pruebas de todo proyecto de software y ser
aceptado por el cliente final, el DWH está actualmente en producción. Los directivos de
la empresa lo recibieron con mucho entusiasmo y satisfacción. Tanto ellos como el
grupo del desarrollo del proyecto están convencidos de haber hecho un producto de
excelente calidad, pues se rigió por una metodología especializada para la materia, que
siguiéndose con prudencia iba a garantizar el éxito del proyecto.
También se realizó una capacitación en el uso del producto, confirmando la aceptación
y acogida que tuvo el proyecto. Esta capacitación fue rápida, pues Jpivot-Mondrian es
muy fácil y orientada al usuario, característica fundamental que permitió facilitar el
trabajo.
En cuanto al mantenimiento y crecimiento de la bodega, se puede decir que se harán
actualizaciones semanales, condición impuesta por los ejecutivos de la empresa, para
mantener datos al día y disponibles para cualquier momento que se necesiten. En
cuanto al crecimiento, la tabla que crecería con mayor incremento es la tabla de
fact_venta de la bodega de datos. No existe ningún riesgo que estos datos se pierdan
o entren en conflicto en la aplicación, la base de datos PostgreSQL garantiza que
soporta la cantidad de información que puede ser generada por la empresa en los
negocios que se enfrentaran mas adelante.
78
CONCLUSIONES
•
El data warehouse es mucho más que un producto. Es una serie de productos
relacionados entre sí que por medio de procesos bien definidos producen
información útil para los usuarios. Para que una solución de este tipo realmente
tenga éxito, los usuarios deben aprovechar esta información y ejecutar
decisiones y acciones basadas en el conocimiento adquirido.
•
Para que un proyecto de data warehousing tenga éxito es necesario que exista
una cultura de información en la organización. Si las decisiones son tomadas
basadas en intuiciones y suposiciones y no hay disposición al cambio, un
proyecto de data warehouse está destinado a fracasar en la organización.
•
El desarrollo óptimo del proceso de implementación del data warehouse se
encuentra estrechamente relacionado con la existencia de patrocinadores dentro
de la organización. Si no se cuenta con patrocinadores en el área del negocio y
en el área técnica es preferible posponer un proyecto.
•
Es esencial el manejo de roles en el equipo de desarrollo de un proyecto de data
warehouse, de esta manera hay fluidez y especialización en los miembros del
equipo que implica una mayor eficiencia y calidad del trabajo.
•
El proceso con más dificultades en un proyecto de data warehouse es el de
recolección de requerimientos y análisis de los sistemas fuente. En las empresas
existe un alto volumen de inconsistencias en los datos y falta de documentación
de sus sistemas de información.
•
Un datamart permite servir a un área del negocio como lo haría una bodega a
varias áreas. La especialización del datamart tiene un enfoque hacia la necesidad
de un área específica, que facilita la definición de la granularidad de los datos
utilizados y sus dimensiones.
•
El uso de software libre en inteligencia de negocios tiene la ventaja de ser
desarrollado a la medida de las necesidades de una organización. Por lo tanto
ofrece un análisis más personalizado y con menores restricciones que el llevado
a cabo con herramientas comerciales, a las cuales se debe ajustar el negocio.
Con el software libre, la solución es la que se ajusta al negocio.
•
Dada la madurez y fortaleza de las herramientas libres utilizadas en este
proyecto, se llega a competir en iguales condiciones en términos de
funcionalidad, rendimiento y fortaleza con las herramientas comerciales
tradicionales del data warehousing.
79
•
Aunque existe una documentación limitada de las herramientas de software
libre, existen foros mundiales sobre estas herramientas compuestos por personas
de la comunidad libre, que dan soporte efectivo a desarrolladores y usuarios de
estas herramientas.
•
La estructura de una base de datos de inteligencia de negocios es esencial para el
éxito de un proyecto de este tipo. Aunque la estructura de entidad – relación
funciona correctamente para almacenar datos operativos, es totalmente impropia
para estas soluciones. Se debe seleccionar ya sea un modelo en estrella o copo
de nieve para un data warehouse dependiendo de las necesidades del negocio.
Este modelo es utilizado dado que refleja las necesidades de un negocio en
términos de soporte a toma de decisiones.
•
El análisis OLAP es adecuado para el análisis de una bodega de datos, dado que
permite relacionar a una o varias medidas con atributos vistos como
dimensiones, analizando los aspectos importantes y determinantes para el éxito
de un negocio.
•
El análisis OLAP realizado con Mondrian es similar al realizado con
herramientas comerciales del mismo tipo, ofreciendo la misma funcionalidad y
rendimiento. Aunque la construcción y definición de dimensiones y cubos
requiere conocimientos técnicos más avanzados que con las otras herramientas,
una vez implementados, la facilidad de uso para el usuario es evidente.
•
Más que una solución para reducir costos, el data warehouse debe ser visto
como una solución para incrementar ingresos y ventas. Sus resultados se
perciben como beneficios económicos para una empresa en términos de mediano
y largo plazo.
•
Dada la proximidad del tratado de libre comercio, negociado actualmente por
Colombia, es necesario el uso de la inteligencia de negocios para aprovechar
nuevos mercados y fortalecer la posición ocupada en el mercado actual por las
empresas colombianas. El uso de estas herramientas mejorará la competitividad
de las empresas y las hará más eficientes.
•
Las pymes, tradicionalmente alejadas de soluciones tecnológicas por sus altos
costos, se acercan cada vez más a una competencia “de igual a igual” con
grandes empresas “inteligentes”, dada la disminución de costos en hardware y a
la implantación de soluciones de software libre como la de este proyecto.
•
El presupuesto de las empresas para su área tecnológica se encuentra en
crecimiento cada año, por lo que existe un mercado potencial para soluciones de
inteligencia de negocios.
80
RECOMENDACIONES
•
En un proyecto de data warehouse se deben confrontar los requerimientos del
negocio con el área técnica, para determinar si existen las fuentes de datos para
dar soporte a los requerimientos planteados. De esta forma no ofrecer reportes
imposibles de cumplir en el proyecto.
•
Un data warehouse es tan confiable como sus datos fuentes. Por lo tanto, se
debe determinar la confiabilidad y disponibilidad de estos datos, y si existe un
mismo dato en diversas fuentes, extraerlo de la fuente que sea más confiable.
•
Al iniciar un proyecto de data warehouse se deben identificar y mantener
sponsors del proyecto al interior de la organización. Si no se identifican, es
mejor posponerlo o buscar el apoyo.
•
Se deben identificar justificadores del negocio al iniciar un proyecto de data
warehouse, esto es justificar el proyecto desde un punto de vista financiero con
un retorno sobre la inversión. De esta manera aumentará el entusiasmo hacia el
proyecto de la organización.
•
En Colombia hay miles de pymes, todas ellas son un cliente potencial para esta
solución. Por lo tanto se deben aprovechar sus necesidades de información y el
bajo costo de esta solución para cubrir este mercado.
81
GLOSARIO
DWH: Por el inglés Data warehouse. Es una bodega de datos.
Datamart: subconjunto especializado de una bodega de datos. Los diferentes datamarts
contienen diferentes combinaciones y selección de los mismos datos detallados
identificados en la bodega de datos, por esto puede decirse que los datamarts vienen a
ser como una extensión natural de la bodega de datos.
JDBC: Java Database Connectivity, API de Java que permite hacer conexiones a bases
de datos para manipular la información que están contienen.
Metadata: Información sobre los datos almacenados en la bodega de datos, permite
conocer las fuentes de donde es extraído y reglas de negocio.
OLAP: ON LINE ANALYTICAL PROCESSING, tecnología que permite a los
usuarios tener una visión de los datos de una forma rápida, interactiva y fácil de usar.
OLTP: ON LINE TRANSACTIONAL PROCESSING, las aplicaciones de OLTP están
organizadas para ejecutar las transacciones para los cuales fueron hechos, como por
ejemplo: mover dinero entre cuentas, un cargo o abono, una devolución de inventario,
etc. Por otro lado, una bodega de datos está organizada en base a conceptos, como por
ejemplo: clientes, facturas, productos, etc.
Query: Consultas sobre una base de datos o sobre una bodega de datos. Permiten
manipular la información de las bases de datos y las bodegas.
RDBMS: Manejador de bases de datos relacional. Constituyen la base para los sistemas
OLTP.
Sistemas Legacy: Sistemas fuente de la empresa con los que manejan la operación de
las transacciones diarias. Su característica principal es el enfoque en los procesos de
operación diaria de la empresa.
82
BIBLIOGRAFÍA
[1] Ralph Kimball, 1996. The Data Warehouse Toolkit. Wiley.
[2] Ralph Kimball, 1998. The Data Warehous Lifecycle Toolkit. Wiley.
[3] Barry Devlin, 1997. Data Warehouse from architecture to implementation.
Addison Wesley.
[4] IBM Learning Services, 2002. Fundamentals of Data Warehouse and Business
Intelligence for Knowledge Management. IBM Global Services Group.
[5] Richard Connelly, Robin McNeill, Roland
Multidimensional Manager. Cognos Incorporated.
Mosimann,
1997.
The
[6] Corinne Baragoin, Jorge Bercianos, Janez Komel, Gary Robinson, Richard
Sawa, Erik Schuinder, 2001. OLAP Server Theory and Practices. IBM Red
Books.
[7] IBM Learning Services. Business Intelligence Tutorial. IBM Corporation.
[8] Jiawei Han, Micheline Kamber, 2001. Data Mining: Concepts and Techniques.
Morgan Kaufmann Publishers.
[9] Julian Hyde, Paul Dymecki, Sean McCullough, Andreas Voss, 2003. What is
Mondrian? (online). Mondrian Project.
http://mondrian.sourceforge.net/.
[10]
PostgreSQL Global Development Group, 2005. PostreSQL 8.0.3
Documentation. PostgreSQL Global Development Group.
[11]
William H. Inmon, 1996. Building the Data Warehouse.Wiley.
[12]
Liza Andrea Rojas Rojas, 2003. Diseño de un prototipo de bodega de
datos para un modelo de empresa de ventas y aplicación de herramientas OLAP.
Trabajo de grado (Ingeniero de Sistemas). Universidad Nacional de Colombia.
Facultad de Ingeniería. Departamento de Ingeniería de Sistemas.
[13]
Alexandra Pomares, 2004. Business Intelligence. Universidad Javeriana.
[14]
Kimball Group. About Kimball Group (online).
http://www.kimballgroup.com/html/about.html.
83
ANEXOS
ANEXO 1. MANUAL DE ADMINISTRADOR
Datamart Ventas
Http://pegasus.javeriana.edu.co/~infempre
Datamart Ventas
Ubiquando
Manual Administrador
Tabla de Contenido
1 Propósito y Alcance
1
2 Conceptos Basicos Sobre Consultas OLAP
2
2.1 EL MODELO DIMENSIONAL EN ESTRELLA.
2
2.2 DEFINICIÓN DE UN CUBO EN XML
3
2.3 ANÁLISIS MULTIDIMENSIONAL
4
2.4 MDX
12
3 Herramientas para el datamart
18
3.1 JAKARTA-TOMCAT
18
3.2 POSTGRESQL
20
4 Scripts de carga a la base de datos
22
5 Quienes Pueden Usar La Herramienta?
28
6 Navegando En El Datamart
29
Manual Administrador
Versión 1.0
1. PROPÓSITO Y ALCANCE
El propósito de este documento es describir los conceptos básicos y avanzados del
datamart ventas así como sus funcionalidades. Esta dirigido al usuario administrador
describiendo características de los lenguajes MDX y de las herramientas de software
pre-instaladas para el funcionamiento del datamart. El documento esta limitado a todo
lo descrito en la fase de requerimientos del proyecto.
1
2. CONCEPTOS BÁSICOS SOBRE CONSULTAS OLAP
En este capítulo se verá la teoría detrás del datamart. Este datamart no es una
herramienta de reporteo común, se basa en tecnología OLAP para realizar
consultas multidimensionales, así que es una herramienta orientada al análisis
de datos.
Comenzaremos por la capa más baja, que es la de base de datos. Una bodega
de datos debe estar orientada al análisis, no al almacenamiento transaccional
de los datos. Existen básicamente dos tipos de almacenamientos
multidimensionales, y son el M-OLAP y el R-OLAP. El primero se basa en
motores de bases de datos especializados para almacenar sus datos en
estructuras dimensionales, el segundo se basa en los motores de bases de
datos Relacionales comunes.
Este segundo modelo es en el que se basa Mondrian, la herramienta
implementada en el datamart.
2.1 EL MODELO DIMENSIONAL EN ESTRELLA.
Este modelo, es conocido como R-OLAP star schema. R-OLAP por ser
utilizado por el análisis OLAP soportado sobre bases de datos Relacionales, de
ahí la "R". El modelo propiamente se conoce como estrella, araña o copo de
nieve. Este modelo está específicamente diseñado para basarse en el la
construcción de hipercubos o cubos de decisión, donde se tiene una serie de
dimensiones , temas que interesan a la organización, y todas estas
dimensiones rodeando tablas de hechos que son las que registran todos los
movimientos o transacciones sobre las cuales se quiere hacer el análisis.
Figura 1. Generalidades del modelo estrella
2
Las generalidades del modelo son como se muestra en la figura 1, donde se
observa que debe existir una tabla de hechos rodeada por las dimensiones
asociadas. En las bases de datos que adoptan este modelo, se puede tener
una o más estrellas, dependiendo de los hechos que se quieran registrar en las
tablas de hechos.
La tabla de hechos o "fact table" como se conoce comúnmente, debe tener una
estructura que se divide en dos partes:
•
La primera de ellas debe contener las llaves foráneas que van a
relacionar a las dimensiones. Es decir, que por cada dimensión que
exista asociada a una tabla de hechos, debe aparecer una llave foránea
a dicha dimensión. Esto permite que al momento de utilizar los
hipercubos se involucre información contenida en los atributos de las
dimensiones que no estén almacenados en la tabla de hechos.
•
Después de los campos que tienen las llaves foráneas a las
dimensiones, deben aparecer los campos que almacenan la información
concreta del registro y particular al problema, y que permiten hacer las
sumarizaciones que se requieran en la aplicación. Esto es lo que en el
lenguaje de hipercubos se conoce como las Medidas o los Indicadores.
Las medidas como su nombre lo indica son las que miden una
determinada variable de estudio, y por lo general son cantidades de
cosas (cantidades de ventas, de dinero, etc.).
La medida utilizada en este proyecto que permite analizar las ventas de
Ubiquando, es el valor de venta en pesos. También pueden ser fechas, o en
fin, cualquier atributo que sea comparable y medible, y que proporcione
información valiosa al realizar los análisis requeridos del negocio. Sin unos
buenos indicadores, los resultados de las herramientas de acceso a datos no
van a ser muy eficientes.
Una vez analizada la tabla de hechos, se continúa con las dimensiones. Cada
una de las dimensiones es un tema, que debe tener una llave asociada en la
tabla de hechos. Estas dimensiones guardan información en sus atributos que
solo le atañe a ella, que no es necesario que deba ir incluida en la tabla de
hechos.
2.2 DEFINICIÓN DE UN CUBO EN XML
Mondrian utiliza un esquema propio para la generación de los hipercubos, y es
en un archivo de extensión .xml. En este archivo se establece el modelo lógico,
es decir, las dimensiones, jerarquías, medidas y niveles del cubo, así como el
modelo físico, o la relación con la base de datos que soporta dicho modelo.
Típicamente es el modelo de estrella, descrito en este documento.
3
La sintaxis para crear un cubo en xml es bastante intuitiva y organizada. A
continuación se muestra un esquema xml sencillo para el ejemplo incluido en
Mondrian, de una tienda de alimentos:
< Schema>
< Cube name="Sales">
< Table name="sales_fact_1997"/>
< Dimension name="Gender" foreignKey="customer_id">
< Hierarchy hasAll="true" allMemberName="All Genders" primaryKey="customer_id">
< Table name="customer"/>
< Level name="Gender" column="gender" uniqueMembers="true"/>
< /Hierarchy>
< /Dimension>
< Dimension name="Time" foreignKey="time_id">
< Hierarchy hasAll="false" primaryKey="time_id">
< Table name="time_by_day"/>
< Level name="Year" column="the_year" type="Numeric"
uniqueMembers="true"/>
< Level name="Quarter" column="quarter" uniqueMembers="false"/>
< Level name="Month" column="month_of_year" uniqueMembers="false"/>
< /Hierarchy>
< /Dimension>
< Measure name="Unit Sales" column="unit_sales" aggregator="sum"
formatString="#,###"/>
< Measure name="Store Sales" column="store_sales"aggregator="sum"
formatString="#,#"/>
< /Cube>
</ Schema>
Figura 2. Esquema de cubo XML
Este esquema contiene un cubo sencillo, llamado "Sales", o ventas. El cubo
tiene 2 dimensiones, que son tiempo y género, y 2 medidas, que son unidades
vendidas y valor de dichas unidades vendidas. Con este esquema ya se puede
construir una consulta MDX como:
select {[Measures].[Unit Sales], [Measures].[Store Sales]} on columns,
{[Time].[1997].[Q1].descendants} on rows
from [Sales]
where [Gender].[F]
2.3 ANÁLISIS MULTIDIMENSIONAL
El análisis multidimensional utilizado en este proyecto se basa en los siguientes
conceptos básicos.
•
Cubo Multidimensional. Es una estructura de almacenamiento que permite
realizar las diferentes y posibles combinaciones para visualizar los
resultados de una organización hasta un determinado grado de detalle. Esta
estructura es independiente del sistema transaccional de la organización y
facilita consultar información histórica de manera rápida y eficiente;
ofreciendo la posibilidad de navegar y analizar los datos requeridos. Cabe
4
recordar que el modelo de estrella es el que sopota este modelo de cubos
multidimensionales.
•
Medidas. Son características cualitativas o cuantitativas de los objetos que
se desean analizar en el negocio, es decir los temas. Las medidas
cuantitativas están dadas por valores o cifras porcentuales. Lo que se
puede medir se puede controlar y mejorar . Por ejemplo, se tienen las
ventas en dólares, el número de unidades de inventario, las horas
trabajadas, el promedio de piezas producidas, el porcentaje de aceptación
de un producto, el consumo de combustible de un vehículo, etc. Hay
muchos ejemplos de medidas, pero la definición de las mismas corresponde
a cada hipercubo en particular, es decir, del problema que se desee
resolver.
•
Dimensión. Son los objetos del negocio, con los cuales se puede analizar la
tendencia y el comportamiento del mismo. La definición de estas
dimensiones, se basa en políticas de la compañía o del mercado. Depende
del modo como se interpreta o clasifica su información, para segmentar el
análisis en sectores que por sus características comunes facilitan la
observación y el análisis. Para poder definir las dimensiones requeridas
dentro de los cubos multidimensionales, se deben responder a las
siguientes preguntas:
¿Cuando? : Permite hacer un análisis a través del tiempo y visualizar de
manera comparativa el desempeño del negocio por unidades de tiempo
que van desde días hasta años.
¿Donde? : Se centra en un área física o imaginaria donde se están
llevando a cabo los movimientos que se desean analizar, estos lugares
pueden ser zonas geográficas, bodegas de almacenamiento de
mercancía, divisiones hacia el interior de la organización, centros de
costo, clasificación de las cuentas contables y etc.
¿Que?: Es el objeto del negocio, o es el objeto de interés para
determinada área de la compañía.
¿Quien?: En esta dimensión se plantea una estructura de los elementos
que inciden directamente sobre el objeto de interés, en estos casos se
hace referencia a el área comercial o de ventas, a los empleados de la
organización cuando se esta realizando un análisis a nivel del talento
Humano y etc.
¿Cual? : Es hacia donde esta enfocado el esfuerzo de la organización o
una determinada área del negocio, para hacer llegar los productos o
servicios. En esta dimensión se trabaja con los clientes que pueden ser
internos o externos a la organización.
2.3.1 Los Cubos De Decisión
Al contar con estos componentes del análisis multidimensional, se inicia el
proceso de determinar los cubos que reflejen las necesidades del negocio.
5
CUANDO
DONDE
QUE
QUIEN
CUAL
MEDIDAS
año
zona
tipo de producto
fuerza de
ventas
división de clientes
ventas
semestre
región
grupo de producto
categoría
tipo de cliente
unidades
trimestre
ciudad
producto
vendedor
cliente
horas
Tabla 1. Ejemplos de dimensiones.
Un cubo de decisión es el resultado lógico del proceso de modelamiento en
estrella. En el caso del manejo relacional de bases de datos, los cubos pueden
estar organizados físicamente en motores de bases de datos que soporten esta
multidimensionalidad. De esta manera un cubo se convierte en una abstracción
multidimensional de los datos contenidos en un esquema relacional.
En un cubo están relacionados varios conceptos vistos en la sección anterior,
pero los conceptos que básicamente componen un cubo son las dimensiones,
las medidas, las jerarquías y los miembros.
Otros conceptos determinantes en el análisis multidimensional son las celdas,
los niveles, las tuplas y los grupos o sets, que son elementos que agregan
complejidad y funcionalidad a uno de estos cubos.
Intentar separar estos conceptos e intentar explicarlos por separado es una
tarea muy difícil pues se encuentran estrechamente relacionados entre sí. Para
enunciar y explicar de manera adecuada estos elementos se da un ejemplo.
Los elementos fundamentales de un cubo son las dimensiones y las medidas.
En la Tabla 2 aparecen dos dimensiones. La dimensión tiempo y la dimensión
producto. Para este cubo que consta de dos dimensiones existe una medida,
que es el número de unidades vendidas. Es decir que cada una de las celdas
contiene el valor de una medida que es la intersección de dos miembros de la
dimensión.
La dimensión producto tiene cuatro miembros, que son: carnes, vegetales,
cereales y leche. La dimensión tiempo tiene cuatro miembros también, que son
los meses de abril a julio. Es decir que la información contenida en este cubo
habla de las unidades vendidas de cada producto en cada mes. Los valores de
la medida unidades vendidas aparecen en una celda, que representa la
intersección entre dos dimensiones.
Unidades
Vendidas
tiempo
abril
mayo
junio
Producto
carnes
23
34
43
vegetales
17
43
65
cereales
34
14
21
leche
67
31
19
6
Unidades
Vendidas
julio
23
47
34
12
Tabla 2. Cubo de dos dimensiones y una medida
Por supuesto, podemos dar vuelta a las filas para que queden en las columnas
y viceversa, y el sentido de los datos es el mismo, como lo muestra la tabla 3.
Unidades
Vendidas
Tiempo
abril
23
17
34
67
Producto
carnes
vegetales
cereales
leche
mayo
34
43
14
31
junio
43
65
21
19
julio
23
47
34
12
Tabla 3. Cubo de dos dimensiones y una medida con dimensiones cambiadas.
Claramente, cada celda puede ser descrita en términos de un miembro de cada
dimensión. En ambas visualizaciones del cubo se pueden ver el número de
unidades de cereales vendidas en el mes de mayo.
Es muy fácil visualizar y analizar un cubo como estos, que consiste en dos
dimensiones y una medida. Sin embargo, no hay razón para que un cubo como
estos deba estar limitado a una sola medida. También se podría tener una
nueva medida, la medida "pesos vendidos". Hay muchas formas de visualizar
ésta medida y la medida de unidades vendidas. Podría representarse bien
como en la tabla 4.
Unidades
Vendidas/pesos
vendidos
tiempo
abril
mayo
junio
julio
Producto
carnes
23 $5000
34 $2500
43 $4250
23 $2355
vegetales
17 $3000
43 $3900
65 $5000
47 $6562
cereales
34 $2500
14 $3100
21 $1500
34 $3287
leche
67 $6000
31 $2000
19 $5300
12 $2345
Tabla 4. Cubo de dos dimensiones y dos medidas
En este caso las unidades vendidas ocupan la parte izquierda de la celda y los
pesos vendidos la parte derecha.
Así como los cubos pueden tener múltiples medidas, también pueden tener
más de dos dimensiones. Si al negocio de este ejemplo, se le agrega que la
compañía que vende estos productos tiene sedes en distintos lugares,
aparecería una nueva dimensión. Es posible ver la información anterior, ahora
discriminada por dichos lugares. Se le agrega la dimensión ciudad y se obtiene
el cubo de la figura 3.
7
Figura 3. Cubo dimensional de tiempo, producto y ciudad.
La celda que está en verde en el cubo muestra una intersección entre tres
aristas del cubo.Cada arista representa una dimensión. La celda seleccionada
es pues una intersección de el mes de mayo, de el producto vegetales y de la
ciudad Bogotá. El valor que se encuentra dentro de la celda es el número de
unidades de vegetales vendidos en mayo en bogota.
De esta manera los datos ahora se analizan en tres dimensiones. Sin embargo,
gracias a OLAP no hay límite de dimensiones para el análisis de datos. Por lo
tanto, un cubo multidimensional podría tener muchas más dimensiones que las
expuestas en el anterior ejemplo.
Para complementar ese cubo tridimensional se podría agregar la dimensión
empleado, para saber que empleado vendió el producto, y también agregar la
dimensión cliente, para saber a que persona se le han vendido cuantos
productos. De esta manera el cubo ahora tendría cinco dimensiones.
De este cubo, se puede obtener una aseveración como esta: "pedro vendió 10
cajas de cereal en mayo en la ciudad de bogota a la cliente María, que le
costaron $35000 pesos". Para conocer esto se han usado las 5 dimensiones
definidas, así como las dos medidas.
Hasta este punto se ha expuesto la relación de los conceptos básicos de
análisis multidimensional, como dimensiones, medidas, miembros y celdas.
Pero la complejidad de los conceptos va en aumento, y se agregan los
siguientes elementos:
8
Jerarquías Y Agregaciones. Las dimensiones vistas proveen una análisis
significativo para los datos. Sin embargo han sido dimensiones estáticas, que
no permiten variar su forma. Si se pretendiera analizar los datos por día, por
mes, por trimestre, o por año no se justificaría hacer un cubo diferente para
cada restricción. Para hacerlo eficiente, se usan dimensiones con jerarquías.
Una dimensión puede estar organizada jerárquicamente. Por ejemplo, muchos
cubos tienen una dimensión tiempo que normalmente es jerárquica, y que
incluye un año, semestre, trimestre, mes y día. Un ejemplo de esta dimensión
ocurre cuando se quieren ver las unidades vendidas de un producto en
determinada ciudad discriminadas por año, mes, trimestre y día. Estas vistas
son las tablas 5, 6 y 7.
Unidades
Vendidas
tiempo
año
2001
2002
2003
2004
producto
carnes
232
343
432
234
vegetales
173
432
656
472
cereales
344
145
215
345
leche
675
318
193
128
cereales
145
144
169
198
leche
123
113
105
102
cereales
34
14
21
34
leche
67
31
19
12
Tabla 5. Resultados por año
Unidades
Vendidas
tiempo
trimestre
trim 1
trim 2
trim 3
trim 4
producto
carnes
101
122
176
138
vegetales
172
165
128
126
Tabla 6. Resultados por trimestre
Unidades
Vendidas
tiempo
mes
abril
mayo
junio
julio
producto
carnes
23
34
43
23
vegetales
17
43
65
47
Tabla 7. Resultados por mes.
Todas estas tablas se refieren a la dimensión tiempo, y se relacionan entre sí,
dado que un mes está contenido en un trimestre, y este a su vez está
contenido en un año. Están organizados lógicamente de manera jerárquica.
9
Los resultados de los datos con estas restricciones se pueden representar
como aparecen en la tabla 8.
Este tipo de representaciones que se encuentran al interior de un cubo, son el
resultado de sumar o hacer agregaciones de los datos originalmente guardados
en la base de datos. Es decir, el resultado por trimestre surge de sumar los
resultados de los tres meses que conforman el trimestre. Esto es lo que se
conoce como una agregación.
El termino agregación no es propiamente un concepto del análisis
multidimensional. Surge de la necesidad de optimizar los tiempos de respuesta
a los clientes o usuarios, y en él vienen involucrados conceptos de almacenar y
cargar datos temporalmente en la memoria.
2000
trim 3
2000
trim 3 total
trim 4
trim 4 total
2000 total
julio
agosto
septiembre
octubre
noviembre
diciembre
carnes
17
16
12
45
27
24
21
72
242
leche
22
18
19
59
19
19
12
50
199
Tabla 8. Resultados anteriores vistos de una forma más compleja
Las jerarquías están compuestas por niveles, que se exponen a continuación.
Niveles. Siguiendo con el ejemplo de la dimensión tiempo, la jerarquía de esta
dimensión podría ser como se ve en la figura 4.
Figura 4. Niveles de la jerarquía tiempo.
10
En la figura 4, se incluye por cuestiones de visibilidad solo parte de la jerarquía.
En este ejemplo de observa claramente que la jerarquía de la dimensión tiempo
tiene 4 niveles, que son: el nivel "all", el año, el trimestre y el mes. Además de
los niveles propios de una fecha, que son: el año, el trimestre y el mes, se
incluye el nivel all, que es la raíz de este árbol jerárquico.
El nivel all está creado específicamente para poder manejar y tener acceso a
toda la información de tiempo contenida dentro del cubo, para producir
respuestas a preguntas como : ¿cual es el número de unidades vendidas de
algún producto para todo el periodo de tiempo cubierto por el cubo?. Muchas
de las dimensiones existentes poseen un nivel superior "all".
Los niveles tienen miembros, y un miembro es un ítem simple en una
dimensión. Se podría formar un cubo con cada uno de estos niveles y la
dimensión tiempo, y todos serían miembros. El nivel año tiene 2 miembros, el
nivel trimestre tiene 8 miembros, y así sucesivamente.
Tuplas Y Sets. Un set es un conjunto o un grupo. Pero para efectos del
análisis multidimensional se considera tal cual como se maneja en el ambiente
multidimensional.
Tuplas.
Dada la figura 3 descrita anteriormente, se analiza la celda
seleccionada, identificada con color verde. Esta selección se representa con la
siguiente notación:
" [productos].[vegetales], [tiempo].[mayo], [ciudad].[bogota] "
En esta notación, se tiene la intersección especificada en función de las tres
dimensiones y sus miembros respectivos. Primero está la dimensión producto,
donde el miembro al que se hace referencia es vegetales, y de esta forma se
representan las demás dimensiones, separadas por comas. En este orden se
hace referencia a la celda seleccionada en el caso del ejemplo.
Es independiente el orden en el que se coloquen las dimensiones. La celda
descrita también se podría representar de esta manera:
" [productos].[vegetales], [ciudad].[bogota], [tiempo].[mayo] ".
Lo importante es utilizar las coordenadas dentro del cubo para hacer la
selección requerida. Las coordenadas son miembros, un miembro tomado de
cada dimensión. Por lo tanto, se llega a la definición que este conjunto de
coordenadas es lo que se conoce como una tupla que es única en la matriz
multidimensional.
11
Figura 5. Expresión multidimensional vista gráficamente.
Sets. Un set es una colección simple de tuplas, o un conjunto de tuplas, las
cuales son definidas usando las mismas dimensiones. El uso de las mismas
dimensiones se ve en esta expresión:
( [productos].[vegetales], [ciudad].[bogota], [tiempo].[mayo] ) ( [productos].[carnes],
[ciudad].[bogota], [tiempo].[mayo] )
Estas dos tuplas toman cada una exactamente un miembro de cada una de las
dimensiones, y ambas son definidas usando las mismas dimensiones. Es decir
que si se unen en una expresión, se convertirían en un set. Podemos decir que
estas tuplas tienen la misma "dimensionalidad".
Por lo tanto se complementa la definición de set, estableciendo que es una
colección de tuplas con la misma dimensionalidad. Puede tener varias tuplas,
una tupla, o ninguna tupla, en cuyo caso sería un set vacío.
2.4 MDX
Definición Básica Del Lenguaje Mdx.
Hasta ahora se ha usado una notación para referirse a un miembro en una
dimensión. Se había dicho que primero se colocaba la dimensión, entre [ ], se
separaban por un punto y se escribía el miembro entre otros [ ]. Todo esto
pertenece a un lenguaje llamado MDX.
Las siglas MDX significan Multi Dimensional eXpressions. Es un lenguaje que
sirve para hacer consultas en una base de datos multidimensional,
análogamente a como lo haría el lenguaje SQL en las bases de datos
comunes. Es la forma de expresar el análisis de un cubo OLAP.
12
Desde que la empresa Microsoft entro al mundo de la Inteligencia de negocios,
en el año de 1998, con una versión de servicios OLAP en la aplicación SQL
Server 7.0, el lenguaje MDX se ha venido convirtiendo en una lengua estándar
para este tipo de consultas. Es verdad que aunque fue creado por compañías
propietarias, el lenguaje MDX ha sido adoptado también por el mundo del
Software libre, para las aplicaciones OLAP existentes.
Este lenguaje es útil para muchas cosas, desde aspectos de seguridad en el
cubo, hasta el diseño de la navegación hacia adentro y fuera del cubo. En
definitiva este lenguaje fue creado específicamente para el manejo de cubos
OLAP. Una de las grandes características de este lenguaje es el de permitir el
manejo de las agregaciones y los resultados precalculados, sin necesidad de
que aparezcan físicamente establecidos en las bases de datos.
Siguiendo con la notación del lenguaje, la forma natural de llamar a un miembro
con
una
jerarquía
suficiente
podría
ser
como
este:
[lugar].[Colombia].[Cundinamarca].[Bogota].[Chapinero]. Esta sería la forma completa
para referirse al barrio chapinero de la ciudad de Bogotá. Aunque muchas
veces es posible usar expresiones más cortas, como [ciudad].[chapinero], esto se
puede hacer, pero solo bajo ciertas condiciones de nombrado y ciertos datos.
Por ejemplo, para el caso de la dimensión tiempo, es posible tener una
expresión como "[tiempo].[octubre]". Pero como se podría saber si el octubre al
que se hace referencia es al del año 2001 o 2002 o 2003?. Una forma de
solucionar este inconveniente es el de hacer unas convenciones de
nombramiento. Por ejemplo, si el miembro no se llamara octubre sino "octubre2001", ya se podría identificar con una corta expresión, es decir que se puede
definir como: [tiempo].[octubre-2001] en vez de: [tiempo].[all].[2001].[octubre].
La sintaxis MDX no es solo para obtener datos de las bases
multidimensionales, también provee una funcionalidad extra para el manejo de
sets, manejo de miembros calculados y la escritura de información acerca de
dimensiones y celdas. Para finalizar esta definición de MDX, se examina la
siguiente consulta MDX, definida de la siguiente forma:
SELECT {[Measures].[Cantidad_visitas], [tiempo].[All Members].[1998].[sem2]} ON columns,
{[geografía].[All Members]} ON rows
FROM [visitas]
WHERE [vendedor].[juan]
Esta sencilla consulta mdx presenta la misma estructura que una consulta SQL,
es decir, tiene un select, un from y un where. Es importante notar que en el
lenguaje mdx las medidas también son interpretadas como dimensiones. En
este ejemplo se está consultando el número de visitas hechas en el segundo
semestre de 1998 en todas las zonas, veredas y municipios, por el vendedor
juan. Como se identifica en la sintaxis se da la opción de escoger como
comparar las dimensiones, en filas o en columnas. [visitas] es el nombre del
cubo.
13
2.4.1 Conceptos Avanzados con mdx.
En la explicación anterior se revisaron los conceptos básicos de como construir
una consulta MDX, en esta parte se explicarán conceptos mas avanzados de
MDX.
La estructura detallada de una consulta MDX se expone en el siguiente
diagrama.
Dimensiones
Eje X, Columnas.
SELECT {[Measures].[Cantidad_visitas], [tiempo].[All Members].[1998].[sem2]} ON columns,
{[geografía].[All Members]} ON rows
Eje Y, Filas.
FROM [visitas]
Alcance de la consulta, (cubo)
WHERE [vendedor].[juan]
Cláusula de selección
Figura 6. Estructura de una consulta MDX
Existe una similitud entre las consultas MDX y SQL, debido a que comparten
sintaxis como lo son las cláusulas SELECT, FROM y WHERE. Sin embargo
existen ciertos elementos que se distancian de SQL para dar soporte a las
necesidades multidimensionales.
En MDX se identifican varios miembros, que cumplen un rol determinado por su
posición en la jerarquía.
Children.
La primera función es Children la cual, identifica el miembro o los miembros de
un nivel por debajo del nivel inicial. Para usar la función Children se debe
especificar el miembro, para que la función retorne todos los niveles por debajo
de ella.
Ejemplo:
Se tiene la siguiente consulta MDX:
select {[Measures].[Valor]} ON columns,
Hierarchize({[Producto].[All Productos]}) ON rows
from [cuboVentas]
De esta consulta se obtiene el siguiente resultado
Measures
Valor
Producto
All
1,480,238,151
Productos
14
Que es el valor de las ventas de todos los productos. Ahora se utilizará la
función children aplicada a la dimensión producto para comparar su resultado.
Ejemplo de consulta
select {[Measures].[Valor]} ON columns,
Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All Productos].Children)) ON rows
from [cuboVentas]
Al ejecutar la anterior consulta se da el siguiente resultado
Measures
Valor
1,480,238,151
All Productos
Producto
Asesora
5,510,000
Capacitación 110,569,754
Desarrollo
1,068,367,852
Instalación
147,968,876
Soporte
88,168,533
Esta nueva consulta muestra el valor vendido de todos los productos como un
total y también de cada uno, pues cada producto es hijo de la categoría
Producto.
Count.
La función Count retorna el numero de items de de un cubo, por ejemplo las
dimensiones, las tuplas, las celdas, niveles en una dimensión o una jerarquía.
Se tiene el siguiente ejemplo:
with member [Measures].[total] as 'count([Producto].[All Productos].Children)'
select {[Measures].[total]} ON columns
from [cuboVentas]
El resultado es el siguiente:
Measures
total
5
La función realiza un conteo de los componentes de Producto, que son cinco pues hay cinco
categorías de productos.
Avg.
La función Avg retorna el promedio de un número total de miembros.
En la siguiente consulta de ejemplo se utiliza esta función.
15
with member [Measures].[total] as 'Avg([Producto].[All Productos].Children)'
select {[Measures].[total]} ON columns
from [cuboVentas]
El resultado es el promedio del valor de las ventas de las categorías de
productos.
Measures
total
284,117,003
Max.
La Función max retorna el máximo valor de un numero total de miembros.
Max(«Set»[, «Numeric Expression»])
En el siguiente ejemplo se ve:
with member [Measures].[total] as 'Max([Producto].[All Productos].Children)'
select {[Measures].[total]} ON columns
from [cuboVentas]
Tiene el siguiente resultado:
Measures
total
1,068,367,852
En el cual se ve el valor de ventas de la categoría de producto con mayor valor
en ventas.
Min
La Función min retorna un mínimo valor de un numero total de miembros.
Min({Set}[, {Numeric Expression}])
Para la cual se da el siguiente ejemplo.
with member [Measures].[total] as 'Min([Producto].[All Productos].Children)'
select {[Measures].[total]} ON columns
from [cuboVentas]
Measures
total
5,510,000
El resultado muestra el valor de la categoría de productos con menores ventas.
Crossjoin
16
Frecuentemente en MDX, los resultados de una consulta deberán necesitar
más miembros de más de una dimensión.
Crossjoin({Set1}, {Set2})
Esta función retorna el producto cartesiano de distintos miembros de dos sets,
que retorna todas las posibles combinaciones de esos miembros.
El siguiente ejemplo muestra el uso de esta característica.
select Crossjoin(Hierarchize(Union({[Ciudad].[All Ciudads]}, [Ciudad].[All Ciudads].Children)),
{[Measures].[Valor]}) ON columns,
{[Producto].[All Productos]} ON rows
from [cuboVentas]
Se genera el siguiente resultado:
Ciudad
All Ciudads
-
BOGOTA
CALI
MONTERIA
Measures
Measures
Measures
Measures
Measures
Producto
Valor
Valor
Valor
Valor
Valor
All
1,480,238,15 43,584,752 900,610,669 469,833,235 57,565,495
Productos
Se hace un producto cartesiano entre el miembro Producto y Ciudad, para
conocer el valor de las ventas de los productos en cada ciudad.
17
3. HERRAMIENTAS PARA EL DATAMART
Para el desarrollo del datamart se usaron varias herramientas, y varias de ellas
soportan el funcionamiento del datamart. A continuación se explica el concepto
y funcionalidad de cada una de ellas, así como el proceso de instalación,
administración y uso de estas aplicaciones, todas ellas de libre distribución.
3.1 JAKARTA-TOMCAT
Tomcat es un sub proyecto de Jakarta que provee un poderoso servidor web
(web-container) con soporte a Java Servlets y JSP. El servidor de Tomcat ha
llegado a ser la referencia para el funcionamiento tanto de servlet como de
JSP. Es muy estable y tiene todas las características de un servidor web
comercial. Tomcat también proporciona funcionalidades adicionales que lo
hacen una excelente opción para desarrollar una solución web.
3.1.1 El Manager de Tomcat
El manager es una aplicación para administración del motor Tomcat que usa
una interfaz vía web. En principio y por razones de seguridad no se puede
ingresar al módulo manager hasta que sea creado un usuario de Tomcat con
privilegio de administrador. Para crearlo se debe modificar el archivo de
configuración de usuarios de Tomcat, que se encuentra en
$Tomcathome/CATALINA_HOME/conf/tomcat-users.xml. A dicho archivo se
deben agregar las siguientes líneas:
<role rolename="manager"/>
<user username="root" password="xxxxxxx" roles="manager"/>
Debido a que es un documento xml, se debe respetar el orden de las etiquetas.
Dicho de otro modo, la línea <role> debe insertarse debajo de las que ya están
y lo mismo para la línea <user>. Con respecto a la línea <user> agregada, se
puede poner el nombre de usuario que se prefiera, no hace falta que sea root
(la condición de administrador se define en el atributo role, no en el nombre). Al
momento de asignar el password puede ser cualquiera. Una vez se ha
agregado el usuario, se debe reiniciar Tomcat y acceder, desde un navegador
a la dirección http://localhost:8080/manager/html, se introduce la información
del usuario administrador (username/password), recién creado y aparecerá la
interfaz del manager. Dicha interfaz consta de 5 partes:
o
Message: Aquí se muestra el resultado de las órdenes que se le
hayan dado al manager. Pueden ser OK o FAILED.
18
o
Manager: Aquí se encuentran tres opciones. La primera recarga
la lista de aplicaciones instaladas. Las dos siguientes son un
enlace a la documentación de Tomcat.
o
Applications: Aquí aparece la lista de aplicaciones web que está
ejecutando Tomcat. Para cada aplicación se tiene la columna
“Commands” que es la más importante para administrar los
servicios ofrecidos por Tomcat. Las opciones de Commands son:
parar (stop), iniciar (start), recargar (reload) o borrar (undeploy) la
aplicación.
o
Install: Desde aquí se suben aplicaciones directamente al
Tomcat. Para agregar una aplicación, se da el url del archivo .war
de la aplicación que se quiere instalar. Luego se oprime el botón
install, y la aplicación es agregada a las aplicaciones soportadas
por Tomcat.
o
Server information: Información respecto al servidor.
Arranque del servidor Tomcat.
Hay dos técnicas de arranque del servidor Tomcat
La primera es mediante la variable de ambiente:
- Estableciendo la variable de ambiente TOMCAT_HOME en la ruta del
directorio el cual se ha instalado el Tomcat
%TOMCAT_HOME%\bin\startup para Unix,
%TOMCAT_HOME%/bin/startup.sh
(para Windows
La segunda puede hacerse modificando el directorio actual de trabajo:
- Ejecute los siguientes comandos en el shell:
cd$TOMCAT_HOME/bin (Linux)
./startup.sh (Unix)
Hay dos técnicas para parar el Tomcat: Vía variable de ambiente:
- Establecerla variable de ambiente TOMCAT_HOME en la ruta del directorio
en la cual se instalo el Tomcat.
- Ejecutar el comando prompt o shell:
$TOMCAT_HOME/bin/shutdown.sh (para Unix)
Modificando su actual directorio de trabajo:
- Ejecutar los comandos siguientes en el prompt oshell:
19
cd $TOMCAT_HOME/bin
./shutdown.sh
(para Linux)
(para Linux)
3.2 POSTGRESQL
PostgreSQL es un administrador de bases de datos relacionales, que soporta
las instrucciones de SQL, y se encuentra entre los más populares y funcionales
dentro del mundo del software libre. Además, ofrece una potencia adicional
sustancial al incorporar los siguientes cuatro conceptos adicionales básicos en
una vía en la que los usuarios pueden extender fácilmente el sistema
clases
herenci
a
tipos
funcione
s
Otras características aportan potencia y flexibilidad adicional:
Restricciones
(Constraints)
Disparadores (triggers)
Reglas (rules)
Integridad
transaccional
Estas características colocan a Postgresql en la categoría de las Bases de
Datos identificadas como objeto-relacionales. Nótese que éstas son diferentes
de las referidas como orientadas a objetos, que en general no son bien
aprovechables para soportar lenguajes de bases de datos relacionales
tradicionales. Postgresql tiene algunas características que son propias del
mundo de las bases de datos orientadas a objetos. De hecho, algunas Bases
de Datos comerciales han incorporado recientemente características en las que
Postgresql fue pionera.
Instalación de PostgreSQL
En el directorio de instalación se digita la siguiente línea:
[root#localhost]# su postgres
[bash]$
20
El siguiente paso es crear un nuevo usuario para la base de datos en
postgresql, se digita lo siguiente:
[bash]$:createuser
Enter name of user to add: Ubiquando
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allowed to create more new users? (y/n) y
CREATE USER
[bash]$createdb martVentas
CREATE DATABASE
Para permitir conexiones tcp/ip, se necesita editar el fichero postgresql.conf y
habilitar la opción tcpip_socket. En redhat 9, este fichero está localizado en
/var/lib/pgsql/data. Como súper usuario (root) configure lo siguiente
y se modifica la siguiente línea:
#tcpip_socket = false
y la cambiamos por los siguiente:
tcpip_socket = true
Queda un último paso que es editar el fichero pg_hba.conf. Este fichero
especifica los ordenadores que pueden conectarse a la base de datos
postgres.
Se guarda el archivo y por ultimo se debe reiniciar el servicio.
service postgresql restart
21
4. SCRIPTS DE CARGA A LA BASE DE DATOS
Descripción:
La Funcionalidad de los scripts de carga es realizar la carga de los datos a la
base de datos que manipula el datamart, a partir de los archivos planos y de la
base de datos “netcontable” que son utilizados como fuente del datamart.
Este documento va a describir cual es la función de cada uno de cada archivos
planos y de la base de datos netcontable que son las fuentes de datos, y de los
scripts de carga, para los que se define cada cuanto se realiza su ejecución.
Definición de los archivos planos:
1.
Sectores.txt
Este archivo contiene los sectores de clientes que se han identificado para
Ubiquando, cada cliente de Ubiquando será relacionado con uno de estos
sectores. Se tienen tres campos para identificar a cada sector, estos
campos deben estar en la misma línea. El primer campo es el código del
sector. Este código no se puede asignar al azar, pues tiene un significado.
Los códigos que inician con “00” son categorías de Gobierno, si se quieren
agregar subcategorías a Gobierno los códigos de estos subsectores deben
iniciar con “00” y empezar a numerar cada subsector en el quinto carácter
de este campo, incrementando de uno en uno. Por ejemplo, “00000” sería la
primera subcategoría de gobierno, “00001” la siguiente, y continúa con
“00002” y así sucesivamente. Los campos que inician con “01” hacen
referencia a clientes del sector “Corporativo” y se incrementa la numeración
del código para cada subsector de igual manera que en el caso de
Gobierno. El último sector es el de Pymes, el cual inicia con “02” y cumple
con los mismos requisitos en los códigos que los anteriores sectores.
El segundo campo de cada línea, identifica el nombre de la categoría del
sector. Este puede ser: Gobierno, Corporativo o Pymes. Y por último, el
tercer campo de cada línea dice el nombre de la subcategoría de la
categoría. Se pueden agregar subcategorías a cada categoría en este
archivo, lo importante es mantener el estándar de codificación descrito en el
párrafo anterior. El siguiente es un ejemplo de la estructura del archivo
“Sectores.txt”.
00000;Gobierno;Gobierno
01000;Corporativo;Agremiaciones
01001;Corporativo;Salud
02000;PYMES;PYMES
2.
Clientes.txt
Este archivo es utilizado para relacionar a cada cliente de Ubiquando con el
segmento al que pertenece, de acuerdo a la clasificación acordada de
22
clientes. Debe contener una lista de la identificación de todos los clientes, la
cual es extraída de la tabla “tercero” y su campo “id” de la base de datos
netcontable. Al lado de cada identificación, y separada por punto y coma (;)
se debe incluir el código del sector al que pertenece el cliente. Los códigos
de sector que se pueden incluir se encuentran en el archivo “sectores.txt”
descrito previamente. Las siguientes dos líneas son un ejemplo de la
estructura que debe contener el archivo.
8600136124;1002
8001443313;1001
3.
“lineas.txt”
Este archivo es utilizado para especificar las líneas de productos que tiene
Ubiquando. Cada renglón de este archivo establece una línea de producto,
especificando su código y luego de un punto y coma (;) se da el nombre de
la línea. Cada producto pertenece a una línea y esta relación entre producto
y línea se realiza en el archivo “productos.txt” que será descrito en la
siguiente sección. Es importante el código de cada línea, pues a partir de
este código se codifican los productos. A continuación se da todo el
contenido del archivo “lineas.txt” por ser de gran utilidad para describir la
siguiente sección.
0;Asesora
1;Instalación
2;Desarrollo
3;Capacitacion
4;Soporte
4.
“productos.txt”
En este archivo aparecen todos los productos que comercializa Ubiquando.
Cada renglón del archivo especifica un producto, incluyendo un código del
producto, seguido por punto y coma(;) y luego por el nombre del producto.
Es importante la codificación de cada producto, pues de su código depende
su clasificación en las líneas de producto. Todos los códigos tienen una
longitud de cinco caracteres. Los códigos de producto que empiecen con
“00” se refieren a productos de asesoría, los que empiezan con “01“ a
instalación, los de “02” a desarrollo, los de “03” a capacitación y los de “04”
a soporte. Luego de identificar a la línea de el producto codificado utilizando
los dos primeros caracteres del código, se asigna un número a cada
producto individual, estableciendo el quinto dígito del campo e
incrementando este número para cada producto individual de la misma
línea. A continuación se dan ejemplos de renglones incluidos en el archivo
“productos.txt” .
01000;Mensajeria y Email
01001;Proteccion de Borde
01002;VPN
01003;PDC
23
En estos renglones todos los productos pertenecen a la línea Instalación,
por iniciar con “01” y luego se incrementa el número del quinto dígito para
establecer el código individual de cada producto.
5.
“Ventas.txt”
Dado que la mayoría de los registros de ventas existentes en las base de
datos “netcontable”, la cual es utilizada para registrar ventas - entre otras
cosas -, contienen información errónea respecto al producto vendido por
cada factura, se dio la necesidad de crear este archivo. El archivo contiene
todos los códigos de facturas encontrados en netcontable desde el
01/01/2004 hasta el 20/04/2005. Por cada código de factura se agrega el
código del producto vendido en esa factura, separados ambos códigos por
un punto y coma(;). Cada renglón del archivo corresponde a una factura.
Este archivo fue creado hasta el 20/04/2005 para establecer el correcto
código de producto vendido en estas facturas, pues el registrado en
netcontable es erróneo. A partir de esta fecha se ingresan correctamente
los códigos de productos vendidos a la base de datos netcontable, por lo
tanto la carga de las facturas generadas luego de esta fecha se hace
directamente a la base de datos netcontable y no a través de este archivo.
Por lo que el archivo no se actualizará. A continuación se da un ejemplo de
las líneas de este archivo, reafirmando que el primer campo corresponde al
número de factura y el segundo al código del producto vendido en esa
factura.
875;1008
876;4002
877;4002
Definición de Scripts:
6.
Fechas200X.csv
Este script se debe correr directamente en un cliente de PostgreSQL. El
script inserta los datos directamente a la dimensión dim_tiempo de la base
de datos martVentas del datamart. Lo que hace cada renglón de este
archivo es crear el registro de un día de calendario a esta dimensión. Cada
renglón tiene la forma “insert into dim_tiempo values(Número de llave
primaria,número de año,'Nombre del número de semestre','Nombre del
número de trimestre','nombre del mes',número de día);”. En la base de
datos ya se encuentran, por defecto ingresadas las fechas hasta el 2006.
Para agregar nuevas fechas es importante seguir con el mismo estándar y
tener precaución de no repetir llaves primarias, por lo que es necesario,
incrementar el valor de cada llave primaria en uno para cada nuevo registro.
Por lo tanto, es importante verificar el último valor de llave primaria
encontrado en la tabla dim_tiempo de la base de datos martVentas e
insertar el nuevo registro con llave primaria de ese valor más uno. A
continuación se da un ejemplo de un renglón de este archivo.
insert into dim_tiempo values(161,2004,'Sem1','Trim2','Junio',11);
24
7.
Propiedades.java
Esta clase define los parámetros externos que requiere la clase
CargaBodegaUbiquando.java descrita a continuación para ejecutarse. El
único objetivo de “Propiedades.java” es especificar los datos del usuario de
la base de datos martVentas, la ubicación de esta base de datos, la
ubicación de los drivers de las bases de datos, y el directorio y nombres de
los archivos de texto fuentes de datos para la bodega.
8.
CargaBodegaUbiquando.java
Esta clase es la única invocada por el usuario o el sistema para realizar el
proceso de extracción, transformación y carga a la bodega. Antes de
ejecutar esta clase es importante que se encuentren disponibles todos los
archivos de texto fuentes en el directorio especificado por el archivo
“Propiedades.java” y las bases de datos fuentes y destino.
En esta clase se obtiene una instancia de seis clases, cada una encargada
del proceso ETL de una dimensión y de la tabla de hechos. Luego de
obtener la instancia de cada clase, se ejecuta el método correspondiente a
cada clase para extraer, transformar y cargar su respectiva dimensión o
tabla de hechos. A continuación se relaciona a cada clase instanciada
dentro de “CargaBodegaUbiquando.java” con su dimensión o tabla de
hechos objetivo.
Clase
Tabla del datamart
CargaSectores
dim_sector
CargaLinea
dim_linea
CargaGeografia
dim_geografia
CargaProductos
dim_producto
CargaCliente
dim_cliente
CargaFactVenta
fact_venta
Luego de ejecutar la clase “CargaBodegaUbiquando.java”, la bodega estará
cargada para hacerle los análisis necesarios con OLAP. A continuación se
describe cada clase que aparece en la tabla superior en el orden de
invocación de la clase principal “CargaBodegaUbiquando.java”.
9.
CargaSectores.java
Tiene como datos fuentes: Archivo “sectores.txt”.
Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y
cargar los datos fuentes, encontrados en el archivo “sectores.txt” a la
dimensión dim_sector. El método invocado desde la clase principal
“CargaBodegaUbiquando.java” es cargarSectores(). En este método, lo
25
primero que se hace es borrar de la tabla dim_sector de la bodega todo lo
que halla, para luego cargar en esa misma tabla los datos que se
encuentren en el archivo “sectores.txt”. Por lo tanto, si se hiciese algún
cambio en el archivo de sectores, al realizar la siguiente carga, la
información del archivo sectores.txt actualizada reemplaza a la que se había
cargado previamente.
10.
CargaLinea.java
Tiene como datos fuentes: Archivo “lineas.txt”.
Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y
cargar los datos fuentes, encontrados en el archivo “lineas.txt” a la
dimensión dim_linea. El método invocado desde la clase principal
“CargaBodegaUbiquando.java” es cargarLinea(). En este método, lo primero
que se hace es borrar de la tabla dim_linea de la bodega todo lo que halla,
para luego cargar en esa misma tabla los datos que se encuentren en el
archivo “lienas.txt”. Por lo tanto, si se hiciese algún cambio en el archivo de
líneas, al realizar la siguiente carga, la información del archivo lineas.txt
actualizada reemplaza a la que se había cargado previamente.
11.
CargaGeografia.java
Tiene como datos fuentes: Tabla ciudad de la base de datos netcontable.
Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y
cargar los datos fuentes, encontrados en la base de datos netcontable en la
tabla ciudad. Los campos extraídos de esta tabla son “codigo” y “nombre”.
Estos campos son extraídos y cargados a una tabla temporal llamada
“ciudad”, encontrada en la base de datos martVentas de PostgreSql.
“ciudad” es independiente y se encuentra aislada del diagrama estrella de la
bodega. En esta tabla se realizan las transformaciones que sean
necesarias, para luego cargar los datos de esta tabla temporal a la tabla
dim_geografia. Todos los datos de la tabla dim_geografia son borrados
antes de cargar los nuevos datos de la tabla temporal. Y los datos de esta
tabla temporal son borrados luego de realizar el proceso.
12.
CargaProductos.java
Tiene como datos fuentes: Archivo “productos.txt”.
Esta clase tiene como objetivo extraer, transformar y cargar los datos
fuentes, encontrados en el archivo “productos.txt” a la dimensión
dim_producto. En este método, lo primero que se hace es borrar de la tabla
dim_producto de la bodega todo lo que halla. Luego se leen los datos del
archivo de texto y se hace la transformación para asignarle una llave
foránea a cada producto, que indique su pertenencia a una línea.
13.
CargaCliente.java
Tiene como datos fuentes: Archivo “clientes.txt” y tabla tercero de base de
datos netcontable.
Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y
cargar los datos fuentes, encontrados en la base de datos netcontable en la
tabla tercero y el archivo “clientes.txt”. Los campos extraídos de la tabla
26
tercero son “id, “nombre”” y “ciudad”. Primero se borran todos los datos
existentes en la tabla dim_cliente y luego se insertan los datos encontrados
en las fuentes. Los campos cli_idcliente, cli_nombre y cli_ciudad de la tabla
destino dim_cliente son tomados de netcontable; y el campo cli_idsector
que relaciona a un cliente con un sector, tiene como fuente el archivo
clientes.txt. Son necesarias estas dos fuentes, pues en la base de datos
netcontable no se establece correctamente le pertenencia del cliente a un
sector, por lo tanto se requiere este archivo adicional.
14.
CargaFactVenta.java
Tiene como datos fuentes: Archivo “ventas.txt” y tabla comprobante de base
de datos netcontable.
Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y
cargar los datos fuentes, encontrados en la base de datos netcontable en la
tabla comprobante y el archivo “ventas.txt”. Los campos extraídos de la
tabla comprobante
son “numero, “creacion”, ”tercero” y “total”. Los
elementos del archivo de texto son: el número de factura y el código del
producto vendido en esa factura. Para realizar el proceso ETL de esta tabla,
se crea una tabla temporal llamada comprobante en la base de datos
martVentas. Esta tabla es independiente del diagrama estrella de la bodega,
solo se utiliza para hacer las transformaciones requeridas antes de insertar
los datos en la tabla fact_venta de la bodega. En esta tabla temporal se
insertan los datos extraídos de todos los registros de la tabla comprobante
de la base de datos netcontable. Luego de haber extraído los datos, se
borran todos los datos de la tabla fact_venta y se poblan con los nuevos.
Preservación de errores
Cuando se ejecuta el script de carga puede presentarse algún problema, si
esto llega a ocurrir el script genera algunos mensajes que se pueden llegar a
presentar en el cargue como pueden ser:
Mal formato de la fecha y hora.
No se tiene conexión con base de datos netcontable
No tiene conexión con base de datos martVentas
No se encuentra el archivo fuente xxx.txt.
Entre otros más que se pueden presentar en el momento de la ejecución,
actualmente la ejecución de los scripts envía los mensajes por pantalla.
27
5. QUIENES PUEDEN USAR LA HERRAMIENTA?
Figura 6. Registro del usuario
Como recomendación para usar la herramienta debe haberse seguido la
capacitación planeada para Ubiquando para tal fin, y haber entendido los
conceptos básicos de análisis multidimensional que expone este documento.
Roles de usuarios.
La aplicación del datamart define dos roles usuarios: Analista y administrador.
Funciones de cada rol.
Administrador. Tendrá acceso a todas las funciones básicas de la aplicación,
es decir, ingreso y exploración. Adicionalmente podrá modificar el archivo
Propiedades.txt para modificar las propiedades y usuarios de la base de datos.
Analista: Tendrá acceso a las funciones de análisis de la aplicación: ingreso,
visualización de consultas.
28
6. NAVEGANDO EN EL DATAMART
Mondrian es una herramienta supremamente robusta en cuanto al manejo de
hipercubos y tratamiento de bases de datos se refiere.
•
El usuario de mondrian debe tener conocimientos básicos de OLAP,
generación y uso de hipercubos e inteligencia de negocios y administración.
Por lo general, las Herramientas OLAP son dirigidas a usuarios que toman
decisiones, como ejecutivos, gerentes o buzos de información. Por lo tanto son
herramientas que permiten una interacción relativamente sencilla con el
usuario, permitiéndole generar un cubo gráficamente o hacer gráficas con los
resultados sin mayores conocimientos técnicos.
El menú principal del datamart es el que se presenta a continuación:
Figura 7. Menú principal del datamart
Dicho menú muestra en su lado izquierdo la opción del datamart de Ubiquando.
Al apuntar con el puntero del Mouse sobre esta opción, se despliega la opción
“Análisis de ventas”. Para ingresa al reporte se da clic en el nombre de esta
opción.
Para explicar los modos y opciones de navegación en la herramienta se
seguirá el proceso de realizar un reporte típico.
Luego de entrar a la opción “Análisis de ventas” se muestra el primer resultado,
que ha sido predeterminado para mostrar las ventas por productos. Esta vista
se encuentra en la siguiente figura.
29
Figura 8. Reporte predeterminado del datamart
En esta vista se determina que está involucrada la dimensión Producto y la
medida Valor. En este ejemplo se ve el valor total vendido por todos los
productos.
Figura 9. Barra de herramientas OLAP de Mondrian
Para poder interactuar con los reportes se utiliza la barra de herramientas de
mondrian:
Los nombres de los botones son los siguientes:
•
Navegador OLAP
•
Editor de MDX
•
Mostrar Miembros Padre
•
Detallar miembros padre
•
Ocultar celdas vacías
•
Intercambiar filas por columnas
30
•
“Taladrar” miembro
•
“Taladrar” posición
•
“ Taladrar” reemplazando
•
“Taladrar a través”
•
Mostrar Gráfica y Configurar Gráfica
•
•
Imprimir en PDF y configurar Impresión
Exportar a Excel
Salir al menú Principal
Se continúa el ejemplo haciendo clic sobre el botón Navegador Olap, que
muestra un menú con las dimensiones del cubo que pueden ser utilizadas para
generar el reporte.
31
Figura 10. Dimensiones disponibles para el análisis OLAP
En este caso, en las columnas del reporte se tiene la medida (valor) y en las
filas la dimensión Producto. En la parte que dice Filter se encuentran todas las
dimensiones del cubo que no intervienen directamente en la consulta
específica. De allí, con ayuda de los iconos auxiliares se pueden ubicar las
dimensiones en las columnas o las filas dependiendo del criterio del analista.
En este mismo menú se puede ver como está compuesta una dimensión,
haciendo clic sobre su nombre. La figura 11 muestra cómo se describe la
dimensión Producto al hacer clic sobre su nombre.
Figura 11. Composición de la dimensión Producto
Se puede ver que esta dimensión tiene dos niveles, con cinco miembros, que
son: Asesora, Capacitación, Desarrollo, Instalación y Soporte. Si se quiere
hacer una consulta que involucre a solo uno o varios miembros, se seleccionan
las casillas de verificación correspondiente a los miembros requeridos en la
consulta.
Usando el botón de “intercambio filas por columnas” se intercambian las
dimensiones de lugar. A continuación se va a navegar un nivel más abajo en la
32
dimensión Producto. Para esto se da clic en el signo “+” que acompaña el nivel
“ALL” de la dimensión:
Figura 12. Drill down aplicado a la dimensión producto. De lo general (Producto) se va a analizar lo
particular (Asesoria, Capacitacion, Desarrollo, Instalacion, Soporte)
En el análisis aparecen ahora todas las categorías de productos.
Si existiesen celdas sin valor, se puede oprimir el botón “Ocultar celdas vacías”,
y de este modo se ocultarán los renglones en el reporte para los que no halla
una medida. En este caso, los renglones donde el valor de venta es 0.
En este navegador Olap se puede escribir una consulta MDX (explicado
anteriormente) por líneas de código para realizar un reporte específico.
Normalmente no se escribe código para realizar las consultas, pues este
código es generado automáticamente por la herramienta cuando se navega y
se escogen opciones utilizando el Mouse. Sin embargo, si el usuario es
avanzado puede especificar directamente los criterios del reporte.
Figura 13. Inserción de código MDX para generar consultas
Hay otra serie de botones que prestan servicios de visualización de los padres
de un miembro. El primero de ellos es el botón de “Detallar miembros padre”.
Cambia la tabla de tal forma que al lado derecho en un solo bloque se
muestren los padres del miembro.
Al utilizar esta opción en el ejemplo seguido se muestra la siguiente tabla.
33
Figura 14. Opción “Detallar miembros padre” activada
El botón “Detallar miembros padre” especifica el padre de cada miembro en su
lado izquierdo, como se ve en la siguiente figura 14, donde el padre de las
cinco categorías de productos es Producto.
La siguiente es una de las funcionalidades más útiles de la herramienta, pero
igual que todo en OLAP depende del modelamiento de la base de datos. Se
llama Drill through o “taladrar a través”, y consiste en poder observar el detalle
de determinada celda del cubo. Este detalle será tan específico como
específicos sean los datos en la base de datos.
Cabe aclarara que esta función no aplica en el caso de las sumarizaciones, por
la razón anterior, ni cuando se trabaja con miembros o medidas calculadas
como porcentajes o promedios.
Se puede solamente obtener el detalle de los hechos.
Luego de seleccionar la opción de taladrar, se da clic en la flecha verde que
aparece al lado del valor de cada miembro. Al hacer clic en la flecha
correspondiente al miembro Desarrollo de obtiene el siguiente resultado.
Si se da clic sobre el botón “E” sobre la tabla de drill through, se puede
configurar esta tabla de una mejor manera. Permitiendo establecer los campos
que aparecerán en el reporte.
Figura 15. Opción “drill through” activada para la dimensión Desarrollo.
34
Por último se encuentran los botones de despliegue gráfico y exportación. Si se
utiliza la opción “mostrar gráfica”, se despliega un gráfico que muestra los
datos que están en ese momento expresados en la tabla
Figura 16. Reporte gráfico de la consulta
Este gráfico se puede configurar con el siguiente botón, de configurar la gráfica:
Figura 17. Configuración de la gráfica, con múltiples opciones de gráficos.
En la opción Chart Type se encuentran los tipos de gráficas más comunes y
útiles en reportes, como líneas verticales, horizontales, bloques, pies, entre
otros. También es posible configurar las leyendas y el tamaño y tipo de letras
de ellos, como también el tamaño de la gráfica.
35
El botón de “imprimir en PDF” es el que continúa.
Al oprimir este botón se crea un archivo PDF que se puede guardar en el disco
duro o se puede abrir. Dicho pdf se puede configurar con el siguiente botón.
Figura 18. Configuración del archivo PDF de exportación.
Las opciones para configurar el pdf incluyen darle un titulo al reporte, escoger
el tamaño de la página, la orientación de la hoja y elegir la forma de incluir la
gráfica en el pdf.
Por último se encuentra la funcionalidad de exportar a Excel, con lo que se crea
un archivo que se puede almacenar en el disco duro o ser abierto directamente.
Este archivo Excel exporta los valores de la tabla que se este visualizando en
el momento de la exportación.
El último botón da la opción de regresar al menú principal.
36