UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO IMPLEMENTAÇÃO DE UM DATA MART PARA ANÁLISE DE DOCUMENTAÇÃO DESTINADA À EXPORTAÇÃO PARA SEARA ALIMENTOS Área de Banco de Dados por Marcelo Katsurayama Reinert Luis Carlos Martins, Esp. Orientador Luis Antônio Lobo, Bel. Co-orientador Itajaí (SC), novembro de 2006

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO IMPLEMENTAÇÃO DE UM DATA MART PARA ANÁLISE DE DOCUMENTAÇÃO DESTINADA À EXPORTAÇÃO PARA SEARA ALIMENTOS Área de Banco de Dados por Marcelo Katsurayama Reinert Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Luis Carlos Martins, Esp. Itajaí (SC), novembro de 2006

3 SUMÁRIO LISTA DE ABREVIATURAS...iv LISTA DE FIGURAS...v RESUMO...vi ABSTRACT... vii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA ESTUDO DE CONCEITOS Oracle Data Warehouse OLAP OLTP X OLAP Topologias de um Data Warehouse Sistemas de Apoio a Decisão ÁREA DE EXPORTAÇÃO DA SEARA ALIMENTOS S.A Processo de Exportação DESENVOLVIMENTO MODELAGEM ANÁLISE DE INFORMAÇÕES GERENCIAIS CONSTRUÇÃO DO MODELO FÍSICO MODELAGEM LÓGICA DAS TABELAS DE TRANSIÇÃO PROCESSO DE CARGA NA ÁREA DE TRANSIÇÃO CONSTRUÇÃO DE RELATÓRIOS CONCLUSÕES...56 REFERÊNCIAS BIBLIOGRÁFICAS...58 A. CMEK3600.pck...60 A.1 CMEK9000.PCK...63 A.2 CMEK9001.PCK...66 A.3 CMEK9002.PCK...68 ii

4 A.4 SCRIPT CRIAÇÃO DM...73 A.5 SCRIPT CRIAÇÃO TRANSIÇÃO...76 A.6 CMEK9003.PCK...78 A.7 CRIAÇÃO DE UNIVERSO B.O...80 A.8 RELATÓRIOS...87 A.9 ATA DE REUNIÃO DE VALIDAÇÃO...95 iii

5 LISTA DE ABREVIATURAS APL A Programming Language BL BO Bill of Lading Business Objects (Ferramenta OLAP) CMEK Sistema Comercial Mercado Externo (Seara Alimentos) CNE Carnes CNH Conhecimento CSI Certificado Sanitário Internacional DASD Dispositivo de Armazenamento de Acesso Direto DM Data Mart DW Data Warehouse EMBA Embarque EUA Estad Estados Unidos da América EXP Exportação FIL Filial ITM Item MRM Marítimo OLAP Online Analytical Processing OLTP Online Transaction Processing PGM Programação RDBMS Relational Data Base Management System RDV Rodoviário RE Registro de Exportação REG Registro SAD Sistema de Apoio a Decisão SGBD Sistema Gerenciador de Banco de Dados SIF Serviço de Inspeção Federal SIG Sistema de Informações Gerenciais SISCOMEX Sistema Integrado de Comércio Exterior SMX Siscomex SQL Structured Query Language RSI TCC Relational Software Incorporated Trabalho de Conclusão de Curso TI Tecnologia da Informação UNIVALI Universidade do Vale do Itajaí iv

6 LISTA DE FIGURAS Figura 1. Niveis de detalhamento Figura 2. Data Warehouse centralizado Figura 3. Data Warehouse distribuído Figura 4. Arquitetura de Data Mart Figura 5. Data Mart dependente Figura 6. Data Mart independente Figura 7. Estrutura de tabelas de registro de exportação Figura 8. Estrutura de tabelas de conhecimento de embarque Figura 9. Estrutura de tabelas de fatura comercial Figura 10. Estrutura de tabelas de certificado de origem Figura 11. Estrutura de tabelas de borderô de cobrança Figura 12. Estrutura de tabelas de Certificado Sanitário Internacional Figura 13. Tela de geração de Certificado Sanitário Internacional Figura 14. Modelo relacional CMEK Figura 15. Modelagem dimensional do Data Mart Figura 16. Modelagem Dimensional baseado nas necessidades gerenciais Figura 17. Estrutura da tabela de transição de documentação Figura 18. Estrutura da tabela de transição da moeda Figura 19. Processo de carga das tabelas Figura 20. Relatório Documentos Emitidosmês Figura 21. Criação de um novo universo Figura 22. Universo vazio Figura 23. Inserção de tabelas no universo Figura 24. Ligando chaves primárias entre tabelas Figura 25. Universo ligado Figura 26. Criação de classes Figura 27. Universo DM completo Figura 28. Documentos emitidosmês Figura 29. Documentos corretosdocumentos errados Figura 30. Documentos com erros e sem erros por cliente Figura 31. Documentos com erros e sem erros por mercado Figura 32. Documentos com erros e sem erros por navio Figura 33. Documentos com erros Figura 34. Documentos com erros e valores Figura 35. Relatório gerencial geral v

7 RESUMO REINERT, Marcelo K. Implementação de um Data Mart para Análise de Documentação destinada à Exportação para Seara Alimentos. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, Este trabalho apresenta a modelagem de uma arquitetura para a análise de dados aplicada à área de Documentação de Exportação da empresa Seara Alimentos S.A., visando a busca da quantidade e das causas de erros encontrados nos documentos destinados à exportação de carnes e derivados. A arquitetura utilizada é de um Data Warehouse, utilizando a topologia de Data Mart. O objetivo principal é criar o modelo lógico para a construção do modelo físico, que permitirá aos gestores, obter informações necessárias para as tomadas de decisões. No cenário corporativo, uma decisão correta pode significar drástica diminuição de custos, tornando assim o negócio mais rentável, pois com a diminuição de custos, obtém-se preços mais competitivos e lucros mais elevados, consolidando a empresa cada vez mais no mercado. O banco de dados utilizado é o Oracle 9i, já existente na empresa, e para as consultas OLAP, a ferramenta utilizada é o Business Objects 5, ferramenta esta capaz de gerar relatórios precisos aos gestores. Tanto as necessidades gerenciais, quanto a validação deste trabalho foram feitas pelos próprios gestores, para que essas informações possam ser utilizadas tanto na empresa quanto em análises dentro da sala de aula. Palavras-chave: Data Mart. Informação. Tomada de decisão. Custos. vi

8 ABSTRACT This work presents the modeling of an architecture to data analysis applied in Seara Alimento s Exportation Documentation area, searching the quantity and the mistake s causes found in the documents destined to meat and derived s exportation. The architecture utilized is a Data Warehouse utilizing the Data Mart s topology. The main objective is createthe logical model to fisical model s build, that will allow to managers, to take decisions about the problem. In the corporative scenery, a correct decision can signify drastic cost decrease, enabling the business more profitable, because with the cost reduction, obtain more competitive prices and more high profit, consolidating more the company in the market. The used database is the Oracle 9i, already existent in the company, and, for OLAP analysis, the used tool is the Business Objects 5, tool apt to beget just reports to managers. As much the management necessity, how much the validation of this work made at managers, to that this information can be used as much in the company how much to analysis in the classroom. Keywords: Data Mart. Information. Take decisions. Cost. vii

9 1 INTRODUÇÃO Num cenário corporativo, o domínio da informação torna-se um aspecto de extrema importância para que uma empresa possa se consolidar num mercado cada vez mais competitivo. A informação passa a ser um bem com valor inestimável dentro da corporação. Para que esse controle possa existir, é necessário, além da organização de seus gestores, ferramentas e um banco de informações que possam auxiliar no processo de tomada de decisão, uma vez que seu volume e dinamismo ultrapassam os limites do simples controle. Um desses ambientes utilizados é o Data Warehouse (DW) (KIMBALL, 1998). Segundo W. H. Inmon (1997), um DW é um conjunto de dados baseados em assuntos, integrado, não-volátil, e variável em relação ao tempo, de apoio às decisões gerenciais. Sendo assim, trata-se basicamente de uma construção arquitetônica de um sistema de informações, que fornece aos seus usuários informações históricas de apoio a decisões. Desta forma, acaba formando uma base de dados que permite efetuar um tratamento adequado a informação, podendo assim, habilitar a descoberta e a exploração de tendências empresariais de suma importância (INMON, 1997). Porém, a criação de um DW não está restritamente ligada a tecnologia de banco de dados ou de servidores. Além destes fatores, é de extrema importância o correto planejamento e modelagem, aspectos muitas vezes deixados de lado por seus projetistas, mas que garantem a qualidade dos dados, fator este, importante para seu sucesso (INMON, 1997). Um DW é implementado idealmente utilizando o sistema gerenciador de Banco de Dados já existente, visando filtrar e tratar as informações de acordo com as necessidades de seus gerentes e diretores. Este processo de organização dos dados é consolidado com novos métodos de estruturação e armazenamento dos dados já existentes em sua base. Pelo fato de já existir uma base de dados na empresa, será necessário a implementação de um novo DW (INMON, 1997). Dentro dessa nova estrutura, é importante que exista uma integridade das informações contidas na base em que os dados são extraídos, ou seja, as inconsistências existentes devem estar desfeitas. A não-volatilidade abordada por Inmon (1997) está relacionada em apenas acessar e carregar os dados, não modificando os mesmos. Outra característica significativa é a manutenção de dados

10 históricos, isto é, vários dados sobre um determinado assunto, tratados em diferentes tempos, são armazenados para permitir analises que demandam de um contexto histórico. Foi observada a possível utilização de um Data Mart, que, segundo Inmon(1997), tem-se como meta organizar, por exemplo, cada setor da corporação, sendo que cada área passa a ter seu próprio repositório de dados. 1.1 PROBLEMATIZAÇÃO Formulação do Problema A Seara Alimentos S.A., empresa do ramo industrial de produtos alimentícios e frigorificados, com matriz situada em ItajaíSC possui, em média, 75% de seu faturamento provido de negociações com clientes do mercado externo, gerando em média, um volume de documentos necessários à exportação, e enviados aos clientes e órgãos responsáveis pelo controle dessas transações internacionais. Como exemplos de documentos utilizados, pode-se citar o Certificado Sanitário Internacional (Enviado ao Ministério da Agricultura e Pecuária Brasileira), o Certificado de Origem, o Certificado de Não-Radioatividade, o Certificado Form-A (Enviados ao cliente final), a Invoice (fatura comercial internacional, enviada ao cliente final), o Borderô de Cobrança (enviado ao cliente e ao banco responsável pelas transações financeiras internacionais), o Registro de Exportação (enviado à Receita Federal), entre outros. Na Seara Alimentos, 100% dos documentos necessários para concretização dessas negociações são gerados automaticamente via sistema. Pela imensa demanda das exportações, e, conseqüentemente, uma grande quantidade de documentos gerados, a incidência de erros é proporcional. Na ocorrência de erros, uma Carta de Correção é necessária. Cada Carta de Correção gera um custo para a Empresa, variando entre US$ 50,00 e US$ 150,00. Em média, 5% dos documentos gerados apresentam erros. Efetuando o cálculo, cerca de US$ ,00 são gastos em cartas de correção, baseado em informações entre janeiro 2003 à dezembro de 2004, quando possuía-se uma média de documentos emitidos mensalmente Solução Proposta Verificando o problema, observou-se a possível utilização de um DW na empresa. Para diminuir estes custos, a busca da origem desses erros e suas correções seriam imprescindíveis. 9

11 Sendo assim, a utilização de uma topologia de DW intitulada de Data Mart (DM) seria muito importante, tendo a preocupação com possíveis integrações futuras em um DW. Os gestores teriam capacidade de analisar através de relatórios, a origem eou a causa dos erros, podendo indicar e tomar as decisões cabíveis às situações apresentadas. 1.2 OBJETIVOS Objetivo Geral Construir um Data Mart (DM) para apoio a gestão da qualidade dos processos de emissão de documentação para exportação da empresa Seara Alimentos, bem como fornecer informações para apoio a tomadas de decisões nesta área de negócio Objetivos Específicos Estudar os conceitos de Data Warehouse, Data Mart, Sistemas de Apoio a Decisão, Online Analytical Processing (OLAP); Estudar a área de Documentação de Exportação da Seara Alimentos, bem como mapear o processo da área de documentação da empresa; Identificar a incidência de erros nas gerações de documentos destinados à exportação, bem como mapear a origem dos erros; Identificar as necessidades de informações gerenciais; Construir a modelagem dimensional do Data Mart no Sistema Gerenciador de Banco de Dados (SGBD) do Oracle; Construir o modelo físico do DM; Preparar a área de transição de dados (extração, transferência, carga); Executar os processos de carga e testes do modelo dimensional; Construir as consultas ao DM; e Validar as consultas junto ao gestor e ao pessoal da área operacional; 10

12 1.3 Metodologia Foi estudado através de livros e artigos os conceitos e terminologias relacionados ao Data Warehouse e Data Mart. Livros estes de autores conceituados na área de banco de dados e Data Warehouse, como Kimball e Inmon, disponíveis na biblioteca central da Univali no campus de Itajaí. Alguns artigos utilizados como pesquisa foram apresentados em congressos nacionais de computação, como o Congresso Brasileiro de Computação, realizado na própria Univali. Outros artigos foram divulgados em revistas relacionadas a área. A seguir, foi acompanhado durante três meses todo processo de exportação, desde a emissão de pedidos e reserva de espaço nos navios, até a documentação final para a exportação. Este acompanhamento teve a supervisão do analista de exportação da Seara Alimentos e co-orientador deste projeto, Luiz Antônio Lobo. O mesmo forneceu dados necessários para uma melhor análise do que foi realizado neste trabalho, como custo de cartas de correção e documentos que geram estes custos. Após este estudo do negócio da empresa, foram realizadas pesquisas relacionadas à área de comércio exterior, através de livros e páginas na internet. A base de dados utilizada para o estudo foi o Oracle 9i, já que empresa Seara Alimentos utiliza este banco em seu sistema, local onde foi modelado o Data Mart, já possuir a licença do mesmo. A ferramenta OLAP (processamento analítico on-line dos dados com capacidade de visualizações das infomações a partir de muitas perspectivas diferentes, enquanto mantém uma estrutura de dados adequada e eficiente. A visualização é realizada em dados agregados) que foi utilizada para a realização deste trabalho é o Business Objects 5, que, assim como o Oracle 91, já estão presentes devidamente licenciados dentro da empresa. E, também pelo motivo de já existir na empresa, para a modelagem de entidades e relacionamento foi utilizada a ferramenta Visio, da Microsoft. 1.4 Estrutura do trabalho Este documento foi estruturado em quatro capítulos. O Capítulo 1, Introdução, apresentou uma visão geral do trabalho, como problematização e objetivos estabelecidos. No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica sobre Data Warehouse, Data Mart 11

