No entanto, a criação de um DW não está intimamente relacionada à tecnologia de banco de dados ou de servidores. Devido ao fato de já existir um banco de dados na empresa, será necessária a implementação de um novo DW (INMON, 1997).
PROBLEMATIZAÇÃO
Formulação do Problema
Observou-se a possível utilização de um Data Mart, que segundo Inmon (1997) visa organizar, por exemplo, cada setor da empresa, tendo cada área seu próprio repositório de dados.
Solução Proposta
Portanto, a utilização de uma topologia DW chamada Data Mart (DM) seria muito importante, considerando possíveis integrações futuras em um DW.
OBJETIVOS
Objetivo Geral
Objetivos Específicos
METODOLOGIA
ESTRUTURA DO TRABALHO
Este capítulo também discutiu a estrutura das tabelas utilizadas pelo sistema de documentação de exportação.
ESTUDO DE CONCEITOS
- Oracle
- Data Warehouse
- OLAP
- OLTP X OLAP
- Topologias de um Data Warehouse
- Sistemas de Apoio a Decisão
Como os dados informativos requerem uma quantidade significativa e diversificada de recursos, eles devem ser separados dos dados operacionais em um ambiente de banco de dados. Em segundo lugar, as estruturas básicas de dados do DW são completamente diferentes daquelas do sistema OLTP.
ÁREA DE EXPORTAÇÃO DA SEARA ALIMENTOS S.A
Processo de Exportação
Após cadastrar essas informações, o pedido é inserido no conhecimento de embarque, que contém informações sobre o cliente, a filial de produção (dados derivados do pedido), a filial do contêiner, a quantidade no contêiner, a filial de exportação (a filial responsável para faturamento), etc. , e você pode receber mais de um pedido. O programa CMEK5610 gera o certificado de origem e as tabelas form-a (o certificado form-a utiliza as mesmas tabelas do certificado de origem, conforme mostra a estrutura da Figura 10). O usuário entra nas print screens, solicita documento via planejamento de carga e guia de transporte.
O módulo Documentação CMEK funciona da seguinte forma: o usuário informa o número da lista de planejamento e carga, e através de procedimentos armazenados (rotinas de execução de instruções para realização de tratamentos e transações no banco de dados) os documentos são gerados automaticamente. As informações também são recuperadas de outros sistemas (Sistema de Produção, Cadastro de Clientes, etc.) e armazenadas nestas tabelas divididas por planejamento e lista de carga. Todas essas tabelas possuem informações de código de planejamento e lista de carga e estão “centralizadas” na tabela FIL_EXP_ITEM_LISTA_CARGA_MRM.
MODELAGEM
Porém, os documentos envolvidos na exportação são carregados nas tabelas de transição somente quando um evento denominado Confirmação de Embarque é inserido na tabela de rastreamento, o que evita que um usuário gere alguns documentos e a transação comercial não ocorra por algum motivo. , que não gera possíveis custos de regeneração de documentos, não afetará os resultados obtidos nas consultas do Data Mart pelos gestores. A modelagem dimensional requer o mapeamento de tabelas de dimensões, bem como a criação de tabelas de granularidade de fatos e DM, com o objetivo de atender às necessidades de informações gerenciais solicitadas pelo gestor da área, como “qual mercado tem mais erros por mês”. Nesta modelagem observamos a existência de cinco tabelas de dimensões e uma tabela de fatos conectadas pelas respectivas chaves.
As tabelas de dimensão cliente e mercado são responsáveis por descrever os códigos que aparecerão nas consultas por estes motivos. As tabelas de dimensão Dim_tipo_campo e Dim_tipo_documento, mostrarão aos gestores quais documentos possuem erros e quais campos(s) causaram o erro, bem como os responsáveis e o sistema de origem. Isso foi possível porque todas as tabelas do sistema da empresa possuem o campo usuário e data de atualização do registro, possibilitando carregar essas tabelas de dimensões com essas informações de responsabilidade.
ANÁLISE DE INFORMAÇÕES GERENCIAIS
A tabela de fatos FT_COTACAO é utilizada para consultar as taxas de câmbio nas datas de geração dos documentos. O valor da cotação é carregado diariamente em uma tabela do sistema relacional da empresa e é carregado na tabela de transição TRANSICAO_MOEDA_EXP_CNE. Sempre no último dia do mês, através de uma tarefa executiva (rotina que é executada periodicamente conforme a necessidade), busca-se em uma tabela transitiva as informações do mês anterior, os valores médios daquele mês.
A tabela fato FT_DOCUMENTACAO_EXP_CNE é utilizada para que todas as dúvidas dos gestores quanto à geração da documentação de exportação possam ser respondidas. A partir daí, existem conexões com todas as tabelas de dimensões no modelo lógico que fornecem essas informações. Um ponto relevante é que o campo VL_CARTA_CORRECAO está dentro de uma tabela de dimensões e não dentro da tabela de fatos, como era esperado.
CONSTRUÇÃO DO MODELO FÍSICO
MODELAGEM LÓGICA DAS TABELAS DE TRANSIÇÃO
Para controle são utilizados os campos DT_ATUALIZACAO e ID_USUARIO, pois são registrados a data e a hora, além do número de cadastro do usuário, cada vez que o registro é inserido ou alterado. Para a tabela de transição utilizada para carregar as tabelas FT_COTACAO e CURRENCY também foi utilizado um procedimento armazenado chamado a partir de um job de execução, porém o tempo de carregamento desta tabela é diário, após 19h00, para que haja sempre informação sobre o valor médio da moeda.
PROCESSO DE CARGA NA ÁREA DE TRANSIÇÃO
Para atualizar a tabela de transição TRANSICAO_MOEDA_EXP_CNE foi utilizado o procedimento armazenado CMEK9001.pck (o código fonte é mostrado no Apêndice A.2, CMEK9001.pck). Uma vez identificado esse registro, inicia-se a filtragem dos dados, que consiste em não permitir a entrada de registros duplicados ou potencialmente errôneos (por limitações ou problemas na busca de dados) na tabela de transição. O procedimento armazenado CMEK9001 também carrega a tabela de transição, porém, exclusivamente para a parte da cota de moeda.
Os dados são armazenados nas tabelas de transição até que o JOB seja executado para a carga DM no final do mês, ou seja, todo último dia do mês após 21h30, o procedimento armazenado CMEK9002 é chamado (Apêndice D, CMEK9002. pck ) , onde são pesquisados os dados das tabelas de transição, são pesquisadas as próximas chaves a serem inseridas e por fim são carregadas as tabelas DM. Para evitar a inserção de dados, a tabela de transição só é limpa quando não há mais registros nela. Ao final de todos os registros inseridos, a tabela de transição é escaneada, verificando se não há registros com erros.
CONSTRUÇÃO DE RELATÓRIOS
Este sinalizador está na tabela FLAG_DATA_MART e é preenchido quando os dados daquele mês terminam de carregar o DM. As validações de dados foram realizadas através da execução de relatórios utilizando Business Objects, após os quais foram realizadas consultas diretamente no banco de dados transacional utilizando linguagem SQL. Os dados apresentados nos relatórios são dados armazenados no ambiente de desenvolvimento da empresa durante o período de janeiro de 2003 a dezembro de 2004, conforme explicado na problematização do projeto.
No ambiente de homologação da empresa (espelho do banco de dados de produção), já foi implementado o Data Mart, possibilitando a visualização de relatórios com dados reais e atualizados. Para validar as consultas gerenciais foi realizada reunião com o desenvolvedor do Data Mart, o Analista de Sistemas da área de exportação e o gerente da área de documentação de exportação da empresa. Após validações e aprovações na base de testes do DM, os gestores terão a opção de implementá-lo na base de produção da empresa, possibilitando a utilização do DM para reduzir custos de documentação e decisões relacionadas ao sistema.
CMEK3600.pck
CMEK9000.PCK
VOEG IN transicao_documentacao_exp_cne@C0827DVM (kies afsonderlike. b.cd_programacao_mrm_rdv plano, b.cd_lista_carga,. f.cd_csd_carga_exp_cne, g.cd_cliente_intern_m_client, h.cd_cliente_intern_m_client, i.e.m. ( b.dt_inclusao), MIN( b.d t_inclusion), sysdate ; mrm_rdv = P_CD_PLANE JAMENTO en b.cd_lista_carga = P_CD_LISTA_CARGA. en b.cd_ponto_verificacao = c .cd_ponto_verification _lista_carga = f.cd_lista_carga. en f.cd_plj_trp_mrm_exp_cne = i.cd_plj_trp_mrm_exp_cne en f.cd_lista_carga = i.cd_lista_carga. en f.cd_lista_carga. en f.cpnecd_pedido g_expnecd_pedido en_expnecd g.cd_cliente_internacional = h.cd_cliente_internacional en i.cd_mercado = j.cd_mercado .
CMEK9001.PCK
CMEK9002.PCK
INSERT INTO DIM_TYPE_FIELD VALUES( .. R1.DS_RESPONSAVEL_ERRO, R1.DS_SEVERITY_ERRO, R1.CD_SISTEMA_ORIGEM);. INDSÆT I FT_DOCUMENTACAO_EXP_CNE VALUES ( 'TIME', . VA_CH_CLIENTE, VA_CH_MERCADO, VA_CH_PLANEJAMENTO, VA_CH_TIPO_DOC, VA_CH_TIPO_CAMPO, 'QT_ERRADOS_', 'QT_ERRADOS_', 'ACT_ERRADOS_', 'QT_ERRADOS_', 'ACTSROTS_PRCOR'ER', 'ACTSPROS.'
SCRIPT CRIAÇÃO DM
ALTER TABLE DIM_TYPE_DOCUMENT ADICIONAR CONSTRAINT DIM_TYPE_DOC_PK CHAVE PRIMÁRIA (CHAVE_TYPE_DOC). CHAVE_TIPO_FIELD NUMBER(7) NÃO NULO, CD_TIPO_FIELD NUMBER(3) NÃO NULO, DS_TIPO_FIELD VARCHAR2(50) NÃO NULO, DS_GROUPING VARCHAR2(50),. ALTER TABLE DIM_TYPE_FIELD ADICIONAR CONSTRAINT DIM_TYPE_FIELD_PK CHAVE PRIMÁRIA (KEY_TYPE_FIELD).
Create table FT_DocumentACAO_EXP_CNE (CHAVE_TEMPO NUMBER (7) Not NULL, CHAVE_CLIENE NUMBER (7) Not NULL, CHAVE_MERCADO NUMBER (7) Not NULL, CHAVE_TIPO_CAMPO NUMBER (7) NOUR NO) NOT NOT NUM) NOT NOT NUST (7) NOT NULL, .
SCRIPT CRIAÇÃO TRANSIÇÃO
CMEK9003.PCK
CRIAÇÃO DE UNIVERSO B.O
Clicar duas vezes em qualquer parte da caixa branca abre uma pequena tela onde podemos inserir as tabelas que serão utilizadas para construir o universo. Uma vez inseridas as tabelas, elas devem ser vinculadas à chave primária clicando na tabela de origem no topo do campo-chave e arrastando o mouse até o topo do campo-chave da tabela de destino, conforme mostrado na Figura 24. Todas as tabelas devem estar vinculados corretamente, caso contrário poderão criar produtos cartesianos no momento das consultas.
Uma vez concluído o “desenho” das tabelas do universo, deverão ser criadas classes com os campos disponíveis para consulta, para que o usuário possa desenvolver os relatórios. Para fazer isso, você precisa arrastar a tabela desejada até a caixa no canto esquerdo da tela. Com o universo totalmente criado (Figura 27), ele poderá ser exportado para produção, onde ficará disponível a todos os usuários com permissão para desenvolver seus relatórios para conferências e outros fins.
RELATÓRIOS
Quantidade de documentos emitidos com erros e quantidade de documentos emitidos sem erros (bem como seus respectivos percentuais);
ATA DE REUNIÃO DE VALIDAÇÃO
