Sistema de business intelligence numa empresa do setor têxtil

Henrique Silvério Ferreira Abreu Sistema de Business Intelligence numa empresa do setor têxtil Novembro de 2021 UMinho|2021 Sistema de Business Intelligence numa empresa do setor têxtil Henrique Abreu 126 i Henrique Silvério Ferreira Abreu Sistema de Business Intelligence numa empresa do setor têxtil Dissertação de Mestrado Mestrado em Engenharia de Sistemas Trabalho realizado sob a orientação do Professor Doutor Paulo Sérgio Lima Pereira Afonso novembro de 2021 ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição-NãoComercial-SemDerivações CC BY-NC-ND https://creativecommons.org/licenses/by-nc-nd/4.0/ iii AGRADECIMENTOS Para a realização deste projeto, aproveito esta ocasião para agradecer às pessoas que me auxiliaram para a conclusão do mesmo, pois sem elas, isto não seria possível. Agradeço ao Professor Doutor Paulo Sérgio Lima Afonso, pela orientação prestada no desfecho desta etapa académica. Agradeço ao Luís Pedro, Carlos Leite e ao Leonardo Sousa, amigos que em particular, me auxiliaram com o apoio técnico e paciência na construção de algumas etapas no projeto. Agradeço à minha família pelo apoio e motivação a realizar este trajeto. Agradeço aos colaboradores da LEIPER pelo acolhimento e pela oportunidade prestada, para o âmbito deste projeto. Agradeço a todos os meus amigos e colegas pelas experiências vividas. A todos, um grande obrigado! iv DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. v Sistema de Business Intelligence numa empresa do setor têxtil RESUMO Num contexto de mercado, cada vez mais volátil, a gestão estratégica predomina através da formulação de decisões, que afetam os processos da organização. Por vezes, estas decisões podem se revelar como tardias e até mesmo mal fundamentadas, por existirem muitas variáveis que condicionam as atividades de gestão. Os sistemas de Business Intelligence conferem informação atualizada, configurada e ao dispor, em qualquer momento, para o decisor analisar. Neste projeto de dissertação, procedeu-se ao desenvolvimento de um sistema de Business Intelligence , num contexto empresarial. Num primeiro momento, procedeu-se ao levantamento dos requisitos a cumprir e à recolha dos dados, para assegurar que a informação disponibilizada cumpria as necessidades. De seguida, modelou-se um Data Warehouse capaz de armazenar toda a informação operacional, bem como um processo de ETL que, desde a fonte até às tabelas criadas, transforma os dados para satisfazer as necessidades estabelecidas e tratar de problemas associados aos sistemas transacionais. Por fim, foi desenvolvido um dashboard que evidenciasse as métricas construídas, disponibilizando a informação de uma forma resumida para facilitar o processo de tomada de decisão. Já com toda a estrutura criada, foi efetuada uma breve análise a alguns tópicos adquiridos. Todavia, recomenda-se que, para a implementação do sistema, seja estabelecida uma ligação direta com a base de dados interna, conferindo assim a propriedade de autonomia ao sistema. Palavras-Chave: Business Intelligence , Armazém de Dados, Relatórios , Tomada de Decisão vi Business Intelligence System in a textile company ABSTRACT In an increasingly volatile market context, strategic management predominates through the formulation of decisions, which affect the organization's processes. Sometimes, these decisions can turn out to be late and even poorly founded, because there are many variables that condition the management’s activities. Business Intelligence systems provide updated, configured and available information, at any time, for the decision maker to analyze. In this dissertation project, a Business Intelligence system was developed, in a business context. Initially, a survey of requirements and a collection of data were proceeded, to ensure that the information made available complied with the needs. Then, it was modeled a Data Warehouse, capable of storing all operational information, as well as an ETL process capable of, from the source of the data, to the created tables, transform the data to satisfy the established needs and deal with problems from the transactional systems. Finally, a dashboard was developed to evince the constructed metrics, providing the information in a summarized form to facilitate the decision making process. With all the structure created, a brief analysis was made on some acquired topics. However, it is recommended that, for the implementation of the system, it should include a direct link to the internal database, thus giving the system the autonomy property. Keywords: Business Intelligence , Data Warehouse, Decision Making , Reporting vii ÍNDICE Agradecimentos .................................................................................................................................. iii Resumo............................................................................................................................................... v Abstract.............................................................................................................................................. vi Lista de Abreviaturas, Siglas e acrónimos ............................................................................................. x Lista de Figuras .................................................................................................................................. xi Lista de Tabelas ............................................................................................................................... xiii 1. Introdução .................................................................................................................................. 1 Enquadramento .................................................................................................................. 1 Objetivos ............................................................................................................................. 2 Metodologia ........................................................................................................................ 2 Estrutura da dissertação ...................................................................................................... 3 2. Revisão da literatura ................................................................................................................... 4 Gestão Estratégica .............................................................................................................. 4 2.1.1 Conceito de Gestão Estratégica .................................................................................... 4 2.1.2 ERP ............................................................................................................................. 5 2.1.3 Tomada de Decisão ..................................................................................................... 6 2.1.4 Indicadores Chave de Desempenho ............................................................................. 8 Business Intelligence ........................................................................................................... 9 2.2.1 Conceito de Business Intelligence ................................................................................ 9 2.2.2 Processo ETL ............................................................................................................ 11 2.2.3 Data Warehouse ........................................................................................................ 12 2.2.3.1 Sistema OLAP .................................................................................................... 12 2.2.3.2 Sistema OLTP .................................................................................................... 13 2.2.3.3 Modelação OLAP e Modelação OLTP .................................................................. 13 2.2.3.4 Arquiteturas ....................................................................................................... 14 2.2.3.5 Esquemas.......................................................................................................... 15 2.2.3.6 Dimensão com Alteração Lenta .......................................................................... 18 2.2.4 Reporting ................................................................................................................... 24 1 1. INTRODUÇÃO Este projeto de dissertação, foi desenvolvido no âmbito do curso de Mestrado em Engenharia de Sistemas, perante um estágio curricular, na empresa LEIPER® - Thinking Home Textiles . Neste capítulo, é discutido o enquadramento do projeto, os objetivos propostos, a metodologia utilizada e a representação da estrutura da dissertação. Enquadramento Com o avanço da tecnologia, as empresas procuram descobrir, como incorporar estes ao seu negócio e que proveito pode ser retirado, a fim de desfrutar de vantagens organizacionais, num mercado cada vez mais competitivo. Segundo Luhn (1958), a informação tem vindo a ser gerada e utilizada a um ritmo cada vez mais crescente. Ao mesmo tempo, o crescimento das organizações criou novas barreiras à circulação da informação (Luhn, 1958). Atualmente, e nos últimos anos, a informação continua a ser descrita como um fator fundamental na tomada de decisão nas empresas com forte impacto nos lucros (Primak, 2008). O Business Intelligence (BI), é um instrumento de apoio ao processo de tomada de decisão. Segundo Watson (2007), uma das prioridades é transformar a informação existente e disponibilizá-la de uma forma estruturada, providenciando conhecimento efetivo sobre o negócio. A história do BI liga-se com a dos sistemas ERP, que representam sistemas integrados de gestão, com a função de facilitar o processo operacional da organização, através do registo, processamento e documentação de nova informação, distribuindo-a de uma forma clara, em tempo real (Primak, 2008). No entanto, as empresas reconhecem que, somente armazenar grandes quantidades de dados, não é suficiente, porque a informação encontra-se disposta de uma forma incompleta, repetida e dispersa pelos sistemas organizacionais (Primak, 2008). Através da abordagem do Business Intelligence , este problema pode ser resolvido, através da combinação de várias tecnologias que permitem moldar um repositório central de dados, sendo esta uma base de dados relacional, fora do ambiente transacional e, um interface de relatórios, que servirá para a realização das análises pelo utilizador final, de uma forma automática e periodicamente atualizada. 2 É neste contexto que surge este projeto de mestrado. A empresa LEIPER, sentia a falta de algo que combinasse a informação existente nas várias fontes de dados da empresa. Deste modo, desenvolveu-se um processo de estudo, modelação e implementação de um sistema de Business Intelligence , capaz de corresponder às expetativas da organização, baseado na informação registada diariamente nos processos operacionais. Objetivos O projeto de dissertação teve como principal objetivo o desenvolvimento de um sistema de Business Intelligence , capaz de tratar da informação e disponibilizar relatórios atualizados da situação atual da empresa. Neste contexto, foram estabelecidos alguns objetivos complementares: • Definição de um modelo multidimensional para armazenar a informação; • Desenvolver as etapas de ETL que permitam extrair, transformar e carregar os dados no modelo multidimensional; • Desenvolver uma aplicação de relatórios, que permita a pesquisa e análise da informação. Metodologia A metodologia de investigação usada neste projeto denomina-se por investigação-ação. Segundo Reason & Bradury (2001), esta metodologia combina a prática e a teoria para responder a um problema ou necessidade organizacional. Stringer (2008) define-a como uma abordagem sistemática de investigação que permite procurar soluções efetivas para problemas de diferentes naturezas. Esta metodologia enquadra-se em situações relacionadas com a tomada de decisão, tendo como finalidade solucionar algum problema, sendo a mesma baseada em análises provenientes de dados ou da análise de processos. Este projeto de mestrado foi elaborado atendendo à identificação de um problema de diversificação de informação e à necessidade de analisar a mesma, sob a forma de relatórios interativos. O processo de investigação-ação iniciou-se com o levantamento dos requisitos para a determinação da informação essencial a ser trabalhada. De seguida, procedeu-se à modelação multidimensional que permite sedimentar toda a informação recolhida. Por fim, foi necessário desenvolver uma estrutura de reporting capaz de fornecer conhecimento acerca dos requisitos previamente estabelecidos. 3 Estrutura da dissertação Este documento apresenta-se estruturado em sete capítulos, sendo o presente capítulo, uma redação introdutória do propósito do projeto, dos objetivos propostos e da metodologia utilizada na investigação. De seguida, no Capítulo 2, são descritos os principais conceitos que suportam o projeto, nomeadamente em termos de gestão estratégica e Business Intelligence . No Capítulo 3 são apresentadas as ferramentas tecnológicas usadas no desenvolvimento do sistema, assim como o endereço web que permite o download da solução desenvolvida. No Capítulo 4 é feita uma breve apresentação da empresa e dos produtos que comercializa, fazse a descrição dos requisitos levantados, e apresenta-se uma visão da exploração dos dados e o desenho do sistema desenvolvido. No Capítulo 5 é explicado o sistema desenvolvido, o que compreende a modelação do sistema, o retrato do processo ETL, a representação dos cubos OLAP e a ferramenta de construção de relatórios delineada. No Capítulo 6 é apresentada uma análise aos dados obtidos. Por fim, são destacadas as conclusões principais e considerações acerca do sistema desenvolvido, terminando com algumas sugestões para desenvolvimentos futuros. 4 2. REVISÃO DA LITERATURA Neste capítulo, é descrito os principais temas que compõem todo o trabalho deste projeto. Os temas enquadram-se nas temáticas de gestão estratégica e business intelligence , dando especial foco neste último tema. Por fim, é apresentado um exemplo do produto final, pretendido na realização do projeto. Gestão Estratégica 2.1.1 Conceito de Gestão Estratégica Num mundo cada vez mais competitivo, as empresas procuram novas formas de realizar o negócio e desenvolvem ações para dotar-se de maior capacidade competitiva face aos rivais na indústria onde operam. Isto pode ser conseguido com a modernização da tecnologia empregue, melhoramentos de processos, planeamento de ações de melhoria a vários níveis na empresa e um melhor controlo dos vários fluxos que caraterizam a empresa. Figura 1 - Esquema de Gestão Estratégica. Figura adaptada de Giian Victor (2015). A gestão estratégica pretende contribuir para a organização da empresa na prossecução dos seus objetivos, projetando e coordenando as ações a realizar para que os objetivos esboçados sejam atingidos. Segundo Santos (2008), a gestão estratégica diz respeito a um processo contínuo e dinâmico de planeamento, organização, liderança e controlo, através do qual, as organizações atuam em 5 conformidade com o caminho traçado, ajustando-o continuamente às alterações ocorridas no seu meio envolvente. O gestor ou o analista necessitam, então, de analisar várias informações e qual o impacto que estas causam à organização, quer globalmente quer nas diferentes áreas funcionais: marketing , vendas, produção, logística, entre outras. É uma atividade de bastante responsabilidade pois as decisões deliberadas e implementadas vão afetar a empresa e, subsequentemente, a forma como esta é vista no mercado. Para a formulação de decisões, a informação necessita de estar constantemente disponível, bem estruturada e permitindo uma interpretação clara, para que seja possível tomar medidas acertadas e responder a problemas com impacto no médio e longo prazo e outros que surgem no dia-a-dia da organização. 2.1.2 ERP Na ótica de gestão de dados, é frequente encontrar nas empresas sistemas integrados de gestão empresarial ERP ( Enterprise Resource Planning ), habitualmente denominados de sistemas de informação, para auxiliar no processamento dos dados diários e de suporte ao trabalho a realizar. Normalmente, estes sistemas são criados e implementados de uma forma padrão, com base em ambientes reais e abrangem todo o negócio, facilitando a comunicação entre filiais da mesma empresa, quando estas existem. Segundo Laudon e Laudon (1996), estes sistemas podem ser definidos por um conjunto de componentes que recebem dados, introduzidos pelos colaboradores, processam, armazenam e distribuem informação com o objetivo de auxiliar no controlo e tomada de decisões da organização. Este tipo de ferramentas são a primeira base de consulta de informação do negócio e traduzemse em várias vantagens para os seus utilizadores. No caso dos operários, estes podem verificar as encomendas realizadas, o planeamento das ordens de fabrico, o stock dos produtos, entre várias outras informações relacionadas com os produtos. Para os gerentes ou membros de hierarquia mais alta, a importância maior é atribuída aos módulos financeiros do sistema e à informação de natureza estratégica que permite compreender o comportamento geral da empresa e dos produtos ao longo do ano. Segundo Mesquita (2000), estes sistemas abrangem vários setores da organização e, por este facto, apresentam algumas vantagens como: 6 • Atomicidade de dados: esta propriedade corresponde à inexistência de dados parciais após a realização de uma tarefa. Ao retirar um valor num campo, significa somar noutro campo; • Reorganização dos processos da organização: diz respeito ao agrupamento de tópicos por processos organizacionais; • Eliminação de processos manuais: redução da informação física da organização (arquivos, folhas); • Controlo do ciclo produtivo: oferecer diagnósticos sobre o processo produtivo. Já no caso das desvantagens, o mesmo autor indica: • Custos elevados: a aquisição do sistema requere esforço financeiro, como licenças, hardware; • Implementação complexa: a implementação do software pode necessitar de requisitos adicionais para retirar o melhor proveito do mesmo; • Complexidade de personalização: os sistemas normalmente são criados de uma forma padrão, o que pode causar transtornos quando este não consegue satisfazer algum novo requisito ou estrutura adicional em módulos que não satisfaça a organização. Com isto podemos verificar a importância de um sistema ERP e como este fornece informação de grande utilidade para a gestão das empresas. Para além disto, esta é uma ferramenta que ajuda bastante no que toca à tomada de decisão pela harmonização de setores e empresas sob um conjunto de regras comuns de gestão do negócio. 2.1.3 Tomada de Decisão A tomada de decisão é um processo de ponderação de várias alternativas e a escolha de uma dessas alternativas, com o objetivo de melhorar algo. Geralmente estas atividades são da responsabilidade dos gestores de topo e de alguns gestores intermédios. Por exemplo, determinados gestores de nível operacional (e.g., produção), pelo facto destas pessoas trabalharem questões que visam o melhoramento dos resultados organizacionais ou da eficiência de fabrico. 7 É um processo que exige que a informação seja pertinente, e que os parâmetros de análise estejam corretos pois, dados incorretos ou análises incorretas prejudicam o estado da empresa e não servem para promover a eficiência nem a competitividade da mesma. Segundo Chiavenato (1983), deparamo-nos com dois tipos de decisões, nomeadamente a decisão não programada, que é uma decisão única e singular que representa uma novidade, e a decisão programada, que é uma decisão de rotina que pode ser transformada em um procedimento definitivo, rotineiro e sistemático. Tabela 1 - Tipos de Decisão. Tabela adaptada de Chiavenato. (1983). Tipos de decisões Técnicas de tomada de decisão Tradicionais Modernas Programadas Hábito Decisões repetitivas Rotina Investigação operacional de rotina (procedimentos Análise matemática padronizados de Modelos, Simulação ação) Estrutura Decisões através de organizacional processos (Sistema de Processamento específicos objetivos, Canais de eletrónico de dados estabelecidos pela comunicação bem organização definidos) Não-programadas Decisões de Julgamento, intuitivo Técnicas heurísticas momento, mal e criativo. Regras de solução de estruturadas e de empíricas. Seleção e problemas aplicados novas políticas formação de executivos a: Decisões tratadas a) Formação de pelos processos homens p/decisões. gerais de solução de problemas b) Estabelecimento de programas heurísticos para computador A realização de uma análise concisa tem que corresponder à ponderação das alternativas possíveis de modo a apurar a que melhor se ajusta às necessidades da ação. Para este efeito, a escolha dos parâmetros para análise é imperativa, pois estes irão servir de base de fundamento para a forma como se representa o ambiente real do problema. 8 2.1.4 Indicadores Chave de Desempenho Indicadores chave de desempenho ou KPI (do inglês Key Perfomance Indicators ) são os parâmetros de medida que refletem a atividade da empresa e os aspetos que impactam essa atividade, a fim de melhorar o desempenho de um problema ou de um setor na área da empresa. A importância de incorporar vários KPI, revela-se no facto de estes serem o cálculo de um processo ou algo de valor de uma forma regular. A construção dos mesmos é uma tarefa árdua pois, inicialmente, deve-se fazer um estudo de quais os que melhor representam a tarefa a ser avaliada. De acordo com Shahin (2007), o critério para a construção de um KPI assenta na metodologia SMART. Este é um acrónimo em inglês de Specific , Measurable , Achievable , Realistic , Timely (Figura 2). Figura 2 - Representação da metodologia SMART. Figura adaptada de Patel (2020). • Específico: Os objetivos devem ser detalhados e específicos se possível. Desta forma, é mais acessível indicar os progressos aos trabalhadores; • Mensurável: As medidas devem ser de um cariz numérico e concreto, quer seja quantitativo ou qualitativo; • Realizável: Devem ser justos e aceitáveis, sem estarem fora do raio de alcance; • Realista: Estendido do ponto anterior, devem ser orientados a resultados; • Temporal: Devem ter um intervalo de tempo para a sua conclusão, de forma a verificar o seu progresso. Após a formulação dos KPI, estes serão implementados sob os processos e a informação adquirida e, cabe ao responsável analisar estes fatores e demonstrar qual o impacto que estes traduzem na progressão e cumprimento dos objetivos. 9 Business Intelligence 2.2.1 Conceito de Business Intelligence O conceito de Business Intelligence , do inglês inteligência de negócio, refere-se à análise de dados de setores específicos de uma organização ou a visão total da mesma, proporcionando suporte aos gestores e às suas decisões. Santos & Ramos (2006) indicam que, os sistemas de Business Intelligence combinam a extração/recolha de dados, o armazenamento dos mesmos e, através de ferramentas de análise, extrair informações vantajosas para o conhecimento da organização. As mesmas autoras comentam que, as tarefas associadas aos ambientes de Business Intelligence são: • Elaborar previsões baseadas nos dados históricos e atuais da organização; • Criar cenários que demonstrem o impacto de várias variáveis; • Permitir acesso aos dados com a finalidade de responder a questões não pré-definidas; • Analisar a organização, retirando um conhecimento profundo da mesma. Com o que foi descrito, está evidenciado que um sistema de Business Intelligence fornece bastante utilidade para uma organização. No entanto, para além de transmitir informações na forma de análises do negócio, uma vantagem destes sistemas encontra-se na forma como estes são implementados, nomeadamente a automatização do mesmo. Esta última parte significa que, desde a etapa de recolha de dados até à elaboração de relatórios para análise, este é um processo autónomo e constantemente atualizado com as informações históricas da empresa, quando corretamente construído. Para facilitar a implementação destes sistemas, a Figura 3 ilustra as etapas para a construção do mesmo. 10 Figura 3 - Modelo genérico de um projeto de Business Intelligence. Figura adaptada de Chaudhuri (1997). Na Figura 3, destacam-se as fases de um projeto de Business Intelligence , nomeadamente a fonte de dados, processo ETL, Data Warehouse , Cubos OLAP e Reporting . 1. Fonte de dados: Diz respeito à origem da informação adquirida. Esta pode ser obtida através de uma base de dados interna, em ERP ou em ficheiros externos como ficheiros EXCEL, CSV, TXT, entre outros. 2. Processo ETL: Corresponde ao fluxo que é aplicado à informação, desde a sua extração das fontes até ao carregamento das mesmas nas tabelas de destino. Durante o fluxo, são conferidas propriedades à informação, de acordo com as especificações discutidas com o utilizador final. 3. Data Warehouse : Este ambiente é a fase final do fluxo da informação, onde os dados, já transformados, são armazenados. 4. Cubos OLAP: Nesta etapa procede-se ao processamento de dados e a análise dos mesmos perante múltiplas perspetivas, sem perder desempenho computacional. 5. Reporting : Por fim, são desenvolvidos gráficos de forma a demonstrar, de uma forma simplificada e apelativa, o comportamento dos dados em apreço. É de salientar que cada tópico foi descrito de uma forma sintetizada. As etapas “ Data Warehouse ”, “Processo ETL”, “Cubos OLAP” e “ Reporting ” serão abordados extensivamente nos próximos capítulos pois, existem várias tecnologias aplicadas no seu desenvolvimento. 17 desempenho na consulta de queries . No entanto, este esquema apresenta uma desvantagem ao nível da não normalização das tabelas de dimensão, contendo a mesma informação repetida (Sousa, 2011). Ao contrário do anterior, a forma do diagrama do esquema SnowFlake , compara-se a um floco de neve, como demonstrado na Figura 8. Este considera-se uma extensão do esquema anterior pois, apresenta uma tabela de factos no meio do diagrama, ligado a várias tabelas de dimensão que, por sua vez, ligam-se a outras tabelas de dimensão, normalizando os dados para evitar redundância (dados repetidos). O princípio deste diagrama centra-se na normalização das tabelas de dimensão, removendo atributos com baixa cardinalidade, formando outras tabelas para os mesmos (Ponniah, 2011). Figura 8 - Snowflake Schema. Figura adaptada de Adamson (2010). Como este esquema adota a normalização das tabelas de dimensão, este adquire uma troca entre vantagem e desvantagem, comparativamente ao diagrama anterior. A vantagem revela-se na otimização do espaço físico em disco enquanto que a desvantagem, devido à normalização de tabelas, comprova-se no desempenho de join queries (Kimball & Ross, 2011), ou seja, na consulta onde é necessário juntar tabelas, para além da sua interpretação ser mais complexa. 18 O esquema Constelação é mais complexo que os esquemas anteriores (Edi, 2009). Como apresentado na seguinte Figura, este esquema contém várias tabelas de facto que, por sua vez, estão ligadas a tabelas de dimensão compartilhadas entre as mesmas. Figura 9 - Constellation Schema. Figura adaptada de Edi (2009). As vantagens deste esquema são, como no esquema anterior, a normalização das tabelas e um esquema flexível. As desvantagens são que este é mais complexo, difícil de implementar e de manter (Bhadauria, 2019). 2.2.3.6 Dimensão com Alteração Lenta Outro aspeto importante na conceção da modelação multidimensional, diz respeito à atualização dos dados caso algum agente do negócio da organização sofra alterações da sua informação. Isto diz respeito ao tratamento dos dados no carregamento das tabelas de dimensão, pois estas podem sofrer atualizações de informação, por exemplo, a localização de um cliente mudar, atualização de um produto, entre outros, ao passo que, as tabelas de facto já têm uma dimensão temporal explícita (Nguyen et al, 2007). Devido às tabelas de dimensão sofrerem alterações, ao longo do tempo, é necessário haver uma forma de registar estas mudanças para que não falhe a ligação com as tabelas de factos. Para isto, implementa-se o método de dimensão com alteração lenta ou SCD (do inglês Slowly Changing Dimension ). O propósito do mesmo é manter um registo histórico das dimensões e, enquanto as mesmas sofrem as alterações, não alterar a tabela de factos, fornecendo uma legitimidade aos dados (Kimball & Ross, 2011). 19 Neste âmbito, é inserido um novo conceito de chave, nomeadamente a chave substituta (do inglês surrogate key ). Estas chaves são números inteiros, atribuídos de forma sequencial, começando no valor 1, sempre que uma nova chave é necessária (Kimball & Ross, 2011), utilizando a terminologia SK. De acordo com Kimball & Ross (2011), o método de dimensão com alteração lenta, segue os seguintes tipos, sendo os tipos 1,2 e 3 os mais frequentemente utilizados: • Tipo 0 – Manter o original (Retain Original); • Tipo 1 - Escrever por cima (Overwrite); • Tipo 2 - Adicionar uma nova linha (Add New Row); • Tipo 3 - Adicionar um novo atributo/coluna à dimensão (Add New Attribute); • Tipo 4 - Adicionar uma pequena dimensão (Add Mini-Dimension); • Tipo 5 – Adicionar uma pequena dimensão e um tipo 1 Outrigger (Add Mini-Dimension and Type 1 Outrigger); • Tipo 6 – Adicionar atributos do Tipo 1 para dimensões do Tipo 2 (Add Type 1 Attributes to Type 2 Dimension); • Tipo 7 - Combinação do Tipo 1 com Tipo 2 em Dimensões (Dual Type 1 and Type 2 Dimensions). O tipo 0 corresponde a atributos da dimensão cuja a informação não muda, ou seja, mantém a sua originalidade (Ross, 2013). Um caso deste tipo de valores é a data de nascimento de um cliente ou colaborador da organização, pois é um valor que nunca é alterado. O tipo 1 é o mais simples de realizar pois apenas basta modificar o valor desejado. Esta técnica é utilizada em atributos que não demonstrem interesse em manter um registo histórico pois, com a aplicação do mesmo, não se garante um registo histórico após a atualização (Kimball & Ross, 2011). Um exemplo disto é demonstrado na Figura 10. Figura 10 - Tipo 1. 20 Já o tipo 2 corresponde à inserção de um novo registo atualizado. A identificação é feita através de duas chaves (chave primária e chave substituta), onde uma classifica o registo e a outra chave as alterações em causa, respetivamente. Desta forma é possível manter um registo histórico dos dados (Kimball & Ross, 2011), como é possível verificar na Figura 11. Figura 11 - Tipo 2. O tipo 3 consiste em adicionar um novo atributo para a atualização em questão. O valor é associado ao original e ao valor atualizado. Este tipo oferece periodicidade aos valores atualizados, no entanto encontra-se limitado pelas colunas criadas (Kimball & Ross, 2011). Um exemplo é apresentado na Figura 12. Figura 12 - Tipo 3. No caso do tipo 4, a tabela dimensão em questão é dividida em duas dimensões onde, uma regista a informação atual e a outra (pequena dimensão) regista o histórico da primeira dimensão, mantendo-se ambas ligadas à tabela de facto. Este tipo é utilizado quando a variação da informação é frequentemente atualizada (Kimball & Ross, 2011). Um exemplo deste caso é observado na Figura 13. 21 Figura 13 - Tipo 4. No tipo 5, é feita uma combinação do tipo 1 com o tipo 4. Acrescenta-se uma pequena dimensão ligada à dimensão base (sem que a ligação de ambas seja feita através da interação com a tabela de factos) e, na pequena dimensão, são realizadas as devidas atualizações (escrever por cima), caso a pequena dimensão corrente sofra mudanças ao longo do tempo (Kimball & Ross, 2011). Figura 14 - Tipo 5. Figura adaptada de Ross (2013). Já o tipo 6, como o tipo anterior, é uma combinação dos tipos 1,2 e 3, formando o número 6. Este é desenvolvido a partir do tipo 2, por incorporar os recentes valores na dimensão, para a tabela de factos poder ser filtrada ou agrupada pelos valores do tipo 2. Através desta técnica, os valores correntes são atualizados em todos os valores do tipo 2 (Ross, 2013). 22 Figura 15 - Tipo 6. Figura adaptada de Kimball & Ross (2011). Por fim, o tipo 7 funciona da mesma forma que o tipo 6, no entanto, é feito através de duas chaves, ao passo de fisicamente escrever por cima dos valores mais recentes. A tabela de factos está ligada com ambas as dimensões, onde a primeira dimensão corresponde a dados do tipo 2 e a segunda dimensão aos dados mais recentes (Ross, 2013). Figura 16 - Tipo 7. Figura adaptada de Ross (2013). 2.2.3.7 Granularidade Ainda no aspeto de modelação dimensional, a declaração do grão é um passo essencial no desenvolvimento das tabelas de facto e tabelas de dimensão. A granularidade determina o que cada linha de facto representa. Este deve ser declarado pois deve haver uma consistência de granularidade entre as dimensões e factos (Kimball & Ross, 2011). 23 O autor Silvers (2008) define a atomicidade do grão como a representação do nível de detalhe, profundidade da hierarquia ou precisão da medida a ser extraído pelo referido processo de negócio. O mesmo autor carateriza que: • Nível de detalhe: especificação e singularidade pelo que a informação se identifica no caso de uma entidade da organização ou a instância da entidade da organização; • Profundidade da hierarquia: especificação e singularidade no contexto da estrutura organizacional; • Precisão da medida: o uso de uma unidade de medida mais pequena (milímetros) é mais precisa que a utilização de uma unidade de medida maior (metros). Na seguinte Figura, encontra-se demonstrado o nível de detalhamento, conforme a granularidade da informação, de uma forma resumida. Figura 17 - Granularidade. Figura adaptada de Elias (2014). À medida que se desce na granularidade da informação, aumenta-se no detalhe da mesma, ou seja, é utilizado a operação Drill Down que significa a visualização dos dados em maior detalhe. Ao contrário do anterior, quando se aumenta a granularidade da informação, diminui-se o detalhe da mesma, ou seja, é utilizado a operação Roll Up que significa a visualização dos dados de uma forma sumarizada. Um exemplo destes casos concentra-se nos documentos de venda, ou seja, por meio de opção do utilizador final, na visualização dos dados, a situação de Drill Down representa os produtos por linha vendidos, ao passo que, a situação de Roll Up representa somente os totais dos produtos, custos adicionais, entre outros. 24 2.2.4 Reporting De acordo com Durcevic (2020), a fase de Business Intelligence Reporting é o processo de adquirir dados, com a utilização de software e ferramentas adequadas, para extrair perceções relevantes do negócio. Esta última etapa no desenvolvimento de um projeto de Business Intelligence , corresponde à elaboração de meios visuais para facilitar a interpretação da informação, ao ponto de monitorizar e manipular métricas, de forma a auxiliar no processo de tomada de decisão. No que concerne a ferramentas para a concessão de meios visuais de interpretação de dados, utilizam-se ferramentas de front-end que se definem por ser mecanismos de interface frontais que ligam o utilizador final com os processos anteriormente desenvolvidos. Nestas ferramentas são desenvolvidos os relatórios ( reports ) ou painéis de controlo ( dashboards ) que o utilizador final monitoriza e interpreta, a fim de tomar as suas decisões. A Figura 18 apresenta um exemplo. Figura 18 - Exemplo de um dashboard. Figura adaptada de Durcevic (2020). Na Figura anterior, encontra-se exposto um exemplo de um dashboard , onde a informação se encontra disponibilizada, de uma forma apelativa e acessível. Cada valor apresentado na Figura sugere um KPI relevante para o analisador e o desempenho que o mesmo possui ao longo do tempo. Desta forma, evidencia-se o poder da análise de um dashboard onde a capacidade para influenciar o negócio deve ter como base o fundamento das métricas do mesmo. 25 3. TECNOLOGIAS UTILIZADAS Neste capítulo, são descritas as tecnologias utilizadas no desenvolvimento deste projeto. É de notar que as tecnologias enumeradas de seguida, não são as únicas ferramentas capazes de efetuar o desenvolvimento de um projeto desta natureza. A opção pela utilização, das mesmas, recai na opção no desenvolvedor, ou então, na opção da própria organização (devido a custos, hardware ou familiarização/uso atual em relação a outras ferramentas). Star UML StarUML 1 é uma ferramenta sofisticada de modelação que suporta uma modelação concisa e rápida (Lee, 2020). Esta pertence à MKLab e é uma ferramenta, a partir do sufixo do nome “UML”, de linguagem de modelagem unificada (do inglês Unified Modeling Language ). Com esta ferramenta é possível desenvolver diagramas que irão corresponder aos sistemas a desenvolver. Normalmente, este tipo de software é usado como forma de apresentar, numa primeira referência, a estrutura que o projeto irá ter e se o mesmo assenta nos objetivos pretendidos pela organização. Deste modo, com o esquema visual da estrutura dos sistemas, é averiguado se este corresponde ao pretendido ou se necessita de acertos, a fim de sedimentar o trajeto para o seu desenvolvimento. Esta ferramenta oferece vários tipos de diagramas para exemplificar um sistema, porém para o âmbito deste projeto, foi utilizada a componente dos diagramas ER ( Entity-Relationship ), ou seja, para a apresentação dos modelos relacionais. SQL Server O Microsoft SQL Server 2 é um produto de base de dados relacional cliente-servidor onde, a sua linguagem de programação primária é o Transact-SQL, mais frequentemente denominada por T-SQL (Nielsen, 2011). É considerado um SGBD, sistema de gestão de base de dados relacional (do inglês, Data Base Management System , sigla DBMS). Este apresenta múltiplos serviços disponíveis, como se encontra exposto na Figura 19. 1 https://staruml.io/download 2 https://www.microsoft.com/pt-br/sql-server/sql-server-downloads 26 Figura 19 - Funções possíveis no SQL Server. Figura adaptada de Nielsen (2011). Microsoft SQL Server Management Studio Segundo vários contribuidores para a documentação do software, nomeadamente Ghanayem et al (2019), o Microsoft SQL Server Management Studio 3 é um ambiente integrado para gerir infraestruturas do SQL Server, onde combina vários grupos de ferramentas gráficas com um vasto número de editores de script , que disponibiliza acesso a desenvolvedores e administradores de SQL Server. Por outras palavras, este é um ambiente UI, interface do usuário (do inglês user interface ), que permite a visualização do explorador de objetos, editor de código e explorar tudo inerente ao SQL Server. É através do editor que os desenvolvedores conseguem gerir os servidores organizacionais, através da linguagem T-SQL. Dentro desta linguagem, existe três categorias pela qual os comandos da mesma podem ser caraterizados (Nielsen, 2011): • Linguagem de Manipulação de Dados (Data Manipulation Language, DML): Aqui entram os comandos Select, Insert, Update e Delete; • Linguagem de Definição de Dados (Data Definition Language, DDL): Já neste são os comandos Create, Alter, Drop. São formas de modificar as tabelas ou objetos da base de dados; 3 https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15 33 do documento, este é transferido para os colaboradores de ordem administrativa, onde esta informação é registada no segundo ERP. Por outro lado, para a área logística, somente é utilizado o ERP Primavera, onde são efetuados os registos de movimentação de stock . Já na área operacional, são utilizados dois ERP, sendo eles o Primavera e o VMP Plan em que, no segundo ERP, são efetuados os registos das ordens de fabrico e, como ambos estão ligados na mesma base de dados, esses mesmos registos ficam também guardados no primeiro ERP. Nesta área é de salientar que, existe uma outra fonte de dados, nomeadamente um ficheiro Excel, onde se encontra disposta a informação dos tempos de fabrico e a quantidade fabricada por colaborador e por máquina, com base em relatórios escritos em papel, pelos colaboradores da produção e redigido em formato digital (Excel). A abordagem aplicada neste contexto, foi a abordagem top-down a qual, com uma instrução inicial dos colaboradores, para o correto manuseamento e exploração dos programas ERP, permitiu interpretar e filtrar quais os dados que seriam tratados e quais os que seriam pertinentes na demonstração final do projeto. Através dos módulos dos programas, realizou-se a execução de views para visualizar a informação e exportou-se para um ficheiro Excel, para o seu posterior processamento e tratamento. Através das seguintes 3 Figuras, apresenta-se o estado, dos ficheiros de fonte de dados (neste caso os vários ficheiros Excel exportados), dos ambientes ERP da organização. É de salientar que os dados provenientes dos ERP Sage e Primavera compreendem um intervalo de tempo que compreende janeiro de 2019 a junho de 2020. Já para os dados ilustrados na Figura 24, compreendem toda a informação do ficheiro, independentemente da data. Figura 22 - Informação sobre o fornecedor, proveniente do ERP Sage. 34 Figura 23 - Informação sobre o produto, proveniente do ERP Primavera. Figura 24 - Informação à cerca do controlo da produção. Através da análise dos mesmos, verificou-se a existência de algumas anomalias nos dados, nomeadamente problemas de grão (falta de informação entre os ERP) e de qualidade de dados. Todavia, toda a informação foi avaliada e tratada com o devido cuidado pois, na ocorrência de constrangimentos em futuras etapas, implicaria a reestruturação do sistema. Estrutura do sistema de Business Intelligence Neste tópico será descrito a estruturação do sistema de Business Intelligence desenvolvido, bem como as tecnologias utilizadas em cada etapa do seu desenvolvimento. 35 A partir da Figura 25, encontra-se demonstrado a arquitetura do sistema construído. Esta é semelhante à da Figura 3 (Figura genérica da arquitetura de um projeto de Business Intelligence ), no entanto, nesta Figura são explicitados os programas utilizados em cada etapa de desenvolvimento. Figura 25 - Arquitetura do sistema de Business Intelligence desenvolvido. Pela interpretação da Figura verifica-se que os dados em formato de ficheiro Excel (fontes de dados), têm a sua origem na exportação dos programas ERP da organização. É com estes que o processo ETL é iniciado, onde são extraídos, transformados e carregados nas tabelas do Data Warehouse . Após o seu carregamento, a informação no Data Warehouse é dirigida para uma aplicação de produção de dashboards , no propósito de auxiliar o processo de análise, necessário a boas práticas de gestão. É de salientar que o processo ETL é realizado três vezes e os dados são carregados em três bases de dados distintas. Além disto, a implementação de um servidor OLAP foi considerada como opcional, pelo facto de a ferramenta front-end não permitir a criação de medidas adicionais a dados provenientes de Cubos OLAP. 36 5. IMPLEMENTAÇÃO DO SISTEMA Neste capítulo, é descrito em detalhe, todo o projeto desenvolvido. Isto diz respeito à modelação do Data Warehouse desenvolvido, aos pacotes criados na fase do processo ETL, aos cubos OLAP (etapa opcional no projeto) e aos relatórios em ambiente de Power BI. Modelação Esta primeira etapa corresponde à arquitetura que o Data Warehouse apresenta. É de referir que a modelação proposta se desenvolveu com base nos tópicos discutidos com o colaborador da organização e com a disponibilidade da informação. Posto isto, na Figura 26 encontra-se a modelação multidimensional, em esquema Constelação, onde se encontram todas as tabelas (tabelas de facto e tabelas de dimensão), bem como as ligações entre ambas, tudo num espaço integrado. Figura 26 - Arquitetura do Data Warehouse. 37 A apresentação foi disposta da seguinte forma para representar todo o modelo lógico do projeto, no entanto, o mesmo será demonstrado de uma forma focalizada por assunto do negócio (por tabela de facto), para facilitar a compreensão e detalhar ainda mais a sua estrutura. Conforme a visualização da Figura 26, esta contém cinco tabelas de facto e dezassete tabelas de dimensão. Isto é detetado através do prefixo no nome de cada tabela, onde “TF” corresponde a tabela de facto e “DIM” corresponde a tabela de dimensão. 5.1.1 Tabelas de Facto Começando pela tabela de facto “TF_VENDA”, esta armazena a informação referente às vendas da organização e relaciona-se com as tabelas de dimensão “DIM_CLIENTE”, “DIM_COLABORADOR”, “DIM_PRODUTO_SAGE”, “DIM_REGISTO_VENDA” e “DIM_TEMPO”, ou seja, é possível analisar as vendas sobre as perspetivas mencionadas (tabelas de dimensão). Figura 27 - Esquema Floco de Neve da TF_VENDA. Representado na tabela abaixo (Tabela 2), encontram-se todos os campos da tabela, especificados pelo tipo de dado, se é uma chave ou não (e qual chave) e uma descrição do que o mesmo simboliza. 38 Tabela 2 - TF_VENDA TF_VENDA Atributo Domínio Tipo de Chave Descrição IDCLIENTE INTEGER PK e FK Código identificador DIM_CLIENTE IDCOMERCIAL INTEGER PK e FK Código identificador DIM_COLABORADOR IDARTIGO INTEGER PK e FK Código identificador DIM_PRODUTO_SAGE IDFATURA INTEGER PK e FK Código identificador DIM_REGISTO_VENDA IDTEMPO INTEGER PK e FK Código identificador DIM_TEMPO QUANTIDADE FLOAT - Quantidade Vendida VALOR_BRUTO FLOAT - Valor Bruto do Produto DESCONTOS FLOAT - Desconto do Produto OUTROS FLOAT - Despesa Adicional VALOR_LIQUIDO FLOAT - Valor Líquido do Produto TAXA_IVA FLOAT - Valor do IVA TOTAL FLOAT - Preço Total do Produto com IVA Pela observação da Tabela 2 retiramos que os cinco primeiros campos (campos com prefixo “ID”) correspondem aos identificadores das dimensões (daí a designação FK), ou seja, é a forma de distinguir qual o representante que atuou na respetiva venda. Para além disto, todos eles são números inteiros ( Integer ) com a especificação de serem PK e FK da tabela, isto é, a combinação destes campos é o que carateriza a unicidade da tabela. Os restantes campos são as métricas pelas quais são efetuados cálculos e têm a capacidade de serem números decimais ( Float ). É de referir que, na tabela, estão inseridos registos de todos os documentos referentes às vendas (documentos “CFC”, “FR”, “FT” e “NC”), pelo qual, a sua distinção é feita através da dimensão “DIM_REGISTO_VENDA”. De seguida, a tabela de factos TF_COMPRA armazena toda a informação referente às compras realizadas pela organização e relaciona-se com as dimensões “DIM_REGISTO_COMPRA”, “DIM_FORNECEDOR”, “DIM_TEMPO” e “DIM_PRODUTO_SAGE”, o que permite análises sobre as mesmas (Figura 28). 39 Figura 28 - Esquema floco de neve da TF_COMPRA. Na Tabela 3, apresenta-se o detalhamento da tabela. Tabela 3 - TF_COMPRA TF_COMPRA Atributo Domínio Tipo de Chave Descrição IDARTIGO INTEGER PK e FK Código identificador DIM_PRODUTO_SAGE IDFATURA INTEGER PK e FK Código identificador DIM_REGISTO_COMPRA IDFORNECEDOR INTEGER PK e FK Código identificador DIM_FORNECEDOR IDTEMPO INTEGER PK e FK Código identificador DIM_TEMPO QUANTIDADE FLOAT - Quantidade Comprada TOTAL FLOAT - Preço Total do Produto com IVA Neste caso, os quatro primeiros atributos são os identificadores de uma compra e destacam o agente da compra da dimensão. Apresentam o domínio de número inteiros. Os dois últimos atributos são números decimais. Tal como acontece na tabela anterior, a distinção entre documentos de compra, é feita através da “DIM_REGISTO_COMPRA”. A tabela de factos TF_PARAGEM armazenada a informação referente às paragens durante o fabrico do produto e esta relaciona-se com as dimensões “DIM_COLABORADOR”, “DIM_TEMPO”, “DIM_MOTIVO”, “DIM_TURNO” e “DIM_MAQUINA”. A caraterização da mesma é exposta na Figura 29. 40 Figura 29 - Esquema Estrela da TF_PARAGEM. O detalhamento da tabela de factos apresenta-se da seguinte forma (Tabela 4). Tabela 4 - TF_PARAGEM TF_PARAGEM Atributo Domínio Tipo de Chave Descrição IDTEMPO INTEGER PK e FK Código identificador DIM_TEMPO IDMAQUINA INTEGER PK e FK Código identificador DIM_MAQUINA IDTURNO INTEGER PK e FK Código identificador DIM_TURNO IDCOLABORADOR INTEGER PK e FK Código identificador DIM_COLABORADOR IDMOTIVO INTEGER PK e FK Código identificador DIM_MOTIVO TEMPO_PARAGEM FLOAT - Tempo de paragem Tal como nos anteriores, os atributos com o prefixo “ID” são os identificadores da respetiva paragem feita e integram a mesma designação de PK e FK da tabela. Todos estes valores são números inteiros, ao contrário da métrica que é um número decimal, correspondente aos valores em horas. A tabela de factos “TF_PRODUCAO” armazena a informação referente aos totais produzidos por colaborador por máquina e esta relaciona-se com as dimensões “DIM_COLABORADOR”, “DIM_TEMPO”, “DIM_MAQUINA” e “DIM_TURNO”. A Figura 30 demonstra em detalhe a tabela e as respetivas tabelas de dimensão. 41 Figura 30 - Esquema Estrela da TF_PRODUCAO. A tabela 5 demonstra em mais detalhe os atributos do facto. Tabela 5 - TF_PRODUCAO TF_PRODUCAO Atributo Domínio Tipo de Chave Descrição IDTEMPO INTEGER PK e FK Código identificador DIM_TEMPO IDMAQUINA INTEGER PK e FK Código identificador DIM_MAQUINA IDTURNO INTEGER PK e FK Código identificador DIM_TURNO IDCOLABORADOR INTEGER PK e FK Código identificador DIM_COLABORADOR HORA_MAQUINA FLOAT - Tempo de utilização da máquina METRO FLOAT - Metros produzidos TOTAL_PECA_ROLO FLOAT - Quantidade total produzida Novamente, os quatro primeiros atributos correspondem às PK e FK da tabela e são de domínio números inteiros. As restantes são as métricas e apresentam o domínio de números decimais. Por fim, a tabela de factos “TF_DEFEITO” armazena a informação referente aos produtos produzidos que obtiveram defeito. Esta relaciona-se com as dimensões “DIM_TEMPO”, 42 “DIM_MAQUINA”, “DIM_PRODUTO_PRODUCAO” e “DIM_TIPO_DEFEITO”, como apresentado na Figura 31. Figura 31 - Esquema Snowflake da TF_DEFEITO. A Tabela 6 demonstra em detalhe a tabela em questão. Tabela 6 - TF_DEFEITO TF_DEFEITO Atributo Domínio Tipo de Chave Descrição IDTEMPO INTEGER PK e FK Código identificador DIM_TEMPO IDMAQUINA INTEGER PK e FK Código identificador DIM_MAQUINA IDPRODUTO INTEGER PK e FK Código identificador DIM_PRODUTO_PRODUCAO IDTIPO_DEFEITO INTEGER PK e FK Código identificador DIM_TIPO_DEFEITO NUMERO_PECA FLOAT - Produtos produzidos METRO_DEFEITO FLOAT - Metros produzidos com defeito HORA_PRODUCAO FLOAT - Horas trabalhadas Os primeiros quatro atributos da tabela são de domínio números inteiros e correspondem às PK e FK da tabela. Os últimos atributos correspondem às métricas e apresentam o seu domínio como número decimal. 49 Tabela 21 - DIM_TEMPO DIM_TEMPO Atributo Domínio Tipo de Chave Descrição IDSK INTEGER PK Chave primária DATA DATE - Data DIA CHAR(2) - Número do dia DIASEMANA VARCHAR(10) - Nome do dia MES CHAR(2) - Número do mês NOMEMES VARCHAR(20) - Nome do mês QUARTO TINYINT - Número do trimestre NOMEQUARTO VARCHAR(20) - Nome da ordem do trimestre ANO CHAR(4) - Número do ano ESTACAOANO VARCHAR(20) - Nome da estação do ano FIMSEMANA CHAR(3) - Indicador de fim de semana DATACOMPLETA VARCHAR(10) - Data com valores juntos A Tabela 21 armazena os dados de datas. As datas foram geradas com um script que se encontra no Anexo I. Os valores entram num intervalo de 1950 e 2050, onde a tabela é povoada, imediatamente no primeiro carregamento de dados. Tabela 22 - DIM_TIPO_DEFEITO DIM_TIPO_DEFEITO Atributo Domínio Tipo de Chave Descrição IDSK INTEGER PK Chave substituta IDTIPO_DEFEITO INTEGER - Chave original DESCRICAO VARCHAR(50) - Nome do defeito A Tabela 22 guarda a informação referente ao dano que o produto fabricado pode possuir. Tabela 23 - DIM_TURNO DIM_TURNO Atributo Domínio Tipo de Chave Descrição IDSK INTEGER PK Chave substituta IDTURNO INTEGER - Chave original DESCRICAO VARCHAR(20) - Nome do turno Por fim, a Tabela 23 guarda a informação dos diferentes turnos de trabalho. 50 Processo ETL A segunda etapa do projeto correspondeu ao processo de ETL, desenvolvido no Microsoft SQL Server Integration Services (SSIS). Como foi anteriormente descrito, este é o processo onde se extraia os dados das várias fontes de informação (neste caso dos vários ficheiros excel, provenientes dos sistemas de ERP da organização), a transformação dos dados e o seu posterior carregamento nas tabelas do Data Warehouse “ESTAGIO_DW”. A Figura 25 presente no capítulo anterior, demonstra todo o sistema desenvolvido neste projeto. No entanto, o foco nesta etapa encontra-se entre o ambiente de fluxo de dados e o ambiente do Data Warehouse , como representado na Figura. Em primeiro lugar, é necessário definir o trajeto que os dados tomam nesta etapa, antes de iniciar o detalhamento do mesmo. A etapa tem como base o processo ETL, realizado três vezes, sendo feito o carregamento em três bases de dados, de uma forma sequencial: 1. A primeira iteração corresponde à extração dos dados e carregamento dos mesmos numa base de dados, sem quaisquer restrições (tabelas sem relacionamentos), denominada por “ESTAGIO_ERRO”. Este somente serve o propósito de ser uma estrutura que armazene todo a informação adquirida, num ambiente integrado, para que não haja nenhum constrangimento tecnológico no âmbito de realizar operações aos dados. 2. A segunda iteração deve-se à extração do ERRO para a realização de operações, de modo a modificar e limpar a informação e, posteriormente, estes são novamente carregados numa segunda base de dados, com as mesmas propriedades que a anterior, denominada por “ESTAGIO_STAGE”. Dentro deste, toda a informação deve estar já preparada, no que diz respeito aos requisitos estabelecidos, e abrigar a consolidação entre os dados. 3. A terceira e última iteração corresponde ao carregamento no Data Warehouse “ESTAGIO_DW”, em que já existem condições e relacionamentos entre as tabelas. Devido a isto, o carregamento das tabelas começa com os dados das dimensões e depois com os factos, pois estes apontam para a informação nas dimensões. É de notar que, caso exista informação com lacunas que não correspondam ao realizado no DW, esta é transferida para uma base de dados, nominada de “ESTAGIO_QUARENTENA”, para posterior análise dos problemas e tratamento do mesmo, a fim de voltar a carregar a informação, já devidamente tratada, no DW. 51 Apresentada a metodologia utilizada, seguidamente será retratado, em maior detalhe, o processo de ETL para um dos tópicos, considerado como pertinente, pois cada pacote foi desenvolvido, segundo a seguinte estrutura lógica: 1. Limpeza da tabela com o comando Truncate de SQL; 2. Extração dos dados das fontes; 3. Transformação dos dados; 4. Carregamento nas tabelas. O ambiente do Microsoft SQL Server Integration Services é constituído por pacotes que, por sua vez, permitem aplicar ferramentas para realizar operações aos dados, tais como nodos, com comandos de linguagem de manipulação de dados (DML) incorporados. Na Figura 32, encontra-se representado esse mesmo ambiente. Figura 32 - Visão geral dos pacotes no SSIS. Indicados na Figura a vermelho, encontram-se os pacotes do projeto. Estes apresentam uma metodologia no início do nome (1Carga_ERRO, 2Carga_STAGE, 3Carga_DW), que indica a fase pela qual, o específico tema da informação, se encontra referido, havendo a flexibilidade de modificar ou adicionar algum aspeto, conforme a necessidade. Os mesmos, poderiam ser desenvolvidos de uma forma conjunta, ou seja, não haver a divisão por tema (produto, fornecedor, cliente, entre outros) mas isto tornaria mais confuso a deteção de algum equívoco nos dados. 52 Na fase de carregamento dos dados para as tabelas em “ESTAGIO_ERRO”, de acordo com os dados provenientes dos ERP, caso este seja do ERP Sage, houve a necessidade de eliminar as primeiras e últimas N linhas dos documentos, correspondentes ao nome da empresa e à data em que foi adquirida a informação. Isto ilustra-se nas seguintes Figuras. Figura 33 - Control Flow do pacote ERRO_REGISTO_VENDA. Figura 34 - Data Flow do pacote ERRO_REGISTO_VENDA. Na Figura 33, ilustra-se o control flow para os dados dos registos de venda. O processo inicia-se com um nodo de tarefa de SQL que remove a estrutura e os dados existentes na tabela. De seguida, entra o nodo de data flow que, por sua vez, é composto por vários nodos de transformação de dados. Já na Figura 34 estão expostas as ferramentas utilizadas no data flow para tratar dos dados dos registos de venda. Nestes é somente selecionada a informação pertinente, logo no primeiro nodo (nodo origem Excel), para evitar a extração das primeiras linhas, são feitas algumas transformações aos dados e, por fim, são convertidos para o domínio e carregados na respetiva tabela. Caso os dados sejam 53 provenientes do ERP Primavera, foi necessário eliminar alguns carateres especiais como os denominados non-breaking space , inerentes ao texto, antes do seu carregamento. É de salientar que, para a informação que irá representar as tabelas de facto, criou-se uma view para representa-la de uma forma já estruturada. Agora na fase de carregamento do “ESTAGIO_STAGE”, é de salientar a informação referente aos itens de venda numa fatura. Este é um exemplo dos dados que povoam uma tabela de factos e a estrutura do seu pacote ilustra-se pela seguinte Figura. Figura 35 - Control Flow do pacote STAGE_TF_VENDA. Aqui, novamente são feitos os mesmos processos que já foram mencionados. No entanto, neste passo é feita uma correção aos dados, devido à soma do total por linha dos produtos não corresponder ao total da fatura, em muitos casos por cêntimos (que pode significar problemas em arredondamentos) e em outros casos por alguns euros, o que não pode acontecer. Para resolver esta situação, foi criada uma view responsável por tratar destes dados (ANEXO 2). Todas as tabelas de facto são compostas por uma view derivada da anterior pois, estes sofriam de problemas em algum aspeto. Por fim, na fase de carregamento do “ESTAGIO_DW”, é realizado o mesmo processo que nos anteriores, exceto o primeiro passo de limpeza da tabela pois, é neste que é pretendido que a informação esteja arquivada e disponível para os utilizadores. Para a realização do carregamento é imperativo iniciar este processo pelas tabelas de dimensão e depois pelas tabelas de facto pois, estas últimas têm 54 informação que apontam diretamente para as tabelas de dimensão, pelo que, se não houver esta integridade, acontece um erro no carregamento. Como exemplo, ilustra-se na Figura 36 o pacote da dimensão fornecedor. A particularidade para esta e outras dimensões é a inclusão da ferramenta Slowly Changing Dimension e das tabelas de quarentena. A partir deste nodo, escolhe-se quais os atributos que podem mudar algum aspeto do respetivo fornecedor e, caso isto aconteça, é registado no campo “FIM” a data a que a atualização foi realizada e é inserida uma nova linha, com o mesmo fornecedor, com o campo “FIM” sem valor, pois este representa a informação do fornecedor atualizada. A quarentena só é povoada caso alguma informação não esteja coerente, pelo que não é pretendido que algo passe neste fluxo. Figura 36 - Data Flow do pacote DW_DIM_FORNECEDOR. Os nomes nos restantes nodos são gerados automaticamente, com a utilização do nodo Slowly Changing Dimension . É por essa razão que os nomes dos restantes nodos estão dispostos de uma forma genérica. Após o carregamento das tabelas de dimensão, inicia-se o carregamento das tabelas de facto. Para estes, foi desenvolvida uma procedure encarregue de povoar a tabela com dados que tenham datas superiores à data dos registos já existentes na tabela. 55 Figura 37 - Control Flow do pacote DW_TF_COMPRA. Todas as views e procedures são scripts de sql guardadas no Microsoft SQL Server Management Studio e podem ser executadas através deste programa, mantendo todo o processo de ETL num só ambiente. No script para esta tabela, também se encontra presente, o conceito das tabelas de quarentena só que, para os dados transitários a factos, caso exista alguma informação duplicada ou um código inexistente na respetiva dimensão, é povoada na quarentena a linha correspondente à informação que causa o erro e o tipo de erro associado com o mesmo. Por fim e porque foram desenvolvidos sessenta e um pacotes para o processo de ETL, resolveuse criar dois jobs no SSMS, de modo a executar todos os pacotes de uma vez, de uma forma sequencial, estando os mesmos separados por fase (ERRO, STAGE, DW). Estes jobs ou rotinas, servem para tornar este processo automático e, a sua execução, pode ser estabelecida, de acordo com uma periodicidade diária, semanal ou mensal, a uma determinada hora, porém deve-se ter em conta que a execução do mesmo ocorre após um dia normal de trabalho, para não sobrecarregar o sistema da empresa. Cubos OLAP Esta etapa será descrita de uma forma breve pois, não foi muito explorada devido ao facto de que, na utilização da ferramenta de reporting , se a fonte fosse desenvolvida nesta etapa, não havia a possibilidade de modificar ou acrescentar mais aspetos ao modelo, pelo que se optou pela mesma ser opcional para o projeto. 56 Contudo, a criação dos cubos OLAP serve para realizar o processamento analítico dos dados em grande quantidade, possibilitando a consulta dos mesmos, num tempo bastante reduzido. Isto foi desenvolvido através do Microsoft SQL Server Analytics Services (SSAS). Em primeiro lugar, gerou-se a ligação com o Data Warehouse ( Data Source ) e, imediatamente de seguida, a vista sobre a ligação gerada ( Data Source View ). Após a criação das mesmas, construiram-se as dimensões e as tabelas de facto, de forma a gerar os cubos, como indicado a vermelho na Figura 38. Figura 38 - Visão geral do SSAS. Para a criação dos cubos resolveu-se criar um número de cubos igual ao número de tabelas de facto. Isto indica que foram criados 5 cubos OLAP, que apresentam a mesma constituição que o apresentado pelas Figuras 27 à 31, no tópico da modelação, sendo estes: • Cubo TF_COMPRA: Informação referente às compras feita pela organização; • Cubo TF_DEFEITO: Informação referente aos defeitos subjacentes na produção; • Cubo TF_PARAGEM: Informação referente às paragens na produção; • Cubo TF_PRODUCAO: Informação referente aos produtos produzidos; • Cubo TF_VENDA: Informação referente às vendas da organização. Para as tabelas de dimensão, criaram-se hierarquias que resultam na agregação dos valores de alguns atributos das tabelas. As dimensões com hierarquias são: • DIM CLIENTE; 57 • DIM COLABORADOR; • DIM FORNECEDOR; • DIM PRODUTO PRIMAVERA; • DIM PRODUTO PRODUCAO; • DIM PRODUTO SAGE; • DIM REGISTO COMPRA; • DIM REGISTO VENDA; • DIM TEMPO. Para exemplificar, são ilustradas nas Figuras 39 e 40 as hierarquias presentes na dimensão “DIM_PRODUTO_SAGE”, bem como uma pesquisa da hierarquia. Já na Figura 41, encontra-se ilustrado o cubo TF_VENDA. Figura 39 - DIM_PRODUTO_SAGE. 58 Figura 40 - Exploração das hierarquias da DIM_PRODUTO_SAGE. Figura 41 - Cubo TF_VENDA. Normalmente, estes cubos são criados e ligados com a ferramenta Microsoft SQL Server Reporting Services (SSRS), no entanto, a ferramenta utilizada no lugar desta, foi o Microsoft Power BI, 65 respetivamente. Para este caso, valores mais próximos de 100% já seria de esperar pois, devido ao estado que o país atravessou, o nível da procura foi bastante baixo, o que influenciou estes resultados. Análise dos Clientes A seguinte Figura ilustra dois gráficos que representam o número de encomendas realizadas por um cliente e o top de clientes em termos monetários. Figura 48 – Gráficos Cliente O cliente que mais comprou, em termos monetários, corresponde somente a 8 vendas. Já o cliente que mais comprou, em termos de quantidade, corresponde ao terceiro cliente em valor. Análise do projeto Para analisar o projeto desenvolvido, deve-se compreender se o mesmo melhora ao nível de economizar tempo, ao nível de interação e compreensão por parte do utilizador final e, por fim, ao nível da melhoria no negócio. No que toca aos dois primeiros pontos, o foco na construção do dashboard foi demonstrar, de uma forma compreensível, os principais pontos discutidos na fase de levantamento de requisitos, sendo apresentado, na primeira página do relatório, uma síntese geral da situação da empresa (Figura 49). 66 Figura 49 - Página Inicial do Relatório Com isto, é pretendido retirar a informação mais pertinente para a empresa (nomeadamente os indicadores chave prioritários para análise), para os gestores terem uma visão amplificada da posição em que se assentam, assegurando uma rapidez de consulta e, por sua vez, reduzindo o tempo para análise e aplicação de decisões. Para além do tempo, a perceção e utilização do modelo demonstrou-se benéfica pelas primeiras observações e utilizações do modelo. Já no que toca a melhorias ao negócio, apesar de os responsáveis da empresa terem elogiado o projeto, este não pode ser implementado devido a uma limitação na obtenção dos dados, pelo que não existe forma de analisar se o projeto foi benéfico para a empresa. 67 7. CONCLUSÕES Com o crescente avanço da tecnologia, as empresas procuram soluções eficientes que contribuam para a vantagem competitiva da empresa, num mercado, cada vez mais saturado e competitivo. As decisões estratégicas influenciam como uma organização trabalha e interage com o meio envolvente, face a uma oportunidade de negócio, ou a uma ameaça proveniente do ambiente externo potenciado os seus pontos fortes. A tomada de decisão deve ser fundamentada em informação adequada, completa, atualizada, inteligível e disponível. O Business Intelligence torna possível retirar conclusões das informações disponibilizadas pelos sistemas de informação. Por outras palavras, permite gerar conhecimento, sob a forma de métricas de desempenho, de acordo com a informação operacional da empresa. No caso de estudo desenvolvido neste projeto, a empresa determinou quais os aspetos que pretendia saber e controlar com maior detalhe. Sabendo estes requisitos, iniciou-se o processo de desenvolvimento de um sistema, capaz de armazenar a informação que foi solicitada como prioridade para análise. A etapa inicial para lidar com a informação foi composta pela modelação multidimensional de todas as tabelas que irão formar o modelo. Tratam-se de tabelas relacionais que descrevem cada tópico recolhido das diferentes fontes examinadas (Sage, Primavera, VMP Plan, Excel produção). Os atributos em cada tabela correspondem aos campos que identificam os tópicos e as métricas estabelecidas nos requisitos. A designação das tabelas é composta por tabelas de facto, onde se encontram as métricas e correspondem ao evento ocorrido, e as tabelas de dimensão, com os atributos que os caraterizam e ao agente existente no evento. A composição aqui existente designa-se por Data Warehouse , ou seja, um armazém de dados que serve o propósito de analisar dados. De seguida, elaborou-se o processo ETL onde é feita a extração dos dados das fontes, são feitas operações de transformação aos dados e, estes são carregados no Data Warehouse criado. Este processo foi dividido em vários pacotes, de acordo com o tópico e fase do processo, em que se encontravam, nomeadamente pelas tabelas na secção “ESTAGIO_ERRO”, correspondente às tabelas criadas com a função de agrupar toda a informação oriunda das múltiplas fontes, “ESTAGIO_STAGE”, correspondente à informação já devidamente tratada ou com aspetos a serem tratados, e por fim no “ESTAGIO_DW”, correspondente à informação já devidamente tratada e armazena para posterior análise. Se a informação permanecer com algum defeito, esta é direcionada para outras tabelas, que correspondem à 68 “ESTAGIO_QUARENTENA”, espaço onde a informação é verificada, a fim de voltar a carregar esses mesmos dados no armazém de dados. Após esta etapa, considerou-se a criação de um projeto de análises, ou seja, a criação dos cubos OLAP. A realização deste foi considerada como opcional, pelo facto da ferramenta de reporting não disponibilizar opções, após a seleção dos cubos como fonte ao modelo de relatórios. No entanto, a criação dos cubos é feita através da seleção do Data Warehouse como fonte ao projeto. Com esta ligação feita, os cubos tratam-se por ser a tabela de factos, juntamente com as tabelas de dimensão, relacionadas com a mesma. As principais caraterísticas desta etapa, são a vantagem do processamento de dados, em grande quantidade e, a capacidade de hierarquizar os dados de forma a pesquisar, em maior detalhe. Por fim, desenvolveu-se um dashboard que permite consultar os dados, mediante várias perspetivas, a fim de visualizar o comportamento que estes apresentam, ao longo do tempo. Para isto, é estabelecida a ligação com o Data Warehouse e, manualmente, relacionam-se as tabelas, da mesma forma como estas se encontram no modelo do Data Warehouse . Após estas configurações, criaram-se várias páginas de relatórios, com filtros integrados, para capacitar a pesquisa de parâmetros, afunilando a informação, juntamente com métricas, escritas em DAX, para demonstrar algumas transformações numéricas e permitir a comparação de períodos homólogos. O intervalo temporal dos dados recolhidos apresenta algumas limitações, pelo que muitas das análises, entre os anos 2019 e 2020, conseguem ser explicadas pela influência da epidemia e da gestão governamental para travar a mesma. Devido a estas circunstâncias, a empresa revelou uma faturação inferior ao ano anterior, somente ultrapassada no mês de junho. Com a crescente procura a empresa sentiu a necessidade de comprar matéria prima para a fabricação dos seus produtos, demonstrado pela linha com um declive positivo no mês de maio. Estas análises, entre outras possíveis de se realizar, são a potencialidade inerente na construção de um projeto de Business Intelligence . Com isto, comprovou-se a importância que a estrutura desenvolvida exerce, para a gestão estratégica e operacional da empresa, tendo o mesmo correspondido a quase todos os requisitos propostos, exceto os requisitos referentes ao stock e à automatização do projeto. Durante a realização deste projeto, existiram algumas limitações na obtenção dos dados da empresa. Isto diz respeito há forma como os mesmos foram extraídos, ou seja, caso existisse uma ligação direta com a base de dados interna, não haveria a necessidade de exportar os dados, oriundos dos ERP para ficheiros de Excel (entre outros), pois o sistema seria capaz de trazer toda a informação histórica e 69 em constante atualização. Para além disto, devido à informação dos ERP se encontrar em ficheiros Excel, necessitou-se efetuar vários passos extras, na etapa do processo ETL, para a consolidação da mesma. As informações referentes aos stocks também entram nesta categoria, porém, os mesmos encontravam-se num ficheiro PDF, pois não era possível extrair para outro tipo de ficheiro. Isto causou alguns transtornos pois, numa primeira ação, os dados teriam que ser convertidos para algum ficheiro de texto, de forma a ler esses mesmos dados. Após a utilização de várias ferramentas online de conversão de ficheiro, uma delas demonstrou resultados promissores, no que toca à estruturação da informação, no entanto, a informação encontrava-se dividida entre várias páginas do mesmo ficheiro de Excel. Devido a isto, desenvolveu-se um script em C#, capaz de copiar a informação das várias páginas, para uma única página, gravando esse ficheiro, já denominado por “ fixed ”, na localização do ficheiro inicial, resolvendo assim o problema. Contudo, após a verificação se os dados se encontravam válidos para trabalhar, verificou-se que a ferramenta de conversão não foi capaz de converter devidamente o ficheiro, resultando em má qualidade de dados. Após várias tentativas sem sucesso, optou-se por desabilitar o pacote referente a este passo. Na eventualidade de conectar o sistema à base de dados interna, será possível corresponder a este requisito, tendo em consideração que devem ser trabalhados o processo ETL e o Data Warehouse . Assim, recomenda-se que seja realizado esta ponte entre o sistema e a base de dados interna, para que o sistema se torne autónomo e constantemente atualizado. 70 BIBLIOGRAFIA Adamson, C. (2010). Star schema the complete reference. McGraw Hill Professional. Bhadauria, R. (2019). Fact Constellation in Data Warehouse modelling Brown, A. P. G. (1975). Modelling a Real World System and Designing a Schema to Represent It. In IFIP TC-2 Special Working Conference on Data Base Description (pp. 339-348). Chaudhuri, S., & Dayal, U. (1997). An overview of data warehousing and OLAP technology. ACM Sigmod record , 26(1), 65-74. Chiavenato, I. (1983). Introdução à teoria geral da administração. 3ª edição. São Paulo. Mcgraw do Brasil. Codd, E. F. (1983). A relational model of data for large shared data banks. Communications of the ACM , 26(1). Costa, S., & Santos, M. (2014, March ). Sistema de Business Intelligence no suporte à Gestão Estratégica. In Atas da Conferência da Associação Portuguesa de Sistemas de Informação. Dedić, N., & Stanier, C. (2016). An evaluation of the challenges of multilingualism in data warehouse development. Durcevic, S. (2020). Get The Most Out Of Smart Business Intelligence Reporting. Retrieved December 8, 2020, from https://www.datapine.com/blog/business-intelligence-reporting/ Edi, D., & Betshani, S. (2009). Analisis Data dengan Menggunakan ERD dan Model Konseptual Data Warehouse. Jurnal Informatika. Elias, D. (2014). A granularidade de dados no Data Warehouse . Retrieved December 6, 2020, from https://canaltech.com.br/business-intelligence/a-granularidade-de-dados-no-data-warehouse-26310/ Fouché, G., & Langit, L. (2011). Foundations of SQL server 2008 R2 business intelligence. Apress. George, S. (2012). Inmon vs. Kimball: Which approach is suitable for your data warehouse? Data Warehousing. Ghanayem, M. et al. (2019). What is SQL Server Management Studio (SSMS)?. Retrieved December 10, 2020, from https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-ssms?view=sqlserver-ver15 Hart, M. & Olprod. (2020). What is Power BI?. Retrieved December 11, 2020, from https://docs.microsoft.com/pt-pt/power-bi/fundamentals/power-bi-overview Hejlsberg, A., Torgersen, M., Wiltamuth, S., & Golde, P. (2010). The C# programming language. Inmon, W. H. (2005). Building the data warehouse. John wiley & sons. 71 Kimball, R., & Ross, M. (2011). The data warehouse toolkit: the complete guide to dimensional modeling. John Wiley & Sons. Koballa, D. et al (2020). Download SQL Server Data Tools (SSDT) for Visual Studio. Retrieved December 11, 2020, from https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-toolsssdt?view=sql-server-ver15 Lachev, T., & Price, E. (2017). Applied Microsoft Power BI: Bring your data to life!. Prologika Press. Laudon, K. C., & Laudon, J. P. (1999). Management information systems. Prentice Hall PTR. Lee, M. (2020). StarUML. Retrieved December 10, 2020, from https://docs.staruml.io/userguide/readme Leiper, 2020. Sobre nós. Retrieved December 12, 2020, from https://www.texteisleiper.pt/grupo/ Luhn, H. P. (1958). A Business Intelligence System. IBM Journal of Research and Development , 2(4), 314–319. https://doi.org/10.1147/rd.24.0314 Machado, F. N. R. (2000). Projeto de Data Warehouse: uma visão multidimensional. Ed. Érica. MESQUITA, R. A. C. (2000). Sistemas ERP (Enterprise Resource Planning). Brasília: UNICEUB. Nguyen, T. M., Tjoa, A. M., Nemec, J., & Windisch, M. (2007). An approach towards an event-fed solution for slowly changing dimensions in data warehouses with a detailed case study. Data & Knowledge Engineering. Nielsen, P., & Parui, U. (2011). Microsoft SQL server 2008 bible (Vol. 607). John Wiley & Sons. Patel, N. (2020). Metas SMART: O Que São, Como Definir, Exemplos e Muito Mais!. Retrieved December 21, 2020, from https://neilpatel.com/br/blog/metas-smart/ Ponniah, P. (2011). Data warehousing fundamentals for IT professionals. John Wiley & Sons. Primak, F. V. (2008). Decisões com bi (business intelligence). Fabio Vinicius Primak. Rahm, E., & Do, H. H. (2000). Data cleaning: Problems and current approaches. IEEE Data Eng. Bull. , 23(4), 3-13. Reason, P., & Bradbury, H. (Eds.). (2001). Handbook of action research: Participative inquiry and practice. Sage. Ross, M. (2013). Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7. Santos, A. J. R. (2008). Gestão estratégica: conceitos, modelos e instrumentos. Escolar Editora. 72 Santos, M. Y., & Ramos, I. (2006). Business Intelligence: tecnologias da informação na gestão de conhecimento. FCA-Editora de Informática, Lda. Santos, M. Y., & Ramos, I. (2009). Business Intelligence – Tecnologias da Informação na Gestão de Conhecimento (2 ed.). Lisboa, Portugal: FCA. Shahin, A., & Mahbod, M. A. (2007). Prioritization of key performance indicators. International Journal of Productivity and Performance Management. Silvers, F. (2008). Building and maintaining a data warehouse. CRC Press. Singh, M. (2016). Inmon vs Kimball Data Models Approaches. Retrieved November 28, 2020, from http://www.sql-datatools.com/2016/09/inmon-vs-kimball-data-warehouse-Architectureapproaches.html Sousa, Rui S. (2011). Modelo Dimensional para Data Warehouse. Stringer, E. T. (2008). Action research in education. Upper Saddle River, NJ: Pearson Prentice Hall. Vassiliadis, P., Simitsis, A., & Skiadopoulos, S. (2002, November ). Conceptual modeling for ETL processes. In Proceedings of the 5th ACM international workshop on Data Warehousing and OLAP (pp. 14-21). Vercellis, C. (2009). Business intelligence: data mining and optimization for decision making (pp. 1-420). New York: Wiley. Victor, G. (2015). Gestão Estratégica. Retrieved November 19, 2020, from http://gianengproducao.blogspot.com/2015/03/gestao-estrategica.html 73 ANEXO I – DIMENSÃO DIM_TEMPO Figura 50 - Script Dimensão Tempo parte 1. 74 Figura 51 - Script Dimensão Tempo parte 2. 81 O problema existente com os dados dos stocks foi explicado no Capítulo Conclusões, ou seja, os problemas derivam da conversão de um ficheiro PDF para um ficheiro de texto, como o Excel. Para solucionar este primeiro problema, utilizaram-se várias ferramentas online de conversão gratuita, sendo que a ferramenta, denominada por Tabula 6 , foi capaz de, à primeira vista, transformar com sucesso o ficheiro PDF num ficheiro de extensão CSV. Já com este pronto, ao nível de leitura de dados, desenvolveuse um script, na linguagem de C#, para resolver problemas existentes nas linhas, deste novo ficheiro. Ilustrado na Figura 54, no lado direita da mesma, encontram-se as bibliotecas utilizadas. Já no início do script , é referida a função ReadCsvFile . Na Figura 55 é ilustrada a parte do script referente à criação de uma janela, onde o utilizador escolhe o ficheiro CSV que pretende trabalhar, de forma a tornar este processo mais amigável para o utilizador final. De seguida, os dados são divididos conforme as vírgulas entre eles, para estes estarem dispostos sobre diferentes células. Por fim, nas Figuras 56 e 57, o script concatena a informação com a linha de baixo, caso esta fosse a continuação do nome no respetivo campo, pois existiam nomes que, por serem longos, encontravam-se na linha imediatamente abaixo. Para averiguar quais os campos que seriam concatenados, era verificado se o campo “Data” se encontrava nulo ou não, de modo a não produzir informação sem qualidade. Já com os dados devidamente tratados, era guardado um novo ficheiro CSV com o nome “ fixed ”, na mesma localização do ficheiro original, para extração no processo ETL. O script foi capaz de tratar toda a informação com sucesso, no entanto, após a verificação das conversões do Tabula, verificou-se que este foi incapaz de converter o ficheiro, na sua totalidade, pois o mesmo apresentava várias anomalias, em que o script desenvolvido foi inapto de responder. A única solução possível, seria inserir manualmente os valores num ficheiro. Todavia esta solução não é viável pois, são centenas de páginas que se teria que inserir e, o facto de o mesmo ter de ser efetuado manualmente, elimina a propriedade de automatização do sistema. 6 https://tabula.technology/