Capítulo 5. Implementación

Este capítulo describe los detalles de implementación de DOMINIQUE. La sección 5.1

describe las herramientas utilizadas para la implementación de DOMINIQUE. La sección

5.2 se muestra la arquitectura general del prototipo, sus estructuras de datos y módulos

principales (integrador y extractores). Las secciones 5.3 y 3.4 describen respectivamente la

implementación de los extractores y del integrador. La sección 5.6 describe el motor de

consultas implementado. La sección 5.7 concluye el capítulo.

5.1 Arquitectura de DOMINIQUE

DOMINIQUE fue implementado sobre una plataforma UNIX en el lenguaje java. Se

adoptó Oracle 8i como soporte de persistencia y SQL-Plus como lenguaje de consulta. Para

comunicar la base de datos con la aplicación del usuario se usó JDBC. La Figura 5.1

muestra la arquitectura empleada por DOMINIQUE.

Construcción

DW (ORACLE)

Motor de Consultas

Figura 5.1 Arquitectura general de DOMINIQUE

Como se muestra en la Figura 5.1, el DW tiene comunicación directa con el motor de

consultas y con el módulo de construcción, mismo que se comunica directamente con las

fuentes de datos de DOMINIQUE. Los componentes principales de DOMINIQUE son el

motor de consultas y el integrador que implementan el tratamiento de consultas y la

construcción del DW.

5.1.1 Construcción

Dado un esquema multidimensional que organiza la información de nuestro DW y un

conjunto de fuentes, DOMINIQUE implementa extractores que son capaces de recuperar

datos de sus fuentes (HTML) y homogeneizar los datos, para finalmente integrar los datos

y con estos poblar el repositorio, tarea ejecutada por el integrador. La Figura 5.2 muestra la

arquitectura de construcción para DOMINIQUE.

Servidor

SQL

SQL Cliente / Servidor

Cliente

DW (ORACLE)

Extractor/Monitor Extractor/Monitor Extractor/Monitor

Integrador

JDBC

INEGI El universal Banco de

Figura 5.2 Arquitectura de construcc

HTML

HTML HTML Servidor

México

ión

El repositorio es el servidor de datos del integrador comunicándose con este de la misma

forma que el motor de consultas con el repositorio. En este momento el integrador funciona

como cliente, pero además funciona también como servidor del extractor. Finalmente las

fuentes de datos sirven como servidores de información a los extractores mediante un

protocolo de comunicación HTTP.

5.1.2 Análisis OLAP

Dada una consulta OLAP expresada por la interfaz de DOMINIQUE, el motor de consulta

la procesa (transforma en una expresión SQL) y la envía al DW. La arquitectura para el

análisis (motor de consultas) se muestra en la Figura 5.3.

OLAP Cliente

Servidor

Motor de consultas

JDBC

DW (ORACLE)

Interfaz

Figura 5.3 Arquitectura de análisis

DOMINIQUE se implementa bajo una arquitectura cliente/servidor. El motor de consultas

se comunica con el repositorio mismo que sirve como servidor. Esta comunicación se

realiza mediante JDBC, la que permite una comunicación entre java y SQL.

5.2 Esquema de DOMINIQUE

DOMINIQUE implementa un esquema de datos relacional, instrumentado a través de un

esquema en copo de nieve (Capítulo 4). Para implementar el modelo de datos se empleo el

lenguaje SQL. Las tablas que se crearon ya fueron presentadas con anterioridad. La

creación de tablas empleadas Por DOMINIQUE se presenta a Figura 5.4.

Create table Ciudad( CodCiudad NUMBER (4),

NomCiudad VARCHAR2 (45), PRIMARY KEY (CodCiudad));

Create table Estado (CodEstado NUMBER (4),

NomEstado VARCHAR2(45), PRIMARY KEY (CodEstado));

Create table Ciudedo (CodCiudad NUMBER (4),

CodEstado NUMBER (4), PRIMARY KEY (CodCiudad, CodEstado),

FOERING KEY (CodCiudad) REFERENCES Ciudad, FOERING KEY (CodEstado) REFERENCES Estado);

Create table Zona (CodEstado NUMBER (4),

NomZona VARCHAR2 (45), PRIMARY KEY (CodEstado, NomZona));

Create table Producto (CodProducto NUMBER (4),

NomProducto VARCHAR2 (60), PRIMARY KEY (CodProducto));

