Embed Size (px)
Citation preview
i
Business Intelligence
Paulo Sérgio de Figueiredo Marques
Aplicação prática na Avicultura
Trabalho de Projeto apresentado como requisito parcial para
obtenção do grau de Mestre em Estatística e Gestão de
Informação
ii
Business Intelligence
Paulo Sérgio de Figueiredo Marques
Aplicação prática na Avicultura
Trabalho de Projeto apresentado como requisito parcial para
obtenção do grau de Mestre em Gestão de Informação
i
Título: Business Intelligence
Subtítulo:Aplicação prática na Avicultura Paulo Sérgio de Figueiredo Marques MEGI
20
15
20
15
Título:Business Intelligence
Subtítulo:Aplicação prática na Avicultura Paulo Sérgio de Figueiredo Marques MGI
i
ii
NOVA Information Management School
Instituto Superior de Estatística e Gestão de Informação
Universidade Nova de Lisboa
BUSINESS INTELLIGENCE
APLICAÇÃO PRÁTICA NA AVICULTURA
por
Paulo Sérgio de Figueiredo Marques
Trabalho de Projeto apresentado como requisito parcial para a obtenção do grau de Mestre em
Gestão de Informação, Especialização em Gestão do Conhecimento e Business Intelligence
Orientador/Coorientador: Professor Doutor Roberto Henriques
iii
AGRADECIMENTOS
Um agradecimento, muito especial, ao meu orientador Professor Doutor Roberto Henriques, pela
disponibilidade, atenção, dedicação e profissionalismo.
Agradeço à Avibom, pela aposta que fizeram em mim, para o desenvolvimento deste projeto.
À minha esposa, Paula Queirós, pelo incentivo, paciência e coragem, durante todo este período.
Ao meu filho Guilherme, com 7 anos, pelo tempo que prescindiu do Pai e que tanto me custou.
A toda a minha família e em particular aos meus sogros e cunhados, quer pelo apoio e confiança
depositada, bem como, por toda a disponibilidade manifestada ao meu filho e esposa, na minha
forçada ausência.
Aos meus colegas de mestrado, pelos momentos partilhados juntos e pela coragem e determinação
que sempre me transmitiram, que se revelaram determinantes ao longo do mestrado.
A todos vocês, os meus sinceros agradecimentos por terem contribuído direta e indiretamente de
forma significativa, para que este projeto tivesse chegado a bom termo… Obrigado por tudo !!!
iv
RESUMO
Numa sociedade do conhecimento e num mercado cada vez mais competitivo, onde os volumes de
dados crescem exponencialmente e são cada vez mais complexos, é cada vez mais difícil o tratamento
da informação.
Neste contexto, torna-se necessário recorrer a um conjunto de técnicas e ferramentas de suporte ao
negócio, destacando-se o Business Intelligence, com um papel determinante na solução.
A Avibom é uma empresa inserida no ramo agroalimentar, sendo uma empresa de particular
relevância no mercado nacional e líder no abate e comercialização de aves em Portugal. Com a
aplicação das ferramentas de Business Intelligence, propõe-se desenvolver uma plataforma de
informação, com uma visão unificada dos dados, cujo objetivo é construir um sistema de exploração
analítica, consolidado no Data Warehouse da organização. Possibilitando o suporte à tomada de
decisão de uma forma mais sólida, clara e eficiente.
As inúmeras vantagens daqui decorrentes, constituem a motivação para a elaboração deste relatório
como parte integrante do Mestrado em Gestão de Informação, com a vertente de especialização em
Gestão do Conhecimento e Business Intelligence.
PALAVRAS-CHAVE
Business Intelligence; Data Warehouse; Modelação Dimensional; Plataforma de BI da Microsoft
v
ABSTRACT
In a knowledge society and in an increasingly competitive market, in which data volumes increase
exponentially and are gradually more complex, it is increasingly challenging to generate evidence from
data.
In this context, it is key to take advantage of Business Intelligence and similar business support tools
and techniques centered on problem solving.
Avibom operates in the agri-food industry, is a company of particular relevance in the domestic market
and leader in the slaughter and trade of poultry in Portugal. Making use of business intelligence tools,
Avibom is investing in the development of an information platform with a unified view of data, whose
goal is to build an analytical operating system, consolidated in the Data Warehouse of the
organization. This will enable providing support to decision-making in a more solid, clear and efficient
manner.
The numerous advantages derived from this initiative constitute the motivation behind this report as
part of the Master in Statistics and Information Management, with a specialization in Knowledge
Management and Business Intelligence.
KEYWORDS
Business Intelligence; Data Warehouse; Dimensional Model; Platforms BI Microsoft;
vi
ÍNDICE
1. Introdução .................................................................................................................... 1
1.1. Enquadramento Geral ........................................................................................... 1
1.2. Enquadramento do Problema ............................................................................... 2
1.3. Definição do Problema .......................................................................................... 2
1.4. Objetivo ................................................................................................................. 2
1.5. Organização do Relatório ...................................................................................... 3
1.6. Planeamento ......................................................................................................... 3
1.6.1. Fases do Projeto ............................................................................................. 3
1.6.2. Cronograma do Projeto .................................................................................. 4
2. Enquadramento do Negócio......................................................................................... 5
2.1. Caraterização da Empresa ..................................................................................... 5
2.2. Visão ...................................................................................................................... 5
2.3. Missão .................................................................................................................... 5
2.4. ERP - SAP ................................................................................................................ 6
2.5. Identificação das Necessidades do Negócio.......................................................... 6
2.6. Necessidades Finais ............................................................................................... 7
2.7. Importância e Relevância do Projeto .................................................................... 7
3. Enquadramento Teórico ............................................................................................... 8
3.1. Breve Historial ....................................................................................................... 8
3.2. Business Intelligence ............................................................................................. 8
3.3. Data warehouse................................................................................................... 10
3.3.1. Ferramenta OLAP (Multidimensional) e Tabular ......................................... 13
4. Contexto ..................................................................................................................... 21
4.1. Enquadramento Técnico ..................................................................................... 21
4.2. Modelo Dimensional do DW ............................................................................... 22
4.3. Modelo Tabular ................................................................................................... 23
4.4. Descrição Técnica ................................................................................................ 24
4.4.1. Fontes de Dados ........................................................................................... 24
4.4.2. Staging Area .................................................................................................. 25
4.4.3. Data Warehouse e Data Marts ..................................................................... 25
4.4.4. Relatórios ...................................................................................................... 25
5. Análise e Estrutura do DW ......................................................................................... 29
5.1. Introdução ........................................................................................................... 29
vii
5.2. Análise do Negócio .............................................................................................. 29
5.3. Origem Dados ...................................................................................................... 31
5.4. Estrutura Dimensional ......................................................................................... 32
5.4.1. Classificação das Entidades .......................................................................... 33
5.4.2. Identificação das Hierarquias ....................................................................... 34
5.4.3. Matriz Bus ..................................................................................................... 36
5.4.4. Granularidade ............................................................................................... 37
5.5. Identificação e Caraterização do Modelo Dimensional ...................................... 37
5.5.1. Tabela de Factos ........................................................................................... 37
5.5.2. Chaves Artificiais (Surrogate Keys) ............................................................... 38
5.5.3. Dimensões .................................................................................................... 38
5.5.4. Definição das Métricas ................................................................................. 43
5.6. Estrutura Física da SA e DW ................................................................................ 44
6. Desenvolvimento do Projeto ...................................................................................... 46
6.1. Processo ETL ........................................................................................................ 47
6.1.1. Fontes de Dados ........................................................................................... 47
6.1.2. Staging Area .................................................................................................. 48
6.1.3. Data Marts .................................................................................................... 53
6.2. Relatórios ............................................................................................................. 60
6.2.1. Ciclo de Vida ................................................................................................. 60
6.2.2. Estrutura Funcional ...................................................................................... 61
6.2.3. Descrição dos Relatórios .............................................................................. 66
6.2.4. Exemplos ...................................................................................................... 68
7. Implementação do Projeto ......................................................................................... 77
7.1. Validação e Testes Finais ..................................................................................... 77
7.2. Implementação dos Jobs ..................................................................................... 77
8. Conclusões .................................................................................................................. 78
8.1. Objetivos Concretizados ...................................................................................... 78
8.2. Limitações ............................................................................................................ 79
8.3. Trabalho Futuro ................................................................................................... 80
9. Bibliografia .................................................................................................................. 82
10. Anexos ................................................................................................................. 85
10.1. Anexo A – Views do sistema Fonte ............................................................. 85
10.1.1. VW_DWValouroVendas ...................................................................... 85
10.1.2. VW_DWValouroProdutos ................................................................... 87
viii
10.1.3. VW_DWValouroClientes ..................................................................... 88
10.1.4. VW_DWValouroCompras .................................................................... 88
10.2. Anexo B – ETL .............................................................................................. 90
10.2.1. SA ......................................................................................................... 90
10.2.2. DM ....................................................................................................... 93
10.3. Anexo C – Views do DW .............................................................................. 96
10.3.1. VW_DWVendasPowerViewGeo .......................................................... 96
10.3.2. VW_DWVendasPowerViewGeo_1802 ................................................ 97
10.3.3. VW_DWComprasPowerViewGeo........................................................ 98
10.3.4. VW_DWVendas ................................................................................... 99
10.4. Anexo D – Diagrama do Sistema SAP ........................................................ 102
ix
ÍNDICE DE FIGURAS
Figura 1 – Componentes principais de uma arquitetura de Business Intelligence .................... 9
Figura 2 – Representação cubo (Wrembel R. e Koncilia, C., 2007) .......................................... 14
Figura 3 – Arquitetura Business Intelligence do projeto.......................................................... 21
Figura 4 - Exemplo modelo em Estrela, adaptado (Kimball & Ross, 2013) .............................. 23
Figura 5 - Fluxo de informação para os relatórios do projeto ................................................. 25
Figura 6 – Exemplo plataforma Gestão Web de relatórios ...................................................... 27
Figura 7 – Exemplo do site de relatórios no Sharepoint da Avibom ........................................ 27
Figura 8 - Arquitetura relatórios Excel 2013 do projeto .......................................................... 28
Figura 9 – Fluxo dos documentos de venda ............................................................................. 30
Figura 10 – Fluxo dos documentos de compra ........................................................................ 30
Figura 11 - Diagrama das vendas da estrutura de origem ....................................................... 31
Figura 12 - Diagrama das compras da estrutura de origem..................................................... 32
Figura 13 – Exemplo hierarquia produtos em SAP .................................................................. 35
Figura 14 – Exemplo hierarquia de clientes em SAP ................................................................ 36
Figura 15 - Estrutura Dimensão Data ....................................................................................... 39
Figura 16 – Exemplo da Dimensão Data .................................................................................. 39
Figura 17 – Estrutura Dimensão Produto ................................................................................. 39
Figura 18 – Exemplo da Dimensão Produto ............................................................................. 39
Figura 19 – Dimensão Canal Distribuição ................................................................................. 40
Figura 20 – Exemplo da Dimensão Canal de Distribuição ........................................................ 40
Figura 21 - Estrutura Dimensão Centro .................................................................................... 40
Figura 22 – Exemplo da Dimensão Centro ............................................................................... 40
Figura 23 – Estrutura Dimensão Clientes ................................................................................. 41
Figura 24 – Exemplo da Dimensão Clientes ............................................................................. 41
Figura 25 - Estrutura Dimensão Fornecedores ........................................................................ 41
Figura 26 – Exemplo da Dimensão Fornecedor ....................................................................... 41
Figura 27 - Estrutura Dimensão Rotas ...................................................................................... 42
Figura 28 – Exemplo da Dimensão Rotas ................................................................................. 42
Figura 29 - Estrutura Dimensão Vendedores ........................................................................... 42
Figura 30 – Exemplo da Dimensão Vendedores ...................................................................... 42
Figura 31 – Estrutura física da Staging Area ............................................................................. 44
Figura 32 – Estrutura física do Data Warehouse ...................................................................... 44
Figura 33 – Diagrama do Data Warehouse .............................................................................. 45
Figura 34 - Arquitetura da Solução de Business Intelligence ................................................... 46
x
Figura 35 – Fluxo dados do ETL ................................................................................................ 47
Figura 36 - Controlo de Fluxo ETL da Staging Area .................................................................. 49
Figura 37 – Carga e mapeamento das vendas na Staging Area ............................................... 51
Figura 38 – Carga e mapeamento dos clientes na Staging Area .............................................. 52
Figura 39 – Notificação processo carregamento por email na Staging Area ........................... 53
Figura 40 – Controlo do Fluxo ETL dos Data Marts .................................................................. 54
Figura 41 – Mapeamento da dimensão produto no Data Warehouse. ................................... 55
Figura 42 – Fluxo de carga dos factos das vendas ................................................................... 57
Figura 43 – Exemplo de transformação dos valores null na tabela de produtos .................... 57
Figura 44 – Agregação dos factos de Vendas no Data Warehouse ......................................... 58
Figura 45 – Mapeamento dos factos das vendas no Data Warehouse ................................... 59
Figura 46 - Notificação processo carregamento por email do ETL no Data Warehouse ......... 59
Figura 47 - Ciclo de vida dos relatórios .................................................................................... 60
Figura 48 - Área de Filtro na plataforma SSRS ......................................................................... 62
Figura 49 - Dashboard das vendas ........................................................................................... 63
Figura 50 - Exemplo de um Dataset na plataforma SSRS ......................................................... 67
Figura 51 – Exemplo de sub-relatório das vendas diárias ........................................................ 69
Figura 52 - Exemplo sub-relatório Top 30 Clientes Com e Sem Vendas .................................. 70
Figura 53 – Exemplo de sub-relatório das vendas de Outubro................................................ 70
Figura 54 – Exemplo de sub-relatório das Vendas Frango Fresco com evolução semanal ..... 71
Figura 55 – Relatório de vendas por tipo de produto .............................................................. 71
Figura 56 – Exemplo Power Table das vendas ......................................................................... 72
Figura 57 – Power View com as margens de vendas ............................................................... 72
Figura 58 – Power View dos produtos e hierarquias de vendas .............................................. 73
Figura 59 – Power View dos Clientes por centro e tipo de vendas ......................................... 73
Figura 60 – Power View dos vendedores ................................................................................. 74
Figura 61 – Power View com a rentabilidade das rotas ........................................................... 74
Figura 62 – Exemplo Power Table de Compras ........................................................................ 75
Figura 63 – Power View por produto e fornecedor de compras ............................................. 75
Figura 64 – Power View com evolução das compras por tipo de produto .............................. 76
Figura 65 – Power View de análise anual por centros e produto ............................................ 76
Figura 66 – Diagrama do Sistema SAP .................................................................................... 102
xi
ÍNDICE DE TABELAS
Tabela 1 - Cronograma do projeto ............................................................................................. 4
Tabela 2 – Arquiteturas OLAP, adaptado, Howson, C. (2008) ................................................. 16
Tabela 3 – Principais diferenças dos 3 modelos, Mistry R. e Misner S. (2012). ....................... 19
Tabela 4 – Principais funcionalidades de cada modelo, Mistry R. e Misner S. (2012)............. 20
Tabela 5 – Matriz Bus do projeto ............................................................................................. 37
Tabela 6 – Métricas do Data Warehouse ................................................................................. 43
Tabela 7 – Calendário Semanal de Envio de Relatórios na Plataforma SSRS........................... 64
Tabela 8 - Identificação dos relatórios na plataforma SSRS..................................................... 66
Tabela 9 – Identificação dos Livros Excel do projeto ............................................................... 68
xii
LISTA DE SIGLAS E ABREVIATURAS
BI Business Intelligence
DM Data Mart
DW Data Warehouse
ERP Enterprise Resource Planning
ETL Extract, Transform and Load
SA Staging Area
SQL Structured Query Language
SSIS SQL Server Integration Services
SSRS SQL Server Reporting Services
1
1. INTRODUÇÃO
1.1. ENQUADRAMENTO GERAL
Nos últimos anos a avicultura tem sido profundamente afetada por várias situações críticas e
asfixiantes para as empresas ligadas ao sector.
A crise dos nitrofuranos, a crise das salmonelas, o fantasma do colesterol no caso dos ovos, o
pavor das encefalopatias espongiformes, e ainda muitas outras notícias alarmistas veiculadas
pela comunicação social abalaram ainda mais um mercado já por si muito debilitado (Carlos
Alberto Gomes Durães Guerra, 2010).
De acordo com o diagnóstico setorial, elaborado pelo Ministério da Agricultura
Desenvolvimento Rural e das Pescas (2007), o total de carne de aves produzida em 2005 atingiu
as 296 000 toneladas, valor superior aos 270.000 registados em 2003 (ano de retração do
consumo e produção por causa dos nitrofuranos), mas inferior às 311 000 toneladas de 2002.
No seio deste sector, a carne de frango, é o principal subsector, representando mais de 95% do
seu valor económico. A tendência de crescimento deste sector que se verificou entre 1988 e
1997, com um acréscimo de 30% a preços correntes, foi contrariada posteriormente, com uma
redução de 20% até 2004.
Segundo o diagnóstico, a produção de aves de capoeira tem registado um crescimento
sustentado, quer em volume, quer em valor, desde antes da adesão. Apenas é de registar uma
quebra significativa no ano de 2003, fruto da denominada “crise dos nitrofuranos”, a qual
originou uma retração do consumo, devida também ao Verão muito quente que provocou uma
queda na produção. A Carne produção veio a recuperar em 2004 com um crescimento superior
a 8%, vindo a verificar-se um abrandamento desse crescimento em 2005, com a quebra de
confiança do consumidor devido ao aparecimento de focos de gripe aviária na UE no final desse
ano.
Neste contexto e conscientes da evolução dos sistemas de informação e das suas vantagens
competitivas, foi adjudicado em 2006, o sistema integrado SAP, com o objetivo de agilizar
processos, otimizar recursos, através da consolidação de vários sistemas dispersos, de modo a
responder aos constantes e novos desafios.
O sistema demorou 9 anos a implementar nas várias empresas do grupo e já adquiriu a sua
maturidade. Como não foram adquiridos os módulos de SAP de Business Intelligence (BI), a
solução não oferece respostas eficientes ao nível de relatórios, tanto nas vendas como nas
compras da empresa. Os relatórios estão vocacionados para as áreas operacionais, sendo muito
limitados para efeitos de gestão, nomeadamente em análises mais aprofundadas que requerem
maiores volumes de informação.
Foi equacionada a aquisição dos referidos módulos de BI de SAP e concluiu-se que a relação
qualidade preço da solução não justificava o investimento.
2
A frequência no mestrado em gestão de informação com especialização em Business
Intelligence, veio contribuir de forma significativa para a solução deste dilema. Na verdade,
existem sistemas de informação especializados e especialmente desenhados para servirem de
suporte aos processos de decisão, designadas soluções de BI. São vários os fabricantes destas
soluções como Microstrategy, Microsoft, Qlick View, Tableau, envolvendo diferentes tipos de
componentes e arquiteturas, como Data Warehouse (DW), OLAP, Tabular, Data Mining e
ferramentas de visualização e exploração de dados.
1.2. ENQUADRAMENTO DO PROBLEMA
Os modernos sistemas de gestão de informação, utilizados pela maioria das empresas e
organizações da nossa sociedade, são construídos com suporte em sistemas de base de dados
relacionais. Estes sistemas são pela sua própria natureza estrutural, fundamentalmente
vocacionados para armazenar, com altos níveis de eficiência, os resultados das operações
quotidianas das organizações (Caldeira C., 2012).
A Avibom enquadra-se na perfeição neste contexto. A empresa é suportada por um sistema ERP
(Enterprise Resource Planning) designado por SAP, baseado em base de dados relacionais. Este
sistema é constituído por pacotes integrados de gestão, que constituem a base do processo de
negócio da empresa. Estão desenhados e formatados por transações, dificultando desse modo
a recolha para a análise e tratamento da informação.
1.3. DEFINIÇÃO DO PROBLEMA
Não existe no sistema transacional SAP da Avibom, nenhuma plataforma, que permita de uma
forma simples e transparente extrair os dados nas mais diversas áreas, sendo necessário
recorrer a diversos mapas e ferramentas auxiliares para obter a informação mínima desejada. A
recolha da informação é lenta, parcial, suscetível de erros, provocando uma sobrecarga adicional
no sistema, não oferecendo de uma forma rápida, adequada e eficaz, o suporte à tomada de
decisão.
1.4. OBJETIVO
O presente projeto tem como objetivo desenvolver um sistema de Business Intelligence, através
de ferramentas Microsoft, com base no sistema de informação existente na empresa, suportado
por um DW, que funcione como instrumento de apoio e suporte à tomada de decisão, nas
vendas e compras da empresa.
Pretende seguir a metodologia Kimball e assim desenvolver uma modelação dimensional a partir
de modelos relacionais.
3
O DW será constituído por um conjunto de dois Data Marts de compras e vendas, que serão
alimentados através da Staging Area (SA). Será necessário desenhar e desenvolver um processo
de ETL (Extract, Transform and Load), que garanta a extração da informação do sistema fonte,
efetue as transformações necessárias e assegure a transferência para o DW, servindo de base
às plataformas de relatórios.
A análise e exploração dos dados de suporte à tomada de decisão serão baseadas no
desenvolvimento de duas plataformas de relatórios SQL Server Reporting Service (SSRS) e Excel.
Esta tese tem como último objetivo, servir de complemento ao desenvolvimento de novos DMs
a outras áreas da empresa.
1.5. ORGANIZAÇÃO DO RELATÓRIO
O presente relatório está dividido em 8 capítulos:
O primeiro capítulo pretende enquadrar o projeto nas motivações que levaram ao seu
desenvolvimento, bem como os seus objetivos;
O segundo capítulo pretende descrever com algum detalhe o enquadramento do
negócio, a sua importância e as principais necessidades;
O terceiro capítulo tem como objetivo introduzir o enquadramento teórico base para o
desenvolvimento deste projeto, como as suas definições e metodologias;
O quarto capítulo pretende aprofundar os conceitos técnicos dos principais elementos
do projeto;
O quinto capítulo, mais técnico, tem como objetivo fornecer com algum detalhe o
desenvolvimento do projeto, desde a análise e fonte do DW, identificação e
caraterização da estrutura dimensional e física do DW;
O sexto capítulo, também técnico, aborda ao pormenor as fases do desenvolvimento do
projeto, desde o processo de ETL aos relatórios;
O sétimo capítulo concentra-se na implementação do projeto;
O oitavo e último capítulo aborda as conclusões do projeto, as principais limitações e
proposta de trabalhos futuros;
1.6. PLANEAMENTO
1.6.1. Fases do Projeto
As fases do projeto foram definidas e adaptadas conforme o seguinte modelo:
Análise: Levantamento dos processos de negócio, identificação das fontes;
Arquitetura e Desenho: Modelo de negócio e do modelo físico;
4
Desenvolvimento: Execução dos procedimentos necessários ao carregamento do DW,
Desenvolvimento de relatórios;
Testes: Testes ao Data Warehouse e relatórios;
Disponibilização aos utilizadores: Disponibilização dos relatórios e informação do DW
aos utilizadores credenciados para o efeito;
1.6.2. Cronograma do Projeto
Na tabela 1, está representado o cronograma do projeto, que se distribuiu ao longo de 17 meses.
A primeira versão do projeto foi entregue em Dezembro de 2015, como existiam algumas
correções e melhorias sugeridas pelo orientador, foi decidido perlongar a sua entrega por mais
3 meses. A versão final foi assim entregue em Fevereiro de 2016 e o cronograma foi
respetivamente atualizado.
Tabela 1 - Cronograma do projeto
5
2. ENQUADRAMENTO DO NEGÓCIO
2.1. CARATERIZAÇÃO DA EMPRESA
A Avibom é a principal marca comercial do Grupo Valouro, utilizada na comercialização de
produtos avícolas, e é também a designação da Sociedade que tutela os quatro matadouros da
empresa. Só o matadouro da Avibom em Torres Vedras tem capacidade para abater 8.000
frangos por hora, 2000 patos por hora e 1500 perus por hora, sendo considerado um dos
maiores da Península Ibérica.
A Avibom, S.A. exporta produtos frescos e congelados para mais de 20 países, representando as
exportações em 2012 cerca de seis por cento do seu volume de negócios. A Europa tem sido
o principal mercado de exportação mas a empresa espera reforçar, em breve, a sua posição
neste e noutros mercados.
Atualmente é líder de mercado no sector em que se insere na indústria agroalimentar, tendo
instalações devidamente equipadas para abate, preparação, transformação e distribuição de
aves (frangos, patos, perus e galinhas) e também para a produção de salsicharia e charcutaria,
tratamento e comercialização de subprodutos.
O Grupo tem 7 centros de reprodução e 10 matadouros, tendo uma capacidade produtiva de
160 milhões de pintos ano.
A Avibom tem um portfólio de 220 produtos. Em 2012, apresentou um Volume de Negócios de
298 milhões de Euros, um EBITDA de 52,3 milhões de Euros e um Resultado líquido de 16 milhões
de Euros.
2.2. VISÃO
A Avibom, pretende reforçar a sua posição de marca mais reconhecida no seu sector em termos
nacionais, bem como aumentar a sua presença no mercado internacional, sendo reconhecida
como um importante contribuinte para o aumento da riqueza nacional e afirmação do nome de
Portugal enquanto fornecedor de bens de excelência e qualidade.
2.3. MISSÃO
Produzir produtos nacionais com elevados padrões de qualidade, concebendo e
disponibilizando ao mercado soluções competitivas, inovadoras e sustentáveis, mantendo
elevado nível de serviço e qualidade.
Criar valor económico e social a longo prazo levando os benefícios do progresso e da inovação a
um número crescente de pessoas.
6
2.4. ERP - SAP
Foi iniciado um projeto de implementação do SAP em 2007, no grupo Valouro. Este projeto tinha
como objetivo, cobrir todo o modelo de negócios do grupo. A solução SAP implementada foi
projetada para fornecer uma grande variedade de serviços e ferramentas que asseguram a
implementação dos seguintes módulos:
FI – Contabilidade Geral
CO – Contabilidade Analítica
HR – Recursos Humanos
MM – Stocks e Compras
SD – Vendas
WM – Gestão de Localizações
PP – Controlo de Produção
QM – Controlo de Qualidade
2.5. IDENTIFICAÇÃO DAS NECESSIDADES DO NEGÓCIO
Inserida numa indústria competitiva e de alto volume de produção, o negócio da Avibom foca-
se essencialmente na produção e comercialização de três produtos principais: Frango, Pato e
Peru; existindo unidades fabris e de distribuição, divididas de Norte a Sul de Portugal:
Vila Facaia (Torres Vedras) – unidade base de abate, transformação, comercialização e
distribuição;
Daroeira (Beja) - unidade de reprodução, abate e distribuição;
Barcelos, Maia, Leiria, Tomar, Beja e Albufeira – unidades de distribuição;
O presente projeto pretende fornecer ferramentas de análise e gestão na área de vendas e
compras, aos seguintes níveis da organização:
Administração
Direção Comercial e Marketing
Diretores Centros
Direção de Compras
7
2.6. NECESSIDADES FINAIS
A capacidade de criação de uma fonte independente de dados fidedignos, com uma “única
versão da verdade” e análise em tempo real é objetivamente uma vantagem competitiva.
Com o carregamento dos dados no DW e o seu repositório definido, será possível criar aplicações
e relatórios dinâmicos de análise e apresentação dos dados, tanto ao nível operacional como de
gestão.
2.7. IMPORTÂNCIA E RELEVÂNCIA DO PROJETO
Este projeto é pioneiro na empresa, na realidade até à data, nunca houve qualquer abordagem
nesta matéria, as soluções de reporte existentes são estáticas e dispersas. Assim este projeto
pretende provocar um forte impacto no tratamento dos dados existentes no sistema SAP, em
informação útil ao negócio.
A introdução de uma ferramenta de relatórios simples e rápida aos utilizadores, permitirá uma
gestão muito mais eficiente de clientes e fornecedores, através da análise dos principais
indicadores de negócio, assim como na identificação de padrões e tendências de suporte ao
negócio.
Embora secundário, mas igualmente importante, a escalabilidade do DW, é um dos pontos a ter
em consideração. O modelo adotado irá permitir estender, de uma forma simplificada, o projeto
a outras áreas de negócio, nomeadamente financeira e de produção.
Existe um volume significativo de dados no sistema SAP, com cerca de 1 Terabyte. Parte
substancial da informação não tem qualquer tipo de tratamento, o que constitui um grande
desafio à organização na abordagem ao Big Data.
8
3. ENQUADRAMENTO TEÓRICO
3.1. BREVE HISTORIAL
Durante um longo período, o software de base de dados foi desenvolvido sem regras. Até 1971
as bases de dados faziam parte da ciência da computação, sem um suporte geral ou formal.
Nesse ano, E.F. Codd publicou dois pequenos documentos onde introduziu o modelo relacional.
Este modelo foi um verdadeiro avanço para o fundamento e compreensão das bases de dados
(Paredaens, J., Bra, P.B., Gyssens, M., Gucht, D.V., 1989).
Com base no modelo relacional de Codd, nasceram os primeiros sistemas de base de dados,
assentes num armazenamento consistente e útil de informação gerada pelo negócio, permitindo
uma análise mais rápida e simples no suporte à tomada de decisão, traduzindo-se numa nova
vantagem competitiva para as empresas.
Segundo, Mohanty S., Jagadeesh, M., Srivatsa, H., (2013), os seres humanos têm vindo a gerar
dados para dezenas de anos. Durante muitos anos a quantidade de dados produzidos nos
mainframes e ERP’s, foi considerada inútil. No entanto, os dados sempre foram parte integrante
de cada empresa, seja pequena ou grande, a sua importância e valor ao longo do tempo tornou-
se evidente, assim como a proliferação de bases de dados dentro das empresas.
Assim, os sistemas de base de dados foram crescendo e multiplicando-se. Com o passar dos
anos, começou a haver dificuldades na sua análise e consequentemente fortes
constrangimentos, num mercado cada vez mais exigente e global.
Para responder a esta contrariedade, surgem na década de 90 grandes investimentos em novas
áreas de negócio, como o DW e BI para o suporte à tomada de decisão, com a análise em tempo
real de grandes e dispersas fontes de dados.
As bases de dados deixaram de ser vistas unicamente como repositório de dados, passando
também a ser um meio de eficiência na sua análise. Com a criação do DW e as ferramentas de
BI é possível gerar um valor competitivo, de acesso fácil e rápido.
3.2. BUSINESS INTELLIGENCE
Segundo Howson, C. (2008), como os olhos são a janela da alma, o BI é a janela dinâmica do
negócio, demonstra o desempenho, as eficiências operacionais e oportunidades por explorar. O
BI é um conjunto de tecnologias e processos que permite a todos os elementos e níveis da
organização o acesso e análise dos dados. Dá prioridade aos analistas do negócio em detrimento
da tecnologia, uma vez que sem estes a informação pouco ou nada vale.
De outra forma, Turban, Sharda, Delen & King (2010), o BI é um chapéu que combina
arquiteturas, ferramentas, bases de dados, ferramentas analíticas, aplicações e metodologias.
O grande objetivo é permitir um acesso interativo (por vezes em tempo real) aos dados e à sua
9
manipulação, oferecendo aos gestores e analistas uma condução apropriada da informação. A
análise do histórico, de dados atuais e de performance torna-se um valor acrescentado para as
tomadas de decisão.
Na Figura 1, está representada uma visão geral de uma solução de BI e os principais elementos
que a compõem.
Figura 1 – Componentes principais de uma arquitetura de Business Intelligence
Conforme é possível observar, o ambiente de BI é composto por um sistema de fonte de dados,
cujos elementos principais são as bases de dados transacionais (OLTP), um processo de Extração,
transformação e carregamento de dados (ETL), onde os dados são carregados no DW. E termina
num conjunto de ferramentas de análise e visualização dos dados que são alimentadas a partir
do DW. Estas ferramentas podem usar vários tipos de tecnologia como Online Analytical
Processing (OLAP) e utilizar metodologias como Data Mining com o objetivo de identificar
padrões e relacionamentos dos dados ou simplesmente disponibilizar a informação diretamente
aos relatórios através de consultas.
Na metodologia de Kimball, o DW é a plataforma para o BI, desde a extração da informação, ao
software e as aplicações que a compõem (Mundy, ThornthWaite e Kimball, 2011), aplicando-se
assim o termo DW/BI.
Para Kimball, R. e Ross, M. (2013), existem alguns requisitos fundamentais a ter em consideração
no desenvolvimento e criação do DW/BI, no qual se destacam:
O sistema de DW/BI deve tornar a informação facilmente acessível; o conteúdo deve
ser facilmente compreendido de um modo intuitivo, não só para o programador mas
também para o analista, bem como a sua linguagem. As ferramentas e aplicações de
10
acesso aos dados devem ser simples e fáceis de usar, tornando o processo mais simples
e rápido.
O sistema de DW / BI deve apresentar a informação de forma consistente; os dados
devem ser credíveis a partir das fontes, limpos e de qualidade assegurada. Deve-se ter
particular atenção aos nomes das medidas utilizadas, medidas com o mesmo nome
devem representar o mesmo
O sistema de DW / BI deve-se adaptar à mudança; nomeadamente às necessidades dos
utilizadores, às mudanças do negócio e tecnologia. O sistema deve ser projetado para
lidar com estas mudanças com transparência aos utilizadores.
O sistema de DW / BI deve apresentar a informação em tempo útil.
O sistema de DW / BI deve ser seguro e de acessos controlados.
3.3. DATA WAREHOUSE
Conforme descrito no capítulo anterior, um dos principais elementos da plataforma de BI é a
DW.
Para Turban et al. (2010), o DW é um conjunto de dados produzidos para o suporte à tomada
de decisão, sendo também um repositório de dados históricos e correntes, fornecendo um
potencial de informação aos gestores de toda a organização. Mais recentemente Caldeira
(2012), afirma, de outro modo que o DW é um repositório central de factos sobre múltiplos
temas, desenvolvido com o objetivo de facilitar os mecanismos de pesquisa de informação.
É apresentado por Inmon (2005), como as caraterísticas mais importantes de um DW são as
seguintes:
Orientado ao Assunto: Os dados estão organizados por assunto, como vendas, produtos
ou clientes, contendo exclusivamente a informação relevante para a tomada de decisão.
Permite aos utilizadores determinar não só a performance do negócio, mas o porquê.
Os sistemas operacionais ao contrário das DW, estão orientados para o produto e estão
direcionados para suportar as transações, que atualizam a base de dados. A orientação
por assunto fornece uma visão mais clara da organização.
Integrado: O DW extrai a informação de diversas fontes num formato consistente. Para
o fazer, tem de lidar com conflitos de nomes e discrepâncias de unidades de medidas.
Depois de tratadas as inconsistências e inseridas no DW muitas das inconsistências
existentes ao nível aplicacional ficam automaticamente resolvidas.
11
Não Volátil: No sistema operacional os dados são regularmente alterados e
manipulados através de transações, no DW os dados são carregados incrementalmente
mas não atualizados da mesma forma, devido a um conjunto diferente de características
do DW. Assim, quando os dados são carregados fica um registo instantâneo no DW, os
carregamentos seguintes são atualizados com um novo registo instantâneo, sem que
exista perca do histórico da informação.
Varia no tempo: O DW armazena o histórico dos dados. Os dados podem não estar
necessariamente atualizados (exceto em sistemas em tempo real). Através do histórico
é possível detetar tendências, desvios e relações de longo prazo, para as previsões e
comparações de suporte à tomada de decisão. O tempo é uma das dimensões mais
importantes que todos os DW têm de suportar. A análise dos dados de múltiplas fontes
contém múltiplos pontos temporais, como visões diárias, semanais, mensais.
Recentemente, Mundy, J., ThornthWaite, W. e Kimball, R. (2011), afirmam, o DW está
fortemente associado ao BI, sem o suporte de um repositório de dados, devidamente modelado
e transformado, o esforço é desnecessário e inútil. Para os autores o DW e BI são um conjunto
de ferramentas para o negócio, disponibilizadas aos analistas, para tomar decisões de negócio
operacionais e estratégicas, não se podendo desassociar um do outro.
Os principais objetivos do DW/BI, para Kimball, R. e Ross, M. (2013), são os seguintes:
Estar organizado de forma a tornar a informação de fácil acesso;
A informação deve ser apresentada de uma forma consistente;
O sistema deve ser adaptável e resistente às mudanças;
Apresentar a informação de forma atempada;
O sistema deve ser seguro e a informação protegida;
A informação deve ser segura para a tomada de decisão;
Deve ser aceite pelos utilizadores de forma a ser bem sucedido.
Modelo dimensional
Segundo, Kimball, R. e Ross, M. (2013), a modelagem dimensional é uma técnica antiga para
tornar a DW mais simples ao utilizador. A simplicidade é fundamental para garantir que os
utilizadores possam facilmente compreender os dados, bem como permitir uma fácil navegação
do software e entrega de resultados de uma forma rápida e eficiente.
12
O sistema de gestão tradicionais como ERP e CRM, estão desenvolvidos para responder a
operações diárias e estão construídos com suporte a sistema de base de dados transacionais,
normalmente designados por OLTP ou Sistemas Transacionais. São baseados em modelos
normalizados, aumentando fortemente a integridade dos dados nela inseridos, mas diminuindo
drasticamente de performance em termos de pesquisa.
Para superar este problema e simplificar o desempenho nas consultas em grandes volumes de
dados, foram desenvolvidos os modelos dimensionais. A abordagem da modelagem
dimensional fornece uma forma de melhorar o desempenho na consulta dos relatórios sem
afetar a integridade dos dados (Ballard, C., Farrell, D. M., Gupta, A., Mazuela, C. e Vohnik S.
2006). Segundo Mundy et al. (2011), as principais vantagens do modelo dimensional são:
Apresentar a informação aos utilizadores o mais simples possível;
Retornar o resultado das consultas o mais rápido possível;
Fornecer informações relevantes dos processos de negócio.
O modelo dimensional é muito mais fácil de compreender aos utilizadores que os modelos
normalizados (OLTP), apesar de os conteúdos dos modelos serem muito idênticos. Com o
modelo dimensional existem muito menos tabelas e a informação é agrupada em categorias de
negócio. Estas categorias são chamadas dimensões, permitindo aos utilizadores navegar entre
elas, conforme a necessidade, simplificando a análise ao utilizador e aumentando desta forma a
sua eficácia.
O bom desempenho é outra vantagem do modelo dimensional, consegue-se alcançar devido à
desnormalização envolvida na criação das dimensões. Através da junção das hierarquias e da
proximidade das tabelas, o motor de base de dados efetua menos junções e cria menos tabelas
temporárias intermediárias, aumentando assim o seu desempenho.
Pelas vantagens acima indicadas o modelo dimensional torna-se assim o mais indicado para a
estrutura do DW do projeto.
O modelo dimensional é concebido com base numa ou mais tabelas de fatos, que se encontram
ao centro e com as dimensões à sua volta, em formato estrelar. Os dados são agregados na
tabela de fatos em função da granularidade definida no modelo. As tabelas de fatos são
constituídas por um conjunto chaves estrangeiras e métricas calculadas. As chaves estrangeiras
são originárias das tabelas de dimensão, onde se encontram as entidades.
Este modelo normalmente designado por modelo em estrela ou Start Schema, foi proposto
inicialmente por Ralph Kimball para a modelagem da DW, sendo a abordagem mais utilizada no
modelo dimensional.
Existem no entanto, outros modelos dimensionais, Snowflake Schema, Flat Schema e Terraced.
Cada modelo tem as suas caraterísticas, dependendo da complexidade e dimensão da
arquitetura do sistema fonte, bem como da análise que se pretende efetuar. A escolha do
13
modelo que melhor se adapta às necessidades é muitas vezes uma tarefa difícil. Vejamos, de
uma forma geral, cada um dos modelos analisados, segundo Moody, D. L. e Kortink, M. A. R.
(2000):
Flat Schema: Este modelo é o mais simples, permitindo a construção de um modelo
dimensional sem que exista a perda de dados. É caraterizado pela não utilização de
agregações, minimizando as entidades, originando um número muito mais reduzido de
tabelas. Por outro lado, provoca normalmente, um aumento dos atributos, com pouca
redundância, diminuindo a complexidade relacional e aumentando a complexidade de
cada tabela.
Terraced Schema: Este modelo obtém-se através de uma arquitetura composta apenas
pelas entidades transacionais, existindo uma tabela por cada uma destas mesmas
entidades. As tabelas obtidas possuem as mesmas chaves primárias relativamente ao
modelo relacional e não são aplicadas operações de agregação.
Start Schema: Este modelo designado por Start Schema ou modelo em estrela é
formado por uma tabela de factos e dimensões. A tabela de factos é formada pela
entidade transacional do sistema fonte e a chave desta tabela é a combinação das
chaves das entidades componentes. A tabela dimensão é formada para cada
componente entidade, juntamente com as hierarquias. Onde existirem relações de
hierarquia entre a entidade de transação, a entidade filho herda todas as dimensões da
entidade mãe. Os atributos numéricos das entidades de transação devem ser agregados
por atributos-chave (dimensões).
Snowflake Schema: Este modelo designado por Snowflake schema ou modelo Floco de
Neve é muito idêntico ao modelo em Estrela, no modelo em estrela, as hierarquias são
desnormalizadas para formar as tabelas de dimensão . Cada tabela de dimensão pode
conter várias hierarquias independentes. O modelo Snowflake Schema é um esquema
em estrela com todas as hierarquias explicitamente visíveis. Um esquema floco de neve
pode ser formado a partir de um esquema em estrela com as hierarquias normalizadas
em cada dimensão.
3.3.1. Ferramenta OLAP (Multidimensional) e Tabular
Segundo Kimball et al. (2013), o OLAP é uma estrutura dimensional, implementada numa base
de dados Multidimensional, por outro lado, M., Ferrari, A., Webb, C. (2012), afirmam que ao
nível mais alto o modelo multidimensional é muito semelhante ao modelo tabular.
14
As ferramentas de OLAP (Online Analytical Processing) e Tabular, estão desenhados para
permitir aos analistas, interagir com os dados durante a sua análise. No primeiro os dados são
apresentados em métricas, dimensões, tabelas, relações, hierarquias e cubos, ao contrário do
segundo onde os dados estão relacionados por tabelas e atributos, aproximando-se mais do
modelo de base de dados relacionais.
Entre muitos outros produtos, o SQL Service Analysis Services (SSAS) é uma possível escolha para
um motor analítico incorporado numa aplicação ou serviço. Prevê dois motores diferentes
associados a dois tipos de modelos: Tabular e Multidimensional. A escolha do modelo mais
adequado, é uma tarefa nem sempre fácil. De seguida serão analisados com mais detalhe os
modelos indicados:
OLAP (Multidimensional)
Tabular 1
Modelo OLAP (Multidimensional)
Wrembel R. e Koncilia, C. (2007), afirmam que tradicionalmente, as ferramentas OLAP são
baseadas em modelagem multidimensional, que representa de forma intuitiva os dados em
forma de cubo, cujas células correspondem a eventos (events) que ocorreram no negócio,
conforme Figura 2.
Figura 2 – Representação cubo (Wrembel R. e Koncilia, C., 2007)
Cada evento é quantificado por um conjunto de medidas (measures), cada eixo do cubo
corresponde a uma dimensão (dimension) relevante para a análise, tipicamente associada a uma
hierarquia (hierarchy) de atributos.
1 No SSAS tabular existe uma variante na instalação designada por Power Pivot para Sharepoint
15
Esta ferramenta é a mais comum, no uso e exploração em tempo real do DW, muito utilizada no
modelo dimensional em estrela. É poderosa, nomeadamente pela capacidade de efetuar
cálculos complexos e na capacidade de converter grandes volumes de dados em informação.
Segundo, SAS Institute Inc. (2015), Online Analytical Processing (OLAP) é uma tecnologia que é
usada para criar software de apoio à decisão. O OLAP permite aos utilizadores uma análise
rápida às informações que estão previamente resumidas em visões multidimensionais e
hierarquias. Ao resumir as consultas previstas em visões multidimensionais antes de tempo de
execução, torna o OLAP uma poderosa ferramenta no desempenho relativamente aos sistemas
de base de dados tradicionais (OLTP). Grande parte dos cálculos de agregação é feita antes do
pedido da consulta.
Conforme o manual da SAS, a capacidade de ter uma informação coerente, relevante e oportuna
é a razão pela qual o OLAP ganhou popularidade. Os sistemas OLAP podem ajudar a revelar
inconsistências e tendências evasivas em dados que não poderiam ser vistos antes. Os
utilizadores OLAP podem intuitivamente procurar informação consolidada e sintetizada no
cubo. Além disso, as ferramentas OLAP permitem tarefas como previsão de vendas,
planeamento de recursos, orçamento e avaliação de risco e os seus principais benefícios são:
Acesso rápido e cálculos, e resumos de dados de uma organização;
Suporte para acesso de múltiplos utilizadores e várias consultas;
Capacidade de lidar com múltiplas hierarquias e níveis de dados;
Capacidade de resumir e consolidar dados para consultas mais rápidas e para funções
de relatório;
Capacidade de expandir o número de dimensões e níveis de dados como um negócio.
Para, Howson, C. (2008), existem vários tipos de arquitetura OLAP, podendo variar em função
do desempenho, tipos de cálculo multidimensional, volume de dados a analisar e atualizações,
bem como vários fábricantes com vários tipos de interface para aceder à informação, conforme
descrito na Tabela 2.
16
Tabela 2 – Arquiteturas OLAP, adaptado, Howson, C. (2008)
Modelo Tabular
O modelo tabular é baseado no armazenamento de dados em memória, com uma metodologia
semelhante às bases de dados relacionais, em vez do tradicional modelo OLAP baseado em fatos
e dimensões ou cubos (Clements, R. e Reade, J., 2012).
O acesso á informação é feita através de um mecanismo designado por xVelocity, que funciona
como alternativa ao OLAP. A grande vantagem desta tecnologia é aliar uma forte compressão
de dados em memória e um poderoso sistema de processamento de consultas com vários
segmentos, fornecendo uma velocidade extremamente rápida, sem recorrer ao
armazenamento de disco muito mais lento.
Existem duas formas de armazenamento, em modo Cache (xVelocity ou Vertipaq) e Direct Query
(Larson, B. 2012).
Modo Cache (xVelociy): Neste tipo de operação, os dados são carregados em memória
e aliados a grandes taxas de compressão, permitindo um forte desempenho, não
necessitando de pré-agregações. Simplesmente os dados são carregados em memória,
combinados para responder aos critérios e produzir as agregações necessárias ao
modelo previamente estabelecido.
Arquitetura Principais Carateristicas Fornecedor
ROLAP
Os cálculos são feitos num
base de dados relacional,
grande volume de dados,
dificil previsão de tempo.
Oracle BI EE, SAP Netweaver BI,
MicroStrategy, Cognos 8,
BusinessObjects Web Intelligence
MOLAP
Cálculos são realizados
numa base de dados
baseada num servidor
multidimensional. O cubo
fornece um acesso de escrita
de modo a armazenar os
dados para a realização dos
mais variados tipos de
análises.
Oracle’s Hyperion Essbase, Microsoft
Analysis Services, TM1, SAS OLAP,
Cognos PowerCubes
HOLAPAgregações são feitas em
cache
Microsoft Analysis Services, SAS OLAP,
Oracle’s Hyperion Essbase
DOLAPUma pequena cache é feita
aquando a realização da
consulta.
BusinessObjects Web Intelligence,
Oracle’s Hyperion Interactive
Reporting (formerly Brio)
17
Direct Mode (Direct Query): Ao contrário de modo em cache, neste processo os dados
não são carregados para a memória, mas são lidos através de consultas diretas à base
de dados para obter os resultados. Este modo provoca uma carga adicional no sistema
fonte, sendo um fator a ter em consideração na sua escolha. Com este modo não existe
latência nos dados, assim que a informação é alterada no sistema fonte é logo refletida
no modelo de análise, no entanto a performance é significativamente afetada, com a
leitura dos dados diretamente na fonte em tempo real. Este modo é recomendado em
modelos cuja latência é prioritária, em detrimento da performance.
Para, Russo, M. (2014), existem fatores importantes a ter em consideração, na escolha do
modelo Tabular, nomedamente:
Linguagem
Manutenção
Performance
Hardware
Linguagem DAX e MDX
Muitas aplicações têm incorporado características que permitem aos utilizadores criar relatórios
personalizados, para o efeito é necessário utilizar consultas dinâmicas ao motor da base de
dados. O SQL é a linguagem de escolha para as bases de dados relacionais, enquanto o tabular
oferece o DAX e MDX, como linguagem alternativa. A escolha mais comum para Tabular é o Dax,
é uma linguagem funcional que torna mais fácil compor e encapsular operações em sub-
consultas. Outra vantagem do uso desta linguagem é ser comum a grande parte dos utilizadores
que utilizam o Excel, as suas funções são muito semelhantes, permitindo uma fácil
aprendizagem.
Manutenção
O modelo Tabular, não tem índices ou agregações, pelo que não necessita de manutenção. Os
dados são carregados através das consultas e não requerem estruturas de dados adicionais.
Estas consultas internas são muito rápidas e não interferem com o desempenho geral, graças ao
mecanismo de armazenamento em memória otimizada. Os fatores importantes que
determinam o desempenho do sistema são o desenho do modelo e a estrutura da consulta.
18
Performance
Cada consulta no modelo tabular pode executar uma verificação completa das colunas
envolvidas. Através de um mecanismo de armazenamento de uma pequena cache interna
impedem que a mesma consulta DAX seja executada várias vezes. Mesmo quando há uma
consulta de uma coluna completa, o tempo de execução de um pedido é geralmente de
milissegundos, devido às otimizações, baseadas principalmente na compressão de dados, que
reduzem a quantidade de RAM a ler em cada pedido.
Assim, os cálculos não afetam o desempenho (ao contrário do modelo multidimensional). O
modelo tabular trabalha sempre no nível mais alto de granularidade e graças à sua arquitetura
oferece performances muito elevadas.
Hardware A escolha do hardware para o modelo tabular é fator muito importante para a performance da
informação. Este modelo exige muito do CPU, memórias e cache L2, pelo que devem ser rápidos.
É recomendado um processador com uma velocidade de pelo menos 3.3 GHz, e no mínimo com
2 Mb de cache L2 por core, a memória deve funcionar no mínimo a 1866 MHz.
Business Intelligence Semantic Model (BISM)
A Microsoft desenvolveu um modelo híbrido, que chamou Business Intelligence Semantic Model
(BISM) de forma a suportar as diferentes tecnologias. Fundamentalmente traduz-se na escolha
do motor do Analyses Services para o armazenamento dos dados analíticos (Clements, R. e
Reade, J., 2012).
Na plataforma do SQL 2012 existem alguns aspetos a ter em consideração na escolha da
arquitetura e tecnologia a utilizar para a análise e visualização dos dados. Podem ser usadas 2
arquiteturas distintas na instalação do SQL 2012 Analyses Services: Multidimensional e Tabular,
esta última com opção do Power Pivot para Sharepoint. Cada modo suporta diferentes tipos de
origem, ferramentas, linguagem e segurança, conforme Tabela 3.
19
Tabela 3 – Principais diferenças dos 3 modelos, Mistry R. e Misner S. (2012).
Outro fator a ter em consideração, para a escolha do modelo, são os requisitos para os relatórios
de análise e a seleção do modelo que melhor se adapte a essas necessidades. Na Tabela 4, estão
representadas as principais funcionalidades de cada modelo na plataforma SQL 2012.
20
Tabela 4 – Principais funcionalidades de cada modelo, Mistry R. e Misner S. (2012)
21
4. CONTEXTO
4.1. ENQUADRAMENTO TÉCNICO
Conforme referido anteriormente, a solução desenvolvida neste projeto é baseada na
plataforma Microsoft, como se pode analisar através da Figura 3.
O servidor operacional SAP, onde residem as fontes de dados, encontra-se sediado
externamente, localizado no Porto e replicado em Lisboa. É suportado por um servidor virtual
2008 Server e o motor de base de dados é o Microsoft SQL Server 2008.
O processo é iniciado através de um processamento diário de um Job do SQL, constituído por
dois packages. No primeiro é efetuado o carregamento direto da fonte de dados (SAP), sem
qualquer transformação, denominado por Staging Area. O segundo é feito com base no
carregamento do primeiro, sendo estes jobs executados de modo sequencial.
Estes packages, são desenvolvidos no Microsoft SQL Server Integration Services (SSIS) e são
responsáveis pelo processo de extração, transformação e carregamento (ETL) dos dados nos
DMs. A partir desta fase os dados estão disponíveis para análise e apresentação, através das
ferramentas de relatórios, Microsoft SQL Server Reporting Service (SSRS) e Plataforma Excel.
Figura 3 – Arquitetura Business Intelligence do projeto
Os dados são extraídos diariamente de acordo com a granularidade definida para o negócio,
tornando-se assim possível garantir em tempo útil:
1. Fotografia do sistema operacional (snapshop);
2. Disponibilidade de informação;
22
3. Libertação de recursos do sistema operacional;
4. Fonte independente de dados centralizados num único ponto;
5. Informação relevante para o negócio;
6. Apresentação da informação de forma simples e rápida.
4.2. MODELO DIMENSIONAL DO DW
Existem atualmente sistemas que permitem a recolha de informação em tempo real, isto é, a
extração do modelo de análise é feita diretamente a partir do modelo transacional. Esta
abordagem permitiria simplificar o processo de extração e carregamento de dados, mas a
complexidade e dimensão, tanto estrutural como física da fonte de dados, limitou muito este
tratamento, não sendo mesmo possível na maior parte dos cenários. De facto, os testes
efetuados em determinados cenários, pararam o sistema fonte, colocando em risco o próprio
funcionamento operacional.
Conforme descrito anteriormente, existem diversos modelos, o modelo dimensional da DW
adotado neste projeto é em estrela, contribuindo para o efeito:
Simplicidade: Sendo o primeiro projeto desta natureza na empresa, a simplicidade foi
um fator decisivo para o seu desenvolvimento.
Velocidade de implementação: Face a outros modelos, a implementação é mais rápida,
o que permite aos utilizadores um maior acompanhamento e envolvimento.
Redução de Custos: Numa altura de crise e com os orçamentos mais limitados, torna-se
um fator de peso.
Orientado para os resultados: Com a introdução de métricas, torna-se possível
produzir, medir e comunicar resultados, fator decisivo para a gestão da empresa.
Na Figura 4, na próxima página, está representado um modelo em estrela, onde se torna
facilmente visível ao utilizador os factos e as dimensões.
23
Figura 4 - Exemplo modelo em Estrela, adaptado (Kimball & Ross, 2013)
Esta forma de representação dos dados é a mais utilizada mundialmente nos modelos de DM,
permitindo um maior desempenho na exploração dos dados e a sua representação gráfica é
facilmente compreensível pelo utilizador.
Neste exemplo, estão representadas as vendas e a tabela de factos fica situada no centro da
estrela, estando interligada, num formato estrelar, a um conjunto de tabelas de dimensões que
contêm a sua descrição. A tabela de factos é constituída por dados numéricos ou qualitativos,
medidos ou registados. É formada por um conjunto de chaves estrangeiras que ligam às tabelas
dimensão, normalmente constituídas por poucos atributos, comparativamente às tabelas de
dimensão.
Cada linha de uma tabela de factos corresponde a uma medição. Todas as medidas de uma
tabela de factos têm de ter a mesma granularidade (Kimball et al., 2013).
As tabelas dimensão são formadas pelos atributos dos factos medidos, são basicamente as
características dos factos. No exemplo acima, o modelo dimensional é composto por 3
dimensões, respetivamente, Produtos, Clientes e Data e uma tabela de factos relativa às vendas.
É possível usar uma ou mais dimensões para a análise, o que nos garante uma grande
flexibilidade e desempenho na análise e tratamento, garantindo assim:
Facilidade no acesso à informação;
Informação organizada de forma consistente;
Suporte ao processo de decisão.
4.3. MODELO TABULAR
Uma das tendências mais significativas na indústria de BI ao longo dos últimos anos foi o
nascimento das chamadas ferramentas de Self-Service BI, como o QlickView e Tableau.
24
Estas ferramentas têm como objetivo oferecer aos usuários a capacidade de criar soluções de BI
de pequena escala com pouca ou nenhuma ajuda de departamentos de TI, (Russo, Ferrari &
Webb, 2012).
Existiram algumas dificuldades na escolha do modelo, Tabular ou Multidimensional. Por um
lado, o uso do cubo é recomendado em situações de grande dimensão e em modelos já
existentes, encontrando-se de certa forma ultrapassado. Por outro lado, embora tenha menos
funcionalidades, é baseado numa tecnologia mais recente e simples e face às características do
projeto, poderá trazer maior valor acrescentado.
Foi assim, decidido que o modelo a implementar para a análise dos dados será o tabular em
detrimento do cubo OLAP, para os relatórios mais avançados. Este processo será desenvolvido
com a importação dos dados dos DM’s diretamente para a Power Pivot, na plataforma Excel.
Para os restantes relatórios os dados são extraídos do DW através de consultas na plataforma
SSRS.
4.4. DESCRIÇÃO TÉCNICA
Pretende-se que a solução desenvolvida seja robusta, rápida e flexível e que forneça toda a
informação de gestão necessária à análise do negócio. Embora estejam previstos relatórios pré-
configurados, é de todo desejável, que seja possível ao utilizador direcionar a sua análise de
acordo com as várias perspetivas, pré-estabelecidas nas dimensões e nos mais variados níveis
de detalhe.
Para o efeito torna-se necessário desenvolver uma arquitetura de BI, cujos principais elementos
que a compõe são:
Fontes de dados
Staging Area
Data Warehouse e Data Marts
Relatórios
4.4.1. Fontes de Dados
A fonte de dados é o local onde se encontra armazenado o sistema operacional SAP da Avibom.
É um ERP que cobre todas as áreas do negócio, traduzindo-se na única fonte de informação do
projeto. A estrutura da base de dados encontra-se desenvolvida em SQL Server 2008 e é
composta por mais de 70.000 tabelas, ocupando sensivelmente 1 Terabyte. Derivado à sua
complexidade e dimensão está previsto o desenvolvimento de Views no SQL, no sistema fonte,
de modo a simplificar a extração dos dados. Além da Avibom, existem mais 15 empresa assentes
sobre esta plataforma o que dificulta, de alguma forma, o processo de extração, bem como a
análise técnica do negócio.
25
4.4.2. Staging Area
A Staging Area é uma estrutura de dados relacional, responsável pelo carregamento na fase
inicial do ETL. Os dados são extraídos e carregados na SA e posteriormente enviados para os
DMs. Embora a SA não seja obrigatória é recomendado. Quando os dados são carregados a
informação armazenada anteriormente é eliminada nesta área.
4.4.3. Data Warehouse e Data Marts
O Data Warehouse do projeto será composto pelo conjunto de dois Data Marts de Vendas e
Compras e assumem um modelo dimensional, naturalmente direcionado para satisfazer as
necessidades de análise, bem como, manter o armazenamento do histórico dos dados analíticos,
nas diferentes dimensões e métricas disponíveis. Os dados ficam armazenados e otimizados por
departamento, permitindo um tempo de resposta rápido, simples e menos complexo aos
utilizadores.
Os DM’s são constituídos por uma estrutura de dados desnormalizada e suportada por um
modelo em estrela, são nos DM’s que o processo de ETL é concluído.
4.4.4. Relatórios
Neste ponto os dados já se encontram integrados e disponíveis de forma atempada e
estruturada, proporcionando à organização, informação fidedigna e atualizada, através da
solução de Data Warehouse. Começa assim a ser possível oferecer capacidades analíticas aos
utilizadores finais, através de ferramentas de Report, designadamente, SQL Server Reporting
Services e Plataforma Excel, bem como através da publicação no Sharepoint, representadas
através da Figura 5.
Figura 5 - Fluxo de informação para os relatórios do projeto
26
Esta plataforma de relatórios pretende ser muito abrangente e destacam-se as seguintes
funcionalidades:
Uma única versão da verdade, com uma visão unificada, simplificando a tomada de
decisão;
Visualização de relatórios de diferentes perspetivas e interligados;
Vários métodos de disponibilização de relatórios;
Definição de relatórios pré-definidos com vários tipos de parametrização, permitindo
utilizar um único relatório direcionado a diferentes tipos de conteúdo;
Definir expressões que proporcionam a capacidade como os relatórios são filtrados,
agrupados e ordenados;
Simples e intuitivos.
Conforme se pode verificar na Figura 5, na página anterior, os relatórios são constituídos por 3
elementos:
Reporting Service;
SharePoint;
Plataforma Excel.
Reporting Service
A Plataforma de relatórios SQL Server Reporting Services (SSRS) fornece uma gama completa de
ferramentas e serviços para o desenvolvimento e criação de relatórios a toda a organização.
Inclui ferramentas de programação que permitem acrescentar e personalizar funcionalidades e
simplicidade aos relatórios.
Deste modo, é possível criar várias formas de relatórios interativos, que podem incluir por
exemplo, gráficos, tabelas e mapas, a partir de fontes de dados relacionais, multidimensionais,
ou XML.
O Reporting Services será a plataforma a utilizar neste projeto para o desenvolvimento de
relatórios pré-definidos, através de ferramentas disponíveis para o efeito. Os relatórios depois
de desenhados e testados serão publicados numa plataforma de gestão em ambiente WEB,
conforme exemplo na Figura 6, na próxima página.
27
Figura 6 – Exemplo plataforma Gestão Web de relatórios
Sharepoint
Os relatórios e ficheiros de análise serão publicados no Sharepoint, desta forma, torna-se
possível disponibilizar os relatórios no portal, num ambiente já familiar aos utilizadores. Através
de um simples click podem ter acesso a uma vasta gama de relatórios, conforme exemplo na
Figura 7.
Figura 7 – Exemplo do site de relatórios no Sharepoint da Avibom
28
Plataforma Excel
A plataforma Excel, tem integrado um suplemento de análise de dados do SQL, que utiliza um
modelo de dados tabular. Com esta tecnologia torna-se possível integrar o DW na plataforma
Excel, através da importação para o Power Pivot.
Na Figura 8, está representado o modelo da arquitetura de relatórios que se pretende
implementar no projeto.
Figura 8 - Arquitetura relatórios Excel 2013 do projeto
A análise dos dados, previamente modelada é feita de uma forma intuitiva e familiar, os dados
são explorados e analisados através de ferramentas de análise e apresentação, como Pivot
Charts, Pivot Tabels, Power Maps e Power Views dos quais se destacam as seguintes vantagens:
Agregar grandes volumes de dados;
Definição de novas Métricas;
Processamento de dados é praticamente instantâneo;
Grande compressão dos dados, simplificando o manuseamento do ficheiro;
Os dados são armazenados no Excel, sendo portáteis;
Criação de atributos calculados;
Definição de indicadores chave de desempenho (KPIs);
Definição de hierarquias;
Segmentação de dados;
Várias perspetivas de visualização; tabelas e matrizes, gráficos circulares, de barras e de
bolhas, bem como conjuntos de múltiplos gráficos;
Visualização Geográfica;
29
5. ANÁLISE E ESTRUTURA DO DW
5.1. INTRODUÇÃO
Pretende-se neste projeto a construção de uma base de dados dimensional, centralizada e
otimizada para a análise dos dados. São necessários os seguintes elementos, para a sua
construção e desenvolvimento:
Análise do Negócio
Origem dos dados
Estrutura dimensional
Estrutura física do DW
5.2. ANÁLISE DO NEGÓCIO
Com os mercados cada vez mais instáveis, a capacidade das empresas de aumentar as receitas
de uma forma sustentável e previsível depende essencialmente de dois fatores:
Compras
Vendas
Vendas
As vendas da empresa encontram-se distribuídas por vários centros logísticos espalhados pelo
país, os clientes encontram-se divididos em 3 grandes segmentos: Grossistas, Retalhistas e
Grandes Superfícies e dois canais de distribuição: mercado externo e mercado interno.
O preço da venda é fundamental para o sucesso do negócio. O ciclo do preço é definido à semana
e pode variar em função da zona geográfica, condições do cliente, produto e ciclo de vida do
produto.
A empresa tem um leque muito diversificado de produtos, divididos em 4 classes que são
designados no modelo como hierarquias de produto. Os produtos podem ser frescos ou
congelados, o ciclo de vida pode variar em função desta caraterística. No primeiro caso é de 5
dias e o segundo de 365 dias, podem ser vendidos à unidade ou ao KG, em função das
caraterísticas de cada um.
Existem vários vendedores distribuídos pelo país, associados aos centros. Os vendedores estão
agregados aos clientes e os clientes podem ter mais do que um vendedor.
Os centros logísticos são compostos por um Call Center, onde são feitas as encomendas via
telefone, fax, email ou EDI; as encomendas são inseridas no sistema informático e processadas
30
nos diversos centros logísticos, com vista à satisfação do cliente. Depois de processada a
encomenda é emitida uma fatura ou Guia de Transporte.
Podem ainda ser emitidos créditos de devolução, diferença de peso ou de estorno, no caso de
um engano na emissão de uma fatura ou acertos que se pretendam efetuar.
Na Figura 9, estão definidos o fluxo dos documentos de venda. A vermelho encontram-se
assinalados os documentos necessários ao carregamento do DM das vendas, documentos que
designaremos como faturas e créditos.
Figura 9 – Fluxo dos documentos de venda
Compras
As compras estão divididas em três áreas, consumíveis e outros materiais, produtos alimentares
e aves vivas.
Os consumíveis e outros materiais, tal como as aves vivas, estão centralizados no centro de
produção em Vila Facaia. Por outro lado os produtos alimentares ou mercadorias, são
autónomos, ou seja, cada centro logístico faz a gestão destes produtos.
Para efetuar as compras é necessário um pedido de orçamento ao fornecedor através de email,
fax ou pela internet através de plataformas de compras. Depois do orçamento aprovado é
inserido no sistema informático uma nota de encomenda. Após a receção a encomenda é
conferida e inserida no sistema através de uma guia de remessa ou fatura do fornecedor.
Podem ser emitidos créditos totais ou parciais, caso a encomenda não esteja em conformidade
com o produto ou valores acordados.
Na Figura 10, estão definidos o fluxo dos documentos de compra. Como nas vendas, os
documentos necessários para o carregamento do DM das compras, são as faturas e os créditos
e estão assinalados a vermelho.
Figura 10 – Fluxo dos documentos de compra
• Faturas
• Créditos
• Guia Transferência Armazéns
Emissão do documento
•Ordens Produção
•Conclusão
Satisfação encomenda
• Telefone
• Fax
• Edi
Emissão Encomenda
•Guia Remessa
•Fatura
•Credito
Documento
•Conferência
•Satisfação Encomenda
Recepção
•Fax
•Internet
Orçamento
31
5.3. ORIGEM DADOS
O SAP é o ERP instalado na empresa e é onde reside a informação necessária ao projeto,
traduzindo-se na origem de dados.
Foi feito um levantamento exaustivo, baseado em testes, de modo a identificar as tabelas e
atributos necessários ao desenvolvimento do DW. Na verdade o SAP é um livro em branco,
aquando da sua instalação, existindo milhares de configurações e parametrizações definidas à
medida de cada cliente, não existindo documentação técnica adequada para o efeito.
Através de uma análise muito rigorosa foi possível ultrapassar este obstáculo ao
desenvolvimento do projeto.
De modo a melhorar a visão do modelo de classificação das entidades, optou-se por caracterizar
os dados na sua origem, bem como identificar as suas ligações.
Na Figura 11 e Figura 12, estão identificadas as tabelas da fonte de dados e as ligações entre
elas, respetivamente Vendas e Compras. Estas tornam-se a base para a identificação das
entidades e hierarquias do modelo dimensional. As tabelas base para a identificação das
entidades transacionais encontram-se a vermelho, e as restantes são as entidades,
componentes e de classificação, conforme descrito mais à frente neste capítulo.
Vendas
Na Figura 11, estão identificadas as tabelas principais de vendas do sistema fonte, definidas com
base no modelo de negócio. Através deste diagrama torna-se possível identificar as entidades a
criar no DW.
Figura 11 - Diagrama das vendas da estrutura de origem
32
Compras
A exemplo das vendas, na Figura 12, estão representadas as tabelas de origem referente às
compras, necessárias para a criação do DW.
Figura 12 - Diagrama das compras da estrutura de origem
No Anexo D, capítulo 10.4, poderá ser consultado o diagrama das principais tabelas de compras
e vendas do sistema fonte.
5.4. ESTRUTURA DIMENSIONAL
Uma das caraterísticas principais da estrutura dimensional é a capacidade de pesquisa e
cruzamento entre os diversos atributos e factos, ao contrário do modelo transacional, otimizado
para grandes volumes de informação, armazenados de uma forma consistente. O modelo
dimensional torna-se assim uma alternativa ao modelo transacional, a sua construção é
composta pelas seguintes fases:
Classificação das entidades
Identificação das Hierarquias
Criação Matriz Bus
Definição da Granularidade
33
5.4.1. Classificação das Entidades
Para construir o modelo dimensional é necessário classificar as entidades em três categorias
distintas:
Transacional;
Componente;
Classificação.
Entidade Transacional
A entidade transacional é responsável pelos detalhes das transações, são os principais atributos
inerentes ao negócio, representam uma métrica que foi usada num determinado instante e que
pode ser medida. As entidades transacionais identificadas neste projeto são:
VBRP: Documento de faturação - dados de item;
EKPO: Documento de compras - dados de item;
VBAP: Documento de vendas: dados de item.
Entidade Componente
A entidade componente é responsável pelos componentes que estão diretamente ligados às
entidades transacionais, estabelecendo um ligação de 1 para muitos. Identificam quem, o quê,
quando, onde e porquê de um determinado evento do negócio. As entidades componentes
identificadas neste projeto são:
EKKO: Cabeçalho do documento de compra;
EKBE: Histórico para o documento de compra;
MAKT: Descrição dos Produtos;
MVKE: Produtos por empresa;
T001W: Centros/filiais;
LFA1: Mestre de fornecedores;
TVROT: Rotas/Itinerários;
KNA1: Mestre de clientes;
KNVV: Dados de vendas e distribuição;
VBRK: Documento de faturação - dados de cabeçalho;
TVGRT: Grupo de vendedores;
TVTWT: Canais de distribuição.
34
Entidade Classificação
As entidades de Classificação são dependentes da entidade Componente, são relacionadas com
os componentes através de uma relação de 1 para muitos e representam hierarquias contidas
no modelo de dados fonte, podem ser integradas nos componentes (Modelo estrela) para
formar as tabelas de dimensão. As entidades classificação identificadas neste projeto são:
T179T: Designação das hierarquias de produtos;
TVV1T: Identificação do segmento 1;
TVV2T: Identificação do segmento 2;
T005T: Denominação dos países;
MARA: Dados gerais de material - hierarquia de produtos.
5.4.2. Identificação das Hierarquias
Depois da classificação das entidades poderá ser necessária a identificação das hierarquias
correspondentes, as hierarquias são muito importantes na modelação multidimensional (cubo),
formando a base para a transformação de um modelo relacional num modelo multidimensional.
No modelo tabular as hierarquias não são rígidas nem obrigatórias, existindo grande
flexibilidade no seu manuseamento. O uso das hierarquias é recomendado em situações que os
utilizadores não conhecem o modelo de dados ou em situações cujo modelo assim o obrigue.
As hierarquias de clientes e produtos são as de principal destaque neste projeto, devido às suas
caraterísticas no modelo de negócio e às transformações necessárias, de forma a integrar as
entidades de classificação nos componentes.
Hierarquia Produtos
A Hierarquia produtos está representada no sistema fonte pelas seguintes tabelas:
MAKT: Descrição dos Produtos;
MVKE: Produtos por empresa;
MARA: Identificação das 4 Hierarquias do produto;
T179T: Designação das Famílias de Produtos.
35
Figura 13 – Exemplo hierarquia produtos em SAP
Esta dimensão, contém uma hierarquia com cinco níveis; Produto (Nível Pai) e as Hierarquias 1,
2, 3 e 4.
Hierarquia Clientes
A hierarquia de clientes está representada no sistema fonte através das seguintes tabelas:
KNA1: Descrição dos Clientes;
KNVV: Relação dos clientes por empresa e segmentos;
TVV1T: Identificação do segmento 1;
TVV2T: Identificação do segmento 2.
36
Figura 14 – Exemplo hierarquia de clientes em SAP
Esta dimensão contém uma hierarquia de três níveis, Cliente (Nível Pai), segmento 1 e segmento
2, conforme exemplo na Figura 14.
5.4.3. Matriz Bus
Depois de identificados as tabelas de origem tornou-se mais fácil a construção da matriz Bus. A
Matriz Bus é uma ferramenta utilizada para criar, documentar e comunicar a arquitetura do DW
(Kimball, 2002). As linhas da matriz representam os processos de negócio e as colunas as
dimensões. O cruzamento das linhas e colunas, representados por “x”, indicam os processos de
negócio associados a cada dimensão.
A matriz em bus pretende acompanhar o DW, não apenas durante o seu desenvolvimento mas
durante todo o seu prazo de vida útil e deve refletir sempre o seu atual estado pois permite uma
visão rápida sobre a atual arquitetura. A Tabela 5, apresenta a matriz do modelo dimensional a
desenvolver no projeto, formada por dois processos de negócio e oito dimensões.
37
Tabela 5 – Matriz Bus do projeto
5.4.4. Granularidade
A granularidade na tabela de factos é um aspeto essencial na modelação dimensional. Esta é
descrita como a definição do mais elevado grau de detalhe que é suportado no DW, ou seja, o
máximo de detalhe que será definido. Quanto maior é a granularidade, menos detalhes têm os
dados e vice-versa.
Pretende-se efetuar uma análise diária dos dados, sendo o número de documento das vendas e
compras um campo chave para o efeito. O grau máximo de detalhe definido neste projeto,
torna-se assim o número de documento, em ambos os DMs de compras e vendas.
5.5. IDENTIFICAÇÃO E CARATERIZAÇÃO DO MODELO DIMENSIONAL
Pretendia-se, face à granularidade definida, um modelo de agregação, simples e intuitivo, a
independência das dimensões e a performance, foram fatores determinantes para a escolha do
modelo em estrela.
Para a construção do modelo em estrela será necessário identificar as tabelas de factos e as
dimensões:
5.5.1. Tabela de Factos
As tabelas de factos desenvolvidas neste projeto são as Vendas e Compras da Avibom.
A tabela de factos contém todos os registos e métricas do negócio que se pretende analisar,
agregados através de chaves estrangeiras (foreign Keys). É formada por um chave primária
(primary key), criada através da concatenação de todos os atributos que não representam as
métricas, incluindo as chaves estrangeiras, de forma a garantir a consistência dos dados.
A tabela de factos das vendas, será formada por treze atributos, destes sete são chaves
estrangeiras associados às dimensões, Centro, Canal de Distribuição, Rotas, Vendedores, Cliente
Produto e a Data. Optou-se ainda por criar um campo com a data do registo de entrada no DW,
o seguinte é o número do documento da fonte de dados e os restantes serão as métricas. As
Processos Negócio Dat
a
Pro
du
tos
Clie
nte
s
Cen
tro
s
Ven
ded
ore
s
Can
al D
istr
ibu
ição
Ro
tas
Forn
eced
ore
s
Vendas x x x x x x x
Compras x x x x
Dimensões
38
métricas são somadas e consolidadas no DW, através da agregação dos restantes atributos da
tabela de factos.
A metodologia para a tabela de factos relativa às compras será a mesma e será formada por 10
atributos, destes 4 são chaves estrangeiras associados às dimensões, Centro, Fornecedor,
Produto e Data e os restantes serão as métricas.
5.5.2. Chaves Artificiais (Surrogate Keys)
As chaves artificiais ou Surrogate Keys definem-se como uma chave primária única em todas as
dimensões. Esta chave primária não é a chave natural (chave do negócio), porque as dimensões
podem sofrer alterações ao longo do tempo (Kimball et al., 2013). Basicamente uma chave
artificial é um atributo que identifica univocamente cada registo de uma dimensão ao longo do
tempo. A chave artificial liga-se à tabela de factos formando uma chave estrangeira,
estabelecendo desse modo uma restrição de integridade referencial entre os factos e as
dimensões do modelo dimensional.
Defendida por Kimball et al. (2013) e Caldeira (2012), estava previsto em determinada fase do
projeto o uso de Chaves Artificiais. No entanto, depois de analisada a fonte de dados com mais
detalhe, concluiu-se que os atributos das dimensões, Clientes, Produtos, Rotas, Centros,
Vendedores, Fornecedores e Canais de Distribuição, não sofriam alterações ao longo do tempo.
Não havendo assim necessidade de recorrer ao uso de Chaves Artificiais, tornando-se, neste
ponto de vista, um modelo mais simples e fácil de manusear.
5.5.3. Dimensões
Uma dimensão contém uma lista de atributos, sendo cada atributo mapeado para uma
propriedade numa classe. As dimensões são desnormalizadas e constituídas por uma chave
primária, natural ou artificial. São ligadas à tabela de factos através de uma chave estrangeira,
estabelecendo uma relação de 1 para N.
Através das dimensões é possível filtrar, agrupar e rotular os dados. Os dados podem ser
apresentados num formato no qual são classificados naturalmente, de forma a permitir uma
análise mais aprofundada. As dimensões podem também incluir hierarquias naturais,
permitindo aprofundar a níveis mais detalhados. Por exemplo, a dimensão Data possui uma
hierarquia que pode ser detalhada sucessivamente por Ano, Semestre, Mês, Semana e Dia.
Dimensão Data
A dimensão data representa as diferentes granularidades temporais em que os dados podem
ser representados, apresentando uma estrutura hierárquica com 5 níveis. Os atributos principais
39
para análise são o Ano, Mês, Semana e dia, conforme Figura 15 e Figura 16, respetivamente
estrutura e exemplo. O exemplo contém 4 níveis hierárquicos, Ano, Mês, Semana e DateIdCode.
Figura 15 - Estrutura Dimensão Data
Dimensão Produto
A dimensão produto, Figura 17, é representada pelos produtos associados às vendas e compras
da empresa, estão divididos em 3 grupos principais: Frango, Pato e Peru.
A dimensão produto apresenta uma estrutura hierárquica com 4 níveis de análise, DFam1,
Dfam2, Dfam3 e Dfam4. Na Figura 18, está representado um exemplo de produtos com 2 níveis
hierárquicos, o primeiro, Frango, Pato e Peru, o segundo, as subfamílias, “Frango” nível 1;
“Frango – Miúdos”, “Frango – Desmanchado” e “Frango Inteiro”, nível 2. Os principais atributos
desta tabela são o Produto, DFam1, DFam2, DFam3 e DFam4.
•DateIdCode
•Ano
•Mes
•Semana
•Dia
Dim
Dat
e
•ProdIDCode
•Produto
•PRDHA
•Fam1
•DFam1
•Fam2
•DFam2
•Fam3
•DFam3
•Fam4
•DFam4
•DataInicio
•DataFim
Dim
Pro
du
to
Figura 18 – Exemplo da
Dimensão Produto
Figura 16 – Exemplo da Dimensão Data
Figura 17 – Estrutura Dimensão
Produto
40
Dimensão Canal de Distribuição
A dimensão Canal de Distribuição representa os canais associados às vendas da empresa e estão
divididos em dois grupos: Mercado Interno e Mercado Externo. O campo principal de análise é
a designação do Canal Distribuição, representado pelo atributo CanalDistribuição, conforme
Figura 19 e Figura 20
Dimensão Centro
A dimensão Centro representa os Centros logísticos das Compras e Vendas da empresa, estão
divididos em 9 grupos logísticos, conforme Figura 18. O campo principal para efeitos de análise
é o Centro.
Figura 22 – Exemplo da Dimensão Centro
•CanalIDCode
•Canal Distribuição
•DataInicio
•DataFimDim
Can
alD
ist
•CentroIDCode
•Centro
•DataInicio
•DataFimDim
Cen
tro
Figura 21 - Estrutura Dimensão Centro
Figura 19 – Dimensão Canal Distribuição
Figura 20 – Exemplo da Dimensão Canal de Distribuição
41
Dimensão Cliente
A dimensão Cliente é representada pelos clientes da empresa, é constituída por doze atributos,
conforme Figura 23. Os atributos principais de análise são o Cliente (nome do cliente),
TipoCliente1, TipoCliente2, País e Localidade. A Figura 24, apresenta um exemplo da dimensão
clientes, com duas hierarquias.
Dimensão Fornecedor
A dimensão Fornecedor é representada pelos Fornecedores da empresa, é constituída por dez
atributos, conforme Figura 25. Os atributos principais de análise são o Fornecedor (nome do
fornecedor), País e Localidade e a Figura 26 um exemplo da dimensão fornecedores.
•ClienteIDCode
•Cliente
•País
•Localidade
•CodPostal
•Morada
•NrContr
•Telefone
•TipoCliente1
•TipoCliente2
•DataInicio
•DataFim
Dim
Clie
nte
s
•FornIDCode
•Fornecedor
•País
•Localidade
•CodPostal
•Morada
•NrContr
•Telefone
•DataInicio
•DataFim
Dim
Forn
ece
do
res
Figura 25 - Estrutura Dimensão Fornecedores Figura 26 – Exemplo da Dimensão Fornecedor
Figura 23 – Estrutura Dimensão Clientes
Figura 24 – Exemplo da Dimensão Clientes
42
Dimensão Rotas
A dimensão Rotas representa as rotas pré-definidas das viaturas de distribuição, as rotas são
definidas diariamente em função das quantidades de carga e zonas de distribuição.
Normalmente as Rotas estão associadas a Viaturas e cada Centro tem rotas próprias, que variam
ao longo dos dias. É formada por quatro atributos, conforme Figura 27. O campo Rota (nome da
rota) é o principal campo de análise. A Figura 28, apresenta um exemplo da Dimensão Rotas
com a Dimensão Centros.
Dimensão Vendedores
A dimensão Vendedores é formada pelos vendedores da Avibom, os vendedores estão
associados aos centros e clientes e cada cliente pode estar agregado a mais do que um
vendedor, ao longo das vendas. A Figura 29 e Figura 30, representam respetivamente a estrutura
e exemplo da dimensão vendedores.
•VendedorIDCode
•Vendedor
•DataInicio
•DataFim
Dim
Ven
ded
ore
s
•RotaIDCode
•Rota
•DataInicio
•DataFimDim
Ro
tas
Figura 27 - Estrutura Dimensão Rotas
Designação
Beja
Rota 1
Rota 2
Rota 3
Rota 4
Rota 5
Sem Rota Definida
Leiria
Rota 1
Rota 2
Rota 3
Rota 4
Rota 5
Sem Rota Definida
Figura 28 – Exemplo da Dimensão Rotas
Figura 29 - Estrutura Dimensão Vendedores
Figura 30 – Exemplo da Dimensão Vendedores
43
5.5.4. Definição das Métricas
A etapa seguinte é fazer uma análise cuidada das métricas a utilizar no projeto, são elas que
determinam a análise do negócio e são armazenadas na tabela de factos de cada DM.
As métricas foram definidas ao longo do desenvolvimento do projeto, através da análise de
relatórios já existentes, bem como nas métricas tradicionalmente usadas nestas áreas,
conforme Tabela 6.
Tabela 6 – Métricas do Data Warehouse
Métricas Descrição Fatos
QuantidadeQuantidades Vendidas por
unidade de MedidaVendas
PesoPeso, normalmente unidade de
faturaçãoVendas
Valor Valor líquido Vendas
Custo Valor do custo Vendas
QuantidadeQuantidades por unidade de
MedidaCompras
PesoPeso, normalmente unidade de
faturaçãoCompras
Unidades Unidades de medida Compras
Valor Valor líquido Compras
44
5.6. ESTRUTURA FÍSICA DA SA E DW
A última etapa é a criação da estrutura física, esta estrutura é composta por duas base de dados,
a primeira para carregamento da Staging Area, com o nome de DW_SA_1800 e a segunda para
carregamento do modelo dimensional, designada por DW_1800. Para o efeito foi utilizada a
ferramenta da Microsoft, SQL Server Management Studio (SSMS).
Na Figura 31, estão representadas as treze tabelas que compõem a estrutura de base de dados
da Staging Area, tratando-se de um processo transitório, capítulo 4.4.2, estas tabelas não têm
qualquer tipo de relação.
A Figura 32, representa a estrutura do DW, constituída por dois DM de oito dimensões e duas
tabelas de factos, é nesta base de dados que ficam armazenada toda a informação do DW,
tratando-se da estrutura mais importante do projeto e apresenta-se como a fonte de dados dos
relatórios.
Figura 31 – Estrutura física da Staging Area
Figura 32 – Estrutura física do Data Warehouse
45
Conforme se pode verificar na Figura 33, é apresentado o diagrama do DW, as tabelas de factos
estão no centro da estrela com cor azul e as restantes são as dimensões. Estão relacionadas
através de chaves estrangeiras nos factos e chaves primárias nas dimensões, de forma a
assegurar a integridade e consistência dos dados no DW.
Figura 33 – Diagrama do Data Warehouse
46
6. DESENVOLVIMENTO DO PROJETO
A Figura 34, representa a arquitetura da solução BI implementada no desenvolvimento do
projeto. Traduziu-se numa sequência de etapas, a primeira consistiu na identificação da fonte
de dados disponível na plataforma SAP, que incluiu uma análise aprofundada da sua estrutura.
Foi assim, possível, identificar as dimensões e a sua correspondência na fonte de dados, fator
indispensável para a etapa seguinte, a criação física do modelo dimensional ou Data Marts.
Depois de concluída a estrutura dimensional, desenharam-se os processos ETL, que consistiu no
desenvolvimento de técnicas e uso de ferramentas da Microsoft SQL Server Integration Services
(SSIS), responsável pela extração da fonte de dados, transformação e carregamento do DW.
Depois de afinados e testados os processos de ETL, iniciou-se o processo de análise de dados do
DW, através da criação e desenvolvimento de relatórios de análise a partir da DW.
Figura 34 - Arquitetura da Solução de Business Intelligence
47
De seguida serão descritos detalhadamente as principais fases de desenvolvimento do projeto
e os elementos que a compõem.
6.1. PROCESSO ETL
A criação de DW começa na conceção do modelo que irá ser carregado com os dados
provenientes do sistema fonte SAP. É o início do denominado processo de ETL, é através deste,
que é feito numa primeira fase o carregamento da Staging Area e depois dos DMs, os dados são
extraídos e transformados de acordo com o modelo de negócio, a Figura 35 representa o fluxo
de informação no processo ETL.
Figura 35 – Fluxo dados do ETL
6.1.1. Fontes de Dados
O levantamento da estrutura de origem SAP, assumiu um papel determinante, na construção
dos DMs, assim como o seu mapeamento.
Foram identificadas vinte tabelas alvo do sistema SAP, capitulo 5.3, que representam a fonte de
dados do DW.
Foram desenvolvidas quatro views, anexo A, capítulo 10.1, no sistema operacional, de modo a
simplificar a extração e carregamento de dados da SA, que merecem especial destaque,
respetivamente:
[dbo].[VW_DWValouroVendas]: Através desta query tornou-se possível aproximar o
modelo relacional do modelo dimensional, os documentos de venda são identificados e
parcialmente transformados, bem como as métricas de peso e quantidade. Permitiu
juntar os factos do sistema fonte, numa única entidade transacional, simplificando
significativamente o processo de transformação dos dados no ETL.
[dbo].[VW_DWValouroClientes]: O sistema operacional é multiempresa e multi-lingua,
a dimensão clientes é constituída por cinco tabelas fonte, com uma relação de 1 para N
empresas e 1 cliente para N países, isto porque um cliente pode existir em mais do que
uma empresa e em mais que uma língua. Esta query pretendeu resolver este problema,
transformando esta relação de N para N, numa relação de 1 para N, relativamente à
empresa e à língua. Pretendeu também agregar os dois segmentos a que os clientes
Fontes de Dados Staging Area Data Marts
48
podem pertencer. São ainda filtrados os clientes exclusivos da Avibom, nacionais e
internacionais.
[dbo].[VW_DWValouroProdutos]: Com o mesmo objetivo de aproximar as tabelas do
sistema fonte referente aos produtos ao modelo dimensional, esta query tem como
principal função agregar os produtos por empresa e dividir as quatro hierarquias
naturais dos produtos.
[dbo].[VW_DWValouroCompras]: Esta query é muito similar à das vendas, aplicada às
compras.
6.1.2. Staging Area
A Staging Area é por definição a localização temporária, onde os dados são copiados numa fase
intermédia a partir do sistema fonte, antes do DW, não existindo qualquer processo de
transformação.
Os dados são carregados do sistema fonte através de views ou de instruções em SQL, inseridas
nos processos de carregamento da SA. O processo é incremental e executado diariamente pela
madrugada a partir dos dados do dia anterior.
Foram criados 17 processos de controlo e divididos em 4 níveis, com um fluxo de cima para baixo
de modo a simplificar a análise e descrição, conforme se pode verificar na Figura 36, na próxima
página.
O primeiro nível carateriza-se pela definição das datas de carregamento das tabelas de fatos, o
segundo pela limpeza da própria SA, o nível seguinte, a cópia das tabelas do sistema fonte que,
posteriormente, irão dar origem às dimensões e factos e por último, o nível do controlo do
processo.
As tabelas da SA, são limpas na fase inicial do fluxo. A informação relativa aos factos do sistema
fonte é extraída com base na última data de carga, existente nos fatos dos DM’s e as dimensões
são carregadas integralmente nesta fase.
Os processos mais importantes serão analisados com mais pormenor nas páginas seguintes. No
Anexo B, capítulo 10.2.1, poderão ser consultados exemplos do código fonte da SA.
49
Figura 36 - Controlo de Fluxo ETL da Staging Area
50
Este processo, “Begin Date”, é baseado numa instrução em SQL, que devolve a última data
existente na tabela de factos das vendas e é acrescentado um dia. Será a partir desta data que
os dados são extraídos do sistema fonte, se o DM não tiver qualquer informação a data de
carregamento é de 2013-01-01, data de início do histórico do DW. Esta data é criada como um
parâmetro com o nome de “BeginDate”, para ser usada como parâmetros de filtro no processo
de carga das vendas.
Este processo é igual ao anterior, mas referente às compras.
Esta instrução em SQL limpa o conteúdo das tabelas da SA, de modo a limpar o último
carregamento e a preparar a SA para um novo carregamento.
É através deste processo que as vendas (Facturas e Notas de Crédito) são extraídas do sistema
operacional e carregadas na SA. O carregamento é feito através de um comando SQL. Os dados
são filtrados no sistema fonte por mandante, empresa, código de cliente (CodCli) e pela data de
criação do sistema fonte (datacriacao). Esta data é a data de criação dos documentos do sistema
fonte, é através desta, que os dados são incrementados diariamente na tabela de fatos das
vendas do DW. O filtro é feito através de dois parâmetros de datas, a data de início (BeginDate)
e a data do fim (EndDate).
Como o processo é diário, poderia ser utilizada uma única data, no entanto optou-se por utilizar
um intervalo de datas de modo a garantir, no caso de algum problema no ETL, esta situação seja
contemplada e não falhe nenhum dia.
Na Figura 37, estão representados o fluxo e o mapeamento de 8074 registos de vendas na SA.
51
Figura 37 – Carga e mapeamento das vendas na Staging Area
52
Através deste processo são carregados os clientes, a carga é efetuada através de uma view, no
sistema fonte. Na Figura 38, estão representados o fluxo e o mapeamento de 8458 clientes na
SA.
Figura 38 – Carga e mapeamento dos clientes na Staging Area
O processo de carga das restantes nove tabelas, segmento1, segmento2, vendedores,
distribuição, produtos, famílias, centros, rotas e fornecedores, é similar, variando o
mapeamento mediante os atributos de cada dimensão.
A entidade transacional do sistema fonte relativo às compras, contém variados tipos de
documentos, como faturas, notas de crédito, recibos, orçamentos e guias de remessa, estes
últimos três não são necessários para a análise das compras, provocando mesmo uma incorreta
avaliação. Foi introduzida uma variável “VGABE2” no processo de extração de modo a garantir
que sejam extraídas exclusivamente as faturas e os créditos.
Os restantes processos são muito idênticos às vendas, não havendo necessidade de os
mensurar.
53
Por último é feito o controlo de carga da SA, todos os processos do fluxo da SA terminam nesta
fase. Este controlo meramente informativo, destina-se a emitir um email com a informação do
status do processo, com ou sem sucesso e perceber antecipadamente a existência de um
problema, conforme Figura 39.
Figura 39 – Notificação processo carregamento por email na Staging Area
6.1.3. Data Marts
Depois de completo o processo de carregamento da SA é efetuado o carregamento dos Data
Marts a partir da informação aí existente. Foi desenhado um controlo de fluxo com 15 processos,
alinhados em cinco níveis, com um fluxo de cima para baixo, conforme Figura 40, na página
seguinte.
O primeiro nível baseia-se na inserção de um registo de controlo para o tratamento dos valores
Null da chave primária das tabelas de dimensão. O segundo representa a carga em simultâneo
das várias dimensões, no seguinte é feito o preenchimento dos valores Null dos atributos das
dimensões principais, depois é feita a carga sequencial das tabelas de factos e por fim o controlo
final dos processos.
São dentro destes processos de controlo de fluxo que são feitas as transformações e os
mapeamentos de carga dos DM’s.
O controlo do fluxo e os processos serão descritos seguidamente com mais detalhe.
No Anexo B, capítulo 10.2.2, estão alguns exemplos do código fonte do processo de carga dos
DM’s.
54
Figura 40 – Controlo do Fluxo ETL dos Data Marts
55
Um dos objetivos de um DW é ser o mais fiel possível ao sistema fonte, existindo situações que
requerem um tratamento especial, nomeadamente os valores Null.
Podem existir atributos sem valor na tabela de factos, não havendo correspondência nas
dimensões, provocando erros no processo de ETL ou mesmo registos que deixam de transitar
para o DW. Para contornar esta situação optou-se por inserir um registo em cada dimensão com
o código “…” e com a designação “ Sem XXXXXX definido” em função de cada uma. Por exemplo,
para a dimensão produto a designação para os produtos sem definição é “Sem Prod.Definido”.
Tradicionalmente este processo só é necessário para o carregamento inicial das dimensões, no
entanto será importante na criação de novas dimensões, ou no caso, embora raro, de existir
necessidade de recarregar os DM’s.
Este elemento de controlo do fluxo é composto por nove tarefas, conforme Figura 41. Na
primeira tarefa (Load Dim Produtos), os atributos referentes aos produtos são carregados a
partir da SA. As quatro tarefas seguintes consistem na pesquisa dos atributos das hierarquias de
produto, em cada atributo é criado um novo campo, como resultado da pesquisa e na sexta
tarefa é criado um campo com a data e hora da inserção do produto na DM e por último nos
processos seguintes os dados são mapeados e são carregados ou atualizados na dimensão
produto, em função de eventuais alterações nos atributos (OLE DB Command) ou no caso de um
produto novo (Load DW).
Fluxo/Mapeamento
Figura 41 – Mapeamento da dimensão produto no Data Warehouse.
56
O processo de carga das restantes dimensões, Centros, Clientes, Vendedores, Canal de
Distribuição, Rotas e Fornecedores é bastante similar ao dos produtos.
Existem produtos que devido às suas características, não têm famílias definidas. Este processo
destina-se ao controlo e processamento de situações desta natureza, de modo a evitar que
apareçam sem valor na visualização dos dados.
Os valores dos atributos Fam1, Fam2, Fam3 e Fam4 (Códigos Família) são preenchidos
respetivamente por ‘000’, ‘000000’, ‘000000000’ e ‘000000000000’ e o atributo DFam1, DFam2,
DFam3 e DFam4, referente à descrição das famílias é substituído por ‘Sem Família definida’.
Embora na maior parte dos casos, não existam valores null nos atributos da dimensão clientes,
optou-se por inserir um processo específico para esta situação. Os valores null ou em branco,
são alterados para ‘Sem definição’, de modo a simplificar a visualização, o código postal devido
às suas características tem um tratamento diferente e é preenchido com os valores “0000-000”.
Depois de tratados os valores null e completo o processamento de carga das dimensões, os
processos seguinte, mais complexos, consistem na passagem de informação de forma
sequencial para as tabelas de factos dos DMs de vendas e compras.
Como ambos os fluxos são muito idênticos optou-se por particularizar o carregamento dos
factos das vendas.
Este processo é feito através da leitura dos factos da SA, passando por processos de controlo,
transformação e agregação e termina no carregamento de dados no DM das vendas, a Figura 42
está representado o fluxo de carga dos factos das vendas.
57
Figura 42 – Fluxo de carga dos factos das vendas
A leitura dos factos da SA são feitos através de uma instrução em SQL, na tarefa designada por
“Load SA”, o fluxo segue com a tarefa “Transformation”, onde são feitas as transformações e
cálculos necessários, em função do modelo dimensional previamente definido. Posteriormente
é feito o controlo dos valores nulos referentes às chaves estrangeiras das dimensões, produtos,
centros, vendedores, canal de distribuição, clientes e rotas. É através da união de duas tarefas
(U_Produtos) que este processo é feito, na primeira tarefa (Produtos) é feita uma pesquisa
através do lookup, os valores não encontrados são tratados numa tarefa especifica (Null
Produtos) e substituídos por “…”, conforme se pode verificar na Figura 43. Esta chave foi
previamente introduzida nas dimensões de modo a garantir que não existam erros.
Figura 43 – Exemplo de transformação dos valores null na tabela de produtos
58
O processo é equivalente para as restantes cinco dimensões, Centros, Vendedores, Canal de
Distribuição, Cliente e Rotas.
Depois de preparadas as dimensões é necessário consolidar a informação (Aggregate). Nesta
fase a informação proveniente da SA, já se encontra devidamente transformada e tratada, será
agora necessário agregar a informação de acordo com a granularidade previamente definida.
Esta tarefa consiste na agregação da chave primária, com a soma das métricas, conforme Figura
44.
Figura 44 – Agregação dos factos de Vendas no Data Warehouse
59
A última tarefa deste fluxo é a passagem dos dados para o DM (Load Factos Vendas), depois de
extraídos, transformados e consolidados. Esta tarefa é efetuada através do mapeamento dos
atributos de entrada com os atributos de saída, conforme Figura 45. Os atributos de entrada têm
origem na fonte de dados e os atributos de saída são os atributos do DM.
Figura 45 – Mapeamento dos factos das vendas no Data Warehouse
O último processo é o controlo do ETL, da mesma forma que a SA. Este controlo meramente
informativo, destina-se a emitir um email com a informação do status do processo, com ou sem
sucesso e perceber antecipadamente que houve problemas, conforme Figura 46.
Figura 46 - Notificação processo carregamento por email do ETL no Data Warehouse
60
6.2. RELATÓRIOS
A informação dos relatórios é de caracter confidencial da empresa, assim para os exemplos
neste capítulo, optou-se por filtrar informação e ocultar alguns atributos.
O desenvolvimento dos relatórios, foi baseado na informação já existente no sistema SAP.
Procurou-se através de análise interna e dos conhecimentos adquiridos ao longo do tempo,
consolidar dentro do possível, uma vasta gama de relatórios estáticos, cujo propósito seria servir
órgãos isolados dentro da empresa, numa perspetiva meramente operacional. Por outro lado,
procurou-se introduzir novas métricas e ferramentas de análise, como KPIs, Gráficos Dinâmicos
e Dashboards2, até à data inexistentes, como suporte à tomada de decisão.
Desta forma, as ferramentas utilizadas para a elaboração de relatórios, são o SQL Reporting
Services 2014 e a plataforma Excel 2013, a primeira para a elaboração de relatórios pré-
configurados e a segunda para relatórios dinâmicos e mais alargados, ambas com capacidade de
aceder diretamente à estrutura relacional dos DMs.
6.2.1. Ciclo de Vida
O ciclo de vida de um relatório, é constituído por um fluxo de três fases, conforme Figura 47,
designadas por Criação, Manutenção e Entrega.
Figura 47 - Ciclo de vida dos relatórios
Criação: É na primeira fase que os relatórios são desenhados e desenvolvidos, com as
ferramentas do SSRS, Report Builder ou Visual Studio. Para o efeito é necessário
identificar um conjunto de informações, como as Fontes de dados, Tabelas, Dimensões
e Métricas a usar. Os dados são integrados em Gráficos, Tabelas, Matrizes ou outra
forma de representação de modo a formar um primeiro esboço, depois de formatado e
2 Um Dashboard permite apresentar a informação resumida de uma forma intuitiva e dinâmica, e
são semelhantes ao cockpit de um automóvel e representados através de gráficos.
•Desenho e testes
•PublicaçãoCriação
•Organização
•ControloManutenção
•Assinaturas
•PortalEntrega
61
ajustado, o relatório é testado e validado nesta fase, antes de ser publicado na
plataforma centralizada, para ser utilizado.
Manutenção: Depois de publicados os relatórios são organizados, controlados e
configurados aos utilizadores, numa plataforma Web centralizada para o efeito.
Entrega: Depois de desenvolvidos e publicados os relatórios estão em condições de ser
visualizados. Os utilizadores podem receber os relatórios através de assinaturas
previamente agendadas pelo administrador do sistema e receber por email ou numa
pasta partilhada no formato desejado. Podem também ser acedidos diretamente
através da seleção do relatório a partir da ferramenta Web de visualização de relatórios
ou através de links do sharepoint.
6.2.2. Estrutura Funcional
Conforme descrito anteriormente, existem duas plataformas distintas de relatórios, SSRS e
Excel, ambas com finalidade e publico alvo diferente. A primeira direcionada para utilizadores
com menos experiência, com automatismos de envio e subscrição, e vocacionada para uma
estrutura de relatórios pré definidos, a segunda, por seu lado, destina-se a utilizadores mais
avançados e para análises mais detalhadas e inovadoras.
Com um leque muito alargado de opções de análise e também à larga experiência em Excel dos
principais destinatários do projeto, optou-se por desenvolver parte dos relatórios no Excel,
permitindo reduzir substancialmente os mapas a desenvolver na plataforma SSRS,
nomeadamente nos centros logísticos e compras.
Plataforma SSRS
A plataforma SSRS é constituída por cinco parâmetros de análise: data de faturação, mês inicial
e final, o ano e os centros; estes parâmetros são aplicados ao relatório base e aos relatórios
subsequentes, tornando-se assim possível, analisar com mais detalhe períodos temporais ou
áreas de negócio específico. Na Figura 48, estão representados os parâmetros de filtros,
transversal a toda a plataforma SSRS da Avibom.
62
Figura 48 - Área de Filtro na plataforma SSRS
Esta plataforma, foi desenvolvida especificamente para as vendas, a sua estrutura funcional é
constituída por um relatório base designado por Dashboard (Figura 49) e os restantes derivam
deste. O Dashboard, pretende oferecer uma visão global do negócio das vendas, em
quantidades, valor e margens, com diferentes granularidades temporais, diárias, semanais e
mensais e em várias perspetivas dimensionais. Os restantes relatórios, oferecem uma análise
mais aprofundada do negócio, encontrando-se focados numa avaliação mais detalhada de
produtos e clientes da empresa. Para o efeito basta premir o rato nas diferentes áreas do
Dashboard.
Com o objetivo de apresentar e enriquecer os dados de uma forma clara e intuitiva, foram
inseridos nos relatórios, além de atributos calculados, tabelas, matrizes, gráficos lineares e de
barras, foram introduzidos Sparklines3 e Gauges4. Houve ainda a preocupação em distinguir
através de cores, avermelhadas e esverdeadas, respetivamente, valores negativos e positivos,
conforme se poderá verificar com exemplos no capítulo 6.2.4.1.
Os relatórios adjacentes ao Dashboard foram criados através de um modelo, onde estão pré-
definidos os cabeçalhos e rodapés a utilizar.
3 Sparkline é um pequeno gráfico de fácil visualização, intuitivo e sem eixos. 4 Gauge é um gráfico estilo velocímetro bastante intuitivo e muito associado aos dashboards.
63
Figura 49 - Dashboard das vendas
64
O Dashboard é enviado diariamente por email, através de uma assinatura programada. Desta
forma é possível a leitura em qualquer dispositivo, com capacidade de receção de emails, como
computador, dispositivos móveis ou tablets. A tabela que se segue, apresenta o calendário
semanal do dashboard enviado por Email, bem como os parâmetros do filtro aplicado, hora de
envio e os respetivos destinatários.
Tabela 7 – Calendário Semanal de Envio de Relatórios na Plataforma SSRS
Parâmetros Filtro*
Centros Destinatários Centro Hora Seg. Ter. Qua. Qui. Sex. Sáb. Dom.
Vila FacaiaDireção Comercial,
Administração e MarketingTodos os Centros 09:00 X X X X X X O
Barcelos Diretor Centro Barcelos 09:00 X X X X X X O
Maia Diretor Centro Maia 09:00 X X X X X X O
Leiria Diretor Centro Leiria 09:00 X X X X X X O
Tomar Diretor Centro Tomar 09:00 X X X X X X O
Beja Diretor Centro Beja 09:00 X X X X X X O
Albufeira Diretor Centro Albufeira 09:00 X X X X X X O
Legenda: X - Dia programado
O - Dia não programado
* Os parâmetros temporais são os standarts, gerados a partir do dia, mês e ano de emissão do relatório.
Dias da Semana
65
Plataforma EXCEL
No Excel procurou-se desenvolver uma plataforma a partir do DW, que desse resposta às
diferentes perspetivas de análise das vendas e compras da empresa, da forma mais simples,
dinâmica e objetiva possível.
Os relatórios de vendas foram desenvolvidos com base no modelo inicial
“AviPowerViewVendas.xlsx” e replicados para os restantes livros. O modelo inicial tem a
informação toda do DM de vendas. Cada livro é organizado por 7 folhas, com a finalidade de
oferecer variadas visões do negócio.
Para satisfazer a análise das compras foi criado um livro com o nome de
“AviPowerViewCompras.xlsx”, com toda a informação do DM de compras. O livro é organizado
por 5 folhas com variadas visões do negócio das compras.
A informação é importada para os livros a partir dos DM’s e armazenada na Power Pivot. Foi
criado em cada livro uma tabela dinâmica para analisar a informação nas mais variadas formas,
perspetivas e combinações, de forma a contemplar todas as necessidades ao nível operacional
e de gestão.
As Power Tables têm do lado esquerdo uma área de segmentação dos dados, de modo a tornar
a análise mais fácil e intuitiva, conforme se pode analisar no capítulo 6.2.4.2, Figura 56.
Foram criadas várias Power Views (vistas avançadas), interativas, direcionadas a diferentes
perspetivas do negócio, como Margens, Produtos, Rotas, Fornecedores e Clientes.
As Power Views foram desenhadas de modo a visualizar a informação da forma mais uniforme
e simples ao utilizador, mas com um leque muito alargado de opções de navegação e seleção.
Para o efeito foram introduzidos mapas de localização geográfica, com o objetivo de aperfeiçoar
a visão e seleção do negócio, com vista a otimizar a análise e exploração das vendas nesta área
inovadora. Torna-se assim possível agregar automaticamente diferentes níveis hierárquicos,
como país, concelho ou localidade, por exemplo a análise de vendas por país, concelho ou
localidade, bem como cruzar locais de vendas entre centros. Foram ainda introduzidos, zonas
de segmentação de dados, de modo a filtrar a informação de uma forma simples e eficaz e
criados gráficos de barras e circulares para uma visualização mais clara e objetiva.
No cabeçalho à direita dos relatórios foram acrescentadas métricas importantes de análise.
Nas vendas foi introduzido um KPI, referente às margens de modo a identificar facilmente,
através de um ícone de forma redonda, de cores, vermelho, amarelo e verde, os valores
respetivamente, negativos, intermédios e positivos.
No capítulo 6.2.4.2, estão disponíveis vários exemplos de relatórios na plataforma Excel.
66
6.2.3. Descrição dos Relatórios
Devido à quantidade de relatórios existentes nas duas plataformas e às suas semelhanças, optou-se por identificar através de exemplos, as caraterísticas principais de cada uma.
Na plataforma SSRS, foram desenvolvidos 17 relatórios, criados 77 Datasets e uma fonte de
dados do DW, com o nome de AviDW. Os Datasets, são alimentados através de uma view
desenvolvida especificamente para o efeito, Anexo C, capítulo 10.3.4.
Na Tabela 8 estão representados os relatórios desenvolvidos na plataforma SSRS e na Figura 50,
na página seguinte, um exemplo de um DataSet, com desenvolvimento em SQL.
Tabela 8 - Identificação dos relatórios na plataforma SSRS
Relatório Descrição
VendasExecutivos.rdl Dashboard com a evolução das Vendas.
Clientes.rdl Análise TOP 30 de clientes novos e sem vendas em valor versus período anterior.
VendasDia.rdlAnálise diária das vendas, em quantidade, Preços médio, valor e margens por produto e
hierarquias, com o TOP 10 de produto e clientes.
VendasDiaClie.rdl Análise diária das vendas, em quantidade, Preços médio, valor e margens por cliente e produto.
VendasDiaProd.rdlAnálise de Vendas diária, em quantidade, Preços médio, valor e margens por Produto e
hierarquia1
ClientesTop.rdl Análise Top 30 clientes, em valor com mais e menos vendas no período selecionado
VendasMes.rdlAnálise Mensal das Vendas, em quantidade, Preços Médios, valor e margem por produto e
hierarquia, em função do mês selecionado no gráfico, versus período homólogo.
VendasSemana.rdlAnálise semanal das Vendas, em quantidade, Preços Médios, valor e margem por produto e
hierarquia, em função da semana selecionada no gráfico, versus período homólogo.
ClientesTopMargem Análise Top 30, dos clientes com mais e menos margem no período selecionado
VendasMargMes.rdlAnálise Mensal das Margens por produto e hierarquia, em função do mês selecionado no gráfico,
versus período homólogo.
VendasMargSemana.rdlAnálise Semanal das Margens por produto e hierarquia, em função da semana selecionada no
gráfico, versus período homólogo.
VendasFrgPatPerMes.rdl
Análise de Vendas em quantidade, valor e margem dos produtos Core, Frango, Patos e Peru, em
função do Gauge ou gráfico selecionado, versus período homólogo. Inclui também a evolução das
Vendas e Margens Semanais
VendasPrecos.rdlAnálise Top 5 clientes, com preços médio mais baixos por Produtos Core, em função do Gauge
selecionado.
Vendedores.rdl
Análise de vendas em quantidade, valor e margem, por vendedor mensal por cliente e produto, em
função do mês selecionado no gráfico, inclui ainda o número total de clientes versus período
homólogo
VendasMesTipProduto.rdl Análise de vendas em quantidade por tipo de produto, em função da seleção no gráfico.
VendasMesFam1.rdl Análise de vendas em quantidade e valor por família, em função da seleção no gráfico.
VendasClientTipo.rdl Análise de vendas em quantidade e valor por tipo de produto, em função da seleção no gráfico.
67
Figura 50 - Exemplo de um Dataset na plataforma SSRS
Na plataforma Excel foram criados oito livros e cinquenta e três folhas de suporte ao negócio,
sete livros foram destinados às vendas, a sua estrutura é idêntica, variando o conteúdo em
função dos centros logísticos a que se destinam. O oitavo e último livro destina-se às compras e
é composto por 4 folhas.
Para cada livro do Excel foi desenvolvida uma view, com o objetivo de simplificar o acesso aos
dados e reforçar a segurança de acesso aos Dm’s.
Só os utilizadores, devidamente autenticados para o efeito, conseguem aceder às respetivas
views, o acesso aos ficheiros do Excel também se encontram limitados, bem como os links do
sharepoint, por exemplo o diretor do Centro 1802, só tem acesso, à view respeitante às suas
vendas, como ao link e ao ficheiro de Excel respetivo.
Outra vantagem na utilização das views, foi simplificar o tratamento dos dados na plataforma
do Excel, através da transformação do modelo dimensional em tabular. Através da view foi
possível transformar a informação numa única tabela constituída por todos os atributos
principais da tabela de factos e dimensões, tornando-se muito mais simples, a importação e
tratamento na Power Pivot.
68
Na tabela 6, estão identificados os DM’s e as views, que servem de fonte a cada livro, o centro
a que se destina, bem como os respetivos destinatários. No Anexo C, capítulo 10.3, podem ser
consultadas as views com mais detalhe.
Tabela 9 – Identificação dos Livros Excel do projeto
6.2.4. Exemplos
Conforme abordado anteriormente, todos os relatórios da Plataforma SSRS exemplificados têm
origem no Dashboard (Figura 49), para compreender melhor o seu funcionamento, foi
adicionado aos exemplos, no lado esquerdo em cima, parte da estrutura do Dashboard que dá
origem aos relatórios. As zonas assinaladas por um retângulo vermelho, são as zonas para a
abertura dos relatórios. No caso dos gráficos a zona selecionada serve também como parâmetro
do relatório, por exemplo, no gráfico de barras das vendas mensal no Dashboard, se for
selecionado o mês de Setembro do ano 2015, será aberto um relatório com a informação
referente a esse período, o mesmo se aplica à semana.
DataMart Centro Filtro Livro Excel View origem dados Destinatários
Vendas Todos Sem Fi l tro AviPowerViewVendas .xlsx Vw_DWVendasPowerViewGeo Direção Comercia l e Marketing
Vendas Barcelos Barcelos AviPowerViewVendas_1802.xlsx Vw_DWVendasPowerViewGeo_1802 Diretor Centro
Vendas Maia Maia AviPowerViewVendas_1803.xlsx Vw_DWVendasPowerViewGeo_1803 Diretor Centro
Vendas Leiria Leiria AviPowerViewVendas_1804.xlsx Vw_DWVendasPowerViewGeo_1804 Diretor Centro
Vendas Tomar Tomar AviPowerViewVendas_1805.xlsx Vw_DWVendasPowerViewGeo_1805 Diretor Centro
Vendas Beja Beja AviPowerViewVendas_1806.xlsx Vw_DWVendasPowerViewGeo_1806 Diretor Centro
Vendas Albufeira Albufeira AviPowerViewVendas_1807.xlsx Vw_DWVendasPowerViewGeo_1807 Diretor Centro
Compras Todos Sem Fi l tro AviPowerViewCompras .XLSX Vw_DWComprasPowerViewGeo Diretor Compras
69
6.2.4.1. Exemplos de Relatórios na Plataforma SSRS
Na Figura 51, é possível observar as vendas diárias, bem como o Top 10 de vendas de clientes e
produtos. Para aceder ao detalhe basta pressionar o botão direito do rato no retângulo
vermelho à esquerda da figura.
Na Figura 52, está representado um exemplo de um relatório de vendas com duas tabelas, na
tabela à esquerda estão representados os clientes sem vendas e à direita novos clientes.
Tornando-se possível através de um click, identificar clientes eventualmente perdidos e
eventuais novos clientes.
Figura 51 – Exemplo de sub-relatório das vendas diárias
70
Figura 52 - Exemplo sub-relatório Top 30 Clientes Com e Sem Vendas
Na Figura 53, está representada uma Matriz Dinâmica das Vendas de produtos do Mês de
Outubro, com três hierarquias de produto. Os produtos principais, Frango Inteiro Fresco e
Congelado, Peru e Pato Inteiro Fresco e Congelado, têm por defeito selecionada a terceira
hierarquia (nível 3), a vermenho. Nas métricas a verde estão representados os valores positivos
e a vermelho os negativos relativamente ao ano anterior.
É possível navegar através das três hierarquias nesta matriz, até ao detalhe dos produtos
vendidos.
Figura 53 – Exemplo de sub-relatório das vendas de Outubro
71
Para aceder aos relatórios da Figura 54, basta pressionar o botão direito do rato em cima do
Gauge correspondente do Dashboard.
Neste exemplo a seleção recaiu no produto Frango Fresco. É possível analisar com grande
detalhe a evolução semanal das margens e valores vendidos, bem como produto a produto, as
quantidades, o preço médio e os valores, com as cores a distinguirem a evolução das vendas
homólogas.
Figura 54 – Exemplo de sub-relatório das Vendas Frango Fresco com evolução semanal
Através da seleção do gráfico circular na área correspondente aos frescos, torna-se possível
analisar as hierarquias (Nível 1) correspondentes aos produtos frescos e de um modo dinâmico
os produtos correspondentes, conforme Figura 55.
Figura 55 – Relatório de vendas por tipo de produto
72
6.2.4.2. Exemplos de Relatórios na Plataforma Excel
Figura 56 – Exemplo Power Table das vendas
Figura 57 – Power View com as margens de vendas
73
Figura 58 – Power View dos produtos e hierarquias de vendas
Figura 59 – Power View dos Clientes por centro e tipo de vendas
74
Figura 60 – Power View dos vendedores
Figura 61 – Power View com a rentabilidade das rotas
75
Figura 62 – Exemplo Power Table de Compras
Figura 63 – Power View por produto e fornecedor de compras
76
Figura 64 – Power View com evolução das compras por tipo de produto
Figura 65 – Power View de análise anual por centros e produto
77
7. IMPLEMENTAÇÃO DO PROJETO
Nesta fase os relatórios já se encontram concluídos e os processos de ETL consolidados no DW,
sendo necessário efetuar alguns passos finais de implementação, nomeadamente os testes
finais do ETL e relatórios e a programação dos Jobs de ETL. Depois desta fase os dados ficam
disponíveis aos utilizadores.
7.1. VALIDAÇÃO E TESTES FINAIS
Os testes do ETL, foram feitos através do carregamento inicial de 3 anos do sistema operacional
SAP na SA. Com este teste, de sensivelmente 2 milhões de transações foi possível testar ao limite
o comportamento da fonte de dados e o processo de carregamento do ETL. Os resultados foram
satisfatórios, levando cerca de 45 minutos e concluídos com sucesso. Depois do histórico
carregado, o carregamento é processado diariamente, demorando sensivelmente 5 minutos.
Os testes à integridade da informação foram feitos através da comparação de mapas do sistema
operacional, já devidamente testados e validados, com os do DW. Estes testes foram feitos
através da extração do DW, de um período de um ano de compras e vendas, para o Excel. Foram
detetadas algumas diferenças relativas aos documentos de crédito, quer das vendas como das
compras. Embora pouco significativas, o problema foi identificado e resolvido.
Posteriormente, e à medida do seu desenvolvimento, foram feitos testes à integridade da
plataforma Excel e SSRS, seguindo a mesma metodologia. Foram encontrados alguns erros
relativos à parametrização do dataset referente aos gauges no dashboard das vendas. Depois
de analisados e detetados, os erros foram corrigidos.
Todos os testes feitos demonstram que o DW está estável e íntegro, bem como os testes finais
efetuados às plataformas de relatórios correram com sucesso.
7.2. IMPLEMENTAÇÃO DOS JOBS
Na fase final do projeto torna-se necessário automatizar os processos de carregamento do DW,
de modo a evitar a intervenção humana, nomeadamente fora de horas. Para o efeito, corre
diariamente no SQL Server 2014 pelas 07:00, um processo designado por Job, com o nome de
AviSSIS_DW. Este Job é constituído por dois passos e executado sequencialmente, o primeiro
com o nome de ETL_SA, para carregamento da SA e o segundo com o nome de ETL, para
carregamento do DW. Já com os dados carregados no DW, são posteriormente executados
automáticamente os mapas, conforme descrito no capítulo 6.2.2, Tabela 7.
78
8. CONCLUSÕES
Segundo a IDC5 (Fórum, IDC 2015), os principais desafios globais que as organizações enfrentam
e que mais de destacam neste projeto são os seguintes:
Recolher e analisar mais informações sobre clientes.
Conseguir desenvolver melhores provisões nas várias áreas de negócio de forma a
tomarem decisões mais assertivas e de forma mais rápida.
A criação dos dois DMs de compras e vendas, o desenvolvimento do ETL e as duas plataformas
de relatórios, desenvolvidos neste projeto, contribuem de forma significativa, como resposta a
estes desafios, sendo seguro afirmar que os objetivos inicialmente propostos não sofreram
alterações ao longo do projeto.
Outro aspeto importante deste projeto, foi o contributo para o meu enriquecimento pessoal e
profissional, não só através da consolidação dos conhecimentos adquiridos nas disciplinas do
mestrado, como no desenvolvimento de novas aptidões através do uso das ferramentas da
Microsoft em todas as vertentes deste projeto.
Não menos significativo, este relatório irá servir de manual técnico, com elevado nível de
detalhe, funcionando como alavanca ao desenvolvimento futuro de novas funcionalidades ou
mesmo como base a futuros projetos, tanto de relatórios, bem como na extensão a outras áreas
de negócio, através do desenvolvimento de novos DMs.
8.1. OBJETIVOS CONCRETIZADOS
No decorrer do projeto existiram alterações na metodologia utilizada na recolha dos dados para
os relatórios, mas que não comprometeram o resultado final a que estava proposto. Deste
modo, os objetivos, resumem-se aos seguintes pontos:
Desenho e implementação de uma SA e de um DW escalável e eficiente.
Desenho, desenvolvimento e implementação de um processo ETL com uma gestão
versátil.
Desenvolvimento de duas plataformas de relatórios, SSRS e Excel, de forma a
disponibilizar a informação de uma forma atempada, simples e dinâmica.
O primeiro e segundo objetivo, são complemento um do outro, foram desenvolvidos em
paralelo. Surgiram algumas dificuldades referentes à modelação e à criação da base de dados,
mas que foram gradualmente ultrapassadas.
5 Empresa líder mundial na área de “Market Intelligence”
79
O desenvolvimento dos relatórios foi uma tarefa morosa, nomeadamente no SSRS, embora os
dados tivessem devidamente formatados e configurados no DW, existia pouca prática nesta
plataforma de desenvolvimento, sendo uma ferramenta praticamente nova para mim. A
importação dos dados para o Excel através da Power Pivot e a implementação das folhas de
análise do Excel, foram mais pacíficas, embora a Power View, como ferramenta de análise fosse
até à data desconhecida.
A simplicidade e qualidade, das plataformas desenvolvidas aos utilizadores finais, foram
preponderantes no sucesso do projeto, superando as expetativas da empresa. Apesar de não
estar explicito no relatório, traduziu-se naturalmente num dos objetivos finais do projeto.
Assim e apesar das dificuldades, que levaram ao prolongamento da entrega do relatório,
poderei dar como garantido o cumprimento de todos os objetivos inicialmente propostos.
8.2. LIMITAÇÕES
Houve a preocupação neste projeto em acompanhar a evolução e as novas tendências
tecnológicas de análise de dados, sendo o modelo Tabular uma das suas mais recentes
inovações. No entanto, a versão do SQL existente na empresa não suporta o modelo Tabular
no SSAS, outra solução seria o uso do modelo tabular através da instalação da plataforma de
relatórios (SSRS) no Sharepoint, mas, mais uma vez, a versão do Sharepoint instalado, não
permite integrar a Power Pivot. Como alternativa, optou-se assim, com a inclusão do modelo
Tabular no Excel, através da Power Pivot em detrimento do Cubo OLAP, desenvolvido numa
fase precoce do projeto.
Esta opção revelou-se, numa fase inicial, uma limitação, visto tratar-se de uma ferramenta
nova, pelo que houve necessidade de aprofundar, embora superficialmente, os conhecimentos,
nomeadamente na linguagem de tratamento de dados DAX.
As complexas views e querys desenvolvidas em SQL para recolha e tratamento da informação,
no SSRS e para o ETL, obrigaram também a uma revisão aprofundada do tema.
A definição certa da granularidade para o projeto foi outra condicionante, numa fase inicial a
granularidade escolhida para o projeto era ao dia, os dados eram agregados e as métricas
consolidadas diariamente. Na fase de testes, chegou-se à conclusão que o campo número do
documento do sistema fonte seria importante numa perspetiva operacional. Esta situação
obrigou uma série de ajustes no ETL, na fonte de dados e ainda na redefinição da estrutura
física do DW. Foi necessário introduzir nas tabelas de factos o número de documento, optando-
se ainda por introduzir uma data de controlo de carregamento nos DMs. Por lapso, os nomes
atribuídos a estes atributos não foram os mais adequados, não sendo chaves estrangeiras (FK),
foram nomeados como tal.
A estrutura complexa, a falta de documentação e a dimensão do sistema fonte (SAP), provocou
uma dificuldade acrescida na identificação das tabelas e atributos fonte, quer para a
80
identificação do modelo de negócio para o desenvolvimento das views para o ETL, bem como
para o seu mapeamento, representando o ponto mais crítico do projeto, na minha perspetiva.
Resumindo, as principais limitações do projeto deveram-se aos seguintes aspetos:
Versões de software instalados;
Definição da granularidade;
Dimensão e complexidade do sistema fonte;
Linguagens tratamento dados SQL e DAX.
8.3. TRABALHO FUTURO
Conforme anteriormente descrito, um dos objetivos do projeto concentrava-se na
escalabilidade. Através do modelo de dados adotado torna-se possível de uma forma
transparente, estender conforme previsto o DW a outras áreas de negócio, nomeadamente
financeira e produção.
Para que seja possível, no futuro usufruir em modo nativo do modelo tabular do SQL 2014,
recomendo que se efetue o Upgrade do SQL Server 2014 Standart para SQL Server 2014
Business Intelligence. Torna-se assim mais fácil e prático, o processo de integração com a
plataforma Excel, bem como as políticas de segurança de acesso os dados.
Conforme já abordado, a dimensão e estrutura do sistema fonte, condiciona e limita a extração
e transformação direta dos dados, acarretando riscos ao seu normal funcionamento.
Recomendo vivamente que se mantenha a metodologia ETL atualmente em vigor, em
detrimento da alimentação direta de futuras plataformas de relatórios a partir da fonte.
No desenvolvimento deste relatório e na fase final do projeto, foram detetados alguns
processos, que não comprometem o normal funcionamento, mas que podem ser melhorados
e otimizados ao longo do tempo, nomeadamente:
Manutenção das views do sistema fonte: Foram desenvolvidas algumas views de
testes no sistema fonte que devem ser eliminadas; proceder à deteção e eliminação de
atributos não utilizados nas views de forma a potenciar o seu desempenho.
Manutenção do DW: Embora tenham sido desenvolvidas rotinas de manutenção e
backups da DW, fora do âmbito deste projeto, é recomendado, por questões de
otimização e performance, que sejam eliminadas tabelas e atributos das dimensões
que não sejam necessários à DW. Por exemplo, as dimensões têm um campo referente
à data final, que numa fase inicial destinava-se ao controlo das chaves artificiais, não
sendo necessários podem ser eliminados. Existem também views de testes que podem
ser eliminadas.
81
Manutenção SSRS: Existem alguns relatórios e datasets de desenvolvimento e testes
que não são utilizados e devem ser eliminados.
Atualmente a DW, com informação de sensivelmente três anos de histórico, tem uma dimensão
de 1,7 Gb e encontra-se devidamente indexada e otimizada. No entanto devem ser
implementadas políticas de manutenção e análise, nomeadamente, à performance, segurança
e dimensão do DW, de modo a garantir disponibilidade e funcionalidade em todo o ciclo de
vida.
82
9. BIBLIOGRAFIA
Ballard, C., Farrell, D. M., Gupta, A., Mazuela, C. e Vohnik S. (2006), Dimensional Modeling: In a
Business Intelligence Environment.: Redbooks. 99-102
Caldeira, C. P. (2012), Data Warehousing: Conceitos e modelos 2th ed.: Edições Sílabo, Lda.
Carlos Alberto Gomes Durães Guerra (2010), Perspetivas do sector avícola. Acedido em 09 de
Agosto de 2015, no web site da: DRAP Centro Laboratório Veterinário de Viseu:
http://www.acessibilidade.gov.pt/accessmonitor/dir/see/?cD01fG89aHh8cz0yNTN8dj1wYWdl
Clements, R. e Reade, J. (2012). What’s new in SQL Server: Unleash the new features of SQL
Server 2012: Packt Publishing Ltd. 79-97
Gabinete de Planeamento e Políticas (2007), Carne Diagnóstico Setorial. Acedido em 09 de
Agosto de 2015, no web site do: Gabinete de Planeamento, Políticas e Administração Central:
http://www.gpp.pt/pbl/diagnosticos/Carne__Diagnostico_Sectorial.pdf
Howson, C. (2008), Successful Business Intelligence: Secrets to making BI a Killer App. ed.: The
McGraw-Hill.
Inmon, H.W. (2005), Building the Data Warehouse. 4th ed.: John Wiley & Sons. 29 - 33
Kimball, R., M. Ross (2002), The Data WareHouse toolkit: The complete Guide to Dimensional
Modeling. 2th Ed.: Wiley Computer Publishing. 1-62
Kimball, R. and M. Ross, (2013), The Data WareHouse toolkit: The Definitive Guide to
Dimensional Modeling. 3th Ed.: Wiley Computer Publishing: 1-109
Larson, B. (2012), Delivering Business Intelligence with Microsoft SQL Server 2012. 3th Ed.:
McGraw-Hill.
83
Larson, B. (2012), Reporting Services Microsoft SQL Server 2012. 4th Ed.: McGraw-Hill.
Microsoft Trends. PowerView vs. PowerPivot vs. Power BI. Acedido em 12 de Maio de 2015, no
web site da: Microsoft: http://www.microsofttrends.com/2014/02/15/powerview-vs-
powerpivot-vs-power-bi/
Mistry, R. , Misner S. (2012). Introducing Microsoft SQL Server 2012: Microsoft
Mohanty S., Jagadeesh, M., Srivatsa, H., (2013). Big Data Imperatives: Enterprise Big Data
Warehouse, BI implementations and Analytics: Apress: 1-3
Moody, D. L. e Kortink, M. A. R. (2000), From Enterprise Models to Dimensional Models: A
Methodology for Data Warehouse and Data Mart Design, In Proceedings of International
Workshop on Design and Management of Data Warehouses (DMDW'2000), Sweden, pp: 5-1,5-
12
Mundy, J., ThornthWaite, W. e Kimball, R. (2011), The Microsoft Datawarehouse Tookit: With
Sql Server 2008 R2 and the Microsoft Business Inteligence. Toolset. Second Ed.; Wiley
Computer Publishing
Office. Power View: explorar, visualizar e apresentar dados. Acedido em 29 de Agosto de 2015,
no web site da: Microsoft: https://support.office.com/pt-pt/article/Power-View-explorar-
visualizar-e-apresentar-dados-98268d31-97e2-42aa-a52b-a68cf460472e
Office. Novidades no Power Pivot no Microsoft Excel 2013. Acedido em 30 de Agosto de 2015,
no web site da: Microsoft: https://support.office.com/pt-pt/article/Novidades-no-Power-
Pivot-no-Microsoft-Excel-2013-930be6c5-e839-4860-8c74-8a5e2cba1279?ui=pt-PT&rs=pt-
PT&ad=PT
Paredaens, J., Bra, P.B., Gyssens, M., Gucht, D.V. (1989), The Structure of the Relational Database
Model. Ed.: Wilfried Brauer, Grzegorz Rozenberg, Arto Salomaa.
84
Russo, M. (2014). SSAS Tabular as Analytic Engine: SQLBI
Russo, M., Ferrari, A., Webb, C. (2012), Sql Server 2012 Analysis Server: The BISM Tabular
Model.: Microsoft.
SAS Institute Inc. (2015), 9.4 OLAP Server: User's Guide, Fourth Edition, Cary, NC, USA
Thomsen, E. (2002), OLAP Solutions: Building Multidimensional Information Systems. 2th ed.:
John Wiley & Sons, Inc.
Turban, E., Sharda, R., Delen, D. e King, D. (2010). Business Intelligence: A Managerial
Approach Second Edition. Upper Sadle River, New Jersey: Pearson Prentice Hall. 8-10
Wrembel, R. e Koncilia, C., (2007). Data Warehouses and OLAP: Concepts, Architectures and
Solutions: IRM Press.
85
10. ANEXOS
10.1. ANEXO A – VIEWS DO SISTEMA FONTE
10.1.1. VW_DWValouroVendas
CREATE VIEW [dbo].[VW_DWValouroVendas]
AS
SELECT Vendas.MANDT
, Vendas.BUKRS As Empresa
, CentVend.WERKS As CodCentro
, CentVend.VKGRP As CodVend
, Vendas.VTWEG As CodCanalD
, Rota.ROUTE As Rota
, Vendas.VBELN AS NumeroDoc
, Vendas.FKART AS TipDoc
, Vendas.FKDAT As DataFact
, Vendas.ERDAT As DataCriacao
, Vendas.KUNAG AS CodCli
, CentVend.MATNR as CodProd
, CentVend.CHARG as Lote
, CentVend.VRKME As UnidMed
, Case When CentVend.SHKZG<>''
then -1
else 1
End as Estorno
, FKART
, Case When Substring(Vendas.FKART,1,3)='ZNC' or Substring(Vendas.FKART,1,3)='ZND'Then
0
86
When CentVend.VRKME <> 'SC4707' and Substring(CentVend.PRODH,1,3)<>'COD' and
Substring(CentVend.PRODH,1,3)<>'506' and Substring(CentVend.PRODH,1,3)<>'005'
and CentVend.NTGEW <> 0 Then CentVend.NTGEW
else FKIMG
End as Quantidade -- Vendas, Multiplicar por estorno
, Case When Vendas.FKART='ZNC' or Vendas.FKART='ZND'Then CentVend.NETWR
else CentVend.WAVWR
End as Custo -- Valor Custo, Multiplicar por estorno
, Case When CentVend.NTGEW <> 0 and Substring(Vendas.FKART,1,3)='ZNC' then 0
When CentVend.NTGEW <> 0 then CentVend.NTGEW
When Substring(Vendas.FKART,1,3)='ZNC' or Substring(Vendas.FKART,1,3)='ZND' Then 0
else FKIMG
End as Peso -- Peso, Multiplicar por estorno
, CentVend.NETWR as Valor
FROM [PRD].[prd].VBRK as Vendas
Inner join [PRD].[prd].VBRP as CentVend On (CentVend.VBELN = Vendas.VBELN and CentVend.MANDT
= Vendas.MANDT)
LEFT JOIN PRD.prd.VBAP as Rota ON((CentVend.MANDT=Rota.MANDT) AND
(CentVend.AUBEL=Rota.VBELN) AND (CentVend.AUPOS = Rota.POSNR))
87
10.1.2. VW_DWValouroProdutos
CREATE VIEW [dbo].[VW_DWValouroProdutos]
AS SELECT DISTINCT [MVKE].MANDT, [MAKT].SPRAS,
[MVKE].MATNR, [MVKE].VKORG,
[MAKT].MAKTX,
[MARA].PRDHA
,Case
when LEN([PRDHA])>= 3 Then substring([PRDHA],1,3)
Else ''
End As Hier1
,Case
when LEN([PRDHA])>= 6 Then substring([PRDHA],1,6)
Else ''
End As Hier2
,Case
when LEN([PRDHA])>= 9 Then substring([PRDHA],1,9)
Else ''
End As Hier3
,Case
when LEN([PRDHA])>= 12 Then substring([PRDHA],1,12)
Else ''
End As Hier4
FROM prd.[MVKE]
INNER JOIN [PRD].[prd].[MAKT] ON ([PRD].[prd].[MVKE].MANDT =[PRD].[prd].[MAKT].MANDT) AND
([PRD].[prd].[MVKE].MATNR = [PRD].[prd].[MAKT].MATNR)
INNER JOIN [PRD].[prd].[MARA] ON ([PRD].[prd].[MVKE].MATNR = [PRD].[prd].[MARA].MATNR) AND
([PRD].[prd].[MVKE].MANDT = prd.[MARA].MANDT)
88
10.1.3. VW_DWValouroClientes
CREATE VIEW [dbo].[VW_DWValouroClientes]
AS SELECT Distinct Clientes.[KUNNR]
,Pais.[LAND1]
,LANDX
,NAME1
,STCEG
,STRAS
,PSTLZ
,ORT01
,TELF1
,KVGR1
,KVGR2
FROM [PRD].[prd].[KNVV] as ClieSegm
inner Join [PRD].[prd].KNA1 as Clientes on (ClieSegm.MANDT=Clientes.MANDT and
ClieSegm.KUNNR=Clientes.KUNNR)
LEFT JOIN PRD.prd.T005T as Pais on (Pais.MANDT='100' and Pais.SPRAS = 'P' and
Pais.LAND1=Clientes.LAND1)
Where ClieSegm.MANDT = '100' and VKORG='1080' and (VTWEG='80' or
VTWEG='90')
10.1.4. VW_DWValouroCompras
CREATE VIEW [dbo].[VW_DWValouroCompras]
AS
Select Compras.MANDT, Compras.BLDAT as DataFact, CabCompras.AEDAT as DataCriacao,
CabCompras.LIFNR as CodForn, Compras.BELNR as NrFact,
LinCompras.EBELN as NrPedido, LinCompras.AEDAT as DataPedido,
Case When Compras.SHKZG = 'H' then 'Crédito'
else 'Débito'
end as Tipo,
89
Compras.VGABE as VGABE2,
LinCompras.MATNR as CodProd, LinCompras.BUKRS as Empresa, LinCompras.WERKS as Centro,
LinCompras.LGORT as Deposito, Compras.BUDAT as DataLanc, /* Controlo DW */
Compras.CHARG as Lote, LinCompras.MEINS as UnidPedido,
Compras.MENGE as Qtd,
Compras.BPMNG as QtfFact,
Compras.BPMNG as Peso,
Case When Compras.SHKZG = 'H' then -1
else 1
end as Estorno,
LinCompras.BPRME as UnidFact,
Case When Compras.BPMNG =0 Then 0
Else Compras.WRBTR/Compras.BPMNG
End as PrecoCompra,
Compras.WRBTR as ValorLiq,
Compras.BLDAT as DataDoc
FROM (([PRD].[prd].EKPO as LinCompras INNER JOIN [PRD].[prd].EKBE as Compras ON
(LinCompras.EBELP = Compras.EBELP) AND (LinCompras.EBELN = Compras.EBELN) AND
(LinCompras.MANDT = Compras.MANDT))
INNER JOIN [PRD].[prd].EKKO as CabCompras ON (LinCompras.EBELN = CabCompras.EBELN) AND
(LinCompras.MANDT = CabCompras.MANDT))
90
10.2. ANEXO B – ETL
10.2.1. SA
Limpa último dia do DW
DECLARE @DiaEliminar VARCHAR(8)
DECLARE @DiaEliminarCompras VARCHAR(8)
if exists(select top 1 FK_DATACRIACAO FROM [DW_1800].[dbo].[FactVendas])
Set @DiaEliminar=(select top 1 Convert(varchar, dateadd("day",- 1,FK_DATACRIACAO),112) as
DiaEliminar FROM [DW_1800].[dbo].[FactVendas] ORDER BY FK_DATACRIACAO DESC)
Else Set @DiaEliminar=(select '20130101' as DiaEliminar)
if exists(select top 1 FK_DATACRIACAO FROM [DW_1800].[dbo].[FactCompras])
Set @DiaEliminarCompras=(select top 1 Convert(varchar, dateadd("day",-1,FK_DATACRIACAO),112) as
DiaEliminarCompras FROM [DW_1800].[dbo].[FactCompras] ORDER BY FK_DATACRIACAO DESC)
else
Set @DiaEliminarCompras=(select '20130101' as DiaEliminarCompras)
Delete
FROM [DW_1800].[dbo].[FactVendas]
Where FK_DataCriacao>=@DiaEliminar
Delete
FROM [DW_1800].[dbo].[FactCompras]
Where FK_DataCriacao>=@DiaEliminarCompras
Begin Date
if exists(select top 1 FK_DATACRIACAO FROM [DW_1800].[dbo].[FactVendas])
select top 1 Convert(varchar, dateadd("day",1,FK_DATACRIACAO),112) as BeginData FROM
[DW_1800].[dbo].[FactVendas] ORDER BY FK_DATACRIACAO DESC
else
select '20130101' as BeginData
Clean Tables SA
Delete From [dbo].[Produtos]
91
Delete From [dbo].[Clientes]
Delete From [dbo].T179T_Fam
Delete From [dbo].T001W_Centros
Delete From [dbo].TVGRT_Vendedores
Delete From [dbo].TVTWT_CanalDist
Delete From [dbo].TVV1T_Segm1
Delete From [dbo].TVV2T_Segm2
Delete From [dbo].TVROT_Rotas
Delete From [dbo].Vendas
Delete From [dbo].[Fornecedores]
Delete From [dbo].Compras
Load Vendas
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT MANDT, Empresa, CodCentro, CodVend, CodCanalD, NumeroDoc, TipDoc, DataFact,
DataCriacao, CodCli, CodProd, Rota, Estorno, Quantidade, Custo, Peso, Valor
FROM VW_DWValouroVendas
WHERE (MANDT = '100') AND (Empresa = '1080') AND (CodCli<>'0000208231')AND (DataCriacao >=
?) AND (DataCriacao <=?)
Load Compras
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT [MANDT]
,[DataFact]
,[DataCriacao]
,[CodForn]
,[NrFact]
,[NrPedido]
92
,[DataPedido]
,[Tipo]
,[VGABE2]
,[CodProd]
,[Empresa]
,[Centro]
,[Deposito]
,[DataLanc]
,[Lote]
,[UnidPedido]
,[Qtd]
,[QtfFact]
,[Peso]
,[Estorno]
,[UnidFact]
,[PrecoCompra]
,[ValorLiq]
,[DataDoc]
FROM [PRD].[dbo].[VW_DWValouroCompras]
WHERE (((MANDT)='100') AND ((Empresa)='1080') AND ((VGABE2)='2'))
AND (DataCriacao >= ?) AND (DataCriacao <=?)
93
10.2.2. DM
Insert Dim Null
if not exists(Select * From DimVendedores where VendIDCode='...')
Begin
Insert into DimVendedores
(VendIDCode,Vendedor,datainicio)
Values
('...','Sem Vend.Definido', CURRENT_TIMESTAMP )
End
if not exists(Select * From DimCentros where CentroIdCode='...')
Begin
Insert into DimCentros
(CentroIdCode,Centro,datainicio)
Values
('...','Sem Centro Definido',CURRENT_TIMESTAMP)
End
if not exists(Select * From DimClientes where ClienteIdCode='...')
Begin
Insert into DimClientes
( ClienteIdCode,Cliente,datainicio)
Values
('...','Sem Cliente Definido',CURRENT_TIMESTAMP)
End
if not exists(Select * From DimFornecedores where FornIdCode='...')
Begin
Insert into DimFornecedores
(FornIdCode,Fornecedor,datainicio)
Values
94
('...','Sem Forn.Definido',CURRENT_TIMESTAMP)
End
if not exists(Select * From DimProdutos where ProdIdCode='...')
Begin
Insert into DimProdutos
(ProdIdCode,Produto,datainicio)
Values
('...','Sem Prod.Definido',CURRENT_TIMESTAMP)
End
if not exists(Select * From DimRotas where RotaIdCode='...')
Begin
Insert into DimRotas
(RotaIdCode,Rota,datainicio)
Values
('...','Sem Rota Definida',CURRENT_TIMESTAMP)
End
UPDATE Hierarquias NULL
UPDATE DimProdutos
SET FAM1 ='000', DFAM1 ='Sem Família Definida'
WHERE FAM1=Null or FAM1='' or DFAM1='' or DFAM1=null
UPDATE DimProdutos
SET FAM2 ='000000', DFAM2 ='Sem Família Definida'
WHERE FAM2=Null or FAM2='' or DFAM2='' or DFAM2=null
UPDATE DimProdutos
SET FAM3 ='000000000', DFAM3 ='Sem Família Definida'
WHERE FAM3=Null or FAM3='' or DFAM3='' or DFAM3=null
UPDATE DimProdutos
95
SET FAM4 ='000000000000', DFAM4 ='Sem Família Definida'
WHERE FAM4=Null or FAM4='' or DFAM4='' or DFAM4=null
Update Nulls
UPDATE DimClientes
SET País ='Não Definido'
WHERE País is Null
UPDATE DimClientes
SET Localidade ='Não Definido'
WHERE Localidade is Null
UPDATE DimClientes
SET CodPostal ='0000-000'
WHERE CodPostal is Null
UPDATE DimClientes
SET Morada ='Não Definido'
WHERE Morada is Null
UPDATE DimClientes
SET NrContr ='Não Definido'
WHERE NrContr is Null
UPDATE DimClientes
SET Telefone ='Não Definido'
WHERE Telefone is Null
UPDATE DimClientes
SET TipoCliente1 ='Não Definido'
WHERE TipoCliente1 is Null
UPDATE DimClientes
SET TipoCliente2 ='Não Definido'
WHERE TipoCliente2 is Null
96
10.3. ANEXO C – VIEWS DO DW
10.3.1. VW_DWVendasPowerViewGeo
CREATE VIEW [dbo].[Vw_DWVendasPowerViewGeo]
as
SELECT [Ano]
,[Mes]
,[MesAno]
,[Semana]
,[DataFact]
,[Centro]
,[CanalDistr]
,[Cliente]
,[Pais]
,Vendas.[Localidade]
,[CodPostal]
,Vendas.[CP4]
,[TipoCliente1] as Tipo
,[Rota]
,[Vendedor]
,[NumeroFact]
,[Produto]
,[DFam1] as Hier1
,[DFam2] as Hier2
,[DFam3] as Hier3
,[DFam4] as Hier4
,[Custo]
,[Valor]
,[Peso]
97
,[Quantidade] as Qtd
,[Margem]
, case
When Concelho is null or len(CodPostal)=5 then Vendas.Localidade+ ',' + Pais
Else Concelho + ',' + Pais
End as Concelho
FROM [DW_1800].[dbo].[Vw_DWVendas] as Vendas
Left Join [DW_1800].[dbo].[VwDwMapsCodPostal] as CodPost on CodPost.[CP4]=Vendas.[CP4]
10.3.2. VW_DWVendasPowerViewGeo_1802
CREATE VIEW [dbo].[Vw_DWVendasPowerViewGeo_1802]
as
SELECT [Ano]
,[Mes]
,[MesAno]
,[Semana]
,[DataFact]
,[Centro]
,[CanalDistr]
,[Cliente]
,[Pais]
,Vendas.[Localidade]
,[CodPostal]
,Vendas.[CP4]
,[TipoCliente1] as Tipo
,[Rota]
,[Vendedor]
98
,[NumeroFact]
,[Produto]
,[DFam1] as Hier1
,[DFam2] as Hier2
,[DFam3] as Hier3
,[DFam4] as Hier4
,[Custo]
,[Valor]
,[Peso]
,[Quantidade] as Qtd
,[Margem]
, case
When Concelho is null or len(CodPostal)=5 then Vendas.Localidade+ ',' + Pais
Else Concelho + ',' + Pais
End as Concelho
FROM [DW_1800].[dbo].[Vw_DWVendas] as Vendas
Left Join [DW_1800].[dbo].[VwDwMapsCodPostal] as CodPost on CodPost.[CP4]=Vendas.[CP4]
Where Centro='Maia'
10.3.3. VW_DWComprasPowerViewGeo
CREATE VIEW [dbo].[Vw_DWComprasPowerViewGeo]
as
SELECT [Ano]
,[Mes]
,[MesAno]
99
,[Semana]
,[DataFact]
,[Centro]
,[Fornecedor]
,[Pais]
,Compras.[Localidade]
,[CodPostal]
,Compras.[CP4]
,[Produto]
,[DFam1] as Hier1
,[DFam2] as Hier2
,[DFam3] as Hier3
,[DFam4] as Hier4
,[Valor]
,[Peso]
,[Unidade]
,[Quantidade] as Qtd
, case
When Concelho is null or len(CodPostal)=5 then Compras.Localidade+ ',' + Pais
Else Concelho + ',' + Pais
End as Concelho
FROM [DW_1800].[dbo].[Vw_DWCompras] as Compras
Left Join [DW_1800].[dbo].[VwDwMapsCodPostal] as CodPost on CodPost.[CP4]=Compras.[CP4]
10.3.4. VW_DWVendas
CREATE VIEW [dbo].[Vw_DWVendas]
as
100
SELECT
DatePart("yyyy",FK_Data) as Ano,
DatePart("mm",FK_Data) As Mes,
DatePart("ISO_WEEK",FK_Data) as Semana,
FK_Data as DataFact,
DimCentros.Centro as Centro,
DimCentros.CentroIdCode as IdCentro,
DimCanalDist.[Canal Distribuição] as CanalDistr,
DimClientes.ClienteIdCode,
DimClientes.Cliente as Cliente,
DimClientes.País as Pais,
DimClientes.Localidade as Localidade,
DimClientes.CodPostal as CodPostal,
LEFT(DimClientes.CodPostal,4) as CP4,
DimClientes.TipoCliente1,
DimClientes.TipoCliente2,
DimRotas.Rota as Rota,
DimVendedores.Vendedor as Vendedor,
DimProdutos.ProdIDCode,
DimProdutos.Produto,
DimProdutos.Fam1,
DimProdutos.DFam1,
DimProdutos.Fam2,
DimProdutos.DFam2,
DimProdutos.Fam3,
DimProdutos.DFam3,
DimProdutos.Fam4,
DimProdutos.DFam4,
101
FactVendas.FK_NumeroFact as NumeroFact,
FactVendas.Custo,
FactVendas.Valor,
FactVendas.Peso,
FactVendas.Quantidade,
(FactVendas.Valor-FactVendas.Custo) as Margem,
IIF(FactVendas.Quantidade=0,0,FactVendas.Valor/FactVendas.Quantidade) as Preco
FROM FactVendas
LEFT JOIN DimCanalDist ON DimCanalDist.CanalIDCode = FactVendas.FK_CanalDist
LEFT JOIN DimCentros ON FactVendas.FK_Centro = DimCentros.CentroIdCode
LEFT JOIN DimClientes ON FactVendas.FK_Codclie = DimClientes.ClienteIdCode
LEFT JOIN DimProdutos ON FactVendas.FK_CodProd = DimProdutos.ProdIDCode
LEFT JOIN DimRotas ON FactVendas.FK_CodRot = DimRotas.RotaIdCode
LEFT JOIN DimVendedores ON FactVendas.FK_CodVend = DimVendedores.VendIDCode
102
10.4. ANEXO D – DIAGRAMA DO SISTEMA SAP
Figura 66 – Diagrama do Sistema SAP
