Modelagem e Projeto de Bancos de Dados Geográficos com Características Temporais

Modelagem e Projeto de Bancos de Dados Geográficos com Características Temporais Gustavo Breder Sampaio, Alexandre Gazola, Jugurta Lisboa Filho Departamento de Informática Universidade Federal de Viçosa (UFV) CEP 36570.000 Viçosa MG Brasil {gustavobreder,agazola,jugurta}@dpi.ufv.br Abstract. This paper describes the support for the modeling of temporal aspects in Geographic Information Systems, using the UML-GeoFrame conceptual data model. It is also presented the extension of the ArgoCASEGEO tool that makes it possible the conceptual modeling of temporal aspects, as well as the implementation proposal in logic-level of these aspects. Resumo. Este artigo descreve o suporte à modelagem de aspectos temporais em aplicações de Sistemas de Informação Geográfica, com base no modelo conceitual de dados UML-GeoFrame. É apresentada também a extensão da ferramenta ArgoCASEGEO para permitir a modelagem conceitual dos aspectos temporais, bem como a proposta de implementação desses aspectos em nível lógico. 1. Introdução Freqüentemente os administradores recorrem a alguma informação espaço-temporal para tomar uma decisão. O sistema que auxilia nesse tipo de decisão é o Sistema de Informação Geográfica (SIG), porque permite recuperar, analisar e apresentar dados geográficos, também conhecidos como dados georreferenciados. Em muitas aplicações de SIG, a importância do tempo é indiscutível. Para se estudar o desmatamento de uma área de floresta, por exemplo, é fundamental que se possa recorrer a dados levantados no passado. Uma grande dificuldade no desenvolvimento desses sistemas é projetar o banco de dados, pois além de armazenar dados descritivos, esse banco também deve armazenar dados espaciais. Porém, utilizando-se um modelo conceitual adequado, esta tarefa pode ser extremamente facilitada. Para solucionar este problema, [Lisboa Filho and Iochpe, 1999] propõem o framework conceitual GeoFrame, atrelado à linguagem UML. Entretanto esse modelo não atendia adequadamente a alguns requisitos necessários para o tratamento de aspectos temporais. [Rocha, L. V. and Edelweiss, N., 2001] descrevem uma extensão a esse modelo que possibilita ao projetista modelar diversos aspectos relativos ao tempo, mas não apresenta nenhuma solução de como essa modelagem deve ser implementada posteriormente. Dessa forma, com o intuito de permitir aos usuários o tratamento de

