Consulta a Banco de Datos

Esta página presenta una visión general de bancos de datos relacional (SGDB), con énfasis en lo referente a la ligación entre el SPRING y un gerenciador de bancos de datos relacionales. Son presentados también los mecanismos de consulta a objetos catastrales disponibles en el SPRING.

En esta versión del SPRING está disponible solamente la conexión con el CODEBASE, donde todas las tablas son padrones DBF. A pesar de algunas limitaciones aún no superadas, las tablas (*.dbf) del SPRING pueden ser manipuladas por cualquier otro aplicativo que las leen como DBase4, Clipper, Microsoft Access, etc. Para entender las aplicaciones de crear una tabla para cada categoría de datos del sistema, así como para cada objeto, el usuario debe estar familiarizado con el modelo de datos del SPRING.

Consulte también:
Programación en LEGAL
Análisis Geográfico en el SPRING.
Como obtener informaciones conceptuales del sistema.
¿Cómo definir la Visual de una Categoría o Clase temática?
¿Cómo definir los Atributos de una Categoría o Clase temática?
Acerca el Esquema Conceptual del SPRING


Otras opciones de análisis geográfico en el Spring



Bancos de Datos Relacionales

La idea de bancos de datos relacionales fue presentada por la primera vez por Codd, investigador de IBM en 1972. Codd partió de la noción matemática de relación. Con una visión intuitiva, se puede entender una relación como un conjunto de atributos asociados a una entidad del mundo real. Por ejemplo, para describir un "catastro urbano" se puede utilizar la relación:

<número_lote, dueño, dirección, área, impuesto territorial >

Una relación puede ser representada a través de una tabla. Así, por ejemplo, la tabla qu sigue presenta la relación "catastro urbano" con sus atributos y ejemplos de valores para estos atributos.

Ejemplo de Atributos para "Catastro Urbano"
Num_lote
dueño
dirección
área (m2)
IPTU (R$)
195689Guimaraes, M.
Clóvis Bevilacua, 768
900
350

Codd propuso inclusive, un conjunto de operaciones sobre relaciones, por él llamado "álgebra relacional", que incluía las operaciones de proyección, selección, unión, intersección y producto cartesiano. Mostró también que estas operaciones eran cerradas, esto quiere decir, que la aplicación de una operación de esta álgebra a una relación, genera siempre otra relación.

El modelo relacional se mostró bastante útil para lidiar con los problemas de bancos de datos en aplicaciones administrativas y comerciales, siendo hoy la tecnología más difundida en el área. Su formulación rigurosa permitió la definición de un lenguaje de consulta patronizada (SQL).

En el ambiente PC, la mayor parte de los gerenciadores también siguen el padrón relacional, inclusive los sistemas DBASE y ACCESS.



Consulta a Banco de Datos - Índice



Modelo de Datos Geo-Relacional

La forma usual de ligación entre un sistema de información geográfica y un banco de datos relacional es a través de un SGBDR (Sistema Gerenciador de Banco de Datos Relacional) - llamado modelo "geo-relacional": los componentes espacial y descritivo del objeto geográfico son almacenados separadamente. Los atributos convencionales son guardados en el banco de datos (en forma de tablas) y los datos espaciales son tratados por un sistema dedicado. La conexión es hecha por identificadores (id) de objetos.

Para recuperar un objeto, los dos subsistemas deben ser investigados y la respuesta es una composición de resultados. Esta arquitectura es ilustrada en la figura que sigue.



Figura - Modelo de datos geo-relacional.

Consulta al Banco de Datos - Índice



SGBD Relacionales y el SPRING

El SPRING fue concebido como un banco de datos geográfico y proyectado desde el inicio para operar eficientemente en conjunto con un sistema gerenciador de bancos de datos (SGBD). Así, utiliza el modelo de datos geo-relacional descrito en la sección anterior.

En nuestra definición, un banco de datos geográfico es el depósito de datos de un SIG, que almacena y recupera datos geográficos en sus diferentes geometrías (imágenes, vectores, retículas), así como también, las informaciones descriptivas (atributos no espaciales) que son almacenadas en tablas en el caso de SGBD relacionales.

Así, en el SPRING todas las informaciones descriptivas sobre los datos geográficos son guardadas en tablas del SGBD relacional asociadas al sistema. En la versión 3.0, están disponibles solamente los sistemas gerenciadores de bancos de datos CODEBASE - gerenciador compatible con el DBASE IV, que viene incluido en la versión básica del sistema.

Se encuentra en desarrollo la conexión con:


Los gerenciadores ORACLE e INGRES deberán ser adquiridos separadamente por el usuario. El uso del SGBD es controlado a partir de la variable ambiental SpringDBMS, que en la instalación actual usa como default el CODEBASE.