13 e conceitos relacionados a área de banco de dados relacional, assim como um estudo da área de exportação da empresa Seara Alimentos. Neste capítulo, também foi abordada a estrutura de tabelas utilizadas pelo sistema de documentação de exportação. O Capítulo 3 apresenta o projeto detalhado do sistema a ser desenvolvido, incluindo sua especificação e a sua modelagem. O capítulo também discute como foi implementado o Data Mart na empresa, apresentando a metodologia a ser utilizada no desenvolvimento e o cronograma de atividades para o TCC II. Concluindo, no Capítulo 4, apresentam-se as considerações finais, onde são abordados os resultados preliminares, mudanças de algumas estratégias de desenvolvimento do projeto, alterações de cronograma, dentre outros. 12

14 2 FUNDAMENTAÇÃO TEÓRICA 2.1 Estudo de Conceitos Oracle Segundo Fanderuff (2003), no ano de 1970, Ted Codd lançou seu modelo de dados relacional para o mundo. Seus melhores protótipos foram o System R e o Ingress. O System R era um modelo não-comercial até então de banco de dados, desenvolvido pelo laboratório da IBM; já o Ingress se baseava em um sistema de pesquisa em banco de dados que foi desenvolvido pela equipe liderada por Michael Stonebaker, na Universidade de Berkeley, Califórnia. Através do System R, foi gerado a Structured Query Language (SQL), a linguagem dos bancos de dados relacionais, que é utilizada hoje como um padrão universal. Ainda segundo Fanderuff (2003), em meados de 1977, surgiu a empresa chamada Software Development Laboratories fundada por analistas de sistemas que, ao lerem e estudarem o Ingress e o System R, resolveram lançar a sua versão comercial de um produto similar. Dois anos depois, a empresa mudou seu nome para RSI (Relational Software Incorporated), e nessa ocasião foi gerada a primeira versão do Oracle, conhecida como Oracle V2. Em 1983, a RSI teve seu nome alterado para Oracle, e nesse mesmo ano seu produto, ORACLE V3, já era o sistema mais portável do mundo, rodando sobre as plataformas PCs e mainframes. Desde então o banco de dados Oracle veio evoluindo e se adaptando a evolução tecnológica, como o Oracle 8i, que tem como principal característica a integração com a web, devido a popularização da Internet. O banco de dados Oracle é muito conceituado e considerado o melhor banco de dados na atualidade pelos seus diversos recursos e sua variedade de ferramentas. Atualmente o banco de dados Oracle encontra-se na versão Oracle 10g. O Oracle foi o banco de dados escolhido para o desenvolvimento do DW, pois a empresa já possui este banco instalado, bem como suas licenças de uso. 13

15 2.1.2 Data Warehouse Após o advento das transações on-line de alta performance surgiram os programas de extração, que usando alguns critérios de seleção transportavam os dados para um novo arquivo ou banco de dados. Com isto conseguia-se uma melhora na performance das análises coletivas dos mesmos, pois o processamento não estaria concorrendo com as transações on-line e, além disso, a posse dos dados passou para as mãos dos usuários. Por esses motivos, tornou-se comum o uso dos programas de extração e, conseqüentemente, o advento de alguns problemas como a falta de credibilidade dos dados, problemas de produtividade e a impossibilidade de transformar os dados em informações. Esse novo ambiente desorganizado não atendia às necessidades do futuro e por isso se fizeram necessárias algumas mudanças de arquitetura, surgindo o ambiente projetado de DW. No cerne de um ambiente projetado de DW está a percepção da existência de dois tipos de dados (INMON, 1997): Dados primitivos: utilizados pelos sistemas operacionais das empresas. Podem ser atualizados e refere-se a um presente momento. Atendem as atividades funcionais; e Dados derivados: dados resumidos ou calculados para atender às necessidades da empresa. Não podem ser atualizados e são históricos. Atendem as atividades gerenciais. Como pode ser visto, existe uma grande diferença entre os dados primitivos (dados operacionais) e os dados derivados (dados gerenciais) e, portanto, eles não devem coexistir num mesmo banco de dados. Num ambiente projetado de uma empresa existem quatro níveis (INMON, 1997): Operacional: contém os dados primitivos e atendem ao processamento on-line de alta performance; Atômico ou DW: contém dados primitivos não atualizados e dados derivados;. Departamental: contém informações úteis aos diversos departamentos da empresa. A fonte de todos esses dados é o DW. Há um banco de marketing, um de contabilidade e assim por diante, às vezes denominado Data Mart; e 14

16 Individual: geralmente dados temporários e de pequenas proporções e são utilizados para analises heurísticas. À primeira vista, pode-se concluir que existe uma grande redundância de dados neste ambiente, mas essa afirmação não é verdadeira. No nível operacional existem apenas registros com valores atuais, no de DW existem dados históricos e, no Departamental, existem registros dos departamentos específicos da empresa. Pode-se dizer que um Data Warehouse é um repositório de dados voltado à tomada de decisão, armazenando enorme quantidade de dados para se ter uma visão mais ampla das informações relacionadas à corporação. Existe uma grande preocupação com relação ao contexto histórico da informação da mesma para auxiliar na determinação da conduta apropriada quando da tomada de uma decisão. Um DW deve ter como principal característica a especialização em gerenciar grandes conjuntos de dados, os quais são coletados de diferentes fontes, como por exemplo, arquivos, base de dados já existentes e até mesmo outros DW s. Uma definição teórica de um DW, segundo Inmon (1997), diz que é Um conjunto de dados baseados em assuntos, integrado, não-volátil, e variável em relação ao tempo, de apoio ás decisões gerenciais.. A seguir, uma definição das características abordadas por Inmon. Orientado por Assunto Refere-se ao fato de que os dados estão organizados de acordo com os assuntos de interesse da empresa, como por exemplo: produto, cliente, filial. Em contrapartida, os dados dos sistemas operacionais estão organizados de acordo com a funcionalidade da empresa, como por exemplo, no caso da Seara: nome do navio, porto de destino, cliente. Esses assuntos serão armazenados em um conjunto de tabelas relacionadas. Desta forma, passa a ser possível realizar consultas do tipo quantos documentos do tipo A, que foram enviados para clientes do continente Y durante o período X tiveram erros, e conseqüentemente, geraram cartas de correção. É importante enfatizar que, não necessariamente, todas essas tabelas devem estar com o mesmo nível de resumo ou no mesmo dispositivo de armazenamento (INMON, 1997). 15

17 Integrado Refere-se ao fato de que todo dado, trazido dos sistemas operacionais para o ambiente de DW é, anteriormente, consolidado, de forma que passe a ter um único significado. É comum que em uma corporação, dados do tipo data sejam armazenados de formas diferentes. Por exemplo, na área de produção, a informação necessária é de dia, mês e ano. Já na área do comercial, a data pode estar apenas como mês e ano. Para ser transportado para o DW, o dado tem que ser codificado de uma única forma, não podendo ser modificado (INMON, 1997). Variante no Tempo Refere-se ao fato de que as estruturas de dados no DW sempre contêm um atributo de tempo, ou seja, a cada mudança ocorrida num dado, uma nova entrada é criada e não atualizada, como acontece nos sistemas operacionais. É importante salientar a complexidade do ambiente de DW, pois pode possuir não somente resumos anuais e mensais como também diários e semanais. Sabe-se que o número de dias e o início de uma semana diferem de um mês para o outro e de um ano para o outro. Além disso, os metadados também devem acompanhar essa variação no tempo, pois um determinado dado pode ter um significado numa época e outro em uma época diferente. Essa característica do DW garante a qualidade no contexto histórico dos dados (INMON, 1997). Não Volátil Refere-se ao fato de que, em um DW, os dados não sofrem atualizações. Eles são carregados uma única vez e, a partir desse momento, só podem ser consultados. Ao contrário do que acontece nos sistemas operacionais onde existem milhões de transações de atualizações ocorrendo a todo instante. Por isso esses sistemas têm de possuir um grande número de controles para que não ocorra nenhuma inconsistência devido a uma transação interrompida indevidamente (INMON, 1997). Particionamento e Granularidade Ainda seguindo o conceito de Inmon (1997), outros dos aspectos do DW devem ser considerados: o particionamento dos dados e a granularidade. Considerando que um dos objetivos de um DW é o acesso flexível dos dados, é de extrema importância que exista o particionamento dos dados. Entretanto, a grande quantidade de 16

18 informações torna complicada esta ação. Sendo assim, uma solução é particionar os dados, dividindo-os em mais de uma unidade física, proporcionando maior flexibilidade no seu gerenciamento. A granularidade se refere ao nível de detalhamento dos dados. É interessante que em um DW a informação armazenada possua um nível de detalhamento apropriado para a aplicação, ou seja, quanto mais dados a respeito da informação, mais consultas podem ser realizadas. Contudo, muitos detalhes acabam gerando um grande volume de dados, dificultando o armazenamento e o gerenciamento dessas informações. Desta forma, para uma melhor organização, a estrutura do DW pode apresentar diferentes níveis de detalhe. Por exemplo, um nível no qual os dados estão bem detalhados (nível de detalhe), um segundo nível no qual os dados são manipulados e agregados (nível de detalhe resumido). Fazendo uma analogia à Seara Alimentos, o nível de detalhe poderia ser de 90 dias de histórico detalhado de vendas de cada cliente e o nível resumido poderia ser 3 anos de histórico de vendas. A Figura 1 mostra os níveis de detalhamento numa granularidade. Figura 1. Níveis de detalhamento Fonte: Adaptado de Inmon (1997). Analisando estas características, nota-se que o DW é uma tecnologia que surgiu para melhorar a qualidade e o acesso das informações utilizadas pelos sistemas de suporte à tomada de decisão, visto que os bancos de dados operacionais não estavam adequados para este tipo de aplicação. Para um melhor proveito das melhorias ao acesso dessas informações, tornou-se necessário a utilização de métodos e tecnologias, como por exemplo o OLAP. 17

19 2.1.3 OLAP A base da análise Multidimensional para OLAP não é nova. De fato, ela remonta a 1962, com a publicação do livro A Programming Language, de Ken Iverson. A IBM desenvolveu e implementou a primeira linguagem com análise multidimensional, no fim da década de 60, chamada de APL(A Programming Language). Definida matematicamente, baseada em símbolos gregos, utilizadas por usuários finais e grande consumidora de recursos, foi amplamente utilizada nas décadas de 80 e 90 em aplicações de negócio. Acompanhando a evolução dos sistemas, na década de 90, introduziu-se uma nova classe de ferramentas no mercado, que foi batizada de OLAP. As ferramentas de OLAP possuem a maioria dos conceitos introduzidos pela linguagem APL, porém, com maior integração na utilização dos dados fontes. Existe um grupo de empresas que desenvolveu e ainda desenvolve engine de OLAP e arquiteturas nela baseada como a IBM, a Computer Associates, MicroSoft, MicroStrategy, Cognos, IRI, Oracle, entre outras. Multdimensionalidade O termo OLAP foi citado pela primeira vez por Codd (1970), quando ele definiu doze regras que estas aplicações deveriam atender. A visão conceitual multidimensional dos negócios de uma empresa foi umas das regras citadas, a qual se tornou a característica fundamental no desenvolvimento destas aplicações. A visão multidimensional consiste de consultas que fornecem dados a respeito de medidas de desempenho, decompostas por uma ou mais dimensões dessas medidas. Podendo também ser filtradas pela dimensão eou pelo valor da medida. As visões multidimensionais fornecem as técnicas básicas para cálculo e análise requeridos pelas aplicações de BI. Para se obter a visão multidimensional é necessário compreender outras características: Cubo é uma estrutura que armazena os dados de negócio em formato multidimensional, tornando-os mais fácil de analisar; Dimensão é uma unidade de análise que agrupa dados de negócio relacionados. As dimensões se tornam cabeçalho de colunas e linhas, como exemplo linhas de produto, regiões de venda ou períodos de tempo; Hierarquia é composta por todos os níveis de uma dimensão, podendo ser balanceada ou não. Na hierarquia balanceada os níveis mais baixo são equivalentes, porém, isto não 18

20 ocorre nas hierarquias não balanceadas onde a equivalência hierárquica não existe. Por exemplo, em uma dimensão geográfica o nível país não possui o subnível Estado para um determinado membro e possui para outro. No caso específico pode-se citar o país Liechtenstein que não possui Estado e o Brasil, que possui uma série de Estados; Membro é um subconjunto de uma dimensão. Cada nível hierárquico tem membros apropriados aquele nível. Por exemplo, em uma dimensão geográfica existe o nível e seus membros, como Região (Ásia, América do Sul, América do Norte), Países (China, Brasil, EUA), Estados (Yunna, Piauí, Califórnia); e Medida é uma dimensão especial utilizada para realizar comparações. Ela inclue membros tais como: custos, lucros ou taxas. Definição de OLAP A aplicação OLAP soluciona o problema de síntese, análise e consolidação de dados, pois é o processamento analítico online dos dados. Tem capacidade de visualizações das infomações a partir de muitas perspectivas diferentes, enquanto mantém uma estrutura de dados adequada e eficiente. A visualização é realizada em dados agregados, e não em dados operacionais porque a aplicação OLAP tem por finalidade apoiar os usuários finais a tomar decisões estratégicas. Os dados são apresentados em termos de medidas e dimensão, a maior parte das dimensões é hierárquica. Considerando as aplicações bancárias utilizadas diariamente no controle de contas correntes, na qual são efetuados saques ou depósitos pelos correntistas, se tem o exemplo típico de sistema de OLTP(On-line Transaction Processing). O interesse destes usuários é criar, atualizar e recuperar informações sobre registros individuais. Já para o Gerente de Contas Corrente, os requisitos de uso de informações dos dados das contas têm por finalidade a análise global de contas correntes com diversas visões. Por exemplo, o Gerente de Contas pode requer uma análise sobre o desempenho de contas correntes que tenham cheque especial e tenham utilizado o valor máximo dos mesmos em um determinado período de tempo em algumas regiões. Obter a resposta a esta consulta mais complexa fazendo uso de ferramentas relacionais padrão, não fornece solução requerida. Analisando as limitações do uso e ferramentas relacionais 19