dados espaço-temporais de um modo simples, tanto conceitualmente como em nível lógico, somente os conceitos essenciais da proposta de Rocha foram utilizados na proposta de extensão de aspectos temporais do modelo UML-GeoFrame e que foram implementados na ferramenta ArgoCASEGEO [Lisboa Filho et al., 2004]. Outro framework conceitual orientado a objetos baseado no GeoFrame e que também pode ser utilizado para projeto de aplicações espaço-temporais é proposto por [Wang et al., 2003]. Este artigo está organizado da seguinte forma: a Seção 2 apresenta uma breve revisão de alguns modelos conceituais específicos para aplicações espaço-temporais propostos na literatura. Na Seção 3 são mostrados os aspectos temporais adicionados ao modelo UML-GeoFrame. A Seção 4 descreve a incorporação desses aspectos à ferramenta ArgoCASEGEO e apresenta regras de transformação de esquemas conceituais para esquemas lógicos, considerando o modelo de dados da biblioteca de componentes espaciais TerraLib. Finalmente, a Seção 5 traz algumas considerações finais. 2. Trabalhos Correlatos Apesar de muitos modelos conceituais de banco de dados geográficos serem encontrados na literatura, nenhum deles é utilizado até hoje em larga escala. Isso pode ser explicado em parte pela grande quantidade de opções de que eles dispõem para representar características espaço-temporais do objeto. Tamanha variedade dificulta o seu uso, como ocorre com o modelo MADS, por exemplo. O MADS (Modeling of Application Data with Spatiotemporal features) [Parent et al., 1999] foi apresentado em 1995 e é uma extensão do modelo ER. Possui um grande poder de expressão e com a adição de ícones ao diagrama, pode-se representar características espaciais e temporais das entidades, atributos e relacionamentos. Um atributo pré-definido chamado status guarda a situação atual de uma instância através dos possíveis valores que pode receber. Esses valores são: not-yet-existing (ainda não existe), active (ativo), suspended (suspendido) ou disabled (desabilitado). Outro modelo conceitual de banco de dados geográficos é o UML+SpatialPVL [Bédard, 1999], que é uma extensão da UML e utiliza estereótipos para representação espaço-temporal. Dois conceitos básicos são utilizados: existência (indica quando um objeto existe na realidade modelada) e evolução (utilizado quando se deseja guardar o histórico das mudanças de um atributo). Uma ferramenta CASE (Perceptory) foi implementada para dar suporte ao modelo UML+SpatialPVL, como uma extensão do software Microsoft Visio. Apesar desta ferramenta permitir que o projetista crie esquemas utilizando os conceitos do modelo UML+SpatialPVL, ela ainda não possui um módulo para geração automática, o que limita bastante o seu uso. Além desses dois modelos, pode-se citar ainda os modelos GeoOOA e OO- TGIS, ambos com suporte à modelagem de aspectos temporais, mas também sem suporte à conversão para o nível lógico. 3. Modelagem de Aspectos Temporais no Modelo UML-GeoFrame Para permitir o tratamento de dados espaço-temporais, novos construtores foram adicionados ao modelo UML-GeoFrame. Essa extensão tem como objetivo tornar simples a modelagem dos aspectos temporais dos dados geográficos. Por exemplo, o

tempo de transação, proposto por Rocha [Rocha et al., 2001], que considera o momento em que a informação existe no banco de dados, não é adotado. Nas aplicações de SIG, o mais importante é saber quando um determinado dado é válido na realidade modelada. O modelo UML-GeoFrame dispõe de duas opções para indicar que uma classe é temporal: Classe Instante ( ) e Classe Intervalo ( ). Usa-se a primeira quando uma informação é válida somente em um determinado ponto no tempo. Nesse caso, o objeto não evolui, pois sua validade se resume a um instante. Por exemplo, quando se deseja representar um acidente que ocorreu em uma rodovia, é essencial associar um instante de tempo a ele. A outra alternativa indica que a informação é válida em um intervalo de tempo, ou seja, entre um valor temporal inicial e um final. Esses intervalos de validade não possuem necessariamente o mesmo tamanho. Além disso, é permitida a evolução do objeto, pois seus atributos podem variar no período correspondente ao seu intervalo de validade. Se uma classe possui o estereótipo ( ), significa que uma alteração em qualquer atributo de um objeto (exceto o identificador) gera uma nova versão do objeto, sendo que a antiga não é perdida. No modelo UML-GeoFrame as classes do domínio de aplicação são modeladas como subclasses das seguintes classes: ObjetoNãoGeográfico ( ), ObjetoGeográfico ( ) e CampoGeográfico ( ). Objetos Não Geográficos não possuem representação espacial. Objetos Geográficos representam fenômenos discretos e podem possuir representação espacial pontual ( ), linear ( ) ou poligonal ( ). Campos Geográficos caracterizam fenômenos que variam continuamente no espaço. Algumas de suas representações espaciais mais utilizadas são grade de células ( ), isolinhas ( ) e TIN ( ). Um estereótipo temporal de Instante ou Intervalo pode ser adicionado a qualquer classe, transformando-a em uma classe temporal. Na Figura 1, são mostrados exemplos de classes hipotéticas com estereótipos temporais. ObjetoNãoGeográfico ObjetoGeográfico CampoGeográfico Instante Intervalo Figura 1. Classes temporais no modelo UML-GeoFrame

