View
214
Download
0
Category
Preview:
Citation preview
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
Recommended