Create table Derivado (CodDerivado NUMBER (4),

NomDerivado VARCHAR2 (60), PRIMARY KEY (CodDerivado));

Create table Grupo (CodGrupo NUMBER (4), NomGrupo VARCHAR2 (60), PRIMARY KEY (CodGrupo));

Create table Rama (CodRama NUMBER (4),

NomRama VARCHAR2 (60), PRIMARY KEY (CodRama));

Create table Familia (CodFamilia NUMBER (4),

NomFamilia VARCHAR2 (60), PRIMARY KEY (CodFamilia));

FIGURA 5.4. Creación de tablas empleadas por DOMINIQUE

En la Figura 5.4 se muestran algunas tablas importantes en el diseño interno de

DOMINIQUE. El lenguaje que maneja es SQL, y como se puede observar existen

restricciones de integridad y llaves únicas de identificación. En este caso las relaciones

entre las tablas pueden distinguirse por sus llaves externas, aquí referenciadas por la palabra

reservada “FOREING KEY”.

5.3 Extractor

Los extractores de DOMINIQUE fueron implementados usando la liberaría

com.Kizna.html, disponible en [26]. Dicha librería permite analizar páginas HTML para

que un extractor pueda transformarlos en una representación relacional. La Figura 5.5

muestra la arquitectura general de un extractor implementada por la clase

HTMLStringFilter.

1 1

RegisterScanner() GetReader() Elements()

ReadFlag: boolean Node: HTMLNode

HTMLParser

BuildmyParser() Parse() Clena_String()

Parser : HTMLParser Docparseado: File

HTMLStringFilter

Figura 5.5 Clases para el extractor

Esta arquitectura fue especializada para implementar tres extractores, cada uno adaptado

para una página de periódico electrónico. Por lo tanto, se desarrollaron tres algoritmos. Uno

que recupera las temperaturas publicadas diariamente en la página web de periódico “El

Universal” [29] (ver Anexo 3). Un segundo extractor que recupera las entidades federativas

de la republica mexicana disponibles en la página web de INEGI [31] (ver Anexo 4). Y

finalmente un tercer algoritmo que recupera los índices de consumo de productos

publicados mensualmente en el sitio web del Banco de México [30] (Anexo 5). Los tres

extractores conocen bien la ubicación y formato tanto de las fuentes como del DW, por lo

tanto, por un lado manejan el protocolo HTTP para comunicarse con las fuentes y por otro

también manejan el lenguaje SQL necesario para comunicarse con el integrador.

El primer análisis que se realizó fue el de la página del INEGI, ya que para poder ingresar

más datos a la base era necesario conocer las ciudades que esta proporcionaba y anexarles

un código de identificación como ya se mostró en las tablas correspondientes. El extractor

de esta fuente sólo extrae el nombre de las ciudades y mediante un módulo implementado

en java asigna un número de identificación para la ciudad, preparándolo para que después

el integrador se encargue de actualizar la información en el repositorio.

Lo siguiente fue implementar el extractor para recuperar las temperaturas. Una vez que se

analiza la página web, la información recuperada se copia a un archivo de texto, el cual es

recorrido por un algoritmo implementado en java encargado de limpiar la información de

los posibles errores que ésta pueda tener y también de completar los posibles faltantes de

información.

Como último paso de extracción se implementó el extractor de los índices de consumo de

productos. La metodología de implementación que se aplicó para este es la misma que para

el extractor de consumo de productos sólo que para este no se implementa un monitor. Sin

embargo, debido a las dificultades de acceso a esta información por las razones antes ya

mencionadas, se tuvo que implementar cinco módulos que fueran capaces de recuperar y

limpiar la información previamente analizada.

Los cinco módulos implementados son muy parecidos entre sí. La razón de implementar

estos por separado es la diferente estructuración entre las páginas del mismo sitio web, ya

que en algunas de ellas la estructura de las etiquetas de marcado se encuentran distribuidas

de forma no uniforme. Razón por la que no es posible tener un algoritmo general que

recupere la información de todas las páginas necesarias de este sitio web.

5.4 Integrador

Una vez que ya se tiene la información proporcionada por las fuentes en un archivo de

texto, tarea realiza por los extractores, lo siguiente es homogeneizarla, y una vez ya con el

mismo formato actualizar la información en el DW.

