Universidad de las Ciencias Informáticas
Facultad 4
Título: Modelo y diseño de un Data Warehouse utilizando vistas materializadas.
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autora:
Heidy Carmona Lora Tutores:
Lic. Eddy Manuel Infante Alonso Ing. Julio Cesar Díaz Vera
Ciudad de la Habana
Julio del 2007
Declaración de Autoría
Declaro que soy el único autor de este trabajo y autorizo al <nombre área>
de la Universidad de las Ciencias Informáticas a hacer uso del mismo en su beneficio.
Para que así conste firmamos la presente a los ____ días del mes de ________ del año ________.
___________________________
Heidy Carmona Lora Autor
____________________________ ___________________________
Lic. Eddy Manuel Infante Alonso Ing. Julio Cesar Diaz Vera Tutor Tutor
Agradecimientos
A la Revolución, por darme la posibilidad de realizar mis sueños, por permitir mi formación profesional, por hacerme una persona triunfadora.
A la UCI, por ser mi hogar, por brindarme tantos buenos momentos, por darme la posibilidad de desarrollarme como persona.
A Eddy y a Julio, por su asesoramiento tanto en la investigación como en el estudio, por su apoyo, por ser los mejores tutores que pude tener.
A mami por creer en mi, por su apoyo, confianza y sacrificio, por ese amor brindado cada día de mi vida, por ser no solo madre sino también amiga, gracias.
A mi hermana, por esa forma tan especial de quererme y brindarme su apoyo, por siempre estar ahí para mí, te quiero mucho.
A mi abuela, por su amor desmedido, por su fe en mi, por demostrarme que siempre hay que seguir hacia adelante, gracias por todo.
A mi tío el Dr. Guzmán, por ser un ejemplo a seguir, por su experiencia, por ayudarme y enseñarme, por ser sobre todas las cosas un padre para mí.
A mi tía Mirna por siempre estar ahí en las buenas y en las malas, ¿cómo no agradecerte todo lo que has hecho por mí?
A mi familia en general por todo el apoyo brindado en cada momento de mi vida.
A Mabel, Daymara, Dayami y Ana, por haberme dado un grandioso quinto año, por su amistad.
A Hayron, a Michel y Nolber, gracias por la ayuda brindada.
A Elvio, Yunior y Osniel por esos momentos brindados, gracias por su amistad.
A todos los que de una forma u otra hicieron mi estancia más placentera en esta universidad.
Dedicatoria
A mami, a mi hermana, a mi abuela, al Dr. Guzmán y a todos, los que siempre están.
Resumen
Un Data Warehouse facilita la compresión de los datos, transformándolos en información útil y sirviendo de apoyo a la toma de decisiones. Sin embargo se encuentra el problema del costo excesivamente alto de los proyectos Data Warehouse. Para reducir el costo de los proyectos de Data Warehouse es que surge como una alternativa factible el proceso de virtualización del mismo mediante, vistas materializadas, dicho proceso trae consigo el problema del consumo excesivo de espacio de almacenamiento.
La reducción del tiempo de la consulta mediante la selección de un sistema apropiado de vistas materializadas con un bajo costo de almacenamiento es crucial para un eficiente Data Warehouse.
Este trabajo, propone la utilización de un algoritmo eficiente para seleccionar un conjunto apropiado de vistas materializadas, que contemple las consideraciones de almacenaje y de costo de almacenamiento, y que explote con eficacia la ganancia y pérdida métrica.
Palabras claves
Data Warehouse, vistas materializadas, vistas.
Índice de contenido
Introducción ... 1
CAPITULO 1: Fundamentación teórica... 4
1.1 Data Warehouse y sus características... 4
1.2 Importancia de la arquitectura de un Data Warehouse... 7
1.3 Diferentes criterios sobre el Data Warehouse ... 10
1.4 Diferentes gestores de bases de datos... 13
1.4.1 Algunos gestores de bases de datos: ... 13
1.4.2 ¿Qué diferencias hay entre los diferentes gestores?... 15
1.4.3 Comparación entre diferentes gestores: ... 16
1.5 Data Warehouse y vistas materializadas. ... 18
CAPITULO 2: Proceso de virtualización de un DWH... 23
2.1 Selección de las vistas a materializar ... 24
2.1.1 Descripción resumida de los algoritmos de (J. Yang 1996): ... 25
2.1.2 Algoritmo A* y BUPS:... 29
2.1.2.1 Definición del problema... 29
2.1.2.2 Descripción de los algoritmos A* y BUPS. ... 30
2.1.2.3 Análisis y comparación entre los algoritmos A* y BPUS:... 33
2.1.3 Algoritmo Counting y algoritmo DRed:... 38
2.1.3.1 Descripción del algoritmo Counting:... 39
2.1.3.2 Descripción del algoritmo DRed:... 39
2.1.3.3 Análisis del algoritmo counting:... 40
2.1.4 Lattice framework... 44
2.1.4.1 El vector de estructura de datos... 45
2.1.4.2 Aplicación del vector de estructura de datos... 46
2.1.4.3 Reescritura de la consulta... 46
2.1.4.4 El modelo propuesto de costo... 47
2.1.4.5 Los algoritmos propuestos de la selección ... 54
CAPITULO 3: Caso de estudio. ... 61
Conclusiones ... 72
Recomendaciones ... 73
Referencias bibliográficas... 74
Glosario de Términos ... 76
Índice de figuras
Figura 1 Modelo de Kimball ... 11
Figura 2 Modelo de Inmon... 12
Figura 3 Plano de acceso individual para las consultas 1 y 2. ... 26
Figura 4 Plano de acceso combinado para las consultas 1 y 2... 27
Figura 5 Un MVPP para el ejemplo. ... 28
Figura 6 Cuboide ... 34
Figura 7 Costo contra restricción (primera prueba) ... 35
Figura 8 Utilización del espacio (primera prueba) ... 36
Figura 9 Costo contra restricción (segunda prueba). ... 36
Figura 10 Restricción contra espacio (segunda prueba). ... 37
Figura 11 Tiempo contra restricción ... 37
Figura 12 Modelo del VIRTUA... 43
Figura 13 Relación entre pieza, surtidor y cliente... 45
Figura 14 Lattice framework del cubo de datos... 45
Figura 15 Representación del lattice para un cubo de datos. ... 46
Figura 16 Lattice framework más complejo. ... 52
Figura 17 Representación visual del algoritmo MPL. ... 56
Figura 18 Representación visual del algoritmo MPL-CV. ... 56
Figura 19 Relación entre individuos, datos de estancia, ubicación geográfica y expediente. ... 68
Figura 20 Lattice framework del cubo de datos... 68
Figura 21 Representación del lattice para el cubo de datos... 70
Índice de tablas
Tabla 1 Información general de los diferentes gestores... 16Tabla 2 Soporte del sistema operativo. ... 17
Tabla 3 Características fundamentales de los gestores... 17
Tabla 4 Tablas y vistas. ... 17
Tabla 5 Indices. ... 18
Table 6 Otros objetos ... 18
Tabla 7 Definición de los símbolos del modelo de costo propuesto... 49
Tabla 8 Prueba de los datos para el experimento con w = 0... 52
Introducción
Desde el inicio de la era de la computadora, su evolución a través del tiempo se hace cada vez mas evidente y algunas organizaciones aun manejan una data no limpia e inconsistente, sobre las cuales se toman decisiones sumamente importantes, por lo que se reconoce que una manera de elevar su eficiencia es hacer un mejor uso de los recursos de información.
Las empresas enfrentan en este momento un creciente enfrentamiento potenciado por la gran competencia de los mercados cada vez más insaciables. Este hecho fomenta su competitividad llevándolas a reestructurar sus modelos de negocio.
Para obtener sistemas de información capaces de tener variantes de producción y estimar indicadores más precisos en tiempo real es necesario la regeneración de procesos y la automatización. De este modo, se colocaran a disposición de los agentes de decisión un conjunto de herramientas y mecanismos de control, incluidos en sistemas de soporte de decisiones. Este nuevo tipo de sistemas va evolucionando de forma clara todas las etapas de un proceso de toma de decisión, ofreciendo un acceso privilegiado a la información de mayor importancia para las actividades del negocio de una empresa.
Los sistemas de soporte de decisiones tienen el papel de integrar toda la información interna y externa en una única plataforma de datos. El objetivo primordial es tener disponible la información necesaria a los agentes de decisiones durante el proceso de toma de decisiones, en las diversas vertientes del negocio. Actualmente se tiende a un aumento de la inversión en investigaciones y al desenvolvimiento de técnicas de optimización. Estas técnicas son utilizadas para el mejoramiento del desempeño de los sistemas de información.
Al tener en cuenta la naturaleza cambiante de los datos, el mundo tiende al análisis integrado de ellos para gestionar sus enormes cantidades. Muchas empresas utilizan Data Warehouse porque integra datos en un solo depósito desde el cual los usuarios terminales pueden fácilmente ejecutar consultas, confeccionar reportes y realizar análisis, además de ser un ambiente para la toma de decisiones, que refuerza los datos almacenados en diferentes fuentes, organizándolos y poniéndolos a disposición de los
encargados de esta responsabilidad en la empresa. En esta tecnología no existen alternativas libres de implementación y los gestores Oracle y SQLServer, comercializan las herramientas de Data Warehouse como módulos de sus gestores que deben ser adquiridos de manera independiente lo cual incrementa el costo de estos productos que ya tienen un precio excesivamente alto en el mercado, por lo que es bastante difícil para empresas pequeñas la utilización de esta tecnología.
Esta técnica es utilizada para la recuperación y la integración de los datos a partir de fuentes distribuidas, autónomas y posiblemente heterogéneas. Los datos son almacenados en un gran deposito llamado Data Warehouse, que resume los datos que son organizados en dimensiones, disponiéndolos para consultas y análisis a través de aplicaciones OLAP y sistemas de soporte de decisiones.
Es de uso frecuente para apoyar el proceso analítico en línea (OLAP), y aumentar estas consultas, almacenar algunos resultados intermedios de la consulta que procesa el Data Warehouse. A estos resultados intermedios almacenados en un Data Warehouse se le llaman vistas materializadas. Es decir, que puede verse un Data Warehouse como un conjunto de vistas materializadas obtenida a través de una o más fuentes de datos.
Puesto que una consulta puede producir muchos resultados intermedios, una de las decisiones importantes en diseñar un almacén de los datos es seleccionar las vistas más convenientes. Si el espacio disponible es suficiente, se quisiera materializar todas las vistas posibles por adelantado para acelerar el proceso de la consulta de un Data Warehouse.
Este trabajo se centrará en el proceso de modelado de un Data Warehouse a partir de la utilización de vistas materializadas. Con el, se le dará solución a la interrogativa de
¿como disminuir el costo de los proyectos Data Warehouse a partir de un modelo de implementación virtual del mismo usando las vistas materializadas?
El objetivo principal es la propuesta de un modelo para la implementación de un Data Warehouse a partir de vistas materializadas, para lo cual se realizará el diseño del Data Warehouse a partir de la utilización de vistas materializadas.
Si se logra modelar un Data Warehouse para implementarlo utilizando vistas materializadas entonces se podrá reducir el costo de los proyectos de implementación.
Hipotéticamente si se cuenta con un Data Warehouse estructurado a partir de vistas materializadas, entonces se minimizará el tiempo de respuesta de las consultas y se reducirá el costo de los proyectos por contar con una herramienta para implementar de forma más eficiente las consultas de sistemas de soporte de decisiones.
Variable Independiente:
Modelo de implementación de un Data Warehouse a partir de vistas materializadas.
Variable Dependiente:
Reducción del costo de los proyectos de implementación.
Se propone en el desarrollo de este trabajo la selección exhaustiva de la bibliografía. Se investigará acerca de las características y facilidades que brinda la utilización de un Data Warehouse, además se estudiará e investigará sobre diferentes algoritmos para la selección de las vistas materializadas. También, se investigará sobre las facilidades que brinda la utilización de las vistas materializadas para crear un Data Warehouse.
1:
CAPITULO Fundamentación teórica
Este capítulo brindará un acercamiento a la descripción de un Data Warehouse, enfatizando en sus características principales y la importancia de su arquitectura, además de comparar los diferentes criterios que existen acerca de la creación de un Data Warehouse. Se ofrecerá una breve descripción de los gestores de bases de datos y se establecerá una breve comparación entre ellos, además de la relación que existe entre un Data Warehouse y las vistas materializadas.
Las empresas de hoy en día se caracterizan por sus estructuras de conducción dinámicas, donde los individuos que las componen deben tomar decisiones en forma rápida y efectiva basados en la última información disponible, para poder así mantener la ventaja competitiva. Por otro lado, las compañías están acumulando grandes volúmenes de datos en sus bases de datos operativas a un ritmo que, en promedio, se duplica cada año. Aún así, sólo el 7% de estos datos es aprovechado para obtener una ventaja en las decisiones de negocios. Recién ahora las organizaciones se están dando cuenta de que existe una significativa cantidad de información que puede ser extraída de sus bases de datos, necesaria para soportar las decisiones que deben ser tomadas por sus ejecutivos, llegando así al concepto de Data Warehouse.
1.1 Data Warehouse y sus características.
El Data Warehouse, es actualmente, el centro de atención de las grandes instituciones, porque provee un ambiente para que las organizaciones hagan un mejor uso de la información que está siendo administrada por diversas aplicaciones operacionales.
Es una colección de datos que se encuentra formada por la información de la empresa y se usa como soporte para la toma de decisiones. Para acelerar el proceso de análisis, consultas y acceder a la información en el menor tiempo posible, es necesario reunir los datos apropiados desde las diversas bases de datos.
Las aplicaciones para soporte de decisiones basadas en un Data Warehouse, pueden hacer más práctica y fácil la explotación de datos para una mayor eficacia del negocio, que no se logra cuando se usan sólo los datos que provienen de las aplicaciones operacionales (que ayudan en la operación de la empresa en sus operaciones
cotidianas), en los que la información se obtiene realizando procesos independientes y muchas veces complejos.
En sí, un Data Warehouse es una colección de datos integrada, orientada a sujetos, variante en el tiempo y no volátil, utilizada como apoyo para los procesos de toma de decisión.
Para comprender lo que expresa esta definición es necesario detenernos en cada uno de los calificadores.
• Integrada: Contiene una base de datos centralizada y consolidada que integra datos derivados de toda la organización. Los datos se almacenan en un formato consistente y existe un único esquema de representación.
• Orientada a sujetos: Los datos se organizan y se resumen por temas, tales como ventas, finanzas y transportación, para cada uno de los cuales el Data Warehouse contiene sujetos, tales como productos, compradores y regiones. Por tanto, un Data Warehouse se enfoca a las entidades del negocio, lo cual contrasta con los sistemas operacionales que se orientan a los procesos.
• Variante en el tiempo: Los datos se asocian con un punto en el tiempo o con un período. La toma de decisiones se apoya en diferentes modelos (estadísticos o de otro tipo) que necesitan información histórica. Esta característica básica de los datos en un Data Warehouse difiere del comportamiento en el ambiente operacional donde los datos reflejan exactamente el momento actual.
• No volátil: Los datos no se modifican una vez introducidos (solo lectura). Ello permite la optimización del acceso a los datos, puesto que el sistema no tiene que efectuar frecuentemente los chequeos de integridad requeridos por las operaciones de modificación. Además, se garantiza la disponibilidad de datos históricos.
El almacenamiento de los datos es un acercamiento para integrar la información de múltiples bases de datos operacionales, muy grandes, distribuidas, y heterogéneas. Un Data Warehouse es un depósito de datos que proporciona un ambiente integrado para las preguntas y el análisis de la toma de decisiones que requiere agregaciones complejas de cantidades enormes de los datos históricos.
Los Data Warehouses son muy utilizados por muchas empresas de todo el mundo, ya que proporcionan una fundación sólida de integración de los datos corporativos e
históricos para la realización de análisis gerenciales. Su construcción e implementación se realiza paso a paso, organizando y almacenando los datos sobre una perspectiva a largo plazo.
Así partiendo de los datos históricos básicos se puede realizar el análisis de tendencias.
Por sus características básicas, integran los datos provenientes de varias fuentes diferentes, la etapa mas compleja de implementación de un Data Warehouse es el proceso de carga. En este proceso, los datos distribuidos por varios ambientes operacionales (bases de datos de producción que contienen los datos utilizados por varios sistemas de una empresa) deben ser seleccionados, trabajados con el objetivo de estandarizarlos y limpiarlos, transferirlos para un nuevo ambiente y finalmente sean cargados, siempre atendiendo al estándar de modelación utilizado para el Data Warehouse. Este proceso se hace periódicamente, siendo su frecuencia dependiente de varios factores relacionados al modelo de negocio utilizado por la empresa. De esta forma se puede decir que los datos almacenados en el Data Warehouse son para todos los propósitos prácticos. Una vez que los datos son almacenados en el Data Warehouse no sufren actualizaciones, siendo, por tanto un ambiente de carga y acceso.
Un Data Warehouse se crea, al extraer datos desde una o más bases de datos de aplicaciones operacionales, tanto internas como externas. La data extraída es transformada para eliminar inconsistencias y resumir si es necesario y luego, cargarlas en el Data Warehouse. El proceso de transformar, crea el detalle de tiempo variante, resume y combina los extractos de datos, ayudando a crear el ambiente para el acceso a la información Institucional. Luego en el proceso de carga se organiza y actualiza los datos obtenidos de las bases de datos y por último, y no menos importante el proceso de explotación que es en el cual se extrae y se analiza la información almacenada en el Data Warehouse. Este nuevo enfoque ayuda a las personas individualmente, en todos los niveles de la empresa, a efectuar su toma de decisiones con más responsabilidad.
Desde el punto de vista del usuario, el único proceso visible es la explotación, aunque el éxito del Data Warehouse radica fundamentalmente en los tres primeros procesos que alimentan la información del mismo y proporcionan el mayor porcentaje de esfuerzo (en torno a un 80%) a la hora de desarrollar el Data Warehouse.
Después de su creación y la primera carga, el Data Warehouse pasa a sufrir cargas incrementales que debe reflejar el ambiente operacional a lo largo del tiempo tornándose en una inmensa bases de datos para los sistemas de apoyo y decisiones.
Las empresas para mantenerlo, dejan el Data Warehouse disponible para lectura, a través de consultas durante el día, mientras durante la noche permanece indisponible, de forma tal que se pueda realizar el proceso de mantenimiento. Se torna claro, que un Data Warehouse en la gran mayoría de los casos tiene características de un ambiente estático.
En varias áreas del negocio los análisis son basados en resúmenes mensuales, ejemplo de ello es que la alta complejidad en el proceso de carga se transforma en un punto muy susceptible para la introducción de errores y puede llevar al colapso de todo un proceso de toma de decisiones. También la empresa al pasar por proceso de globalización necesitan de un Data Warehouse disponible el mayor tiempo posible, por lo que es importante la implementación de alternativas que reduzcan al máximo el tiempo necesario para la manutención o que se permita que el proceso de manutención sea ejecutado de forma concurrente a las consultas de usuarios, garantizando, sin embargo la consistencia de acceso al Data Warehouse.
Al Data Warehouse sufrir nuevas cargas constantemente, va aumentando su tamaño y debido a esto al utilizarlo aumenta la dificultad de responder las consultas de los usuarios de forma rápida y eficiente.
La alta complejidad del proceso de carga, la prolongada disponibilidad de un Data Warehouse, aliadas a sus características estáticas y las necesidades de mejorar el modelo de datos implementado, busca el análisis de algunas de las alternativas disponibles para una implementación más eficiente y dinámica de un Data Warehouse.
1.2 Importancia de la arquitectura de un Data Warehouse.
El concepto Data Warehouse es sustancial, porque es entendido como la plataforma que concentra toda la información de interés para la organización, sus fuentes de información son tanto las bases de datos corporativas, como otras fuentes externas.
El uso de esta herramienta de suma importancia para el mundo financiero, ya que es mucho más sencillo decidir cuándo invertir, en dónde invertir, en qué productos invertir.
Sin duda es una herramienta que hará ahorrar varios miles de pesos a la organización.
Para el área de operaciones, el tema de los inventarios es de vital importancia. Con el uso de un Data Warehouse, se estaría asegurando en cierta manera, que los inventarios nunca se inflarán de más, y que tampoco faltará mercancía.
El contar con una herramienta de soporte a las decisiones es de gran utilidad para las empresas, en especial en el sector minorista, en donde la competencia es cada vez más agresiva, sobre todo con la entrada de las grandes compañías transnacionales.
En nuestros días, la información es un arma estratégica en los ambientes de negocio, pero acceder fácilmente a los datos, analizarlos y convertirlos en información útil no es una tarea sencilla. Un Data Warehouse se diseña para resolver los problemas que los usuarios terminales enfrentan continuamente al trabajar con los datos.
Las herramientas tradicionales de acceso y análisis de los datos no son adecuadas para manipular los grandes volúmenes de información actuales, por lo que se pueden presentar algunas de las dificultades siguientes cuando se necesita información:
Una vista no única de los datos:
Con frecuencia existe la necesidad de saber qué datos están accesibles, dónde y cómo obtenerlos. En ocasiones, los datos se definen por las áreas que los manejan sin tomar en consideración los requerimientos de otras dependencias o las interrelaciones existentes con otros datos de la organización. Así mismo, los datos también pueden duplicarse sin el debido control para aplicaciones específicas. Estas múltiples representaciones expresan un alto grado de redundancia y, por ende, la posibilidad de la existencia de las anomalías de inconsistencia relacionadas con ella.
Diferentes herramientas de usuarios:
Los datos pueden estar ubicados o no en almacenes diferentes y se pueden acceder o no utilizando herramientas de usuario distintas. Incluso, algunas de estas herramientas pueden responder a departamentos locales y, otras, a la organización. En cualquier caso, el empleo de diversas herramientas obliga a que el usuario terminal tenga que asimilarlas.
Problemas de consistencia:
Una vez que el usuario accede a los datos, necesita entenderlos. Usualmente el mismo dato se diferencia de una fuente a otra, quizás en su definición, formato, significado, u otros. Esto contribuye a que se dificulte su combinación y su comparación.
Carencia de datos históricos:
Muchos usuarios necesitan mantener los datos a través del tiempo, registrar los eventos que causan los cambios en los datos y otras informaciones útiles para la toma de decisiones. Generalmente, los sistemas operacionales no manejan información histórica aunque, en ocasiones, archivan datos en varios medios externos como copias de seguridad. Si no existe un tratamiento consecuente de los datos históricos, esta diversidad de soportes puede provocar problemas con el acceso a la información histórica, tales como incongruencia en las versiones, ausencia de datos, desorganización, entre otras.
Conflicto entre tipos de aplicaciones:
Es común que los sistemas operacionales y los sistemas informacionales utilicen una base de datos de forma compartida. Ahora bien, los objetivos de ambos tipos de sistemas son diferentes y no es recomendable que trabajen simultáneamente sobre los mismos datos. Los sistemas informacionales están dirigidos a la consulta de los datos, mientras que los operacionales realizan con frecuencia modificaciones de los datos. Esto puede provocar un conflicto en los resultados que obtienen las aplicaciones.
Problemas en la administración de los datos:
Existen múltiples y complejos tipos de datos en los sistemas operacionales, cada uno soportado por herramientas que, a su vez, también son múltiples y complejas. En este sentido se destaca la carencia de una estructura común, así como la falta de un punto único de control administrativo.
El Data Warehouse se ha convertido en la herramienta idónea para ayudar a los ejecutivos a tomar las decisiones apropiadas, que les permitan seguir compitiendo en el mercado. La innovación de la tecnología de información dentro de este, puede permitir a cualquier organización hacer un uso mas optimo de los datos, como principal elemento para una la toma de decisión de forma más efectiva.
Las organizaciones tienen que aprovechar sus recursos de informáticos para crear la información de la operación del negocio, pero deben considerarse las estrategias
tecnológicas necesarias para la implementación de una arquitectura completa de Data Warehouse.
1.3 Diferentes criterios sobre el Data Warehouse
El término Data Warehouse fue acuñado por Bill Inmon a principios de la década de los
´90 y lo definió de la siguiente manera:
“Un Data Warehouse es una colección de datos orientado a sujeto, integrado, variante en el tiempo y no volátil para ayudar al proceso de toma de decisiones gerenciales“.
Obviamente que esta definición, ya clásica, debe tomarse como la definición “pura” sobre Data Warehouse. Después de diez años, sin embargo, algunos términos han sido manejados según las necesidades y capacidades del mercado, dando origen a conceptos como el de Data Mart o Data Warehouse volátiles, que ante la imposibilidad de almacenar toda la información histórica, almacenan una foto sobre determinado período.
Ralph Kimball define Data Warehouse de una forma más sencilla y práctica pero igual de importante, un Data Warehouse es:
“Una copia de los datos transaccionales específicamente estructurados para consultas y análisis”.
Se puede decir que un Data Warehouse es una base de datos, orientada al análisis de la información histórica contenida en ella. Dependiendo las necesidades de análisis de la organización, puede almacenarse desde unos meses hasta varios años la información.
El modelo que soporta la información que contiene, se encuentra diseñado, estructurado e implementado con la finalidad y propósito del análisis y navegación de los datos.
Se entiende por navegación, la posibilidad de ver información correspondiente a diferentes contextos o entornos, por ejemplo, analizar las ventas anuales y poder
“abrirlas” por sucursal, después, analizar en más en detalle una sucursal para ver cómo se discriminan las ventas por cada producto.
La “lucha" Kimball contra Inmon es bien conocida. Kimball aseguro en 1997 su modelo multidimensional era "la única manera viable de diseñar bases de datos destinadas a su uso directo por parte de un usuario final".
Casi todos le siguieron la corriente, pero obviamente algunos valientes se le tiraron a la yugular entre ellos Inmon en el año 2000 cuando dijo que… “si diseñas un Data Warehouse desde el punto de vista de análisis de un solo individuo, condenas al resto a su mismo punto de vista y que difícilmente en el modelo dimensional puedes incluir información no incluida en el foco original del análisis”.
En este ámbito la creación de los Data Warehouse tienen dos grandes gurús, por un lado el archiconocido Kimball con su modelo multidimensional, y por el otro el quizás menos conocido, pero no menos importante Inmon.
Estilo Kimball:
Figura 1 Modelo de Kimball
El modelo de Kimball es mas corporativo en el que un proceso ETL (Extracción, Transformación, y Carga), nutre un espacio Data Warehouse en el que se comparten las dimensiones entre diferentes puntos de vista y en el que los Data Marts de cada departamento se forman utilizando los hechos y las dimensiones ya establecidas para toda la compañía.
Estilo Inmon:
Figura 2 Modelo de Inmon
Coincide con Kimball en un único proceso ETL que nutra un Data Warehouse corporativo, pero el que el nutre no es dimensional es un Data Warehouse basado en el Modelo Entidad-Relación.
La idea de Inmon es que el Modelo Entidad-Relación es mucho más rico y adaptable que el multidimencional.
Una vez que se tiene el Data Warehouse Entidad-Relación corporativo se genera los Data Marts dimensionales que se quiera, y no solo eso, nos puede servir para crear cualquier otra extracción para cualquier otro sistema de toma de decisiones, como puede ser para minería de datos o para sistemas expertos.
Inmon no se cierra a un solo modelo y no solo eso, además su arquitectura mejora la trazabilidad decisional. Con ella se puede desgranar un valor hasta una serie de análisis y reportes que lo expliquen en detalle, tan en detalle como permiten los modelos Entidad- Relación que se tienen en nuestros sistemas operacionales.
Parece maravilloso, pero el problema es que es más costoso de mantener y de implementar. El de Inmon es un modelo que mira a largo plazo y para una metodología ágil el largo plazo es secundario.
El modelo de Kimball es más eficiente en ese aspecto porque es metodología con la rapidez necesaria para realizar un Data Warehouse a corto plazo. Es mas fácil de entender el proceso para llevar a cabo la creación del Data Warehouse y garantiza un mayor rendimiento debido a que el Data Warehouse esta compuesto por Data Mart que
solo esta orientado a una sola actividad y no satisfacen las necesidades de toda la empresa, solo se centra en su objetivo.
1.4 Diferentes gestores de bases de datos
En informática existen los sistemas gestores de bases de datos (SGBD), que permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Los sistemas de gestión de base de datos son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan.
Los SGBD manejan de grandes volúmenes de información con una gran velocidad, es decir en poco tiempo. Trata la información de manera independiente y no hay duplicidad de esta, además de asegurar la protección de la información. Aunque existen varios inconvenientes como el costo de actualización del hardware y software que hoy en día son de muy elevados precios en el mercado, además del elevado pago a los administradores de bases de datos, el mal diseño de las bases de datos que pueden producir en un futuro problemas y el mal adiestramiento de los usuarios.
Existen muchas formas de manejar informáticamente las bases de datos: con Access, Oracle, SQL, PostgreSQL o MySQL, entre otros. Cada sistema tiene sus características, sus ventajas y sus inconvenientes, la elección de uno u otro sistema para gestionar nuestra base de datos vendrá definida por nuestras necesidades.
Un sistema de gestión de bases de datos constituye el núcleo de la base de datos, contiene todas las rutinas necesarias para la gestión de los datos. Siendo una base de datos como un sistema de captación y mantenimiento de registros de forma computarizada, en este sistema se van a poder realizar las operaciones de inserción, borrado y modificación de un dato y modificaciones, borrados e inserciones de información de la estructura de la base de datos.
1.4.1 Algunos gestores de bases de datos
:
PostgreSQL es un motor de base de datos, es servidor de base de datos relacionales, conjunto de dos o mas tablas estructuradas en registros (líneas) y campos (columnas), que se vinculan entre sí por un campo en común, en ambos casos posee las mismas características como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave.
PostgreSQL permite que mientras un proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos. Cada usuario obtiene una vista consistente de lo último a lo que se le hizo commit. Esta estrategia es superior al uso de bloqueos por tabla o por filas común en otras bases, eliminando la necesidad del uso de bloqueos explícitos.
También adicionalmente los usuarios pueden crear sus propios tipos de datos, los que pueden ser por completo indexables gracias a la infraestructura GiST de PostgreSQL.
MySQL es un sistema de gestión de base de datos, multihilo y multiusuario, es un bibliotecario computarizado que administra, gestiona, y opera con nuestros ficheros de datos. Si se le habla en un idioma que entienda los devolverá ordenados, clasificados, seleccionados o ambos inclusive.
Inicialmente, MySQL carecía de elementos considerados esenciales en las bases de datos relacionales, tales como integridad referencial y transacciones. A pesar de ello, atrajo a los desarrolladores de páginas Web con contenido dinámico, justamente por su simplicidad; aquellos elementos faltantes fueron llenados por la vía de las aplicaciones que la utilizan.
MySQL es un sistema de administración relacional de bases de datos. Una base de datos relacional archiva datos en tablas separadas en vez de colocar todos los datos en un gran archivo. Esto permite velocidad y flexibilidad. Las tablas están conectadas por relaciones definidas que hacen posible combinar datos de diferentes tablas sobre pedido.
MySQL es software de fuente abierta. Fuente abierta significa que es posible para cualquier persona usarlo y modificarlo. Cualquier persona puede bajar el código fuente de MySQL y usarlo sin pagar.
Solo MySQL implementa:
• Múltiples motores de almacenamiento (MyISAM, Merge, InnoDB, BDB, Memory/heap, MySQL Cluster, Federated, Archive, CSV, Blackhole y Example en 5.x), permitiendo al usuario escoger la que sea más adecuada para cada tabla de la base de datos.
• Agrupación de transacciones, reuniendo múltiples transacciones de varias conexiones para incrementar el número de transacciones por segundo.
Oracle es un sistema de gestión de base de datos relacional.
Se considera a Oracle como uno de los sistemas de bases de datos más completos, destacando su:
• Soporte de transacciones.
• Estabilidad.
• Escalabilidad.
• Es multiplataforma.
Su mayor defecto es su enorme precio, que es de varios miles de euros (según versiones y licencias). Otro aspecto que ha sido criticado por algunos especialistas es la seguridad de la plataforma, y las políticas de suministro de parches de seguridad, modificadas a comienzos de 2005 y que incrementan el nivel de exposición de los usuarios. En los parches de actualización provistos durante el primer semestre de 2005 fueron corregidas 22 vulnerabilidades públicamente conocidas, algunas de ellas con una antigüedad de más de 2 años.
Aunque su dominio en el mercado de servidores empresariales ha sido casi total hasta hace poco, recientemente sufre la competencia del Microsoft SQL Server de Microsoft y de la oferta de otros RDBMS con licencia libre como PostgreSQL, MySQL o Firebird. Las últimas versiones de Oracle han sido certificadas para poder trabajar bajo Linux.
1.4.2 ¿Qué diferencias hay entre los diferentes gestores?
Diferencias a la hora de funcionar en nuestra Web:
Se puede decir que el “Rolls Royce” de los gestores de bases de datos es Oracle: por su integridad referencial, rapidez en las consultas dado por el número de acceso concurrentes que soportan una gran cantidad de información, además de que se puede realizar una copia de seguridad sin necesidad de paralizar la Web, y es multiplataforma.
Si se decide trabajar con SQL se tendrá que alojar nuestra Web en un servidor con entorno Windows.
El gestor MySQL puede trabajar en entornos tanto Windows como Linux.
Para administrar una base de datos de una pequeña empresa o para gestionar bases de datos personales: libros, discos, contactos, entre otras. Access puede resultar ser una
excelente herramienta, una base de datos en la cual se puede crear tablas relacionadas, personalizar formularios, realizar informes, establecer módulos y acceder a páginas Web.
El problema resulta ser cuando se necesita incluir una cantidad importante de información, en ese momento Access resulta ser excesivamente lento para las consultas.
Existen diferencias económicas:
Mientras que MySQL es un software gratuito, con SQL se tendrá que adquirir la versión que se utilice y Oracle para Web puede costar mas de 5 000 euros.
Diferencias Operativas:
El precio excesivamente alto de Oracle determina que casi ninguna empresa tenga este servicio, para usarlo se tendrá que disponer de un servidor exclusivo con las implicaciones que supone a nivel técnico y objetivos a largo plazo.
La Web de una gran empresa, que se puede permitir tener técnicos para controlar la seguridad de un servidor, que necesita soportar múltiples conexiones a su base de datos, cuyos usuarios interactúan con una gran cantidad de información, podría elegir a Oracle como su gestor de base de datos.
MySQL se encuentra en el otro extremo de la oferta. Es la opción que nos plantean todos los servidores de hosting gratuito que soportan bases de datos y es casi imposible encontrar una empresa de hosting de pago que no lo soporte
1.4.3
Comparación entre diferentes gestores:
Tabla 1 Información general de los diferentes gestores.
Creador Fecha de la primera versión pública
Ultima versión estable
Licencia de software
MySQL MySQL AB Noviembre de 1996
5.0 GPL o
propietario Oracle Oracle
Corporation
1977 10g Release 2 Propietario
PostgreSQL PostgreSQL Global
Junio de 1989 8.2.3
Licencia BSD
Development Group
Microsoft SQL Server
Microsoft 1989 9.00.2047 (2005
SP1)
Propietario
Tabla 2 Soporte del sistema operativo.
Windows Mac OS X Linux BSD Unix z/OS
Microsoft
SQL Server Sí No No No No No
MySQL Sí Sí Sí Sí Sí Quizá
Oracle Sí Sí Sí No Sí Sí
PostgreSQL Sí Sí Sí Sí Sí No
Tabla 3 Características fundamentales de los gestores.
ACID Integridad
referencial Transacciones Unicode Microsoft SQL
Server Sí Sí Sí Sí
MySQL Depende 1 Depende 1 Depende 1 Sí
Oracle Sí Sí Sí Sí
PostgreSQL Sí Sí Sí Sí
Nota (1): Para las transacciones y la integridad referencial, el tipo de tabla InnoDB debe ser usado; el tipo de tabla por defecto, MyISAM, no soporta estas características. Sin embargo, inclusive el tipo de tabla InnoDB permite el almacenamiento de valores que excedan el rango de datos; algunas vistas violan la limitación de ACID.
Tabla 4 Tablas y vistas.
Tabla temporal Vista materializada Microsoft SQL Server Sí Similar 3
MySQL Sí No
Oracle Sí Sí
PostgreSQL Sí No 2
Nota (2): La vista materializada puede ser emulada con PL/PgSQL .
Nota (3): El servidor MS SQL provee vistas indexadas.
Tabla 5 Indices.
Árbol R-/R+ Hash Expresión Parcial Reversa Mapa de bits Microsoft
SQL Server ? ? No No No No
MySQL
Tablas MyISAM solamente
Tablas HEAP solamente
No No No No
Oracle Edición EE
solamente ? Sí No Sí Sí
PostgreSQL Sí Sí Sí Sí No No
Table 6 Otros objetos
Dominio Cursor Trigger Función 5 Procedimiento 5 Rutina externa 5 Microsoft
SQL Server No Sí Sí Sí Sí Sí
MySQL No Sí 4 Sí 4 Sí 4 Sí 4 Sí
Oracle Sí Sí Sí Sí Sí Sí
PostgreSQL Sí Sí Sí Sí Sí Sí
Nota (4): Estos objetos de base de datos son disponibles a partir de MySQL 5.0 disponible desde 24/12/2005.
Nota (5): Función y procedimiento se refieren a las rutinas internas escritas en SQL o lenguajes procedurales como PL/SQL. Rutina externa se refiere a la escritura en los lenguajes anfitriones como C, Java, Cobol, etc. "Procedimiento almacenado" es un término comúnmente usado para ese tipo de rutinas. Sin embargo, su definición varía entre diferentes vendedores de bases de datos.
1.5 Data Warehouse y vistas materializadas
.
Otra forma de implementar un Data Warehouse es definirlo como un conjunto de vistas materializadas que integran los datos a partir de múltiples fuentes de datos heterogéneas, y eventualmente distribuidas de información.
Una vista es una relación derivada, definida en términos de relaciones bases que es computada todas las veces donde se hace referencia. Una vista esta materializada cuando esta realmente almacenada en una base de datos en vez de ser computada a partir de las relaciones bases en respuesta a consultas. Una vista materializada puede ser vista como una caché, una copia de datos que puede ser accedida rápidamente.
Mas allá de definir el propio Data Warehouse como un conjunto de vistas materializadas basadas en datos de ambientes operacionales, estas vistas también pueden ser utilizadas como objetivo de optimizar consultas complejas, siendo que, para esto, se debe definir un conjunto compartido de vistas, cuidadosamente escogidas a partir de un análisis de las consultas mas frecuentes ejecutadas en un Data Warehouse. Estas vistas, al ser materializadas, apresurarían el acceso de datos necesarios para la realización de consultas en el Data Warehouse.
Para aumentar la eficacia de las consultas, un acercamiento de uso general, es almacenar algunos resultados intermedios de la consulta que procesa en el Data Warehouse. Estos resultados intermedios, almacenados en un Data Warehouse se llaman, las vistas materializadas.
Las vistas materializadas se pueden utilizar por una amplia variedad de consultas de los datos de las bases de datos. Ellas son extremadamente útiles en la optimización de la consulta. La más reciente investigación, es que se pretende integrar la información distribuida, y se ha concentrado en desarrollar un eficiente sistema de intermediarios que no sólo proporcionan un alto grado de independencia para los usuarios locales, también apoyan la integración flexible de las funciones requeridas para los usuarios globales. Sin embargo, ha habido poca atención prestada a la puesta en práctica de las consultas globales definidas en el intermediario. Es posible acelerar la ejecución de una consulta global, si el resultado anterior de una vista materializada es un intermediario. Puesto que el esquema de integración de un intermediario puede ser modificado incrementalmente y su uso puede también ser variado continuamente, el uso de la vista se debe supervisar cuidadosamente, para determinar el sistema optimizado de vistas materializadas.
Además, como el número de vistas aumenta, el proceso de la optimización puede ser demasiado largo, de modo que el sistema optimizado identificado por un proceso largo, se convierta en obsoleto, debido al cambio reciente del uso de la vista. Se propone la adaptación de la selección de un método práctico para cada vista global, tal que el
almacenaje disponible en un intermediario se puede utilizar en cualquier momento (S.
Agrawal 2000).
Reescribir una consulta basada en el uso de un sistema de vistas materializadas puede rendir un plan mucho más eficiente de la ejecución de la consulta para la consulta de OLAP en el ambiente de Data Warehouse (S. Flesca 2001). Aunque las vistas materializadas proporcionan una gran ventaja para las consultas de OLAP, la selección de un sistema de vistas concerniente a los diversos niveles de la agregación que se materializará en el Data Warehouse se debe hacer cuidadosamente, considerando el compromiso del funcionamiento de la consulta con restricciones del mantenimiento de la vista. Sin embargo, seleccionando el sistema apropiado de vistas materializadas es una tarea no trivial y es un problema completo (Gupta 1997).
Desde 1995, los investigadores han estado interesados en el estudio de vistas materializadas, generalmente basado en un todo o nada, modo para las vistas materializadas. Harinarayan y otros. (V. Harinarayan 1996) propusieron el algoritmo codicioso, basado en el concepto de la derivación de un grafico en el cual una vista materializada superior depende de otras vistas. En el primer paso, el algoritmo elige siempre la materialización de la vista que se puede utilizar para derivar cualquier otra vista. En el segundo paso, para cada vista en el gráfico que todavía no pertenece al sistema de vistas materializadas, el algoritmo determina la ventaja total de materializar esta vista. Entre estas vistas analizadas, el algoritmo selecciona la vista que maximiza la ventaja y la agrega a un sistema materializado. Este segundo paso se repite hasta que un número resuelto de vistas materializadas se selecciona o el límite del espacio de almacenaje disponible se alcanza. Este acercamiento particular no considera el costo de mantenimiento.
Ross y otros, (K.A. Ross 1996) consideraban el uso de vistas adicionales para reducir costo de mantenimiento. Liang y otros, (W. Liang 2001) propusieron un algoritmo de dos etapas que optimiza el tiempo de reacción total de la consulta en la primera etapa, y elige las vistas para la materialización bajo restricciones, dado el tiempo del mantenimiento en la segunda etapa. Desafortunadamente, si el espacio de almacenaje es inadecuado para contener todas las vistas que sean dependientes en otras vistas, entonces el algoritmo codicioso tiene el peor funcionamiento. Chen y Liu (Y.H. Chen 1997) consideraban que las vistas materializadas, es un método para aumentar la eficacia de la consulta de un
Data Warehouse. Sin embargo, uno encuentra el problema de la escasez del espacio, si todas las vistas posibles se materializan por adelantado. La reducción de tiempo de la consulta por medio de seleccionar un sistema apropiado de vistas materializadas con un costo más bajo es crucial para el almacenamiento eficiente de los datos. El propósito es, seleccionar un sistema apropiado de vistas materializadas bajo apremios del almacenaje y de costo y ayudar al incrementar la velocidad los datos enteros que almacenan proceso. Utilizando el algoritmo bifásico para seleccionar vistas materializadas. El propósito de la primera fase es, encontrar el espacio de almacenaje mínimo para que las vistas materializadas contesten a todas las preguntas posibles.
Yang y otros, (J. Yang 1997) propusieron un marco del análisis para las vistas materializadas, usando el plan de proceso de múltiples vistas (MVPP). El método de MVPP considera el costo como factor de la materialización de la vista que no toma el espacio requerido en consideración. Lin y Kuo (W.Y. Lin 2004) propusieron una solución mejorada del funcionamiento usando algoritmos genéticos. Gupta y Mumick (H. Gupta 1999) concluyeron que el almacenaje de datos era tan barato, que desarrollaron un método para seleccionar vistas materializadas con eficacia, dado el bajo costo de mantenimiento, sin la preocupación por apremios del espacio.
Theodoratos y Sellis (D. Theodoratos 1999) propusieron vistas simples y vistas auxiliares. Las vistas simples son para las consultas de usuarios; las vistas auxiliares se utilizan para mantener las vistas simples. Utilizaron el algoritmo exhaustivo incremental para analizar vistas materializadas. Puesto que el algoritmo recurrente toma tanto tiempo, los autores utilizaron el algoritmo re-codicioso para restringir el espacio de la búsqueda y los últimos algoritmos más usados de la heurística son para suprimir el espacio innecesario de la búsqueda.
Liang y otros, (W. Liang 1999) idearon un algoritmo para encontrar un sistema tan auxiliar de la vista explotando la información compartida entre las vistas auxiliares y materializó las vistas, de tal modo que redujo el número total de vistas auxiliares.
Park y otros (C.S. Park 2002) propusieron un algoritmo heurístico para encontrar un sistema de vistas materializadas y de sus regiones que darían lugar a un plan eficiente de la consulta. El algoritmo consiste en varios pasos principales. En el primer paso, el
algoritmo heurístico selecciona las vistas materializadas que serán utilizadas para reescribir, determinando regiones de la consulta. En el segundo paso, el algoritmo genera los bloques de la consultas para las vistas materializadas seleccionadas usando regiones de la consulta. El paso pasado integra los bloques de la consulta en una consulta rescrita final. Puede haber muchos rescritos equivalentes que contienen un diverso sistema de las vistas materializadas candidatas que se diferencian grandemente en el funcionamiento de la ejecución.
Zhang y otros. (C. Zhang 2001) aplicaron un algoritmo evolutivo híbrido para la selección de vistas materializadas, consistiendo en dos niveles de proceso del algoritmo. El algoritmo de alto nivel busca buenos planes de proceso globales, de los planes de proceso local basados en consultas. El algoritmo de nivel inferior selecciona el mejor sistema de vistas materializadas con el costo mínimo total para un plan de proceso global particular. Este algoritmo híbrido se realiza mejor que el algoritmo heurístico en términos de ahorros de costo, pero requiere un tiempo más largo de cómputo. Yu y otros.
(J.X. Yu 2003) extendieron el trabajo de Zhang, proponiendo un algoritmo evolutivo, obligado con un procedimiento estocástico de la graduación para solucionar el problema de la selección de vistas reduciendo el costo de mantenimiento. Se presentó un modelo del costo basado en un trabajo previo (D.L. Yang 2002) para determinar las vistas materializadas deseables en las cuales el costo total de proceso de la consulta y el mantenimiento se reducen al mínimo.
Yang y otros, (D.L. Yang 2002) utilizaron la posición del punto-corte del espacio de almacenaje real, dado entre el espacio del candidato y el espacio mínimo para tomar decisiones mejores en la determinación de, si suprimir algunas vistas materializadas candidatas, o agregar más vistas materializadas al espacio mínimo.
Existen diversas maneras para desarrollar de forma más eficiente y efectiva, la utilización de vistas materializadas para la creación de un Data Warehouse.
En la siguiente sección, se analizarán diferentes algoritmos de materialización de vistas y se escogerá el más efectivo para determinar las mejores vistas materializadas en las cuales, el costo total del proceso de la consulta y el mantenimiento se reduzcan al mínimo.
CAPITULO 2: Proceso de virtualización de un DWH.
Un Data Warehouse (DWH), se puede ver como un conjunto de vistas materializadas, donde guardan la información extraída de una o mas bases de datos que la organización utiliza en sus sistemas operacionales.
Una vista materializada, es una consulta cuyo resultado está almacenado en una base de datos. Las consultas que pudieran utilizar vistas materializadas ya almacenadas, pueden ser ejecutadas de forma mucho más rápida, siendo que, para consultas complejas que envuelven grandes volúmenes de datos, esta alternativa favorece dramáticamente los resultados: de horas o días para minutos o segundos. Las vistas materializadas son vistas como una de las principales opciones para el control de desempeño de un Data Warehouse.
La desventaja de estas vistas materializadas, son las alteraciones hechas a los datos bases, a partir de los cuales una vista materializada es definida, se convierte entonces en una vista desactualizada. Para que una vista pueda ser nuevamente sincronizada, será necesario recrear una vista a partir de los datos origen, y actualizarla incrementalmente.
El uso de vistas materializadas en los Data Warehouse, requiere del análisis de la selección de las vistas más adecuadas llevando en cuenta los costos de mantención, los aspectos de materialización y utilización de las vistas para responder las consultas, además de los mecanismos que permiten la propagación correcta, cuando hay actualizaciones de las fuentes de datos bases, utilizando el concepto de las mismas vistas materializadas.
Para los servicios informativos, las posibles vistas necesitan ser restauradas siempre que las fuentes de datos cambien para asegurar validez, exactitud, y modernidad. Esto aumentará el costo de mantenimiento de las vistas materializadas. La selección de las vistas materializadas, implica una compensación difícil entre el funcionamiento de la consulta y el mantenimiento del costo, además de una utilización mejor del espacio de almacenaje. Sin embargo, la limitación del almacenaje prohíbe la materialización de todas las vistas posibles.
En este contexto, surge uno de los desafíos que tiene la utilización de vistas materializadas. Se trata de la selección de un conjunto de vistas que minimice el tiempo de procesamiento de las consultas y el tiempo de procesamiento de las vistas. Esta cuestión es concebida como el problema de selección de vistas a materializar.
2.1 Selección de las vistas a materializar
Una vista es una función que parte de un conjunto de tablas bases para una tabla derivada, siendo recalculada todas las veces que es referenciada.
La materialización de un conjunto de vistas, es una técnica muy utilizada en base de datos. Materializar una vista en una base de datos, consiste en almacenar las tuplas resultantes del procesamiento en una tabla.
Con el almacenamiento de las tuplas de las vistas en la base de datos, puede resultar entonces, la materialización, con la cual el acceso a estas vistas materializadas será más rápido que el recálculo, que es ejecutado todas las veces que las vistas son referenciadas.
Un Data Warehouse contiene múltiples vistas y esto hace que puedan estar relacionadas unas con otras, lo que resulta, a veces, ser más eficiente tan solo materializar cierta parte de estas vistas, por lo que se requiere seleccionar las vistas que serán materializadas.
Esta selección, se basa en determinaciones de un conjunto de vistas, donde el objetivo principal es seleccionar un conjunto apropiado de vistas que minimice el tiempo de respuesta de las consultas o el costo de manutención de las vistas elegidas, dado cierto número de recursos, como son: el tiempo de materialización y espacio para el almacenamiento, entre otras.
En sí, la materialización de vistas consiste en la anticipación del procesamiento y almacenamiento de las tuplas resultantes en una tabla. En efecto, el tiempo de respuesta de una consulta es menor, si las operaciones intermedias como selecciones, proyecciones, uniones y agregaciones, se encuentran ya almacenadas en una tabla.
2.1.1 Descripción resumida de los algoritmos de (J. Yang 1996):
Para la selección de las vistas a ser materializadas, existen diversos algoritmos, algunos definen aspectos de un modelo para el diseño de las vistas materializadas, seleccionando un conjunto de resultados intermedios de las consultas que serán materializadas de forma que el costo total de estas sea el menor. También se lleva en cuenta la frecuencia de las consultas y la frecuencia de las actualizaciones en los datos base.
Todo este proceso de selección de las vistas a ser materializadas también puede estar basado en el plan de procesamiento de múltiples vistas (Multiple View Processing Plan, MVPP), generado por un algoritmo que parte de planos individuales de cada consulta.
El trabajo realizado por (J. Yang 1996) esta basado en una base de datos ejemplo, que contiene las siguientes relaciones:
Product (Pid, name, Did) División (Did, name, city) Order (Pid, Cid, quantity, date) Customers (Cid, name, city) Part (Tid, name, Pid, supplier)
Para el acceso al Data Warehouse se utilizan diferentes consultas, suponiendo que se tienen las siguientes consultas:
Consulta 1: select Product. name from Product, División
where División. city = “LA” and Product. Did= División. Did
Consulta 2: select Part. name
from Product, Part, División
where División. city = “LA” and Product. Did= División. Did and Part. Pid=Product. Pid
Para cada una de estas consultas será generado un grafo de procesamiento, que representa el plano de acceso individual:
Figura 3 Plano de acceso individual para las consultas 1 y 2.
En los diagramas para una mejor representación se simplifican Pd de Product, Div de Division, Ord de Orden, Cust de Customer, Pt de Part.
Para la obtención de un rápido tiempo de respuesta de las consultas, una de las alternativas a utilizar seria la materialización de los intermedios de cada plano de acceso individual, de esta forma, entonces en el intermedio temp2 la consulta 1 es equivalente a la consulta 2, las cuales son llamadas sub-expresiones comunes. Por consiguiente queda formado un plano de los planos de la consulta 1 y 2:
Figura 4 Plano de acceso combinado para las consultas 1 y 2.
Si se materializa temp1 entonces puede ser utilizado para las consultas, en vez de acceso a las relaciones bases, disminuyendo de esta forma el costo de ejecución.
Además de que seria de gran beneficio por ser el costo de manutención de las vistas mucho menor.
Suponiendo que otras dos consultas de uso frecuente en el Data Warehouse son:
Consulta 3: select Customers. name, Product. name, quantity from Product, División, Order, Customers
where División. city = “LA” and Product. Did= División. Did and Product. Pid= Order. Pid and Order. Cid= Customers. Cid and date > 7/ 1/ 96
Consulta 4: select Customers. city, date from Order, Customers
where quantity > 100 and Order. Cid = Customers. Cid
En la Fig. 5 se representa un plan de acceso global llamando Multiple View Processing Plan (MVPP), donde se combinan los planos individuales de las cuatro consultas, después se puede decidir cuales serán materializadas, de forma tal que el costo de la consulta de la vista materializada sea el mínimo.
Figura 5 Un MVPP para el ejemplo.
Existen varias opciones para materializar el conjunto de vistas a seleccionar, una sería materializar todas las consultas, y otra materializar solo algunos de los intermedios, por ejemplo: temp1, temp2, entre otros.
Para tomar la mejor decisión es necesario calcular el costo de cada alternativa en términos de manutención de la vista.
En conclusión el algoritmo para la definición de MVPP normalmente obtiene uno o varios planos globales basados en las diferentes combinaciones de los planos individuales.
Este algoritmo parte de los planos individuales óptimos y los ordena, basándose en la
frecuencia de las consultas y en los costos, una vez ordenado, combina las sub- expresiones comunes de los planos individuales, llegando a un conjunto de planos globales o un conjunto de MVPP. Cada MVPP generado, tiene su costo total y será analizado por un segundo algoritmo que selecciona los intermedios que serán materializados. Este algoritmo trabaja dado un MVPP, con el objetivo de definir un conjunto de vistas materializadas tal que, el costo de manutención de estas vistas sea el mínimo, por lo que compara los costos de cada combinación posible. Finalmente este algoritmo compara el costo total de cada MVPP generado, seleccionando el de menor costo.
2.1.2 Algoritmo A* y BUPS:
Estos algoritmos son los llamados algoritmos determinísticos, porque devuelven una sola solución por búsqueda exhaustiva, o sea, devuelven soluciones próximas a la más óptima. Usualmente las soluciones dadas por este tipo de algoritmo, son utilizadas como punto de partida para otros algoritmos.
2.1.2.1 Definición del problema.
Sea L (un grafo acíclico por ejemplo) el espacio de soluciones y un conjunto de vistas a materializar. Cada vista tiene tres valores asociados: a la frecuencia de la consulta , la frecuencia de actualización , y el costo de lectura . Según (Panos Kalnis 2002) el costo de responder a una consulta q (que corresponde a una vista v) corresponde al tamaño de v, o sea, al número de tuplas
El problema de la determinación de un espacio L de soluciones es abordado en (Dimitri Theodoratos 2004). En esta fase apenas se atiende al problema de la selección del conjunto de vistas M a materializar suponiendo la existencia de L. El costo de almacenamiento de M esta dado por:
Sea u (v, M) el costo de actualización de la vista v cuando M es el conjunto de vistas materializadas. Entonces el costo de actualización de M es dado por:
Sea q (v, M) el costo de si responder a una consulta v cuando M es el conjunto de vistas materializadas. El costo total de responder las consultas es dado por:
El problema de la selección de vistas a materializar consiste en escoger un conjunto M tal que Q (M) es mínimo y que se respeten las restricciones S (M) ≤ Smax y U (M) ≤ Umax. Siendo Smax el espacio disponible para materializar y Umax la ventana temporal disponible para la manutención del conjunto de vistas materializadas.
2.1.2.2 Descripción de los algoritmos A* y BUPS.
El algoritmo BUPS presentado por Himanshu Gupta en 1997 es de los más utilizados (Himanshu Gupta 2005), (Himanshu Gupta 1997), (Gupta 1997), (Gupta 1999). Utiliza grafos acíclicos para representar las vistas y las consultas, siendo que para cada nodo existe una operación de selección, agregación, proyección o unión. A cada nodo, esta asociado un número de tuplas determinado y un número de frecuencia de la consulta (número de veces que el nodo fue accedido).
Este algoritmo en cada iteración selecciona la vista con mayor beneficio por unidad de espacio, la noción del beneficio de una vista, es en relación al conjunto de vistas materializadas, y esta dado por la siguiente ecuación:
Este cálculo del beneficio consiste en la diferencia de los costos de procesamiento de las vistas materializadas con o sin la vista.
El costo total del conjunto de vistas materializadas esta dado por:
El beneficio por unidad de espacio es calculado a través de la división entre el beneficio presentado por la vista y su espacio:
En el algoritmo BUPS el tiempo de procesamiento es O (kn2), donde n es el numero de nodos en el grafo y k es el numero de iteraciones dado por este algoritmo.
Datos: G es un grafo de vista ANDOR, S una restricción de espacio INICIO
M = {};
En cuanto (S (M) <S)
Sea V la vista que tiene un máximo beneficio por unidad de espacio en relación a M.
M = M U {V};
Fin del En cuanto Devuelve M
FIN
Algoritmo 1 – El algoritmo BPUS
El algoritmo A* presentado por Himanshu Gupta.y M. Inderpal Singh y extendido por (Gang Gou 2004), para la selección sobre una restricción de tiempo de manutención, sobre una restricción de espacio y utiliza igualmente los grafos acíclicos orientados de tal forma que representa el problema.
Este algoritmo se especializa en la representación de un cuboide, que no es mas que un grafo acíclico orientado al modelo multidimencional, con un nodo como raíz y otro como hoja. El nodo raíz es la tabla de hechos y el nodo hoja consiste en la agregación universal de los datos a la tabla de hechos, o sea, el total sobre todas las dimensiones.
El algoritmo A* expande un árbol binario de búsqueda TG. Cada nodo en TG es del tipo (Nx, Mx), denotado por x = (Nx, Mx), donde Nx es el conjunto de vistas visitadas y Mx es el conjunto de vistas seleccionadas para la materialización
Si se sigue la orden de inserción predeterminada (v1, v2,..., vn), cada vista vi es considerada para la materialización. El descendiente izquierdo de x es definido por que significa que la recién insertada vista vi+1 no será materializada y el descendiente derecho x definido por
significa que la recién insertada vista vi+1 será materializada.
Finalmente, el nivel mas bajo del árbol Nx = V, significa que todas las vistas del cuboide G fueron consideradas o no para la materialización (V denota el conjunto de vistas o nodos en G).
El beneficio de expandir el nodo x es la suma de dos funciones: g(x) y h(x). La primera calcula el beneficio adquirido y la segunda el beneficio estimado al materializar x (Gang Gou 2004).
El proceso de construcción del árbol binario de búsqueda A* cobra todo el espacio de 2n soluciones posibles. Esto asegura que el algoritmo contempla la solución óptima. La complejidad del algoritmo A* se sitúa entre O(n) y O (2n) dependiendo de la cantidad de la función estimadora h(x). O sea, en el peor de los casos tiene un comportamiento exponencial, mucho peor que el BPUS.
Datos: Un cuboide G y una restricción de espacio S.
INICIO
Crear una árbol de pesquisa A* inicial TG, teniendo como nodo de raíz ({}, {});
Determinar una orden de inserción de vistas:
(v1, v2,..., vn);
Crear una lista de prioridad L = {raíz};
Repite
Retirar un nodo x = (Nx, Mx) de L, donde x tiene el menor g(x) + h(x) valor en L;
i = |Nx|;
Si (i = n) Entonces Devuelve Mx;
Fin del Si
Insertar l(x) = (Nx U {vi+1}, Mx) en L;
Si (U (Mx U {vi+1}) <= S) Entonces Insertar r(x) = (Nx U {vi+1}, Mx U {vi+1}) en L;
Fin del Si
Escribir (L estar vacía);
Devuelve {};
FIN
Escribir (L estar vacía);
Devuelve {};
FIN
Algoritmo 2 – El algoritmo A*
2.1.2.3 Análisis y comparación entre los algoritmos A* y BPUS:
En un Data Warehouse los datos son organizados según un modelo multidimensional, de forma tal, que mejora el desempeño de procesamiento de los datos y su visualización (Gang Gou 2004). En este ejemplo, se tiene un esquema con tres dimensiones y una tabla de hechos con cuatro atributos: VENTAS (Tiempo, Producto, Hoja, Precio). Los atributos Tiempo (T), Producto (P) y Hoja (L) forman el espacio dimensional. El último atributo, Precio, es la medida sobre la cual se pretenden analizar los datos. Los análisis realizados en OLAP consisten en agregaciones de algunas dimensiones. Las funciones de agregación usualmente disponibles en la base de datos, juntamente con el operador GROUP-BY, son: la suma; promedio; máximo y mínimo. Las ventas de producto por hoja se traducen en la siguiente consulta SQL:
select Producto, Hoja, SUM (Precio) from VENTAS group by Producto, Hoja.
En esta consulta recorre al tipo de agregación producto por hoja (PL).
En el esquema multidimensional presentado se pueden efectuar 23 tipos de agregaciones diferentes (PLT, PL, PT, LT, P, L, T).
Generalmente se recurre al cuboide para representar las relaciones entre las posibles agregaciones a efectuar sobre un esquema multidimensional dado. Por ejemplo, a partir de la agregación producto por hoja (PL) aun es posible efectuar dos agregaciones (por producto, P, y por hoja, L). De estas dos, se puede llegar a la agregación universal (ALL), o agregación de las medidas en un único total.
En la figura 6 se ilustra el cuboide del ejemplo utilizado, donde TF simboliza la tabla de hechos. Para cada nodo del cuboide existen dos parámetros, T y F. El primero indica el
número de tuplas que resultan de la agregación especificada. El segundo indica la frecuencia de interrogaciones que utilizan la agregación en causa. Cualquier consulta puede ser respondida a partir de la tabla de hecho, motivo por el cual, esta no tiene una frecuencia de consulta asociada.
Figura 6 Cuboide
Ambos algoritmos utilizados fueron ejecutados en un ciclo donde varía la restricción del espacio. El espacio total para materializar todas las vistas de un cuboide es 2721 que no es más que la sumatoria del número de tuplas de todas las agregaciones.
La relación del costo total de procesamiento de las soluciones obtenidas por los algoritmos y la evolución de la restricción del espacio se ven en la figura 7.
Cuando el espacio de restricción es nulo, o sea, que el conjunto de vistas a materializar esta vacío, los costos de procesamiento son de 58000. Ya cuando se llega a una restricción de espacio de 2721, el costo de procesamiento se minimiza.