Em uma classe temporal, deve-se especificar a granularidade da informação. O modelo UML-GeoFrame suporta três opções de granularidades: Date, Time e Timestamp. A opção Date indica que apenas a informação de data é armazenada. Esta é a opção padrão. Já a opção Time indica que apenas a informação de horário é armazenada. Por fim, a opção Timestamp indica que ambas as informações (data e hora) devem ser armazenadas no banco de dados. Dessa forma, cada objeto ou cada versão do objeto (para classes que possuem o estereótipo ) tem associado a ele uma informação temporal juntamente com a granularidade escolhida. É importante que o projetista entenda quais classes devem ser modeladas como temporal. Três casos são analisados a seguir: a) Classes em que se deseja guardar a evolução de seus objetos devem receber o estereótipo temporal do tipo intervalo ( ). Nesse caso, uma forma especial de armazenamento precisa ser criada no banco de dados, permitindo que novas versões do objeto sejam criadas para armazenar sua evolução; b) Classes em que seus objetos variam com o tempo, mas não é de interesse da aplicação guardar essa evolução, não devem receber nenhum estereótipo temporal. Nesse caso, fica indicado que os objetos são armazenados de forma tradicional. Toda vez que houver uma mudança, o valor antigo é sobrescrito; c) Classes em que seus objetos existem apenas em um ponto no tempo devem receber o estereótipo do tipo instante ( ). Além de permitir a inclusão de temporalidade em classes (com a conseqüente e automática propagação para seus atributos), o modelo UML-GeoFrame permite representar associações temporais, identificadas pelo estereótipo <<temp>>. A validade de uma associação, ou seja, o período de tempo em que a mesma existe, pode ser definida como a interseção dos períodos de validade dos objetos das classes envolvidas na associação. Isto porque não é possível um relacionamento existir num instante de tempo em que um objeto de uma das classes participantes desse relacionamento não exista. Assim, considerando T como esse período de interseção, tem-se: Associação temporal sua validade deve estar contida no intervalo T. Isto é, a associação deve permanecer válida no máximo pelo período de tempo no qual ambos os objetos coexistam no tempo; Associação não temporal sua validade é igual ao intervalo T. Nesse caso, a interpretação é a mesma dada a relacionamentos convencionais, onde a associação permanece válida enquanto os objetos coexistirem no tempo. As subseções seguintes ilustram os conceitos de classes e associações temporais, por meio de alguns exemplos. 3.1. Exemplo de Associação entre Classes com Temporalidade do Tipo Intervalo A Figura 2 exibe uma associação entre duas classes temporais do tipo Intervalo. Nesse exemplo, o projetista poderia estar interessado em relacionar informações temporais sobre países e epidemias que ocorrem nesses países. A classe País possui informações sobre nome, população e PIB. Os atributos população e PIB variam no tempo, caracterizando País como uma classe temporal do tipo Intervalo. A classe Epidemia é responsável por tratar os diversos tipos de epidemia que podem ocorrer em determinado

país. A temporalidade da classe Epidemia é importante pela necessidade de se observar sua evolução no tempo, bem como possíveis períodos de início e erradicação da mesma. Neste exemplo, utilizou-se uma associação não temporal. A diferença entre uma associação temporal e uma não temporal é que, no primeiro caso, relacionamentos que não são mais válidos no presente continuam sendo mantidos no banco de dados, ou seja, continuam válidos apenas para o período em que ocorreram. Já na associação não temporal, somente os relacionamentos válidos no presente é que são mantidos no banco de dados. Figura 2. Exemplos de associação entre classes temporais do tipo Intervalo 3.2. Exemplo de Associação entre Classes com Temporalidade do Tipo Instante e Classes não Temporais A Figura 3 exibe um exemplo de uma associação entre as classes Rodovia e Acidente. A classe Rodovia não possui temporalidade associada, pois o projetista optou por não armazenar informações relativas à evolução ou período de existência de uma rodovia. Por outro lado, a classe Acidente está modelada como sendo temporal do tipo Instante, caracterizando o instante de tempo em que o acidente ocorreu. A associação (não temporal) entre essas classes representa que, em cada rodovia, podem ser verificados zero ou muitos acidentes. Figura 3. Exemplos de associação entre uma classe temporal Instante e uma classe não temporal Para classes não temporais, considera-se como período de validade de seus objetos todo o eixo temporal. É o que ocorre com os objetos da classe Rodovia. A classe Acidente, caracterizada como temporal do tipo Instante, possui informações válidas somente em um determinado ponto do tempo. 3.3. Exemplo de Associação entre Classes com Temporalidade do Tipo Instante e Classes com Temporalidade do Tipo Intervalo Como um último exemplo, considere a associação exibida na Figura 4, entre as classes Incêndio e Edificação. A primeira é modelada como objeto não geográfico, mas temporal do tipo Instante, representando que um incêndio pode ocorrer em um

