Self-Service Business Intelligence - Repositório Aberto · Mestrado Integrado em Engenharia Informática e Computação Orientador: Professor Gabriel David 21 de Julho de 2016. Self-Service

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Self-Service Business Intelligence

Eduardo Cardoso de Abreu

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Professor Gabriel David

21 de Julho de 2016

Self-Service Business Intelligence

Eduardo Cardoso de Abreu

Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo Júri:

Presidente: Professora Cristina RibeiroArguente: Professora Benedita Malheiro

Vogal: Professor Gabriel David

21 de Julho de 2016

Resumo

Os sistemas de gestão da produção nas empresas industriais produzem grandes quantidades dedados, mas de onde nem sempre é fácil retirar os indicadores necessários à tomada de decisão. Aresolução deste problema é o objetivo das ferramentas de processamento analítico (Business Intel-ligence), que extraem a informação relevante dos sistemas operacionais e produzem os relatóriospedidos pelos gestores, mas, muitas vezes, recorrendo ao auxílio de especialistas.

A necessidade de ter um departamento de TI como intermediário gera atrasos, reduzindo acapacidade de decisão da empresa, pelo que houve a necessidade de criar ferramentas de Self-Service Business Intelligence (SSBI). Estas permitem que colaboradores sem conhecimentos deTI consigam interrogar a base de dados, obtendo a informação que desejam de imediato, para alémde poderem explorar mais e melhor a informação armazenada.

A Critical Manufacturing (CMF), empresa onde esta dissertação foi realizada, é uma empresade desenvolvimento de software com soluções gerais de BI e SSBI para o seu sistema de gestão delinhas de produção (MES) cmNavigo. No entanto, há muitas empresas sem disponibilidade finan-ceira para adquirir estas soluções, pelos custos consideráveis no licenciamento e infraestrutura,mas que, mesmo assim, pretendem obter alguns dos seus benefícios.

O objetivo desta dissertação é integrar no cmNavigo uma ferramenta protótipo de SSBI, quepermita a não especialistas interrogar os dados e produzir dashboards através de uma interfacegráfica. Para isso, selecionam-se algumas ferramentas de SSBI e de construção e visualiza-ção de dashboards e avaliam-se as suas abordagens, funcionalidades, vantagens e desvantagens,determinando-se qual o melhor caminho a tomar para o projeto. Escolhida a ferramenta, são estu-dadas abordagens diferentes à implementação de um modelo de dados simplificado, que permitemao utilizador final a interação com os dados que considere mais relevantes.

i

ii

Abstract

The production management systems in industrial companies produce large amounts of data,but from which is not always easy to gather the indicators needed for decision-making. To solvethis problem is the goal of the on-line analytical processing tools (Business Intelligence), whichextract the relevant information from operating systems and produce the reports requested by themanagers, but, many times, using the aid of experts.

The need of an IT department as an intermediary causes delays, thereby reducing the com-pany’s decision-making ability, creating a need for tools of Self-Service Business Intelligence(SSBI). These allow employees without IT knowledge to query the database, gathering the neededinformation immediately, in addition to being able to better explore the stored information.

Critical Manufacturing (CMF), the company where this dissertation took place, is a softwaredevelopment company with BI and SSBI solutions for its Manufacturing Execution System (MES)cmNavigo. Although many companies wish to obtain some of its benefits, their financial capabilitydoes not allow them to purchase these solutions due to its considerable costs in licensing andinfrastructure.

The objective of this dissertation is to integrate in cmNavigo a SSBI tool prototype, allowingnon-experts to query the data and produce dashboards through a graphical interface. To do this,some SSBI and dashboard tools were evaluated for their approaches, features, advantages anddisadvantages, determining what is the best path to take for the project. After choosing the tool,different approaches are studied for the implementation of a simplified data model which willallow the end user to interact with the data considered most relevant.

iii

iv

“Perfection is achieved,not when there is nothing more to add,

but when there is nothing left to take away”

Antoine de Saint-Exupéry

v

vi

Conteúdo

Abreviaturas e Símbolos xiii

1 Introdução 11.1 Contexto/Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Estado da arte das soluções de BI 52.1 Microsoft Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Tableau Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Qlik Sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Conclusão do estudo das três soluções . . . . . . . . . . . . . . . . . . . . . . . 192.5 Klipfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Dundas BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Telerik Reporting e Report Server . . . . . . . . . . . . . . . . . . . . . . . . . 232.8 Sisense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.9 Syncfusion Dashboard Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 262.10 Conclusão do estudo das ferramentas . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Solução actual do cmNavigo 373.1 Arquitectura geral do cmNavigo . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2 Dashboards actuais do cmNavigo . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1 Resource Key Performance Indicators (RKPI) . . . . . . . . . . . . . . . 383.2.2 Process Key Performance Indicators (PKPI) . . . . . . . . . . . . . . . . 393.2.3 Overall Equipment Effectiveness (OEE) . . . . . . . . . . . . . . . . . . 39

4 Simplificação do modelo de dados 41

5 Teste da solução proposta 475.1 Replicação dos dashboards do cmNavigo . . . . . . . . . . . . . . . . . . . . . 475.2 Dashboards embebidos na nova interface do cmNavigo . . . . . . . . . . . . . . 52

6 Conclusões e Trabalho Futuro 57

Referências 59

A Vistas sobre o DW 61A.1 Vista Completa (Pré-junção) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.2 Vista Individual (Pós-junção) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

vii

CONTEÚDO

viii

Lista de Figuras

2.1 Magic Quadrant da Gartner, divulgado em Fevereiro de 2016. [Gara] . . . . . . . 62.2 Magic Quadrants da Gartner dos últimos quatro anos. [Gara] . . . . . . . . . . . 72.3 Interface do Power BI Desktop, com um dashboard de exemplo. . . . . . . . . . 82.4 Interface de edição da fonte de dados (data source) no Power BI Desktop. . . . . 92.5 Lista de checkboxes num filtro para colunas textuais. . . . . . . . . . . . . . . . 102.6 Exemplo de uma planta no Power BI. . . . . . . . . . . . . . . . . . . . . . . . 102.7 Interrogações feitas nos modos de importação e DirectQuery. . . . . . . . . . . . 112.8 Criação de parâmetros no Power BI . . . . . . . . . . . . . . . . . . . . . . . . 122.9 Selecção de parâmetros no Power BI . . . . . . . . . . . . . . . . . . . . . . . . 132.10 Interface de edição da fonte de dados (data source) no Tableau Desktop . . . . . 142.11 Exemplo de um dashboard no Tableau Desktop . . . . . . . . . . . . . . . . . . 152.12 Criação de parâmetros no Tableau . . . . . . . . . . . . . . . . . . . . . . . . . 162.13 O primeiro valor da lista de parâmetros "Accessories"está seleccionado por defeito. 162.14 Ao seleccionar "Components", o Tableau actualiza o gráfico. . . . . . . . . . . . 172.15 Interface de edição da fonte de dados (data source) do Qlik Sense. . . . . . . . . 182.16 Interface de criação de dashboards do Qlik Sense. . . . . . . . . . . . . . . . . . 182.17 Interrogações feitas pelo Dundas BI. . . . . . . . . . . . . . . . . . . . . . . . . 212.18 Dashboard do Dundas BI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.19 Exemplo de uma planta de uma fábrica no Dundas BI. . . . . . . . . . . . . . . 232.20 Interface do Sisense ElastiCube Manager. . . . . . . . . . . . . . . . . . . . . . 242.21 Dashboard de exemplo na interface Web do Sisense. . . . . . . . . . . . . . . . 252.22 Interface de edição da fonte de dados no Syncfusion Dashboard Designer. . . . . 262.23 O Syncfusion pede para escolher uma junção ao adicionar uma nova tabela. . . . 272.24 O Syncfusion permite criar uma interrogação personalizada. . . . . . . . . . . . 272.25 Interface de especificação dos dados de um widget. . . . . . . . . . . . . . . . . 282.26 Dashboard com um gráfico de barras e uma combobox. . . . . . . . . . . . . . . 292.27 O dashboard foi filtrado pela cor "Red". . . . . . . . . . . . . . . . . . . . . . . 292.28 Cor "Silver"adicionada ao dashboard. . . . . . . . . . . . . . . . . . . . . . . . 302.29 Dashboard com duas comboboxes e com os filtros sem nada seleccionado. . . . . 312.30 Segunda combobox afectada pelo filtro "Red". . . . . . . . . . . . . . . . . . . . 312.31 Seleccionada a categoria "Bikes"no dashboard. . . . . . . . . . . . . . . . . . . 322.32 Pelo SQL Server Profiler é possível ver o filtro por "Red"na interrogação. . . . . 332.33 Dashboard com as cores alteradas graças ao SDK. . . . . . . . . . . . . . . . . 342.34 Dashboard e interrogações duma filtragem por endereço. . . . . . . . . . . . . . 35

3.1 Os três tipos de bases de dados envolvidos no cmNavigo e como se relacionam. . 373.2 Dashboard RKPI no actual cmNavigo. . . . . . . . . . . . . . . . . . . . . . . . 383.3 Dashboard PKPI no actual cmNavigo. . . . . . . . . . . . . . . . . . . . . . . . 39

ix

LISTA DE FIGURAS

3.4 Dashboard OEE no actual cmNavigo. . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Modelo de dados dimensional da tabela de factos FactMaterial e suas dimensões. 42

5.1 Dashboard RKPI replicado no Syncfusion. . . . . . . . . . . . . . . . . . . . . 485.2 Dashboard PKPI replicado no Syncfusion. . . . . . . . . . . . . . . . . . . . . . 495.3 Dashboard OEE replicado no Syncfusion. . . . . . . . . . . . . . . . . . . . . . 495.4 Dashboard RKPI replicado no Power BI. . . . . . . . . . . . . . . . . . . . . . 505.5 Dashboard PKPI replicado no Power BI. . . . . . . . . . . . . . . . . . . . . . . 505.6 Dashboard OEE replicado no Power BI. . . . . . . . . . . . . . . . . . . . . . . 515.7 Dashboard RKPI replicado no Tableau. . . . . . . . . . . . . . . . . . . . . . . 515.8 Interface HTML5 do cmNavigo com o dashboard RKPI embebido. . . . . . . . 525.9 Interface HTML5 do cmNavigo com o dashboard PKPI embebido. . . . . . . . . 535.10 Interface HTML5 do cmNavigo com o dashboard OEE embebido. . . . . . . . . 535.11 Dashboard filtrado pelos três problemas mais frequentes. . . . . . . . . . . . . . 54

x

Lista de Tabelas

2.1 Tabela comparativa das ferramentas estudadas. . . . . . . . . . . . . . . . . . . 36

xi

LISTA DE TABELAS

xii

Abreviaturas e Símbolos

AVA AvailabilityBI Business IntelligenceCMF Critical ManufaturingDBMS Database Management SystemDW Data WarehouseETL Extract, Transform and LoadHTML HyperText Markup LanguageI&D Investigação e DesenvolvimentoIIS Internet Information ServicesKPI Key Performance IndicatorMDX MultiDimensional eXpressionsMES Manufacturing Execution SystemMSSQL Microsoft SQL ServerMTBF Mean Time Between FailuresMTTR Mean Time To RepairODS Operational Data StoreOEE Overall Equipment EffectivenessPER PerformancePKPI Process Key Performance IndicatorQUA QualityRKPI Resource Key Performance IndicatorRSS Rich Site SummarySDK Software Development KitSI Sistemas de InformaçãoSP Stored ProcedureSQL Structured Query LanguageSSBI Self-Service Business IntelligenceSSAS Microsoft SQL Server Analysis ServicesSSRS Microsoft SQL Server Reporting ServicesTI Tecnologias da InformaçãoUDF User-Defined FunctionURL Uniform Resource LocatorUTC Coordinated Universal TimeVizQL Visual Query Language

xiii

Capítulo 1

Introdução

1.1 Contexto/Enquadramento

Os sistemas de informação são um conceito bem conhecido dentro das empresas nos dias de

hoje. O contributo destes é inegável para com a integração de todas as fontes de dados numa em-

presa, tornando fácil e rápida a obtenção de informação útil por parte dos diferentes funcionários.

Hoje em dia é possível a um gestor ter acesso quase instantâneo aos dados completos da

sua empresa, mesmo que esta tenha departamentos em diferentes países ou continentes. Mas

a tecnologia da informação (TI), além de unir o mundo, também reduziu o tempo de resposta.

Uma linha de montagem pode gerar enormes quantidades de dados ao guardar para cada produto

produzido milhares de medidas, ao qual se multiplica o número de produtos produzidos. E mesmo

perante bases de dados com terabytes de informação, é possível extrair rapidamente indicadores

dessa produção tais como saber o número de unidades produzidas por unidade de tempo ou o

tempo médio de produção.

Ao permitir que as empresas tomem decisões com base em dados mais detalhados, mais cor-

retos e de forma mais célere, estas podem crescer e esses dados tornam-se indispensáveis para se

conseguirem diferenciar e obter mais lucro. Este processo foi apelidado de Business Intelligence

(BI).

No entanto, houve e continuam a existir barreiras no caminho, sendo uma das mais relevantes

a necessidade de especialistas de TI para implementarem consultas ou relatórios específicos a

pedido dos utilizadores, pois nem todos os que procuram tirar proveito da informação armazenada

na empresa têm conhecimento de como os dados da empresa estão estruturados ou de linguagens

como SQL. Esta necessidade de ter um departamento de TI como intermediário cria atrasos e

custos adicionais na obtenção de informação, reduzindo a capacidade de decisão da empresa.

Para responder a esta dificuldade surgiram ferramentas de Self-Service Business Intelligence

(SSBI), que permitem ao utilizador interrogar as suas fontes de dados de uma forma fácil e in-

tuitiva, sem necessidade de conhecer como a informação está estruturada e sem necessidade de

1

Introdução

conhecimentos técnicos. Isto pode ser feito permitindo-lhe, por exemplo, escolher o tipo de rela-

tório e filtros como os dados financeiros do último trimestre, e depois escolher apenas a informação

que lhe interessa como as receitas e as despesas. Os especialistas de TI continuam a ser neces-

sários para instalar as interrogações necessárias, mas deixam de ser necessários para as executar,

podendo os responsáveis da empresa obter informação útil de imediato, para além de terem a

possibilidade de explorarem mais e melhor a informação armazenada.