21 padrão, Codd (1970) disse: "Ter um RDBMs(Relational Data Base Management System) não significa ter a nirvana instantânea de suporte a decisão. Mesmo com tantas possibilidades que os RDBMs têm oferecido aos usuários, eles nunca pretenderam fornecer poderosas funções de síntese, análise e consolidação de dados." Ligação do DW e OLAP O DW é utilizado para armazenar informações e o OLAP para recuperá-las, ambos são especializados para exercer suas funções de forma eficiente. As duas tecnologias são complementares de modo que um bom DW é planejado com produção de relatórios em mente. Desta forma, para explorar o DW completamente é necessário o OLAP que irá extrair e alavancar totalmente as informações nele contidas (INMON; HACKATHORN, 1997). Ligação do Data Mining e OLAP O OLAP e Data Mining são partes integrantes de todo e qualquer processo de suporte à decisão. Ainda, nos dias de hoje, a maioria dos sistemas de OLAP tem o foco no provimento de acesso aos dados multidimensionais, enquanto os sistemas de DM lidam com a análise de influência para os dados de uma única dimensão. As grandes empresas como a IBM, Oracle estão liberando versões de seus RDBMS que possuem ferramentas de OLAP e DM. Quando os usuários possuem ferramentas de OLAP e não de mineração de dados, eles gastam boa parte de seu tempo fazendo as tarefas pertinentes a um DM, como classificações e predições das informações recebidas (INMON; HACKATHORN, 1997). Ferramentas OLAP Atualmente, existem muitas ferramentas de OLAP no mercado e mudanças têm ocorrido em um ritmo acelerado. Na maioria das ferramentas observa-se a existência de dois componentes: a ferramenta do administrador e a ferramenta do usuário final. O componente do administrador é usado para administrar e gerar os cubos de dados a serem acessados., enquanto o componente do usuário final, tem acesso aos dados para extraí-los de suas bases de dados, com os quais geram relatórios capazes de responder as suas questões gerenciais. 20

22 As ferramentas surgiram juntamente com os sistemas de apoio a decisão para fazerem a extração e análise dos dados contidos nos DW e DMs. Algumas das características destas ferramentas (INMON; HACKATHORN, 1997). Consultas ad-hoc: geradas pelos usuários finais de acordo com os suas necessidades de cruzar informações de uma forma não vista e que o levem a descoberta do que procuram. Segundo Inmom e Hackathorn (1997) "são consultas com acesso casual único e tratamento de dados segundo parâmetros nunca antes utilizado de forma iterativa e heurística"; Slice and Dice: possibilita a alteração da perspectiva de visão. Serve para modificar a posição de uma informação, trocar linhas por colunas de maneira facilitar a compreensão dos usuários e girar o cubo sempre que houver necessidade; e Drill downup: consiste em realizar exploração em diferentes níveis de detalhes da informação. Com drill down divide-se um item de resumo em seus componentes detalhados, como, por exemplo, ano, semestre, trimestre, mensal e diário. Além das principais características apresentadas, é necessário que estas aplicaçações forneçam vários modelo de visualização em uma variedade de formatos, e não apenas em simples tabelas, sendo muitas vezes apresentados através de gráficos OLTP X OLAP Existem grandes diferenças entre os dois ambientes que, a seguir, serão definidas, mostrando o benefício que a implantação do DW pode trazer para o ambiente operacional. Sistemas operacionais (On-line Transaction Processing - OLTP): sistemas que dão suporte ao dia a dia do negócio da empresa, que mantém a empresa em funcionamento e são chamados de sistemas de produção; e Sistemas informacionais (On-line Analitycal Processing - OLAP): sistemas que dão suporte aos processos decisórios da empresa, que irão dar subsídios para as decisões estratégias da empresa e compreendem os SADs e os SIGs. Segundo Inmon, Welch e 21

23 Glassey (1999), OLAP é o método de análise sofisticado que visa orientar profissionais que precisam tomar decisões num determinado negócio. Como os dados informacionais exigem uma quantidade significativa e variada de recursos, devem estar num ambiente de banco de dados separado dos dados operacionais. Isso deve ocorrer porque o o DW engloba dados de vários sistemas OLTP e as estruturas básicas de dados de um DW são diferentes do sistema OLTP (KIMBALL, 1998). A grande vantagem de separar esses dados é que, como eles satisfazem a objetivos diferentes, eles poderão se concentrar no que fazem, oferecendo melhor desempenho e funcionalidade (KIMBALL, 1998). Integração dos dados Os dados no ambiente operacional não estão integrados, cada sistema possui uma definição própria. Para migrá-los para o DW deve existir uma integração prévia, porque se os dados chegarem em um estado não integrado, não poderão ser utilizados para obter uma visão corporativa. Com isso consolidam-se dados inconsistentes dos sistemas mais antigos em conjuntos coerentes (KIMBALL, 1998). Atualização dos dados Não há sobreposição entre os registros existentes no ambiente operacional e no de DW. Caso ocorra uma mudança, um novo registro é inserido no DW, associando ao mesmo um elemento de tempo. Com isso os dados históricos não precisam mais ser guardado no ambiente operacional. A remoção de grandes volumes de dados traz algumas facilidades para o ambiente de produção como: correção, reestruturação, monitoração e indexação, deixando o ambiente mais maleável (KIMBALL, 1998). Ciclo de vida do desenvolvimento O ciclo de vida do DW começa pelos dados. Caso esses dados estejam sob controle, eles são integrados e testados para verificar distorções. Então, é feita a codificação do programa. Os resultados dos programas são analisados e, finalmente, os requisitos do sistema são compreendidos (KIMBALL, 1998). 22

24 Organização dos dados (modelo de dados) Enquanto no ambiente operacional, os dados são modelados segundo a técnica denominada Modelagem entidaderelacionamento, que busca remover qualquer redundância dos dados para obter um melhor desempenho da transação, no ambiente de DW os dados são modelados segundo a técnica da Modelagem Multidimensional, que busca obter um maior desempenho nas consultas e atender às necessidades de simplicidade do usuário (KIMBALL, 1998). Tempo de resposta A noção de tempo de resposta nos dois ambientes é bem diferente. Enquanto no OLTP, o tempo de resposta é um fator crítico, ou seja, está diretamente ligado aos negócios, no ambiente de DW é mais atenuado, podendo ser medido em minutos, horas ou dias. No entanto isso não quer dizer que ele não seja importante, o tempo de resposta está diretamente ligado à produtividade, então quanto menor mais resultados serão alcançados (KIMBALL, 1998). Uma máquina ou duas Como o DW exige uma quantidade significativa e variada de recursos, geralmente é implementado em uma máquina separada do sistema OLTP. A palavra recurso, de um modo geral, é um motivo suficiente para requerer uma segunda máquina, mas existem outros dois motivos importantes. Primeiro, o DW é um recurso centralizado que integra dados de vários sistemas OLTP. Neste caso, por definição, a máquina do DW é separada. Segundo, as estruturas básicas de dados do DW são completamente diferentes daquelas do sistema OLTP. Como os dados devem ser copiados e reestruturados para o DW, praticamente não há razão para mantê-los na máquina do original OLTP (KIMBALL, 1998). Metadados Segundo Kimball (1998), são normalmente definidos como "dados sobre dados". Talvez uma definição mais exata seja a de que metadado é uma abstração dos dados, ou ainda, dados de alto nível que descrevem dados de um nível inferior. Sem metadados, os dados não têm significado. São exemplos de metadados as descrições de registros em um programa de aplicação ou o esquema de um banco de dados descrito em seu catálogo ou ainda as informações contidas em um dicionário 23

25 de dados. Em um ambiente operacional, os metadados são especialmente valiosos para os desenvolvedores de aplicação e os administradores de banco de dados. Os bancos de dados operacionais são usualmente utilizados via aplicação, que já contém as definições de dados embutidas. Seus usuários simplesmente interagem com as telas do sistema, sem precisar conhecer como os dados são mantidos pelo banco de dados. O ambiente de suporte a decisão, por sua vez, é bastante distinto. Nele, analistas de dados e executivos procuram por fatos não usuais e correlações que serão conhecidas quando encontradas. Aplicações rotineiras e predefinidas não fazem sentido neste ambiente. Os usuários de um DW precisam examinar seus dados e para tal, conhecer sua estrutura e significado. De um modo geral existem três camadas de metadados em um DW: Operacionais (do nível das aplicações): definem a estrutura dos dados mantidos pelos bancos operacionais, usados pelas aplicações de produção da empresa; Centrais do DW: mantidos no catálogo do DW. Distingue-se por serem orientados por assunto, definindo como os dados transformados devem ser interpretados. Incluem definições de agregados e campos calculados, assim como as visões sobre cruzamentos de assuntos; e Nível do usuário: mapeiam os metadados do DW para conceitos que sejam familiares e adequados aos usuários finais. Um DW pode ser visto e implementado de diferentes formas. Para isso, foi estudado as topologias existentes em relação aos DWs Topologias de um Data Warehouse A implementação de um DW pode utilizar-se de diferentes tipos de topologia como Centralizada, Data Marts e Data Warehouse Distribuído. Data Warehouse Centralizado Numa topologia Centralizada, um único DW concentra as informações disponíveis da corporação, isto é, os dados históricos e operacionais são extraídos e integrados em um grande repositório. A topologia Centralizada é projetada tendo como principal objetivo, organizar todos os 24

26 dados de uma corporação, fornecendo-a uniformidade e integridade dos dados (INMON; HACKATHORN, 1997). A Figura 2 ilustra um DW centralizado. Figura 2. Data Warehouse Centralizado Fonte: Adaptado de Inmon (1997). Data Warehouse Distribuído A topologia Data Warehouse Distribuído consiste de vários DWs conectados por uma rede de comunicação com suporte a processamento distribuído. O sistema é visto logicamente como um DW único, ou seja, os usuários não conseguem visualizar a existência de vários DWs separados fisicamente. O desempenho dessa topologia é influenciado diretamente pela tecnologia de comunicação de dados empregada (INMON, 1997). Na figura 3, pode-se ter um visão da topologia de DW Distribuído. 25

27 Figura 3. Data Warehouse Distribuído Fonte: Adaptado de Inmon (1997). Data Mart Os primeiros projetos sobre Data Warehouse (DW) referiam-se a uma arquitetura centralizada. Embora fosse interessante fornecendo uniformidade, controle e maior segurança, a implementação desta abordagem não é uma tarefa fácil. Requer uma metodologia rigorosa e uma completa compreensão dos negócios da empresa. Esta abordagem pode ser longa e dispendiosa e por isto sua implementação exige um planejamento bem detalhado. Com o aparecimento de Data Mart ou Warehouse departamental, a abordagem descentralizada passou a ser uma das opções de arquitetura Data Warehouse. Os Data Marts podem surgir de duas maneiras. A primeira é top-down e a outra é a botton-up (INMON, 1997). Top-down: é quando a empresa cria um DW e depois parte para a segmentação, ou seja, divide o DW em áreas menores gerando assim pequenos bancos orientados por assuntos "departamentalizados"; e Botton-up: é quando a situação é inversa. A empresa por desconhecer a tecnologia, prefere primeiro criar um banco de dados para somente uma área. Com isso os custos são bem inferiores de um projeto de DW completo. A partir da visualização dos 26

28 primeiros resultados parte para outra área e assim sucessivamente até resultar num Data Warehouse, sendo assim, a forma que foi utilizada no desenvolvimento deste trabalho na Seara Alimentos. Na topologia Data Mart tem-se como meta organizar, por exemplo, cada setor da corporação, sendo que cada área possui seu próprio repositório de dados, como pode-se ver na Figura 4. As diferenças existentes entre um Data Warehouse e um Data Mart são apenas relacionadas ao tamanho e ao escopo do problema a ser resolvido. Portanto, as definições dos problemas e os requisitos de dados são essencialmente os mesmos para ambos. Grosseiramente falando, enquanto um Data Mart trata de problema departamental ou local, um Data Warehouse envolve o esforço de toda a companhia para que o suporte a decisões atue em todos os níveis da organização. Sabendo-se as diferenças entre escopo e tamanho, o desenvolvimento de um Data Warehouse requer tempo, dados e investimentos gerenciais muito maiores que um Data Mart (INMON, 1997). Figura 4. Arquitetura de Data Marts Fonte: Mundim e Breternitz (2002). 27

29 Os DMs podem ser independentes de um DW (Figura 6), possuindo informações de determinado setor da corporação, ou dependentes (Figura 5), onde vários DMs são criados a partir de um Data Warehouse. Data Marts procuram otimizar as análises para obter resultados com mais qualidade e precisão nas tomadas de decisão. Figura 5. Data Marts Dependentes Fonte: Adaptado de Inmon (1997). Figura 6. Data Marts Independentes Fonte: Adaptado de Inmon (1997). 28

