Implementation of the agreement between the UP and the UT

Existem duas bases de dados no sistema LIFE PAYT, a base de dados Auth e a base de dados Tenant. A base de dados Tenant é replicada pelo número de municípios com o sistema implementado a funcionar e podem ser diferentes entre si, dependendo das características de cada município. Na descrição que se segue para a base de dados Tenant estará representado o esquema base que é apresentado a todos os municípios e que cobre por exemplo as necessidades do município de Aveiro. As bases de dados estão instaladas através do PostgreSQL em servidores dedicados que comunicam com o

servidor principal através da rede interna. Para a proteção das bases de dados, os discos do servidor foram formatados com o sistema de ficheiros Zettabyte File System (ZFS), um sistema que garante a integridade dos dados ao aplicar a cada bloco do disco um checksum que verifica a cada leitura e escrita os dados de cada bloco [75]. Além da integridade dos dados, o sistema de ficheiros cifra todo o conteúdo nele armazenado sendo isso mais uma camada de segurança para os dados nele armazenados [76]. Além da segurança oferecida pelo próprio sistema de ficheiros, as permissões de acesso às bases de dados são atribuídas apenas aos módulos a que pertencem, ou seja, o módulo pertencente ao município X não consegue ter acesso, mesmo utilizando os seus métodos de acesso, à base de dados do município Y. Este facto cria a primeira camada de segurança no acesso às bases de dados. De seguida serão analisadas as duas principais bases de dados, primeiro a base de dados de autenticação e de seguida a base de dados do Tenant.

Base de dados Auth

A base de dados do módulo de autenticação, descrita na figura 3.3, guarda todos os utilizadores na tabela ’users’ guardando o e-mail, palavra-passe, papel de utilizador, nome de utilizador e um identificador único no campo ’user_id’.

Figura 3.3: Diagrama da base de dados que suporta o módulo de autenticação.

A cada utilizador é associado um papel no sistema que pode ser administrador, utilizador ou funcionário das câmaras municipais, sendo estes armazenados na tabela ’roles’ e só os papéis inseridos na tabela são possíveis atribuir. Existem ainda duas tabelas que servem de suporte para a identificação mais completa de utilizadores e funcionários das câmaras municipais, as tabelas ’customers’ e ’countyadmins’. Além da listagem de cada tipo de utilizador, associam também cada um ao município a que pertencem que tal como no caso dos papéis de utilizador, se encontram listados numa tabela dedicada, a tabela ’counties’.

Base de dados Tenant

Figura 3.4: Diagrama da base de dados que suporta o módulo Tenant.

A figura 3.4 representa o diagrama geral da base de dados que serve o módulo Tenant. O identificador único de cada utilizador proveniente do módulo Auth é armazenado na tabela ’users’ (figura 3.5) de forma a que o sistema consiga ligar as contas de utilizador aos seus dados de utilização do LIFE PAYT. As contas de utilizador podem ser do tipo ’personal’ ou ’business’, com a primeira a ser uma conta de um utilizador doméstico e a segunda uma conta de um utilizador não doméstico como por exemplo uma loja ou empresa.

Figura 3.5: Tabelas que armazenam informação relativamente aos utilizadores da base de dados que suporta o módulo Tenant.

Associados a esses tipos de utilizadores está a informação pessoal de cada um, número de identificação fiscal, e caso seja um utilizador não doméstico o tipo de negócio

e qual o contrato de fornecimento de água com a câmara municipal e a descrição da organização, definida pelo número de identificação fiscal e a morada (figura 3.6).

Figura 3.6: Tabelas que armazenam informação pessoal das pessoas e organizações da base de dados que suporta o módulo Tenant.

Este conjunto de informação é associado a um agregado de produtores (’producer_party’), que é caracterizado pela morada, utilizadores associados ao con- trato (domésticos ou não domésticos), datas de início e fim de produção. Este agregado é identificado por um identificador na tabela ’producer’, sendo cada contrato um produtor mesmo que existam várias pessoas associadas ao contrato, ou seja, vários produtores de resíduos. Associado ao produtor, que identifica uma habitação ou negó- cio, está o identificador do cartão de acesso aos contentores. Esta informação é a que permite associar um consumo a um produtor e gerar faturas reais para o mesmo. Esta identificação serve tanto para utilizadores domésticos e não domésticos, enquanto que o aluguer de um contentor é apenas para utilizadores não domésticos, aí o consumo é associado ao contentor apenas. A tabela ’producer_container’ existe para registar esses contentores alugados (figura 3.7).

Os consumos são guardados na tabela ’garbage_collection’ onde é feita uma associação entre contentor e cartões de utilizador, sendo que este último é o que permite chegar ao cliente que teve o consumo associado (figura 3.8). Neste caso o consumo é uma abertura do contentor, pois no caso de Aveiro a tarifa é por aberturas dos contentores. No entanto a base de dados está preparada para outros tipos de tarifas, como por exemplo uma tarifa baseada no peso.

Figura 3.7: Tabelas que armazenam informação sobre os produtores e identificação dos mesmos da base de dados que suporta o módulo Tenant.

Figura 3.8: Tabelas que armazenam informação sobre consumos, cartões de acesso e contentores da base de dados que suporta o módulo Tenant.

Estas são as descrições das bases de dados que se encontram atualmente implementa- das no sistema. Durante o desenho e implementação da nossa solução é importante ter esta estrutura de dados em conta, pois qualquer alteração indevida poderá comprometer o funcionamento do portal LIFE PAYT. A base de dados que suporta o módulo de autenticação irá estar mais sujeito a alterações, pois é lá que a grande parte das questões de segurança poderão ser resolvidas.