A Critical Manufacturing (CMF), onde esta dissertação foi realizada, é uma empresa de de-

senvolvimento de software focada na área da manufatura e tem no seu portfólio ferramentas de BI

e SSBI. Um dos seus principais produtos é o Manufacturing Execution System (MES) cmNavigo,

que é um sistema que faz a gestão de linhas de produção, como linhas de montagem, e através da

automatização, monitorização e controlo dos processos produtivos consegue aumentar a eficiên-

cia destas empresas. Mas os dados não servem apenas para o próprio sistema e para o nível de

operação, também podem ser valiosos para as tomadas de decisão dos gestores.

Com este sistema torna-se possível monitorizar todo o processo de fabrico permitindo saber,

por exemplo, quais os lotes de materiais utilizados na montagem de um determinado produto

defeituoso. Isto é importante pois permite identificar e chamar de volta à fábrica todos os produtos

com materiais defeituosos, evitando que coloquem em risco vidas, como nos casos de dispositivos

médicos e airbags. Outras utilidades são a deteção de problemas nas máquinas, faltas de material

ou necessidades de intervenção humana.

1.2 Motivação e Objetivos

As empresas têm consciência das vantagens que um sistema de informação lhes pode conferir,

como são os clientes da CMF com o cmNavigo, e também das vantagens que uma ferramenta

SSBI lhes pode conferir. No entanto, várias empresas que desejam este tipo de ferramentas não

têm disponibilidade financeira para as adquirir, não só pelos custos consideráveis no licenciamento

como também no investimento necessário em infraestrutura. Devido a isso, as soluções que o

mercado atualmente oferece não são geralmente opção para essas empresas de menor dimensão.

E ainda há um outro problema, que é a personalização que cada empresa tem no seu modelo

de dados. Isto significa que mesmo os clientes com um Data Warehouse (DW) só conseguem

interrogar a parte do modelo de dados que vem de base no cmNavigo, sendo obrigados a pedir

uma personalização ao DW ou o desenvolvimento de relatórios específicos, o que acresce ao custo

total do projeto.

No entanto, mesmo clientes de menor dimensão demonstram interesse por ferramentas do tipo

SSBI, pelo que se trata de um mercado ao qual a CMF quer chegar por via da implementação de

uma ferramenta simplificada que possa ser integrada com o cmNavigo, de forma a que empresas de

menores possibilidades também possam colher as vantagens do SSBI, aumentando a sua eficiência,

o que é do interesse delas e da CMF.

2

Introdução

Além disto, está-se a fazer a transição da interface em Microsoft Silverlight do cmNavigo para

uma nova em HyperText Markup Language versão 5 (HTML5). Os dashboards actualmente exis-

tentes na primeira interface deixarão de existir e é necessário encontrar alternativas em HTML5

que sejam fáceis de criar e embeber na nova interface.

O objetivo deste trabalho de dissertação é o de desenvolver uma ferramenta protótipo de SSBI,

que faça com que apenas os especialistas de TI necessitem de saber SQL e de como os dados estão

estruturados, sendo encarregues de disponibilizar ao utilizador final meios de inquirir fáceis de

usar. Essa ferramenta deve lidar com diferentes modelos de dados, devido às personalizações que

cada empresa pode pedir por cima do modelo de base do cmNavigo.

O utilizador final deve ser capaz de produzir dashboards através de uma interface gráfica que

seja fácil e intuitiva de usar e integrada no cmNavigo. Essa produção é composta pela escolha dos

widgets e da respectiva fonte de dados.

Como tal, foram definidos os seguintes objetivos:

• Estudar as diferentes ferramentas de SSBI e de construção de dashboards existentes no

mercado, procurando perceber quais as suas funcionalidades, vantagens e desvantagens,

como abordam os diferentes desafios na implementação e se estas abordagens podem ou

não ser aplicadas neste trabalho;

• Inquirir sobre as necessidades dos utilizadores que podem ser satisfeitas por uma ferramenta

de SSBI, especialmente junto daqueles que trabalham com o MES cmNavigo, de forma a

que o trabalho desenvolvido consiga ser bem recebido e usado nos seus sistemas;

• Estudar as diferentes abordagens à implementação de um modelo de dados simplificado,

permitindo que o utilizador escolha de entre os dados que considera mais relevantes;

• Conceber a solução, com base nos requisitos do cmNavigo, nas ferramentas a utilizar, nos

diferentes modelos de dados existentes e nas necessidades do front-end, de forma a se poder

antecipar os desafios que existirão e procurar uma solução;

• Implementar o trabalho de uma forma iterativa, de forma a que a CMF e o orientador possam

acompanhar o desenvolvimento da ferramenta e dar o seu feedback atempadamente;

• Testar a ferramenta desenvolvida com o cmNavigo, usando dados reais ou semelhantes, de

forma a poder avaliar a correção, qualidade, eficiência e correspondência com as expectati-

vas;

• Testar a ferramenta junto de alguns utilizadores finais, pessoas interessadas numa ferra-

menta de SSBI, mas sem conhecimentos técnicos e de como os dados estão estruturados no

sistema, de forma a avaliar a forma como a ferramenta desenvolvida é usada e a facilidade

de uso, além de recolher sugestões.

3

Introdução

4

Capítulo 2

Estado da arte das soluções de BI

O objectivo desta fase do trabalho é encontrar uma ferramenta que possibilite a um utilizador

sem grandes conhecimentos técnicos criar os seus próprios dashboards, escolhendo os widgets e

as fontes de dados.

Não sendo possível estudar todas as ferramentas que existem actualmente no mercado, procurou-

se quais seriam as melhores ferramentas de BI. Esse é um trabalho que a Gartner, Inc. realiza

anualmente.

A Gartner é uma empresa especializada em análise e consultoria na área de apoio à decisão,

com análises a centenas de áreas distintas [Garc]. As análises que permitem ter uma rápida visão

geral da área são os Magic Quadrants [Garb], que apresentam as diferentes empresas da área num

gráfico bidimensional, com um eixo a representar a capacidade da empresa conseguir executar

as necessidade de hoje, e outro a representar o quão bem qualificadas e preparadas estão para

responder às necessidades do futuro. As empresas que conseguem estar bem posicionadas em

ambas as valências são apelidadas de líderes na área.

No relatório que lançou em 2016 sobre as soluções que existem na área de Business Intel-

ligence, a Gartner considerou a Tableau, a Microsoft e a Qlik como empresas líderes do mer-

cado [Gara], tal como se pode ver na Figura 2.1. Desde 2013 - ano em que o Tableau entrou pela

primeira vez na categoria dos líderes - que estas três empresas têm sido apresentadas como líderes.

No arranque deste trabalho de dissertação, a análise mais recente, referente a Fevereiro de

2015, colocava o Tableau destacado, como o grande líder da área na capacidade de executar as

necessidades de hoje. Mas durante a realização deste estado da arte, foi lançada a análise mais

recente, de Fevereiro de 2016, onde já não aparece com o mesmo destaque, e com a Microsoft

destacada na visão que tem para o mercado de BI.

O Tableau tem-se consolidado nos últimos anos como a ferramenta líder na área de Business

Intelligence, como indicado nos respetivos quadrantes. A Gartner afirma que os pontos fortes do

Tableau são a capacidade de execução, a versatilidade de instalação e uso, as diversas ofertas para

aprendizagem e a grande quantidade de conectores para diferentes fontes de dados. Quanto aos

5


Figura 2.1: Magic Quadrant da Gartner, divulgado em Fevereiro de 2016. [Gara]

pontos negativos, foram apontados o preço elevado, alguma incapacidade de lidar com necessida-

des complexas e uma fraca capacidade de integrar os dados provenientes de múltiplas fontes de

dados. Esta forte opinião positiva, assim como as boas análises que possui, quer do jornalismo

tecnológico, quer de clientes, levou à sua escolha para ser estudada neste trabalho.

O Power BI da Microsoft é uma ferramenta recente e que tem estado a agitar o mercado de BI.

Em Fevereiro de 2016, a Gartner colocou a Microsoft como a empresa com a maior visão futura da

área pela forma como consegue oferecer um dos preços mais reduzidos, combinado com muitas

funcionalidades e novidades a saírem todas as semanas. A Microsoft, através dos eventos em

que participa, tem-se mostrado bastante determinada em elevar a fasquia na oferta de BI através

não só do elevado investimento e ritmo de evolução do Power BI, mas também pela aquisição da

Datazen, especialista em BI para dispositivos móveis, da colaboração com a Pyramid Analytics e

6


Figura 2.2: Magic Quadrants da Gartner dos últimos quatro anos. [Gara]

das novidades reveladas em redor do SQL Server Reporting Services 2016. Os pontos negativos

da ferramenta são apontados como a juventude do Power BI, a falta de capacidades de análise

avançadas e as frequentes alterações de preços e requisitos. Devido aos preços competitivos e

boas opiniões, esta ferramenta também foi incluída na análise.

Por fim, devido à boa opinião da Gartner sobre a Qlik ao longo dos últimos anos, esta empresa

entrou no estudo através da ferramenta QlikSense, que é a mais orientada para SSBI. A Gartner

salienta as soluções da Qlik pela facilidade de utilização e análises complexas que é capaz de fazer.

Também possui várias fontes de dados e consegue ligá-las com maior facilidade que a concorrên-

cia. Nos pontos negativos estão os preços calculados de forma complexa, preços elevados, suporte

abaixo da média e a falta de aposta nos dispositivos móveis e na Cloud.

7


O estudo começou pelo Power BI visto que, de entre as três ferramentas, é consideravelmente

mais barata.

2.1 Microsoft Power BI

O Power BI foi apresentado pela Microsoft em Setembro de 2014, confirmando uma crescente

aposta da empresa na área de Business Intelligence, depois de fortalecer o Excel com o Power

Map, Power Pivot, Power Query e Power View.

A ferramenta foi disponibilizada inicialmente somente para empresas, tendo sido lançada pu-

blicamente no dia 24 de Julho de 2015, contando nessa altura com mais de 500 mil utilizadores de

45 mil empresas [Corc].

A CMF utiliza toda a stack de soluções da Microsoft, incluindo o Microsoft SQL Server

(MSSQL), pelo que o primeiro requisito para todas as ferramentas que viessem a ser estudadas

era a capacidade de recolher a informação de tabelas, vistas, User-Defined Functions (UDF) e

Stored Procedures (SP) destes sistemas.

Para realizar os estudos foi necessário ter uma base de dados com uma estrutura e dados

interessantes para testar, mas sem ser computacionalmente exigente. Para o estudo inicial das

ferramentas optou-se por instalar um servidor de SQL Server localmente, com a base de dados

AdventureWorks. A utilização dos servidores da CMF e respectivos dados ficou para uma fase de

análise mais avançada.

Figura 2.3: Interface do Power BI Desktop, com um dashboard de exemplo.

O Power BI mostrou-se uma ferramenta fácil de utilizar, tal como era pretendido.

8


O carregamento dos dados da fonte de dados é simples, através de um wizard que pergunta o

nome do servidor, os dados de autenticação, o nome da base de dados, quais as tabelas, vistas ou

funções a carregar e qual o modo de importação a utilizar. Existem dois modos de importação, que

diferem na influência que têm na frescura dos dados recolhidos e na máquina onde faz a filtragem.

A primeira opção é um simples importar de todos os objectos (Tabelas, Vistas, etc.), fazendo as

operações localmente, como junções e filtragens. A outra opção é o DirectQuery, que interroga a

base de dados sempre que se alteram as relações ou um filtro no dashboard.

Caso se importem tabelas que tenham relações de chaves secundárias entre elas, o Power BI

automaticamente cria as relações, permitindo agregações.

No caso das relações criarem ciclos, o Power BI não estabelece as relações suficientes para o

impedir. É possível gerir estas relações e o Power BI nunca permite que se active uma relação que

crie um ciclo.

Figura 2.4: Interface de edição da fonte de dados (data source) no Power BI Desktop.

Depois de ter o modelo de dados pretendido, avançou-se para a criação de um dashboard que

permitisse explorar a quantidade e relevância dos widgets do Power BI e o detalhe com que é pos-

sível editá-los tanto a nível de filtros, como a nível de design. Em todos estes pontos, a ferramenta

mostrou-se muito completa, com todos os widgets que se podiam esperar de um dashboard. E a

edição do design vai longe o suficiente para, por exemplo, permitir escolher se se quer um título

para o widget ou não, e qual o texto, tamanho e cor deste ou quais as cores a utilizar nesse widget.

No que toca aos filtros, o Power BI permite filtrar quer ao nível visual do widget, quer da página,

quer de todo o relatório, e permite-o por qualquer uma das colunas importadas, sem recorrer a

SQL.

9


Figura 2.5: Lista de checkboxes num filtro para colunas textuais.

De seguida, explorou-se a ferramenta para conhecer se é possível criar e adicionar widgets

personalizados ao Power BI. O supervisor referiu alguns widgets, que não constavam no Power BI,

que seriam interessantes. Um deles era ser possível ter a planta da fábrica do cliente, destacando

cada máquina ou área de forma dependente das métricas aplicadas, como o Uptime/Downtime, o

Mean Time Between Failures (MTBF) ou o Mean Time To Repair (MTTR).

Foi encontrado um widget externo desenvolvido pela SQLBI chamado Synoptic Panel que

permitiria realizar esse widget. A simplicidade de criação e uso das plantas impressionou, visto

que basta ir à página http://synoptic.design/, importar uma imagem, desenhar as áreas que se pre-

tende e dar-lhes o nome ao qual estarão associadas no dashboard, por exemplo o ID da máquina.

Depois, é só seleccionar o widget Synoptic Panel e escolher a dimensão, como o ID da máquina,

e a medida, como o MTBF. A Figura 2.6 mostra uma planta de exemplo, com valores associados

a cada divisão e coloridas de acordo com intervalos de valores especificados.

Figura 2.6: Exemplo de uma planta no Power BI.

Para além disso, foi explorada a possibilidade de criar os próprios widgets, algo que a Micro-

soft permite que seja feito no seu Power BI online, recorrendo à linguagem TypeScript [Cora].

10


De seguida, avançou-se para o estudo da forma como o Power BI inquire e recolhe os dados

do SQL Server, nomeadamente, se utiliza os filtros escolhidos no dashboard. Isto é importante

pois as bases de dados do cmNavigo possuem grandes quantidade de dados, podendo tornar a

