Business intelligence : aplicação prática na avicultura

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

2015

2015

Título:Business Intelligence

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

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

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

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

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

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

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

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

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

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

1

1. INTRODUÇÃO

1.1. E

G

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.

E

P

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. D

P

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. O

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. O

R

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. P

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;

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.

5

2. ENQUADRAMENTO DO NEGÓCIO

2.1. C

E

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. V

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. M

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. I

N

N

Inserida numa indústria competitiva e de alto volume de produção, o negócio da Avibom foca-se esfoca-sencialmente 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

7

2.6. N

F

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. I

R

P

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. B

H

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 batornou-ses 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. B

I

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. D

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.

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

HOLAP Agregações são feitas em

cache

Microsoft Analysis Services, SAS OLAP, Oracle’s Hyperion Essbase

DOLAP

Uma pequena cache é feita aquando a realização da

consulta.

BusinessObjects Web Intelligence, Oracle’s Hyperion Interactive

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. E

T

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. M

D

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. M

T

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. D

T

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.

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.

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;

29

5. ANÁLISE E ESTRUTURA DO DW

5.1. I

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. A

N

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