Modelo relacional da App e Servidor

Para manter o registo de todos os avistamentos foram criadas duas bases de dados. Uma base de dados no lado servidor e uma outra que funcionará em cada dispositivo móvel com a aplicação instalada. São ainda documentadas as alterações feitas para o caso de estudo da Cortaderia

selloana.

4.2.3.1 Modelo relacional da App

Cada dispositivo móvel terá uma base de dados onde serão armazenados todos os dados relevantes para a navegação na aplicação. Esta base de dados serve como um bloco de notas para todos os eventos e avistamentos registados, quer estes sejam submetidos ou não.

Para cumprir pontos descritos nos requisitos funcionais, acima referidos, é relevante guardar o nome da espécie observada, uma pequena descrição desta ou informação adicional sobre o meio onde esta está inserida, a data, a localização que pode ser apenas um ponto geográfico ou um conjunto de pontos (área representada através de um polígono), identificação do tipo de espécie (e.g., plantas, aves), campo para guardar informação sobre cada foto adicionada e ainda a identificação do evento a que este pertence. O identificador do evento é uma chave para outra tabela. É também armazenada informação sobre se o avistamento já foi submetido e se este está completo (campos obrigatórios preenchidos). Sendo atribuído o valor de zero nos casos em que o avistamento não foi submetido ou não está completo. Esta informação é especialmente útil para adaptar a interface gráfica no dispositivo móvel.

Da primeira vez que a aplicação é executada, são criadas as tabelas representadas na Figura4.3 que contêm a informação descrita anteriormente.

28 Capítulo 4. Sistema Gaia

Figura 4.3: Modelo relacional do dispositivo móvel.

4.2.3.2 Modelo relacional do Servidor

No lado do servidor é utilizada uma base de dados que vai receber todos os dados dos avistamentos submetidos pelos dispositivos móveis bem como os dados dos utilizadores registados na aplicação.

Relativamente aos avistamentos, para além do nome da espécie, descrição, data, fotos, localização, tipo de espécie (e.g., ave, mamífero) é ainda adicionada informação acerca do Concelho e respetivo Distrito onde o avistamento foi criado. Estes dois últimos são adicionados depois de o avistamento ser submetido e antes de ser adicionado à base de dados do servidor. O evento não é guardado do lado do servidor pois apenas é utilizado no dispositivo móvel de maneira a organizar os avistamentos. Cada avistamento tem ainda um campo de utilizador que identifica conta da pessoa que submeteu o avistamento. Este último campo trata-se de uma chave para a tabela que guarda a informação dos utilizadores registados, tabela essa que guarda informação como o primeiro e último nome, email, tipo de utilizador (e.g., normal ou administrador), e ainda dois campos que se destinam à encriptação da password. Cada avistamento pode ainda ter uma ou mais acções associadas. Esta tabela destina-se a guardar informação acerca do avistamento em causa, a data, o email do utilizador que adicionou a ação (normalmente este é um processo destinado a utilizadores com permissão de administrador) o tipo de ação efetuada (e.g., entrada, verificada ou removida) e a data em que esta ocorreu. Relativamente à tabela com a informação acerca dos utilizadores registados, existem dois tipos: os que submetem os avistamentos através da aplicação móvel (normal) e o responsável por gerir toda a informação recebida (administrador). A base de dados encontra-se representada na Figura 4.4.

4.2. Arquitetura dos componentes 29

Figura 4.4: Modelo relacional do servidor.

4.2.3.3 Alterações feitas no âmbito do caso de estudo da Cortaderia selloana

Dado o âmbito mais reduzido do projeto e depois de conhecidas as principais preocupações para com a espécie em causa, foi necessário redefinir toda a estrutura de dados tanto do lado do dispositivo móvel como no lado servidor.

Relativamente à aplicação móvel, foi utilizado o processo já descrito na Subsecção 4.2.3.1. Retirou-se o conceito de que os avistamentos estariam de estar associados a um evento, existindo assim apenas uma tabela onde são armazenados todos os dados recolhidos representada na Figura 4.5. Como a aplicação se destina ao registo de avistamentos de apenas uma espécie, a Cortaderia selloana, não é necessária a identificação da espécie. Para além dos campos da descrição, data, submissão, completo, fotos e localização que já foram previamente descritos, foram adicionados três novos campos. A densidade, que guarda informação sobre a quantidade de plantas que existe no avistamento (e.g., menos de 10, de 10 a 20, mais de 20). Outro dos campos foi o estado, onde representa a informação acerca do estado fenomenológico da planta (e.g., só folha, em flor, com fruto). E por fim o habitat que, como o próprio nome indica, guarda informação acerca do tipo de local onde foi registado o avistamento. Na Figura 4.5 temos a base de dados ilustrada.

30 Capítulo 4. Sistema Gaia

Figura 4.5: Modelo relacional do dispositivo móvel (Cortaderia).

Quanto ao servidor, para além de adicionar a informação recolhida através do dispositivo móvel foram ainda alterados os tipos de acções possíveis, como podemos confirmar pela Figura4.6. Sendo agora considerados três tipos de ação: entrada, intervencionada e exterminada. A primeira é aplicada quando o avistamento chega pela primeira vez ao servidor. A segunda indica algum tipo de intervenção física na planta quer seja através herbicida ou outro tipo de ação similar. E por último temos a exterminada que indica que a planta foi completamente removida do local. Cada ação para além da data e descrição da mesma, o administrador que adiciona a ação associa esta ao técnico que levou a cabo intervenção física. Relativamente à base de dados que armazena os dados dos utilizadores, são considerados três tipos: os que apenas submetem informação da aplicação móvel para o servidor (normal), os responsáveis pela intervenção no terreno de forma a eliminar a planta (técnico) e o responsável por toda a gestão da informação obtida (administrador).