interrogação excessivamente demorada e pesada. Por este motivo era importante saber se o Power

BI, na interrogação que faz à base de dados, utiliza os filtros definidos no dashboard, importando

com um tamanho gerível.

Recorrendo ao SQL Server Profiler foi possível ver que o Power BI diverge neste ponto entre

os dois modos de importação, com e sem o DirectQuery. No lado esquerdo da Figura 2.7 estão as

interrogações feitas no modo de importação, pedindo todos os valores. No lado direito, estão as

interrogações feitas no modo DirectQuery quando se filtra por "Accessories", "Bikes"e "Clothing".

No modo de importação não há filtros, pois são feitos na própria máquina, ao contrário do Direct-

Query.

Figura 2.7: Interrogações feitas nos modos de importação e DirectQuery.

Quando o modo escolhido é o de importação, o Power BI inquire pedindo individualmente

todos os objectos no modelo quando estes são escolhidos. Quando as relações ou filtros são altera-

dos, não ocorrem interrogações ao SQL Server, dando a entender que são feitos localmente. Esta

solução pode ser vantajosa quando há memória suficiente para os dados e não se quer realizar pro-

cessamento no servidor, tendo a desvantagem dos dados não serem frescos aquando da abertura do

11


dashboard, sendo necessário pedir uma actualização manual dos dados para importar novamente

os objectos, além de poder ser impraticável o uso sobre objectos de grandes dimensões.

Quando o modo escolhido é o DirectQuery, e sempre que os filtros são alterados, o Power BI

interroga a base de dados para obter um novo dataset. Para o fazer recorre apenas a uma interro-

gação, com um JOIN entre todas as tabelas e um WHERE no final com o filtro definido, tal como

mostra o SQL Server Profiler na Figura 2.7. No entanto, caso a interrogação já tenha sido feita du-

rante a sessão, não é feita qualquer interrogação, o que significa que recorre a um armazenamento

temporário de todas as interrogações feitas durante a sessão do dashboard. Portanto, o Power BI

deixa para o SQL Server todas as operações sobre os dados, evitando a importação de grandes

volumes de dados.

De seguida, tratou-se de estudar se era possível criar argumentos, utilizáveis em interrogações,

que pudessem ser manipulados pelo dashboard. O objetivo era saber se era possível, por exemplo,

manipular os argumentos de uma User-defined Function ou Stored Procedure através do dashbo-

ard. Na altura em que a ferramenta foi estudada, não foi encontrado como o fazer, mas numa

actualização a 28 de Abril foi incluída uma funcionalidade que satisfaz este requisito [Cord].

Através do menu de edição das interrogações, é agora possível criar um Parâmetro, definir o

seu tipo, valores e valor por defeito, e utilizá-lo, por exemplo, numa função, tal como exemplifi-

cado na Figura 2.8.

Figura 2.8: Criação de parâmetros no Power BI

Na Figura 2.8 é possível ver a função dbo_ufnGetInventory com Category como argu-

mento, que é o parâmetro criado. O parâmetro Category é do tipo texto e possui um lista de valores

12


introduzidos manualmente. Outra opção seria permitir que o utilizador escrevesse o texto a passar

como argumento.

Voltando ao dashboard, é possível alterar o valor do parâmetro através do botão Edit Queries

e depois Edit Parameters. No menu aparecem os parâmetros existentes e respectivas opções. Ao

premir OK o Power BI automaticamente volta a carregar o dataset utilizando o novo valor como

argumento da função. Este menu é mostrado na Figura 2.9.

Figura 2.9: Selecção de parâmetros no Power BI

Por fim, no que toca à publicação dos dashboards, de momento, apenas é possível publicá-los

para a Cloud do Power BI. Assim, para visualizar um dashboard sem a necessidade de ter o Power

BI instalado ou através de dispositivos móveis, este tem de estar alojado na Cloud disponibilizada

pela Microsoft. E este é, para a Critical Manufacturing, um factor eliminatório. A confidenciali-

dade da informação presente nos sistemas não permite que sejam publicados na Cloud porque iria

contra as políticas de segurança dos clientes. Este é o maior ponto negativo do Power BI e que

impediu que fosse a ferramenta escolhida.

A Microsoft colocou no seu roadmap [Corb] e anunciou numa conferência [Core] que no

futuro será possível publicar os dashboards no SQL Server Reporting Services (SSRS), mas não

forneceu quaisquer datas, pelo que se optou por descartar esta ferramenta. O trabalho deverá ter

em conta uma possível migração para o Power BI, se no futuro se justificar.

13


2.2 Tableau Software

Entre 1999 e 2002, o professor Pat Hanrahan da Universidade de Stanford e um dos seus alu-

nos, Chris Stolte, procuraram comercializar o seu trabalho, que consistia numa nova linguagem

num sistema que a utilizava. A Visual Query Language (VizQL) combinava SQL com uma lin-

guagem descritiva para renderização gráfica [Pat06] e era o núcleo do Polaris, uma interface de

visualização de dados armazenados [PCD]. Em 2003 é então fundada a Tableau Software, que se

dedica a desenvolver produtos na área de BI.

Recentemente, no anúncio dos resultados fiscais referentes a 2015, reveleram receitas de 654

milhões de dólares, com 424 a referirem-se exclusivamente a licenças vendidas aos mais de 39 mil

clientes [Sofb] [Sofa]. Estes fortes resultados, somados às análises da Gartner, colocam-na como

uma ferramenta líder no mercado de BI, pelo que faz todo o sentido explorar o Tableau e perceber

se pode ser a solução.

Figura 2.10: Interface de edição da fonte de dados (data source) no Tableau Desktop

O Tableau Desktop, ferramenta para a criação de dashboards, tem uma forma muito seme-

lhante à do Power BI no que toca à escolha de uma fonte de dados SQL Server, pedindo o nome

do servidor, autenticação e nome da base de dados. As escolhas seguintes são distintas pois o

Tableau não possui a mesma capacidade de automatizar as relações como o Power BI. Isto porque

vê o primeiro objecto (Tabela, Vista ou Função) como uma espécie de tabela de factos, procurando

ligar todos os objectos importados a seguir ao primeiro objecto, como se fossem as suas dimen-

sões. Cabe ao utilizador corrigir as associações erradas. Na Figura 2.10 é possível ver as tabelas

relacionadas entre si.

14


No que toca à criação dos widgets, há grandes diferenças. O Tableau possui uma grande

riqueza, não tanto na diversidade de widgets, que é muito boa, mas pela personalização que lhes

pode conferir, juntando a isso uma interface intuitiva e simples de utilizar, o que confere uma boa

experiência ao utilizador.

Em relação à publicação de dados provenientes do SQL Server, o Tableau Desktop possui dois

destinos distintos:

• Uma solução na Cloud, apelidada de Tableau Online, que não é solução pelo mesmo motivo

da Cloud do Power BI, as políticas de segurança não permitirem que os dados saiam da

intranet;

• E uma solução on-premises, apelidada de Tableau Server. Cabe ao Tableau Desktop pu-

blicar para um servidor com este software, que por sua vez o disponibiliza através de uma

página Web. Desta forma, apenas quem necessita de criar os dashboards é que deve ter o

Tableau Desktop instalado no seu computador, podendo os colegas aceder através da Web,

sem qualquer outro requisito para além do browser.

Figura 2.11: Exemplo de um dashboard no Tableau Desktop

Mostra-se então possível publicar on-premises, cumprindo este requisito fundamental.

Durante este estudo analisou-se também se era possível criar interrogações personalizadas e

utilizar argumentos nessa interrogação que pudessem ser manipulados pelo dashboard. O objetivo

era saber se era possível, por exemplo, manipular os argumentos de uma UDF ou SP através do

dashboard.

15


O Tableau permite criar de forma bastante simples interrogações personalizadas, bastando

para isso ir ao editor da fonte de dados, clicar em New Custom SQL e introduzi-la. Para introduzir

um novo parâmetro, basta escolher a opção “Insert Parameter”, depois “Create a new Parameter”,

definir o seu nome, tipo e valor por defeito e fazer Ok.

Figura 2.12: Criação de parâmetros no Tableau

Depois de criado o parâmetro, na lista de medidas e dimensões do dashboard, surge o nome

desse parâmetro personalizado, sendo possível arrastá-lo e utilizá-lo no dashboard e, inclusiva-

mente, alterá-lo através dos filtros. Isto significa que, por exemplo, seria possível obter os dados

de uptime, MTBF e MTTR para determinados equipamentos ou intervalo de tempo.

Figura 2.13: O primeiro valor da lista de parâmetros "Accessories"está seleccionado por defeito.

16


Figura 2.14: Ao seleccionar "Components", o Tableau actualiza o gráfico.

Um dos pormenores importantes do Tableau era saber qual o seu preço. Como é pretendida

uma solução on-premises, o Tableau Server é a única opção. Este tem, no pacote mais barato de

10 utilizadores, um preço de 10 mil dólares no primeiro ano e 2 mil e quinhentos por ano nos

restantes. Foi considerado um preço excessivo, principalmente para uma solução que se queria de

baixo custo e que chegasse a empresas de menores orçamentos, tendo o Tableau sido descartado.

2.3 Qlik Sense

A Qlik foi fundada na Suécia em 1993, como uma empresa de software na área de BI. Três

anos após, foi lançado o QlikView, ferramenta de exploração e análise de dados que até hoje tem

sido aperfeiçoada e é tida como uma das líderes na área pela Gartner. Mas embora a ferramenta

seja poderosa, não é fácil de aprender a utilizar e requer algum nível de conhecimentos tecnoló-

gicos. Posteriormente, surgiu o QlikSense, uma ferramenta de SSBI fácil e intuitiva para criação

de dashboards. Não tem a complexidade de análise e exploração do QlikView, mas tem a sim-

plicidade de criação de visualizações, permitindo a exploração dos dados e posterior criação de

dashboards sem grandes conhecimentos iniciais.

O QlikSense mostrou-se simples de utilizar. O carregamento dos dados é feito tal e qual

os concorrentes Power BI e Tableau, que apenas diferem nas junções. Esta ferramenta não cria

relações entre os objectos automaticamente como o Power BI, mas é capaz de sugeri-las, dizendo

inclusivamente qual o seu grau de certeza quanto à sugestão.

Trabalha com o SQL Server, um requisito fundamental, e produz dashboards facilmente.

A Qlik tem soluções Cloud, já rejeitadas devido às políticas de segurança das empresas da área

da manufactura, pelo que a única solução para empresas é a Qlik Sense Enterprise, que tem um

preço baseado em “tokens”. Um token pode ser utilizado para conceder uma licença ilimitada a um

utilizador ou para conceder 10 acessos de 1 hora a utilizadores por mês. A empresa disponibiliza

um PDF [AB] a explicar o funcionamento dos tokens, o que também deixa perceber que eles

próprios reconhecem a complexidade do cálculo dos preços.

17


Figura 2.15: Interface de edição da fonte de dados (data source) do Qlik Sense.

Figura 2.16: Interface de criação de dashboards do Qlik Sense.

18


Cada token custa actualmente mil e quinhentos dólares no momento da aquisição e depois 300

dólares (20%) por ano. Comparando com o Tableau, que para o preço base com 10 utilizadores

custa 10 mil dólares no primeiro ano e 2 mil e quinhentos por ano nos seguintes, o Qlik Sense

Enterprise para os mesmos 10 utilizadores custa:

• 15 mil dólares no primeiro ano e 3 mil por ano nos seguintes no caso de terem todos acesso

ilimitado;

• 7 mil e quinhentos dólares no primeiro ano e mil e quinhentos dólares por ano nos seguintes

no caso que a Qlik coloca como o mais comum, que é o de cada utilizador fazer 4 acessos

mensais, a que se adiciona mais 20% de acessos de folga, resultando na necessidade de 5

tokens.

Não sendo significativamente mais barato que o Tableau, acrescido à complexidade no cálculo

do preço, o estudo do Qlik Sense ficou-se por aqui.

2.4 Conclusão do estudo das três soluções

Estudaram-se as três ferramentas líderes da área de BI segundo a Gartner, sem que nenhuma

tivesse satisfeito as necessidades de publicação ou de preço acessível. Por esse motivo a pro-

cura alargou-se a outras ferramentas potencialmente interessantes nos quadrantes da Gartner, mas

também a ferramentas de simples criação de dashboards, sem as funcionalidades de exploração,

análise ou previsão das de BI, mas que permitissem ainda assim a criação de dashboards a partir

de dados retirados do SQL Server.

Dos quadrantes da Gartner, explorou-se, para além das três líderes, o Sisense. As restantes

foram excluídas:

• Pelo seu preço excessivo, naquelas em que é possível sabê-lo facilmente, como a SAP Bu-

siness Objects, SAS ou Information Builders;

• Pela falta de acesso à ferramenta, inclusivamente para experimentar, como no caso da Birst,

que apenas disponibiliza demonstrações da ferramenta aos interessados.

Para além do Sisense, adicionou-se à lista de ferramentas a explorar, o Klipfolio e o Dundas

BI, por serem duas ferramentas com vários prémios e boas opiniões, além de anunciarem for-

tes clientes internacionais, como a Intel, Google, Adobe, IKEA, Deloitte, Philips ou BMW, no

primeiro caso, e a Coca-Cola, Siemens, HP, Microsoft ou a farmacêutica Bayer, no segundo caso.

Por serem ferramentas de criação de dashboards conhecidas de colegas da CMF, também

foram adicionadas à lista as soluções da Telerik e da Syncfusion.

O estudo das três ferramentas anteriores permitiu ganhar algum conhecimento sobre as fun-

cionalidades das ferramentas na área de BI, o método de como as estudar e também uma melhor

definição dos objectivos do estudo e requisitos que as ferramentas devem preencher. Por este

19


motivo foi desenvolvida uma lista de requisitos, de forma a fazer uma análise sistemática às ferra-

mentas seguintes. Esta lista, mais tarde, serviu para criar uma tabela de comparação de todas as

ferramentas estudadas.

A lista de requisitos inclui:

• Se é possível importar dados on-premises do SQL Server. Requisito eliminatório.A ferramenta deve ser capaz de recolher dados de um servidor local de SQL Server visto ser

a DBMS do cmNavigo e os dados não deverem sair da intranet.

• Como é feita a interrogação e carregamento dos dados.Se os dados são importados e interrogados localmente ou se são feitas interrogações di-

