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.DATAWAREHOUSE ...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.HERRAMIENTASDEBASESDEDATOSYOLAP ...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.METODOLOGIADERALPHKIMBALLPARAUNPROYECTODEDATAWAREHOUSE ...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ÓNYADMINISTRACIÓNDELPROYECTO ...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ÁLISISDEREQUERIMIENTOS ...44
5.1 Levantamiento de requerimientos ...44
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.MODELAMIENTODIMENSIONAL ...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ÑOTECNICODELAARQUITECTURA...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.PROCESODEEXTRACCIÓN,TRANSFORMACIÓNYCARGA ...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ÓNDELCUBO ...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.REPORTESIMPLEMENTADOS...67
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.MANTENIMIENTOYCRECIMIENTODELDATAMART ...78
CONCLUSIONES ...79
RECOMENDACIONES ...81
GLOSARIO ...82
BIBLIOGRAFÍA ...83
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
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.
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.
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.
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
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.
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
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
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.
• 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.
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,
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 objeto- relacionales. 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.
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
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.
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
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
y tienda son dimensiones.
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:
• 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
5 [14] About Kimball Group
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
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:
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.
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.
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.
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.
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
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.
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. El datamart.
2. La granularidad de la tabla de hechos.
3. Las dimensiones.
4. 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?
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