30 2.1.6 Sistemas de Apoio a Decisão O SAD consiste na escolha da melhor opção entre diversas alternativas, auxiliada por recursos computacionais com a possibilidade da obtenção de dados com melhor qualidade e maior velocidade. Assim, resultando na resolução do problema de modo mais adequado, ou seja, podendo em alguns casos sugerir novos caminhos e contribuindo de forma positiva. Os Sistemas de Apoio a Decisão, conforme Rezende (1999), auxiliam o executivo em todas as fases de tomada de decisão, principalmente, nas etapas de desenvolvimento, comparação e classificação de riscos, além de fornecer subsídios para a escolha de uma boa alternativa. Para que um SAD tenha sucesso é preciso utilizar a tecnologia adequada à aplicação. Neste caso, na Seara Alimentos, a tecnologia que mais se encaixa ao problema é o OLAP, abordado anteriormente neste mesmo trabalho. 2.2 Área de Exportação da Seara Alimentos S.A. Fundada em 1956 na cidade de Seara, oeste de Santa Catarina, a Seara Alimentos é uma empresa de grande porte que atua no mercado de aves e suínos, e em janeiro de 2004, passou a fazer parte do grupo Cargill, empresa esta atuante no mercado mundial de alimentos, soja entre outros. Com sede em Itajaí, onde possui um terminal privado de cargas frigoríficas, o primeiro e único no país, a Seara conta ainda com nove unidades industriais (abatedouros e frigoríficos) e mais de colaboradores. Opera de forma verticalizada e totalmente integrada, com matrizes, ovos, incubatórios, engorda e terminação de aves e suínos, produzindo integralmente as rações empregadas na alimentação de seu plantel. Possuindo três escritórios no exterior (Holanda, Argentina e Cingapura), a Seara é considerada uma das maiores empresas de carnes frigorificadas e industrializadas de alta qualidade da América do Sul, atendendo mercados como África, América do Sul, América Central, Ásia, Caribe, Europa, Oriente Médio, Hong Kong, Japão, entre outros. Cerca de 75% de seu faturamento anual é provido de negociações com clientes do mercado exterior. Com esse volume de exportações, a empresa necessita de um sistema robusto, que possa suprir esta demanda e suportar a grande quantidade de informações inseridas todos os dias. 29

31 Dentro da área de TI (Tecnologia da Informação), cerca de 30 colaboradores são responsáveis pelo desenvolvimento interno das aplicações baseadas no banco de dados Oracle 9i. A área de exportação possui um sistema gerencial denominado Sistema Comercial Mercado Externo (CMEK), constituído por 302 programas (telas), 313 relatórios (incluindo os documentos destinados à exportação) e 211 rotinas responsáveis pela manutenção dos dados dentro do sistema. Além disso, o sistema dispõe de 502 tabelas de registros Processo de Exportação O processo de exportação é iniciado com a área de comercial mercado externo, onde um trader efetua a venda de produtos da empresa para clientes internacionais. Após o contato com o cliente, e acertado preço e demais condições, é gerado via sistema, um contrato de venda enviado diretamente ao cliente. O cliente retorna um , confirmando que a transação comercial será concretizada. A partir deste momento, o trader passa aos seus auxiliares todos os dados necessários referentes a aquela transação. O auxiliar de trader faz o cadastro de pedidos no sistema e aciona a área de logística. Automaticamente o sistema já gera as ordens de produção, e as envia para o sistema de produção. Uma vez confirmado pela produção, o pedido é ovado em um ou mais containers, ficando disponível para a inserção em uma lista de carga. A logística tem como função, reservar espaço de container no navio e criar um planejamento de carga, onde ficam as informações de nome de navio, data de atracação, data de saída do porto de origem, data de chegada no proto de destino, nome do armador (empresa responsável pelo transporte e aluguel dos containers), valores de frete, porto de origem, porto de destino, entre outras. Após cadastradas essas informações, o pedido é inserido em uma lista de carga, que possui informações de cliente, filial produtora (informação vinda do pedido), filial de ovação de container, quantidade no container, filial exportadora (filial responsável pelo faturamento), etc., e pode receber mais de um pedido. A lista de carga é faturada contra o cliente, e fica a disposição para o carregamento no container. Após faturada, os documentos necessários a exportação começam a ser gerados. Esta é uma função do setor de documentação de exportação, e foi o enfoque principal para a concretização 30

32 deste trabalho. Dentre os documentos gerados, alguns necessitam de cartas de correção quando possuem erros de dados em sua geração. São eles: Registro de Exportação; Bill of Lading (Conhecimento de Embarque); Invoice (Fatura Comercial); Certificado de Origem; Certificado Form-A; Borderô de Cobrança; e Certificado Sanitário Internacional (CSI); Registro de Exportação O registro de Exportação (R.E.) é o primeiro documento a ser gerado. Ele é enviado ao sistema da receita federal através do SISCOMEX, do próprio governo. É gerado pelo usuário assim que a lista de carga é confirmada pelo comercial. Este documento é gerado a partir de informações de tabelas do comercial, financeiro, produção e logística. Para a geração deste documento, o usuário entra com os parâmetros de planejamento e lista, e a rotina CMEK4224.pck, buscando de tabelas de outros sistemas, cria registros nas tabelas de registro de exportação com estrutura conforme Figura 7. 31

33 Figura 7. Estrutura de tabelas de registro de exportação Bill of Lading (BL) O conhecimento de embarque marítimo ou Bill of Lading (BL) é um documento emitido pelo armador ou seu agente, representando o contrato de transporte. É considerado também, como comprovante de que a mercadoria foi entregue ao importador. O conhecimento de embarque confere ao importador o direito à posse da mercadoria após o transporte, sendo sempre emitido em inglês, em 3 vias originais utilizadas para negociação e as demais cópias não negociáveis. Algumas informações indispensáveis devem ser mencionadas no BL, tais como: nome do exportador; nome do consignatário; notificado; porto de embarque e desembarque; destino final; descrição do produto; quantidade de volume; 32

34 tipo de embalagem; tipo de contêiner; número do contêiner; nome do navio; dimensões dos volumes; peso líquido e peso bruto; número do lacre do armador; descrição da mercadoria; e data de embarque. Algumas informações adicionais devem ser mencionadas no BL, tais como: tipo de frete, dados referentes ao embarque, se a mercadoria foi colocada a bordo e sem restrições e se está em boas condições. O conhecimento de embarque marítimo deve estar devidamente assinado pelo agente ou pelo armador. Quando ele for emitido a alguém, ele é intransferível por endosso. Já quando ele for emitido à ordem de alguém, é endossável e transferível. A Figura 8 mostra a estrutura de tabelas do BL. 33

35 Figura 8. Estrutura de tabelas de conhecimento de embarque. Invoice (Fatura Comercial) A invoice ou fatura comercial é um documento emitido pelo exportador, que representa a operação comercial e serve para formalizar a transferência de propriedade da mercadoria para o importador. É emitida em formulário próprio (não obedece a um modelo oficial), sem erros, emendas ou rasuras, preferencialmente com o texto em inglês ou no idioma do país importador, devendo ser preenchida de acordo com a regulamentação deste. A Figura 9 mostra a estrutura de tabelas da Invoice. Deve conter no mínimo os seguintes dados: Nome do exportador e importador; Tipo de transporte; 34

36 Locais de embarque e desembarque; Descrição completa da mercadoria; Quantidade, peso bruto e peso líquido; Moeda, preço unitário, valor total; Incoterms (tipo de frete); Assinatura do exportador; Modalidade de pagamento; Tipo de embalagem e número e marca de volumes; Data de emissão; Nome do navio; e Número do contêiner. Segundo Vázquez (1999), É um documento usado internacionalmente para comprovar a venda mercantil. Nela devem aparecer todos os detalhes possíveis da operação: nome do vendedor, endereço, nome do comprado e endereço, nome do consignatário (que pode ser o comprador), nome do representante e, de maneira sumária, as condições em que foi efetuada a venda, tais como: prazo, modalidade de pagamento (nesse caso cobrança bancária) etc.. A fatura comercial deve ser emitida em quantas vias solicitadas pelo importador visando atender às exigências no desembaraço aduaneiro e liberação da carga no país de destino. 35

37 Figura 9. Estrutura de tabelas de fatura comercial. Certificado de Origem e Certificado Form-A O certificado de origem é um documento que tem como objetivo atestar que o produto é efetivamente originário do país exportador, assim como o Form-A, que é destinado ao mercado russo. São emitidos por exigência do importador para poder auferir benefícios no ato da liberação das mercadorias na alfândega de seu país, quando as mesmas gozam de redução ou isenção tarifária em seus paises de origem. Os certificados de origem e Form-A são fornecidos por entidades credenciadas através de um formulário timbrado. Através do programa CMEK5610, são geradas as tabelas de certificado de origem e form-a (o certificado form-a utiliza as mesmas tabelas do certificado de origem, conforme estrutura na Figura 10). 36

38 Figura 10. Estrutura de tabelas de certificado de origem. Borderô de Cobrança É a nota discriminativa das mercadorias e de seus respectivos valores, enviado ao banco responsável pela cobrança desta venda. O borderô é gerado pelo programa CMEK5626 e utiliza apenas uma tabela para manter seus dados, conforme Figura

39 Figura 11. Estrutura de tabelas de borderô de cobrança. Certificado Sanitário Internacional (CSI) A confecção do CSI tem início após a unitização do contêiner na unidade produtora ou em algum entreposto frigorífico. Assim que todas as informações estiverem inseridas no sistema, o inspetor veterinário oficial responsável dá o parecer no próprio sistema atestando a boa procedência da mercadoria imprime, carimba e assina-o para que este acompanhe o contêiner até o porto de embarque, onde as autoridades sanitárias do porto farão a verificação e autorização para embarque. 38

40 Após o embarque da mercadoria, o CSI que está no porto é coletado e trazido até o escritório para que seja enviado para o agente no destino, juntamente com os demais documentos da exportação, para que a mercadoria seja liberada e entregue para o cliente. Os dados que são obrigatórios para este documento são: Código do CSI; nome do exportador; nome do consignatárioimportador; nome, endereço e número do SIF da unidade produtora; nome, endereço e número do SIF do entreposto frigorífico; local de carregamento; meio de transporte; número do lacre sanitário; tipo de embalagem; identificação da remessa (número do contêiner); estado-membro de destino; destino final; espécie de ave; tipo de peças; número de embalagens; peso líquido; data de produção; e carimbo e assinatura do inspetor veterinário oficial. No sistema da Seara, a rotina CMEK5321 é a responsável pela geração do certificado sanitário. Cada país de destino possui seu próprio modelo de certificado, mantido também no sistema CMEK. A Figura 12 ilustra a estrutura de tabelas de certificado sanitário internacional dentro do sistema. 39

41 Figura 12. Estrutura de tabelas de certificado sanitário internacional. 40

42 Na Seara, todos os documentos são gerados automaticamente pelo sistema. O usuário entra nas telas de impressão, solicita o documento através do planejamento de carga e da lista de carga. Na Figura 13, pode-se visualizar a tela de impressão do Certificado Sanitário Internacional (CSI): Figura 13. Tela de geração de CSI. Seguindo o exemplo dos CSIs, o programa que gera é uma Procedure Stored, e busca informações do sistema de produção (código do produto, data de fabricação, data de validade, número do pedido), do cadastro de itens (descrição do item, tipo de embalagem do item, unidade de medida), do sistema comercial mercado externo (número da ordem de compra), do sitema de logística (número do container, número do lacre do container, peso bruto, peso líquido, quantidade de volumes, porto de origem, porto de destino, entre outras), além de informações como nome do cliente, nome da empresa, nome da filial, vindas dos cadastros gerais da empresa. Sendo assim, qualquer tipo de informação cadastrada erroneamente pelos sistemas envolvidos, ou qualquer informação que o sistema busca que não faz parte a regra daquele cliente, geram documentos com erro, e, conseqüentemente, passam a exigir uma carta de correção. 41

43 3 DESENVOLVIMENTO Este trabalho tem como objetivo a implementação de um Data Mart no sistema de documentação da Seara Alimentos, para que se busque uma decisão gerencial em relação aos erros ocorridos nas gerações de documentos destinados a exportação de carnes de aves, suínos e seus derivados. Uma vez implementado, o Data Mart permitirá que a gerência tome decisões baseados em relatórios construídos via Business Objects, sobre os custos gerados por cartas de correção dos documentos, além de buscar a origem dos erros e, conseqüentemente, buscar a solução para que se diminua a demanda de erros. Segundo Inmon (1997), a topologia de Data Mart possui a característica de organizar cada setor de uma corporação, para que se tenha um repositório para cada área. Na Seara Alimentos, o sistema integrado da documentação faz uma busca de outras áreas, para que se possa gerar os documentos. É utilizando um Data Mart, que este projeto se baseará, uma vez que deverão ser organizados os dados em apenas um repositório. O módulo CMEK Documentação funciona da seguinte forma: o usuário digita o número do planejamento e da lista de carga e através de stored procedures (rotinas de execução de instruções para realizações de tratamentos e transações no banco de dados), gera-se automaticamente os documentos. Existe uma ordem para que esses documentos sejam gerados. Quando há a necessidade de um reprocesso (é realizado quando existem erros nos documentos), é inserido através de uma rotina numa tabela no banco de dados qual foi o documento, o planejamento e a lista de carga com erro. A ordem de emissão de documentação é a seguinte: 1. Registro de Exportação; 2. Bill of Lading (Conhecimento de Embarque); 3. Invoice (Fatura Comercial); 4. Certificado de Origem; 42

44 5. Certificado Form-A; 6. Borderô de Cobrança; e 7. Certificado Sanitário Internacional (CSI); A Figura 14 mostra o modelo relacional das tabelas de documentação de exportação no sistema CMEK. Figura 14. Modelagem relacional CMEK Seguindo esta modelagem relacional, as tabelas DCT_CTF_SAN_INN_EXP_CNE, DCT_CTF_SAN_NAC_EXP_CNE, DCT_ITEM_CTF_SAN_INN_EXP_CNE E DCT_ITEM_CTF_SAN_NAC_EXP_CNE são utilizadas para o armazenamento de informações referentes aos Certificados Sanitários Internacionais. Existe uma stored procedure(cmek5321.pck) que busca as informações necessárias. Estas informações vêm de sistemas distintos, como do Sistema de Produção (data de produção, filial de produção, etc.), Sistema de cadastro de itens (data 43

45 de validade, descrição do produto, etc.), Sistema de cadastro de clientes (nome e endereço do cliente), entre outros. Um certificado sanitário é identificado pelo Código do Certificado (CD_CTF_SAN_EXP_CNE_NAC). O usuário digita o código de planejamento e lista de carga, e, a partir destes parâmetros, gera um certificado. Para cada país de destino do CSI, é atribuído um modelo, já que cada país importador eou espécie do produto, existe um modelo físico específico. A tabela que possui o cadastro dos modelos de CSI é a MODELO_CTF_SANITARIO_INN. Nela, são cadastrados informações do tipo Código do Modelo, País de Destino, Espécie do produto enviado e o caminho do programa que imprimirá este CSI, já que, para cada CSI, é utilizado um relatório confeccionado pela TI e desenvolvido no Oracle Reports. Para a geração de fatura comercial (invoice) são utilizadas as tabelas FATURA_COMERCIAL_MRM_INN e ITEM_FATURA_CML_MRM_INN, ligadas pelo código da fatura. Assim como no CSI, é utilizado uma stored procedure chamada de CMEK5401.pck Também são buscadas informações de outros sistemas (Sistema de Produção, Cadastro de Clientes, etc.) e armazenadas nestas tabelas quebradas por planejamento e lista de carga. Para cada lista de carga do planejamento é gerada uma nova invoice com seus itens. As tabelas utilizadas para o armazenamento dos certificados de origem são CTL_CTF_ORIGEM_EXP_CNE e CTL_ITEM_CTF_ORIGEM_EXP_CNE, ligadas pelo código de origem, e carregadas através da stored procedure CMEK5611.pck. No caso dos registros de exportação(re), é utilizada a seguinte estrutura: a tabela REGISTRO_EXPORTACAO_SMX_CNE, faz o papel do cabeçalho do RE e possui informações de importador, exportador, entre outras. Abaixo dela, ligado pelo código de registro, existe a tabela ANEXO_REGISTRO_EXP_SMX_CNE, onde estão contidas as informações de item, quantidades, valores, etc. Em seguida, ligada pelo código de registro e pelo código do anexo, existe a tabela FABRICANTE_PRO_REG_EXP_CNE, onde encontra-se as informações de produção dos itens a serem exportados, como filial de produção, data de produção entre outras. Para que essas informações sejam carregadas, utilizam-se as stored procedures CMEK4220.pck, CMEK4221.pck, CMEK4222.pck e CMEK4223.pck. 44