rectamente à fonte de dados. A importação pode colocar problemas de descarregamento e

operação local de datasets de grandes dimensões, além da frescura dos dados. No entanto,

uma boa capacidade de filtragem e actualização dos dados pode ultrapassar este problema.

• Intuitividade, simplicidade e funcionalidade dos dashboards.A ferramenta final deve ser intuitiva e fácil de usar de forma a que utilizadores sem co-

nhecimentos técnicos consigam criar dashboards, devendo ser apontadas dificuldades de

utilização pertinentes.

• Se é possível publicar os dashboards num servidor on-premises. Requisito eliminatório.Devido às políticas de segurança das empresas de manufactura, que procuram proteger pa-

tentes, processos e dados de fabrico, os dados nunca devem sair da rede da empresa. As

soluções de BI deverão ser on-premises, descartando soluções Cloud, como acontece actu-

almente com o Power BI.

• Se tem uma versão móvel e se é aplicação ou uma página responsiva.O crescimento do mercado e desempenho dos dispositivos móveis tornou possível aceder a

várias aplicações que antes eram exclusivas dos computadores pessoais. Hoje os utilizadores

querem ter acesso à informação no smartphone ou tablet em qualquer lado. As ferramentas

de BI oferecem soluções bastante díspares nesta matéria. Umas oferecem aplicações nativas

como o Power BI ou o Tableau, outras oferecem interfaces Web responsivas e outras ainda

não apresentam qualquer solução móvel.

• Se permite a criação e adição de widgets (visualizações) personalizadosEmbora não seja fundamental que o dashboard possua uma planta de uma fábrica, como foi

estudado com o Power BI, este é um factor diferenciador. E, para além deste caso, poderão

existir outros que a CMF pretenda cobrir, pelo que convém perceber se a ferramenta em

causa permite ou não a criação e adição de novos widgets.

• Como são calculados os preços e quais os preçosCom duas ferramentas estudadas excluídas e outras excluídas da selecção devido ao preço

excessivo, é importante saber qual o preço das ferramentas a estudar, inclusivamente nos

casos onde este não é divulgado publicamente e é necessário contactar a equipa de vendas.

20


2.5 Klipfolio

Fundada em 2001 no Canadá, a Klipfolio Inc. é uma uma empresa de software cujo foco se

concentrou na área de BI em 2007 quando se aperceberam do sucesso do seu dashboard, inicial-

mente desenvolvido para agregadores de notícias e RSS.

O Klipfolio possui um criador de dashboards na Cloud, tal como o Power BI, só que sem

qualquer tipo de solução de desenvolvimento on-premises. Ou seja, os dados seriam trabalhados

fora da rede da empresa. Embora rapidamente descartado, o pormenor da criação dos dashboards

necessitar de ser igualmente on-premises foi adicionado à lista de requisitos.

Foi possível verificar que o Klipfolio importa dados de um servidor SQL Server e possui uma

página responsiva para lidar com dispositivos móveis. Recolher os preços só faria sentido numa

comparação com as ofertas na Cloud do Power BI, Tableau e QlikSense, mas não teria relevância

para o objectivo deste estudo por não serem on-premises.

2.6 Dundas BI

A Dundas Software foi fundada em 1992 no Canadá como uma empresa de desenvolvimento

de soluções para visualização de dados, nomeadamente dashboards. O seu sucesso levou à aqui-

sição de algumas das suas soluções pela Microsoft em 2007 para integrar o SSRS a partir do SQL

Server 2008, nomeadamente o Dundas Chart, Dundas Map, Dundas Gauge e Dundas Calendar.

Convém frisar que a empresa em si não foi comprada, mas sim as soluções referidas.

Figura 2.17: Interrogações feitas pelo Dundas BI.

O Dundas BI é uma solução on-premises, tal como exigido pelos requisitos, mas ao contrário

das três ferramentas líderes estudadas anteriormente, esta tem uma interface totalmente baseada

na Web. Ou seja, o servidor Dundas BI disponibiliza um serviço Web capaz de funcionar numa

intranet, onde é possível criar os dashboards, para além de ser onde ficam publicados e de onde

podem ser visualizados.

O Dundas BI importa de SQL Server, preenchendo esse requisito fundamental. No que toca

à forma como interroga os dados, interroga a base de dados de forma simples, com as junções

21


necessárias, conforme demonstrado pelo SQL Server Profiler na Figura 2.17, onde é possível ver

uma interrogação para cada dataset utilizado no dashboard.

O servidor recorre a uma cache interna [DDV] para armazenamento das interrogações que

foram feitas, de forma a aumentar o desempenho dos dashboards e diminuir a carga na base de

dados, algo que foi possível comprovar visto que as interrogações foram feitas apenas uma vez,

no primeiro carregamento do dashboard. O recarregamento da página do dashboard ou o reiniciar

limpo do navegador não obrigam o servidor a actualizar o dataset interrogando novamente a base

de dados. Apenas foi possível forçar esse refrescamento dos datasets com um reiniciar do servidor

através do Internet Information Services (IIS) Manager.

Figura 2.18: Dashboard do Dundas BI.

Toda a interface Web do Dundas BI é responsiva, o que a torna mais fácil de utilizar em

dispositivos móveis. No entanto, os dashboards não se adaptam às dimensões dos ecrãs, pelo

que devem ser criados propositadamente. O maior exemplo da falta de adaptação é não conseguir

visualizar adequadamente um dashboard feito para um ecrã na horizontal num dispositivo que

esteja com a orientação na vertical.

No que toca a visualizações personalizadas, esta solução não só o permite, como já disponibi-

liza de raiz um widget de diagramas que permite, nomeadamente, a realização do caso das plantas

de fábricas. Um exemplo fornecido pela Dundas é exactamente esse, mostrando a planta de uma

fábrica com cada zona a ser colorida de acordo com um intervalo de valores mostrado em legenda

(Figura 2.19).

Como o preço não é público e não foi encontrado nada para além de comentários online sobre

o custo da ferramenta, foi necessário contactar a equipa de vendas.

22


Figura 2.19: Exemplo de uma planta de uma fábrica no Dundas BI.

O Dundas BI possui dois pacotes distintos. Um primeiro, dependente do número de utiliza-

dores e utilização do servidor, que torna o pagamento complexo e imprevisível, o que é algo que

a CMF pretende evitar. E o segundo, com número ilimitado de instalações, para empresas que

procuram integrar a solução nos seus próprios produtos, como é o caso. O custo é de 6 mil e qui-

nhentos dólares anuais mais uma percentagem das receitas do produto onde será embebido, neste

caso, o cmNavigo, o que a CMF igualmente rejeitou.

2.7 Telerik Reporting e Report Server

A Telerik é uma empresa de software búlgara fundada em 2002 e adquirida em 2014 pela

Progress Software. No seu portfólio conta com diversas soluções de interfaces gráficas e de visu-

alização de dados e de navegação, para diversas tecnologias, entre as quais ASP.NET e Microsoft

Silverlight. As suas soluções para Silverlight levaram a que a CMF tenha constituído uma parceria

com a Telerik para potenciar a actual interface do cmNavigo.

O programa Telerik Report Designer, ferramenta on-premises para desenvolvimento de rela-

tórios, tem uma interface familiar, semelhante às que a Microsoft desenvolveu para o Office ou

o explorador de ficheiros do Windows. Esta ferramenta foi capaz de importar os dados do MS-

SQL, utilizá-los para criar relatórios semelhantes aos que se encontram no SSRS e publicar esses

relatórios no Report Server instalado.

Com o Report Server foi possível visualizar através de um navegador os relatórios criados e o

MSSQL Profiler mostrou que faziam as interrogações, a cada carregamento da página Web.

O preço do Report Server é de 1499 dólares anuais, com direito a 15 utilizadores. Para permitir

o acesso de mais utilizadores ao servidor, a Telerik vende incrementos de 5 a 500 dólares cada

23


incremento. Este é pago apenas uma vez. A licença do Report Designer vai dos 599 aos 1999

dólares anuais. Os pacotes mais caros incluem outros produtos de desenvolvimento de interfaces.

Os 2098 dólares anuais são um preço bem mais apelativo que as ferramentas anteriores.

No entanto, a ferramenta e os relatórios criados mostraram-se visualmente antiquados e ne-

cessitariam de trabalho adicional para serem embebidos na interface HTML5 mais recente do

cmNavigo. Por esse motivo avançou-se para o estudo da ferramenta seguinte.

2.8 Sisense

A Sisense é uma empresa de software israelita fundada em 2004 que lançou em 2010 a sua

solução atual de BI.

A criação de dashboards é diferente de todas as outras ferramentas estudadas. O Sisense

possui um programa à parte para definir a fonte de dados, o Sisense ElastiCube Manager. Toda

a criação e visualização de dashboards é feita através do servidor Web Sisense, que disponibiliza

uma página Web onde se pode seleccionar a fonte de dados definida no referido programa.

Figura 2.20: Interface do Sisense ElastiCube Manager.

O ElastiCube é a solução do Sisense para as necessidades de BI. O Sisense ElastiCube Mana-

ger (Figura 2.20) é uma ferramenta de Extract, Transform and Load (ETL) que permite a impor-

tação de dados de diversas fontes, entre as quais o MSSQL, relacionar as colunas dos diferentes

objectos, manipular esses dados e, no final, preparar um dataset para ser utilizado pelos dashbo-

ards.

24


Estes ElastiCubes podem ser definidos com dois modos diferentes de actualização dos dados:

• Definir um intervalo de tempo após o último build, por exemplo, fazer builds de 30 em 30

minutos;

• Ou especificar uma hora de criação do build, podendo ser ainda definido em que dias se

pretende que o build ocorra, por exemplo, fazer builds todos os dias úteis às 6 da manhã.

Este intermediário na obtenção dos dados tem os seus pontos positivos e negativos. Os as-

pectos positivos residem no facto de não ser necessário inquirir frequentemente a base de dados,

através da realização espaçada de builds frequentes ou em horas de menor processamento, redu-

zindo a carga sobre o sistema e obtendo os dados de forma mais célere. Por outro lado, os dados

não são os mais actuais.

Figura 2.21: Dashboard de exemplo na interface Web do Sisense.

Estando a fonte de dados definida e o build concluído, já pode ser utilizada pelos dashboards.

Ao aceder ao servidor Web do Sisense para criar o dashboard, a primeira coisa que temos de

indicar é o nome do Elasticube que vai ser utilizado. A partir daqui, a criação do dashboard dá-se

de forma semelhante às restantes ferramentas testadas: escolha do widget, das colunas que irão

compôr os seus eixos e métricas e as habituais opções para filtrar ou alterar o aspecto visual do

widget escolhido. As páginas Web do Sisense também mostraram ser responsivas.

O único problema encontrado no Sisense foi o preço. O pacote base, para 1 licença de edição,

10 licenças de visualização e 75 milhões de transacções por Elasticube fica por 20 mil dólares

anuais. O dobro do pacote base do Tableau no primeiro ano e oito vezes mais caro nos anos

seguintes. Para cada licença de criação adicional acresce mil dólares anuais e por cada licença de

visualização mais 450 dólares.

Por ser excessivamente caro, o Sisense foi rejeitado.

25


2.9 Syncfusion Dashboard Platform

Fundada em 2001, a empresa de desenvolvimento de software Syncfusion tem actualmente

sede na Carolina do Norte dos Estados Unidos da América. O seu portfólio tem algumas seme-

lhanças com o da Telerik, contando com várias frameworks para tecnologias Web e dispositivos

móveis, e também soluções de BI, para o desenvolvimento e gestão de dashboards e relatórios.

Figura 2.22: Interface de edição da fonte de dados no Syncfusion Dashboard Designer.

A sua solução para dashboards, Dashboard Platform, divide-se entre um programa on-premises

de criação de dashboards, Dashboard Designer, e um servidor Web para a publicação e gestão dos

dashboards, o Dashboard Server.

Na criação de uma fonte de dados, depois dos habituais dados de acesso ao servidor e base de

dados, o Syncfusion mostra o modelo de dados (Figura 2.22) dividido pelos diferentes esquemas

e dentro de cada um tem os objectos organizados pelos diversos tipos, nomeadamente Tabelas,

Vistas e Stored Procedures. Em baixo estão os dados do dataset.

Depois de inserido o primeiro objecto na fonte de dados, a cada nova inserção o Syncfusion

pede para que seja definida a junção (Join) com algum dos objectos já inseridos (Figura 2.23). Ou

seja, o Syncfusion obriga a que uma fonte de dados tenha os seus objectos todos ligados, de forma

a que resulte num só dataset. No entanto, é possível criar e utilizar várias fontes de dados num

dashboard.

Para além de ser possível definir a fonte de dados arrastando os objectos pretendidos, também

é possível defini-lo escrevendo o código manualmente (Figura 2.24). Na barra superior é possível

alterar para a vista de código para introduzir código SQL personalizado.

26


Figura 2.23: O Syncfusion pede para escolher uma junção ao adicionar uma nova tabela.

Figura 2.24: O Syncfusion permite criar uma interrogação personalizada.

27


O desenvolvimento visual do dashboard também é baseado no arrastamento de um dos widgets

disponíveis para o dashboard, sendo necessário editá-lo individualmente para lhe associar os dados

de uma fonte de dados, para além das personalizações visuais.

Na definição dos dados de um widget (Figura 2.25), escolhe-se a fonte de dados da lista e

são listadas as diferentes colunas entre medidas, valores numéricos e dimensões, datas e strings.

Estas colunas podem ser arrastadas para os campos de valores e colunas, sendo que em alguns

casos podem constar várias colunas, formando uma hierarquia onde é possível fazer drill-down.

Também é possível criar colunas personalizadas, contendo valores por omissão ou calculados

através de outras colunas.

Figura 2.25: Interface de especificação dos dados de um widget.

As definições visuais permitem desligar e ligar diferentes funcionalidades, como o título do

widget, os nomes dos eixos e as legendas. Não permite alterar as cores dos gráficos através deste

menu de personalização ao invés de outras ferramentas estudadas.

Para além de widgets de visualização como gráficos de barras, gráficos de linhas, gráficos de

área, gráficos circulares ou KPI, o Syncfusion também disponibiliza widgets que permitem filtrar

os dados através do dashboard. Um widget de combobox dá ao utilizador a escolher um valor ou

