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.
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.
195689 | Guimaraes, M. |
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.
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.
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:
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.
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.
satélite | sensor | fecha_pas | órbita | punto | corrección | |
001 | LANDSAT5 | 25/01/86 | ||||
002 | LANDSAT3 | 19/06/82 |
En este caso, el especialista en suelos puede querer asociar a cada mapa los datos de su adquisición, como por ejemplo: fecha del levantamiento, responsable, Institución, como lo ilustra la tabla que sigue.
fecha_levantamiento | responsable | Institución | |
001 | 29/05/85 | Damian Carneiro | FUNCEME |
Nótese que esta tabla se aplica a los mapas de la categoría MapaSuelos. Dicha tabla debe ser usada para almacenar informaciones relativas a los mapas referidas a las entidades espaciales. El SPRING también permite asociar tablas a las clases asociadas a un mapa temático. Se puede tener una única tabla para todas las clases.
En el ejemplo de suelos, se puede querer determinar propiedades comunes a todas las clases temáticas, como ser: ph, tenor de aluminio, nitrógeno, potasio y humedad. La tabla que sigue, muestra un ejemplo de atributos para las clases asociadas a la categoría MapaSuelos.
humedad | ph | tenor_Al | tenor_K | ||
latosol |
En el caso de los lotes, la información asociada podría ser: número del catastro en la prefectura, nombre del propietario, dirección, área construida, valor del impuesto territorial - IPTU (vea la tabla a continuación). Como se trata de un geo-objeto (que posee la localización geográfica), el SPRING automáticamente asocia a cada entrada de la tabla un identificador único para cada objeto geográfico.
195689 | Guimaraes, M. |
Para los elementos de la categoría MapaLotes,
los atributos típicos serían las características del mapa, como: número del mapa, región de la ciudad, escala del mapa, fecha del levantamiento, empresa responsable, como se ilustra en la tabla que sigue.
Jardín Esplanada |
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:
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.);
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.
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.
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.
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).
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:
Vea mayores detalles de como operar módulos.