46 Para a geração de BL s (conhecimento de embarque), é utilizada a stored procedure CMEK5341.pck, além das tabelas CNH_EMB_MRM_EXP_CNE e ITEM_CNH_EMB_MRM_EXP_CNE, ligadas pelo código do conhecimento e contendo informações de produto, cliente, exportador entre outras. A tabela BORDERO_COBRANCA_INN é utilizada para o armazenamento de informações referentes ao Borderô de Cobrança, e é carregada por uma tela no próprio sistema corporativo, denominada CMEK5626.fmb (Programa este desenvolvido na ferramenta Oracle Forms). Todas estas tabelas possuem as informações de código de planejamento e lista de carga, e estão centralizadas na tabela FIL_EXP_ITEM_LISTA_CARGA_MRM. Toda vez que um documento é gerado, é inserido na tabela RASTREAMENTO_EXPORTACAO por planejamento e lista de carga, o código do documento, a ordem em que foi inserido, a data e a hora e a matrícula do usuário que gerou. Atualmente, esta tabela é utilizada na empresa para conferências e auditorias. Como a estrutura era viável para a implementação do Data Mart, foi utilizada para saber quando um documento é gerado, e se foi gerado mais de uma vez (quando isto acontece, caracteriza a primeira geração como erro. Sempre que houver mais de uma geração do mesmo tipo de documento, a stored procedure de carga ao DM leva em consideração que ocorreu um erro na geração deste documento, de acordo com as informações obtidas em entrevista com os gestores). Entretanto, os documentos envolvidos na exportação só serão carregados nas tabelas de transição, quando um evento chamado Confirmação de Embarque for inserido na tabela de rastreamento, evitando assim, que, se porventura um usuário gerar alguns documentos e a transação comercial não se concretizar por quaisquer motivos, não gerando assim possíveis custos de regeração de documentos, não influencie nos resultados obtidos nas consultas do Data Mart pelos gestores. Sendo assim, só estarão no modelo do DM as informações que sejam efetivamente concretizadas comercialmente. 3.1 Modelagem Para a modelagem do Data Mart, foi escolhida as ferramentas Business Objects Designer 5, sendo que o BO Designer foi utilizado para desenvolver a modelagem dimensional deste Data Mart. 45

47 A modelagem dimensional exige o mapeamento das tabelas de dimensão, bem como a criação das tabelas fato e da granularidade do DM, visando atender as necessidades de informações gerenciais solicitadas pelo gestor da área, como qual o mercado que mais possui erros por mês, qual o cliente que mais teve erros na geração dos documentos e qual o documento que mais apresentou erros. A Figura 15 mostra a modelagem dimensional do DM, com sua tabela fato e a granularidade. Figura 15. Modelagem Dimensional do Data Mart. Nesta modelagem, observa-se a existência de cinco tabelas de dimensão, e uma tabela fato ligado pelas respectivas chaves. Na tabela de dimensão de tempo inicia-se a partir da dimensão de mês. A partir dela, segue a granularidade por ano, bimestre, trimestre, semestre e ano fiscal, que contempla o período de junho de um ano à maio do ano seguinte. Esta dimensão foi solicitada pela gerência, uma vez que a Seara baseia-se neste período para balanços. As tabelas de dimensão de Cliente e Mercado são responsáveis pela descrição dos códigos que aparecerão nas consultas por estes motivos. 46

48 Já as tabelas de dimensão Dim_tipo_campo e Dim_tipo_documento, mostrarão aos gestores quais os documentos que possuem erros e qual ou quais os campos que causaram o erro, bem como os responsáveis e o sistema de origem. Tendo esta informação, o gestor poderá tomar a decisão correta para a distribuição dos custos causados para o verdadeiro responsável pelo erro. Isto foi possível pois todas as tabelas do sistema da empresa possuem os campo de usuário e data da atualização do registro, tornando possível a carga destas tabelas de dimensão com estas informações de responsabilidade. 3.2 Análise de informações gerenciais Após análise junto ao gestor da área, foram identificados, através de entrevistas informais, os seguintes pontos em relação às necessidades gerenciais de informação (os relatórios referentes a cada necessidade gerencial encontram-se no apêndice A.8, Relatórios): Quantidade de documentos emitidos por mês; Quantidade de documentos emitidos com erro e quantidade de documentos emitidos sem erros (bem como suas respectivas porcentagens); Quantidades de documentos emitidos com erros e sem erros por cliente; Quantidades de documentos emitidos com erros e sem erros por mercado; Quantidades de documentos emitidos com erros e sem erros por planejamento (navio); Quais documentos geram mais erros; Custo gerado através de cartas de correção por documento; Custo gerado através de cartas de correção total; e Responsáveis pelos erros, bem como identificação de reincidência, entre outros. Além destas informações, foi conversado com os gestores, sobre a possível disponibilidade da informação referente às cotações da moeda, uma vez que as cartas de correção são todas cobradas em dólar americano (US$), nas datas em que os documentos foram gerados. 47

49 Desta forma, chegou-se a conclusão de que um novo modelo lógico deveria ser implementado. Um modelo que pudesse contemplar todas as necessidades de informação solicitadas pelo gestor. Assim, com o objetivo de substituir o modelo utilizado na primeira parte deste trabalho (TCC 1), foi criado o modelo dimensional conforme figura 16. Figura 16. Modelagem Dimensional baseado nas necessidades gerenciais. Ainda conforme figura 16, as tabelas hachuradas identificam as tabelas fato. A tabela fato FT_COTACAO é utilizada para as consultas de cotação de moeda nas datas da geração dos documentos. O valor da cotação é carregado em uma tabela do sistema relacional da empresa diariamente, e sendo carregada na tabela de transição TRANSICAO_MOEDA_EXP_CNE. Sempre no último dia do mês, através de um Job de Execução (rotina programada para ser rodada de tempos em tempos conforme necessidades), busca-se as informações do mês que passou em uma tabela de transição, a média de valores deste mês. A stored procedure utilizada é a CMEK9003.pck, e possui seu código fonte apresentado no apêndice A.6, CMEK9003.pck. Desta 48

50 forma, os gestores podem ter noções de custos mais aproximadas possíveis em relação aos documentos, pois o dólar americano é uma moeda que pode ter oscilações em sua cotação. A tabela fato FT_DOCUMENTACAO_EXP_CNE é utilizada para que todas as perguntas dos gestores referentes à geração de documentação de exportação possam ser respondidas. A partir dela, tem-se ligações com todas as tabelas de dimensão do modelo lógico, trazendo estas informações. Um ponto relevante é o campo VL_CARTA_CORRECAO estar dentro de uma tabela de dimensão, e não dentro da tabela fato, como se era esperado. Esta característica apresentada neste modelo lógico se dá ao fato da granularidade ser mensal, além deste valor estar em dólar, com raras alterações neste valor. 3.3 Construção do Modelo Físico Uma vez que o modelo dimensional estava definido, era necessária a criação do modelo físico. Para isso, foram criadas as tabelas tanto do Data Mart (Apêndice A.4, Script criação DM), quanto da área de transição (Apêndice A.5, Scripts criação Transição). As tabelas seguem um padrão de nomenclatura da própria empresa, com exceção dos campos chave que fazem parte das tabelas do Data Mart. Foi definido junto ao usuário, que o campo chave, tanto das tabelas fato como das tabelas de dimensão, seriam numéricos com tamanho definido de 7. Sendo assim, é permitido inserir em cada tabela aproximadamente 10 milhões de registros. Foi definida como chave primária das tabelas de dimensão os campos que iniciam com a nomenclatura chave. As tabelas fato possuem chaves compostas e estrangeiras (chaves buscadas das tabelas de dimensão). Após criadas as tabelas, foi necessário o desenvolvimento do universo do DM utilizando o Business Objects. No Apêndice A.7, é possível visualizar o passo-a-passo da ferramenta a construção do universo DM. 49

51 3.4 Modelagem Lógica das tabelas de Transição As tabelas existentes na área de transição, tem por objetivo armazenar as informações que serão gravadas nas tabelas do Data Mart. Isto deve ser feito para que, toda vez que ocorrer um erro no momento da gravação nas tabelas do DM, não se perca as informações daquele período. As tabelas de transição são apagadas somente após a confirmação da transição do banco de dados. Com exceção da tabela fato de cotação (FT_COTACAO), as tabelas são carregadas uma vez por semana, também através de um Job de execução. Este Job é rodado toda sexta-feira, após as 21:30 hs, buscando as informações das tabelas de transição, utilizando-se de uma stored procedure (pck). Na figura 17, é possível visualizar a estrutura da tabela da área transacional. Figura 17. Estrutura da tabela de transição de documentação Nesta tabela, as informações são buscadas das tabelas do sistema relacional da empresa, e carregadas. O campo ID_STATUS_ERRO é utilizado para verificar se existem registros com erros nesta tabela. Ou seja, após carregar as tabelas do Data Mart, é feita uma verificação na tabela transacional, buscando por registros que possuam ID_STATUS_ERRO = 1 (com erro). Caso encontre algum registro, a stored procedure tenta a inserção no DM até que não existam mais registros com este status. Caso não encontre nenhum registro, é rodado um procedimento para a limpeza desta tabela. 50

52 Os campos de DT_ATUALIZACAO e ID_USUARIO são utilizados para controle, uma vez que são gravadas a data e a hora, além da matrícula do usuário toda vez que o registro é inserido ou alterado. Estes campos devem existir nas tabelas por questões de normas de gestão de TI da empresa, mesmo que não venham ser utilizados. Para a tabela de transição, utilizada para a carga das tabelas FT_COTACAO e MOEDA, também foi utilizada uma stored procedure chamada a partir de um job de execução, entretanto, o tempo de carga desta tabela é diária, após as 19:00 hs, para que tenha-se sempre uma informação de valor médio de cotação da moeda. Na figura 18, nota-se a estrutura da tabela de transição TRANSICAO_MOEDA_EXP_CNE. Figura 18. Estrutura da tabela de transição da moeda 3.5 Processo de carga na área de transição Toda vez que um documento é gerado pela equipe de documentação para exportação, é chamada a stored procedure CMEK3600 (o código fonte encontra-se no Apêndice A, CMEK3600.pck). Esta pck tem como objetivo inserir na tabela RASTREAMENTO_EXPORTACAO informações como o nome da pessoa que gerou o documento e a data de geração deste documento por planejamento e lista de carga, bem como informações de confirmação de lista ou de embarque, utilizadas pela área comercial e área de TI para consultas de fluxo de procedimento, quando necessário. Foi acrescido nesta stored procedure uma chamada para a rotina CMEK9000 (código fonte apresentado no Apêndice A.1, CMEK9000.pck), que tem por objetivo, inserir nas tabela de transição TRANSICAO_DOCUMENTACAO_EXP_CNE as informações que, posteriormente, serão carregadas no Data Mart. Assim sendo, toda vez que um documento é gerado, automaticamente as informações já são inseridas na área de transição de documentação. 51

53 Para a atualização da tabela de transição TRANSICAO_MOEDA_EXP_CNE, foi utilizada a stored procedure CMEK9001.pck(código fonte exposto no Apêndice A.2, CMEK9001.pck). Foi inserido em um job já existente que roda todo dia às 18:00hs. Esta package busca o valor do dia, e faz uma média com os valores já existentes na tabela, deixando a mesma atualizada com a média mensal da cotação do dólar já no final do dia. A figura 19 ilustra o processo de carga nas tabelas de transição e carga no Data Mart. Sistema Relacional CMEK9000 CMEK9001 Área de Transição CMEK9002 Data Mart Busca dos Dados; Filtragem dos Dados; Inserção dos Dados. Busca das chaves; Carga no DM. Figura 19. Processo de carga das tabelas De acordo com a figura 19, na stored procedure CMEK9000 existem procedimentos para a busca dos dados no banco do sistema relacional. Esta busca é feita na tabela RASTREAMENTO_EXPORTACAO toda vez que for identificado o registro de Confirmação de Embarque. Após identificado esse registro, inicia-se a filtragem dos dados, que consiste em não permitir que sejam inseridos na tabela de transição registros duplicados ou com possíveis erros (de restrições ou problemas nas buscas dos dados). A stored procedure CMEK9001 também faz cargas na tabela de transição, entretanto, exclusivamente para a parte de cotação de moeda. É rodado todo final de dia, é faz a média do valor 52

