O geoprocessamento é uma disciplina com uma vasta área de aplicações e fornece informações muito importantes através de imagens e dados para diversas áreas. Dados – esse é um componente muito importante para o geoprocessamento. Afinal, o que seria para esta disciplina somente as imagens vetoriais sem os dados? Seriam imagens vetoriais e não necessitariam de processamentos de dados algum. A manipulação de seus dados são de grande importância para que estes sejam confiáveis, íntegros e redundantes. Por outro lado não podemos nos esquecer que uma imagem vale mais do que mil palavras.
Primeiro vamos a nossa introdução: O primeiro tipo de banco de dados a ser comercializado foi o banco de dados em rede ou reticular, também chamado de CODASYL – Conference on Data System) ou DBTG ( Database Task Group). Em seguida surgiu o Banco de Dados Hierárquico e a sua implementação mais popular foi o IMS ( Information Management System). Esses dois modelos de Banco de Dados eram conhecidos como sistema de navegação e eram complexos e de difícil manutenção e os relacionamentos eram definidos através de ponteiros.
Em 1970 o Dr. E. F. Codd propôs o modelo relacional para o sistema de banco de dados. Este modelo é baseado na teoria dos conjuntos e as operações sobre as relações (tabelas) são as operações da teoria dos conjuntos.
Mais recentemente surgiram os banco de dados Objeto-Relacional que se propõem a serem tanto banco de dados Relacionais como banco de dados orientados a objeto, os banco de dados geográficos que possibilitam a armazenagem de grandes imagens como por exemplo o campo oid no PostGIS que são definidos para Large Object e o campo Shape do Geodatabase da ESRI que é um campo muito especial e capaz de armazenar uma quantidade enorme de dados seja de imagens ou de vetores, e outros banco de dados como os utilizados para mapeamento genético como o Gerenciador de dados de genoma, Banco de dados Móvel, Banco de dados Multimídia, Banco de dados Distribuídos etc.
Como foi abordado no post anterior, a facilidade de manipulação de dados no PostGIS ficou muito fácil e os comandos de manipulação de dados SQL - Structured Query Language ficaram muito fáceis e amigáveis para qualquer leigo no assunto e foi possível a inserção de dados vetoriais com apenas um único clique usando o Quantum GIS. Em relação às imagens foram necessários alguns comandos muito simples de inserção e seleção.
No ArcMap 9.3 , a manipulação de dados é tão fácil e automático que muitas vezes pensamos não ser necessário ter conhecimento de banco de dados. A facilidade e automaticidade são muito importantes e produtivos mas o conhecimento de banco de dados é importante no sentido de evitar que os dados se tornem não redundantes e não confiáveis.
Por exemplo, a seguinte imagem pode fornecer dados corretos mas será que é preciso a criação de tantas colunas para dados de apenas um local que possui algumas agências ou órgãos? Essa imagem é só um exemplo porque a verdadeira tabela de uma empresa, continha cerca de 120 colunas e isso prejudica a realização de junção (JOIN) com tabelas de um banco de dados relacional.
E nesta outra imagem que contém dados somente para exemplo, os dados serão recuperados mas como será a sua recuperação em um sistema de informações?
No início eu até fiz tabelas como essas demonstradas e só fui descobrir a dificuldade de manipular os dados mais tarde quando tive que desenvolver aplicativos para web. Outros pontos que não são recomendáveis para o bom funcionamento de um banco de dados é nomear as tabelas e as suas respectivas colunas, ou seja os cabeçalhos, usando acentuação, espaços e caracteres especiais porque pode ser que comprometa a sua utilização em um possível aplicativo a ser desenvolvido como por exemplo nesse trecho de código de programação:
String sql = “ SELECT identificação, organização, ação de espera, todos os documentos FROM tabela ação;”
Se alguém estiver programando em Java ou Action Script provavelmente poderá ter problemas assim como se alguém criar esses campos no shapefile em seguida criar um serviço de mapas para depois chamar o serviço REST - Representational State Transfer - destes campos certamente poderá ter problemas. Esse código não terá problemas se for chamado como o trecho a seguir:
String sql = “SELECT identificacao, organizacao, acao_de_espera, todos_os_documentos FROM tabela_acao;”
Nesses dois exemplos acima nós poderíamos dividir as tabelas e usar o comando SQL JOIN (junção) para unir os dados das duas tabelas usando a chave primária e a chave estrangeira. E é justamente isso que será abordado neste e nos posts seguintes. O DBA – Database Administrator ( Administrador de Banco de Dados ) Tiago Campos irá dar algumas considerações sobre a matéria.
Eu penso que não é necessário ser um DBA ou ter um conhecimento equivalente a este para manter as tabelas relevantes na programação para geoprocessamento mas entender os conceitos básicos da matéria como por exemplo: os comandos de manipulação de dados SQL , a DML – Data Manipulation Language, os conceitos de chave primária e chave estrangeira, o conceito de índice, o conceito de JOIN, a cardinalidade e relacionamentos e a normalização é recomendável.
A importância também de conhecer os conceitos de banco de dados é porque o programador de geoprocessamento não precisa ter os privilégios necessários para a criação de uma tabela no banco de dados relacional mas ele é responsável pela criação e manipulação das tabelas de um shapefile assim como as suas respectivas junções (JOINS), a sua cardinalidade (um para um, muitos para um ou um para muitos e muitos para muitos), criação das chaves primárias e estrangeiras e a observação das formas normais de criação de tabelas.
O ArcMap 9.3 possui a opção de fazer JOIN com uma tabela de um banco de dados relacional e fornece as possíveis colunas candidatas a chave estrangeira para fazê-lo conforme as conexões feitas no ArcCatalog 9.3. Este sem dúvida é um grande gerenciador de banco de dados porque nele é possível fazer uma conexão com vários SGBDs – Sistemas Gerenciadores de Banco de Dados com apenas um clique no botão direito e com as janelas de assistência não necessitando de inserção de códigos nem comandos SQL. Mais um ponto para a observação das chaves primárias e estrangeiras porque se estas estiverem corretas e definidas com um identificador comum nas tabelas de diferentes SGBDs ( por exemplo: Oracle, SQL Server, PostgreSQL , SDE Geodatabase, etc.), o ArcMap 9.3 poderá fazer JOINS entre as tabelas unindo-as todas em uma única tabela automaticamente somente com as suas janelas de assistência e com as conexões do ArcCatalog 9.3.
Somente para reforçar a importância do que foi dito anteriormente: no artigo postado anteriormente sobre SOAP no FLEX foi feito um JOIN de uma tabela de um shapefile que estava em um serviço no ArcGIS Server 9.3.1 com um web service SOAP de um serviço do Business Intelligence Pentaho. Isso só foi possível por causa dos identificadores comuns das chaves primárias e estrangeiras e o resultado foi a visualização de dados de um Business Intelligence nos serviços de mapas do ArcGIS Server 9.3.1 com dados provenientes de um Data Warehouse.
Como neste post será abordado os conceitos gerais e introdutórios e as opiniões de um desenvolvedor de sistemas web para geoprocessamento, vamos abordar a respeito da importância da normalização na criação das tabelas seja de bancos de dados relacionais ou de bancos de dados geográficos.
A tabela seguinte pode não apresentar erros mas notem que ela está sujeita a ter dados de difíceis manipulação e manutenção porque contém dados repetidos não estando conforme a primeira forma normal:
Notem que conforme a inserção dos dados nos campos ela poderá conter dados que podem dificultar a sua manipulação por isso é muito importante observar a normalização.
No livro Sistema de Banco de Dados 4ª Edição dos autores Rames Elmasri e Shamkant B. Navathe, diz que na primeira forma normal (1FN) “Estabelece-se que o domínio de um atributo só deva incluir os valores atômicos (simples, indivisíveis), e que o valor de qualquer atributo em uma tupla deve ter um único valor no domínio daquele atributo.” Na obra “SQL Server 2005 Administração & Desenvolvimento – Curso Completo” de Júlio Battisti encontramos que “Uma tabela está na Primeira Forma Normal quando seus atributos não contêm grupos de repetição.” Neste mesmo livro o autor cita o conceito de chave primária: “ …o campo Chave Primária identifica de maneira única cada registro de uma tabela, isto é, de posse do valor da chave primária somente localizaremos um registro com aquele valor no campo Chave Primária.”. Mas a Chave Primária pode não ser uma única coluna então passaremos a ter mais colunas como chave primária tornando a tabela como possuidora de chave primária composta.
Voltando ao conceito de normalização para responder a uma pequena dúvida: Mas o que fazer se um determinado estado possuir ilhas como o estado do Pará por exemplo e não for possível a separação nas tabelas? Nesse caso não é possível ter somente dados atômicos e terão dados repetidos mesmos a não ser que seja criada uma outra regra no seu projeto de banco de dados assim como na Tabela_pedido da figura acima a coluna “idregiao” que possui dados repetidos. Para separar esses dados a fim de que se tornem dados não repetitivos é preciso avaliar o seu custo-benefício. Seguir os conceitos de normalização não irá garantir que as tabelas criadas ou o projeto de banco de dados tenham somente dados íntegros e redundantes. No livro Sistema de Banco de Dados os autores dizem que: “ A normalização de dados pode ser vista como o processo de análise de determinados esquema de relações com base em Dfs e chaves primárias para alcançar as propriedades desejáveis de: (1) minimização de redundância e (2) minimização de anomalias de inserção, exclusão e atualização…” . Ou seja, tudo o que foi dito até agora é para minimizar possíveis falhas, dificuldades de manipulação, facilidade de busca e minimização de redundâncias. Afinal na Tecnologia da Informação não é possível estabelecer uma padronização de acontecimentos e os desafios fazem com que tanto a área de TI quanto a área de geoprocessamento tornem se mais atraentes e desafiadores.
Este post inicial foi mais conceitual e os próximos serão mais técnicos e realmente dirigidos para o SGBD PostgreSQL desde a sua instalação até os comandos necessários para uma boa integração de dados de um banco de dados relacional com uma tabela de um banco de dados geográfico.
Bibliografia:
_ ELMASRI, Rames; NAVATHE, Shamkant B. Sistema de Banco de Dados. Pearson. 4ª Edição. 2005.
_ BATTISTI, Júlio. SQL SERVER 2005 ADMINISTRAÇÃO & DESENVOLVIMENTO CURSO COMPLETO. Axcel. 2005 .
