Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
PROTÓTIPO DE UM DATA MART PARA AUXILIAR O GESTOR NO CONTROLE E ACOMPANHAMENTO DA QUEBRA DE ESTOQUE
Área de Sistemas de Informação
por
Josiel Samuel Luiz
Luiz Eduardo Perfeito Nunes, M. Eng. Orientador
São José (SC), julho de 2008
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
PROTÓTIPO DE UM DATA MART PARA AUXILIAR O GESTOR NO CONTROLE E ACOMPANHAMENTO DA QUEBRA DE ESTOQUE
Área de Sistemas de Informação
por
Josiel Samuel Luiz 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: Luiz Eduardo Perfeito Nunes, M. Eng.
São José (SC), julho de 2008
DEDICATÓRIA
Aos meus pais, Samuel e Eliane e meus irmãos Leandro e Maria Eduarda.
ii
AGRADECIMENTOS
A Deus, por ter iluminado esta caminhada com saúde, paz e tranqüilidade.
Ao professor e amigo Luiz Eduardo Perfeito Nunes, M. Eng. pela orientação, crítica e
principalmente pelo apoio dado no decorrer do estudo.
À coordenadora Anita Maria da Rocha Fernandes, Dra. Eng. que contribuiu com
considerações que vieram enriquecer muito este trabalho.
Aos meus pais, por toda a educação, incentivo, orientação e dedicação, em todos os sentidos,
para que eu pudesse alcançar os meus objetivos.
Aos amigos e familiares que direta ou indiretamente contribuíram para a realização desse
trabalho.
Às pessoas que contribuíram durante a fase de desenvolvimento do trabalho, respondendo
aos questionamentos.
Em especial à Anelize do Amaral, pela compreensão, carinho e apoio.
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................v
LISTA DE FIGURAS ..............................................................................vi LISTA DE TABELAS............................................................................viii RESUMO ..................................................................................................ix
ABSTRACT ...............................................................................................x
1 INTRODUÇÃO.....................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 3 1.1.1 Formulação do Problema................................................................................. 3 1.1.2 Solução Proposta ............................................................................................... 4 1.2 OBJETIVOS ........................................................................................................ 4 1.2.1 Objetivo Geral ................................................................................................... 4 1.2.2 Objetivos Específicos ........................................................................................ 4 1.3 METODOLOGIA................................................................................................ 5 1.4 ESTRUTURA DO TRABALHO ....................................................................... 6
2 FUNDAMENTAÇÃO TEÓRICA .......................................................7 2.1 ÁREA DE COMPRAS ........................................................................................ 7 2.1.1 Objetivo da área de compras ........................................................................... 8 2.1.2 Modelos de administração de compras........................................................... 8 2.1.3 Competências da área de compras ................................................................ 10 2.2 GERENTE E TOMADA DE DECISÃO......................................................... 11 2.3 SISTEMAS DE INFORMAÇÃO..................................................................... 12 2.3.1 Conceito............................................................................................................ 12 2.3.2 Sistemas de Apoio ao Executivo .................................................................... 14 2.3.3 Sistemas de Apoio à decisão ........................................................................... 15 2.3.4 Sistemas de informações gerenciais............................................................... 17 2.4 DATA WAREHOUSE ...................................................................................... 18 2.4.1 Conceito............................................................................................................ 18 2.4.2 Granularidade de Dados ................................................................................ 25 2.4.3 Metadados........................................................................................................ 26 2.4.4 Data Mart......................................................................................................... 27 2.4.5 On-Line Analytical Processing ...................................................................... 30 2.4.6 Modelagem Multidimensional ....................................................................... 32 2.4.7 Extração de Dados .......................................................................................... 35 2.4.8 Ciclo de projeto e desenvolvimento de um DW ........................................... 37 2.5 TRABALHOS RELACIONADOS .................................................................. 39
3 DESENVOLVIMENTO .....................................................................42 3.1 METODOLOGIA DE DESENVOLVIMENTO ............................................ 42
iv
3.1.1 Planejamento ................................................................................................... 43 3.1.2 Definição dos requisitos de negócio............................................................... 48 3.1.3 Modelagem dimensional................................................................................. 52 3.1.4 Projeto Físico ................................................................................................... 55 3.1.5 ETL................................................................................................................... 60 3.1.6 Projeto da arquitetura técnica....................................................................... 66 3.1.7 Seleção e instalação dos produtos.................................................................. 67 3.1.8 Definição da ferramenta Front-End ............................................................. 67 3.1.9 Desenvolvimento da aplicação Front-End.................................................... 68 3.1.10 Teste.................................................................................................................. 73
4 CONCLUSÃO.....................................................................................78 4.1 TRABALHOS FUTUROS................................................................................ 80
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................81
GLOSSÁRIO ...........................................................................................83
APÊNDICE A QUESTIONÁRIO APLICADO AOS GESTORES..85
APÊNDICE B CARACTERÍSTICAS DO PROCESSO DE COMPRAS DA EMPRESA PAUTA.....................................................86
APÊNDICE C STORED PROCEDURE.............................................89 A.1 EXTRAÇÃO DA TABELA DE FATO ........................................................... 89 A.2 EXTRAÇÃO DAS TABELAS DE DIMENSÃO............................................ 96 A.2.1 Dimensão Ano.................................................................................................. 96 A.2.2 Dimensão Mês.................................................................................................. 97 A.2.3 Dimensão Dia................................................................................................... 98 A.2.4 Dimensão Filial................................................................................................ 98 A.2.5 Dimensão Grupo ........................................................................................... 100 A.2.6 Dimensão Grupo Margem de Erro ............................................................. 100 A.2.7 Dimensão Produto......................................................................................... 102
APÊNDICE D JOBS ...........................................................................103
LISTA DE ABREVIATURAS
AWM Analytic Workspace Manager BI Business Intelligence DM Data Mart DW Data Warehouse EDI Eletronic Data Interchange ETL Extract Transformation and Loading JAD Joint Application Design JIT Just In Time ND Nota de Débito ODS Operational Data Storage OLAP On-Line Analytical Processing RMA Return Merchandise Authorization RO Registro de ocorrência SAD Sistema de apoio à decisão SAE Sistema de apoio ao executivo SGBD Sistema de Gerenciamento de Banco de Dados SI Sistemas da informação SIG Sistema de informação gerencial SPT Sistema de processamento de transação STC Sistema de trabalhadores de conhecimento TCC Trabalho de Conclusão de Curso TI Tecnologia da Informação UNIVALI Universidade do Vale do Itajaí
LISTA DE FIGURAS
Figura 1. Tipos de sistemas de informação ........................................................................................13 Figura 2. Um exemplo de dados baseados em assuntos/negócios .....................................................20 Figura 3. A questão da não-volatilidade.............................................................................................21 Figura 4. A questão da integração......................................................................................................23 Figura 5. Arquitetura Genérica de um Data Warehouse Centralizado...............................................25 Figura 6. Implementação Bottom-up .................................................................................................28 Figura 7. Implementação Top-Down .................................................................................................29 Figura 8. Implementação Combinada ................................................................................................30 Figura 9. Tecnologia Drill Down e Roll Up.......................................................................................32 Figura 10. Dimensões comuns em um modelo dimensional..............................................................33 Figura 11. Modelo dimensional do tipo Estrela .................................................................................34 Figura 12. Projeto lógico de banco de dados do modelo floco de neve.............................................35 Figura 13. Ciclo de Projeto do DW....................................................................................................37 Figura 14. Metodologia de desenvolvimento.....................................................................................42 Figura 15. Organograma do departamento de compras .....................................................................45 Figura 16. Fluxograma geral da área de compras da Pauta................................................................46 Figura 17. Modelo Dimensional.........................................................................................................54 Figura 18. Modelo Dimensional DM para Oracle 10g.......................................................................56 Figura 19. Representação do Data Mart Físico no Oracle. ................................................................57 Figura 20. Mapeamento da dimensão produto. ..................................................................................59 Figura 21. Processo de ETL e replicações de registros......................................................................60 Figura 22. Modelo Entidade Relacional da Pauta ..............................................................................61 Figura 23. Resultado da carga de uma dimensão ...............................................................................65 Figura 24. Resultado da carga do cubo. .............................................................................................66 Figura 25. Plugin Oracle no MS Excel 2003. ....................................................................................67 Figura 26. Primeira etapa da visão do cubo no front-end. .................................................................69 Figura 27. Segunda etapa da visão do cubo no front-end. .................................................................70 Figura 28. Terceira etapa da visão do cubo no front-end...................................................................71 Figura 29. Resultado da consulta do front-end. .................................................................................71 Figura 30. Gráfico da consulta do front-end. .....................................................................................72 Figura 31. Resultado da Carga do cubo .............................................................................................74 Figura 32. Relatório de programação de compra ...............................................................................74 Figura 33. Resultado da consulta vendas do front-end. .....................................................................75 Figura 34. Percentual de produtos transferidos para suprir a necessidade de venda de uma filial ....75 Figura 35. Percentual de garantia não atendida..................................................................................76 Figura 36. Stored Procedure para extração do Fato ...........................................................................94 Figura 37. Stored Procedure para extração do estoque para a tabela de fato .....................................95 Figura 38. Stored Procedure para extração da dimensão ano. ...........................................................96 Figura 39. Stored Procedure para extração da dimensão mês............................................................97 Figura 40. Stored Procedure para extração da dimensão dia. ............................................................98 Figura 41. Stored Procedure para extração da dimensão filial...........................................................99 Figura 42. Stored Procedure para relacionamento da dimensão filial................................................99 Figura 43. Stored Procedure para extração da dimensão grupo. ......................................................100 Figura 44. Stored Procedure para extração da dimensão grupo margem erro. ................................101 Figura 45. Stored Procedure para extração da dimensão produto....................................................102 Figura 46. PL/SQL de criação do job de extração da dimensão ano. ..............................................103
vii
Figura 47. PL/SQL de criação do job de extração da dimensão grupo margem de erro..................103 Figura 48. PL/SQL de criação do job de extração da dimensão mês...............................................104 Figura 49. PL/SQL de criação do job de extração da dimensão produto.........................................104 Figura 50. PL/SQL de criação do job de extração da dimensão dia. ...............................................104 Figura 51. PL/SQL de criação do job de extração do fato Quebra de estoque. ...............................105 Figura 52. PL/SQL de criação do job de atualização da carga do cubo...........................................105
LISTA DE TABELAS
Tabela 1. Diferença entre Banco de dados operacionais e DW .........................................................24 Tabela 2. Requisitos Funcionais.........................................................................................................51 Tabela 3. Dimensões ..........................................................................................................................52 Tabela 4. Medidas ..............................................................................................................................53 Tabela 5. Medidas Calculadas............................................................................................................63 Tabela 6. Requisitos do banco de dados Oracle.................................................................................66 Tabela 7. Requisitos Atendidos pelo modelo do cubo .......................................................................77 Tabela 8. Questionário aplicado aos gestores ....................................................................................85 Tabela 9. Fórmulas das variáveis da programação de compra...........................................................86 Tabela 10. Descrição da modelagem entidade relacional ....................................................................1
RESUMO
LUIZ, Josiel Samuel. Protótipo de um Data Mart para auxiliar na gestão do processo de compras. São José, 2008. 140 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, São José, 2008. Este trabalho desenvolveu um protótipo de um Data Mart para área de compras da empresa Pauta. Dos diferentes modelos de compra apresentados, o modelo de central de compras foi o que mais se aproximou da estratégia de compras da Pauta. Os sistemas de informação são necessários no processo de tomada de decisão, porém nem sempre seus dados são disponibilizados de forma fácil para os gestores, da mesma forma que existem diferentes modelos de tomada de decisão, que exigem diferentes visões sobre os mesmos dados. Para os gestores tomarem decisões, seria interessante que eles usassem a sua experiência. As experiências surgem a partir do momento que se têm dados históricos, ou seja, fatos ocorridos. Um modelo que se propõe a preservar dados históricos é o Data Mart (DM), que reúne em uma única estrutura dados operacionais, regras de negócio e informações estratégicas, tais como, conhecer empresas concorrentes. O desenvolvimento do DM seguiu o modelo proposto por Kimball. Foram efetuadas entrevistas junto aos gestores seguindo a metodologia Joint Application Design (JAD). Após análise da documentação existente e do material produzido nas reuniões, foi possível observar a dificuldade em lidar com o item quebra de estoque. Foi desenvolvido um modelo de DM usando a estrutura do banco de dados Oracle e como ferramenta de front-end o Microsoft Excel. Após os testes, observou-se que os gestores passaram a ter mais facilidade em visualizar os dados vindos das diferentes filiais, como se fossem uma só, facilitando assim analisar as causas das quebras de estoque. Palavras-chave: Sistemas de informação. Data Mart. Área de Compras.
ABSTRACT
This work developed a Data Mart prototype to the Pauta's purchasing area. Among the different purchase models presented, the central one was the closest to the Pauta's department in discussion. Information systems are necessary during the decision taking process, though its data is sometimes disclosed in not an easy manner to managers, in the same way that different models are presented, that enforce different visions on the same data. For managers to take decisions, it would be interesting for them to use their own experience. The experiences arise from the moment that historical data is available, in other words, occurred facts. A model in which purpose is to preserve historical data is called Data Mart (DM), that puts together in a unique structure operational data, business rules and strategical information, as such, to know concurrent companies. The DM development followed the model proposed by Kimball. Interviews were conducted with managers according to the Joint Application Design (JAD) methodology. After analyzing the existing documentation and the material produced as consequence of meetings, it was possible to observe the difficulty in dealing with the storage breaking item. A DM using the Oracle structure was developed, and Microsoft Excel was used in the front-end tier. After tests, we identified that managers managed to have more ease in what concerns the visualization of data coming from different parts of the company, as this parts were one, what turned to ease storage breaks causes analysis. Keywords: Information Systems, Data Mart, Purchase Area.
1 INTRODUÇÃO
Em um mercado altamente competitivo, onde os clientes necessitam de produtos com mais
qualidade, com preços mais acessíveis e que sejam entregues em um prazo cada vez mais curto, os
gestores precisam de informações estratégicas confiáveis para auxiliá-los durante a tomada de
decisão (ALMEIDA, 2006). Porém, essas informações normalmente estão distribuídas entre
estruturas informatizadas e não informatizadas, e em muitas vezes sem a sua referência às regras de
negócio, sem saber a qual instrução normativa da empresa este evento esta ligado. A utilização de
sistemas de informação tem se mostrado uma boa alternativa para auxiliar e apoiar os gestores nas
tomadas de decisão. Como pode ser observado no conceito de Laudon & Laudon (2006), Sistema
de informação pode ser definido tecnicamente como um conjunto de componentes inter-
relacionados que coleta, processa, armazena e distribui informações destinadas a apoiar a tomada de
decisões.
Segundo Stair & Reynolds (1999), as organizações ou empresas têm gerado vantagem
competitiva em relação ao mercado através das transformações dos dados contidos nos SGBD
(sistema gerenciador de banco de dados) da própria empresa em informações que possam ser
utilizadas em apoio a tomadas de decisões.
Autores como Laudon & Laudon (2006) e O’Brien (2006) relatam que os dados dispostos
por alguns tipos de sistemas de informação não são preparados para serem utilizados pelos gestores
e tão pouco os dados históricos são preservados. Para tanto, as organizações têm procurado por
tecnologias que auxiliem ou amenizem este problema, transformando os dados operacionais em
informações estratégicas que possam auxiliar o gestor em suas tomadas de decisão. Uma das
tecnologias que tem se apresentado como uma alternativa é o Data Warehouse (DW), que além de
transformar os dados operacionais em dados informacionais, também armazenam os dados
históricos e as regras do negócio (Informações contidas nos manuais de atividades da empresa),
podendo assim gerar vantagens competitivas.
“Data Warehouse é o ponto central da arquitetura de processamento de informações para
sistemas de informática modernos, sendo 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” (INMON, 1997). Já
para Oliveira (2002), um DW foca a empresa como um todo, quando se trata de um único
departamento ou a um assunto de negócio se trata de um Data Mart. O conjunto de dados contido
2
em um DW/DM é armazenado de forma informacional, ou seja, a soma dos dados operacionais, os
eventos que deram origem aos mesmos, juntamente com os registros do tempo. “O processamento
informacional ou analítico é o processamento que atende às necessidades dos gerentes durante o
processo de tomada de decisão que é atendido pelos Sistemas de apoio à decisão (SAD)” (INMON,
1997).
Os sistemas de apoio à decisão são sistemas de informação computadorizados que fornecem
apoio interativo de informações para os gestores durante o processo de tomada de decisão. Para
tanto podem ser usados modelos analíticos, banco de dados especializados, as próprias percepções e
julgamentos do tomador de decisão, processos de modelagem computadorizada, tudo para apoiar a
tomada de decisões empresariais no nível tático e ou da administração estratégica (O’BRIEN,
2006).
De forma prática um sistema de informação pode detectar uma quebra de estoque a partir
dos dados operacionais, porém quando esta ocorre é porque num dado momento um evento ou
alguma informação relevante ficou de fora. Para tanto, os eventos históricos podem nos auxiliar a
não cometer os mesmos erros e até mesmo projetar o futuro para prever situações que já ocorreram
e pela evolução ou projeção das informações nos permitirá prever a sua repetição, é importante
salientar que isso também ocorre para as situações em que as decisões foram acertadas, só que neste
caso queremos repetir e não evitar. A empresa foco deste projeto é a Pauta Equipamentos e Serviços
LTDA, cujo modelo de compra é baseado no processo centralizado. As quebras de estoque podem
ser provocadas por vários fatores. Como a empresa possui cinco filiais e tem se o processo de
compras ancorado na modalidade centralizada, o volume de dados e de eventos a serem aplicados
para evitar as quebras de estoque levando-se em consideração a peculiaridade de cada filial é muito
grande, ou seja, temos ai um conjunto de dados operacionais e históricos que precisam ser
modelados de tal forma para que o gestor possa usar junto com os mesmo a sua experiência para
tomar as decisões de forma mais segura.
Para este cenário, a quebra de estoque é um problema a ser levado em consideração dentro
do processo de compras, pois a mesma é responsável por atender a demanda do cliente (Área de
vendas). Para manter a área de vendas de forma eficiente, ter uma área de compras eficaz pode fazer
toda diferença. Dado o volume e a diversidade de informações envolvidas no processo de compras,
isso pode gerar dificuldades para manter a mesma. Em um mercado de vendas cada vez mais
competitivo e que exige uma capacidade de adaptação, a área de compras tem um papel
3
fundamental (saber vender não é necessariamente saber comprar). O processo de compra de
mercadorias junto aos fornecedores passou a ser uma etapa fundamental no processo de
comercialização. O estoque mal dimensionado pode acarretar comprometimento financeiro, aliado a
este poderemos ter fatos como o risco da descontinuidade ou depreciação do estoque, entre outros,
principalmente nas áreas de tecnologia de informática e afins. A compra de mercadorias pode ter
influência direta nas vendas, ou seja, não comprar bem pode gerar vendas ruins.
A empresa Pauta investe em tecnologia, na expectativa de se manter competitiva no
mercado de vendas de produtos de informática e para tanto, tem investido na sua área de compras,
como visto anteriormente, esta área tem se mostrado importante para o comprimento dos seus
objetivos. Este trabalho objetiva elaborar uma ferramenta de apoio à gestão para a área de compras,
focado no evento quebra de estoque. Para elaborar esta ferramenta foi utilizado a metodologia e os
conceitos para a construção de Data Mart.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
As compras de produtos efetuadas pelo departamento de compras da empresa Pauta não tem
conseguido evitar que ocorra o evento quebra de estoque, agravado por um mercado dinâmico e
competitivo e dificultado pelo processo de compra ser centralizado, que precisa respeitar as
peculiaridades de cada filial. Para tanto, sistemas de informação podem dar apoio nas tomadas de
decisão, com o objetivo de conseguir respostas mais rápida e com mais qualidade. Os pedidos de
compra efetuados pela empresa Pauta não levam em conta diversos fatores, como exemplo as
sazonalidades, ou seja, segundo Grazziotin (2004), são os eventos que ocorrem durante uma
determinada época do ano, que pode ocasionar uma mudança na quantidade e no tipo de produto a
ser comprado, sendo assim uma boa previsão de compra auxiliaria a manter os estoques em níveis
adequados. Desta forma, se não são levadas em conta o histórico das mesmas é possível ocorrer
uma quebra de estoque (falta de estoque) e, conseqüentemente, é possível uma perda de
oportunidade de venda desses produtos.
Outro fator que atualmente não é levado em conta na hora de efetuar um pedido de compra
são os produtos que não podem ser vendidos, devido a uma possível quebra de estoque. Sendo
assim, não é possível ter uma média exata de vendas desse produto no período em que o mesmo
passou por uma quebra de estoque.
4
Com esses fatores levantados foi possível observar que a principal necessidade de
informação é saber o que e o quanto adquirir de um determinado produto, para um determinado
local. Porém, para alcançar este nível de conhecimento é necessário ter meios de se identificar e
visualizar os fatos que ocasionam as possíveis quebras de estoque que é o foco dos problemas da
área de compras da empresa Pauta, que acontece durante todo o processo de aquisição dos produtos.
1.1.2 Solução Proposta
O contexto da seção anterior mostra a necessidade que a empresa Pauta tem em possuir uma
ferramenta que auxilie os gestores do departamento de compras a identificarem e visualizarem os
fatos que ocasionam as possíveis quebras de estoque.
A solução proposta para o desenvolvimento desta ferramenta é baseada nos conceitos de
Sistemas de Apoio à Decisão. Foi desenvolvido e implantado um Data Mart para os gestores do
departamento de compras, que através de uma ferramenta de consulta analítica poderá abstrair
informações úteis na identificação de fatos que pode ocasionar as quebras de estoque. Através de
entrevistas com os gestores se verificou que atualmente essas informações são obtidas por meios de
cruzamento de informações de planilhas e relatórios, e conforme o relato dos gestores é um
processo difícil e trabalhoso.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver um protótipo de Data Mart para a área de compras.
1.2.2 Objetivos Específicos
• Identificar e mapear os bancos de dados vinculados a área de compras;
• Identificar os gestores e funcionários envolvidos no processo;
• Levantar os requisitos no processo de gestão de compras;
• Identificar projetos semelhantes;
• Modelar o Data Mart para a área de compras (Quebra de estoque);
5
• Desenvolver o protótipo do Data Mart para a área de compras com foco na quebra de
estoque;
• Implantar o protótipo; e
• Testar protótipo junto aos gestores.
1.3 Metodologia
A metodologia do desenvolvimento deste trabalho de conclusão de curso seguiu o método
do estudo de caso (Exploratória). Segundo Gil (2002), o método exploratório visa proporcionar
maior familiaridade com o problema em questão, com o intuito de torná-lo explícito ou a construir
hipóteses, ou seja, envolve desde o levantamento de materiais bibliográficos com foco no assunto
do problema até análise de exemplos que estimulem a compreensão. Portanto, este trabalho irá por
meio do método exploratório ou estudo de caso conhecer melhor o problema das quebras de estoque
do departamento de compras da empresa Pauta.
Para alcançar os objetivos, a metodologia deste trabalho foi dividida em cinco etapas, dentro
dos quais se utilizou a metodologia de desenvolvimento de DM de Kimball et al (1998) para
auxiliar nas quatros ultimas etapas devido esta metodologia ter suas fases bem distintas e ser focada
na criação e desenvolvimento de um DM.
A primeira etapa deste trabalho foi focada no levantamento de manuais e procedimentos
sobre a área de compras da Pauta. Também foram realizadas pesquisas e estudos sobre sistemas de
informações e Data Warehouse. Foram levantados os conceitos de sistemas de informação e
segundo as regras básicas foram selecionados os principais tipos de sistemas de informações que
atendem a essas regras. As tecnologias utilizadas pelos Sistemas de Apoio à decisão necessitam,
além dos dados operacionais, os dados históricos para poder entender o processo de decisão. Para
tanto, foi necessário estudar e pesquisar sobre a tecnologia de Data Warehousing com suas
respectivas características, modelos, implementações e por fim o seu ciclo de vida. Após o estudo
sobre esta tecnologia, optou-se pela tecnologia de Data Mart (DM), que abrange um determinado
departamento de uma empresa.
A segunda etapa deste trabalho consistiu no levantamento das necessidades do departamento
de compras da Pauta, verificando assim qual é a dificuldade em tomar uma decisão com eficácia.
Após o levantamento das principais necessidades do departamento, foi também necessário fazer um
6
levantamento das tecnologias de banco de dados que a empresa possui em seu acervo, para
averiguar se alguma das mesmas suporta a tecnologia do DM.
A terceira etapa se baseou na modelagem dimensional do DM proposto por este trabalho.
Para a elaboração de uma modelagem consistente foi necessária a aplicação dos conceitos estudados
na primeira etapa e das necessidades do departamento de compras levantadas na segunda etapa.
A quarta etapa consistiu no desenvolvimento do protótipo de um DM para a empresa Pauta.
A construção do modelo físico e o processo de Extract Transformation and Loading (ETL) foram
processos fundamentais nesta etapa, pois envolve todas as regras de negócios.
Na quinta etapa foi selecionado o front-end e realizados os testes no DM para verificar a
consistência dos dados contidos no mesmo.
1.4 Estrutura do trabalho
O presente trabalho está estruturado em quatro capítulos. No Capítulo 1, Introdução,
apresenta uma visão geral do trabalho. No Capítulo 2, Fundamentação Teórica, foi apresentada uma
revisão bibliográfica sobre os gerentes e as tomadas de decisões, a definição e os principais tipos de
sistemas de informação, o conceito, a arquitetura e as principais características de Data Warehouse,
assim como os seus respectivos tipos de implementações, modelagem dimensional e o ciclo de
projeto e desenvolvimento do mesmo. No Capítulo 3 apresenta-se o desenvolvimento detalhado do
Data Mart, incluindo sua especificação, implementação e apresentação da metodologia utilizada.
Concluindo, no Capítulo 4, apresentam-se as conclusões e os trabalhos futuros, onde foi abordado
um apanhado do trabalho realizado demonstrando os problemas e as soluções encontradas.
2 FUNDAMENTAÇÃO TEÓRICA
Para que se possa construir um Data Mart para a área de compras, é necessário conhecer os
diferentes modelos de funcionamento da mesma, para entender como o modelo de compras que a
empresa em que este projeto vai ser aplicado funciona.
Existem diferentes formas de conduzir o processo de compra. Cada gestor pode utilizar uma
estratégia diferente para executar a mesma tarefa.
Portanto, é necessário levantar os diferentes tipos de sistemas de informação que possam
auxiliar os gestores da área de compras a tornar o processo de compras mais eficaz. Para tanto é
necessário também verificar a quais níveis organizacionais os sistemas de informação pertencem
para averiguar qual o nível de tomada de decisão que poderá ser efetuada com o sistema de
informação implantado.
2.1 ÁREA DE COMPRAS
A área de compras é um dos elementos para o bom andamento da empresa, pois através dela
é possível manter estoques com maior eficiência, através de informações que possam indicar ao
gestor o que, quanto, quando e de quem comprar um determinado produto, melhorando assim o uso
dos recursos disponíveis.
Segundo Costa (2002), a área de compras preocupa-se em comprar o material necessário em
quantidades compatíveis com sua demanda no momento oportuno com a melhor qualidade e pelo
preço justo. Entretanto, deve-se lembrar que o processo de aquisição tem início com a decisão de
efetuar a compra e termina com a chegada do material à empresa, em conformidade com o que foi
solicitado. Com o advento da informática nos processos de gestão dos estoques, novas práticas de
parcerias com o fornecedor surgiram, tal como o EDI (Eletronic Data Interchange) que tem por
foco aperfeiçoar o processo de aquisição, aliviando a necessidade de capital de giro e permitindo
que o comprador junto com o fornecedor planeje de forma mais eficiente seus estoques.
8
2.1.1 Objetivo da área de compras
Uma definição bem conhecida dos objetivos de compras é: comprar a qualidade do material
correta, no tempo certo, na quantidade exata, da fonte certa e ao preço adequado. Essa definição é
criticada por alguns como sendo simplista e superficial (BAILY et al, 2000).
Segundo Costa (2002), os objetivos da administração da área de compras são:
• Aplicar o mínimo de capital de giro em estoques de materiais sem que isso leve a
desabastecimento;
• Disponibilizar o estoque para cobrir as necessidades de produção, consumo e/ou vendas;
• Reduzir a necessidade de capital de giro através de prazos de pagamento superiores à velocidade
das vendas;
• Comprar materiais com um baixo custo; e
• Conservar os padrões de qualidade dos materiais adquiridos.
Um bom exemplo é o processo de Just In Time (JIT), que segundo Fusco & Sacomano
(2007) um processo tardio recorre a um processo antecedente no fluxo operacional e obtém somente
o número de peças que são necessárias, quando se necessita delas, ou seja, é um sistema que
determina que não se deve comprar nada antes do momento exato.
Para efetuar uma venda é necessário ter o produto em estoque ou saber onde adquiri-lo num
prazo e num custo tangível, pois nesses casos, como comprar, onde comprar, o que comprar, a que
custo pode fazer toda diferença na hora de vender. O processo de compra é precursor do processo
de venda. (FUSCO & SACOMANO, 2007).
A Seção 2.3 apresenta os tipos de sistemas de informação que foram estudados e dentre eles
se destaca os Sistemas de Apoio à Decisão, que pode auxiliar os gestores da área de compras a
alcançarem os objetivos apresentados nesta seção.
2.1.2 Modelos de administração de compras
Segundo Costa (2002), existem atualmente pelo menos cinco modelos de administração de
compra, são eles:
9
• Proprietário Comprador: a compra e a negociação junto ao fornecedor são realizadas pelo
próprio proprietário onde o mesmo conhece o comportamento da demanda dos materiais.
Sendo assim, suas compras são mais intuitivas do que técnicas e há falta de processos de
avaliação da aquisição. As compras são realizadas no momento em que o representante lhe
faz uma visita ou, em alguns casos, o próprio comprador se desloca para os centros
produtores com o objetivo de adquirir uma mercadoria;
• Compra centralizada: a compra é feita por um setor especializado em compras de forma
concentrada, obtendo-se assim bons descontos e condições de pagamento, devido à compra
ser em maior quantidade. Tem como desvantagem possíveis atrasos no processo de
aquisição, em conseqüência da demora do processo decisório, já que normalmente os
volumes envolvidos são grandes e muitas áreas dependem dessa compra;
• Central de compras: a compra da sede e de suas filiais é centralizada em um único órgão
negociador obtendo através do volume a ser negociado bons descontos e prazos de
pagamento;
• Compra Descentralizada: a compra é efetuada de forma descentralizada com o objetivo de
agilizar o processo aquisitivo e diminuir seus custos com materiais destinados a atender a
uma demanda regional, pois o comprador local conhece mais as necessidades de sua
unidade, os fornecedores locais, o transporte e as instalações de estocagem. Além disso, o
mesmo tem condições de responder mais rapidamente às possíveis emergências que podem
surgir em sua unidade; e
• Compra cooperativa: associação de pequenas empresas onde suas compras são centralizadas
em um único órgão negociador simulando o modelo central de compras com o objetivo de
aumentar o volume da aquisição, obtendo melhores condições de compra como descontos e
prazos especiais, os quais não conseguiriam isoladamente.
A partir dos modelos administrativos de compras estudados nesta seção é possível relatar
que o modelo que possui o maior poder de negociação junto ao fornecedor é o modelo central de
compras. Pois, é o modelo que ao concentrar o maior volume de produtos, aumenta o interesse do
fornecedor em atender o mesmo, pois todas as compras das filiais de uma empresa são efetuadas de
forma centralizada em um único órgão negociador. Porém como um ponto a ser visto neste modelo
com mais atenção é o volume necessário de informação estratégica que o gestor da área de compras
10
deve possuir para poder efetuar o processo de compra de forma eficaz. Já o modelo descentralizado
possui um menor poder de negociação com seus fornecedores devido ao volume de produtos não
ser tão grande quanto no modelo central de compras, mas de contra partida o processo de aquisição
de seus produtos é mais ágil, devido a facilidade que do gestor conhecer mais as necessidades de
sua unidade.
Para uma empresa que utiliza o modelo central de compras é visível a dificuldade em obter
as informações certas na hora certa, face a descentralização da origem das informações. Neste
modelo para se ter uma boa tomada de decisão na hora de comprar, é importante a utilização de
sistemas de informação, que possam auxiliar o gestor a adquirir informações úteis e relevantes no
processo de tomada de decisão.
2.1.3 Competências da área de compras
Para Costa (2002), as competências podem variar de empresa a empresa, mas existem
algumas dessas que são comuns as mesmas, tais como:
• Fazer pesquisas de mercado;
• Realizar visitas às instalações dos fornecedores;
• Executar pesquisas de preços;
• Examinar proposta;
• Negociar com fornecedores;
• Cadastrar fornecedores e materiais;
• Acompanhar pedidos de aquisição;
• Fazer análise dos custos indiretos; e
• Exibir relatórios de desempenho específicos da área.
Para que se possam usar essas competências em um SAD, é necessário entender o processo
de tomada de decisão e as regras as quais o gestor deve estar atento, ou seja, é preciso fazer um
11
levantamento das diferentes formas de decisão para se saber que tipo de informação deve ser
disponibilizado.
2.2 GERENTE E TOMADA DE DECISÃO
Os gerentes podem passar por grandes dificuldades para tomarem decisões, pois essas
decisões podem não estar em um formato estruturado, ou seja, podem vir em um formato em que os
gerentes não possuem um conhecimento suficiente da situação para tomar uma decisão eficiente
(LAUDON & LAUDON, 2006). Essa tomada de decisão pode ser classificada por nível
organizacional, correspondente aos níveis estratégicos, gerencial, de conhecimento e operacional,
detalhados na Seção 2.3.1.
Conforme O’Brien (2006), dentro de cada um desses níveis as decisões são classificadas
como:
• Estruturadas: são repetitivas e rotineiras envolvem situações de decisão em que os
procedimentos podem ser especificados de antemão. A minimização dos custos ou a
maximização dos lucros são exemplos de situações estruturadas;
• Semi-estruturada: alguns procedimentos de decisão podem ser pré-especificados, mas não o
suficiente para levar a uma decisão definida recomendada. Avaliação anual dos funcionários
e a análise de aquisição de capital são exemplos de decisões semi-estruturada; e
• Não-estruturada: envolvem situações de decisão nas quais não é possível especificar
previamente a maioria dos procedimentos. As decisões são importantes e não-rotineiras.
Planejamento de oferta de novos serviços, a contratação de um executivo são exemplos de
situações não estruturadas.
As decisões vão se tornando mais estratégicas de acordo como vão se aproximando ao nível
não estruturado. Portanto, as decisões dos gestores da área de compra da Pauta se enquadram aos
níveis semi-estruturada e não-estruturada.
Segundo Laudon & Laudon (2006), existem várias atividades para se tomar uma decisão.
Essas atividades foram distribuídas em quatro diferentes estágios no processo de decisão, são elas:
• Inteligência: consiste em identificar e entender os problemas que estão ocorrendo na
organização, para auxiliá-los são utilizados os sistemas de informação gerencial;
12
• Concepção: o individuo imagina possíveis soluções para o problema, para auxiliá-lo são
utilizados os sistemas de apoio à decisão;
• Seleção: consiste em escolher uma das alternativas da solução, para auxiliá-lo são utilizados
os sistemas de apoio à decisão; e
• Implementação: quando a decisão é levada a efeito, os gerentes podem usar um sistema que
emite relatórios de rotina sobre o andamento de uma solução específica.
Alguns modelos de sistemas de informação têm como objetivo oferecer ferramentas para
auxiliar os gerentes e a alta administração a tomarem suas decisões.
2.3 SISTEMAS DE INFORMAÇÃO
Existem vários tipos de sistemas de informação e cada um para atender uma ou mais
necessidades dos gestores, para tanto é necessário conhecer alguns conceitos e alguns desses tipos
de sistemas.
2.3.1 Conceito
Sistema de informação corresponde a um processo que coleta, processa, armazena, analisa e
dissemina informações para uma finalidade específica (TURBAN, RAINER & POTTER, 2005), ou
seja, auxiliam os trabalhadores e gerentes a analisar problemas ou visualizar assuntos complexos.
Uma empresa é um exemplo de sistema organizacional no quais os recursos econômicos
(entradas) são transformados por vários processos organizacionais (processamento) em bens e
serviços (saídas). As entradas são os dados que são submetidos a atividades de processamento como
cálculo, comparação, separação, classificação e resumo que organizam, analisam e manipulam
dados, convertendo-os em informação para os usuários finais. Porém, esses dados devem ser
mantidos sempre em constante correção e atualização para garantir a sua qualidade. Os sistemas de
informação fornecem para a administração informações (feedback) sobre as operações do sistema
para sua direção e manutenção (controle), enquanto ele troca entradas e saídas com seu ambiente
(O’BRIEN, 2006).
Informações são dados apresentados em uma forma significativa e útil para os seres
humanos. Dados são correntes de fatos brutos que representam eventos que estão ocorrendo nas
13
organizações ou no ambiente físico, antes de terem sido organizados e arranjados de uma forma que
as pessoas possam entendê-los e usá-los (LAUDON & LAUDON, 2006).
Segundo O’Brien (2006), os tipos de informações exigidos pelos tomadores de decisão estão
diretamente relacionados com o nível da tomada de decisão gerencial e o grau de estrutura nas
situações de decisão que os mesmos defrontam. Tamanho, forma e participantes dos níveis de
tomada de decisão mudam conforme evoluem as estruturas organizacionais. Segundo Laudon &
Laudon (2006), quatro níveis organizacionais atendem aos sistemas de informação conforme Figura
1.
Figura 1. Tipos de sistemas de informação
Fonte: Laudon & Laudon (2006).
• Nível Estratégico: ajuda o gerente sênior a atacar e enfrentar questões estratégicas e
tendências de longo prazo tanto na empresa quanto no ambiente externo. Neste nível
também são especificados os objetivos, recursos e políticas da organização. Os sistemas de
apoio executivo (SAEs) fazem parte do nível estratégico;
14
• Nível Gerencial: atendem às atividades de monitoração, controle, tomada de decisões e
procedimentos administrativos dos gerentes médios. Os sistemas gerenciais têm a
característica de produzir relatórios periódicos sobre as operações, em vez de informações
instantâneas. Os sistemas de informações gerenciais (SIGs) e os sistemas de apoio à decisão
(SADs) são os principais sistemas de informação do nível gerencial;
• Nível Conhecimento: dão suporte aos trabalhadores do conhecimento e de dados da
organização. O propósito desses sistemas do nível é auxiliar a empresa comercial a integrar
novas tecnologias ao negócio e ajudar a organização a controlar o fluxo de documentos. Os
sistemas de trabalhadores do conhecimento (STCs) e os sistemas de automação de escritório
são os principais sistemas de informação do nível do conhecimento; e
• Nível Operacional: dão suporte aos gerentes operacionais, acompanhando atividades e
transações elementares da organização respondendo as perguntas de rotina e acompanhando
o fluxo de transações pela organização. Os sistemas de processamento de transações (SPTs)
fazem parte do nível operacional.
Como o objetivo deste trabalho é propor uma ferramenta que auxilie os gestores da área de
compras da Pauta nas tomadas de decisão, é importante estudar e entender os sistemas relacionados
aos níveis estratégicos e gerenciais.
A principal diferença entre os sistemas SAEs, SADs e SIGs é o nível organizacional que
estes sistemas estão focados. Os SIG têm como objetivo atender o nível gerencial munindo os
gerentes com relatórios, já os SAD também são focados a atender o nível gerencial e estratégico
provendo informações e técnicas de apoio à decisão para analisar problemas ou oportunidades
específicas, e os SAE são focados a atender o nível estratégico, provendo ferramentas a não atacar
um problema específico e sim dispor meios de analisar, comparar e destacar tendências para um
determinado assunto. Uma das principais semelhanças dos três tipos de sistemas (SAE, SAD e SIG)
é o fato de operam com dados operacionais.
2.3.2 Sistemas de Apoio ao Executivo
Os sistemas de apoio ao executivo fornecem informações críticas elaboradas
especificamente para as necessidades de informação estratégica da alta administração, ou seja, os
SAEs disponibilizam aos executivos, acesso fácil e imediato aos aspectos importantes da
15
organização, assim como as novas direções que a empresa deve seguir. Ainda ajuda-os a monitorar
o progresso da organização (O’BRIEN, 2006).
Os sistemas de apoio ao executivo abordam decisões não-rotineiras que exigem bom senso,
avaliação e percepção, uma vez que não existe um procedimento previamente estabelecido para se
chegar a uma solução. Por isso os SAEs filtram, comprimem e rastreiam dados críticos com ênfase
na redução do tempo e esforço requeridos para obter informações úteis aos executivos (LAUDON
& LAUDON, 2006).
Uma capacidade importante dos SAEs é a capacidade para desagregar, que permite aos
executivos rapidamente recuperarem demonstrativos de informações afins em níveis mais baixos de
detalhe, essa característica também é conhecida como drill down (O’BRIEN, 2006).
Segundo Laudon & Laudon (2006), grande parte do valor do SAE está na sua flexibilidade e
na sua capacidade de analisar, comparar e destacar tendências. Os SAEs colocam dados e
ferramentas nas mãos dos executivos sem atacar problemas específicos ou impor soluções.
A informação é apresentada no SAE conforme as preferências dos executivos usuários do
sistema. Enfatizando o uso de uma interface gráfica com o usuário e relatórios de exceção e a
analise de tendências. Relatórios de exceção são relatórios que contêm informações apenas sobre as
condições excepcionais (O’BRIEN, 2006).
2.3.3 Sistemas de Apoio à decisão
Os Sistemas de Apoio à Decisão (SADs), são sistemas de informação baseados em
computador que combina modelos e dados em uma tentativa de resolver os problemas semi-
estruturados e alguns não-estruturados com intenso envolvimento do usuário (TURBAN, RAINER
& POTTER, 2005), ou seja, fornecem apoio aos gestores durante o processo de tomada de decisão.
As ferramentas de SAD utilizam modelos analíticos, banco de dados especializados, as
próprias percepções e julgamentos do tomador da decisão e um processo de modelagem
computadorizado para apoiar a tomada de decisão empresarial (O’BRIEN, 2006).
O SAD auxilia o processo de decisão gerencial combinando dados, ferramentas e modelos
analíticos em um sistema que pode dar suporte à decisão. São projetados para ajudar a elaborar e
16
avaliar alternativas e monitorar a aceitação ou processo de implementação (LAUDON &
LAUDON, 2006).
Segundo O’Brien (2006), os SADs fornecem informações e técnicas de apoio à decisão para
analisar problemas ou oportunidades específicas, através de consultas e respostas interativas.
Os SAD possuem diversas características que os habilitam como uma ferramenta de suporte
gerencial. Os SADs podem lidar com grandes quantidades de dados de diferentes fontes. Possuem
relatórios flexíveis, onde o usuário pode obter a informação que deseja apresentada num formato
que se ajuste a suas necessidades. Oferece também orientação gráfica e de texto, ou seja, pode
transmitir a informação ao usuário através de textos, tabelas, desenhos lineares, gráficos de pizza,
curvas de tendência, entre outros. Além disso, os SADs suportam a análise de drill down onde o
usuário pode conseguir mais níveis de detalhes dos dados consolidados quando necessário. É
possível se executar em um SAD análise de sensibilidade, simulações, análises complexas e
sofisticadas bem como comparações usando pacotes de softwares avançados. Provê também suporte
às abordagens de otimização, convencionais e heurísticas (STAIR & REYNOLDS, 1999).
Segundo Laudon & Laudon (2006), atualmente existem dois tipos básicos de SADs:
• Orientados por modelo: composto por sistemas autônomos isolados dos principais sistemas
organizacionais de informação e que usam algum tipo de modelo para executar analises. Sua
capacidade de análise baseia-se em teoria ou modelo bem fundamentado, combinado com
uma boa interface de usuário, que torna o modelo fácil de usar; e
• Orientado por dados: esses sistemas analisam grandes repositórios de dados, encontrados em
grandes sistemas organizacionais. Dão apoio à tomada de decisão pela permissão aos
usuários de extrair e analisar informações úteis anteriormente ocultas em grandes bancos de
dados.
Nesse projeto foi utilizado o modelo orientado por dados, devido o volume de dados
históricos.
17
2.3.4 Sistemas de informações gerenciais
Os sistemas de informações gerenciais (SIGs) atendem as funções de planejamento, controle
e decisão no nível gerencial da organização, munindo os gerentes de relatórios ou de acesso on-line
aos registros do desempenho corrente e histórico da organização (LAUDON & LAUDON, 2006).
Um SIG gera produtos de informação que apóiam muitas das necessidades de tomada de
decisão da administração (O’BRIEN, 2006).
Geralmente dependem dos sistemas de processamento de transações subjacentes para a
aquisição de dados. Os dados são comprimidos e comumente apresentados em longos relatórios
produzidos segundo uma programação periódica. Em geral dão respostas a perguntas rotineiras que
foram especificadas anteriormente e cujo procedimento de obtenção de respostas é predefinido.
Esses sistemas geralmente não são flexíveis e sua capacidade analítica é reduzida. A maior parte
dos SIGs usa rotinas simples, como resumos e comparações, em vez de sofisticados modelos
matemáticos ou técnicas estatísticas (LAUDON & LAUDON, 2006).
As informações obtidas através dos sistemas de informação gerencial assumem a forma de
relatórios periódicos, de exceção e por demanda, e respostas imediatas a consultas. Quatro
importantes alternativas de relatórios são fornecidas por esses sistemas:
• Relatórios periódicos programados: forma tradicional de fornecimento de informações para
os gerentes. Utiliza um formato pré-especificado, projetado para fornecer informações em
uma base regular;
• Relatórios de exceção: são produzidos apenas quando ocorrem condições excepcionais.
Contêm informações apenas sobre essas condições excepcionais. Os relatórios de exceção
reduzem a sobrecarga de informações, em vez de sobrecarregarem os tomadores de decisão
com relatórios periódicos detalhados da atividade empresarial;
• Informes e respostas por solicitação: as informações encontram-se disponíveis sempre que
um gerente as requisita. As respostas são imediatas ou personalizadas conforme as
solicitações das informações de que necessitam; e
• Relatórios em pilha: as informações são empilhadas na estação de trabalho em rede do
gerente. Muitas empresas estão utilizando software de transmissão em rede para
18
transmitirem seletivamente relatórios e outras informações para os PCs em rede de gerentes
e especialistas ao longo de suas intranets.
Nesse projeto o gestor irá solicitar e até mesmo montar seus próprios relatórios de acordo
com a sua necessidade.
2.4 Data Warehouse
Para um ambiente de SAD e/ou SAE é necessário a utilização de banco de dados
especializado, uma das tecnologias que podem atender está necessidade é o Data Warehousing.
Para tanto, será necessário entender as definições, características e as diferentes formas de aplicar,
está tecnologia na construção dos mesmos.
2.4.1 Conceito
Entre as definições existentes do Data Warehouse (DW), destacam-se as seguintes:
Segundo Inmon e Hackarthorn (1997), DW é o ponto central da arquitetura de
processamento de informações para sistemas de informática modernos. Suporta o processamento
informacional dos SADs através da integração de dados corporativos e históricos para a realização
de análises gerenciais.
Já Oliveira (2002), expõe que um DW pode ser definido como um banco de dados
especializado, o qual integra e gerencia o fluxo de informações a partir de banco de dados
corporativos e fontes de dados externas à empresa.
Severo Filho (2006), afirma que o objetivo de um DW é organizar, preparar e refinar a
informação para que o gestor possa entender rapidamente o que está acontecendo, de forma a
reduzir um esforço para interpretar os relatórios, como acontece nos sistemas transacionais (SPT).
Kimball (1998), em seu trabalho mostra que o DW fornece acesso a dados corporativos ou
organizacionais, seus dados são consistentes podendo ser separados e combinados usando qualquer
medição possível do negócio. O DW dispõe de um conjunto de ferramentas para consultar, analisar
e apresentar informações. É um local onde se publica dados confiáveis, sendo a qualidade desses
um impulso a reengenharia de negócios.
19
Um DW é de maneira genérica, um sistema de gerenciamento de banco de dados relacional,
com o objetivo de dar suporte à tomada de decisão gerencial e não para atender às necessidades dos
sistemas de informação do tipo transacional. DW, portanto, pode ser considerado o
desenvolvimento gradativo do ambiente de apoio à decisão.
Segundo Ramalho (2004), uma das tarefas mais importantes de um DW é o seu
carregamento ou atualização, que no fundo não passa de um tipo especial de replicação de dados.
Dentre as características de um ambiente de DW segundo Inmon (1997), destacam-se as
seguintes características: orientado por assunto, variável em relação ao tempo, integrado, não
volátil, e de apoio às decisões gerenciais.
Para Oliveira (2002), a orientação por assunto é o direcionamento que se dá da visão que
será disponibilizada, do negócio da empresa. Já Inmon (1997), relata na Figura 2 que os sistemas
operacionais clássicos são organizados em torno das aplicações da empresa, isso pode significar que
o mesmo dado pode estar de diferentes formas, dificultando a sua interpretação junto aos demais
cadastros.
20
Figura 2. Um exemplo de dados baseados em assuntos/negócios
Fonte: Inmon (1997).
De acordo com a Figura 2, as figuras disformes no lado operacional representam a falta de
padronização dos dados operacionais de contra partida o DW trabalha com seus dados de forma
padronizada, o que leva a que todos os dados independentes do uso estejam padronizados. No
exemplo de uma companhia de seguros demonstrada pela Figura 2, as aplicações de um banco de
dados operacional podem ser automóvel, vida, saúde e perdas. Os assuntos ou negócios dessas
aplicações podem ser: cliente, apólice, prêmio e indenização e encima dessas informações que o
gestor tomará suas decisões. Para auxiliar o gestor a enxergar essas informações é necessário que as
mesmas estejam relacionadas, o DW disponibiliza essas informações de forma padronizada como se
pode observar no lado esquerdo e direito da Figura 2.
Segundo Oliveira (2002), a variação em relação ao tempo é uma característica ímpar do
DW, ou seja, sempre é retratada a situação que está sendo analisada em um determinado ponto do
tempo. Segundo Inmon (1997), a variação em relação ao tempo possui as seguintes características:
• O horizonte de tempo válido para o DW é maior do que o dos sistemas operacionais;
21
• Os dados de valor corrente são encontrados nos bancos de dados operacionais e sua precisão
é válida para o momento de acesso. Já os dados de um DW não passam de uma série
sofisticada de instantâneos, capturados num determinado momento; e
• A estrutura de chave dos dados operacionais pode conter ou não elementos de tempo. Em
um DW existe sempre uma chave relacionada ao tempo.
Conforme Oliveira (2002), a volatilidade em um ambiente de Data Warehouse não sofre
modificação como nos sistemas tradicionais, ou seja, em um ambiente de DW ocorrem apenas
consultas e cargas de dados, já nos sistemas tradicionais podem ocorrer alterações nos registros do
SGBD (Sistema Gerenciador de Bando de Dados). Já Inmon (1997), relata na Figura 3 que os dados
operacionais são regularmente acessados e tratados um registro por vez. Os dados do DW são
carregados (normalmente em grandes quantidades) e acessados para consultas, mas a atualização
dos dados (geralmente) não ocorre no ambiente de DW.
Figura 3. A questão da não-volatilidade
Fonte: Inmon (1997).
A Figura 3 permite dar como exemplo a seguinte situação: um dado após ter sido carregado
para o DW, mesmo que ocorra uma alteração do dado no ambiente operacional, no DW não é
alterado, é feito um novo lançamento do dado no DW para que se tenha um histórico das alterações
22
deste dado. Isso ocorre até mesmo para que o gestor possa identificar ou sumarizar a quantidade de
alterações que um determinado dado sofre durante um determinado período de tempo, sendo assim
pode tomar as devidas providências se necessário.
Para Oliveira (2002), a integração é responsável pela padronização dos dados de todos os
sistemas existentes na empresa. Esse processo também é conhecido como fase de ETL (Extract
Transformation and Loading). Segundo Inmon (1997), a integração deve ser feita de forma
consistente e independente da aplicação de origem. A Figura 4 demonstra que as considerações
sobre consistência são válidas para todas as questões de projeto de aplicações, como as convenções
de atribuição de nomes, estruturas de chaves, unidades de medidas de atributos e características
físicas dos dados.
23
Figura 4. A questão da integração
Fonte: Inmon (1997).
Conforme Oliveira (2002), a Tabela 1 demonstra algumas relações das diferenças entre
bancos de dados operacionais e DW, e também as diferenças dos dados que os mesmos manipulam.
24
Tabela 1. Diferença entre Banco de dados operacionais e DW
Características Banco de dados Operacionais Data Warehouse Objetivo Operações diárias do negócio Analisar o negócio Uso Operacional Informativo Tipo de processamento OLTP OLAP Unidade de trabalho Inclusão, alteração e exclusão Carga e consulta Número de usuários Milhares Centenas Tipo de usuário Operadores Comunidade gerencial Interação do usuário Somente predefinida Predefinida e ad-hoc Condições dos dados Dados operacionais Dados analíticos Volume Megabytes – gigabytes Gigabytes – terabytes Histórico 60 a 90 dias 5 a 10 anos Granularidade Detalhados Detalhados e resumidosRedundância Não ocorre Ocorre Estrutura Estática Variável Manutenção desejada Mínima Constante Acesso a registros Dezenas Milhares Atualização Contínua (tempo real) Periódica (em batch) Integridade Transação A cada atualização
Fonte: Oliveira (2002).
De acordo com muitos autores uma arquitetura de um DW, de forma geral, é composta
conforme a Figura 5 por um processo de ETL, por um repositório de metadados, um repositório de
dados do DW e em adição a este podem existir diversos DM’s departamentais. Além disto, podem-
se utilizar diversas ferramentas de consultas para facilitar o entendimento das informações contidas
no banco de dados.
25
Figura 5. Arquitetura Genérica de um Data Warehouse Centralizado
Fonte: Oliveira (2002).
2.4.2 Granularidade de Dados
A granularidade dos dados é medida conforme o nível de detalhe dos dados, ou seja, quanto
mais detalhes, menor é o nível de granularidade, conseqüentemente, quanto menos detalhes, maior é
o nível granularidade (MACHADO, 2000).
Conforme a Tabela 1 o nível de granularidade dos bancos de dados operacionais é baixo, já
no caso de um DW a granularidade pode ser baixa ou alta.
A questão da granularidade é de grande importância em um projeto de DW, pois a mesma
pode afetar profundamente o volume de dados que residem no DW e o tipo de consulta que a
mesma pode fornecer (INMON, 1997). Então se pode dizer que quanto maior é o nível de
granularidade menor é o volume de dados e, conseqüentemente, quanto menor é o nível de
granularidade maior é o volume de dados.
O nível de volume dos dados também influencia no desempenho do seguinte modo: quanto
maior o volume de dados menor é o desempenho, conseqüentemente quanto menor é o volume de
dados maior é o seu desempenho (MACHADO, 2000).
26
2.4.3 Metadados
Segundo Inmon (1997), os metadados são dados sobre dados. É por meio dos metadados que
a utilização mais produtiva do DW é alcançada. Os metadados englobam o DW e mantêm as
informações organizadas e ainda define sobre o que está e onde está no DW.
Segundo Oliveira (2002), os metadados podem surgir de diversos locais durante o decorrer
do projeto, tais como:
• Repositório de ferramentas case;
• Os dados referentes aos relatórios que são gerados pelas ferramentas OLAP; e
• Material proveniente de entrevistas com os usuários.
Já Inmon (1997), relata que geralmente os aspectos sobre os quais os metadados mantêm
informações, são:
• A estrutura dos dados segundo a visão do analista de SAD;
• A estrutura dos dados segundo a visão do programador;
• A fonte de dados que alimenta o DW;
• O modelo de dados;
• O relacionamento entre o modelo de dados e o DW;
• A transformação sofrida pelos dados no momento de sua migração para o DW; e
• O histórico de extrações.
Segundo Oliveira (2002), uma arquitetura de metadados bidirecionais permite que os dados
modificados na fonte possam ser alterados também no repositório, automaticamente. Esta
arquitetura é altamente desejável por duas razões:
1. Permite a essas ferramentas compartilhar metadados; e
2. São atraentes para corporações que querem implementar um repositório de
metadados em toda empresa.
27
2.4.4 Data Mart
Os Data Mart (DM) são bancos de dados departamentalizados (unidades de negócio), que
podem apresentar visões relacionais ou multidimensionais (ROSINI & PALMISANO, 2003).
Um DM representa nada mais do que um subconjunto de um DW, ou seja, por ser
direcionado a um departamento ou a uma área especifica do negócio armazena um menor volume
de dados (MACHADO, 2000).
Um DM tem como vantagem sobre o DW um menor tempo de implementação e com um
baixo custo, por possuírem menos informação que os DW possuem menor tempo de resposta e são
mais facilmente entendidos e navegados do que o DW (TURBAN, RAINER & POTTER,2005).
A construção de um projeto de um DW corporativo integral é lenta e cara. Já na construção
de um projeto utilizando DM é possível equilibrar os gastos e oferecer resultados em prazos mais
curtos. Porém um dos problemas dos DMs é o grande risco de desvio do modelo original, pois pode
acontecer um crescimento desestruturado. O que também pode acontecer é a replicação das mesmas
informações em vários locais, o que pode dificultar uma futura integração de todos os DMs em um
único DW (OLIVEIRA, 2002).
Os DM podem ser implementados de diversas formas. Dentre elas, as mais importantes
segundo diversos autores são a Bottom-up, Top-down e a combinação das duas.
Segundo Oliveira (2002), a implementação do tipo Bottom-up é utilizada quando a empresa
não conhece a tecnologia, prefere primeiramente criar um banco de dados somente para uma área.
Com isso os custos e prazos são bem inferiores de um projeto de DW completo.
A implementação Bottom-up possibilita realizar o planejamento e o desenho dos DM mesmo
que não tenha sido definida uma infra-estrutura corporativa para o DW. Essa infra-estrutura não
deixará de existir, mas poderá ser implementada incrementalmente conforme forem sendo
realizados os DM. Na Figura 6 é demonstrada uma visão desta abordagem de implementação
(MACHADO, 2000).
28
Figura 6. Implementação Bottom-up
Fonte: Machado (2000).
Conforme a Figura 6 a implementação inicia-se com o processo de ETL carregando os
dados em um ou mais DM. Finalizando a construção dos DMs, passaria para a transferência das
informações para um DW geral.
Segundo Machado (2000), um dos grandes problemas desta implementação mesmo com a
independência dos DMs, é a falta de um gerenciador que garanta padrões únicos de metadados.
Essa dificuldade em garantir a padronização é responsável pelas possíveis falhas na elaboração
incremental do DW. Porém, esta dificuldade em garantir a padronização pode ser minimizada por
um planejamento, monitoração e estabelecimento de regras de desenvolvimento. Outro ponto que se
deve prestar atenção é a criação de DMs independentes, ou seja, se transformam em legados
dificultando futuras integrações. Também é necessário que se mantenha um rígido controle do
negócio como um todo. Este controle requer um maior trabalho ao extrair e combinar as fontes
individuais do que utilizar um DW. Como pontos positivos podem ser citados a construção do DM
que é altamente direcionada. Além disso, a estratégia do DM incremental obriga a entrega de
recursos de informações passo a passo permitindo à equipe crescer e aprender, reduzindo os riscos.
Já a implementação do tipo Top-Down segundo Oliveira (2002), é utilizada quando a
empresa cria um DW e depois o transforma em pequenos DMs.
29
A implementação Top-Down requer um maior planejamento e também necessita que as
definições conceituais de tecnologia estejam bem claras antes de se iniciar um projeto de DW. Esta
implementação tem como vantagem a herança da arquitetura, ou seja, todos os DM originados a
partir de um DW utilizam a arquitetura e os dados desse DW, a visão de empreendimento e o
controle e centralização de regras são outros pontos positivos, pois garantem a existência de um
único conjunto de aplicações para o processo de ETL. Já como desvantagem apresenta
implementações muito longas, além disso, não existem garantias para o investimento neste tipo de
ambiente, é necessária também uma boa equipe de desenvolvimento e usuários finais, para avaliar
as informações consultadas. O processo desta implementação é demonstrado na Figura 7
(MACHADO, 2000).
Figura 7. Implementação Top-Down
Fonte: Machado (2000).
Conforme a Figura 3 a implementação inicia-se com o processo de ETL carregando os
dados em um armazenamento intermediário também chamado de Operational Data Storage (ODS)
que segundo Inmon e Hackarthorn (1997) diz que o ODS é uma extensão do DW ao mundo dos
ambientes operacionais. Também oferece as bases para se atingir resultados operacionais tangíveis
e integrados num espaço de tempo razoavelmente curto, ou seja, tem por objetivo facilitar a
30
integração dos dados do ambiente operativo antes de sua atualização no DW. Em seguida os dados
e informações são transferidos para o DW e conseqüentemente extraídos para os DMs.
E por fim na implementação combinada segundo Machado (2000), tem o propósito de
integrar a arquitetura bottom-up com a top-down. A modelagem de dados do DW é efetuada com
uma visão macro, segue-se então à implementação de partes deste modelo, escolhidas por áreas de
interesse e que passam a constituir os DM´s. Todos os DM’s gerado a partir do macro modelo de
dados do DW é integrado ao modelo físico do DW. A principal vantagem é a garantia da
consistência dos dados demonstrada na Figura 8, esta garantia é obtida em virtude do modelo de
dados ser único para os DM’s, possibilitando realizar o mapeamento e o controle dos dados.
Figura 8. Implementação Combinada
Fonte: Machado (2000).
Este trabalho utilizou o modelo de implementação bottom-up, pois o desenvolvido foi
focado a um único assunto do negócio da empresa.
2.4.5 On-Line Analytical Processing
31
A tecnologia On-Line Analytical Processing (OLAP) é um termo inventado para descrever
uma abordagem dimensional para o suporte à decisão (KIMBALL, 1998). Essa tecnologia tem por
objetivo transformar dados em informações úteis ao suporte de decisões gerenciais, de forma
amigável e flexível ao usuário e em tempo hábil. Essas informações são demonstradas nas tabelas
2D e 3D, mapas e gráficos.
Através de consultas OLAP os usuários podem analisar os relacionamentos entre as
categorias de dados e procurar padrões, tendências e exceções (TURBAN, RAINER & POTTER,
2005), ou seja, através das análises realizadas pelas consultas, o gestor pode definir projeções ou
estratégias em cima do assunto relacionado da consulta.
A principal característica do OLAP é a análise multidimensional, que se resume na
visualização de cubos de informações de diferentes ângulos (usando a tecnologia de Slice and
Dice), e de vários níveis de agregação (usando a tecnologia Drill Down e Roll Up) (OLIVEIRA,
2002).
Cubo nada mais é do que uma aproximação da forma como os dados estão organizados, ou
seja, o objetivo é transmitir ao usuário a idéia de múltiplas dimensões. Essas dimensões determinam
o contexto de um assunto de negócios (MACHADO, 2000).
A tecnologia Drill Down e Roll Up consiste em fazer pesquisas em diferentes níveis de
detalhe das informações (OLIVEIRA, 2002). Com o Drill Down o usuário pode navegar do mais
alto nível até o dado detalhado. Já o Roll Up o usuário pode navegar do nível de detalhe até o mais
alto nível de sumarização de dados, a Figura 9 demonstra está etapa (MACHADO, 2000).
32
Figura 9. Tecnologia Drill Down e Roll Up
Fonte: Machado (2000).
Através da tecnologia Drill Down e Roll Up demonstrada pela Figura 9, o usuário pode
efetuar sua análise no nível mais alto de agregação, e então aprofundar a pesquisa passando pelos
diferentes níveis até o nível inferior de detalhe a fim de obter uma perspectiva diferente do que
compôs os valores do nível mais alto.
A tecnologia Slice and Dice tem como objetivo possibilitar a transmissão das informações
em diferentes ângulos (OLIVEIRA, 2002).
2.4.6 Modelagem Multidimensional
Segundo Machado (2000), a modelagem multidimensional é uma técnica de concepção e
visualização de um modelo de dados de um conjunto de medidas que descrevem aspectos comuns
de negócios. É utilizada especialmente para sumarizar e reestruturar dados e apresentá-los em
visões que suportem a análise dos valores desses dados. Três elementos básicos fazem parte de um
modelo multidimensional:
• Fato: é uma coleção de itens de dados, composta de dados de medidas e de contexto. Cada
fato representa um item de negócio, uma transição de negócio ou um evento de negócio, e é
utilizado para analisar o processo de negócio de uma empresa;
33
• Dimensão: é o elemento que participa de um fato, assunto de negócio. Normalmente não
possuem atributos numéricos, pois são somente descritivas e classificatórias dos elementos
que participam de um fato. Conforme a Figura 10, quatro perguntas básicas podem ser
utilizadas para descobrir as dimensões de uma tabela fato, são elas: “onde?”, “quando?”,
“quem?”, “o quê?”. Já Oliveira (1998), relata que uma dimensão é uma reunião de membros,
todos eles de um tipo semelhante; e
Figura 10. Dimensões comuns em um modelo dimensional
Fonte: Machado (2000).
• Medida: é o atributo numérico que representa um fato. Medida é fundamental na criação de
um fato, pois através dela se pode alcançar o desempenho de alguma atividade, ou seja,
representa o desempenho de um indicador de negócios relativo às dimensões que participam
desse fato. Uma medida é determinada pela combinação das dimensões que participam de
um fato.
Segundo Oliveira (2002), os dados multidimensionais podem ser armazenados e
representados em estruturas relacionais, para isso é necessário utilizar formas específicas de
modelagem como o modelo “Estrela” e o modelo “Floco de Neve”.
O modelo Estrela é a estrutura básica de um modelo de dados multidimensional, este modelo
segundo Harrison (1998), possui quatro propriedades que o diferencia de outros modelos de projeto
de DW:
• Dentro de cada categoria, existe uma única tabela de fato;
• A chave primária da tabela fato contém somente uma coluna chave de cada dimensão;
34
• Cada chave é uma chave gerada pelo sistema; e
• Cada dimensão é representada por uma única tabela fato.
Sua composição típica conforme a Figura 10 é composta por uma tabela dominante no
centro que é conhecido como tabela de fatos, na Figura 11 está representada pela tabela com o
rotulo “FATOS VENDAS”, com múltiplas junções conectando-a a outras tabelas, sendo estás
chamadas de tabelas de dimensão, na Figura 10 estão representadas pelos rótulos “DIMENSÃO
TEMPO”, “DIMENSÃO PRODUTO” e “DIMENSÃO LOJA”. Cada uma das tabelas dimensão
possui apenas uma junção com a tabela fato.
Figura 11. Modelo dimensional do tipo Estrela
Fonte: Oliveira (2002).
Segundo Oliveira as vantagens do modelo estrela são as seguintes:
• Possui uma arquitetura padronizada e previsível;
• Todas as dimensões do modelo são equivalentes, ou seja, podem ser vistas como pontos de
entrada simétricos para a tabela de fatos;
• O modelo dimensional é flexível para suportar mudanças que possam ocorrer no projeto,
sem que surjam problemas nas aplicações que existiam antes das mudanças; e
• Está crescendo o número de utilitários administrativos e processo de software ser capazes de
gerenciar e usar agregados.
Já o modelo floco de neve emprega uma combinação de normalização da base de dados para
manter a integridade dos dados e reduzir os dados redundantes e a desnormalização para obter
35
maior desempenho. O modelo consiste em uma extensão do modelo estrela, ou seja, o modelo
contém tabelas dimensionais principais, que têm uma conexão lógica direta com a tabela fato
através de suas chaves primárias, e o diferencial está em poder conter tabelas menores como
extensões conforme a Figura 12, que são usadas para armazenar descrições e decodificações para
chaves e códigos nas tabelas maiores. As colunas de atributo de uma tabela dimensional principal
podem conter chaves para as tabelas extensões. As tabelas extensões são conectadas com a tabela
dimensional principal ou com outras tabelas extensões através de suas chaves primárias
(HARRISON, 1998).
Figura 12. Projeto lógico de banco de dados do modelo floco de neve
Fonte: Harrison (1998).
O modelo floco de neve é de fácil entendimento pelos desenvolvedores de sistemas OLTP,
pois aplica as formas normais como em um projeto relacional (MACHADO, 2000).
2.4.7 Extração de Dados
A extração de dados é uma das fases mais críticas de um DW, pois envolve a fase de
movimentação dos dados. Segundo Oliveira (2002), o processo de extração dos dados é realizado
geralmente em três etapas:
1. Definição das fontes e extração: As origens dos dados podem ser várias e também em
diferentes formatos. Antes de iniciar a definição das fontes e extração é necessário analisar
os seguintes fatores:
36
• A Extração de dados do ambiente operacional para o ambiente de DW demanda uma
mudança na tecnologia. Os dados são transferidos de bancos de dados hierárquicos
para uma nova tecnologia de SGBD (Sistema de Gerenciamento de Banco de Dados)
para DW;
• A seleção de dados do ambiente operacional pode ser muito complexa;
• Possível falta de documentação e do modelo de dados dos sistemas antigos;
• Os dados são re-formatados;
• Quando há vários arquivos de entrada, a escolha das chaves deve ser feita antes que
os arquivos sejam intercalados;
• Os arquivos devem ser gerados obedecendo à mesma ordem das colunas estipuladas
no ambiente de DW;
• Pode haver vários resultados, Dados podem ser produzidos em diferentes níveis de
resumo pelo mesmo programa de criação do DW; e
• Valores default devem ser fornecidos. Às vezes, pode existir um campo no DW que
não possui fonte de dados, então, uma solução encontrada é definir um valor padrão
para estes campos.
2. Transformação e limpeza dos dados: muitas fontes de dados possuem lixo e inconsistência,
por isso é necessário fazer limpezas sobre os dados para haver compatibilidade entre eles.
Além da limpeza, é necessário muitas vezes fazer transformação sobre os dados devido ao
problema de poderem estar em formatos diferentes; e
3. Carga dos dados: o processo de carga dos dados possui uma enorme complexidade, fatores
como a integridade dos dados e o tipo de carga dos dados (carga incremental ou carga por
cima dos dados) devem ser levados em conta.
37
2.4.8 Ciclo de projeto e desenvolvimento de um DW
Um projeto e o desenvolvimento de um DW, para ter sucesso, são necessários seguir uma
metodologia bem definida. Kimball et al (1998) demonstra na Figura 13 uma metodologia
composta por doze etapas de desenvolvimento e projeto de um DW.
Figura 13. Ciclo de Projeto do DW
Fonte: Kimball et al (1998).
Cada etapa demonstrada na Figura 13 Kimball et al (1998) pode ser traduzida da seguinte forma:
1. Planejamento do projeto: nesta etapa é feito todo o planejamento da construção do DW. É
um processo bastante crítico, pois qualquer erro na identificação das necessidades ou na
especificação dos recursos pode inviabilizar a continuação do projeto. É uma etapa com
diversos estágios a serem levantados e estudados, tais como: estudo sobre a empresa
(objetivos, visão, missão, política, organograma, fluxograma e regras de negócio), definição
38
do escopo do trabalho, equipe que irá elaborar o projeto e os fatores críticos que poderão
impossibilitar o sucesso do projeto;
• Definição dos requisitos de negócio: nesta etapa faz-se a identificação dos requisitos
(funcionais e não funcionais), levantando de forma detalhada as necessidades dos usuários e
analisando as mesmas;
• Projeto da arquitetura técnica: nesta etapa o principal objetivo é definir a arquitetura e a
infra-estrutura tecnológica necessárias para suportar a implementação do processo de DW.
Para se definir o mesmo é necessário considerar as regras de negócio e a área técnica;
• Seleção e instalação do produto: o objetivo desta etapa é definir os produtos necessários, tais
como: SGBD, ferramenta OLAP e plataforma de hardware. É importante lembrar que antes
de desenvolver a etapa de implantação desses produtos é necessário testar e avaliar os
mesmos;
• Modelagem dimensional: a definição dos requisitos determina os dados necessários às
exigências analíticas dos negócios. Faz-se também uma análise para identificar o fato, as
dimensões e a granularidade que representam à situação relatada e em seguida constrói-se o
modelo dimensional;
• Projeto físico: nesta etapa a modelagem dimensional precisa ser traduzida em um projeto
físico, ou seja, apesar de serem semelhantes no modelo físico são detalhados os tipos de
dados, chaves, índices, seleção do SGBD, estimativa do volume de dados e o projeto inicial
de agregados;
• Desenvolvimento e projeto da área de transição: essa etapa é um dos processos mais críticos
no projeto de um DW, pois esta etapa preocupa-se em como implementar eficientemente o
processo de ETL. Este processo está descrito com mais detalhe na Seção 2.4.5, ou seja, este
processo tem a responsabilidade de fazer a extração, transformação e carga dos dados a
partir de uma ou mais fontes de dados;
• Especificação da aplicação do usuário final: após a definição dos requisitos, devesse rever as
constatações e os exemplos de relatórios coletados para identificar a aplicação inicial;
• Desenvolvimento da aplicação do usuário final: Esta etapa deve começar depois que o
projeto de banco de dados esteja completo. Onde as ferramentas OLAP e os metadados
estejam instaladas;
39
• Implantação: nesta etapa de implantação do conjunto do DW é importante estabelecer um
pacote de treinamento e suporte aos usuários. Esse pacote deve se concentrar no produto
completo do DW, ou seja, esse treinamento deve incluir: o reconhecimento dos dados,
aplicações analíticas e a ferramenta de acesso a esses dados;
• Manutenção: Após a etapa de implantação é necessário continuar o investimento de recursos
nas áreas de: suporte, treinamento, suporte técnico e suporte a programação. Todo esse
investimento tem como objetivo verificar se realmente as necessidades que existiam antes
do projeto estão sendo atendido, o número de acessos e se o processo de atualização dos
dados está em uma escala de tempo adequada com a necessidade atual; e
• Gerenciamento do Projeto: nesta etapa ocorre a preparação para possíveis
desenvolvimentos. O ciclo de vida de um projeto de DW requer a integração de recursos e
tarefas que devem ser realizadas em paralelo e no tempo certo para obter sucesso. Além
disso, esta etapa tem a responsabilidade de gerenciar o escopo e cuidar de toda a
documentação.
2.5 TRABALHOS RELACIONADOS
Para auxiliar no entendimento do problema, foram realizadas pesquisas sobre trabalhos que
se relacionavam com o tema em questão. Ao final destas pesquisas, três trabalhos merecem
destaque, pelo motivo de tratarem de temas importantes deste trabalho, como: criação de um DM
para o departamento de compras, utilização da metodologia de Kimball et al (1998) e o uso das
ferramentas da Oracle para criação e desenvolvimento de um DM.
O trabalho de graduação de Espírito Santo (2005), sobre o título “Construção de um Data
Mart para apoio às tomadas de Decisão das empresas Proembarque e Casacon”. O trabalho objetiva
a construção de um sistema de apoio à decisão, implementado através de um DM, para atender as
necessidades gerenciais dos departamentos de compras e logística das empresas Proembarque e
Casacon. Essas duas empresas trabalham em conjunto, sendo que a primeira faz a exportação dos
produtos comprados no Brasil e que são comercializados pela segunda, que fica localizada em
Angola. Os pedidos de compra originados pela Casacon não levam em consideração uma análise
histórica das vendas por período e o tempo de reposição do estoque. O contexto apresentado
evidencia a necessidade de alguma ferramenta que possa auxiliar os executivos no processo de
40
tomada de decisões, de maneira a minimizar os custos de transporte e armazenagem, bem como
maximizar os resultados das vendas.
Outro trabalho é o do Centenaro (2003), sobre o título “Desenvolvimento e implantação de
um Data Warehouse corporativo com Data Marts distribuídos em uma cooperativa agroindustrial”.
O mesmo objetiva o desenvolvimento e implantação de um Data Warehouse corporativo com Data
Marts distribuídos a serem utilizados por empresas que tenham a necessidade de implementação de
um sistema de apoio a decisão. O teste do projeto foi executado na cooperativa agroindustrial C.
Vale, onde o principal problema estava concentrado no problema da centralização das informações.
Para tanto, foi necessário efetuar a integração dos diferentes bancos de dados como DMSII,
Microsoft SQL Server, Interbase e Firebird. Uma semelhança encontrada em relação ao trabalho
proposto é a utilização da abordagem de implementação incremental do Kimball et al (1998).
Já o trabalho de Santos (2003), sobre o titulo “Data Warehouse como ferramenta de auxílio
em sistemas de monitoramento ambiental”, possui uma semelhança ao proposto neste trabalho. O
mesmo objetiva o desenvolvimento e implantação de um Data Warehouse corporativo com a
finalidade de suprir a necessidade de inter-relacionar dados ambientais, de modo a encontrar
relações de conformidades e facilitar a manipulação do conjunto de dados coletados nas análises
ambientais. O resultado foi a construção de um protótipo de Data Warehouse para o problema
ambiental do projeto SIBAC, entretanto não foi totalmente finalizado, é necessário a criação da
ferramenta de front-end. Uma semelhança encontrada em relação ao trabalho proposto é a utilização
do banco de dados Oracle, uma diferença se encontra na versão do Oracle. A principal dificuldade
encontrada pelo trabalho refere-se ao domínio das ferramentas de criação e manipulação do DW,
onde o mesmo afirma que apesar da tecnologia ter sido desenvolvida, as ferramentas de criação,
extração, transformação e carga dos dados não possuem uma interface amigável para o usuário.
Com o estudo desses trabalhos, pode se obter idéias de como implementar um sistema de
apoio a decisão em um departamento de compras tendo como base os aspectos positivos e negativos
dos mesmos. O desenvolvimento proposto por este projeto utilizou os componentes OLAP sobre
um DM que conforme o trabalho de Espírito Santo (2005) ao final de seu desenvolvimento foi
possível testa-los junto aos gestores das empresas Proembarque e Casacon e concluiu que a
utilização dos mesmos juntamente com uma modelagem adequada ao perfil do problema em
questão pode trazer grandes benefícios. Para se desenvolver uma solução de DM, se procurou por
metodologias que auxiliasse de forma adequada esse desenvolvimento, ou seja, que fornecesse
41
etapas bem definidas, com o estudo sobre o trabalho do Centenaro (2003), observou-se que a
metodologia de desenvolvimento do DM utilizada pelo mesmo ao final de seu trabalho se
apresentou como uma forma eficaz para a criação e desenvolvimento do mesmo, portanto este
projeto usou esta metodologia visto a sua eficiência e por ser uma metodologia de um autor
importante quando se trata do assunto de DM.
Segundo esta metodologia é importante o uso de ferramentas para auxiliar no processo de
criação, desenvolvimento e manipulação do DM, para tanto a empresa Pauta utiliza os produtos da
linha de produtos da Oracle, para se obter o conhecimento de que ferramentas da linha de produtos
da Oracle podem ser utilizadas para dar suporte a este projeto foi preciso fazer uma identificação
das ferramentas utilizadas por outros projetos dessa linha de estudo. O trabalho de Santos (2003),
proporcionou um ponto de partida para se levantar as ferramentas da Oracle necessárias para o
desenvolvimento e criação de um DM, o seu trabalho utilizou as ferramentas da Oracle de versão
diferente aos disposto por este projeto, como ponto positivo é relatado que as ferramentas da Oracle
conseguem proporcionar o que se espera de uma solução de sistemas de apoio a decisão, apesar que
no seu trabalho ficou claro que os aspectos de usabilidade das ferramentas de transformação dessa
linha de produtos não são tão adequadas a usuários que não possuem experiência nesse tipo de
assunto. Portanto, para a construção deste trabalho se usou os produtos da linha de produtos da
Oracle, porém não se adotou as ferramentas de transformação que a Oracle dispõe visto a
dificuldade demonstrada pelo Santos (2003), para efetuar as transformações se utilizou de stored
procedures onde já se possui um conhecimento suficiente para efetuar as transformações
necessárias sobre os dados.
3 DESENVOLVIMENTO
Esse capítulo apresenta de forma detalhada o processo do desenvolvimento de um Data
Mart para a área de compras da empresa Pauta Distribuidora, com o objetivo de disponibilizar aos
gestores um ambiente integro e com acesso rápido às informações estratégicas no processo de
tomada de decisão da área de compras.
3.1 METODOLOGIA DE DESENVOLVIMENTO
O modelo do ciclo de projeto de DW/DM proposto por Kimball et al (1998), foi utilizado
como referência para o desenvolvimento e implementação de um DM para área de compras da
empresa Pauta Distribuidora, devido ao sucesso de sua utilização em projetos semelhantes. Para
uma melhor adequação a este trabalho, foi realizada uma adaptação do modelo do ciclo de projeto
de DM conforme Figura 14, retirando três etapas da metodologia original, gerenciamento do
projeto, manutenção e implantação, pois este trabalho visa desenvolver um protótipo de um DM.
Também foi incrementado uma etapa, teste e validação, que tem por objetivo testar o protótipo
realizado por este trabalho.
Figura 14. Metodologia de desenvolvimento
Fonte: Adaptação de Kimball et al (1998).
A seguir são apresentados os detalhes que compreendem cada etapa dessa metodologia de
desenvolvimento.
43
3.1.1 Planejamento
O planejamento de um DM objetiva avaliar as necessidades da organização/gestor com as
suas respectivas metas no ambiente onde o projeto será desenvolvido. Nesta Fase é definido qual
área ou assuntos do negócio serão atendidos ou priorizados de acordo com a sua importância dentro
da organização e os respectivos profissionais envolvidos.
O planejamento foi realizado seguindo as seguintes etapas:
1. Estudo da empresa e a definição da área de compras que será atendida por este projeto;
2. Identificação do organograma desta empresa/área;
3. Identificação dos profissionais envolvidos pelo projeto;
4. Identificação do fluxograma geral da área de compras;
5. Identificação das regras de negócio; e
6. Identificação de fatores que poderão impossibilitar o sucesso do projeto.
Para efetuar o estudo sobre a empresa (Pauta) que será foco deste projeto, foi necessário
levantar e entender os aspectos básicos da empresa: objetivos, política, missão e visão da empresa.
Conforme o manual de qualidade da Pauta (2007):
• Visão: crescer buscando estabelecer um novo conceito nas relações cliente-empresa, sendo a
primeira opção em soluções em informática na região sul do Brasil;
• Missão: ser uma empresa de soluções em informática que atenda as necessidades do
mercado na região sul do Brasil, oferecendo qualidade a preços competitivos e serviços
inovadores aos nossos revendedores varejistas e corporativos;
• Política: melhorar continuamente os processos ofertando soluções em informática a nossos
clientes, promovendo a sua satisfação; e
• Objetivo geral: Aumentar o faturamento em 5% em relação ao semestre anterior e atingir no
mínimo 80% da satisfação dos clientes internos e externos.
44
No inicio do projeto devido a dificuldade de estar com o pessoal envolvido pela área de
compras, foi solicitado que se desenvolvesse um questionário para facilitar o inicio do processo,
após a realização e aplicação do questionário, para complementar o estudo foi utilizado a
metodologia de JAD. A partir das entrevistas com os gestores, foi possível detectar uma carência de
informações na área de compras, justamente no processo de compra. O escopo inicial deste projeto
tem como foco prover meios de auxiliar os gestores da área de compra a entender os fatos que tem
ocasionado a quebra de estoque.
Para tanto, foi realizado um estudo sobre a área de compras da empresa (Pauta). Nesse
estudo, foram levantados e estudados os manuais e procedimentos do departamento de compras, os
mesmos seguem no ANEXO II, com o objetivo de entender os processos de uma forma mais ampla.
Para ter uma visão mais detalhada sobre os procedimentos e características deste
departamento, foi necessário efetuar um levantamento do organograma da empresa, fazendo foco no
departamento de compras conforme Figura 15, para identificar quais cargos e as pessoas chaves
para os mesmos, para posteriormente aplicar as entrevistas e questionários.
45
Figura 15. Organograma do departamento de compras
Fonte: Manual de Qualidade da Pauta (2007).
O organograma do departamento de compras, demonstrado na Figura 15, torna possível
visualizar os membros da alta administração que compõem o grupo de gestores, que decidem o que
fazer no processo de compras, são eles: o diretor de compras e o gerente de compras. Os
funcionários pertencentes a esses dois níveis de cargos serão envolvidos por este projeto.
Os envolvimentos do diretor de compras, da gerente de compras e da equipe técnica se
constituem como fatores críticos de sucesso, possibilitando ou não o cumprimento dos prazos e
atividades desempenhadas.
Foi preciso identificar o fluxograma da área de compras para levantar as regras de negócio
do departamento de compras, o mesmo segue na Figura 16.
46
Figura 16. Fluxograma geral da área de compras da Pauta
Através das entrevistas efetuadas com os profissionais envolvidos por este projeto, do
fluxograma do departamento de compras demonstrado pela Figura 16 e do estudo realizado no
manual de procedimentos da área de compras da Pauta, foi possível levantar e entender as regras de
negócio do departamento de compras conforme o estudo contido no APÊNDICE B. As principais
regras de negócio são:
• As compras são realizadas apenas pela matriz (modelo central de compras);
• As compras são realizadas através de projeções de disponibilidade do produto, para tal os
compradores utilizam o relatório de programação de compra conforme ANEXO I;
47
• Levar em consideração o tempo (prazo para disponibilizar o produto, tempo de transporte);
• Verificar se existe meta do produto antes de efetuar o pedido;
• Os relatórios de programação de compras devem ser gerados diariamente, com o intuito de
identificar inconformidades no estoque;
• A quantidade a ser adquirida de um produto leva em conta uma margem de erro;
• Verificar antes de efetuar o pedido a relação de valor mínimo de frete pago pelo fornecedor
e o valor mínimo do pedido;
• A previsão de chegada do produto somente é determinada após a confirmação de
faturamento do fornecedor e a data de previsão de entrega é estipulada conforme a Equação
1;
• Verificar a existência de histórico de vendas, se houver usá-lo no processo de decisão caso
contrário é realizado um estudo do mercado;
• Antes da aquisição do produto é necessário verificar o espaço físico para alocar o mesmo;
• Verificar antes da compra se existem descontos especiais relacionados à quantidade
adquirida, forma de pagamento, promoções e produtos que saíram de linha;
• O departamento financeiro sinaliza para o departamento de compras quanto a
disponibilidade de recursos em caixa está abaixo do padrão determinado pelos gestores;
• Valor acima dos limites normais de compra é necessário verificar se existe saldo em caixa e
justificar;
• É necessário verificar se o estoque está inferior ou superior às projeções de disponibilidade
do produto;
• Verificar antes de efetuar o pedido de compra se houve transferência de produtos;
• É necessário verificar o prazo e o procedimento de garantia e os acordos com seus
fornecedores;
48
• Verificar se o tempo de permanência do produto no estoque está de acordo com as previsões
de venda;
• No caso de produtos com alto índice de garantia, o mesmo deve ser averiguado junto aos
gestores do departamento de compras; e
• Mercadorias que forem entregues a Pauta com não conformidade devem ser averiguadas
junto ao fornecedor.
O posterior acompanhamento e gerenciamento do projeto também se constituem em um
fator indispensável à utilização, manutenção e crescimento do DM dentro da empresa.
3.1.2 Definição dos requisitos de negócio
Esta fase tem por objetivo definir os requisitos de negócio, entretanto, para se alcançar os
requisitos, foi necessário seguir as seguintes etapas:
1. Levantar as necessidades dos profissionais envolvidos por este projeto;
2. Identificar e analisar o problema; e
3. Especificar os requisitos de negócio.
Para realizar o levantamento das necessidades dos profissionais envolvidos por este projeto,
foi necessário preparar reuniões com os mesmos. Estás reuniões foram preparadas segundo a
metodologia JAD (Join Application Design), ou seja, primeiro foi definido o escopo e os objetivos
com seu respectivo cronograma, após a definição do projeto foi realizada uma pesquisa explorando
de forma mais detalhada o domínio do problema e os requisitos dos usuários. Ao final se obteve
uma lista de assuntos que foram decididos durante as sessões. Para realizar as sessões foi criada
uma apresentação visual, onde foi apresentado para todo o pessoal envolvido pelo projeto
(Presidente, diretor de compras e o gerente de compras). Após a finalização das sessões foi criado
um questionário harmônico as questões discutidas pelas sessões. Esse questionário segue no
APÊNDICE A. Através do estudo de todo o material e conhecimento adquirido pelas sessões do
JAD foi possível detalhar os processos do departamento de compras, onde surgiu o documento que
segue no APÊNDICE B.
49
Após efetuar uma mescla das necessidades levantadas junto aos profissionais envolvidos por
este projeto e com as pessoas que possuem um grande conhecimento do processo de compra,
concluiu-se junto com os gestores, que o problema do departamento de compras está em decidir o
que e o quanto adquirir de um determinado produto para uma determinada filial. Porém, para
alcançar este nível de conhecimento se definiu que primeiramente é necessário ter meios de se
identificar e visualizar os fatos que ocasionam as possíveis quebras de estoque, que acontece
durante todo o processo de compra.
Esta quebra de estoque referenciado pelos gestores, é vista como um fato que engloba
diversos departamentos da empresa em questão. Englobando os departamentos de compras, vendas,
transporte, garantia e até mesmo os fornecedores. Uma quebra de estoque pode ser definida como
um fato de não ter estoque para atender as necessidades de vendas e garantias da empresa ou ainda
quando se tem um grande nível de estoque armazenado sem necessidades.
Entretanto, foi necessário efetuar uma análise do problema em questão para melhorar a
compreensão sobre o mesmo, definindo metas, restrições, as entradas e saídas do sistema, ou seja,
uma compreensão geral do que o sistema precisa prover.
Nas entradas estão as pessoas (atores) que estão envolvidas nos processos e
conseqüentemente os possíveis agentes que podem interferir nos processos. Sendo assim foi
subdividido as entradas em: atores, processos, agentes.
Ator é alguém ou alguma coisa que interage com o sistema. A partir desta definição foi
definido que os atores do problema relatado por este projeto são: diretor de compras, gerente de
compras e o gerente de produtos.
Os processos envolvidos no problema são: juntar filiais, montagem da programação de
compras e a programação de compras.
Os agentes são os fatos que podem interferir nos processos que foram citados anteriormente,
podem existir fatores internos na empresa, tais como: transferências, devoluções, garantias, vendas,
filiais, compras, reservas, tempo e produto. Também podem existir fatores externos à empresa com
capacidade de afetar os processos, tais como: sazonalidade, fornecedor, capacidade de entrega do
fornecedor, disponibilidade do produto e o seu tempo de entrega.
50
A saída é o resultado que se obtém, sendo assim foi definido que os atores vão ter para suas
tomadas de decisão as informações das possíveis quebras de estoque, e conseqüentemente poderá
influenciar no processo de compra no que e o quanto comprar de um determinado gênero de
produtos.
Na especificação dos requisitos são definidos os requisitos funcionais e não funcionais. Os
requisitos não funcionais são aqueles que expressam como o produto deve ser. Em geral se
relaciona com os padrões de qualidade como confiabilidade, performance, robustez, entre outros.
Desta forma os requisitos não funcionais deste projeto são:
• O sistema deverá utilizar o banco de dados Oracle;
• O sistema (cliente) deverá ser executado na plataforma Microsoft e o servidor na plataforma
Linux; e
• As informações contidas no sistema deverão ser atualizadas diariamente.
Já os requisitos funcionais especificam o que o produto deve fazer. Os requisitos funcionais
deste projeto estão listados na Tabela 2.
51
Tabela 2. Requisitos Funcionais
Nº Descrição do requisito Rastreabilidade 1 A partir dos dados históricos das compras e das vendas
darem condições ao gestor de analisar o seu estoque (se está adequado, se tem ou não perdido vendas).
Quantidade de compras por via aérea, marítima, terrestre e não definida, quantidade de vendas e variáveis relacionadas com a programação de compra.
2 Avaliar o estoque levando em consideração a garantia e/ou transferência, ou seja, demonstrar ao gestor o índice de transferências entre unidades (filiais) de um determinado produto, para que o gestor possa ajustar as suas compras. Já as garantias o gestor precisa saber qual é o índice de garantia para um determinado produto, caso o índice esteja muito elevado o gestor pode decidir em descontinuar a comercialização deste produto.
Quantidade de garantias de entrada e saída, quantidade de transferências de entrada e saída.
3 Permitir avaliar a qualidade da venda x quantidade comprada (transferência, tempo de permanência do produto em estoque, custo do estoque, entre outros).
Quantidade de compras aérea, marítima, terrestre e não definida, quantidade de vendas, quantidade de reservas, quantidade de estoque e quantidade de transferências de entrada e saída.
4 Avaliar o estoque segundo a sazonalidade x tecnologia, ou seja, verificar eventos de uma determinada época que possa ocasionar uma mudança na quantidade e o produto a ser comprado (natal) e também verifica a cultura de tecnologia que uma determinada região possui, para que o gestor possa comprar o produto certo para cada filial, e com as características corretas.
Quantidade de vendas e a quantidade de reservas.
5 Avaliar a qualidade histórica das entregas, ou seja, checar se o produto está sendo entregue no momento combinado e se está sendo entregues sem avarias.
Pedido e nota fiscal.
6 O DM deve ser capaz de fornecer o estoque e as médias de garantia1, vendas, compras, devoluções, transferências e reserva de um determinado produto em um determinado mês (históricos2) e em uma determinada unidade.
Quantidade de compras aérea, marítima, terrestre e não definida, quantidade de venda, quantidade de reservas, quantidade em estoque, quantidade de transferências de entrada e saída, quantidade de garantias de entrada e saída, e quantidade de devoluções de entrada e saída.
7 O sistema deve ser capaz de fornecer médias de quanto não foi possível vender de um determinado produto devido uma quebra de estoque em um determinado mês (históricos) e em uma determinada unidade.
Variáveis da programação de compra.
8 O sistema deve ser capaz de demonstrar aos gestores as sazonalidades.
Índice de vendas.
52
3.1.3 Modelagem dimensional
Nesta etapa foi definido o modelo dimensional para os objetivos que foram levantados na
etapa anterior. Para que se possa obter um modelo adequado aos objetivos é necessário definir a
granularidade do DM e conseqüentemente os três elementos básicos do modelo, são eles: fato,
dimensões e medidas.
A definição da granularidade do DM foi realizada através dos resultados que são esperados
para este projeto. Para tanto, os níveis de detalhes definidos para o DM são: filial, tempo, produto, o
tipo de transporte e as características do produto.
As dimensões que compõem a tabela de fato surgem automaticamente após termos definido
a granularidade do modelo de DM. As mesmas são identificadas e apresentadas na Tabela 3.
Tabela 3. Dimensões
Dimensão Descrição
Filial Dimensão que contém o nome das diversas filiais da empresa Pauta.
Grupo Dimensão que contém a categoria do produto.
Produto Dimensão que contém a caracteristica do produto, tais como modelo, tipo e marca.
TempoDimensão que contém os tipos de tempo para este modelo será necessário ser medido em ano, mês e dia.
As medidas são fundamentais na criação de um fato, pois é através dela que se pode alcançar
o desempenho de alguma atividade relacionada às dimensões do fato. As medidas necessárias para
satisfazer as necessidades dos requisitos levantados anteriormente são demonstradas na Tabela 4.
53
Tabela 4. Medidas
Medida Descrição
Quantidade de Compra AéreaIndica a quantidade adquirida de um determinado produto por meio de transporte aéreo para uma determinada filial e para um determinado instante de tempo.
Quantidade de Compra MarítimaIndica a quantidade adquirida de um determinado produto por meio de transporte marítimo para uma determinada filial e para um determinado instante de tempo.
Quantidade de Compra TerrestreIndica a quantidade adquirida de um determinado produto por meio de transporte terrestre para uma determinada filial e para um determinado instante de tempo.
Quantidade de Compra não definidaIndica a quantidade adquirida de um determinado produto por meio de um transporte não identificado para uma determinada filial e para um determinado instante de tempo
Quantidade de VendaIndica a quantidade de um determinado produto que foram vendidos por uma determinada filial em um determinado instante de tempo.
Quantidade de Reserva Indica a quantidade de reserva de um produto para um determinado instante de tempo e para uma filial.
Quantidade de Transferência de EntradaIndica a quantidade de um determinado produto que entrou como transferência de uma determinada filial em um instante de tempo.
Quantidade de Transferência de SaídaIndica a quantidade de um determinado produto que saiu como transferência para uma determinada filial em um instante de tempo.
Quantidade de Garantia de EntradaIndica a quantidade de um determinado produto que entraram no estoque como garantia para uma determinada filial em um instante de tempo.
Quantidade de Garantia de SaídaIndica a quantidade de um determinado produto que sairam do estoque como garantia para uma determinada filial em um instante de tempo.
Quantidade de Devolução de EntradaIndica a quantidade de um determinado produto que os parceiros devolveram para uma determinada filial em um instante de tempo.
Quantidade de Devolução de SaídaIndica a quantidade de um determinado produto de uma filial em um instante de tempo que foram devolvidos aos seus fornecedores devido algum erro contido na nota fiscal
Quantidade de EstoqueIndica a quantidade de estoque de um produto para uma determinada filial e para um determinadoinstante de tempo.
54
As medidas definidas juntamente com as dimensões podem auxiliar em questão de análises
como a quebra de estoques e análises sobre o estoque, garantia, compra, venda e transferência de
produtos.
A partir das medidas e dimensões levantadas para atender os requisitos deste projeto, foi
possível desenvolver o modelo dimensional. Para efetivar o processo da modelagem foi necessário
o uso de uma ferramenta que suporte a construção de modelos dimensionais. Portanto se fez o uso
da ferramenta ERwin versão 3.5.2 da PLATINUM que efetivou o modelo demonstrado na Figura
17.
Figura 17. Modelo Dimensional
55
Conforme o modelo dimensional apresentado na Figura 17, a modelagem dimensional do
DM compõe de uma entidade central (tabela de fato) e quatro entidades menores (tabelas de
dimensão) arranjadas ao redor da tabela central. Esse modelo segue o padrão dimensional tipo
estrela, pois atende as quatro propriedades do modelo estrela apresentadas por Harrison (1998) na
Seção 2.4.6.
3.1.4 Projeto Físico
Após a finalização da modelagem dimensional são realizadas duas etapas, a primeira
consiste na criação da base de dados na área de estágio do DM no Oracle 10g e a segunda consiste
no mapeamento da área de estagiamento com o DM propriamente dito.
Para auxiliar no desenvolvimento da primeira etapa (criação da base de dados na área de
estagiamento), foi utilizada a função Forward Enginner/Schema Generation da ferramenta ERwin.
Essa funcionalidade dispõe de duas formas para se criar a base de dados do DM. A primeira gera
script em SQL para criar as tabelas com suas respectivas triggers, chave primária e secundária, a
segunda forma é através de uma conexão direta com o banco de dados, onde o próprio ERwin se
encarrega de criar a base diretamente no banco. Um exemplo do script criado pela ferramenta está
demonstrado no ANEXO III.
Foi utilizada a segunda forma para a criação física do DM. Após a criação, notou-se que o
modelo não atendeu as especificações do banco de dados Oracle 10g. Devido à dificuldade em fazer
que o modelo proposto interagisse de forma correta sobre o banco de dados, foi necessário procurar
exemplos de modelos que continham a tabela de tempo na versão do Oracle 10g. Após uma serie de
pesquisas, foi encontrado no site da Oracle um exemplo de um modelo que continha uma dimensão
tempo que se subdividia em ano, trimestre e mês. Este exemplo foi estudado e entendido, para então
redesenhar o modelo seguindo as exigências do banco de dados, conforme a Figura 18.
56
Figura 18. Modelo Dimensional DM para Oracle 10g
Seguindo o modelo da Figura 18 se recriou a base de dados. A Figura 19 ilustra o Data Mart
criado fisicamente.
57
Figura 19. Representação do Data Mart Físico no Oracle.
Após a finalização da primeira etapa foi mapeado as dimensões e a tabela de fato com o
DM. Foi utilizado para efetuar está etapa a ferramenta Analytic Workspace Manager (AWM),
58
Primeiramente é necessário criar um espaço analítico para alocar os mapeamentos do DM, o
mesmo foi realizado de acordo com o ANEXO IV.
Após a criação do espaço analítico, o sistema dispõe os menus, dimensões, cubos, pasta de
medidas, planos de cálculo e idiomas. As dimensões foram criadas através da opção criação
disposta pelo menu dimensão. O ANEXO V representa a criação da dimensão produto.
Na tela de criação da dimensão apresentada pelo ANEXO V, deve ser identificado um nome
a dimensão, o tipo da dimensão se é dimensão de tempo ou de usuário e também pode selecionar o
tipo de criação das chaves por meio de chaves substitutas ou por chaves naturais. Após esta criação
é necessário criar os níveis, hierarquias, atributos e mapeamento da dimensão. Foram criados os
níveis Grupo, Grupo margem de erro e produto, para a criação destes basta fornecer um nome e
uma descrição para os mesmos. Foi criada também a hierarquia “HIE_PRODUTO” conforme o
ANEXO VI.
Na criação da hierarquia é necessário definir um nome e selecionar os níveis que fazem
parte desta hierarquia, colocando os mesmos na ordem de hierarquia mais alta para mais baixa
conforme o ANEXO VI. Os atributos já são criados por default conforme o tipo de dimensão, a
ferramenta dispõe a criação dos seguintes tipos de atributos: intervalo de tempo, usuário, data final,
descrição longa e curta de membro e membro visível. Por fim, o mapeamento da dimensão foi
realizado de acordo com a Figura 20.
59
Figura 20. Mapeamento da dimensão produto.
Para realização do mapeamento deve-se selecionar o tipo do mapeamento (estrela, floco de
neve ou outros) e selecionar as tabelas de dimensão da base de estágio do DM. As demais
dimensões foram criadas da mesma forma que a dimensão produto. A única dimensão que possuí
peculiaridades é a dimensão de tempo que tem que ser criada como uma dimensão de tempo e
possui atributos específicos para esse tipo de dimensão como “END_DATE”, ”TIME_SPAN” e a
chave do nível superior à mesma.
Concluindo o processo de criação da área de estágio e o mapeamento das mesmas, foi
iniciado o processo de extração das informações da base de dados da Pauta e a carga no banco de
dados do DM, conforme será explicado na seção seguinte.
60
3.1.5 ETL
Nesta fase do projeto, a extração dos dados como visto na Seção 2.4.7 é subdividido nos
passos seguintes.
3.1.5.1 Definição das fontes e extração
Para efetuar a definição das fontes de dados da empresa Pauta foi necessário efetuar
entrevistas com o departamento de tecnologia, com a finalidade de levantar as bases de dados
existentes e as características das mesmas e os seus respectivos métodos de replicação de registros.
Foi levantado que a estrutura de dados da empresa é composta por seis bancos de dados, ou seja,
cada filial possui um banco especifico para as suas necessidades, com exceção de São José que
possui duas bases de dados, uma denominada São José e a outra Assistência. A base da Pauta sofre
replicações de registros de determinados assuntos das demais bases através de Jobs. A programação
destes está relacionada à execução de Stored Procedures, cujo conteúdo é relacionado as
atualizações de informações para a base Pauta. Este processo está demonstrado juntamente com o
processo de ETL na Figura 21.
Figura 21. Processo de ETL e replicações de registros
61
Foi preciso também efetuar um levantamento de todas as informações contidas na base de
dados da Pauta para selecionar as que estão relacionadas aos assuntos do DM proposto neste
trabalho. Após este levantamento foi possível concluir que a base de dados da Pauta é composta por
440 tabelas. A partir dessas informações, foi realizado um filtro que resultou em 28 tabelas que se
relacionam aos assuntos do DM proposto. A Figura 22 demonstra as 28 tabelas em um modelo
entidade relacional, as especificações de cada tabela estão apresentadas no ANEXO VII.
Figura 22. Modelo Entidade Relacional da Pauta
62
Na Figura 21 após o processo de replicação dos registros na base da Pauta, ocorre o processo
de extração das informações da base de dados de origem para uma área de estagiamento, que
segundo Inmon e Hackarthorn (1997) esta área é uma extensão do DW ao mundo dos ambientes
operacionais. Esta área tem como objetivo facilitar a integração dos dados, efetuando
transformações e padronizações para uma posterior carga no DM/DW.
A extração dos registros em informações para o DM, foi realizado através de Stored
Procedure executados através de Jobs programados para rodar diariamente. As Stored Procedure
criadas estão apresentadas no APÊNDICE C e os Jobs para executá-las no APÊNDICE D.
3.1.5.2 Transformação e limpeza dos registros
Após o processo de filtragem e extração dos registros para a área de estágio, foi necessário
efetuar uma condensação dos registros, pois a descrição de um produto é composta pela marca do
seu produto com o nome do seu grupo juntamente com a sua categoria. A dimensão Filial também
passa por um processo de condensação vinculando as diversas subunidades criadas para separação
de estoque em filiais propriamente ditas. Isso ocorre devido à necessidade de uma granularidade
mais alta, portanto a base de dados do DM possui um menor nível de detalhes sobre os assuntos
produto e filial.
No processo de transformação também foi necessário realizar um processo de conversão dos
registros. O atributo margem de erro da dimensão Grupo margem de erro na base de dados
operacional possui apenas um número como identificação que tem seu significado apenas definido
na aplicação da Pauta, o mesmo nesta fase foi substituído pelos seus significados.
No processo de limpeza de dados é necessário efetuar uma filtragem nos registros com a
finalidade de achar registros que possuem atributos nulos que possam ocasionar perdas de
informação ou gerar distorções graves. Na dimensão Grupo margem de erro foi verificado que
existem ocorrências de registros que possuem o atributo da dimensão margem de erro nulo.
Todos os processos de condensação, conversão e filtragem de dados são efetuados através
das Stored Procedure, criadas para efetuar o processo de extração das informações. As Stored
Procedure estão demonstradas no APÊNDICE C.
Esta fase contempla também a derivação de dados para formar informação ao gestor, como
campos de somatórios, médias ou qualquer outro tipo de campo seguindo esse estilo. Portanto, se
63
fez necessário criar medidas calculadas conforme Tabela 5 com a finalidade de expor ao gestor as
informações de forma mais ágil, fácil e útil.
Tabela 5. Medidas Calculadas
Medida Calculada Descrição
Entrada
As entradas são relacionadas a soma das medidas: compra aérea, compra marítima, compra terrestre, compra não definida, devolução de entrada, garantia de entrada e as transferências de entrada.
SaídaAs saídas são relacionadas a soma das medidas: devolução de saída, garantia de saída, transferência de saída e as vendas.
Valor total de compraÉ relacionado ao somatório sobre todos os tipos de compra (compra aérea, marítima, terrestre e não definida).
Percentual de garantia não atendida É relacionado ao número de garantias que entraram sobre o número de garantias que saíram.
Percentual de garantia sobre as vendas É relacionado ao número de garantias que entraram sobre a quantidade vendida do produto.
Percentual devolução para o fabricante sobre as compras
É relacionado ao número de devoluções feitas para o fabricante sobre a quantidade comprada pelo mesmo.
Percentual devolução de clientes sobreas vendas
É relacionado ao número de devoluções recebidas do cliente sobre a quantidade vendida do mesmo.
Percentual transferido para suprir as vendas da filial
É relacionado a quantidade transferida de um produto para suprir o número de vendas do mesmo.
Concluindo o processo de extração e transformações dos registros na área de estagiamento
do DM, foi iniciado o processo de carga das informações para a base do DM, conforme será
explicado na seção seguinte.
64
3.1.5.3 Carga dos dados
Esta é a última fase do processo de ETL, após ter executado as extrações, limpezas e
transformações nos registros, é necessário efetuar a carga dos resultados (informações) para o DM.
Para se efetuar uma carga em um cubo é necessário primeiramente efetuarmos as cargas de
suas dimensões, só então é possível efetuar o relacionamento com a tabela de fato. No processo de
carga de uma dimensão, primeiro é necessário verificar as alterações dos membros, em seguida se
verifica as hierarquias e posteriormente os atributos. Após estás verificações, é feita a carga das
alterações encontradas na etapa anterior. Todo o processo de carga de uma dimensão é composto
por três etapas distintas. O ANEXO VIII demonstra a primeira etapa do processo de carga da
dimensão Filial do modelo proposto neste trabalho na ferramenta Oracle Analytic Workspace
Manager 10.2.0.3.0A.
Na primeira etapa seleciona-se a dimensão, que no nosso exemplo é a dimensão Filial. A
segunda etapa é demonstrada pelo ANEXO IX, essa etapa define se a carga é do tipo incremental ou
não.
A opção “Delete dimension values that are no longer in the source tables” demonstrada pelo
ANEXO IX indica se a carga será incremental ou não. Quando a carga é incremental no processo de
carga se verifica apenas se existe uma nova informação a ser incrementada pela dimensão e quando
a carga não é do tipo incremental no processo de carga primeiro verifica-se a existência de
informações contidas na dimensão que não existe mais na área de estágio para posterior exclusão da
mesma. Após essa averiguação se verifica a existência de novas informações a serem incrementadas
pela dimensão. A terceira etapa é demonstrada pelo ANEXO X, nessa etapa é selecionado o
momento que a carga será executada.
Conforme o ANEXO X, a carga pode ser executada imediata ou ser programada para uma
determinada data/hora. Também se pode escolher a opção de salvar o script de carga em um
arquivo, onde o mesmo pode ser utilizado na criação de Jobs para execuções rotineiras. O Job para
esta rotina está apresentada no APÊNDICE D.
Por fim, após a terceira etapa a ferramenta retorna o resultado da carga de forma detalhada,
avisando se foi incluída ou excluída alguma informação de acordo com as características da carga.
O resultado devolvido pela carga da dimensão filial está demonstrado pela Figura 23.
65
Figura 23. Resultado da carga de uma dimensão
O resultado da carga da Figura 23 demonstra que foram incluídas seis informações na
dimensão Filial. Esse processo foi executado por todas as dimensões. Após a carga das dimensões
foi preciso dar início a carga da tabela de fato, para com isso formarmos a carga completa do cubo.
O processo de carga do cubo é semelhante ao da dimensão, vale ressaltar a segunda etapa
que possuí uma característica a mais do que a da dimensão, conforme o ANEXO XI.
De acordo com o ANEXO XI, esta etapa demanda duas opções de carga para o cubo:
1. Aggregate the cube for only the incoming data values: carregar para a tabela de fato
somente as informações que possuem valores; e
2. Aggregate the full cube: todas as informações serão carregadas para o cubo.
Para o trabalho proposto utilizamos à primeira opção, o resultado desse processo está
exibido na Figura 24.
66
Figura 24. Resultado da carga do cubo.
Conforme Figura 24, o processo de carga do cubo contempla a carga das medidas.
3.1.6 Projeto da arquitetura técnica
Segundo o manual da Oracle (2008), os requisitos de software e hardware do banco de
dados Oracle 10.2.0.1 para o sistema operacional Windows são conforme apresentados na Tabela 6.
Tabela 6. Requisitos do banco de dados Oracle.
ValorMemória Física (RAM) Mínimo 256MB e recomendado 512MB.Memória Virtual O dobro da quantidade de memória RAMEspaço em disco Instalação Básica 2,04GBAdaptador de Video Mínimo 256 CoresProcessador Mínimo 550MHzArquitetura Intel (x86), AMD64 e Intel EM64T
Sistema Operacional Windows 2000 com Service Pack 1 ou superiorWindows Server 2003Windows XP Professional
Protocolo de redeTCP/IPTCP/IP with SSLNamed Pipes
Hardware
Software
Requisito
67
Atualmente a Pauta dispõe de um servidor de banco de dados por filial, levando em
consideração que os gestores do departamento de compras estão localizados na matriz em São José,
como o servidor de São José abrange todos os requisitos vistos pela Tabela 6 o mesmo será
utilizado para armazenamento do Data Mart proposto neste trabalho.
3.1.7 Seleção e instalação dos produtos
Como a Pauta trabalha com o pacote de banco de dados da Oracle, o banco de dados que
será utilizado é a versão 10.2.0.1 da Oracle e a ferramenta de gerenciamento do Data Mart é o
Oracle Analytic WorkSpace Manager versão 10.2.0.3.0A.
3.1.8 Definição da ferramenta Front-End
Definiu-se utilizar a ferramenta de Front-End MS Excel 2003 da linha de produtos
Microsoft devido à familiaridade e o conhecimento dos gestores sobre a mesma. Além disso, os
computadores dos gestores já possuem esta ferramenta instalada.
Para o funcionamento do DM no MS Excel 2003 foi preciso instalar o plugin “Oracle OLAP
Spreadsheet Add-In 10.1.2.65.0” da Oracle. Após instalação o mesmo aparece na ferramenta do MS
Excel 2003 conforme Figura 25.
Figura 25. Plugin Oracle no MS Excel 2003.
68
A união do plugin com a ferramenta MS Excel propicia uma grande interação entre o
usuário e o cubo proposto por este trabalho, através de diversos tipos de gráficos que auxiliam o
gestor na compreensão dos dados dispostos nas consultas realizadas, a ferramenta ainda dispõe da
funcionalidade da tecnologia Drill Down e Roll Up e a tecnologia Slice and Dice ofertando ao
gestor uma maior interação com o cubo e conseqüentemente uma maior usabilidade.
Já existem versões posteriores da ferramenta MS Excel 2003, porém a versão do Oracle
utilizada neste projeto não dispõe de um plugin para as versões mais atuais do MS Excel.
3.1.9 Desenvolvimento da aplicação Front-End
Após se definir o software MS Excel 2003 como ferramenta de front-end, é necessário
explicar as funcionalidades da mesma.
Para se criar uma consulta OLAP nesta ferramenta é necessário seguir os seguintes passos:
1. Selecionar a opção do menu “OracleBI” e o submenu “Nova Consulta”;
2. Na tela de conexão com o banco de dados é necessário selecionar o nome da conexão e por
o nome do usuário e senha e por fim selecionar a opção “conectar”, caso não exista uma
conexão é necessário criá-la na aba editor de conexão onde se deve dar um nome a conexão
além do host, porta e SID do banco de dados;
3. No assistente de consulta do Oracle OLAP a primeira etapa deve-se selecionar as medidas e
dimensões a serem incluídas na visão que se deseja obter do cubo conforme Figura 26. Para
efeito de demonstração, foram selecionadas as dimensões de tempo, filial e produto, e as
medidas de garantia de entrada e saída, percentual de garantia não atendida e o percentual de
garantia sobre as vendas;
69
Figura 26. Primeira etapa da visão do cubo no front-end.
4. Na segunda etapa do assistente se deve selecionar o layout no qual as dimensões e as
medidas são organizadas na visão do cubo, conforme Figura 27. Para efeito de
demonstração, foi selecionada apenas a dimensão filial como item de página as demais
dimensões e medidas foram encaixadas na caixa de consulta;
70
Figura 27. Segunda etapa da visão do cubo no front-end.
5. Na terceira e última etapa, para cada dimensão se deve selecionar os membros de dimensão
a serem incluídos na visão do cubo, podendo impor condições de visualização sobre os
membros, conforme Figura 28. Para efeito de teste foram selecionados todos os membros da
dimensão tempo, porém com a condição de aparecer apenas o mês Janeiro de todos os
membros. Na dimensão produto foi solicitada a condição para conter apenas os membros do
tipo LCD de 15 polegadas e na dimensão filial foram apenas selecionados todos os
membros; e
71
Figura 28. Terceira etapa da visão do cubo no front-end
6. Após efetuar a terceira etapa basta selecionar a opção “Finalizar” para se obter a visão de
navegação sobre as informações selecionadas do cubo, conforme Figura 29.
Figura 29. Resultado da consulta do front-end.
72
Esta ferramenta também permite criar gráficos em cima das informações obtidas pela
consulta OLAP. Para construir um gráfico basta selecionar o menu “Inserir” e o submenu
“Gráfico”. O MS Excel dispõe de um assistente de criação do gráfico onde a primeira etapa se deve
selecionar o tipo do gráfico, a segunda etapa se deve selecionar os dados de origem, a terceira etapa
se seleciona as opções do gráfico como títulos, legendas e rótulos, e na quarta e última etapa se
seleciona o local do gráfico. Após concluir estas quatro etapas, basta selecionar a opção “Concluir”
que o MS Excel apresenta um gráfico conforme Figura 30.
Figura 30. Gráfico da consulta do front-end.
A ferramenta dispõe também da tecnologia Drill Down e Roll Up, essa tecnologia está
demonstrada pela Figura 29 com o símbolo de “+” nos registros que possuem nesta consulta essa
tecnologia.
As configurações do plugin da Oracle dispõem de características como ocultar linhas com
valores nulos ou para esses valores nulos também se pode dar um valor default para os mesmos.
73
Também se pode escolher a opção de visualizar os labels curtos ou longos e o caractere que
representará a tecnologia Drill Down e Roll Up.
3.1.10 Teste
A sessão de teste do modelo proposto por este projeto foi dividido em algumas etapas:
• Teste de carga dos dados;
• Teste de consistência dos dados; e
• Identificação e visualização dos fatos que tem ocasionado uma quebra de estoque.
A primeira etapa para efeito de teste foi criada uma simulação em cima das informações
contidas pela base operacional da Pauta. Esta simulação é composta por todas as dimensões e
medidas planejadas para este trabalho. Para efeito de teste as dimensões deverão conter:
• Dimensão tempo 1886 registros levando em base as datas do intervalo 01/JAN/2003 a
29/FEV/2008;
• Dimensão filial deverá conter seis registros levando em base que se quer obter apenas as
informações de São José, Porto Alegre, Curitiba, Goiânia, Assistência e Rio de Janeiro; e
• Dimensão produto deverá conter 73 registros.
De acordo com as informações acima, o cubo deverá efetuar uma carga de 826068 registros.
Após a carga do cubo foi possível verificar conforme Figura 31, que foi efetuada a carga dos
826068 registros comprovando que a quantidade de registros realizada pela carga do cubo está
correta.
74
Figura 31. Resultado da Carga do cubo
A segunda etapa de teste teve como objetivo averiguar a confiabilidade das informações
contidas pelas medidas do cubo. Para tanto, foi realizado um teste sobre a quantidade de venda dos
monitores LG de 15 polegadas do modelo LCD. Para efetuar este teste foi emitido um relatório via
sistema Pauta onde foi coletada a quantidade de 689 produtos vendidos no mês de junho de 2007
para a filial de São José, Conforme Figura 32.
Figura 32. Relatório de programação de compra
Foi construída uma consulta OLAP do DM para averiguar a mesma informação emitida pelo
sistema da Pauta, o resultado de acordo com a Figura 33, foi de 689 produtos vendidos também no
75
mês de junho de 2007 para a filial de São José, ou seja, as informações contidas no DM projetado
por este trabalho são consistentes.
Figura 33. Resultado da consulta vendas do front-end.
A terceira etapa que tem por objetivo a obtenção dos fatos que tem ocasionado as quebras de
estoque para efeito de teste, foi simulada a identificação dos fatos através da execução do front-end
com as medidas do cubo. O primeiro teste sobre este etapa foi sobre o percentual de produtos
transferido para suprir as necessidades de uma determinada filial, conforme Figura 34.
Figura 34. Percentual de produtos transferidos para suprir a necessidade de venda de uma filial
Conforme Figura 34, o percentual de transferência de produtos para suprir a necessidade de
venda de uma filial em 2007 e 2008 foi consideravelmente superior aos demais anos, em uma
76
primeira observação se verificou que os compradores tem comprado menos do que o necessário,
verificando o gráfico com uma maior nível de detalhe observou-se ainda que a filial de Goiânia
estava como um índice negativo e que as demais filiais estavam com um índice positivo, ao se
averiguar este caso junto aos gestores departamento de compras, os mesmos relataram que isso
ocorreu devido a abertura de uma nova Filial “Goiânia”, em que se acreditou em uma quantidade de
vendas superior a quantidade que tem se vendido desde a sua abertura. Porém esta visão de
transferências não se tinha tão definida até então, e esse elevado índice transferências retorna em
prejuízos para a empresa, pois o custo de se mover um estoque de uma filial para outra na empresa
Pauta é muito elevado. Após esta identificação os gestores poderão tomar ações para minimizar o
índice de transferência e consequentemente um menor prejuízo em transportes para a empresa.
Outro exemplo foi relacionado ao nível de garantia não atendida, demonstrada pela Figura
35.
Figura 35. Percentual de garantia não atendida
Analisando a Figura 35 observou-se que em 2005, 2006 e 2007 houve um elevado índice de
garantia que não foi possível atender. Visto estas informações com um maior nível de detalhe
observou que o grande problema estava em um determinado monitor de uma marca, porém os
gestores obtiveram essa informação somente em 2007, segundo os mesmos foi retirado esse produto
da sua linha de produtos e que o principal problema estava no fato que o fabricante não estava
conseguindo atender a demanda de garantia para aquele especifico tipo de produto.
77
Para averiguar se os requisitos de negocio foram atendidos pelo cubo proposto por este
projeto, foi efetuado alguns testes junto aos gestores do departamento de compras e como resultado
se obteve a Tabela 7.
Tabela 7. Requisitos Atendidos pelo modelo do cubo
A N P A N P A N P
1 A partir dos dados históricos das compras e das vendas darem condições ao gestor de analisar o seu estoque. X X X
2 Avaliar o estoque levando em consideração a garantia e/ou transferência. X X X
3 Permitir avaliar a qualidade da venda x quantidade comprada X X X4 Avaliar o estoque segundo a sazonalidade x tecnologia. X X X5 Avaliar a qualidade histórica das entregas. X X X
6
O DM deve ser capaz de fornecer o estoque e as médias de garantia , vendas, compras, devoluções, transferências e reserva de um determinado produto em um determinado mês (históricos) e em uma determinada unidade.
X X X
7
O sistema deve ser capaz de fornecer médias de quanto não foi possível vender de um determinado produto devido uma quebra de estoque em um determinado mês (históricos) e em uma determinada unidade.
X X X
8O sistema deve ser capaz de demonstrar aos gestores as sazonalidades X X X
Presidente Diretor Gerente Nº Descrição do requísito
A Tabela 7 demonstra os requisitos que foram totalmente ou parcialmente atendidos e
também os requisitos que não poderem ser atendidos pelo modelo do cubo proposto conforme os
testes efetuados junto aos gestores, conforme o resultado demonstrado pela tabela nenhum requisito
foi totalmente não atendido. Os requisitos que estão demonstrados como parcial foi devido ao
motivo das pendências junto ao departamento de tecnologia da Pauta, ou seja, para atender alguns
requisitos são necessárias algumas mudanças no sistema e para tanto foi solicitado ao departamento
de tecnologia.
4 CONCLUSÃO
Com a crescente competitividade no mercado e busca constante por qualidade e preço
competitivo, torna-se necessário que as empresas estejam fortificadas com ferramentas que lhes
auxiliem nos processos decisórios. Dentro deste contexto tendo como base o desenvolvimento do
projeto, o conceito de Sistemas de Apoio à Decisão foi um importante ponto de apoio, pois se
propõem a extrair informações dos sistemas operacionais e dar uma nova visão que seja mais fácil
de ser utilizada pelo gestor.
Os componentes deste conceito que foram utilizados neste trabalho são: um armazém de
informações (Data Mart) sendo que este tem o foco sobre o departamento de compras da empresa
Pauta, uma ferramenta de extração, transformação e carga dos dados das bases operacionais para o
ambiente de DM e uma ferramenta de front-end para consultas de informações sobre o Data Mart,
ou seja, propõe-se a transformação de dados em informações íntegras e com base histórica, onde o
gestor pode acessar e consultar as informações por meio da ferramenta (MS Excel).
A metodologia de desenvolvimento utilizada foi uma adaptação da metodologia proposta
por Kimball et al (1998), a mesma se mostrou adequada durante o percorrer de todas as suas etapas.
Notou-se que para realizar a etapa de modelagem é necessário que a etapa de levantamento dos
requisitos de negócio esteja bem definida e para efetuar a etapa do projeto físico é necessário um
grande conhecimento da base de dados operacional da empresa Pauta, principalmente no momento
da ligação entre o modelo proposto e o modelo existente da base de dados, onde se determina quais
informações podem ser captada e quais têm que ser criadas para suprir a necessidade do modelo
proposto.
O trabalho proposto foi executado sobre as ferramentas da linha de produtos da Oracle,
apesar de existirem ferramentas de uso livre. O motivo dessa utilização está no fato que a empresa
Pauta utiliza como padrão os produtos da linha Oracle. Vale ressaltar que o único produto a não ser
utilizado da linha de produtos da Oracle foi à ferramenta de front-end, a ferramenta proposta por
este trabalho foi o Excel 2003 da linha de produtos da Microsoft. A utilização deste produto foi
devido ao prévio conhecimento dos gestores com a ferramenta e também pelos próprios gestores já
conterem a ferramenta, a instalação de mais um produto em suas maquinas resultaria em mais perda
de desempenho das mesmas.
79
Os objetivos deste trabalho foram alcançados, como relatados anteriormente. A identificação
e mapeamento do banco de dados vinculados a área de compras foi realizado através de entrevistas
com o gerente e analistas da área de tecnologia da empresa Pauta. Foi realizado um levantamento
do organograma da empresa com foco na área de compras e após esta etapa foi possível se
identificar as pessoas envolvidas por este projeto. Para a identificação dos requisitos de negócio foi
preciso fazer um apanhamento de todo os manuais de atividade relacionados ao processo de
compra, juntamente com entrevistas e questionários para ao final se identificar os requisitos através
de um estudo sobre todos os materiais resultantes deste processo. A modelagem do DM teve como
objetivo alcançar um modelo que dispõe aos gestores medidas em que os mesmos devem averiguar
para se identificar os fatos que tem ocasionado as quebras de estoque. Foi desenvolvido este
protótipo sobre esta modelagem e a implementação deste modelo foi aplicado sobre um servidor de
teste, onde ao final foram executados testes para averiguar a consistência do cubo, avaliando o
processo de carga e as informações contidas no mesmo, o resultado foi aprovado pelos gestores. Ao
inicio do projeto foram estudados alguns trabalhos e ao final observou-se que este projeto tratou de
um problema comum a várias empresas e entre os trabalhos pesquisados três trabalhos mereceram
destaque, pelo motivo de tratarem de temas importantes que foram utilizados na construção do
modelo deste projeto, como: a criação de um DM para o departamento de compras, a utilização da
metodologia de Kimball e o uso das ferramentas da Oracle para criação e desenvolvimento de um
DM.
As principais dificuldades encontradas neste projeto foram estabelecidas pela etapa do
projeto físico, a versão do Oracle proposto neste trabalho apresenta diversas peculiaridades. Logo
no inicio da etapa para importar os dados de uma cópia de segurança ou para exportar para se
armazena uma cópia das informações contidas no banco de dados operacional, houve o problema
em descobrir qual era o usuário do host, pois entrava com o usuário do sistema operacional e o
mesmo relatava que a senha estava incorreta. Para solucionar este problema, foram efetuadas
diversas pesquisas e como resultado descobriu-se que o usuário necessitava conter uma diretiva de
segurança do Windows liberada “fazer logon como um trabalho em lotes”. Um dos principais
problemas foi no momento de criar a dimensão tempo do primeiro modelo dimensional proposto
por este trabalho, pois a dimensão tempo no Oracle tem algumas peculiaridades, ou seja, para cada
nível de tempo (ano, mês e dia) o mesmo deveria conter os membros “TIME_SPAN” e
“END_DATE”, por isso foi preciso redesenhar o modelo físico do DM.
80
4.1 TRABALHOS FUTUROS
Como proposta para trabalhos futuros, pode ser realizada ainda pelo departamento de
compras, um cubo com as informações de detalhamento dos problemas detectados pelo cubo
proposto neste trabalho. Para se obter respostas mais concreta do tempo de permanência do produto
em estoque é necessário alterar o modo como a Pauta trabalha sobre os mesmos. Ainda pela área de
compras poderia ser adicionado ao cubo medidas da programação de compra (média de venda de
acordo com uma data estipulada, Disponibilidade do estoque, Projeção e disponibilidade do estoque
para a projeção) para melhor atender o requisito de negócio, que relata a necessidade do gestor em
analisar o seu estoque a partir de histórico de compras e vendas.
Podem ser desenvolvido outros Data Marts para outras áreas da empresa Pauta, como a área
de vendas, marketing e GDH.
Pode ser desenvolvido um front-end com consultas WEB, porém se deve levar em
consideração aspectos de segurança, por se tratar de informações sigilosas.
Outro aspecto que pode ser abordado é a tecnologia de Data Mining, para que se possa
extrair novas informações e conhecimentos para a base do DM.
REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, M. G. Pedagogia Empresarial, 1º ed.: Brasport, 2006.
BAILY, P. J. H.; FARMER, D.; JESSOP, D.; JONES, D. Compras Princípios e Administração, 1º ed. São Paulo: Atlas, 2000.
CENTENARO, A. C. Desenvolvimento e implantação de um Data Warehouse corporativo com Data Marts distribuidos em uma cooperativa agroindustrial. (Dissertação de Mestrado em Engenharia de Produção) Universidade Federal de Santa Catarina, curso de Engenharia de Produção, Florianópolis, 2003. Disponível em: http://teses.eps.ufsc.br/defesa/pdf/9100.pdf. Acessado em 23/12/2007.
COSTA, F. J. C. L, Introdução à Administração de Materiais em Sistemas Informatizados, 1º ed. São Paulo: ieditora, 2002.
ESPIRITO SANTO, F. G. M. do. Construção de um Data Mart para apoio às tomadas de decisão das empresas proembarque e casacon. (Monografia) Universidade do Vale do Itajaí, curso de Ciência da Computação, Itajaí, 2005. Disponível em: http://Siaibib01.univali.br/pdf/Frederico Guilherme Mariani do Espírito Santo.pdf. Acessado em 10/11/2007.
FUSCO, J. P. A.; SACOMANO, J. B. Operações e Gestão Estratégica da Produção, 1º ed. São Paulo: Arte & Ciencia, 2007.
GIL, A. C. Como elaborar projetos de pesquisa. 4º ed. São Paulo: Atlas, 2002.
GRAZZIOTIN, G. A Arte do Varejo: O pulo do gato está na compra, 4º ed. São Paulo: Senac, 2004.
HARRISON, T. H. Intranet Data Warehouse, São Paulo: Berkeley Brasil, 1998.
INMON, W. H.; HACKARTHORN, R. D. Como Usar o Data Warehouse, Rio de Janeiro: IBPI Press, 1997.
INMON, W. H. Como Construir o Data Warehouse, Rio de Janeiro: Campus, 1997.
KIMBALL, R. Data Warehouse Toolkit, São Paulo: Makron Books, 1998.
KIMBALL, R. et al. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. New York: John Wiley & Sons, 1998.
LAUDON, K. C.; LAUDON J. P. Sistemas de informação Gerenciais: administrando a empresa digital, 5º ed. São Paulo: Pearson Prentice Hall, 2006.
MACHADO, F. N. Projeto de Data Warehouse: Uma visão Multidimensional, São Paulo: Érica, 2000.
OLIVEIRA, A. G. Data Warehouse: conceitos e soluções, Ed. Advanced, 1998.
82
OLIVEIRA, W. J, Data Warehouse, Ed. Visual Books, 2002.
O’BRIEN, J. A. Sistemas de informação e as decisões gerenciais na era da internet. 2º ed. São Paulo: Saraiva, 2006.
ORACLE. Oracle® Database Installation Guide 10g Release 2 (10.2) for Microsoft Windows (32-Bit). Disponível em http://download.oracle.com/docs/cd/B19306_01/install.102/b14316/reqs.htm#i1005703. Acessado em 02/06/2008.
PAUTA. Disponível em http://www.pauta.com.br/intranet acessado em 13/09/2007.
RAMALHO, J. A. Oracle 10g. 1º ed. São Paulo: Thomson, 2004.
ROSINI, A. M.; PALMISANO, A. Administração de sistemas de informação e a gestão do conhecimento, 1º ed. São Paulo: Thomson, 2003.
SANTOS, I. M. Data Warehouse como ferramenta de auxílio em sistemas de monitoramento ambiental. (Monografia) Universidade Federal de Mato Grosso, curso de Ciência da Computação, Cuiabá-MT, 2003. Disponível em: http://www.ufmt.br/cacomp/Downloads/monografias/DW-AcompanhamentoAmbiental.pdf. Acessado em 18/12/2007.
SEVERO FILHO, J. Administração de logística integrada. 2º ed.: E-Papers, 2006.
STAIR, R. M.; REYNOLDS G. W. Princípios de sistemas de informação, 4º ed. Rio de Janeiro: LTC, 1999.
TEIXEIRA FILHO, J. Comércio Eletrônico, Ed. Senac Rio, 2001;
TURBAN, E.; RAINER, R. K.; POTTER, R. E. Administração de tecnologia da informação, 3º ed. Rio de Janeiro: Elsevier, 2005.
GLOSSÁRIO
Nota de Débito Documento emitido para cobrança de crédito junto ao fornecedor.
Price Protection Proteção de preço concedido pelo fornecedor geralmente devido à redução de preço de produtos.
Programação de Compras Relatório sistemático onde é possível ser examinado as vendas, compras que estão em trânsito, estoques, bem como a projeção de vendas do mês.
Rebate Verba concedida pelo fornecedor ou pela diretoria aos gerentes de produtos, com o intuito de disponibilizar competitividade a equipe de vendas para negócios específicos ou ações de vendas.
Registro de Ocorrência Formulário, onde são registrados situações ou processos que de alguma forma podem ser melhorados ou que possam estar prejudicando o andamento dos processos do departamento de compras.
Pallets Plataforma individual para deposito e/ou transporta de mercadorias.
APÊNDICES
APÊNDICE A QUESTIONÁRIO APLICADO AOS GESTORES
Tabela 8. Questionário aplicado aos gestores
PerguntasExiste uma data específica para efetuar um pedido de compra? Se existe porque está data e não outra? Existe algum benefício?Em um pedido de compra existe uma variável chamada de taxa de dólar? Quando ela é utilizada e porque é utilizada?Em um pedido de compra existe uma previsão de entrega? Como é efetuado esse cálculo? Quais variáveis estão ligadas a esse cálculo?Existem fornecedores que precisam de uma quantidade, valor ou umdeterminado requisito para a Pauta poder efetuar um pedido de compra?Como funciona a questão do desconto? Quando que a pauta recebe? Quanto ao rebate como funciona? Quando e porque que a pauta recebe este rebate?Quanto a forma de pagamento como é feito a decisão de qual forma de pagamento a se utilizar?No momento em decidir o quanto comprar, estão dispostas quais informações? E quais informações não estão em mãos? Quais fatores são levados em conta? Quem disponibiliza essa informação?Ao se efetuar um pedido é verificado se existe a disponibilidade do valor em caixa? Como é feito esse processo? E quem está envolvido nesta etapa?Como funciona as transferências? Porque e quando é feito as transferências?Quanto a garantia de um produto, como funciona o processo de garantia? Quando tempo a Pauta possui para efetuar a garantia de um produto? Quais pessoas ou departamentos estão envolvidos neste processo? O termo garantia é levado em conta na hora de decidir o que comprar e o quanto comprar?Quanto as devoluções de produtos é previsto as mesmas na hora de decidir o quanto comprar? Como funciona o processo de devolução? Quem está envolvido neste processo?A pauta efetua processo de consignações? como é realizado? Quanto tempo está consignação dura? É mantido um acompanhamento para verificar se o mesmo está conseguindo vender as mercadorias? Ao se verificar uma necessidade de compra é visto o que se tem de estoque em consignação para evitar uma possível compra fora de época?Existe algum fator que não foi abordado neste questionário que é utilizado em uma compra?
86
APÊNDICE B CARACTERÍSTICAS DO PROCESSO DE COMPRAS DA EMPRESA PAUTA
Como visto anteriormente, a área de compras segue o modelo central de compras, ou seja,
todas as compras são efetuadas por uma única unidade. Para uma compra com uma melhor relação
custo ou beneficio, ou seja, mais próxima à quantidade consumida (venda, garantia, transferência e
devolução) pela empresa Pauta, os compradores do departamento de compras utilizam um relatório
de programação de compra onde o mesmo tem o propósito de indicar qual a projeção de
disponibilidade do produto. Para se chegar nesse valor alguns cálculos são efetuados como segue na
Tabela 9.
Tabela 9. Fórmulas das variáveis da programação de compra
Variável FormulaMédia Venda (Venda + Reserva) / Dias DecorridosMédia Estoque (Disponibilidade) (Estoque - Reserva) / Média VendaProjeção Média Venda * Dias que faltam para terminar o périodo selecionadoDisponibilidade Projeção (Estoque + Compras - Reserva) / Média de Venda
Fonte: Pauta (2007).
O ponto ideal de se efetuar um pedido é no momento em que a disponibilidade do produto
seja igual ou próxima ao tempo de transporte do fornecedor até a Pauta. É considerado um ponto
ideal para se efetuar o pedido, pois no momento em que o estoque tende a zerar já terá um lote
chegando evitando assim excesso de estoque. Para evitar uma possível quebra de estoque (momento
em que a empresa possui estoque zerado de um determinado produto) a empresa Pauta trabalha com
uma margem de erro (uma quantidade mínima de estoque) que pode variar de produto a produto.
Existem ainda casos que o fornecedor passa uma meta para Pauta, estas metas normalmente são
trimestrais e tem como objetivo disponibilizar benefícios para empresa. Neste momento, a
compradora leva a informação ao diretor para decidirem juntos se devem optar em apostar em uma
compra maior. Outro caso que interfere na hora de decidir o quanto comprar é o fato de que alguns
fornecedores comercializam seus produtos em pallets, sendo que o mesmo pode variar de acordo
com o tamanho do produto.
Quanto ao frete do pedido quando o valor do pedido é superior ao valor mínimo exigido
pelo fornecedor o frete é por conta do fornecedor caso contrário o frete se torna por conta da Pauta.
87
O que pode prejudicar o valor dos produtos e conseqüentemente a competitividade dos mesmos no
mercado.
A previsão de entrega deste pedido é realizada após a confirmação de faturamento do
fornecedor, onde é efetuado um cálculo conforme a Equação 1.
Previsão de chegada = data de faturamento + tempo de transporte fornecido pelo
fornecedor
Equação 1
Além do frete que a Pauta pode obter com seus fornecedores, ainda existem possíveis
descontos que podem ser obtidos através de propostas de vendas. Quando a Pauta verifica que um
determinado produto está para ser substituído ou quando o preço está incompatível com o do
mercado, a Pauta negocia com seus fornecedores com o objetivo do fornecedor conceder um rebate
(valor utilizado como desconto em um determinado produto) para aumentar a competitividade de
seus produtos. Também pode obter descontos através da forma de pagamento, porém na maior parte
das negociações a Pauta opta por utilizar formas de pagamento com prazos superiores a 28 dias.
No momento de decidir o quanto comprar, é importante verificar se o produto possui ou não
histórico de venda. No caso de produtos que possuam histórico de vendas é levada em conta a
média de vendas. Já no caso de um produto novo é realizada uma compra cautelosa onde a
quantidade desse produto é estabelecida através de um estudo do mercado (consultando
fornecedores, clientes e em alguns casos disponibilizando enquete no site) para avaliar a provável
saída do produto em uma determinada região, pois a cultura de gosto, cor, marca e modelos
costumam ser diferentes para diferentes regiões. Outro fator de extrema importância no momento de
decidir o quanto comprar é o espaço físico para alocar esses produtos, essa informação é
disponibilizada para o departamento de compras através do departamento de expedição. O dólar
também é um fator de grande importância na compra de produtos importados ou produtos nacionais
que utilizam matérias primas importadas, pois os valores podem subir ou descer em relação à
cotação do dólar. Existem algumas épocas do ano que ocorre uma maior tendência de venda esses
períodos deve ser levados em conta.
Normalmente, não é verificado o valor em caixa para se efetuar um pedido, somente é
verificado em casos de o pedido ter um valor superior aos que normalmente são emitidos para
aquela linha de produtos. Nos momentos que o caixa esteja inferior ao padrão, o departamento
88
financeiro sinaliza o departamento de compras. Este segura as compras e faz ações de vendas
(Promoção e brindes) com o objetivo de restabelecer o nível de dinheiro no caixa. Os gerentes de
vendas também participam, priorizando as vendas à vista.
No caso das transferências, existem casos em que o fornecedor vende o produto em pallets,
a Pauta compra uma única unidade e transfere posteriormente para as demais. Também pode
ocorrer de uma unidade vender melhor que outra, então é feito a transferência entre as unidades
com o objetivo de fazer um equilíbrio dos estoques.
O termo de garantia dos produtos da Pauta é bem variável, pois o tempo de garantia pode
variar de produto a produto. Existem algumas garantias que até um determinado número de dias
pode se efetuar a troca do produto no balcão e após este momento o produto deve ser levado a uma
assistência técnica. O departamento de compras acorda o prazo e o procedimento de garantia com
seus fornecedores. O departamento de garantia é responsável em efetuar as trocas dos produtos para
os clientes, e encaminha o produto com defeito ao fornecedor, além de cobrar o seu retorno. No
momento de definir uma nova parceria com os fornecedores, define-se o procedimento de garantia
de seus produtos. Caso a mesma não atenda as necessidades da Pauta e de seus clientes, ou, caso o
produto apresente um índice muito alto de garantia, podem ser fatores que podem levar a empresa
Pauta a diminuir ou suspender a compra do produto.
Nos casos em que uma mercadoria chega avariada na Pauta, ou não vem em conformidade
com algum acordo negociado anteriormente, o conferencista da unidade questiona o compras
através de um e-mail de divergência. O comprador ou gerente de produto procura resolver a questão
em contato com o fornecedor sem devolver a mercadoria, tendo em vista todos os custos, desgastes,
quebra de estoque e retrabalho que uma devolução pode gerar. A devolução ocorre somente em
último caso.
Quando um produto não tem saída a Pauta comunica o fornecedor para tentar adquirir
rebates para promover a venda do produto ou até mesmo pode ocorrer o processo de stock rotation
(processo de devolução da mercadoria ou troca por outra mercadoria de maior giro).
89
APÊNDICE C STORED PROCEDURE
Para contemplar de modo eficaz toda a extração do modelo dimensional do DM, foi
necessário subdividir o processo de extração da seguinte forma:
A.1 EXTRAÇÃO DA TABELA DE FATO
A criação da rotina de extração da tabela de fato é composta por duas rotinas, a primeira cria
os registros da tabela de fato com exceção do estoque conforme Figura 36, e a segunda atualiza o
estoque dos registros contidos na tabela de fato conforme Figura 37.
CREATE OR REPLACE PROCEDURE GERA_FATO IS CURSOR c_Data IS SELECT DIA_CODIGO, DIA_END_DATE FROM DATAMART.DIA WHERE TO_CHAR(DIA_END_DATE,'DD/MM/YYYY') = TO_CHAR(SYSDATE,'DD/MM/YYYY') ORDER BY DIA_END_DATE; CURSOR c_Item IS SELECT PRO_CODIGO, MAS_CODIGO, GRU_CODIGO, SUB_CODIGO, MAR_CODIGO FROM DATAMART.PRODUTO ORDER BY MAS_CODIGO, PRO_CODIGO; CURSOR c_Filial IS SELECT FIL_CODIGO FROM DATAMART.FILIAL ORDER BY FIL_CODIGO; v_Compra number(8,0); v_Venda number(8,0); v_TransferenciaEntrada number(8,0); v_TransferenciaSaida number(8,0); v_DevolucaoSaida number(8,0); v_DevolucaoEntrada number(8,0); v_GarantiaSaida number(8,0); v_GarantiaEntrada number(8,0); v_Dominio varchar2(20); BEGIN FOR c_Filial1 IN c_Filial LOOP FOR c_Data1 IN c_Data LOOP FOR c_Item1 IN c_Item LOOP BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD INTO v_DevolucaoSaida FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO
90
FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (404,55,472,426,427,447,437,53,54,56) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_DevolucaoSaida:= 0; END; BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD INTO v_DevolucaoEntrada FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (220,221,402,211,435,442,459,439,202,203,208,403) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_DevolucaoEntrada:= 0; END; BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD INTO v_GarantiaEntrada FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL
91
WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (410,207) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_GarantiaEntrada:= 0; END; BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD INTO v_GarantiaSaida FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (61,51) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_GarantiaSaida:= 0; END; BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD
92
INTO v_TransferenciaSaida FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (997,217,400,999,995,464,443,4) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_TransferenciaSaida:= 0; END; BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD INTO v_TransferenciaEntrada FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (218,457,466,201) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_TransferenciaEntrada:= 0; END;
93
BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD INTO v_Venda FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (12,224,401,10,1002,467,231,425,428,430,453,462,458,446,438, 1,2,3,18,16,6,7,8,50,52,101,100,104) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_Venda:= 0; END; BEGIN SELECT NVL(SUM(INO_QUANTIDADE),0) AS QTD INTO v_Compra FROM PAUTA.NOTAFISCAL, PAUTA.PEDIDONOTA, PAUTA.PEDIDO, PAUTA.ITEMNOTA, PAUTA.ITEMESTOQUEGERAL WHERE TRUNC(NOTAFISCAL.NOT_DATASAIDA) = c_Data1.DIA_END_DATE AND NOTAFISCAL.STN_CODIGO = 1 AND NOTAFISCAL.DOM_CODIGO IN (SELECT DOM_CODIGO FROM PAUTA.FILIAL_DOMINIO WHERE FIL_CODIGO = c_Filial1.FIL_CODIGO ) AND PEDIDONOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND PEDIDONOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND PEDIDONOTA.PED_CODIGO = PEDIDO.PED_CODIGO AND PEDIDONOTA.PED_SEQUENCIAL = PEDIDO.PED_SEQUENCIAL AND PEDIDONOTA.DOM_CODIGO = PEDIDO.DOM_CODIGO AND PEDIDO.TPE_CODIGO IN (216,222,200,227,471,1006,1007,1003,468,436, 454,460,230,209,205,210,206,213,214) AND ITEMNOTA.NOT_CODIGO = NOTAFISCAL.NOT_CODIGO AND ITEMNOTA.NOT_SEQUENCIAL = NOTAFISCAL.NOT_SEQUENCIAL AND ITEMNOTA.DOM_CODIGO = NOTAFISCAL.DOM_CODIGO AND ITEMNOTA.ITG_CODIGO = ITEMESTOQUEGERAL.ITG_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = c_Item1.MAS_CODIGO
94
AND ITEMESTOQUEGERAL.MAR_CODIGO = c_Item1.MAR_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = c_Item1.SUB_CODIGO; EXCEPTION WHEN NO_DATA_FOUND THEN v_Compra:= 0; END; INSERT INTO DATAMART.QUEBRA_ESTOQUE (DIA_CODIGO, FIL_CODIGO, PRO_CODIGO, QES_COMPRAAEREA, QES_COMPRAMARITIMA, QES_COMPRATERRESTRE, QES_COMPRANAODEFINIDA, QES_DEVOLUCAOENTRADA, QES_DEVOLUCAOSAIDA, QES_ESTOQUE, QES_GARANTIAENTRADA, QES_GARANTIASAIDA, QES_RESERVA, QES_TRANSFERENCIAENTRADA, QES_TRANSFERENCIASAIDA, QES_VENDA) VALUES(c_Data1.DIA_CODIGO, c_Filial1.FIL_CODIGO, c_Item1.PRO_CODIGO, 0, 0, 0, v_Compra, v_DevolucaoEntrada, v_DevolucaoSaida, 0, v_GarantiaEntrada, v_GarantiaSaida, 0, v_TransferenciaEntrada, v_TransferenciaSaida, v_Venda); COMMIT; END LOOP; END LOOP; END LOOP; END; -- Procedure
Figura 36. Stored Procedure para extração do Fato
CREATE OR REPLACE PROCEDURE GERA_ESTOQUE (pDataInicial IN DATE, pDataFinal IN DATE, pMasterGrupo IN NUMBER, pFilial IN NUMBER, pAnoMesReferencia IN NUMBER) IS CURSOR c_Data IS SELECT DIA_CODIGO, DIA_END_DATE FROM DATAMART.DIA WHERE DIA_END_DATE BETWEEN pDataInicial AND pDataFinal ORDER BY DIA_END_DATE; CURSOR c_Item IS SELECT PRO_CODIGO, MAS_CODIGO, GRU_CODIGO, SUB_CODIGO, MAR_CODIGO FROM DATAMART.PRODUTO WHERE MAS_CODIGO = pMasterGrupo ORDER BY PRO_CODIGO; v_saldo number(8,0); v_entrada number(8,0); v_saida number(8,0); BEGIN FOR c_Item1 IN c_Item LOOP BEGIN SELECT NVL(SUM(SLD_ANTERIOR),0) AS SALDO INTO v_saldo FROM PAUTA.SALDOITEM SALDO WHERE SALDO.ITG_CODIGO IN (SELECT ITG_CODIGO FROM PAUTA.ITEMESTOQUEGERAL ITEM
95
WHERE ITEM.MAS_CODIGO = c_Item1.MAS_CODIGO AND ITEM.GRU_CODIGO = c_Item1.GRU_CODIGO AND ITEM.SUB_CODIGO = c_Item1.SUB_CODIGO AND ITEM.MAR_CODIGO = c_Item1.MAR_CODIGO ) AND SALDO.SLD_ANTERIOR > 0 AND SALDO.DOM_CODIGO = pFilial AND SALDO.SLD_ANOMES = pAnoMesReferencia; EXCEPTION WHEN NO_DATA_FOUND THEN v_saldo:= 0; END; FOR c_Data1 IN c_Data LOOP SELECT (qes_compraaerea + qes_compramaritima + qes_compraterrestre + qes_compranaodefinida + qes_devolucaoentrada + qes_garantiaentrada + qes_transferenciaentrada) AS ENTRADA, (qes_devolucaosaida + qes_garantiasaida + qes_transferenciasaida + qes_venda) AS SAIDA INTO v_entrada, v_saida FROM DATAMART.QUEBRA_ESTOQUE WHERE DIA_CODIGO = c_Data1.DIA_CODIGO AND FIL_CODIGO = pFilial AND PRO_CODIGO = c_Item1.PRO_CODIGO; v_saldo:= v_saldo + (v_entrada - v_saida); UPDATE DATAMART.QUEBRA_ESTOQUE SET QES_ESTOQUE = v_saldo WHERE DIA_CODIGO = c_Data1.DIA_CODIGO AND FIL_CODIGO = pFilial AND PRO_CODIGO = c_Item1.PRO_CODIGO; COMMIT; END LOOP; END LOOP; END;
Figura 37. Stored Procedure para extração do estoque para a tabela de fato
96
A.2 EXTRAÇÃO DAS TABELAS DE DIMENSÃO
A criação da rotina de extração das tabelas de dimensão foi subdividida para efetivar a
extração individual do assunto se necessário e também para diminuir a carga de processamento em
cima de uma única sessão.
A.2.1 Dimensão Ano
A stored procedure para extração da dimensão ano segue na Figura 38.
Figura 38. Stored Procedure para extração da dimensão ano.
CREATE OR REPLACE PROCEDURE GERA_ANO IS CURSOR C_ANO IS SELECT DISTINCT TO_CHAR(CAL_DATA,'YYYY') ANO_DESCRICAO, (SELECT COUNT(*) FROM PAUTA.CALENDARIO CAL WHERE TO_CHAR(CAL.CAL_DATA,'YYYY') = TO_CHAR(CALENDARIO.CAL_DATA,'YYYY') ) ANO_TIMESPAN, LAST_DAY(CAL_DATA) ANO_END_DATE FROM PAUTA.CALENDARIO WHERE TO_CHAR(CAL_DATA,'YYYY') = TO_CHAR(SYSDATE,'YYYY') AND TO_CHAR(CAL_DATA,'MM') = '12' AND TO_CHAR(CAL_DATA,'YYYY') NOT IN (SELECT ANO_DESCRICAO FROM DATAMART.ANO ); v_Codigo number(8,0); BEGIN FOR C_ANO1 IN C_ANO LOOP SELECT GETCODIGOPROXIMOANO INTO v_Codigo FROM DUAL; INSERT INTO DATAMART.ANO (ANO_CODIGO, ANO_DESCRICAO, ANO_TIMESPAN, ANO_END_DATE) VALUES (v_Codigo,C_ANO1.ANO_DESCRICAO, C_ANO1.ANO_TIMESPAN, C_ANO1.ANO_END_DATE); COMMIT; END LOOP; END;
97
A.2.2 Dimensão Mês
A stored procedure para extração da dimensão mês segue na Figura 39.
Figura 39. Stored Procedure para extração da dimensão mês.
CREATE OR REPLACE PROCEDURE GERA_MES IS CURSOR C_MES IS SELECT DISTINCT ANO_CODIGO, TO_CHAR(CAL_DATA,'MON-YY') MES_DESCRICAO, (SELECT COUNT(*) FROM PAUTA.CALENDARIO B WHERE TO_CHAR(B.CAL_DATA,'MMYYYY') = TO_CHAR(CALENDARIO.CAL_DATA,'MMYYYY') ) AS MES_TIMESPAN, LAST_DAY(CAL_DATA) AS MES_END_DATE FROM PAUTA.CALENDARIO, DATAMART.ANO WHERE TO_CHAR(CAL_DATA,'YYYY') = TO_CHAR(SYSDATE,'YYYY') AND ANO.ANO_DESCRICAO = TO_CHAR(CAL_DATA,'YYYY') AND TO_CHAR(CAL_DATA,'MON-YY') NOT IN (SELECT MES_DESCRICAO FROM DATAMART.MES ) ORDER BY MES_END_DATE; vCodigo number(8,0); BEGIN FOR C_MES1 IN C_MES LOOP SELECT GETCODIGOPROXIMOMES INTO vCodigo FROM DUAL; INSERT INTO DATAMART.MES (MES_CODIGO, ANO_CODIGO, MES_DESCRICAO, MES_TIMESPAN, MES_END_DATE) VALUES (vCodigo, C_MES1.ANO_CODIGO, C_MES1.MES_DESCRICAO, C_MES1.MES_TIMESPAN, C_MES1.MES_END_DATE); COMMIT; END LOOP; END;
98
A.2.3 Dimensão Dia
A stored procedure para extração da dimensão dia segue na Figura 40.
Figura 40. Stored Procedure para extração da dimensão dia.
CREATE OR REPLACE PROCEDURE GERA_DIA IS CURSOR C_DIA IS SELECT MES_CODIGO, SUBSTR(TO_CHAR(CAL_DATA,'DD'),1,2) DIA_DESCRICAO, '1' DIA_TIMESPAN, CAL_DATA DIA_END_DATE FROM PAUTA.CALENDARIO, DATAMART.MES WHERE TO_DATE(CAL_DATA,'DD-MM-YYYY') BETWEEN SYSDATE AND SYSDATE AND TO_CHAR(MES.MES_END_DATE,'MM-YYYY') = TO_CHAR(CAL_DATA,'MM-YYYY') AND TO_DATE(CAL_DATA,'DD-MM-YYYY') NOT IN (SELECT DIA_END_DATE FROM DATAMART.DIA ) ORDER BY CAL_DATA; v_Codigo number(8,0); BEGIN FOR C_DIA1 IN C_DIA LOOP SELECT GETCODIGOPROXIMODIA INTO v_Codigo FROM DUAL; INSERT INTO DATAMART.DIA (DIA_CODIGO, MES_CODIGO, DIA_DESCRICAO, DIA_TIMESPAN, DIA_END_DATE) VALUES (v_Codigo,C_DIA1.MES_CODIGO, C_DIA1.DIA_DESCRICAO, C_DIA1.DIA_TIMESPAN, C_DIA1.DIA_END_DATE); COMMIT; END LOOP; END;
A.2.4 Dimensão Filial
Existem duas rotinas para extração da dimensão Filial, uma para criar a filial conforme
Figura 41 e a outra para criar uma relação com a Filial principal, caso exista mais do que um
domínio para uma única filial conforme Figura 42.
99
Figura 41. Stored Procedure para extração da dimensão filial.
CREATE OR REPLACE PROCEDURE GERA_FILIAL (pFilial IN NUMBER) IS CURSOR c_Filial IS SELECT DOM_CODIGO, DOM_DESCRICAO FROM PAUTA.DOMINIO WHERE DOM_CODIGO = pFilial; BEGIN FOR c_Filial1 IN c_Filial LOOP INSERT INTO DATAMART.FILIAL (FIL_CODIGO, FIL_DESCRICAO) VALUES (pFilial, c_Filial1.DOM_DESCRICAO); COMMIT; INSERT INTO PAUTA.FILIAL_DOMINIO (FIL_CODIGO, DOM_CODIGO) VALUES (pFilial, c_Filial1.DOM_CODIGO); COMMIT; END LOOP; END;
Figura 42. Stored Procedure para relacionamento da dimensão filial.
CREATE OR REPLACE PROCEDURE GERA_RELACAOFILIAL (pFilial IN NUMBER, pRelacao IN NUMBER) IS CURSOR c_Filial IS SELECT DOM_CODIGO, DOM_DESCRICAO FROM PAUTA.DOMINIO WHERE DOM_CODIGO = pRelacao; BEGIN FOR c_Filial1 IN c_Filial LOOP INSERT INTO PAUTA.FILIAL_DOMINIO (FIL_CODIGO, DOM_CODIGO) VALUES (pFilial, c_Filial1.DOM_CODIGO); COMMIT; END LOOP; END;
100
A.2.5 Dimensão Grupo
A stored procedure para extração da dimensão Grupo segue na Figura 43.
Figura 43. Stored Procedure para extração da dimensão grupo.
CREATE OR REPLACE PROCEDURE GERA_GRUPO (pGrupo IN NUMBER) IS CURSOR c_Grupo IS SELECT MAS_DESCRICAO FROM PAUTA.MASTERGRUPO WHERE MAS_CODIGO = pGrupo; BEGIN FOR c_Grupo1 IN c_Grupo LOOP INSERT INTO DATAMART.GRUPO (GRU_CODIGO,GRU_DESCRICAO) VALUES (pGrupo, c_Grupo1.MAS_DESCRICAO); COMMIT; END LOOP; END;
A.2.6 Dimensão Grupo Margem de Erro
A stored procedure para extração da dimensão Grupo Margem de Erro segue na Figura 44.
101
Figura 44. Stored Procedure para extração da dimensão grupo margem erro.
CREATE OR REPLACE PROCEDURE GERA_GRUPOMARGEMERRO IS CURSOR c_GrupoErro IS SELECT DISTINCT (NVL(SUBGRUPOITEM.SUB_MARGEM,NVL(GRUPOITEM.GRU_MARGEM,0)) || '%') AS GMA_MARGEMERRO, GRUPOITEM.MAS_CODIGO AS GRU_CODIGO, NVL(SUBGRUPOITEM.SUB_MARGEM,NVL(GRUPOITEM.GRU_MARGEM,0)) AS GMA_ERRO FROM PAUTA.ITEMESTOQUEGERAL, PAUTA.GRUPOITEM, PAUTA.SUBGRUPOITEM WHERE GRUPOITEM.MAS_CODIGO IN (SELECT GRU_CODIGO FROM DATAMART.GRUPO ) AND SUBGRUPOITEM.MAS_CODIGO = GRUPOITEM.MAS_CODIGO AND SUBGRUPOITEM.GRU_CODIGO = GRUPOITEM.GRU_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = GRUPOITEM.MAS_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = GRUPOITEM.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = SUBGRUPOITEM.SUB_CODIGO AND NVL(SUBGRUPOITEM.SUB_MARGEM,NVL(GRUPOITEM.GRU_MARGEM,0)) NOT IN (SELECT GMA_ERRO FROM DATAMART.GRUPO_MARGEMERRO WHERE GRU_CODIGO = GRUPOITEM.MAS_CODIGO) ORDER BY GMA_ERRO; vCodigo number(8,0); BEGIN FOR c_GrupoErro1 IN c_GrupoErro LOOP SELECT NVL(MAX(GMA_CODIGO)+1,1) AS CODIGO INTO vCodigo FROM DATAMART.GRUPO_MARGEMERRO; INSERT INTO DATAMART.GRUPO_MARGEMERRO (GMA_CODIGO, GMA_MARGEMERRO, GRU_CODIGO, GMA_ERRO) VALUES (vCodigo, c_GrupoErro1.GMA_MARGEMERRO, c_GrupoErro1.GRU_CODIGO, c_GrupoErro1.GMA_ERRO); COMMIT; UPDATE PAUTA.GRUPOITEM SET GRU_CODIGO = 0 WHERE MAS_CODIGO = c_GrupoErro1.GRU_CODIGO AND GRU_CODIGO IS NULL; COMMIT; END LOOP; END;
102
A.2.7 Dimensão Produto
A stored procedure para extração da dimensão Produto segue na Figura 45.
Figura 45. Stored Procedure para extração da dimensão produto.
CREATE OR REPLACE PROCEDURE GERA_PRODUTO IS CURSOR c_Produto IS SELECT DISTINCT (MAR_DESCRICAO || ' - ' || GRU_DESCRICAO || ' - ' || SUB_DESCRICAO) AS PRO_DESCRICAO, ITEMESTOQUEGERAL.MAS_CODIGO, ITEMESTOQUEGERAL.GRU_CODIGO, ITEMESTOQUEGERAL.SUB_CODIGO, ITEMESTOQUEGERAL.MAR_CODIGO, GRUPO_MARGEMERRO.GMA_CODIGO FROM PAUTA.MARCA, PAUTA.GRUPOITEM, PAUTA.SUBGRUPOITEM, PAUTA.ITEMESTOQUEGERAL, DATAMART.GRUPO_MARGEMERRO WHERE GRUPOITEM.MAS_CODIGO IN (SELECT GRU_CODIGO FROM DATAMART.GRUPO ) AND SUBGRUPOITEM.MAS_CODIGO = GRUPOITEM.MAS_CODIGO AND SUBGRUPOITEM.GRU_CODIGO = GRUPOITEM.GRU_CODIGO AND ITEMESTOQUEGERAL.MAS_CODIGO = GRUPOITEM.MAS_CODIGO AND ITEMESTOQUEGERAL.GRU_CODIGO = GRUPOITEM.GRU_CODIGO AND ITEMESTOQUEGERAL.SUB_CODIGO = SUBGRUPOITEM.SUB_CODIGO AND ITEMESTOQUEGERAL.MAR_CODIGO = MARCA.MAR_CODIGO AND GRUPO_MARGEMERRO.GMA_ERRO = GRUPOITEM.GRU_MARGEM AND GRUPO_MARGEMERRO.GRU_CODIGO = GRUPOITEM.MAS_CODIGO AND NOT EXISTS (SELECT 8 FROM DATAMART.PRODUTO WHERE PRODUTO.MAS_CODIGO = GRUPOITEM.MAS_CODIGO AND PRODUTO.GRU_CODIGO = GRUPOITEM.GRU_CODIGO AND PRODUTO.SUB_CODIGO = SUBGRUPOITEM.SUB_CODIGO AND PRODUTO.MAR_CODIGO = MARCA.MAR_CODIGO AND PRODUTO.GMA_CODIGO = GRUPO_MARGEMERRO.GMA_CODIGO ) ORDER BY MAR_CODIGO, GRU_CODIGO, SUB_CODIGO; vCodigo number(8,0); BEGIN FOR c_Produto1 IN c_Produto LOOP SELECT SEQ_PRODUTO.NEXTVAL INTO vCodigo FROM DUAL; INSERT INTO DATAMART.PRODUTO (PRO_CODIGO, PRO_DESCRICAO, MAS_CODIGO, GRU_CODIGO, SUB_CODIGO, MAR_CODIGO, GMA_CODIGO) VALUES (vCodigo, c_Produto1.PRO_DESCRICAO, c_Produto1.MAS_CODIGO, c_Produto1.GRU_CODIGO, c_Produto1.SUB_CODIGO, c_Produto1.MAR_CODIGO, c_Produto1.GMA_CODIGO); COMMIT; END LOOP; END;
APÊNDICE D JOBS
Conforme a descrição do processo de ETL Seção 3.1.5 a criação dos Jobs foi feita da
seguinte ordem:
1. Execução dos Jobs de extração: as execuções de carga dos Jobs de extração são feitas de forma
automatizada com exceção da dimensão Filial e da dimensão Grupo que devem ser executados
manualmente por não serem dimensões com atualizações constantes, como por ex: filial só será
atualizada após a abertura de uma nova filial. Já as demais dimensões são executadas de acordo
com a seguinte ordem:
1.1. Dimensões Ano e Grupo Margem de erro: o script para criação do Job segue
respectivamente na Figura 46 e 47.
BEGIN sys.dbms_scheduler.create_job( job_name => '"DATAMART"."EXECUTA_EXTRACAO_ANO"', job_type => 'STORED_PROCEDURE', job_action => 'DATAMART.GERA_ANO', repeat_interval => 'FREQ=DAILY;BYHOUR=3;BYMINUTE=0;BYSECOND=0', start_date => to_timestamp_tz('2008-06-11 -3:00', 'YYYY-MM-DD TZH:TZM'), job_class => 'DEFAULT_JOB_CLASS', comments => 'EXECUTA_EXTRACAO_ANO', auto_drop => FALSE, enabled => TRUE); END;
Figura 46. PL/SQL de criação do job de extração da dimensão ano.
BEGIN sys.dbms_scheduler.create_job( job_name => '"DATAMART"."EXECUTA_EXTRACAO_GRUPOMARGEMERRO"', job_type => 'STORED_PROCEDURE', job_action => 'DATAMART.GERA_GRUPOMARGEMERRO', repeat_interval => 'FREQ=DAILY;BYHOUR=3;BYMINUTE=0;BYSECOND=0', start_date => to_timestamp_tz('2008-06-11 -3:00', 'YYYY-MM-DD TZH:TZM'), job_class => 'DEFAULT_JOB_CLASS', comments => 'EXECUTA_EXTRACAO_GRUPOMARGEMERRO', auto_drop => FALSE, enabled => TRUE); END;
Figura 47. PL/SQL de criação do job de extração da dimensão grupo margem de erro.
104
1.2. Dimensões Mês e Produto: o script para criação do Job segue respectivamente na Figura 48
e 49.
BEGIN sys.dbms_scheduler.create_job( job_name => '"DATAMART"."EXECUTA_EXTRACAO_MES"', job_type => 'STORED_PROCEDURE', job_action => 'DATAMART.GERA_MES', repeat_interval => 'FREQ=DAILY;BYHOUR=3;BYMINUTE=30;BYSECOND=0', start_date => to_timestamp_tz('2008-06-11 -3:00', 'YYYY-MM-DD TZH:TZM'), job_class => 'DEFAULT_JOB_CLASS', comments => 'EXECUTA_EXTRACAO_MES', auto_drop => FALSE, enabled => TRUE); END;
Figura 48. PL/SQL de criação do job de extração da dimensão mês.
BEGIN sys.dbms_scheduler.create_job( job_name => '"DATAMART"."EXECUTA_EXTRACAO_PRODUTO"', job_type => 'STORED_PROCEDURE', job_action => 'DATAMART.GERA_PRODUTO', repeat_interval => 'FREQ=DAILY;BYHOUR=3;BYMINUTE=30;BYSECOND=0', start_date => to_timestamp_tz('2008-06-11 -3:00', 'YYYY-MM-DD TZH:TZM'), job_class => 'DEFAULT_JOB_CLASS', comments => 'EXECUTA_EXTRACAO_PRODUTO', auto_drop => FALSE, enabled => TRUE); END;
Figura 49. PL/SQL de criação do job de extração da dimensão produto.
1.3. Dimensão Dia: o script para criação do Job segue na Figura 50.
BEGIN sys.dbms_scheduler.create_job( job_name => '"DATAMART"."EXECUTA_EXTRACAO_DIA"', job_type => 'STORED_PROCEDURE', job_action => 'DATAMART.GERA_DIA', repeat_interval => 'FREQ=DAILY;BYHOUR=3;BYMINUTE=50;BYSECOND=0', start_date => to_timestamp_tz('2008-06-11 -3:00', 'YYYY-MM-DD TZH:TZM'), job_class => 'DEFAULT_JOB_CLASS', comments => 'EXECUTA_EXTRACAO_DIA', auto_drop => FALSE, enabled => TRUE); END;
Figura 50. PL/SQL de criação do job de extração da dimensão dia.
105
1.4. Fato Quebra de estoque: o script para criação do Job segue na Figura 51.
BEGIN sys.dbms_scheduler.create_job( job_name => '"DATAMART"."EXECUTA_EXTRACAO_FATO"', job_type => 'STORED_PROCEDURE', job_action => 'DATAMART.GERA_FATO', repeat_interval => 'FREQ=DAILY;BYHOUR=4;BYMINUTE=0;BYSECOND=0', start_date => to_timestamp_tz('2008-06-11 -3:00', 'YYYY-MM-DD TZH:TZM'), job_class => 'DEFAULT_JOB_CLASS', comments => 'EXECUTA_EXTRACAO_FATO', auto_drop => FALSE, enabled => TRUE); END;
Figura 51. PL/SQL de criação do job de extração do fato Quebra de estoque.
2. Execução dos Jobs de carga no DM: para efetuar a carga dos dados da área de estagiamento
para o DM é executado o script demonstrado pela Figura 52.
BEGIN sys.dbms_scheduler.create_job( job_name => '"DATAMART"."ATUALIZA_CARGA_CUBO"', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN dbms_aw.execute(''aw attach sys.awxml ro''); dbms_aw.execute(''call __xml_sequential_loader(346 0 600 1 NA ''DATAMART.DM'''' ''''TEMPO.DIMENSION:FILIAL.DIMENSION:PRODUTO.DIMENSION:QUEBRA_ESTOQUE.CUBE:'''' NA YES NA NA )''); END;', repeat_interval => 'FREQ=DAILY;BYHOUR=5;BYMINUTE=0;BYSECOND=0', start_date => to_timestamp_tz('2008-06-11 -3:00', 'YYYY-MM-DD TZH:TZM'), job_class => 'DEFAULT_JOB_CLASS', comments => 'ATUALIZA_CARGA_CUBO', auto_drop => FALSE, enabled => TRUE); END;
Figura 52. PL/SQL de criação do job de atualização da carga do cubo.
ANEXOS
I. RELATÓRIO DE PROGRAMAÇÃO DE COMPRA
II. MANUAL E PROCEDIMENTO DO DEPARTAMENTO DE COMPRAS DA PAUTA
II.1 RESPONSABILIDADES
• Gerente de compras:
o Buscar contínuo comprometimento do departamento com os processos e,
principalmente, com a empresa;
o Monitorar, dominar e manter o bom andamento das atividades do
departamento além de representar o mesmo em qualquer ocasião;
o Estar a par da situação financeira da empresa, no sentido de que as compras
não afetem negativamente a liquidez;
o Conhecer o mercado (principais clientes, fornecedores e concorrentes);
o Implementação das definições estratégicas da diretoria voltadas ao
departamento;
o Acompanhamento constante quanto ao funcionamento do sistema
informatizado (confiabilidade nos dados mediante relatórios gerenciais) e
solicitação de melhorias quando necessário;
o Integração com demais departamentos na busca de soluções e de melhoria
contínua;
o Conhecimento macro do funcionamento de todos os processos da empresa;
o Conhecer e administrar o nível do estoque (ideal, mínimo, máximo e
existente);
o Conhecer as linhas distribuídas pela empresa;
o Análise e ações quando necessário, quanto aos Rebates em aberto, RMA
(Return Merchandise Authorization) pendente, produtos deslacrados e
devoluções de compras;
o Análise e conferência dos rebates concedidos ao Call Center;
o Estar a par quanto ao recebimento dos produtos, se os fornecedores estão
cumprindo o acordado (preço, prazo de entrega, produtos, condições
financeiras e o transporte) em conjunto com os Gerentes de Produtos;
o Validação de pedidos de compra em conjunto com os Gerentes de Produtos,
quando necessário;
o Validação da transferência de produtos entre as filiais, quando necessário;
o Seleção e treinamento de novos colaboradores sobre o processo macro bem
como sobre o procedimento;
o Acompanhamento e análise crítica de avaliação de fornecedor em conjunto
com os gerentes de produtos; e
o Análise de mercado e prospecção de novas linhas.
• Gerente de produtos:
o Buscar contínuo comprometimento do comprador com os processos e,
principalmente, com a empresa;
o Representar a empresa junto aos fornecedores;
o Estar a par da situação financeira da empresa, no sentido de que as compras
não afetem negativamente a liquidez;
o Negociar a compra de mercadorias aos melhores preços possíveis e
praticados no mercado, programando os recebimentos de forma a minimizar
o risco de quebra de estoque e atraso na entrega, face à projeção de vendas e,
da mesma forma, para que esta não chegue antes da data necessária para que
não tenha perda no prazo de pagamento;
o Conhecer o mercado (principais clientes, fornecedores e concorrentes);
110
o Conhecer o nível do estoque (ideal, mínimo, máximo e existente) e mantê-lo,
minimizando o risco de quebra de estoque;
o Conhecer todas as áreas da empresa;
o Conhecer os produtos, das linhas pelas quais é responsável;
o Conhecer a média de vendas de cada produto;
o Conhecer as previsões de compra (programação);
o Verificação quanto ao recebimento dos produtos, se os fornecedores estão
cumprindo o acordado (preço, prazo de entrega, produtos, condições
financeiras e o transporte);
o Fluxo da logística junto aos fornecedores;
o Verificação da programação diária de compras;
o Validação dos pedidos de compra;
o Controle Rebates;
o Acordar e desenvolver campanhas em conjunto com o departamento de
marketing e quando necessário com a área comercial para desenvolver a
venda dos produtos;
o Buscar campanhas de incentivos de vendas internas/externas e ou rebates
junto aos fornecedores;
o Validação da transferência de produtos entre as filiais quando necessário;
o Treinamento de novos compradores;
o Acompanhamento e análise crítica de avaliação de fornecedor;
o Buscar e/ou ministrar treinamento na sua linha de produto, interno e externo;
o Análise e ações quanto necessário quanto aos Rebates em aberto, RMAs
pendentes, produtos deslacrados e devoluções de compras;
o Análise e conferencia dos rebates concedidos ao Call Center; e
o Seleção e treinamento de novos colaboradores sobre o processo macro bem
como sobre o procedimento.
• Comprador
o Negociar a compra de mercadorias de boa qualidade aos melhores preços
possíveis e praticados no mercado, programando os recebimentos de forma a
minimizar o risco de quebra de estoque e atraso na entrega, face à projeção
de vendas e, da mesma forma, para que esta não chegue antes da data
necessária para que não tenha perda no prazo de pagamento;
o Conhecer o mercado (clientes, fornecedores e concorrentes);
o Conhecer o nível do estoque (ideal, mínimo, máximo e existente) e mantê-lo,
minimizando o risco de quebra de estoque;
o Conhecer todas as áreas da empresa;
o Conhecer os produtos, das linhas pelas quais é responsável;
o Conhecer a Média de vendas de cada produto;
o Conhecer as previsões de compra (programação);
o Verificação quanto ao recebimento dos produtos, se os fornecedores estão
cumprindo o acordado (preço, prazo de entrega, produtos, condições
financeiras e o transporte);
o Fluxo da logística junto aos fornecedores; e
o Solicitação e validação da transferência de produtos entre as filiais quando
necessário.
• Assistente de Compras
o Transferência de produtos entre as filiais;
o Parciais do dólar;
o Controle e arquivamento dos documentos do departamento (Nota de débito
(ND), avaliação de fornecedores, ficha cadastral, Atas, e Registro de ocorrência
(RO));
o Relatório diário de acompanhamento de vendas das principais linhas de
produtos;
o Relatório diário de estoque;
o Relatório diário 60 dias;
o Relatório semanal de pendências em garantia;
o Relatório semanal de pendências de ND;
o Relatório semanal de pendências devolução;
o Emissão do relatório mensal de avaliação de fornecedores;
o Confecção das atas de reunião;
o Emissão relatórios sistêmicos solicitadas pela diretoria para análise macro do
departamento;
o Suporte para os demais da equipe quando necessário; e
o Responsável pelo material de expediente para o departamento.
II.2 DEFINIÇÃO ESTRATÉGICA DE FORNECEDOR
Qualquer Gerente de Produtos esta apto a efetuar acordos comerciais e definir parcerias de
sua linha de produtos, os quais desenvolverão as bandeiras. Porém caso se trate de um grande
fabricante, o GP deverá buscar o aval da gerencia de compras, e caso seja necessário ambos deverão
consultar a diretoria.
No início desta parceria já é negociada a forma de pagamento, tempo de transporte, política
de garantia, frete, relatórios, bem como a política de rebates, sell in, sell out, spiff, price protection,
113
treinamentos, ficando a cargo do depto de compras gerenciarem e alimentarem estas informações,
restrita a política estabelecida pelos fornecedores.
II.3 SOLICITAÇÃO DE CADASTRO DE FORNECEDOR
Depois de definida a parceria Pauta X Fornecedor é de responsabilidade do departamento de
compras solicitar as informações cadastrais do fornecedor e preencher uma ficha cadastral padrão
(conforme modelo em anexo) que contempla as seguintes informações:
1. Razão Social
2. CNPJ
3. Inscrição Estadual
4. Endereço Completo
5. Fone/Contato
6. Data da Solicitação
7. Comprador Responsável pela solicitação
De posse desta ficha cadastral preenchida, deverá o departamento de compras proceder da
seguinte forma:
• Encaminhar o formulário cadastral preenchido ao Setor de crédito para
cadastramento;
• O Setor de crédito fará uma consulta de Síntegra (inscrição estadual) e receita federal
(CNPJ), efetuará o cadastramento e devolverá o processo inteiro para o departamento
de compras;
• O departamento de compras arquivará o processo interno no departamento, na pasta
de fornecedor/fornecedores.
• Após passar pelo processo acima, o fornecedor estará apto a fornecer seus produtos a
Pauta.
Nota 1: Esta ficha é utilizada apenas no momento do cadastro do fornecedor, em todo o resto
do processo ela não volta a ser utilizada, ou seja, não é consultada para saber qual é o contato no
fornecedor ou qual o comprador atual responsável pela mesma. Desta forma os campos “Comprador
Responsável pela Solicitação” é a pessoa responsável pela solicitação na data em questão e
“Contato”, a pessoa que atende a Pauta no fornecedor na data em que é efetuado o cadastro. A
finalidade destes campos é para que o funcionário responsável pelo cadastro possa tirar alguma
dúvida, caso seja necessário, no momento do cadastramento e verificação fiscal do fornecedor.
II.4 CADASTRO DE PRODUTOS
Caso o produto a ser comprado ainda não esteja cadastrado em nosso sistema, cabe ao
departamento de compras efetuar o cadastro no sistema, sendo que após a conclusão do cadastro
deve ser enviado um e-mail aos conferencistas informando o novo código para estes complementem
o cadastro em situações específicas e agreguem produtos quando necessário.
II.5 EMISSÃO DO PEDIDO DE COMPRAS
Como início de todo o processo, realiza-se a negociação com o fornecedor, e depois de
acordadas quantidades, valores e prazos, é emitido um pedido de compra no sistema.
Após o comprador lançar o pedido no sistema, a situação do mesmo é em espera (situação =
1 no sistema). Desta forma o comprador deve enviar a confirmação do pedido para o fornecedor.
Quando este recebe a confirmação de faturamento do fornecedor, conforme o pedido de
compra bem como a previsão de recebimento, este lança a previsão de recebimento no sistema e
altera a situação do pedido para liberado para faturamento (situação = 6 no sistema).
Nota: Caso o comprador responsável pela linha não esteja na empresa, o gerente de produto
deve liberar os pedidos. Em casos em que o comprador e o gerente de produtos não estejam na
empresa, cabe a eles deixarem a instrução com a Assistente de compras dos processos em
andamento para que esta libere os pedidos.
II.6 RECEBIMENTO DE MERCADORIA
II.6.1 MERCADORIA COM ACEITE DE RECEBIMENTO PELO ESTOQUE
Nos casos em que o depto de estoque não encontrar divergências, deverá efetuar o
recebimento e aceite da mercadoria. Antes de dar entrada no sistema o conferencista informará ao
depto de compras, para que este faça os ajustes de custos que se façam necessários.
Nota: Se a diferença do preço faturado para o pedido de compra for menor ou igual a R$
10,00, não será necessária alteração no pedido, pois não será considerado como uma não
conformidade de faturamento e sim uma diferença de arredondamento, seja referente ao número de
casas decimais utilizada pelo fornecedor ou a taxa do dólar.
II.6.2 MERCADORIAS SEM ACEITE DE RECEBIMENTO PELO ESTOQUE
Nos casos em que a mercadoria não tenha sido aceita pelo depto de estoque por divergência,
o mesmo solicitará via e-mail um posicionamento ao departamento de compras para aceitar ou não
a mercadoria. É responsabilidade do departamento de compras informar quanto ao recebimento ou
não da mesma.
Nota: Quando o depto de estoque receber uma mercadoria com divergência deverá passar
um e-mail aos responsáveis pela linha com cópia para o setor de contas a pagar, informando quais
foram às divergências encontradas (por exemplo: um valor faturado a maior, prazo para pagamento,
frete incorreto, etc.), sendo que cabe ao departamento de compras responderem e justificarem a
causa das diferenças e como ficou acordado junto ao fornecedor para resolver as divergências, ou se
foi um erro do próprio departamento ao emitir o pedido.
II.7 ALTERAÇÃO DE CUSTO DE PRODUTOS EM ESTOQUE
O departamento de compras é responsável pelas alterações de custos no sistema, caso o
fornecedor conceda algum tipo de crédito específico (rebate, price protection, sell out), nos casos de
faturamentos incorretos (onde o fornecedor ressarcirá a divergência), ação estratégica da Pauta (de
acordo com diretrizes da diretoria), custos médios, ou valor pago de transporte, sendo que ao fazê-lo
cabe ao comprador ou Ger. de Produtos alimentarem a informação no sistema sobre o que se trata
para acompanhamento da Gerencia e Diretoria da área.
II.8 MONITORAMENTO DE MERCADO E ESTOQUE
Após o recebimento da mercadoria no estoque começa o monitoramento do produto,
cabendo ao gerente de produto e ao comprador controlar o nível de estoque para atender o volume
de vendas de sua linha de produtos.
Cada comprador gera diariamente a programação de compras e, junto com o gerente de
produtos, define as próximas compras bem como as ações para os casos de produtos com giro baixo
em estoque (quando necessário solicitam as informações para a assistente de compras, que
apresentará o comparativo do referido fornecedor).
Nota: Casos seja necessário, o comprador estará efetuando a impressão da programação de
compras para anotações e análise em conjunto com o gerente de produtos ou a gerencia de compras.
III. SCRIPT DE CRIAÇÃO DA ÁREA DE ESTAGIAMENTO
Função Script
Criação da dimensão Filial
create table filial ( FIL_CODIGO NUMBER(8,0) NOT NULL, FIL_DESCRICAO VARCHAR2(50) NOT NULL);
Criação da chave primária alter table filial add (PRIMARY KEY (FIL_CODIGO) ) ;Criação do índice create unique index XPKFILIAL on filial (FIL_CODIGO ASC);
Criação da trigger depois de deletar
create trigger tD_FILIAL after DELETE on FILIAL for each row declare numrows INTEGER;begin select count(*) into numrows from QUEBRA_ESTOQUE where QUEBRA_ESTOQUE.FIL_CODIGO = :old.FIL_CODIGO; if (numrows > 0) then raise_application_error(-20001,'Cannot DELETE FILIAL because QUEBRA_ESTOQUE exists.'); end if;end;
Criação da trigger depois de atualiza
create trigger tU_FILIAL after UPDATE on FILIAL for each row declare numrows INTEGER;begin if :old.FIL_CODIGO <> :new.FIL_CODIGO then select count(*) into numrows from QUEBRA_ESTOQUE where QUEBRA_ESTOQUE.FIL_CODIGO = :old.FIL_CODIGO; if (numrows > 0) then raise_application_error(-20005,'Cannot UPDATE FILIAL because QUEBRA_ESTOQUE exists.'); end if; end if;end;
IV. TELA DE CRIAÇÃO DO ESPAÇO ANALÍTICO DO DM
V. TELA DE CRIAÇÃO DA DIMENSÃO PRODUTO
VI. TELA DE CRIAÇÃO DA HIERARQUIA DA DIMENSÃO PRODUTO
VII. DESCRIÇÃO DA MODELAGEM ENTIDADE RELACIONAL
Tabela 10. Descrição da modelagem entidade relacional
TABELA PK FK CAMPO TIPO NOT
NULL BANCO Yes No BAN_CODIGO NUMBER(8) Sim No BAN_DESCRICAO CHARACTER(50) Não BAN_NUMERO NUMBER(8) CALENDARIO Yes CAL_DATA DATE Sim No CAL_DIAUTIL CHARACTER(2) Não CLASSE Yes CLA_CODIGO NUMBER(8) Sim No CLA_DESCRICAO CHARACTER(50) Não CLA_PERMITEVENDA CHARACTER(1) CLA_PERMITEFATURAMENTODIRETO CLA_SITUACAOSITE CLASSIFICACAO Yes CLF_CODIGO NUMBER(8) Sim No CLF_DESCRICAO CHARACTER(50) Não CODIGOFISCAL Yes CFI_CODIGO NUMBER(8) Sim No CFI_DESCRICAO CHARACTER(50) Não CFI_EMUSO CHARACTER(1) DOMINIO Yes DOM_CODIGO NUMBER(8) Sim No DOM_DESCRICAO CHARACTER(50) Não DOM_RAZAOSOCIAL DOM_ENDERECO DOM_CIDADE DOM_CEP NUMBER(8) DOM_ESTADO CHARACTER(3) DOM_ODBC CHARACTER(50) DOM_CGC CHARACTER(20) DOM_INSCRICAOESTADUAL DOM_INSCRICAOMUNICIPAL DOM_MENSAGEMICM CHARACTER(255) DOM_SEQBOLETO NUMBER(15) DOM_ICMSFRETE NUMBER(5,2) DOM_PATHFIGURA CHARACTER(200) DOM_IPEMAIL CHARACTER(50) DOM_BAIRRO DOM_FONE DOM_PRINCIPAL CHARACTER(1) FISICA Yes Yes PAR_CODIGO NUMBER(8) Sim No No FIS_CARTEIRAIDENTIDADE CHARACTER(20) Não FIS_CPF FIS_HABILITADOCPF CHARACTER(1) FIS_VALIDOCPF FORMAPAGAMENTO Yes FOR_CODIGO NUMBER(8) Sim No Yes TCR_CODIGO NUMBER(8,0) Não No FOR_DESCRICAO CHARACTER(50) Yes BAN_CODIGO NUMBER(8) No FOR_PRAZOMINIMO FOR_PRAZOMAXIMO TCR_CODIGO FOR_VISUALIZAWEB CHARACTER(1) FOR_VISUALIZASISTEMA FOR_VALORMINIMO NUMBER(13,2) FOR_VALORMAXIMO GRUPOITEM Yes GRU_CODIGO NUMBER(8) Sim Yes MAS_CODIGO No No GRU_DESCRICAO CHARACTER(50) Não GRU_MARGEM NUMBER(4,2)
2
GRU_ANTIGO CHARACTER(20) GRU_PESO NUMBER(13,2) GRU_VOLUME NUMBER(13,4) GRU_MOSTRARWEB CHARACTER(1) GRU_MOSTRAVENDACONSULTIVA ITEMESTOQUEGERAL Yes ITG_CODIGO NUMBER(8) Sim No Yes MAS_CODIGO Não MAR_CODIGO CLF_CODIGO LOC_CODIGO GRU_CODIGO SUB_CODIGO No ITG_DESCRICAO CHARACTER(100) ITG_ESPECIFICACAO CHARACTER(255) ITG_UNIDADE CHARACTER(2) ITG_MODELO CHARACTER(20) ITG_CODIGOUSUARIO CHARACTER(50) ITG_CODIGONBM ITG_EMBALAGEM ITG_VOLUME NUMBER(13,4) ITG_PESOLIQUIDO NUMBER(13,2) ITG_PESOEMBALAGEM ITG_VALIDADE DATE ITG_POSICAOCIF CHARACTER(20) ITG_ANTIGO ITG_DATAATUALIZACAO DATE ITG_PARTNUMBER CHARACTER(30) ITG_NUMEROPPB CHARACTER(10) ITG_DATAVALIDADEPPB DATE ITG_TEMPPB CHARACTER(1) ITG_PRODMANAUS ITG_NUMEROMANAUS CHARACTER(30) ITG_DATAVALIDADEMANAUS DATE ITG_PRAZOENTREGAFORNECEDOR CHARACTER(30) ITG_MANAUS CHARACTER(1) ITG_GARANTIA CHARACTER(255) ITG_SUFRAMA CHARACTER(13) ITG_CLASSIFICACAOFISCAL CHARACTER(20) ITG_FOB NUMBER(8,2) ITG_COMPUTADORTODOS CHARACTER(1) ITG_ALTURA NUMBER(13,2) ITG_PROFUNDIDADE ITG_LARGURA ITG_EAN NUMBER(13) ITEMNOTA Yes Yes NOT_CODIGO NUMBER(8) Sim NOT_SEQUENCIAL DOM_CODIGO ITG_CODIGO No No INO_QUANTIDADE Não INO_VALORUNITARIO NUMBER(13,5) INO_DESCONTO NUMBER(13,2) INO_ICMS NUMBER(4,2) INO_IPI INO_SITUACAOTRIBUTARIA CHARACTER(3) INO_REDUCAO NUMBER(8,2) INO_NOTAFISCALFORNECEDOR NUMBER(8) INO_FORNECEDOR INO_VALORICMS NUMBER(13,2)
3
INO_VALORIPI INO_BASEICMS INO_REDUCAOIPI NUMBER(8,2) ITEMPEDIDO Yes Yes PED_CODIGO NUMBER(8) Sim PED_SEQUENCIAL DOM_CODIGO ITG_CODIGO No No IPE_QUANTIDADE Não IPE_VALORUNITARIO NUMBER(13,5) IPE_DESCONTO NUMBER(13,2) IPE_ICMS NUMBER(4,2) IPE_IPI IPE_SITUACAOTRIBUTARIA CHARACTER(3) IPE_VALORREFERENCIA NUMBER(13,2) IPE_ITEMPROMOCIONAL NUMBER(2) IPE_REDUCAO NUMBER(8,2) IPE_REDUCAOIPI IPE_VALORREVENDA NUMBER(13,2) JURIDICA Yes Yes PAR_CODIGO NUMBER(8) Sim No No JUR_CNPJ CHARACTER(14) Não JUR_INSCRICAOESTADUAL CHARACTER(20) JUR_INSCRICAOMUNICIPAL JUR_HABILITADOCNPJ CHARACTER(1) JUR_HABILITADOIE JUR_VALIDOCNPJ JUR_VALIDOIE POR_CODIGO NUMBER(8) REGI_CODIGO LOCALIZACAO Yes LOC_CODIGO Sim No LOC_DESCRICAO CHARACTER(50) Não MARCA Yes MAR_CODIGO NUMBER(8) Sim No MAR_DESCRICAO CHARACTER(50) MASTERGRUPO Yes MAS_CODIGO NUMBER(8) No MAS_DESCRICAO CHARACTER(50) Não MAS_MARGEM NUMBER(4,2) MAS_ANTIGO CHARACTER(3) USR_CODIGO NUMBER(8) MAS_PECAUNICA CHARACTER(1) MAS_MOSTRARWEB MAS_MOSTRAVENDACONSULTIVA NOTAFISCAL Yes NOT_CODIGO NUMBER(8) Sim NOT_SEQUENCIAL Yes DOM_CODIGO No PAR_CODIGO Não TRA_CODIGO STN_CODIGO CFI_CODIGO ORI_CODIGO Sim No NOT_ESPECIE CHARACTER(2) Não NOT_SERIE CHARACTER(3) NOT_DATAEMISSAO DATE NOT_DATASAIDA NOT_DESCONTO NUMBER(13,2) NOT_FRETE NOT_SEGURO NOT_OUTRA NOT_BASEISS NOT_VALORISS
4
NOT_OBSERVACAO CHARACTER(255) NOT_DESCRICAOSERVICO NOT_VALORIR NUMBER(13,2) NOT_VALORINSS NOT_DATAATUALIZACAO DATE PGT_CODIGO NUMBER NOT_DATACANCELAMENTO DATE TCA_CODIGO NUMBER(8) NOT_CODIGOSUBSTITUICAO USR_CODIGOSEPARADOR NOT_VALORINSSDESCONTO NUMBER(13,2) NOT_FRETEDESTAQUE NOT_ALIQUOTAIPIICM NUMBER(8,2) NOT_VALORPIS NUMBER(13,2) NOT_VALORCOFINS NOT_VALORCSLL NOT_ALIQUOTAICMFRETE NOT_BASEICMS NOT_VALORICMS NOT_PESO NOT_VOLUME NOT_TOTALPRODUTO NOT_TOTAL NOT_ARREDONDAMENTO NOT_IMPRESSOPAUTA CHARACTER(1) NOT_VALORIPI NUMBER(13,2) NOT_DATALANCAMENTO DATE NOT_ARREDONDAMENTOPRODUTO NUMBER(13,2) NOT_ARREDONDAMENTOVALORICMS NOT_ARREDONDAMENTOVALORIPI NOT_ARREDONDAMENTOBASEICMS NOT_ARREDONDAMENTOBASEIPI NOT_ARREDONDAMENTOTOTAL NOT_PAR_DESCRICAO CHARACTER(100) NOT_PAR_ENDERECO NOT_PAR_BAIRRO NOT_CID_CODIGO NUMBER(8) NOT_PAR_CNPJ_CPF CHARACTER(25) NOT_PAR_IE_RG NOT_PAR_FONE CHARACTER(20) NOT_PAR_CEP NUMBER(8) ORIGEM Yes ORI_CODIGO Sim No ORI_DESCRICAO CHARACTER(50) Não PARCEIRO Yes PAR_CODIGO NUMBER(8) Sim No CID_CODIGOENTREGA Não Yes FOR_CODIGO DOM_CODIGO No CID_CODIGOCOBRANCA Yes TRA_CODIGO CLA_CODIGO No PAR_DESCRICAO CHARACTER(50) PAR_NOMEFANTASIA CHARACTER(250) PAR_EMAIL PAR_AUTORIZA CHAR(1) PAR_FONE1 CHARACTER(15) PAR_FONE2 PAR_FONE3 PAR_FAX
5
PAR_ENDERECOENTREGA CHARACTER(50) PAR_PONTOREFERENCIAENTREGA PAR_CEPENTREGA NUMBER(8) PAR_BAIRROENTREGA CHARACTER(50) PAR_ENDERECOCOBRANCA PAR_PONTOREFERENCIACOBRANCA PAR_CEPCOBRANCA NUMBER(8) PAR_DATAATUALIZACAO DATE PAR_BAIRROCOBRANCA CHARACTER(50) PAR_TIPOPESSOA NUMBER PAR_HOMEPAGE CHARACTER(250) PAR_OBSERVACAO CHARACTER(255) PAR_LIMITECREDITO NUMBER(13,2) USR_CODIGOVENDEDOR NUMBER(8) PAR_CONTRATOSOCIAL CHAR(1) PAR_ULTIMOBALANCO CHARACTER(5) PAR_XEROXIDENTIDADECPF CHAR(1) PAR_CARTAOCGC PAR_FICHAATUALIZACAO PAR_RELACAOBENS PAR_REFBANCARIA PAR_REFCOMERCIAL PAR_DATACADASTRO DATE PAR_DATAESTIPULACAOCREDITO PAR_DATASINTEGRA PAR_HABILITADO CHAR(1) PAR_HABILITADOINSCRICAO PAR_HABILITADOCNPJ PAR_DATARECEITAFEDERAL DATE PAR_VALORFIANCA NUMBER(13,2) PAR_ULTIMAALTERACAOCONTRATUAL NUMBER(8) PAR_DATAFUNDACAO DATE PAR_CAPITALSOCIAL NUMBER(13,2) PAR_BOLETOQUITADO CHAR(1) PAR_DATABOLETOQUITADO DATE PAR_FICHACADASTROPAUTA CHAR(1) PAR_DATAULTALTERACAOCONTRATUAL DATE PAR_ULTALTERACAOCONTRATUAL CHARACTER(40) PAR_IRSOCIOS CHARACTER(20) SPA_CODIGO NUMBER(8) CAR_CODIGO PAR_DATAVENCIMENTOFICHA DATE PAR_EMAILINVALIDO CHARACTER(1) PAR_TELEFONEINVALIDO PAR_TELEFONESPAM CAR_CODIGO1 NUMBER(8) CAR_CODIGO2 PAR_POTENCIAL CHARACTER(250) POT_CODIGO NUMBER(8) PAR_IRSOCIOSANO CHARACTER(20) PAR_PERMITECOMISSAOLIQUIDA CHARACTER(1) PAR_IPIINTEL CHARACTER(10) PAR_DATARECADASTRO DATE PAR_PERMITEFTRDIRETONFSERVICO CHARACTER(1) PAR_PERMITEFTRDIRETODESCONTO PAR_DATAVENCIMENTOFIANCA DATE PAR_POTENCIAL1 CHARACTER(255) CAR_CODIGO3 NUMBER(8)
6
CAR_CODIGO4 CAR_CODIGO5 PAR_VENCIMENTOANALISE DATE PEDIDO Yes PED_CODIGO NUMBER(8) Sim PED_SEQUENCIAL Yes DOM_CODIGO No SPE_CODIGO Não No DOL_DATAREFERENCIA DATE PGT_CODIGO NUMBER(8) Yes TPE_CODIGO Sim No CTA_CODIGO Não Yes TRA_CODIGO No PAR_CODIGONOTA PED_EMISSAO DATE PED_OBSERVACAO CHARACTER(255) USR_CODIGOAUTORIZA NUMBER(8) USR_CODIGOVENDEDOR DOM_CODIGOEMITENTE PED_DOLARBASE NUMBER PAR_CODIGOCONTRAFATURAMENTO NUMBER(8) PED_NUMEROPARCELA PED_INICIODIA PED_PRAZO PED_DATAATUALIZACAO DATE PED_DATAPREVISAOENTREGA PED_DESCONTO NUMBER(13,2) PED_FRETE PED_OUTRAS PED_SEGURO PED_BASEDATACONDICAOPAGTO CHARACTER(1) PEDIDONOTA Yes Yes NOT_CODIGO NUMBER(8) Sim NOT_SEQUENCIAL PED_CODIGO PED_SEQUENCIAL DOM_CODIGO SALDOITEM ITG_CODIGO DOM_CODIGO No SLD_ANOMES NUMBER(6) No SLD_ENTRADA NUMBER(8) Não SLD_SAIDA SLD_DEMOPAUTA SLD_DEMOPARCEIRO SLD_ANTERIOR SITUACAONOTA Yes STN_CODIGO Sim No STN_DESCRICAO CHARACTER(50) Não SITUACAOPEDIDO Yes SPE_CODIGO NUMBER(8) Sim No SPE_DESCRICAO CHARACTER(50) Não SUBGRUPOITEM Yes SUB_CODIGO NUMBER(8) Sim Yes GRU_CODIGO MAS_CODIGO No No SUB_DESCRICAO CHARACTER(50) Não SUB_MARGEM NUMBER(4,2) SUB_PESO NUMBER(13,2) SUB_VOLUME NUMBER(13,4) TIPOCREDITO Yes TCR_CODIGO NUMBER(8,0) Sim No TCR_DESCRICAO VARCHAR2(20) Não TIPOPEDIDO Yes TPE_CODIGO NUMBER(8) Sim No TPE_DESCRICAO CHARACTER(50) Não
7
TPE_MOVESTOQUE CHARACTER(1) TPE_MOVDUPLICATA TPE_PRECISAAUTORIZACAO TPE_SOEXISTENTE TPE_FAZRESERVA TPE_TEMMERCADORIA TPE_TEMSERVICO TPE_TEMRECEITADESPESA TPE_TEMICMS TPE_USAFATURAMENTO TPE_TEMCOMISSAO TPE_TIPOPARCPEDIDO NUMBER(8) TPE_PERMITEFATURARPARCIAL CHARACTER(1) TPE_TEMINSS TPE_TEMISS TPE_TEMIR TPE_OBRIGACOMISSAO TPE_TEMPIS TPE_TEMCOFINS TPE_TEMCSLL TPE_CORRIGEICMSAUTO TPE_RETEMISS TPE_CONSIDERARCUSTO TPE_ACUMULADOR NUMBER(8) TPE_VERIFICAETQDESLACRADO CHARACTER(1) TPE_INICIATIVA TPE_CORRIGEIPISAIDAIMPORTADO TPE_BLOQUEIAFTRPESSOAFISICA TPE_CONSIDERACUSTOREAL TPE_VALIDAMARKUP TRANSPORTADORA Yes TRA_CODIGO NUMBER(8) Sim No CID_CODIGO Não TRA_DESCRICAO CHARACTER(50) TRA_FONE CHARACTER(15) TRA_ENDERECO CHARACTER(50) TRA_CEP NUMBER(8) TRA_CONTATO CHARACTER(20) TRA_OBSERVACAO CHARACTER(255) TRA_CNPJ CHARACTER(20) TRA_INSCRICAOESTADUAL TRA_ACORDO CHARACTER(1) Yes DOM_CODIGO NUMBER(8) No STR_CODIGO TRA_MOSTRASITE CHARACTER(1) TRA_MOSTRASISTEMA TRA_MOSTRASISTEMA_PARCEIRO TRA_MOSTRASITE_PARCEIRO TRA_DATAATUALIZACAO DATE TRA_MOSTRA_PARCEIRO_COMPRA CHARACTER(1) TRA_MOSTRA_PAUTA_COMPRA
VIII. PRIMEIRA ETAPA DO PROCESSO DE CARGA DE UMA DIMENSÃO
IX. SEGUNDA ETAPA DO PROCESSO DE CARGA DE UMA
DIMENSÃO
X. TERCEIRA ETAPA DO PROCESSO DE CARGA DE UMA DIMENSÃO
XI. SEGUNDA ETAPA DO PROCESSO DE CARGA DE UM CUBO