múltiplos valores de entre uma lista de opções. Essa lista é obtida escolhendo uma das colunas da

fonte de dados, da qual o Syncfusion irá buscar os valores distintos.

Na Figura 2.26 temos uma combobox que filtra os dados pela cor escolhida. Ao escolher a

cor vermelha (Red) apenas são mostradas duas barras das quatro originais pois as duas retiradas

não contêm qualquer elemento com a cor vermelha e vice-versa (Figura 2.27). Os valores também

reduziram. Também é possível filtrar por múltiplos elementos. Na Figura 2.28 é mostrado um

28


Figura 2.26: Dashboard com um gráfico de barras e uma combobox.

Figura 2.27: O dashboard foi filtrado pela cor "Red".

29


Figura 2.28: Cor "Silver"adicionada ao dashboard.

filtro pela cor vermelha (Red) e prateada (Silver) surgindo uma terceira barra no gráfico, além de

um aumento dos valores.

Sobre os filtros convém acrescentar que, no caso de existirem múltiplos widgets de filtragem,

estes influenciam-se mutuamente. Assim, num dashboard com duas comboboxes, se filtrarmos

numa delas, a outra combobox poderá aparecer com menos elementos, fruto de esses elementos

filtrados não preencherem os requisitos da filtragem feita como se demonstra nas (Figura 2.29) e

(Figura 2.30). O mesmo acontece caso se filtre na segunda combobox. A primeira actualiza-se

com menos elementos por não satisfazerem os requisitos da segunda filtragem(Figura 2.31).

Para desfazer os filtros têm-se 3 alternativas. Pode-se seleccionar a opção All em cada widget,

pode-se carregar no ícone no canto superior direito para desfazer o filtro desse widget ou pode-se

desfazer os filtros todos do dashboard de uma vez só, indo ao Filters Overview, no canto superior

direito do dashboard.

O Syncfusion Dashboard Designer possui um botão de pré-visualização no canto superior

direito que permite ver a aparência do dashboard num navegador, criando uma página Web pelo

IIS Express com o dashboard.

Para publicar efectivamente o dashboard é necessário ter uma máquina com o Dashboard

Server instalado. Quando se tenta publicar a partir do Dashboard Designer, é necessário introduzir

o endereço e porta do Dashboard Server, juntamente com os dados de autenticação, que podem

ser do painel de gestão do Syncfusion ou do Windows. Depois da autenticação no servidor, é

permitido ao utilizador publicar o dashboard, introduzindo dados como a pasta onde este deverá

ser guardado, título e descrições. Depois de publicado, o utilizador pode optar por ver o dashboard

através do Dashboard Server e confirmar o sucesso dessa publicação.

30


Figura 2.29: Dashboard com duas comboboxes e com os filtros sem nada seleccionado.

Figura 2.30: Segunda combobox afectada pelo filtro "Red".

31


Figura 2.31: Seleccionada a categoria "Bikes"no dashboard.

Através do MSSQL Profiler (Figura 2.32) é possível ver que o dashboard, sempre que é car-

regado no navegador, inquire a base de dados assim como quando é alterado um dos filtros.

Através do servidor Web do Dashboard Server é possível gerir o dashboard, sendo possível

organizá-los em pastas, criar novos utilizadores e definir as suas permissões de acesso, entre outras

funcionalidades. O Syncfusion permite, para além da publicação dos dashboards, a publicação de

fontes de dados e widgets para o servidor, que podem ser descarregados para o Dashboard Designer

para serem reutilizados num outro dashboard.

As páginas mostraram-se responsivas, adaptáveis a diferentes resoluções. Actualmente, não é

possível criar widgets personalizados.

No que toca ao preço, a Syncfusion Dashboard Platform oferece uma licença comunitária

(Community License), tornando-a gratuita para empresas com receitas inferiores a um milhão de

dólares anuais e limitada a 5 utilizadores. A licença empresarial fica por 1995 dólares anuais até

50 utilizadores, sendo que acresce 500 dólares anuais por cada incremento de 25 utilizadores. Ao

conhecer o projecto da CMF, a equipa de vendas da Syncfusion propôs um número ilimitado de

licenças e utilizadores por seis mil dólares anuais.

O Syncfusion foi escolhido porque cumpre todos os requisitos e possui um preço atrativo.

No que toca à fonte de dados, importa saber se é capaz de invocar vistas, UDF e SP. Na

definição da fonte de dados do Syncfusion, a barra lateral esquerda lista os esquemas da base de

dados escolhida, sendo possível encontrar, para além das tabelas, as vistas e SP a que o utilizador

tem acesso.

No caso das vistas, o Syncfusion trata-as tal como se fossem tabelas, pedindo para referir qual

a junção que deve ser feita aquando da introdução de um novo objecto.

32


Figura 2.32: Pelo SQL Server Profiler é possível ver o filtro por "Red"na interrogação.

No caso das SP, a interface pede para introduzir os valores dos argumentos bloqueando a vista

de código (Code View) e a adição de novos objectos. Também não é possível adicionar uma SP

quando já existem tabelas ou vistas no modelo.

As UDF não são listadas. No entanto, caso sejam conhecidas do utilizador, é possível chamá-

las através do modo de código. No modo de código, e neste modo apenas, é possível criar parâ-

metros personalizados e utilizá-los na interrogação. No entanto, estes parâmetros apenas podem

ser editados na fonte de dados. Não é possível editar o valor do parâmetro noutro local, seja no

dashboard, no widget ou por argumento no URL.

Na personalização dos widgets, o Dashboard Designer não permite, por exemplo, a alteração

das cores utilizadas num gráfico de barras. A cor azul é aplicada a todas e não é possível ser

alterada através deste editor. Para o conseguir, é necessário descarregar o Syncfusion Dashboard

SDK, que contém exemplos de ficheiros .sydx (extensão dos dashboards Syncfusion guardados

localmente) embebidos numa página Web e as stylesheets e scripts necessários para personalizar

o aspecto e experiência dos dashboards. Para efeitos de demonstração, foi criado um exemplo

simples onde foram colocados elementos em redor do dashboard e personalizadas as cores de

fundo e do gráfico de barras do dashboard.

Outro aspecto estudado foi a autenticação. A utilização de contas criadas através do painel de

gestão do servidor Syncfusion acrescenta não só trabalho extra na gestão de utilizadores e suas

permissões, como também obriga os utilizadores a possuírem uma nova conta. Para evitar isso, o

Syncfusion permite a autenticação com contas Windows através do Active Directory.

33


Figura 2.33: Dashboard com as cores alteradas graças ao SDK.

No que toca a manter os dados do dashboard actualizados quando se pretende que estes es-

tejam abertos durante longos períodos, o Syncfusion permite estabelecer um refrescamento do

mesmo em intervalos de tempo personalizáveis. Para activar e configurar esse refrescamento é ne-

cessário editá-lo com o Dashboard Designer, indo ao menu superior, escolhendo Server e depois

Refresh Settings.

Na finalização deste estudo e ao ver como a nova interface HTML5 estava estruturada, uma

das questões que surgiu foi se era possível o dashboard receber parâmetros através do URL para

serem utilizados na filtragem.

A passagem de argumentos é bastante simples, bastando para isso utilizar a sintaxe:

<Endereço>:<Porta>/?<Nome da coluna a filtrar>=<Valor>,<Valor2>

&<Nome da segunda coluna a filtrar>=<Valor>,<Valor2>

Exemplo:

http://localhost:6765/?Color=white,grey

Este endereço filtra a fonte de dados com a coluna “Color” pelos valores “White” e “Grey”.

Na Figura 2.34 é possível ver que o dashboard aparece filtrado, tanto no gráfico de barras como

na combobox. É possível ver através do Profiler que o dashboard, no carregamento de uma página

que contenha os parâmetros mencionados, adiciona à interrogação a filtragem especificada.

O dashboard aparece filtrado, não só no gráfico de barras, como também na combobox, que

permite posteriormente filtrar especificamente por um dos dois valores resultantes.

34


Figura 2.34: Dashboard e interrogações duma filtragem por endereço.

Infelizmente, não é possível passar argumentos pelo URL que possam ser utilizados nos ar-

gumentos das SP ou UDF. Os argumentos de SP e UDF apenas podem ser alterados na fonte de

dados.

2.10 Conclusão do estudo das ferramentas

Concluindo o estudo das ferramentas, é possível compará-las nos diferentes requisitos listados.

Esta comparação ajuda a perceber quais são as alternativas ao Syncfusion e que ferramentas po-

derão ser melhores alternativas caso ocorra mudanças, nomedamente uma solução de publicação

on-premises no Power BI ou preços mais atractivos em soluções como o Tableau.

Todas as ferramentas foram simples de instalar e configurar, exceptuando o Klipfolio, que não

é on-premises. O único pormenor a ter em atenção é nas configurações dos servidores Web para

os dashboards, que envolve escolher uma porta que não entre em conflito com outros servidores

Web ou programas.

À lista de requisitos mencionada anteriormente, foi adicionado um outro não obrigatório:

• Se a ferramenta é capaz de inquirir SQL Server Analysis Services (SSAS).O cmNavigo disponibiliza de base, para além das bases de dados operacionais, um DW. O

cliente final pode ou não ter capacidade de interagir com o SSAS. Se a ferramenta for capaz

de interagir com o DW é uma qualidade extra.

Através da lista de requisitos, realizou-se uma tabela comparativa das ferramentas estudadas.

35


Tabela 2.1: Tabela comparativa das ferramentas estudadas.

36

Capítulo 3

Solução actual do cmNavigo

3.1 Arquitectura geral do cmNavigo

As instalações dos servidores MSSQL do cmNavigo contam no mínimo com duas máquinas.

Uma primeira máquina com uma base de dados relacional Online, onde são efectuadas todas as

transacções por parte das máquinas envolvidas na produção e uma segunda máquina com uma

base de dados relacional Operational Data Store (ODS) e um DW.

Figura 3.1: Os três tipos de bases de dados envolvidos no cmNavigo e como se relacionam.

A instância ODS mantém-se actualizada com a Online, sincronizando os dados de 5 em 5

segundos. A base de dados ODS mantém todo o histórico de informação, enquanto a Online

mantém apenas um histórico recente. O número de horas de histórico da Online depende do

processo de produção do cliente, tendo sido dado como exemplo 5 horas. Ao mesmo tempo, a

ODS também pode servir como backup da Online em caso de falha.

As interrogações feitas pelos utilizadores, nomeadamente na interface de gestão do cmNavigo,

recorrem à informação armazenada na ODS para não perturbar o funcionamento da base de dados

37


de produção Online. Essa informação presente na ODS também é utilizada nas builds do DW, que

ocorrem com frequências diferentes para cada cliente, incluindo desde builds de 5 em 5 minutos

até builds diárias.

3.2 Dashboards actuais do cmNavigo

As versões actuais do cmNavigo, desenvolvidas em Silverlight, possuem três dashboards de

base, podendo os clientes pedir alterações a esses ou a criação de novos conforme as suas necessi-

dades específicas.

Os valores apresentados nos dashboards são as médias dos recursos da fábrica excepto no

cronograma do Resource Key Performance Indicators (RKPI), que mostra os diferentes estados ao

longo do tempo para cada recurso seleccionado.

Esses dashboards são:

3.2.1 Resource Key Performance Indicators (RKPI)

Este dashboard possui indicadores de quanto tempo as máquinas estiveram em condições de

produzir (Uptime) e o tempo em que não estiveram (Downtime), o tempo médio entre as suas

falhas ou Mean Time Between Failures (MTBF) e o tempo médio entre reparações ou Mean Time

To Repair (MTTR).

Para além destes indicadores relativos aos últimos dias, semanas ou meses, conforme a escolha

do utilizador, também é mostrado o tempo em que as máquinas estiveram em cada um dos estados

e um cronograma (Timeline) com os estados de cada uma das máquinas seleccionadas.

Figura 3.2: Dashboard RKPI no actual cmNavigo.

38


De base, no cmNavigo as máquinas podem ter os estados de Produção (Productive), Sem

programação (NonScheduled), Em espera (StandBy), Manutenção não programada (Unscheduled

Down), Manutenção programada (Scheduled Down) e Engenharia (Engineering).

3.2.2 Process Key Performance Indicators (PKPI)

Este dashboard possui indicadores das unidades produzidas com sucesso em relação ao total

previsto no início do processo (Yield), o tempo de ciclo desse processo (Cycle Time) e quais os

problemas mais frequentes na produção, medidos quer em frequência, quer em percentagem.

Figura 3.3: Dashboard PKPI no actual cmNavigo.

3.2.3 Overall Equipment Effectiveness (OEE)

Este dashboard possui indicadores de:

• Eficácia da produção (OEE), que pode ser calculado através da multiplicação das percenta-

gens das métricas Availability (AVA), Quality (QUA) e Performance (PER).

OEE = AVA×QUA×PER

• Disponibilidade para operar ou uptime (AVA)

• Unidades produzidas com sucesso em relação ao total iniciado (QUA)

• Desempenho medido em relação à velocidade projectada (PER)

39


Estes indicadores são apresentados, quer para o valor actual nos widgets superiores, quer nos

últimos dias, semanas ou meses, indicado nos widgets inferiores.

Figura 3.4: Dashboard OEE no actual cmNavigo.

Para cada um destes dashboards é possível ao utilizador filtrar pelo intervalo de tempo que

deseja ver nos gráficos, podendo escolher entre Dias, Semanas ou Meses.

Segundo a CMF a criação destes dashboards foi morosa, pelo que as ferramentas de criação

de dashboards resultam também num desenvolvimento mais fácil por parte da CMF. Isto significa

que os dashboards pedidos pelos clientes podem ser desenvolvidos e entregues mais rapidamente

e potencialmente a uma maior diversificação dos dashboards de base. No entanto, o principal

objectivo é tornar o cliente final capaz de desenvolver os seus próprios dashboards.

40

Capítulo 4

Simplificação do modelo de dados

Uma das características de algumas ferramentas estudadas, incluindo o Syncfusion, é não

serem capazes de inquirir o DW através do SSAS. Isto significa que há duas alternativas para

inquirir os dados do DW:

• Ou são criadas SPs com interrogações aos cubos recorrendo a MultiDimensional eXpressi-

ons (MDX). Este é o método que o cmNavigo utiliza para mostrar os dados presentes nos

dashboards apresentados;

• Ou são consultadas as respectivas tabelas, o que é menos eficiente por não tirar proveito das

