UNIVERSIDADE DO VALE DO ITAJA CENTRO DE CINCIAS TECNOLGICAS DA TERRA E DO MAR

CURSO DE CINCIA DA COMPUTAO

IMPLEMENTAO DE UM DATA MART PARA ANLISE DE DOCUMENTAO DESTINADA EXPORTAO PARA SEARA

ALIMENTOS

rea de Banco de Dados

por

Marcelo Katsurayama Reinert

Luis Carlos Martins, Esp. Orientador

Luis Antnio Lobo, Bel. Co-orientador

Itaja (SC), novembro de 2006

UNIVERSIDADE DO VALE DO ITAJA CENTRO DE CINCIAS TECNOLGICAS DA TERRA E DO MAR

CURSO DE CINCIA DA COMPUTAO

IMPLEMENTAO DE UM DATA MART PARA ANLISE DE DOCUMENTAO DESTINADA EXPORTAO PARA SEARA

ALIMENTOS

rea de Banco de Dados

por

Marcelo Katsurayama Reinert

Relatrio apresentado Banca Examinadora do Trabalho de Concluso do Curso de Cincia da Computao para anlise e aprovao. Orientador: Luis Carlos Martins, Esp.

Itaja (SC), novembro de 2006

ii

SUMRIO

LISTA DE ABREVIATURAS.................................................................iv LISTA DE FIGURAS................................................................................v RESUMO...................................................................................................vi ABSTRACT ............................................................................................ vii 1 INTRODUO.....................................................................................8 1.1 PROBLEMATIZAO......................................................................................9 1.1.1 Formulao do Problema .................................................................................9 1.1.2 Soluo Proposta ...............................................................................................9 1.2 OBJETIVOS.......................................................................................................10 1.2.1 Objetivo Geral .................................................................................................10 1.2.2 Objetivos Especficos.......................................................................................10 1.3 METODOLOGIA..............................................................................................11 1.4 ESTRUTURA DO TRABALHO......................................................................11

2 FUNDAMENTAO TERICA .....................................................13 2.1 ESTUDO DE CONCEITOS .............................................................................13 2.1.1 Oracle ...............................................................................................................13 2.1.2 Data Warehouse ..............................................................................................14 2.1.3 OLAP................................................................................................................18 2.1.4 OLTP X OLAP ................................................................................................21 2.1.5 Topologias de um Data Warehouse ...............................................................24 2.1.6 Sistemas de Apoio a Deciso...........................................................................29 2.2 REA DE EXPORTAO DA SEARA ALIMENTOS S.A........................29 2.2.1 Processo de Exportao ..................................................................................30

3 DESENVOLVIMENTO .....................................................................42 3.1 MODELAGEM..................................................................................................45 3.2 ANLISE DE INFORMAES GERENCIAIS ...........................................47 3.3 CONSTRUO DO MODELO FSICO........................................................49 3.4 MODELAGEM LGICA DAS TABELAS DE TRANSIO ....................50 3.5 PROCESSO DE CARGA NA REA DE TRANSIO...............................51 3.6 CONSTRUO DE RELATRIOS...............................................................53

4 CONCLUSES ...................................................................................56 REFERNCIAS BIBLIOGRFICAS...................................................58 A. CMEK3600.pck ...................................................................................60 A.1 CMEK9000.PCK................................................................................................63 A.2 CMEK9001.PCK................................................................................................66 A.3 CMEK9002.PCK................................................................................................68

iii

A.4 SCRIPT CRIAO DM...................................................................................73 A.5 SCRIPT CRIAO TRANSIO..................................................................76 A.6 CMEK9003.PCK................................................................................................78 A.7 CRIAO DE UNIVERSO B.O......................................................................80 A.8 RELATRIOS...................................................................................................87 A.9 ATA DE REUNIO DE VALIDAO ..........................................................95

iv

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 Sanitrio Internacional DASD Dispositivo de Armazenamento de Acesso Direto DM Data Mart DW Data Warehouse EMBA Embarque EUA Estad Estados Unidos da Amrica

EXP Exportao FIL Filial ITM Item MRM Martimo OLAP Online Analytical Processing OLTP Online Transaction Processing PGM Programao RDBMS Relational Data Base Management System RDV Rodovirio RE Registro de Exportao REG Registro SAD Sistema de Apoio a Deciso SGBD Sistema Gerenciador de Banco de Dados SIF Servio de Inspeo Federal SIG Sistema de Informaes Gerenciais SISCOMEX Sistema Integrado de Comrcio Exterior SMX Siscomex SQL Structured Query Language RSI TCC

Relational Software Incorporated Trabalho de Concluso de Curso

TI Tecnologia da Informao UNIVALI Universidade do Vale do Itaja

v

LISTA DE FIGURAS

Figura 1. Niveis de detalhamento ...................................................................................................... 17 Figura 2. Data Warehouse centralizado............................................................................................ 25 Figura 3. Data Warehouse distribudo.............................................................................................. 26 Figura 4. Arquitetura de Data Mart ................................................................................................... 27 Figura 5. Data Mart dependente ........................................................................................................ 28 Figura 6. Data Mart independente ..................................................................................................... 28 Figura 7. Estrutura de tabelas de registro de exportao................................................................... 32 Figura 8. Estrutura de tabelas de conhecimento de embarque .......................................................... 34 Figura 9. Estrutura de tabelas de fatura comercial ............................................................................ 36 Figura 10. Estrutura de tabelas de certificado de origem .................................................................. 37 Figura 11. Estrutura de tabelas de border de cobrana.................................................................... 38 Figura 12. Estrutura de tabelas de Certificado Sanitrio Internacional ............................................. 40 Figura 13. Tela de gerao de Certificado Sanitrio Internacional ................................................... 41 Figura 14. Modelo relacional CMEK................................................................................................ 43 Figura 15. Modelagem dimensional do Data Mart............................................................................ 46 Figura 16. Modelagem Dimensional baseado nas necessidades gerenciais. ..................................... 48 Figura 17. Estrutura da tabela de transio de documentao........................................................... 50 Figura 18. Estrutura da tabela de transio da moeda ....................................................................... 51 Figura 19. Processo de carga das tabelas........................................................................................... 52 Figura 20. Relatrio Documentos Emitidos/ms............................................................................... 54 Figura 21. Criao de um novo universo........................................................................................... 80 Figura 22. Universo vazio ................................................................................................................. 81 Figura 23. Insero de tabelas no universo........................................................................................ 82 Figura 24. Ligando chaves primrias entre tabelas ........................................................................... 83 Figura 25. Universo ligado ................................................................................................................ 84 Figura 26. Criao de classes ............................................................................................................ 85 Figura 27. Universo DM completo.................................................................................................... 86 Figura 28. Documentos emitidos/ms ............................................................................................... 87 Figura 29. Documentos corretos/Documentos errados...................................................................... 88 Figura 30. Documentos com erros e sem erros por cliente ............................................................... 89 Figura 31. Documentos com erros e sem erros por mercado ............................................................ 90 Figura 32. Documentos com erros e sem erros por navio ................................................................. 91 Figura 33. Documentos com erros..................................................................................................... 92 Figura 34. Documentos com erros e valores ..................................................................................... 93 Figura 35. Relatrio gerencial geral .................................................................................................. 94

vi

RESUMO

REINERT, Marcelo K. Implementao de um Data Mart para Anlise de Documentao destinada Exportao para Seara Alimentos. Itaja, 2006. 55 f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao)Centro de Cincias Tecnolgicas da Terra e do Mar, Universidade do Vale do Itaja, Itaja, 2006.

Este trabalho apresenta a modelagem de uma arquitetura para a anlise de dados aplicada rea de Documentao de Exportao da empresa Seara Alimentos S.A., visando a busca da quantidade e das causas de erros encontrados nos documentos destinados exportao de carnes e derivados. A arquitetura utilizada de um Data Warehouse, utilizando a topologia de Data Mart. O objetivo principal criar o modelo lgico para a construo do modelo fsico, que permitir aos gestores, obter informaes necessrias para as tomadas de decises. No cenrio corporativo, uma deciso correta pode significar drstica diminuio de custos, tornando assim o negcio mais rentvel, pois com a diminuio de custos, obtm-se preos 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 relatrios precisos aos gestores. Tanto as necessidades gerenciais, quanto a validao deste trabalho foram feitas pelos prprios gestores, para que essas informaes possam ser utilizadas tanto na empresa quanto em anlises dentro da sala de aula.

Palavras-chave: Data Mart. Informao. Tomada de deciso. Custos.

vii

ABSTRACT

This work presents the modeling of an architecture to data analysis applied in Seara Alimentos Exportation Documentation area, searching the quantity and the mistakes causes found in the documents destined to meat and deriveds exportation. The architecture utilized is a Data Warehouse utilizing the Data Marts topology. The main objective is createthe logical model to fisical models 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.

