capítulo 1: almacenamiento y gestión de datos científicos
TRANSCRIPT
Universidad Central “Marta Abreu” de las Villas.
Facultad Matemática, Física y Computación
Licenciatura en Ciencias de la Computación
Título
Estudio de la factibilidad del uso de PostgreSQL para el trabajo con
datos científicos.
Autor: Marlén López Mora.
Tutor: Msc. Alberto Morell Pérez.
Departamento: Computación Gráfica.
“Año 50 de la Revolución”
Santa Clara
2008
II
Hago constar que el presente trabajo fue realizado en la Universidad Central Marta Abreu de
Las Villas como parte de la culminación de los estudios de la especialidad de Ciencia de la
Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que
estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en
eventos ni publicado sin la autorización de la Universidad.
______________
Firma del autor
Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la
dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de
esta envergadura referido a la temática señalada.
_______________ _________________
Firma del tutor Firma del jefe del
Laboratorio.
III
Dedicatoria
A mis padres, Santiago y Marlene.
IV
Agradecimientos
A todos los profesores que me han impartido clases,
Gracias por sus enseñanzas.
A todos los que de una forma u otra contribuyeron
A la elaboración de este trabajo.
V
Resumen
En los últimos años, los avances en la tecnología de la información han facilitado la obtención
de grandes cantidades de información. La Visualización Científica proporciona métodos y
herramientas capaces de procesar y analizar datos del orden de los Terabytes. La manipulación,
el almacenamiento, el acceso eficiente y el análisis de esos datos representan una tarea que
constituye un gran reto. Muchos de estos datos son generados en forma de arreglos numéricos.
Tradicionalmente se han empleado archivos planos secuenciales para almacenar los datos
científicos, pues se ha demostrado que los SGBD resultan demasiado lentos para manipular
datos de gran complejidad. Los formatos nativos de datos científicos incluyen estructuras para
soportar grandes cantidades de datos, arreglos multidimensionales, una amplia variedad de
tipos de datos y métodos para el acomodo de metadatos. Aunque el trabajo con estas
herramientas resulta ventajoso para la manipulación de archivos secuenciales, los científicos, al
usarlas en su trabajo, se enfrentan con la problemática del traslado y almacenamiento de una
gran cantidad de archivos de soluciones individuales. Con el advenimiento de los SGBD-OR
han surgido en los últimos años herramientas capaces de soportar gran cantidad de arreglos de
datos multidimensionales. Estos sistemas combinan las ventajas de los SGBD-OO y sus
antecesores, los SGBD relacionales. En este trabajo se hace un estudio de la factibilidad del
uso del SGBD-OR PostgreSQL para la manipulación y visualización de los datos científicos a
través de las extensiones que se les han creado para estos fines.
VI
Abstract
In the last years, the advances in the technology of the information have facilitated the
obtaining of big quantities of information. Scientific Visualization provides methods and tools
able to process and to analyze data of the order of the Terabytes. Manipulation, storage,
efficient access and data analysis represent a task that constitutes a great challenge. Many of
these data are generated in form of numeric arrangements. Traditionally sequential plane files
have been used to store scientific data, because it has been demonstrated that the DBMS is too
slow to manipulate data of great complexity. Scientific data native formats include structures to
support big quantities of data, multidimensional arrangements, a wide variety of types of data
and methods for metadatos accommodation. Although work with these tools is advantageous
for sequential files manipulation, scientists face with transfer and storage problem of great
quantity of singular solutions files, when using them. In the last years, with coming of DBMS-
OR has arisen tools able to support great quantity of multidimensional data arrays. These
systems combine the advantages of those DBMS-OO and their predecessors, the relational
DBMS. In this work, a study of the feasibility of the use of PostgreSQL DBMS-OR systems is
made for manipulation and visualization of scientific data through the extensions created for
that.
VII
Índice.
Introducción. ................................................................................................................................ 2
Capítulo 1: Almacenamiento y Gestión de Datos Científicos. .................................................... 7
1.1 - Bases de Datos Científicas. ............................................................................................. 7
1.1.1 - Archivos Binarios. .................................................................................................... 8
1.1.1.1 – NetCDF. ................................................................................................................ 9
1.1.1.2 - HDF. .................................................................................................................... 12
1.1.2 - Sistemas Gestores de Bases de Datos aplicados. .................................................... 20
1.1.2.1 - Sistemas de Base de Datos Relacionales (SGBDR). ........................................... 21
1.1.2.2 - Sistemas de Bases de Datos Orientadas a Objeto (SGBD-OO). ......................... 22
1.1.2.3 - Sistemas de Bases de Datos Objeto Relacionales (SGBD-OR). ......................... 24
1.2 - Gestión de los DC. ......................................................................................................... 26
1.2.1 - Análisis estadístico. ................................................................................................ 27
1.2.2 - Visualización de Datos Científicos......................................................................... 27
1.2.2.1 - Requerimientos. ................................................................................................... 31
1.2.2.2 - Consultas. ............................................................................................................ 34
1.2.2.3 - Softwares de Visualización. ................................................................................ 36
1.2.2.3.1 - Iris Explorer. ..................................................................................................... 36
1.2.2.3.2 - Advanced Visual Systems (AVS)..................................................................... 37
1.2.2.3.3 - Khoros. ............................................................................................................. 38
1.2.2.3.4 - Amira. ............................................................................................................... 39
1.2.2.3.5 - OpenDX. ........................................................................................................... 40
Conclusiones parciales ........................................................................................................... 41
Capítulo 2: Uso del SGBD-OR PostgreSQL para el trabajo con datos científicos. .................. 42
2.1- PostgreSQL. .................................................................................................................... 42
2.1.1- Características del PostgreSQL. .............................................................................. 43
2.1.2 – Capacidad del PostgreSQL. ................................................................................... 44
2.1.3 - Uso del PostgreSQL. .............................................................................................. 45
2.1.4 - Soporte para PostgreSQL. ...................................................................................... 45
2.1.5 - Tipos de Datos. ....................................................................................................... 46
2.1.6 - Extensibilidad de PostgreSQL para el almacenamiento de datos científicos. ........ 48
2.1.7 – Medidas para mejorar el rendimiento en el acceso a los datos científicos
almacenados en el PostgreSQL. ......................................................................................... 49
2.2- Modelado de los datos científicos. ................................................................................. 49
2.2- Importación de los Datos. ............................................................................................... 52
2.3- Accediendo a los DC en PostgreSQL. ............................................................................ 53
Conclusiones Parciales........................................................................................................... 54
Capítulo 3: Análisis del Rendimiento. ....................................................................................... 55
3.1 - Ambiente de prueba. ...................................................................................................... 55
3.2 - Métricas de Rendimiento. .............................................................................................. 56
3.3 – Caso de Estudio 1.......................................................................................................... 57
3.4 – Resultados del Caso de Estudio 1. ................................................................................ 58
3.5 – Caso de Estudio 2.......................................................................................................... 60
3.6 – Resultados del Caso de Estudio 2. ................................................................................ 61
VIII
3.7 - Comparación entre los dos Casos de Estudio. ............................................................... 63
Conclusiones parciales ........................................................................................................... 64
Conclusiones y Recomendaciones ............................................................................................. 65
Bibliografía ................................................................................................................................ 66
Anexo ......................................................................................................................................... 68
Anexo I. Esquema de BDVar................................................................................................. 68
Anexo II. Tablas generadas para BDVar. .............................................................................. 69
Anexo III. Tabla del comportamiento de concentraciones CO2. ........................................... 71
1
Introducción
2
Introducción.
Los volúmenes de datos generados por las aplicaciones científicas crecen de manera
exponencial cada año. Los avances alcanzados en instrumentos, detectores y tecnología de
computadoras están creando repositorios de datos del orden de los Terabytes en muchas
disciplinas. La Visualización Científica (VC) emerge como una alternativa para extraer
información de estos grandes volúmenes de datos, basada en la generación, a partir de ellos, de
imágenes, ya sean estáticas o en movimiento. Para que este proceso sea efectivo se necesitan
formas eficientes de almacenamiento y gestión de los datos.
Una alternativa común usada en los primeros algoritmos de cálculos científicos fue el empleo
de archivos planos secuenciales para el almacenamiento de los datos de entrada y salida. Esta
solución, aunque simplifica el acceso, es ineficiente cuando se almacenan y procesan grandes
conjuntos de datos, además de presentar problemas de interoperabilidad.
La necesidad de tener una manera eficiente e independiente de la arquitectura de leer y escribir
datos científicos condujo a la creación de nuevos modelos de datos. Estos modelos incluyen
estructuras de datos que soportan grandes conjuntos de datos, arreglos multidimensionales, gran
variedad de tipos de datos (números enteros, números en punto flotante, cadenas, entre otros), y
métodos para incorporar metadatos. Como ejemplos de estos estándares tenemos NetCDF
(NetCDF, 1998), HDF (HDF, 1998) y FITS (NASA). Cada uno incluye una biblioteca que
encapsula los archivos correspondientes, y brinda una forma independiente de la plataforma para
crear, acceder, buscar y visualizar los datos. Estas bibliotecas están disponibles mediante una
Interface de Programación de Aplicaciones (API, por sus siglas en ingles) que puede ser usada
desde varios lenguajes, siendo los más comunes C, C++ y Java.
Estos estándares facilitan el intercambio de datos entre los científicos. Sin embargo, es común
que cada disciplina o comunidad científica favorezca un formato específico, así como las
herramientas construidas sobre él, lo que hace que el intercambio fuera del grupo sea
problemático.
Por otro lado, aunque las ventajas sobre el uso de archivos planos son considerables, aún se
presenta el problema de la generación de un gran número de archivos, pues los científicos
acostumbran a generar un archivo por cada simulación. Esto provoca que, cuando el sitio de
almacenamiento no coincide con el de procesamiento, deban moverse muchos archivos de un lugar
3
a otro. Además, los archivos se organizan en directorios. El sistema de archivos no contiene más
metadatos que la estructura jerárquica de nombres de directorios y archivos. Esto promueve un
modelo de datos de hágalo-usted-mismo (Gray, 2003), que no se beneficia del surgimiento de las
nuevas herramientas de análisis de datos. En este modelo, el análisis de datos se realiza buscando
primero todos los archivos relevantes, abriendo cada archivo, buscando los datos necesarios y
moviéndose hacia el próximo archivo. Cuando todos los datos están en memoria, o en un archivo
intermedio, el programa puede comenzar el análisis. Este proceso de “filtra, después analiza”, hace
que el análisis de grandes volúmenes de datos con herramientas procedurales convencionales sea
más lento a medida que el volumen de datos aumenta. Esta forma de acceso impide las búsquedas
temporales, espaciales, asociativas y paralelas, así como el uso de un lenguaje de consulta de alto
nivel.
Varios de los problemas mencionados anteriormente pueden ser resueltos usando Sistemas de
Gestión de Bases de Datos (SGBD). Estos están diseñados para minimizar el tiempo de las
búsquedas, hacer balance de carga y manejar grandes volúmenes de datos. Además, permiten el
acceso simultáneo a los datos desde varias aplicaciones, lo que brinda un adecuado ambiente para
compartir los mismos. Los SGBD también brindan poderosos lenguajes de consultas no
procedurales, independencia física y lógica de los datos, y variadas herramientas para el diseño y
manipulación de los datos. Sin embargo, la comunidad científica no ha sido proclive a usar los
SGBD comerciales. Entre las razones se encuentran que los SGBD Relacionales (los más usados
en el mercado) no brindaban soporte para arreglos multidimensionales y su rendimiento al trabajar
con grandes arreglos era bajo. Sin embargo, el surgimiento de los SGBD Objeto Relacionales
(SGBD-OR) han abierto las puertas a la inclusión de conjuntos de datos científicos dentro de los
SGBD. Por otra parte, las aplicaciones científicas en general, y las de visualización en particular,
difieren de las aplicaciones comerciales en la forma de procesar los datos (Pérez Risquet, 2006).
Planteamiento del problema.
Las aplicaciones científicas basadas en archivos binarios de datos científicos estándares
presentan varias dificultades, entre las que se encuentran el uso de varios formatos incompatibles
entre si y la necesidad de almacenamiento y transmisión de muchos archivos individuales. Los
SGBD-OR brindan una alternativa para resolver estos problemas, pero a su vez presentan retos
4
para usarlos en el almacenamiento de datos científicos, como son la gestión eficiente de grandes
volúmenes de estos y su modelación.
Consecuentemente, en este trabajo se plantean las siguientes:
Preguntas de investigación.
¿Qué ventajas ofrece un SGBD-OR para el almacenamiento y visualización de datos
científicos?
¿Qué medidas se pueden tomar para mejorar el rendimiento en el acceso a los datos
científicos almacenados en un SGBD-OR, que contrarresten la sobrecarga impuesta por
aquellas funcionalidades del mismo que no son necesarias en las aplicaciones
científicas y de visualización de datos científicos?
¿Cómo es el rendimiento de las operaciones de acceso a los datos científicos, en
especial aquellas orientadas a la visualización de los mismos, usando un SGBD-OR,
comparado con esas mismas operaciones usando una biblioteca estándar como HDF?
Teniendo en cuenta lo anterior se proponen los siguientes objetivos.
Objetivos Generales.
Estudiar la factibilidad del uso de un SGBD-OR para el almacenamiento y visualización de
datos científicos.
Objetivos Específicos.
Determinar las tendencias en el uso de Bases de Datos para el almacenamiento de datos
científicos (Bases de Datos Científicas), con respecto a aspectos tales como tipo de
SGBD (relacional, objeto-relacional, orientado a objetos, deductivo), tipos de datos
almacenados, forma de modelar los datos, entre otros.
5
Determinar las ventajas que ofrece un SGBD-OR para el almacenamiento y
visualización de datos científicos.
Definir medidas para mejorar el rendimiento en el acceso a los datos científicos
almacenados en el SGBD-OR escogido, que contrarresten la sobrecarga impuesta por
las funcionalidades del mismo.
Implementar un caso de estudio de visualización de datos científicos almacenados en
archivos HDF y en un SGBD-OR y hacer una comparación de rendimiento entre las
dos soluciones.
Justificación de la investigación.
Los instrumentos científicos y las simulaciones por computadoras están generando grandes
cantidades de datos que necesitan nuevos métodos de análisis y organización de los datos. La VC
es una potente herramienta que permite analizar grandes volúmenes de datos de manera rápida,
revelando relaciones que pueden perderse al usar métodos estadísticos.
El reto que se presenta a los investigadores comprende varios aspectos. Primero, almacenar
todo ese extenso volumen de datos; segundo, apoyarse en un Gestor de Bases de Datos que permita
manejar lo recopilado de una manera adecuada; y tercero, métodos para “filtrar” y extraer
resultados que permitan investigar problemas y obtener información relevante.
PostgreSQL es un SGBD-OR gratis y de código abierto, muy usado en la actualidad. Uno de
sus puntos fuertes, es la capacidad de tratar grandes volúmenes de datos con escalabilidad, o sea,
su arquitectura puede ser continuamente ampliada de acuerdo con la demanda de los usuarios.
Exactamente en este contexto, entran las aplicaciones solicitadas por las áreas de investigación
científica que necesitan de una infraestructura robusta y en continua expansión.
Forma de validar los resultados.
Se implementará un caso de estudio de visualización de datos científicos almacenados en
archivos HDF y en un SGBD-OR y se harán comparaciones de rendimiento entre las dos
soluciones.
6
Hipótesis.
El uso de un SGBD-OR para el almacenamiento y visualización de datos científicos ofrece
ventajas sobre el uso de una biblioteca estándar de acceso a datos científicos como HDF.
Es posible definir medidas para mejorar el rendimiento en el acceso a los datos científicos
almacenados en el SGBD-OR, que contrarresten la sobrecarga impuesta por las funcionalidades
del mismo.
7
Capítulo 1: Almacenamiento y Gestión de Datos Científicos.
Uno de los últimos retos para los programadores ha sido crear las condiciones para almacenar
la creciente cantidad de datos científicos que se derivan de los últimos estudios, principalmente los
relacionados con astrofísica, física de altas energías y genética.
Ya se asoman los términos de terabytes y posiblemente petabytes para referirse a la impensada
cantidad de datos electrónicos que se han derivado de la creciente actividad científica. Ha llegado a
estimarse que sólo en el último año la cantidad de datos científicos supera todos los años anteriores
desde que comenzó la ciencia. Más allá de la capacidad de almacenar datos, se empieza a hablar de
nuevas necesidades surgidas por el acceso y forma de procesar la información científica.
1.1 - Bases de Datos Científicas.
Las bases de datos científicas son, casi por definición, muy extensas. Pero el tamaño por sí solo
no hace necesariamente distinción entre una base de datos científica y una comercial. Las bases de
datos científicas están separadas de sus primas comerciales por tres características fundamentales.
Primero, las entidades observadas son frecuentemente más complejas, con interrelaciones
significativas. Consecuentemente, la tecnología orientada a objetos frecuentemente parece más
apropiada.
Segundo, las bases de datos científicas están muy pocas veces orientadas a las transacciones.
Los datos son registrados para ser preservados con posterioridad, y no están cambiando
constantemente para reflejar el estado actual de un sistema. La recuperación de datos de interés es
lo más importante.
Tercero, la recuperación de datos es frecuentemente volumétrica, esto es, basada en dos o más
búsqueda de rangos o parámetros conjuntivos. Las consultas espaciales constituyen un caso
especial de recuperación volumétrica. Esto sólo es tan importante, que los métodos especiales de
acceso, como los archivos grid y los árboles R+, son desarrollados exclusivamente para ejecutar
accesos eficientemente con respecto a estos diseños volumétricos.(Pfaltz, 1998).
Un ejemplo de base de datos científicas constituye el sistema concebido e implementado sobre
una base de datos relacional en el Observatorio Astronómico Nacional de Llano del Hato (OAN),
8
en los Andes Merideños, capaz de contener información sobre el sondeo del firmamento en la
franja ecuatorial (Anexo I. Esquema de BDVar).
La nombrada Base de Datos de Variabilidad en Objetos Celestes (BDVar), dispone una tabla
(Anexo II. Tablas generadas para BDVar.) para datos de las observaciones y dentro de la
información directa que se recaba para ellas, se encuentra: un identificador único, la fecha y hora
de la observación, la Ascensión Recta, la Declinación, número de la observación según el catálogo
(que es único para cada noche de observación, pero puede repetirse incluso para observaciones de
objetos distintos, en noches diferentes), el CCD líder, número de cuadros en que aparece el objeto
en la observación, el ángulo horario e indicador sobre la calidad de la imagen. Indirectamente,
relacionando la observación con los CCD’s y filas, se encuentran: filtros utilizados, color de los
filtros, términos de color, segundos de arco y punto cero. Por último, asociando cada objeto con los
cuadros (o frames) en que aparece, se registran sus coordenadas X, Y en píxeles.
1.1.1 - Archivos Binarios.
Los principales adelantos en los programas de simulación científica y recolección de datos,
obtenidos de las observaciones espaciales, por solo citar un ejemplo, han permitido desarrollar
potentes herramientas de la Visualización Científica que poseen su propio campo de aplicación.
Muchos de estos datos son generados en forma de arreglos numéricos.
Inicialmente, se usaron archivos planos secuenciales para almacenar estos datos. Esta solución,
aunque simplifica el acceso, resulta ineficiente cuando se trata del almacenaje y procesamiento de
grandes conjuntos de datos. Por otra parte, el uso de representaciones binarias causa problemas de
interoperatividad, debido a que el orden de almacenamiento de los octetos difiere según la
arquitectura de computadoras empleada (Gray, 2005).
La tecnología de la instrumentación detrás de estos generadores de los datos está mejorando
aceleradamente, y a un ritmo superior a las técnicas disponibles para mejorar y poder utilizar los
datos resultantes (Treinish, 2005).
Los científicos demandaban para su actividad un método eficiente e independiente para la lectura
y escritura de datos científicos que permitiera desarrollar bibliotecas especificas de accesos de datos
(Cohen et al., 2006).
9
Surgen así, desarrolladas por universidades y empresas, aplicaciones para representar, almacenar
y procesar esta información y para facilitar su manipulación, permitiendo de esta forma diversas
representaciones para muchos tipos de datos y el acceso rápido y eficiente a estos, proveyendo
herramientas para una visualización efectiva. Todo ello trajo como consecuencia el surgimiento de
nuevos formatos de datos, que permiten representar arreglos y datos tabulares, así como las
relaciones entre ellos.
En la década de los 80’s se diseñaron dos populares bibliotecas para cubrir estas necesidades:
Network Common Data Form (NetCDF, 1998) y Hierarchical Data Format (HDF, 1998). Ambos
formatos incluyen estructuras para soportar grandes cantidades de datos, arreglos
multidimensionales, una amplia variedad de tipos de datos (enteros, números de punto flotantes,
cadenas de caracteres, etc.) y métodos para el acomodo de metadatos1.
Aunque las herramientas antes mencionadas (NetCDF y HDF) resultaban ventajosas sobre los
archivos secuenciales, los científicos, al usarlas en su trabajo, se enfrentaban con el traslado y
almacenamiento de una gran cantidad de archivos de soluciones individuales en demasía
engorroso.
Ambas bibliotecas están implementadas como bibliotecas de funciones vinculadas dentro de
sus códigos, no como servidores; además no controlan las transacciones. Las implementaciones
para el control de transacciones conllevan un gran esfuerzo de escritura del código (Cohen, 2006).
1.1.1.1 – NetCDF.
NetCDF (Network Common Data Form) fue creado en 1988. Es una interfaz de una biblioteca
de funciones de acceso a datos diseñada para el almacenamiento y recuperación de datos en forma
de arreglos, donde cada arreglo es una estructura rectangular n-dimensional en la que todos sus
elementos son del mismo tipo de dato. Un escalar (un solo valor) es un arreglo 0-dimensional.
La biblioteca NetCDF implementa un tipo de dato abstracto, por lo que todas las operaciones
para crear, acceder y manipular datos deben usar sólo las funciones que provee la interfaz. La
representación de los datos está oculta para las aplicaciones que usen la interfaz, de modo que se
puede modificar la forma en la que estos se encuentran almacenados sin afectar los programas
1 Son “datos sobre los datos”.Nivel superior de la información, o instrucciones que describen el
contenido, contexto, calidad, estructura, y accesibilidad de una colección de datos específica.
10
existentes. La representación física de los datos en formato NetCDF fue diseñada para ser
independiente de la computadora en que fueran guardados.
Los datos son vistos como una colección de objetos portables y autodescriptivos que pueden
ser accedidos a través de una interfaz simple. Se puede acceder directamente a los valores sin
conocer el modo en que estos datos están almacenados; para esto se dispone de informaciones
auxiliares sobre los datos que son almacenadas juntamente con estos. Los programas de aplicación
pueden transformar, combinar, analizar y mostrar campos específicos de estos conjuntos de datos.
El desarrollo de estas aplicaciones ha dado lugar a una mejor accesibilidad de los datos y a una
mejor reutilización del software para la administración, análisis, y visualización de datos
orientados a arreglos.
La biblioteca NetCDF está soportada sobre varios sistemas operativos UNIX y dispone
tambien de varias interfaces para Windows como LeoNetCDF y netcdf-3.5.0.win32bin. Este
paquete fue también probado en algunos otros sistemas operativos, con la asistencia de usuarios
con acceso a esos sistemas.
Un conjunto de datos de NetCDF clásico es almacenado como un solo archivo que consiste en
dos fragmentos: un encabezado y una parte de datos. El encabezado contiene toda la información
sobre las dimensiones, variables y atributos del archivo, incluyendo sus nombres, tipos y otras
características. La sección de los datos se divide en una parte de datos de tamaño fijo, conteniendo
los datos para variables que no tienen una dimensión ilimitada, y otra parte de datos de tamaño
variable, conteniendo los datos para variables que tienen una dimensión ilimitada.
La información sobre cada variable incluye: el desplazamiento al inicio de los datos de la
variable para variables de tamaño fijo y el desplazamiento relativo de otras variables dentro del
registro. El encabezamiento también contiene los tamaños dimensionales e informaciones
necesarias para hacer un mapa de índices multidimensionales para cada variable hacia los
desplazamientos apropiados.
Por defecto, este encabezamiento tiene poco espacio extra para su uso; es tan grande como
necesita ser para poder incluir las dimensiones, variables, y atributos (incluyendo todos los valores
de atributos) en el conjunto de datos de NetCDF. Esto tiene la ventaja de que los archivos sean
compactos, requiriéndose muy poco costo para almacenar los datos auxiliares que hacen a los
conjuntos de datos autodescriptivos. Una desventaja de esta organización es que cualquier
operación en un conjunto de datos de NetCDF que requiera que crezca el encabezamiento (por
11
ejemplo: adicionar nuevas dimensiones o nuevas variables) requiere de movimiento de los datos
mediante la copia de los mismos.
No obstante si se crean todas las dimensiones necesarias, variables y atributos, antes de escribir
los datos, y se evita adiciones posteriores y renombramientos de componentes que requieran más
espacio en la parte de encabezamiento del archivo, entonces se puede evadir el costo asociado al
cambio posterior del encabezamiento.
Otra alternativa para esta problemática es usar una versión de la función enddef para reservar
espacio extra en el encabezamiento del archivo de forma explícita. Mediante esta reservación se
puede evitar el gasto de tener que mover todos los datos posteriormente.
Cuando se cambia el tamaño del encabezamiento, los datos en el archivo son movidos y la
localización de los valores de datos en el archivo cambia. Si otro programa esta leyendo el
conjunto de datos de NetCDF durante la redefinición, su vista estará basada en el archivo viejo,
mostrando probablemente índices incorrectos. Si los conjuntos de datos de NetCDF están
compartidos, debe estar previsto algún mecanismo externo a la biblioteca NetCDF para que
prevenga el acceso a los lectores durante la redefinición.
Las partes de datos con tamaño fijo que le siguen al encabezamiento contienen todos los datos
versátiles para las variables que no emplean una dimensión ilimitada. Los datos para cada variable
son almacenados contiguamente en esta parte del archivo. Si no hay dimensión ilimitada, esta es la
última parte del archivo NetCDF.
La parte que le sigue a los datos de tamaño fijo consiste de un número variable de registros de
tamaño fijo, donde cada uno de los cuales contiene datos para todas las variables de registros.
Una de las metas de NetCDF es soportar acceso eficiente a pequeños subconjuntos de en
grandes conjuntos de datos. Para lograr esto, NetCDF utiliza accesos directos en lugar de accesos
secuenciales. Esto puede ser mucho más eficiente cuando el orden en que los datos son leídos es
diferente del orden en que fueron escritos, o cuando deben ser leídos en diferentes órdenes por
diferentes aplicaciones.
El costo computacional para la representación externa portable depende de muchos factores,
incluyendo el tipo de dato, el tipo de computador, la granularidad del acceso a los datos, y de cuán
bien se ha ajustado la implementación a la computadora en la que está corriendo. Este costo es
típicamente pequeño en comparación con todo el conjunto de recursos utilizados por una
12
aplicación. De cualquier forma, el costo de la capa de representación externa es usualmente un
precio razonable a pagar por acceso de datos portables.
A pesar de que la eficiencia en el acceso a los datos ha sido un aspecto importante en el diseño
e implementación de NetCDF, el hecho de tener aún que utilizar la interfaz para acceder a los
datos puede en algunas ocasiones resultar ineficiente, por ejemplo: cuando se solicita una porción
de datos que requiere un solo valor de cada registro.
Una de las razones primarias para usar la interfase de NetCDF para aplicaciones que traten
con arreglos es para tomar ventaja de las utilidades de alto nivel y las aplicaciones genéricas de
NetCDF para este tipo de datos. Algunas de las funciones más utilizadas de la biblioteca se
despliegan a continuación:
ncdump: lee un conjunto de datos NetCDF e imprime una representación textual de la
información en el conjunto de datos.
ncgen: lee una representación textual de un conjunto de datos NetCDF y genera el
archivo binario NetCDF correspondiente o un programa en C o FORTRAN para crear
el conjunto de datos NetCDF.
ncmeta: imprime los metadatos seleccionados para uno o mas conjuntos de datos
NetCDF
ncrob: realiza varias operaciones (copy, sum, mean, max, min, etc.) con los datos
leídos, impresos o escritos para archivos texto o con partes seleccionadas de variables o
atributos NetCDF (NetCDF, 1998).
El programa NetCDF de Unidata está disponible libremente vía FTP para alentar a su uso
generalizado. [ftp://ftp.unidata.ucar.edu/pub/NetCDF]
1.1.1.2 - HDF.
HDF (Hierarchical Data Format) es un formato de datos desarrollado por el Centro Nacional
de Aplicaciones de Supercómputo (NCSA) de la Universidad de Illinois. Es una biblioteca de
funciones que permite estructurar los archivos de datos y posee un formato de archivo multiobjeto
para la transferencia de datos gráficos y numéricos entre ordenadores. HDF se encuentra
libremente disponible. La distribución incluye, además de la biblioteca HDF, las utilidades de línea
de comando HDF y una suite de prueba (código fuente solamente).
13
HDF posee diferentes niveles de interacción (Figura 1. Niveles de interacción de HDF.). En su
nivel más bajo es un formato físico de archivos para el almacenamiento de datos científicos. En su
nivel más alto es una colección de utilidades y aplicaciones para manipular, ver y analizar datos en
los archivos HDF. Entre estos niveles existe una biblioteca de programas que provee una Interfaz
de Programación de Aplicaciones (API) de alto nivel y una interfaz de datos de bajo nivel.
En el nivel más alto de HDF se incluyen varias utilidades de línea de comandos para
administrar y visualizar los archivos HDF, aplicaciones de NCSA que soportan visualización y
análisis de datos, y una gran variedad de aplicaciones de terceros.
Figura 1. Niveles de interacción de HDF.
El paquete HDF se agrupa en las siguientes categorías.
API’s de C y de FORTRAN 77.
Herramientas de análisis y visualización científica que leen y escriben archivos HDF.
Utilidades de línea de comandos para operar directamente en los archivos HDF.
Las utilidades de línea de comando son programas de aplicación que pueden ser ejecutados
invocándolos desde el intérprete de comandos como comandos UNIX. Estas realizan operaciones
comunes en los archivos HDF, como:
Convertir de un formato a otro, por ejemplo, desde y hacia JPEG/HDF.
Analizar y ver archivos HDF.
Manipular los archivos HDF.
De las utilidades HDF, hdp es una de las más importantes ya que provee información rápida
sobre los contenidos y objetos de datos en un archivo HDF. Puede listar los contenidos de los
archivos HDF en varios niveles con diferentes detalles. Además puede descargar los datos de uno
o más archivos en formato binario o ASCII.
14
Las API´s incluyen conjuntos de rutinas para el almacenamiento y acceso a tipos de datos
específicos, y se encuentran disponibles en los lenguajes C y Fortran. A pesar de que el uso de las
interfaces requiere programación, todos lo detalles de bajo nivel pueden ser ignorados.
Las API’s de HDF están divididas en dos categorías: las interfaces multiarchivo y las
interfaces de un solo archivo. Las interfaces multiarchivo son aquéllas que proporcionan el acceso
simultáneo a varios archivos HDF, esto es un rasgo importante que las interfaces de un solo
archivo no soportan.
HDF 4.0 (y versiones posteriores) soporta una interfaz de compresión de bajo nivel, que
permite que cualquier objeto de datos sea comprimido utilizando diferentes algoritmos.
Actualmente solo soporta tres algoritmos de compresión: RLE, Huffman adaptativo y LZ-77. En
el futuro se planea incluir además Lempel/Ziv-78 (el algoritmo de descompresión que utiliza gzip),
un Codificador Aritmético y un Algoritmo Huffman más rápido. También soporta compresión de
n bits para SDS y compresión JPEG para imágenes raster.
La interfaz de bajo nivel está reservada para desarrolladores de software. Fue diseñada para
E/S de flujo de datos directamente desde archivos, manipulación de errores, administración de
memoria y almacenamiento físico. Es esencialmente un conjunto de herramientas para
programadores experimentados, quienes desean hacer algo más de lo que HDF permite
actualmente a través de la interfaz de alto nivel. Las rutinas de bajo nivel están disponibles solo en
C.
Un archivo HDF contiene un encabezamiento, al menos un bloque descriptor de datos, y cero o
más elementos de datos. El encabezamiento de archivo lo identifica como un archivo HDF. Un
bloque descriptor de datos contiene un número de descriptores de datos. Un descriptor de datos y
un elemento de dato juntos forman un objeto de dato, esta es la estructura básica de agrupamiento
para el encapsulamiento de datos en un archivo HDF.
El archivo HDF posee una serie de rasgos importantes tales como:
Es versátil. HDF suporta muchos tipos diferentes de modelos de datos. Cada modelo de
dato define un conjunto específico de tipo de dato y provee una API para lectura,
escritura y organización de los datos y metadatos del tipo correspondiente. Los modelos
de datos soportados incluyen arreglos multidimensionales, imágenes de puntos y tablas.
Es auto-descriptivo, permitiendo una aplicación para interpretar la estructura y
contenidos de un archivo sin ninguna información proveniente del exterior.
15
Es flexible. Con HDF se pueden mezclar y asociar objetos relacionados agrupados en
un archivo y acceder a ellos como un grupo o como objetos individuales. Los usuarios
pueden además crear sus propias estructuras de agrupamiento utilizando un rasgo de
HDF llamado vgroups.
Es extensible. Puede acomodar fácilmente nuevos modelos de datos, sin tener en cuenta
si fueron adicionados por el equipo de desarrolladores de HDF o por los usuarios de
HDF.
Es portable. Los archivos HDF pueden ser compartidos a través de la mayoría de las
plataformas comunes, incluyendo muchas estaciones de trabajo y computadoras de alto
desempeño. Un archivo HDF creado en una computadora puede ser leído en un sistema
diferente sin modificación alguna.
No obstante, posee varias limitaciones, algunas de las cuales son:
Un solo archivo no puede almacenar más de 20,000 objetos complejos ni sobrepasar
los 2 gigabytes.
El modelado de los datos es menos consistente de lo que debieran ser. Existen más
tipos de objetos que lo necesario y los tipos de datos son demasiado rígidos.
La biblioteca de recursos es ambigua y excesivamente compleja.
HDF se encuentra actualmente en la versión 5, conocida como HDF5, la cual está diseñada
para solucionar algunas de las limitaciones de HDF4.
HDF5 incorpora las siguientes expansiones:
Un nuevo formato de archivo diseñado para solucionar algunas de las deficiencias de
HDF4, particularmente la necesidad de mayor almacenaje de objetos.
Un modelo de datos más simple y comprensivo, que incluye solo dos estructuras
básicas: un arreglo multidimensional de registros y una estructura de agrupamiento.
Biblioteca y API mejor implementadas y más flexibles, con un perfeccionado
soporte para E/S en paralelo, hilos, y otros requerimientos impuestos por otros
sistemas y aplicaciones modernas.
La biblioteca HDF5 está soportada sobre varias plataformas como: AIX,Cray J90, T3E,
FreeBSD, HP-UX, IRIX, Linux, OSF1, Solaris, ASCI TFLOPS, Windows NT 4.0, Windows 98.
Los archivos HDF5 están organizados en estructuras jerárquicas, con dos objetos primarios:
grupos y conjuntos de datos (datasets), y dos objetos secundarios: datatypes y dataspace.
16
Un grupo es una estructura que contiene cero o más objetos HDF5, los cuales, a su vez, se
denominan miembros de ese grupo. Un dataset es un arreglo multidimensional de elementos de
datos, unido al soporte de metadatos.
El trabajo con grupos y miembros de grupos es similar en muchas maneras al trabajo con
directorios y archivos en UNIX. Como los objetos directorios y archivos en UNIX, los objetos en
un archivo HDF5 son también descritos por la entrega de sus caminos enteros o absolutos. Por
ejemplo: / es el grupo root o raíz; el camino /foo/bar significa un miembro llamado bar pertenece
al grupo foo que a su vez pertenece al grupo raíz (Figura 2. Ejemplo de grupos y miembros de
grupos.).
Un grupo cuenta con dos partes:
1) Un encabezado, que contiene un nombre de grupo y una lista de sus respectivos
atributos.
2) Una tabla de símbolos del grupo, que es una lista de objetos HDF5 que pertenecen al
grupo.
Un dataset (Figura 3. Composición de un dataset.) es almacenado en un archivo en dos
partes: un encabezado y un arreglo de datos.
Figura 2. Ejemplo de grupos y miembros de grupos.
17
Figura 3. Composición de un dataset.
Los encabezados contienen información que es necesitada para interpretar la porción del
arreglo del dataset, conocido como metadatos (o punteros a metadatos), que describe o registra el
dataset. La información del encabezado incluye el nombre del objeto, su dimensionalidad, su tipo
de número, información sobre como el dato por sí mismo es almacenado en disco y otras
informaciones usadas por la biblioteca para acelerar el acceso al dataset o mantener la integridad
de los archivos.
Existen cuatro clases esenciales de información en cualquier encabezado: name, datatype,
dataspace y storage layout.
El name es una secuencia de caracteres alfanuméricos ASCII.
Datatype define los tipos de datos del dataset y especifica, dado un elemento, el conjunto de
posibles valores que puede tener y como los valores de ese tipo son almacenados. Existen varias
categorías de datatypes; entre ellas se destacan los atómicos, los nativos, los compuestos y los
named (Figura 4. Categorías de un datatype.).
El atómico es aquel que no puede ser descompuesto. Esta clase incluye a los integer, float,
date, time, string, pointers, bit field, etc. Cada tipo atómico pertenece a una clase particular y posee
algunas propiedades como tamaño, orden, precisión y offset.
Aunque es posible describir prácticamente cualquier clase de datatype atómico, la mayoría de
las aplicaciones usan datatypes predefinidos que son soportados por sus compiladores. En HDF5
estos son llamados NATIVES. Estos datatypes son parecidos a los de C que generalmente
soportados por el hardware de la máquina donde la biblioteca fue compilada. En orden de
portabilidad, las aplicaciones al menos deberían usar la designación NATIVE para describir los
valores de los datos en memoria.
18
El compuesto está conformado por colecciones de datatypes dentro de una sola unidad; similar
a los structs en C. Las partes de un datatype compuesto son llamadas miembros; estos pueden ser
de cualquier tipo, incluyendo a otro datatype compuesto. Dentro de ellos están los named datatypes
que pueden ser lo mismo atómicos que compuestos y son específicamente diseñados para ser
compartidos en datasets cruzados.
Normalmente cada dataset tiene su propio datatype, pero a veces queremos compartir un
datatype entre varios datasets. Esto puede hacerse usando el datatype named. Un named datatype
es almacenado en el archivo independientemente de cualquier dataset, y referenciado por todos los
datasets que tengan ese datatype. Pueden tener una lista de atributos asociados.
Figura 4. Categorías de un datatype.
El dataspace describe la dimensionalidad del dataset. Las dimensiones de un dataset pueden ser
fijas (invariables) o pueden ser ilimitadas (extendibles), las cuales pueden irse expandiendo a
medida que vayan almacenándose nuevas informaciones. Consiste en un rango (número de
dimensiones) del arreglo de datos, el tamaño actual de las dimensiones del arreglo, y el tamaño
máximo de las dimensiones del arreglo (Figura 5. Estructura de un dataspace.). Para un
19
dataset de dimensión fija, el tamaño actual es el mismo del tamaño máximo de la dimensión.
Cuando una dimensión es ilimitada, el tamaño máximo es puesto con el valor H5P_UNLIMITED.
Figura 5. Estructura de un dataspace.
El formato HDF5 posibilita almacenar los datos en variadas formas. El almacenamiento por
defecto es de formato contiguous (Figura 6. Almacenamiento contiguous.), el cual significa
que los datos son guardados del mismo modo lineal en que son organizados en memoria. Las otras
dos formas de almacenamiento son compact y chunked. El almacenamiento compact (Figura 7.
Almacenamiento compact.) es usado cuando el total de datos es pequeño y puede ser almacenado
directamente en el encabezado. El almacenamiento chunked (Figura 8. Almacenamiento
chunked.) actúa dividiendo el dataset en porciones de igual tamaño que luego son guardadas
separadamente.
Figura 6. Almacenamiento contiguous.
Figura 7. Almacenamiento compact.
Figura 8. Almacenamiento chunked.
20
En el futuro, otros formatos de almacenamiento serán añadidos a HDF5.
Los atributos son pequeños named datasets que son adjuntados a los datasets primarios, grupos,
o named datatypes. Los atributos pueden ser usados para describir la naturaleza y/o el uso
entendible de un dataset o grupo. Un atributo cuenta de dos partes:
Nombre: es una cadena de caracteres ASCII terminadas en null. Cada atributo
adjuntado a un objeto tiene un nombre único.
Valor: contiene uno o más elementos de datos del mismo datatype.
La sección del valor contiene uno o más datos de entrada del mismo datatype. Los atributos
HDF5 tienen todas las características de los datasets HDF5 excepto que su capacidad E/S no es
parcial; los atributos pueden ser de escritura y de solo lectura en su completitud, sin ninguna
conjunción.
La API Atributo (H5A) es usada para la lectura o escritura de información del atributo. Cuando
se accede a ellos, los atributos pueden ser identificados por nombre o por un valor índice. El uso de
un valor índice hace posible iterar a través de todos los atributos asociados con el objeto dado.
El formato HDF5 y la biblioteca E/S fueron diseñados con la suposición que los atributos son
pequeños datasets. Ellos siempre son almacenados en la parte cabecera del objeto al que están
adjuntados. A causa de esto, grandes datasets no tendrían que ser almacenados como atributos.
Cuan extenso puede ser no está definido por la biblioteca y está preparado para la interpretación
del usuario. Grandes datasets con metadatos pueden ser guardados como datasets suplementarios
en un grupo con el dataset primario (HDF, 2005).
1.1.2 - Sistemas Gestores de Bases de Datos aplicados.
Recientemente, muchas compañías han empezado a usar SGBD en aplicaciones no
tradicionales, por la gran demanda de imágenes y objetos de multimedia. En consecuencia, los
objetos y las operaciones relacionadas, se han hecho más complejos. Algunos ejemplos de datos
complejos son: imágenes, sistemas de información gráfica, objetos de multimedia, 3-D y datos
temporales.
21
El criterio convencional en el pasado ha sido que los SGBD resultaban demasiado lentos para
manipular datos de gran complejidad. La valoración más aceptada era que todavía los SGBD no
resultaban adecuados para grandes cantidades de datos multidimensionales.
Algunos acontecimientos ocurridos durante los últimos años han venido a opacar la claridad
que existía en estas aceptadas creencias. Entre estos tenemos:
Algunas investigaciones científicas a gran escala, como el Earth Observing System
Data and Information System (EOSDIS), física de gran energía y el estudio del genoma
humano, han adoptado SGBD como el centro de su Sistema de Control de Datos.
Varios de los principales fabricantes de aplicaciones para la administración de Sistemas
de Bases de Datos, han introducido novedosos productos, como los SGBD Objeto-
Relacional (SGBD-OR), con herramientas capaces de soportar gran cantidad de
arreglos de datos multidimensionales.
Los SGBD se diseñan para realizar búsquedas rápidas, balanceando y manipulando gran
cantidad de trabajo en enormes volúmenes de datos y realizan un mejor trabajo que el que un
científico promedio pudiera codificar. Permiten acceder simultáneamente a datos desde diferentes
aplicaciones, creando un buen ambiente compartido (Nieto-Santisteban, 2005).
De ahí la importancia de que los científicos que trabajan en disciplinas donde se utilizan gran
cantidad de datos como la astronomía, biología, etc., reconozcan que los SGBD son herramientas
poderosas para analizar grandes volúmenes de datos y que son capaces de permitirle compartir sus
resultados con otros de forma natural.
1.1.2.1 - Sistemas de Base de Datos Relacionales (SGBDR).
En la actualidad, los Sistemas Gestores de Bases de Datos (SGBD-R) son utilizados para el
almacenamiento de grandes cantidades de información. Por las ventajas que estos brindan
(seguridad, acceso concurrente, rapidez de recuperación de datos, indexado de los datos, etc.) se ha
extendido su uso a casi cualquier aplicación que necesite almacenar datos.
No obstante, los SGBD-R existentes no son apropiados para el almacenamiento y
procesamiento de tipos de datos orientados a arreglos como los que soportan las diferentes
interfaces de trabajo con datos científicos (ejemplo, NetCDF, CDF, HDF).
22
Los sistemas de bases de datos basados en el modelo relacional, no soportan objetos
multidimensionales (arreglos) como una unidad básica de acceso a datos y el hecho de representar
arreglos como relaciones hace complicados algunos tipos útiles de accesos a datos. Además de
esto, proveen poco soporte para las abstracciones de datos multidimensionales y las herramientas
que poseen para el trabajo con sistemas de coordenadas no son lo suficientemente potentes, por lo
que se necesita un modelo de datos bastante diferente que pueda facilitar la recuperación,
modificación, manipulación matemática y visualización de datos orientados a arreglos.
Relacionado a esto hay un segundo problema con los sistemas de bases de datos de propósito
general: su pobre desempeño en arreglos grandes. Las colecciones de imágenes de satélites, salidas
(información) pertenecientes a modelos científicos y observaciones a largo plazo del tiempo
global, se encuentran más allá de las capacidades que poseen la mayoría de los sistemas de bases
de datos de organizar e indexar la información para lograr una recuperación eficiente.
Los SGBD-R proveen muchas facilidades que no son necesarias para el análisis,
administración y muestra de datos orientados a arreglos agregando un costo significativo en
términos de recursos y rendimiento en el acceso. Por ejemplo, las funciones de actualización,
auditorías, formato de reportes y los mecanismos designados para el procesamiento de
transacciones son innecesarios para la mayoría de las aplicaciones científicas.
Cualquier fichero de larga escala basado en un Sistema Gestor de Bases de Datos Relacionales
(SGBD-R) es costoso, requiriendo sistemas de computadoras de alta potencia y buenas conexiones
de red. Los archivos creados con SGBD-R no son portables (intercambiables) directamente, a
menos que se utilicen en ambas partes los mismos tipos de engines de SGBD-R, o sea usado un
formato basado en texto llano. En general, los SGBD-R crean un archivo de gran tamaño debido a
la cantidad de sobrecarga que le añaden (Elsmari, 2002).
1.1.2.2 - Sistemas de Bases de Datos Orientadas a Objeto (SGBD-OO).
Los sistemas de gestión de bases de datos orientadas a objetos surgen debido a la falta de
capacidad semántica del modelo relacional para el acceso uniforme a sistemas de múltiples bases
de datos y atender aplicaciones complejas como las bases de datos científicas, de imágenes,
multimedia, gráficas, etc.
23
Este tipo de aplicaciones necesita trabajar con datos de forma diferente a lo que conocemos
porque necesitan:
Estructuras más complejas para los objetos.
Transacciones de mayor duración.
Nuevos tipos de datos para almacenar imágenes o grandes bloques de texto.
Necesidad de definir operaciones no estándar, especificas para cada aplicación.
Controlar versiones y configuraciones.
Las bases de datos orientadas a objeto usan un modelo que soporta tipos de datos abstractos, e
incluyen además características como el encapsulamiento, la herencia y el polimorfismo. El
encapsulamiento se consigue mediante la ocultación de información, es decir, se basa en ocultar
todos los secretos de un objeto que no contribuyen a sus características esenciales. La herencia es
el proceso mediante el cual las propiedades y los métodos de un objeto pueden ser reusados para
definir las propiedades de un objeto nuevo. El polimorfismo implica que el operador o símbolo
puede ser usado por implementaciones diferentes.
La bases de datos orientadas a objeto proveen identificadores llamados: Unique Object
Identifiers (OID), para que los objetos puedan ser identificados con facilidad. Los datos en un
SBGD-OO son manipulados a través de dos grupos de relaciones: uno que describe las relaciones
entre clases de datos y otro que describe las relaciones abstractas (inherencia). La conexión fuerte
entre la aplicación y la base de datos hace que usen menos código y su estructura es más natural.
Los lenguajes OO, como C++ o java reducen el tamaño del código y son más prácticos porque no
tienen que traducir el código en un sub-lenguaje como SQL, ODBC o JDBC (E. Nahouraii y F.
Petry, 1991; B. R. Rao, 1994).
Hasta ahora, la falta de un patrón o estándar era un problema para los SGBD-OO. El grupo,
Object Data Management Group (ODMG) ha propuesto un estándar conocido como ODMG-93 o
ODMG 1.0 (Cattell, 1995). El estándar consiste en un modelo objetivo: el lenguaje para definir los
objetos (ODL), el lenguaje de consultas (OQL) y los enlaces a los lenguajes de programación.
Los SGBD-OO han sido integrados con C, C++, Java y LISP. La interfaz primaria es de los
SGBD-OO; para crear y modificar los objetos se usa directamente el lenguaje orientado a objeto
(C++, Java, etc).
La mayor diferencia entre las bases de datos relacionales y las bases de datos orientadas a
objeto está en la forma en que manejan las relaciones. Una simple metáfora ayuda a ilustrar la
24
diferencia entre ambos modelos. Consideremos el problema de almacenar un coche en un garaje al
final del día. En un sistema de objetos el coche es un objeto, el garaje es un objeto, y hay una
operación simple que es almacenar-coche-en-garaje. En un sistema relacional, todos los datos
deben ser traducidos a tablas, de esta forma el coche debe ser desarmado, y todos los pistones
almacenados en una tabla, todas las ruedas en otra, etc (Figura 9. Almacenamiento en un SGBD-R
y en un SGBD-OO.). Por la mañana, antes de irse a trabajar hay que componer de nuevo el coche
para poder conducir (problema: al componer piezas puede salir una moto en vez de un coche).
Las mayores ventajas de los SGBD-OO son su flexibilidad y soporte para el manejo de tipos de
datos complejos y la manipulación de estos de forma ágil y rápida, su intento de satisfacer
necesidades de aplicaciones mas complejas y tener como característica clave el poder que dan al
diseñador de la base de datos tanto para especificar la estructura de los objetos complejos como las
operaciones que se pueden aplicar a estos objetos.
Los mayores problemas que se han presentado con los SGBD-OO ha sido el poco apoyo de los
proveedores dentro del mercado, su pobre desempeño para la optimización de consultas complejas
y su dificultad para soportar sistemas en gran escala.
Algunos ejemplos de SGBD-OO son: O2 creado por Ardent Software y Object Store System
creado por Object Design Inc. (Elmasri, R., 2000; Rao, B. R., 1994).
1.1.2.3 - Sistemas de Bases de Datos Objeto Relacionales (SGBD-OR).
Figura 9. Almacenamiento en un SGBD-R y en un SGBD-OO.
25
Los SGBD-OR usan un modelo de datos que trata de combinar las características orientadas a
objeto con el modelo relacional. Toda la información de la base de datos esta guardada en tablas,
pero algunas notaciones tabulares pueden tener una estructura de datos abstractos (ADT).
Los SGBD-OR soportan una forma de SQL llamada SQL3. Las extensiones son necesarias
porque los SGBD-OR deben de soportar ADT.
Los SGBD-OR tienen un modelo relacional porque los datos están guardados en forma de
tablas con renglones y columnas. SQL es usado por el lenguaje de búsqueda de información.
Las características de los SGBD-OR son:
1) Extensión, de base de datos.
2) Soporte de objetos complejos.
3) Herencia.
4) Sistema de reglas (Stonebraker y P. Brow, 1999).
La aparición de los SGBD-OR ha permitido la inclusión de los conjuntos de datos científicos
en los SGBD.
Estos resultan ventajosos por varias cuestiones:
1. Poseen la capacidad de guardar grandes cantidades de información y acceso de alta
velocidad.
2. Ofrecen un enorme potencial en cuanto a sus posibilidades de rapidez.
3. Han estado en fase de desarrollo constante durante la última década y todo indica que
posee promisorias potencialidades de crecimiento en las áreas científicas.
4. Permiten que los usuarios puedan definir los tipos de datos, funciones y operadores,
teniendo mayor funcionabilidad y mejor desempeño.
5. Las inversiones hechas por las organizaciones a lo largo de los últimos años han
familiarizado a los programadores con las herramientas de programación, ajustando el
SQL o mecanismos de acceso relacionado, con que cuenta el SQL, en la adopción de
extensiones propuestas o nuevas funcionalidades de base de datos.
6. Los proveedores de SGBD-OR tienen presencia mayoritaria, y están más fortalecidos,
en la estructura del mercado, en comparación con los proveedores de SGBD-OO, que
ocupan menor cuantía. Esto presupone, que en los próximos anos las expectativas de
crecimiento de los mercados, para los proveedores de SGBD-OR, será también mayor
que los de los SGBD-OO.
26
7. Los SGBD-OR permiten que los usuarios puedan definir tipos de datos, funciones y
operadores. Realizan una gran cantidad de funcionalidades que se ejecutan de forma
automática, como la optimización de consultas y el mantenimiento de índices, que no
requieren de ninguna acción por parte del usuario.
Por esto, los SGBD-OR permiten crear aplicaciones de acceso a datos científicos eficientes,
que en la mayoría de los casos sobrepasan en este sentido a aplicaciones hechas a la medida.
Por otra parte aún subsisten algunas desventajas:
1. Todavía esta propuesta de integrar datos orientados a objetos en una interfaz de
consultas relacionales no ha pasado la prueba de fuego en gran escala. Esto significa
que cualquier aplicación que dependa de un estilo de interfaz dado estará en gran parte
maniatada a un solo proveedor.
2. Su desarrollo esta limitado en la medida en que los usuarios asimilen la nueva
tecnología con suficiente profundidad.
3. La funcionalidad de la interfaz aún resulta transitoria, frágil, limitada y a veces
completamente desconcertante.
4. Resulta complejo establecer el modelado de la relaciones entre los datos almacenados
en el sistema.
5. La arquitectura del modelo objeto relacional no es la mejor para aplicaciones Web de
alta velocidad (Ortega Camacho, 2008).
Aunque estos gestores todavía están en proceso de desarrollo, tienen expectativas de buen
futuro. Centros como el Barrodale Computing Services (BCS) y proyectos como el TRIM
Watershed Atlas (TWA), Integrated Digital Electoral Atlas (INDEA), el Commercial Shipping
Information System, el Weather Modeling and Prediction y Life Sciences se han especializado en
la tecnología de los SGBD-OR para solucionar los problemas en campos tan diversos como la
geofísica, la genética, oceanografía, meteorología, etc (Computing System, 2008)
1.2 - Gestión de los DC.
Mediante estaciones de medición de alta precisión, imágenes de satélite o supercomputadoras
se generan a diario volúmenes de datos tan grandes y complejos, que no pueden ser analizados
suficientemente bien en forma numérica. En general se asume que de todos los datos generados
27
solo una cuarta parte se almacena, y de éstos a su vez solo una cuarta parte realmente se analiza.
Evidentemente se pierden datos valiosos y de muchas informaciones importantes solamente se
utiliza un pequeño porciento (Pérez Risquet, 2005).
Campos tan diversos como la bioinformática, geofísica, astronomía, medicina, meteorología y
física de partículas son los que más se enfrentan a esta clase de situaciones.
1.2.1 - Análisis estadístico.
Para examinar estos datos de forma efectiva, son necesarios métodos de análisis que extraigan
de ellos información y conocimientos a través de consultas que permiten calcular valores
estadísticos de los datos como la suma, promedio, máximo, mínimo, moda, desviación estándar,
varianza, coeficiente de variación, frecuencia, entre otros.
El análisis exploratorio y el confirmatorio incluyen el análisis estadístico de los datos. En el
análisis exploratorio se tiene un conjunto de datos sin una hipótesis específica. Estos datos se
someten a un proceso de búsqueda interactiva de información que va a arrojar como resultado una
visualización que soporte una hipótesis sobre el conjunto de datos. En el análisis confirmativo se
tiene un conjunto de datos sobre los que se plantea una hipótesis. Se realiza un procesamiento de
dichos datos que genera una visualización mediante la cual se pueda validar o refutar la hipótesis
que se tenía de ellos.
Después que se conocen los hechos específicos sobre los datos, se realiza una presentación del
resultado a través de una visualización que enfatice en la veracidad de dichos hechos.
1.2.2 - Visualización de Datos Científicos.
La visualización científica es la transformación de datos científicos y abstractos en imágenes.
Es una forma especial de la visualización que procura encontrar una representación visual
apropiada para un conjunto de datos que permita mayor efectividad en el análisis y evaluación de
los mismos. Simplifica el análisis, comprensión y la comunicación de modelos, conceptos y datos
en la ciencia y la ingeniería.
28
La Visualización Científica es altamente valorada, en muchos experimentos y simulaciones,
que demandan el procesamiento y análisis de numerosos datos, del orden de algunos cientos de
Gigabytes a Terabytes, y que poseen diversas características, pues recogen información de disímiles
esfera de la ciencia y la técnica.
La manipulación, el almacenamiento, el acceso eficiente y el análisis de esos datos representan
una tarea que constituye un gran reto, pero al mismo tiempo ofrece ventajas incuestionables, ya
que nos lleva de la mano en la representación gráfica de objetos y nos permite seguir su evolución
para lograr la exploración interactiva de los mismos, algo que hubiera sido imposible con la simple
observación de una sola imagen.
La visualización científica posibilita reconocer patrones de comportamiento de los datos, ver
en una sola imagen o en una secuencia de estas (animación) una gran cantidad de datos y facilita la
comprensión de algunos conceptos, sobre todo de tipo abstracto. Por ejemplo, si se diera el caso de
que tuviéramos una serie de datos de las concentraciones del dióxido de carbón atmosférico,
tomadas en el transcurso de varios años en Mauna Loa (Anexo III. Tabla del comportamiento de
concentraciones CO2.). Al mostrarlos en forma de tabla, sería muy difícil distinguir a simple vista
alguna relación entre los mismos, pero al conformar una gráfica de los valores veríamos si siguen
cierto patrón de comportamiento (Figura 10. Gráfico de concentración de CO2.). Si un observador
perspicaz pudiera deducir de la tabla el incremento promedio anual de las concentraciones de CO2
que aparecen en la línea azul oscura, sería muy difícil, hasta para el más preparado científico, notar
el ciclo anual del CO2 atmosférico que la línea azul clara muestra fácilmente.
Figura 10. Gráfico de concentración de CO2.
29
De ahí la importancia de la visualización científica, más aún, si añadimos que se trata de una
solución alternativa eficaz a los problemas que difícilmente pueden ser abordados desde la óptica
de las técnicas tradicionales conocidas; por ello, en los últimos tiempos, se ha perfilado como un
área de investigación bien definida. El objetivo de cualquier proceso de visualización es la
generación de imágenes a partir de datos abstractos, que por lo general son de naturaleza no
geométrica. La descripción y modelación de los datos es por tanto un punto de partida para la
realización de un proceso de visualización expresivo, efectivo y adecuado.
Entre las ventajas de la visualización científica está el poder representar datos de varias
dimensiones o variables, lográndose visualizar cuatro o más variables al mismo tiempo
apoyándose en algunos métodos. Por ejemplo, el plano cartesiano puede mostrar dos variables, si
agregamos otro, podremos ver 3, si agregamos colores, tendremos 4, si se hace alguna animación
de la gráfica podremos apreciar una quinta variable o dimensión. Otra gran ventaja es la
independencia del lenguaje, ya que la idea principal del problema está representada de forma
gráfica (Puente Verdin, 2006).
Posibilita a las personas la interacción directa con los datos. La visualización puede ser hecha
sin mayor dificultad en datos no homogéneos o que no se conozca detalladamente su estructura. La
exploración visual es intuitiva, no requiere de complicados conocimientos matemáticos,
estadísticos o de otra índole. Otra gran ventaja consiste de la visualización de datos es la gran
cantidad de conocimiento que puede ser rápidamente interpretado.
Presentar los datos desde donde se sacan conclusiones, le da a los científicos la oportunidad de
analizar ellos mismos los datos, un proceso que tiene el propósito de mantener los experimentos y
análisis científicos al nivel más objetivo posible. A pesar que las tablas son necesarias para anotar
datos, los gráficos le permiten al lector visualizar complejas series de datos de una manera simple
y concisa. Un enorme volumen de información puede plasmarse en una sola imagen. Exitosamente
ella puede reducir el tiempo que toma entender los datos implícitos, encontrar sus relaciones, y
conseguir la información buscada (Sahling, 2002).
El problema principal del proceso de visualización científica consiste en encontrar la técnica de
visualización que logre los resultados más apropiados. Las técnicas de visualización son una de las
partes fundamentales del proceso de visualización y dependen en gran medida del tipo de dato a
30
visualizar (escalar, vector, tensor) y de la dimensión del dominio en que se van a representar los
datos (una, dos, tres dimensiones o multidimensional).
Los algoritmos de transformación de los datos se pueden clasificar según la estructura y el tipo
de transformación. Estructura se refiere a los efectos que puede tener la transformación sobre la
topología, geometría y atributos de los datos, y el tipo se refiere al tipo de datos con que se va a
operar.
Las transformaciones estructurales pueden ser clasificadas en cuatro conjuntos, en dependencia
de cómo estas afectan a la geometría, la topología, y los atributos del conjunto de datos:
Transformaciones Geométricas.
Son aquellas que cambian la geometría de la entrada, pero no cambian la topología del
conjunto de entrada. Por ejemplo si realizamos una traslación, una rotación, y/o un escalado en los
puntos de un conjunto de datos poligonal, la topología no cambia, pero las coordenadas de los
puntos sí.
Transformaciones Topológicas.
Son aquellas que alteran la topología de la entrada, pero no cambian la geometría y los
atributos de los datos. Convirtiendo el tipo de un conjunto de datos poligonal a una malla no
estructurada, o de una imagen a una malla no estructurada, se cambia la topología pero no la
geometría.
Transformaciones de Atributos.
Son aquellas que convierten de los atributos de los datos de una forma a otra, o crean nuevos
atributos del conjunto de entrada manteniendo la estructura del conjunto de datos sin afectarse.
Transformaciones Combinadas.
Son aquellas que cambian la estructura del conjunto de entrada y los atributos de los datos.
Una forma muy usada de clasificar los algoritmos es de acuerdo al tipo de datos que usan. El
significado de la palabra "tipo" en este caso se refiere a la clase de datos perteneciente a los
atributos, tales como vectores y/o escalares. Estas categorías incluyen los siguientes algoritmos:
Algoritmos Escalares: Operan en datos escalares. Un ejemplo es la generación de líneas
de contorno de temperatura en un mapa del estado del tiempo.
31
Algoritmos Vectoriales: Operan en datos vectoriales. Un ejemplo es mostrado por las
flechas orientadas de corrientes de aire en un mapa del estado del tiempo (dirección y
magnitud).
Algoritmos Tensoriales: Operan en matrices tensoriales. Un ejemplo es al mostrar los
componentes de tensión o presión en un material usando iconos orientados.
Algoritmos de Modelado: Generan la topología, la geometría de un conjunto de datos,
normales de la superficie o datos de la textura. Esta última tiende a ser la categoría para
todos los algoritmos que no están en una sola de las categorías que se trataron arriba.
1.2.2.1 - Requerimientos.
La importancia de determinar correctamente los requerimientos de un sistema al comienzo del
proceso de desarrollo es un hecho bien conocido. La experiencia muestra que la definición
incorrecta de los requerimientos conduce al desarrollo de sistemas deficientes, incrementa su costo
de desarrollo o incluso causa que el proyecto falle. Por lo tanto, los requerimientos deben ser
necesarios y suficientes y deben ser descritos de forma tal que dejen el menor margen de mala
interpretación posible. Además, es crucial para los clientes que verifiquen que el sistema planeado
satisface sus necesidades. Esto significa que el sistema debe ser descrito de forma que los clientes
puedan entenderlo con claridad.
El desafío es que un cliente en principio no especialista en informática, debe ser capaz de
entender los resultados del proceso de revelamiento de requerimientos. Para lograr este objetivo,
debe utilizarse "el lenguaje del cliente" para describir los resultados. En este contexto las técnicas
de visualización parecen ser una herramienta útil para describir los requerimientos del sistema. El
uso de técnicas de visualización permite mostrar los requerimientos de un sistema utilizando
representaciones gráficas que ayudan a los usuarios en el proceso de comprensión y validación.
Mientras más características de los datos se consideren en su especificación, más información
estará disponible para una rápida evaluación y para la visualización. Estas técnicas van desde un
simple diagrama para indicar los resultados de una elección a través de imágenes tridimensionales
para visualizar un tumor en el cuerpo hasta animaciones tridimensionales para visualizar la
corriente del aire sobre un coche.
32
Un enfoque es el que considera que los datos del mundo real, teórico y artificial están
localizados en puntos en un espacio n-dimensional llamado el espacio de observación. Aquí debe
distinguirse entre las dimensiones que definen el espacio de observación y los parámetros
(atributos) que son observados/medidos en el espacio de observación. Debe distinguirse, además,
entre las variables dependientes e independientes.
Para la caracterización de los puntos de observación (ejemplo, puntos en el espacio de
observación donde los datos están disponibles) necesitamos conocer lo siguiente:
Dimensionalidad del espacio de observación (variables independientes).
Área de impacto en el espacio: especifica la región en que tienen validez los valores
tomados en un punto. Dichas regiones se clasifican en tres grupos:
1. Impacto puntual: Los datos tienen validez solo en el punto de observación
correspondiente (ejemplo, valores de datos en un punto de una laguna).
2. Impacto local: Los datos tienen validez en una cierta vecindad del punto de
observación correspondiente (ejemplo, datos en la parte norte de la laguna).
3. Impacto global: Los datos tienen validez en todo el espacio de observación
(ejemplo, toda el área que abarca la laguna).
Conectividad de los datos: los puntos de observación pueden estar organizados de
acuerdo a diferentes criterios.
A continuación se describen con mayor detalle las principales características de algunas
técnicas de visualización más ampliamente difundidas, agrupadas de acuerdo a su área de impacto
en el espacio.
Métodos puntuales.
Esquema de flechas: consiste en representar vectores velocidad mediante flechas. Este
método está bien establecido para representaciones en 2D y 3D.
Líneas de fluído (stream lines): consiste en dibujar un conjunto de líneas que son
paralelas al campo vectorial en cada punto.
Líneas de trayectoria (path lines): describe el movimiento en el tiempo de las partículas
de campo de fluído no estacionario.
Líneas de bandas (streak lines): es la localización de todas las partículas dispuestas en
un punto fijo, en momentos diferentes.
33
Movimiento de partículas.
Líneas de tiempo (time lines): se basa en la visualización de todas las partículas que
estuvieron dispuestas sobre una línea recta en un momento fijo.
Superficies de corriente y objetos de corriente (stream surfaces and stream objects):
consiste en hacer combinaciones de diferentes fuentes de partículas lo cual conduce a
diferentes vistas del flujo.
Métodos locales.
Cintas de flujo (flow ribbons): consiste en representar la trayectoria e información
adicional de una partícula mediante una cinta.
Sonda: para visualización de flujo local. El punto de partida es la matriz de Jacobi de la
cual son extraídas y visualizadas las propiedades adicionales.
Métodos globales.
Métodos combinados: combinación de métodos permite obtener una imagen mejorada,
y por tanto se pueden determinar una mayor cantidad de características presentes en los
datos que estas representan. Por ejemplo, se puede combinar una imagen Integrar y
Dibujar con otra imagen de color, la cual codifica propiedades adicionales.
Coordenadas paralelas: puede visualizar una cantidad mucho mayor de variables y sus
relaciones, que con métodos tradicionales (2 ó 3 dimensiones). Cada uno de los ejes
verticales de un sistema de coordenadas paralelas puede tener su propia escala o
definirse todos con una sola escala, la primera forma nos permite la visualización de
hipersuperficies y el análisis del funcionamiento del conjunto de datos, con la segunda
podemos hacer un análisis de las relaciones entre las variables. Este método permite
encontrar patrones de comportamiento de las variables y correlaciones entre ellas. Es
una técnica común para representar datos de muchas dimensiones.
34
1.2.2.2 - Consultas.
Las consultas son requeridas por el usuario para visualizar los cambios continuos y las
combinaciones de fenómenos que ocurren dentro de la naturaleza de su área de investigación.
Una aplicación, por ejemplo en el campo de la Política, muestra las contribuciones políticas de
varios candidatos. El investigador selecciona un estado, una carrera política en ese lugar, y el
apoyo monetario de las contribuciones. La aplicación construye una imagen en 2D que mostrará
quién soporta cada candidato y a qué nivel (basado en los tamaños relativos de las figuras que
representan los contribuidores) se revela la influencia política (Figura 11. Área de contribuciones
políticas.).
Otro ejemplo pero esta vez en el campo del proyecto hidrográfico del TRIM Watershed Atlas
(TWA) cuya base de datos está gestionada por un SGBD-OR (IBM Informix) y tiene almacenado
rangos descriptores de puntos, líneas, áreas, jerarquías de polígonos y otros muchos tipos de datos,
sería hacer una consulta como “encontrar el área de línea divisoria de agua entre la intersección de
un terreno con el río”. La consulta en SQL quedaría así:
SELECT Area(Watershed(streamElement,
(Intersection(streamElement, roadElement))))
FROM streamNetwork, roadNetwork
WHERE Overlap(Intersection(Box(streamElement),
Box(roadElement)), userDefinedArea);
Donde:
• userDefinedArea es un string que provee el usuario.
• Se usan 5 funciones definidas por el usuario, que son:
Figura 11. Área de contribuciones políticas.
35
o BOX – rectángulo que encuadra al objeto;
o INTERSECTION – área común;
o OVERLAP - T o F;
o WATERSHED – calcula la línea divisoria a partir de un punto;
o AREA – calcula el área.
La salida, a través de un software de visualización, quedaría mostrada de la siguiente manera:
Otras consultas comúnmente usadas en las diferentes esferas de investigación se muestran a
continuación:
Meteorología: todo tipo de comportamiento meteorológico, densidad de las tormentas,
zonas de altas presiones, movimiento de las áreas de precipitaciones, cambios en los
niveles de temperaturas, comportamiento de las corrientes marinas, etc.
Astronomía: zona estelar donde ocurren más frecuentemente supernovas, zonas de vacíos,
etc.
Biología: migraciones de animales, áreas de repoblación y extinción de vida animal, etc.
Forestal: crecimiento forestal, zonas de alto riesgo de incendios, comportamiento de la
hidrología en diferentes zonas, zonas de futura poda y tala, zonas de plantación, etc.
Medicina: desarrollo de cáncer en los pacientes, desarrollo supervisado en la embriología,
genética, etc.
Geofísica: zonas de mayor riesgo de terremotos y actividades volcánicas, zonas de alta
saturación hidrológica, etc.
Social: movimientos de criminales o espías, desplazamiento de personas en caso de
emergencias, etc.
Planeamiento Urbano: parcelas administradas, desarrollo de áreas urbanas, zonas de mayor
afluencia de turismo, rutas más frecuentadas, etc.
36
Militar: localizaciones de misiles, movimiento de tropas, etc.
Aviación/Marina: rutas principales, rutas alternativas, desvíos, etc.
1.2.2.3 - Softwares de Visualización.
Durante la última década se han establecido potentes sistemas en el campo de la visualización
científica. Algunos están enfocados a un campo de aplicación específico, como la medicina,
química molecular, meteorología, etc., y otros son de propósito general, con amplia utilización en
diversas ramas de la ciencia. Entre estos últimos se destacan notablemente: Iris Explorer, AVS,
Khoros, Amira y OpenDX. Estos sistemas son conocidos como ambientes modulares de
visualización, puesto que las aplicaciones se componen mediante la unión de diversos módulos en
una red, empleando un paradigma de programación visual. Entre estos últimos se destacan
notablemente:
1.2.2.3.1 - Iris Explorer.
Iris Explorer es un sistema versátil para la visualización de datos científicos y el procesamiento
de imágenes. Usa el paradigma de flujo de datos para convertir, mediante una serie de pasos de
cálculo, los datos brutos en las representaciones visuales.
Iris Explorer soporta la programación visual mediante la construcción interactiva de una red de
módulos interconectados entre sí, denominada mapa (Figura 12. El sistema de visualización Iris
Explorer.). Los datos fluyen a lo largo de este mapa sufriendo las transformaciones necesarias para
ser convertidos en imágenes. Cada módulo es controlado por un conjunto de parámetros, que
también pueden seleccionarse de manera interactiva.
37
Figura 12. El sistema de visualización Iris Explorer.
El proceso de examinar los datos es interactivo. El investigador observa la imagen, altera las
escenas, invoca otros métodos de visualización y combina los cuadros para conseguir una idea más
clara de qué está pasando en los datos (EXPLORER, 1998).
1.2.2.3.2 - Advanced Visual Systems (AVS).
AVS/Express es un ambiente visual orientado a objetos, que permite construir aplicaciones
reusables utilizando distintos elementos, con los cuales se pueden realizar aplicaciones muy
sofisticadas. Este sistema tiene cientos de componentes, que se utilizan para visualizar, analizar,
manipular y desplegar datos (Figura 13. El sistema de visualización AVS.).
Figura 13. El sistema de visualización AVS.
38
Algunas de las herramientas que posee son:
Visor de imágenes (Image Viewer): Herramienta de alto nivel para manipular y ver
imágenes.
Visor de grafos (Graph Viewer): Herramienta de alto nivel para graficar datos.
Visor de geometría (Geometry Viewer): Para componer escenas fuera de objetos
geométricamente definidos accesibles a AVS.También provee una interfaz para
manipular todos los demás tipos de objetos de AVS, como los conjuntos de datos de
volumen.
Editor de mapas: Interfaz de programación visual para conectar módulos
computacionales dentro de redes que realizan las funciones de la visualización (AVS,
1998).
1.2.2.3.3 - Khoros.
Khoros es un sistema de desarrollo de software para el tratamiento y visualización de
imágenes. Es un software abierto, pero no de dominio público. Esto quiere decir que se distribuye
de forma gratuita, y que se puede utilizar gratis igualmente, pero si se quiere desarrollar software
comercial a través de él, será necesario comprar una licencia. Esta característica hace de este
sistema una plataforma idónea para tratamiento científico en ambientes universitarios.
Khoros posee una herramienta de programación visual muy potente que hace uso de un
lenguaje gráfico orientado a flujo de datos (Figura 14. El sistema de visualización Khoros.). Los
módulos están agrupados en cajas de herramientas (toolbox en inglés), las cuales pueden instalarse
a manera de plug-in, y extenderse por los propios usuarios (KHOROS, 1998).
39
Figura 14. El sistema de visualización Khoros.
1.2.2.3.4 - Amira.
Amira es un sistema de visualización y modelado 3D. Permite visualizar conjuntos de datos
científicos de varias áreas de aplicación, como por ejemplo, medicina, biología, química, física, o
ingeniería.
Amira es un software modular orientado a objetos. Los componentes básicos del sistema son
módulos y objetos de datos (Figura 15. El sistema de visualización Amira.). Se usan los módulos
para visualizar los objetos de datos o para realizar algunas operaciones computacionales en ellos.
Las conexiones entre los módulos de Amira representan las dependencias entre los objetos de
datos y sus métodos (AMIRA, 1998).
.
40
Figura 15. El sistema de visualización Amira.
1.2.2.3.5 - OpenDX.
OpenDX es una aplicación y un paquete de desarrollo de software de código abierto para la
visualización de datos científicos, especialmente los adquiridos a partir de observaciones y
simulaciones. Es un sistema multiplataforma de visualización de propósito general, que permite
leer datos de distintas fuentes de una manera flexible y amigable. Aún cuando la organización de
los datos puede ser muy diferente para cada fuente, OpenDX ofrece una manera de leer casi
cualquier tipo de datos a través su herramienta conocida como Data Prompter.
OpenDX ofrece una interfaz gráfica que permite crear programas de manera visual, mediante
la interconexión de bloques o módulos, llamados redes (Figura 16. El sistema de visualización
OpenDX.). Por otro lado, OpenDX contiene un lenguaje script para crear programas de
visualización y genera objetos visuales multidimensionales a partir de datos numéricos
multiparamétricos (OPENDX, 1998).
41
Figura 16. El sistema de visualización OpenDX.
Conclusiones parciales
En este capítulo se han presentado las principales características de los formatos binarios de
almacenamiento de datos científicos más difundidos. Estos formatos han sido creados con el
objetivo de almacenar grandes volúmenes de datos científicos, permitiendo un uso eficiente de
ellos por parte de las aplicaciones que los utilizan. A pesar de esos beneficios, este enfoque
presenta el problema del almacenamiento y movimiento de un gran número de archivos
individuales, lo que dificulta su procesamiento.
Los SGDB-OR actuales ofrecen nuevas posibilidades para el trabajo con datos científicos, que
apenas comienzan a ser explotadas. Una característica importante en la actualidad es la extensión
de los Sistemas de Bases de Datos para unificar las Bases de Datos con los lenguajes de
programación, así como poder vincular nuevos tipos de objetos en los Sistemas de Gestión de
Datos y así lograr esta unión (Musick, 1998).
Los sistemas modulares de visualización de propósito general constituyen la principal
alternativa para integrar la Visualización Científica en los centros de ciencia. Ellos generalmente
usan este paradigma de manipulación de archivos, para lo cual brindan soporte para el acceso a los
datos en varios formatos binarios de almacenamiento de datos científicos.
42
Capítulo 2: Uso del SGBD-OR PostgreSQL para el trabajo con datos científicos.
Los SGDB-OR actuales ofrecen nuevas posibilidades para el trabajo con datos científicos, que
apenas comienzan a ser explotadas. Una característica importante en la actualidad es la extensión
de los Sistemas de Bases de Datos para unificar las Bases de Datos con los lenguajes de
programación, así como poder vincular nuevos tipos de objetos en los Sistemas de Gestión de
Datos y así lograr esta unión (Musick, 1998).
El PostgreSQL es un SGBD-OR de código abierto que posibilitó el desarrollo de soluciones
corporativas con una mejor relación “costo por beneficios”. Un punto fuerte de este SGBD es su
capacidad de tratar grandes volúmenes de datos con escalabilidad, o sea, su arquitectura puede ser
continuamente ampliada de acuerdo con la demanda de los usuarios.
Su extraordinario soporte que incluye desde reporte y recuperación de fallas, instrucciones
sobre como usar tal o cual característica y optimización de consultas convierten a PostgreSQL en
un DBMS de nivel empresarial, que puede ser usado en casi todo tipo de sistemas (desde los más
comunes sistemas de facturación hasta los más complejos sistemas científicos), conservando el alto
rendimiento sin sacrificar la estabilidad ni la integridad de los datos.
2.1- PostgreSQL.
PostgreSQL tiene más de 15 años de desarrollo activo y se ha ganado la reputación de ser
confiable. De hecho, hay compañías que aseguran haber tenido corriendo PostgreSQL en
producción durante varios años y con altas tasas de actividad sin haber experimentado problemas
de ningún tipo y mantener la integridad de los datos. Además corre en la mayoría de los Sistemas
Operativos más utilizados incluyendo, Linux, varias versiones de UNIX (AIX, BSD, HP-UX, SGI
IRIX, Mac OS X, Solaris, SunOS, Tru64), BeOS y Windows.
Por si eso fuera poco, cumple la prueba ACID (Atomicity, Consistency, Integrity, Durability) y
tiene soporte completo para llaves foráneas, joins, vistas, subconsultas (incluyendo subconsultas en
la cláusula FROM), triggers, y procedimientos almacenados (en varios lenguajes). Incluye la
mayoría de los tipos de datos de los estándares SQL92 y SQL99 (INTEGER, NUMERIC,
BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, TIMESTAMP, entre otros). También
43
soporta almacenamiento de objetos grandes (imágenes, sonido y video), así como sus propias
interfaces de programación para C/C++, Java, Perl, Python, Ruby, Tcl, ODBC, entre otros, y una
documentación muy completa.
2.1.1- Características del PostgreSQL.
PostgreSQL se ha preocupado por ser una solución real a los complejos problemas del mundo
empresarial y a la vez mantener la eficiencia al consultar los datos. Con ese fin, se han desarrollado
y añadido a PostgreSQL las más interesantes y útiles características que antes sólo podían hallarse
en sistemas manejadores de bases de datos comerciales con costos muy elevados; lo cual lo coloca,
como su lema indica, como "el manejador (o gestor) de bases de datos de código abierto más
avanzado del mundo".
Algunas de las características que posee PostgreSQL son:
Control de concurrencia multi-versión (MVCC), que sirve para lograr un control de
concurrencia tan eficiente que en la gran mayoría de los casos no se requiere de bloqueos).
Herencia de tablas (aunque la orientación a objetos no está completa esta característica
se la puede utilizar para lograr el particionamiento de tablas en varios discos mediante una
técnica llamada "restricciones excluyentes").
El sistema de reglas (el sistema re-escritor de consultas), permite identificar ciertas
acciones sobre una tabla y reemplazarlas por otras o ejecutar adicionales (podemos, por
ejemplo, crear una regla para que al hacer INSERT sobre una vista se reemplace por un
INSERT sobre la tabla en la que se basa la vista, dando así la impresión de vistas
actualizables).
Varios lenguajes procedurales como: Java, Perl, Python, Ruby, Tcl, C/C++, así como su
lenguaje nativo (PL/PGSQL) que es muy similar al PL/SQL de Oracle.
Su arquitectura extremadamente modular, facilitando el trabajo de los desarrolladores
que desean implementar nuevas funcionalidades.
Posee módulos contribuidos entre los que se cuentan OpenFTS, que es un método para
indexación de texto completo y PostGIS, que añade objetos geográficos lo cual permite a
PostgreSQL ser usado en proyectos de bases de datos para sistemas de información
44
geográfica, por ejemplo los que usan sistemas repartidores. También cuenta con módulos
de criptografía (SHA1, MD5).
Permite la creación de tipos de datos personalizados.
Escritura adelantada de registros (WAL) para evitar perdidas de datos en caso de falla
de energía, fallos del Sistema Operativo, y fallas de hardware.
Juegos de caracteres internacionales, codificación de caracteres multibyte y Unicode;
características para la integridad de los datos, tales como: claves primarias, llaves foráneas
con capacidad de actualizar en cascada o restringir la acción en caso que existan hijos,
restricción check, restricción de unicidad y restricción not null; todas las restricciones se
pueden postergar hasta el momento de terminar la transacción.
Interfaces de programación para Java (JDBC), ODBC, Perl, Python, Ruby, C, C++,
PHP, Lisp, Scheme, y Qt solo para nombrar algunas.
La implementación se sujeta fuertemente a los estándares ANSI-SQL 92/99 (y últimamente se
han añadido características del SQL2003). Este recurso permite una gran facilidad en la migración
de datos de otras bases que también sigan el ANSI SQL. Es altamente escalable; tanto en lo que se
refiere a cantidad de datos que puede manejar (se reportan ambientes de producción activos que
manejan incluso más de 4 Terabytes); así como, al número de usuarios concurrentes que puede
acomodar.
2.1.2 – Capacidad del PostgreSQL.
A continuación se muestran algunos valores límites de PostgreSQL:
Tamaño de una base de datos Ilimitada (limitada solo por el espacio en disco).
Tamaño de una tabla 32 Terabytes.
Tamaño de una fila 1.6 Terabytes.
Tamaño de un campo 1 Gigabyte.
Número de filas en una tabla Ilimitada (limitada solo por el espacio en disco).
Número de columnas en una tabla de 250 - 1600 dependiendo de los tipos de datos.
Número de índices en una tabla Ilimitada (Limitada sólo por el espacio en disco).
Por todo esto y más, PostgreSQL se ha ganado la admiración y el respeto de sus usuarios, así
como el reconocimiento de la industria (ganador del Linux New Media Award for Best Database
45
System y 3 veces ganador del The Linux Journal Editors' Choice Award for best DBMS).
2.1.3 - Uso del PostgreSQL.
En la página de PostgreSQL se pueden encontrar algunos casos de estudio de empresas que han
optado por PostgreSQL y se están recopilando más experiencias que se irán añadiendo a la página.
Además es un secreto a voces (los que dudan pueden usar google para confirmar) que los dominios
.ORG y .INFO corren bajo postgres, tambien la página TravelPost.com y Rambler.ru, así como
ciertas agencias gubernamentales de Estados Unidos tales como: City of Garden Grove, CA;
National Gallery; Media Library project of the Library of Congress; US Army; Dept of Forestry;
State of California; NCSA; National Weather Hidrology Laboratory; The Oxford University
Computing Services; Sandia Labs, sólo por mencionar algunos pero se pueden encontrar aún más
alrededor del mundo.
2.1.4 - Soporte para PostgreSQL.
PostgreSQL esta soportado por diferentes proveedores, entre los que se encuentran:
El soporte de la comunidad. El principal soporte de PostgreSQL lo provee la
comunidad a través de las listas de correo (lo esperamos en la lista en español) y los canales
de IRC (también tenemos nuestro canal en español).
El soporte comercial. También existen varias empresas que proveen soporte comercial
para PostgreSQL , entre las que tenemos: Fujitsu (Australia); Hub.org (Canadá);
PostgreSQL, Inc. (Canadá); credativ GmbH (Alemania); Afilias Limited (Irlanda);
Software Research Associates (Japón, con subsidiarias en USA); Delta-Soft LLC (Rusia);
2ndQuadrant (Reino Unido); 800 Pound Gorilla (USA); Command Prompt, Inc. (USA);
EnterpriseDB (USA); Greenplum (USA); Pervasive Software, Inc. (USA); RedHat, Inc.
(USA) y, hace unos días atrás, Sun Microsystems anunció que daría soporte a sus usuarios
de Solaris. Hace poco SRA comentó su deseo de ingresar al mercado latino-americano.
El soporte a nivel individual.
46
2.1.5 - Tipos de Datos.
PostgreSQL tiene un amplio surtido de tipos de datos nativos disponibles (Figura 17. Tipos de
Datos disponibles en PostgreSQL.). Los usuarios, pueden además añadir nuevos tipos de datos
usando el comando CREATE TYPE.
47
Figura 17. Tipos de Datos disponibles en PostgreSQL.
Internamente PostgreSQL usa identificadores de objetos (OID) como llaves primarias para
varias tablas del sistema. Los OID no se añaden a las tablas creadas por los usuarios, a menos que
se especifique la cláusula WITH OIDS cuando se crea la tabla, o que esté habilitada la variable de
entorno default_with_oids.
El tipo OID se implementa realmente como un entero de cuatro bytes sin signo, por tanto no es
suficientemente grande como para proporcionar una identificación única en bases de datos
grandes, o incluso en grandes tablas individuales, debido a esto se recomienda usar los OID solo
como referencias de las tablas de Sistemas.
El Sistema PostgreSQL contiene varias entradas de propósito especial llamadas colectivamente
pseudo-tipos. Un pseudo-tipo no puede usarse como un tipo de dato de una columna, pero puede
ser declarado como argumento o valor de retorno de una función. Cada uno de los pseudo-tipos es
útil en situaciones donde el comportamiento de una función no corresponde a simplemente tomar
o devolver un valor de un tipo de dato específico de SQL.
Las funciones escritas en C pueden declararse para aceptar o devolver cualquiera de estos
pseudo-tipos. Depende del programador asegurar que la función se comportará adecuadamente
cuando se usa un pseudo-tipo como argumento. En la actualidad la mayoría de los lenguajes
procedurales prohíben el uso de pseudo-tipos como argumentos o retorno.
48
El pseudo-tipo interno se usa para declarar funciones que sólo tienen significado al ser
llamadas internamente por el sistema de bases de datos, y no mediante invocación directa en una
consulta SQL, de ahí que si una función tiene al menos un argumento de tipo interno no pueda
llamarse desde SQL.
2.1.6 - Extensibilidad de PostgreSQL para el almacenamiento de datos científicos.
PostgreSQL se diseñó desde el inicio para ser extensible, por esta razón las extensiones
cargadas en su base de datos pueden funcionar de igual forma que las incluidas en su paquete
original. Existen una serie de características que han hecho que PostgreSQL pueda ser fácilmente
extensible para trabajar con datos científicos, algunas de estas son:
PostgreSQL tiene una amplia gama de tipos de datos nativos disponibles. Los usuarios
pueden añadir además nuevos tipos de datos.
PostgreSQL proporciona un número grande de funciones y operadores integrados con los
tipos de datos. Los usuarios pueden también definir sus propias funciones y operadores.
PostgreSQL tiene la posibilidad de manejar diferentes tipos de datos complejos, en
particular el empleo de arreglos multidimensionales es muy común.
En muchas ocasiones los datos científicos son de gran volumen y se necesita desarrollar
aplicaciones en red que permitan realizar consultas a un servidor centralizado de gran capacidad,
PostgreSQL facilita estas operaciones.
En PostgreSQL está presente la herencia, que es un concepto de las Bases de Datos
Orientadas a Objetos y que abre nuevas posibilidades de interés para al diseño de estas.
Existe una interfaz de programación escrita en C que interactúa con PostgreSQL (Libpq).
Está implementada como un conjunto de bibliotecas de funciones que permiten a los programas
clientes hacer consultas al motor de Bases de Datos de PostgreSQL y recibir los resultados de
estas consultas. Libpq permite además a PostgreSQL interactuar con aplicaciones escritas en otros
lenguajes como: C, Perl, Python, Tcl y ECPG.
En general el rendimiento de PostgreSQL es similar al de otros SGBD, sin embargo resulta
mucho más rápido para algunas operaciones como son: la realización de consultas complejas, la
carga del programa para lectura y escritura y el trabajo en ambientes multiusuario de gran tamaño.
49
2.1.7 – Medidas para mejorar el rendimiento en el acceso a los datos científicos almacenados en el PostgreSQL.
Para contrarrestar la sobrecarga impuesta por las funcionalidades del PostgreSQL, es bueno
tomar medidas para mejorar el rendimiento en el acceso a los datos científicos almacenados.
Algunas de estas optimizaciones se muestran a continuación:
Uso de herramientas de mantenimiento como VACUUM, ANALYZE, REINDEX.
Uso de las cláusulas LIMIT y OFFSET en las consultas siempre que sea posible.
Optimizador de Consultas Genéticas.
Rutinas de recobro de espacio en disco.
Prevención de fallos.
Planificador Optimizador.
Generación de posibles planes.
2.2- Modelado de los datos científicos.
En este trabajo es de interés analizar algunas de las características de los tipos de datos que
posee el PostgreSQL, en particular las facilidades para la definición de arreglos
multidimensionales, tipos compuestos, datos espaciales y tipos abstractos para el acomodo de
datos científicos.
Para los arreglos de una sola dimensión y multidimensionales puede emplearse una sintaxis
alternativa ajustada al SQL estándar. Ambos podrían definirse de la siguiente manera:
50
Esta sintaxis requiere una constante entera para representar el tamaño del arreglo, sin embargo
al igual que en el caso anterior PostgreSQL no restringe el tamaño del arreglo.
Además de los arreglos es posible definir tipos de datos compuestos. En esta sintaxis sólo se
pueden especificar los nombres de los campos y los tipos; hasta el presente no pueden incluirse
restricciones tales como NOT NULL. La palabra clave AS es esencial, pues sin ella el sistema
“pensaría” bastante diferente acerca del significado del comando CREATE TYPE y pudieran
obtenerse extraños errores de sintaxis.
Un dato espacial es una variable asociada a una localización del espacio. Normalmente se
utilizan datos vectoriales, los cuales pueden ser expresados mediante tres tipos de objetos
espaciales:
1. Puntos.
Se encuentran determinados por las coordenadas terrestres medidas por latitud y
longitud. Por ejemplo: ciudades, accidentes geográficos puntuales, hitos.
2. Líneas.
Objetos abiertos que cubren una distancia dada y comunican varios puntos o nodos,
aunque debido a la forma esférica de la tierra también se le consideran como arcos.
Líneas telefónicas, carreteras y vías de trenes son ejemplos de líneas geográficas.
3. Polígonos.
Figuras planas conectadas por distintas líneas u objetos cerrados que cubren un área
determinada, como por ejemplo países, regiones o lagos.
De esta forma la información sobre puntos, líneas y polígonos se almacena como una colección
de coordenadas (x, y). La ubicación de una característica puntual, pueden describirse con un sólo
punto (x, y). Las características lineales, pueden almacenarse como un conjunto de puntos de
coordenadas (x, y). Las características poligonales, pueden almacenarse como un circuito cerrado
de coordenadas.
Una vez definidos los tipos pueden usarse para crear tablas o funciones.
La abstracción es el mecanismo que permite seleccionar partes de un todo complejo para su
consideración, ignorando el resto. Esto permite filtrar aquellos aspectos relevantes, y obtener
soluciones más generales. El concepto de abstracción nos remite a la posibilidad de considerar la
resolución de un problema sin tener en cuenta los detalles por debajo de cierto nivel.
51
El concepto de Tipo de Dato Abstracto (TDA en castellano o ADT en inglés) surgió para
facilitar el trabajo con tipos de datos haciendo abstracción de la implementación de los mismos.
Un TDA está dado por un grupo de datos que cumplen cierta condición especificada para él, más
un conjunto de operaciones que representan su comportamiento.
En un SGBD-OR la variable dependiente puede almacenarse junto con sus dimensiones
utilizando una columna que contenga un arreglo multidimensional, implementado como un ADT.
Esto resulta una representación más natural, ya que la variable dependiente se almacena en la
misma fila que las variables independientes o dimensiones.
PostgreSQL es un SGBD-OR que permite la definición de tipos de datos abstractos y también
de las funciones que trabajarán sobre ellos. Tiene además un tipo predefinido de arreglo n-
dimensional dinámico que se puede utilizar para modelar datos científicos. Este tipo de dato tiene
algunas ventajas sobre tipos de datos similares de otros SGBD-OR (por ejemplo, Oracle) pues
permite insertar, actualizar y eliminar elementos individuales, así como definir índices sobre estos.
En la Figura 18. Modelado abstracto de datos. se muestra la forma en que fue modelada la
variable presión en PostgreSQL. Nótese que se creó un tipo abstracto de datos (PressureData) que
encapsula los valores numéricos de la presión, y una descripción de los mismos. De la misma
manera se pueden agregar otros atributos. Las otras variables fueron modeladas de forma similar.
Otra forma de almacenar los datos en un SGBD-OR, es utilizando el modelado
multidimensional del esquema Estrella.
El esquema estrella deriva su nombre del hecho que su diagrama forma una estrella, con puntos
radiales desde el centro. El centro de la estrella consiste de una tabla de hechos, que es aquella que
contiene toda la información, y un conjunto de tablas dimensiones organizadas alrededor de ésta,
conteniendo el catálogo de la información, formando las puntas de la estrella. Este modelo
Figura 18. Modelado abstracto de datos.
52
entonces, resulta ser asimétrico, pues hay una tabla dominante en el centro con varias conexiones a
las otras tablas. Las tablas de dimensiones tienen sólo una conexión a la tabla de hechos y ninguna
más, vinculada por un identificador (Figura 19). Son relativamente pequeñas y se pueden utilizar
como criterios de filtro. Son bases de datos históricas, más de consulta que de transacción, e
incrementales.
Figura 19. Esquema Estrella.
El esquema de estrella sólo tiene un nivel. Su diseño es ad hoc y difícil de cambiar. La tabla de
hechos es más grande en atributos y tuplas que las de dimensiones. El tener todos los hechos juntos
y las dimensiones separadas permite que las “juntas” sean mínimas ocupando menos tiempo las
consultas.
2.2- Importación de los Datos.
Para cargar una base de datos se utilizaría una herramienta para extraer la información de los
archivos HDF donde están almacenados e ir acotejando estos datos dentro del SGBD-OR. Esta
herramienta pudiera incluir sentencias SQL en código fuente C, lo que facilita mucho la
realización de tareas comunes con bases de datos.
Datos científicos SGBD-OR
HERRAMIENTA
HDF
53
2.3- Accediendo a los DC en PostgreSQL.
Una vez que los datos científicos se encuentran almacenados dentro la base de datos, se pueden
usar las operaciones tradicionales que brindan los SGBD-OR para manipularlos. Para este trabajo
se eligieron cuatro de ellas para el cálculo de valores estadísticos de los datos: la suma, el
promedio, el máximo y el mínimo.
Las bases de datos espaciales no tienen un conjunto de operadores que sirvan como elementos
básicos para la evaluación de consultas ya que estas manejan un volumen extremadamente grande
de objetos complejos no ordenados en una dimensión. Es por esto que existen algoritmos
complejos para evaluar predicados espaciales. Las consultas son realizadas generalmente en SSQL
(Spatial SQL), el cual introduce mediante extensiones, los distintos conceptos del álgebra ROSE
dentro del lenguaje SQL estándar, es decir, utiliza las cláusulas SELECT-FROM-WHERE para las
tres operaciones en el álgebra relacional (proyección algebraica, producto cartesiano y selección).
Las tres categorías fundamentales de consultas en un sistema de información espacial son:
1. Consultas exclusivamente de propiedades espaciales. Ej: "traer todos los pueblos que
son cruzados por un río".
2. Consultas sobre propiedades no espaciales. Ej: "cuantas personas viven en Valdivia".
3. Consultas que combinan propiedades espaciales con no espaciales. Ej: "traer todos los
vecinos de un cuadra localizada en Los Angeles"
En el lenguaje SSQL, el ejemplo del segundo punto se escribiría de la siguiente forma:
SELECT poblacion FROM ciudades WHERE nombre= "Valdivia"
El PostgreSQL posee la capacidad de hacer transacciones anidadas (savepoints) y posee un
sofisticado optimizador de consultas, que es capaz de resolver consultas complejas en tiempos
comparables a los de los mejores DBMS. Una última adición en este campo es la habilidad de
usar varios índices para resolver consultas sobre una misma tabla y mejorar el rendimiento de
la base de datos. Estos índices pueden ser compuestos, únicos, parciales, funcionales (sobre
funciones) y que pueden ser definidos como B-tree, R-tree, hash o GiST. PostgreSQL posee
toda la infraestructura necesaria para extender estos tipos de índices.
54
Conclusiones Parciales.
En específico, los SGBD-OR (donde se ubica el PostgreSQL), extienden el modelo relacional,
brindándole capacidades propias de los lenguajes orientados a objetos, uniendo de este modo lo
mejor de ambos.
PostgreSQL posee una serie de características que han hecho que pueda ser fácilmente
extensible para trabajar con datos científicos, dado el soporte que brinda este sistema para el tipo de
dato arreglo multidimensional y las facilidades de interacción con otros lenguajes como C. Una
vez que los datos científicos están almacenados en el SGBD, se pueden aprovechar todas las
facilidades que este brinda para el manejo de los datos.
55
Capítulo 3: Análisis del Rendimiento.
En el capítulo anterior, se mostró que PostgreSQL posee una serie de características que
han hecho que pueda ser fácilmente extensible para trabajar con datos científicos, debido a su
rica colección de datos y operaciones estadísticas comunes. Utilizando precisamente estas
nuevas extensiones, en este capítulo se presentará un estudio de la incorporación de datos de un
archivo HDF al PostgreSQL y comparar el rendimiento entre ambas bases de datos.
3.1 - Ambiente de prueba.
Para las pruebas de rendimiento realizadas en este trabajo se utilizó una computadora
Hanel, con la siguiente configuración:
CPU Intel Celeron P4/Xeon a 2.40 Ghz.
248 MB de memoria RAM.
128 KB de memoria cache externa.
Disco duro IDE de 80 GB.
Tarjeta de video de 8 MB.
Tarjeta de red de 100 Mbps.
El sistema operativo empleado fue Linux Debian version 2.6.18. Las herramientas usadas
fueron el administrador grafico para PostgreSQL pgadmin3 (version 1.4.3), el SGBD-OR
PostgreSQL (version 8.1), el Hierarchical Data Format hdf5 (version 1.6.5) y el SPSS para
Windows (version 13.0). Como estadígrafos, fueron utilizados los comandos time, iostat y
mpstat que provee el Linux.
El comando time tiene como función ejecutar programas y sumarizar el tiempo consumido
por el mismo. Su valor esta dado en segundos. Proporciona una descripción general de las
estadísticas del CPU y de las E/S del disco.
El comando iostat muestra una descripción general de la utilización del CPU, junto con las
estadísticas de E/S para una o más unidades de disco. Es el encargado de monitorear las
entradas y salidas de los dispositivos del sistema mediante la observación del tiempo y los
dispositivos que están activados en relación con sus momentos de transferencia promedio. El
56
comando genera dos tipos de reportes: el de la utilización de la CPU y el de la utilización de
los dispositivos.
El comando mpstat realiza un reporte de las actividades de la CPU de forma individual. La
salida muestra una fila por cada uno de los procesadores presentes en el sistema y una serie de
columnas con estadísticas muy semejantes a las de iostat sobre distintos elementos, con la
excepción de una columna adicional mostrando las interrupciones por segundo manejadas por
la CPU.
3.2 - Métricas de Rendimiento.
Para el caso de estudio 1 como para el caso de estudio 2, se tomaron las siguientes
métricas de rendimiento:
tiempo de ejecución.
%user: porcentaje de tiempo en modo usuario (ejecutando aplicaciones, etc.)
%nice: porcentaje de tiempo en modo usuario (para procesos que han alterado su
prioridad de planificación usando nice).
%system: porcentaje de tiempo en modo kernel.
%iowait: porcentaje de tiempo que la CPU (o CPUs) estuvo ocioso mientras que el
sistema estuvo en la espera de una solicitud de E/S al disco.
%idle: porcentaje de tiempo ocioso.
tps: número de transferencias (u operaciones de E/S) por segundo.
kB_read/s: número de kilobytes leídos por segundo.
kB_wrtn/s: número de kilobytes escritos por segundo.
kB_read: número total de kilobytes leídos.
kB_wrtn: número total de kilobytes escritos.
rrqm/s: numero de solicitudes de lectura por segundo que son puestos en cola por el
dispositivo.
wrqm/s: numero de solicitudes de escritura por segundo que son puestos en cola por el
57
dispositivo.
r/s: numero de solicitudes de lectura expedidas al dispositivo por segundo.
w/s: numero de solicitudes de escritura expedidas al dispositivo por segundo.
rkB/s: numero de kilobytes leidos desde el dispositivo por segundo.
wkB/s: numero de kilobytes escritos desde el dispositivo por segundo.
avgrq-sz: tamano promedio (en sectores) de las solicitudes que son expedidas hacia el
dispositivo.
avgqu: longitud promedio de la cola de las solicitudes que son expedidas hacia el
dispositivo.
await: tiempo promedio (en milisegundos) de las solicitudes de E/S a ser respondidas.
svctm: tiempo promedio (en milisegundos) de las solicitudes E/S que son expedidas al
dispositivo.
%util: porcentaje del tiempo de la CPU durante el cual las solicitudes de E/S son
expedidas al dispositivo.
3.3 – Caso de Estudio 1.
Los datos utilizados fueron obtenidos del Programa Pathfinder, concebido por la NASA a
principios de los años 90, con el objetivo de poner a disposición de la comunidad científica la
información obtenida durante años por varios satélites que se encargan de recopilar y procesar
a diario datos atmosféricos. Estos se encuentran almacenados en una gran cantidad de archivos
de tipo HDF, y son procesados utilizando complejos algoritmos para obtener información
climatológica de las áreas correspondientes. Entre las variables almacenadas en estos archivos
se consideraron en este trabajo la presión atmosférica, la latitud, la longitud y los valores de
significación correspondientes.
58
3.4 – Resultados del Caso de Estudio 1.
Después de aplicar las consultas estadísticas implementadas en lenguaje C al archivo HDF
TOVS5DAY.h5, se obtuvieron los siguientes resultados:
time.
1 Min: 0.032.
2 Max: 0.03.
3 Average: 0.03.
4 Sum: 0.03.
iostat.
1 Min:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
14.43 485.36 75.03 490.18 75.64
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
3.85 6.79 7.38 6.04 417.19 51.31 54.31 0.07 3.89 2.9 4.21
2 Max:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
28.83 1488.21 21.09 1503.05 22.1
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
11.3 8.18 22.79 1.67 1232.47 39.38 87.32 0.15 4.75 3.42 10.74
59
3 Average:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
27.12 1083.56 51.43 1088.67 52.67
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
15.72 3.43 32.85 4.26 1678.54 30.79 91.85 0.23 8.63 4.87 16.77
4 Sum:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
42.66 1916.03 28.4 1922 28.4
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
12.8 3.07 29.09 0.5 1406.37 14.27 108.84 0.18 6.16 4.99 14.75
mpstat.
1 Min:
%user %nice %sys %iowait %idle intr/s
3.93 0 1.6 2.28 92.19 369.45
2 Max:
%user %nice %sys %iowait %idle intr/s
4.29 0 1.52 0.05 94.14 352.86
60
3 Average:
%user %nice %sys %iowait %idle intr/s
4.38 0 1.46 1.21 92.95 357.36
4 Sum:
%user %nice %sys %iowait %idle intr/s
3.66 0 1.61 2.55 92.19 358.22
3.5 – Caso de Estudio 2.
Para cargar una base de datos con estos datos es necesario extraerlos de los archivos HDF
donde están almacenados. El proceso de extracción de los datos y llenado de la base de datos
puede ser engorroso y consumir tiempo, pues no están disponibles herramientas que lo realicen
de manera automática. Para completar esta tarea, se creó una herramienta en lenguaje C que
recibe como parámetros el nombre del archivo HDF y la información de la base de datos
(nombre, nombre de la tabla, nombre de usuario y contraseña, puerto, etc.), para
posteriormente llenarla con los datos almacenados en el archivo HDF. Para ello utiliza las
bibliotecas libhdf5 y libpq, suministradas por los paquetes HDF y PostgreSQL
respectivamente.
La base de datos científicos fue modelada basándose en el modelo estrellado. Está
compuesta por una tabla principal nombrada TestDataTable que almacenará un número de
secuencia incremental, las llaves extranjeras de las tablas dimensiones (Pressure, Latitude,
Longitude) conectadas a ella y un último campo que almacenará el valor de la significación.
La tabla Pressure almacenará un número identificador que hará función de llave primaria
y un valor que corresponderá con los valores de presión que van desde los 200 hasta los 1200
hectopascal.
61
La tabla Longitude almacenará un número identificador que hará función de llave primaria
y un valor que corresponderá con los valores de longitud.
La tabla Longitude almacenará un número identificador que hará función de llave primaria
y un valor que corresponde con los valores de latitud.
3.6 – Resultados del Caso de Estudio 2.
Después de ejecutar las consultas estadísticas en lenguaje SQL a la base de datos científicos, se
obtuvieron los siguientes resultados:
time.
1 Min: 855.8.
2 Max: 863.
3 Average: 840.83.
4 Sum: 919.63.
iostat.
1 Min:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
91.34 7168.68 39.63 7242.67 39.83
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
45.81 6.94 89.9 1.25 6876.2 32.77 120.66 0.6 6.33 4.23 39.36
2 Max:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
62
65.02 5713.93 16.34 5726.52 16.44
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
57.02 5.9 84.8 1 5918.32 27.58 94.60 0.55 6.18 4.29 35.56
3 Average:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
80.39 6425.23 50.22 6452 50.52
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
89.33 5.24 91.81 0.9 5706.49 24.57 82.78 0.55 5.53 3.74 33.86
4 Sum:
tps kB_reads/s kB_wrtn/s kB_read kB_wrtn
111.35 7310.44 15.75 7377.44 15.84
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
43.84 4.96 76.01 0.83 5706.4 21.51 105.35 0.43 5.5 3.92 30.21
mpstat.
1 Min:
%user %nice %sys %iowait %idle intr/s
32.73 0 5.08 16.53 45.15 482.22
63
2 Max:
%user %nice %sys %iowait %idle intr/s
37.88 0 5.48 13.29 42.56 445.57
3 Average:
%user %nice %sys %iowait %idle intr/s
32.47 0 4.85 20.88 41.42 488.78
4 Sum:
%user %nice %sys %iowait %idle intr/s
35.95 0 5.11 15.46 43.02 451.43
3.7 - Comparación entre los dos Casos de Estudio.
Después de obtener los resultados de emplear los dos casos de estudio, se utilizó el Test de
Wilcoxon a través del SPSS para comparar las métricas de rendimiento de ambos
respectivamente.
Métricas HDF PostgreSQL
Tiempo de duración Menor Mayor
tps Menor Mayor
kB_reads/s Menor Mayor
kB_wrtn/s Igualdad
kB_read Menor Mayor
kB_wrtn Igualdad
%user Menor Mayor
%sys Menor Mayor
64
%iowait Menor Mayor
%idle Mayor Menor
intr/s Menor Mayor
rrqm Igualdad
wrqm Igualdad
r/s Menor Mayor
w/s Igualdad
rkB/s Menor Mayor
wkB/s Menor Mayor
avgrq Igualdad
avgqu Menor Mayor
await Igualdad
svctm Igualdad
%util Menor Mayor
Conclusiones parciales
Se implementó un caso de estudio entre los datos científicos almacenados en archivos HDF y
en un SGBD-OR. Después de elegirse las métricas de rendimiento, realizaron pruebas de
recuperación de datos a través de consultas, midiéndose los valores de las variables de rendimiento.
Finalmente se realizó el Test de Wilcoxon para establecer una comparación entre ambas soluciones,
descubriéndose que en algunos aspectos como el tiempo de duración, la utilización de la CPU, el
tiempo en que esta permanece ociosa, entre otros, es mucho menor en las consultas a archivos
HDF. En otros aspectos como en los requerimientos de lectura/escritura puestos en cola, el tiempo
en que estas son respondidas y expedidas, HDF y PostgreSQL mostraron semejanza. En otros,
como la cantidad de información leída y escrita, la utilización de la CPU, el número de
interrupciones, entre otras es mucho superior en el PostgreSQL.
65
Conclusiones y Recomendaciones
En este trabajo se analizó la factibilidad de la utilización del SGBD-OR PostgreSQL el
almacenamiento y trabajo con datos científicos. Se comprobó que este gestor posee ventajas sobre
los otros modelos (relacional, orientado a objetos) que lo convierten en buen candidato para la
manipulación de datos científicos.
Se determinaron las tendencias en el uso de Bases de Datos para el almacenamiento de datos
científicos (Bases de Datos Científicas), con respecto a aspectos tales como tipo de SGBD
(relacional, objeto-relacional, orientado a objetos, deductivo), tipos de datos almacenados, forma de
modelar los datos, entre otros.
También se mostraron las ventajas que ofrece un SGBD-OR para el almacenamiento y
visualización de datos científicos, así como algunas medidas para mejorar el rendimiento en el
acceso a los datos científicos almacenados en el SGBD-OR escogido.
Se implementó una base de datos en PostgreSQL para almacenar datos científicos y
se realizó una comparación de rendimiento entre este SGBD-OR y el formato nativo HFD.
No obstante, se recomienda que este estudio no termine junto con el presente trabajo y se
continúe la investigación sobre este tema tan controvertido en pesquisas posteriores.
66
Bibliografía
AMIRA (1998).
AVS (1998).
BRICEÑO AVILA, C. (2006) Informe Final.
CACERES GONZÁLEZ, A. (2006) Arreglos Multidimensionales.
CATTELL, R. G. (1995) The Object Database Standard: ODMG-93 (Release 1.2).
COHEN, S. H., PATRICK; SCHULZ, KARL W.; BARTH, WILLIAM L.; BENTON, BRAD (2006) Scientific Formats for Object-Relational Database Systems: A Study of Suitability and Performance.
COMPUTING SYSTEM, BARRODALE (2008) Applications of Object Relational Database Management Systems at BCS
CUBILLOS, C. (2007) Estructuras estáticas.
CURSO (2006) Algoritmos y Programación II.
DX (1998).
EGGER, A. E. (2004) Visualizando Datos Científicos: Un componente esencial de la investigación.
ELSMARI, R. N., S. B. (2002) Fundamentals of Database Systems.
ERWIG, M. (2008) Toward Spatiotemporal Patterns.
EXPLORER, I. (1998).
GRAY, A. R. T. A. A. S. S. A. P. Z. K. A. J. (2003) The Sloan Digital Sky Survey Science Archive: Migrating a Multi-Terabyte Astronomical Archive from Object to Relational DBMS.
HDF (1998).
HDF (2005) HDF5 User Guide
KHOROS (1998).
MUSICK, R. (1998) Supporting Large-Scale Computational Science.
NAHOURAII, E. P., F. (1991) Object-Oriented Databases.
67
NASA fits-page.
NETCDF (1998).
NIETO-SANTISTEBAN, M. S., ALEXANDER S. (2005) When Database Systems Meet the Grid.
OCHOA, G. Tipos Abstractos de Datos. Universidad Simón Bolívar.
OLIVARES ROJAS, J. C. (2008) Apoyo para la toma de decisiones.
OPENDX (1998).
ORTEGA CAMACHO, A. A. (2008) Uso de un SGBD-OR para el trabajo con datos científicos.
PÉREZ RISQUET, C. O. C., JUAN C (2005) Modelación de datos para la Visualización Científica.
PÉREZ RISQUET, C. O. C., JUAN C; MORELL PÉREZ, ALBERTO; ENRIQUE CARO, SAUMEL (2006) Uso de DBMS-OR para el trabajo con datos científicos: un caso de estudio.
PFALTZ, J. L. H., RUSSELL F. ; FRENCH, JAMES C. (1998) Scalable, parallel, scientific databases.
PUENTES VERDIN, JORGE (2006) Introducción a la Visualización Científica.
RAO, B. R. (1994) Object Oriented Database: Technology, Applications, and Products.
RODRÍGUEZ, O. (2008) Data Warehouse: un enfoque industrial.
SAHLING, N. (2002) Computer Science and Visualization.
SILVERIO CASTRO, R. (2002) Procesamiento analítico en línea OLAP.
STONEBRAKER, M. B., P. (1999) Object-Relational DBMSs: Tracking the Next Great Wave.
68
Anexo
Anexo I. Esquema de BDVar
69
Anexo II. Tablas generadas para BDVar.
70
71
Anexo III. Tabla del comportamiento de concentraciones CO2.
Year Jan. Feb. March April May June July Aug. Sept. Oct. Nov. Dec. Annua
l
1958 -99.99 -99.99 315.71 317.45 317.5 -99.99 315.86 314.93 313.19 -99.99 313.34 314.67 -99.99
1959 315.58 316.47 316.65 317.71 318.29 318.16 316.55 314.8 313.84 313.34 314.81 315.59 315.98
1960 316.43 316.97 317.58 319.03 320.03 319.59 318.18 315.91 314.16 313.83 315 316.19 316.91
1961 316.89 317.7 318.54 319.48 320.58 319.78 318.58 316.79 314.99 315.31 316.1 317.01 317.65
1962 317.94 318.56 319.69 320.58 321.01 320.61 319.61 317.4 316.26 315.42 316.69 317.69 318.45
1963 318.74 319.08 319.86 321.39 322.24 321.47 319.74 317.77 316.21 315.99 317.07 318.36 318.99
1964 319.57 -99.99 -99.99 -99.99 322.23 321.89 320.44 318.7 316.7 316.87 317.68 318.71 -99.99
1965 319.44 320.44 320.89 322.13 322.16 321.87 321.21 318.87 317.81 317.3 318.87 319.42 320.03
1966 320.62 321.59 322.39 323.7 324.07 323.75 322.4 320.37 318.64 318.1 319.79 321.03 321.37
1967 322.33 322.5 323.04 324.42 325 324.09 322.55 320.92 319.26 319.39 320.72 321.96 322.18
1968 322.57 323.15 323.89 325.02 325.57 325.36 324.14 322.11 320.33 320.25 321.32 322.9 323.05
1969 324 324.42 325.64 326.66 327.38 326.7 325.89 323.67 322.38 321.78 322.85 324.12 324.62
1970 325.06 325.98 326.93 328.13 328.07 327.66 326.35 324.69 323.1 323.07 324.01 325.13 325.68
1971 326.17 326.68 327.18 327.78 328.92 328.57 327.37 325.43 323.36 323.56 324.8 326.01 326.32
1972 326.77 327.63 327.75 329.72 330.07 329.09 328.05 326.32 324.84 325.2 326.5 327.55 327.46
1973 328.54 329.56 330.3 331.5 332.48 332.07 330.87 329.31 327.51 327.18 328.16 328.64 329.68
1974 329.35 330.71 331.48 332.65 333.09 332.25 331.18 329.4 327.44 327.37 328.46 329.58 330.25
1975 330.4 331.41 332.04 333.31 333.96 333.59 331.91 330.06 328.56 328.34 329.49 330.76 331.15
1976 331.74 332.56 333.5 334.58 334.87 334.34 333.05 330.94 329.3 328.94 330.31 331.68 332.15
1977 332.92 333.42 334.7 336.07 336.74 336.27 334.93 332.75 331.58 331.16 332.4 333.85 333.9
1978 334.97 335.39 336.64 337.76 338.01 337.89 336.54 334.68 332.76 332.54 333.92 334.95 335.5
1979 336.23 336.76 337.96 338.89 339.47 339.29 337.73 336.09 333.91 333.86 335.29 336.73 336.85
1980 338.01 338.36 340.08 340.77 341.46 341.17 339.56 337.6 335.88 336.01 337.1 338.21 338.69
1981 339.23 340.47 341.38 342.51 342.91 342.25 340.49 338.43 336.69 336.85 338.36 339.61 339.93
1982 340.75 341.61 342.7 343.56 344.13 343.35 342.06 339.82 337.97 337.86 339.26 340.49 341.13
1983 341.37 342.52 343.1 344.94 345.75 345.32 343.99 342.39 339.86 339.99 341.16 342.99 342.78
1984 343.7 344.51 345.28 347.08 347.43 346.79 345.4 343.28 341.07 341.35 342.98 344.22 344.42
1985 344.97 346 347.43 348.35 348.93 348.25 346.56 344.69 343.09 342.8 344.24 345.56 345.9
1986 346.29 346.96 347.86 349.55 350.21 349.54 347.94 345.91 344.86 344.17 345.66 346.9 347.15
1987 348.02 348.47 349.42 350.99 351.84 351.25 349.52 348.1 346.44 346.36 347.81 348.96 348.93
1988 350.43 351.72 352.22 353.59 354.22 353.79 352.39 350.44 348.72 348.88 350.07 351.34 351.48
1989 352.76 353.07 353.68 355.42 355.67 355.13 353.9 351.67 349.8 349.99 351.3 352.53 352.91
72