agregações dos cubos.

Como as SP foram criadas especificamente para as necessidades dos três dashboards mencio-

nados, não servem para dashboards com necessidades novas nem permitem explorar os dados.

Ao mesmo tempo, as tabelas possuem muitos dados irrelevantes para o utilizador de BI, úteis

para as máquinas, para a gestão do cmNavigo ou na resolução de problemas. Por esse motivo

optou-se por criar vistas sobre as tabelas de factos e as suas dimensões, capazes de devolver

apenas as colunas que a CMF considera relevantes para o cliente.

Para a criação dessas vistas, contemplaram-se duas abordagens:

• Pré-junçãoCriar uma vista que devolva a tabela de factos junta (Join) a todas as suas dimensões, sacri-

ficando o desempenho a favor da simplicidade do modelo de dados;

• Pós-junçãoCriar uma vista para a tabela de factos e outra para cada dimensão. Isto permitirá uma

maior personalização da interrogação, juntando apenas as dimensões relevantes, mas obriga

a conhecer minimamente o modelo de dados.

A partir desta etapa o estudo passou a recorrer ao servidor e bases de dados de teste da CMF.

Para testar as implementações escolheu-se a tabela de factos de materiais (Material).

41


Um material pode ser qualquer coisa utilizada no fabrico, desde um chip até à cola usada. A

tabela de factos permite rastrear o material ao longo do processo e permite saber quando este foi

utilizado, quanto, onde, por quem, com que finalidade, etc.

O modelo de dados dimensional envolvendo a tabela de factos [FactMaterial] e as suas dimen-

sões é o seguinte.

Figura 4.1: Modelo de dados dimensional da tabela de factos FactMaterial e suas dimensões.

Conhecendo agora todas as tabelas envolvidas e como estão relacionadas, avançou-se para a

escolha das colunas relevantes para os utilizadores em cada uma delas.

Na tabela de factos [FactMaterial] foram seleccionadas as colunas:Seleccionadas nas duas vistas, pré-junção e pós-junção:[UTCDatetime] - Data em UTC no formato datetime

[PrimaryQuantity] - Quantidade de material

[LC1DateTime] - Data na hora local da empresa no formato datetime

Seleccionadas apenas na vista pós-junção, pois necessita das chaves secundárias paraposteriormente se juntar às vistas das dimensões:

[MaterialKey], [ParentMaterialKey], [MaterialHierarchyKey], [AreaKey], [StepKey], [Pro-

ductKey], [FlowKey], [ResourceKey], [EmployeeKey], [ShiftDateKey], [DateKey], [TimeKey],

[ServiceKey], [OperationKey], [RelatedMaterialKey], [MaterialStateKey], [TeamKey], [ShiftKey],

[LC1DateKey], [LC1TimeKey], [PrimaryUnitKey], [SecondaryUnitKey]

Na dimensão [DimArea] foram seleccionadas as colunas:Seleccionada nas duas vistas:[AreaName] - Nome da área (Ex.: Packing)

42


Seleccionadas apenas na vista pós-junção, pois necessita das chaves secundárias paraposteriormente se juntar à tabela de factos e à dimensão relacionada, visto que se trata deum esquema em floco de neve (Snowflake):

[AreaKey], [FacilityKey]

Na dimensão [DimDate] foram seleccionadas as colunas:Seleccionada nas duas vistas:[FullDateAlternateKey] - Data no formato YYYY-MM-DD

[DayNameOfWeek] - Dia da semana por extenso (Ex.: Monday)

[MonthName] - Mês por extenso (Ex.: October)

[DayNumberOfMonth] - Dia do mês

[CalendarYear] - Ano

Seleccionadas apenas na vista pós-junção:[DateKey]

Na dimensão [DimEmployee] foram seleccionadas as colunas:Seleccionada nas duas vistas:[UserName] - Nome do utilizador (Ex.: “Vasconcelos, Fernando”)

[UserAccount] - Conta do utilizador (Ex.: “CORPORATE\FERNANDO.VASCONCELOS”)

Seleccionadas apenas na vista pós-junção:[EmployeeKey]

Na dimensão [DimFacility] foram seleccionadas as colunas:Seleccionada nas duas vistas:[FacilityName] - Nome do edifício (Ex.: “Warehouse”)

Seleccionadas apenas na vista pós-junção:[FacilityKey]

Na dimensão [DimFlow] foram seleccionadas as colunas:Seleccionada nas duas vistas:[FlowName] - Nome do fluxo (Ex.: “DicingBlade”)

[Type] - Nome do tipo de fluxo (Ex.: “Production”)

Seleccionadas apenas na vista pós-junção:[EmployeeKey]

Na dimensão [DimMaterial] foram seleccionadas as colunas:Seleccionada nas duas vistas:[MaterialName] - Nome de material (Ex.: “HCB758”)

[Type] - Tipo do material quanto ao destino (Ex.: Se o destino do material é o cliente é “Pro-

duction”, se ainda estiver a ser testado é “Engineering”)

43


[Form] - Tipo do material quanto à forma como é usado e rastreado no sistema (Ex.: “Consu-

mable” ou “Lot”)

Seleccionadas apenas na vista pós-junção:[MaterialKey]

Na dimensão [DimMaterialHierarchy] foram seleccionadas as colunas:Seleccionada nas duas vistas:[Description] - Descrição da localização do material na sua hierarquia (Ex.: “Inner Material”

ou “TopMost Material”)

Seleccionadas apenas na vista pós-junção:[MaterialHierarchyKey]

Na dimensão [DimMaterialState] foram seleccionadas as colunas:Seleccionada nas duas vistas:[MaterialStateName] - Estado do material (Ex.: “Queued” ou “Dispatched”)

Seleccionadas apenas na vista pós-junção:[MaterialStateKey]

Na dimensão [DimOperation] foram seleccionadas as colunas:Seleccionada nas duas vistas:[OperationName] - Nome da operação (Ex.: “Assemble”)

[EntityName] - Nome da entidade (Ex.: “Resource” ou “Material”)

Seleccionadas apenas na vista pós-junção:[OperationKey]

Na dimensão [DimProduct] foram seleccionadas as colunas:Seleccionada nas duas vistas:[ProductName] - Nome do produto (Ex.: “WIRAU0.8HP-MSD”)

[Type] - Tipo do produto (Ex.: “Consumable”)

[Description] - Descrição do produto (Ex.: “Gold Wire 0.8 mil HP type (MSD)”)

Seleccionadas apenas na vista pós-junção:[ProductKey]

Na dimensão [DimResource] foram seleccionadas as colunas:Seleccionada nas duas vistas:[ResourceName] - Nome da máquina (Ex.: “WFS-01.BladeZ1”)

[Type] - Tipo da máquina (Ex.: “Consumable”)

[Model] - Modelo da máquina (Ex.: “Feed”)

[Description] - Descrição da máquina (Ex.: “WFS-01.Blade”)

Seleccionadas apenas na vista pós-junção:

44


[ResourceKey]

Na dimensão [DimService] foram seleccionadas as colunas:Seleccionada nas duas vistas:[ServiceName] - Nome do serviço (Ex.: “AttachMaterials”)

[ServiceContractName] - Tipo de serviço (Ex.: “MaterialManagement”)

Seleccionadas apenas na vista pós-junção:[ServiceKey]

Na dimensão [DimShift] foram seleccionadas as colunas:Seleccionada nas duas vistas:[ShiftDefinitionName] - Nome do tipo de turno (Ex.: “8HourShift SMART”)

[ShiftDefinitionShiftName] - Nome do turno (Ex.: “ShiftA”)

[StartTime] - Hora de início do turno no formato HH:MM:SS

[EndTime] - Hora de fim do turno no formato HH:MM:SS

Seleccionadas apenas na vista pós-junção:[ShiftKey]

Na dimensão [DimStep] foram seleccionadas as colunas:Seleccionada nas duas vistas:[StepName] - Nome do passo do processo (Ex.: “Mold”)

[StepType] - Tipo do passo do processo (Ex.: “Production”)

[PrimaryUnits] - Unidades (Ex.: “kg”)

[SecondaryUnits] - Unidade secundária (Ex.: Caso a unidade primária seja “pcs” (pieces) ou

“unit”, a unidade a que se refere pode ser “Wafer”)

Seleccionadas apenas na vista pós-junção:[StepKey]

Na dimensão [DimStep] foram seleccionadas as colunas:Seleccionada nas duas vistas:[Name] - Nome da equipa

[Description] - Descrição da equipa

Seleccionadas apenas na vista pós-junção:[TeamKey]

Na dimensão [DimTime] foram seleccionadas as colunas:Seleccionada nas duas vistas:[Hour24] - Hora no formato 24 horas (Ex.: 13)

[Minute24] - Minuto (Ex.: 12)

[Time24] - Hora no formato HH:MM:SS (Ex.: 13:12:31)

45


[Second] - Segundo (Ex.: 31)

Seleccionadas apenas na vista pós-junção:[TimeKey]

No caso da pré-junção isto resultou numa só vista, com 62 colunas e 22 tabelas ligadas entre

si por inner joins, incluindo chamadas repetidas, como nos casos das tabelas DimTime, DimDate

e DimMaterial que são referidas em múltiplas chaves. Devido à enorme quantidade de dados

presente, foi adicionado um filtro para somente devolver os dados referentes às últimas quatro

semanas (28 dias).

No caso da pós-junção, isto resultou em 22 vistas, com a vista sobre a tabela de factos a ter

um filtro igual ao da pré-junção, mostrando apenas os dados das últimas quatro semanas. Como

a tabela de factos possui algumas chaves que se ligam à mesma dimensão, como nos casos do

DimTime com duas chaves e DimDate e DimMaterial com três chaves cada uma, faria sentido

existirem menos de 22 vistas. No entanto, o modo de desenho da fonte de dados do Syncfusion

não permite adicionar uma vista mais que uma vez, nem permite estabelecer mais que um join

entre as mesmas duas vistas, pelo que se optou por repeti-las com outros nomes. Isto resultou

também num benefício, tornou possível dar o mesmo nome da chave da tabela de factos à chave

da dimensão, o que resulta num maior acerto na sugestão do join. Isto é relevante pois as vistas

não possuem chaves secundárias entre si, logo a sugestão de um join por parte das ferramentas

estudadas é feito sobretudo na base do nome e do tipo da coluna.

Concluindo, a diferença entre as duas implementações é notória pela grande diferença entre

importar apenas uma vista ou até 22, o que também implica verificar a correcção das junções e

saber quais as dimensões necessárias. Pela facilidade de uso, a pré-junção parece a estratégia mais

adequada, permintindo ao utilizador explorar, sem conhecer o modelo de dados.

46

Capítulo 5

Teste da solução proposta

O desenvolvimento dos dashboards presentes no cmNavigo foi moroso, pelo que era impor-

tante saber se era possível criá-los de forma mais fácil através do Syncfusion.

5.1 Replicação dos dashboards do cmNavigo

Não podendo aceder por SSAS através do Syncfusion, é possível fazê-lo através do MSSQL,

recolhendo os dados necessários do DW através de SP com chamadas de selecção em MDX para

os cubos. Essas SP estão na base de dados ODS.

• P_GetReasonsFrequencyAndPercentage_ODSUtilizada para obter os problemas mais frequentes na produção, juntamente com a sua

frequência e percentagem do total de problemas existentes, que são representados no gráfico

da direita no dashboard PKPI;

• P_GetResourceOEE_ODSUtilizada para obter os dados no dashboard OEE. Os valores do OEE, Availability, Quality

e Performance presentes em cima são os actuais, enquanto que os do gráfico em baixo são

dos últimos sete dias, semanas ou meses;

• P_GetResourcePerformance_ODSUtilizada para obter o Uptime, Downtime, MTBF e MTTR dos gráficos de cima no dashbo-

ard RKPI. Os valores por baixo do título são o valor actual, enquanto que os dos gráficos

mostram os dos últimos sete dias, semanas ou meses;

• P_GetResourcePerformanceStateChange_ODSUtilizada para obter os estados de cada máquina (Resource) ao longo do tempo, para ser

mostrado no cronograma no canto inferior direito do dashboard RKPI;

47


• P_GetResourcePerformanceStateChangeSummary_ODSUtilizada para obter o tempo total que as máquinas (Resources) estiveram em cada estado,

para ser mostrado no gráfico de barras no canto inferior esquerdo do dashboard RKPI;

• P_GetYieldAndCycleTime_ODSUtilizada para obter o Yield e Cycle Time presentes nos gráficos da esquerda do dashboard

PKPI. Os valores por baixo do título são o valor actual, enquanto que os do gráficos mostram

os dos últimos sete dias, semanas ou meses.

As mesmas Stored Procedures foram utilizadas para replicar os dashboards no Syncfusion.

O Syncfusion não possui um widget que pudesse representar o cronograma de forma seme-

lhante, pelo que este foi deixado de fora. E como o Syncfusion possui uma grelha e pouco espaço

para colocar widgets, alguns foram colocados no seu espaço.

Figura 5.1: Dashboard RKPI replicado no Syncfusion.

48


Figura 5.2: Dashboard PKPI replicado no Syncfusion.

Figura 5.3: Dashboard OEE replicado no Syncfusion.

Como o Power BI afirma ter a intenção de, no futuro, permitir a publicação de dashboards

on-premises para o SSRS também se desenvolveram os dashboards nesta ferramenta.

O Power BI não possui de origem um widget que pudesse representar de forma semelhante

o cronograma e não se encontrou uma solução simples no mercado da ferramenta, pelo que este

foi descartado. Como no Power BI é mais versátil na escolha do espaço e dimensionamento dos

widgets, manteve-se a mesma disposição.

49


Figura 5.4: Dashboard RKPI replicado no Power BI.

Figura 5.5: Dashboard PKPI replicado no Power BI.

50


Figura 5.6: Dashboard OEE replicado no Power BI.

Por fim, e porque a CMF tem clientes que possuem o Tableau, resolveu-se desenvolver so-

mente o dashboard RKPI. Isto permite ter uma ideia de como seriam os dashboard no Tableau e

como podem ser servidos os clientes que já possuem essa solução de BI.

Figura 5.7: Dashboard RKPI replicado no Tableau.

51


Como o Tableau possui um widget de cronograma, o mesmo foi adicionado. Neste é possível

