universidade do vale do itajaÍ centro de ciÊncias ...siaibib01.univali.br/pdf/adelir...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE INFORMAÇÃO BASEADO EM TECNOLOGIA DE DATA MART PARA ANÁLISE DE INFORMAÇÕES DE VENDAS
Área de Sistemas de Informação
por
Adelir Soares
Rogério Gonçalves Bittencourt, M. Sc. Orientador
Damaris Fanderuff, M. Sc. Co-orientadora
Itajaí (SC), dezembro de 2004
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE INFORMAÇÃO BASEADO EM TECNOLOGIA DE DATA MART PARA ANÁLISE DE INFORMAÇÕES DE VENDAS
Área de Sistemas de Informação
por
Adelir Soares
Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Rogério Gonçalves Bittencourt, M. Sc. Co-Orientadora: Damaris Fanderuff, M. Sc.
Itajaí (SC), dezembro de 2004
i
DEDICATÓRIA
Aos meus pais, Nereu e Luiza, e irmãos, Terezinha, Irma, Valmira, Olendina, Maria Elena,
Osmarina, Atair e Adenir. A minha esposa Patrícia, que me deu forças para enfrentar todas as
dificuldades encontradas. Ao meu filho Lucas, que com seu sorriso e alegria vêm me estimulando a
superar todas as etapas nesta caminhada.
ii
AGRADECIMENTO
Em primeiro lugar agradeço a Deus, por mais esta conquista e por tudo o que consegui em
toda a minha vida.
Agradeço também ao César e a Anita, por terem colaborado na conclusão de mais esta
caminhada.
Aos amigos Marlon, Junior, Tamara, principalmente ao Rogério e a Damaris por seus
esforços dedicados e a tantos outros amigos especiais pela força e energia positiva a mim
transmitidos.
iii
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................v LISTA DE FIGURAS ..............................................................................vi LISTA DE TABELAS.............................................................................vii RESUMO ................................................................................................viii ABSTRACT ..............................................................................................ix 1. INTRODUÇÃO.....................................................................................1 1.1. OBJETIVOS .......................................................................................4 1.1.1. Objetivo Geral .................................................................................4 1.1.2. Objetivos Específicos.......................................................................4 1.2. METODOLOGIA...............................................................................4 1.3. Estrutura do trabalho ........................................................................6 2. FUNDAMENTAÇÃO TEÓRICA .......................................................2 2.1. SISTEMAS DE INFORMAÇÃO......................................................2 2.1.1. Tipos de Sistemas de Informação...................................................5 2.1.2. Sistema de Apoio à Decisão ............................................................6 2.1.3. Características do SAD ...................................................................8 2.1.4. Abordagem Adaptativa do SAD...................................................10 2.2. DATA WAREHOUSE .....................................................................11 2.2.1. Data Mart.......................................................................................13 2.2.2. Metadados ......................................................................................13 2.2.3. Características de um Data Warehouse ......................................14 2.2.4. Componentes de um Data Warehouse.........................................15 2.2.5. Processos do Data Warehouse ......................................................16 2.2.6. Granularidade ...............................................................................17 2.2.7. Modelo Dimensional......................................................................17 2.2.8. Processamento Analítico Online (OLAP)....................................18 2.2.9. Etapas para Construção do Data Warehouse .............................20 3. DESENVOLVIMENTO .....................................................................22 3.1. A EMPRESA.....................................................................................22 3.2. APLICAÇÃO DA ABORDAGEM ADAPTATIVA do SAD........24
iv
3.3. APLICAÇÃO DAS ETAPAS PARA CONTRUÇÃO DO DW ....25 3.4. ESPECIFICAÇÃO...........................................................................26 3.5. IMPLEMENTAÇÃO .......................................................................32 3.5.1. ETL.................................................................................................32 3.5.2. Ferramenta OLAP.........................................................................37 4. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS............47 REFERÊNCIAS BIBLIOGRÁFICAS ..................................................50 APÊNDICE 1 – FONTE PRC_CARGA_ARQUIVO_TEXTO...........52 APÊNDICE 2 – FONTE PRC_CARGA_DATAFLEX........................54 APÊNDICE 3 – FONTE PRC_CARGA_MODELO_ESTRELA.......69 APÊNDICE 4 – FONTE PRC_CARGA_DATAFLEX_ESTRELA ...77 APÊNDICE 5 – FONTE PRC_CARGA_INCREMENTAL ...............82 APÊNDICE 6 – FONTE PRC_ACERTA_NF ......................................92 APÊNDICE 7 – ARTIGO PUBLICADO NA REVISTA DISTRIBUIÇÃO (EDIÇÃO NÚMERO 143)........................................93 ANEXO 1 – ARTIGO .............................................................................95
v
LISTA DE ABREVIATURAS
ABAD Associação Brasileira dos Atacadistas e Distribuidores DER Diagrama de Entidade e Relacionamento DFD Diagrama de Fluxo de Dados DM Data Mart DW Data Warehouse EIS Sistema de Informação Executiva ERP Enterprise Resource Planning (Sistema Integrado de Gestão) ETL Extração, Transformação e Limpeza OLAP On Line Analytical Process (Processo Analítico On-Line) OLTP On Line Transaction Processing (Processo de Transações On-Line) SAD Sistema de Apoio a Decisão SI Sistema de Informação SIG Sistema de Informações Gerenciais
vi
LISTA DE FIGURAS
Figura 1. Situação atual de acesso aos dados de vendas na Distribuidora Muller Ltda.......................3 Figura 2. Elementos de um Sistema de Informação.............................................................................2 Figura 3. Modelo de Sistemas de Informação......................................................................................3 Figura 4. Tendências em Sistemas de Informação...............................................................................4 Figura 5. Suporte a diferentes estruturas de problemas .......................................................................7 Figura 6. Arquitetura de um data warehouse .....................................................................................13 Figura 7. Abrangência dos metadados ...............................................................................................14 Figura 8. Elementos de um Data Warehouse .....................................................................................16 Figura 9. Cubos de Decisão................................................................................................................19 Figura 10. Distribuidora Muller Ltda.................................................................................................22 Figura 11. Diagrama de Contexto ......................................................................................................27 Figura 12. DER Lógico da Base Dimensional ...................................................................................27 Figura 13. DER Físico da Base Dimensional.....................................................................................28 Figura 14. DFD dos processos ETL e Ferramenta OLAP..................................................................31 Figura 15. Execução do Processo de Carga dos Dados do Dataflex para o Oracle. ..........................33 Figura 16. Execução do Processo PRC_CARGA_MODELO_ESTRELA. ......................................34 Figura 17. Execução do Processo PRC_CARGA_DATAFLEX_ESTRELA. ..................................34 Figura 18. Execução do Processo PRC_CARGA_INCREMENTAL. ..............................................35 Figura 19. Resumo do processo de carga inicial para a base do DW ................................................36 Figura 20. Estrutura (Componentes) da Ferramenta Oracle Discoverer ............................................39 Figura 21. Business Area “Vendas Muller” no componente Oracle Discoverer Administrator........40 Figura 22. Seleção dos itens desejados dentre os itens disponíveis na Business Area ......................41 Figura 23. Constrtução do layout da consulta (linhas, colunas, células e itens de página)................42 Figura 24. Definição de condições de seleção de dados ....................................................................42 Figura 25. Consulta com seus itens já formatados .............................................................................43 Figura 26. Consulta “Valor Total de Venda – Região / Cidade x Mês” ............................................44 Figura 27. Gráfico “Valor Total de Venda na Região Litoral” ..........................................................45 Figura 28. Gráfico “Valor Total de Venda por Forma de Pagto” ......................................................45 Figura 29. Estrutura multi-camada do DW desenvolvido para Distribuidora Muller Ltda ...............46
vii
LISTA DE TABELAS
Tabela 1. Tabela da dimensão cliente ................................................................................................28 Tabela 2. Tabela da dimensão forma de pagamento ..........................................................................28 Tabela 3. Tabela da dimensão condição de pagamento .....................................................................29 Tabela 4. Tabela da dimensão tipo de venda .....................................................................................29 Tabela 5. Tabela da dimensão embalagem.........................................................................................29 Tabela 6. Tabela da dimensão vendedor / representante....................................................................29 Tabela 7. Tabela da dimensão produto...............................................................................................29 Tabela 8. Tabela da dimensão tempo .................................................................................................30 Tabela 9. Tabela de Fato Venda.........................................................................................................30
viii
RESUMO
SOARES, Adelir. Sistema de Informação Baseado em Tecnologia de Data Mart para Análise de Informações de Vendas. Itajaí, 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2004. A Distribuidora Müller Comércio e Representações Ltda, atuando no setor atacadista a mais de 36 anos, possui um sistema ERP com base de dados em Oracle. Já o sistema anterior, de desenvolvimento interno foi todo desenvolvido no Dataflex. A falta de informação estruturada e integrada de ambos os sistemas acarreta a dificuldade e demora na tomada de decisão gerencial de vendas, fazendo com que problemas e oportunidades passem despercebidos. Fica clara a necessidade de uma ferramenta, que apresente as informações consolidadas a gerencia de vendas e aos dirigentes da empresa, de modo a permitir uma análise flexível, possibilitando a análise de dados de 5 anos de vendas e não de apenas poucos meses, de modo a melhor subsidiar a tomada de decisão, em relação, por exemplo, à investimento dos recursos para vendedores e promoções nas regiões atendidas pela empresa, aquisição de mercadorias, contato com clientes e identificação de clientes especiais em suas categorias, entre outros. Para viabilizar estas informações aos gerentes e supervisores da empresa, foi construido um sistema de Data Mart para o departamento comercial da empresa, que está armazenando informações sobre a estrutura de funcionamento e desempenho do sistema de venda no atacado e que objetiva servir como instrumento balizador no processo de análise e tomada de decisão. Para alcançar estes objetivos foi necessário levantar as necessidades de informação do departamento de vendas através de entrevistas, desenvolver o modelo multidimensional para o Data Mart de vendas, desenvolver o aplicativo ETL (extração, transformação e limpeza de dados) dos dois sistema ERP (Dataflex e Oracle), demonstrar através de consultas ad hoc relatórios e gráficos. Palavras-chave: Data Mart. Distribuição. Sistemas de Informação de Vendas.
ix
ABSTRACT
Muller Comércio e Representações LTDA, dealing with wholesale for more than 36 years, it has an ERP system with data basis in Oracle. The previous system in inner developing was developed in Dataflex. The lack of structured and integrated information causes delay and difficulty when it comes to making decisions managing sales; problems and opportunities may not be noticed. There’s need of a tool which presents the information to sales management and the directors of the company, so that a flexible analysis could be possible not only for the past months but also for the past 5 years, to enable better decisions for investments in sales and promotions throughout the region the company embraces, for acquisition of goods, contacting clients and identifying VIP-clients in their degree. To enable the information to managers and supervisors, a Data Mart system was developed in the business department of the company, which stores data about the functionalism and developing of the wholesale business and is to attend as a marker for analysis and decisions. To reach these goals, a raising of needs in information in the business department was necessary, with the use of interviews, also the developing of a multidimention pattern for business Data Mart, the developing of ETL application (data extraction, modification and sweep) in both ERP systems (Dataflex and Oracle), the demonstration through ad hoc reports and graphs. Key words: Data Mart. Distribution. Business Information System.
1
1. INTRODUÇÃO
A evolução do varejo e do atacado tem demonstrado uma trajetória de convergência para a
busca da eficiência, o aumento da competitividade e da rentabilidade, a redução de custos e a
otimização da atividade. Cada vez mais o setor atacadista/distribuidor passa a se restringir às
funções de comprar e vender, mas de modo a aumentar sua rentabilidade e direcionar corretamente
seus investimentos. Para que isso aconteça, a base da evolução está centrada na informação e na
forma de obtê-la no tempo certa, de forma compreensível e abrangente.
Este trabalho está sendo desenvolvido para a Distribuidora Muller Ltda, estabelecida na
cidade de Itajaí – SC e fundada em 1967. Em 2003 a empresa optou por trocar seu ERP, de
desenvolvimento interno acessando base Dataflex, pelo ERP da empresa CONSINCO de Ribeirão
Preto – SP, baseado em banco de dados Oracle. Com esta troca do sistema transacional da empresa
surgiram problemas relativos a encontrar e integrar informações, que em cada um dos sistemas se
encontram em padrões diferentes. Desta forma, atualmente os dados operacionais dos últimos cinco
anos da empresa estão distribuídos em duas plataformas de banco de dados: Dataflex e Oracle.
Alguns números que permitem identificar o porte e volume de dados da empresa são:
• Funcionários: 201; Estagiários: 02 e Temporários/contratados: 65;
• Representantes: 136;
• Fornecedores: 80 sendo 24 distribuição;
• Clientes: 13.880 ativos;
• Faturamento mensal: R$ 4,5 milhões;
• Média de notas fiscais / mês: 16.000 e Itens de Nota: 184.000;
• ERP atual: Consinco; e
• Banco de dados:
1. Oracle (último ano de dados); e
2. Dataflex (quatro anos de dados anteriores ao Oracle).
2
A falta de informação estruturada e integrada de ambos os sistemas acarreta a dificuldade e
demora na tomada de decisão gerencial de vendas, fazendo com que problemas e oportunidades
passem despercebidos. Essas características demonstram as necessidades específicas que podem ser
satisfatoriamente atendidas pela implantação de um ambiente de Data Warehouse, mais
especificamente um Data Mart para a área de vendas.
Os dados, por serem referentes a sistemas operacionais diferentes, devem ser tratados,
integrados e consistidos em uma fase do Data Warehouse, denominada ETL (Extração,
Transformação e Limpeza). O Processo Analítico de Transações On-Line (OLAP) aplicado aos
dados, após sua integração, permitindo a manipulação de informações organizadas de forma lógica
(através de banco de dados relacional) em Cubos de Decisão, permitindo a geração de consultas ad-
hoc, relatórios e gráficos que atendam, de forma flexível, as necessidades de informação da
gerência de vendas da organização.
Segundo Laudon (1999), um Sistema de Informação (SI) pode ser definido como um
conjunto de componentes inter-relacionados trabalhando juntos para coletar, recuperar, processar,
armazenar e fornecer informação com o objetivo de facilitar o planejamento, o controle, a
coordenação, a análise e o processo decisório nas organizações. Esse conceito permite identificar
que os sistemas de informação abrangem desde a camada operacional até a estratégica, passando
pela tática, da organização.
Os sistemas de informação que atendem as camadas tática e estratégica das organizações são
conhecidos como Sistema de Informações Gerenciais (SIG), pois ao transformar dados em
informações que podem ser utilizadas na estrutura decisória da organização, proporcionam
sustentação para a tomada de decisão gerencial. (OLIVEIRA, 2002). Os SIG evoluíram e ganharam
características de flexibilidade e adaptabilidade às mudanças, dando origem aos Sistemas de Apoio
a Decisão (SAD) (BINDER, 1994).
As informações contidas nos tradicionais sistemas orientados à transação, oriundas da
camada de usuários operacionais da organização, em geral, não suprem as necessidades de
consultas dos gerentes, que precisam acessar longos períodos históricos, muitas vezes de vários
anos, que não estão disponíveis nos sistemas utilizados para gerenciar as tarefas do dia-a-dia da
empresa. E mesmo que estes diversos anos de informação estivessem disponíveis nos sistemas
transacionais, o desempenho no acesso a tais informações seria extremamente prejudicado.
3
A dificuldade de acesso a longos períodos históricos de informação seguida da característica
de muitas organizações de ter seus dados distribuídos em diferentes sistemas de origem e, muitas
vezes, em diferentes plataformas computacionais, dificultando o seu acesso e integração, tornou
necessário o uso de sistemas conhecidos como Data Warehouse (DW). O DW se caracteriza por ser
um ambiente de apoio à decisão que alavanca dados armazenados em diferentes fontes e
plataformas, referentes a longos períodos de tempo, de 5 a 10 anos, e os organiza, valida e entrega
aos tomadores de decisões da organização, oferecendo aos usuários a inteligência do negócio para a
tomada de decisão e se apresentando como uma tecnologia de gestão e análise de dados (SINGH,
2001).
DW é o processo de integração dos dados corporativos de uma organização em um único
repositório a partir do qual os usuários finais podem facilmente executar consultas, gerar relatórios
e fazer análises. Então, um sistema de DW é composto por um banco de dados, para onde somente
as informações necessárias para a tomada de decisões são carregadas, vindas dos bancos de dados
operacionais. Os dados são carregados para este novo banco apenas se fizerem parte do contexto de
interesse e de forma desnormalizada, potencializando desempenho e a possibilidade de responder a
questões complexas, como tendências e mudanças de mercado, desempenho de vendas e assim por
diante (OLIVEIRA, 1998; Singh, 2001).
Figura 1. Situação atual de acesso aos dados de vendas na Distribuidora Muller Ltda
Os conceitos de Data Warehouse / Data Mart encontram oportunidade de aplicação na
situação atual em que a empresa para a qual se destina o projeto encontra-se, no que diz respeito à
obtenção de informação consistente e integrada de forma ágil, como demonstrado na Figura 1.
Base Oracle
1 ano de informação
Base Dataflex
4 anos de informação
Integração
Estruturação
Busca rápida
Consistência
4
1.1. OBJETIVOS
1.1.1. Objetivo Geral
Com este trabalho objetiva-se desenvolver um Sistema de Informação de Data Mart para
disponibilizar informações de vendas no atacado, de modo auxiliar na tomada de decisão e otimizar
o aproveitamento de recursos para o departamento de vendas da Distribuidora Muller Ltda.
1.1.2. Objetivos Específicos
Este objetivo maior deve ser alcançado através de:
• Levantar as necessidades de informação do departamento de vendas através de
entrevistas;
• desenvolver o modelo multidimensional para o Data Mart de vendas, juntamente com
suas propriedades, como granularidade, historicidade, e assim por diante;
• desenvolver o processo ETL (extração, transformação e limpeza de dados) da base
transacional do sistema ERP anterior (Dataflex);
• desenvolver o processo ETL da base transacional atual (Oracle);
• implementação da ferramenta OLAP (lado Servidor) do Data Mart para área de vendas
no atacado; e
• disponibilizar interface para consultas ad hoc, relatórios e gráficos, informações
relevantes a tomada de decisão gerencial em vendas.
1.2. METODOLOGIA
A pesquisa desenvolveu-se através do levantamento bibliográfico em publicações (livros,
revistas e periódicos especializados) e na Internet. Os artigos científicos localizados referenciaram o
desenvolvimento de sistemas semelhantes. A análise das informações encontradas considerou a
procedência das mesmas, sua quantidade, relevância, características desejáveis e limitações
relacionadas à aplicação desejada.
Foi feito levantamento de informações relacionadas a vendas junto à empresa, incluindo a
base de dados e sistema transacional (modelo entidade-relacionamento, diagrama hierárquico de
funções) tanto para o sistema antigo, quanto para o novo e as maiores necessidades de informações
5
gerenciais (entrevistas junto a usuários do sistema transacional e gerente de vendas). Inicialmente
foram entrevistados os gerentes de venda a respeito dos requisitos necessários para um sistema de
informações que auxilie a tomada de decisões gerenciais de vendas, e posteriormente os usuários
que relataram suas necessidades a respeito de relatórios.
Com os conteúdos referentes a sistemas de informação, Data Warehouse e Data Mart,
obtida através de livros especializados e pesquisas na Internet, tratou principalmente do referencial
teórico associado e da programação e uso dessas tecnologias. A leitura e compreensão da
bibliografia referente a metodologia de concepção e construção de ambientes de DM/DW, foram
essenciais para a utilização da metodologia.
Para a especificação detalhada dos processos foi utilizado a ferramenta Oracle Designer. Os
diagramas usado no projeto foi entidade-relacionamento. Foram especificados os componentes que
satisfazem completamente as especificações e análise, determinando os algoritmos dos
componentes, incluindo diagramas de fluxo de dados e dicionário de dados.
A ferramenta OLAP adotada é o Oracle Discoverer, composto por componentes de carater
servidor, cliente desktop e cliente Web. O acesso ao modelo OLAP disponibilizado através de
ferramenta OLAP Desktop e Web aos profissionais será implementada, testada e validada junto ao
usuário do Data Mart de venda.
Inicialmente pretendia-se desenvolver a ferramenta OLAP em linguagem de programação
Borland Delphi 7.0. No entanto, tal construção se mostrou desnecessária, devido ao fato de a
ferramenta Oracle Discoverer apresentar melhor performance e flexibilidade, além de estar
disponível juntamente com a ferramenta Application Server, podendo ser disponibilizada muito
facilmente para a Web. Os testes serão realizados através da verificação do funcionamento das
estruturas modeladas, analisando se as mesmas produzem os resultados esperados para entradas
conhecidas, devendo ser avaliada a funcionalidade e facilidade completa da ferramenta e da
estrutura construída. O teste geral será feito com a gerência de vendas utilizando simultaneamente o
sistema.
Em relação aos riscos, estes são minimizados com a adoção de uma ferramenta já
consolidada no mercado e de um processo formal de revisão e aceitação do projeto implementado,
pelos gerentes envolvidos. Riscos relativos a queda do banco de dados ou falha na comunicação na
6
rede, resultará na saída do sistema de funcionamento. O processo analítico do negócio apresenta
baixo risco, pois os requisitos foram validados previamente com as gerências de interesse.
1.3. ESTRUTURA DO TRABALHO
No Capítulo 2 são apresentados os temas referentes a Sistemas de Informação, delimitando o
aprofundamento da pesquisa no que se refere aos sistemas de informações gerenciais e como estes
se apresentam e classificam na atualidade. O Capítulo 2, ainda permite expandir os conceitos de
Data Warehouse e Data Mart, através da apresentação de algumas linhas de discussão. Neste
capítulo pretende-se esclarecer conceitos e apresentar metodologias para o desenvolvimento de
projetos que envolvam tais tecnologias.
O Capitulo 3 apresenta a empresa para a qual o sistema foi desenvolvido e sua área de
atuação – o atacado, bem como o desenvolvimento do projeto propriamente dito, com suas fases e
os modelos gerados.
O Capítulo 4 finaliza o projeto, apresentando os resultados obtidos, as considerações finais e
as sugestões para trabalhos futuros.
2
2. FUNDAMENTAÇÃO TEÓRICA
Neste capítulo objetiva-se trazer uma visão geral sobre a fundamentação teórica que irá
direcionar a realização do projeto proposto. Parte-se de uma visão mais ampla que resgate conceitos
e classificações de sistemas de informação, de modo a situar sistemas de Data Warehouse e Data
Mart. Após esta primeira visão geral parte-se para a conceituação, objetivos, estrutura e etapas de
desenvolvimento de um Data Warehouse.
2.1. SISTEMAS DE INFORMAÇÃO
Dentre diversos conceitos encontrados na literatura, alguns deles definem Sistemas de
Informações como “um conjunto de pessoas, hardware, software, redes de comunicações e recursos
de dados que coleta, transforma e dissemina informações em uma organização, reforçando a
comunicação entre os seus atores”. Os dados brutos são coletados e transformados em informações
utilizáveis no fluxo de trabalho dentro de uma organização e na sua estrutura decisória,
proporcionando sustentação administrativa (baseada nas metas estabelecidas e nas decisões tomadas
pelas pessoas que as fazem acontecer), como demonstrado na Figura 2. (REZENDE, 2001;
O’BRIEN, 2003; CECHINEL, 2003)
Figura 2. Elementos de um Sistema de Informação
Fonte: Cechinel (2003)
3
A utilização de Sistemas de Informação nas organizações possibilita auxiliar a tomada de
decisões, análise e visualização de assuntos complexos e solução de diversos tipos de problemas
através de um ciclo de atividades básicas: entrada, processamento, saída e retroalimentação
(LAUDON et al, 1999). Dentre os modelos apresentados na literatura, o apresentado por O’Brien
(2003) na Figura 3, expressa a estrutura conceitual dos principais componentes e atividades
inerentes a quaisquer Sistemas de Informação.
Figura 3. Modelo de Sistemas de Informação
Fonte: O'Brien (2003)
A Figura 4 apresenta a evolução nos papéis dos Sistemas de Informação computadorizados e
o impacto dessas mudanças sobre os usuários finais e gerentes das organização.
4
Figura 4. Tendências em Sistemas de Informação
Fonte: O'Brien (2003)
Para Laudon (1999) nenhum tipo único de sistema rege todas as atividades de uma
organização, o que acarreta em que as organizações possuam diferentes tipos de Sistemas de
Informação para diferentes níveis de problemas, diferentes funções dentro da organização e
diferentes níveis de tomada de decisão. Cada área funcional que uma organização desenvolve
sistemas, sendo que a organização passa a utilizar sistemas de fabricação e produção, sistemas de
finanças e contabilidade, sistemas de vendas e marketing e sistemas de recursos humanos. Para cada
uma destas áreas funcionais, os sistemas devem ser entendidos em quatro diferentes níveis:
5
1. nível estratégico: ajudam os gerentes seniores a planejar o curso da ação em longo prazo;
2. nível tático: ajudam os gerentes intermediários a supervisionar e coordenar as atividades
diárias da organização;
3. nível de conhecimento: os especialistas e funcionários de escritório utilizam para
projetar produtos, racionalizar serviços e lidar com documentos; e
4. nível operacional: tratam das atividades diárias de produção e serviço.
2.1.1. Tipos de Sistemas de Informação
Muitos sistemas são usados para controle de tarefas cotidianas e requerem pouco de tomada
de decisão, em geral essas aplicações são altamente estruturadas e previsíveis. Em contrapartida, há
sistemas que são mais voltados ao planejamento estratégico da organização e nesse caso dão suporte
à decisão dos gerentes. Os Sistemas de Informação podem ser classificados segundo o suporte a
tomada de decisão, dentro desta classificação as suas principais categorias são apresentadas a seguir
(REZENDE, 2001; O’BRIEN, 2003; SILVA JR., 2000).
1. Sistemas de automação de escritório: são sistemas computadorizados, tais como
processadores de texto, sistemas de correio eletrônico, e sistemas de agenda, pessoais e
organizacionais, que são projetados para aumentar a produtividade dos trabalhadores
administrativos de um escritório;
2. Sistemas de processamento das transações: sistemas computadorizados que executam e
gravam as transações diárias e rotineiras da organização, necessárias para a condução
dos negócios; processam dados resultantes de transações organizacionais, atualizam
banco de dados operacionais e produzem documentos organizacionais. Servem ao nível
operacional da organização. Esse tipo de sistema também pode envolver os seguintes
sub tipos de sistemas;
a. Sistemas de controle de processos: monitoram e controlam processos industriais; e
b. Sistemas colaborativos: apóiam equipes, grupos de trabalho bem como
comunicações e colaboração nas organizações.
3. Sistemas de Base de Conhecimento ou Especialistas: sistemas de informações que
ajudam aqueles trabalhadores que manipulam, integram e/ou geram informações e
conhecimento na organização. Os sistemas especialistas são sistemas baseados no
6
conhecimento e fornecem conselho especializado e funcionam para os usuários como
consultores especialistas. Já os sistemas de administração baseado em conhecimento são
sistemas baseados no conhecimento e apóiam a criação, organização e disseminação de
conhecimento empresarial dentro da organização;
4. Sistemas de Informações Gerenciais: sistemas de informação ao nível gerencial de uma
organização que servem às funções de planejamento, controle e tomada de decisão. Os
sistemas de apoio gerencial fornecem informações e apoio necessários para a tomada de
decisão eficaz pelos gerentes, fornecendo informações na forma de relatórios e
demonstrativos pré-estipulados para os gerentes;
5. Sistemas de Suporte à Decisão: sistemas de informação ao nível gerencial de uma
organização que combinam dados e modelos analíticos sofisticados para dar suporte a
tomada de decisão semi e não estruturada. Fornecem apoio interativo ad hoc para o
processo de decisão dos gerentes; e
6. Sistemas de Informações Executivas: sistemas de informação ao nível gerencial
projetados para dar suporte à tomada de decisão não estruturada, através de avançadas
interfaces gráficas e mecanismos de comunicação. Fornecem informações críticas
elaboradas especificamente para as necessidades de informação dos executivos.
Os Sistemas de Informação, independentemente de seu nível ou classificação, têm como
maior objetivo auxiliar, cada um a seu modo, os processos de tomada de decisões na organização.
Se os Sistemas de Informação não se propuserem a atender a esse objetivo, sua existência deixa de
ser significativa para a organização, sendo que o foco dos Sistemas de Informação deve estar
direcionado para o principal negócio da organização. Para vencer o desafio da competitividade, as
organizações dependem cada vez mais do que os sistemas de informações podem fazer por elas.
Desta forma, vários destes sistemas podem ser classificados, paralelamente, como sistemas de
informação estratégica, que fornecem a uma organização produtos, serviços e perícias estratégicos
para a vantagem competitiva (REZENDE, 2001).
2.1.2. Sistema de Apoio à Decisão
Um dos principais desafios gerenciais da atualidade é fazer uso da tecnologia da informação
para projetar e gerenciar empresas competitivas e eficientes. Sistemas de Informação se tornaram
vitais e extremamente importantes para o gerenciamento, organização e operação das empresas.
7
Segundo O’Brien (2003) os Sistemas de Apoio à Decisão (SAD) são uma das principais categorias
de sistemas de apoio gerencial. São Sistemas de Informação computadorizados que fornecem aos
gerentes apoio interativo de informações durante o processo de tomada de decisão.
Binder (1994) considera um SAD como um sistema mais complexo que permite total acesso
à base de dados da organização, modelagem de problemas, simulações, possui uma interface
amigável e auxilia os dirigentes em todas as fases da tomada de decisão, principalmente, nas etapas
de desenvolvimento, comparação e classificação dos riscos, além de fornecer subsídios para escolha
de uma boa alternativa.
A Figura 5 caracteriza os tipos de decisões, como semi-estruturadas que podem ser pré-
especificadas, mas não o suficiente para levar à uma decisão definida recomendada, já as decisões
estruturadas envolvem situações em que os procedimentos a serem seguidos para a tomada de
decisão podem ser especificados de antemão, e as decisões não estruturadas envolvem situações de
decisão nas quais não é possível especificar de antemão a maioria dos procedimentos a serem
seguidos (O’BRIEN, 2003).
Figura 5. Suporte a diferentes estruturas de problemas
Fonte: O'Brien (2003)
8
Os SADs geralmente são voltados ao atendimento das necessidades para a tomada de
decisão em operações cotidianas e problemas estruturados ou semi-estruturados, sendo que os
problemas semi-estruturados combinam elementos tanto de problemas estruturados, quanto de não-
estruturados (STAIR, 1999).
Rezende (2001) salienta que, para que a empresa possa usufruir das vantagens básicas do
sistema de informações gerenciais ou de apoio a de decisão, é necessário o envolvimento da alta e
média gerência, a competência das pessoas envolvidas com o sistema, o uso de um plano mestre, a
atenção específica ao fator humano, a habilidade dos executivos em identificar as necessidades de
informações, e em tomar decisões com base nelas, o apoio global dos vários planejamentos da
empresa, o apoio organizacional de adequada estrutura organizacional e das normas e
procedimentos inerentes ao sistema; o conhecimento e confiança no sistema, a existência de
dados/informações relevantes e atualizados e a adequada relação custo-benefício.
A área de informática deve facilitar o trabalho dos gerentes, na busca dos resultados para a
empresa, o que exige um processo cuidadoso de planejamento da arquitetura de informação da
organização. Quatro fatores básicos devem ser observados durante o desenvolvimento e
implantação de um sistema de informação: envolvimento do usuário no processo de
desenvolvimento e implantação; suporte da gerência e o grau no qual a gerência dá suporte ao
esforço de implementação; o nível de risco e complexidade do projeto; a qualidade do
gerenciamento do processo de implantação. A deficiência em um desses fatores pode causar
problemas no design do sistema; na definição, exatidão e confiabilidade dos dados; no custo de
implantação do sistema; e em deficiências na operação do sistema.
2.1.3. Características do SAD
Binder (1994) caracteriza o SAD, como útil para a resolução de problemas mais complexos
e menos estruturados, pois combinam modelos e técnicas analíticas com as funções tradicionais de
processamento de dados. Os SADs devem ser interativos, adaptáveis a mudanças, permitir meios de
distribuição eficientes da informação e o suporte à decisão necessário em todos os níveis. As
principais características deste tipo de sistemas de informação, segundo Stair (1999), são:
1. lidar com grandes quantidades de dados de diferentes fontes: um exemplo, são os
sistemas avançados de banco de dados e de Data Warehouse que têm permitido aos
9
tomadores de decisão consultar informações nos banco de dados usando um SAD,
mesmo que algumas fontes residam em banco de dados diferentes;
2. prover flexibilidade de relatório e de apresentação: os gerentes podem obter a
informação que desejam, apresentada num formato que se ajuste a suas necessidades;
3. oferecer orientação gráfica e de texto: um SAD pode fornecer a orientação de acordo
com a preferência do gerente, seja em texto ou em gráfico;
4. suportar a análise de drill down: um gerente pode conseguir mais níveis de detalhes
quando necessário, fazendo o drill down dos dados consolidados, por exemplo, pode
verificar o custo total do projeto ou, por meio do drill down obter o custo em cada fase,
atividade ou tarefa do projeto;
5. executar análises complexas e sofisticadas bem como comparações usando pacotes de
software avançados: os questionários de pesquisa de marketing, por exemplo, podem ser
analisados numa variedade de maneiras usando programas de análises que fazem parte
de um SAD, muitos dos programas analíticos associados a um SAD são, de fato,
programas independentes e somente fornecem um meio de reuni-los num único pacote;
6. prover suporte às abordagens de otimização, convencionais e heurísticas: para problemas
tidos como pequenos, os SADs podem encontrar a melhor solução, já para problemas
mais complexos são usadas às abordagens convencionais e heurísticas, ou seja, onde o
computador determina uma solução muito boa, mas não, necessariamente, a melhor; e
7. executar análise de sensibilidade, simulações e dispor de ferramentas de “atingir-meta”
(goal-seeking): constitui o processo de se introduzir mudanças hipotéticas nos dados do
problema e observar o impacto nos resultados, um gerente pode modificar os dados do
problema e imediatamente avaliar o impacto.
Um sistema baseado na tecnologia de Data Warehouse (DW) pode ser considerado um
Sistema de Apoio à Decisão, pois uma base relacional do DW pode ser utilizada como apoio para a
tomada de decisão gerencial na organização e engloba a análise de muitas unidades de dados
conduzindo a uma informação de grande valor agregado. O valor da informação é um conceito
muito relativo, pois nem todas as informações apresentam a mesma importância para uma decisão e,
por melhor que seja a informação, se não for comunicada às pessoas interessadas em forma e
conteúdo adequados, ela perde todo o seu valor (INMON, 1997; KIMBALL, 2002).
10
2.1.4. Abordagem Adaptativa do SAD
Para o desenvolvimento de um SAD diversas abordagens podem ser seguidas, dentre elas a
abordagem adaptativa, que tem este nome devido à sua grande adaptabilidade a mudanças no
contexto ou até mesmo no problema de decisão que está sendo modelado. De acordo com Binder
(1994), as principais características da abordagem adaptativa são o reduzido tempo de construção, o
desenvolvimento conjunto com o usuário, o início do processo de desenvolvimento pelo problema
crucial do usuário e a avaliação constante do sistema.
Binder (1994) apresenta os seguintes passos como necessários para o desenvolvimento de
um SAD a partir da abordagem adaptativa:
1. preparação do ambiente: preparar o ambiente para a entrada de um SAD na organização,
através de conversas, workshops e reuniões com o pessoal de suporte à informática,
levantando informações do banco de dados existente na organização e filtrando essas
informações; conversando com o gerente e demais usuários enfatizando a importância do
envolvimento deles na construção do sistema;
2. identificação dos requisitos de informação para a tomada de decisão: conversar com o
gerente para levantar informações sobre os problemas em determinado setor e o tipo de
análise atualmente utilizada para a tomada de decisão relativa a ele, se não for possível
identificar o problema como um todo, identificar um subproblema simples, porém
significativo para o problema geral;
3. desenvolvimento de um protótipo do SAD evolutivo, com base nas exigências ou no
subproblema identificado: esta fase deve ter uma duração o mais curta possível e
envolve todas as etapas do processo de desenvolvimento tradicional com a ativa
participação do usuário: análise, projeto, construção e implementação do protótipo
evolutivo que possui todas as características básicas de um sistema real e deve ser
utilizado efetivamente, logo após os testes;
4. avaliação do protótipo: detectar os possíveis problemas desta solução inicial e as
possíveis mudanças que já estejam ocorrendo no ambiente ou mesmo no processo de
decisão; e
5. implementação de melhorias: o SAD inicial começa a se modificar e responder à
mutabilidade do ambiente. Essas mudanças devem ser inseridas no sistema, obedecendo-
11
se ao ciclo de desenvolvimento (análise, projeto, construção, implementação e avaliação)
de maneira rápida e confiável.
Nesta abordagem, o propósito básico da informação (útil e atualizada) é o de habilitar a
empresa a alcançar seus objetivos pelo uso eficiente dos recursos informacionais disponíveis. Os
tomadores de decisões corporativos precisam de respostas para uma série de questões que afetam
diretamente sua habilidade de competir no mercado. A informação certa, na hora certa e para a
pessoa certa gera subsídios para a implementação de estratégias e definição de objetivos e a sua
modificação quando estes se tornam ineficazes.
Para administrar e usar as informações de forma competitiva, muitas companhias estão
implementando Sistemas de Apoio à Decisão construídos com base em um Data Warehouse (DW),
pois ele armazena os dados históricos e operacionais de uma organização em um banco de dados
integrado para apoio à decisão, acesso a dados corporativos e geração de relatórios (SINGH, 2001).
2.2. DATA WAREHOUSE
Atualmente o desenvolvimento de sistemas de Data Warehouse (DW) vem se tornado uma
grande área de estudo e aplicação nas empresas. As empresas e os clientes ficaram mais ágeis e
exigentes, fazendo com que a descrição, extração e sincronismo dos dados seja necessária para dar
apoio às decisões e manter a competitividade entre as empresas. A possibilidade de acessar
informações confiáveis com boa velocidade e garantia de qualidade de dados está cativando os
diretores das organizações que cada vez mais necessitam de um controle mais correto de seus dados
sem depender de intermediários para poder tomar suas decisões (KIMBALL, 2002).
Na literatura (INMON, 1997; OLIVEIRA, 1998; SINGH, 2001; KIMBALL, 2002), um
Data Warehouse pode ser considerado um conjunto de instantâneos de dados, extraídos dos
Sistemas de Processamento de Transação On-Line (OLTP - sistemas operacionais de fonte única ou
múltipla), em determinado intervalo de tempo e carregados em uma base central de dados ou
“warehouse”. Ou seja, os Data Warehouse são bancos de dados usados unicamente para a produção
de relatórios ou consultas, sendo facilmente acessado por tomadores de decisão para auxiliar em
suas análises, o que contrasta com os bancos de dados tradicionais. As informações contidas nos
tradicionais sistemas orientados à transação não suprem as necessidades de consultas dos gerentes
que precisam acessar longos períodos históricos, em geral de vários anos, os quais certamente não
estão disponíveis nos sistemas utilizados para gerenciar as tarefas do dia-a-dia da empresa.
12
Inmon (1997) resume DW como “um conjunto de dados baseado em assuntos, integrado,
não-volátil e variável em relação ao tempo, de apoio às decisões gerenciais”.
Os sistemas OLTP são baseados em transações, sendo configurados e otimizados para
prover respostas rápidas às transações individuais, como inclusão, alteração e exclusão de dados,
tornando tais transações rápidas e confiáveis. Os dados são dinâmicos e mudam com grande
freqüência. Já os sistemas de apoio à decisão, como o Data Warehouse, se baseiam em uma
tecnologia conhecida como OLAP (Processo Analítico On-Line), onde a velocidade das transações
não influi, pois os dados são armazenados de forma estática (sem a possibilidade de inclusão,
exclusão ou alteração direta pelo usuário), sendo configurados e otimizados para suportar
complexas decisões (OLIVEIRA, 1998).
Os sistemas de apoio à tomada de decisão têm a finalidade de informar a alta direção da
empresa e as gerências quando, como, por quê e onde ocorrem problemas ou oportunidades de
melhoria dentro da organização, projetando certas características e "indicando" ao usuário situações
que podem muitas vezes passar desapercebidas (FLORES, 2002).
Em suma, o principal objetivo do Data Warehouse é coletar dados das várias aplicações,
armazenar informações de forma compreensível e de fácil acesso. Os dados contidos em um Data
Warehouse são organizados por área de assuntos e tornam-se integrados de forma comum a
referencia e o armazenamento de dados úteis (INMON, 1997; KIMBALL, 1998). As principais
utilizações do Data Warehouse são:
• Geração de relatório e gráficos;
• Obtenção de informações de dados necessários para sua criação, de varias fontes de
dados;
• Análise através de ferramenta OLAP; e
• Garimpo de informações, revelando padrões e informações escondidas.
A figura 6 apresenta a arquitetura de um Data Warehouse típico, com a coleta e o
armazenamento de dados, além do suporte à consulta e à análise de dados.
13
Figura 6. Arquitetura de um data warehouse
Fonte: Fanderuff (2002)
2.2.1. Data Mart
O Data Warehouse visa a atender as necessidades da organização como um todo,
apresentando uma estrutura verdadeiramente corporativa que atende a muitas necessidades
diferentes e de departamentos diferentes da organização. Um Data Warehouse é estruturalmente
diferente de um Data Mart, pois o Data Mart é um subconjunto do Data Warehouse que visa a
atender as necessidades de informação de um único departamento ou assunto. A organização pode
construir uma série de Data Marts ao longo do tempo e eventualmente vinculá-los em um DW
lógico da organização (SINGH, 2001; COREY, 2001; SINGH, 2001; KIMBALL, 2002).
Por exemplo, se a corporação não puder determinar a rentabilidade de seus produtos, pode
ser construído um Data Mart para analisar produto sob o foco da rentabilidade (mercado de
rentabilidade dos produtos). Neste caso, o objetivo é analisar os canais de vendas, determinar a
efetividade das campanhas de vendas, estudar as regiões onde estão concentrados os melhores
clientes, entre outros.
2.2.2. Metadados
Metadado são dados sobre os dados, em uma visão puramente simplificada. São dados
físicos que mantém informações sobre processos técnicos, negócios e assuntos usados na
14
organização. Metadados são utilizados para qualificar, contextualizar, organizar, facilitar o acesso,
apresentar existência e manutenção e indicar localização, tipo e meio de obtenção de fontes de
dados que geram informação. Em resumo, mapear e documentar fontes de dados (internas ou
externas). A figura 7 mostra a abrangência de atuação dos metadados.
Figura 7. Abrangência dos metadados
Fonte: DW Brasil (2004)
A constante manutenção de metadados, por muitos conhecida como documentação, permite
que a inclusão de novos membros à equipe do sistema ser menos traumática e mais dinâmica,
possibilitando facilidade de manutenção e integração em relação à equipe e ao sistema.
2.2.3. Características de um Data Warehouse
Um Data Warehouse possui quatro características básicas: é orientado por assunto,
integrado, variante no tempo e não volátil.
• Baseado em assuntos: Os banco de dados do DW, em geral, contêm informações a
respeito de funções organizacionais, consideradas importantes para o negócio da
empresa, pois cada sistema oferece suporte para consultas a respeito das informações
que ele captura (COREY, 2001);
• DW é integrado: Os bancos de dados OLAP são oriundos, em geral, da junção de
duas ou mais bases distintas das quais deve-se agrupar as informações. No entanto,
visto que as bases se encontram em locais, formatos, origens e com codificações
diferentes é necessário que um processo de transformação torne os dados integrados.
A integração ocorre quando os dados passam do ambiente operacional baseado em
15
aplicações para o DW e o processo de introdução dos dados é conduzido de forma
que as inconsistências das aplicações sejam desfeitas, para que a codificação para o
DW seja feita de forma consistente e independente da aplicação de origem (INMON,
1997);
• DW é não-volátil: O Data Warehouse é um banco de dados somente para leitura, no
qual se mantém um registro histórico das transações, desta forma seria incoerente
permitir gravações de manipulações de dados no Data Warehouse. Os dados
operacionais são regularmente acessados e tratados, um registro por vez, sofrem
atualizações, enquanto que os dados no DW são carregados e acessados, mas a
atualização dos dados não ocorre (INMON, 1997; KIMBALL, 2002); e
• DW é variável em relação ao tempo: Visto que o ambiente do Data Warehouse é um
ambiente destinado a geração de relatórios, o item histórico é algo de suma
importância para auxiliar na tomada de decisão, para o estudo de tendências e
sazonalidades. As séries temporais empregam características específicas ao ambiente
do Data Warehouse que deve ser programado para permitir o gerenciamento dos
dados representativos da coexistência de intervalos de tempo com informações que
serão analisadas e comparadas constantemente (INMON, 1997).
2.2.4. Componentes de um Data Warehouse
Os componentes de um DW podem ser analisados abaixo, conforme proposto por Kimball
(2002) e estão apresentados na Figura 8. A Data staging area é tanto uma área de armazenamento
como um conjunto de processos que tem por objetivo extrair os dados dos sistemas transacionais e
proceder à transformação e preparação dos dados para o uso no DW. O principal requisito é que não
esteja acessível aos usuários e que não forneça serviços de consulta nem de apresentação.
16
Figura 8. Elementos de um Data Warehouse
Fonte: Kimball (2002)
A área de apresentação de dados é local em que os dados ficam organizados, armazenados e
tornam-se disponíveis para serem consultados diretamente pelos usuários. Essa área é tudo o que a
comunidade do negócio vê e acessa através de ferramentas de acesso a dados. É essencial que os
dados sejam apresentados, armazenados e acessados em esquemas dimensionais.
Ferramentas de acesso a dados servem para aumentar as variedades de recursos dos usuários
de negócio, visando melhorar a tomada de decisões analíticas. Por definição, todas as ferramentas
de acesso de dados consultam os dados na área de apresentação do DW, sendo que a consulta é o
ponto principal do uso do DW.
2.2.5. Processos do Data Warehouse
Os processos de extração, transformação e carregamento (ETL) do DW transformam os
dados organizacionais em informações empresariais. Os sistemas de origem têm os dados; o DW é
estruturado para apresentar informações e o processo ETL é a caixa preta que transforma os
primeiros no último (COREY, 2001). Segundo Kimball (2002), o conjunto de processos ETL são:
1. Extração: é a obtenção de dados do ambiente operacional, que envolve a leitura e a
compreensão de dados de origem e cópia dos dados necessários ao DW na staging
area para futura manipulação;
17
2. Transformação: é a filtragem dos dados (correções de erros de digitação, solução de
conflitos de domínio, tratamento de elementos ausentes ou a divisão em formatos
padrão), combinação de dados de várias origens, cancelamento de dados duplicados
e atribuição de chaves no DW; e
3. Carga: é carregar os dados para o ambiente do DW. Esse processo normalmente
assume a forma de um processo de apresentação de tabelas dimensionais para o Data
Mart.
2.2.6. Granularidade
A granularidade é considerada um dos mais importantes aspectos em um projeto de Data
Warehouse, pois diz respeito ao nível de detalhe ou resumo dos dados contidos no Data Warehouse.
Quanto mais detalhe, mais baixo o nível de granularidade (INMON, 1997; KIMBALL, 2002).
Preferencialmente deve-se desenvolver modelos dimensionais para a maioria das
informações atômicas capturadas por um processo do negócio. Os dados atômicos são as
informações mais detalhadas coletadas, significa que mais coisas se sabe com certeza e há maior
flexibilidade analítica porque eles podem ser limitados e acumulados de diversas formas. Em
contrapartida, o modelo menos granular é imediatamente vulnerável a inesperadas solicitações de
usuário para descer ao nível de detalhes (KIMBALL, 2002).
2.2.7. Modelo Dimensional
O Data Warehouse utiliza o modelo dimensional ou multidimensional como base para a
representação de seus dados e as relações entre eles. As estruturas dimensionais podem ser
visualizadas como cubos de dados e cubos dentro de cubos de dados, onde cada face do cubo
representa uma dimensão (diferentes categorias – produto, região, tipo de venda, tempo, etc). Cada
célula dentro da estrutura dimensional contém dados agregados, relacionados a elementos em cada
uma das dimensões que constituem os fatos (O’BRIEN, 2003).
Desta forma, uma maneira de considerar a natureza complementar das tabelas de fatos e de
dimensões é exibi-las convertidas em um relatório, onde os atributos de dimensão fornecem a
identificação dos relatórios e as tabelas de fatos fornecem os valores numéricos dos relatórios
(KIMBALL, 2002).
18
Para Kimball (2002) a tabela de fatos é a principal tabela ou a tabela central de um modelo
dimensional, sendo que a palavra fato representa uma medida ou métrica utilizada no negócio, por
exemplo, valor de venda e quantidade vendida. Com essas informações é feita a medição nos pontos
de interseção de todas as dimensões (dia, produto, cliente, representante, etc), assim a lista de
dimensões define a granularidade da tabela de fatos e nos informa qual é o escopo da medição
(MAZZOLA, 2003).
2.2.8. Processamento Analítico Online (OLAP)
Segundo O’Brien (2003) o OLAP é a capacidade dos sistemas de apoio à decisão permitir
aos gerentes e analistas examinarem e manipularem interativamente enormes quantidades de dados
detalhados e consolidados a partir de múltiplas perspectivas.
As ferramentas OLAP são as aplicações que usuários finais têm acesso para extrair os dados
de suas bases e construir os relatórios capazes de responder as questões gerenciais (DWBRASIL,
2003). O processo interativo de criar, administrar, analisar e gerar relatórios sobre os dados são
percebidos e manipulados como se estivessem armazenados em um array multidimensional (DATE,
2000).
O OLAP usa modos de visualização de dados multidimensionais, freqüentemente os dados
são agregados, para maximizar sua eficácia (COREY, 2001). E as estruturas multidimensionais,
podem ser visualizadas como um cubo de dados e cubos dentro de cubos de dados, onde cada face
do cubo é considerada como uma dimensão dos dados (O’BRIEN, 2003). A Figura 9, mostra um
exemplo que a dimensão é exibida em categorias diferentes, assim como o tipo de produto, região,
canal de vendas e tempo.
O processamento OLAP pode ser implementado no banco de dados através de duas
arquiteturas principais: OLAP multidimensional (MOLAP) e OLAP relacional (ROLAP). A
diferença está na forma de armazenamento físico dos dados. Na arquitetura MOLAP os dados são
armazenados fisicamente de forma multidimensional, para serem vistos nesta mesma forma. Na
arquitetura ROLAP, os dados são armazenados em modelos relacionais (em geral,
desnormalizados), em base de dados relacionais. Pode-se, ainda, mesclar as características de ambas
arquiteturas em uma arquitetura híbrida – HOLAP (KIMBALL, 2002).
19
Figura 9. Cubos de Decisão
Fonte: O’Brien (2003)
Uma ferramenta OLAP possui diversas operações analíticas básicas, entre elas (KIMBALL,
2002; O’BRIEN, 2003; MAZZOLA, 2003):
1. drill-down: exibir os dados detalhados que compõem os dados consolidados, ou seja, faz
uma desagregação, por exemplo, as vendas por produtos ou representantes de vendas
individualizados, que formam os totais de vendas de uma região poderiam ser facilmente
obtidos;
2. drill-up: significa ir de um nível mais baixo de agregação até um nível mais alto. Um
exemplo é dada a quantidade total de remessas, obter as quantidades totais para cada
fornecedor individual (DATE, 2000); e
3. Slicing and dicing: significa fatiar em cubos, cujo o termo se refere à possibilidade de
considerar os banco de dados a partir de diferentes pontos de vista, por exemplo a fatia
do banco de dados de vendas poderia mostrar todas as vendas de tipo de produto dentro
20
das regiões. Geralmente ele é efetuado ao longo de um eixo de tempo a fim de analisar
tendências e descobrir padrões.
2.2.9. Etapas para Construção do Data Warehouse
Segundo Kimball e Ross (2002) a criação de um banco de dados dimensional segue em
etapas, em ordem específica, numa metodologia do tipo top-down (de cima para baixo). Estas
etapas são descritas abaixo:
1. selecione o processo de negócio a ser modelado, sendo um processo uma atividade de
negócio natural, executada na organização, que normalmente é aceita por um sistema de
coleta de dados de origem, portanto é importante não se referir a um departamento ou
função de negócio da organização, já que se trata do processo do negócio, por exemplo
um modelo dimensional único para tratar de dados de pedidos, em vez de criar um
modelo dimensional para um departamento de venda, de marketing, que desejam ambos
acessar dados de pedidos;
2. declare o grão (nível de detalhes) do processo de negócio, declarar o grão significa
especificar exatamente o que uma linha da tabela de fatos representa, um exemplo é a
posição diária dos níveis de estoque de cada produto no Data Mart;
3. escolha as dimensões que se aplicam a cada linha da tabela de fatos, quando não há
dúvidas a respeito do grão, geralmente as dimensões podem ser identificadas facilmente;
4. identifique os fatos numéricos que preencherão cada linha da tabela de fatos, o interesse
é analisar as medidas de desempenho do processo de negócio, todos os fatos candidatos
em um projeto devem ser verdadeiros para o grão definido na etapa da declaração do
grão e fatos típicos são valores numéricos aditivos, como quantidade vendida ou valor de
custo;
5. retornar as tabelas de dimensão e preencher os atributos da dimensão com descrições
completas e terminologia apropriada;
6. fazer a carga das tabelas de dimensão, neste ponto a tabela de fatos está completa, os
papéis das tabelas de dimensão são fornecer entradas para a tabela de fatos diretamente
de atributos dimensionais;
7. preparar dimensões para suportar evoluções (mudanças);
21
8. definir a amplitude de tempo do histórico do banco de dados, ou seja, a duração do
banco de dados; e
9. definir o espaço de tempo com que os dados devem ser extraídos e carregados no DW.
22
3. DESENVOLVIMENTO
3.1. A EMPRESA
A Figura 10 mostra a Distribuidora Müller Comércio e Representações Ltda, empresa na
qual onde o projeto foi desenvolvido. Atuando no setor atacadista desde 06 de setembro de 1967,
em Itajaí – SC, seu atendimento abrange toda Santa Catarina e algumas cidades do Rio Grande do
Sul e Paraná. A Distribuidora Müller Ltda é uma das maiores Empresas do Estado no ramo da
distribuição de gêneros alimentícios e a 49a no Ranking Nacional do setor atacadista 2004,
conforme ABAD (Associação Brasileira dos Atacadistas e Distribuidores), encontrando-se entre as
dez maiores empresas do município (ABAD, 2004).
Figura 10. Distribuidora Muller Ltda
Fonte: ABAD (2004)
O principal canal de negócios da empresa é o comércio e a distribuição de mercadorias no
segmento alimentício, produtos de papelaria, higiene pessoal, limpeza, pilhas, lanternas, produtos
para sorveteria, entre outros.
Conforme a ABAD, os tipos de atacadistas no país, são classificados de acordo com a forma
principal de atendimento que oferecem aos clientes e podem ser:
1. atacadista distribuidor: possui equipes de vendas que atende um número elevado de
clientes com freqüência determinada, faz entregas com frota própria ou de terceiros.
Chega a trabalhar com 6.000 itens diferentes e suas vendas, de modo geral, são feitas a
prazo;
2. atacadista de auto-serviço: tem como principal apelo de venda o baixo preço, em geral
suas vendas são despojadas, a mercadoria é oferecida nas embalagens de embarque
23
originais ou em embalagens menores preparadas pela indústria ou pelo próprio
atacadista. O cliente leva suas compras, em geral feitas à vista; e
3. atacadista de balcão: tem uma equipe de vendedores internos preparados para atender
aos clientes que visitam esse tipo de estabelecimento.
A empresa em questão atua nas duas últimas classificações, atacadista de auto-serviço e de
balcão, sendo que o foco deste trabalho se encontra no departamento de vendas da organização, que
é dividido de acordo com tipo de venda e o atendimento efetuado, sendo todas as vendas registradas
no sistema transacional da empresa:
1. venda varejo (loja): É a venda direta ao cliente, que escolhe seus produtos na loja, com
acesso direto aos vendedores que estão à disposição para atender;
2. venda por pedido (externa): A empresa possui vendedores que atendem os clientes.
Neste tipo de venda o vendedor atende o cliente e envia o pedido através de palmtops,
com conexão via Internet ou 0800. Inicialmente, eram utilizados palmtops HP LX 200 e
a partir do ano de 2002 foram substituídos pelos handhelds HP Jornada 548, 568 e Hp
iPAQ h1915. Alguns pedidos que possuem negociações diferenciadas de preços, ainda
são enviados via fax; e
3. telemarketing: A empresa possui uma equipe de atendentes que recebe os pedidos
realizados por telefone. Além disso, esses atendentes também ligam para os clientes que
o sistema transacional da empresa identifique que estão um determinado tempo sem
realizar compras, possibilitando um incremento no relacionamento com o cliente.
A empresa tem um sistema de transação on-line (OLTP), que auxilia o setor de compras,
vendas e o financeiro. Sendo que o foco deste trabalho está no setor de vendas, por ser de grande
importância para empresa e pela carência de informações, principalmente devido ao fato de os
dados estarem distribuidos no sistema atual, em base de dados Oracle, e no sistema legado, em base
de dados Dataflex.
O sistema atual foi adquirido há um ano e possui padrões e modelagens diferenciadas do
sistema legado, de desenvolvimento interno. Fica clara a necessidade de uma ferramenta, que
apresente as informações consolidadas a gerência de vendas e aos dirigentes da empresa, de modo a
permitir uma análise flexível, sob demanda e mais apurada no decorrer do tempo, possibilitando a
24
análise de dados de 5 anos de vendas e não de apenas poucos meses, de modo a melhor subsidiar a
tomada de decisão.
3.2. APLICAÇÃO DA ABORDAGEM ADAPTATIVA DO SAD
Foi aplicada a abordagem adaptativa proposta por Binder (1994), metodologia composta por
cinco passos:
1. primeiro e segundo passos – preparação do ambiente e identificação dos requisitos de
informação para a tomada de decisão: baseada em reuniões com a gerencia do
departamento de vendas, consultor externo e os responsáveis pela futura aplicação no
departamento de informática. As diversas reuniões objetivaram avaliar necessidades,
expor possíveis soluções e metodologias e conscientizar da importância do envolvimento
de todos no processo de análise e desenvolvimento do sistema. Neste passo
identificaram-se necessidades de informação e problemas de fontes e integrações de
dados, pois com a mudança do ERP (Enterprise Resource Planning - Sistema Integrado
de Gestão Empresarial), os anos anteriores de informação encontram-se em sistema
desenvolvido internamente (pelo departamento de informática) baseado em Dataflex e
somente os últimos meses estão disponíveis em sistema adquirido externamente e
baseado em tecnologia Oracle. Ambos os sistemas utilizam padrões diferentes para
codificação e estruturação da informação, evidenciando a necessidade de integração;
2. terceiro passo – desenvolvimento de um protótipo do SAD evolutivo: após identificação
da área de vendas como processo do negócio e das informações que a organização
necessita para servir de apoio à decisões, foi feita a especificação do sistema utilizando a
metodologia de análise estruturada e a ferramenta Power Designer. A carga dos dados da
base operacional para o banco de dados do DW e o desenvolvimento da ferramenta
OLAP, seguindo uma arquitetura ROLAP (OLAP relacional), são baseados no uso da
ferramenta Oracle Discoverer e banco de dados Oracle (com o desenvolvimento de
Stored Procedures);
3. quarto passo – avaliação do protótipo: após a implantação e testes no sistema, devem
ser realizadas avaliações junto com a gerência de vendas, de modo a identificar se as
informações e sua forma de apresentação atendem às necessidades dos usuários; e
4. quinto passo - implementação de novas melhorias: conforme necessidades do usuário.
25
3.3. APLICAÇÃO DAS ETAPAS PARA CONTRUÇÃO DO DW
Neste tópico é apresentada a aplicação das etapas para construção do Data Warehouse,
propostas por Kimball e Ross (2002).
1. primeira etapa - seleção do processo do negócio a ser modelado: com base nas maiores
necessidades da empresa e de sua atividade fim, foi escolhido entre os processos de
negócio a área de vendas;
2. segunda etapa – declaração do grão do processo de negócio: foi escolhido que a
granularidade ou nível de detalhes forneça valores de vendas por produto, embalagem,
cliente, dia, condição e forma de pagamento, tipo de venda e representante;
3. terceira etapa – escolha das dimensões: as dimensões definidas foram produto,
embalagem, cliente, dia, condição e forma de pagamento, tipo de venda e representante;
4. quarta etapa – identificação dos fatos: com a finalidade de analisar as medidas de
desempenho das vendas foi escolhido a quantidade de vendas e valor total da venda;
5. quinta etapa – preenchimento dos atributos nas dimensões: com base nas reuniões foram
definidos os atributos mais relevantes para cada uma das dimensões. Estes atributos
podem ser verificados no modelo da Figura 12;
6. sexta etapa – preenchendo as tabelas de dimensão: esta etapa suporta os processos de
ETL, sendo extraídos os dados das bases operacionais (Dataflex e Oracle) para as tabelas
da base dimensional. Na fase de ETL, os dados são filtrados, combinados e
padronizados, para então serem carregados para as dimensões do Data Mart;
7. sétima etapa – preparar dimensões para suportar mudanças: definição de uma política
de carga de produtos que sofreram alterações em volume de embalagem ou outras
características que possam influenciar em alguma reação do mercado consumidor;
8. oitava etapa – escolha da duração do banco de dados: com base em reunião com a
gerencia de vendas, definiu-se que o período do banco de dados é de cinco anos; e
9. nona etapa – definir espaço de tempo de extração e carga de dados: os dados serão
extraídos e carregados diariamente em processo agendado no sistema operacional do
servidor, em horário noturno.
26
3.4. ESPECIFICAÇÃO
A análise da aplicação é desenvolvida com o auxílio de algumas das ferramentas de
modelagem de sistemas descritas por Yourdon (1990), como:
1. diagrama de contexto: é um caso especial do diagrama de fluxo de dados, no qual uma
única bolha representa o sistema inteiro;
2. diagrama de fluxo de dados (DFD): mostra as funções que o sistema deve executar, que
entradas são transformadas em que saídas, onde obtém a informação e para onde remete
os resultados;
3. diagrama de entidade e relacionamento (DER): mostra em detalhes que informação está
contida em cada depósito de dados e também que relacionamentos existem entre os
depósitos de dados; e
4. dicionário de dados: é uma listagem organizada de todos os elementos de dados
pertinentes ao sistema.
Para a modelagem de dados, do modelo lógico ao físico, foi utilizada a ferramenta case
Oracle Designer. A engenharia reversa de ambas as bases operacionais (Dataflex e Oracle) também
foi feita no Oracle Designer.
Para a modelagem de processos foi utilizada a ferramenta Power Designer. O Power
Designer tem uma forma de modelagem integrada que oferece uma maneira de adequar o tamanho e
abrangência dos projetos. O módulo ProcessAnalyst foi utilizado na especificação do protótipo por
oferecer a modelagem de fluxo de dados (SYBASE, 2003). O diagrama de contexto é apresentado
na Figura 11.
27
Figura 11. Diagrama de Contexto
O DER físico e lógico do modelo dimensional é apresentado na Figura 12 e 13, bem como
as suas dimensões e atributos.
Figura 12. DER Lógico da Base Dimensional
28
Figura 13. DER Físico da Base Dimensional
O dicionário de dados do modelo dimensional é apresentado nas Tabelas de 1 a 9.
Tabela 1. Tabela da dimensão cliente
Descrição Atributo Tipo PK FK Seqüência de Cliente SQ_CLIENTE NUMERIC(8) Sim Não Nome do Cliente NM_CLIENTE VARCHAR(40) Não Não Ramo de Atividade DS_ATIVIDADE VARCHAR(30) Não Não Nome da Cidade NM_ CIDADE VARCHAR(40) Não Não Nome do Bairro NM_ BAIRRO VARCHAR(30) Não Não Sigla do Estado SG_UF VARCHAR(2) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
Tabela 2. Tabela da dimensão forma de pagamento
Descrição Atributo Tipo PK FK Seqüência de Forma SQ_FORMA NUMERIC(3) Sim Não Nome da Forma NM_FORMA VARCHAR(30) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
29
Tabela 3. Tabela da dimensão condição de pagamento
Descrição Atributo Tipo PK FK Seqüência de Condição SQ_CONDICAO NUMERIC(3) Sim Não Descrição da Condição DS_CONDICAO VARCHAR(30) Não Não Nº de Dias da Condição NR_NRO_DIAS NUMBER(3) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
Tabela 4. Tabela da dimensão tipo de venda
Descrição Atributo Tipo PK FK Seqüência tipo de venda SQ_TIPO_VENDA NUMERIC(2) Sim Não Descrição tipo de venda DS_TIPO_VENDA VARCHAR(40) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
Tabela 5. Tabela da dimensão embalagem
Descrição Atributo Tipo PK FK Seqüência da família SQ_FAMILIA NUMERIC(6) Sim Não Unidades da embalagem QT_UND_EMBALAGEM NUMBER(12,6) Sim Não Nome da embalagem NM_EMBALAGEM VARCHAR(2) Não Não Peso Bruto QT_PESO_BRUTO NUMBER(7,3) Não Não Peso Líquido QT_PESO_LIQUIDO NUMBER(7,3) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
Tabela 6. Tabela da dimensão vendedor / representante
Descrição Atributo Tipo PK FK Seqüência do vendedor SQ_VENDEDOR NUMERIC(5) Sim Não Nome do vendedor NM_VENDEDOR VARCHAR(40) Não Não Nome da região NM_REGIAO VARCHAR(40) Não Não Nome da cidade NM_CIDADE VARCHAR(40) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
Tabela 7. Tabela da dimensão produto
Descrição Atributo Tipo PK FK Seqüência de Produto SQ_PRODUTO NUMERIC(6) Sim Não Nome da Categoria NM_CATEGORIA VARCHAR(30) Sim Não Seqüência da Família SQ_FAMILIA NUMERIC(6) Não Não Nome do Produto NM_PRODUTO VARCHAR(50) Não Não Nome do Fornecedor NM_FORNECEDOR VARCHAR(40) Não Não Nome da Marca NM_MARCA VARCHAR(25) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
30
Tabela 8. Tabela da dimensão tempo
Descrição Atributo Tipo PK FK Data de Venda DT_VENDA DATE Sim Não Dia NR_DIA NUMBER(2) Não Não Mês NR_MÊS NUMBER(2) Não Não Ano NR_ANO NUMBER(4) Não Não Dia da Semana NM_DIA_SEMANA VARCHAR(10) Não Não Semana do Mês NR_SEMANA NUMBER(2) Não Não Bimestre NR_BIMESTRE NUMBER(1) Não Não Semestre NR_SEMESTRE NUMBER(1) Não Não Feriado NM_FERIADO VARCHAR(40) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
Tabela 9. Tabela de Fato Venda
Descrição Atributo Tipo PK FK Seqüência de Condição SQ_CONDICAO NUMERIC(3) Sim Sim Seqüência de Forma SQ_FORMA NUMERIC(3) Sim Sim Seqüência de Cliente SQ_CLIENTE NUMERIC(8) Sim Sim Seqüência Tipo de Venda SQ_TIPO_VENDA NUMERIC(2) Sim Sim Seqüência de Vendedor SQ_VENDEDOR NUMERIC(5) Sim Sim Data de Venda DT_VENDA DATE Sim Sim Seqüência de Produto SQ_PRODUTO NUMERIC(6) Sim Sim Nome da Categoria NM_CATEGORIA VARCHAR2(6) Sim Sim Seqüência da Família SQ_FAMILIA NUMERIC(6) Sim Sim Qtdd de Unidades / Embalagem QT_UND_EMBALAGEM NUMERIC(12,6) Sim Sim Identificação Venda/Devolução ID_ENTRADA_SAIDA CHAR(1) Sim Não Quantidade de Produtos QT_PRODUTO NUMERIC(12,3) Não Não Valor de Venda VL_VENDA NUMERIC(10,2) Não Não Número do Documento NR_DOC NUMERIC(6) Não Não Tipo do Documento NM_TIPO_DOC VARCHAR(3) Não Não Data da Última Atualização DT_ULT_ATU DATE Não Não
O sistema de Data Mart de Vendas, possui, basicamente, dois processos, ETL e Ferramenta
OLAP, representados na Figura 14.
31
Figura 14. DFD dos processos ETL e Ferramenta OLAP
32
3.5. IMPLEMENTAÇÃO
3.5.1. ETL
A etapa de ETL (Extração Transformação e Limpeza) do sistema é sua parte central, mais
importante e mais complexa. Consiste na realização de busca dos dados em suas fontes e sua
consolição para popular a base de dados do Data Warehouse. O ETL do sistema foi implementada
através dos seguintes passos:
1. criação de um banco de dados Oracle auxiliar (esquema1 DATAFLEX) para receber
dados dos arquivos de textos extraídos da base Dataflex, com estrutura equivalente aos
dados a serem extraídos dos arquivos texto;
2. retorno do backup da base de dados Dataflex;
3. desenvolvimento de Package através do aplicativo DFQuery 3.1d, para extrair os dados
relevantes da base Dataflex, gerando arquivos de texto. O código fonte de um destes
procedimentos de extração é apresentado no Apêndice 1;
4. desenvolvimento de procedimento de banco de dados (Stored Procedure) criado no
Servidor de Banco de Dados Oracle para leitura dos arquivos texto e gravação dos dados
nas tabelas no esquema DATAFLEX do banco de dados Oracle. O código fonte do
procedimento PRC_CARGA_DATAFLEX encontra-se no Apêndice 2. A Figura 15
demonstra que a carga dos 4 anos de dados (Notas Fiscais, Itens de Notas Fiscais,
Clientes, Representantes, Produtos, entre outros) do Dataflex para o banco de dados
auxiliar no Oracle, foi processada em, aproximadamente, 1 hora e 40 minutos;
1 Um esquema é um conjunto de objetos de um banco de dados Oracle que são de propriedade e desenvolvimento de um
usuário específico. Para melhor identificação e padronização, todos os nomes de esquemas serão apresentados neste
trabalho totalmente em letras maiúsculas.
33
Figura 15. Execução do Processo de Carga dos Dados do Dataflex para o Oracle.
5. criação das tabelas do Data Warehouse no esquema DW na instância (novo banco de
dados) DW_MULLER, em servidor de banco de dados exclusivo para esta aplicação;
6. criação de Database Links (conexões entre bancos de dados remotos) no esquema DW
na instância DW_MULLER para poder acessar dados dos outros dois bancos de dados;
7. desenvolvimento de procedimento de banco de dados (Stored Procedure) criado no
Servidor de Banco de Dados Oracle para carregar e tratar os dados da base transacional
Oracle (CONSINCO), carregando os dados iniciais para o banco de dados
DW_MULLER. O código fonte do procedimento PRC_CARGA_MODELO_ESTRELA
encontra-se no Apêndice 3. Foram identificadas diversas falhas de cadastro,
encaminhadas para correção aos responsáveis até os dados carregados para o modelo
dimensional estarem consistentes. A Figura 16 demonstra que a carga inicial (1 ano de
dados) da base da CONSINCO, foi processada em, aproximadamente, 37 minutos;
34
Figura 16. Execução do Processo PRC_CARGA_MODELO_ESTRELA.
8. desenvolvimento de procedimento de banco de dados no Servidor de Banco de Dados
Oracle para carregar e tratar os dados do banco DATAFLEX, carregando tais dados uma
única vez para o banco de dados DW_MULLER. O código fonte do procedimento
PRC_CARGA_DATAFLEX_ESTRELA encontra-se no Apêndice 4. Foram
identificadas diversas inconsistências de cadastros (em clientes, produto e embalagens),
que tornaram necessário buscar informações aos dados de notas fiscais impressas (no
arquivo morto) para que as informações coletadas estivessem íntegras e carregados para
o modelo dimensional de forma consistente. A Figura 17 demonstra que a carga inicial
de 4 anos de dados (Notas Fiscais, Itens de Notas Fiscais, Clientes, Representantes,
Produtos, entre outros) da base de dados oriunda do Dataflex, foi processada em,
aproximadamente, 1 hora e 20 minutos (com as chaves estrangeiras desligadas para
acerto posterior das inconsistências previamente mencionadas. Tais chaves foram
reabilitadas gradativamente após o acerto da base anterior); e
Figura 17. Execução do Processo PRC_CARGA_DATAFLEX_ESTRELA.
35
9. desenvolvimento de procedimento de banco de dados criado no Servidor de Banco de
Dados Oracle para carga incremental dos dados diariamente acrescidos à base
transacional CONSINCO para o banco de dados DW_MULLER. O código fonte do
procedimento PRC_CARGA_INCREMENTAL encontra-se no Apêndice 5. A Figura 18
demonstra que a carga incremental (movimento e inclusão diária de Notas Fiscais, Itens
de Notas Fiscais, Clientes, Representantes, Produtos, entre outros) obtidos da base
transacional CONSINCO, é processada em, aproximadamente, 2 minutos.
Figura 18. Execução do Processo PRC_CARGA_INCREMENTAL.
Os procedimentos PRC_CARGA_MODELO_ESTRELA e
PRC_CARGA_DATAFLEX_ESTRELA foram executados uma única vez para fazer a carga inicial
de dados de ambos os bancos, do sistema CONSINCO e do sistema antigo. O procedimento
PRC_CARGA_INCREMENTAL foi agendado através do processo de agendamento de tarefas no
sistema operacional, que dispara o processo de banco de dados Oracle, de modo a ser executado
diariamente, em processo noturno, tornando disponível a informação analítica aos tomadores de
decisão gerada pelo movimento de vendas até o dia anterior. A opção pelo agendamento via sistema
operacional se deu em função de bugs identificados nos procedimentos de agendamento interno ao
banco de dados Oracle.
Em suma, o processo de cargas iniciais de dados do Dataflex (com geração de arquivo texto
do backup extraído do servidor SERBACKUP) e do Oracle (CONSINCO – no servidor
SERORACLE) é realizado populando a base de dados no servidor de DW (servidor SERVDW). O
fluxo do processo, bem como a localização de seus componentes está representada na Figura 19. A
36
carga inicial (incluindo dados oriundos da base Dataflex e Oracle) gerou uma base de 2Gb
(10.598.241 Itens de Venda, 31.143 Clientes, 15.656 Produtos e 1.523 Datas).
Figura 19. Resumo do processo de carga inicial para a base do DW
A elaboração da etapa ETL deste sistema foi aquela que além de demandar mais tempo foi a
que exigiu maior pesquisa e esforço computacional e de análise, tanto no desenvolvimento de
processos de banco de dados, como na compreenção dos mecanismos e possibilidades de integração
de ambas as bases de dados e identificação de problemas e erros de cadastro.
SERBACKUP
configuração
Pentium III Dual 800 MHz 1 GB de RAM Disco SCSI 30 GB S. O.: Linux Conectiva 5.1 Dataflex df3.1d
SERORACLE
configuração Pentium III Dual 1.2 GHz 2 GB de RAM Disco 2 SCSI 36 GB (1 com o SO e outro Oracle) S.O.: Linux SUSE 8.1 B.D. Oracle 9i
Restauração do backup dofaturamento da base de dadosDataflex das fitas para oservidor SERBACKUP.
Arquivos texto com os dados do Dataflex transferidos para o
Servidor Oracle Carga dos dados dos arquivos textos do Dataflex para o
banco de dados Oracle
SERVDW
configuração
Pentium IV 2.8 GHz 2 GB de RAM Disco de 160 GB Windows 2000 Server B.D.: Oracle 9i
ETL: Carga e integração dos dados
do Dataflex e do Oracle para a base
DW.
1
3
Execução de procedimentos para criação de arquivos texto no servidor SERBACKUP,
baseados na base restaurada do
Dataflex.2
4
5
Carga diária dos
novos dados
(incremental).
6
37
Pode-se observar que toda a estratégia de ETL deste trabalho foi baseada no uso da
linguagem PL/SQL2 (Program Language with SQL) ao invés do uso de soluções baseadas em
mecanismos (ferramentas patenteadas utilizadas em projetos de DW para a finalidade de ETL). Tal
escolha foi embasada no custo de desenvolvimento do projeto, visto que o PL/SQL vem
incorporado ao banco de dados Oracle, não gerando custos adicionais, ao contrário da adoção de um
produto de terceiros ou da própria Oracle (como o Oracle Warehouse Builder (OWB) ou o Ardent
Data Stage da Informix).
3.5.2. Ferramenta OLAP
Inicialmente, na fase de projeto, havia sido definida como solução OLAP, o
desenvolvimento de uma ferramenta através da linguagem visual de programação Borland Delphi 7,
com o uso do componente Decision Cube para a construção dos cubos e do componente DB-
Express para a conexão ao banco de dados.
No entanto, tal acesso, por não ser nativo, tornava-se lento e os recursos disponibilizados
pelo componente Decision Cube, não tornavam a aplicação muito prática (pouca flexibilidade para
o usuário final na realização de operações OLAP padrão, inexistência de camada lógica para os
dados – tendo esta que ser desenvolvida de forma estática dentro da aplicação, impressão e geração
de gráfico não estava diretamente baseada no cubo previamente gerado, demandando tempo extra
de desenvolvimento e lentidão de acesso ao usuário).
Após tais verificações, a ferramenta OLAP escolhida para o projeto foi o Oracle
Discoverer, devido às suas funcionalidades de servidor OLAP, cliente Desktop e cliente Web, que
se apresenta como um ambiente visual profissional de construção, disponibilização e acesso de uma
estrutura de modelo estrela de dados do Data Mart de Vendas. Além disso, o acesso ao banco de
dados Oracle através do Oracle Discoverer é nativo, o que permite ganho de performance
exponencial.
Esta ferramenta é considerada, pelos especialistas e na literatura, como uma ferramenta
flexivel e de fácil utilização (todos os componentes possuem assistentes e tutoriais, além do help,
2 PL/SQL é uma linguagem procedural que é parte integrante do banco de dados Oracle e considerada em diversas
literaturas (FANDERUFF, 2003; COREY, 2001), uma ferramenta poderosa e flexível para manipulação e integração de
dados.
38
para facilitar sua utilização) e integração tecnológica com outras ferramentas de desenvolvimento
Oracle e Microsoft (principalmente Excel – ferramenta com a qual a área de vendas e financeira, em
geral, está bastante acostumada) (MACHADO, 2000; COREY, 2001; FANDERUFF, 2004). O fato
de a empresa já possuir o banco de dados Oracle facilita a aquisição de solução OLAP coorporativa
integrada, mesmo com o alto custo da ferramenta, o custo x benefício justifica sua aquisição. A
estrutura de componentes da ferramenta Oracle Discoverer é apresentada na Figura 20.
Os cubos de decisão são criados no componente de administração da ferramenta (Oracle
Discoverer Administrator), representando uma base de dados multidimensional, através da qual os
dados são recuperados utilizando-se declarações SQL fornecidas pelos componentes internos (de
forma transparente ao usuário final). Os itens recebem nomes significativos para os usuários,
mascarando os nomes padronizados para campos definidos no banco de dados, além de possibilitar
que determinados itens fiquem indisponíveis e que sejam criadas fórmulas, condições, hierarquias e
listas de valores.
O componente Administrator trabalha com a idéia de End User Layers (EUL – Camada de
Usuário Final), uma camada intermediária que permite ao usuário final transparência em relação a
complexidade de banco de dados. Neste componente são criadas as Business Áreas (Áreas de
Trabalho), que equivalem, individualmente, aos Data Marts da organização (MACHADO, 2000;
FANDERUFF, 2004).
39
Figura 20. Estrutura (Componentes) da Ferramenta Oracle Discoverer
Fonte: Fanderuff (2004)
Os componentes do lado cliente (Desktop, Plus e Viewer) permitem o acesso aos dados em
um formato especial, que permite que eles sejam trabalhados de maneira analítica, através de
pivoteamentos (rotacionar ou observar informações de ângulos diferentes) ou drills (detalhamento
das informações), alterando a organização dos dados sem a necessidade de realização de repetidas
consultas. Os componentes Desktop e Plus permitem a construçãoo de consultas ad-hoc, bem como
as operações OLAP, com base no modelo disponibilizado pela ferramenta de administração. O
componente Viewer permite apenas a manipulação, através de operações OLAP de consultas
previamente criadas e disponibilizadas através dos componentes Desktop ou Plus (MACHADO,
2000; COREY, 2001; FANDERUFF, 2004).
No Oracle Discoverer Administrator, foi desenvolvida a Business Area “Vendas Muller”,
para a qual foram selecionadas as tabelas do modelo dimensional do esquema DW do banco de
dados. Uma vez criada a Business Area e selecionadas as tabelas que a compõem, partiu-se para a
40
identificação dos itens que não estarão visíveis (estes aparecem em cor cinza na árvore de objetos
da Business Area) ao usuário e a nomenclatura pela qual os itens serão conhecidos pelo usuário
final da aplicação, como demonstrado na Figura 21.
Figura 21. Business Area “Vendas Muller” no componente Oracle Discoverer Administrator
Após disponibilizar tal estrutura para o usuário, algumas consultas OLAP foram construídas
e disponibilizadas ao usuário. Estas consultas padrão foram identificadas na fase de entrevistas e
estão elencadas a seguir:
• Vendas por Ramo de Atividade / Estado
• Vendas por Cidade / Estado
• Vendas por Região / Cidade
• Vendas por Produto de Fornecedores
• Evolução das Vendas por Vendedor no Decorrer de um Ano
41
Para construir as consultas ad-hoc, com a ferramenta Discoverer Desktop, pode-se fazer uso
do auxílio disponibilizado pelos tutoriais, que permite construir, passo a passo, tais consultas. A
Figura 22 apresenta a seleção dos dados disponibilizados no componente servidor (Administrator)
para construção de uma consulta.
Figura 22. Seleção dos itens desejados dentre os itens disponíveis na Business Area
A Figura 23 apresenta a elaboração do layout de apresentação dos dados previamente
selecionados. Neste momento é possível definir os dados que serão linhas, colunas, hierarquias,
células calculáveis e itens de página (estes últimos utilizados para o fatiamento – slice-dice – dos
dados). Na Figura 23 está apresentado um layout em que os dados são apresentados, tendo como
linhas os Estados (UF) dos Clientes, com quebra por Ramo de Atividade, as colunas são os meses
do ano referente à fatia do cubo que se seleciona no item de página.
42
Figura 23. Constrtução do layout da consulta (linhas, colunas, células e itens de página)
A Figura 24 apresenta a construção de uma condição de filtragem simples, indicando que
apenas dados referentes a anos posteriores a 2002 serão selecionados. A ferramenta permite a
construção de inúmeras condições, simples e compostas, para uma mesma consulta.
Figura 24. Definição de condições de seleção de dados
43
A Figura 25 apresenta a consulta de quantidade e valor total vendido por mês, no ano de
2004, para cada Ramo de Atividade de clientes de cada Estado, para os quais houve venda.
Figura 25. Consulta com seus itens já formatados
A Figura 26 apresenta a consulta “Valor Total de Venda – Região / Cidade x Mês”, no ano
de 2004, com destaque nas cidades e meses em que a venda mensal for inferior a R$ 50.000,00.
44
Figura 26. Consulta “Valor Total de Venda – Região / Cidade x Mês”
As Figuras 27 e 28 mostram os gráficos “Valor Total de Venda na Região Litoral”, no ano
de 2004 e “Valor Total de Venda por Forma de Pagto”, no ano de 2000 respectivamente.
45
Figura 27. Gráfico “Valor Total de Venda na Região Litoral”
Figura 28. Gráfico “Valor Total de Venda por Forma de Pagto”
46
A estrutura multi camada final desenvolvida neste projeto de apoio à decisão, baseado em
tecnologia de Data Mart, implantado na empresa foco desta pesquisa, a Distribuidora Muller, está
representada na Figura 29.
Figura 29. Estrutura multi-camada do DW desenvolvido para Distribuidora Muller Ltda
Fonte: Adaptado de Fanderuff (2004)
47
4. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Em um primeiro momento foi importante a distinção entre Data Warehouse e Data Mart,
sendo que o primeiro é um grande container de dados por assunto e o segundo um subconjunto do
primeiro, isto é, o Data Mart são pequenos Data Warehouse departamentais, sendo que o fator
principal para a definição da escolha de sua construção é o foco e não o tamanho.
Neste projeto foi desenvolvido o Data Mart que tem como foco o departamento de vendas
de uma empresa do setor atacadista/distribuidor, pois é neste setor que se encontram as maiores
necessidades de obtenção de informações para análise gerenciais.
Atendendo ao primeiro objetivo específico, de levantar as necessidades de informação do
departamento de vendas, na etapa de concepção e modelagem do Data Mart foi de essencial
importância as entrevistas e reuniões com as gerências, diretores, setor de informática e outros
envolvidos direta ou indiretamente no processo decisório. Tais encontros foram realizados para
detectar e extrair todas as informações realmente necessária e úteis, de modo a não honerar ou
deixar incompleto o conjunto de informações gerenciais disponíveis para análise e utilização no
processo decisório.
O objetivo específico referente ao desenvolvimento do modelo multidimensional para o
Data Mart de vendas (dimensões, fato, medidas, granularidade, historicidade, entre outros),
conseguiu ser atingido após as entrevistas e reuniões com as pessoas envolvidas no projeto.
Dentre as etapas de concepção, contrução e implantação do Data Mart, a etapa de ETL
(envolvendo os objetivos específicos de desenvolvimento do processo de ETL da base transacional
do sistema ERP anterior (Dataflex) e da base transacional atual (Oracle)) foi a mais problemática. O
apêndice 6 mostra um exemplo de sql para converter os dados referente ao código do produto do
sistema anterior para o atual. A realização da extração, a partir de uma base de dados operacional e
de sistemas legados exige profundo conhecimento da forma de armazenamento das informações
necessárias, bem como a forma possível de integrá-las, através do uso de ferramentas adequadas de
acesso aos dados. O processo de ETL dos dados derivados de bancos de dados diferentes, apresenta
um grande aumento de complexidade, principalmente na correlação entre os dados dos bancos
integrados no Data Mart. Esta é a parte mais crítica do projeto, onde as informações de diferentes
48
bancos de dados, devem ser filtradas de forma correta e consistente para que o resultado a ser
disponibilizado para análise não seja deturpado.
O objetivo específico de implementação da ferramenta OLAP (lado servidor) do Data Mart
foi atingido com a modelagem, na ferramenta Oracle Discoverer Administrator, dos dados,
cruzamentos e operações disponibilizados aos usuários finais.
O objetivo específico de disponibilizar interface para consultas ad hoc, relatórios e gráficos,
informações relevantes a tomada de decisão gerencial em vendas, através de ferramenta OLAP
(lado cliente) foi atingido através da disponibilização para determinados usuários das informações
previamente modeladas, cruzadas e tratadas, através das ferramentas Oracle Discoverer Desktop,
Plus e Viewer. As ferramentas utilizadas pelo usuário final em um projeto de tal porte devem ser as
mais ágeis e flexíveis, para que as informações a serem buscadas e analisadas retornem de forma
rápida e precisa, além de possibilitar a visualização destas informações de várias formas.
O objetivo geral foi atingido, com o desenvolvimento, de forma geral, do Sistema de
Informação de Data Mart de vendas no atacado e o início da utilização do mesmo pelos principais
usuários identificados no início deste trabalho, otimizando o aproveitamento de recursos humanos,
informacionais e tecnológicos para o departamento de vendas da Distribuidora Muller Ltda.
No entanto, a partir da conclusão do presente trabalho surgem algumas novas possibilidades
que podem ser exploradas no futuro. Dentre essas oportunidades destacam-se:
• Disponibilidade, via Web, do sistema para um maior número de usuários;
• Integrar novos Data Marts, como o de compras e o financeiro, incrementando as
estrutura de suporte à decisão da empresa; e
• Incorporação de novas medidas (indicadores) ao Data Mart já desenvolvido, como
rentabilidade, positivação, ticket médio, lucratividade, inadimplência, ranking de
vendas, entre outros.
Em suma, o projeto tem caráter de protótipo dentro da cultura gerencial, e contribuio para a fusão
da teoria e prática, bem como possibilitou um maior aprendizado das ferramentas e técnicas
utilizadas no projeto. Como o valor da informação tende a sofrer mutações, no que diz respeito
principalmente a relevância, com o passar do tempo, este sistema tende a ser dinâmico, sofrendo
49
modificações e adaptações constantes, tornando-se necessárias, portanto, repetidas avaliações para
que o sistema permaneça relevante e confiável para o setor gerencial da organização.
50
REFERÊNCIAS BIBLIOGRÁFICAS
ABAD – Associação Brasileira de Atacadistas e Distribuidores. Site da ABAD. <http://www.abad.com.br/> Acesso em: 12 nov. 2003, mai. 2004.
BINDER, Fábio Vinícius. Sistemas de apoio à decisão. São Paulo: Érica, 1994.
CANTÙ, Marco. Dominando o Delphi 6 - A Bíblia São Paulo: Pearson Makron Books, 2002.
CARVALHO, Faiçal de. Programação Orientada a Objetos Usando o Delphi 3. São Paulo: Érica, 1998.
CECHINEL, Cristine e SILVA JR, Ovídio Felippe Pereira da. Sistema de Informação Gerencial para Suporte do Balanced Scorecard da Cecpas Empreendimentos Imobiliários Ltda. Trabalho de Conclusão de Curso em Ciências da Computação na Universidade do Vale do Itajaí (Univale) – Itajaí - SC: 2003.
COREY, Michael et al. Oracle 8i data warehouse. Rio de Janeiro: Campus, 2001.
DATE, C. J. Introdução a Sistemas de Bancos de Dados. Tradução da 7ª Ed. Americana. Rio de Janeiro. Ed. Campus, 2000.
DW Brasil. <http://www.dwbrasil.com.br/> Acesso em: 11 jul. 2004.
FANDERUFF, Damaris. Dominando o Oracle 9i: modelagem e desenvolvimento. São Paulo: Pearson, 2003.
____________________ Oracle Discoverer: Aferramenta OLAP da Oracle. Revista SQL Magazine, nº 15. São Paulo: Neofício, nov/2004.
INMON, William H. Como construir o data warehouse. Tradução de Ana Maria Netto Cruz. Rio de Janeiro: Campus, 1997. 388 p.
KIMBALL, Ralph. Data warehouse toolkit. Tradução de Mônica Rosemberg. São Paulo: Makron Books, 1998. 388 p.
KIMBALL, Ralph; ROSS, Margy. The data warehouse tookit. 2. ed. Rio de Janeiro: Campus, 2002. 494 p.
LAUDON, Kenneth C; LAUDON, Jane Price. Sistemas de informação. Tradução Dalton Conde de Alencar. Rio de Janeiro: LTC, 1999.
MAZZOLA, Jailson e SILVA JR, Ovídio Felippe Pereira da. Sistema de Apoio a Decisão para Área Comercial da Empresa Buettner S. A. Indústria e Comércio. Trabalho de Conclusão de Curso em Ciências da Computação na Universidade do Vale do Itajaí (Univale) – Itajaí - SC: 2003.
MACHADO, Felipe Nery Rodrigues. Projeto de Data Warehouse: Uma Visão Multidimensional. São Paulo: Érica, 2000.
51
O’BRIEN, James A. Sistema de informações e as decisões gerenciais na era da internet. São Paulo: Saraiva, 2003.
OLIVEIRA, Adelize Generini de. Data warehouse: conceitos e soluções. Florianópolis: Advanced, 1998. 96 p.
OLIVEIRA, Djalma de Pinho Rebouças de. Sistemas de informações gerenciais. 8. ed. São Paulo: Atlas, 2002. 285 p.
REZENDE, Denis Alcides; ABREU, Aline França de. Tecnologia da informação aplicada a sistema de informação empresariais: o papel estratégico da informação e dos sistemas de informação nas empresas. São Paulo: Atlas, 2001.
SILVA JR, Ovídio Felippe Pereira da e ABREU, Aline França de. Avaliando os Sistemas de Informações Executivas nos Processos Decisórios das Instituições Universitárias Brasileiras. Dissertação de Mestrado. Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina (PPGEP/UFSC), Florianópolis, 2000.
SINGH, Harry S. Data warehouse: conceitos, tecnologias, implementação e gerenciamento. São Paulo: Makron Books, 2001.
STAIR, Ralph M. Princípios de sistemas de informação: uma abordagem gerencial. 2. ed. Rio de Janeiro: LTC, 1999.
Sybase Brasil. <http://www.sybase.com.br/imprensa/noticiasanteriores.jsp> Acesso em: 11 nov. 2003.
YOURDON, E. Análise Estrutura Moderna. Editora Campus-Série Yourdon Press, 1990.
52
APÊNDICE 1 – FONTE PRC_CARGA_ARQUIVO_TEXTO
// // 27/07/2004 08:54:44 // // DISTRIBUIDORA MULLER LTDA // // Package generated by DFQuery 3.1d Use QryRpt /DW_ITENF01_Body Resident _@______;_@______.;_@__.;_@______;_@______.;_@______.__;_@____________.__;_@__.__;_@____________.____;_@__.__;_@____________.____;_@____________.__;_@____________.__;_@________.__;_@________.__;_@____________________________________________________________;_@__/__/____;_@__/__/____;_@____.;_@____.;_@______.;_@______.;_@______;_@___;_@____;_@______.;_@______;_@________;_@______.;_@____________.__ /* /DW_ITENF01_Selection_Form Select records by: INDCAN not equal to _ /DW_ITENF01_Selection_Client ╔════════════════════════════════════════════════════════════════════════════╗ ║ DISTRIBUIDORA MULLER LTDA ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚════════════════════════════════════════════════════════════════════════════╝ /* Open FAA019 Open FAA020 Activate_View Activate_DW_ITENF01_Report for DW_ITENF01_Report Object DW_ITENF01_Report is a Query_View No_Image Object Report is a Standard_Report Report_Main_File FAA020 Report_Index By RECNUM Set Constraint_Value 0 to "S" // FAA019.INDCAN NE Begin_Constraints Constrain FAA019.INDCAN NE (Constraint_Value(Current_Object,0)) End_Constraints Function Starting_Main_Report Returns Integer Local Integer Ret_Val Forward Get Starting_Main_Report to Ret_Val If Ret_Val Function_Return Ret_Val If (Page_End(Current_Object)) NE -2 Set Page_End to 0 End_Function Procedure_Section Body as DW_ITENF01_Body Forward Send Body
53
Print FAA020.SERNOT Print FAA020.NUMNOT Print FAA020.ITEM Print FAA020.INDOBS Print FAA020.CODITE Print FAA020.QTDVEN Print FAA020.VALUNI Print FAA020.PERDES Print FAA020.BASICM Print FAA020.ALIICM Print FAA020.VALICM Print FAA020.VALCOM Print FAA020.CUSMED Print FAA020.PESLIQUNI Print FAA020.PESBRUUNI //Print FAA020.OBSERV Print "OBS" Print FAA020.DATPED Print FAA020.DATNOT Print FAA020.CODFAM Print FAA020.CODGRU Print FAA020.CODREP Print FAA020.CODCLI Print FAA020.INDAUX Print FAA020.MES Print FAA020.ANO Print FAA020.CODSUP Print FAA020.INDDEV Print FAA020.PALM_TOP Print FAA020.CODNAT Print FAA020.CUSREA Output_Pagecheck DW_ITENF01_Body End_Procedure End_Object Object Selection_Client is a Query_Selection_Client DW_ITENF01_Selection_Client Set Output_Selection_State to True Object Selection_Form is a Query_Selection_Form DW_ITENF01_Selection_Form Item_List Repeat_Item 1 Times "" Send Next End_Item_List End_Object End_Object End_Object
54
APÊNDICE 2 – FONTE PRC_CARGA_DATAFLEX
CREATE OR REPLACE PRC_CARGA_DATAFLEX IS in_file UTL_FILE.File_Type; Linha varchar2(300); Posicao number(3); Anterior number(3); Registro number(3); Conteudo varchar2(100); Reg_Faa019 FAA019%RowType; -- Cabecalho de Notas Fiscais Reg_Faa020 FAA020%RowType; -- Itens de Notas Fiscais Reg_Faa005 FAA005%RowType; -- Cliente Reg_Cea005 CEA005%RowType; -- Produto Reg_Gea004 GEA004%RowType; -- Fornecedor Reg_Faa008 FAA008%RowType; -- Representante/Vendedor Reg_Cep000 CEP000%RowType; -- Municipios Reg_Faa007 FAA007%RowType; -- Supervisor/Regi?o Reg_Faa001 FAA001%RowType; -- Condigco de Pagamento Reg_Faa043 FAA043%RowType; -- Forma de Pagamento Reg_Faa002 FAA002%RowType; -- Tipo de Estabelecimento Reg_Cea002 CEA002%RowType; -- Grupo de Produto Reg_Cea001 CEA001%RowType; -- Familia de Produto BEGIN --------------------------------------------------------------------------- -- Carga das Familias de Produto => Origem Dataflex (1) --------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados das famílias de produtos delete from Cea001; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_cea001.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura da linha do arquivo Anterior := 0; Posicao := Instr(Linha, ';',1,1); -- Posicao do 1º ; que encerra o 1º campo -- Retorna o conteudo do campo que vai de uma posição após ; anterior -- ate uma posição antes do ; de encerramento Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Reg_Cea001.codfam := nvl(to_number(trim(Conteudo)),null); Reg_Cea001.nomfam := nvl(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1),null); -- Insere na tabela o conteudo do registro originado da linha do arquivo texto Insert into Cea001 (codfam, nomfam) Values (Reg_Cea001.codfam, Reg_Cea001.nomfam); Registro := Registro + 1; -- Confirma a transação a cada 100 registros inclusos If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN
55
-- Ao terminar de ler o arquivo texto, o processo é encerrado na -- excecao No_Data_Found (equivale a EOF) -- Aqui o arquivo e fechado e a transação pendente é confirmada UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Familias de Produto Processadas com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretorio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 1!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga dos Grupos de Produto => Origem Dataflex (2) ---------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Grupos de Produtos delete from Cea002; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_cea002.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura da linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; Anterior := 0; Posicao := Instr(Linha, ';',1,1); -- Posição do 1º ; que encerra o 1º campo -- Retorna o conteúdo do campo que vai de uma posição após o ; anterior -- até uma posiçãoo antes do ; de encerramento Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Reg_Cea002.codgru := nvl(to_number(trim(Conteudo)),null); Reg_Cea002.nomgru := nvl(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1),null); Insert into Cea002 (codgru, nomgru) Values (Reg_Cea002.codgru, Reg_Cea002.nomgru); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Grupos de Produto Processados com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 2!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga dos Tipos de Estabelecimento => Origem Dataflex (3)
56
---------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Tipos de Estabelecimento delete from Faa002; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_faa002.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo dos campos com base no separador ; Anterior := 0; Posicao := Instr(Linha, ';',1,1); -- Posicao do 1º ; que encerra o 1º campo -- Retorna o conteudo do campo que vai de uma posição após ; anterior -- ate uma posição antes do ; de encerramento Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Reg_Faa002.tipest := nvl(trim(Conteudo),null); Reg_Faa002.desest := nvl(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1),null); Insert into Faa002 (tipest, desest) Values (Reg_Faa002.tipest, Reg_Faa002.desest); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Tipos de Estabelecimento Processados com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 3!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga das Formas de Pagamento => Origem Dataflex (4) ---------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém as Formas de Pagto delete from Faa043; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_faa043.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 2 campos estão finalizados com ; For Campo in 1 .. 2 Loop -- Retorna a posição do ; que encerra cada campo Posicao := Instr(Linha, ';',1,Campo);
57
-- Conteúdo de cada campo que vai de uma posição após ; anterior -- até uma posição antes do ; de encerramento Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; -- Dependendo da posição o conteúdo irá para seu campo no registro Case Campo When 1 Then Reg_Faa043.codforpag := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Faa043.desforpag := trim(Conteudo); End Case; End Loop; -- O último campo vai de uma posição após o último ; até o tamanho da linha Reg_Faa043.Codtip := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Faa043 (codforpag, desforpag, codtip) Values (Reg_Faa043.codforpag, Reg_Faa043.desforpag, Reg_Faa043.codtip); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Formas de Pagamento Processadas com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 4!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; -------------------------------------------------------------------- -- Carga das Condigues de Pagamento => Origem Dataflex (5) -------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados das Condições de Pagto delete from Faa001; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_faa001.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 3 campos estão finalizados com ; For Campo in 1 .. 3 Loop Posicao := Instr(Linha, ';',1,Campo); -- Posição do ; que encerra o campo -- Conteúdo de cada campo que vai de uma posição após ; anterior -- até uma posição antes do ; de encerramento Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Faa001.codpag := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Faa001.despag := trim(Conteudo); When 3 Then Reg_Faa001.diaven := nvl(to_number(trim(Conteudo)),null); End Case; End Loop;
58
Reg_Faa001.Codpre := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Faa001 (codpag, despag, diaven, codpre) Values (Reg_Faa001.codpag, Reg_Faa001.despag, Reg_Faa001.diaven, Reg_Faa001.codpre); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Condições de Pagamento Processadas com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 5!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; -------------------------------------------------------------------- -- Carga dos Supervisores/Regico => Origem Dataflex (6) -------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Supervisores/Regiões delete from Faa007; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_faa007.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 3 campos estão finalizados com ; For Campo in 1 .. 3 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Faa007.codsup := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Faa007.nomsup := trim(Conteudo); When 3 Then Reg_Faa007.endsup := trim(Conteudo); End Case; End Loop; Reg_Faa007.Cepsup := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Faa007 (codsup, nomsup, endsup, cepsup) Values (Reg_Faa007.codsup, Reg_Faa007.nomsup, Reg_Faa007.endsup, Reg_Faa007.cepsup); Registro := Registro + 1; If Registro = 100 Then Commit;
59
Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Supervisores/Região Processados com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 6!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; -------------------------------------------------------------------- -- Carga dos Municmpios => Origem Dataflex (7) -------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Municipios delete from Cep000; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_cep000.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 4 campos estão finalizados com ; For Campo in 1 .. 4 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Cep000.cep := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Cep000.municipio := trim(Conteudo); When 3 Then Reg_Cep000.uf := trim(Conteudo); When 4 Then Reg_Cep000.numuf := nvl(to_number(trim(Conteudo)),null); End Case; End Loop; Reg_Cep000.Nomest := nvl(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1),null); Insert into Cep000 (cep, municipio, uf, numuf, nomest) Values (Reg_Cep000.cep, Reg_Cep000.municipio, Reg_Cep000.uf, Reg_Cep000.numuf, Reg_Cep000.nomest); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Municípios Processados com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN
60
Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 7!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; -------------------------------------------------------------------- -- Carga dos Representantes/Vendedores => Origem Dataflex (8) -------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto contém os dados dos Representantes/Vendedores delete from Faa008; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_faa008.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 4 campos estco finalizados com ; For Campo in 1 .. 4 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Faa008.codrep := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Faa008.nomrep := trim(Conteudo); When 3 Then Reg_Faa008.endrep := trim(Conteudo); When 4 Then Reg_Faa008.ceprep := nvl(to_number(trim(Conteudo)),null); End Case; End Loop; Reg_Faa008.Codsup := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Faa008 (codrep, nomrep, endrep, ceprep, codsup) Values (Reg_Faa008.codrep, Reg_Faa008.nomrep, Reg_Faa008.endrep, Reg_Faa008.ceprep, Reg_Faa008.codsup); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Representantes/Vendedores Processados com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 8!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END;
61
-------------------------------------------------------------------- -- Carga dos Fornecedores => Origem Dataflex (9) -------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Fornecedores delete from Gea004; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_gea004.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 6 campos estão finalizados com ; For Campo in 1 .. 6 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Gea004.codfor := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Gea004.nomfor := trim(Conteudo); When 3 Then Reg_Gea004.endfor := trim(Conteudo); When 4 Then Reg_Gea004.bairro := trim(Conteudo); When 5 Then Reg_Gea004.cepfor := nvl(to_number(trim(Conteudo)),null); When 6 Then Reg_Gea004.cgcfor := trim(Conteudo); End Case; End Loop; Reg_Gea004.Iefor := nvl(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1),null); Insert into Gea004 (codfor, nomfor, endfor, bairro, cepfor, cgcfor, iefor) Values (Reg_Gea004.codfor, Reg_Gea004.nomfor, Reg_Gea004.endfor, Reg_Gea004.bairro, Reg_Gea004.cepfor, Reg_Gea004.cgcfor, Reg_Gea004.iefor); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Arquivo Processado com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Fornecedores Processados com Sucesso!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 9!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga dos Produtos => Origem Dataflex (10) ---------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Produtos
62
delete from Cea005; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_cea005.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 6 campos estão finalizados com ; For Campo in 1 .. 6 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Cea005.codite := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Cea005.desite := trim(Conteudo); When 3 Then Reg_Cea005.codfam := nvl(to_number(trim(Conteudo)),null); When 4 Then Reg_Cea005.codgru := nvl(to_number(trim(Conteudo)),null); When 5 Then Reg_Cea005.codfor := nvl(to_number(trim(Conteudo)),null); When 6 Then Reg_Cea005.pesliqatc := nvl(to_number(trim(Conteudo)),null); End Case; End Loop; Reg_Cea005.Pesbruatc := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Cea005 (codite, desite, codfam, codgru, codfor, pesliqatc, pesbruatc) Values (Reg_Cea005.codite, Reg_Cea005.desite, Reg_Cea005.codfam, Reg_Cea005.codgru, Reg_Cea005.codfor, Reg_Cea005.pesliqatc, Reg_Cea005.pesbruatc); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Produtos Processado com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 10!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga dos Clientes => Origem Dataflex (11) ---------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Clientes delete from Faa005; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_faa005.txt', 'r'); Registro := 0;
63
Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 8 campos estão finalizados com ; For Campo in 1 .. 8 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Faa005.codcli := nvl(to_number(trim(Conteudo)),null); When 2 Then Reg_Faa005.nomcli := trim(Conteudo); When 3 Then Reg_Faa005.endcli := trim(Conteudo); When 4 Then Reg_Faa005.cepcli := nvl(to_number(trim(Conteudo)),null); When 5 Then Reg_Faa005.cgccli := trim(Conteudo); When 6 Then Reg_Faa005.iecli := trim(Conteudo); When 7 Then Reg_Faa005.tipest := trim(Conteudo); When 8 Then Reg_Faa005.fisjur := trim(Conteudo); End Case; End Loop; Reg_Faa005.Consinco := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Faa005 (codcli, nomcli, endcli, cepcli, cgccli, iecli, tipest, fisjur, consinco) Values (Reg_Faa005.codcli, Reg_Faa005.nomcli, Reg_Faa005.endcli, Reg_Faa005.cepcli, Reg_Faa005.cgccli, Reg_Faa005.iecli, Reg_Faa005.tipest, Reg_Faa005.fisjur, Reg_Faa005.consinco); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Clientes Processados com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 11!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga dos Cabegalhos de Notas Fiscais => Origem Dataflex (12) ---------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos cabeçalhos de NF delete from Faa019; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_faa019.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo Anterior := 0;
64
-- Busca do conteúdo de cada um dos campos com base no separador ; -- Os primeiros 39 campos estão finalizados com ; For Campo in 1 .. 39 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Faa019.sernot := trim(Conteudo); When 2 Then Reg_Faa019.numnot := nvl(to_number(trim(Conteudo)),null); When 3 Then Reg_Faa019.codcli := nvl(to_number(trim(Conteudo)),null); When 4 Then Reg_Faa019.codrep := nvl(to_number(trim(Conteudo)),null); When 5 Then Reg_Faa019.codpag := nvl(to_number(trim(Conteudo)),null); When 6 Then Reg_Faa019.codnat := nvl(to_number(trim(Conteudo)),null); When 7 Then Reg_Faa019.numped := nvl(to_number(trim(Conteudo)),null); When 8 Then Reg_Faa019.comped := nvl(to_number(trim(Conteudo)),null); When 9 Then If trim(Conteudo) is not null then Reg_Faa019.datemi := to_date(trim(Conteudo),'dd/mm/yyyy'); else Reg_Faa019.datemi := null; end if; When 10 Then If trim(Conteudo) is not null then Reg_Faa019.datsai := to_date(trim(Conteudo),'dd/mm/yyyy'); else Reg_Faa019.datsai := null; end if; When 11 Then Reg_Faa019.valnot := nvl(to_number(trim(Conteudo)),null); When 12 Then Reg_Faa019.valdes := nvl(to_number(trim(Conteudo)),null); When 13 Then Reg_Faa019.valacr := nvl(to_number(trim(Conteudo)),null); When 14 Then Reg_Faa019.desfin := nvl(to_number(trim(Conteudo)),null); When 15 Then If trim(Conteudo) is not null then Reg_Faa019.datdes := to_date(trim(Conteudo),'dd/mm/yyyy'); else Reg_Faa019.datdes := null; end if; When 16 Then Reg_Faa019.basicm1 := nvl(to_number(trim(Conteudo)),null); When 17 Then Reg_Faa019.basicm2 := nvl(to_number(trim(Conteudo)),null); When 18 Then Reg_Faa019.basicm3 := nvl(to_number(trim(Conteudo)),null); When 19 Then Reg_Faa019.aliicm := nvl(to_number(trim(Conteudo)),null); When 20 Then Reg_Faa019.valicm := nvl(to_number(trim(Conteudo)),null); When 21 Then Reg_Faa019.valdev := nvl(to_number(trim(Conteudo)),null); When 22 Then Reg_Faa019.indcan := trim(Conteudo); When 23 Then Reg_Faa019.valcom := nvl(to_number(trim(Conteudo)),null); When 24 Then Reg_Faa019.numlot := nvl(to_number(trim(Conteudo)),null); When 25 Then Reg_Faa019.numrom := nvl(to_number(trim(Conteudo)),null); When 26 Then Reg_Faa019.codtip := nvl(to_number(trim(Conteudo)),null); When 27 Then Reg_Faa019.valbon := nvl(to_number(trim(Conteudo)),null); When 28 Then Reg_Faa019.indrom := trim(Conteudo); When 29 Then Reg_Faa019.peso := nvl(to_number(trim(Conteudo)),null); When 30 Then Reg_Faa019.codmot := nvl(to_number(trim(Conteudo)),null); When 31 Then Reg_Faa019.codcon := nvl(to_number(trim(Conteudo)),null); When 32 Then Reg_Faa019.qtdite := nvl(to_number(trim(Conteudo)),null); When 33 Then Reg_Faa019.coddig := nvl(to_number(trim(Conteudo)),null); When 34 Then Reg_Faa019.clitmk := trim(Conteudo); When 35 Then Reg_Faa019.atcvar := trim(Conteudo); When 36 Then Reg_Faa019.codnat2 := nvl(to_number(trim(Conteudo)),null); When 37 Then Reg_Faa019.tiptab := nvl(to_number(trim(Conteudo)),null); When 38 Then Reg_Faa019.numtab := nvl(to_number(trim(Conteudo)),null); When 39 Then Reg_Faa019.codforpag := nvl(to_number(trim(Conteudo)),null); End Case; End Loop; Conteudo := substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1); If trim(Conteudo) is not null then Reg_Faa019.datexp := to_date(trim(Conteudo),'dd/mm/yyyy');
65
else Reg_Faa019.datexp := null; end if; Insert into Faa019 (sernot, numnot, codcli, codrep, codpag, codnat, numped, comped, datemi, datsai, valnot, valdes, valacr, desfin, datdes, basicm1, basicm2, basicm3, aliicm, valicm, valdev, indcan, valcom, numlot, numrom, codtip, valbon, indrom, peso, codmot, codcon, qtdite, coddig, clitmk, atcvar, codnat2, tiptab, numtab, codforpag, datexp) Values (Reg_Faa019.sernot, Reg_Faa019.numnot, Reg_Faa019.codcli, Reg_Faa019.codrep, Reg_Faa019.codpag, Reg_Faa019.codnat, Reg_Faa019.numped, Reg_Faa019.comped, Reg_Faa019.datemi, Reg_Faa019.datsai, Reg_Faa019.valnot, Reg_Faa019.valdes, Reg_Faa019.valacr, Reg_Faa019.desfin, Reg_Faa019.datdes, Reg_Faa019.basicm1, Reg_Faa019.basicm2, Reg_Faa019.basicm3, Reg_Faa019.aliicm, Reg_Faa019.valicm, Reg_Faa019.valdev, Reg_Faa019.indcan, Reg_Faa019.valcom, Reg_Faa019.numlot, Reg_Faa019.numrom, Reg_Faa019.codtip, Reg_Faa019.valbon, Reg_Faa019.indrom, Reg_Faa019.peso, Reg_Faa019.codmot, Reg_Faa019.codcon, Reg_Faa019.qtdite, Reg_Faa019.coddig, Reg_Faa019.clitmk, Reg_Faa019.atcvar, Reg_Faa019.codnat2, Reg_Faa019.tiptab, Reg_Faa019.numtab, Reg_Faa019.codforpag, Reg_Faa019.datexp); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Cabegalhos Processados com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 12!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga dos Itens de Notas Fiscais => Origem Dataflex (13) ---------------------------------------------------------------------------- BEGIN -- Abertura do arquivo texto que contém os dados dos Itens de NFs delete from Faa020; commit; in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_itenf01.txt', 'r'); Registro := 0; Loop UTL_FILE.Get_Line(in_file, Linha); -- Leitura de cada linha do arquivo
66
Anterior := 0; -- Busca do conteúdo de cada um dos campos com base no separad or ; -- Os primeiros 29 campos estão finalizados com ; For Campo in 1 .. 29 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Faa020.sernot := trim(Conteudo); When 2 Then Reg_Faa020.numnot := nvl(to_number(trim(Conteudo)),null); When 3 Then Reg_Faa020.item := nvl(to_number(trim(Conteudo)),null); When 4 Then Reg_Faa020.indobs := trim(Conteudo); When 5 Then Reg_Faa020.codite := nvl(to_number(trim(Conteudo)),null); When 6 Then Reg_Faa020.qtdven := nvl(to_number(trim(Conteudo)),null); When 7 Then Reg_Faa020.valuni := nvl(to_number(trim(Conteudo)),null); When 8 Then Reg_Faa020.perdes := nvl(to_number(trim(Conteudo)),null); When 9 Then Reg_Faa020.basicm := nvl(to_number(trim(Conteudo)),null); When 10 Then Reg_Faa020.aliicm := nvl(to_number(trim(Conteudo)),null); When 11 Then Reg_Faa020.valicm := nvl(to_number(trim(Conteudo)),null); When 12 Then Reg_Faa020.valcom := nvl(to_number(trim(Conteudo)),null); When 13 Then Reg_Faa020.cusmed := nvl(to_number(trim(Conteudo)),null); When 14 Then Reg_Faa020.pesliquni := nvl(to_number(trim(Conteudo)),null); When 15 Then Reg_Faa020.pesbruuni := nvl(to_number(trim(Conteudo)),null); When 16 Then Reg_Faa020.observ := trim(Conteudo); When 17 Then If trim(Conteudo) is not null then Reg_Faa020.datped := to_date(trim(Conteudo),'dd/mm/yyyy'); else Reg_Faa020.datped := null; end if; When 18 Then If trim(Conteudo) is not null then Reg_Faa020.datnot := to_date(trim(Conteudo),'dd/mm/yyyy'); else Reg_Faa020.datnot := null; end if; When 19 Then Reg_Faa020.codfam := nvl(to_number(trim(Conteudo)),null); When 20 Then Reg_Faa020.codgru := nvl(to_number(trim(Conteudo)),null); When 21 Then Reg_Faa020.codrep := nvl(to_number(trim(Conteudo)),null); When 22 Then Reg_Faa020.codcli := nvl(to_number(trim(Conteudo)),null); When 23 Then Reg_Faa020.indaux := trim(Conteudo); When 24 Then Reg_Faa020.mes := trim(Conteudo); When 25 Then Reg_Faa020.ano := trim(Conteudo); When 26 Then Reg_Faa020.codsup := nvl(to_number(trim(Conteudo)),null); When 27 Then Reg_Faa020.inddev := trim(Conteudo); When 28 Then Reg_Faa020.palm_top := trim(Conteudo); When 29 Then Reg_Faa020.codnat := nvl(to_number(trim(Conteudo)),null); End Case; End Loop; Reg_Faa020.CusRea := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Faa020 (sernot, numnot, item, indobs, codite, qtdven, valuni, perdes, basicm, aliicm, valicm, valcom, cusmed, pesliquni, pesbruuni, observ, datped, datnot, codfam, codgru, codrep, codcli, indaux, mes, ano, codsup, inddev, palm_top, codnat, cusrea) Values (Reg_Faa020.sernot, Reg_Faa020.numnot, Reg_Faa020.item, Reg_Faa020.indobs, Reg_Faa020.codite, Reg_Faa020.qtdven, Reg_Faa020.valuni, Reg_Faa020.perdes, Reg_Faa020.basicm, Reg_Faa020.aliicm, Reg_Faa020.valicm, Reg_Faa020.valcom, Reg_Faa020.cusmed, Reg_Faa020.pesliquni, Reg_Faa020.pesbruuni, Reg_Faa020.observ, Reg_Faa020.datped, Reg_Faa020.datnot, Reg_Faa020.codfam, Reg_Faa020.codgru,
67
Reg_Faa020.codrep, Reg_Faa020.codcli, Reg_Faa020.indaux, Reg_Faa020.mes, Reg_Faa020.ano, Reg_Faa020.codsup, Reg_Faa020.inddev, Reg_Faa020.palm_top, Reg_Faa020.codnat, Reg_Faa020.cusrea); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Arquivo de Itens Processado com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 13!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; ---------------------------------------------------------------------------- -- Carga dos Itens de Notas Fiscais => Origem Dataflex (14) ---------------------------------------------------------------------------- BEGIN -- Abertura do segundo arquivo texto que contém os dados dos Itens de NFs in_file := UTL_FILE.FOPEN('E:\DW_Texto\','dw_itenf02.txt', 'r'); Registro := 0; Loop -- Busca do conteúdo de cada um dos campos com base no separad or ; -- Os primeiros 29 campos estão finalizados com ; For Campo in 1 .. 29 Loop Posicao := Instr(Linha, ';',1,Campo); Conteudo := trim(substr(Linha, Anterior + 1, Posicao - Anterior - 1)); Anterior := Posicao; Case Campo When 1 Then Reg_Faa020.sernot := trim(Conteudo); When 2 Then Reg_Faa020.numnot := nvl(to_number(trim(Conteudo)),null); When 3 Then Reg_Faa020.item := nvl(to_number(trim(Conteudo)),null); When 4 Then Reg_Faa020.indobs := trim(Conteudo); When 5 Then Reg_Faa020.codite := nvl(to_number(trim(Conteudo)),null); When 6 Then Reg_Faa020.qtdven := nvl(to_number(trim(Conteudo)),null); When 7 Then Reg_Faa020.valuni := nvl(to_number(trim(Conteudo)),null); When 8 Then Reg_Faa020.perdes := nvl(to_number(trim(Conteudo)),null); When 9 Then Reg_Faa020.basicm := nvl(to_number(trim(Conteudo)),null); When 10 Then Reg_Faa020.aliicm := nvl(to_number(trim(Conteudo)),null); When 11 Then Reg_Faa020.valicm := nvl(to_number(trim(Conteudo)),null); When 12 Then Reg_Faa020.valcom := nvl(to_number(trim(Conteudo)),null); When 13 Then Reg_Faa020.cusmed := nvl(to_number(trim(Conteudo)),null); When 14 Then Reg_Faa020.pesliquni := nvl(to_number(trim(Conteudo)),null); When 15 Then Reg_Faa020.pesbruuni := nvl(to_number(trim(Conteudo)),null); When 16 Then Reg_Faa020.observ := trim(Conteudo); When 17 Then If trim(Conteudo) is not null then Reg_Faa020.datped := to_date(trim(Conteudo),'dd/mm/yyyy'); else Reg_Faa020.datped := null; end if; When 18 Then If trim(Conteudo) is not null then Reg_Faa020.datnot := to_date(trim(Conteudo),'dd/mm/yyyy'); else
68
Reg_Faa020.datnot := null; end if; When 19 Then Reg_Faa020.codfam := nvl(to_number(trim(Conteudo)),null); When 20 Then Reg_Faa020.codgru := nvl(to_number(trim(Conteudo)),null); When 21 Then Reg_Faa020.codrep := nvl(to_number(trim(Conteudo)),null); When 22 Then Reg_Faa020.codcli := nvl(to_number(trim(Conteudo)),null); When 23 Then Reg_Faa020.indaux := trim(Conteudo); When 24 Then Reg_Faa020.mes := trim(Conteudo); When 25 Then Reg_Faa020.ano := trim(Conteudo); When 26 Then Reg_Faa020.codsup := nvl(to_number(trim(Conteudo)),null); When 27 Then Reg_Faa020.inddev := trim(Conteudo); When 28 Then Reg_Faa020.palm_top := trim(Conteudo); When 29 Then Reg_Faa020.codnat := nvl(to_number(trim(Conteudo)),null); End Case; End Loop; Reg_Faa020.CusRea := nvl(to_number(substr(Linha, Anterior + 1, Length(Linha) - Anterior - 1)),null); Insert into Faa020 (sernot, numnot, item, indobs, codite, qtdven, valuni, perdes, basicm, aliicm, valicm, valcom, cusmed, pesliquni, pesbruuni, observ, datped, datnot, codfam, codgru, codrep, codcli, indaux, mes, ano, codsup, inddev, palm_top, codnat, cusrea) Values (Reg_Faa020.sernot, Reg_Faa020.numnot, Reg_Faa020.item, Reg_Faa020.indobs, Reg_Faa020.codite, Reg_Faa020.qtdven, Reg_Faa020.valuni, Reg_Faa020.perdes, Reg_Faa020.basicm, Reg_Faa020.aliicm, Reg_Faa020.valicm, Reg_Faa020.valcom, Reg_Faa020.cusmed, Reg_Faa020.pesliquni, Reg_Faa020.pesbruuni, Reg_Faa020.observ, Reg_Faa020.datped, Reg_Faa020.datnot, Reg_Faa020.codfam, Reg_Faa020.codgru, Reg_Faa020.codrep, Reg_Faa020.codcli, Reg_Faa020.indaux, Reg_Faa020.mes, Reg_Faa020.ano, Reg_Faa020.codsup, Reg_Faa020.inddev, Reg_Faa020.palm_top, Reg_Faa020.codnat, Reg_Faa020.cusrea); Registro := Registro + 1; If Registro = 100 Then Commit; Registro := 0; End If; End Loop; UTL_FILE.FCLOSE(in_file); EXCEPTION WHEN No_data_found THEN UTL_FILE.FCLOSE(in_file); Dbms_Output.Put_Line('Segundo Lote de Itens Processado com Sucesso!'); Commit; WHEN UTL_FILE.INVALID_PATH THEN Dbms_Output.Put_Line('Diretsrio Invalido!'); UTL_FILE.FCLOSE(in_file); WHEN Others THEN Dbms_Output.Put_Line('Problemas na Leitura do Arquivo 14!'); Dbms_Output.Put_Line(sqlerrm); UTL_FILE.FCLOSE(in_file); END; END PRC_CARGA_DATAFLEX;
69
APÊNDICE 3 – FONTE PRC_CARGA_MODELO_ESTRELA
CREATE OR REPLACE PROCEDURE "PRC_CARGA_MODELO_ESTRELA" IS BEGIN -- Limpar tabelas para a carga inicial execute immediate 'TRUNCATE TABLE DWD_FATO_VENDA'; DELETE FROM DWD_TEMPO; DELETE FROM DWD_PRODUTO; DELETE FROM DWD_EMBALAGEM; DELETE FROM DWD_TIPO_VENDA; DELETE FROM DWD_CONDICAO_PAGTO; DELETE FROM DWD_FORMA_PAGTO; DELETE FROM DWD_VENDEDOR; DELETE FROM DWD_CLIENTE; COMMIT; Begin -- Carga de Clientes do Sistema Consinco -- Clientes das NFs de Venda Insert Into DWD_CLIENTE (SQ_CLIENTE, NM_CLIENTE, DS_ATIVIDADE, NM_CIDADE, NM_BAIRRO, SQ_UF, DT_ULT_ATU) select distinct b.seqpessoa, b.nomerazao, b.atividade, b.cidade, b.bairro, b.uf, sysdate from mfl_doctofiscal a, ge_pessoa b where a.seqpessoa = b.seqpessoa; COMMIT; -- Clientes das NFs de Entrada / Devolução Insert Into DWD_CLIENTE (SQ_CLIENTE, NM_CLIENTE, DS_ATIVIDADE, NM_CIDADE, NM_BAIRRO, SQ_UF, DT_ULT_ATU) select distinct b.seqpessoa, b.nomerazao, b.atividade, b.cidade, b.bairro, b.uf, sysdate from mlf_notafiscal a, ge_pessoa b where a.seqpessoa = b.seqpessoa and not exists (select c.sq_cliente from DWD_CLIENTE c where c.SQ_CLIENTE = b.seqpessoa); COMMIT; End; Begin -- Carga de Representante/Vendedor do Sistema Consinco Insert Into DWD_VENDEDOR (SQ_VENDEDOR, NM_REGIAO, NM_VENDEDOR, NM_CIDADE, DT_ULT_ATU) select distinct b.nrorepresentante, d.descequipe, c.nomerazao, c.cidade, sysdate from mfl_doctofiscal a, mad_representante b, ge_pessoa c, mad_equipe d where a.seqvendedor = b.nrorepresentante
70
and b.seqpessoa = c.seqpessoa and b.nroequipe = d.nroequipe; COMMIT; End; Begin -- Carga de Forma de Pagamento do Sistema Consinco Insert Into DWD_FORMA_PAGTO (SQ_FORMA, DS_FORMA, DT_ULT_ATU) select a.nroformapagto, a.formapagto, sysdate from mrl_formapagto a; COMMIT; End; Begin -- Carga de Condição de Pagamento do Sistema Consinco Insert Into DWD_CONDICAO_PAGTO (SQ_CONDICAO, DS_CONDICAO, NR_NRO_DIAS, DT_ULT_ATU) select a.nrocondicaopagto, a.desccondicaopagto, a.nrodiavencto, sysdate from mad_condicaopagto a; COMMIT; End; Begin -- Carga de Tipo de Venda (Segmento) do Sistema Consinco Insert Into DWD_TIPO_VENDA (SQ_TIPO_VENDA, DS_TIPO_VENDA, DT_ULT_ATU) select a.nrosegmento, a.descsegmento, sysdate from mad_segmento a where a.nrosegmento <= 2; COMMIT; End; Begin -- Carga de Embalagem do Sistema Consinco Insert Into DWD_EMBALAGEM (SQ_FAMILIA, NM_EMBALAGEM, QT_UND_EMBALAGEM, QT_PESO_BRUTO, QT_PESO_LIQUIDO, DT_ULT_ATU) select a.seqfamilia, a.embalagem, a.qtdembalagem, a.pesobruto, a.pesoliquido, sysdate from map_famembalagem a, map_familia b, map_produto p where a.seqfamilia = b.seqfamilia and p.seqfamilia = b.seqfamilia group by a.seqfamilia, a.embalagem, a.qtdembalagem, a.pesobruto, a.pesoliquido, sysdate; COMMIT; End; Begin -- Carga de Produto do Atacado do Sistema Consinco Insert Into DWD_PRODUTO (SQ_PRODUTO, SQ_FAMILIA, NM_PRODUTO, NM_FORNECEDOR, NM_MARCA, NM_CATEGORIA, DT_ULT_ATU) select distinct a.seqproduto, a.seqfamilia, a.desccompleta, c.nomerazao, e.marca, g.categoria, sysdate from map_produto a, map_famfornec b, ge_pessoa c, map_familia d, map_marca e, map_famdivcateg f, map_categoria g, map_famdivisao h where a.seqfamilia = d.seqfamilia
71
and b.seqfamilia = d.seqfamilia and b.principal = 'S' and b.seqfornecedor = c.seqpessoa and d.seqmarca = e.seqmarca and d.seqfamilia = h.seqfamilia and h.seqfamilia = f.seqfamilia and h.nrodivisao = f.nrodivisao and f.seqcategoria = g.seqcategoria and f.nrodivisao = g.nrodivisao and g.nivelhierarquia = 1 and g.tipcategoria = 'M' and g.categoria != ('LIXEIRA') and g.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607); COMMIT; End; Begin -- Carga Tempo de NF de Saída Insert Into DWD_TEMPO (DT_VENDA, NR_DIA, NR_MES, NR_ANO, NM_DIA_SEMANA, NR_SEMANA, NR_BIMESTRE, NR_SEMESTRE, DT_ULT_ATU) select distinct TRUNC(v.dtahoremissao) DATAVENDA, EXTRACT(DAY FROM v.dtahoremissao) DIADATA, EXTRACT(MONTH FROM v.dtahoremissao) MESDATA, EXTRACT(YEAR FROM v.dtahoremissao) ANODATA, TO_CHAR(v.dtahoremissao,'DAY') DIASEMANADATA, TO_NUMBER(TO_CHAR(v.dtahoremissao,'WW')) SEMANADATA, CEIL(TO_NUMBER(TO_CHAR(v.dtahoremissao,'MM')) / 2) BIMESTREDATA, CEIL(TO_NUMBER(TO_CHAR(v.dtahoremissao,'MM')) / 6) SEMESTREDATA, sysdate from mfl_doctofiscal v; COMMIT; End; Begin -- Carga de Tempo das NFs de Entrada / Devolução Insert Into DWD_TEMPO (DT_VENDA, NR_DIA, NR_MES, NR_ANO, NM_DIA_SEMANA, NR_SEMANA, NR_BIMESTRE, NR_SEMESTRE, DT_ULT_ATU) select distinct TRUNC(v.dtaemissao) DATAVENDA, EXTRACT(DAY FROM v.dtaemissao) DIADATA, EXTRACT(MONTH FROM v.dtaemissao) MESDATA, EXTRACT(YEAR FROM v.dtaemissao) ANODATA, TO_CHAR(v.dtaemissao,'DAY') DIASEMANADATA, TO_NUMBER(TO_CHAR(v.dtaemissao,'WW')) SEMANADATA, CEIL(TO_NUMBER(TO_CHAR(v.dtaemissao,'MM')) / 2) BIMESTREDATA, CEIL(TO_NUMBER(TO_CHAR(v.dtaemissao,'MM')) / 6) SEMESTREDATA, sysdate from mlf_notafiscal v where not exists (Select 1 From DWD_TEMPO t Where t.dt_venda = TRUNC(v.dtaemissao)); COMMIT; End; Begin -- Carga de NF de Saida do Sistema Consinco da Empresa-1 (Atacado) Insert Into DWD_FATO_VENDA (SQ_CLIENTE, SQ_FORMA, SQ_CONDICAO, SQ_TIPO_VENDA, SQ_VENDEDOR, DT_VENDA,
72
SQ_PRODUTO, ID_ENTRADA_SAIDA, NM_CATEGORIA, SQ_FAMILIA, QT_UND_EMBALAGEM, QT_PRODUTO, VL_VENDA, NR_DOC, NM_TIPO_DOC, DT_ULT_ATU) select v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, v.seqvendedor, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, sum(x.quantidade), sum(x.vlritem), v.numerodf, v.seriedf, sysdate from mfl_dfitem x, mfl_doctofiscal v, mad_representante r, map_produto p, map_categoria m, map_famdivcateg n, map_famembalagem k, map_famdivisao a, map_familia f where v.nroempresa = 1 and v.statusdf != 'C' and v.nroempresa = x.nroempresa and v.numerodf = x.numerodf and v.seriedf = x.seriedf and v.nroserieecf = x.nroserieecf and v.seqvendedor = r.nrorepresentante and x.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and x.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 1 and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.categoria != 'LIXEIRA' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) group by v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, v.seqvendedor, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, v.numerodf, v.seriedf, sysdate; COMMIT; End; Begin -- Carga de NF de Saida do Sistema Consinco da Empresa-2 (Autoserviço) Insert Into DWD_FATO_VENDA (SQ_CLIENTE, SQ_FORMA, SQ_CONDICAO, SQ_TIPO_VENDA, SQ_VENDEDOR, DT_VENDA, SQ_PRODUTO, ID_ENTRADA_SAIDA, NM_CATEGORIA, SQ_FAMILIA, QT_UND_EMBALAGEM, QT_PRODUTO, VL_VENDA, NR_DOC, NM_TIPO_DOC, DT_ULT_ATU) select v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa,
73
9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, sum(x.quantidade), sum(x.vlritem), v.numerodf, v.seriedf, sysdate from mfl_dfitem x, mfl_doctofiscal v, map_produto p, map_categoria m, map_famdivcateg n, map_famembalagem k, map_famdivisao a, map_familia f where v.nroempresa = 2 and v.seriedf != 'CF' and v.statusdf != 'C' and v.nroempresa = x.nroempresa and v.numerodf = x.numerodf and v.seriedf = x.seriedf and v.nroserieecf = x.nroserieecf and x.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and x.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 2 and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.categoria != 'LIXEIRA' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) group by v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, 9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, v.numerodf, v.seriedf, sysdate; COMMIT; End; Begin -- Carga de Cupom Fiscal de Saida do Sistema Consinco da Empresa-2 (Autoserviço) Insert Into DWD_FATO_VENDA (SQ_CLIENTE, SQ_FORMA, SQ_CONDICAO, SQ_TIPO_VENDA, SQ_VENDEDOR, DT_VENDA, SQ_PRODUTO, ID_ENTRADA_SAIDA, NM_CATEGORIA, SQ_FAMILIA, QT_UND_EMBALAGEM, QT_PRODUTO, VL_VENDA, NR_DOC, NM_TIPO_DOC, DT_ULT_ATU) select v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, 9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, sum(x.quantidade), sum(x.vlritem), v.numerodf, v.nrocheckout||'S'|| substr(v.nroserieecf, 9, 1), sysdate from mfl_dfitem x,
74
mfl_doctofiscal v, map_produto p, map_categoria m, map_famdivcateg n, map_famembalagem k, map_famdivisao a, map_familia f where v.nroempresa = 2 and v.seriedf = 'CF' and v.statusdf != 'C' and v.nroempresa = x.nroempresa and v.numerodf = x.numerodf and v.seriedf = x.seriedf and v.nroserieecf = x.nroserieecf and x.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and x.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 2 and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.categoria != 'LIXEIRA' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) group by v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, 9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, v.numerodf, v.nrocheckout||'S'|| substr(v.nroserieecf, 9, 1), sysdate; COMMIT; End; ----------------------- ----------------------- Begin -- Carga de NF de Entrada/Devolução do Sistema Consinco da Empresa-1 (Atacado) Insert Into DWD_FATO_VENDA (SQ_CLIENTE, SQ_FORMA, SQ_CONDICAO, SQ_TIPO_VENDA, SQ_VENDEDOR, DT_VENDA, SQ_PRODUTO, ID_ENTRADA_SAIDA, NM_CATEGORIA, SQ_FAMILIA, QT_UND_EMBALAGEM, QT_PRODUTO, VL_VENDA, NR_DOC, NM_TIPO_DOC, DT_ULT_ATU) select vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, v.seqvendedor, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, sum(xd.quantidade), sum(xd.vlritem), vd.numeronf, vd.serienf, sysdate from mfl_doctofiscal v, mlf_notafiscal vd, mlf_nfitem xd,
75
mad_representante r, map_produto p, map_categoria m, map_famdivcateg n, map_famembalagem k, map_famdivisao a, map_familia f where vd.nroempresa = 1 and vd.statusnf != 'C' and vd.numeronf = xd.numeronf and vd.seqpessoa = xd.seqpessoa and vd.serienf = xd.serienf and vd.tipnotafiscal = xd.tipnotafiscal and vd.nroempresa = xd.nroempresa and v.nroempresa = vd.nroempresa and v.numerodf = vd.nfreferencianro and v.seriedf = vd.nfreferenciaserie and v.nroserieecf = 'NF' and v.cfop in (5102, 6102) and xd.cfop in (1202, 2202, 1411, 2411) and v.seqvendedor = r.nrorepresentante and xd.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and xd.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and m.nrodivisao = 1 and n.status != 'I' and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.categoria != 'LIXEIRA' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) group by vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, v.seqvendedor, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, vd.numeronf, vd.serienf, sysdate; COMMIT; End; Begin -- Carga de NF de Entrada/Devolução do Sistema Consinco da Empresa-2 (Autoserviço) Insert Into DWD_FATO_VENDA (SQ_CLIENTE, SQ_FORMA, SQ_CONDICAO, SQ_TIPO_VENDA, SQ_VENDEDOR, DT_VENDA, SQ_PRODUTO, ID_ENTRADA_SAIDA, NM_CATEGORIA, SQ_FAMILIA, QT_UND_EMBALAGEM, QT_PRODUTO, VL_VENDA, NR_DOC, NM_TIPO_DOC, DT_ULT_ATU) select vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, 9000, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, sum(xd.quantidade), sum(xd.vlritem), vd.numeronf, vd.serienf, sysdate
76
from mfl_doctofiscal v, mlf_notafiscal vd, mlf_nfitem xd, map_produto p, map_categoria m, map_famdivcateg n, map_famembalagem k, map_famdivisao a, map_familia f where vd.nroempresa = 2 and vd.statusnf != 'C' and vd.numeronf = xd.numeronf and vd.seqpessoa = xd.seqpessoa and vd.serienf = xd.serienf and vd.tipnotafiscal = xd.tipnotafiscal and vd.nroempresa = xd.nroempresa and v.nroempresa = vd.nroempresa and v.numerodf = vd.nfreferencianro and v.seriedf = vd.nfreferenciaserie and v.nroserieecf = 'NF' and v.cfop in (5102, 6102) and xd.cfop in (1202, 2202, 1411, 2411) and xd.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and xd.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 2 and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.categoria != 'LIXEIRA' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) group by vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, 9000, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, vd.numeronf, vd.serienf, sysdate; COMMIT; End; END PRC_CARGA_MODELO_ESTRELA;
77
APÊNDICE 4 – FONTE PRC_CARGA_DATAFLEX_ESTRELA
CREATE OR REPLACE PROCEDURE "PRC_CARGA_DATAFLEX_ESTRELA" IS Cursor Cur_Cliente Is select DISTINCT c.CODCLI + 300000 seqpessoa, TRIM(SUBSTR(c.NOMCLI,1,40)) nomerazao, a.DESEST atividade, l.MUNICIPIO cidade, TRIM(LPAD(c.ENDCLI, 30)) bairro, l.UF uf from DATAFLEX.FAA005 c, DATAFLEX.CEP000 l, DATAFLEX.FAA002 a, DATAFLEX.FAA019 v where c.CEPCLI = l.CEP and c.TIPEST = a.TIPEST and c.CODCLI = v.CODCLI and NOT EXISTS (Select 1 From GE_PESSOA@MULLER p2 Where c.CODCLI = p2.CODCLIENTEFORA And REPLACE(REPLACE(REPLACE(REPLACE( SUBSTR(TRIM(C.CGCCLI), 1, LENGTH(TRIM(C.CGCCLI))-2) ,'.',''),'/',''),'-',''),'_','')|| -- Nro do CGC/CPF SUBSTR(TRIM(C.CGCCLI), LENGTH(TRIM(C.CGCCLI))-1,2) -- Digito do GCG/CPF = p2.NROCGCCPF||p2.DIGCGCCPF); Cursor Cur_Vendedor Is select TO_NUMBER(RPAD(v.CODREP,5)) nrorepresentante, TRIM(SUBSTR(s.NOMSUP, 1, 40)) descequipe, TRIM(SUBSTR(v.NOMREP, 1, 40)) nomerazao, TRIM(SUBSTR(l.MUNICIPIO,1,40)) cidade from DATAFLEX.FAA008 v, DATAFLEX.FAA007 s, DATAFLEX.CEP000 l where v.CEPREP = l.CEP and v.CODSUP = s.CODSUP and v.CODREP not in (select sq_vendedor from dwd_vendedor); Cursor Cur_Forma Is select CODFORPAG + 900 nroformapagto, DESFORPAG formapagto from DATAFLEX.FAA043; Cursor Cur_Condicao Is select CODPAG + 900 nrocondicaopagto, DESPAG desccondicaopagto, DIAVEN nrodiavencto from DATAFLEX.FAA001; Cursor Cur_Embalagem Is select p.CODGRU seqfamilia, nvl(Trim(p.univar),'DS') embalagem, p.qtdvar qtdembalagem, max(p.PESLIQATC) pesoliquido, max(p.PESBRUATC) pesobruto from DATAFLEX.CEA005 p where not exists (select 1
78
from MAP_PRODCODIGO@muller mp where mp.codacesso = p.CODITE and mp.tipcodigo = 'A') and not exists (select 1 from DWD_EMBALAGEM eb where eb.sq_familia = p.CODGRU and eb.qt_und_embalagem = p.qtdvar) and p.CODGRU < 1901 group by p.CODGRU, p.univar, p.qtdvar; Cursor Cur_Produto Is select distinct p.CODITE + 300000 seqproduto, p.CODGRU seqfamilia, TRIM(SUBSTR(p.DESITE, 1, 50)) desccompleta, TRIM(SUBSTR(f.NOMFOR, 1, 40)) nomerazao, TRIM(SUBSTR(m.NOMFAM, 1, 25)) marca, TRIM(SUBSTR(c.NOMGRU, 1, 30)) categoria from DATAFLEX.CEA005 p, DATAFLEX.GEA004 f, DATAFLEX.CEA001 m, DATAFLEX.CEA002 c where p.CODFOR = f.CODFOR and p.CODFAM = m.CODFAM and p.CODGRU = c.CODGRU and not exists (select 1 from MAP_PRODCODIGO@muller mp where mp.codacesso = p.CODITE and mp.tipcodigo = 'A'); Cursor Cur_Tempo Is select distinct -- Tempo de NF TRUNC(c.datemi) DATAVENDA, EXTRACT(DAY FROM c.datemi) DIADATA, EXTRACT(MONTH FROM c.datemi) MESDATA, EXTRACT(YEAR FROM c.datemi) ANODATA, TO_CHAR(c.datemi,'DAY') DIASEMANADATA, TO_NUMBER(TO_CHAR(c.datemi,'WW')) SEMANADATA, CEIL(TO_NUMBER(TO_CHAR(c.datemi,'MM')) / 2) BIMESTREDATA, CEIL(TO_NUMBER(TO_CHAR(c.datemi,'MM')) / 6) SEMESTREDATA from DATAFLEX.FAA019 c where TRUNC(c.datemi) not in (Select Dt_Venda From Dwd_Tempo); Cursor Cur_Venda Is select v.CODCLI + 300000 seqpessoa, nvl(v.CODFORPAG, 1) + 900 nroformapagto, nvl(v.CODPAG, 1)+ 900 nrocondicaopagto, 1 nroempresa, TO_NUMBER(RPAD(v.CODREP,5)) seqvendedor, TRUNC(v.DATEMI) dtahoremissao, i.CODITE seqproduto, DECODE(v.SERNOT,'ENN','E','S') Tipo, TRIM(SUBSTR(ct.NOMGRU, 1, 30)) categoria, p.CODGRU seqfamilia, p.qtdvar qtdembalagem, sum(i.QTDVEN) Quantidade, sum((i.VALUNI * (1 - (i.PERDES / 100))) * i.QTDVEN) Valor, v.NUMNOT numerodf, v.SERNOT seriedf from DATAFLEX.FAA019 v, DATAFLEX.FAA020 i, DATAFLEX.FAA005 c, DATAFLEX.CEA005 p, DATAFLEX.CEA002 ct
79
where p.CODITE = i.CODITE and p.CODGRU = ct.CODGRU and v.CODCLI = c.CODCLI and v.NUMNOT = i.NUMNOT and v.SERNOT = i.SERNOT and NOT EXISTS (Select 1 From GE_PESSOA@MULLER p2 Where c.CODCLI = p2.CODCLIENTEFORA And REPLACE(REPLACE(REPLACE(REPLACE( SUBSTR(TRIM(C.CGCCLI), 1, LENGTH(TRIM(C.CGCCLI))-2) ,'.',''),'/',''),'-',''),'_','')|| -- Nro do CGC/CPF SUBSTR(TRIM(C.CGCCLI), LENGTH(TRIM(C.CGCCLI))-1,2) -- Digito do GCG/CPF = p2.NROCGCCPF||p2.DIGCGCCPF) group by v.CODCLI + 300000, nvl(v.CODFORPAG, 1), nvl(v.CODPAG, 1), 1, TO_NUMBER(RPAD(v.CODREP,5)), TRUNC(v.DATEMI), i.CODITE, DECODE(v.SERNOT,'ENN','E','S'), TRIM(SUBSTR(ct.NOMGRU, 1, 30)), p.CODGRU, p.qtdvar, v.NUMNOT, v.SERNOT UNION select v.CODCLI seqpessoa, nvl(v.CODFORPAG, 1) + 900 nroformapagto, nvl(v.CODPAG, 1)+ 900 nrocondicaopagto, 1 nroempresa, TO_NUMBER(RPAD(v.CODREP,5)) seqvendedor, TRUNC(v.DATEMI) dtahoremissao, i.CODITE seqproduto, DECODE(v.SERNOT,'ENN','E','S') Tipo, TRIM(SUBSTR(ct.NOMGRU, 1, 30)) categoria, p.CODGRU seqfamilia, p.qtdvar qtdembalagem, sum(i.QTDVEN) Quantidade, sum((i.VALUNI * (1 - (i.PERDES / 100))) * i.QTDVEN) Valor, v.NUMNOT numerodf, v.SERNOT seriedf from DATAFLEX.FAA019 v, DATAFLEX.FAA020 i, DATAFLEX.FAA005 c, DATAFLEX.CEA005 p, DATAFLEX.CEA002 ct where p.CODITE = i.CODITE and p.CODGRU = ct.CODGRU and v.CODCLI = c.CODCLI and v.NUMNOT = i.NUMNOT and v.SERNOT = i.SERNOT group by v.CODCLI, nvl(v.CODFORPAG, 1), nvl(v.CODPAG, 1), 1, TO_NUMBER(RPAD(v.CODREP,5)), TRUNC(v.DATEMI), i.CODITE, DECODE(v.SERNOT,'ENN','E','S'), TRIM(SUBSTR(ct.NOMGRU, 1, 30)), p.CODGRU, p.qtdvar, v.NUMNOT, v.SERNOT; Nr_registros Number(4); BEGIN Begin -- Carga de Clientes do Sistema Consinco For Reg_Cliente in Cur_Cliente Loop Insert Into DWD_CLIENTE (SQ_CLIENTE, NM_CLIENTE, DS_ATIVIDADE, NM_CIDADE, NM_BAIRRO, SQ_UF, DT_ULT_ATU) Values (Reg_Cliente.Seqpessoa, Reg_Cliente.nomerazao, Reg_Cliente.atividade, Reg_Cliente.cidade, Reg_Cliente.bairro, Reg_Cliente.Uf,
80
Sysdate); End Loop; COMMIT; End; Begin -- Carga de Representante/Vendedor do Sistema Consinco For Reg_Vendedor in Cur_Vendedor Loop Insert Into DWD_VENDEDOR (SQ_VENDEDOR, NM_REGIAO, NM_VENDEDOR, NM_CIDADE, DT_ULT_ATU) Values (Reg_Vendedor.nrorepresentante, Reg_Vendedor.descequipe, Reg_Vendedor.nomerazao, Reg_Vendedor.cidade, Sysdate); End Loop; COMMIT; End; Begin -- Carga de Forma de Pagamento do Sistema Consinco For Reg_Forma in Cur_Forma Loop Insert Into DWD_FORMA_PAGTO (SQ_FORMA, DS_FORMA, DT_ULT_ATU) Values (Reg_Forma.nroformapagto, Reg_Forma.formapagto, sysdate); End Loop; COMMIT; End; Begin -- Carga de Condigco de Pagamento do Sistema Consinco For Reg_Condicao in Cur_Condicao Loop Insert Into DWD_CONDICAO_PAGTO (SQ_CONDICAO, DS_CONDICAO, NR_NRO_DIAS, DT_ULT_ATU) Values (Reg_Condicao.nrocondicaopagto, Reg_Condicao.desccondicaopagto, Reg_Condicao.nrodiavencto, sysdate); End Loop; COMMIT; End; Begin -- Carga de Embalagem do Sistema Consinco For Reg_Embalagem in Cur_Embalagem Loop Insert Into DWD_EMBALAGEM (SQ_FAMILIA, NM_EMBALAGEM, QT_UND_EMBALAGEM, QT_PESO_BRUTO, QT_PESO_LIQUIDO, DT_ULT_ATU) Values (Reg_Embalagem.seqfamilia, Reg_Embalagem.embalagem, Reg_Embalagem.qtdembalagem, Reg_Embalagem.pesobruto, Reg_Embalagem.pesoliquido, Sysdate); End Loop; COMMIT; End; Begin -- Carga de Produto do Atacado do Sistema Consinco For Reg_Produto in Cur_Produto Loop Insert Into DWD_PRODUTO (SQ_PRODUTO, SQ_FAMILIA, NM_PRODUTO, NM_FORNECEDOR, NM_MARCA, NM_CATEGORIA, DT_ULT_ATU) Values
81
(Reg_Produto.seqproduto, Reg_Produto.seqfamilia, Reg_Produto.desccompleta, Reg_Produto.nomerazao, Reg_Produto.marca, Reg_Produto.categoria, Sysdate); End Loop; COMMIT; End; Begin -- Carga de Tempos de NFs For Reg_Tempo in Cur_Tempo Loop Insert Into DWD_TEMPO (DT_VENDA, NR_DIA, NR_MES, NR_ANO, NM_DIA_SEMANA, NR_SEMANA, NR_BIMESTRE, NR_SEMESTRE, DT_ULT_ATU) Values (Reg_Tempo.DATAVENDA, Reg_Tempo.DIADATA, Reg_Tempo.MESDATA, Reg_Tempo.ANODATA, Reg_Tempo.DIASEMANADATA, Reg_Tempo.SEMANADATA, Reg_Tempo.BIMESTREDATA, Reg_Tempo.SEMESTREDATA, Sysdate); End Loop; COMMIT; End; Nr_registros := 0; Begin -- Carga de NF; For Reg_Venda in Cur_Venda Loop Insert Into DWD_FATO_VENDA (SQ_CLIENTE, SQ_FORMA, SQ_CONDICAO, SQ_TIPO_VENDA, SQ_VENDEDOR, DT_VENDA, SQ_PRODUTO, ID_ENTRADA_SAIDA, NM_CATEGORIA, SQ_FAMILIA, QT_UND_EMBALAGEM, QT_PRODUTO, VL_VENDA, NR_DOC, NM_TIPO_DOC, DT_ULT_ATU) Values (Reg_Venda.seqpessoa, Reg_Venda.nroformapagto, Reg_Venda.nrocondicaopagto, Reg_Venda.nroempresa, Reg_Venda.seqvendedor, Reg_Venda.dtahoremissao, Reg_Venda.seqproduto, Reg_Venda.Tipo, Reg_Venda.categoria, Reg_Venda.seqfamilia, Reg_Venda.qtdembalagem, Reg_Venda.Quantidade, Reg_Venda.Valor, Reg_Venda.numerodf, Reg_Venda.seriedf, Sysdate); If Nr_registros > 1500 Then Nr_registros := 0; COMMIT; End If; End Loop; COMMIT; End; END PRC_CARGA_DATAFLEX_ESTRELA;
82
APÊNDICE 5 – FONTE PRC_CARGA_INCREMENTAL
CREATE OR REPLACE PROCEDURE "PRC_CARGA_INCREMENTAL" IS DT_BASE Date; Cursor Cur_Cliente (PDt_Base Date) Is select distinct -- Clientes das NFs de Venda b.seqpessoa, b.nomerazao, b.atividade, b.cidade, b.bairro, b.uf from mfl_doctofiscal@muller a, ge_pessoa@muller b where a.seqpessoa@muller = b.seqpessoa And TRUNC(a.dtahoremissao) >= PDt_Base And NOT EXISTS (Select 1 From DWD_CLIENTE dc Where dc.Sq_Cliente = b.seqpessoa) UNION select distinct -- Clientes das NFs de Entrada / Devolugco b.seqpessoa, b.nomerazao, b.atividade, b.cidade, b.bairro, b.uf from mlf_notafiscal@muller a, ge_pessoa@muller b where a.seqpessoa = b.seqpessoa And TRUNC(a.dtaemissao) >= PDt_Base And NOT EXISTS (Select 1 From DWD_CLIENTE dc Where dc.Sq_Cliente = b.seqpessoa); Cursor Cur_Vendedor (PDt_Base Date) Is select distinct b.nrorepresentante, d.descequipe, c.nomerazao, c.cidade from mfl_doctofiscal@muller a, mad_representante@muller b, ge_pessoa@muller c, mad_equipe@muller d where a.seqvendedor = b.nrorepresentante and b.seqpessoa = c.seqpessoa and b.nroequipe = d.nroequipe And TRUNC(a.dtahoremissao) >= PDt_Base And NOT EXISTS (Select 1 From DWD_VENDEDOR dv Where dv.Sq_Vendedor = b.nrorepresentante); Cursor Cur_Forma Is select a.nroformapagto, a.formapagto from mrl_formapagto@muller a Where NOT EXISTS (Select 1 From DWD_FORMA_PAGTO df Where df.Sq_Forma = a.nroformapagto); Cursor Cur_Condicao Is select a.nrocondicaopagto, a.desccondicaopagto, a.nrodiavencto from mad_condicaopagto@muller a Where NOT EXISTS (Select 1 From DWD_CONDICAO_PAGTO dc Where dc.Sq_Condicao = a.nrocondicaopagto); Cursor Cur_TpVenda Is select a.nrosegmento, a.descsegmento
83
from mad_segmento@muller a where a.nrosegmento <= 2 And NOT EXISTS (Select 1 From DWD_TIPO_VENDA dt Where dt.Sq_Tipo_Venda = a.nrosegmento); Cursor Cur_Embalagem Is select distinct a.seqfamilia, a.embalagem, a.qtdembalagem, a.pesobruto, a.pesoliquido from map_famembalagem@muller a, map_familia@muller b, map_produto@muller p where a.seqfamilia = b.seqfamilia and p.seqfamilia = b.seqfamilia And NOT EXISTS (Select 1 From DWD_EMBALAGEM de Where de.SQ_FAMILIA = a.seqfamilia And de.QT_UND_EMBALAGEM = a.qtdembalagem); Cursor Cur_Produto Is select distinct a.seqproduto, a.seqfamilia, a.desccompleta, c.nomerazao, e.marca, g.categoria from map_produto@muller a, map_famfornec@muller b, ge_pessoa@muller c, map_familia@muller d, map_marca@muller e, map_famdivcateg@muller f, map_categoria@muller g, map_famdivisao@muller h where a.seqfamilia = d.seqfamilia and b.seqfamilia = d.seqfamilia and b.principal = 'S' and b.seqfornecedor = c.seqpessoa and d.seqmarca = e.seqmarca and d.seqfamilia = h.seqfamilia and h.seqfamilia = f.seqfamilia and h.nrodivisao = f.nrodivisao and f.seqcategoria = g.seqcategoria and f.nrodivisao = g.nrodivisao and g.nivelhierarquia = 1 and g.tipcategoria = 'M' and g.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) And NOT EXISTS (Select 1 From DWD_PRODUTO dp Where dp.Sq_Produto = a.seqproduto); Cursor Cur_Tempo (PDt_Base Date) Is select distinct -- Tempo de NF de Samda TRUNC(v.dtahoremissao) DATAVENDA, EXTRACT(DAY FROM v.dtahoremissao) DIADATA, EXTRACT(MONTH FROM v.dtahoremissao) MESDATA, EXTRACT(YEAR FROM v.dtahoremissao) ANODATA, TO_CHAR(v.dtahoremissao,'DAY') DIASEMANADATA, TO_NUMBER(TO_CHAR(v.dtahoremissao,'WW')) SEMANADATA, CEIL(TO_NUMBER(TO_CHAR(v.dtahoremissao,'MM')) / 2) BIMESTREDATA, CEIL(TO_NUMBER(TO_CHAR(v.dtahoremissao,'MM')) / 6) SEMESTREDATA from mfl_doctofiscal@muller v Where TRUNC(v.dtahoremissao) >= PDt_Base And NOT EXISTS (Select 1 From DWD_TEMPO dt Where dt.dt_venda = TRUNC(v.dtahoremissao)) UNION select distinct -- Tempo das NFs de Entrada / Devolugco
84
TRUNC(v.dtaemissao) DATAVENDA, EXTRACT(DAY FROM v.dtaemissao) DIADATA, EXTRACT(MONTH FROM v.dtaemissao) MESDATA, EXTRACT(YEAR FROM v.dtaemissao) ANODATA, TO_CHAR(v.dtaemissao,'DAY') DIASEMANADATA, TO_NUMBER(TO_CHAR(v.dtaemissao,'WW')) SEMANADATA, CEIL(TO_NUMBER(TO_CHAR(v.dtaemissao,'MM')) / 2) BIMESTREDATA, CEIL(TO_NUMBER(TO_CHAR(v.dtaemissao,'MM')) / 6) SEMESTREDATA from mlf_notafiscal@muller v Where TRUNC(v.dtaemissao) >= PDt_Base And NOT EXISTS (Select 1 From DWD_TEMPO dt Where dt.dt_venda = TRUNC(v.dtahoremissao)); Cursor Cur_Venda (PDt_Base Date) Is select -- NF de Saida do Sistema Consinco da Empresa-1 (Atacado) v.seqpessoa, nvl(v.nroformapagto, 1) nroformapagto, nvl(v.nrocondicaopagto, 1) nrocondicaopagto, v.nroempresa, v.seqvendedor, TRUNC(v.dtahoremissao) dtahoremissao, x.seqproduto, 'S' Tipo, m.categoria, p.seqfamilia, x.qtdembalagem, sum(x.quantidade) Quantidade, sum(x.vlritem) Valor, v.numerodf, v.seriedf from mfl_dfitem@muller x, mfl_doctofiscal@muller v, mad_representante@muller r, map_produto@muller p, map_categoria@muller m, map_famdivcateg@muller n, map_famembalagem@muller k, map_famdivisao@muller a, map_familia@muller f where v.nroempresa = 1 and v.statusdf != 'C' --and trunc(v.dtahoremissao) < '01-oct-04' and v.nroempresa = x.nroempresa and v.numerodf = x.numerodf and v.seriedf = x.seriedf and v.nroserieecf = x.nroserieecf and v.seqvendedor = r.nrorepresentante and x.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and x.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 1 and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) and TRUNC(v.dtahoremissao) >= PDt_Base and NOT EXISTS (Select 1 From DWD_FATO_VENDA dwv Where dwv.dt_venda >= PDt_Base And dwv.Sq_Cliente = v.seqpessoa And dwv.Sq_Forma = nvl(v.nroformapagto, 1)
85
And dwv.Sq_Condicao = nvl(v.nrocondicaopagto, 1) And dwv.Sq_Tipo_Venda = v.nroempresa And dwv.Sq_Vendedor = v.seqvendedor And dwv.Dt_Venda = TRUNC(v.dtahoremissao) And dwv.Sq_Produto = x.seqproduto And dwv.Id_Entrada_Saida = 'S' And dwv.Nm_Categoria = m.categoria And dwv.Sq_Familia = p.seqfamilia And dwv.Qt_Und_Embalagem = x.qtdembalagem And dwv.Nr_DOC = v.numerodf And dwv.Nm_Tipo_Doc = v.seriedf) group by v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, v.seqvendedor, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, v.numerodf, v.seriedf UNION select -- NF de Saida do Sistema Consinco da Empresa-2 (Autoservigo) v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, 9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, sum(x.quantidade), sum(x.vlritem), v.numerodf, v.seriedf from mfl_dfitem@muller x, mfl_doctofiscal@muller v, map_produto@muller p, map_categoria@muller m, map_famdivcateg@muller n, map_famembalagem@muller k, map_famdivisao@muller a, map_familia@muller f where v.nroempresa = 2 and v.seriedf != 'CF' and v.statusdf != 'C' --and trunc(v.dtahoremissao) < '01-oct-04' and v.nroempresa = x.nroempresa and v.numerodf = x.numerodf and v.seriedf = x.seriedf and v.nroserieecf = x.nroserieecf and x.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and x.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 2 and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) and TRUNC(v.dtahoremissao) >= PDt_Base and NOT EXISTS (Select 1 From DWD_FATO_VENDA dwv Where dwv.dt_venda >= PDt_Base And dwv.Sq_Cliente = v.seqpessoa And dwv.Sq_Forma = nvl(v.nroformapagto, 1) And dwv.Sq_Condicao = nvl(v.nrocondicaopagto, 1) And dwv.Sq_Tipo_Venda = v.nroempresa
86
And dwv.Sq_Vendedor = 9000 And dwv.Dt_Venda = TRUNC(v.dtahoremissao) And dwv.Sq_Produto = x.seqproduto And dwv.Id_Entrada_Saida = 'S' And dwv.Nm_Categoria = m.categoria And dwv.Sq_Familia = p.seqfamilia And dwv.Qt_Und_Embalagem = x.qtdembalagem And dwv.Nr_DOC = v.numerodf And dwv.Nm_Tipo_Doc = v.seriedf) group by v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, 9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, v.numerodf, v.seriedf UNION select -- Cupom Fiscal de Saida do Sistema Consinco da Empresa-2 (Autoservigo) v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, 9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, sum(x.quantidade), sum(x.vlritem), v.numerodf, v.nrocheckout||'S'||substr(v.nroserieecf, 9, 1) from mfl_dfitem@muller x, mfl_doctofiscal@muller v, map_produto@muller p, map_categoria@muller m, map_famdivcateg@muller n, map_famembalagem@muller k, map_famdivisao@muller a, map_familia@muller f where v.nroempresa = 2 and v.seriedf = 'CF' and v.statusdf != 'C' --and trunc(v.dtahoremissao) < '01-oct-04' and v.nroempresa = x.nroempresa and v.numerodf = x.numerodf and v.seriedf = x.seriedf and v.nroserieecf = x.nroserieecf and x.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and x.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 2 and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) and TRUNC(v.dtahoremissao) >= PDt_Base and NOT EXISTS (Select 1 From DWD_FATO_VENDA dwv Where dwv.dt_venda >= PDt_Base And dwv.Sq_Cliente = v.seqpessoa And dwv.Sq_Forma = nvl(v.nroformapagto, 1) And dwv.Sq_Condicao = nvl(v.nrocondicaopagto, 1) And dwv.Sq_Tipo_Venda = v.nroempresa And dwv.Sq_Vendedor = 9000 And dwv.Dt_Venda = TRUNC(v.dtahoremissao)
87
And dwv.Sq_Produto = x.seqproduto And dwv.Id_Entrada_Saida = 'S' And dwv.Nm_Categoria = m.categoria And dwv.Sq_Familia = p.seqfamilia And dwv.Qt_Und_Embalagem = x.qtdembalagem And dwv.Nr_DOC = v.numerodf And dwv.Nm_Tipo_Doc = v.nrocheckout||'S'||substr(v.nroserieecf, 9, 1)) group by v.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), v.nroempresa, 9000, TRUNC(v.dtahoremissao), x.seqproduto, 'S', m.categoria, p.seqfamilia, x.qtdembalagem, v.numerodf, v.nrocheckout||'S'||substr(v.nroserieecf, 9, 1) UNION select -- NF de Entrada/Devolugco do Sistema Consinco da Empresa-1 (Atacado) vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, v.seqvendedor, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, sum(xd.quantidade), sum(xd.vlritem), vd.numeronf, vd.serienf from mfl_doctofiscal@muller v, mlf_notafiscal@muller vd, mlf_nfitem@muller xd, mad_representante@muller r, map_produto@muller p, map_categoria@muller m, map_famdivcateg@muller n, map_famembalagem@muller k, map_famdivisao@muller a, map_familia@muller f where vd.nroempresa = 1 and vd.statusnf != 'C' --and trunc(vd.dtaemissao) < '01-oct-04' and vd.numeronf = xd.numeronf and vd.seqpessoa = xd.seqpessoa and vd.serienf = xd.serienf and vd.tipnotafiscal = xd.tipnotafiscal and vd.nroempresa = xd.nroempresa and v.nroempresa = vd.nroempresa and v.numerodf = vd.nfreferencianro and v.seriedf = vd.nfreferenciaserie and v.nroserieecf = 'NF' and v.cfop in (5102, 6102) and xd.cfop in (1202, 2202, 1411, 2411) and v.seqvendedor = r.nrorepresentante and xd.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and xd.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and m.nrodivisao = 1 and n.status != 'I' and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) and TRUNC(vd.dtaemissao) >= PDt_Base and NOT EXISTS
88
(Select 1 From DWD_FATO_VENDA dwv Where dwv.dt_venda >= PDt_Base And dwv.Sq_Cliente = vd.seqpessoa And dwv.Sq_Forma = nvl(v.nroformapagto, 1) And dwv.Sq_Condicao = nvl(v.nrocondicaopagto, 1) And dwv.Sq_Tipo_Venda = vd.nroempresa And dwv.Sq_Vendedor = v.seqvendedor And dwv.Dt_Venda = TRUNC(vd.dtaemissao) And dwv.Sq_Produto = xd.seqproduto And dwv.Id_Entrada_Saida = 'E' And dwv.Nm_Categoria = m.categoria And dwv.Sq_Familia = p.seqfamilia And dwv.Qt_Und_Embalagem = xd.qtdembalagem And dwv.Nr_DOC = vd.numeronf And dwv.Nm_Tipo_Doc = vd.serienf) group by vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, v.seqvendedor, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, vd.numeronf, vd.serienf UNION select -- NF de Entrada/Devolugco do Sistema Consinco da Empresa-2 (Autoservigo) vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, 9000, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, sum(xd.quantidade), sum(xd.vlritem), vd.numeronf, vd.serienf from mfl_doctofiscal@muller v, mlf_notafiscal@muller vd, mlf_nfitem@muller xd, map_produto@muller p, map_categoria@muller m, map_famdivcateg@muller n, map_famembalagem@muller k, map_famdivisao@muller a, map_familia@muller f where vd.nroempresa = 2 and vd.statusnf != 'C' --and trunc(vd.dtaemissao) < '01-oct-04' and vd.numeronf = xd.numeronf and vd.seqpessoa = xd.seqpessoa and vd.serienf = xd.serienf and vd.tipnotafiscal = xd.tipnotafiscal and vd.nroempresa = xd.nroempresa and v.nroempresa = vd.nroempresa and v.numerodf = vd.nfreferencianro and v.seriedf = vd.nfreferenciaserie and v.nroserieecf = 'NF' and v.cfop in (5102, 6102) and xd.cfop in (1202, 2202, 1411, 2411) and xd.seqproduto = p.seqproduto and p.seqfamilia = f.seqfamilia and f.seqfamilia = a.seqfamilia and a.nrodivisao = n.nrodivisao and a.seqfamilia = n.seqfamilia and n.seqfamilia = k.seqfamilia and xd.qtdembalagem = k.qtdembalagem and n.nrodivisao = m.nrodivisao and n.seqcategoria = m.seqcategoria and n.status != 'I' and m.nrodivisao = 2
89
and m.nivelhierarquia = 1 and m.tipcategoria = 'M' and m.seqcategoria not in (1, 2, 13, 14, 15, 16, 4, 1607) and TRUNC(vd.dtaemissao) >= PDt_Base and NOT EXISTS (Select 1 From DWD_FATO_VENDA dwv Where dwv.dt_venda >= PDt_Base And dwv.Sq_Cliente = vd.seqpessoa And dwv.Sq_Forma = nvl(v.nroformapagto, 1) And dwv.Sq_Condicao = nvl(v.nrocondicaopagto, 1) And dwv.Sq_Tipo_Venda = vd.nroempresa And dwv.Sq_Vendedor = 9000 And dwv.Dt_Venda = TRUNC(vd.dtaemissao) And dwv.Sq_Produto = xd.seqproduto And dwv.Id_Entrada_Saida = 'E' And dwv.Nm_Categoria = m.categoria And dwv.Sq_Familia = p.seqfamilia And dwv.Qt_Und_Embalagem = xd.qtdembalagem And dwv.Nr_DOC = vd.numeronf And dwv.Nm_Tipo_Doc = vd.serienf) group by vd.seqpessoa, nvl(v.nroformapagto, 1), nvl(v.nrocondicaopagto, 1), vd.nroempresa, 9000, TRUNC(vd.dtaemissao), xd.seqproduto, 'E', m.categoria, p.seqfamilia, xd.qtdembalagem, vd.numeronf, vd.serienf; Nr_registros Number(4); BEGIN Select Trunc(Max(DT_ULT_ATU)) INTO DT_BASE FROM DWD_FATO_VENDA; Begin -- Carga de Clientes de novas NFs do Sistema Consinco For Reg_Cliente in Cur_Cliente (Dt_Base) Loop Insert Into DWD_CLIENTE (SQ_CLIENTE, NM_CLIENTE, DS_ATIVIDADE, NM_CIDADE, NM_BAIRRO, SQ_UF, DT_ULT_ATU) Values (Reg_Cliente.Seqpessoa, Reg_Cliente.nomerazao, Reg_Cliente.atividade, Reg_Cliente.cidade, Reg_Cliente.bairro, Reg_Cliente.Uf, sysdate+1); End Loop; COMMIT; End; Begin -- Carga de Representante/Vendedor de novas NFs do Sistema Consinco For Reg_Vendedor in Cur_Vendedor (Dt_Base) Loop Insert Into DWD_VENDEDOR (SQ_VENDEDOR, NM_REGIAO, NM_VENDEDOR, NM_CIDADE, DT_ULT_ATU) Values (Reg_Vendedor.nrorepresentante, Reg_Vendedor.descequipe, Reg_Vendedor.nomerazao, Reg_Vendedor.cidade, sysdate+1); End Loop; COMMIT; End; Begin -- Carga de Forma de Pagamento de novas NFs do Sistema Consinco
90
For Reg_Forma in Cur_Forma Loop Insert Into DWD_FORMA_PAGTO (SQ_FORMA, DS_FORMA, DT_ULT_ATU) Values (Reg_Forma.nroformapagto, Reg_Forma.formapagto, sysdate+1); End Loop; COMMIT; End; Begin -- Carga de Condigco de Pagamento de novas NFs do Sistema Consinco For Reg_Condicao in Cur_Condicao Loop Insert Into DWD_CONDICAO_PAGTO (SQ_CONDICAO, DS_CONDICAO, NR_NRO_DIAS, DT_ULT_ATU) Values (Reg_Condicao.nrocondicaopagto, Reg_Condicao.desccondicaopagto, Reg_Condicao.nrodiavencto, sysdate+1); End Loop; COMMIT; End; Begin -- Carga de Tipo de Venda (Segmento) de novas NFs do Sistema Consinco For Reg_TpVenda in Cur_TpVenda Loop Insert Into DWD_TIPO_VENDA (SQ_TIPO_VENDA, DS_TIPO_VENDA, DT_ULT_ATU) Values (Reg_TpVenda.nrosegmento, Reg_TpVenda.descsegmento, sysdate+1); End Loop; COMMIT; End; Begin -- Carga de Embalagem de novas NFs do Sistema Consinco For Reg_Embalagem in Cur_Embalagem Loop Insert Into DWD_EMBALAGEM (SQ_FAMILIA, NM_EMBALAGEM, QT_UND_EMBALAGEM, QT_PESO_BRUTO, QT_PESO_LIQUIDO, DT_ULT_ATU) Values (Reg_Embalagem.seqfamilia, Reg_Embalagem.embalagem, Reg_Embalagem.qtdembalagem, Reg_Embalagem.pesobruto, Reg_Embalagem.pesoliquido, sysdate+1); End Loop; COMMIT; End; Begin -- Carga de Produto do Atacado de novas NFs do Sistema Consinco For Reg_Produto in Cur_Produto Loop Insert Into DWD_PRODUTO (SQ_PRODUTO, SQ_FAMILIA, NM_PRODUTO, NM_FORNECEDOR, NM_MARCA, NM_CATEGORIA, DT_ULT_ATU) Values (Reg_Produto.seqproduto, Reg_Produto.seqfamilia, Reg_Produto.desccompleta, Reg_Produto.nomerazao, Reg_Produto.marca, Reg_Produto.categoria, sysdate+1); End Loop; COMMIT; End; Begin -- Carga de Tempos de novas NFs For Reg_Tempo in Cur_Tempo (Dt_Base) Loop
91
Insert Into DWD_TEMPO (DT_VENDA, NR_DIA, NR_MES, NR_ANO, NM_DIA_SEMANA, NR_SEMANA, NR_BIMESTRE, NR_SEMESTRE, DT_ULT_ATU) Values (Reg_Tempo.DATAVENDA, Reg_Tempo.DIADATA, Reg_Tempo.MESDATA, Reg_Tempo.ANODATA, Reg_Tempo.DIASEMANADATA, Reg_Tempo.SEMANADATA, Reg_Tempo.BIMESTREDATA, Reg_Tempo.SEMESTREDATA, sysdate+1); End Loop; COMMIT; End; Nr_registros := 0; Begin -- Carga de novas NFs For Reg_Venda in Cur_Venda (Dt_Base) Loop Insert Into DWD_FATO_VENDA (SQ_CLIENTE, SQ_FORMA, SQ_CONDICAO, SQ_TIPO_VENDA, SQ_VENDEDOR, DT_VENDA, SQ_PRODUTO, ID_ENTRADA_SAIDA, NM_CATEGORIA, SQ_FAMILIA, QT_UND_EMBALAGEM, QT_PRODUTO, VL_VENDA, NR_DOC, NM_TIPO_DOC, DT_ULT_ATU) Values (Reg_Venda.seqpessoa, Reg_Venda.nroformapagto, Reg_Venda.nrocondicaopagto, Reg_Venda.nroempresa, Reg_Venda.seqvendedor, Reg_Venda.dtahoremissao, Reg_Venda.seqproduto, Reg_Venda.Tipo, Reg_Venda.categoria, Reg_Venda.seqfamilia, Reg_Venda.qtdembalagem, Reg_Venda.Quantidade, Reg_Venda.Valor, Reg_Venda.numerodf, Reg_Venda.seriedf, sysdate+1); If Nr_registros > 1500 Then Nr_registros := 0; COMMIT; End If; End Loop; COMMIT; End; END PRC_CARGA_INCREMENTAL;
92
APÊNDICE 6 – FONTE PRC_ACERTA_NF
CREATE OR REPLACE PROCEDURE "PRC_ACERTA_NF" IS BEGIN update dwd_fato_venda a set a.sq_produto = 5 where a.sq_produto = 357037 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 6 where a.sq_produto = 332972 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 7 where a.sq_produto = 336587 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 8 where a.sq_produto = 321067 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 9 where a.sq_produto = 359315 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 10 where a.sq_produto = 330260 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 11 where a.sq_produto = 336420 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 12 where a.sq_produto = 336390 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 13 where a.sq_produto = 336412 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 14 where a.sq_produto = 336374 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 15 where a.sq_produto = 336366 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 16 where a.sq_produto = 353350 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 17 where a.sq_produto = 342994 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 18 where a.sq_produto = 336447 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 19 where a.sq_produto = 374280 ; COMMIT; update dwd_fato_venda a set a.sq_produto = 20 where a.sq_produto = 302461 ; COMMIT; ... END PRC_ACERTA_NF;
93
APÊNDICE 7 – ARTIGO PUBLICADO NA REVISTA DISTRIBUIÇÃO (EDIÇÃO NÚMERO 143)
DATA MART PARA ANÁLISE DE INFORMAÇÕES DE VENDAS NO ATACADO
Adelir Soares
Introdução
A evolução do varejo e do atacado tem demonstrado uma trajetória de convergência para a busca da eficiência, o aumento da competitividade e da rentabilidade, a redução de custos e a otimização da atividade. Cada vez mais o setor atacadista/distribuidor passa a se restringir às funções de comprar e vender, mas de modo a aumentar sua rentabilidade e direcionar corretamente seus investimentos. Para que isso aconteça, a base da evolução está centrada na informação e na forma de obtê-la no tempo certo, de forma compreensível e abrangente. Este trabalho está sendo desenvolvido na Distribuidora Muller Ltda, estabelecida na cidade de Itajaí – SC e fundada em 1967. Em 2003 a empresa optou por trocar seu ERP, de desenvolvimento interno acessando base Dataflex, por ERP de mercado baseado em Oracle. Com a troca do sistema transacional da empresa surgiram problemas relativos à integração das informações, que em cada um dos sistemas se encontram em padrões diferentes. Desta forma, atualmente os dados operacionais dos últimos cinco anos da empresa estão distribuídos em duas plataformas de banco de dados: Dataflex e Oracle.
A falta de informação estruturada e integrada de ambos os sistemas acarreta a dificuldade e demora na tomada de decisão gerencial de vendas, fazendo com que problemas e oportunidades passem despercebidos. Essas características demonstram as necessidades específicas que podem ser satisfatoriamente atendidas pela implantação de um ambiente de Data Warehouse, mais especificamente um Data Mart para a área de vendas.
Desenvolvimento
O foco deste trabalho está no setor de vendas, por ser de grande importância para empresa e pela carência de informações, principalmente devido ao fato de os dados estarem distribuidos no sistema atual, em base de dados Oracle, e no sistema legado, em base de dados Dataflex. Sendo que o sistema atual foi adquirido há um ano e possui padrões e modelagens diferenciadas do sistema legado, de desenvolvimento interno. Fica clara a necessidade de uma ferramenta, que apresente as informações consolidadas à gerência de vendas e aos dirigentes da empresa, de modo a permitir uma análise flexível, sob demanda e mais apurada no decorrer do tempo, possibilitando a análise de dados de 5 anos de vendas e não de apenas poucos meses, melhor subsidiando a tomada de decisão.
Conclusão
Neste projeto foi desenvolvido o Data Mart que tem como foco o departamento de vendas de uma empresa do setor atacadista/distribuidor, pois é neste setor que se encontram as maiores necessidades de obtenção de informações para análise gerenciais.
Finalmente, a ferramenta OLAP (On Line Analytical Process) utilizada em um projeto de tal porte deve ser a mais ágil e flexível, para que as informações consultadas retornem de forma rápida e precisa, daí a escolha da ferramenta Oracle Discoverer.
O objetivo geral foi atingido, com o desenvolvimento do Sistema de Informação de Data Mart de vendas no atacado e o início da utilização do mesmo pelos principais usuários identificados, otimizando o aproveitamento de recursos para o departamento de vendas da empresa. Como o valor da informação tende a sofrer mutações, no que diz respeito à relevância, este sistema tende a ser dinâmico, sofrendo modificações e adaptações constantes, tornando-se necessárias repetidas avaliações para que o sistema permaneça relevante e confiável para o setor gerencial.
94
Adelir Soares é gerente de tecnologia da Distribuidora Müller. Este projeto foi desenvolvido para o Trabalho de Conclusão de Curso da Universidade do Vale do Itajaí, Rua Uruguai, 45– Itajaí – SC.
Rogério Gonçalves Bittencourt, M. Sc. - Orientador Damaris Fanderuff, M. Sc. - Co-orientadora
95
ANEXO 1 – ARTIGO
SISTEMA DE INFORMAÇÃO BASEADO EM TECNOLOGIA DE DATA MART PARA ANÁLISE DE INFORMAÇÕES DE VENDAS
Adelir Soares Rogério Gonçalves Bittencourt, M. Sc. - Orientador
Damaris Fanderuff, M. Sc. - Co-orientadora
RESUMO
A Distribuidora Müller Comércio e Representações Ltda, atuando no setor atacadista a mais de 36 anos, possui um sistema ERP com base de dados em Oracle. Já o sistema anterior, de desenvolvimento interno foi todo desenvolvido no Dataflex. A falta de informação estruturada e integrada de ambos os sistemas acarreta a dificuldade e demora na tomada de decisão gerencial de vendas, fazendo com que problemas e oportunidades passem despercebidos. Fica clara a necessidade de uma ferramenta, que apresente as informações consolidadas a gerencia de vendas e aos dirigentes da empresa, de modo a permitir uma análise flexível, possibilitando a análise de dados de 5 anos de vendas e não de apenas poucos meses, de modo a melhor subsidiar a tomada de decisão, em relação, por exemplo, à investimento dos recursos para vendedores e promoções nas regiões atendidas pela empresa, aquisição de mercadorias, contato com clientes e identificação de clientes especiais em suas categorias, entre outros. Para viabilizar estas informações aos gerentes e supervisores da empresa, foi construido um sistema de Data Mart para o departamento comercial da empresa, que está armazenando informações sobre a estrutura de funcionamento e desempenho do sistema de venda no atacado e que objetiva servir como instrumento balizador no processo de análise e tomada de decisão. Para alcançar estes objetivos foi necessário levantar as necessidades de informação do departamento de vendas através de entrevistas, desenvolver o modelo multidimensional para o Data Mart de vendas, desenvolver o aplicativo ETL (extração, transformação e limpeza de dados) dos dois sistema ERP (Dataflex e Oracle), demonstrar através de consultas ad hoc relatórios e gráficos. Palavras-chave: Data Mart. Distribuição. Sistemas de Informação de Vendas.
ABSTRACT
Muller Comércio e Representações LTDA, dealing with wholesale for more than 36 years, it has an ERP system with data basis in Oracle. The previous system in inner developing was developed in Dataflex. The lack of structured and integrated information causes delay and difficulty when it comes to making decisions managing sales; problems and opportunities may not be noticed. There’s need of a tool which presents the information to sales management and the directors of the company, so that a flexible analysis could be possible not only for the past months but also for the past 5 years, to enable better decisions for investments in sales and promotions throughout the region the company embraces, for acquisition of goods, contacting clients and identifying VIP-clients in their degree. To enable the information to managers and supervisors, a Data Mart system is to be developed in the business department of the company, which will store data about the functionalism and developing of the wholesale business and is to attend as a marker for analysis and decisions. To reach these goals, a raising of needs in information in the business department will be necessary, with the use of interviews, also the developing of a multidimention pattern for business Data Mart, the developing of ETL application (data extraction, modification and sweep) in both ERP systems (Dataflex and Oracle), the demonstration through ad hoc reports and graphs. Key words: Data Mart. Distribution. Business Information System. Introdução
A evolução do varejo e do atacado tem demonstrado uma trajetória de convergência para a busca da eficiência,
o aumento da competitividade e da rentabilidade, a redução de custos e a otimização da atividade. Cada vez mais o setor
atacadista/distribuidor passa a se restringir às funções de comprar e vender, mas de modo a aumentar sua rentabilidade e
96
direcionar corretamente seus investimentos. Para que isso aconteça, a base da evolução está centrada na informação e na
forma de obtê-la no tempo certo, de forma compreensível e abrangente.
Este trabalho foi desenvolvido na Distribuidora Muller Ltda, estabelecida na cidade de Itajaí – SC e fundada
em 1967, com aproximadamente, 13.880 clientes, 136 representantes, 200 funcionários e faturamento mensal médio de
R$ 4,5 milhões. A empresa é uma das maiores do estado no ramo da distribuição de gêneros alimentícios e a 49a no
Ranking Nacional do setor atacadista 2004, conforme ABAD (Associação Brasileira dos Atacadistas e Distribuidores),
encontrando-se entre as dez maiores empresas do município (ABAD, 2004). Em 2003 a empresa optou por trocar seu
ERP, de desenvolvimento interno acessando base Dataflex, por ERP de mercado baseado em Oracle. Com a troca do
sistema transacional da empresa surgiram problemas relativos à integração das informações, que em cada um dos
sistemas se encontram em padrões diferentes. Desta forma, atualmente os dados operacionais dos últimos cinco anos da
empresa estão distribuídos em duas plataformas de banco de dados: Dataflex e Oracle.
A falta de informação estruturada e integrada de ambos os sistemas acarreta a dificuldade e demora na tomada
de decisão gerencial de vendas, fazendo com que problemas e oportunidades passem despercebidos. Essas
características demonstram as necessidades específicas que podem ser satisfatoriamente atendidas pela implantação de
um ambiente de Data Warehouse, mais especificamente um Data Mart para a área de vendas.
Um Data Warehouse/Data Mart é um sistema de informação. Segundo Laudon (1999), um Sistema de
Informação (SI) pode ser definido como um conjunto de componentes inter-relacionados trabalhando juntos para
coletar, recuperar, processar, armazenar e fornecer informação com o objetivo de facilitar o planejamento, o controle, a
coordenação, a análise e o processo decisório nas organizações. Esse conceito permite identificar que os sistemas de
informação abrangem desde a camada operacional até a estratégica da organização. Sendo que os sistemas de
informação que atendem as camadas tática e estratégica das organizações são conhecidos como Sistema de Informações
Gerenciais (SIG), pois ao transformar dados em informações que podem ser utilizadas na estrutura decisória da
organização, proporcionam sustentação para a tomada de decisão gerencial. Os SIG evoluíram e ganharam
características de flexibilidade e adaptabilidade às mudanças, dando origem aos Sistemas de Apoio a Decisão (SAD)
(BINDER, 1994; OLIVEIRA, 2002).
As informações contidas nos tradicionais sistemas orientados à transação, oriundas da camada de usuários
operacionais da organização, em geral, não suprem as necessidades de consultas dos gerentes, que precisam acessar
longos períodos históricos que, em geral, não estão disponíveis nos sistemas utilizados para gerenciar as tarefas
cotidianas da empresa, além do problema do desempenho no acesso a tais informações, que seria extremamente
prejudicado. A dificuldade de acesso a longos períodos históricos de informação seguida da característica de muitas
organizações de ter seus dados distribuídos em diferentes sistemas de origem e, muitas vezes, em diferentes plataformas
computacionais, dificultando o seu acesso e integração, tornou necessário o uso de sistemas conhecidos como Data
Warehouse (DW).
O DW é um ambiente de apoio à decisão que integra dados corporativos armazenados em diferentes fontes e
plataformas oferecendo aos usuários a inteligência do negócio para a tomada de decisão e se apresentando como uma
tecnologia de gestão e análise de dados. Então, um sistema de DW é composto por um banco de dados, para onde
97
somente as informações necessárias para a tomada de decisões são carregadas, vindas dos bancos de dados
operacionais. Os dados são carregados para este novo banco apenas se fizerem parte do contexto de interesse e de forma
desnormalizada, potencializando desempenho e a possibilidade de responder a questões complexas, como tendências e
mudanças de mercado, desempenho de vendas e assim por diante (SINGH, 2001).
Os dados, por serem referentes a sistemas operacionais diferentes, devem ser tratados, integrados e consistidos
em uma fase do Data Warehouse, denominada ETL (Extração, Transformação e Limpeza). O Processo Analítico de
Transações On-Line (OLAP) aplicado aos dados, após sua integração, permite a manipulação de informações
organizadas de forma lógica (através de banco de dados relacional) em Cubos de Decisão, a geração de consultas ad-
hoc, relatórios e gráficos que atendam, de forma flexível, as necessidades de informação da gerência de vendas da
organização.
Justificativa
Os conceitos de Data Warehouse / Data Mart encontraram oportunidade de aplicação na situação atual em que
a empresa para a qual se destina o projeto encontra-se, no que diz respeito à obtenção de informação consistente
integrada de forma ágil, como demonstrado na Figura 1.
Figura 1. Situação atual de acesso aos dados de vendas na Distribuidora Muller Ltda
Foi desenvolvido um Sistema de Informação de Data Mart para disponibilizar informações de vendas no
atacado, de modo a auxiliar a tomada de decisão e otimizar o aproveitamento de recursos para o departamento de
vendas da Distribuidora Muller Ltda. Este objetivo foi alcançado através de:
• Levantar as necessidades de informação do departamento de vendas através de entrevistas;
• desenvolver o modelo multidimensional para o Data Mart de vendas, juntamente com suas propriedades,
como granularidade, historicidade, e assim por diante;
• desenvolver o processo ETL (extração, transformação e limpeza de dados) das bases transacionaid do
sistema ERP anterior (Dataflex) e da base transacional atual (Oracle);
• implementação da ferramenta OLAP (lado Servidor) do Data Mart para área de vendas no atacado; e
• disponibilizar interface para consultas ad hoc, relatórios e gráficos, informações relevantes a tomada de
decisão gerencial em vendas.
Base Oracle 1 ano de informação
Base Dataflex 4 anos de informação
Integração
Estruturação
Busca rápida
Consistência
98
Metodologia
Inicialmente, a pesquisa se deu através do levantamento bibliográfico (livros, revistas, periódicos
especializados e na Internet), que referenciam metodologias e casos de desenvolvimento de sistemas semelhantes.
Em uma segunda etapa, foi feito levantamento de informações relacionadas a vendas junto à empresa,
incluindo a base de dados e sistema transacional, tanto para o sistema antigo, quanto para o novo e as maiores
necessidades de informações gerenciais (entrevistas junto a usuários do sistema transacional e gerente de vendas).
Em relação aos riscos, estes são minimizados com a adoção de ferramentas já consolidadas (Banco de dados
Oracle e Oracle Discoverer) no mercado e de um processo formal de revisão e aceitação do projeto implementado, pelos
gerentes envolvidos. O processo analítico do negócio apresenta baixo risco, pois os requisitos foram validados
previamente com as gerências de interesse.
Fundamentação Teórica
Dentre diversos conceitos encontrados na literatura, alguns deles definem Sistemas de Informações como “um
conjunto de pessoas, hardware, software, redes de comunicações e recursos de dados que coleta, transforma e dissemina
informações em uma organização, reforçando a comunicação entre os seus atores”. Os dados brutos são coletados e
transformados em informações utilizáveis no fluxo de trabalho dentro de uma organização e na sua estrutura decisória,
proporcionando sustentação administrativa (baseada nas metas estabelecidas e nas decisões tomadas perlas pessoas que
as fazem acontecer). A utilização de Sistemas de Informação nas organizações possibilita auxiliar a tomada de decisões,
análise e visualização de assuntos complexos e solução de diversos tipos de problemas através de um ciclo de atividades
básicas: entrada, processamento, saída e retroalimentação (LAUDON et al, 1999; REZENDE, 2001; O’BRIEN, 2003;
CECHINEL, 2003).
Um dos principais desafios gerenciais da atualidade é fazer uso da tecnologia da informação para projetar e
gerenciar empresas competitivas e eficientes. Sistemas de Informação se tornaram vitais e extremamente importantes
para o gerenciamento, organização e operação das empresas. Segundo O’Brien (2003) os Sistemas de Apoio à Decisão
(SAD) são uma das principais categorias de sistemas de apoio gerencial, por fornecerem aos gerentes apoio
informacional interativo durante o processo de tomada de decisão.
Rezende (2001) salienta que, para que a empresa possa usufruir das vantagens básicas do sistema de
informações gerenciais ou de apoio a de decisão, é necessário o envolvimento da alta e média gerência, a competência
das pessoas envolvidas com o sistema, o uso de um plano mestre, a atenção específica ao fator humano, a habilidade
dos executivos em identificar as necessidades de informações, e em tomar decisões com base nelas, o apoio global dos
vários planejamentos da empresa, o apoio organizacional de adequada estrutura organizacional e das normas e
procedimentos inerentes ao sistema; o conhecimento e confiança no sistema, a existência de dados/informações
relevantes e atualizados e a adequada relação custo-benefício.
A área de informática deve facilitar o trabalho dos gerentes, na busca dos resultados para a empresa, o que
exige um processo cuidadoso de planejamento da arquitetura de informação da organização. Quatro fatores básicos
99
devem ser observados durante o desenvolvimento e implantação de um sistema de informação: envolvimento do usuário
no processo de desenvolvimento e implantação; suporte da gerência e o grau no qual a gerência dá suporte ao esforço de
implementação; o nível de risco e complexidade do projeto; a qualidade do gerenciamento do processo de implantação.
A deficiência em um desses fatores pode causar problemas no design do sistema; na definição, exatidão e confiabilidade
dos dados; no custo de implantação do sistema; e em deficiências na operação do sistema.
Um sistema baseado na tecnologia de Data Warehouse (DW) pode ser considerado um Sistema de Apoio à
Decisão, pois uma base relacional do DW pode ser utilizada como apoio para a tomada de decisão gerencial na
organização e engloba a análise de muitas unidades de dados conduzindo a uma informação de grande valor agregado.
O valor da informação é um conceito muito relativo, pois nem todas as informações apresentam a mesma importância
para uma decisão e, por melhor que seja a informação, se não for comunicada às pessoas interessadas em forma e
conteúdo adequados, ela perde todo o seu valor (INMON, 1997; KIMBALL, 2002).
Para o desenvolvimento de um SAD diversas abordagens podem ser seguidas, dentre elas a abordagem
adaptativa, que tem este nome devido à sua grande adaptabilidade a mudanças no contexto ou até mesmo no problema
de decisão que está sendo modelado. De acordo com Binder (1994), as principais características da abordagem
adaptativa são o reduzido tempo de construção, o desenvolvimento conjunto com o usuário, o início do processo de
desenvolvimento pelo problema crucial do usuário e a avaliação constante do sistema. Nesta abordagem, o propósito
básico da informação (útil e atualizada) é o de habilitar a empresa a alcançar seus objetivos pelo uso eficiente dos
recursos informacionais disponíveis. Os tomadores de decisões corporativos precisam de respostas para uma série de
questões que afetam diretamente sua habilidade de competir no mercado. A informação certa, na hora certa e para a
pessoa certa gera subsídios para a implementação de estratégias e definição de objetivos e a sua modificação quando
estes se tornam ineficazes.
Data Warehouse
Atualmente o desenvolvimento de sistemas de Data Warehouse (DW) vem se tornado uma grande área de
estudo e aplicação nas empresas. As empresas e os clientes ficaram mais ágeis e exigentes, fazendo com que a
descrição, extração e sincronismo dos dados seja necessária para dar apoio às decisões e manter a competitividade entre
as empresas. A possibilidade de acessar informações confiáveis com boa velocidade e garantia de qualidade de dados
está cativando os diretores das organizações que cada vez mais necessitam de um controle mais correto de seus dados
sem depender de intermediários para poder tomar suas decisões (KIMBALL, 2002).
Na literatura (INMON, 1997; SINGH, 2001; KIMBALL, 2002), um Data Warehouse pode ser considerado um
conjunto de dados, extraídos dos Sistemas de Processamento de Transação On-Line (OLTP - sistemas operacionais de
fonte única ou múltipla), em determinado intervalo de tempo e carregados em uma base central de dados. São bancos de
dados usados unicamente para a produção de consultas, sendo facilmente acessado por tomadores de decisão para
auxiliar em suas análises.
Os sistemas OLTP são baseados em transações, sendo configurados e otimizados para prover respostas rápidas
às transações individuais, como inclusão, alteração e exclusão de dados, tornando tais transações rápidas e confiáveis.
100
Os dados são dinâmicos e mudam com grande freqüência. Já para os sistemas de apoio à decisão, que se baseiam em
uma tecnologia conhecida como OLAP (Processo Analítico On-Line), onde a velocidade das transações não influi, pois
os dados são armazenados de forma estática (sem inclusão, exclusão ou alteração direta pelo usuário), são configurados
e otimizados para suportar buscas complexas de dados para as decisões (FLORES, 2002).
Em suma, o principal objetivo do DW é coletar dados das várias aplicações, armazenar informações de forma
compreensível e de fácil acesso. Os dados contidos em um Data Warehouse são organizados por área de assuntos e
tornam-se integrados de forma comum a referencia e o armazenamento de dados úteis (INMON, 1997; KIMBALL,
2002). A figura 2 apresenta a arquitetura de um Data Warehouse típico.
Figura 2. Arquitetura de um data warehouse
Fonte: Fanderuff (2002)
O Data Warehouse visa a atender as necessidades da organização como um todo, apresentando uma estrutura
verdadeiramente corporativa que atende a muitas necessidades diferentes e de departamentos diferentes da organização.
Um Data Warehouse é estruturalmente diferente de um Data Mart, pois o Data Mart é um subconjunto do Data
Warehouse que visa a atender as necessidades de informação de um único departamento ou assunto. A organização
pode construir uma série de Data Marts ao longo do tempo e eventualmente vinculá-los em um DW lógico da
organização (COREY, 2001; SINGH, 2001; KIMBALL, 2002).
Neste contexto, a importância da constante manutenção dos Metadado (documentação - dados sobre os dados,
informações sobre processos técnicos, negócios e assuntos usados na organização); utilizados para qualificar,
contextualizar, organizar, facilitar o acesso, apresentar existência e manutenção e indicar localização, tipo e meio de
obtenção de fontes de dados que geram informação; está em possibilitar que a inclusão de novos membros à equipe do
projeto seja menos traumática e mais dinâmica.
A granularidade também é considerada um aspecto importante em um projeto de DW, pois diz respeito ao nível
de detalhe ou resumo dos dados contidos no DW. Quanto mais detalhe, mais baixo o nível de granularidade. Pode-se
desenvolver modelos dimensionais para a maioria das informações atômicas capturadas por um processo do negócio,
pois os dados atômicos são as informações mais detalhadas coletadas. Desta forma, mais coisa se sabe e há maior
flexibilidade analítica, pois estes podem ser limitados e acumulados de diversas formas. Em contrapartida, o modelo
101
menos granular, apesar de ocupar menos espaço, é imediatamente vulnerável a inesperadas solicitações de usuário para
descer ao nível de detalhes (INMON, 1997; KIMBALL, 2002).
Um Data Warehouse possui quatro características básicas (COREY, 2001; INMON, 1997; KIMBALL, 2002):
• Baseado em assuntos: Contêm informações a respeito de funções organizacionais, consideradas
importantes para o negócio da empresa, pois cada sistema oferece suporte para consultas a respeito
das informações que ele captura;
• DW é integrado: Os bancos de dados OLAP são oriundos, em geral, da junção de duas ou mais bases
distintas das quais deve-se agrupar as informações. No entanto, visto que as bases se encontram em
locais, formatos, origens e com codificações diferentes é necessário que um processo de
transformação torne os dados integrados;
• DW é não-volátil: O DW é um banco de dados somente para leitura, no qual se mantém um registro
histórico das transações, desta forma seria incoerente permitir gravações de manipulações de dados.
Os dados operacionais são regularmente acessados, tratados e sofrem atualizações, enquanto que os
dados no DW são carregados e acessados, mas a atualização dos dados não ocorre; e
• DW é variável em relação ao tempo: Visto ser um ambiente destinado à consultas, o item histórico é
algo de suma importância para auxiliar na tomada de decisão, para o estudo de tendências e
sazonalidades. As séries temporais empregam características específicas ao ambiente do DW que deve
ser programado para permitir o gerenciamento dos dados representativos da coexistência de intervalos
de tempo com informações que serão analisadas e comparadas constantemente.
Ferramentas de acesso a dados são os recursos de consultas dos usuários. Idealmente, as ferramentas de acesso
de dados consultam os dados na área final do DW. Esta área final é gerada através dos processos de extração,
transformação e carregamento (ETL) que transformam os dados transacionais em informações empresariais. O processo
ETL é a caixa preta que transforma tais dados em informações. Segundo Kimball (2002), os processos ETL são:
1. Extração: é a obtenção de dados do ambiente operacional, que envolve a leitura e a compreensão de
dados de origem e cópia dos dados necessários ao DW na staging area para futura manipulação;
2. Transformação: é a filtragem dos dados (correções de erros de digitação, solução de conflitos de
domínio, tratamento de elementos ausentes ou a divisão em formatos padrão), combinação de dados
de várias origens, cancelamento de dados duplicados e atribuição de chaves no DW; e
3. Carga: é carregar os dados para o ambiente do DW. Esse processo normalmente assume a forma de
um processo de apresentação de tabelas dimensionais para o Data Mart.
O Data Warehouse utiliza o modelo dimensional ou multidimensional como base para a representação de seus
dados e as relações entre eles. As estruturas dimensionais podem ser visualizadas como cubos de dados e cubos dentro
de cubos de dados, onde cada face do cubo representa uma dimensão (diferentes categorias – produto, região, tipo de
venda, tempo, etc). Cada célula dentro da estrutura dimensional contém dados agregados, relacionados a elementos em
102
cada uma das dimensões que constituem os fatos. Desta forma, uma maneira de considerar a natureza complementar das
tabelas de fatos e de dimensões é exibi-las convertidas em consultas, onde os atributos de dimensão são a identificação
dos relatórios e as tabelas de fatos fornecem os valores numéricos (KIMBALL, 2002; O’BRIEN, 2003).
Para Kimball (2002) a tabela de fatos é a principal tabela ou a tabela central de um modelo dimensional, sendo
que a palavra fato representa uma medida ou métrica utilizada no negócio, por exemplo, valor de venda e quantidade
vendida. Com essas informações é feita a medição nos pontos de interseção de todas as dimensões (dia, produto, cliente,
representante, etc), assim a lista de dimensões define a granularidade da tabela de fatos e nos informa qual é o escopo da
medição (MAZZOLA, 2003).
Segundo O’Brien (2003), OLAP é a capacidade dos sistemas de apoio à decisão permitir aos gerentes e
analistas examinarem e manipularem interativamente enormes quantidades de dados detalhados e consolidados, a partir
de múltiplas perspectivas. As ferramentas OLAP são as aplicações que usuários finais têm acesso para extrair os dados
de suas bases e construir os relatórios capazes de responder as questões gerenciais (DATE, 2000; DWBRASIL, 2003).
A Figura 3 mostra exemplos de cubos de decisões com diferentes categorias.
O processamento OLAP pode ser implementado no banco de dados através de duas arquiteturas principais:
OLAP multidimensional (MOLAP) e OLAP relacional (ROLAP), onde a diferença se encontra na forma de
armazenamento físico dos dados. Na arquitetura MOLAP os dados são armazenados fisicamente de forma
multidimensional, para serem vistos nesta mesma forma. Na arquitetura ROLAP, os dados são armazenados em
modelos relacionais (em geral, desnormalizados), em base de dados relacionais. Pode-se, ainda, mesclar as
características de ambas arquiteturas em uma arquitetura híbrida – HOLAP (KIMBALL, 2002).
Figura 3. Cubos de Decisão
Fonte: O’Brien (2003)
Uma ferramenta OLAP possui operações analíticas básicas (KIMBALL, 2002; MAZZOLA, 2003):
103
1. drill-down: exibir os dados detalhados que compõem os dados consolidados, ou seja, faz uma
desagregação, por exemplo, as vendas por produtos ou representantes de vendas individualizados, que
formam os totais de vendas de uma região poderiam ser facilmente obtidos;
2. drill-up: significa ir de um nível mais baixo de agregação até um nível mais alto. Um exemplo é dada
a quantidade total de remessas, obter as quantidades totais para cada fornecedor individual; e
3. Slicing and dicing: significa fatiar em cubos, cujo o termo se refere à possibilidade de considerar os
banco de dados a partir de diferentes pontos de vista, por exemplo a fatia do banco de dados de vendas
poderia mostrar todas as vendas de tipo de produto dentro das regiões. Geralmente ele é efetuado ao
longo de um eixo de tempo a fim de analisar tendências e descobrir padrões.
Desenvolvimento
O foco deste trabalho está no setor de vendas, por ser de grande importância para empresa e pela carência de
informações, principalmente devido ao fato de os dados estarem distribuidos no sistema atual, em base de dados Oracle,
e no sistema legado, em base de dados Dataflex. Sendo que o sistema atual foi adquirido há um ano e possui padrões e
modelagens diferenciadas do sistema legado, de desenvolvimento interno. Fica clara a necessidade de uma ferramenta,
que apresente as informações consolidadas à gerência de vendas e aos dirigentes da empresa, de modo a permitir uma
análise flexível, sob demanda e mais apurada no decorrer do tempo, possibilitando a análise de dados de 5 anos de
vendas e não de apenas poucos meses, melhor subsidiando a tomada de decisão.
Foi aplicada a abordagem adaptativa proposta por Binder (1994), composta por cinco passos:
1. primeiro e segundo passos – preparação do ambiente e identificação dos requisitos de informação
para a tomada de decisão: baseada em reuniões com a gerencia de vendas, consultor externo e
representantes do departamento de informática. As diversas reuniões objetivaram avaliar
necessidades, expor possíveis soluções e metodologias e conscientizar da importância do
envolvimento de todos no processo. Neste passo identificaram-se necessidades de informação e
problemas de fontes e integrações de dados, pois com a mudança do ERP (Enterprise Resource
Planning - Sistema Integrado de Gestão Empresarial), os anos anteriores de informação encontram-se
em sistema desenvolvido internamente baseado em Dataflex e somente os últimos meses estão
disponíveis no sistema atual (Oracle);
2. terceiro passo – desenvolvimento de um protótipo do SAD evolutivo: após identificação da área de
vendas como processo do negócio e das informações que a organização necessita para servir de apoio
à decisões. A carga dos dados da base operacional para o banco de dados do DW e o desenvolvimento
da ferramenta OLAP, seguindo uma arquitetura ROLAP (OLAP relacional), são baseados no uso da
ferramenta Oracle Discoverer e banco de dados Oracle (com o desenvolvimento de Stored
Procedures);
3. quarto passo – avaliação do protótipo: após a implantação e testes no sistema, são realizadas
avaliações junto com a gerência de vendas, de modo a identificar se as informações e sua forma de
apresentação atendem às necessidades dos usuários; e
104
4. quinto passo - implementação de novas melhorias: conforme necessidades do usuário.
Foram aplicadas as seguintes etapas de construção do Data Warehouse propostas por Kimball e Ross (2002):
1. primeira etapa - seleção do processo do negócio a ser modelado: com base nas maiores necessidades
da empresa e de sua atividade fim, foi escolhido entre os processos de negócio a área de vendas;
2. segunda etapa – declaração do grão do processo de negócio: granularidade (nível de detalhes) é de
produto, embalagem, cliente, dia, condição e forma de pagamento, tipo de venda e representante;
3. terceira etapa – escolha das dimensões: as dimensões definidas foram produto, embalagem, cliente,
dia, condição e forma de pagamento, tipo de venda e representante;
4. quarta etapa – identificação dos fatos: com a finalidade de analisar as medidas de desempenho das
vendas foi escolhido a quantidade de vendas e valor total da venda;
5. quinta etapa – preenchimento dos atributos nas dimensões: com base nas reuniões foram definidos os
atributos mais relevantes para cada uma das dimensões;
6. sexta etapa – preenchendo as tabelas de dimensão: esta etapa suporta os processos de ETL, sendo
extraídos os dados das bases operacionais (Dataflex e Oracle) para as tabelas da base dimensional. Os
dados são filtrados, combinados e padronizados, para então serem carregados para o Data Mart;
7. sétima etapa – preparar dimensões para suportar mudanças: definição de uma política de carga de
produtos que sofreram alterações que possam influenciar em alguma reação do mercado consumidor;
8. oitava etapa – escolha da duração do banco de dados: o período do banco de dados é de cinco anos; e
9. nona etapa – definir espaço de tempo de extração e carga de dados: os dados serão extraídos e
carregados diariamente em processo agendado no sistema operacional do servidor, em horário
noturno.
O diagrama de contexto do projeto é apresentado na Figura 4 e o DER físico do modelo dimencional da
aplicação é apresentado na Figura 5.
105
Figura 4. Diagrama de Contexto
Figura 5. DER Físico da Base Dimensional
Com a etapa de ETL do sistema, é realizada a busca dos dados em suas fontes e sua consolição para popular a
base de dados do Data Warehouse. Esta fase foi implementada através dos seguintes passos:
1. criação de um banco de dados Oracle auxiliar para receber dados extraídos da base Dataflex;
2. retorno do backup da base de dados Dataflex;
3. desenvolvimento de procedimento de banco de dados (Stored Procedure) para carga dos dados do
Dataflex nas tabelas no banco de dados Oracle;
4. criação das tabelas DW no banco de dados DW_MULLER, em servidor de banco de dados exclusivo;
5. desenvolvimento de procedimento para carga e tratamento dos dados da base transacional Oracle,
carregando os dados iniciais para o banco de dados DW_MULLER;
6. desenvolvimento de procedimento de banco de dados para carga e tratamento dos dados do banco
Dataflex para o banco de dados DW_MULLER;
7. desenvolvimento de procedimento para carga incremental dos dados diariamente acrescidos à base
transacional atual para o banco de dados DW_MULLER.
Os procedimentos PRC_CARGA_MODELO_ESTRELA e PRC_CARGA_DATAFLEX_ESTRELA foram
executados uma única vez para a carga inicial de dados de ambos os bancos. O procedimento
PRC_CARGA_INCREMENTAL foi agendado para execução diária, tornando disponível a informação gerada até o dia
anterior. O fluxo do processo de carga está representado na Figura 6.
106
Figura 6. Resumo do processo de carga inicial para a base do DW
Pode-se observar que toda a estratégia de ETL foi baseada no uso da linguagem PL/SQL3 ao invés do uso de
soluções baseadas em ferramentas patenteadas de ETL. Tal escolha foi embasada no custo do projeto, visto que o
PL/SQL está incorporado ao banco de dados Oracle, não gerando custos adicionais, ao contrário da adoção de outra
ferramenta de ETL (como o Oracle Warehouse Builder (OWB) ou o Ardent Data Stage da Informix).
A ferramenta OLAP escolhida é o Oracle Discoverer, devido às suas funcionalidades de servidor, cliente e
Web, que se apresenta como um ambiente visual de construção, disponibilização e acesso de uma estrutura de modelo
estrela de dados do DM. O acesso ao Oracle através do Discoverer é nativo, permitindo ganho de performance. É uma
ferramenta flexivel e de fácil utilização e integração tecnológica (MACHADO, 2000; FANDERUFF, 2004).
Os cubos de decisão são criados no componente de administração da ferramenta (Discoverer Administrator).
Os itens recebem nomes significativos, mascarando os nomes padronizados para campos definidos no banco de dados,
além de possibilitar que determinados itens fiquem indisponíveis e que sejam criadas fórmulas, condições, hierarquias e
listas de valores. O componente Administrator trabalha com End User Layers (EUL – Camada de Usuário Final), uma
3 PL/SQL é uma linguagem procedural que é parte integrante do banco de dados Oracle. É uma ferramenta poderosa e
flexível para manipulação e integração de dados (FANDERUFF, 2003; COREY, 2001).
SERBACKUP
configuração
Pentium III Dual 800 MHz 1 GB de RAM Disco SCSI 30 GB S. O.: Linux Conectiva 5.1 Dataflex df3.1d
SERORACLE
configuração Pentium III Dual 1.2 GHz 2 GB de RAM Disco 2 SCSI 36 GB (1 com o SO e outro Oracle) S.O.: Linux SUSE 8.1 B.D. Oracle 9i
Restauração do backup dofaturamento da base de dadosDataflex das fitas para oservidor SERBACKUP.
Arquivos texto com os dados do Dataflex transferidos para o Servidor Oracle
Carga dos dados dos arquivos textos do
Dataflex parao banco de
dados Oracle
SERVDW
configuração
Pentium IV 2.8 GHz 2 GB de RAM Disco de 160 GB Windows 2000 Server B.D.: Oracle 9i
ETL: Carga e integração dos dados
do Dataflex e do Oracle para a base
DW.
Execução de procedimentos para criação de arquivos
texto no servidor SERBACKUP,
baseados na base restaurada do Dataflex.
Carga diária dos
novos dados
(incremental).
2
1
3
4
5
6Dados da Carga: 2 Gb de Dados 10.598.241 Itens de Venda 31.143 Clientes 15.656 Produtos e
1.523 Datas
107
camada intermediária que permite traduzir ao usuário final a complexidade do banco de dados. Neste componente são
criadas as Buisiness Áreas (Áreas de Trabalho) para os Data Marts (MACHADO, 2000; FANDERUFF, 2004). Foi
desenvolvida a Business Area “Vendas Muller”, selecionando-se as tabelas do modelo dimensional do banco de dados
para compô-la e adaptando tal modelo ao conhecimento do usuário, como demonstrado na Figura 7.
Figura 7. Business Area “Vendas Muller” no componente Oracle Discoverer Administrator
Os componentes do lado cliente permitem o acesso aos dados para que eles sejam analisados, através de
pivoteamentos (rotacionamento) ou drills (detalhamento ou resumo), alterando a organização dos dados sem a
necessidade de realização de novas consultas. Os componentes Desktop e Plus permitem a construção de consultas ad-
hoc, bem como as operações OLAP, com base no modelo disponibilizado pela ferramenta de administração. O
componente Viewer permite a manipulação, através de operações OLAP de consultas previamente criadas e
disponibilidas através dos componentes Desktop ou Plus (MACHADO, 2000; FANDERUFF, 2004). Algumas
consultas foram construídas e disponibilizadas, como a consulta apresentada na Figura 8, “Valor Total de Venda –
Região / Cidade x Mês”, no ano de 2004, com destaque a venda mensal inferior a R$ 50.000,00.
Figura 8. Consulta “Valor Total de Venda – Região / Cidade x Mês” com destaque às vendas inferiores a R$ 50.000,00.
A estrutura multi camada final desenvolvida está representada na Figura 9.
108
Figura 9. Estrutura multi-camada do DW desenvolvido para Distribuidora Muller Ltda
Fonte: Adaptado de Fanderuff (2004)
Conclusão
Neste projeto foi desenvolvido o Data Mart que tem como foco o departamento de vendas de uma empresa do
setor atacadista/distribuidor, pois é neste setor que se encontram as maiores necessidades de obtenção de informações
para análise gerenciais.
Para levantar as necessidades de informação do departamento de vendas, na concepção e modelagem do Data
Mart foi de essencial importância as entrevistas e reuniões com as gerências, diretores, setor de informática e outros
envolvidos no processo decisório. Tais encontros foram realizados para detectar e extrair as informações necessárias e
úteis, de modo a não honerar ou deixar incompleto o conjunto de informações gerenciais disponíveis para utilização. A
construção do modelo multidimensional foi desenvolvido após as entrevistas e reuniões, quando o conhecimento dos
requisitos de informação já estava consolidado.
A etapa de ETL foi a mais problemática. A realização da extração, a partir de uma base de dados operacional e
de sistemas legados, exige profundo conhecimento da forma de armazenamento das informações necessárias, bem como
a forma possível de integrá-las. O processo de ETL dos dados derivados de bancos de dados diferentes gerou aumento
de complexidade, principalmente na correlação entre os dados dos distintos bancos.
Finalmente, a ferramenta OLAP utilizada em um projeto de tal porte deve ser a mais ágil e flexível, para que as
informações consultadas retornem de forma rápida e precisa, daí a escolha da ferramenta Oracle Discoverer.
109
O objetivo geral foi atingido, com o desenvolvimento do Sistema de Informação de Data Mart de vendas no
atacado e o início da utilização do mesmo pelos principais usuários identificados, otimizando o aproveitamento de
recursos para o departamento de vendas da empresa. Como o valor da informação tende a sofrer mutações, no que diz
respeito à relevância, este sistema tende a ser dinâmico, sofrendo modificações e adaptações constantes, tornando-se
necessárias repetidas avaliações para que o sistema permaneça relevante e confiável para o setor gerencial.
Referências Bibliográficas
ABAD – Associação Brasileira de Atacadistas e Distribuidores. Site da ABAD. <http://www.abad.com.br/> Acesso em: 12 nov. 2003, mai. 2004.
BINDER, Fábio Vinícius. Sistemas de apoio à decisão. São Paulo: Érica, 1994.
CECHINEL, Cristine e SILVA JR, Ovídio Felippe Pereira da. Sistema de Informação Gerencial para Suporte do Balanced Scorecard da Cecpas Empreendimentos Imobiliários Ltda. Trabalho de Conclusão de Curso em Ciências da Computação na Universidade do Vale do Itajaí (Univale) – Itajaí - SC: 2003.
COREY, Michael et al. Oracle 8i data warehouse. Rio de Janeiro: Campus, 2001.
DATE, C. J. Introdução a Sistemas de Bancos de Dados. Trad. 7ª Ed. Americana. Rio de Janeiro: Campus, 2000.
FANDERUFF, Damaris. Dominando o Oracle 9i: modelagem e desenvolvimento. São Paulo: Pearson, 2003.
____________________ Oracle Discoverer: Aferramenta OLAP da Oracle. Revista SQL Magazine, nº 15. São Paulo: Neofício, nov/2004.
INMON, William H. Como construir o data warehouse. Trad. Ana Maria N. Cruz. Rio de Janeiro: Campus, 1997.
KIMBALL, Ralph; ROSS, Margy. The data warehouse tookit. 2. ed. Rio de Janeiro: Campus, 2002. 494 p.
LAUDON, Kenneth C; LAUDON, Jane P. Sistemas de informação. Trad. Dalton C. de Alencar. Rio de Janeiro: LTC, 1999.
MAZZOLA, Jailson e SILVA JR, Ovídio Felippe Pereira da. Sistema de Apoio a Decisão para Área Comercial da Empresa Buettner S. A. Indústria e Comércio. Trabalho de Conclusão de Curso em Ciências da Computação na Universidade do Vale do Itajaí (Univale) – Itajaí - SC: 2003.
MACHADO, Felipe N. R. Projeto de Data Warehouse: Uma Visão Multidimensional. São Paulo: Érica, 2000.
O’BRIEN, James A. Sistema de informações e as decisões gerenciais na era da internet. São Paulo: Saraiva, 2003.
OLIVEIRA, Djalma de Pinho Rebouças de. Sistemas de informações gerenciais. 8. ed. São Paulo: Atlas, 2002.
REZENDE, Denis Alcides; ABREU, Aline França de. Tecnologia da informação aplicada a sistema de informação empresariais: o papel estratégico da informação e dos sistemas de informação nas empresas. São Paulo: Atlas, 2001.
SILVA JR, Ovídio Felippe Pereira da e ABREU, Aline França de. Avaliando os Sistemas de Informações Executivas nos Processos Decisórios das Instituições Universitárias Brasileiras. Dissertação de Mestrado. Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina (PPGEP/UFSC), Florianópolis, 2000.
SINGH, Harry S. Data warehouse: conceitos, tecnologias, implementação e gerenciamento. São Paulo: Makron Books, 2001.