La Figura 5.6 muestra las clases empeladas por el integrador del integrador, como la clase

Integra que ofrece el método Transforma, que se ocupa de transformar los documentos

HTML actualizados por el extractor hacia expresiones SQL.

1 1 1 *

Figura 5.6 Clases del integrador

HTMLStringFilter

Parser : HTMLParser Docparseado: File

BuildmyParser() Parse() Clena_String()

Bitácora Bitácora_Resultados

Diccionario

BuildmyParser() Parse() Clena_String()

Parser : HTMLParser Docparseado: File

HTMLStringFilter

Dada la heterogeneidad de términos usados por las fuentes, el integrador se sirve de un

diccionario para realizar la transformación. El diccionario en una tabla relacional. Esta tabla

se llama “Sinónimos” y contiene las equivalencias de valores de los datos según se

almacenan en el repositorio y como se hace referencia a ellos dentro de las fuentes.

El integrador recibe la información y se encarga de prepararla para ser llevada a la base de

datos. El algoritmo que realiza esto, es encargado de llevar la información del formato en

que se encontraba en las fuentes (HTML) al formato que se maneja dentro del repositorio

(SQL). En otras palabras, es encargado de seleccionar y agrupar la información para

después ponerla como expresión SQL y mediante una conexión a la base insertar las tuplas

con sus atributos en las tablas correspondientes. De esta tarea se encarga el módulo de pre-

consultas referido en la parte de diseño del integrador.

Este módulo es implementado en lenguajes java. Su principal función consiste en la

homogenización de los datos que se encuentran en las fuentes. Es decir seleccionar los

elementos tal y como se tienen almacenados en el repositorio. La tarea de homogenización

es necesaria para todas las fuentes. Su algoritmo en Pseudo-código se muestra en la Figura

5.7.

1 Recibir los datos del módulo del extractor 2 Buscar la ciudad o producto en la tabla Sinónimos 3 Obtener el valor con el que se nombra a la ciudad o producto dentro del repositorio 4 Buscar en la tabla correspondiente el código de identificación del producto o ciudad 5 Con el resultado obtenido y los demás datos recuperados por el extractor formular las tuplas de inserción a la base de datos e insertarlas.

Figura 5.7 Pseudo-código de ejecución del integrador

5.5 Motor de consultas OLAP

Para crear un sistema de apoyo a la toma de decisiones es necesario un análisis de la

información recuperada y almacenada. OLAP es un conjunto de técnicas y operadores que

facilitan el análisis de la información contenida dentro del DW. Las funciones principales

del motor de consultas son ofrecer un medio para expresar consultas OLAP y para

procesarlas. El proceso clave que implementa el motor es la administración de vistas.

1 1 Traduce() Select_operador() Crea_vista () Recuperación()

OLAP_OP

ActionPerformed() ItemStateChanged()

Jframe: JFrame

DOMINIQUE

Figura 5.8 Clases del motor de consultas

Como muestra la Figura 5.8 la clase DOMINIQUE es la interfaz de usuario que se

comunica directamente con el motor de consulta, mismo que tiene cuatro métodos que se

encargan implementar las operaciones OLAP.

5.5.1 Administración de vistas

La estrategia que se sigue para almacenar las consultas consiste en crear vistas

materializadas que contengan exclusivamente las tuplas requeridas para dicha consulta y

finalmente almacenar el resultado de las consultas en la base de datos. Para realizar esto, es

necesaria la creación de dos tablas que tengan un listado de las consultas hechas y sus

resultados, de ésta forma se crearon las siguientes tablas:

• Bitácora (Cubo, Grano, Valor, Dimensión)

• Bitácora_Resultados (Cubo, Operación, Cantidad, Multidimensión)

Donde se tienen las siguientes restricciones:

Restricciones de llave: Señaladas con el subrayado.

Restricciones referenciales: Expresadas mediante las llaves.

Restricciones de dominio: Señaladas con el mismo nombre en ambas tablas.

Vista

Marializada Bitácora

Cubo Grano Valor Dimension

Cubo Operación Cantidad Multidimensión

Bitácora_resultados

Figura 5.9 Relación de la administración de consultas

En la Figura 5.9 se muestran las dos tablas y que se relacionan mediante llaves de

referencia en este caso la llave es el cubo y se muestra mediante una flecha de referencia.

Siendo éste el identificador de cada vista materializada que se crea.