54 de cotação da moeda do primeiro dia do mês até o dia corrente, inserindo na tabela de transição de cotação o valor já calculado. Os dados ficam armazenados nas tabelas de transição até que rode o JOB do fim de mês para a carga do DM, ou seja, todo último dia do mês após as 21:30 hs, é chamado a stored procedure CMEK9002 (Apêndice D, CMEK9002.pck), onde é feita a busca dos dados das tabelas de transição, a busca das próximas chaves a serem inseridas e, por fim, a carga nas tabelas do DM. Para evitar que dados não sejam inseridos, a tabela de transição só será limpa quando não existir mais nenhum registro dentro dela. Para que isto ocorra, após cada inserção no DM, o registro recebe um indicador de que já foi carregado, e a transação no banco é concretizada. Ao final de todos os registros inseridos, é feita uma varredura na tabela de transição, verificando se não há nenhum registro com erro. Caso não exista, é feita a limpeza da tabela. Poderia ocorrer um problema mais sério durante as consultas: o gestor poderia estar rodando os relatórios no momento em que as tabelas do DM estivessem sendo carregadas, podendo gerar tomadas de decisões equivocadas em cima de uma base de dados incompleta. Para não ocorrer este problema foi criada uma flag, que emitirá um aviso ao usuário que estiver consultando as informações, se os dados daquele mês estão carregados por completo. Esta flag está na tabela FLAG_DATA_MART, e será preenchida sempre que os dados daquele mês terminarem de carregar o DM. 3.6 Construção de Relatórios Para a construção dos relatórios gerenciais, foi utilizada a ferramenta Business Objects. Como exemplo, a figura 20 ilustra um relatório que atende a necessidade gerencial Quantidade de documentos emitidos por mês. 53

55 Figura 20. Relatório Documentos Emitidosmês Os usuários da empresa têm treinamento específico para o desenvolvimento dos relatórios utilizando a ferramenta BO. Sendo assim, possuem privilégios da ferramenta para que possam aplicar seus conhecimentos adquiridos nos treinamentos na confecção dos relatórios. Mesmo sendo uma ferramenta indicada para a aplicação de um DW, não é utilizada totalmente desta forma na Seara. Tanto usuários gestores como usuários finais (comuns) têm acesso ao desenvolvimento de relatórios. Entretanto, muito poucos são usados para a tomada de decisão. As validações dos dados foram realizadas com a execução dos relatórios utilizando o Business Objects, logo em seguida foram realizadas consultas diretamente na base de dados transacional utilizando linguagem SQL. Os resultados foram comparados em diversas situações, apresentando consistência em todos os dados, tanto agrupados como desagrupados. 54

56 Os dados apresentados nos relatórios são dados armazenados no ambiente de desenvolvimento da empresa durante o período de janeiro de 2003 a dezembro de 2004, conforme exposto na problematização do projeto. No ambiente de homologação da empresa (espelho da base de dados de produção) já se encontra implantado o Data Mart, sendo possível a visualização dos relatórios com dados reais e atualizados. Para a validação das consultas gerenciais, foi realizada uma reunião com o desenvolvedor do Data Mart, o Analista de Sistemas da área de exportação e o gestor da área de documentação de exportação da empresa. Por meio de uma ata de reunião (Apêndice A.9, Ata de reunião de validação), garantiu-se que as consultas estão validadas de acordo com as necessidades da área de gestão de documentação de exportação identificadas no início do projeto. 55

57 4 CONCLUSÕES O correto controle das informações de uma empresa pode significar grande redução de custos e aumento significativo da capacidade do sistema. Um Data Warehouse permite aos gestores que decisões de suma importância possam ser dadas com o conhecimento pleno de o que está acontecendo na empresa. Ao final do TCC I, tinha-se base do que deveria ser desenvolvido no TCC II. Com base no cronograma definido na pré-proposta, foram realizadas mais reuniões junto a gerencia, para que se chegasse a uma nova modelagem lógica do Data Mart antes de ser implantado. Através das entrevistas informais, chegou-se a um maior número de necessidades gerencias que poderiam ser supridas com o desenvolvimento de relatórios. A partir deste novo modelo lógico, criou-se o modelo físico. O sistema que foi neste trabalho para permitir que os gestores possam tomar as decisões corretas em relação aos custos gerados por documentos com erros, bem como repassar estes custos aos responsáveis pelos erros. Também é permitido aos gestores que tomem decisões em relação ao sistema da empresa, já que alguns erros podem ser causados pelo próprio sistema. Na construção física deste DM, foi dada a devida importância na manutenção de dados históricos, pois permite ao gestor buscar informações de períodos passados. De acordo com as necessidades dos gestores, foram criadas consultas ao DM através de relatórios. Estes relatórios foram validados pelos mesmos. Após as validações e homologações em base de teste do DM, os gestores terão a opção de implantação na base de produção da empresa, tornando possível a utilização do DM para a redução de custos de documentação e decisões relacionadas ao sistema. Os benefícios conquistados pela empresa vão além de apenas a redução de custos em relação às cartas de correção. A partir das informações analisadas nos relatórios, pode-se obter também uma melhoria na qualidade dos demais programas dos sistemas transacionais, uma vez que identificado o problema nos documentos pode-se descobrir qual programa que gerou aquele erro, e tomar as devidas providências, desde correções até reavaliação dos processos. De maneira geral, todos os objetivos previstos no início do trabalho foram alcançados. 56

58 Como benefício ao acadêmico, os fatores preponderantes foram a oportunidade de desenvolver um estudo teórico e aplicar na prática de um projeto de interesse profissional, bem como a possibilidade de demonstrar à empresa como utilizar as ferramentas Business Objects e Business Objects Designer para a geração de informações gerenciais. As melhorias deste projeto ocorrerão naturalmente, à medida que novas consultas forem necessárias para suprir informações do processo decisório dos gestores. Dependendo das necessidades poderão ser necessárias adequações nos modelos lógico e físico do Data Mart. Para trabalhos futuros, sugere-se o desenvolvimento e a implementação de Data Marts em outras áreas da empresa, tomando como base as referências bibliográficas e do projeto presentes neste trabalho. 57

59 REFERÊNCIAS BIBLIOGRÁFICAS ALMEIDA, Alexandre de; DAROLT, Reginaldo. Pesquisa e desenvolvimento em UML f. Projeto de Conclusão de Curso Curso de Ciência da Computação, Universidade do Sul de Santa Catarina, Araranguá, 2001 BERSON, A. Data Warehousing, Datamining, and OLAP. USA: McGraw-Hill, 1998 CIELO, Ivã. Data Mart, Disponível em < Acesso em: 28 abril CODD, E.F., A relational model of data for large shared data banks. Washington, EUA: Addison Wesley Publishing Company, 1970 MAZZOLA, J.; FELIPPE JR, Ovídio. CONGRESSO BRASILEIRO DE COMPUTAÇÃO, 3., 2003, Itajaí. Anais eletrônicos, Itajaí: UNIVALI, Disponível em: < Acesso em: 28 abril FANDERUFF, Damaris. Dominando o Oracle 9i: modelagem e desenvolvimento. São Paulo: Pearson Education do Brasil, FERNANDES, Lúcia. ORACLE 9i para Desenvolvedores: Oracle developer 6i, curso completo. 1. ed. Rio de Janeiro: Axcel Books, GUPTA, Vivek R. An introduction to data warehousing, Disponível em < Acesso em: 05 maio INMON, William H. Como construir o data warehouse. Rio de Janeiro: Campus, INMON, William H.; HACKATHORN, Richard D. Como usar o Data Warehouse. Rio de Janeiro: Infobook, INMON, William H.; WELCH, J. D.; GLASSEY, K. L. Gerenciamento Data Warehouse. São Paulo: Makron Books, KIMBALL, R. Data Warehouse Toolkit. São Paulo: Makron Books, LAUDON, Jane Price; LAUDON, Kenneth C. Gerenciamento de sistemas de informação. Rio de Janeiro: LTC, 2001 MUNDIM, Ana Paula de F.; BRETERNITZ, Vivaldo J. Data warehouse, Disponível em < Acesso em: 04 maio REZENDE, D. A. Engenharia de software e sistemas de informação. Rio de Janeiro: Brasport, VAZQUEZ, J. L. Manual de exportação. São Paulo: Atlas,

60 APÊNDICES 59

61 A. CMEK3600.PCK SISTEMA EXPORTACAO - CMEK -- ANALISTAPROGRAMADOR : MARCELO KATSURAYAMA -- PERIODO : CREATE OR REPLACE PACKAGE CMEK3600 IS -- PROCEDURE INCLUIR_PTO_VERIFICACAO (P_CD_PROGRAMACAO_MRM_RDV IN NUMBER,P_CD_LISTA_CARGA IN NUMBER,P_CD_PONTO_VERIFICACAO IN NUMBER -- END CMEK3600; -- CREATE OR REPLACE PACKAGE BODY CMEK3600 IS -- ERRO_GRAVE EXCEPTION; WRK_DS_ERRO VARCHAR2(2000); VA_CHAMA_DM VARCHAR2(50);,P_DS_ERRO OUT VARCHAR2 ); PROCEDURE INCLUIR_PTO_VERIFICACAO (P_CD_PROGRAMACAO_MRM_RDV IN NUMBER,P_CD_LISTA_CARGA IN NUMBER,P_CD_PONTO_VERIFICACAO IN NUMBER,P_DS_ERRO OUT VARCHAR2) IS V_CD_ORDEM NUMBER(4); PROCEDURE OBTER_ORDEM_PTO_VERIF (P_CD_PONTO_VERIFICACAO IN NUMBER,P_CD_ORDEM OUT NUMBER) IS V_CD_ORDEM NUMBER(4); BEGIN SELECT CD_ORDEM INTO V_CD_ORDEM FROM PONTO_VERIFICACAO_EXP WHERE CD_PONTO_VERIFICACAO = P_CD_PONTO_VERIFICACAO; -- P_CD_ORDEM := V_CD_ORDEM; -- EXCEPTION WHEN NO_DATA_FOUND THEN WRK_DS_ERRO := 'CMEK3600. Ponto de Verificacao nao cadastrado.'; RAISE ERRO_GRAVE; WHEN OTHERS THEN WRK_DS_ERRO := 'CMEK3600. Erro na rotina OBTER_ORDEM_PTO_VERIF. ' SQLERRM; RAISE ERRO_GRAVE; END OBTER_ORDEM_PTO_VERIF; PROCEDURE VALIDAR_PROGRAMACAO_EMBARQUE (P_CD_PROGRAMACAO_MRM_RDV IN NUMBER 60

62 ,P_CD_LISTA_CARGA IN NUMBER) IS V_EXISTE VARCHAR2(1); BEGIN IF P_CD_LISTA_CARGA > 0 THEN --Programacao de Embarque Maritima BEGIN SELECT 'X' INTO V_EXISTE FROM LISTA_CARGA_MRM_EXP_CNE WHERE CD_PLJ_TRP_MRM_EXP_CNE = P_CD_PROGRAMACAO_MRM_RDV AND CD_LISTA_CARGA = P_CD_LISTA_CARGA; EXCEPTION WHEN NO_DATA_FOUND THEN WRK_DS_ERRO := 'CMEK3600. Lista de Carga nao encontrada.'; RAISE ERRO_GRAVE; WHEN OTHERS THEN WRK_DS_ERRO := 'CMEK3600. Erro de leitura na Lista de Carga. ' SQLERRM; RAISE ERRO_GRAVE; END; ELSE BEGIN SELECT 'X' INTO V_EXISTE FROM CSD_CARGA_RDV_EXP_CNE WHERE CD_CSD_CARGA_EXP_CNE = P_CD_PROGRAMACAO_MRM_RDV; EXCEPTION WHEN NO_DATA_FOUND THEN WRK_DS_ERRO := 'CMEK3600. Consolidacao nao encontrada.'; RAISE ERRO_GRAVE; WHEN OTHERS THEN WRK_DS_ERRO := 'CMEK3600. Erro na leitura da Consolidacao. ' SQLERRM; RAISE ERRO_GRAVE; END; END IF; EXCEPTION WHEN ERRO_GRAVE THEN RAISE ERRO_GRAVE; WHEN OTHERS THEN WRK_DS_ERRO := 'CMEK3600. Erro na rotina VALIDAR_PROGRAMACAO_EMBARQUE. ' SQLERRM; RAISE ERRO_GRAVE; END VALIDAR_PROGRAMACAO_EMBARQUE; Programa Principal - INCLUIR_PTO_VERIFICACAO BEGIN -- P_DS_ERRO := NULL; -- VALIDAR_PROGRAMACAO_EMBARQUE (P_CD_PROGRAMACAO_MRM_RDV,P_CD_LISTA_CARGA); -- OBTER_ORDEM_PTO_VERIF (P_CD_PONTO_VERIFICACAO,V_CD_ORDEM); -- INSERT INTO RASTREAMENTO_EXPORTACAO (CD_SEQ_RASTREAMENTO 61

63 ,CD_PROGRAMACAO_MRM_RDV,CD_LISTA_CARGA,CD_PONTO_VERIFICACAO,CD_ORDEM,ID_USUARIO,DT_INCLUSAO) VALUES (SEQ_RASTREAMENTO_EXP.NEXTVAL,P_CD_PROGRAMACAO_MRM_RDV,P_CD_LISTA_CARGA,P_CD_PONTO_VERIFICACAO,V_CD_ORDEM,REPLACE(USER,'OPS$'),SYSDATE); -- EXCEPTION WHEN ERRO_GRAVE THEN P_DS_ERRO := WRK_DS_ERRO; WHEN OTHERS THEN P_DS_ERRO := 'CMEK3600. Erro na inclusao do Ponto de Verificacao. ' SQLERRM; IF (P_CD_PONTO_VERIFICACAO = 1 AND V_CD_ORDEM = 7) OR (P_CD_PONTO_VERIFICACAO = 2 AND V_CD_ORDEM = 80) THEN CMEK9000(P_CD_PROGRAMACAO_MRM_RDV, P_CD_LISTA_CARGA,VA_CHAMA_DM); IF VA_CHAMA_DM <> 'OK' THEN P_DS_ERRO := 'CMEK3600. Erro ao chamar CMEK9000. ' VA_CHAMA_DM; END IF; END IF; END INCLUIR_PTO_VERIFICACAO; -- END CMEK3600; GRANT EXECUTE ON CMEK3600 TO PUBLIC CREATE PUBLIC SYNONYM CMEK3600 FOR CMEK

