Appearance
Bases de datos espaciales
Para que un Sistema Administrador de Bases de Datos (DBMS por sus siglas en inglés) pueda soportar aplicaciones geo espaciales, es necesario extenderlo para que tome en cuenta otros tipos de datos que no son los incorporados.
Sobre estos nuevos tipos de datos se debe definir tanto su estructura, como las operaciones que se pueden ejecutar.
Esquemas de referencia
Un esquema conceptual describe a un nivel abstracto uno o varios temas (capas) necesarios para representar el conjunto de objetos geográficos existentes en una aplicación geográfica, tanto como las relaciones entre ellos.
Unidades administrativas (esquema 1)
Consideramos una jerarquía de particiones en el espacio 2D, que sigue el esquema de unidades administrativas de Estados Unidos. Un país (por ejemplo, Estados Unidos o Alemania) está formado por estados, y un estado, a su vez, está formado por condados. Existen subdivisiones más finas del espacio, como la división en subcondados en Estados Unidos, definida por la Oficina del Censo.
Sin embargo, estas subdivisiones más finas del plano no nos conciernen aquí. Para simplificar las cosas, un país tiene como atributos un nombre y una geometría. Un estado también tiene un nombre y una geometría. Un condado tiene como atributos un nombre, una población y una geometría. Los países, estados y condados se identifican de forma única por su código administrativo.
Estos tres temas se resumen en la Figura 3.1. El símbolo en forma de diamante entre dos tipos de entidad expresa una relación de agregación (por ejemplo, un Estado está formado por Condados). El símbolo del círculo sólido se utiliza para denotar una relación de uno a muchos.
Red de carreteras entre ciudades (esquema 2)
El segundo esquema que consideramos, independientemente del esquema 1, es una simple red de carreteras entre ciudades. En este esquema se definen tres temas. Una entidad de autopista tiene un nombre y un tipo (como autopista de EE.UU., autopista estatal o interestatal), y consta de tramos, cada uno de los cuales tiene un nombre, un número determinado de carriles y una parte geométrica. Las autopistas y los tramos se identifican mediante un código. Un tramo puede ser compartido por varias autopistas; de ahí la relación de muchos a muchos. Los tramos de las autopistas conectan las ciudades entre sí. Esto se resume en la figura 3.2. Obsérvese el uso de las asociaciones con nombre starts-at y ends-at entre las entidades Section y City. Un tramo comienza en una ciudad determinada y termina en otra. A través de estos dos tipos de relación, una autopista conecta muchas ciudades entre sí, y las ciudades están conectadas por muchas autopistas (relación de muchos a muchos).
Uso del suelo (esquema 3)
Por último, el tercer esquema de interés tiene un solo tema: el uso del suelo. Dentro de este tema, una zona concreta del plano se asocia a un tipo de uso, como vivienda, zona agrícola y bosque. Dicha área está representada por un objeto geométrico 2D (región).
Modelo relacional extendido con ADT
En los sistemas relacionales extendidos, los usuarios finales manipulan valores cuyos tipos son básicos, como los enteros o los reales, pero también tipos de datos abstractos accesibles mediante las operaciones definidas sobre ellos. Para representar y consultar nuestra aplicación geográfica de referencia con un sistema relacional de este tipo, ahora consideramos los tipos de datos abstractos espaciales definidos en la sección anterior.
Representación de los esquemas de referencia
El esquema conceptual presentado en la sección anterior puede ser fácilmente traducirse a un esquema relacional. Cada tipo de entidad corresponde a una relación cuyos atributos son los de la entidad considerada. También hay que tener en cuenta los vínculos de composición entre las entidades, como el hecho de que un estado pertenezca a un país o un tramo a una carretera. Para ello, el tema compuesto (por ejemplo, País) se menciona en el componente (por ejemplo, Estado) mediante una clave externa. La clave de País se convierte en un atributo9 de Estado. Este mecanismo es estándar en los esquemas relacionales, y el lenguaje de definición de datos (DDL) SQL2, utilizado en lo sucesivo, proporciona una cláusula específica (Foreign Key) para declarar que uno o varios atributos hacen referencia a una tupla de otra relación.
Unidades administrativas (Esquema 1)
En el esquema relacional que sigue, la referencia a un país se hace en una relación de Estado. El mismo razonamiento se aplica a los estados y condados. Esto nos lleva a las relaciones siguientes. Para cada relación, proporcionamos su nombre y su lista de atributos (nombre y tipo de atributo).
sql
Create Table Country
(country_code integer,
country_name varchar (30),
geometry region,
Primary Key (country_code))
Create Table State
(state_code integer,
state_name varchar (30),
country_code varchar (30),
geometry region,
Primary Key (state_code),
Foreign Key (country_code) References Country)
Create Table County
(county_code integer
county_name varchar (30),
state_code varchar (30),
population integer,
geometry region,
Primary Key (county_code),
Foreign Key (state_code) References State)Create Table Country
(country_code integer,
country_name varchar (30),
geometry region,
Primary Key (country_code))
Create Table State
(state_code integer,
state_name varchar (30),
country_code varchar (30),
geometry region,
Primary Key (state_code),
Foreign Key (country_code) References Country)
Create Table County
(county_code integer
county_name varchar (30),
state_code varchar (30),
population integer,
geometry region,
Primary Key (county_code),
Foreign Key (state_code) References State)Obsérvese que, de forma similar al esquema proporcionado en la sección anterior, el atributo espacial aparece en todos los niveles; es decir, la geometría del atributo está en las relaciones País, Estado y Condado. La geometría podría haber aparecido sólo en el nivel más bajo de la jerarquía administrativa, y luego propagarse a los niveles superiores, dada la partición del plano en todos los niveles administrativos. Sin embargo, aunque los objetos base, como los condados, forman una partición, calcular la geometría de un estado a partir de la unión de la geometría de todos los condados resulta extremadamente costoso. Además, se supone que estas geometrías no cambian con el tiempo, o lo hacen raramente, por lo que es ciertamente más eficiente en términos de tiempo computarlas una sola vez.
La elección de representar tales atributos (o no) en todos los niveles depende de su uso en una aplicación determinada. Por otro lado, un atributo como la población se calcula fácilmente a partir de objetos base (condados). Por ello, hemos optado por tener un atributo de población sólo a nivel de condado, y no a nivel de país o de estado. A veces, los atributos constituyen una clave externa, es decir, una clave para otra relación. Se utilizan para mantener la integridad referencial. Esto significa, en particular, que si hacen referencia a una tupla de otra relación, esta tupla debe existir. La única diferencia entre este esquema y un esquema relacional puro es la existencia de un tipo de dato abstracto espacial región, para representar la parte geométrica de un país, un estado y un condado.
Red de carreteras y ciudades (Esquema 2)
Utilizando el mismo principio, podemos definir un esquema sobre redes de carreteras. La geometría de una autopista, una polilínea, no aparece en el esquema Autopista relación. De hecho, a diferencia de las unidades administrativas comentadas anteriormente, sólo aparece a nivel de tramo de autopista. La geometría de una autopista se obtiene aplicando la unión geométrica a todos los tramos que la constituyen. Así, se evita la redundancia del esquema anterior. La razón principal para no almacenar la geometría a nivel de autopista es la relativa frecuencia de cambio en la geometría de los tramos de autopista.
Existe una relación de muchos a muchos entre las autopistas y sus tramos, lo que significa que una autopista tiene muchos tramos y que un tramo puede ser compartido por muchas autopistas. Para expresar esto en el modelo relacional, utilizamos tres relaciones: (1) Highway representa una autopista con información básica, (2) Section representa un tramo de autopista, y (3) HighwaySection hace la correspondencia entre una sección y una autopista. La existencia de las tres relaciones permite eliminar las redundancias que existirían si sólo estuvieran presentes dos relaciones (por ejemplo, Autopista y Tramo). Dado que una sección puede pertenecer a muchas autopistas, y que el orden de las secciones puede ser útil de considerar, la relación AutopistaSección mantiene un registro del número de sección para una autopista en particular. La relación Inicio y Fin entre Sección y Ciudad se expresa mediante la introducción de Inicio Ciudad y Fin Ciudad, respectivamente.
Independientemente, la parte geométrica de una ciudad aparece en la relación Ciudad como una región. Suponemos que el nombre de la ciudad es un atributo clave de la relación Ciudad. Consideremos el siguiente esquema.
sql
Create Table Highway
(highway_code integer,
highway_name varchar (4),
highway_type varchar (2),
Primary Key (highway_code))
Create Table HighwaySection
(section_code integer,
section_number integer,
highway_code integer,
Primary Key (section_code,highway_code),
Foreign Key (section_code) References Section,
Foreign Key (highway_code) References Highway)
Create Table Section
(section_code integer,
section_name varchar (4),
number_lanes integer,
city_start varchar (30),
city_end varchar (30),
geometry line,
Primary Key (section_code),
Foreign Key (city_start) References City,
Foreign Key (city_end) References City)
Create Table City
(city_name varchar (30),
population integer,
geometry region,
Primary Key (city_name))Create Table Highway
(highway_code integer,
highway_name varchar (4),
highway_type varchar (2),
Primary Key (highway_code))
Create Table HighwaySection
(section_code integer,
section_number integer,
highway_code integer,
Primary Key (section_code,highway_code),
Foreign Key (section_code) References Section,
Foreign Key (highway_code) References Highway)
Create Table Section
(section_code integer,
section_name varchar (4),
number_lanes integer,
city_start varchar (30),
city_end varchar (30),
geometry line,
Primary Key (section_code),
Foreign Key (city_start) References City,
Foreign Key (city_end) References City)
Create Table City
(city_name varchar (30),
population integer,
geometry region,
Primary Key (city_name))Uso del suelo (Esquema 3)
La única relación que hay que tener en cuenta es la del uso del suelo, como se muestra a continuación.
sql
Create Table Land Use
(region_name varchar (30),
land_use_type varchar (30),
geometry region,
Primary Key (region_name))Create Table Land Use
(region_name varchar (30),
land_use_type varchar (30),
geometry region,
Primary Key (region_name))Consultas de referencia
Esta sección explora un conjunto de consultas representativas planteadas contra una base de datos espacial basada en los esquemas introducidos anteriormente. Algunas consultas son sencillas y sólo implican la descripción de objetos geográficos.
Otras consultas son más complejas y más difíciles de manejar en un SGBD, ya que requieren la existencia de operaciones espaciales (por ejemplo, intersección, diferencia o adyacencia). Estas consultas se estudian con más detalle en este capítulo, según los diferentes modelos de datos y lenguajes de consulta del SGBD.
Enumeramos las consultas de referencia según la siguiente clasificación: (1) consultas con criterios alfanuméricos, (2) consultas con un criterio espacial (es decir, una operación que se aplica a la parte espacial de uno o varios objetos geográficos), y (3) consultas interactivas, que requieren la participación del usuario final (por ejemplo, para seleccionar una zona concreta dibujándola en un dispositivo de visualización mediante un ratón).
Cada consulta se escribe como una cláusula SQL "select from where". La palabra clave select va seguida de uno o varios atributos que pertenecen a la(s) relación(es) a considerar, o de una operación definida sobre los ADT espaciales; from va seguido del nombre de esta(s) relación(es). La palabra clave where indica las condiciones de selección de las tuplas.
Consultas con criterio alfanumérico
- Número de habitantes en el Condado de San Francisco
Se trata de una selección/proyección relacional. La única relación que se considera es la de Condado. Las tuplas de la relación County se seleccionan de forma que su valor para el atributo nombre del condado sea "San Francisco".
sql
select population
from County
where county_name = ‘San Francisco’select population
from County
where county_name = ‘San Francisco’- Lista de los condados del Estado de California
En primer lugar, hay que listar todos los condados cuyo nombre de estado sea California. Para ello, se realiza un join entre las relaciones Condado y Estado, restringido a la tupla tal que el nombre del estado es "California". Por último, se realiza una proyección sobre el atributo nombre del condado. El atributo para la unión es el código del estado.
sql
select county_name
from County, State
from State.state_code = County.state_code
and state_name = ‘California’select county_name
from County, State
from State.state_code = County.state_code
and state_name = ‘California’Se trata de dos relaciones que comparten un atributo con el mismo nombre, código de estado. Para indicar a qué atributo se refiere, SQL nos permite anteponer el nombre de la relación. Así, State.state_code se refiere al atributo state_code de la relación State. Cuando no hay ambigüedad, no es necesario anteponer un atributo.
Una forma alternativa común de la consulta utiliza los alias de los nombres de las relaciones. En la cláusula from, la expresión R como A permite utilizar A como sinónimo de la relación R en cualquier parte de la consulta. Como ya se ha dicho, este prefijo no es obligatorio cuando no hay ambigüedad.
sql
select county name
from County as c, State as s
where s.state_code = c.state_code
and state_name = ‘California’select county name
from County as c, State as s
where s.state_code = c.state_code
and state_name = ‘California’Esto es especialmente útil cuando una consulta implica dos o más tuplas de la misma relación. A continuación, no utilizamos la palabra clave as, que es opcional en el estándar de SQL2.
- Número de habitantes en los Estados Unidos
Como no se puede acceder directamente a la población de un país, para responder a esta consulta, la población de un país se calcula sumando la población de todos sus condados (obtenida a través de los estados que pertenecen a un país). El join entre Condado y Estado se realiza como en la consulta anterior. Se necesita un segundo join entre País y Estado. La población total se calcula aplicando la función agregada suma a todos los valores de población procedentes de la relación Condado.
sql
select sum (c2.population)
from Country c1, State s, County c2
where c1.country_name = ‘USA’
and s.state_code = c2.state_code
and c1.country_code = s.country_codeselect sum (c2.population)
from Country c1, State s, County c2
where c1.country_name = ‘USA’
and s.state_code = c2.state_code
and c1.country_code = s.country_code- Número de carriles en la primera sección de la Interestatal 99
Las tres relaciones a considerar para expresar esta consulta son AutopistaSección, Autopista y Sección. Las dos uniones entre las relaciones (1) Autopista y AutopistaSección y (2) AutopistaSección y Sección se realizan de forma que el nombre de la autopista es I99 y el número de sección de esta autopista es 1. Por último, se realiza la proyección sobre el atributo número de carriles procedente de la relación Sección.
sql
select s.number_lanes
from HighwaySection h1, Highway h2, Section s
where h2.highway_code = h1.highway_code
and h1.section_code = s.section_code
and h2.highway_name = ‘I99’
and h1.section_number = 1select s.number_lanes
from HighwaySection h1, Highway h2, Section s
where h2.highway_code = h1.highway_code
and h1.section_code = s.section_code
and h2.highway_name = ‘I99’
and h1.section_number = 1- Nombre de todas las secciones que constituyen la Interestatal 99
Hay que recuperar todos los tramos que constituyen la autopista con nombre I99. Para ello, se realiza la unión entre Highway, HighwaySection y Section se realiza de forma que la autopista considerada sea I99.
sql
select section_name
from HighwaySection h1, Highway h2, Section s
where h2.highway name = ‘I99’
and h2.highway_code = h1.highway_code
and h1.section_code = s.section_codeselect section_name
from HighwaySection h1, Highway h2, Section s
where h2.highway name = ‘I99’
and h2.highway_code = h1.highway_code
and h1.section_code = s.section_codeConsultas con criterio espacial
Con base en los esquemas de referencia anteriores se pueden plantear una serie de consultas que utilizan criterios espaciales para realizar su procesamiento. A diferencia de las consultas anteriores, las consultas de esta categoría implican funciones y predicados definidos sobre ADTs espaciales. Los predicados se utilizan como criterios de selección (cláusula where en SQL). Las funciones espaciales pueden aplicarse a las tuplas de una relación resultante (cláusula select), exactamente igual que las funciones agregadas. También pueden utilizarse como argumentos de un predicado (cláusula where).
- Condados adyacentes al condado de San Francisco, en el mismo estado
Como en este caso hay que realizar un inner join entre Condado y sí mismo, es obligatorio utilizar alias. Se utilizan dos variables para denotar las dos tuplas de la relación County que hay que considerar. County c1 denota una tupla de la primera, y c2 representa el condado de San Francisco (c2.county_name = 'San Francisco'). Los condados c1 que están en el mismo condado que San Francisco (esto se verifica mediante las dos primeras condiciones de la cláusula where) se mantienen en el resultado sólo si son adyacentes al condado de San Francisco, lo que se averigua mediante la prueba de adyacencia Meets (c1.geometría, c2.geometría).
sql
select c1.county name
from County c1, County c2
where c2.county_name = ‘San Francisco’
and c1.state_code = c2.state_code
and Meets (c1.geometry, c2.geometry)select c1.county name
from County c1, County c2
where c2.county_name = ‘San Francisco’
and c1.state_code = c2.state_code
and Meets (c1.geometry, c2.geometry)- Condados mayores que el mayor condado de California.
En la cláusula select anidada, se seleccionan todos los condados de California. Se calcula el tamaño de su superficie (función espacial Area) y se determina la mayor (función agregada SQL max). Por último, la cláusula externa comprueba el tamaño de la superficie de todos los condados y devuelve aquellos cuya superficie es mayor que la seleccionada en la cláusula interna.
sql
select county_name
from County
where Area (County.geometry) >
(select max (Area (c.geometry)) from County c, State s
where s.state_code = c.state_code
and s.state_name = ‘California’)select county_name
from County
where Area (County.geometry) >
(select max (Area (c.geometry)) from County c, State s
where s.state_code = c.state_code
and s.state_name = ‘California’)- Extensión de la Interestatal 99
En cada sección de la Autopista I99, se aplica la función Longitud definida en el tipo Línea. De nuevo, hay una unión entre las relaciones Autopista, Autopista-Sección y Sección. Sobre la lista de valores (longitud de los distintos tramos) se aplica el operador SQL sum, que calcula la suma.
sql
select sum (Length (s.geometry))
from Highway h1, HighwaySection h2, Section s
where h1.highway_name = ‘I99’
and h1.highway_code = h2.highway_code
and h2.section_code = s.section_codeselect sum (Length (s.geometry))
from Highway h1, HighwaySection h2, Section s
where h1.highway_name = ‘I99’
and h1.highway_code = h2.highway_code
and h2.section_code = s.section_code- Todas las carreteras que pasan a través del Estado de California.
Hay que devolver todos los tramos que cruzan el estado de California (predicado espacial OverlapsLR aplicado sobre la geometría de un tramo y la geometría de un estado). Se devuelve el nombre de la autopista a la que pertenecen devuelto. Nótese la eliminación de duplicados con el uso de distinct.
sql
select distinct h1.highway_name
from State s1, Highway h1, HighwaySection h2, Section s2
where s1.state_name = ‘California’
and h1.highway_code = h2.highway_code
and h2.section_code = s2.section_code
and OverlapsLR (s2.geometry, s1.geometry)select distinct h1.highway_name
from State s1, Highway h1, HighwaySection h2, Section s2
where s1.state_name = ‘California’
and h1.highway_code = h2.highway_code
and h2.section_code = s2.section_code
and OverlapsLR (s2.geometry, s1.geometry)- Desplegar todas las áreas residenciales en el condado de San José
Hacemos una selección tanto de las zonas residenciales en la relación Uso del suelo como del condado de San José a partir de la relación Condado. Sólo se retienen las zonas residenciales cuya geometría se cruza con la del condado de San José (predicado Overlaps definido en el tipo región). Se calcula el área que está exactamente dentro del condado de San José (operación de intersección definida en la región ADT). Esta consulta puede simplificarse eliminando la prueba de intersección espacial, que se supone que se realiza cuando se calcula la propia intersección (cláusula select).
sql
select Intersection (l.geometry, c.geometry)
from County c, Land_Use l
where c.county_name = ‘San Jose’
and l.land_use_type = ‘residential area’
and Overlaps (l.geometry, c.geometry)select Intersection (l.geometry, c.geometry)
from County c, Land_Use l
where c.county_name = ‘San Jose’
and l.land_use_type = ‘residential area’
and Overlaps (l.geometry, c.geometry)- Traslape de los temas de división administrativa y uso de la tierra
Esta consulta corresponde a una operación de superposición de mapas (temas), que construye una nueva relación cuyo esquema se crea a partir de (1) el conjunto de atributos descriptivos de las dos relaciones consideradas, Condado y Uso del suelo, y (2) un atributo espacial que procede de la intersección de los dos conjuntos de regiones. Cada tupla de esta relación corresponde a la intersección entre una parcela y un condado. Su descripción se construye a partir de la del condado y la de la parcela. Obsérvese que, en aras de la simplicidad, no hemos mantenido todos los atributos descriptivos de las relaciones originales en la expresión de la consulta anterior.
sql
select county_name, land_use_type,
Intersection (c.geometry, l.geometry)
from County c, Land_Use l
where Overlaps (c.geometry, l.geometry)select county_name, land_use_type,
Intersection (c.geometry, l.geometry)
from County c, Land_Use l
where Overlaps (c.geometry, l.geometry)Referencia
- Tomado del capítulo 3 del libro "Spatial Databases with Applications to GIS" de Philippe Rigaux, Michel Scholl y Agnes Voisard.