Primeiramente, foram mapeadas para o banco de dados as classes identificadas como persistentes. Também foram identificados todos os atributos de cada classe, assim como o atributo que representava a chave primária.
Posteriormente, foram identificados todos os relacionamentos entre as classes persistentes em um diagrama lógico e um diagrama de entidade- relacionamento. No diagrama ER, os relacionamentos com cardinalidade 1-N foram representados através de chaves estrangeiras e os relacionamentos com
cardinalidade N-N foram representados através de novas tabelas com a composição de suas chaves primárias.
Abaixo serão mostrados os modelos: Transacional e Analítico, nos quais serão utilizados modelos relacionais para representar as tabelas, mesmo que em concepções distintas no que se diz a maneira de inserção e manutenção dos dados.
Modelo Relacional (Transacional – OLTP)
O modelo relacional transacional proposto possui apenas uma tabela “NFE_TB_XNF_XML_NFE”. Isto se deve ao fato de se estar tentando diminuir o trabalho que atualmente se tem em mapear documentos que já possuem um padrão nacional e fazer um DER mais estruturado; No entanto, quando se tem uma mudança na estrutura nacional, o trabalho necessário para os estados se adaptarem às mudanças pode demorar muito tempo.
Essa tabela possui um campo do tipo “sys.XMLType”, onde será armazenada uma estrutura XML que terá todos os campos e valores necessários para se fazer qualquer tipo de Auditoria ou Gerenciamento das informações.
Tudo isto em um único campo facilitando assim a alteração do documento pelos órgãos responsáveis e o ajuste a ser feito seria minimizado.
Na Figura 4.6 encontra-se a tabela que será criada para armazenar as informações dos arquivos XML.
Figura 4.6 – Tabela XML NFe
Fonte: O Autor
A Figura 4.7 mostra um exemplo de um arquivo XML de Nota Fiscal Eletrônica para que sejam observados alguns dos campos que podem ser obtidos deste arquivo.
Fonte: TKS Software, 2012
Com base nesses campos de XML, será montado o modelo relacional analítico, no qual as informações serão distribuídas entre as tabelas de maneira tal, que a utilização dessas informações sejam exibidas para o usuário final de forma rápida e prática através das consultas gerenciais e de auditoria.
Para que essa coleta dos dados XML fosse realizada, foi necessária a execução de consultas diretamente no arquivo XML, a fim de que se pudesse extrair os dados necessários para a montagem do modelo relacional analítico.
Assim, como estamos utilizando o banco de dados Oracle e a partir da versão 10g, é possível fazer uso de inserção, atualização, exclusão e consultas baseadas em arquivos XML.
O ETL foi baseado nesse leitura dos arquivos XML e inserção do dado no modelo analítico conforme a necessidade do dado encontrado no arquivo.
A consulta montada possui alguns comandos específicos para ler os dados de um arquivo XMLType, como por exemplo, o “extractvalue” que retorna o nó indicado em seus parâmetros. Logo abaixo está uma consulta utilizando a função mencionada:
select extractvalue(nfe.xnf_arquivoxml, '//mod',
'xmlns="http://www.portalfiscal.inf.br/nfe"') as "Modelo" from nfe_tb_xnf_xml_nfe nfe
where nfe.nfeid = 159;
Após conseguir extrair o dado necessário o mesmo foi inserido de maneira usual através do comando INSERT do SQL para que o dado seja inserido na base de dados que possui o modelo analítico.
Sendo assim, o modelo relacional analítico foi montado para que posteriormente fossem utilizados os seus dados para análises gerenciais, através do protótipo.
A implementação poderia ser feita diretamente em XML, resumindo tudo a uma única tabela para o sistema. No entanto, as consultas ficariam muito mais lentas mesmo se fosse utilizado um banco de dados XML nativo, que é próprio para otimizar esse tipo de consultas.
Isto ocorre porque as consultas BI não são consultas triviais e ainda aumentando a complexidade da consulta com o uso dos recursos do sys.XMLType, ficaria inviável no momento este tipo de implementação.
Modelo Relacional (Analítico – OLAP)
O modelo relacional analítico possui algumas tabelas que irão ajudar com a montagem do esquema estrela do BI da nota fiscal eletrônica e assim conseguir unir várias informações para posterior análise.
As tabelas deste modelo são:
DW_ALQ_ALIQUOTA
Nesta tabela dimensão, serão armazenadas as diversas alíquotas que foram aplicadas nas notas fiscais analisadas, como mostrado na Figura 4.8.
Figura 4.8 – Tabela de Alíquotas
DW_ATV_ATIVIDADE
Nesta tabela dimensão, serão armazenadas as diversas atividades econômicas encontradas nas secretarias de fazenda, podendo assim verificar se o produto que o contribuinte está comercializando está dentro do que sua CNAE permite, seja ela do tipo varejista ou de serviços. A descrição da tabela é mostrada na Figura 4.9.
Figura 4.9 – Tabela de Atividades
Fonte: O Autor
DW_CFO_CODIGO_FISCAL_OPERACAO
Nesta tabela dimensão, serão armazenadas as diversas operações fiscais que podem ser realizadas em uma nota fiscal, como mostra a Figura 4.10.
Figura 4.10 – Tabela de Códigos Fiscais de Operações
DW_CNN_CONTRIBUINTE_NOTA
Nesta tabela dimensão, serão armazenados os diversos contribuintes de uma nota fiscal eletrônica, sejam eles do tipo emitente, destinatário ou transportadora, como mostrado na Figura 4.11.
Figura 4.11 – Tabela de Contribuintes
Fonte: O Autor
DW_CPR_CATEGORIA_PRODUTO
Nesta tabela dimensão, serão armazenadas as diversas categorias de produto, na qual se pode identificar o produto e saber se foi aplicada a alíquota correta para um determinado tipo de produto, ou até mesmo fazer um rastreamento do mesmo, como um produto do tipo farmacêutico ou de armamento militar. Sua descrição é mostrada na Figura 4.12.
Figura 4.12 – Tabela de Categorias de Produtos
Nesta tabela dimensão, serão armazenadas as diversas localidades, sejam elas do emitente ou destinatário, como mostrado na Figura 4.13.
Figura 4.13 – Tabela de Localidade das Notas Fiscais
Fonte: O Autor
DW_MDF_MODALIDADE_FRETE
Nesta tabela dimensão, serão armazenadas as diversas modalidades de frete (Figura 4.14).
Figura 4.14 – Tabela de Modalidade de Frete
Fonte: O Autor
DW_MNO_MOVIMENTACAO_NOTA
Nesta tabela dimensão, serão armazenados os diversos tipos de movimentação de nota fiscal (Figura 4.15).
Figura 4.15 – Tabela de Movimentação das Notas Fiscais
Fonte: O Autor
DW_MON_MODELO_NOTA
Nesta tabela dimensão, serão armazenados os diversos modelos de nota fiscal (Figura 4.16).
Figura 4.16 – Tabela de Modelo das Notas Fiscais
Fonte: O Autor
DW_NCM_NOMENC_COMUM_MERCOSUL
Nesta tabela dimensão, serão armazenados os diversos nomes de produtos comuns do MERCOSUL que foram encontrados nas notas fiscais, como mostrado na Figura 4.17.
Figura 4.17 – Tabela de Nomenclatura Comum do MERCOSUL
DW_PER_PERIODO
Nesta tabela dimensão, será armazenado um intervalo de datas, o qual determinará o período ou tabela temporal do BI. Esse período será utilizado nesse esquema estrela como período de emissão ou período de operação da nota fiscal eletrônica. A descrição da tabela é mostrada na Figura 4.18.
Figura 4.18 – Tabela de Período
Fonte: O Autor
DW_SNF_SITUACAO_NOTA_FISCAL
Nesta tabela dimensão, serão armazenadas as diversas situações nas quais se podem encontrar uma nota fiscal eletrônica, como mostrado na Figura 4.19.
Figura 4.19 – Tabela de Situação das Notas Fiscais
DW_FIE_FATOS_ITEM_EMITIDA
Nesta tabela fatos, serão armazenados os diversos itens de nota fiscal. Tais informações são oriundas de outras tabelas já apresentadas anteriormente, que juntas podem identificar um único item de nota fiscal específico, além dos diversos valores que o próprio item de nota fiscal possui. Ela é descrita na Figura 4.20.
Figura 4.20 – Tabela de Itens das Notas Fiscais
Fonte: O Autor
DW_FNE_FATOS_NOTA_EMITIDA
Nesta tabela fatos, serão armazenadas as diversas informações da nota fiscal, oriundas de outras tabelas já apresentadas anteriormente, que juntas podem identificar uma nota fiscal específica, além dos diversos valores que a própria nota fiscal possui. Ela é descrita na Figura 4.21.
Fonte: O Autor
Após apresentadas todas as tabelas em separado, a Figura 4.22 mostra o modelo relacional analítico completo, chamado de “BI_NFe”.
Figura 4.22 – BI – NFe
O banco de dados será armazenado em um Data Center que oferece 50MB de espaço, podendo ser aumentado a depender do uso do mesmo.
Será utilizado o “Oracle RAC – Real Application Cluster” que é uma solução que exige alta disponibilidade, desempenho e escalabilidade (Oracle, 2013).
A alta disponibilidade se deve ao fato de ser um banco de dados em cluster, onde dois ou mais servidores (nodes) trabalham em conjunto processando acessos e transações de forma distribuída. Utiliza o método, “Round Robin” que viabiliza alto desempenho e poder de processamento (KingHost, 2013).
O Round Robin é um método que seleciona todos os itens em um grupo de forma igualitária e em uma ordem racional, geralmente começando no primeiro elemento da lista até o ultimo. O nome do algoritmo vem do princípio de rodízio conhecido de outros campos, onde cada pessoa tem uma parte de algo compartilhado em quantidades pares (Oracle, 2010).
Esse algoritmo de escalonamento é projetado especialmente para sistemas de compartilhamento de tempo. Foi definido neste projeto um intervalo de tempo chamado “Quantum” que varia por sistema. A fila de processos é organizada de forma circular de modo FIFO (First In First Out) (Oracle, 2010).
Caso ocorra alguma dificuldade no acesso a algum node, os outros servidores automaticamente assumem os processos executados, evitando erros de conexão. A Figura 4.23 demonstra o funcionamento do Oracle Rac na perca de um node.
Figura 4.23 – Oracle RAC
Fonte: Kinghost, 2013
O ambiente RAC, além de redundância no nível de software, proporciona escalabilidade em termos de hardware, onde é possível adicionar novos nodes sem
impactar na disponibilidade do serviço (Kinghost, 2013).
Foi escolhido o Sistema de banco de dados Oracle por ser um banco de dados reconhecido como bastante robusto e confiável, garantindo desempenho para grande quantidade de dados com segurança e expansão do sistema, o que é de extrema importância em aplicações de Business Intelligence, nas quais é necessário que haja uma grande quantidade de informações e que as mesmas sejam exibidas sem distorções dos dados. Uma comparação entre diversos SGBD é apresentada na Figura 4.24, corroborando a afirmativa acima.
Figura 4.24 – Comparativo dos SGBD
Fonte: Grupo Impacta, 2005
Embora a pesquisa do Grupo Impacta não seja tão recente, ela foi a mais confiável e concisa encontrada na literatura.
Outra vantagem de se utilizar este SGBD é a consistência de leitura, pois independente da complexidade da consulta, o resultado desta é sempre o conteúdo existente no início da leitura. Por exemplo: imaginando uma consulta muito complexa, onde o resultado leve uma quantia significativa de tempo para ser processado, os dados entregues estarão íntegros aos que constavam no começo da ação, sem influência de atualizações ou exclusões que podem ter ocorrido durante o período.
4.8. Considerações Finais
Neste capitulo, foram apresentados os requisitos básicos do protótipo desenvolvido de modo a permitir uma visão geral do seu funcionamento. Com o uso das tecnologias que foram descritas acima, a dificuldade na parte de ETL pode ser
os dados, não havendo necessidade de passar por mais uma camada de software para que o usuário informe os campos que ele quer migrar ou não.
Desta forma, também será evitada a mudança da aplicação se um usuário quiser um novo campo no BI montado para ele, não tendo escolhido tal campo inicialmente no projeto, bastando que apenas os novos arquivos a serem inseridos possuam esse campo, e o próprio BI irá poder utilizar esses dados.
No próximo capitulo as ideias mencionadas nesse escopo serão concretizadas e esplanadas, mostrando-se por meio de suas telas o funcionamento do protótipo, construído com base nos requisitos funcionais e não funcionais, e arquitetura de software e hardware anteriormente definidos.