determinado ponto do tempo. A segunda é a classe Edificação, que modela as edificações existentes e seus tipos, como casas, prédios, etc. A classe Edificação é temporal do tipo Intervalo pelo fato de uma edificação possuir um período de existência, caracterizado pelo instante de inauguração da edificação e o instante de demolição da edificação. A associação (não temporal) entre essas duas classes denota que, em cada edificação, podem ter ocorrido nenhum ou muitos incêndios. Figura 4. Exemplos de associação entre uma classe que possui estereótipo Instante e uma classe que possui estereótipo Intervalo 4. Implementação dos Aspectos Temporais na Ferramenta ArgoCASEGEO ArgoCASEGEO [Lisboa Filho et al., 2004] é uma ferramenta CASE que tem como objetivo dar suporte à modelagem e projeto de bancos de dados geográficos com base no modelo UML-GeoFrame. ArgoCASEGEO foi implementada como uma extensão do software ArgoUML [Tigris, 2005]. Portanto, é escrita em Java e com código-aberto. Para tornar a ferramenta ArgoCASEGEO habilitada para a modelagem de informação temporal, foram inseridos os novos construtores do modelo UML-GeoFrame, descritos na seção anterior. O Módulo Gráfico da ArgoCASEGEO foi o primeiro a ser estendido para suportar aspectos temporais, ou seja, para permitir a inclusão dos estereótipos ( ) e ( ). Além disso, o projetista deve informar qual a granularidade temporal de cada classe temporal. Para uma classe que não é temporal, a ArgoCASEGEO não permite indicar granularidade e para uma classe temporal não é permitido ter mais de uma granularidade. A ferramenta ArgoCASEGEO armazena o esquema conceitual de dados em um arquivo XMI através do Módulo Dicionário de Dados. Novas tags foram adicionadas ao esquema XMI para armazenar as características temporais do objeto. Como exemplo, a Figura 5 exibe um trecho do arquivo gerado para uma classe chamada Imagem_Satélite, a qual está definida como sendo temporal do tipo Instante com granularidade Timestamp.