La función de la tabla Bitácora es tener una relación o listado de las vistas materializadas

que han sido creadas, así como también de los valores, granos y dimensiones en los que

estas se encuentran involucradas. La tabla Bitácora como es de suponerse se encuentra

almacenada en la base de datos. El atributo cubo es el nombre que se le da a la vista

materializada, como detalle de implementación, lo que se hace es darle el nombre genérico

de “Consulta” y a esta palabra se le concatena el número máximo de valores en la tabla

sumándole una unidad. Este procedimiento se ejecuta mediante consultas a la base de datos

y manipulación de los resultados en lenguaje java.

La función de la tabla Bitácora_resultados es almacenar el resultado numérico de la

consulta realizada, haciendo referencia a la vista que se creó y al modelo multidimensional

al que corresponde, para casos prácticos, temperatura o consumo de productos. El atributo

de operación hace referencia a las funciones de agregación que ofrece SQL, como lo es el

máximo, el mínimo o el promedio (max(), min(), avg()).

Es también importante resaltar que DOMINIQUE implementa los operadores

fusionándolos, esto es, no sólo maneja un operador a la vez, si no que puede responder a

consultas aplicando inclusive dos operadores.

5.5.2 Mantenimiento de vistas

De la forma en que ya se explicó, refrescar significa actualizar la información que se genera

en las fuentes, para lo que se necesita un módulo que localice las tablas o vistas donde se

debe actualizar los datos adquiridos por el DW, y otro módulo que se encargue de llevar a

cabo dicha actualización. El algoritmo de mantenimiento que implementa DOMINIQUE, se

muestra en la Figura 5.9a.

Si uno o más valores de la tupla a ingresar pertenecen a alguna vista

Desde 1 hasta el número de vistas involucradas Ingresar la tupla en la vista

Calcular de nuevo la función de agregación de dicha vista Actualizar el resultado obtenido de la función de agregación

Actualizar la tupla inicial

De lo contrario

Actualizar la tupla inicial

Figura 5.9a Algoritmo de mantenimiento de vistas

Según se muestra en la Figura 5.9a, el algoritmo de localización se encarga de comprobar si

existen vistas materializadas que contengan valores de la nueva tupla que se esta insertando

en el sistema. De no ser cierto, simplemente inserta la tupla en la tabla donde se almacenan

ya sea las temperaturas o el índice de consumo de productos; sin embargo, si existe alguna,

además de insertar las tuplas en las tablas antes mencionadas, también inserta dicha tupla

en la vista materializada seleccionada y recalcula la función de agregación realizada en

dicha vista, actualizando a la par el resultado contenido en la tabla de Bitácora_resultados.

La implementación de dicha rutina es realizada en el lenguaje java. Pero como se muestra

también es necesario que se ingrese directamente a la base de datos usando el lenguaje

SQL, así mediante JDBC se logra la conexión entre java y la base de datos Oracle.

El acceso a las vistas materializadas y tablas, así como la alteración de las mismas, es

realizado a través de los comandos de SQL, con una clase propiamente diseñada para

facilitar el acceso a la base de datos. Esta clase recupera los valores que están siendo

insertados y compara si existen estos valores en alguna vista. El proceso de comparación

debe ser realizado minuciosamente ya que pueden haber vistas almacenadas que coincidan

en más de uno con los valores que se están ingresando, por lo tanto dichas vistas también

deben ser actualizadas.

5.5.3 Slice’n dice

La operación slice’n dice en forma aislada o como único operador, simplemente sería capaz

de responder a consultas que cuestionasen al sistema sobre las granularidades más pequeñas

de este.

El motor de consultas recibe la petición de realizar una consulta directamente de la interfaz

de usuario, que fue realizada mediante la selección de granularidades, dimensiones y

valores. Mediante la elección de las dimensiones se debe elegir el operador que se

implementará; en caso de estar trabajando con los granos más pequeños de las dimensiones

entonces se aplicará el operador slice’n dice.

Este operador recibe las dimensiones y granos que necesita agrupar para ejecutar la

consulta. En el lenguaje java y mediante la implementación de un algoritmo de

comparaciones de las dimensiones seleccionadas se va conformando una oración SQL que

verifica si esta consulta ya fue realizada. En caso de tenerse registro de haber sido realizada

la consulta con anterioridad se recupera el resultado almacenado en la tabla