64 A.1 CMEK9000.PCK CREATE OR REPLACE PACKAGE CMEK9000 IS PROCEDURE PRINCIPAL(P_CD_PLANEJAMENTO IN NUMBER, P_CD_LISTA_CARGA IN NUMBER, P_DS_RETORNO OUT VARCHAR2); END CMEK9000; CREATE OR REPLACE PACKAGE BODY CMEK9000 IS PROCEDURE PRINCIPAL(P_CD_PLANEJAMENTO IN NUMBER, P_CD_LISTA_CARGA IN NUMBER, P_DS_RETORNO OUT VARCHAR2) IS VA_CONT NUMBER; BEGIN P_DS_RETORNO := 'OK'; BEGIN INSERT INTO ( select distinct b.cd_programacao_mrm_rdv planejamento, b.cd_lista_carga, e.nm_navio, f.cd_csd_carga_exp_cne, g.cd_cliente_internacional, h.nm_cliente_internacional, i.cd_mercado, j.nm_mercado, decode(c.cd_ponto_verificacao, 14, 17, 15, 39, 19, 3, 20, 31, 27, 13, 41, 1), l.ds_tipo_campo, (SELECT y.cd_processo_gerencial FROM all_tab_columns x, tabela_oracle y where x.table_name = y.cd_tabela_oracle and rownum = 1), 'GRAVE', 'CMEK', c.cd_ponto_verificacao, c.ds_ponto_verificacao, 1, MAX( b.dt_inclusao), MIN( b.dt_inclusao), sysdate, user from rastreamento_exportacao b, ponto_verificacao_exp c, plj_transporte_mrm_exp_cne d, navio e, item_lista_carga_mrm_exp_cne f, pedido_exportacao_cne g, cliente_internacional h, lista_carga_mrm_exp_cne i, 63

65 mercado_exportacao j, l where b.cd_programacao_mrm_rdv = P_CD_PLANEJAMENTO and b.cd_lista_carga = P_CD_LISTA_CARGA and b.cd_ponto_verificacao = c.cd_ponto_verificacao and b.cd_ordem = c.cd_ordem and b.cd_programacao_mrm_rdv = d.cd_plj_trp_mrm_exp_cne and d.cd_navio = e.cd_navio and b.cd_programacao_mrm_rdv = f.cd_plj_trp_mrm_exp_cne and b.cd_lista_carga = f.cd_lista_carga and f.cd_plj_trp_mrm_exp_cne = i.cd_plj_trp_mrm_exp_cne and f.cd_lista_carga = i.cd_lista_carga and f.cd_pedido_exp_cne = g.cd_pedido_exp_cne and g.cd_cliente_internacional = h.cd_cliente_internacional and i.cd_mercado = j.cd_mercado and l.cd_tipo_campo = decode(c.cd_ponto_verificacao, 14, 17, 15, 39, 19, 3, 20, 31, 27, 13, 41, 1) and c.cd_ponto_verificacao in (14, 15, 19, 20, 27, 39, 41) and b.dt_inclusao between '01-jan-2003' and '31-dez-2005' GROUP BY b.cd_programacao_mrm_rdv, b.cd_lista_carga, e.nm_navio, f.cd_csd_carga_exp_cne, g.cd_cliente_internacional, h.nm_cliente_internacional, i.cd_mercado, j.nm_mercado, decode(c.cd_ponto_verificacao, 14, 17, 15, 39, 19, 3, 20, 31, 27, 13, 41, 1), l.ds_tipo_campo, null, null, 'CMEK', c.cd_ponto_verificacao, c.ds_ponto_verificacao, 1, sysdate, user); EXCEPTION WHEN NO_DATA_FOUND THEN NULL; WHEN OTHERS THEN P_DS_RETORNO := ('CMEK9000.ERRO-Inserindo na tabela de transição, ' sqlerrm); RETURN; END; BEGIN BEGIN SELECT 1 INTO VA_CONT FROM FLAG_DATA_MART WHERE DT_MES_ANO = TRUNC(SYSDATE, 'MM'); EXCEPTION WHEN NO_DATA_FOUND THEN VA_CONT := 0; WHEN OTHERS THEN P_DS_RETORNO := ('CMEK9000.ERRO-Busca data FLAG, ' sqlerrm); RETURN; END; 64

66 BEGIN IF VA_CONT = 0 THEN INSERT INTO FLAG_DATA_MART VALUES (TRUNC(SYSDATE, 'MM'), 'N', USER, SYSDATE); END IF; EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9000.ERRO-Insere FLAG_DATA_MART, ' sqlerrm); RETURN; END; END; END PRINCIPAL; END CMEK9000; CREATE or replace PUBLIC SYNONYM CMEK9000 FOR CMEK9000 GRANT EXECUTE ON CMEK9000 TO PUBLIC 65

67 A.2 CMEK9001.PCK CREATE OR REPLACE PACKAGE CMEK9001 IS PROCEDURE PRINCIPAL(P_DS_RETORNO OUT VARCHAR2); END CMEK9001; CREATE OR REPLACE PACKAGE BODY CMEK9001 IS PROCEDURE PRINCIPAL(P_DS_RETORNO OUT VARCHAR2) IS VL_MEDIA_VALOR NUMBER(16,8); VA_CONTROLE NUMBER(1); BEGIN P_DS_RETORNO := 'OK'; BEGIN SELECT AVG(A.VL_VENDA) INTO VL_MEDIA_VALOR FROM GR_VALOR_MOEDA A WHERE A.CD_MOEDA = 10 AND DT_MOEDA = TRUNC(SYSDATE); EXCEPTION WHEN NO_DATA_FOUND THEN VL_MEDIA_VALOR := 0; WHEN OTHERS THEN P_DS_RETORNO := ('CMEK9001.ERRO-Buscando valor médio cotação mensal, ' sqlerrm); RETURN; END; BEGIN SELECT 1 INTO VA_CONTROLE FROM TRANSICAO_MOEDA_EXP_CNE WHERE DT_MES_MOEDA = TRUNC(SYSDATE, 'MM'); EXCEPTION WHEN NO_DATA_FOUND THEN VA_CONTROLE := 0; WHEN OTHERS THEN P_DS_RETORNO := ('CMEK9001.ERRO-Buscando informação tabela moeda transição, ' sqlerrm); RETURN; END; IF VA_CONTROLE = 0 THEN BEGIN INSERT INTO TRANSICAO_MOEDA_EXP_CNE VALUES ( 10, -- DOLAR (COD. INTERNO DO SISTEMA RELACIONAL) 'DOLAR', TRUNC(SYSDATE, 'MM'), VL_MEDIA_VALOR ); EXCEPTION WHEN OTHERS THEN 66

68 P_DS_RETORNO := ('CMEK9001.ERRO-Inserindo tabela transição moeda, ' sqlerrm); RETURN; END; ELSE BEGIN UPDATE TRANSICAO_MOEDA_EXP_CNE SET VL_MOEDA = VL_MEDIA_VALOR WHERE DT_MES_MOEDA = TRUNC(SYSDATE, 'MM'); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := ('CMEK9001.ERRO-Atualizando tabela transição moeda, ' sqlerrm); RETURN; END; END IF; END PRINCIPAL; END CMEK9001; CREATE or replace PUBLIC SYNONYM CMEK9001 FOR CMEK9001 GRANT EXECUTE ON CMEK9001 TO PUBLIC 67

69 A.3 CMEK9002.PCK CREATE OR REPLACE PACKAGE CMEK9002 IS PROCEDURE PRINCIPAL(P_DS_RETORNO OUT VARCHAR2); END CMEK9002; CREATE OR REPLACE PACKAGE BODY CMEK9002 IS PROCEDURE PRINCIPAL(P_DS_RETORNO OUT VARCHAR2) IS CURSOR C1 IS SELECT CD_PLJ_TRP_MRM_EXP_CNE, CD_LISTA_CARGA, NM_NAVIO, CD_CSD_CARGA_EXP_CNE, CD_CLIENTE_INTERNACIONAL, NM_CLIENTE_INTERNACIONAL, CD_MERCADO, NM_MERCADO, CD_TIPO_CAMPO, DS_TIPO_CAMPO, DS_RESPONSAVEL_ERRO, DS_GRAVIDADE_ERRO, CD_SISTEMA_ORIGEM, CD_TIPO_DOC, DS_TIPO_DOC, ID_STATUS_ERRO, DT_GERACAO_DOCUMENTO, DT_ERRO, DT_ATUALIZACAO, ID_USUARIO FROM TRANSICAO_DOCUMENTACAO_EXP_CNE; VA_CH_CLIENTE NUMBER; VA_CH_MERCADO NUMBER; VA_CH_PLANEJAMENTO NUMBER; VA_CH_TIPO_DOC NUMBER; VA_CH_TIPO_CAMPO NUMBER; VA_VL_CARTA_CORRECAO NUMBER(5,2); BEGIN P_DS_RETORNO := 'OK'; BEGIN -- BUSCA ULTIMA CHAVE CLIENTE BEGIN SELECT MAX(NVL(CHAVE_CLIENTE,0)) + 1 INTO VA_CH_CLIENTE FROM DIM_CLIENTE; EXCEPTION WHEN NO_DATA_FOUND THEN VA_CH_CLIENTE := 0; 68

70 WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao dim_cliente. ' sqlerrm; RETURN; buscar maior chave tabela END; -- BUSCA ULTIMA CHAVE MERCADO BEGIN SELECT MAX(NVL(CHAVE_MERCADO,0)) + 1 INTO VA_CH_MERCADO FROM DIM_MERCADO; EXCEPTION WHEN NO_DATA_FOUND THEN VA_CH_MERCADO := 0; WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao dim_mercado. ' sqlerrm; RETURN; buscar maior chave tabela END; -- BUSCA ULTIMA CHAVE PLANEJAMENTO BEGIN SELECT MAX(NVL(CHAVE_PLANEJAMENTO,0)) + 1 INTO VA_CH_PLANEJAMENTO FROM DIM_PLANEJAMENTO; EXCEPTION WHEN NO_DATA_FOUND THEN VA_CH_PLANEJAMENTO := 0; WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao dim_planejamento. ' sqlerrm; RETURN; buscar maior chave tabela END; -- BUSCA ULTIMA CHAVE TIPO DOCUMENTO BEGIN SELECT MAX(NVL(CHAVE_TIPO_DOC,0)) + 1 INTO VA_CH_TIPO_DOC FROM DIM_TIPO_DOCUMENTO; EXCEPTION WHEN NO_DATA_FOUND THEN VA_CH_TIPO_DOC:= 0; WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao dim_tipo_documento. ' sqlerrm; RETURN; buscar maior chave tabela END; -- BUSCA ULTIMA CHAVE TIPO CAMPO BEGIN SELECT MAX(NVL(CHAVE_TIPO_CAMPO,0)) + 1 INTO VA_CH_TIPO_CAMPO FROM DIM_TIPO_CAMPO; EXCEPTION WHEN NO_DATA_FOUND THEN 69

71 VA_CH_TIPO_CAMPO:= 0; WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao dim_tipo_campo. ' sqlerrm; RETURN; buscar maior chave tabela END; FOR R1 IN C1 LOOP -- CARGA TABELA DIM_CLIENTE BEGIN INSERT INTO DIM_CLIENTE VALUES( VA_CH_CLIENTE, R1.CD_CLIENTE_INTERNACIONAL, R1.NM_CLIENTE_INTERNACIONAL); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao inserir dim_cliente, ' sqlerrm; RETURN; END; -- CARGA TABELA DIM_MERCADO BEGIN INSERT INTO DIM_MERCADO VALUES( VA_CH_MERCADO, R1.CD_MERCADO, R1.NM_MERCADO); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao inserir dim_mercado, ' sqlerrm; RETURN; END; -- CARGA TABELA DIM_PLANEJAMENTO BEGIN INSERT INTO DIM_PLANEJAMENTO VALUES( VA_CH_PLANEJAMENTO, R1.CD_PLJ_TRP_MRM_EXP_CNE, R1.CD_LISTA_CARGA, R1.NM_NAVIO); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao inserir dim_planejamento, ' sqlerrm; RETURN; END; -- CARGA TABELA DIM_TIPO_DOCUMENTO BEGIN BEGIN SELECT VL_CARTA_CORRECAO INTO VA_VL_CARTA_CORRECAO FROM VALOR_CARTA_CORRECAO WHERE CD_TIPO_DOC = R1.CD_TIPO_DOC; EXCEPTION WHEN NO_DATA_FOUND THEN VA_VL_CARTA_CORRECAO := 0; 70

72 WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao buscar valor da carta de correcao. ' sqlerrm; RETURN; END; INSERT INTO DIM_TIPO_DOCUMENTO VALUES( VA_CH_TIPO_DOC, R1.CD_TIPO_DOC, R1.DS_TIPO_DOC, VA_VL_CARTA_CORRECAO); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao inserir dim_tipo_documento, ' sqlerrm; RETURN; END; -- CARGA TABELA DIM_TIPO_CAMPO BEGIN INSERT INTO DIM_TIPO_CAMPO VALUES( VA_CH_TIPO_CAMPO, R1.CD_TIPO_CAMPO, R1.DS_TIPO_CAMPO, NULL, R1.DS_RESPONSAVEL_ERRO, R1.DS_GRAVIDADE_ERRO, R1.CD_SISTEMA_ORIGEM); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao inserir dim_tipo_campo, ' sqlerrm; RETURN; END; -- CARGA TABELA FATO DOCUMENTAÇÃO BEGIN INSERT INTO FT_DOCUMENTACAO_EXP_CNE VALUES ( 'TEMPO', VA_CH_CLIENTE, VA_CH_MERCADO, VA_CH_PLANEJAMENTO, VA_CH_TIPO_DOC, VA_CH_TIPO_CAMPO, 'QT_ERRADOS', 'QT_CORRETOS' 'PR_ERROS', 'PR_ACERTOS'); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9002. Erro ao inserir na tabela fato ft_documentacao_exp_cne' sqlerrm; RETURN; END; END LOOP; 71

73 END; END PRINCIPAL; END CMEK9002; CREATE or replace PUBLIC SYNONYM CMEK9002 FOR CMEK9002 GRANT EXECUTE ON CMEK9002 TO PUBLIC 72