<Foundation.Core.GeographicField xmi.id="xmi.2" xmi.uuid="-64--0-43-1c0b8a0:1025e1f0:-7ffd"> <Foundation.Core.ModelElement.name> Imagem_Satélite </Foundation.Core.ModelElement.name> <Foundation.Core.GeneralizableElement.isGridOfCels xmi.value="true"/> <Foundation.Core.GeneralizableElement.isAdjPolygons xmi.value="false"/> <Foundation.Core.GeneralizableElement.isIsolines xmi.value="false"/> <Foundation.Core.GeneralizableElement.isGridOfPoints xmi.value="false"/> <Foundation.Core.GeneralizableElement.isTIN xmi.value="false"/> <Foundation.Core.GeneralizableElement.isIrregularPoints xmi.value="false"/> <Foundation.Core.GeneralizableElement.isInterval xmi.value="false"/> <Foundation.Core.GeneralizableElement.isInstant xmi.value="true"/> <Foundation.Core.GeneralizableElement.isTimeGranularity xmi.value="false"/> <Foundation.Core.GeneralizableElement.isDateGranularity xmi.value="false"/> <Foundation.Core.GeneralizableElement.isTimestampGranularity xmi.value="true"/> Figura 5. Definição da classe Imagem_Satélite no formato XMI 4.1 Transformação Conceitual-Lógico A ferramenta ArgoCASEGEO possui um Módulo de Geração Automática (MGA) de esquema no nível lógico. Como não existe um modelo padrão para SIG, cada software possui um modelo de implementação próprio. Assim, a ArgoCASEGEO possui um MGA para alguns sistemas comerciais e também um MGA para a biblioteca TerraLib [Câmara, et al., 2000]. TerraLib é uma biblioteca de código aberto, com classes e funções escritas em C++ para a construção de aplicações de SIG. Com o objetivo de validar a extensão temporal proposta para o modelo UML- GeoFrame, neste trabalho optou-se por estender o MGA-TerraLib para possibilitar a especificação do esquema de dados lógico considerando os aspectos temporais descritos anteriormente. Assim, a partir do arquivo XMI o MGA-TerraLib transforma um esquema conceitual UML-GeoFrame em um esquema de dados lógico da TerraLib. As regras de transformação são definidas com base no modelo relacional, seguindo o esquema da TerraLib. Logo, deve-se especificar uma chave primária em cada classe para que essa transformação possa ser realizada corretamente. A seguir, as duas regras de transformação dos aspectos temporais são apresentadas. Regra 1: Classes temporais Os atributos definidos para uma classe dão origem a atributos em uma relação correspondente. Para as classes temporais do tipo Instante as regras são bastante simples. Além dos atributos descritivos e geométricos, é adicionado um atributo temporal instante, que possui o domínio definido de acordo com a granularidade especificada para a classe correspondente. Como exemplo, na Figura 6 são mostrados os esquemas das relações gerados para as classes A, B e C mostradas na Figura 1. Considerou-se que o primeiro atributo é a chave primária. Os campos object_id e limit que aparecem em algumas relações são criados para fazer referência à geometria do objeto. Para facilitar a compreensão, a chave primária está sublinhada.

A: A1 instante A2 A3 B: B1 instante B2 B3 object_id C: C1 instante C2 C3 object_id limit Figura 6. Esquemas gerados para três classes temporais do tipo Instante Para classes temporais do tipo Intervalo que possuem uma chave primária (PK) e outros atributos (OA), uma relação é criada com a PK. As chaves estrangeiras, caso existam, também são acrescentadas à essa relação. Além disso, outra relação é criada para armazenar as versões de seus objetos. Para garantir a integridade, também é feito um relacionamento 1..N entre a primeira relação e a relação de versões. A chave primária da relação de versões é composta pela PK mais um atributo temporal. Logo, a relação de versões possuirá os seguintes atributos: chave primária = (PK + inicio); demais atributos = (fim + OA) A Figura 7 exibe os esquemas das relações geradas para as classes D, E e F mostradas na Figura 1. Os atributos temporais início e fim possuem granularidade especificada no painel da classe correspondente. O asterisco indica que o atributo é chave estrangeira. D: D1 D_versões D1* inicio fim D2 D3 E: E1 E_versões E1* inicio fim E2 E3 object_id F: F1 F_versões F1* inicio fim F2 F3 object_id limit Figura 7. Esquemas gerados para três classes temporais do tipo Intervalo Regra 2: Associações temporais Dada uma associação temporal, seja qual for sua multiplicidade, uma nova relação é criada com as chaves primárias das classes envolvidas (semelhante a um relacionamento N..N). Essa nova relação é necessária para guardar o período de validade da associação. Para isso, dois atributos temporais que indicam o início e o fim de validade daquela associação estão presentes.

