faculdade farias brito ciÊncia da...
TRANSCRIPT
FACULDADE FARIAS BRITO
CIÊNCIA DA COMPUTAÇÃO
CICERO ROBSON BARROS FEITOSA
MANIPULAÇÃO DE INFORMAÇÕES GEOGRÁFICAS EM UM BANCO DE DADOS ESPACIAL
Fortaleza
2013
CICERO ROBSON BARROS FEITOSA
MANIPULAÇÃO DE INFORMAÇÕES GEOGRÁFICAS EM UM BANCO DE DADOS ESPACIAL
Monografia apresentada para obtenção dos créditos da disciplina Trabalho de Conclusão de Curso da Faculdade Farias Brito, como parte das exigências para graduação no Curso de Ciência da Computação.
Orientador: MSc. Ricardo Wagner Cavalcante Brito.
Fortaleza
2013
F142m Feitosa, Cícero Robson Barros Manipulação de informações geográficas em um banco de dados espacial / Cícero Robson Barros Feitosa 65 f. : il. : color. Monografia (Graduação) – Faculdade Farias Brito, Fortaleza, 2013. Orientador: Prof. Msc. Ricardo Wagner Cavalcante Brito
1. Espacial. 2. Geometria. I. Brito, Ricardo Wagner Cavalcante. (orient.) II. Faculdade Farias Brito. Graduação em Ciência da Computação. III. Título.
CDD 005
MANIPULAÇÃO DE INFORMAÇÕES GEOGRÁFICAS EM UM BANCO DE DADOS ESPACIAL
Cicero Robson Barros Feitosa
PARECER ____________________________
NOTA: FINAL (0-10): ______
Data: ____/____/_______
BANCA EXAMINADORA
______________________________
Prof. Msc. Ricardo Wagner Cavalcante Brito (Orientador)
______________________________
Prof. Dr. Daniel de Matos Alves (Examinador)
______________________________
Prof. Msc. Murilo Eduardo Ybanez Nascimento (Examinador)
AGRADECIMENTOS
Agradeço primeiramente a Deus por esta conquista, por iluminar-me e guiar-me ao
longo desta jornada no Curso de Ciência da Computação.
Aos meus pais, Geralda e Januário, minha avó Edite e meu tio-avô Damião, que me
apoiaram neste percurso e, que sem Deus e eles não teria sido possível alcançar esta
conquista.
À minha irmã Rejane pelo seu incentivo e apoio.
Ao meu orientador, Ricardo Wagner pela paciência e dedicação ao longo no
desenvolvimento deste trabalho.
Aos professores Maikol, Sérgio, Daniel, Lúcio, Leopoldo, Flaúdio, Paulo Benício e
Elizabeth e também aos ex-professores Aragão, Ernani, Sales, Wietske e Eugênia pelas
contribuições para a minha formação profissional e pelas experiências repassadas ao longo
das disciplinas.
À minha namorada Josiane pelo seu amor, apoio e dedicação.
Aos meus ex-colegas de estágio da Caixa Econômica Federal e Justiça Federal pelas
experiências repassadas e pelos conhecimentos adquiridos, que contribuíram para minha
formação profissional.
A todos os meus amigos que participaram desta conquista e que contribuíram para que
esta fosse alcançada, com os diversos trabalhos, provas e conhecimentos adquiridos ao longo
do curso.
RESUMO
A criação do Modelo Relacional no final da década de 1960 por Edgar Frank Codd
possibilitou o armazenamento de dados em sistemas computacionais. Desde sua concepção,
este modelo de dados vem evoluindo para implementações mais robustas. Na tentativa de
integração entre o paradigma da orientação a objetos e os sistemas de bancos de dados
relacionais, surgiu o banco de dados Objeto-Relacional. Este tornou possível a criação de
tipos abstratos de dados (TADs) em Sistemas Gerenciadores de Bancos de Dados (SGBDs).
Por meio desta técnica, foram desenvolvidos novos tipos de bancos de dados de propósitos
específicos. Um destes tipos foi o Banco de Dados Espacial. Este, por sua vez, provê diversas
funcionalidades para a manipulação de elementos do mundo real por meio da geometria
euclidiana, além de outros recursos de vetorização de imagens digitais. Diante disto, o
presente trabalho visa à criação de um conjunto de rotinas na linguagem procedural
PL/pgSQL, para manipulação de elementos geográficos por meio da geometria euclidiana.
Estes elementos serão criados com base no modelo espacial de dados, utilizando os recursos
da extensão espacial PostGis, proveniente do SGBD PostgreSQL. Este conjunto de
funcionalidades será aplicado em um problema do mundo real, onde será tratado um cenário
relativo à distribuição de preços de combustíveis em diversos postos de gasolina.
Palavras chave: Relacional. Objeto-relacional. Espacial. Geometria. PostgreSQL. Type.
Procedure. PostGis.
SUMÁRIO
INTRODUÇÃO ..................................................................................................................................... 9
1. BANCOS DE DADOS RELACIONAIS.................................................................................... 12
1.1 MODELO RELACIONAL ......................................................................................................................... 12 1.2 MODELAGEM ........................................................................................................................................ 13 1.3 SQL-92................................................................................................................................................. 16 1.4 SGBD................................................................................................................................................... 18
2. BANCO DE DADOS OBJETO-RELACIONAL...................................................................... 21
2.1 ORIENTAÇÃO A OBJETOS ...................................................................................................................... 21 2.2 BANCO DE DADOS ORIENTADO A OBJETOS .......................................................................................... 22 2.3 BANCO DE DADOS OBJETO RELACIONAL.............................................................................................. 23
3. BANCO DE DADOS ESPACIAL .............................................................................................. 25
3.1 SISTEMA DE INFORMAÇÕES GEOGRÁFICAS (SIG) ................................................................................. 25 3.2 CARACTERÍSTICAS DO BDE.................................................................................................................. 26 3.3 POSTGIS................................................................................................................................................ 31
4. SOLUÇÃO PROPOSTA............................................................................................................. 36
4.1. CRIAÇÃO DOS NOVOS TIPOS DE DADOS ................................................................................................. 38 4.2. CRIAÇÃO DAS FUNCIONALIDADES......................................................................................................... 39 4.3. COMPARATIVO DE FUNCIONALIDADES: BDR, BDE E SOLUÇÃO PROPOSTA:......................................... 48
5. ESTUDO DE CASO .................................................................................................................... 53
5.1 CENÁRIO............................................................................................................................................... 54 5.2 ELABORAÇÃO DA BASE DE DADOS ....................................................................................................... 55
5.2.1. Elaboração do Diagrama Entidade-Relacionamento ................................................................. 55 5.2.2. Elaboração do Diagrama Relacional ......................................................................................... 55 5.2.3. Criação do script SQL................................................................................................................. 57
6. CONCLUSÃO.............................................................................................................................. 62
REFERERÊNCIAS BIBLIOGRÁFICAS......................................................................................... 64
LISTA DE FIGURAS
Figura 1 – Exemplo de DER (REZENDE, 2006). ............................................................................. 15
Figura 2 – Exemplo de DR (REZENDE, 2006). ................................................................................ 15
Figura 3 – Visão contínua e visão discreta (SPACCAPIETRA, 2007)............................................ 27
Figura 4 – Mapa do Brasil em termos de suas latitudes e longitudes (Maps of World, 2012)...... 28
Figura 5 – Tipos de Dados Primitivos da extensão Geometry (FERREIRA, QUEIROZ & CÂMARA, 2007).................................................................................................................................. 29
Figura 6 – Hierarquia de classes da extensão espacial Geometry (MEDEIROS, 2012)................. 30
Figura 7 – Relacionamentos entre elementos espaciais (SPACCAPIETRA, 2007). ...................... 31
Figura 8 – A comunicação entre a BDG e o PostgreSQL por meio do PostGis (IBIS, 2012). ....... 32
Figura 9 – Visualização dos Distritos de São Paulo (FERREIRA & QUEIROZ, 2005). .............. 34
Figura 10 – Visualização dos bairros de São Paulo (FERREIRA & QUEIROZ, 2005)................ 35
Figura 11 – Distância entre dois pontos (Martins, 2013). ................................................................ 50
Figura 12 – DER Postos de Gasolina. ................................................................................................ 56
Figura 13 – DR Postos de Gasolina. ................................................................................................... 57
LISTA DE TABELAS
Tabela 1 – Características do DER (GUIMARÃES, 2008)................................................................... 14
Tabela 2 – Principais comandos DDL e DML da linguagem SQL (MILANI, 2008). .......................... 17
Tabela 3 – Comparativo de criação da tabela de ruas............................................................................ 48
LISTA DE ABREVIATURAS E SIGLAS
Sigla Significado
ACID Atomicidade, Consistência, Isolamento e Durabilidade
BDE Banco de Dados Espacial
BDOO Banco de Dados Orientado a Objetos
BDOR Banco de Dados Objeto-Relacional
BDR Banco de Dados Relacionais
CEP Código de Endereçamento Postal
CPF Cadastro de Pessoa Física
CRUD Create, Read, Update, Delete
DDD Discagem Direta de Longa Distância
DDL Data Definition Language
DER Diagrama Entidade-Relacionamento
DML Data Manipulation Language
DR Diagrama Relacional
GPS Global Positioning System
SGBD Sistema Gerenciador de Banco de Dados
SGBDOR Sistema Gerenciador de Banco de Dados Objeto-Relacional
SIG Sistema de Informações Geográficas
SQL Structured Query Language
TAD Tipo Abstrato de Dados
UF Unidade Federativa
9
INTRODUÇÃO
Nas últimas décadas, o fluxo intenso de veículos nos perímetros urbanos do país
aumentou consideravelmente. Este fator provocou um aumento no tempo de deslocamento de
uma região a outra e o transporte de mercadorias entre duas regiões tornou-se mais
dispendioso. Com o aumento na variação de preços de produtos por região, muitas empresas
estão criando sistemas computacionais para administrar melhor a distribuição de preços de
seus produtos. Esses sistemas estão servindo também como uma estratégia na tentativa de
prover alguma forma de economia para seus clientes.
Além disso, muitas empresas disponibilizam, em seus sites, recursos extras para seus
clientes. Um destes recursos permite que o cliente digite o tipo de produto desejado. A partir
desta informação, o site realiza uma busca, retornando estabelecimentos dos afiliados da
empresa que possuem o item desejado pelo cliente, mostrando o preço e a descrição do
mesmo. Com isso, os clientes poderão saber aonde ir para comprar o produto que está
procurando. As informações da empresa que são mostradas na busca feita pelo cliente vão
desde um simples número de telefone, até a localização física da empresa, contendo endereço
e a visualização do mesmo em um mapa.
Com a tecnologia de representação de dados reais em um mapa, os estudiosos da
ciência da informação obtiveram uma nova perspectiva: a criação de sistemas para
armazenamento de informações geográficas. Estes sistemas visam tratar a representação de
elementos geográficos por meio da geometria. Exemplos desses elementos podem ser uma
rua, uma avenida, um estabelecimento comercial ou uma indústria.
10
Devido a isso, uma questão precisou ser levada em consideração: como armazenar
dados geográficos em um sistema? Os sistemas computacionais comumente se utilizam de
bancos de dados para armazenar suas informações.
O modelo mais comumente utilizado para o armazenamento de dados, o Modelo
Relacional, surgiu no final da década de 1960 e continua sendo preponderante. Esse modelo
manipula os dados em tabelas, formadas por linhas e colunas. As colunas representam
atributos, as características de uma entidade do banco de dados. As linhas contêm os valores
desses atributos, para cada elemento da tabela.
Para a utilização de informações geográficas, o Modelo Relacional, apesar de sua
ampla difusão, não se mostrou suficientemente adequado. Para tanto, surgiu uma variação
chamada de Banco de Dados Espacial (BDE), oriunda do Banco de Dados Objeto-Relacional
(BDOR) e, conseqüentemente, do Banco de Dados Relacionais (BDR). O BDE diferencia-se
dos anteriores pelo armazenamento de informações que o BDR e o BDOR não suportam.
Através da criação de funções e de novos tipos de dados, é possível armazenar, nesse tipo de
banco, representações geométricas de elementos geográficos.
Diante da perspectiva de sistemas apresentada, esse trabalho visa criar um conjunto de
funcionalidades para facilitar a manipulação de dados geográficos em um sistema
computacional. A pesquisa apresentará novos tipos de dados que permitirão mapear estes
dados geográficos, além de diversas rotinas que tornarão possível executar operações
matemáticas sobre estes tipos de dados. Estas operações matemáticas utilizarão princípios da
geometria euclidiana.
Depois de implementados os novos tipos de dados e funções, será elaborado um
modelo de dados que contém informações relacionais e espaciais. Esse modelo será um
diagrama relacional, acrescido de atributos cujo tipo é um dado espacial, além de um conjunto
de funções para manipulação destes dados. Juntamente a isso, será desenvolvido um script de
modelo de dados, composto por um código na linguagem de manipulação de dados SQL
(Structured Query Language). Esse código poderá ser executado em um Sistema Gerenciador
de Banco de Dados (SGBD) para criação da base de dados. Nesta pesquisa, será adotado o
SGBD PostgreSQL. O modelo de dados será construído com base em um cenário real no qual
será a aplicado o conjunto de funcionalidades que será desenvolvido.
11
O trabalho está dividido em seis capítulos. No primeiro capítulo são detalhadas as
características do BDR. No segundo capítulo, são apresentados os elementos que compõem o
BDOR. O terceiro capítulo descreve as tecnologias relativas ao Banco de Dados Espaciais e
apresentará trechos de código na linguagem SQL para este tipo de banco. Estes trechos de
código seguem a sintaxe do SGBD PostgreSQL e de sua extensão espacial PostGis. No quarto
capítulo serão apresentados os tipos de dados e as funcionalidades que serão desenvolvidos
nesta pesquisa. No quinto capítulo será ilustrada a aplicação das funcionalidades
implementadas através de um estudo de caso, no qual será tratada uma situação do mundo real
e uma possível solução para a mesma. O último capítulo apresentará as conclusões finais do
projeto, bem como sugestões para trabalhos futuros.
12
1. BANCOS DE DADOS RELACIONAIS
A seguir, serão elencados os aspectos teóricos relativos ao Banco de dados Relacional
(BDR). Além disto, serão apresentados exemplos de diagramação e trechos de códigos na
linguagem de manipulação de dados SQL.
1.1 Modelo Relacional
Em 1969, o matemático Edgar Frank Codd criou o Modelo Relacional. Esse modelo
consiste no armazenamento de dados em forma de tabelas. Cada tabela possui atributos de
diferentes tipos. Esses atributos correspondem às características do elemento que está sendo
modelado. Cada atributo corresponde a uma coluna da tabela. Cada linha de uma tabela é
chamada de registro ou tupla.
Assim, por meio da publicação da obra de Codd (CODD,1969), iniciou-se o
desenvolvimento de sistemas mais robustos para armazenamento de dados, sistemas estes
que, nas quatro últimas décadas, tornaram-se predominantes no mercado mundial: o Banco de
Dados Relacional.
Uma das características fundamentais do BDR diz respeito às restrições de
integridade, que servem para garantir a consistência e exatidão dos dados. Exemplos destas
regras são as chaves primárias e as chaves estrangeiras.
13
1.2 Modelagem
Antes de ser implementado um novo banco de dados, deve-se criar um modelo de
dados. Esse modelo trata-se da diagramação do banco de dados, com todos os elementos que
o compõem. Segundo Silberschatz, Korth & Sudarshan (1999, p.7), um modelo de dados é
“um conjunto de ferramentas conceituais usadas para a descrição de dados, relacionamentos
entre dados, semântica de dados e regras de consistência”. Ou seja, no modelo de dados estão
descritos os elementos que devem estar presentes na base de dados, bem como os
relacionamentos entre eles.
O primeiro passo do processo de diagramação da base de dados relacional corresponde
à criação do Diagrama Entidade-Relacionamento (DER). Neste modelo, os elementos que
compõem a base de dados são representados por meio de figuras geométricas. Isto servirá de
documento base para a elaboração do Diagrama Relacional (DR). No DER, os elementos
principais são denominados de entidades. Cada entidade representa um elemento do mundo
real, como empresas, veículos, cidades. Além disso, cada entidade possui atributos, que são
suas características. As diversas entidades do modelo podem ser interligadas por meio de
relacionamentos. (GUIMARÃES, 2008).
O DER também possui as seguintes características: As entidades são representadas por
retângulos. Os atributos, que podem ser do tipo simples, composto, derivado ou
multivalorado, são representados por círculos. Neste caso, se o atributo for simples, ele é
representado por uma única elipse; se ele for do tipo composto, o mesmo será representado
por elipses interligadas; por sua vez, se o atributo for do tipo derivado, ele deve ser
representado por uma elipse com seus contornos pontilhados; por fim, se o atributo for do tipo
multivalorado, ele deve ser representado por uma elipse dupla (GUIMARÃES, 2008).
Já os relacionamentos entre entidades devem ser representados por losangos, contendo
suas cardinalidades. Estas cardinalidades são pares formados pelos elementos 1 e N, que são
utilizados para determinar como as tabelas se relacionam. Além destes, existem as
especializações e generalizações. Estes são mecanismos para identificar se uma entidade
herdará atributos de outra entidade. No DER, as especializações/generalizações são
representadas por triângulos. Na Tabela 1, estão representadas as características do DER.
14
Tabela 1 – Características do DER (GUIMARÃES, 2008).
Para a construção do DER, existem algumas ferramentas disponíveis no mercado.
Exemplos delas são o SQL Power Architect, O Gliffy, o brModelo e o Dia Portable. Um
exemplo de DER pode ser encontrado na Figura 1.
Elemento Representação
Entidade
Atributo simples
Atributo composto
Atributo multivalorado
Atributo derivado
Relacionamento
Especialização/
Generalização
15
Figura 1 – Exemplo de DER (REZENDE, 2006).
O segundo passo consiste na criação do Diagrama Relacional (DR). Diferente do
DER, no DR são especificados o tipo de dado e tamanho de cada atributo, além de seu
conteúdo e suas restrições de integridade. Os relacionamentos entre as tabelas também são
representados neste modelo por meio de linhas que interligam as tabelas. Para a construção do
DR, existem diversas ferramentas disponíveis no mercado. Além das ferramentas já citadas
para a construção do DER, com exceção da Gliffy, é possível citar também o Sybase Power
Designer, a DB Designer, a EMS SQL Manager e o CA ERwin Data Modeling. Um exemplo
de DR pode ser encontrado na Figura 2.
Aluno
mat_aluno nome endereco turma
1 Cecília Ortiz Rezende Rua dos Ipês, 37 1
2 Abílio José Dias Avenida Presidente Jânio Quadros, 357 2
Turma
cod_turma sala período
1 8 Manhã
2 5 Noite
Figura 2 – Exemplo de DR (REZENDE, 2006).
16
Concluída a etapa de modelagem, deve ser gerado um script na linguagem SQL. O
código será utilizado para a implementação do modelo de dados em um SGBD. Nesta
pesquisa, os scripts a serem apresentados serão adaptados para a sintaxe do SGBD
PostgreSQL.
1.3 SQL-92
A criação dos diagramas DER e DR tornou possível o armazenamento de informações
do mundo real em uma base de dados relacional. Para tanto, foi elaborada uma linguagem de
manipulação de dados específica para este fim.
Uma linguagem de manipulação de dados é constituída de comandos para a criação,
atualização e exclusão dos elementos que compõem a base de dados do sistema, também
chamados de comandos DDL (Data Definition Language); além destes, existem comandos
para a inserção e manipulação de dados armazenados na base, denominados de comandos
DML (Data Manipulation Language). Ou seja, Os comandos DDL servem para tanto para a
criação e exclusão da base de dados, como para a criação, alteração e exclusão das tabelas e
atributos que irão compor esta base; já os comandos DML são utilizados para inserir,
consultar, remover e alterar dados que estão armazenados nas tabelas da base de dados.
(SILBERSCHATZ, KORTH & SUDARSHAN, 1999).
Com a criação dos comandos para a manipulação e criação de elementos de uma base
de dados, surgiram linguagens especificas para este fim. Exemplos disto são as linguagens
QEL, OQL e SQL. As duas primeiras não se firmaram no mercado; já a SQL, pela sua
robustez e simplicidade de seus comandos DDL e DML, tornou-se o padrão adotado nos
principais SGBDs comerciais existentes. A Tabela 2 lista os principais comandos DDL e
DML da SQL-92.
17
Tabela 2 – Principais comandos DDL e DML da linguagem SQL (MILANI, 2008).
Comandos DML
Comando Utilização Exemplos de Código (PostgreSQL)
CREATE Criação de bases de dados, tabelas, views e procedures.
CREATE DATABASE Teste;
CREATE SEQUENCE seq_pessoa
START 1, INCREMENT 1; 1
CREATE TABLE Pessoa (
id integer default nextval (seq_pessoa),
Nome varchar(100),
CPF varchar(11)
);
CREATE VIEW dadosPessoas AS SELECT * FROM Pessoa;
CREATE FUNCTION atualizaNome (varchar, integer) RETURNS VOID AS $$
BEGIN;
UPDATE pessoas SET nome = $1 WHERE id = $2;
END; $$LANGUAGE plpgsql;
ALTER Alterar as propriedades de uma sequence ou de uma tabela.
ALTER SEQUENCE seq_pessoa RESTART WITH 1;
ALTER TABLE Pessoa ADD COLUMN rg varchar(20);
DROP Excluir uma sequence, uma tabela ou uma base de dados por completo.
DROP SEQUENCE seq_pessoa;
DROP TABLE Pessoa;
DROP DATABASE Teste;
1 As sequences são campos cujo valor é auto-incrementável. Ou seja, o valor deste campo obedece a uma sequência ordenada. No PostgreSQL, para atribuir um auto-incremento em um campo de uma tabela, faz-se necessária à criação de sequences. Já no SBGD SQL Server, não há necessidade de criação desse tipo de estrutura, devido à existência da clausura Identity.
18
Comandos DML
INSERT Inserir dados nas tabelas da base de dados
INSERT INTO Pessoa (nome, CPF) values (‘José’, ‘11111111122’);
SELECT Realizar uma consulta nos dados de uma tabela.
Fazer chamadas de views e procedures.
SELECT * FROM Pessoa;
SELECT * FROM dadosPessoa;
SELECT atualizaDados( ‘João’,1);
UPDATE Atualizar os valores dos registros de uma tabela.
UPDATE Pessoa SET nome = ‘João’ WHERE id = 1;
DELETE Excluir os valores dos registros de uma tabela.
DELETE FROM Pessoa WHERE id = 1;
1.4 SGBD
Segundo Silberschatz, Korth & Sudarshan (1999, p.1):
Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto
de dados associados a um conjunto de programas para acesso a estes dados. O
conjunto de dados, comumente chamado banco de dados, contém informações sobre
uma empresa em particular. O principal objetivo de um SGBD é proporcionar um
ambiente tanto conveniente quanto eficiente para a recuperação e armazenamento
das informações do banco de dados.
Assim, o SGBD é uma ferramenta capaz de gerenciar diversos bancos de dados
criados pelo usuário. O SGBD possui diversas funcionalidades, dentre as quais é possível
destacar:
· O gerenciamento das informações dos bancos de dados;
· A criação e o gerenciamento de usuários e grupos de usuários;
· Execução de comandos da linguagem procedural SQL.
19
O recurso de execução e criação de consultas permite, nos SGBDs a manipulação de
dados por meio das funcionalidades da linguagem SQL. Entre estas operações, podem ser
citadas:
· A criação e manutenção de tabelas e da base de dados;
· Criação de views, e procedures e triggers;
· Realização de diversas consultas aos dados por meio de comandos SQL.
As views são tabelas virtuais para o armazenamento das consultas mais importantes do
sistema (ELMASRI, NAVATHE & SHAMKANT, 2005). Por exemplo, em um sistema de
cadastro de ponto eletrônico, uma consulta importante se refere ao relatório de horas por mês
de um funcionário qualquer. É possível criar uma visão para armazenar este relatório; assim,
durante o desenvolvimento da aplicação, será necessário apenas utilizar essa visão para emitir
o relatório de horas mensais do funcionário.
As procedures são funções escritas em uma linguagem procedural derivada da
linguagem SQL para a manipulação de dados. No sistema de ponto eletrônico citado, é
possível criar uma procedure para atualizar o número de horas do funcionário toda vez que o
mesmo registrar o ponto de saída. Nesta pesquisa, será utilizada a linguagem procedural
PL/pgSQL.
A trigger é um procedimento que é disparado toda vez que é feita uma operação sobre
uma tabela específica do banco de dados. No sistema de ponto eletrônico mencionado
anteriormente, pode ser criada uma trigger para, cada vez que for alterada a quantidade de
horas do funcionário, a view com o relatório de horas registradas seja automaticamente
atualizada.
Os Bancos de Dados Relacionais destacam-se também pela garantia em suas
operações internas de quatro principais propriedades: Atomicidade, Consistência, Isolamento
e Durabilidade, formando um conjunto chamado de ACID (SILBERSCHATZ, KORTH &
SUDARSHAN, 1999). Estes quatro princípios são utilizados para controle de transações nos
SGBDs.
20
Segundo Silberschatz, Korth & Sudarshan (1999, p.13): “Uma transação é uma
coleção de operações que desempenha uma função lógica única dentro de uma aplicação do
sistema de banco de dados. Cada transação é uma unidade de atomicidade e consistência.”.
Assim, uma transação pode ser definida como qualquer seqüência de eventos que são
disparados no BD para manipulação e/ou criação de bases de dados, constituindo-se
basicamente de operações de criações, consultas, atualizações e exclusões nas mesmas,
também chamadas de operações CRUD (Create, Read, Update, Delete). A consistência do
banco de dados deve ser mantida após o processamento de cada transação; ou seja, as
operações executadas durante uma transação devem manter a consistência dos dados.
Já as propriedades ACID podem ser definidas da seguinte forma: a atomicidade
garante que durante uma transação, ou todas as operações são feitas, ou nenhuma é realizada.
A consistência garante que as operações foram realizadas de maneira que os dados não sejam
corrompidos. O isolamento garante que as operações de uma transação não interfiram nas
operações de outra transação qualquer que esteja executando paralelamente a ela. Por sua vez,
a durabilidade é utilizada para garantir que, se todas as operações de uma transação foram
concluídas com sucesso, as alterações que essas fizeram nos dados do banco não serão
perdidas (SILBERSCHATZ, KORTH & SUDARSHAN, 1999). Nos últimos 30 anos, o
Modelo Relacional tem sido cada vez mais adotado como o modelo de dados utilizados por
quase todos os Sistemas Gerenciadores de Bancos de Dados (SGBDs) comerciais existentes
como, por exemplo, Microsoft SQL Server, Oracle, DB2, PostgreSQL, MySQL e Firebird.
21
2. BANCO DE DADOS OBJETO-RELACIONAL
Com a criação do Banco de Dados Relacional, cientistas da informação começaram a
pesquisar técnicas para utilizar esta tecnologia na resolução de problemas do mundo real. A
seguir, será apresentada a integração dos BDR com a Orientação a Objetos, uma técnica de
programação para representação de elementos do mudo real por meio de objetos.
2.1 Orientação a Objetos
A metodologia orientada a objetos consiste na representação de elementos do mundo
real por meio de estruturas de código contendo ações e características deste elemento. Estas
estruturas foram denominadas de classes. Uma classe pode representar a abstração de um
elemento do mundo real, contendo suas características e ações que pode executar. As
características correspondem aos atributos da classe; As ações correspondem aos métodos da
classe.
A Orientação a Objetos destaca-se também por suas quatro principais propriedades,
também chamadas de “pilares”: encapsulamento, abstração, herança e polimorfismo. A
abstração. O encapsulamento “é a técnica de proteger as propriedades e os métodos de um
objeto” (Kaupa, 2008). Ou seja, por meio do encapsulamento, os detalhes da criação do
sistema ficam ocultos para seus usuários. Já a abstração é a representação de um elemento do
mundo real, com suas propriedades, que são seus atributos; e seus métodos, que são as ações
que este elemento pode executar. Por sua vez, a herança é a propriedade que permite a
reutilização de informações de uma classe qualquer para outra classe. (KAUPA, 2008)
22
2.2 Banco de Dados Orientado a Objetos
Com o advento do paradigma de orientação a objetos, o desenvolvimento de sistemas
computacionais vem evoluindo. É cada vez mais frequente a adoção, nos sistemas
empresariais, dos princípios da orientação a objetos. Com isso, os fabricantes dos principais
SGBDs existentes perceberam a importância da adaptação entre os bancos de dados e a
tecnologia orientada a objetos. Diversas tecnologias surgiram ao longo dos anos com o
propósito dessa integração. Um exemplo disso foi o Banco de Dados Orientado a Objetos
(BDOO).
O BDOO permitiu aos projetistas de bancos mapearem os dados como objetos
(SILBERSCHATZ, KORTH & SUDARSHAN, 1999). Isto possibilitou a integração de duas
tecnologias: Banco de Dados e Orientação a Objetos. Nessa última, os elementos dos sistemas
são tratados como objetos, sendo estes criados pela instanciação de classes. Cada classe é uma
estrutura que possui atributos e métodos. Essa classe pode também ser vista e utilizada como
um novo tipo de variável. Para os sistemas de bancos de dados, os métodos das classes não
são necessários. Esses métodos não são utilizados na criação das tabelas. Entretanto, os
métodos das classes podem ser mapeados no SGBD na forma de procedures.
O BDOO fomentou alguns recursos que são muito utilizados atualmente, como o
controle de versão por parte dos SGBDs. Entretanto, o BDOO trouxe problemas de
implementação, tornando-se um banco de dados de difícil manutenção. Isso ocorreu devido ao
fato do BDOO apresentar uma perda na durabilidade das consultas SQL.
Com isso, esse modelo não se firmou no mercado. Ainda assim, foram criadas
algumas ferramentas e SGBDs voltados para esta tecnologia. Entre estas ferramentas, é
possível citar: DB4O, Objectivity/DB e O2; mesmo assim, as pesquisas sobre esta tecnologia
continuaram, evoluindo para o Banco de dados Objeto-Relacional (BDOR).
23
2.3 Banco de Dados Objeto Relacional
O BDOR tornou possível o desenvolvimento de técnicas para criação de TADs dentro
dos SGBDs. Estes TADs são denominados de types, que são tipos de dados definidos pelo
usuário (RAMAKRISHNAN & JOHANNES, 2008). Com isto, podem-se criar atributos com
seu tipo definido por um type. Além disso, é possível utilizar um type como um objeto dentro
do SGBD. O SGBD PostgreSQL não possui suporte à manipulação de types como objetos.
Para exemplificar o funcionamento da técnica do BDOR, suponha-se uma tabela
“Funcionário”, com os atributos (código, CPF, nome, endereço, telefone). Código e nome são
atributos simples das tabelas, ou seja, são elementos de um só tipo de dados; o campo código,
neste caso, representa a chave primária da tabela “Funcionário”; na modelagem de dados
relacionais, o atributo que representa a chave primária é destacado como sublinhado. O
Cadastro de Pessoa Física (CPF) é um número de onze caracteres que representam um código
único para cada pessoa no país. Já os atributos endereço e telefone são atributos compostos de
mais de um tipo de dados. Um telefone é constituído por um código para Discagem Direta de
Longa Distância (DDD), que corresponde ao código de área estadual a qual o número de
telefone está associado, e o número, que é a seqüência de algarismos que são utilizados para
realizar uma chamada local. Por sua vez, o endereço é composto pelas seguintes informações:
número da residência, que é um valor numérico; rua, bairro, complemento e cidade, que são
valores alfanuméricos; um Código de Endereçamento Postal (CEP), que identifica cada rua de
uma cidade no sistema dos Correios.
Em um Banco de Dados Relacional, os atributos endereço e telefone da tabela
“funcionário” mencionada anteriormente são armazenados em tabelas a parte, contendo uma
chave estrangeira para a tabela “funcionário”. Com o BDOR, estes atributos podem ser
tratados como novos tipos de dados, bastando apenas serem criados os types endereço e
telefone. Assim, não se faz necessário criar tabelas separadas para eles. Na tabela funcionário,
o campo endereço será uma instância de type endereço. O atributo telefone será uma instância
de type telefone. Esse recurso fornece uma maior robustez aos bancos de dados, provendo
diversas possibilidades para a integração entre bancos de dados e aplicações orientadas a
objetos. Essas aplicações necessitam de uma base de dados que possua recursos para mapear
os dados como instâncias de classes da orientação a objetos.
24
A criação de colunas das tabelas de um banco de dados como um objeto type quebra
um dos princípios fundamentais dos bancos de dados relacionais: a Primeira Forma Normal.
Nesta propriedade, cada atributo de uma tabela é atômico, ou seja, não são permitidos que, em
uma coluna de uma tupla, seja armazenado mais de um dado. Dessa maneira, não é possível
utilizar TADs dentro dos SGBDs. As estruturas de dados são conjuntos formados por dados
de diversos tipos, podendo ser reutilizados como um novo tipo de dado em diversas
aplicações.
Os SGBDs com suporte ao BDOR são denominados de Sistema Gerenciador de Banco
de Dados Objeto-Relacional (SGBDOR). Com este tipo de SGBD, é possível criar diversos
Tipos Abstratos de Dados (TAD). Estes TADs permitem a manipulação de novos tipos de
dados dentro dos SGBDs. Assim, em uma tabela, pode-se criar um atributo cujo tipo possuirá
as características do novo tipo de dados que foi criado. Em alguns SGBDs, como o Oracle, é
possível utilizar os novos tipos de dados como um objeto.
O advento do BDOR trouxe para os desenvolvedores de sistemas um conjunto de
novas possibilidades. Com a implementação de bases de dados com bases nos princípios da
orientação a objetos, a robustez do armazenamento de dados tornou-se cada vez maior. No
entanto, a linguagem SQL-92, linguagem padrão para a implementação de bases de dados
relacionais, não possuía os recursos necessários para suprir a robustez do BDOR. Diante
disso, foi preciso implantar os recursos do BDOR na linguagem SQL-92. Com isso, surgiu
uma nova versão da linguagem SQL: a SQL:1999.
A SQL:1999 possui os mesmos comandos DDL e DML da sua antecessora SQL-92. A
diferença entre elas é que a SQL:1999 possui recursos adicionais, como criação de TADs, que
são implementados como types. Estes types são tipos de dados definidos pelo usuário. Além
destes, a SQL:1999 permite: a criação de funções para a manipulação de novos tipos de
dados; a criação de atributos das tabelas como vetores e a inserção de blocos de dados de
vários bytes2 nas colunas das tabelas.
2 O Byte é um conjunto de 8 algarismos formado pela combinação dos números 0 e 1. Cada 0 ou 1 é chamado de bit. Exemplo: 00110011
25
3. BANCO DE DADOS ESPACIAL
Neste capítulo, serão apresentadas as características do Banco de Dados Espacial
(BDE) e as tecnologias relacionadas com este tipo específico de banco de dados.
3.1 Sistema de Informações Geográficas (SIG)
Em meados da década de 1960 foi criado o Sistema de Informações Geográficas
(SIG). Segundo Oliveira (2004, p. 1), o SIG é “um conjunto de softwares, métodos,
dados e usuários integrados, possibilitando o desenvolvimento de uma aplicação capaz
de coletar, armazenar e processar dados georreferenciados”. Com a criação do SIG,
abriu-se uma nova possibilidade: o desenvolvimento de sistemas para armazenar dados
geográficos por meio da geometria.
Segundo Câmara (2005, p. 3), “A principal diferença de um SIG para um
sistema de informação convencional é sua capacidade de armazenar tanto os atributos
descritivos como as geometrias dos diferentes tipos de dados geográficos.”. Dessa
forma, é possível operar informações não suportadas pelos sistemas convencionais
como, por exemplo, representações matemáticas de figuras geométricas.
Dessa forma, os sistemas que utilizam SIG podem mapear figuras geométricas
de elementos que são representados em mapas. Um exemplo disso pode ser um mapa
das indústrias de uma cidade, onde as indústrias de uma cidade podem ser representadas
como polígonos.
26
Segundo Câmara & Queiroz (2000, p.1), “Para cada objeto geográfico, o SIG necessita
armazenar seus atributos e as várias representações gráficas associadas”. Com base nesse
princípio, cada indústria pode ser representada no banco de dados como um tipo de dado que
possui um polígono, sendo este mapeado por meio das coordenadas de seus vértices.
O SIG torna possível a criação de sistemas computacionais para operar dados
georreferenciados. As operações sobre esses dados podem ser de captura, modelagem,
manipulação, recuperação e análise dos dados (WOR apud LISBOA FILHO, 2000).
A aplicação mais popular do SIG é o Global Positioning System (GPS). O GPS
fornece a posição do planeta que um determinado dispositivo ocupa no momento. Ou seja, por
meio do GPS, uma pessoa que esteja de posse de um dispositivo móvel pode ser facilmente
localizada, desde que o dispositivo móvel possua o recurso do GPS. Esta tecnologia é
amplamente utilizada por empresas transportadoras, para que as mesmas saibam onde está no
momento o veículo com a carga transportada. Esta técnica é útil para determinar se esse
veículo saiu da rota para a qual ele foi programado.
Entretanto, esta nova alternativa trouxe um problema: como armazenar os dados
geográficos em um banco de dados? Até então, o conjunto de instruções e tipos de variáveis
aceitos pelos SGBDORs não eram suficientes para armazenar esses tipos de dados.
Com o objetivo da integração entre o SIG e os bancos de dados, começaram a surgir
implementações de propósito específicas do BDOR, como é o caso do BDE.
3.2 Características do BDE
O BDE é uma extensão do BDOR. Além de possuírem as propriedades deste, o BDE
permitem a manipulação de dados espaciais por meio de funções matemáticas próprias para
este fim.
Com o advento do Banco de Dados Espacial, tornou-se possível armazenar em um
banco de dados representações matemáticas de elementos geográficos, por meio da criação de
tipos de dados específicos para este propósito. Esta representação pode ser feita tanto em
27
termos da localização geográfica desses elementos, incluindo latitude e longitude, como seus
limites na forma de figuras geométricas (CÂMARA & QUEIROZ, 2000).
Para a representação em um banco de dados das informações geográficas, é possível
trabalhar com dois tipos de visões: os objetos do espaço e o próprio espaço (GÜTING, 1994).
No primeiro tipo de visão, chamada de visão discreta, os objetos são vistos por sua
representação espacial, em termos de sua área e localização. No segundo tipo de visão,
chamada de visão contínua, os objetos são caracterizados por meio da sequência de valores
contínuos de suas propriedades, na forma de uma matriz de células (SPACCAPIETRA,
2007). Um exemplo no nível da primeira visão pode ser a cidade de Fortaleza. Neste caso, a
região que compreende a dimensão da cidade pode ser modelada como um polígono; as ruas e
avenidas como linhas; os domicílios residenciais e lojas comerciais como pontos. A dimensão
da cidade, neste caso, pode ser calculada com base nos seus limites territoriais; a localização
pode ser mapeada em função de suas coordenadas geográficas de latitude e longitude. Já no
nível da segunda visão, a cidade é vista em sua forma global como uma matriz. Nesta matriz,
cada célula corresponde a um elemento geográfico da cidade. Neste caso, são considerados os
valores em graus das coordenadas geográficas – latitude e longitude – de cada ponto da cidade
que, no âmbito da cartografia, indicam a posição que esse elemento possui no globo terrestre.
Na Figura 3, são mostrados os dois níveis de visão anteriormente citados, juntamente
com a comparação destes em relação à representação gráfica do mundo real.
Figura 3 – Visão contínua e visão discreta (SPACCAPIETRA, 2007).
28
Para que seja feita a modelagem dos dados geográficos em uma ferramenta própria
para este fim, foram criadas duas técnicas: a representação matricial e a representação
vetorial.
A representação matricial, segundo Câmara (2005, p.34):
Nesta representação, o espaço é representado como uma matriz P(m, n) composto de
m colunas e n linhas, onde cada célula possui um número de linha, um número de
coluna e um valor correspondente ao atributo estudado e cada célula é
individualmente acessada pelas suas coordenadas.
Um exemplo da representação matricial pode ser visualizado na Figura 4:
Figura 4 – Mapa do Brasil em termos de suas latitudes e longitudes (Maps of World, 2012).
Conforme a Figura 4, o mapa do Brasil pode ser representado na cartografia como
uma matriz de coordenadas, caracterizadas por latitude e longitude.
29
Na representação vetorial, segundo Lisboa Filho (2001, p. 7):
Na estrutura vetorial, cada fenômeno geográfico é representado, no banco de dados,
por um objeto com identificação própria e representação espacial o tipo ponto, linha,
polígono ou um objeto complexo. A posição de cada objeto definida por sua
localização no espaço, de acordo com um sistema de coordenadas. Objetos vetoriais
não preenchem todo o espaço, ou seja, nem todas as posições do espaço necessitam
estar referenciadas na base de dados.
Durante a criação da base de dados, pode ser criado um novo tipo de dados para a
manipulação das coordenadas geográficas, que possuirá os atributos latitude e longitude.
As operações mais importantes na representação geométrica de elementos espaciais
dizem respeitos aos relacionamentos existentes entre diferentes objetos. Exemplos disso
podem ser consultas topológicas, envolvendo a interseção entre dois objetos e se estes são
vizinhos; a direção do objeto no mapa; a distância de um objeto a outro em uma região do
mapa (GÜTING, 1994). Durante a pesquisa, a representação matricial será utilizada como
modelo de representação das informações geográficas.
A fim de prestarem suporte aos BDE, vários SGBDs incorporaram elementos da
extensão espacial Geometry. Esta extensão possui uma hierarquia de classes que permitem
manipular geometricamente os dados espaciais. Na Figura 5, são representados os tipos
primitivos desta extensão:
Figura 5 – Tipos de Dados Primitivos da extensão Geometry (FERREIRA, QUEIROZ &
CÂMARA, 2007).
30
Na Figura 5, são apresentados os tipos de dados espaciais correspondentes às
primitivas básicas de um BDE. Esses tipos de dados representam, respectivamente, um ponto,
uma linha e um polígono (ALESSIO, 2009). Em um BDE, um ponto pode ser visto como um
elemento qualquer no mapa. Uma rua qualquer de uma cidade pode ser vista como uma linha.
Por sua vez, o polígono pode representar tanto uma praça de um bairro ou a Faculdade Farias
Brito, como a cidade de Fortaleza. Além disso, a partir dos tipos de dados primitivos, é
possível criar diversos outros tipos, tanto primitivos quanto tipos abstratos.
Figura 6 – Hierarquia de classes da extensão espacial Geometry (MEDEIROS, 2012).
Com base nas classes da extensão espacial Geometry, representadas na Figura 6, foram
criados relacionamentos entre os elementos geométricos. Esses relacionamentos servem para
identificar conexões entre eles. Por exemplo, no mapa da cidade de Fortaleza, essa técnica
será útil para identificar os cruzamentos entre ruas e avenidas da cidade. Isso pode ser
utilizado para indicar as ruas que passam pelos limites da Faculdade Farias Brito, além de
identificar se, por exemplo, a Praça Portugal está próxima à Faculdade Farias Brito; nesse
caso, é possível também, por meio das operações de conexão, calcular a distância entre esses
dois pontos mencionados. Outra operação possível é determinar se dois elementos
representados no mapa são iguais ou, ainda, se eles se tocam em uma determinada região do
mapa.
31
Figura 7 – Relacionamentos entre elementos espaciais (SPACCAPIETRA, 2007).
Na Figura 7, estão representados os tipos de conexões possíveis entre os elementos
geométricos. Essas conexões são nomes de funções implementadas em SGBDs com suporte à
manipulação de dados espaciais. Essas funções foram implementadas nesses SGBDs a fim de
que seja possível realizar diversas operações sobre os dados espaciais. A operação disjoint
avalia se um elemento está longe de outro; isso pode ser útil para identificar se, por exemplo,
os estados do Ceará e de São Paulo estão próximos um do outro. A touch identifica se um
elemento ‘toca’ outro, ou seja, se eles se interceptam em um determinado ponto do mapa. A
cross identifica se há um cruzamento entre dois objetos; essa operação é útil para determinar
cruzamentos entre avenidas e ruas de uma cidade. A overlap identifica se uma parte de um
elemento está contida em outro elemento; isso é amplamente utilizado para a localização de
prédios, hospitais e farmácias em qualquer rua ou avenida da cidade. A contains determina se
um elemento está totalmente contido em outro; essa técnica é importante para localizar
praças, açudes, indústrias em uma determinada região da cidade. A equal define a
equivalência entre dois elementos.
3.3 PostGis
O SGBD PostgreSQL, a partir de sua versão 8.3, possui diversas rotinas matemáticas
para manipulação de dados geográficos. Estas funções permitem uma manipulação direta
32
desses dados por meio de sua representação geométrica, proveniente da extensão PostGis. O
PostGis foi implementado com base nas extensões espaciais Geometry e Geography, cujas
classes possuem diversos tipos de dados geométricos e geográficos, desde uma simples reta
até polígonos e áreas de superfície, além de funções para manipulação de dados espaciais. Na
Figura 8, está representada a comunicação entre o SGBD PostgreSQL e sua extensão espacial.
Nesta Figura 8, a base de dados espacial é chamada de Banco de Dados Geográfico (BDG). A
utilização da extensão PostGis no SGBD PostgreSQL permitirá que este reconheça os tipos
de dados espaciais.
Figura 8 – A comunicação entre a BDG e o PostgreSQL por meio do PostGis (IBIS, 2012).
Além disso, a extensão espacial PostGis possui diversas funcionalidades tanto para a
representação de dados geográficos, em ambientes 2D e 3D, como funções para tratamento
vetorial de imagens digitais. Nesta pesquisa, algumas destas funções foram utilizadas,
principalmente as funções que operam dados da extensão Geometry.
A utilização da extensão PostGis permitirá a criação de diversas views e procedures
para a manipulação dos dados espaciais. Muitas funcionalidades já estão incluídas nesta
extensão, como funções matemáticas euclidianas. Exemplos disso podem ser: a distância entre
dois pontos; a área de uma região, representada como um polígono; além de diversas funções
para a criação dos objetos geométricos, como pontos, linhas, polígonos e círculos.
33
Para demonstrar a implementação de um BDE no SGBD PostgreSQL, será
apresentado a seguir um código escrito na linguagem SQL para a representação dos distritos e
bairros do estado de São Paulo no PostgreSQL (FERREIRA & QUEIROZ, 2005).
CREATE TABLE distritossp ( cod SERIAL, sigla VARCHAR(10), denominação VARCHAR(50), PRIMARY KEY(cod) ); SELECT AddGeometryColumn (‘public’,‘distritossp’,‘spatial_data’,-1,‘POLYGON’, 2);
CREATE TABLE bairrossp ( cod SERIAL, sigla VARCHAR(10), denominação VARCHAR(50), PRIMARY KEY(cod)
); SELECT AddGeometryColumn (‘public’, ‘bairrossp’, ‘spatial_data’, -1, ‘POINT’, 2);
Nos exemplos apresentados no trecho de código anterior, foram criadas tabelas
relacionais para representar os distritos e bairros de São Paulo. Em seguida, foi adicionada
uma coluna espacial a esta tabela. Essa coluna corresponde a um elemento geométrico com as
coordenadas especificadas no comando select. Nesse caso, a informação espacial é
representada por um polígono. No próximo trecho de código SQL, será mostrado como inserir
dados nas tabelas distritossp e bairrossp:
INSERT INTO distritossp (denominação, sigla, spatial_data) VALUES ('MARSILAC', ‘MAR’, GeometryFromText (
'POLYGON ((335589.530575,7356020.721956,335773.784959,7355873.470174, …))', -1)
); INSERT INTO bairrossp (denominação, sigla, spatial_data) VALUES ('JARDIM DOS EUCALIPTOS', 'JD_EUC', GeometryFromText ('POINT (321588.628426 7351166.969244)',-1)
);
34
Durante a inserção de dados mostrada anteriormente, são repassados os valores das
colunas da tabela. Para o campo que representa o dado geométrico, o insert recebe as
coordenadas matemáticas necessárias para a criação de um polígono e de um ponto. No
primeiro insert, essas coordenadas matemáticas representam os vértices do polígono que irá
representar os distritos. No segundo insert, são repassadas as coordenadas dos pontos que
constituirão os bairros. O método de consulta aos dados das tabelas é feito da mesma forma
com a qual se consultam dados relacionais, alterando apenas a utilização de uma função do
PostGis para realizar a busca da informação espacial, conforme apresentado no código a
seguir:
SELECT bairro, AsText (spatial_data) geom FROM distritossp WHERE denominação = ‘MARSILAC'; SELECT bairro, AsText (spatial_data) geom FROM bairrossp WHERE denominação = ‘JARDIM DOS EUCALIPTOS';
A visualização do resultado dos códigos SQL anteriormente apresentados pode ser
encontrada na Figura 9 e na Figura 10.
Figura 9 – Visualização dos Distritos de São Paulo (FERREIRA & QUEIROZ, 2005).
35
Figura 10 – Visualização dos bairros de São Paulo (FERREIRA & QUEIROZ, 2005).
36
4. SOLUÇÃO PROPOSTA
A criação do Banco de Dados Espacial possibilitou aos desenvolvedores de sistemas o
armazenamento de informações do mundo real em um SGBD. Os principais SGBDs do
mercado passaram a suportar a implementação de elementos espaciais, possuindo diversas
funcionalidades para a manipulação destes tipos de dados. O SGBD PostgreSQL, a partir de
sua versão 8.3, possui uma extensão chamada de PostGis, que suporta a criação e
manipulação de atributos, consultas e funções para tratamento de dados espaciais.
Diante disso, esta pesquisa tem como solução proposta a criação de diversas rotinas
para a manipulação de dados espaciais. Serão criados novos types e procedures, para
tratamento de dados do mundo real por meio da geometria euclidiana e do uso das
funcionalidades da extensão espacial PostGis.
As funcionalidades criadas nesta pesquisa serão úteis para facilitar a utilização do
BDE em aplicações que utilizem dados geográficos. Ou seja, com a implementação destes
novos recursos, será possível criar uma camada de abstração que facilite a utilização do BDE
em um sistema que mapeie dados geográficos. Por exemplo, aplicações que utilizam mapas
como Google Maps, Wikimapia e Google Earth, poderão utilizar os novos types e procedures
para tratamento de ruas, avenidas, bairros, distritos, cidades e estados por meio do BDE.
O conjunto de funcionalidades desenvolvido concentra-se em funções de manipulação
de elementos geográficos, como ruas, bairros, cidades e estados. Estas funções estão divididas
em rotinas de criação de elementos, cálculos de distâncias e interseções entre eles.
37
Além disso, o conjunto de funcionalidades será aplicado em um cenário real, que
abordará um problema do mundo real e uma possível solução para o mesmo. Para tanto, será
construída uma base de dados para o problema. Este cenário real será apresentado no item 5 –
Estudo de Caso.
Um possível problema no qual as funcionalidades são aplicáveis poderá ser um
sistema que mostre as farmácias que fiquem localizadas até uma determinada distância de um
determinado local que ofereceram, por exemplo, o serviço de coleta de exames de sangue.
Neste caso, o desenvolvedor criará as tabelas relacionais com as características e produtos das
farmácias, além de uma tabela contendo todos os tipos de serviços que estas possuem. Além
disso, ele poderá criar views e procedures que utilizem as funcionalidades criadas nesta
pesquisa para otimizar a criação das tabelas, consultas e atualizações da base de dados.
No problema de serviços de farmácias anteriormente apresentado, podem ser criadas
rotinas para listar os tipos de exames que cada farmácia disponibiliza, juntamente com os
valores de cada um. Suponha-se que uma paciente queira localizar as farmácias que oferecem
o serviço de coleta de exame de sangue, a fim de descobrir a taxa de diabetes que está contida
em seu sangue. Este paciente poderá utilizar o sistema para localizar estas farmácias. Além
disso, o paciente poderá localizar farmácias que estejam até uma determinada distância de sua
residência. Para tanto, o sistema deverá prover rotinas que utilizem as funções de cálculo de
distância que foram desenvolvidas nesta pesquisa.
Outra funcionalidade que poderá ser implementada no sistema de farmácias será a
localização daquelas que possuam um maior custo/benefício de um determinado
medicamento, e que fiquem localizadas em um bairro X. Esta funcionalidade poderá ser
desenvolvida utilizando as funções de interseções que foram desenvolvidas nesta pesquisa.
A seguir, serão apresentados os novos tipos de dados e funções que foram elaborados
nesta pesquisa, com seu código na linguagem procedural PL/pgSQL e uma breve descrição
dos mesmos. Estas novas funcionalidades poderão ser aplicadas em diversos problemas que
envolvam dados geográficos, facilitando a utilização do BDE na resolução destes problemas.
38
4.1. Criação dos novos tipos de dados
Durante a pesquisa, foram criados novos TADs. Estes TADs são tipos de dados
definidos pelo usuário criados obedecendo à sintaxe do SGBD PostgreSQL, sendo
denominados de types. Foram criados os seguintes types: telefone, localidade, rua, região,
bairro, cidade e estado.
A seguir, serão apresentados estes novos tipos de dados, com seu código na linguagem
SQL, especificamente, a linguagem procedural PL/pgSQL, juntamente com uma breve
descrição de alguns deles. Estes novos types serão importantes para a representação dos
elementos do mundo real.
CREATE TYPE LOCALIDADE AS (coordenadas geometry);
O type localidade possui o atributo coordenadas, que indica a
latitude e a longitude de um determinado ponto. Este atributo é um
elemento do tipo geometry. Durante a inserção de dados na tabela
cujo atributo for do tipo localidade, deverá ser inserido um point.
CREATE TYPE RUA AS (nome varchar (100), extensão double
precision, limites geometry);
O type rua possui os atributos nome, extensão e limites. O nome
serve para identificar a rua e indicar se esta é uma rua, travessa
ou avenida. A extensão indica o comprimento da rua, equivalente à
distância entre seu ponto inicial e final. Por sua vez, o atributo
limites indica o ponto inicial e o ponto final da rua. Durante a
inserção de dados na tabela cujo atributo for do tipo rua, deverá
ser inserida uma line no campo limites, expressa pelas coordenadas
de seu ponto inicial e ponto final.
CREATE TYPE REGIAO AS (nome varchar(100), AREA geometry);
O type região possui os atributos nome e área. O nome
identifica a região que está sendo tratada. A área indica o polígono
que geograficamente representa a região. Durante a inserção de dados
39
na tabela cujo atributo for do tipo regiao, deverá ser inserido um
polygon no campo área, expresso pelas coordenadas de seus vértices.
Os types bairro, cidade e estado possuem o atributo descrição,
que indica o nome e a representação geográfica de cada um. Durante a
inserção de dados na tabela cujo atributo for do tipo bairro, cidade
ou estado, deverá ser inserido, no campo descrição, um registro que
contenha um nome e as coordenadas dos vértices de um polígono. O
type estado diferencia-se dos outros dois por possuir o atributo
sigla, que indica a Unidade Federativa (UF) relativa ao estado.
4.2. Criação das funcionalidades
Além dos tipos de dados anteriormente apresentados, foram criadas diversas
procedures para a manipulação destes types. Basicamente, estas procedures dividem-se em
funções de instanciação de types, de cálculo de distâncias e de interseção de elementos
geográficos, mapeados por meio da geometria euclidiana.
A seguir, serão apresentadas as novas funções criadas, com seu código na linguagem
procedural PL/pgSQL, juntamente com uma breve descrição de cada uma delas.
CREATE FUNCTION gerarLocal(x double precision, y double precision)
RETURNS localidade AS $$
DECLARE
l localidade;
BEGIN
l := ROW(ST_MakePoint($1,$2));
RETURN l;
END; $$LANGUAGE plpgsql;
A procedure gerarLocal recebe por parâmetro a latitude e
longitude de um lugar geográfico. Esta procedure cria uma
40
localidade utilizando a função ST_MakePoint, que gera um point
utilizando as variáveis de entrada.
CREATE FUNCTION gerarRua
(nome varchar, xA double precision, xB double precision, yA double precision, yB double precision)
RETURNS rua AS $$
DECLARE
limites geometry; extensao double precision; r rua;
BEGIN
limites:=(SELECT ST_MakeLine(ST_MakePoint($2,$3), ST_MakePoint($4, $5)));
extensao:=(SELECT ST_Distance_Sphere (st_startpoint(limites),st_endpoint(limites)));
r := ROW($1, extensao, limites);;
RETURN r;
END; $$LANGUAGE plpgsql;
CREATE FUNCTION gerarRua
(nome varchar,pontoInicial geometry, pontoFinal geometry)
RETURNS rua AS $$
DECLARE
limites geometry; extensao double precision; r rua;
BEGIN
limites := (SELECT ST_MakeLine($2,$3));
extensao := (SELECT ST_Distance_Sphere
(st_startpoint(limites),st_endpoint(limites)));
r := ROW ($1, extensao, limites);
RETURN r;
END; $$LANGUAGE plpgsql;
A procedure gerarRua recebe por parâmetro as coordenadas dos
pontos inicial e final de uma rua. A variável limites recebe uma
41
linestring construída por meio da função ST_MakeLine. A extensão da
rua é calculada utilizando a função ST_Distance_Sphere, que retorna
em metros a distância entre dois pontos. Assim, a procedure cria e
retorna uma rua com base nos parâmetros de entrada. O trecho de
código SQL anteriormente apresentado contém duas representações
desta função. Na primeira representação, são passadas as coordenadas
X e Y de cada ponto; na segunda, são repassados dois pontos do tipo
geometry. As rotinas de criação de ruas apresentadas neste trecho de
código exemplificam o uso da sobrecarga de métodos no SGBD
PostgreSQL, que representa dois métodos com o mesmo nome, mas com
parâmetros diferentes.
CREATE FUNCTION gerarRegiao(varchar,geometry[])
RETURNS regiao AS $$
DECLARE
geo geometry; vertices integer; reg regiao;
BEGIN
vertices := (SELECT ST_NPoints($2));
FOR i in 1..vertices
LOOP
geo := (select ST_MakeLine($2));
geo := (select ST_AddPoint(geo,$2[1],vertices));
geo := (select ST_MakePolygon(geo));
END LOOP;
reg := ROW($1, geo);
RETURN reg;
END; $$LANGUAGE plpgsql;
A procedure gerarRegiao recebe por parâmetro o nome da região e
um vetor com as coordenadas dos vértices do polígono que representa
esta região. A procedure possui a variável vértices, que recebe o
número de pontos da geometria passada por parâmetro, calculados por
meio da função ST_NPoints. Já a variável geo recebe uma linestring
construída a partir dos valores do vetor passado por parâmetro. Em
42
seguida, é adicionado no final da variável geo o primeiro ponto da
linestring. Esta operação de adição é fundamental para a criação do
polígono que representa a região, pois na criação de polígonos no
PostGis, o ponto inicial deverá ser o último ponto a ser inserido no
polígono, a fim de formar uma geometria fechada (convexa). Dessa
forma, a procedure cria e retorna uma região, armazenando as
informações desta na variável reg.
CREATE FUNCTION gerarBairro (nome varchar, area geometry []) RETURNS bairro AS $$
DECLARE
geo regiao; b bairro;
BEGIN
geo = gerarRegiao($1,$2);
b := ROW(ROW($1, geo));
RETURN b;
END; $$LANGUAGE plpgsql;
As procedures gerarBairro, gerarCidade e gerarEstado tem código
similar. Todas recebem por parâmetro o nome destes e um vetor com as
coordenadas dos vértices do polígono que os representam. Estas
procedures possuem a variável geo, que é utilizada para criação de
uma região, recebendo o nome e o vetor de coordenadas passado por
parâmetro. Dessa forma, a procedure cria e retorna uma região, que
será o valor a ser armazenado no atributo descrição de ambos os
types bairro, cidade e estado. Vale ressaltar que, na procedure
gerarEstado, deve ser passado por parâmetro o valor da sigla que
representa a UF do estado.
CREATE FUNCTION distanciaLocalidades (localidade, localidade)
RETURNS SETOF double precision AS $$
BEGIN
RETURN QUERY SELECT ST_Distance_Sphere($1.coordenadas,$2.coordenadas);
END; $$LANGUAGE plpgsql;
43
A procedure distanciaLocalidades recebe por parâmetro duas
localidades e implementa a rotina da geometria euclidiana do cálculo
da distância entre dois pontos, utilizando a função
ST_Distance_Sphere.
As demais procedures relativas ao calculo de distâncias, como
as procedures distanciaRuas, distanciaRegioes, distanciaLocalRua,
distanciaLocalRegiao e distanciaRuaRegiao tem comportamento similar,
recebendo por parâmetro duas ruas e implementando a rotina da
geometria euclidiana para o cálculo da distância entre as
geometrias, utilizando a função ST_Distance_Sphere.
CREATE FUNCTION cruzamentoRuas(rua, rua) RETURNS text AS $$
DECLARE
message text;
BEGIN
IF (ST_CROSSES($1.limites,$2.limites) = true) OR (ST_TOUCHES($1.limites,$2.limites) = true)
THEN
message := (SELECT ST_AsText (ST_Intersection ($1.limites,$2.limites)));
ELSE IF ST_Disjoint($1.limites, $2.limites)= TRUE
THEN RETURN NULL;
END IF;
END IF;
RETURN message;
END; $$LANGUAGE plpgsql;
A procedure cruzamentoRuas recebe por parâmetro duas ruas e
implementa a rotina da geometria euclidiana para o cálculo da
interseção entre duas retas. Para tanto, são utilizadas as funções
ST_Crosses, que determina se duas retas se cruzam em algum ponto, e
a função ST_Touches, que determina se existem algum ponto onde as
retas se tocam. Caso exista alguma interseção, será retornada a
geometria com esta interseção, utilizando a função ST_Intersection.
44
Em caso negativo, será verificado se não há nenhum ponto em comum
entre as ruas, retornando uma geometria vazia.
CREATE FUNCTION intersecaoRuas(rua, rua)
RETURNS TEXT AS $$
DECLARE
intersecao TEXT;
BEGIN
IF ST_EQUALS($1.area,$2.area)= TRUE) THEN RETURN NULL;
ELSE
IF (ST_OVERLAPS($1.area, $2.area) = TRUE) OR (ST_INTERSECTS($1.area, $2.area) = TRUE)THEN
intersecao := (SELECT ST_AsText (ST_INTERSECTION($1.area,$2.area)));
RETURN 'Região de interseção :||intersecao;
ELSE
IF ST_Disjoint($1.area, $2.area) = true THEN RETURN NULL;
END IF;
END IF;
END IF;
END;
$$LANGUAGE plpgsql;
A procedure intersecaoRuas recebe por parâmetro duas ruas e
implementa a rotina da geometria euclidiana para o cálculo da
interseção entre duas retas. Para tanto, são feitas duas
verificações: na primeira, a função ST_Equals é utilizada para
determinar se não foi passado por parâmetro duas retas iguais. Após
isto, as funções ST_Overlaps e ST_Intersects são utilizadas para
determinar se há uma interseção entre as ruas. Em caso positivo,
será retornada a geometria com esta interseção, utilizando a função
ST_Intersection. Em caso negativo, será verificado se não há nenhum
ponto em comum entre elas, retornando uma geometria vazia.
45
CREATE FUNCTION intersecaoRegioes(regiao, regiao)
RETURNS TEXT AS $$
DECLARE
intersecao TEXT;
BEGIN
IF ST_EQUALS($1.area, $2.area)= TRUE) THEN RETURN NULL;
ELSE
IF (ST_OVERLAPS($1.area, $2.area) = TRUE) OR (ST_INTERSECTS($1.area, $2.area) = TRUE) THEN
intersecao := (SELECT ST_AsText (ST_INTERSECTION($1.area,$2.area)));
RETURN 'Região de interseção :||intersecao;
ELSE IF ST_Disjoint($1.area, $2.area) = true
THEN RETURN NULL;
END IF;
END IF;
END IF;
END; $$LANGUAGE plpgsql;
A procedure intersecaoRegioes recebe por parâmetro duas regiões
e implementa a rotina da geometria euclidiana para o cálculo da
interseção entre dois planos. Para tanto, são feitas duas
verificações: na primeira, a função ST_Equals é utilizada para
determinar se não foi passado por parâmetro dois planos iguais. Após
isto, as funções ST_Overlaps e ST_Intersects são utilizadas para
determinar se há uma interseção entre as regiões. Em caso positivo,
será retornada a geometria com esta interseção, utilizando a função
ST_Intersection. Em caso negativo, será verificado se não há nenhum
ponto em comum entre as regiões, retornando uma geometria vazia.
46
CREATE FUNCTION intersecaoLocalidadeRua (localidade, rua)
RETURNS BOOLEAN AS $$
BEGIN
IF ST_INTERSECTS($1.coordenadas, $2.limites)= TRUE THEN RETURN TRUE;
ELSE RETURN FALSE;
END IF;
END; $$LANGUAGE plpgsql;
A procedure intersecaoLocalidadeRua recebe por parâmetro uma
localidade e uma rua e determina se há interseção entre elas,
utilizando a função ST_Intersects.
CREATE FUNCTION diferencaRuas (rua,rua)
RETURNS SETOF TEXT AS $$
BEGIN
RETURN QUERY SELECT ST_AsText (ST_Difference($1.limites, $2.limites));
END; $$LANGUAGE plpgsql;
A procedure diferencaRuas recebe por parâmetro duas ruas e
implementa a rotina da geometria euclidiana para o cálculo da
diferença A - B, utilizando a função ST_Difference.
CREATE FUNCTION diferencaRegioes (regiao,regiao)
RETURNS SETOF TEXT AS $$
BEGIN
RETURN QUERY SELECT ST_AsText (ST_Difference($1.area, $2.area));
END; $$LANGUAGE plpgsql;
A procedure diferencaRegioes recebe por parâmetro duas regiões
e implementa a rotina da geometria euclidiana para o cálculo da
47
diferença A – B entre elas, utilizando a função ST_Difference. A
procedure diferencaRuaRegiao possui comportamento similar.
CREATE FUNCTION containsLocalidadeRua (localidade, rua)
RETURNS SETOF TEXT AS $$
BEGIN
RETURN QUERY SELECT ST_AsText (ST_WITHIN($1.coordenadas,$2.limites));
END; $$LANGUAGE plpgsql;
A procedure containsLocalidadeRua recebe por parâmetro uma
localidade e uma rua e determina se a localidade está totalmente
contida na rua, utilizando a função ST_Within. As procedures
containsLocalidadeRegiao e containsRuaRegiao possuem comportamento
similar.
CREATE FUNCTION distantePontoPonto (localidade,localidade,double precision)
RETURNS BOOLEAN AS $$
BEGIN
IF ST_DWITHIN($1.coordenadas,$2.coordenadas,$3)= TRUE
THEN RETURN TRUE;
ELSE RETURN FALSE;
END IF;
END;
$$LANGUAGE plpgsql;
A procedure distantePontoPonto recebe por parâmetro duas
localidades e determina se elas estão distante de até X metros uma
da outra, utilizando a função ST_DWithin. As procedures
distantePontoRua, distantePontoRegiao e distanteRuaRegião possuem
comportamento similar.
48
4.3. Comparativo de funcionalidades: BDR, BDE e Solução proposta:
Os types e as procedures criados neste capítulo tiveram como base os recursos do
BDE. Caso estas tivessem sido desenvolvidas com base no BDR, a criação delas seria mais
complexa e dispendiosa. A seguir, serão mostrados alguns exemplos comparativos da
implementação de algumas das funcionalidades desenvolvidas neste trabalho utilizando BDR
e BDE. Para tanto, será ilustrada a criação de uma rua e funções para manipular desta
utilizando BDR, BDE e as funcionalidades desenvolvidas neste trabalho. Este comparativo
será importante para mostrar a importância do BDE nesta pesquisa. Ou seja, por meio das
comparações, será possível mostrar a complexidade de implementação das funcionalidades
demonstradas nos itens anteriores, caso o BDR tivesse sido adotado como metodologia
padrão, em contraste com os recursos que o BDE possui. A seguir, serão mostrados trechos de
código SQL para demonstração deste comparativo.
Tabela 3 – Comparativo de criação da tabela de ruas.
- Tabela Ruas
BDR CREATE TABLE rua ( id integer primary key not null, nome varchar(100) );
CREATE TABLE quarteirao ( id integer primary key not null, x0 double precision, x1 double precision, y0 double precision, y1 double precision, rua integer references rua (id) );
BDE CREATE TABLE rua ( id integer PRIMARY KEY NOT NULL, nome varchar(100), limites geometry );
49
Solução
proposta
CREATE TABLE rua ( id integer PRIMARY KEY NOT NULL, descricao rua );
A Tabela 3 representa a criação da tabela de ruas utilizando os recursos do BDR, BDE
e das funcionalidades desenvolvidas nesta pesquisa. No BDR, faz-se necessária a criação de
duas tabelas: quarteirão, que armazenará as divisões das ruas, que são seus quarteirões, em
termos das coordenadas x e y de seus pontos iniciais e finais; rua, que armazenará o nome da
rua. No BDE será preciso apenas adicionar a coluna limites, que armazenará a geometria
correspondente às informações de seus quarteirões. Já pela solução proposta, a coluna limites
do BD e será substituída pela coluna descrição, do tipo rua. Este tipo de rua é um type com as
informações da rua, correspondentes ao seu nome, seus limites e sua extensão, sendo esta
última a distância entre o ponto inicial e final da rua.
Nos trechos de código da Tabela 3, foram apresentados exemplos de representação
geométrica de uma rua. Suponha-se a existência de uma tabela x de relacionamento entre duas
ruas, com as colunas id e dist. Considerando que, nesta tabela, a coluna dist será utilizada para
armazenar a distância entre as ruas, como este cálculo poderá ser realizado? Para responder a
este questionamento, serão mostrados alguns trechos de código SQL representando a
comparação da criação de rotinas para calcular a distância entre ruas. Serão utilizadas como
base as implementações apresentadas na Tabela 3.
· Comparação 1: BDR x BDE
· BDR
CREATE FUNCTION distanciaPontos (x1 double precision, y1 double precision, x2 double precision, y2 double precision)
RETURNS double precision AS $$
DECLARE
raiz double precision; expoente double precision;
50
BEGIN
expoente := ((SELECT power($1-$3,2)) +
(SELECT power($2-$4,2)));
raiz := sqrt(expoente);
RETURN raiz;
END; $$LANGUAGE plpgsql;
· BDE:
SELECT ST_Distance_Sphere(p1 geometry, p2 geometry);
Na comparação 1, foram apresentados códigos SQL do cálculo de
distância entre dois pontos. A procedure distanciaPontos utiliza as
coordenadas x e y dos pontos e calcula a distância entre estes
utilizando a seguinte fórmula matemática de distância presente na
Figura 11:
Figura 11 – Distância entre dois pontos (Martins, 2013).
Já no BDE, existe uma função especifica da extensão PostGis para cálculo da
distância, não sendo necessária a criação de uma nova procedure. Basta passar por parâmetro
os dois pontos.
51
· Comparação 2: BDE x Solução proposta:
· BDE
SELECT ST_Distance_Sphere(p1 geometry, p2 geometry);
· Solução proposta:
SELECT distanciaLocalidades(localidade, localidade);
Na comparação 2, foram apresentados códigos SQL do cálculo de distância entre dois
pontos utilizando BDE e as funcionalidades criadas nesta pesquisa. Similar à comparação 1, o
BDE utiliza a ST_Distance_Sphere para cálculo da distância. Na solução proposta, foi
desenvolvida uma procedure que recebe suas localidades, com a sua geometria, e calcula a
distância entre elas.
A partir das comparações 1 e 2, é possível notar a vantagem de utilização do BDE em
relação ao BDR no tratamento de dados geográficos por meio da geometria. Os SGBDs com
suporte ao BDE possuem uma extensão espacial com diversas rotinas para manipulação de
dados geográficos. No BDR, faz-se necessária a criação destas rotinas. Em relação ao BDE e
a solução proposta, esta apresenta novas técnicas de utilizar os recursos que aquela provê em
sua extensão espacial.
Vale ressaltar que a solução proposta desenvolvida nesta pesquisa não tem como
objetivo recriar a extensão espacial, mas sim, criar funcionalidades que facilitem o uso de
seus recursos em um sistema com suporte ao BDE. Um exemplo disso pode ser encontrado na
procedure gerarRua. Esta procedure recebe as coordenadas x e y dos pontos inicial e final de
uma rua. A procedure então cria uma rua a partir destas coordenadas, com o auxilio das
funções ST_Makeline e ST_Makepoint. No BDE, a ST_Makeline recebe por parâmetro dois
atributos do tipo geometry. Para um desenvolvedor que irá utilizar BDE em seu sistema,
torna-se menos dispendioso utilizar uma função na qual ele tenha que passar apenas as quatro
coordenadas por parâmetro, do que utilizar uma função na qual este desenvolvedor precise
52
passar uma geometria. No trecho de código SQL a seguir, serão mostrados exemplos das
chamadas das funções ST_Makeline e gerarRua, sendo passados por parâmetro as
coordenadas relativas à Avenida Engenheiro Santana Júnior. Através deste exemplo, é
possível notar outra vantagem da utilização da procedure gerarRua: a possibilidade de passar
por parâmetro o nome da rua, ao invés de somente os valores de sua geometria.
SELECT ST_MakeLine(ST_MakePoint(-3.729082,-38.477957), ST_MakePoint(-3.756695,-38.491454));
SELECT gerarRua ('Avenida Engenheiro Santana Júnior',
-3.729082, -38.477957, -3.756695, -38.491454);
53
5. ESTUDO DE CASO
No capitulo anterior, foi apresentada a criação de um conjunto de funcionalidades para
a manipulação de dados geográficos por meio da linguagem procedural PL/pgSQL . O
conjunto de funcionalidades inclui diversas funções e novos tipos de dados específicos para
BDE.
A aplicação das funcionalidades desenvolvidas será demonstrada na resolução de um
problema do mundo real. Neste problema, todos os recursos disponíveis no conjunto de
funcionalidades serão utilizados como forma de solução do problema e, caso possível, uma
otimização desta solução. Vale ressaltar que o conjunto de funcionalidade está restrito aos
recursos do SGBD PostgreSQL e de sua extensão PostGis.
Diante disso, foi proposto um estudo de caso para aplicação das funcionalidades. Para
tanto, um cenário real será utilizado. Este cenário terá como base a situação problema que foi
apresentada na introdução deste trabalho, onde foi relatado o problema da divergência de
preços finais de produtos em algumas regiões do país.
Depois de apresentado o cenário, serão listados os passos necessários para a criação da
base de dados do problema. Esta base de dados conterá as tabelas, procedures e demais
elementos que forem identificados durante a análise do problema. Para tanto, será gerado um
código na linguagem SQL, que deverá ser adaptado para a sintaxe de comandos do SGBD
PostgreSQL, sendo este o SGBD a ser adotado nesta solução.
54
5.1 Cenário
Durante o capitulo de introdução, foi apresentado um problema real, relativo à
divergência de preços de mercadorias em diversos estabelecimentos do país. Naquele
momento, foi relatado que, dependendo da região onde o produto será comercializado, este
terá um preço alto ou baixo.
Este trabalho propõe um conjunto de tipos e rotinas a serem utilizadas em um sistema
geográfico que permita ao usuário uma maior facilidade no momento da implementação da
solução. Diferentemente da maioria das soluções comumente encontradas que se utilizam
puramente do Modelo Relacional, a solução proposta faz uso do Banco de Dados Espacial e
suas funcionalidades referentes a elementos geográficos.
Como exemplo, foi criada uma base de dados na qual foram mapeados diversos postos
de gasolina, com as informações destes. Os critérios adotados para a coleta de informações
foram dados relativos a tipos de combustíveis comercializados, formas de pagamento, tipos de
serviços fornecidos e lojas conveniadas. Os tipos de produtos são combustíveis, como etanol,
gasolina comum, gasolina aditivada, etanol, gás natural (GNV) e diesel. Vale ressaltar que,
durante a pesquisa, não foram localizados postos de gasolina na cidade de Fortaleza que
possuíssem algum tipo de biocombustível. As formas de pagamento mapeiam os tipos de
cartões de credito que o posto aceita como pagamento da quantidade de combustível que cada
cliente utilizou para abastecer seu veículo. Os tipos de serviço indicam se o posto possui
banco 24 horas, se possui troca de óleo, estacionamento, loja de conveniência do próprio
posto, etc. As lojas conveniadas indicam os estabelecimentos comerciais que ficam
localizados no mesmo espaço geográfico no qual o posto está localizado.
O mapeamento anteriormente apresentado será útil para proprietários de moto, carro,
caminhão e demais veículos, além de moto-taxistas e taxistas cujos veículos possam ser
abastecidos com um dos tipos de combustíveis anteriormente listados. Eles poderão utilizar
um sistema no qual a solução apresentada nesta pesquisa esteja implementada, no sentido de
que localizem postos de gasolina que possam prover uma maior economia ao abastecerem
seus veículos. Nos itens seguintes, serão apresentadas as tabelas e procedures que foram
criadas para a resolução do problema.
55
5.2 Elaboração da Base de Dados
Com base no cenário anteriormente apresentado, será criada uma base de dados
contendo as tabelas, com seus atributos relacionais e espaciais, além de funções específicas
para a resolução do problema relativo a postos de gasolina localizados na cidade de Fortaleza.
Os atributos espaciais da tabela serão criados com base no type geometry, da extensão
PostGis, e nos types que foram criados na solução proposta. Já as funções específicas
utilizarão tanto as funcionalidades do PostGis como das procedures criadas no capitulo
anterior. Além disso, estas procedures desenvolvidas na etapa anterior serão utilizadas
durante a inserção de dados nas tabelas. Nos itens a seguir, serão apresentados o DER e o DR
da base de dados, além de sua implementação na linguagem PL/pgSQL.
5.2.1. Elaboração do Diagrama Entidade-Relacionamento
Na Figura 12, será apresentado o DER da base de dados do sistema, com as entidades
e seus atributos. Vale ressaltar que no DER não são especificados os tipos de dados dos
atributos. Esta Figura 12 ilustra a representação do DER referente ao problema analisado, com
os elementos necessários para tanto.
5.2.2. Elaboração do Diagrama Relacional
Na Figura 13, será apresentado o DR da base de dados do sistema, com as entidades e
seus atributos. Vale ressaltar que os alguns atributos utilizam os tipos criados na solução
proposta. Esta Figura 13 ilustra a diagramação do DR com a representação gráfica das tabelas,
atributos e tipos.
56
Figura 12 – DER Postos de Gasolina.
57
Figura 13 – DR Postos de Gasolina.
5.2.3. Criação do script SQL
A seguir, serão apresentados alguns dos elementos mais importantes que compõem a
base de dados dos postos de gasolina, com as tabelas e procedures mais representativas
· Tabelas:
CREATE TABLE ruas(
idRuas integer PRIMARY KEY NOT NULL,
descricao rua
);
58
CREATE TABLE enderecos(
idEnderecos integer PRIMARY KEY NOT NULL,
rua integer REFERENCES ruas (idRuas),
numero integer,
bairro integer REFERENCES bairros (idBairros),
complemento character varying (100),
cidade integer REFERENCES cidades (idCidades),
estado integer REFERENCES estados (idEstados),
cep character varying (9),
localizacao localidade
);
CREATE TABLE postos(
idPostos integer PRIMARY KEY NOT NULL,
nome character varying(100) NOT NULL,
endereco integer REFERENCES enderecos (idEnderecos),
telefone telefone,
grupo character varying (50)
);
CREATE TABLE combustiveis(
idCombustiveis integer PRIMARY KEY NOT NULL,
tipo character varying(50),
preco double precision NOT NULL,
posto integer REFERENCES postos (idPostos)
);
59
· Procedures:
CREATE FUNCTION distanciaPostoPreco (localidade, combustivel varchar(50)) RETURNS SETOF double precision AS $$ BEGIN RETURN QUERY SELECT distanciaLocalidades ($1, (SELECT e.localizacao FROM enderecos e, postos p WHERE p.endereco = e.idEnderecos AND p.idpostos = (SELECT c.posto FROM combustiveis c WHERE c.tipo = $2 AND c.preco =
(SELECT min(preco) FROM combustiveis WHERE tipo = c.tipo) ) ) );
END; $$LANGUAGE plpgsql;
A procedure distanciaPostoPreco recebe por parâmetro uma
localidade e um tipo de combustível. Internamente, uma consulta é
realizada para localizar os postos de gasolina que e retorna a
distância entre eles, utilizando a função distanciaLocalidades.
CREATE FUNCTION buscaPostosCartao (cartao varchar,ponto localidade, distancia double precision) RETURNS SETOF varchar (100) AS $$ DECLARE registro RECORD; BEGIN FOR registro IN SELECT DISTINCT p.nome AS Posto
FROM pagamentos pg, postos p WHERE pg.posto = p.idpostos AND pg.empresa = (SELECT idcartoes FROM cartoes WHERE descricao= $1) AND p.idpostos IN
(SELECT p.idpostos FROM postos p,enderecos e WHERE e.idenderecos = p.endereco
AND (distantePontoPonto( (SELECT ed.localizacao FROM enderecos ed WHERE ed.idenderecos = e.idenderecos), $2,$3))= TRUE )
ORDER BY p.nome LOOP RETURN NEXT registro.Posto; END LOOP; RETURN; END; $$LANGUAGE plpgsql;
60
A procedure buscaPostosCartao recebe por parâmetro um tipo de
cartão, uma localidade e uma distância e retorna os postos que
aceitem este tipo de cartão, mas que fiquem no máximo a uma
distância x de uma localidade, utilizando a função
distantePontoPonto, que verifica se duas localidades estão distantes
uma da outra em até x metros.
CREATE FUNCTION buscaPostosPreco(coord localidade, preco double precision, combustivel varchar(100), dist double precision) RETURNS SETOF VARCHAR(100) AS $$ $$ DECLARE registro RECORD; BEGIN
FOR registro IN
SELECT DISTINCT p.nome AS Posto, c.tipo AS Combustivel FROM combustiveis c, postos p
WHERE c.posto = p.idpostos AND c.preco < $2 AND c.tipo = $3 AND p.idpostos IN (
SELECT p.idpostos FROM postos p, enderecos e WHERE e.idenderecos = p.endereco AND (SELECT distantePontoPonto( (SELECT ed.localizacao FROM enderecos ed WHERE ed.idenderecos = e.idenderecos), $1.coordenadas,$4)) = TRUE) ORDER BY p.nome, c.tipo DESC
LOOP RETURN NEXT registro.Posto; END LOOP;
END; $$ LANGUAGE plpgsql;
A procedure buscaPostosPreco recebe por parâmetro uma
localidade, um preço de referência, um tipo de combustível e uma
distância e retorna os postos que possuam este tipo de combustível
cujo valor esteja abaixo de um preço x, mas que fiquem no máximo a
uma distância y de uma localidade, utilizando a função
distantePontoPonto.
CREATE FUNCTION buscaPostosPrecoCartao (coord localidade, preco double precision, combustivel varchar(100),dist double precision, cartao varchar) RETURNS SETOF VARCHAR(100) AS $$ DECLARE registro RECORD;
61
BEGIN FOR registro IN SELECT distinct p.nome AS Posto, c.tipo AS Combustível
FROM combustiveis c, postos p, pagamentos pg WHERE pg.posto = p.idpostos
AND pg.empresa = (SELECT idcartoes FROM cartoes WHERE descricao = $5)
AND c.posto = p.idpostos AND c.preco < $2 AND c.tipo = $3 AND p.idpostos IN ( SELECT idpostos FROM postos pt, enderecos e WHERE e.idenderecos = endereco AND(distantePontoPonto( (SELECT ed.localizacao FROM enderecos ed
WHERE ed.idenderecos = e.idenderecos), $1,$4)) = TRUE )
ORDER BY p.nome, c.tipo DESC LOOP RETURN NEXT registro.posto; END LOOP; END; $$ LANGUAGE plpgsql;
A procedure buscaPostosPrecoCartao recebe por parâmetro uma
localidade, um preco de referência, um tipo de combustível , uma
distância e um tipo de cartão e retorna os postos que possuam este
tipo de combustível cujo valor esteja abaixo de um preço x, e que
aceitem este cartão, mas que fiquem no máximo a uma distância y de
uma localidade, utilizando a função distantePontoPonto.
CREATE FUNCTION ruasLocalizacao(endereco localidade) RETURNS SETOF varchar AS$$ DECLARE registro text; contador integer;
BEGIN contador := (SELECT COUNT(*) FROM RUAS);
FOR i IN 1..contador LOOP
registro := (SELECT (r.descricao).nome AS RUA FROM enderecos e, ruas r WHERE e.rua = r.idruas AND (SELECT ST_Intersects( (SELECT (descricao).limites FROM ruas r WHERE idruas = i),$1.coordenadas)) = TRUE );
END LOOP; RETURN registro; END; $$LANGUAGE plpgsql;
A procedure ruasLocalizacao recebe por parâmetro uma localidade
e retorna o nome das ruas que passam por esta localidade, utilizando
a função ST_Intersects.
62
6. CONCLUSÃO
A pesquisa teve como objetivo principal a criação de um conjunto de rotinas para
mapear geometricamente dados geográficos do mundo real. As funcionalidades criadas nesta
pesquisa poderão auxiliar desenvolvedores de sistemas na utilização dos recursos dos bancos
de dados espaciais. Exemplo disso é a rotina de criação de uma região. Para criar a área da
região no PostGis, faz-se necessário inserir os pontos das coordenadas dos vértices, com a
condição de que o vértice final seja também o vértice final pois, em caso negativo, será
disparada uma exceção de que os valores passados não retornam uma geometria convexa. Na
solução proposta, foi criada uma procedure que recebe um vetor de pontos e criada o
polígono correspondente à área desta região. Para um desenvolvedor, torna-se menos
dispendioso utilizar uma rotina na qual ele possa apenas passar o vetor com os vértices do
polígono, do que utilizar outra rotina na qual ele precise estar sempre atento para não passar
por parâmetro uma geometria inválida.
Em suma, a pesquisa objetiva criar uma camada de abstração que possa facilitar o
desenvolvimento de aplicações que utilizem a robustez do banco de dados espacial. Algumas
aplicações, como Google Maps, Google Earth, Wikimapia e demais aplicações que utilizam
mapas possuem alguns dos recursos disponíveis nesta pesquisa. No entanto, durante a
pesquisa, não foi identificado se estas aplicações comerciais utilizam dados relacionais ou
espaciais. Vale ressaltar que esta pesquisa não tem como objetivo reimplementar estas
aplicações, mas criar recursos que facilitem a utilização da robustez do BDE nestas
aplicações.
63
Como trabalhos futuros, podem ser sugeridos:
· Criação de um software que utilizem todos os recursos apresentados nesta pesquisa,
mapeando não apenas postos de gasolina, mas farmácias, hospitais, entre outros
problemas do mundo real. Este mapeamento deverá ser feito não apenas na cidade de
Fortaleza, mas em todo o país.
· Integrar a técnica do banco de dados espacial ao processamento de imagens. O
PostGis possui um conjunto de funções que permitem a vetorização de imagens
digitais, incluindo funções de vetorização e de histograma.
· Desenvolvimento de um framework ou de um gerenciador de conteúdo que
contenham uma interface gráfica para manipulação dos dados geográficos. Esta
ferramenta poderá ser fundamental para a criação de novas procedures e types com
informações espaciais. Este trabalho futuro seria, portanto, uma extensão desta
pesquisa.
· Implementação de uma framework para integração dos recursos do BDE com a API
openGL. O openGL é uma API para a linguagem de programação C que representa
dados do mundo real por meio da geometria.
64
REFERERÊNCIAS BIBLIOGRÁFICAS
ALESSIO, Augusto Colombelli. Bancos de Dados Espaciais. Foz do Iguaçu:
CESUFOZ, 2009.
CÂMARA, Gilberto. Representação computacional de informações geográficas. São
José dos Campos: INPE, 2005.
CÂMARA, Gilberto; QUEIROZ, Gilberto Ribeiro de. Arquitetura de Sistemas de
Informação Geográfica. Belém: UFPA, 2000.
CODD, Edgar Frank. A Relational Model of Data for Large Shared Data Banks. San
José, Califórnia: IBM Research Laboratory, 1969.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. 4ª Ed.
São Paulo: Pearson Addison-Wesley, 2005. cap. 20-22, p. 459-524.
FERREIRA, Karine Reis; QUEIROZ, Gilberto Ribeiro de. Bancos de Dados
Geográficos. Brasília: INPE, 2005.
GUIMARÃES, Célio Cardoso. Fundamentos de Bancos de Dados: Modelagem,
projeto e linguagem SQL. São Paulo: Unicamp, 2008. p. 231-242.
GÜTING, Ralf Hartmut. An Introduction to Spatial Database System. Hagen,
Alemanha: Praktische Informatik IV, Fernuniversität Hagen, 1994.
IBIS. Simple Freatures. Disponível em:
<http://ibis.colostate.edu/WebContent/IBIS/BlueSpray/UsersGuide/Script_SimpleFeat
ures.html>. Acesso em: 30, maio. 2012.
KAUPA, Paulo. Os 4 pilares da Programação Orientada a Objetos. Disponível em: <
http://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264>.
Acesso em: 20, abril. 2013.
LISBOA FILHO, Jugurta. Projeto de Banco de Dados para Sistemas de Informação
Geográfica. Viçosa: Universidade Federal de Viçosa, 2000.
65
MAPS OF WORLD. Disponível em:
<http://www.mapsofworld.com/lat_long/brazil-lat-long.html>.
Acesso em: 31, maio. 2012.
MARTINS, Lucas. Introdução à Geometria Analítica. Disponível em:
<http://www.infoescola.com/matematica/introducao-a-geometria-analitica-bissetriz-
plano-cartesiano/>. Acesso em: 15, junho. 2013.
MEDEIROS, Anderson. O Geoprocessamento e suas tecnologias – Parte 2.
Disponível em:
<http://andersonmedeiros.com/2010/03/13/geotecnologias-parte2/#.T8VjiWXFbIU>.
Acesso em: 15, maio. 2012.
MILANI, André. PostgreSQL: Guia do programador. 1ª Ed. São Paulo: Novatec,
2008.
OLIVEIRA, Evaldo. Introdução a Sistemas de Informações Geográficas. Ed. 14. São
Paulo: Revista SQL Magazine, 2004.
QUADRO, Fernando. Introdução ao PostGis. Disponível em:
<http://www.slideshare.net/fernandoquadro/introduo-ao-PostGis>. Acesso em: 7,
maio. 2012.
RAMAKRISHNAN, Raghu; JOHANNES, Gehrke. Sistemas de Gerenciamento de
Banco de Dados. 3ª Ed. São Paulo: McGraw-Hill, 2008. cap. 23; 28, p. 642-678; 803-
822.
REZENDE, Ricardo. Conceitos Fundamentais de Bancos de Dados. Disponível em:
<http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>.
Acesso em: 11, abril. 2013.
SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistemas de
Banco de Dados. 3ª Ed. São Paulo: Pearson Makron Books, 1999. cap. 1-4, p. 1-150;
cap. 8-9, p. 249-290.
SPACCAPIETRA, Stefano. Space Modeling. Lausanne, Bélgica: Laboratoire de Bases
de Données, 2007.