VOLUMEN III
DEL RIO CAUCA - PMC FASE II
Convenio Interadministrativo 0168 de Noviembre 27 de 2002
OPTIMIZACIÓN DEL SISTEMA DE GESTIÓN DE
BASE DE DATOS DE CALIDAD DEL AGUA-SGBD
UNIVERSIDAD DEL VALLE
FACULTAD DE INGENIERIA
ESCUELA DE INGENIERIA DE RECURSOS NATURALES Y DEL AMBIENTE
Santiago de Cali, Abril de 2004
SUBDIRECCION DE CONOCIMIENTO AMBIENTAL TERRITORIAL
Convenio Interadministrativo 0168 de Noviembre 27 de 2002 entre la CVC y la Universidad del Valle
PROYECTO DE MODELACION DEL RIO CAUCA – PMC FASE II
OPTIMIZACIÓN DEL SISTEMA DE GESTIÓN DE BASE DE
DATOS DE CALIDAD DEL AGUA-SGBD
VOLUMEN III
UNIVERSIDAD DEL VALLE FACULTAD DE INGENIERIA
ESCUELA DE INGENIERIA
DE RECURSOS NATURALES Y DEL AMBIENTE
El presente documento fue realizado en desarrollo del Proyecto de Modelación Matemática del Río Cauca, Proyecto PMC Fase II, dentro del Convenio Interadministrativo 0168 de Noviembre 27 de 2002 suscrito entre la Corporación Autónoma Regional del Valle del Cauca CVC y la Universidad del Valle.
Este informe fue elaborado por la Escuela de Ingeniería de Recursos Naturales y del Ambiente de la Facultad de Ingeniería de la Universidad del Valle. Participaron en el desarrollo del informe los siguientes profesionales:
Ing. Carlos Alberto Ramírez Director del Proyecto Ing. José Luis García Vélez Codirector del Proyecto
Ing. Alberto Galvis Castaño Coordinador de Modelación de Calidad del Agua Ing. Edgar Fernandez Hernandez Ingeniero del Proyecto
Ing. Carlos Velez Quintero Ingeniero del Proyecto
Debe destacarse la colaboración de los profesionales y técnicos de la CVC quienes participaron durante el desarrollo del mismo, desde el suministro de información hasta la revisión y ajuste del informe final. El Comité de Seguimiento de CVC estuvo integrado principalmente por:
Ing. Maria Clemencia Sandoval Coordinadora General Ing. José Antonio Sierra Asesor Técnico
Ing. Freide Guzmán Asesor Técnico
Ing. Carlos Humberto Duque Asesor Técnico Ing. José Alberto Riascos Asesor Técnico
Ing. Amparo Duque Asesor Técnico
Ing. Luisa Baena Asesor Técnico
TABLA DE CONTENIDO Pag. 1. INTRODUCCION 1.1 2 OBJETIVOS 2.1 2.1 Objetivo General 2.1 2.2 Objetivos Específicos 2.1 3 JUSTIFICACION 3.1 4 METODOLOGIA 4.1
4.1 Sistema de Gestión de Base de Datos (SGBD) 4.1
4.2 Revisión del Modelo Conceptual 4.2
4.2.1 Modelos de Datos 4.2
4.2.2 Clasificación de los Modelos de Datos 4.2
4.2.3 Arquitectura del SGBD 4.3 4.2.4 Funciones del SGBD 4.4 4.2.5 Modelos Relacionales 4.4 4.2.6 Relaciones 4.5 4.2.7 Dominios 4.5 4.2.8 Tuplas 4.5
4.2.9 Grado de una Relación 4.5
4.2.10 Cardinalidad 4.6
4.2.11 Propiedades de las Relaciones 4.6
4.2.12 Tipos de Relaciones 4.6
4.2.13 Claves 4.7
4.2.14 Esquema de una base de datos relacional 4.8
4.2.15 Integralidad Relacional de los Datos 4.8
4.2.16 Nulos 4.8
4.2.17 Reglas de Integralidad Referencial 4.9
4.2.18 Reglas de Negocio 4.9
4.2.19 Álgebra Relacional 4.9
4.3 Optimización del Diseño del SGBD 4.11
4.4 Implementación del SGBD 4.12
4.5 Evaluación del SGBD 4.12
4.6 Instalación del SGBD 4.13
6 CONCLUSIONES Y RECOMENDACIONES 6.1
6.1 Conclusiones 6.1
6.2 Recomendaciones 6.1
ANEXOS
1. Manual de Usuario del SGBD
2. Código Fuente de la Interfase del SGBD (Impreso y en CD) 3. Instalador de la Interfase (en CD)
4. Formatos de plantillas para exportar datos de muestras de industrias
LISTADO DE FIGURAS
LISTADO DE FIGURAS
CAPITULO 2
Fig. No. TITULO
4.1 ARQUITECTURA DEL SGBD
CAPITULO 5
Fig. No. TITULO
5.1 PORTADA DE LA INTERFASE
5.2 PLANTILLA PARA EXPORTAR MUESTRAS DE ESTACIONES
5.3 PLANTILLA PARA EXPORTAR MUESTRAS DE INDUSTRIAS
5.4 VENTANA PARA EXPLORAR, ACTUALIZAR Y CREAR REGISTROS DE
INDUSTRIA
5.5 VENTANA PARA ANALIZAR VERTIMIENTOS
5.6 VENTANA PARA EL ANÁLISIS ESTADÍSTICO DEL RÍO CAUCA Y
TRIBUTARIOS.
5.7 VARIACIÓN ESPACIAL DE LOS PARÁMETROS DE CALIDAD SOBRE RÍO
CAUCA
5.8 APORTE DE CARGA POR ZONA DE INTERÉS SOBRE EL RÍO CAUCA
CAPITULO 1
INTRODUCCION
1. INTRODUCCIÓN
En el marco del estudio de Modelación del Río Cauca, proyecto PMC fase II se realizó la optimización del Sistema de gestión de Bases de Datos para la sistematización del manejo de la información que posee CVC de más de 20 años de registros. El propósito de la actividad está orientado a facilitar el procesamiento de la información que regularmente toma la CVC en relación con la calidad del agua del río Cauca y sus tributarios, incluyendo las descargas industriales y domésticas.
Para el desarrollo de la actividad se investigaron los formatos y medios físicos y electrónicos en los cuales CVC ha consignado sus registros. Desde 1997 CVC se planteó la posibilidad de diseñar un sistema de información para agilizar consultas, analizar tendencias estadísticas y generar informes para lograr una mejor comprensión de los procesos que ocurren en el río Cauca y en sus tributarios. Este análisis puede presentar dificultades si la información no se encuentra sistematizada.
Con base en las necesidades de obtención de un mayor provecho de las mediciones, en el año 1999 CVC contrató a la firma Mapas y Datos de Bogotá para el diseño de un sistema de información de orden corporativo. El sistema de información siguió todos los pasos normales, tales como los requeridos para el desarrollo de un software de programación. La firma Mapas y Datos dividió la información por módulos, de acuerdo como estaban distribuidas las funciones de control de la cuenca del río Cauca.
Entre los módulos implementados se dispone de uno para el manejo de la información sobre la calidad del agua del río Cauca, ríos tributarios e información sobre industrias, grandes consumidores, vertimientos industriales, además de un aspecto esencial como lo es el cálculo del valor a pagar por tasa retributiva. Este módulo de calidad del agua se utilizó por dos años, pero debido a problemas operativos, de poca amigabilidad para el ingreso de los datos y por asuntos administrativos en CVC se suspendió su uso.
En el presente informe se describe el modelo conceptual y la metodología empleada para la actualización y puesta en operación del sistema de información para el manejo de registros de calidad del agua del río Cauca, sus ríos tributarios e información sobre vertimientos de origen doméstico e industriales.
La optimización del sistema de información y el diseño de una nueva interfase sirven como punto de partida para integrar, consolidar y optimizar toda la información que posee CVC en todas sus dependencias. En la actualidad el conjunto de archivos que componen la base de datos no son manejables de manera práctica debido a que la información no está asociada a un sistema de información. Para facilitar su manejo se optimizó el sistema de información y se diseñó una nueva interfase gráfica. En los capítulos siguientes se describe la metodología aplicada para la optimización y puesta en operación del sistema de gestión de bases de datos.
CAPITULO 2
OBJETIVOS
2. OBJETIVOS
2.1 OBJETIVO GENERAL
Optimizar y poner en funcionamiento el Sistema de Gestión de Bases de Datos de CVC para el acceso fácil, seguro y confiable de la información de calidad del agua del Río Cauca y sus tributarios.
2.1. OBJETIVOS ESPECÍFICOS
• Contribuir al buen manejo de la información, que posee la CVC, sobre la calidad del agua del Río Cauca y sus tributarios.
• Diseñar una herramienta eficaz (interfase), de bajo costo y de fácil actualización y ampliación para el manejo de la información recolectada por la CVC concerniente a datos de calidad del agua, vertimientos y cobro de tasas retributivas.
• Agrupar, ordenar, cruzar información, generar tablas y gráficas dinámicas a través de un sistema de información de carácter gerencial para el manejo de la información sobre calidad del agua del Río Cauca y sus tributarios.
CAPITULO 3
JUSTIFICACION
3. JUSTIFICACIÓN
La Corporación Autónoma Regional de Valle del Cauca, CVC, ha recolectado información de distintos parámetros físico-químicos e hidráulicos del Río Cauca por más de 20 años. La información tomada ha sido consignada en papel y en hojas electrónicas de Excel, lo cual hace difícil el análisis e interpretación de los diferentes procesos en el Río Cauca, y más concretamente el análisis estadístico temporal y espacial de la información consignada.
Por lo anterior, y considerando las dificultades para el manejo de la información, se propuso a CVC rescatar el sistema de información y gestión de datos existente con el fin de generar informes y realizar el análisis estadístico de la información, además de permitir el cálculo de las tasas retributivas.
La optimización del sistema de información facilitará la toma de decisiones y servirá de apoyo en la modelación hidrodinámica y de calidad del agua del Río Cauca; además cumplirá con los estándares de aplicaciones de cuarta generación, como son: agilidad, confiabilidad, expansión y fácil actualización.
CAPITULO 4
METODOLOGIA
4. METODOLOGÍA
Para la optimización del sistema de información de CVC se aprovecha la estructura actual de la base de datos de CVC y la base de datos desarrollada en Excel durante la Fase I del proyecto PMC.
Para la optimización del Sistema de Gestión de Base de Datos (SGBD) se siguieron los siguientes pasos:
a) Especificación: Esta actividad corresponde a la determinación de los propósitos y funciones del sistema.
b) Diseño: En esta fase se evaluó el modelo conceptual y se ajustaron los mecanismos de consulta y se diseñó una nueva interfase gráfica que permite agilizar el SGBD.
c) Implementación: Esta actividad se refiere a la construcción física del SGBD; es la transformación del diseño en la aplicación mediante la creación de la base de datos y los objetos del programa.
d) Evaluación: En esta actividad se verifica si la aplicación cumple con el propósito predefinido y las funciones para las cuales ha sido diseñada.
e) Instalación: La aplicación dispone de un instalador para poder ser ejecutada en cualquier ordenador.
4.1. SISTEMA DE GESTIÓN DE BASES DE DATOS (SGBD)
El propósito fundamental de la optimización del Sistema de Gestión de Bases de Datos es permitir la interpretación de la información de los registros de calidad del agua para facilitar la toma de decisiones para propósitos de control del recurso hídrico, al igual de servir como soporte para la modelación del Río Cauca. Con lo anterior las principales funciones que permite el SGBD optimizado son:
1. Análisis de la información sobre la calidad del agua del Río Cauca. Estos análisis son de suma importancia para el manejo integral del recurso hídrico y como soporte para la toma de decisiones. Por ejemplo, se considera de gran valor conocer la variación temporal y espacial de los parámetros de calidad del agua en el Río Cauca y sus tributarios.
2. Estimar el impacto de los vertimientos en el Río Cauca por tramos: Salvajina-Hormiguero, Hormiguero-Mediacanoa y Mediacanoa-La Virginia. Con esto se pretende conocer el efecto de las descargas en estos tres tramos y posibilitar la cuantificación de las tasas retributivas. Para ello se diseñaron diversos tipos de gráficos con lo cual se puede determinar la magnitud de la variación de los parámetros de calidad del agua en los 3 tramos sobre el río Cauca.
El SGBD actualizado permitirá procesos como transacciones en línea y servirá como un sistema de soporte de decisiones. La primera función permitirá el acceso e inserción de información y la segunda el análisis de los datos y la elaboración de análisis estadísticos, descubrir tendencias, agrupar registros, etc.
4.2. REVISIÓN DEL MODELO CONCEPTUAL
Se presenta aquí una breve descripción del modelo conceptual el cual sirvió como base para la optimización del SGBD existente.
Los sistemas de información permiten manejar estructuras de datos. Un Modelo de Datos se define como un conjunto de conceptos que se utilizan para describir el esquema de una base de datos, las operaciones para manejar los datos y el conjunto de reglas de integridad. Hay tres categorías principales de modelos de datos: modelos conceptuales, modelos lógicos y modelos físicos.
4.2.1. Modelos de Datos
Un modelo de datos está conformado por:
Un conjunto de conceptos para definir la estructura de la base de datos: • Datos.
• Relaciones entre datos.
• Restricciones sobre datos y relaciones.
Un conjunto de operaciones para realizar consultas y actualizaciones de información.
4.2.2. Clasificación de los Modelos de Datos
Los modelos de datos se clasifican en conceptuales, lógicos y físicos: Modelos conceptuales.
El diseño del modelo conceptual parte de las especificaciones y los requisitos del usuario. Su resultado se simplifica mediante el esquema conceptual de la base de datos. Se entiende por esquema conceptual la descripción de alto nivel de la estructura de la base de datos, independientemente del SGBD que se diseñe para manipularla o la plataforma que se vaya a utilizar.
En un sentido más amplio, un modelo conceptual es una representación abstracta estructurada que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es
describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar la información.
Los modelos conceptuales son muy buenas herramientas para representar la realidad, estos deben poseer las siguientes cualidades:
Expresividad: Deben tener suficientes conceptos para expresar perfectamente la realidad.
Simplicidad: Deben ser simples para que sean fáciles de entender. Minimalidad: Cada concepto debe tener un significado distinto.
Formalidad: Todos los conceptos deben tener una interpretación única, precisa y bien definida.
Modelos lógicos.
El objetivo del diseño del modelo lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de SGBD sobre el que se va a implementar el sistema. El modelo lógico permite obtener una representación para usar del modo más eficiente posible los recursos que el modelo de SGBD posee con el fin de estructurar los datos y modelar las restricciones.
Modelos físicos.
En el modelo físico se específica cómo se almacena la información del esquema lógico global. Para ello, se debe conocer muy bien toda la funcionalidad del SGBD, además del sistema informático sobre el que éste va a trabajar. El diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo pueden obligar a una reestructuración del esquema lógico.
La metodología del diseño físico consta de cuatro fases: La traducción del esquema lógico global para el SGBD específico, el diseño de representación física del SGBD, el diseño de los mecanismos de seguridad y el monitoreo y afinamiento del sistema.
4.2.3. Arquitectura del SGBD
La arquitectura del SGBD obedece a 4 niveles tal como se muestra en la Figura 1. Estos son: (i.) nivel externo; (ii.) nivel conceptual; (iii.) nivel interno; y (iv.) organización física de los datos.
Figura 4.1. Arquitectura del SGBD
4.2.4. Funciones del Sistema de Gestión de Bases de Datos
Las funciones principales del SGBD son:
• Permitir a los usuarios almacenar datos, acceder a ellos y actualizarlos, ocultando su estructura física.
• Proporcionar un catálogo (diccionario de datos) accesible por los usuarios. • Proporcionar un mecanismo que garantice el procesamiento de las transacciones. • Proporcionar un mecanismo que realice el control de la concurrencia.
• Proporcionar un mecanismo para recuperación ante fallos. • Proporcionar un mecanismo de seguridad.
• Integrarse con algún software de comunicación (interfase). • Encargarse de mantener las reglas de integridad.
• Encargarse de mantener la independencia entre los programas y la estructura de la base de datos.
• Proporcionar herramientas para administrar la base de datos.
4.2.5. Modelos relacionales
Un SGBD relacional se basa en un modelo relacional. Este es un modelo lógico donde la estructura de los datos se fundamenta en relaciones y reglas de integridad. El modelo relacional representa la segunda generación de los SGBD. En él todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lógica, pero detrás de esa simple estructura hay un fundamento teórico importante. En
los últimos años se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, disponer de los conceptos de la orientación a objetos y disponer de capacidad deductiva.
El modelo relacional, como todo modelo de datos, tiene que ver con la estructura, integridad y maniobrabilidad de la información.
4.2.6. Relaciones
El modelo relacional se basa en el concepto matemático de relación. Una relación se representa gráficamente como una tabla bidimensional, con columnas y filas, en la que las filas corresponden a registros individuales y las columnas corresponden a los campos o atributos de esos registros. En un SGBD el usuario percibe la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la estructura lógica de la base de datos.
Los constituyentes básicos de las tablas son los atributos de las entidades. Un atributo es el nombre de una columna de una relación. En el modelo relacional, las relaciones se utilizan para almacenar información sobre los objetos que se representan en la base de datos. Los atributos pueden aparecer en la relación en cualquier orden.
4.2.7. Dominios
Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios constituyen una poderosa característica del modelo relacional. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. El concepto de dominio es importante porque permite que el usuario defina, en un lugar común, el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya más información disponible para el sistema cuando éste va a ejecutar una operación relacional, de modo que las operaciones que son semánticamente incorrectas se pueden evitar.
4.2.8. Tuplas
Una tupla es una fila de una relación. Los elementos de una relación son las tuplas o filas de la tabla.
4.2.9. Grado de una Relación
El grado de una relación es el número de atributos que contiene. El grado de una relación no cambia con frecuencia.
4.2.10. Cardinalidad
La cardinalidad de una relación es el número de tuplas o filas que contiene. Ya que en las relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía constantemente.
4.2.11. Propiedades de las relaciones
Las relaciones tienen las siguientes características:
Cada relación tiene un nombre y éste es distinto del nombre de todas las demás.
Los valores de los atributos son atómicos: en cada tupla, cada atributo toma un solo valor. Bajo esta condición se dice que las relaciones están normalizadas.
No hay dos atributos que tengan igual nombre.
El orden de los atributos no importa: los atributos no requieren estar ordenados. Cada tupla es distinta de las demás: no hay tuplas duplicadas.
El orden de las tuplas no importa: las tuplas no requieren estar ordenadas.
4.2.12 Tipos de relaciones
En un SGBD relacional pueden existir varios tipos de relaciones. No todos los SGBD manejan todos los tipos de relaciones.
Relaciones base. Son relaciones reales que tienen nombre y forman parte directa de la base de datos almacenada (son autónomas).
Vistas. También denominadas relaciones virtuales, son relaciones con nombre y derivadas; se representan mediante su definición en términos de otras relaciones con nombre, no poseen datos almacenados propios.
Instantáneas. Son relaciones con nombre y derivadas. Pero a diferencia de las vistas, son reales, no virtuales: Las relaciones instantáneas están representadas no sólo por su definición en términos de otras relaciones, sino también por sus propios datos almacenados. Son relaciones de sólo lectura y se refrescan periódicamente.
Resultados de consultas. Son las relaciones resultantes de alguna consulta específica. Pueden o no tener nombre y no persisten en la base de datos.
Resultados intermedios. Son las relaciones que contienen los resultados de sub-consultas. Normalmente no tienen nombre y tampoco persisten en la base de datos.
Resultados temporales. Son relaciones con nombre, similares a las relaciones base o a las instantáneas, pero la diferencia es que se destruyen automáticamente en algún momento apropiado.
4.2.13 Claves
Una clave es una identificación única de un atributo. Puesto que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus atributos.
Para un SGBD una superclave es un atributo o un conjunto de atributos que identifican de modo único las tuplas de una relación.
Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la relación.
El atributo o conjunto de atributos de la relación es una clave candidata que sí y sólo sí satisface las siguientes propiedades:
• Unicidad: nunca hay dos tuplas en la relación con el mismo valor.
• Irreductibilidad: ningún subconjunto tiene la propiedad de unicidad, es decir, no se pueden eliminar componentes de una tabla sin destruir la unicidad.
• Cuando una clave candidata está formada por más de un atributo, se dice que es una clave compuesta. Una relación puede tener varias claves candidatas.
El único modo de identificar las claves candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es posible que aparezcan duplicados. Sólo usando esta información semántica se puede saber con certeza si un conjunto de atributos forman una clave candidata.
La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus tuplas de modo único.
Dado que una relación no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relación siempre tiene clave primaria.
En el peor de los casos, la clave primaria estará formada por todos los atributos de la relación, pero normalmente habrá un pequeño subconjunto de los atributos que hagan esta función.
Las claves candidatas que no son escogidas como clave primaria son denominadas claves alternativas.
Una clave ajena es un atributo o un conjunto de atributos de una relación cuyos valores coinciden con los valores de la clave primaria de cualquier otra relación. Las claves ajenas representan
relaciones entre datos.
4.2.14 Esquema de una base de datos relacional
Una base de datos relacional es un conjunto de relaciones normalizadas. Para representar el esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de éstas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves ajenas.
4.2.15 Integridad Relacional de los Datos
Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de dominios.
Hay además dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Éstas son las reglas de integridad de entidades y de integridad referencial.
4.2.16 Nulos
Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un atributo nulo no representa el valor cero ni la cadena vacía, éstos son valores que tienen significado para el SGBD.
El nulo implica ausencia de información, bien porque al insertar la tupla se desconocía el valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido.
Ya que los atributos nulos no son valores deben tratarse de modo diferente, lo cual causa problemas de implementación. De hecho, no todos los SGBD relacionales soportan los nulos. La primera regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de los atributos que componen la clave primaria puede ser nulos.
Por definición, una clave primaria es un identificador indivisible que se utiliza para identificar de modo único las tuplas.
El indivisible significa que ningún subconjunto de la clave primaria sirve para identificar las tuplas de modo único.
son necesarios para distinguir las tuplas, con lo que se contradice la irreductibilidad.
La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos.
La regla de integridad referencial se enmarca en términos del estado de la base de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse.
4.2.17 Reglas de Integridad referencial
Las reglas de integridad relacional son: Regla de los nulos
Regla de borrado Regla de modificación
4.2.18 Reglas de Negocio
Además de las tres reglas de integridad anteriores, los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de negocio, con base en las reglas de negocio se tiene un mayor control sobre la información almacenada en la base de datos.
4.2.19 Álgebra relacional
El álgebra relacional es un lenguaje formal con una serie de operadores que trabajan sobre una o varias relaciones para obtener otra relación resultado sin que cambien las relaciones originales. Tanto los operandos como los resultados son relaciones, por lo que la salida de una operación puede ser la entrada de otra operación. Esto permite anidar expresiones algebraicas, del mismo modo que se pueden anidar las expresiones aritméticas. A esta propiedad se le denomina clausura. Las relaciones son cerradas bajo el álgebra, del mismo modo que los números son cerrados bajo las operaciones aritméticas.
Hay cinco operadores que son fundamentales: restricción, proyección, producto cartesiano, unión y diferencia. Estos permiten realizar la mayoría de las operaciones para la obtención de datos. Los operadores no fundamentales son la concatenación, la intersección y la división: Estos se pueden expresar a partir de los cinco operadores fundamentales.
Restricción
La restricción, también denominada selección, opera sobre una sola relación y da como resultado otra relación cuyas tuplas son las tuplas de la primera relación y que satisfacen la condición especificada.
Proyección
La proyección opera sobre una sola relación. La proyección entrega como resultado otra relación que contiene un subconjunto vertical de la relación inicial, extrayendo los valores de los atributos especificados y eliminando atributos duplicados. La restricción y la proyección son operaciones que permiten extraer información de una sola relación.
Debido a que es posible que haya atributos con el mismo nombre en las dos relaciones, el nombre de la relación se antepondrá al del atributo para que los nombres de los atributos sigan siendo únicos en la relación resultado.
Producto Cartesiano
El producto cartesiano obtiene una relación cuyas tuplas están formadas por la concatenación de todas las tuplas de una relación (R) con todas las tuplas de otra relación (S).
Unión
Se dice que dos relaciones son compatibles para la unión si ambas tienen la misma cabecera, es decir, si tienen el mismo número de atributos y éstos se encuentran definidos sobre los mismos dominios. En muchas ocasiones será necesario realizar proyecciones para hacer que dos relaciones sean compatibles para la unión.
Diferencia
La diferencia obtiene una relación que tiene las tuplas que se encuentran en R y no se encuentran en S. Para realizar esta operación, R y S deben ser compatibles para la unión.
Concatenación (Join)
Con la concatenación de dos relaciones (R y S) se obtiene como resultado una relación cuyas tuplas son todas las tuplas de R concatenadas con todas las tuplas de S. Para los atributos comunes se obtienen los mismos valores.
Concatenación externa (Outer-join)
La concatenación externa es una concatenación en la que las tuplas de R que no tienen valores en común con ninguna tupla de S, también aparecen en el resultado.
Intersección
La intersección obtiene como resultado una relación que contiene las tuplas de R que también se encuentran en S. Para realizar esta operación, R y S deben ser compatibles para la unión.
División
En la división de relaciones se obtiene una relación resultante cuya cabecera es el conjunto de atributos que contienen las tuplas de una relación base acompañadas de las tuplas de una relación secundaria.
Agrupación
Esta operación agrupa las tuplas que tienen los mismos valores en los atributos especificados y realiza un cálculo sobre los grupos obtenidos. La relación resultado tiene como cabecera los atributos por los que se ha agrupado y el cálculo realizado.
4.3. OPTIMIZACIÓN DEL DISEÑO DEL SGBD
En la actualidad la base de datos corporativa de CVC se encuentra residiendo en Oracle 7i. Físicamente las entidades, en la base de datos de Oracle, están representadas por tablas en primera forma normal. Las tablas se denominan entidades del sistema.
Las entidades principales dentro del modelo entidad - relación definidas para el SGBD son las estaciones en el río Cauca, estaciones sobre los ríos tributarios e industrias.
Cada entidad está constituida por un conjunto de atributos consignados en tablas. Cada tabla posee una identidad propia y única para el sistema.
Para dinamizar la información consignada en las tablas se efectúan relaciones entre ellas. Estas relaciones adquieren un sentido a través de las consultas. El lenguaje de consulta utilizado es el SQL (Structured Query Language).
Mediante el SQL se pueden consultar los datos almacenados desde el año 1999 hasta el año 2001. La fase de optimización del diseño incluye tres actividades principales:
• Documentación de los procesos de transacciones necesarias para acompañar las funciones requeridas.
• Diagramas de entidad – relación necesarias para servir a los procesos.
• Actualización de la base de datos lógica, necesaria para implementar el proceso de transacciones entre entidades - relaciones.
En esta fase se conservó la estructura de la base de datos actual, la cual obedece al tipo cliente - servidor.
En la actividad fue necesario limpiar la base de datos de información incompleta e incoherente que generaban ruido a la información.
Debido a que el manejo de la información a través de Oracle puede ser difícil y poco amigable para un usuario inexperto (entendido como inexperto aquella persona que no conozca el lenguaje de consulta (SQL) de Oracle), se optó por el diseño de una interfase gráfica de cuarta generación que permite realizar las siguientes actividades principales:
1. Consultas de datos históricos
2. Migración y emigración de registros
3. Realización de gráficos de datos históricos de variación temporal y especial de parámetros de calidad del agua a lo largo del Río Cauca y en los ríos tributarios
4. Cálculo de tasas retributivas 5. Generación de informes
6. Actualización y creación de datos sobre industrias entre otros aspectos
4.4 IMPLEMENTACIÓN DEL SGBD
La implementación del SGBD incluyó la transformación del diseño conceptual en la aplicación (software) mediante la actualización de la base de datos y los programas requeridos para su manejo y generación de reportes. Las tablas fueron actualizadas mediante la migración de datos. La aplicación desarrollada (nueva interfase) será la responsable de las diferentes actividades de validación de la información, almacenamiento, búsquedas, etc.
4.5. EVALUACIÓN DEL SGBD
La evaluación del SGBD se realizó con datos reales al interior de CVC. Para ello se efectuó, a tiempo real, una demostración con el personal de CVC de las bondades de la nueva aplicación conectados al servidor principal de la corporación (CVC). Dentro de la fase de evaluación se realizó un recorrido por todas las ventanas de la aplicación, con lo cual se detectaron fallos y se efectuaron los ajustes correspondientes.
4.6. INSTALACIÓN DEL SGBD
CAPITULO 5
5. INTERFASE GRÁFICA
Para hacer operativo el SGBD se diseñó una interfase gráfica en Visual Basic que permite de manera fácil y amigable, realizar todo tipo de consultas, importar y exportar datos, graficar, realizar cálculos y generar informes sin necesidad de conocer el lenguaje estructurado de consulta SQL. La interfase diseñada se codificó empleando el programa Visual Basic de Microsoft para facilitar la unión con las aplicaciones comerciales de más amplia difusión, como lo son World y Excel. En la Figura 5.2 se muestra la portada de la interfase.
Figura 5.1 Portada de la Interfase
Para el diseño de la interfase se identificaron los procesos y transacciones que realizan los usuarios para acceder a la información, la representación de estas actividades se presenta en el diagrama de flujo desarrollado para la implementación de la aplicación (ver Figura 5.2).
En los anexos se incluyen el código fuente de los principales módulos desarrollados para la interfase, junto con las tablas del sistema optimizadas.
La interfase diseñada cuenta con una serie de ventanas que permiten al usuario navegar fácilmente por la aplicación de acuerdo con sus necesidades de información y actualización de registros o cálculos.
Figura 5.2 Diagrama de Flujo del SGBD
La información sobre calidad del agua y demás mediciones de campo podrán ser exportadas directamente a la base de datos. Para facilitar el ingreso de la información se diseñó una serie de plantillas en Excel, las cuales se describen a continuación (ver Figuras 5.3 y 5.4).
Figura 5.3 Plantilla para Exportar datos de Muestras de Estaciones Sobre el Río Cauca y sus Tributarios
Figura 5.4 Plantilla para Exportar datos de Muestras de Industrias
Las principales ventanas creadas en la aplicación para realizar las consultas de acuerdo con la estructura de la base de datos son: Consultas sobre registros de calidad del agua e hidrología en las estaciones de medición de calidad del agua sobre el Río Cauca, información sobre registros de calidad del agua de los vertimientos de industrias y ríos tributarios y cálculo de tasas retributivas.
Con la nueva interfase es posible generar los informes de tendencias estadísticas y variaciones de parámetros, tanto espacial como temporal, para cada estación de medición sobre el río Cauca. En la aplicación los parámetros de calidad del agua siempre están asociados a la información hidrológica de la fuente.
En el caso del río Cauca, éste se dividió en 3 tramos principales de interés para facilitar el análisis. Estos tramos son: Salvajina-Hormiguero, Hormiguero-Mediacanoa y Mediacanoa-La Virginia.
La interfase permite la realización de los cálculos de los promedios anuales de concentración y cargas contaminantes de cada parámetro para cada estación. También posibilita graficar su valor para los 3 tramos preestablecidos sobre el Río Cauca.
La interfase igualmente permite determinar: (i.) promedio de caudal; (ii.) promedio de carga de DBO; (iii.) promedio de Oxigeno disuelto; (iv.) promedio de carga de DQO; y, (v.) promedio de carga de Sólidos Suspendidos, tanto en las estaciones de medición en el Río Cauca como en los ríos tributarios.
Para facilitar la presentación de las estadísticas por temporada seca o lluviosa, el año es dividido en trimestres. Para cada trimestre la interfase confronta con un caudal máximo preestablecido de invierno lo que permite definir automáticamente si el periodo corresponde a invierno o verano. Con lo anterior la aplicación puede calcular los promedios anuales de cada parámetro por estación (por temporada de verano o invierno) y graficar su valor para los 3 tramos definidos del río Cauca. Los gráficos generados son: (i.) promedio de caudal de invierno y de verano; (ii.) promedio de carga de DBO de invierno y de verano; (iii.) promedio de oxigeno disuelto de invierno y de verano; (iv.) promedio de carga de DQO de invierno y de verano; y, (v.) promedio de carga de Sólidos Suspendidos de invierno y de verano tanto para las estaciones de medición sobre el Río Cauca como para los ríos tributarios.
Las principales características y los tipos de reportes generados se presentan a continuación (ver Figuras 5.5 a 5.12).
Figura 5.5 Ventana para Explorar, Actualizar y Crear Registros de Industrias
Figura 5.7 Ventana para el Análisis Estadístico de los caudales y los parámetros de calidad del agua del Río Cauca y Tributarios.
Figura 5.9 Variación de los Parámetros de Calidad del Agua en Función del Caudal.
Figura 5.11 Análisis del aporte promedio de contaminación por Zonas de Interés sobre el río Cauca
Anexo al presente documento se entrega un CD con el instalador de la nueva aplicación desarrollada junto con el manual de usuario de la interfase gráfica, en formato HTML con todas sus ventanas, y un análisis detallado de sus funciones.
CAPITULO 6
6. CONCLUSIONES Y RECOMENDACIONES
6.1. CONCLUSIONES
Del estudio efectuado se puede concluir que laa herramienta desarrollada servirá de soporte para propósitos de pronóstico y control, también servirá como insumo para efecto de calibración del modelo de simulación. La herramienta permite soportar las decisiones para la gestión de la cuenca del Río Cauca, con lo que se ayudará a la CVC en la toma de decisiones para el control de sus usos y permitirá visualizar sus variaciones históricas para el planteamiento de escenarios de restauración y controles en el tiempo para el buen manejo de la cuenca del Río Cauca.
Con la nueva versión del SGBD se apoyará la recopilación, organización y procesamiento de la información de calidad del agua del Río Cauca y sus ríos tributarios, incluyendo los aportes de municipalidades y las descargas de aguas residuales industriales para efectos del cobro de tasas retributivas, análisis estadísticos e insumo para el modelo de simulación. La interfase estará en capacidad de facilitar la información consignada en la base de datos y permitirá una actualización periódica de la información.
La aplicación diseñada permitirá utilizar de manera satisfactoria las herramientas que posee PMC - Calidad de agua, para el uso adecuado y transferencia de la información con lo que se contribuirá en la conservación y manejo integral de los recursos hídricos.
A través de la descripción de los elementos, las características y procedimientos de Calidad de agua expuestos, se podrá conocer los alcances de la aplicación y por lo tanto, obtener un mejor provecho del conjunto de datos históricos de gran valía que posee la corporación.
6.2. RECOMENDACIONES GENERALES
a) Optimizar la totalidad del SGBD disponible en CVC e integrar los diferentes módulos (hidrológicos, sedimentológicos, calidad del agua, etc.), ya que en la actualidad la información se encuentra disgregada en bases de datos distintas. Esto permitirá un manejo integral de toda la información de la cuenca del río Cauca.
b) Conectar el SGBD de CVC con el de otras corporaciones regionales, tales como CRC, CRQ, CARDER, para facilitar el manejo del flujo de información y lograr un control amplio de la cuenca del río Cauca.
c) Presentar algunos de los reportes generados por el SGBD al público en general vía INTERNET.
d) Generar un Módulo adicional en la base de datos con los resultados de MIKE 11 para contrastar resultados y facilitar la calibración del modelo.
e) Conectar el SGBD a un SIG para conocer puntos específicos para generar mapas, videos, etc. f) Realizar un programa de actualización y verificación de datos del SGBD, así como un
BIBLIOGRAFÍA
Solomatine, D. 1992. Software Engineering: An introduction. Lectures notes. Delft IHE. Solomatine, D. 1996. Object-Oriented Programming: A practical Introduction. Lecture notes. Delft: IHE.
Solomatine, D. 1997. Information Technology and Computer Science: An Introduction. Lecture notes. Delft: IHE.
Burch, J., Strater R. Sistemas de Información Teoría y Práctica. Edit. Limusa: México 1981. Oracle 7i. User Manual 1999.
CREATE TABLE ca_actividades(
actividad VARCHAR2(6) NOT NULL,
descripcion VARCHAR2(60) NOT NULL,
ca_ind_cod_industria VARCHAR2(10) NULL,
ca_fnt_cod_fuente VARCHAR2(6) NOT NULL,
ca_prm_ca_prm_id NUMBER(10,0) NULL,
coord_x NUMBER(12,2) NULL,
coord_y NUMBER(12,2) NULL,
KILOMETRAJE NUMBER(12,2) NULL);
REM PROMPT
PROMPT Creating Table CA_ACTUACIONES_JURIDICAS CREATE TABLE ca_actuaciones_juridicas(
ca_ind_cod_industria VARCHAR2(10) NOT NULL;
cod_actuacion NUMBER NOT NULL,
fecha DATE NULL,
descripcion VARCHAR2(1200) NULL,
ca_tac_cod_actuacion VARCHAR2(6) NOT NULL);
REM PROMPT
PROMPT Creating Table CA_CARACTERISTICAS CREATE TABLE ca_caracteristicas(
caracteristica VARCHAR2(6) NOT NULL,
tipo_valor VARCHAR2(1) NOT NULL,
descripcion VARCHAR2(60) NOT NULL);
REM PROMPT
PROMPT Creating Table CA_CARACTERIZACIONES CREATE TABLE ca_caracterizaciones(
ca_sns_cod_sensor VARCHAR2(6) NOT NULL,
ca_mst_numero_pertenece NUMBER(6,0) NOT NULL,
ca_mst_numero NUMBER(6,0) NULL,
valor NUMBER(20,5) NOT NULL,
mascara VARCHAR2(20) NULL,
rango VARCHAR2(1) NULL);
REM PROMPT
PROMPT Creating Table CA_CIIUS CREATE TABLE ca_ciius(
PROMPT Creating Table CA_FUENTES CREATE TABLE ca_fuentes(
cod_fuente VARCHAR2(6) NOT NULL,
descripcion VARCHAR2(60) NOT NULL,
ca_tfn_tipo_fuente VARCHAR2(6) NOT NULL);
REM PROMPT
PROMPT Creating Table CA_HISTORICO_FRS CREATE TABLE ca_historico_frs (
ca_ind_cod_industria VARCHAR2(10) NOT NULL,
mes_ano DATE NOT NULL,
fr_sst NUMBER(5,2) NULL,
fr_dbo NUMBER(5,2) NULL);
REM PROMPT
PROMPT Creating Table CA_INDUSTRIAS CREATE TABLE ca_industrias (
cod_industria VARCHAR2(10) NOT NULL,
ciiu VARCHAR2(10) NULL,
a_a VARCHAR2(10) NULL,
direccion VARCHAR2(100) NULL,
e_mail VARCHAR2(80) NULL,
lugar VARCHAR2(6) NULL,
nic VARCHAR2(25) NULL,
nit VARCHAR2(20) NULL,
nombre VARCHAR2(80) NULL,
num_fax VARCHAR2(20) NULL,
representante VARCHAR2(80) NULL,
telefono VARCHAR2(45) NULL,
coor_x NUMBER(12,2) NULL, coor_y NUMBER(12,2) NULL,
cod_expediente VARCHAR2(15) NULL,
fecha_encuesta DATE NULL,
ca_cii_cod_ciiu VARCHAR2(10) NOT NULL,
gs_lgr_lugar VARCHAR2(6) NOT NULL,
gs_lgr_lugar_ubica VARCHAR2(6) NOT NULL);
REM PROMPT
PROMPT Creating Table CA_MUESTRA CREATE TABLE ca_muestra(
horas_dia_virtiendo VARCHAR2(6) NULL);
REM PROMPT
PROMPT Creating Table CA_PARAMETROS_TASA_RETRIBUTIVA CREATE TABLE ca_parametros_tasa_retributiva(
fecha_norma DATE NOT NULL,
tarifa_dbo NUMBER(6,2) NULL,
tarifa_sst NUMBER(6,2) NULL);
REM PROMPT
PROMPT Creating Table CA_PERMISOS CREATE TABLE ca_permisos(
ca_prm_id NUMBER(10,0) NOT NULL);
REM PROMPT
PROMPT Creating Table CA_SENSORES CREATE TABLE ca_sensores(
cod_sensor VARCHAR2(6) NOT NULL,
nombre VARCHAR2(30) NULL,
descripcion VARCHAR2(60) NULL,
unidades VARCHAR2(20) NULL);
REM PROMPT
PROMPT Creating Table CA_TASAS_INDUSTRIAS CREATE TABLE ca_tasas_industrias(
ca_ind_cod_industria VARCHAR2(10) NOT NULL,
mes_ano DATE NOT NULL,
tasa_dbo NUMBER(10,2) NULL,
tasa_sst NUMBER(10,2) NULL,
ca_ptr_fecha_norma DATE NOT NULL);
REM PROMPT
PROMPT Creating Table CA_TIPOS_ACTUACION CREATE TABLE ca_tipos_actuacion(
PROMPT Creating Table CA_TIPOS_FUENTE CREATE TABLE ca_tipos_fuente(
tipo_fuente VARCHAR2(6) NOT NULL,
descripcion VARCHAR2(60) NOT NULL,
clase VARCHAR2(20) NOT NULL);
REM PROMPT
PROMPT Creating Table CA_VALORES_CARACTERISTICA_INDU CREATE TABLE ca_valores_caracteristica_indu(
ca_cin_caracteristica VARCHAR2(6) NOT NULL,
ca_ind_cod_industria VARCHAR2(10) NOT NULL,
valor_numerico NUMBER(22,0) NULL,
valor_caracter VARCHAR2(30) NULL);
REM PROMPT
PROMPT Creating Table CA_VERTIMIENTOS CREATE TABLE ca_vertimientos();
CD ANEXO
En el CD anexo se encuentra el instalador de la aplicación y el manual de usuario en formato HTM para facilitar su uso.