Bitácora_resultados; y si no se tiene registro de la consulta se formula una sentencia SQL

de selección de tuplas con los granos, dimensiones y valores elegidas por el usuario,

mismas que son recuperadas de la tabla Temperaturas o Ventas, según sea el caso.

Las tuplas regresadas de la selección son insertadas en una vista materializada, la cual

recibe nombre o identificador interno mediante la implementación de una función en java,

que no es mas que un generador de etiquetas usando un contador. Finalmente ya con las

tuplas agrupadas en esta vista materializada se calcula la función de agregación deseada y

el resultado se actualiza en las tablas de administración de vistas.

Sin embargo, las consultas que un usuario requiera pueden ser más estructuradas e

involucrar las diferentes granularidades de cada dimensión, por esto el operador slice’n dice

se puede combinar con el operador roll – up o drill – down, para así poder navegar en los

diversos niveles de agregación de las dimensiones deseadas por el usuario.

5.5.4 Roll – up

Implementar este operador requiere de más procesos que el operador anterior. Roll – up

consiste en aumentar de nivel de granularidad, es decir, una vez que se ha hecho una

consulta y ésta se ha almacenado, es posible ocupar ésta para responder a una nueva

consulta correspondiente a un nivel de agregación mayor de la misma dimensión o

dimensiones. Trabajar con este operador implica trabajar con los granos superiores de las

dimensiones, es decir, con roll-up podemos subir del primer al segundo nivel de

granularidad, del segundo al tercero y así sucesivamente.

La elección de este operador al igual que el anterior se hace mediante un módulo de

comparaciones en java. Se tienen listados los granos superiores de las dimensiones y en

caso de ser uno de estos igual al de la selección del usuario, el operador entra en acción.

De inicio lo que hace es agrupar y formular en java una consulta SQL para cerciorarse que

la consulta fue realizada, ejecutándose esta parte igual que el operador slice’n dice. En caso

de que la consulta no se tenga registrada se reformula una consulta SQL, sólo que esta vez

buscando los valores del grano inmediato inferior de manera que se puedan reutilizar esos

valores y sólo calcular los restantes para completar la consulta de grano superior.

La manera de implementar lo anterior se realizó con java y SQL. Primeramente se

cuestiona al repositorio por todos los valores correspondientes a la granularidad inmediata

inferior, los valores son almacenados en un arreglo dinámico (Vector en java) y después

cíclicamente se realiza la búsqueda de consultas ya realizadas con cada uno de los valores

almacenados en el arreglo. En caso de que los valores se tengan, se recuperan y almacenan

en otro arreglo dinámico, este almacenando únicamente valores numéricos. En el caso

contrario se ejecuta una consulta de selección, se almacenan las tuplas obtenidas en una

vista materializada, se calcula la función de agregación y finalmente el resultado numérico

se ingresa en el arreglo dinámico de resultados. Una vez que se haya terminado de recorrer

el arreglo que contiene los valores de los granos pequeños se obtiene el promedio de todos

los datos almacenados en el arreglo de valores numéricos y el resultado de este es

almacenado como resultado de la consulta original.

Es importante notar, que esta vez el proceso consumirá mucho tiempo y recursos, sin

embargo, posteriormente el sacrificio de ambos factores al responder a esta consulta son

altamente benéficos, ya que ahora se tienen almacenados en la base de datos información

sobre todos los valores de la granularidad que se preguntó y sobre la granularidad inmediata

más baja.

5.5.5 Drill – down

Teniendo claro el funcionamiento del operador roll – up, implementar el operador drill –

down se convierte en una tarea sumamente sencilla, ya que se trata justamente de la

operación inversa. En esta ocasión se trata de obtener el resultado de una consulta de grano

inferior, en base a una consulta previamente realizada sobre algún grano superior de la

dimensión.

A la par de los anteriores operadores, este también se implementó con java y SQL, sobre la

plataforma JDBC. La operación drill-down consiste en reutilizar parte de una

consulta realizada con anterioridad y que corresponda a un grano más alto al de la consulta

actual.

El código de implementación realiza las siguientes operaciones: 1) mediante una

instrucción SQL ejecutada desde java; 2) buscar en la tabla de almacenamiento si se tiene

una vista materializada que contenga los valores de la granularidad inmediata más alta al

grano que fue seleccionado por el usuario en la interfaz; 3) recuperar de esta vista las tuplas