74 A.4 SCRIPT CRIAÇÃO DM CREATE TABLE DIM_MOEDA (CHAVE_MOEDA NUMBER(7) NOT NULL, CD_MOEDA NUMBER(3) NOT NULL, NM_MOEDA VARCHAR2(10) NOT NULL ) CREATE or replace PUBLIC SYNONYM DIM_MOEDA FOR DIM_MOEDA grant select on DIM_MOEDA to PUBLIC ALTER TABLE DIM_MOEDA ADD CONSTRAINT DIM_MOEDA_PK PRIMARY KEY (CHAVE_MOEDA) CREATE TABLE DIM_TEMPO (CHAVE_TEMPO NUMBER(7) NOT NULL, DT_MES NUMBER(2) NOT NULL, DT_ANO_CALENDARIO NUMBER(4) NOT NULL, DT_ANO_FISCAL NUMBER(4) NOT NULL, DT_BIMESTRE NUMBER(1) NOT NULL, DT_TRIMESTRE NUMBER(1) NOT NULL, DT_SEMESTRE NUMBER(1) NOT NULL ) CREATE or replace PUBLIC SYNONYM DIM_TEMPO FOR DIM_TEMPO grant select on DIM_TEMPO to PUBLIC ALTER TABLE DIM_TEMPO ADD CONSTRAINT DIM_TEMPO_PK PRIMARY KEY (CHAVE_TEMPO) CREATE TABLE DIM_CLIENTE (CHAVE_CLIENTE NUMBER(7) NOT NULL, CD_CLIENTE NUMBER(5) NOT NULL, NM_CLIENTE VARCHAR2(50) NOT NULL ) CREATE or replace PUBLIC SYNONYM DIM_CLIENTE FOR DIM_CLIENTE grant select on DIM_CLIENTE to PUBLIC ALTER TABLE DIM_CLIENTE ADD CONSTRAINT DIM_CLIENTE_PK PRIMARY KEY (CHAVE_CLIENTE) CREATE TABLE DIM_MERCADO (CHAVE_MERCADO NUMBER(7) NOT NULL, CD_MERCADO NUMBER(2) NOT NULL, NM_MERCADO VARCHAR2(40) NOT NULL ) CREATE or replace PUBLIC SYNONYM DIM_MERCADO FOR DIM_MERCADO 73

75 grant select on DIM_MERCADO to PUBLIC ALTER TABLE DIM_MERCADO ADD CONSTRAINT DIM_MERCADO_PK PRIMARY KEY (CHAVE_MERCADO) CREATE TABLE DIM_PLANEJAMENTO (CHAVE_PLJ NUMBER(7) NOT NULL, CD_PLANEJAMENTO NUMBER(6) NOT NULL, CD_LISTA_CARGA NUMBER(2) NOT NULL, NM_NAVIO VARCHAR2(100) NOT NULL ) CREATE or replace PUBLIC SYNONYM DIM_PLANEJAMENTO FOR DIM_PLANEJAMENTO grant select on DIM_PLANEJAMENTO to PUBLIC ALTER TABLE DIM_PLANEJAMENTO ADD CONSTRAINT DIM_PLANEJAMENTO_PK PRIMARY KEY (CHAVE_PLJ) CREATE TABLE DIM_TIPO_DOCUMENTO (CHAVE_TIPO_DOC NUMBER(7) NOT NULL, CD_TIPO_DOC NUMBER(4) NOT NULL, DS_TIPO_DOC VARCHAR2(40) NOT NULL, VL_CARTA_CORRECAO NUMBER(5,2) NOT NULL ) CREATE or replace PUBLIC SYNONYM DIM_TIPO_DOCUMENTO FOR DIM_TIPO_DOCUMENTO grant select on DIM_TIPO_DOCUMENTO to PUBLIC ALTER TABLE DIM_TIPO_DOCUMENTO ADD CONSTRAINT DIM_TIPO_DOC_PK PRIMARY KEY (CHAVE_TIPO_DOC) CREATE TABLE DIM_TIPO_CAMPO (CHAVE_TIPO_CAMPO NUMBER(7) NOT NULL, CD_TIPO_CAMPO NUMBER(3) NOT NULL, DS_TIPO_CAMPO VARCHAR2(50) NOT NULL, DS_AGRUPAMENTO VARCHAR2(50), DS_RESPONSAVEL_ERRO VARCHAR2(50), DS_GRAVIDADE_ERRO VARCHAR2(50), CD_SISTEMA_ORIGEM VARCHAR2(4) ) CREATE or replace PUBLIC SYNONYM DIM_TIPO_CAMPO FOR DIM_TIPO_CAMPO grant select on DIM_TIPO_CAMPO to PUBLIC ALTER TABLE DIM_TIPO_CAMPO ADD CONSTRAINT DIM_TIPO_CAMPO_PK PRIMARY KEY (CHAVE_TIPO_CAMPO) 74

76 CREATE TABLE FT_DOCUMENTACAO_EXP_CNE (CHAVE_TEMPO NUMBER(7) NOT NULL, CHAVE_CLIENTE NUMBER(7) NOT NULL, CHAVE_MERCADO NUMBER(7) NOT NULL, CHAVE_PLANEJAMENTO NUMBER(7) NOT NULL, CHAVE_TIPO_DOC NUMBER(7) NOT NULL, CHAVE_TIPO_CAMPO NUMBER(7) NOT NULL, QT_ERRADOS NUMBER(7), QT_CORRETOS NUMBER(7), QT_DOC_EMITIDOS NUMBER(7), PR_ERROS NUMBER(5), PR_ACERTOS NUMBER(5) ) CREATE or replace PUBLIC SYNONYM FT_DOCUMENTACAO_EXP_CNE FOR FT_DOCUMENTACAO_EXP_CNE grant select on FT_DOCUMENTACAO_EXP_CNE to PUBLIC CREATE TABLE FT_COTACAO (CHAVE_MOEDA NUMBER(7) NOT NULL, CHAVE_TEMPO NUMBER(7) NOT NULL, VL_COTA_MEDIA_MES NUMBER(16,8) NOT NULL ) CREATE or replace PUBLIC SYNONYM FT_COTACAO FOR FT_COTACAO grant select on FT_COTACAO to PUBLIC 75

77 A.5 SCRIPT CRIAÇÃO TRANSIÇÃO create table transicao_documentacao_exp_cne (cd_plj_trp_mrm_exp_cne number(6), cd_lista_carga number(2), nm_navio varchar2(100), cd_csd_carga_exp_cne number(6), cd_cliente_internacional number(5), nm_cliente_internacional varchar2(50), cd_mercado number(2), nm_mercado varchar2(40), cd_tipo_campo number(3), ds_tipo_campo varchar2(50), ds_responsavel_erro varchar2(50), ds_gravidade_erro varchar2(50), cd_sistema_origem varchar2(4), cd_tipo_doc number(4), ds_tipo_doc varchar2(40), id_status_erro number(1), dt_geracao_documento date, dt_erro date, dt_atualizacao date, id_usuario varchar2(12) ) CREATE or replace PUBLIC SYNONYM transicao_documentacao_exp_cne FOR transicao_documentacao_exp_cne grant select on transicao_documentacao_exp_cne to PUBLIC create table tipo_campo_doc_exp (cd_tipo_campo number(3), cd_tipo_dct_exp_cne number(2), ds_tipo_campo varchar2(50), id_usuario varchar2(12), dt_atualizacao date ) CREATE or replace PUBLIC SYNONYM TIPO_CAMPO_DOC_EXP FOR TIPO_CAMPO_DOC_EXP grant select on TIPO_CAMPO_DOC_EXP to PUBLIC create table transicao_moeda_exp_cne (cd_moeda number(3), nm_moeda varchar2(10), dt_mes_moeda date, vl_moeda number(16,8)) CREATE or replace PUBLIC SYNONYM transicao_moeda_exp_cne FOR transicao_moeda_exp_cne grant select on transicao_moeda_exp_cne to PUBLIC 76

78 create table valor_carta_correcao (cd_tipo_doc number(4), vl_carta_correcao number(5,2), id_usuario varchar2(12), dt_atualizacao date ) CREATE or replace PUBLIC SYNONYM valor_carta_correcao FOR valor_carta_correcao grant select on valor_carta_correcao to PUBLIC create table FLAG_DATA_MART (DT_MES_ANO DATE, ID_COMPLETO VARCHAR2(1) DEFAULT 'N', ID_USUARIO VARCHAR2(12), DT_ATUALIZACAO DATE) CREATE or replace PUBLIC SYNONYM FLAG_DATA_MART FOR FLAG_DATA_MART grant select on FLAG_DATA_MART to PUBLIC 77

79 A.6 CMEK9003.PCK CREATE OR REPLACE PACKAGE CMEK9003 IS PROCEDURE PRINCIPAL(P_DS_RETORNO OUT VARCHAR2); END CMEK9003; CREATE OR REPLACE PACKAGE BODY CMEK9003 IS PROCEDURE PRINCIPAL(P_DS_RETORNO OUT VARCHAR2) IS VA_CH_MOEDA VA_CH_TEMPO VA_CD_MOEDA VA_NM_MOEDA VA_DATA VA_VL_MOEDA NUMBER; NUMBER; NUMBER; VARCHAR2(10); DATE; NUMBER(16,8); BEGIN P_DS_RETORNO := 'OK'; -- BUSCA ULTIMA CHAVE MOEDA BEGIN SELECT MAX(NVL(CHAVE_MOEDA,0)) + 1 INTO VA_CH_MOEDA FROM DIM_MOEDA; EXCEPTION WHEN NO_DATA_FOUND THEN VA_CH_MOEDA := 0; WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9003. Erro ao dim_moeda. ' sqlerrm; RETURN; buscar maior chave tabela END; BEGIN SELECT CD_MOEDA, NM_MOEDA, DT_MES_MOEDA, VL_MOEDA INTO VA_CD_MOEDA, VA_NM_MOEDA, VA_DATA, VA_VL_MOEDA FROM TRANSICAO_MOEDA_EXP_CNE WHERE DT_MES_MOEDA = TRUNC(SYSDATE, 'MM'); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9003. Erro ao buscar tabela de transicao_moeda. ' sqlerrm; RETURN; END; BEGIN 78

80 SELECT CHAVE_TEMPO INTO VA_CH_TEMPO FROM DIM_TEMPO WHERE DT_MES = TRUNC(SYSDATE, 'MM'); EXCEPTION WHEN NO_DATA_FOUND THEN SELECT MAX(CHAVE_TEMPO) + 1 INTO VA_CH_TEMPO FROM DIM_TEMPO; WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9003. Erro ao buscar chave tempo. ' sqlerrm; RETURN; END; BEGIN INSERT INTO DIM_MOEDA VALUES (VA_CH_MOEDA, VA_CD_MOEDA, VA_NM_MOEDA ); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9003. Erro ao inserir dim_moeda. ' sqlerrm; RETURN; END; BEGIN INSERT INTO FT_COTACAO VALUES (VA_CH_MOEDA, VA_CH_TEMPO, VA_VL_MOEDA ); EXCEPTION WHEN OTHERS THEN P_DS_RETORNO := 'CMEK9003. Erro ao inserir ft_cotacao. ' sqlerrm; RETURN; END; END PRINCIPAL; END CMEK9003; CREATE or replace PUBLIC SYNONYM CMEK9003 FOR CMEK9003 GRANT EXECUTE ON CMEK9003 TO PUBLIC 79

81 A.7 CRIAÇÃO DE UNIVERSO B.O. Este apêndice tem por objetivo mostrar a construção de um no universo de tabelas utilizandose da ferramenta Business Objects 5. Para a construção de um novo universo, é necessária a utilização da ferramenta Designer. Após aberto, foi solicitado a criação de um novo universo, e preenchimento de alguns parâmetros, como nome do universo e conexão com o banco desejado (neste caso, foi escolhido o nome Universo BO, e o banco de dados de desenvolvimento da empresa, c0827dvm ), conforme figura 21. Figura 21. Criação de um novo universo Após criado, o universo estará vazio, conforme figura

82 Figura 22. Universo vazio Com um duplo clique em qualquer parte da área branca, abrirá uma pequena tela, para que possam ser inseridas as tabelas que serão utilizadas para compor o universo. Na figura 23, pode-se visualizar a lista das tabelas e as que serão inseridas no universo. 81

83 Figura 23. Inserção de tabelas no universo. Após inseridas, as tabelas devem ser interligadas pela sua chave primária, clicando na tabela de origem, em cima do campo da chave, e arrastando com o mouse até em cima do campo chave da tabela de destino, conforme figura 24. Todas as tabelas devem estar ligadas devidamente, caso contrário, podem gerar produtos cartesianos no momento das consultas. 82

84 Figura 24. Ligando chaves primárias entre tabelas Após ligadas as chaves, deve-se ter um universo semelhante ao ilustrado na figura

85 Figura 25. Universo ligado Uma vez terminado o desenho das tabelas no universo, deverão ser criados as classes com os campos disponíveis para consulta, para que o usuário possa desenvolver os relatórios. Para que isso possa ser feito, deve-se arrastar a tabela desejada até a caixa que encontra-se no canto esquerdo da tela. O BO Designer irá criar a classe automaticamente, conforme figura

86 Figura 26. Criação de classes Com o universo completamente criado (Figura 27), pode-se exportá-lo para a produção, onde ficará disponível para todos os usuários com permissão desenvolverem seus relatórios para conferências e outros objetivos. 85

87 Figura 27. Universo DM completo. 86

88 A.8 RELATÓRIOS Quantidade de documentos emitidos por mês; Figura 28. Documentos emitidosmês 87

89 Quantidade de documentos emitidos com erro e quantidade de documentos emitidos sem erros (bem como suas respectivas porcentagens); Figura 29. Documentos corretosdocumentos errados 88

90 Quantidades de documentos emitidos com erros e sem erros por cliente; Figura 30. Documentos com erros e sem erros por cliente 89

91 Quantidades de documentos emitidos com erros e sem erros por mercado; Figura 31. Documentos com erros e sem erros por mercado 90

92 Quantidades de documentos emitidos com erros e sem erros por planejamento (navio); Figura 32. Documentos com erros e sem erros por navio 91

93 Quais documentos geram mais erros; Figura 33. Documentos com erros 92

94 Custo gerado através de cartas de correção por documento; Custo gerado através de cartas de correção total; Figura 34. Documentos com errosvalores e custo total 93

95 Responsáveis pelos erros, bem como identificação de reincidência, entre outros. Figura 35. Relatório gerencial geral 94