1 INTRODUO

Num cenrio corporativo, o domnio da informao torna-se um aspecto de extrema

importncia para que uma empresa possa se consolidar num mercado cada vez mais competitivo. A

informao passa a ser um bem com valor inestimvel dentro da corporao. Para que esse controle

possa existir, necessrio, alm da organizao de seus gestores, ferramentas e um banco de

informaes que possam auxiliar no processo de tomada de deciso, 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, no-voltil, e varivel em relao ao tempo, de apoio s decises gerenciais.

Sendo assim, trata-se basicamente de uma construo arquitetnica de um sistema de

informaes, que fornece aos seus usurios informaes histricas de apoio a decises. Desta

forma, acaba formando uma base de dados que permite efetuar um tratamento adequado a

informao, podendo assim, habilitar a descoberta e a explorao de tendncias empresariais de

suma importncia (INMON, 1997).

Porm, a criao de um DW no est restritamente ligada a tecnologia de banco de dados ou

de servidores. Alm destes fatores, de extrema importncia 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 informaes de acordo com as necessidades de seus gerentes e

diretores. Este processo de organizao dos dados consolidado com novos mtodos de

estruturao e armazenamento dos dados j existentes em sua base. Pelo fato de j existir uma base

de dados na empresa, ser necessrio a implementao de um novo DW (INMON, 1997).

Dentro dessa nova estrutura, importante que exista uma integridade das informaes

contidas na base em que os dados so extrados, ou seja, as inconsistncias existentes devem estar

desfeitas.

A no-volatilidade abordada por Inmon (1997) est relacionada em apenas acessar e carregar

os dados, no modificando os mesmos. Outra caracterstica significativa a manuteno de dados

9

histricos, isto , vrios dados sobre um determinado assunto, tratados em diferentes tempos, so

armazenados para permitir analises que demandam de um contexto histrico. Foi observada a

possvel utilizao de um Data Mart, que, segundo Inmon(1997), tem-se como meta organizar, por

exemplo, cada setor da corporao, sendo que cada rea passa a ter seu prprio repositrio de

dados.

1.1 PROBLEMATIZAO

1.1.1 Formulao do Problema A Seara Alimentos S.A., empresa do ramo industrial de produtos alimentcios e

frigorificados, com matriz situada em Itaja/SC possui, em mdia, 75% de seu faturamento provido

de negociaes com clientes do mercado externo, gerando em mdia, um volume de 12.368

documentos necessrios exportao, e enviados aos clientes e rgos responsveis pelo controle

dessas transaes internacionais. Como exemplos de documentos utilizados, pode-se citar o

Certificado Sanitrio Internacional (Enviado ao Ministrio da Agricultura e Pecuria Brasileira), o

Certificado de Origem, o Certificado de No-Radioatividade, o Certificado Form-A (Enviados ao

cliente final), a Invoice (fatura comercial internacional, enviada ao cliente final), o Border de

Cobrana (enviado ao cliente e ao banco responsvel pelas transaes financeiras internacionais), o

Registro de Exportao (enviado Receita Federal), entre outros.

Na Seara Alimentos, 100% dos documentos necessrios para concretizao dessas

negociaes so gerados automaticamente via sistema. Pela imensa demanda das exportaes, e,

conseqentemente, uma grande quantidade de documentos gerados, a incidncia de erros

proporcional.

Na ocorrncia de erros, uma Carta de Correo necessria. Cada Carta de Correo gera

um custo para a Empresa, variando entre US$ 50,00 e US$ 150,00. Em mdia, 5% dos documentos

gerados apresentam erros. Efetuando o clculo, cerca de US$ 61.800,00 so gastos em cartas de

correo, baseado em informaes entre janeiro 2003 dezembro de 2004, quando possua-se uma

mdia de 12.368 documentos emitidos mensalmente.

1.1.2 Soluo Proposta

Verificando o problema, observou-se a possvel utilizao de um DW na empresa. Para

diminuir estes custos, a busca da origem desses erros e suas correes seriam imprescindveis.

10

Sendo assim, a utilizao de uma topologia de DW intitulada de Data Mart (DM) seria muito

importante, tendo a preocupao com possveis integraes futuras em um DW.

Os gestores teriam capacidade de analisar atravs de relatrios, a origem e/ou a causa dos

erros, podendo indicar e tomar as decises cabveis s situaes apresentadas.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Construir um Data Mart (DM) para apoio a gesto da qualidade dos processos de emisso de

documentao para exportao da empresa Seara Alimentos, bem como fornecer informaes para

apoio a tomadas de decises nesta rea de negcio.

1.2.2 Objetivos Especficos

Estudar os conceitos de Data Warehouse, Data Mart, Sistemas de Apoio a Deciso, Online

Analytical Processing (OLAP);

Estudar a rea de Documentao de Exportao da Seara Alimentos, bem como mapear o

processo da rea de documentao da empresa;

Identificar a incidncia de erros nas geraes de documentos destinados exportao, bem

como mapear a origem dos erros;

Identificar as necessidades de informaes gerenciais;

Construir a modelagem dimensional do Data Mart no Sistema Gerenciador de Banco de

Dados (SGBD) do Oracle;

Construir o modelo fsico do DM;