ver o detalhe de cada estado, com o nome da máquina (“BOV-03”), o estado (“Standby”) e a data

de início e de fim desse estado.

5.2 Dashboards embebidos na nova interface do cmNavigo

A nova interface do cmNavigo em HTML5, ainda em desenvolvimento, já permite embeber

páginas externas, facilitando a integração com o Syncfusion. É apenas necessário criar um widget

de uma página externa e adicionar-lhe o valor do URL.

Figura 5.8: Interface HTML5 do cmNavigo com o dashboard RKPI embebido.

52


Figura 5.9: Interface HTML5 do cmNavigo com o dashboard PKPI embebido.

Figura 5.10: Interface HTML5 do cmNavigo com o dashboard OEE embebido.

53


Também foi testada a passagem de argumentos através do URL, apresentada na Figura 5.11

onde se escolhem os três problemas mais frequentes no dashboard PKPI.

Figura 5.11: Dashboard filtrado pelos três problemas mais frequentes.

Um dos aspetos que se pretendeu testar foi o funcionamento do servidor de dashboards,

abrindo-os noutro computador sem qualquer programa do Syncfusion. Para ser possível fazê-lo,

foi necessário:

• Abrir o Syncfusion Server com o IIS em vez do IIS Express, de forma a que este não aceite

apenas ligações para o endereço local (localhost ou 127.0.0.1), mas também para o IP da

máquina;

• Abrir a porta utilizada pelo Syncfusion Server na firewall.

Depois disso foi possível ver os dashboards através de outros computadores na rede da CMF.

Os dashboards disponíveis actualmente no cmNavigo demoraram cerca de três semanas a

serem criados e envolveram a identificação e desenvolvimento dos diferentes pontos necessários,

como as SPs na base de dados, a interface gráfica e os serviços do host intermediário. É ainda

necessário obter a especificação dos requisitos por parte dos clientes, dos especialistas da CMF e

do Product Owner, que posteriormente validaram a implementação.

A criação do dashboard através de qualquer uma destas três ferramentas demora umas horas,

dependendo da complexidade da ferramenta, da complexidade e dimensão da fonte de dados e do

54


detalhe do projecto. O tempo total estimado de criação de um dashboard é de pelo menos um

dia de trabalho. No caso do dashboard ser criado pela CMF, acresce o tempo necessário para

desenvolver as SP de forma a optimizar as interrogações feitas.

55


56

Capítulo 6

Conclusões e Trabalho Futuro

O primeiro objectivo delineado foi estudar as diferentes ferramentas de SSBI e de construção

de dashboards existentes no mercado.

A solução desenvolvida adotou a Syncfusion Dashboard Platform para a criação e gestão de

dashboards. Esta ferramenta mostrou ser simples mas muito funcional, fornecendo uma solução

on-premises, fácil de utilizar e de integrar numa página Web. Foi capaz de satisfazer quase todos

os requisitos, nomeadamente a passagem de argumentos por URL, uma forma de autenticação

externa à ferramenta e o refrescamento temporizado do dashboard. O preço é um dos seus pontos

fortes, ficando por 1995 dólares anuais por uma licença ou seis mil dólares anuais para licenças e

utilizadores ilimitados. Os pontos negativos encontrados na ferramenta são a impossibilidade de

passar um argumento de um URL para uma SP e alguma limitação na personalização visual do

dashboard.

No que toca às outras ferramentas, destaque para o Power BI que, caso passe a permitir a

publicação num servidor on-premises, poderá tornar-se numa solução mais em conta, visto que

actualmente é gratuita. Caso isso aconteça, deverá ser estudada a forma como trata alguns pontos

explorados no Syncfusion, nomeadamente a passagem de argumentos pelo URL.

Várias soluções foram excluídas pelo preço, mas podem voltar a ser consideradas se, no futuro,

o preço se encaixar melhor nos orçamentos das empresas ou a CMF conseguir um acordo de

revenda.

No que toca à simplificação do modelo de dados, criar uma só vista, com a tabela de factos

e todas as suas dimensões juntas, parece ser a melhor solução. Isto permite que um utilizador

não especialista só tenha a necessidade de importar um único elemento. A importação de várias

vistas obrigaria a conhecer o modelo de dados para saber que dimensão deseja e como a deveria

ligar às vistas já importadas, embora esta junção possa ser bem sugerida pela ferramenta de dash-

boards. O lado negativo desta importação é uma menor eficiência, visto que ao juntar todas as

dimensões existirão várias que serão sistematicamente chamadas e não utilizadas, resultando em

processamento, transferência de dados e consumo de memória adicional.

57

Conclusões e Trabalho Futuro

Quanto ao objectivo de embeber os dashboards na interface mais recente do cmNavigo, o

projecto foi bem sucedido, sendo possível replicar os dashboards actuais e mostrá-los na nova

interface. No entanto, fica a faltar um widget de cronograma para completar o dashboard RKPI. O

Power BI e o Tableau mostraram ser ferramentas mais poderosas na personalização do dashboard.

Se a vista única permite que o cliente obtenha os dados de uma forma simples, sem necessi-

dade de conhecer o modelo de dados, as ferramentas estudadas facilitam a importação de dados

e a criação de dashboards. Deste modo, o cliente consegue obter os dashboards que pretende

em consideravelmente menos tempo e pode fazer as suas próprias análises, inclusivamente para

problemas pontuais.

Dentro dos objectivos não alcançados, não foi possível inquirir e testar a ferramenta junto dos

utilizadores finais porque a interface HTML5 do cmNavigo ainda está em desenvolvimento.

Embora tenha sido possível encontrar um boa ferramenta de criação de dashboards, com uma

interface Web capaz de ser integrada facilmente no cmNavigo, falta estudar melhor a personali-

zação visual e testar adequadamente a solução quando a nova interface HTML5 o permitir. A

integração visual, através da personalização das cores e outros estilos, é possível através do SDK

fornecido, conforme demonstrado neste estudo.

O modelo de dados de uma vista para cada tabela de factos e suas dimensões carece de ser

melhor estudado com os clientes, para compreender se esta solução é capaz de lhes solucionar os

problemas e se é efectivamente útil para explorar os dados armazenados.

58

Referências

[AB] QlikTech International AB. Qlik sense token licensing. Disponível emhttp://www.qlik.com/-/media/images/global-us/site-content/pricing/qliksense_token_licensing.pdf.

[Cora] Microsoft Corporation. Create a custom visual with the developer tools (preview).Disponível em https://powerbi.microsoft.com/en-us/documentation/powerbi-custom-visuals-getting-started-with-developer-tools/.

[Corb] Microsoft Corporation. Microsoft business intelligence –our reporting roadmap. Disponível em https://blogs.technet.microsoft.com/dataplatforminsider/2015/10/29/microsoft-business-intelligence-our-reporting-roadmap/.

[Corc] Microsoft Corporation. Over 500,000 unique users from 45,000 com-panies across 185 countries helped shape the new power bi. Dis-ponível em http://blogs.microsoft.com/blog/2015/07/10/over-500000-unique-users-from-45000-companies-across-185-countries-helped-shape-the-new-power-bi/#sm.001lq2ngg1c6zdt8y761x2owlqe69.

[Cord] Microsoft Corporation. Power bi desktop april update feature summary.Disponível em https://powerbi.microsoft.com/en-us/blog/power-bi-desktop-april-update-feature-summary/.

[Core] Microsoft Corporation. What’s new in sql server 2016 reporting services. Disponível emhttps://www.youtube.com/watch?v=7PYnAxEyQCw.

[DDV] Inc. Dundas Data Visualization. Building dashboards with performance in mind. Dispo-nível em http://support.dundas.com/Dashboard5.buildingDashboards_Performance.ashx.

[Gara] Inc. Gartner. Gartner magic quadrant for business intelligence and analytics platforms.Disponível em https://www.gartner.com/doc/reprints?id=1-2XXET8P&ct=160204.

[Garb] Inc. Gartner. Gartner magic quadrant research methodologies. Disponí-vel em http://www.gartner.com/technology/research/methodologies/research_mq.jsp.

[Garc] Inc. Gartner. Gartner magic quadrants. Disponível em http://www.gartner.com/technology/research/methodologies/magicQuadrants.jsp.

59

http://www.qlik.com/-/media/images/global-us/site-content/pricing/qliksense_token_licensing.pdf

http://www.qlik.com/-/media/images/global-us/site-content/pricing/qliksense_token_licensing.pdf

https://powerbi.microsoft.com/en-us/documentation/powerbi-custom-visuals-getting-started-with-developer-tools/

https://powerbi.microsoft.com/en-us/documentation/powerbi-custom-visuals-getting-started-with-developer-tools/

https://blogs.technet.microsoft.com/dataplatforminsider/2015/10/29/microsoft-business-intelligence-our-reporting-roadmap/



http://blogs.microsoft.com/blog/2015/07/10/over-500000-unique-users-from-45000-companies-across-185-countries-helped-shape-the-new-power-bi/#sm.001lq2ngg1c6zdt8y761x2owlqe69



https://powerbi.microsoft.com/en-us/blog/power-bi-desktop-april-update-feature-summary/

https://powerbi.microsoft.com/en-us/blog/power-bi-desktop-april-update-feature-summary/

https://www.youtube.com/watch?v=7PYnAxEyQCw

http://support.dundas.com/Dashboard5.buildingDashboards_Performance.ashx

http://support.dundas.com/Dashboard5.buildingDashboards_Performance.ashx

https://www.gartner.com/doc/reprints?id=1-2XXET8P&ct=160204

https://www.gartner.com/doc/reprints?id=1-2XXET8P&ct=160204

http://www.gartner.com/technology/research/methodologies/research_mq.jsp

http://www.gartner.com/technology/research/methodologies/research_mq.jsp

http://www.gartner.com/technology/research/methodologies/magicQuadrants.jsp

http://www.gartner.com/technology/research/methodologies/magicQuadrants.jsp

REFERÊNCIAS

[Pat06] Hanrahan Pat. Vizql: A language for query, analysis and visualization. In Proceedingsof the 2006 ACM SIGMOD International Conference on Management of Data, SIGMOD’06, pages 721–721, New York, NY, USA, 2006. ACM. URL: http://doi.acm.org/10.1145/1142473.1142560, doi:10.1145/1142473.1142560.

[PCD] Hanrahan Pat, Stolte Chris e Tang Diane. Polaris: Database and data cube visualization.Disponível em http://graphics.stanford.edu/projects/polaris/.

[Sofa] Tableau Software. 2015 annual report. Disponível em http://s1.q4cdn.com/149179428/files/doc_financials/2015Annual/Tableau-2015-Annual-Report-and-Proxy-Statement.pdf.

[Sofb] Tableau Software. Tableau reports q4 and fiscal year 2015 financial results.Disponível em https://www.tableau.com/about/press-releases/2016/tableau-reports-q4-and-fiscal-year-2015-financial-results.

60

http://doi.acm.org/10.1145/1142473.1142560

http://doi.acm.org/10.1145/1142473.1142560

http://graphics.stanford.edu/projects/polaris/

http://s1.q4cdn.com/149179428/files/doc_financials/2015Annual/Tableau-2015-Annual-Report-and-Proxy-Statement.pdf



https://www.tableau.com/about/press-releases/2016/tableau-reports-q4-and-fiscal-year-2015-financial-results

https://www.tableau.com/about/press-releases/2016/tableau-reports-q4-and-fiscal-year-2015-financial-results

Anexo A

Vistas sobre o DW

Apresenta-se de seguida o código SQL de todas as vistas criadas para o DW do cmNavigo.

A.1 Vista Completa (Pré-junção)

V_FactMaterial_Complete_Last4Weeks

1 SELECT fm.LC1DateTime AS Date,

2 fm.UTCDatetime AS DateUTC,

3 fm.PrimaryQuantity AS Quantity,

4 dm.MaterialName AS Material,

5 dm.Type AS MaterialType,

6 dm.Form AS MaterialForm,

7 dmp.MaterialName AS ParentMaterial,

8 dmp.Type AS ParentMaterialType,

9 dmp.Form AS ParentMaterialForm,

10 dmh.Description AS MaterialHierarchy,

11 da.AreaName AS Area,

12 dst.StepName AS Step,

13 dst.StepType,

14 dst.PrimaryUnits AS StepPrimaryUnits,

15 dst.SecondaryUnits AS StepSecondaryUnits,

16 dp.ProductName AS Product,

17 dp.Type AS ProductType,

18 dp.Description AS ProductDescription,

19 dfl.FlowName AS Flow,

20 dfl.Type AS FlowType,

21 dr.ResourceName AS Resource,

22 dr.Type AS ResourceType,

23 dr.Model AS ResourceModel,

24 dr.Description AS ResourceDescription,

25 de.UserName AS Employee,

26 de.UserAccount AS EmployeeAccount,

27 dsd.FullDateAlternateKey AS ShiftDate,

61

Vistas sobre o DW

28 dsd.DayNameOfWeek AS ShiftDateWeek,

29 dsd.MonthName AS ShiftDateMonth,

30 dsd.DayNumberOfMonth AS ShiftDateDay,

31 dsd.CalendarYear AS ShiftDateYear,

32 dd.FullDateAlternateKey AS UTCDate,

33 dd.DayNameOfWeek AS UTCDateWeek,

34 dd.MonthName AS UTCDateMonth,

35 dd.DayNumberOfMonth AS UTCDateDay,

36 dd.CalendarYear AS UTCDateYear,

37 dt.Hour24 AS UTCTimeHour,

38 dt.Minute24 AS UTCTimeMinute,

39 dt.Time24 AS UTCTime,

40 dt.Second AS UTCTimeSecond,

41 dse.ServiceName AS Service,

42 dse.ServiceContractName AS ServiceContract,

43 do.OperationName AS Operation,

44 do.EntityName AS OperationEntity,

45 ddl.FullDateAlternateKey AS LocalDate,

46 ddl.DayNameOfWeek AS LocalDateWeek,

47 ddl.MonthName AS LocalDateMonth,

48 ddl.DayNumberOfMonth AS LocalDateDay,

49 ddl.CalendarYear AS LocalDateYear,

50 dtl.Hour24 AS LocalTimeHour,

51 dtl.Minute24 AS LocalTimeMinute,

52 dtl.Time24 AS LocalTime,

53 dtl.Second AS LocalTimeSecond,

54 dfa.FacilityName AS Facility,

55 dmr.MaterialName AS RelatedMaterial,