Consulta al Banco de Datos - Índice



Atributos de Geo-Campos y de Geo-Objetos

En el SPRING, cada categoría de datos geográficos está asociada a una tabla que contiene los atributos descriptivos del tipo de dato. Cada geo-objeto y geo-campo recibe un identificador único (llamado "geoid") que es mantenido automáticamente por el sistema y no debe ser modificado por el usuario.

El SPRING utiliza el SGBD relacional (definido a través de la variable ambiental SpringDBMS) para almacenar todos los atributos descriptivos de los datos geográficos, bien como todas las tablas auxiliares del sistema. De este modo, todas estas informaciones son visibles externamente, a través del uso del SGDB correspondiente.

Consulta al Banco de Datos - Índice



Entrada de Atributos de Datos Geográficos

La definición de atributos de datos geográficos es descrita en detalle en el Atributos... asociado al comando Esquema Conceptual... localizado en el ítem del menú Archivo permite la entrada de los atributos de la relación (tabla) asociada.

En el caso de categorías que sean especializaciones de MAPA TEMÁTICO, cada clase temática ( también llamada de geo-clase) puede tener asociada una relación (tabla).

Para incluir una tabla externa (ya existente) en el banco de datos del SPRING, el usuario podrá crear una categoría de datos no-espacial y asociar a esta categoría la tabla externa ya disponible (OBS: la función de relacionamiento con tablas externas se encuentra en desarrollo).

Los siguientes ejemplos ilustran la asociación de atributos a geo-campos y geo-objetos en el SPRING.

OBS: Solamente la asociación con objetos catastrales está implementada en la versión actual del SPRING.



Atributos de Geo-Objetos en el SPRING

En el SPRING, los geo-objetos son definidos de forma independiente a su representación gráfica. Para establecer la ligación entre los geo-objetos y sus representaciones (en el ejemplo, entre lotes y sus localizaciones en un mapa de lotes) es preciso seguir los siguientes pasos:



Figura - Asociación de geo-objetos a representaciones geométricas.


NOTA: Vea a continuación como consultar objetos catastrales a partir de los atributos definidos por el usuario.

Consulta al Banco de Datos - Índice



Consulta a objetos catastrales

Los recursos de visualización de mapas en general en el SPRING son accesados a través del "Panel de Control" (vea detalles de como operar), el cual posee un buen control para la exhibición de imágenes, mapas temáticos y modelos numéricos de terrenos. No obstante, cuando se trata de objetos catastrales, el "Panel de Control" solamente tiene control para seleccionar y presentar todas las categorías de objetos (sin restricción por consulta) pertenecientes a un plano de información de la categoría catastral.

Utilizando el "Panel de Control", el usuario podrá sólo definir cual PI será consultado, independiente de si el mapa catastral tiene sus entidades (puntos, líneas o polígonos) asociadas a solamente una categoría de objetos (por ejemplo, Lotes urbanos) o a diferentes categorías de objetos (por ejemplo, especificar los lotes urbanos en categorías como: Escuelas, Hospitales y Centros Comerciales), en este último caso la elección de cual categoría será consultada vendrá posteriormente.

Los recursos de consulta a objetos catastrales en el SPRING va más allá de una simple presentación de categorías de objetos. Una categoría de objetos es constituida por varios objetos geográficos (o geo-objetos) del mismo tipo. Según Goodchild (1992), un geo-objeto es individualizable y tiene identificación con el mundo real, lo que posibilita, la manipulación individual de este tipo de dato.

Entretanto, manipular una tabla con todos los geo-objetos de un PI catastral se puede tornar lento en función del volumen de datos, así fue creado el concepto de colección de objetos. Una colección permite extraer de la tabla de objetos solamente los de interés para el usuario, creando una tabla auxiliar. Como ejemplo, el usuario puede pedir para el sistema crear una colección de los polígonos de Lotes, que tengan valores de IPTU mayores que 1500, y a partir de ese nuevo universo de objetos, hacer otras consultas, análisis por agrupación, etc.


IMPORTANTE: El usuario debe saber como estructurar su mapa catastral, no debe olvidar que varias categorías de objetos pueden estar visibles en la pantalla de su computador, pero siempre estará consultando sobre una única categoría.


Un mapa catastral puede estar organizado de varias maneras, vea algunos ejemplos a continuación:

EJEMPLO 1

Mapa Catastral con un único tipo (categoría) de objeto y cada entidad (punto, línea o polígono) asociada a solamente un único identificador (rótulo/nombre) de esa categoría, por ejemplo, un mapa de haciendas en donde cada polígono tiene un único identificador (FZ001/Hac. Santa María) y sus atributos (Propietario: Antonio, Valor del inmueble: 2.344.000, Área plantada: 234 ha, etc.);