Preparar a rea de transio de dados (extrao, transferncia, 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;

11

1.3 Metodologia

Foi estudado atravs 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, disponveis na biblioteca central da Univali no campus de

Itaja. Alguns artigos utilizados como pesquisa foram apresentados em congressos nacionais de

computao, como o Congresso Brasileiro de Computao, realizado na prpria Univali. Outros

artigos foram divulgados em revistas relacionadas a rea.

A seguir, foi acompanhado durante trs meses todo processo de exportao, desde a emisso

de pedidos e reserva de espao nos navios, at a documentao final para a exportao. Este

acompanhamento teve a superviso do analista de exportao da Seara Alimentos e co-orientador

deste projeto, Luiz Antnio Lobo. O mesmo forneceu dados necessrios para uma melhor anlise do

que foi realizado neste trabalho, como custo de cartas de correo e documentos que geram estes

custos.

Aps este estudo do negcio da empresa, foram realizadas pesquisas relacionadas rea de

comrcio exterior, atravs de livros e pginas 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 licena do

mesmo.

A ferramenta OLAP (processamento analtico on-line dos dados com capacidade de

visualizaes das infomaes a partir de muitas perspectivas diferentes, enquanto mantm uma

estrutura de dados adequada e eficiente. A visualizao realizada em dados agregados) que foi

utilizada para a realizao deste trabalho o Business Objects 5, que, assim como o Oracle 91, j

esto presentes devidamente licenciados dentro da empresa. E, tambm 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 captulos. O Captulo 1, Introduo, apresentou

uma viso geral do trabalho, como problematizao e objetivos estabelecidos. No Captulo 2,

Fundamentao Terica, apresentada uma reviso bibliogrfica sobre Data Warehouse, Data Mart

12

e conceitos relacionados a rea de banco de dados relacional, assim como um estudo da rea de

exportao da empresa Seara Alimentos. Neste captulo, tambm foi abordada a estrutura de tabelas

utilizadas pelo sistema de documentao de exportao. O Captulo 3 apresenta o projeto detalhado

do sistema a ser desenvolvido, incluindo sua especificao e a sua modelagem. O captulo tambm

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 Captulo 4,

apresentam-se as consideraes finais, onde so abordados os resultados preliminares, mudanas de

algumas estratgias de desenvolvimento do projeto, alteraes de cronograma, dentre outros.

13

2 FUNDAMENTAO TERICA

2.1 Estudo de Conceitos

2.1.1 Oracle

Segundo Fanderuff (2003), no ano de 1970, Ted Codd lanou seu modelo de dados

relacional para o mundo. Seus melhores prottipos foram o System R e o Ingress. O System R era

um modelo no-comercial at ento de banco de dados, desenvolvido pelo laboratrio 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, Califrnia. Atravs do System R,

foi gerado a Structured Query Language (SQL), a linguagem dos bancos de dados relacionais, que

utilizada hoje como um padro 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 lanar a sua verso comercial de um produto similar. Dois anos depois, a

empresa mudou seu nome para RSI (Relational Software Incorporated), e nessa ocasio foi gerada a

primeira verso 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 portvel do mundo,

rodando sobre as plataformas PCs e mainframes.

Desde ento o banco de dados Oracle veio evoluindo e se adaptando a evoluo tecnolgica,

como o Oracle 8i, que tem como principal caracterstica a integrao com a web, devido a

popularizao 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 verso 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 licenas de uso.

14

2.1.2 Data Warehouse

Aps o advento das transaes on-line de alta performance surgiram os programas de

extrao, que usando alguns critrios de seleo transportavam os dados para um novo arquivo ou

banco de dados. Com isto conseguia-se uma melhora na performance das anlises coletivas dos

mesmos, pois o processamento no estaria concorrendo com as transaes on-line e, alm disso, a

posse dos dados passou para as mos dos usurios.

Por esses motivos, tornou-se comum o uso dos programas de extrao e, conseqentemente,

o advento de alguns problemas como a falta de credibilidade dos dados, problemas de produtividade

e a impossibilidade de transformar os dados em informaes. Esse novo ambiente desorganizado

no atendia s necessidades do futuro e por isso se fizeram necessrias algumas mudanas de

arquitetura, surgindo o ambiente projetado de DW. No cerne de um ambiente projetado de DW est

a percepo da existncia 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. No podem ser atualizados e so histricos. Atendem as atividades gerenciais.

Como pode ser visto, existe uma grande diferena entre os dados primitivos (dados

operacionais) e os dados derivados (dados gerenciais) e, portanto, eles no devem coexistir num

mesmo banco de dados. Num ambiente projetado de uma empresa existem quatro nveis (INMON,

1997):

Operacional: contm os dados primitivos e atendem ao processamento on-line de alta

performance;

Atmico ou DW: contm dados primitivos no atualizados e dados derivados; .

Departamental:

contm informaes 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

15

Individual: geralmente dados temporrios e de pequenas propores e so utilizados para

analises heursticas.

primeira vista, pode-se concluir que existe uma grande redundncia de dados neste

ambiente, mas essa afirmao no verdadeira. No nvel operacional existem apenas registros com

valores atuais, no de DW existem dados histricos e, no Departamental, existem registros dos

departamentos especficos da empresa.

Pode-se dizer que um Data Warehouse um repositrio de dados voltado tomada de

deciso, armazenando enorme quantidade de dados para se ter uma viso mais ampla das

informaes relacionadas corporao. Existe uma grande preocupao com relao ao contexto

histrico da informao da mesma para auxiliar na determinao da conduta apropriada quando da

tomada de uma deciso.

Um DW deve ter como principal caracterstica a especializao em gerenciar grandes

conjuntos de dados, os quais so coletados de diferentes fontes, como por exemplo, arquivos, base

de dados j existentes e at mesmo outros DWs.

Uma definio terica de um DW, segundo Inmon (1997), diz que Um conjunto de

dados baseados em assuntos, integrado, no-voltil, e varivel em relao ao tempo, de apoio s

decises gerenciais.. A seguir, uma definio das caractersticas abordadas por Inmon.

Orientado por Assunto

Refere-se ao fato de que os dados esto organizados de acordo com os assuntos de interesse

da empresa, como por exemplo: produto, cliente, filial. Em contrapartida, os dados dos sistemas

operacionais esto organizados de acordo com a funcionalidade da empresa, como por exemplo, no

caso da Seara: nome do navio, porto de destino, cliente. Esses assuntos sero armazenados em um

conjunto de tabelas relacionadas.

Desta forma, passa a ser possvel realizar consultas do tipo quantos documentos do tipo A,

que foram enviados para clientes do continente Y durante o perodo X tiveram erros, e

conseqentemente, geraram cartas de correo. importante enfatizar que, no necessariamente,

todas essas tabelas devem estar com o mesmo nvel de resumo ou no mesmo dispositivo de

armazenamento (INMON, 1997).

16

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 corporao, dados do tipo data sejam armazenados de formas diferentes. Por exemplo, na

rea de produo, a informao necessria de dia, ms e ano. J na rea do comercial, a data pode

estar apenas como ms e ano. Para ser transportado para o DW, o dado tem que ser codificado de

uma nica forma, no podendo ser modificado (INMON, 1997).

Variante no Tempo

Refere-se ao fato de que as estruturas de dados no DW sempre contm um atributo de

tempo, ou seja, a cada mudana ocorrida num dado, uma nova entrada criada e no atualizada,

como acontece nos sistemas operacionais.

importante salientar a complexidade do ambiente de DW, pois pode possuir no somente

resumos anuais e mensais como tambm dirios e semanais. Sabe-se que o nmero de dias e o

incio de uma semana diferem de um ms para o outro e de um ano para o outro. Alm disso, os

metadados tambm devem acompanhar essa variao no tempo, pois um determinado dado pode ter

um significado numa poca e outro em uma poca diferente. Essa caracterstica do DW garante a

qualidade no contexto histrico dos dados (INMON, 1997).

No Voltil

Refere-se ao fato de que, em um DW, os dados no sofrem atualizaes. Eles so carregados

uma nica vez e, a partir desse momento, s podem ser consultados. Ao contrrio do que acontece

nos sistemas operacionais onde existem milhes de transaes de atualizaes ocorrendo a todo

instante. Por isso esses sistemas tm de possuir um grande nmero de controles para que no ocorra

nenhuma inconsistncia devido a uma transao 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 flexvel dos dados, de extrema

importncia que exista o particionamento dos dados. Entretanto, a grande quantidade de

17

informaes torna complicada esta ao. Sendo assim, uma soluo particionar os dados,

dividindo-os em mais de uma unidade fsica, proporcionando maior flexibilidade no seu

gerenciamento.

A granularidade se refere ao nvel de detalhamento dos dados. interessante que em um

DW a informao armazenada possua um nvel de detalhamento apropriado para a aplicao, ou

seja, quanto mais dados a respeito da informao, mais consultas podem ser realizadas. Contudo,

muitos detalhes acabam gerando um grande volume de dados, dificultando o armazenamento e o

gerenciamento dessas informaes. Desta forma, para uma melhor organizao, a estrutura do DW

pode apresentar diferentes nveis de detalhe. Por exemplo, um nvel no qual os dados esto bem

detalhados (nvel de detalhe), um segundo nvel no qual os dados so manipulados e agregados

(nvel de detalhe resumido). Fazendo uma analogia Seara Alimentos, o nvel de detalhe poderia

ser de 90 dias de histrico detalhado de vendas de cada cliente e o nvel resumido poderia ser 3 anos

de histrico de vendas. A Figura 1 mostra os nveis de detalhamento numa granularidade.

Figura 1. Nveis de detalhamento Fonte: Adaptado de Inmon (1997).

Analisando estas caractersticas, nota-se que o DW uma tecnologia que surgiu para

melhorar a qualidade e o acesso das informaes utilizadas pelos sistemas de suporte tomada de

deciso, visto que os bancos de dados operacionais no estavam adequados para este tipo de

aplicao. Para um melhor proveito das melhorias ao acesso dessas informaes, tornou-se

necessrio a utilizao de mtodos e tecnologias, como por exemplo o OLAP.

18

2.1.3 OLAP

A base da anlise Multidimensional para OLAP no nova. De fato, ela remonta a 1962,

com a publicao do livro A Programming Language, de Ken Iverson. A IBM desenvolveu e

implementou a primeira linguagem com anlise multidimensional, no fim da dcada de 60,

chamada de APL(A Programming Language). Definida matematicamente, baseada em smbolos

gregos, utilizadas por usurios finais e grande consumidora de recursos, foi amplamente utilizada

nas dcadas de 80 e 90 em aplicaes de negcio. Acompanhando a evoluo dos sistemas, na

dcada 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,

porm, com maior integrao na utilizao 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 aplicaes deveriam atender. A viso conceitual multidimensional dos negcios de uma

empresa foi umas das regras citadas, a qual se tornou a caracterstica fundamental no

desenvolvimento destas aplicaes. A viso multidimensional consiste de consultas que fornecem

dados a respeito de medidas de desempenho, decompostas por uma ou mais dimenses dessas

medidas. Podendo tambm ser filtradas pela dimenso e/ou pelo valor da medida. As vises

multidimensionais fornecem as tcnicas bsicas para clculo e anlise requeridos pelas aplicaes

de BI. Para se obter a viso multidimensional necessrio compreender outras caractersticas:

Cubo

uma estrutura que armazena os dados de negcio em formato multidimensional,

tornando-os mais fcil de analisar;

Dimenso

uma unidade de anlise que agrupa dados de negcio relacionados. As

dimenses se tornam cabealho de colunas e linhas, como exemplo linhas de produto,

regies de venda ou perodos de tempo;

Hierarquia

composta por todos os nveis de uma dimenso, podendo ser balanceada ou

no. Na hierarquia balanceada os nveis mais baixo so equivalentes, porm, isto no

19

ocorre nas hierarquias no balanceadas onde a equivalncia hierrquica no existe. Por

exemplo, em uma dimenso geogrfica o nvel pas no possui o subnvel Estado para

um determinado membro e possui para outro. No caso especfico pode-se citar o pas

Liechtenstein que no possui Estado e o Brasil, que possui uma srie de Estados;

Membro

um subconjunto de uma dimenso. Cada nvel hierrquico tem membros

apropriados aquele nvel. Por exemplo, em uma dimenso geogrfica existe o nvel e

seus membros, como Regio (sia, Amrica do Sul, Amrica do Norte), Pases (China,

Brasil, EUA), Estados (Yunna, Piau, Califrnia); e

Medida

uma dimenso especial utilizada para realizar comparaes. Ela inclue

membros tais como: custos, lucros ou taxas.

Definio de OLAP

A aplicao OLAP soluciona o problema de sntese, anlise e consolidao de dados, pois

o processamento analtico online dos dados. Tem capacidade de visualizaes das infomaes a

partir de muitas perspectivas diferentes, enquanto mantm uma estrutura de dados adequada e

eficiente. A visualizao realizada em dados agregados, e no em dados operacionais porque a

aplicao OLAP tem por finalidade apoiar os usurios finais a tomar decises estratgicas. Os

dados so apresentados em termos de medidas e dimenso, a maior parte das dimenses

hierrquica.

Considerando as aplicaes bancrias utilizadas diariamente no controle de contas correntes,

na qual so efetuados saques ou depsitos pelos correntistas, se tem o exemplo tpico de sistema de

OLTP(On-line Transaction Processing). O interesse destes usurios criar, atualizar e recuperar

informaes sobre registros individuais.

J para o Gerente de Contas Corrente, os requisitos de uso de informaes dos dados das

contas tm por finalidade a anlise global de contas correntes com diversas vises. Por exemplo, o

Gerente de Contas pode requer uma anlise sobre o desempenho de contas correntes que tenham

cheque especial e tenham utilizado o valor mximo dos mesmos em um determinado perodo de

tempo em algumas regies.

Obter a resposta a esta consulta mais complexa fazendo uso de ferramentas relacionais

padro, no fornece soluo requerida. Analisando as limitaes do uso e ferramentas relacionais

20

padro, Codd (1970) disse: "Ter um RDBMs(Relational Data Base Management System) no

significa ter a nirvana instantnea de suporte a deciso. Mesmo com tantas possibilidades que os

RDBMs tm oferecido aos usurios, eles nunca pretenderam fornecer poderosas funes de sntese,

anlise e consolidao de dados."

Ligao do DW e OLAP

O DW utilizado para armazenar informaes e o OLAP para recuper-las, ambos so

especializados para exercer suas funes de forma eficiente. As duas tecnologias so

complementares de modo que um bom DW planejado com produo de relatrios em mente.

Desta forma, para explorar o DW completamente necessrio o OLAP que ir extrair e

alavancar totalmente as informaes nele contidas (INMON; HACKATHORN, 1997).

Ligao do Data Mining e OLAP

O OLAP e Data Mining so partes integrantes de todo e qualquer processo de suporte

deciso. 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 anlise de influncia

para os dados de uma nica dimenso.

As grandes empresas como a IBM, Oracle esto liberando verses de seus RDBMS que

possuem ferramentas de OLAP e DM. Quando os usurios possuem ferramentas de OLAP e no de

minerao de dados, eles gastam boa parte de seu tempo fazendo as tarefas pertinentes a um DM,

como classificaes e predies das informaes recebidas (INMON; HACKATHORN, 1997).

Ferramentas OLAP

Atualmente, existem muitas ferramentas de OLAP no mercado e mudanas tm ocorrido em

um ritmo acelerado. Na maioria das ferramentas observa-se a existncia de dois componentes: a

ferramenta do administrador e a ferramenta do usurio final. O componente do administrador

usado para administrar e gerar os cubos de dados a serem acessados., enquanto o componente do

usurio final, tem acesso aos dados para extra-los de suas bases de dados, com os quais geram

relatrios capazes de responder as suas questes gerenciais.

21

As ferramentas surgiram juntamente com os sistemas de apoio a deciso para fazerem a

extrao e anlise dos dados contidos nos DW e DMs. Algumas das caractersticas destas

ferramentas (INMON; HACKATHORN, 1997).

Consultas ad-hoc:

geradas pelos usurios finais de acordo com os suas necessidades de

cruzar informaes de uma forma no vista e que o levem a descoberta do que procuram.

Segundo Inmom e Hackathorn (1997) "so consultas com acesso casual nico e

tratamento de dados segundo parmetros nunca antes utilizado de forma iterativa e

heurstica";

Slice and Dice: possibilita a alterao da perspectiva de viso. Serve para modificar a

posio de uma informao, trocar linhas por colunas de maneira facilitar a compreenso

dos usurios e girar o cubo sempre que houver necessidade; e

Drill down/up: consiste em realizar explorao em diferentes nveis de detalhes da

informao. Com drill down divide-se um item de resumo em seus componentes

detalhados, como, por exemplo, ano, semestre, trimestre, mensal e dirio. Alm das

principais caractersticas apresentadas, necessrio que estas aplicaaes forneam

vrios modelo de visualizao em uma variedade de formatos, e no apenas em simples

tabelas, sendo muitas vezes apresentados atravs de grficos.

2.1.4 OLTP X OLAP

Existem grandes diferenas entre os dois ambientes que, a seguir, sero definidas, mostrando

o benefcio que a implantao do DW pode trazer para o ambiente operacional.

Sistemas operacionais

(On-line Transaction Processing - OLTP): sistemas que do

suporte ao dia a dia do negcio da empresa, que mantm a empresa em funcionamento e

so chamados de sistemas de produo; e

Sistemas informacionais

(On-line Analitycal Processing - OLAP): sistemas que do

suporte aos processos decisrios da empresa, que iro dar subsdios para as decises

estratgias da empresa e compreendem os SADs e os SIGs. Segundo Inmon, Welch e

22

Glassey (1999), OLAP o mtodo de anlise sofisticado que visa orientar profissionais

que precisam tomar decises num determinado negcio.

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 vrios sistemas OLTP e as estruturas bsicas de dados de um DW

so diferentes do sistema OLTP (KIMBALL, 1998).

A grande vantagem de separar esses dados que, como eles satisfazem a objetivos

diferentes, eles podero se concentrar no que fazem, oferecendo melhor desempenho e

funcionalidade (KIMBALL, 1998).

Integrao dos dados

Os dados no ambiente operacional no esto integrados, cada sistema possui uma definio

prpria. Para migr-los para o DW deve existir uma integrao prvia, porque se os dados chegarem

em um estado no integrado, no podero ser utilizados para obter uma viso corporativa. Com isso

consolidam-se dados inconsistentes dos sistemas mais antigos em conjuntos coerentes (KIMBALL,

1998).

Atualizao dos dados

No h sobreposio entre os registros existentes no ambiente operacional e no de DW.

Caso ocorra uma mudana, um novo registro inserido no DW, associando ao mesmo um elemento

de tempo. Com isso os dados histricos no precisam mais ser guardado no ambiente operacional.

A remoo de grandes volumes de dados traz algumas facilidades para o ambiente de produo

como: correo, reestruturao, monitorao e indexao, deixando o ambiente mais malevel

(KIMBALL, 1998).

Ciclo de vida do desenvolvimento

O ciclo de vida do DW comea pelos dados. Caso esses dados estejam sob controle, eles so

integrados e testados para verificar distores. Ento, feita a codificao do programa. Os

resultados dos programas so analisados e, finalmente, os requisitos do sistema so compreendidos

(KIMBALL, 1998).

23

Organizao dos dados (modelo de dados)

Enquanto no ambiente operacional, os dados so modelados segundo a tcnica denominada

Modelagem entidade/relacionamento, que busca remover qualquer redundncia dos dados para

obter um melhor desempenho da transao, no ambiente de DW os dados so modelados segundo a

tcnica da Modelagem Multidimensional, que busca obter um maior desempenho nas consultas e

atender s necessidades de simplicidade do usurio (KIMBALL, 1998).

Tempo de resposta

A noo de tempo de resposta nos dois ambientes bem diferente. Enquanto no OLTP, o

tempo de resposta um fator crtico, ou seja, est diretamente ligado aos negcios, no ambiente de

DW mais atenuado, podendo ser medido em minutos, horas ou dias. No entanto isso no quer

dizer que ele no seja importante, o tempo de resposta est diretamente ligado produtividade,

ento quanto menor mais resultados sero alcanados (KIMBALL, 1998).

Uma mquina ou duas

Como o DW exige uma quantidade significativa e variada de recursos, geralmente

implementado em uma mquina separada do sistema OLTP. A palavra recurso, de um modo geral,

um motivo suficiente para requerer uma segunda mquina, mas existem outros dois motivos

importantes.

Primeiro, o DW um recurso centralizado que integra dados de vrios sistemas OLTP.

Neste caso, por definio, a mquina do DW separada. Segundo, as estruturas bsicas de dados do

DW so completamente diferentes daquelas do sistema OLTP. Como os dados devem ser copiados

e reestruturados para o DW, praticamente no h razo para mant-los na mquina do original

OLTP (KIMBALL, 1998).

Metadados

Segundo Kimball (1998), so normalmente definidos como "dados sobre dados". Talvez

uma definio mais exata seja a de que metadado uma abstrao dos dados, ou ainda, dados de

alto nvel que descrevem dados de um nvel inferior. Sem metadados, os dados no tm significado.

So exemplos de metadados as descries de registros em um programa de aplicao ou o esquema

de um banco de dados descrito em seu catlogo ou ainda as informaes contidas em um dicionrio

24

de dados. Em um ambiente operacional, os metadados so especialmente valiosos para os

desenvolvedores de aplicao e os administradores de banco de dados.

Os bancos de dados operacionais so usualmente utilizados via aplicao, que j contm as

definies de dados embutidas. Seus usurios simplesmente interagem com as telas do sistema, sem

precisar conhecer como os dados so mantidos pelo banco de dados. O ambiente de suporte a

deciso, por sua vez, bastante distinto. Nele, analistas de dados e executivos procuram por fatos

no usuais e correlaes que sero conhecidas quando encontradas.

Aplicaes rotineiras e predefinidas no fazem sentido neste ambiente. Os usurios de um

DW precisam examinar seus dados e para tal, conhecer sua estrutura e significado. De um modo

geral existem trs camadas de metadados em um DW:

Operacionais (do nvel das aplicaes): definem a estrutura dos dados mantidos pelos

bancos operacionais, usados pelas aplicaes de produo da empresa;

Centrais do DW: mantidos no catlogo do DW. Distingue-se por serem orientados por

assunto, definindo como os dados transformados devem ser interpretados. Incluem definies de

agregados e campos calculados, assim como as vises sobre cruzamentos de assuntos; e

Nvel do usurio:

mapeiam os metadados do DW para conceitos que sejam familiares e

adequados aos usurios finais.

Um DW pode ser visto e implementado de diferentes formas. Para isso, foi estudado as

topologias existentes em relao aos DWs.

2.1.5 Topologias de um Data Warehouse

A implementao de um DW pode utilizar-se de diferentes tipos de topologia como

Centralizada, Data Marts e Data Warehouse Distribudo.

Data Warehouse Centralizado

Numa topologia Centralizada, um nico DW concentra as informaes disponveis da

corporao, isto , os dados histricos e operacionais so extrados e integrados em um grande

repositrio. A topologia Centralizada projetada tendo como principal objetivo, organizar todos os

25

dados de uma corporao, 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 Distribudo

A topologia Data Warehouse Distribudo consiste de vrios DWs conectados por uma rede

de comunicao com suporte a processamento distribudo. O sistema visto logicamente como um

DW nico, ou seja, os usurios no conseguem visualizar a existncia de vrios DWs separados

fisicamente. O desempenho dessa topologia influenciado diretamente pela tecnologia de

comunicao de dados empregada (INMON, 1997). Na figura 3, pode-se ter um viso da topologia

de DW Distribudo.

26

Figura 3. Data Warehouse Distribudo 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 segurana, a

implementao desta abordagem no uma tarefa fcil. Requer uma metodologia rigorosa e uma

completa compreenso dos negcios da empresa.

Esta abordagem pode ser longa e dispendiosa e por isto sua implementao exige um

planejamento bem detalhado. Com o aparecimento de Data Mart ou Warehouse departamental, a

abordagem descentralizada passou a ser uma das opes 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 segmentao, ou

seja, divide o DW em reas menores gerando assim pequenos bancos orientados por

assuntos "departamentalizados"; e

Botton-up: quando a situao inversa. A empresa por desconhecer a tecnologia,

prefere primeiro criar um banco de dados para somente uma rea. Com isso os custos

so bem inferiores de um projeto de DW completo. A partir da visualizao dos

27

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

corporao, sendo que cada rea possui seu prprio repositrio de dados, como pode-se ver na

Figura 4. As diferenas existentes entre um Data Warehouse e um Data Mart so apenas

relacionadas ao tamanho e ao escopo do problema a ser resolvido. Portanto, as definies dos

problemas e os requisitos de dados so essencialmente os mesmos para ambos.

Grosseiramente falando, enquanto um Data Mart trata de problema departamental ou local,

um Data Warehouse envolve o esforo de toda a companhia para que o suporte a decises atue em

todos os nveis da organizao. Sabendo-se as diferenas 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).