Pode-se perceber que alguns esquemas gerados são equivalentes do ponto de vista das informações que eles podem armazenar. Para exemplificar, é feita uma adaptação em parte de um esquema conceitual encontrado em [Rocha et al., 2001] sobre abastecimento de água. A Figura 8 mostra duas classes. Deseja-se criar uma associação entre elas de forma que, para cada ponto de captação, seja possível guardar dados sobre coleta de amostras do recurso hídrico ao qual aquele ponto pertence, sendo estas amostras feitas em instantes diferentes. Figura 8. Classes de um esquema sobre abastecimento de água Uma maneira de se fazer isso é criar uma associação que represente que cada ponto de captação possui várias amostras. A Figura 9 ilustra essa opção. A Figura 10 exibe, respectivamente, os esquemas das relações PontoCaptação, PontoCaptação_versões e ColetaAmostra, gerados a partir desse esquema. Figura 9. Associação não temporal entre PontoCaptação e ColetaAmostra PontoCaptação: código PontoCaptação_versões código* inicio fim vazão níveltrechorh object_id ColetaAmostra código instante nívelph condiçãoamostra codpontocaptação* Figura 10. Esquemas gerados a partir de uma associação não-temporal Uma alternativa é criar uma associação temporal, indicando que cada ponto de captação possui apenas uma amostra em um mesmo instante de tempo. A Figura 11 exibe o esquema utilizando essa abordagem. Na Figura 12 têm-se, respectivamente, os esquemas das relações PontoCaptação, PontoCaptação_versões, ColetaAmostra e PontoCaptacão_ColetaAmostra (relação que guarda os relacionamentos) gerados pela transformação automática do esquema conceitual de dados.

Figura 11. Associação temporal entre PontoCaptação e ColetaAmostra PontoCaptação: código PontoCaptação_versões código* início fim vazão níveltrechorh object_id ColetaAmostra código instante nívelph condiçãoamostra PontoCaptação_ColetaAmostra: codpontocaptação* codcoletaamostra* início fim Figura 12. Esquemas gerados a partir de uma associação temporal O projetista pode optar pela segunda opção para expressar melhor a associação. Porém, há um inconveniente: os atributos inicio e fim da relação PontoCaptação_ ColetaAmostra (que contêm os relacionamentos) são redundantes, pois o único valor que eles podem assumir é o instante de validade da coleta da amostra. Esse controle deve ser feito pela aplicação, assim como ela também não deve permitir que, em um mesmo instante, um ponto possua mais de uma amostra, visto que isso é incompatível com o que foi especificado. 6. Conclusões Este artigo apresentou técnicas de modelagem de aspectos temporais em uma aplicação de Sistema de Informação Geográfica. Foram discutidas algumas alternativas de modelagem espaço-temporal, com a conseqüente proposta de extensão do modelo UML-GeoFrame e sua implementação na ferramenta ArgoCASEGEO. Foram descritas as regras de transformação dos aspectos temporais, tendo como origem um esquema conceitual de dados no modelo UML-GeoFrame e como destino o esquema lógico de dados da biblioteca de componentes espaciais TerraLib. Dessa forma, ilustrou-se como modelar as informações espaço-temporais, tanto em nível conceitual (UML-GeoFrame) quanto em nível lógico (TerraLib). Agradecimentos Este trabalho foi parcialmente financiado pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico CNPq, entidade governamental brasileira promotora do desenvolvimento científico e tecnológico e pela Fapemig Fundação de Amparo à Pesquisa do Estado de Minas Gerais.

Referências Bédard, Y. (1999), Visual modelling of spatial databases towards spatial extensions and UML. In Geomatica, v.53, n.2. Câmara, G. et al. (2000), TerraLib: Technology in Support of GIS Innovation. In II Brazilian Symposium in Geoinformatics, GeoInfo2000, São Paulo. Lisboa Filho, J. and Iochpe, C. (1999), Specifying analysis patterns for geographic databases on the basis of a conceptual framework. In Proc.7th ACM GIS, Kansas City. Parent, C. et al. (1999), Spatio-temporal conceptual models: data structures + space + time. In Proc.7th ACM GIS, Kansas City. Rocha, L. V. and Edelweiss, N. (2001), GeoFrame-T: um framework conceitual temporal para aplicações de Sistemas de Informação Geográfica. Porto Alegre: PGCC da UFRGS. Dissertação de Mestrado. Tigris: ArgoUML Project Home. (2005). Disponível em http://argouml.tigris.org/ Wang, K., Fierbinteanu, C. and Maekawa1, M. (2003), A conceptual framework for spatiotemporal data modeling. In DEXA 2003, LNCS 2736, pp. 57 66, Prague, Czech Republic.