correspondientes al grano y con estas crear una nueva vista materializada; 4) ya con las

tuplas seleccionadas se calcula la función de agregación y; 5) se actualizan las tablas

correspondientes.

Como se puede observar en el párrafo anterior sólo se trata de un par de consultas SQL que

recuperan el nombre de la vista del grano superior y después se realiza una consulta de

selección sobre esta misma vista. El proceso de formulación de las sentencias es realizado

en java, de igual manera como se describió en los operadores anteriores.

5.6 Interfaz y consultas

Para realizar la aplicación con la que interactúe el usuario final se hizo un diseño que fuese

fácil de manipular para este y que lo fuese guiando a través de la misma ejecución. Para la

implementación de esta interfaz de usuario se empleo el lenguaje de programación java el

cuál brinda clases que facilitan el diseño de una interfaz gráfica que sea amigable con el

usuario.

Lo primero que se debe tener en mente es que DOMINIQUE manipula dos tipos de

documentos electrónicos que son la climatología y la venta o consumo de productos. De

esta manera la interfaz le ofrece al usuario la posibilidad de interactuar por separado con

cada una de estas.

La interfaz de la climatología se reconoce con el título de “Temperaturas”, en esta se

pueden identificar las 4 dimensiones que conforman al cubo multidimensional y los

diferentes granos de cada una de estas. Las diferentes granularidades son presentadas con

sus nombres respectivos y un cuadro o pestaña en la cual se puede seleccionar los valores

que se tienen almacenados, permitiéndole al usuario hacer consultas entre las diferentes

dimensiones que conforman ese cubo. En la Figura 5.11 se muestra la interfaz de

climatología.

Figura 5.11 Interfaz de DOMINIQUE (Temperaturas)

Como se muestra en la Figura, el usuario debe seleccionar los valores de los granos

correspondientes a las dimensiones deseadas e inmediatamente debe de agregar los valores

seleccionados, en caso de no hacerlo el sistema le informa que no ha hecho la agregación

necesaria. Una vez que el usuario haya seleccionado los campos de su consulta este debe de

pulsar el botón de “Aceptar” para que se ejecute su consulta. Los resultados de esta serán

visualizados en el campo del título “Resultados”. En caso de arrepentirse de la consulta

hecha y querer realizar una nueva, deberá presionar el botón “Borrar” y automáticamente

todas las selecciones que haya hecho serán eliminadas

Para la interfaz de consumo de productos se procedió de la misma forma que para la

climatología, solo que en esta se presentan sólo tres dimensiones, que son las

correspondientes al diseño multidimensional del consumo de productos, la Figura 5.12

muestra esta interfaz.

Figura 5.12 DOMINIQUE interfaz (Consumo de productos)

Con lo primero que se debe de proceder es seleccionar la función de agregación que se

desea consultar, es decir si se quiere el valor máximo, mínimo o promedio, como se

muestra en la Figura 5.13.

Figura 5.13 Elección de la función de agregación

Para clarificar el procedimiento de selección de algún valor se presenta la Figura 5.14 y

5.15. En esta se presenta la selección del grano ciudad en la dimensión temperatura. Lo

primero que se debe hacer es seleccionar el cuadro que dice “Región”, es decir la

dimensión, lo siguiente es seleccionar el grano que se desee, para el caso del ejemplo es

“Ciudad”. Una vez ya seleccionados estos se puede elegir un valor en la pestaña, una vez

que este haya sido elegido se debe presionar el botón de “Agregar” y entonces el valor será

colocado en la pestaño ubicada debajo de los botones. En caso de querer seleccionar otro

valor deberá repetir la selección de la primera pestaña y repetir el resto de pasos. En caso de

que ya haya agregado algún valor y desee retirarlo, deberá de elegirlo en la pestaña ubicada

debajo de los botones y después presionar el botón “Quitar”.

Figura 5.14 Elegir un valor en un grano

Figura 5.15 Agregar el valor seleccionado

Sin embargo, es posible que al usuario se le olvide agregar el valor seleccionado o bien no

seleccione el cuadro de la dimensión o el del grano deseado, e incluso que intente

seleccionar más de un grano por dimensión. La interfaz de usuario es capaz de controlar

todas estas posibles situaciones. En el caso de que olvide seleccionar el grano o la

dimensión y en el que intente seleccionar dos granos en una misma dimensión el sistema