28

Os DMs podem ser independentes de um DW (Figura 6), possuindo informaes de

determinado setor da corporao, ou dependentes (Figura 5), onde vrios DMs so criados a partir

de um Data Warehouse. Data Marts procuram otimizar as anlises para obter resultados com mais

qualidade e preciso nas tomadas de deciso.

Figura 5. Data Marts Dependentes Fonte: Adaptado de Inmon (1997).

Figura 6. Data Marts Independentes Fonte: Adaptado de Inmon (1997).

29

2.1.6 Sistemas de Apoio a Deciso

O SAD consiste na escolha da melhor opo entre diversas alternativas, auxiliada por

recursos computacionais com a possibilidade da obteno de dados com melhor qualidade e maior

velocidade. Assim, resultando na resoluo 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 Deciso, conforme Rezende (1999), auxiliam o executivo em todas

as fases de tomada de deciso, principalmente, nas etapas de desenvolvimento, comparao e

classificao de riscos, alm de fornecer subsdios para a escolha de uma boa alternativa. Para que

um SAD tenha sucesso preciso utilizar a tecnologia adequada aplicao. Neste caso, na Seara

Alimentos, a tecnologia que mais se encaixa ao problema o OLAP, abordado anteriormente neste

mesmo trabalho.

2.2 rea de Exportao 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 sunos, 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 frigorficas, o primeiro e