cons_exe01.gif - 10756 Bytes

NOTA: En este ejemplo solamente el objeto Haciendas estará disponible para ser consultado y los atributos de cada polígono estarán en una única tabla asociada a este objeto.


EJEMPLO 2

Mapa Catastral con un único tipo (categoría) de objeto y cada entidad (punto, línea o polígono) asociada a varios identificadores (rótulos/nombres) de esa categoría, por ejemplo, un mapa de cuadras urbanas en donde cada polígono tiene varios identificadores, siendo cada uno asociado a un lote. En este caso los lotes no tienen representación gráfica individual, se sabe solamente que estos están dentro de una determinada cuadra.

cons_exe02.gif - 12095 Bytes

NOTA: En este ejemplo solamente el objeto Lotes estará disponible para ser consultado y los atributos de cada polígono (cuadra) estarán en una única tabla asociada a este objeto. Al hacer clic sobre el polígono, el sistema muestra todos los identificadores asociados a este polígono.


EJEMPLO 3

Mapa Catastral con varios tipos (categorías) de objetos y cada entidad (punto, línea o polígono) asociada a un único identificador (rótulos/nombres) de esas categorías, por ejemplo, un mapa de lotes urbanos donde cada polígono tiene un único identificador para cada tipo de objeto, o sea, Hospital, Residencia, Hotel, etc. En este caso cada lote tiene su representación gráfica individual.

cons_exe03.gif - 11840 Bytes

NOTA: En este ejemplo solamente un tipo de objeto Hospital, Residencia u Hotel estará disponible para ser consultado por vez y los atributos de cada polígono estarán disponibles solamente si la categoría del referido objeto es seleccionada.


EJEMPLO 4

Mapa Catastral con varios tipos (categorías) de objetos y cada entidad (punto, línea o polígono) asociada a un o más identificadores (rótulos/nombres) de esas categorías, por ejemplo, un mapa de lotes urbanos en donde cada polígono tiene un único identificador para el objeto Lote y un grupo de polígonos asociados a otro identificador de otro tipo de objeto, Cuadras o un Barrio. En este caso cada Lote tiene su representación gráfica individual, pero una Cuadra o Barrio serían representados por varios polígonos.

cons_exe04.gif - 15669 Bytes

NOTA: En este ejemplo solamente un tipo de objeto (Lote, Cuadra o Barrio) estará disponible para ser consultado por vez y los atributos de cada polígono estarán disponibles solamente si la categoría del referido objeto fuera seleccionada. Se debe verificar también el orden de visualización, pues un objeto puede enmascarar a otro (vea como definir el orden de presentación de los objetos).


Módulos de Consulta de los Objetos

Las funciones de consultas sobre un mapa catastral se inician con una selección en el Colección de Objetos y unControl de Visualización. A partir del Control de Visualización el usuario tendrá acceso a los módulos de Consulta, Agrupamiento y Tabla. Con los objetos en la pantalla de visualización el usuario puede consultar el módulo Atributos/Foto/URL y en el módulo Tabla se puede guardar el contenido de la misma. La figura siguiente muestra la relación entre esos módulos.



La figura de arriba muestra que existe una secuencia que debe ser seguida y una dependencia entre los módulos de consulta. A continuación se describe como el usuario debe proceder:

  1. En el "Panel de Control" el usuario debe definir cuales serán los PI's a ser presentados en el área de visualización y especialmente cual es el PI catastral a ser consultado;
  2. Sobre el PI catastral escogido se debe definir cuales objetos de una categoría serán consultados, o sea, se debe definir una Colección de Objetos, o si se prefiere, se puede trabajar con todos los objetos presentes en el mapa (opción TODO);
  3. En el módulo de Control de Visualización está la función de comandar la visualización de las categorías de objetos, a menos que una colección sea definida y en este caso, solamente una única categoría será presentada. Básicamente, se controla cómo y cuáles objetos serán visualizados. Además de estos controles, este módulo es responsable por el control de exhibición de leyendas y por el control de ordenamiento de la secuencia de presentación gráfica, como también, en la determinación de cual categoría de objetos debe ser consultada, agrupada o visualizada en forma de tabla. El módulo también determina cual categoría de objetos está activa para ser indicada y analizada sobre la pantalla.
  4. Los módulos de Consulta, Agrupamiento y Tabla modifican la forma de presentación gráfica; luego, un flujo de operaciones debe ser definido antes de que los datos sean exhibidos gráficamente. Este flujo de operaciones es importante porque el resultado final de la presentación dependerá de esa secuencia de operaciones.


Vea mayores detalles de como operar módulos.



Consulta al Banco de Datos - Índice