reacciona inmediatamente mostrándole un cuadro de dialogo donde le informa que alguno

de los dos errores fue cometido y borra la selección de los cuadros de los granos. Un

ejemplo de esto se muestra en la Figura 5.16 y 5.17. Y para el caso en que el usuario olvida

agregar los datos, el sistema espera hasta que se pulse el botón de “Aceptar” y entonces le

aparece un cuadro de dialogo recordándole que olvido agregar algún valor de los elegidos.

Figura 5.16 Mensaje de advertencia por no haber seleccionado la dimensión o el grano

Figura 5.17 Mensaje de advertencia de doble selección de grano en una dimensión

Por último, una vez que el usuario ha ejecutado su consulta correctamente, esta se procesa y

el resultado es mostrado en la región que antes ya se mencionó. Pero también existe la

posibilidad de que no se tengan datos disponibles para la consulta ejecutada, en este caso se

muestra nuevamente un cuadro de diálogo notificándole al usuario lo que ocurrió. Se

muestra un ejemplo en la Figura 5.18.

Figura 5.18 Mensaje de no disponibilidad de datos a la consulta

Otro aspecto que vale la pena mencionar es la facilidad que presta el sistema de agrupar los

valores de una cierta consulta. Esto se refiere a que en una dimensión puede elegir el grano

que desee y en el resultados le aparecerán los diferentes elementos correspondientes a un

grano más bajo. Para clarificar esto imaginemos que se hace una consulta sobre la

temperatura máxima registrada en el estado de Veracruz. Lo primero sería seleccionar la

dimensión “Región” y el grano “Estado”, y ahí se elige el estado de VERACRUZ-LLAVE,

en caso de que se seleccione la opción de “Agrupar por” en el cuadro de resultados le

aparecerá la temperatura máxima del estado, pero también de las diferentes ciudades que

pertenecen al estado.

En la Figura 5.19 se muestra un ejemplo de consulta en el cubo de temperatura, donde se

pregunta por la temperatura máxima registrada en el estado de Veracruz, durante el verano

en el mes de junio y estando el cielo soleado.

Figura 5.19 Ejemplo de consulta en cubo de temperatura

5.7 Discusión

Respecto a la extracción de los datos en las fuentes, los algoritmos encargados de esto son

hechos exclusivos para el formato de cada página web. Como es de suponerse cada página

proporciona mucha más información de la que le es útil al sistema. De esta forma, la

construcción de cada parser está diseñada para la recuperación exclusiva de la información

deseada. En el caso de que hubiese algún tipo de cambio en la estructura de las páginas web

que funcionan como fuentes, habría que actualizar la estructura de parseo de los

algoritmos.

Al respecto de este inconveniente se buscaron sistemas ya implementados que recuperasen

la información sin importar los cambios de las páginas, sin embargo, ninguno de los

sistemas analizados tenía las características necesarias para solucionar este aspecto.

La ventaja de utilización de este protocolo es que esta diseñado 100% en java y utiliza el

protocolo nativo de red para comunicarse con el sistema gestor de la base de datos, por

tanto, se independiza totalmente de la plataforma. El único inconveniente que conlleva el

uso de este controlador es que se crea una dependencia con un tipo de servidor de un

sistema gestor de base de datos.

Otro aspecto que es de mencionarse, es la dificultad para recuperar los datos de consumo de

productos. Debido a razones de seguridad del Banco de México, no era posible realizar un

parseo directo de las páginas donde proporcionaba la información. La única solución que

pudo ser factible fue recuperar cada una de las páginas y guardarlas en una máquina local,

para ya después estando la información disponible en dicha ubicación parsear las páginas

web seleccionadas.

Actualmente existe software que ya implementa los operadores OLAP y facilitan mucho la

manipulación de la información. Un claro ejemplo de esto es la versión 9i de Oracle, misma

que tiene herramientas para el desarrollo de data warehouses. Para poder utilizar esta

herramienta es necesario implementar desde la fase de diseño la información en base a los

estándares requeridos por Oracle 9i, de otra forma se vuelve casi imposible emplear los

operadores OLAP que ya implementa. Por esta razón y cuestiones de acceso a dicha

versión, DOMINIQUE es implementado en la versión de Oracle 8i, la cual no proporciona

la herramienta OLAP, por lo tanto se emplea un propio diseño y la implementación propia

de dichos operadores.