nico no pas, a Seara conta ainda com nove unidades industriais (abatedouros e frigorficos) e mais

de 15.000 colaboradores. Opera de forma verticalizada e totalmente integrada, com matrizes, ovos,

incubatrios, engorda e terminao de aves e sunos, produzindo integralmente as raes

empregadas na alimentao de seu plantel.

Possuindo trs escritrios no exterior (Holanda, Argentina e Cingapura), a Seara

considerada uma das maiores empresas de carnes frigorificadas e industrializadas de alta qualidade

da Amrica do Sul, atendendo mercados como frica, Amrica do Sul, Amrica Central, sia,

Caribe, Europa, Oriente Mdio, Hong Kong, Japo, entre outros.

Cerca de 75% de seu faturamento anual provido de negociaes com clientes do mercado

exterior. Com esse volume de exportaes, a empresa necessita de um sistema robusto, que possa

suprir esta demanda e suportar a grande quantidade de informaes inseridas todos os dias.

30

Dentro da rea de TI (Tecnologia da Informao), cerca de 30 colaboradores so responsveis

pelo desenvolvimento interno das aplicaes baseadas no banco de dados Oracle 9i. A rea de

exportao possui um sistema gerencial denominado Sistema Comercial Mercado Externo

(CMEK), constitudo por 302 programas (telas), 313 relatrios (incluindo os documentos destinados

exportao) e 211 rotinas responsveis pela manuteno dos dados dentro do sistema. Alm disso,

o sistema dispe de 502 tabelas de registros.

2.2.1 Processo de Exportao

O processo de exportao iniciado com a rea de comercial mercado externo, onde um

trader efetua a venda de produtos da empresa para clientes internacionais. Aps o contato com o

cliente, e acertado preo e demais condies, gerado via sistema, um contrato de venda enviado

diretamente ao cliente. O cliente retorna um e-mail, confirmando que a transao comercial ser

concretizada.

A partir deste momento, o trader passa aos seus auxiliares todos os dados necessrios

referentes a aquela transao. O auxiliar de trader faz o cadastro de pedidos no sistema e aciona a

rea de logstica. Automaticamente o sistema j gera as ordens de produo, e as envia para o

sistema de produo. Uma vez confirmado pela produo, o pedido ovado em um ou mais

containers, ficando disponvel para a insero em uma lista de carga.

A logstica tem como funo, reservar espao de container no navio e criar um planejamento

de carga, onde ficam as informaes de nome de navio, data de atracao, data de sada do porto de

origem, data de chegada no proto de destino, nome do armador (empresa responsvel pelo

transporte e aluguel dos containers), valores de frete, porto de origem, porto de destino , entre

outras.

Aps cadastradas essas informaes, o pedido inserido em uma lista de carga, que possui

informaes de cliente, filial produtora (informao vinda do pedido), filial de ovao de container,

quantidade no container, filial exportadora (filial responsvel pelo faturamento), etc., e pode receber

mais de um pedido.

A lista de carga faturada contra o cliente, e fica a disposio para o carregamento no