56 dmr.Type AS RelatedMaterialType,

57 dmr.Form AS RelatedMaterialForm,

58 dms.MaterialStateName AS MaterialState,

59 dte.Name AS Team,

60 dte.Description AS TeamDescription,

61 dsh.ShiftDefinitionName,

62 dsh.ShiftDefinitionShiftName,

63 dsh.StartTime AS ShiftStartTime,

64 dsh.EndTime AS ShiftEndTime

65 FROM dbo.FactMaterial AS fm

66 INNER JOIN dbo.DimMaterial AS dm ON fm.MaterialKey = dm.MaterialKey

67 INNER JOIN dbo.DimMaterial AS dmp ON fm.ParentMaterialKey = dmp.MaterialKey

68 INNER JOIN dbo.DimMaterialHierarchy AS dmh ON fm.MaterialHierarchyKey = dmh

.MaterialHierarchyKey

69 INNER JOIN dbo.DimArea AS da ON fm.AreaKey = da.AreaKey

70 INNER JOIN dbo.DimStep AS dst ON fm.StepKey = dst.StepKey

71 INNER JOIN dbo.DimProduct AS dp ON fm.ProductKey = dp.ProductKey

72 INNER JOIN dbo.DimFlow AS dfl ON fm.FlowKey = dfl.FlowKey

73 INNER JOIN dbo.DimResource AS dr ON fm.ResourceKey = dr.ResourceKey

74 INNER JOIN dbo.DimEmployee AS de ON fm.EmployeeKey = de.EmployeeKey

75 INNER JOIN dbo.DimDate AS dsd ON fm.ShiftDateKey = dsd.DateKey

62

Vistas sobre o DW

76 INNER JOIN dbo.DimDate AS dd ON fm.DateKey = dd.DateKey

77 INNER JOIN dbo.DimTime AS dt ON fm.TimeKey = dt.TimeKey

78 INNER JOIN dbo.DimService AS dse ON fm.ServiceKey = dse.ServiceKey

79 INNER JOIN dbo.DimOperation AS do ON fm.OperationKey = do.OperationKey

80 INNER JOIN dbo.DimDate AS ddl ON fm.LC1DateKey = ddl.DateKey

81 INNER JOIN dbo.DimTime AS dtl ON fm.LC1TimeKey = dtl.TimeKey

82 INNER JOIN dbo.DimFacility AS dfa ON da.FacilityKey = dfa.FacilityKey

83 INNER JOIN dbo.DimMaterial AS dmr ON fm.RelatedMaterialKey = dmr.

MaterialKey

84 INNER JOIN dbo.DimMaterialState AS dms ON fm.MaterialStateKey = dms.

MaterialStateKey

85 INNER JOIN dbo.DimTeam AS dte ON fm.TeamKey = dte.TeamKey

86 INNER JOIN dbo.DimShift AS dsh ON fm.ShiftKey = dsh.ShiftKey

87 WHERE (fm.UTCDatetime > DATEADD(day, - 28, GETUTCDATE()))

A.2 Vista Individual (Pós-junção)

É mostrado em seguida o código SQL de cada vista sobre cada dimensão da tabela de factos

FactMaterial. Importa relembrar que existem algumas vistas para a mesma dimensão devido a não

ser possível ter cada vista mais que uma vez na fonte de dados do Syncfusion. No entanto, essas

vistas também têm a coluna da chave com um nome igual ao da tabela de factos para ser mais fácil

descobrir as relações.

V_DimArea_Single

1 SELECT AreaKey, FacilityKey, AreaName AS Area

2 FROM dbo.DimArea AS da

V_DimEmployee_Single

1 SELECT EmployeeKey, UserName AS Employee, UserAccount AS EmployeeAccount

2 FROM dbo.DimEmployee AS de

V_DimFacility_Single

1 SELECT FacilityKey, FacilityName AS Facility

2 FROM dbo.DimFacility AS dfa

63

Vistas sobre o DW

V_DimFlow_Single

1 SELECT FlowKey, FlowName AS Flow, Type AS FlowType

2 FROM dbo.DimFlow AS dfl

V_DimLocalDate_Single

1 SELECT DateKey AS LocalDateKey,

2 FullDateAlternateKey AS LocalDate,

3 DayNameOfWeek AS LocalDateWeek,

4 MonthName AS LocalDateMonth,

5 DayNumberOfMonth AS LocalDateDay,

6 CalendarYear AS LocalDateYear

7 FROM dbo.DimDate AS ddl

V_DimLocalTime_Single

1 SELECT TimeKey AS LocalTimeKey,

2 Hour24 AS LocalTimeHour,

3 Minute24 AS LocalTimeMinute,

4 Time24 AS LocalTime,

5 Second AS LocalTimeSecond

6 FROM dbo.DimTime AS dtl

V_DimMaterial_Single

1 SELECT MaterialKey,

2 MaterialName AS Material,

3 Type AS MaterialType,

4 Form AS MaterialForm

5 FROM dbo.DimMaterial AS dm

V_DimMaterialHierarchy_Single

1 SELECT MaterialHierarchyKey, Description AS MaterialHierarchy

2 FROM dbo.DimMaterialHierarchy AS dmh

V_DimMaterialState_Single

1 SELECT MaterialStateKey, MaterialStateName AS MaterialState

2 FROM dbo.DimMaterialState AS dms

64

Vistas sobre o DW

V_DimOperation_Single

1 SELECT OperationKey, OperationName AS Operation, EntityName AS OperationEntity

2 FROM dbo.DimOperation AS do

V_DimParentMaterial_Single

1 SELECT MaterialKey AS ParentMaterialKey,

2 MaterialName AS ParentMaterial,

3 Type AS ParentMaterialType,

4 Form AS ParentMaterialForm

5 FROM dbo.DimMaterial AS dmp

V_DimProduct_Single

1 SELECT ProductKey,

2 ProductName AS Product,

3 Type AS ProductType,

4 Description AS ProductDescription

5 FROM dbo.DimProduct AS dp

V_DimRelatedMaterial_Single

1 SELECT MaterialKey AS RelatedMaterialKey,

2 MaterialName AS RelatedMaterial,

3 Type AS RelatedMaterialType,

4 Form AS RelatedMaterialForm

5 FROM dbo.DimMaterial AS dmr

V_DimResource_Single

1 SELECT ResourceKey,

2 ResourceName AS Resource,

3 Type AS ResourceType,

4 Model AS ResourceModel,

5 Description AS ResourceDescription

6 FROM dbo.DimResource AS dr

V_DimService_Single

1 SELECT ServiceKey, ServiceName AS Service, ServiceContractName AS ServiceContract

2 FROM dbo.DimService AS dse

65

Vistas sobre o DW

V_DimShift_Single

1 SELECT ShiftKey,

2 ShiftDefinitionName,

3 ShiftDefinitionShiftName,

4 StartTime AS ShiftStartTime,

5 EndTime AS ShiftEndTime

6 FROM dbo.DimShift AS dsh

V_DimShiftDate_Single

1 SELECT DateKey AS ShiftDateKey,

2 FullDateAlternateKey AS ShiftDate,

3 DayNameOfWeek AS ShiftDateWeek,

4 MonthName AS ShiftDateMonth,

5 DayNumberOfMonth AS ShiftDateDay,

6 CalendarYear AS ShiftDateYear

7 FROM dbo.DimDate AS dsd

V_DimStep_Single

1 SELECT StepKey,

2 StepName AS Step,

3 StepType,

4 PrimaryUnits AS StepPrimaryUnits,

5 SecondaryUnits AS StepSecondaryUnits

6 FROM dbo.DimStep AS dst

V_DimTeam_Single

1 SELECT TeamKey, Name AS Team, Description AS TeamDescription

2 FROM dbo.DimTeam AS dte

V_DimUTCDate_Single

1 SELECT DateKey AS UTCDateKey,

2 FullDateAlternateKey AS UTCDate,

3 DayNameOfWeek AS UTCDateWeek,

4 MonthName AS UTCDateMonth,

5 DayNumberOfMonth AS UTCDateDay,

6 CalendarYear AS UTCDateYear

7 FROM dbo.DimDate AS dd

66

Vistas sobre o DW

V_DimUTCTime_Single

1 SELECT TimeKey AS UTCTimeKey,

2 Hour24 AS UTCTimeHour,

3 Minute24 AS UTCTimeMinute,

4 Time24 AS UTCTime,

5 Second AS UTCTimeSecond

6 FROM dbo.DimTime AS dt

É mostrado em seguida o código SQL da vista sobre a tabela de factos FactMaterial. Depois

das três primeiras colunas com a data na hora local, a data em UTC e a quantidade, todas as

restantes são chaves para associar às vistas anteriores.

V_FactMaterial_Single_Last4Weeks

1 SELECT LC1DateTime AS Date,

2 UTCDatetime AS DateUTC,

3 PrimaryQuantity AS Quantity,

4 MaterialKey,

5 ParentMaterialKey,

6 MaterialHierarchyKey,

7 AreaKey,

8 StepKey,

9 ProductKey,

10 FlowKey,

11 ResourceKey,

12 EmployeeKey,

13 ShiftDateKey,

14 DateKey AS UTCDateKey,

15 TimeKey AS UTCTimeKey,

16 ServiceKey,

17 OperationKey,

18 LC1DateKey AS LocalDateKey,

19 LC1TimeKey AS LocalTimeKey,

20 RelatedMaterialKey,

21 MaterialStateKey,

22 TeamKey,

23 ShiftKey

24 FROM dbo.FactMaterial AS fm

25 WHERE (UTCDatetime > DATEADD(day, - 28, GETUTCDATE()))

67

Vistas sobre o DW

É mostrado em seguida o código SQL utilizado para seleccionar todos os dados presentes

nestas vistas de forma a obter um dataset igual ao da pré-junção.

1 SELECT [Date],

2 [DateUTC],

3 [Quantity],

4 [Material],

5 [MaterialType],

6 [MaterialForm],

7 [ParentMaterial],

8 [ParentMaterialType],

9 [ParentMaterialForm],

10 [MaterialHierarchy],

11 [Area],

12 [Step],

13 [StepType],

14 [StepPrimaryUnits],

15 [StepSecondaryUnits],

16 [Product],

17 [ProductType],

18 [ProductDescription],

19 [Flow],

20 [FlowType],

21 [Resource],

22 [ResourceType],

23 [ResourceModel],

24 [ResourceDescription],

25 [Employee],

26 [EmployeeAccount],

27 [ShiftDate],

28 [ShiftDateWeek],

29 [ShiftDateMonth],

30 [ShiftDateDay],

31 [ShiftDateYear],

32 [UTCDate],

33 [UTCDateWeek],

34 [UTCDateMonth],

35 [UTCDateDay],

36 [UTCDateYear],

37 [UTCTimeHour],

38 [UTCTimeMinute],

39 [UTCTime],

40 [UTCTimeSecond],

41 [Service],

42 [ServiceContract],

43 [Operation],

44 [OperationEntity],

45 [LocalDate],

68

Vistas sobre o DW

46 [LocalDateWeek],

47 [LocalDateMonth],

48 [LocalDateDay],

49 [LocalDateYear],

50 [LocalTimeHour],

51 [LocalTimeMinute],

52 [LocalTime],

53 [LocalTimeSecond],

54 [Facility],

55 [RelatedMaterial],

56 [RelatedMaterialType],

57 [RelatedMaterialForm],

58 [MaterialState],

59 [Team],

60 [TeamDescription],

61 [ShiftDefinitionName],

62 [ShiftDefinitionShiftName],

63 [ShiftStartTime],

64 [ShiftEndTime]

65 FROM [cmNavigoDWH].[dbo].[V_FactMaterial_Single_Last4Weeks] fm

66 INNER JOIN [V_DimArea_Single] da ON fm.AreaKey=da.AreaKey

67 INNER JOIN [V_DimEmployee_Single] de ON fm.EmployeeKey=de.EmployeeKey

68 INNER JOIN [V_DimFacility_Single] dfa ON da.FacilityKey = dfa.FacilityKey

69 INNER JOIN [V_DimFlow_Single] dfl ON fm.FlowKey = dfl.FlowKey

70 INNER JOIN [V_DimLocalDate_Single] dld ON fm.LocalDateKey = dld.LocalDateKey

71 INNER JOIN [V_DimLocalTime_Single] dlt ON fm.LocalTimeKey = dlt.LocalTimeKey

72 INNER JOIN [V_DimMaterial_Single] dm ON fm.MaterialKey = dm.MaterialKey

73 INNER JOIN [V_DimMaterialHierarchy_Single] dmh ON fm.MaterialHierarchyKey = dmh

.MaterialHierarchyKey

74 INNER JOIN [V_DimMaterialState_Single] dms ON fm.MaterialStateKey = dms.

MaterialStateKey

75 INNER JOIN [V_DimOperation_Single] do ON fm.OperationKey = do.OperationKey

76 INNER JOIN [V_DimParentMaterial_Single] dpm ON fm.ParentMaterialKey = dpm.

ParentMaterialKey

77 INNER JOIN [V_DimProduct_Single] dp ON fm.ProductKey = dp.ProductKey

78 INNER JOIN [V_DimRelatedMaterial_Single] drm ON fm.RelatedMaterialKey = drm.

RelatedMaterialKey

79 INNER JOIN [V_DimResource_Single] dr ON fm.ResourceKey = dr.ResourceKey

80 INNER JOIN [V_DimService_Single] dse ON fm.ServiceKey = dse.ServiceKey

81 INNER JOIN [V_DimShift_Single] dsh ON fm.ShiftKey = dsh.ShiftKey

82 INNER JOIN [V_DimShiftDate_Single] dsd ON fm.ShiftDateKey = dsd.ShiftDateKey

83 INNER JOIN [V_DimStep_Single] dst ON fm.StepKey = dst.StepKey

84 INNER JOIN [V_DimTeam_Single] dt ON fm.TeamKey = dt.TeamKey

85 INNER JOIN [V_DimUTCDate_Single] dud ON fm.UTCDateKey = dud.UTCDateKey

86 INNER JOIN [V_DimUTCTime_Single] dut ON fm.UTCTimeKey = dut.UTCTimeKey

69

Documents

Self-Service Business Intelligence - Repositório Aberto · Mestrado Integrado em Engenharia Informática e Computação Orientador: Professor Gabriel David 21 de Julho de 2016. Self-Service