O protótipo implementado tem os seguintes componentes: • Base de dados Oracle versão 10G°R.
• Oracle Discoverer°R, uma aplicação que não tem pré-requisitos especícos de software e de fácil utilização, sendo composta por dois módulos separados: Oracle Discoverer Administrator que permite criar um End User Layer onde os metadados serão guardados, e depois permite a criação dos próprios metadados, através da interpretação do esquema físico implementado e com mais alguma informação registada pela pessoa que efectua o desenvolvimento, e o Oracle Discoverer Desktop, uma ferramenta de edição e criação de relatórios.
A motivação de ter sido utilizada a plataforma Oracle, e mais especicamente o Ora- cle Discoverer°Rexplica-se porque estas eram as ferramentas imediatamente disponíveis e passíveis de serem utilizadas no IA, já com as questões de licenciamento resolvidas. Foram feitas tentativas para fazer a migração da aplicação para o Oracle 10g AS Server°R, o que per- mitiria a utilização do Oracle Discoverer Plus°R, com um interface web (os utilizadores teriam acesso aos relatórios já criados e à criação de novos relatórios através de um simples browser), mas não houve possibilidade em tempo útil de ser criada no IA a infraestrutura necessária em
termos da instalação de software.
A implementação (criação e actualização) do esquema de base de dados de suporte ao pro- tótipo foi efectuada à custa de scripts SQL. Para o carregamento dos dados foi utilizado o pro- grama da Oracle SQL Loader°R. Os dados foram exportados através de scrips SQL a partir da base de dados em cheiros no formato comma separated values, e depois transforma- dos para criar as chaves substitutas necessárias para o preenchimento do protótipo. Os dados foram retirados em fases separadas, cada uma correspondente a entidades diferentes:
• Instalações, respectivas empresas e geograa - foram retiradas a partir do módulo transversal ao IA para gestão de entidades(ver gura 1.1 no capítulo 1.1), que inclui um repositório central de dados de entidades. Na sequência desta exportação foi detectada alguma falta de qualidade nos dados destas três entidades. Vericou-se que existem al- gumas disparidades entre os dados disponíveis nos próprios formulários EPER, onde foram relatadas as emissões, e os dados deste módulo central de gestão de entidades existente no IA. Foi assumido desde o início da implementação deste protótipo que em caso de dúvida os dados que iriam prevalecer seriam os do repositório central (de onde foram efectivamente exportados), mas nalguns casos foi mesmo detectada a necessidade de correcção do conteúdo do repositório central.
• Dados de emissões provenientes dos registos IA e UE- retirados a partir da base de dados operacional de suporte aos formulários (Gestão dos E-forms)
• Dados de processo - para permitir identicar quais as prioridades de processo associadas a cada instalação, retirados também a partir da base de dados operacional de suporte aos formulários (Gestão dos E-forms).
• Dados de volumes e capacidades - foram exportados a partir da base de dados opera- cional de suporte aos formulários, tendo sido acrescentada em cada linha a indicação de qual o indicador associado a essa linha.
As listas classicativas, actividades PCIP, Nose-P, indicadores de produção, processo e período (apenas existiam dois períodos de dados) foram denidas como tabelas estáticas, pois são listas denidas e limitadas. A lista de actividades PCIP e Nose-P foi fornecida pelo IA, pois faz parte da informação de apoio ao próprio formulário EPER.
Para as actividades não-PCIP, que no formulário EPER foram corporizadas como simples campos textuais de inserção livre, e portanto pouco relevantes para análise, foi tomada a opção, após análise conjunto com os técnicos do IA, de se substituir a sua descrição (às vezes con- tendo mais de 1000 caracteres, e portanto até tornava impraticável a leitura dos relatórios) pelo respectivo Nose-P da emissão. Esta opção, embora tivesse mostrado os seus frutos em temos de análise de dados, teve também os seus inconvenientes, pois vericou-se que existiam casos
em que para um mesmo processo nose-p havia várias actividades não PCIP com emissões as- sociadas. Foram apresentadas três propostas de correcção desta problemática aos técnicos IA, nomeadamente:
1. Ser criada uma lista nita, delimitada e abrangente de caracterizações para as actividades não PCIP, e em cada registo de emissão associado a uma actividade não PCIP esta ser substituída por um elemento da lista.
2. Os valores associados a um mesmo processo Nose-P com várias actividades não PCIP diferentes serem somados, de forma a criar um único registo.
3. Serem criados novos valores para as descrições das actividades não PCIP em que hou- vesse conito (depois de terem sido substituídas pelo processo nose-P), para que um registo casse associado à actividade original, e o outro casse associado ao novo valor. A primeira hipótese foi considerada pelos técnicos do IA como não sendo praticável, de- vido ao volume de dados e de alterações envolvido. Quanto à segunda hipótese, tinha a desvantagem de poder adulterar as contagens de emissões, pois haveria casos em que 2 ou mesmo 3 registos passariam a contar apenas como uma única emissão, de maior valor. Assim, a resolução adoptada foi a indicada no ponto 3, em que à descrição original da actividade se acrescentou o suxo -v2´´ para diferenciar valores (por exemplo, para a actividade não PCIP já transformada 105.01´´ foi criada uma nova actividade 105.01-v2´´).
A dimensão emissão foi preenchida através da selecção de todos os valores diferentes de poluente, tipo de emissão e método de cálculo presentes nos registos de emissões exportados.