container. Aps faturada, os documentos necessrios a exportao comeam a ser gerados. Esta

uma funo do setor de documentao de exportao, e foi o enfoque principal para a concretizao

31

deste trabalho. Dentre os documentos gerados, alguns necessitam de cartas de correo quando

possuem erros de dados em sua gerao. So eles:

Registro de Exportao;

Bill of Lading (Conhecimento de Embarque);

Invoice (Fatura Comercial);

Certificado de Origem;

Certificado Form-A;

Border de Cobrana; e

Certificado Sanitrio Internacional (CSI);

Registro de Exportao

O registro de Exportao (R.E.) o primeiro documento a ser gerado. Ele enviado ao

sistema da receita federal atravs do SISCOMEX, do prprio governo. gerado pelo usurio assim

que a lista de carga confirmada pelo comercial.

Este documento gerado a partir de informaes de tabelas do comercial, financeiro,

produo e logstica. Para a gerao deste documento, o usurio entra com os parmetros de

planejamento e lista, e a rotina CMEK4224.pck, buscando de tabelas de outros sistemas, cria

registros nas tabelas de registro de exportao com estrutura conforme Figura 7.

32

Figura 7. Estrutura de tabelas de registro de exportao

Bill of Lading (BL)

O conhecimento de embarque martimo ou Bill of Lading (BL) um documento emitido pelo

armador ou seu agente, representando o contrato de transporte. considerado tambm, como

comprovante de que a mercadoria foi entregue ao importador. O conhecimento de embarque

confere ao importador o direito posse da mercadoria aps o transporte, sendo sempre emitido em

ingls, em 3 vias originais utilizadas para negociao e as demais cpias no negociveis.

Algumas informaes indispensveis devem ser mencionadas no BL, tais como:

nome do exportador;

nome do consignatrio;

notificado;

porto de embarque e desembarque;

destino final;

descrio do produto;

quantidade de volume;

33

tipo de embalagem;

tipo de continer;

nmero do continer;

nome do navio;

dimenses dos volumes;

peso lquido e peso bruto;

nmero do lacre do armador;

descrio da mercadoria; e

data de embarque.

Algumas informaes adicionais devem ser mencionadas no BL, tais como: tipo de frete,

dados referentes ao embarque, se a mercadoria foi colocada a bordo e sem restries e se est em

boas condies.

O conhecimento de embarque martimo deve estar devidamente assinado pelo agente ou pelo

armador. Quando ele for emitido a algum, ele intransfervel por endosso. J quando ele for

emitido ordem de algum, endossvel e transfervel. A Figura 8 mostra a estrutura de tabelas do

BL.

34

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

operao comercial e serve para formalizar a transferncia de propriedade da mercadoria para o

importador. emitida em formulrio prprio (no obedece a um modelo oficial), sem erros,

emendas ou rasuras, preferencialmente com o texto em ingls ou no idioma do pas importador,

devendo ser preenchida de acordo com a regulamentao deste. A Figura 9 mostra a estrutura de

tabelas da Invoice.

Deve conter no mnimo os seguintes dados:

Nome do exportador e importador;

Tipo de transporte;

35

Locais de embarque e desembarque;

Descrio completa da mercadoria;

Quantidade, peso bruto e peso lquido;

Moeda, preo unitrio, valor total;

Incoterms (tipo de frete);

Assinatura do exportador;

Modalidade de pagamento;

Tipo de embalagem e nmero e marca de volumes;

Data de emisso;

Nome do navio; e

Nmero do continer.

Segundo Vzquez (1999), um documento usado internacionalmente para comprovar a

venda mercantil. Nela devem aparecer todos os detalhes possveis da operao: nome do vendedor,

endereo, nome do comprado e endereo, nome do consignatrio (que pode ser o comprador), nome

do representante e, de maneira sumria, as condies em que foi efetuada a venda, tais como: prazo,

modalidade de pagamento (nesse caso cobrana bancria) etc..

A fatura comercial deve ser emitida em quantas vias solicitadas pelo importador visando

atender s exigncias no desembarao aduaneiro e liberao da carga no pas de destino.

36

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 originrio do pas exportador, assim como o Form-A, que destinado ao mercado

russo. So emitidos por exigncia do importador para poder auferir benefcios no ato da liberao

das mercadorias na alfndega de seu pas, quando as mesmas gozam de reduo ou iseno tarifria

em seus paises de origem.

Os certificados de origem e Form-A so fornecidos por entidades credenciadas atravs de

um formulrio timbrado. Atravs do programa CMEK5610, so 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).

37

Figura 10. Estrutura de tabelas de certificado de origem.

Border de Cobrana

a nota discriminativa das mercadorias e de seus respectivos valores, enviado ao banco

responsvel pela cobrana desta venda. O border gerado pelo programa CMEK5626 e utiliza

apenas uma tabela para manter seus dados, conforme Figura 11.

38

Figura 11. Estrutura de tabelas de border de cobrana.

Certificado Sanitrio Internacional (CSI)

A confeco do CSI tem incio aps a unitizao do continer na unidade produtora ou em

algum entreposto frigorfico. Assim que todas as informaes estiverem inseridas no sistema, o

inspetor veterinrio oficial responsvel d o parecer no prprio sistema atestando a boa

procedncia da mercadoria imprime, carimba e assina-o para que este acompanhe o continer at

o porto de embarque, onde as autoridades sanitrias do porto faro a verificao e autorizao para

embarque.

39

Aps o embarque da mercadoria, o CSI que est no porto coletado e trazido at o escritrio

para que seja enviado para o agente no destino, juntamente com os demais documentos da

exportao, para que a mercadoria seja liberada e entregue para o cliente. Os dados que so

obrigatrios para este documento so:

Cdigo do CSI;

nome do exportador;

nome do consignatrio/importador;

nome, endereo e nmero do SIF da unidade produtora;

nome, endereo e nmero do SIF do entreposto frigorfico;

local de carregamento;

meio de transporte;

nmero do lacre sanitrio;

tipo de embalagem;

identificao da remessa (nmero do continer);

estado-membro de destino;

destino final;

espcie de ave;

tipo de peas;

nmero de embalagens;

peso lquido;

data de produo; e

carimbo e assinatura do inspetor veterinrio oficial.

No sistema da Seara, a rotina CMEK5321 a responsvel pela gerao do certificado

sanitrio. Cada pas de destino possui seu prprio modelo de certificado, mantido tambm no

sistema CMEK. A Figura 12 ilustra a estrutura de tabelas de certificado sanitrio internacional

dentro do sistema.

40

Figura 12. Estrutura de tabelas de certificado sanitrio internacional.

41

Na Seara, todos os documentos so gerados automaticamente pelo sistema. O usurio entra

nas telas de impresso, solicita o documento atravs do planejamento de carga e da lista de carga.

Na Figura 13, pode-se visualizar a tela de impresso do Certificado Sanitrio Internacional (CSI):

Figura 13. Tela de gerao de CSI.

Seguindo o exemplo dos CSIs, o programa que gera uma Procedure Stored, e busca

informaes do sistema de produo (cdigo do produto, data de fabricao, data de validade,

nmero do pedido), do cadastro de itens (descrio do item, tipo de embalagem do item, unidade de

medida), do sistema comercial mercado externo (nmero da ordem de compra), do sitema de

logstica (nmero do container, nmero do lacre do container, peso bruto, peso lquido, quantidade

de volumes, porto de origem, porto de destino, entre outras), alm de informaes como nome do

cliente, nome da empresa, nome da filial, vindas dos cadastros gerais da empresa.

Sendo assim, qualquer tipo de informao cadastrada erroneamente pelos sistemas envolvidos,

ou qualquer informao que o sistema busca que no faz parte a regra daquele cliente, geram

documentos com erro, e, conseqentemente, passam a exigir uma carta de correo.

42

3 DESENVOLVIMENTO

Este trabalho tem como objetivo a implementao de um Data Mart no sistema de

documentao da Seara Alimentos, para que se busque uma deciso gerencial em relao aos erros

ocorridos nas geraes de documentos destinados a exportao de carnes de aves, sunos e seus

derivados.

Uma vez implementado, o Data Mart permitir que a gerncia tome decises baseados em

relatrios construdos via Business Objects, sobre os custos gerados por cartas de correo dos

documentos, alm de buscar a origem dos erros e, conseqentemente, buscar a soluo para que se

diminua a demanda de erros.

Segundo Inmon (1997), a topologia de Data Mart possui a caracterstica de organizar cada

setor de uma corporao, para que se tenha um repositrio para cada rea. Na Seara Alimentos, o

sistema integrado da documentao 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 devero ser

organizados os dados em apenas um repositrio.

O mdulo CMEK Documentao funciona da seguinte forma: o usurio digita o nmero do

planejamento e da lista de carga e atravs de stored procedures (rotinas de execuo de instrues

para realizaes de tratamentos e transaes 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

atravs 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 emisso de documentao a seguinte:

1. Registro de Exportao;

2. Bill of Lading (Conhecimento de Embarque);

3. Invoice (Fatura Comercial);

4. Certificado de Origem;

43

5. Certificado Form-A;

6. Border de Cobrana; e

7. Certificado Sanitrio Internacional (CSI);

A Figura 14 mostra o modelo relacional das tabelas de documentao de exportao 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 so utilizadas para o armazenamento de informaes

referentes aos Certificados Sanitrios Internacionais. Existe uma stored procedure(CMEK5321.pck)

que busca as informaes necessrias. Estas informaes vm de sistemas distintos, como do

Sistema de Produo (data de produo, filial de produo, etc.), Sistema de cadastro de itens (data

44

de validade, descrio do produto, etc.), Sistema de cadastro de clientes (nome e endereo do

cliente), entre outros. Um certificado sanitrio identificado pelo Cdigo do Certificado

(CD_CTF_SAN_EXP_CNE_NAC).

O usurio digita o cdigo de planejamento e lista de carga, e, a partir destes parmetros, gera

um certificado. Para cada pas de destino do CSI, atribudo um modelo, j que cada pas

importador e/ou espcie do produto, existe um modelo fsico especfico.

A tabela que possui o cadastro dos modelos de CSI a MODELO_CTF_SANITARIO_INN.

Nela, so cadastrados informaes do tipo Cdigo do Modelo, Pas de Destino, Espcie do produto

enviado e o caminho do programa que imprimir este CSI, j que, para cada CSI, utilizado um

relatrio confeccionado pela TI e desenvolvido no Oracle Reports.

Para a gerao de fatura comercial (invoice) so utilizadas as tabelas

FATURA_COMERCIAL_MRM_INN e ITEM_FATURA_CML_MRM_INN, ligadas pelo cdigo

da fatura. Assim como no CSI, utilizado uma stored procedure chamada de CMEK5401.pck

Tambm so buscadas informaes de outros sistemas (Sistema de Produo, 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 so

CTL_CTF_ORIGEM_EXP_CNE e CTL_ITEM_CTF_ORIGEM_EXP_CNE, ligadas pelo cdigo

de origem, e carregadas atravs da stored procedure CMEK5611.pck.

No caso dos registros de exportao(RE), utilizada a seguinte estrutura: a tabela

REGISTRO_EXPORTACAO_SMX_CNE, faz o papel do cabealho do RE e possui informaes

de importador, exportador, entre outras. Abaixo dela, ligado pelo cdigo de registro, existe a tabela

ANEXO_REGISTRO_EXP_SMX_CNE, onde esto contidas as informaes de item, quantidades,

valores, etc.

Em seguida, ligada pelo cdigo de registro e pelo cdigo do anexo, existe a tabela

FABRICANTE_PRO_REG_EXP_CNE, onde encontra-se as informaes de produo dos itens a

serem exportados, como filial de produo, data de produo entre outras. Para que essas

informaes sejam carregadas, utilizam-se as stored procedures CMEK4220.pck, CMEK4221.pck,

CMEK4222.pck e CMEK4223.pck.

45

Para a gerao de BLs (conhecimento de embarque), utilizada a stored procedure

CMEK5341.pck, alm das tabelas CNH_EMB_MRM_EXP_CNE e

ITEM_CNH_EMB_MRM_EXP_CNE, ligadas pelo cdigo do conhecimento e contendo

informaes de produto, cliente, exportador entre outras.

A tabela BORDERO_COBRANCA_INN utilizada para o armazenamento de informaes

referentes ao Border de Cobrana, e carregada por uma tela no prprio sistema corporativo,

denominada CMEK5626.fmb (Programa este desenvolvido na ferramenta Oracle Forms).

Todas estas tabelas possuem as informaes de cdigo de planejamento e lista de carga, e

esto 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 cdigo do documento, a ordem em que foi inserido, a data e a hora e a matrcula do

usurio que gerou.

Atualmente, esta tabela utilizada na empresa para conferncias e auditorias. Como a

estrutura era vivel para a implementao 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

gerao como erro. Sempre que houver mais de uma gerao do mesmo tipo de documento, a stored

procedure de carga ao DM leva em considerao que ocorreu um erro na gerao deste documento,

de acordo com as informaes obtidas em entrevista com os gestores).

Entretanto, os documentos envolvidos na exportao s sero carregados nas tabelas de

transio, quando um evento chamado Confirmao de Embarque for inserido na tabela de

rastreamento, evitando assim, que, se porventura um usurio gerar alguns documentos e a transao

comercial no se concretizar por quaisquer motivos, no gerando assim possveis custos de re-

gerao de documentos, no influencie nos resultados obtidos nas consultas do Data Mart pelos

gestores. Sendo assim, s estaro no modelo do DM as informaes 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.

46

A modelagem dimensional exige o mapeamento das tabelas de dimenso, bem como a criao

das tabelas fato e da granularidade do DM, visando atender as necessidades de informaes

gerenciais solicitadas pelo gestor da rea, como qual o mercado que mais possui erros por ms,

qual o cliente que mais teve erros na gerao 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 existncia de cinco tabelas de dimenso, e uma tabela fato

ligado pelas respectivas chaves.

Na tabela de dimenso de tempo inicia-se a partir da dimenso de ms. A partir dela, segue a

granularidade por ano, bimestre, trimestre, semestre e ano fiscal, que contempla o perodo de junho

de um ano maio do ano seguinte. Esta dimenso foi solicitada pela gerncia, uma vez que a Seara

baseia-se neste perodo para balanos.

As tabelas de dimenso de Cliente e Mercado so responsveis pela descrio dos cdigos

que aparecero nas consultas por estes motivos.

47

J as tabelas de dimenso Dim_tipo_campo e Dim_tipo_documento, mostraro aos gestores

quais os documentos que possuem erros e qual ou quais os campos que causaram o erro, bem como

os responsveis e o sistema de origem.

Tendo esta informao, o gestor poder tomar a deciso correta para a distribuio dos

custos causados para o verdadeiro responsvel pelo erro. Isto foi possvel pois todas as tabelas do

sistema da empresa possuem os campo de usurio e data da atualizao do registro, tornando

possvel a carga destas tabelas de dimenso com estas informaes de responsabilidade.

3.2 Anlise de informaes gerenciais

Aps anlise junto ao gestor da rea, foram identificados, atravs de entrevistas informais,

os seguintes pontos em relao s necessidades gerenciais de informao (os relatrios referentes a

cada necessidade gerencial encontram-se no apndice A.8, Relatrios):

Quantidade de documentos emitidos por ms;

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 atravs de cartas de correo por documento;

Custo gerado atravs de cartas de correo total; e

Responsveis pelos erros, bem como identificao de reincidncia, entre outros.

Alm destas informaes, foi conversado com os gestores, sobre a possvel disponibilidade

da informao referente s cotaes da moeda, uma vez que as cartas de correo so todas

cobradas em dlar americano (US$), nas datas em que os documentos foram gerados.

48

Desta forma, chegou-se a concluso de que um novo modelo lgico deveria ser

implementado. Um modelo que pudesse contemplar todas as necessidades de informao 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 cotao de moeda nas datas da gerao dos

documentos. O valor da cotao carregado em uma tabela do sistema relacional da empresa

diariamente, e sendo carregada na tabela de transio TRANSICAO_MOEDA_EXP_CNE.

Sempre no ltimo dia do ms, atravs de um Job de Execuo (rotina programada para ser

rodada de tempos em tempos conforme necessidades), busca-se as informaes do ms que passou

em uma tabela de transio, a mdia de valores deste ms. A stored procedure utilizada a

CMEK9003.pck, e possui seu cdigo fonte apresentado no apndice A.6, CMEK9003.pck. Desta

49

forma, os gestores podem ter noes de custos mais aproximadas possveis em relao aos

documentos, pois o dlar americano uma moeda que pode ter oscilaes em sua cotao.

A tabela fato FT_DOCUMENTACAO_EXP_CNE utilizada para que todas as perguntas

dos gestores referentes gerao de documentao de exportao possam ser respondidas. A partir

dela, tem-se ligaes com todas as tabelas de dimenso do modelo lgico, trazendo estas

informaes.

Um ponto relevante o campo VL_CARTA_CORRECAO estar dentro de uma tabela de

dimenso, e no dentro da tabela fato, como se era esperado. Esta caracterstica apresentada neste

modelo lgico se d ao fato da granularidade ser mensal, alm deste valor estar em dlar, com raras

alteraes neste valor.

3.3 Construo do Modelo Fsico

Uma vez que o modelo dimensional estava definido, era necessria a criao do modelo

fsico. Para isso, foram criadas as tabelas tanto do Data Mart (Apndice A.4, Script criao DM),

quanto da rea de transio (Apndice A.5, Scripts criao Transio).

As tabelas seguem um padro de nomenclatura da prpria empresa, com exceo dos

campos chave que fazem parte das tabelas do Data Mart. Foi definido junto ao usurio, que o

campo chave, tanto das tabelas fato como das tabelas de dimenso, seriam numricos com tamanho

definido de 7. Sendo assim, permitido inserir em cada tabela aproximadamente 10 milhes de

registros. Foi definida como chave primria das tabelas de dimenso os campos que iniciam com a

nomenclatura chave. As tabelas fato possuem chaves compostas e estrangeiras (chaves buscadas

das tabelas de dimenso).

Aps criadas as tabelas, foi necessrio o desenvolvimento do universo do DM utilizando o

Business Objects. No Apndice A.7, possvel visualizar o passo-a-passo da ferramenta a

construo do universo DM.

50

3.4 Modelagem Lgica das tabelas de Transio

As tabelas existentes na rea de transio, tem por objetivo armazenar as informaes que

sero gravadas nas tabelas do Data Mart. Isto deve ser feito para que, toda vez que ocorrer um erro

no momento da gravao nas tabelas do DM, no se perca as informaes daquele perodo. As

tabelas de transio so apagadas somente aps a confirmao da transio do banco de dados.

Com exceo da tabela fato de cotao (FT_COTACAO), as tabelas so carregadas uma vez

por semana, tambm atravs de um Job de execuo. Este Job rodado toda sexta-feira, aps as

21:30 hs, buscando as informaes das tabelas de transio, utilizando-se de uma stored procedure

(pck). Na figura 17, possvel visualizar a estrutura da tabela da rea transacional.

Figura 17. Estrutura da tabela de transio de documentao

Nesta tabela, as informaes so 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, aps carregar as tabelas do Data Mart, feita uma verificao na tabela

transacional, buscando por registros que possuam ID_STATUS_ERRO = 1 (com erro). Caso

encontre algum registro, a stored procedure tenta a insero no DM at que no existam mais

registros com este status. Caso no encontre nenhum registro, rodado um procedimento para a

limpeza desta tabela.

51

Os campos de DT_ATUALIZACAO e ID_USUARIO so utilizados para controle, uma vez

que so gravadas a data e a hora, alm da matrcula do usurio toda vez que o registro inserido ou

alterado. Estes campos devem existir nas tabelas por questes de normas de gesto de TI da

empresa, mesmo que no venham ser utilizados.

Para a tabela de transio, utilizada para a carga das tabelas FT_COTACAO e MOEDA,

tambm foi utilizada uma stored procedure chamada a partir de um job de execuo, entretanto, o

tempo de carga desta tabela diria, aps as 19:00 hs, para que tenha-se sempre uma informao de

valor mdio de cotao da moeda. Na figura 18, nota-se a estrutura da tabela de transio

TRANSICAO_MOEDA_EXP_CNE.

Figura 18. Estrutura da tabela de transio da moeda

3.5 Processo de carga na rea de transio

Toda vez que um documento gerado pela equipe de documentao para exportao,

chamada a stored procedure CMEK3600 (o cdigo fonte encontra-se no Apndice A,

CMEK3600.pck). Esta pck tem como objetivo inserir na tabela

RASTREAMENTO_EXPORTACAO informaes como o nome da pessoa que gerou o documento

e a data de gerao deste documento por planejamento e lista de carga, bem como informaes de

confirmao de lista ou de embarque, utilizadas pela rea comercial e rea de TI para consultas de

fluxo de procedimento, quando necessrio.

Foi acrescido nesta stored procedure uma chamada para a rotina CMEK9000 (cdigo fonte

apresentado no Apndice A.1, CMEK9000.pck), que tem por objetivo, inserir nas tabela de

transio TRANSICAO_DOCUMENTACAO_EXP_CNE as informaes que, posteriormente,

sero carregadas no Data Mart. Assim sendo, toda vez que um documento gerado,

automaticamente as informaes j so inseridas na rea de transio de documentao.

52

Para a atualizao da tabela de transio TRANSICAO_MOEDA_EXP_CNE, foi utilizada a

stored procedure CMEK9001.pck(cdigo fonte exposto no Apndice 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 mdia com os valores j existentes na tabela, deixando a mesma atualizada com a mdia

mensal da cotao do dlar j no final do dia.

A figura 19 ilustra o processo de carga nas tabelas de transio e carga no Data Mart.

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 Confirmao de

Embarque.

Aps identificado esse registro, inicia-se a filtragem dos dados, que consiste em no permitir

que sejam inseridos na tabela de transio registros duplicados ou com possveis erros (de restries

ou problemas nas buscas dos dados).

A stored procedure CMEK9001 tambm faz cargas na tabela de transio, entretanto,

exclusivamente para a parte de cotao de moeda. rodado todo final de dia, faz a mdia do valor

rea de TransioSistema RelacionalCMEK9000CMEK9001

Data Mart

Busca dos Dados;Filtragem dos Dados;Insero dos Dados.

Busca das chaves;Carga no DM.

CMEK9002

53

de cotao da moeda do primeiro dia do ms at o dia corrente, inserindo na tabela de transio de

cotao o valor j calculado.

Os dados ficam armazenados nas tabelas de transio at que rode o JOB do fim de ms

para a carga do DM, ou seja, todo ltimo dia do ms aps as 21:30 hs, chamado a stored

procedure CMEK9002 (Apndice D, CMEK9002.pck), onde feita a busca dos dados das tabelas

de transio, a busca das prximas chaves a serem inseridas e, por fim, a carga nas tabelas do DM.

Para evitar que dados no sejam inseridos, a tabela de transio s ser limpa quando no

existir mais nenhum registro dentro dela. Para que isto ocorra, aps cada insero no DM, o registro

recebe um indicador de que j foi carregado, e a transao no banco concretizada. Ao final de

todos os registros inseridos, feita uma varredura na tabela de transio, verificando se no h

nenhum registro com erro. Caso no exista, feita a limpeza da tabela.

Poderia ocorrer um problema mais srio durante as consultas: o gestor poderia estar rodando

os relatrios no momento em que as tabelas do DM estivessem sendo carregadas, podendo gerar

tomadas de decises equivocadas em cima de uma base de dados incompleta. Para no ocorrer este

problema foi criada uma flag, que emitir um aviso ao usurio que estiver consultando as

informaes, se os dados daquele ms esto carregados por completo. Esta flag est na tabela

FLAG_DATA_MART, e ser preenchida sempre que os dados daquele ms terminarem de carregar

o DM.

3.6 Construo de Relatrios

Para a construo dos relatrios gerenciais, foi utilizada a ferramenta Business Objects.

Como exemplo, a figura 20 ilustra um relatrio que atende a necessidade gerencial Quantidade de

documentos emitidos por ms.

54

Figura 20. Relatrio Documentos Emitidos/ms

Os usurios da empresa tm treinamento especfico para o desenvolvimento dos relatrios

utilizando a ferramenta BO. Sendo assim, possuem privilgios da ferramenta para que possam

aplicar seus conhecimentos adquiridos nos treinamentos na confeco dos relatrios.

Mesmo sendo uma ferramenta indicada para a aplicao de um DW, no utilizada

totalmente desta forma na Seara. Tanto usurios gestores como usurios finais (comuns) tm acesso

ao desenvolvimento de relatrios. Entretanto, muito poucos so usados para a tomada de deciso.

As validaes dos dados foram realizadas com a execuo dos relatrios 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 situaes,

apresentando consistncia em todos os dados, tanto agrupados como desagrupados.

55

Os dados apresentados nos relatrios so dados armazenados no ambiente de

desenvolvimento da empresa durante o perodo de janeiro de 2003 a dezembro de 2004, conforme

exposto na problematizao do projeto.

No ambiente de homologao da empresa (espelho da base de dados de produo) j se

encontra implantado o Data Mart, sendo possvel a visualizao dos relatrios com dados reais e

atualizados.

Para a validao das consultas gerenciais, foi realizada uma reunio com o desenvolvedor do

Data Mart, o Analista de Sistemas da rea de exportao e o gestor da rea de documentao de

exportao da empresa. Por meio de uma ata de reunio (Apndice A.9, Ata de reunio de

validao), garantiu-se que as consultas esto validadas de acordo com as necessidades da rea de

gesto de documentao de exportao identificadas no incio do projeto.

56

4 CONCLUSES

O correto controle das informaes de uma empresa pode significar grande reduo de

custos e aumento significativo da capacidade do sistema. Um Data Warehouse permite aos gestores

que decises de suma importncia 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 reunies junto a gerencia, para que se

chegasse