UNIVERSIDADE DO SUL DE SANTA CATARINA DANIEL LUIZ DA SILVA

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE DO SUL DE SANTA CATARINA DANIEL LUIZ DA SILVA"

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA DANIEL LUIZ DA SILVA ESTUDO DE CASO: ARQUITETURA DE BI PARA APOIAR O PROCESSO DECISÓRIO DE UMA FÁBRICA DE SOFTWARE Florianópolis 2014

2 DANIEL LUIZ DA SILVA ESTUDO DE CASO: ARQUITETURA DE BI PARA APOIAR O PROCESSO DECISÓRIO DE UMA FÁBRICA DE SOFTWARE Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof.Aran Bey Tcholakian Morales, Dr. Florianópolis 2014

3

4 Dedico esse trabalho a meus pais por terem financiados meus estudos e acreditado em meu potencial, e também porque sem eles nada disso teria ocorrido. E minha namorada por sempre me apoiarem momentos difíceis e contribuir muito para meu crescimento pessoal e profissional, sem ela eu seria uma pessoa diferente.

5 AGRADECIMENTOS Agradeço a Deus por sempre me auxiliar no meu desenvolvimento como ser humano, a meus pais por terem financiado meus estudos e acredito sempre em mim, minha namorada por sempre estar comigo em todos os momentos, a meu orientador Aran Bey Tcholakian Morales, por fazer parte desse trabalho, com muita humildade, e a todos professores da universidade que me ensinaram a fazer uma tarefa simples, porém de muita utilidade, pensar.

6 O dever da pessoa que trabalha com sistemas informação é levar a informação a todas as pessoas, ou seja, encurtar o caminho do acesso à informação de todas as pessoas. ANÔNIMO.

7 RESUMO Com o passar dos anos as empresas desenvolvedoras de software, e pessoas que tem como profissão alguma tarefa relacionada ao desenvolvimento de software, tem novos desafios para transformar dados em informação, e informação em conhecimento. Com isso, existe a área de engenharia de softwarede estudo que analisa o gerenciamento do desenvolvimento de software, ou seja, como pode-se melhorar a fabricação de sistemas, afim de garantir a satisfação do cliente. A partir desse contexto, o presente estudo tem por finalidade, analisar os dados coletados de demandas geradas em uma fábrica de software, ou seja, gerar informação e conhecimento para auxiliar a tomada decisão na melhoria do processo de produção de sistemas. Para isso foi construído uma arquitetura de BI, para analisar as solicitações (tíquetes), gerada por clientes e pela própria empresa, por meio de um sistema que gerencia demandas. Deste modo foi elaborada a pesquisa bibliográfica, utilizando como referência os principais autores da área de BI. O desenvolvimento desta arquitetura de BI, foi elaborado segundo a metodologia ICONIX. Foi construído um modelo dimensional de banco de dados, seguindo o padrão dos principais autores, apresentados na revisão bibliográfica. Foi utilizado a ferramenta ETL Pentaho Kettle, para realizar a extração, transformação e carga de dados, do banco de dados relacional, para o banco de dados dimensional. Por fim, foi realizado a montagem de gráficos, com auxílio da ferramenta Pentaho Saiuku, que apresentam os resultados conforme os requisitos levantados e expõem as informações encontrada desse trabalho. Palavras-chave: Análise de dados,business intelligence,data warehouse, Desenvolvimento de Software, Sistemas de apoio a tomada de decisão.

8 LISTA DE ILUSTRAÇÕES Figura 1 Evolução do BI Figura 2 Arquitetura de BI Figura 3 - Processo ETL Figura 4 - Arquitetura três camadas Figura 5 - Arquitetura duas camadas Figura 6 - Componentes do data warehouse Figura 7 - Tabela fato Figura 8 - Tabela dimensão Figura 9 - Modelo estrela Figura 10 Operação Drill Down Figura 11 Operação Roll Up Figura 12 Operação Drill Across Figura 13 Operação Slice and Dice Figura 14 Arquitetura de BI Solução Proposta Figura 15 Análise de requisitos - ICONIX Figura 16 Análise de projeto preliminar Figura 17 Revisão detalhada do projeto Figura 18 Requisitos funcionais Figura 19 Casos de uso Figura 20 Diagrama de robustez Figura 21 UCE001 diagrama de sequência Figura 22 UCE002 diagrama de sequência Figura 23 - UCE003 - diagrama de sequência Figura 24 - etapas back-end Figura 25 Modelo entidade relacionamento Figura 26 - Modelo DW Figura 27 - Carga de dados DI_CATEGORIA Figura 28 - Carga de dados DI_PROJETO Figura 29 - Carga de dados DI_RESPONSAVEL_AREA Figura 30 - Carga de dados DI_STATUS Figura 31 - Carga de dados DI_TEMPO Figura 32 - Carga de dados DI_TICKET Figura 33 - Carga de dados FT_TICKETS Figura 34 - Cubo OLAP Figura 35 - Horas x projetos Figura 36 - horas x mês Figura 37 - Horas x semana Figura 38 - Horas x dia Figura 39 - Horas x categoria Figura 40 - Horas x área - equipe Figura 41 - Tíquete x release Figura 42 - Percentual de prioridade de tíquete Figura 43 Percentual de horas x pessoas... 83

9 LISTA DE TABELAS Tabela 1 Definição de atores Tabela 2 UCE001 Importar dados com ferramenta ETL Tabela 3 UCE003 Criar data warehouse Tabela 4 - UCE003 - Analisar dados comferramenta OLAP Tabela 5 Tecnologias utilizadas... 61

10 LISTA DE SIGLAS BD Banco de Dados BI Business Intelligence BPM Business Performance Management DM Data Mart DW Data Warehouse ERP Enterprise Resource Planning ETL Enterprise Transform and Load FK foreign key GUI Graphical User Interface ODS OperationalDataStore OLAP On-line Analytic Processing PK Primary Key RUP Rational Unified Process SGBD Sistema de Gerenciamento de Banco de Dados SQL - Structured Query Language UML Unified Modeling Language XP Extreme Programming

11 SUMÁRIO 1 INTRODUÇÃO PROBLEMÁTICA OBJETIVOS OBJETIVO GERAL OBJETIVO ESPECÍFICO JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA REVISÃO BIBLIOGRÁFICA BUSINESS INTELLIGENCE (CONCEITOS E DEFINIÇÕES) ARQUITETURA DE BI ETL EXTRAÇÃO DE DADOS TRANSFORMAÇÃO DE DADOS CARREGAMENTO DE DADOS DATA WAREHOUSE ABORDAGEM BILL INMON ABORDAGEM RALPH KIMBALL CARACTERÍSTICAS DO DATA WAREHOUSE OBJETIVOSDO DATA WAREHOUSE ARQUITETURA DO DATA WAREHOUSE Arquitetura três camadas Arquitetura duas camadas COMPONENTES DO DATA WAREHOUSE MODELO DIMENSIONAL Tabelas fato Granularidade Tabelas de dimensão Medidas (variáveis) União de fatos e dimensão OLAP DRILL DOWN ROLL UP DRILL ACROSS SLICE AND DICE PIVOT CONSIDERAÇÕES FINAIS DO CAPÍTULO MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA ATIVIDADES METODOLÓGICAS ARQUITETURA DA SOLUÇÃO DELIMITAÇÕES CONSIDERAÇÕES FINAIS DO CAPÍTULO DESENVOLVIMENTO DA SOLUÇÃO METODOLOGIA ICONIX ANÁLISE DE REQUISITOS ANÁLISE DE PROJETO PRELIMINAR PROJETO...50

12 4.1.4 IMPLEMENTAÇÃO PROTÓTIPO DA SOLUÇÃO LEVANTAMENTO DE REQUISITOS CASOS DE USO DIAGRAMA DE ROBUSTEZ DIAGRAMA DE SEQUÊNCIA CONSIDERAÇÕES FINAIS DA MODELAGEM ESTUDO DE CASO EMPRESA DESENVOLVEDORA DE SOFTWARE FERRAMENTAS E TECNOLOGIA APRESENTAÇÃO DA ARQUITETURA DE BI A EMPRESA ARQUITETURA DE BI: BACK-END ARQUITETURA DE BI: FRONT-END CONSIDERAÇÕES FINAIS DO CAPÍTULO CONCLUSÕES E TRABALHOS FUTUROS CONCLUSÕES TRABALHOS FUTUROS...86 APÊNDICE A CRONOGRAMA...87 REFERÊNCIAS...88

13 13 1 INTRODUÇÃO Visando analisar os dados de desenvolvimento de software, de uma empresa que fabrica software para seus clientes, e com intuito de encontrar informação para apoiar a gerência da empresa a encontrar pontos de melhora, no processo de desenvolvimento de sistemas, será apresentado uma pesquisa, que analisa as demandas geradas por clientes da empresa ou demandas internas relacionadas a melhoria do software. Nos dias atuais, a valorização por informações relevantes que podem melhorar o processo de desenvolvimento de software, é o alvo principal de funcionários que compõem a parte estratégica da empresa, ou seja, os funcionários que ocupam cargos gerenciais dentro da empresa, tem como meta encontrar informações relevantes que podem agregar valor ao processo de desenvolvimento. Para que assim, a empresa seja mais competitiva no mercado com relação a suas concorrentes, e agregue mais valor a seu produto ou serviço. Nesse contexto, o Business Intelligence (BI), é uma ferramenta que pode auxiliar os funcionários que compõem a parte estratégica da empresa a tomar decisões, ou seja, as ferramentas de BI, disponibilizam recursos para as pessoas que utilizam, analisar a performance do assunto escolhido. Com isso, esse trabalho, visa implementar uma arquitetura de BI, para analisar as demandas disponibilizadas por uma empresa desenvolvedora de software. Essa arquitetura é composta pela base de dados relacional, local que será extraído os dados; a transformação desses dados; e importação dos dados na base de dados dimensional (Data Warehouse); e a ferramenta que analisa os dados na base dimensional. Assim, será feito a pesquisa que analisará todos esses dados, dos últimos 5 anos de desenvolvimento de software, e será apresentado as conclusões chegadas com essas análises. 1.1 PROBLEMÁTICA A fabricação de software é uma atividade intensiva em conhecimento, e requer capital humano altamente especializado para realizar essa atividade.conhecer o andamento do

14 14 processo de produção de software, é de extrema importância para a empresa desenvolvedora. O processo de produção de software, gera as demandas para melhoria do sistema,de forma que se forem analisadas as demandas, podem dar indícios e indicadores que permitem fazer a gestão do processo de desenvolvimento, de forma mais adequada, para a melhora do processo e tomar decisões baseadas em planejamento estratégico da empresa. Nesse sentido, o principal objetivo do trabalho a alcançar é transformar os dados brutos,extraídosdo processo de produção de um software,em informações estratégicas para auxiliar a tomada de decisão, que for fim seja de acordo com o planejamento estratégico da empresa. A riqueza de informação gerada dentro da empresa pela fabricação de software, muitas vezes,não é muito explorada, porque, ossoftwares que controlam essa fabricação, já fazem essa análise através de relatórios específicos, porém apresentam informações restritas. Por vez, esses relatórios induzem a pensar da mesma forma. Segundo Inmon (2001 p. 18), A verdade é que somente uma quantidade limitada de análise pode ser feita com a contagem simples, sendo necessário que o analista use formas mais complexas de análise, portanto, para realizar uma contagem complexa de dados, podemos utilizar fatores que não são utilizados nos relatórios apresentados nos softwares que controlam o processo de fabricação de sistemas. Portanto, para conseguir unir os dados brutos,gerado pelo sistema que controla o desenvolvimento do software, e analisando as variáveis externas ao sistema que controla o desenvolvimento, ou seja, as pessoas responsáveis por gerenciar o desenvolvimento. Com isso, podehaver um resultado de análise complexa de dados, podendo gerar informações para tomadas de decisão. De acordo com o problema de organizar e analisar dados do processo de desenvolvimento de sistemas, podemos construir umaarquiteturade BI(Business Intelligence), para auxiliar na solução dos problemas citados, de forma que a informação seja de acesso rápido e fácil.

15 OBJETIVOS A seguir, são apresentados os objetivos deste trabalho em duas partes: objetivo geral e objetivos específicos, assim, tornando explícitos os objetivos da pesquisa realizada Objetivo geral Construir umaarquitetura de BI sobre o processo de desenvolvimento de software, que auxilie nas decisões parasua melhora do processo Objetivo específico Os objetivos específicos são separados em tópicos: entender o processo de desenvolvimento de software da empresa em questão; analisar os dados brutos gerados pelo processo de desenvolvimento; construir uma arquitetura de BI de informações sobre o processo de desenvolvimento de software; apresentar e discutir os resultados obtidos com a análise realizada sobre a arquitetura construída.

16 JUSTIFICATIVA Percebe-se que, emuma era quando a informação gerada é muito importante para tomar decisão dentro da empresa, cada vez mais é investido em análises críticas que podem ter como objetivo ajudar a empresa a encontrar resultados que descrevem o ambiente corporativo. Para chegar ao resultado,é preciso um processo de análise de dados que possa auxiliar a encontrar informações relevantes para empresa. Com isso, podemos utilizar técnicas para construção da arquiteturade BI (Business Intelligence),para realizar esse processo de análise de dados, até que os dados brutos se transformem em informações. O BI é voltado para transformar pequenos ou grandes dados, em informações, de acordo com o assuntoanalisado, fazendo com que cumpra as etapas de análise de dados. Estudar esse assunto é muito relevante para os pontos de vistas científico, tecnológico, social, profissional e pessoal. Para o ponto de vista científico, é importante porque é uma nova pesquisa sobre o processo de desenvolvimento de sistemas, que apresenta dados atuais sobre desenvolvimento de software,com isso, pode servir para outras áreas de sistemas de informação, que estudam o processo de desenvolvimento de sistemas. Do ponto de vista tecnológico, é importante esta pesquisa, porque se trata de aplicações de técnicas de BI,que apresentam a junção da teoria mencionada por principais autores da área, aplicada em um estudo de caso, de uma empresa de desenvolvimento de software, utilizando ferramentas atuais de BI para analisar os dados. Análise do ponto de vista social e profissional, é importante porque socializa a informação, ou seja, esta pesquisa trata de informações que podem ser utilizadas em favor da sociedade, com intuito de informar pessoas e empresassobrea importância de como as informações obtidas podem servir para conhecimento da área. Do ponto de vista pessoal, é importante para o autor, porque servirá como porta de entrada para o mercado de trabalho na área de BI, além de ter como principal função a satisfação de descrever o assunto com que o autor identifica-se.

17 ESTRUTURA DA MONOGRAFIA A monografia está dividida em cinco partes. O capítulo um apresenta a problemática, os objetivos e justifica o trabalho científico. O capítulo dois é referente à revisão bibliográfica, realizada que apresenta as principais ideias de autores da área sobre o assunto de BI e Data Warehouse. No capítulo três,encontra-se a metodologia de trabalho aplicada na monografia, ou seja, os métodos que foram inseridos para realização da pesquisa. O capítulo quatro descreve a aplicação do problema com a metodologia descrita no capítulo anterior. O Capítulo cinco apresenta a conclusão da monografia.

18 18 2 REVISÃO BIBLIOGRÁFICA Neste capítulo, serão apresentadas referências textuais de autores da área para a compreensão de conceitos sobre o assunto abordado. 2.1 BUSINESS INTELLIGENCE (CONCEITOS E DEFINIÇÕES) Na afirmação de Barbieri (2001, p. 34), O conceito de Business Intelligence, de forma mais ampla, pode ser entendido como a utilização de variadas fontes de informação para definir estratégias de competitividade nos negócios da empresa. Atualmente, o ambiente que empresas estão situadas tem aumentado com a concorrência, portanto para enfrentar essa disputa, tem-se adotadas diversas práticas para coletar dados e transformá-los em informações. Entretanto, em alguns casos, tem-se aplicado o conceito de BI apontado por Barbieri em que empresas estão pesquisando dados de diversas fontes e reunindo em Data Warehouse para efetuar análises. Como afirma Turban et. al. (2009, p. 21): O ambiente de negócios no qual as empresas operam atualmente está se tornando cada vez mais complexo e mutante. As empresas, privadas ou públicas, sentem crescentes pressões forçando-as a responder rapidamente a condições que estão sempre mudando, além de terem que ser inovadoras na maneira com que operam. Portanto,algumas empresas têm construído BI para suprir essa necessidade de conseguir uma resposta de maneira mais ágil e conseguir operar em situações onde a pressão por resultados tem aumentado. Desse modo, o BI tem-se apresentado para empresas como forma de obter as informações de modo rápido e preciso, fazendo com que relatórios não sejam suficientes para processar um volume de dados significante. Na sequência,barbieri(2009, p. 124) relata que a organização vencedora será aquela que entender que o que mantém uma organização competitiva é o seu ativo de conhecimento, representado pelos seus colaboradores. Entretanto, a utilização do BI não

19 19 tem-se apoiado somente em técnicas e abordagem e também em capacidade de raciocínio humano. Turbanet. al. (2009, p. 47) acrescenta que o BI não é uma escolha entre a empresa e, sim, uma necessidade a que está inerente. Percebe-se que mais e mais ferramentas de BI irão invadir o mercado para efetuar análises que podem apresentar os dados de diversos setores. É importante ressaltar que, no entender de Turban (2009, p.27), O conceito original de Sistemas de Informação Executivas foi transformado em BI. Portanto, com essa afirmação, tem-se entendido que BI pode ser um sistema de informação que pode executar análises em dados ou manipulação. Na compreensão de Turban et. al. (2009, p. 32), O principal benefício do BI para empresa é sua capacidade de fornecer informações precisas, quando necessário.podem-se citar, como benefícios, os seguintes pontos: economia de tempo; versão única da verdade; melhores estratégias e planos; melhores decisões táticas; processos mais eficientes; economia de custos. A seguir, a figura 1, expõe a evolução do BI na visão de Turban et. al. (2009), exibindo os recursos que se podem integrar ao sistema de Business Intelligence. Pode-se considerar como ferramentas de arquitetura de BI, ferramentas OLAP, Data Warehouse e ferramentas Front-End, que serão abordados a seguir.

20 20 Figura 1 Evolução do BI Fonte: Turban et. al. (2009, p. 29) Arquitetura de BI Conforme define Turban et. al. (2009, p.28): O BI tem quatro grandes componentes: um data warehouse (DW), com seus dadosfonte a análise de negócios, uma coleção de ferramentas para manipular e analisar os dados no data warehouse, incluindo datamining; businessperformancemanagement (BPM) para monitoraria e análise do desempenho e uma interface de usuário (como o dashboard). Na sequência, Barbieri (2011, p. 108) salienta que: Estruturas especiais de armazenamento de informação como data warehouse (DW), data marts (DM) e ODS (OperationalDataStore), com o objetivo de montar uma base de recursos informacionais capaz de sustentar a camada de inteligência da

21 21 empresa e possível de ser aplicado aos seus negócios, como elementos diferenciais e competitivos. Juntamente com o conceito de DW, DM e ODS, o conceito de BI contempla também o conjunto de ferramentas de desenvolvimento de aplicações e ferramentas de desenvolvimento de aplicações e ferramentas ETL (extração, tratamento e carga), fundamentais para a transformação de recursos de dados transacional em informacional. Com a arquitetura de BI, tem-se ferramentas como aplicações que auxiliam a manipulação de dados. É importante ressaltar que os componentes citados na figura anteriorpodem ter funções definidas como aprovar ou não um pedido de empréstimo (TURBAN EL. AL. 2009, p.31). Nafigura 2,a seguir tem-se a arquitetura de BI dividida em 3 ambientes: ambiente de Data Warehouse, ambiente de análise de negócio e Desempenho de estratégia. O Ambiente de Data Warehouse, organiza, resume e padroniza os dados, o ambiente de negócios acessa e manipula os dados, o desempenho de estratégia têm-se estratégias de BPM (Business Performance Management). Figura 2 Arquitetura de BI Fonte: Turban et. al. (2009, p. 30). Na compreensão de Turban et. al.(2009, p.109), O termo processamento analítico online(olap) refere a uma variedade de atividades normalmente executadas por usuários finais em sistemas online, portanto OLAP tem um conceito complexo, pois não se trata apenas de um módulo de relatórios ou consultas a banco de dados. Ferramentas OLAP podem entender como uma forma de unir análise de relacionamentos, buscar padrões e tendências e exceções. (TURBAN ET. AL. 2009, p. 111).

22 22 Nas palavras de Kimball (2002, p. 3), O data warehouse deve fazer com que informações de uma empresa possam ser facilmente acessadas, portanto, identifica-se o Data Warehouse como uma parte fundamental do BI, responsável por armazenar os dados de forma consolidada. O DW deve ser confiável e obtido a partir de fontes confiáveis da empresa, filtrando apenas os dados interessantes para a análise, preservando o processo de negócio. O Data Warehouse deve ser adaptável a mudanças e seguro, porque é concebido para o dever de guardar as informações.(kimbal, 2002, P.4). Como contempla Turban et. al. (2009, p. 70), Antes dos Data Warehouses, dos data marts e dos softwares de BI, oferecer acesso às fontes de dados era um processo trabalhoso e de grande porte, com tudo, ferramentas ETL podem integrar diversas bases de dados, e ou sistemas de informação (TURBAN EL. AL. 2009, P. 70). As transformações e cargas podem ser consideradas como parte principal do processo de migrações de dados.o processo de migrar o dado consiste em extraí-los, transformá-los e carregá-los. Essa migração ocorre por meio de regras ou por combinações de dados com outros dados. Essas funções são integradas a ferramentas ETL, que retiram os dados de um determinado local e os armazenam em outro local (TURBAN ET. AL. 2009, P. 72). A seguir, são apresentados conceitos de ferramentas ETL e seus processos de migração de dados. 2.2 ETL Em concordância com Barbieri (2001 p. 74), Nessa etapa, deverão ser definidos os processos requeridos de transformação do modelo Fonte para o modelo Dimensional, deste modo essa afirmação conceitua que ETL (Extract, Transform and Load), na tradução de Barbieri (2001, p.74), ETC Extração, Transformação e Carga, pode-se entender como a transformação de dados. Segundo Turbanet. al. (2009, p.71), Um grande objetivo do data warehouse é integrar dados de múltiplos sistemas, entretanto,etl pode ser qualificada como uma tecnologia de integração de dados.(turban et. al., 2009, p.71).

23 23 Parafraseando Turban et. al. (2009, p.72): O objetivo do processo de ETL é carregar os dados integrados e limpos no warehouse. Os dados usados nestes processos podem ser oriundos de qualquer fonte: uma aplicação de main-frame, uma aplicação ERP, uma ferramenta de CRM, um arquivo texto, uma planilha de Excel ou até uma fila de mensagens. Conforme a figura 3, a seguir, pode-se identificar uma forma de realizar o processo de ETL de forma aplicada. Figura 3 - Processo ETL Fonte: Turban et. al. (2009, p. 72) Extração de dados Barbieri (2001, p.75): Uma etapa da extração de dados é filtrar ou limpar os dados, conforme afirma Filtro de Dados: Relaciona os procedimentos e condições para se eliminar os elementos de dados indesejáveis no modelo Dimensional. Por Exemplo, desejamos que somente Ordens de Compras com valores totais maiores que R$: 1000,00 sejam considerados no sistema gerencial do projeto. Após o processo de filtrar ou limpar os dados, tem-se outro processo na compreensão de Turban et. al. (2009, p. 73), Todos os arquivos de entrada são gravados em um conjunto de tabelas temporárias, criadas para facilitar o processo de carga, em suma, esse processo de extração de dados pode-se entender como preparação para transformação de dados que identificamos na próximaetapa.

24 Transformação de dados Para poder transformar ou corrigir os dados limpos, existem outras três etapas na concepção de Barbieri (2001, p.75): Integração de Dados: Define a forma de se correlacionar informações existentes em fontes distintas, e que deverão ser integradas no sistema gerencial. Suponha que alguns dados de fornecedor estejam no BD de fornecedores corporativo da empresa, mas que algumas informações específicas, de interesse da área objeto do sistema aplicado, estejam em planilhas locais. A integração dessas informações se torna fundamental para os requisitos do sistema e deverá ser previsto nessa fase. Outro exemplo poderia ser o caso de dados que estão codificados em um ambiente (por exemplo, o código do fornecedor embute região) e que deverão ser decodificados a fim de facilitar o seu uso, associando-se a ele uma informação explícita sobre região. Condensação de Dados: Define forma de reduzir volumes de dados visando obter informações resumidas e sumariadas. Normalmente essas sumarizações acontecem nas dimensões dos dados, como tempo e geografia. Um exemplo seria sumarização em termos semanais de dados diários de vendas, ou o resumo em níveis geográficos, como por exemplo, vendas por região. Conversão de Dados: Define os procedimentos para se transformar dados unidades, formatos e dimensões diferentes. Porém, uma ressalva feita por Turban et. al. (2009, p. 73), Qualquer problema na qualidade dos dados pertencente aos arquivos-fontes precisa ser corrigido antes que os dados sejam carregados no data warehouse, pode-se entender que o processo de transformação de dados,após estarem dentro do DW,poderá ser grande. Esse processo de transformação de dados pode ser executado por meios de ferramentas tradicionais, como exemplo de algumas linguagens de programação como PL/SQL, C++ ou.net Framework, conforme. (TURBAN et al., 2009, p.73). Após a etapa de transformar os dados pode-se ter a última etapa de ETL, carregar os dados dentro do modelo Dimensional, que será abordado a seguir Carregamento de dados Conforme afirma Barbieri (2001, p. 75), Derivação de Dados: Define os meios e fórmulas para produzir dados virtuais, a partir de dados existentes, assim, definidos os meios e formulas, é efetuada a carga de dados em um modelo dimensional (BARBIERI, 2001, p. 75).

25 25 Sobre carregamento de dados pode ser afirmado que: O processo de carregamento e dados em um data warehouse pode ser realizado por meio de ferramentas de transformação de dados que fornecem uma GUI para auxiliar o desenvolvimento e manutenção das regas de negócios. (TURBAN et al., 2009, p.73.) Entretanto, após a etapa de realizar a carga de dados, pode-se entender Data Warehouse,na sessão seguinte. 2.3 DATA WAREHOUSE Na compreensão de Barbieri (2011, p. 113), [...] um grande depósito central de informações empresariais tratadas, limpas e integradas, construindo inicialmente, e de onde outros depósitos secundários (data marts ou mercados de dados) são originais e construídos. Nas palavras de Kimball (2002, p. 2): Um dos bens mais preciosos de qualquer empresa são suas informações. E quase sempre a empresa mantém esse bem de duas formas: os sistemas operacionais de registro e o data warehouse. Em termos gerais, os sistemas operacionais são o local em que os dados são colocados, e o data warehouse é o local a partir de onde eles são obtidos. Na visão de Turban et. al. (2009, p.57): Em poucas palavras, um data warehouse (DW) é um conjunto de dados produzido para oferecer suporte à tomada de decisões; é também um repositório de dados atuais e históricos de possível interesse aos gerentes de toda a organização. Os dados normalmente são estruturados de modo a estarem disponíveis em formato pronto para as atividades de processamento analítico (p. ex. processamento analítico online [OLAP], data mining, consultas, geração de relatórios, outras aplicações de suporte a decisão). Portanto, um data warehouse é uma coleção de dados orientada por assunto, integrada, variável no tempo e não-volátil, que proporciona suporte ao processo de tomada de decisões da gerência. Entretanto, nas abordagens de Barbieri (2011), Kimbal (2002) e Turban et. al. (2009), pode-se identificar um conceito que converge, como um conjunto de dados para apoiar a tomada de decisão.

26 Abordagem Bill Inmon Sob o ponto de vista de Barbieri (2011, p.113), a abordagem que Bill Inmon concentrou-se inicialmente no estilo tradicional de banco de dados, ou seja, muito próximo do primeiro projeto de banco de dados existente, tentando resolver problemas para integração de dados nas áreas funcionais da empresa. Entretanto, Bill Inmon concebeu uma nova proposta denominada de DW 2.0, com ênfase em metadados e dados não estruturados e também concebeu a ideia de armazenamento no DW ser feito de acordo com a idade dos dados, ou seja, armazenando de forma diferenciada os dados, como exemplo, arquivando dados com mais de cinco anos, dados com data maior que três anos e menor que cinco, ficariam em uma região mais acessível, e dados, com menos de três anos, ficariam no próprio DW. (BARBIERI, 2011, p. 113). Com um estilo mais simples, Ralph Kimball é abordado com sua contribuição na sessão seguinte Abordagem Ralph Kimball Em concordância com autor Barbieri (2011, p. 113), a abordagem de Ralph Kimball pode ser entendida como mais simples, com relação a abordagem de Bill Inmon. A abordagem de Ralph Kimball é feita na metodologia star schema(esquema estrela), apontado para projetos menores e independentes, focado em assuntos específicos, como exemplo a criação de uma Data Marts (DM)para cada departamento dentro da empresa. Portanto, a união desses DM pode-se entender como DW. Após as duas abordagens de Ralph Kimball e Bill Inmon, pode-se demonstrar algumas características do Data Warehouse na sessão a seguir.

27 Características do Data Warehouse Algumas características do Data Warehousepodem ser citadas por Turban et. al. (2009, p. 57). Os dados são organizados por assunto, como vendas, produtos ou cliente, e contêm apenas informações relevantes para apoiar o suporte a decisão. Como afirma Turban et. al. (2009, p.57), Um data warehouse difere de um banco de dados operacional no sentido de que esses, em sua maioria, são orientados por produto e ajustados para lidar com transações que atualizem o banco de dados. O data warehousedeve serintegrado aos assuntos de forma consistente, por exemplo, não deve apresentar diferenças entre unidades de medidas. Deve apresentar variável no tempo, ou seja, apresentar os dados de como visualizações diárias, semanais e mensais. Os dados, no DW, não podem ser inconsistentes, portanto após inseridos não podem ser realizadas nenhuma modificação nos registros. Após as características de um DW, são apresentados os objetivos que podem ser alcançados na sessão a seguir Objetivosdo Data Warehouse Segundo Barbieri (2001, p. 51), A ideia, via DW, é armazenar os dados em vários graus de relacionamento e sumarização, de forma a facilitar e agilizar os processos de tomada de decisão por diferentes níveis gerenciais. Em concordância com Kimball (2002, p.3), Antes de nos aprofundarmos nos detalhes de modelagem e implementação, vale a pena nos concentrarmos nos objetivos fundamentais do data warehouse, com tudo, serão apresentados alguns objetivos do data warehouse na visão de Kimball (2002). Os objetivos do DW podem ser listados como:

28 28 o DW tem que prover acesso facilidade para acesso às informações da empresa; as informações apresentadas por o DW terão que ser consistentes; odata warehouse deve ser adaptado para lidar com mudanças; DW deve ser seguro e proteger as informações; o DW deve dar suporte para a tomada de decisão; deve ser aceito na comunidade de negócio. O autor Kimball (2002, p.3), apresenta uma abordagem para que os objetivos possam ser alcançados e supra essas necessidades, citadas a cima. Com os objetivos traçados, pode-se dar início a arquitetura de Data Warehouse, conforme sessão a seguir Arquitetura do Data Warehouse No entender de Turban et. al. (2009, p. 62), Há algumas arquiteturas básicas de data warehouse. As arquiteturas de duas e de três camadas são comuns, mas, às vezes há apenas uma camada. Com tudo, (TURBAN et al., 2009), divide as três camadas do DW em: o Data Warehouse, o software que extrai e consolida os dados no DW e software responsável por acessar e analisar os dados do DW. Podem-se analisar, a seguir, as duasarquiteturas do DW,divididas em dois tipos, três camadas e duas camadas Arquitetura três camadas A arquitetura de três camadas tem esse nome por se tratar de três camadas que são:o servidor de banco de dados, onde são armazenados os dados referentes ao DW, camada

29 29 de aplicação, onde faz a comunicação entre o servidor de banco de dados e cliente e a camada do cliente onde são apresentados os dados. (TURBAN ET. AL., 2009). Na figura 4,a seguir,sãoapresentadas as três camadas de forma gráfica. Figura 4 - Arquitetura três camadas Fonte: Turban et. al. (2009, p. 63) Arquitetura duas camadas Na arquitetura de duas camadas, a divisão acontece entre servidor de aplicação e banco de dados, fisicamente no mesmo local, ou seja, o servidor de aplicação e banco de dados ficam no mesmo local. Por tanto será apenas um servidor que irá prover os recursos necessários para visualização na camada cliente. (TURBAN ET. AL., 2009). Essa arquitetura oferece uma economia de hardware maior por se tratar de apenas um servidor, porém se obtêm um DW com alto volume de dados, poderá ser prejudicial para o desempenho do servidor. (TURBAN ET. AL., 2009). Conforme figura 5 a seguir, é apresentada a arquitetura em duas camadas.

30 30 Figura 5 - Arquitetura duas camadas Fonte: Turban et. al. (2009, p. 64). Após apresentar sobre a arquitetura de um DW, poderá ser iniciado um tópico sobre o entendimento dos componentes do Data Warehouse Componentes do Data Warehouse De acordo com Kimball (2002, p. 8), [...] precisamos considerar quatro componentes separados e distintos, quando analisamos o ambiente de data warehouse: sistemas operacionais de origem, data staging area, área de apresentação de dados e ferramentas de acessos. Na figura 6 a seguir,encontram-se os componentes do DW proposto pelo autor (KIMBALL, 2002).

31 31 Figura 6 - Componentes do data warehouse Fonte: Kimball (2002, p. 9). a) Sistemas operacionais de origem: Esses são os sistemas operacionais de registro que capturam as transações da empresa. (KIMBALL, 2002, p. 9). Portanto, esses sistemas são externos ao DW e têm a função de extrair os dados; b)data stagingarea: A data staging areado data warehouseé tanto uma área de armazenamento com um conjunto de processos e, normalmente, denomina-se de ETL (KIMBALL, 2002, p. 12), conforme abordado na sessão 2.3; c) Apresentação dos dados: [...] é o local em que os dados ficam organizados, armazenados e tornam-se disponíveis para serem consultados diretamente pelos usuários, por criadores de relatórios e por outras aplicações de análise. (KIMBALL, 2002, p. 13).É onde ficam armazenados os data marts de acordo com os assuntos ou áreas da empresa; d) Ferramenta de acesso: Por definição, todas as ferramentas de acesso de dados consultam os dados na área de apresentação do data warehouse. É claro que a consulta é o ponto principal do uso do data warehouse. (KIMBALL, 2002, p.17). Após a definição de Kimball (2002), sobre os componentes do DW, pode-se apresentar conceitos sobre modelagem dimensional.

32 Modelo dimensional Com referência a modelagem dimensional e tabelas fatos, pode-se citar a afirmação de Kimball (2002, p. 20): Na década de 1970, AC Nielsen e IRI usaram esses termos de modo consistente para descrever suas ofertas de dados corporativos, que poderiam ser descritos precisamente hoje em dia como data marts dimensionais para dados de vendas no varejo. Muito antes de a simplicidade ser um estilo de vida, os desenvolvedores de bancos de dados adotaram esses conceitos para simplificar a apresentação de informações analíticas. Eles compreenderam que um banco de dados não seria usado a menos que fosse incluído de forma simples. Na visão de Machado (2011, p. 79): A modelagem multidimensional é uma técnica de concepção e visualização de um modelo de dados de um conjunto de medidas que descrevem aspectos comuns de negócios. É utilizada especialmente para sumarizar e reestruturar dados e apresentalos em visões que suportem a análise dos valores desses dados. Portanto, a modelagem dimensional pode ser uma forma de modelar os dados, para que os dados fiquem de fácil acesso para manipulação e/ou extração de relatórios (KIMBALL, 2002, p.20). Em comum, os autores Barbieri (2001), Kimball (2002) e Machado (2011), citam que a modelagem dimensional é composta dos seguintes itens: tabela fato; tabela de dimensão; medidas. Para o melhor entendimento, os itens, citados a cima, serão abordados nas próximas sessões Tabelas fato Em concordância com Kimball (2002, p. 21), Uma tabela de fatos é a principal tabela de um modelo dimensional em que as medições numéricas de desempenho da empresa estão armazenadas. A tabela fato é responsável por armazenar os dados de medição dos processos de negócio em um único local. (KIMBALL, 2002, p.21).

33 33 A palavra fato pode representar uma medição de negócio. Pode-se imaginar as vendas diárias de um mercado, em que cada dia é anotado a quantidade de produtos vendidos e quantidade de venda em dinheiro para cada produto comercializado. Então é feito um agrupamento por dia, produto e valor, resultando em uma linha para cada item agrupado (KIMBALL, 2002, p.21). A seguir, é exibida a figura 7 que representa um exemplo de tabela fato. Figura 7 - Tabela fato Fonte: Kimball (2002, p. 21). Para Kimball (2002, p. 23), Todas tabelas de fatos possuem duas ou mais chaves estrangeiras, conforme designado na notação FK (foreign key). Essa notação é apresentada na figura 7, acima. Todavia essa chave estrangeira pode se referir a outra tabela, como exemplo, na figura 7 Chave do Produto (FK), que pode referenciar uma tabela de produtos que podem descrever produtos cadastros. Essa aplicação pode-se fazer para que não seja perdido a referência do produto descrito na tabela fato. (KIMBALL, 2002, p. 23). Citando a afirmação de Kimball (2002, p. 23), [...] veremos que todas as granularidades de uma tabela de fatos enquadram-se em uma destas três categorias: transação, instantâneos periódico e instantâneos acumulados. Podeser abordado o assunto granularidade de tabela fato na sessão seguinte Granularidade 37): O conceito de granularidade pode ser apresentado conforme Kimball (2002, p.

34 34 Declare o grão (nível de detalhes) do processo de negócio. Declarar o grão significa especificar exatamente o que cada linha da tabela de fatos representa. O grão exprime o nível de detalhes associados às medidas da tabela de fatos. Ele fornece a resposta para a pergunta: Como descrever uma linha específica na tabela de fatos?. São exemplos de declaração de grãos: um item de linha individual em um ticket de vendas a varejo de um cliente à medida que é lido por um dispositivo de varredura (scanner); um item de linha em uma conta recebida de um médico; um cartão de embarque individual para entrar no avião; um instantâneo diário dos níveis de estoque de cada produto em um warehouse; um instantâneo mensal de cada conta bancária. Conforme descrito por Kimball (2002), a granularidade de tabelas fato instantâneos periódicos são para apresentar dados em períodos de tempo regulares, exemplo o valor em venda para os produtos dividido em meses. Outra granularidade é fato de transação que representa os dados de um acontecimento no tempo instantâneo. Fato de instantâneo cumulativo pode representar diversas datas e múltiplos eventos. Após o descrito sobre tabelas fatos e granularidade, poderá ser apresentado, na próxima sessão sobre tabelas de dimensão Tabelas de dimensão Como afirma Kimball (2002, p. 24), Em um modelo dimensional bem projetado, as tabelas dimensão possuem muitas colunas ou atributos. Esses atributos descrevem as linhas na tabela de dimensão. Entretanto, a tabela de dimensão está sempre acompanhada a uma tabela fato. Elas podem ser caracterizadas por carregar os atributos da tabela fato, porém em uma tabela dimensão (KIMBALL, 2002, p. 25). No exemplo, a seguir, pode-se ter entendimento de vários atributos carregados em tabelas de dimensão. Como exemplo, na figura 8, é apresentada uma tabela dimensão de um produto, em que essa tabela pode conter atributos desse produto.

35 35 Figura 8 - Tabela dimensão Fonte: Kimball (2002, p. 25). Conforme afirmação de Kimball (2002, p. 25), Os melhores atributos são os textuais e os discretos. Os atributos devem ser formados por palavras reais e não por abreviações criptografadas. Na concepção de Machado (2011, p. 6), Conceitualmente são os elementos que participam de um fato, assunto de negócios. São as possíveis formas de visualizar os dados, ou seja, são os por dos dados: por mês, por país, por produto e por região. Após apresentar, nas sessões anteriores, sobre os assuntos tabela fato, granularidade e tabela dimensão, pode-se apresentar a sessão de medidas, ou variáveis, como afirma Machado (2011) Medidas (variáveis) Na visão de Machado (2011, p. 81), Medidas são atributos numéricos que representam um fato, a performance de um indicador de negócios relativo às dimensões que participam desse fato, é possível citar alguns exemplos de medida como: valor total das

36 36 vendas, quantidade de produtos vendidos, quantidade em estoque de produtos, custo da venda e lucro obtido com venda. Medidas podem ser entendidas como as variáveis que serão calculadas, existente dentro da tabela fato, ou a forma que será calculada. Na próxima sessão, será feita a união do conteúdo apresentado nas sessões anteriores, contendo tabela fatos e dimensão, podendo ser resultado em um data warehouse União de fatos e dimensão Para Barbieri (2001, p.81), O produto final da modelagem Dimensional é a produção de um modelo conceitual dimensional, formado por tabelas fatos e tabelas dimensão. No entendimento de Kimball (2002, p. 27), [...] a tabela de fatos formada por medidas numéricas é associada a um conjunto de tabelas dimensão preenchidas com atributos descritivos. Na compreensão Machado (2011, p. 92): O modelo estrela é a estrutura básica de um modelo de dados multidimensional. Sua composição típica possui uma grande entidade central denominada fato (fact table) e um conjunto de entidades menores denominadas dimensões (dimension table), arranjadas ao redor dessa entidade central, formando uma estrela. A visão dos três autores, citados a cima, Barbieri (2001), Kimball (2002) e Machado (2011), podem convergir para o mesmo modelo dimensional, ou esquema estrela, conforme figura 9, apresentada a seguir, podendo serem visualizadas as dimensões tempo, região, cliente, vendedor e produto, e apresentando a tabela de fato vendas.

37 37 Figura 9 - Modelo estrela Fonte: Machado (2011, p. 92). Com a compreensão de modelo dimensional, poderá ser abordado, na próxima sessão, OLAP, responsável por apresentar os dados existentes no DW. 2.4 OLAP OLAP, na concepção de Machado (2011, p.85), É o conjunto de ferramentas que possibilitam efetuar a exploração dos dados de um data warehouse. De acordo com Thomsen (2002, p. 5): Os conceitos de OLAP incluem a noção ou ideia de múltiplas dimensões hierárquicas e podem ser usadas por qualquer um para que se pense mais claramente a respeito do mundo, seja o mundo material da escala atômica à escala galáctica, o mundo econômico dos micro agentes às macro economias, ou o mundo social dos relacionamentos interpessoais aos internacionais. Em outras palavras, mesmo sem qualquer tipo de linguagem formal, é útil apenas sermos capazes de pensar em termos de um mundo multidimensional e com múltiplos níveis, independente da sua posição na vida. No entender de Turban et. al. (2009, p. 109): O termo processamento analítico online (OLAP) se refere a uma variedade de atividades normalmente executadas por usuários finais em sistemas online. Não há um consenso sobre quais atividades são consideradas OLAP. Normalmente, OLAP inclui atividades como geração de respostas de consultas, solicitação de relatórios e gráficos ad hoc e execução dos mesmos, realização de análises estatísticas tradicionais ou modernas e construção e apresentação visuais.

38 38 Basicamente os produtos de OLAP oferecem recursos de modelagem, análise e visualização de grandes conjuntos de dados, ou para sistemas de gerenciamento de banco de dados (SGBD) ou, mais frequentemente, para sistemas de data warehouse. Os produtos oferecem também uma visão conceitual multidimensional dos dados. A seguir, serão apresentados conceitos de operações básicas de OLAP.No entender de Machado (2011, p. 85), [...] são as aplicações às quais os usuários finais têm acesso para extrair os dados de suas bases e construir os relatórios capazes de responder às suas questões gerenciais Drill Down Na visão de Machado (2011, p. 86), São as operações para movimentar a visão dos dados ao longo dos níveis hierárquicos de uma dimensão. Portanto, quando é utilizada essa operação básica, aumenta-se o nível de detalhamento da informação ediminui-se o nível de granularidade. (MACHADO 2011, p. 86). A seguir, é apresentada a figura 10 da operação de Drill Down. Figura 10 Operação Drill Down Fonte: Machado (2011, p. 87).

39 Roll Up Na afirmação de Machado (2011, p. 87), O Drill Up ou Roll Up é o contrário. Ele ocorre quando o usuário aumenta o nível de granularidade, diminuindo o nível de detalhamento da informação. A seguir, é possível visualizar a figura 11 da operação Roll Up. Figura 11 Operação Roll Up Fonte: Machado (2011, p. 86) Drill Across Conforme Machado (2011, p. 88), Drill Across Ocorre quando o usuário pula de um nível intermediário dentro de uma mesma dimensão. Por exemplo: a dimensão tempo é composta por ano, semestre, trimestre, mês e dia. A seguir, encontra-se a operação Drill Across, representado por a figura 12. Figura 12 Operação Drill Across

40 40 Fonte: Machado (2011, p. 88) Slice and Dice No entender de Machado (2011, p. 89): São operações para realizar navegação por meio dos dados na visualização de um cubo. Slice and Dice significa em outra forma simplista a redução do escopo dos dados em análise, além de mudar a ordem das dimensões, mudando desta forma a orientação segundo a qual os dados são visualizados. A seguir, é apresentado um exemplo da operação Slice and Dice na figura 13. Figura 13 Operação Slice and Dice

41 41 Fonte: Machado (2011, p. 90) Pivot Segundo Machado (2011, p. 91), Pivot É o ângulo pelo qual os dados são vistos ou trocados. Na prática, corresponde à modificação da posição das dimensões em um gráfico ou troca de linhas por colunas em uma tabela. 2.5 CONSIDERAÇÕES FINAIS DO CAPÍTULO No próximo capítulo, seráabordadaa proposta de solução definida por o autor,para sanar o problema apresentado no item 1.1 Problema, atendendo ao objetivo geral deste trabalhado, apresentado no item Objetivo geral, e também aos objetivos específicos no

42 42 item Objetivos específicos,conforme os conceitos apresentados no capítulo dois da revisão bibliográfica.

43 43 3 MÉTODO A seguir, será apresentado o método aplicado a este trabalho com referências a autores da área de ciência e método. 3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA Do ponto de vista da natureza, este trabalho pode ser considerado de pesquisa aplicada, na visão de Silva e Menezes (2005, p. 20), Objetiva gerar conhecimentos para aplicação prática e dirigidos à solução de problemas específicos,envolvendo verdades e interesses locais. Portanto visa a gerar conhecimento para aplicação da arquitetura de Business Intelligence aplicada no problema específico. A abordagem pode ser considerada pesquisa qualitativa, também, porque, na interpretação de Silva e Menezes (2005, p.20), Não requer o uso de métodos e técnicas estatísticas. O ambiente natural é a fonte direta para coleta de dados, e o pesquisador é o instrumento chave. Do ponto de vista dos objetivos, esta pesquisa pode ser considerada exploratória, porque, segundo (SILVA E MENEZES 2005, p.21), contém levantamento bibliográfico e existe um caso a ser estudado. Os procedimentos técnicos aplicados no trabalho conforme (SILVA E MENEZES 2005, p.21), são pesquisas bibliográficas, porque foi elaborado a partir de matérias de autores renomados da área de estudo para realizar embasamento teórico, bem como estudo de caso, já que tem um limite definido a ser estudado.

44 ATIVIDADES METODOLÓGICAS Para alcançar os objetivos descritos, nos itens Objetivo geral- e Objetivos específicos-, o trabalho foi divido nas seguintes atividades: a) definição do tema, definir o problema descrito, descrever objetivos a serem alcançados e apresentar uma justificativa para o estudo de caso, conforme conteúdo do capítulo 1; b) elaborar pesquisa com referência dos principais autores de renome da área de Business Intelligence, para contextualizar os assuntos aplicados e entender conceitos que podem ser aplicados no trabalho. Esse conteúdo é apresentado no capítulo 2; c) caracterizar a pesquisa, definir as etapas, produzir a arquitetura para solução proposta de acordo com o problema encontrado, apresentar as delimitações e cronograma das atividades que o autor realizará. Esseconteúdoéapresentado no capítulo 3; d) apróxima etapa consiste em apresentar uma arquitetura proposta para a solução do problema. Para isso é necessário: entender os dados e o problema do domínio de aplicação do sistema,que é na área de desenvolvimento de software; levantar os requisitos que atendam ao problema encontrado na etapa anterior; realizar a criação dos diagrama domínio, casos de uso, robustez e sequência, de acordo com a metodologia ICONIX; criar um modelo dimensional de forma gráfica que atenderá o problema encontrado, com definição de granularidade dos dados; efetuar a criação do banco de dados, com tabelas e campos de acordo com o modelo dimensional (DW); efetuar uma adequação e limpeza dos dados para adequar-se ao modelo dimensional; carregar os dados no modelo dimensional, contidos em banco de dados, utilizando ferramentas definidas pelo autor;

45 45 analisar e interpretar os dados carregados no modelo dimensional através de ferramentas apropriadas definidas pelo autor; apresentar informações sobre a análise realizada na etapa anterior. e) apresentação dos resultados obtidos com a pesquisa realizada, com base nas análises efetuadas. 3.3 ARQUITETURA DA SOLUÇÃO Para representação da arquitetura utilizada, foi elaborado pelo autor conforme figura 14,a seguir, uma possível arquitetura da solução. Figura 14 Arquitetura de BI Solução Proposta Fonte: O autor. A seguir,é apresentado a descrição de cada componente listado na figura 14 Arquitetura de BI. Base de dados: conjunto de dados das demandas realizadas na organização em projetos. ETL (extração, carga e transformação dos dados): momento em que serão preparados os dados da base de dados para carga no Data Warehouse. Data Warehouse: local onde serão armazenados os dados transformados em um modelo dimensional.

46 46 Análise de dados: momento em que serão realizadas análises nos dados contidos do DW, utilizando ferramentas OLAP. 3.4 DELIMITAÇÕES O trabalho foi delimitado com base na arquitetura de BI, proposta no item 3.3. ARQUITETURA DA SOLUÇÃO. Os dados utilizados são provenientes de projetos de desenvolvimento de software por uma organização entre os anos de 2008 e CONSIDERAÇÕES FINAIS DO CAPÍTULO Nesse capítulo, foi descrito o método aplicado no trabalho e tipo de pesquisa realizado. É apresentado de como serão seguidasas atividades até o termino do trabalho e uma possível arquitetura de solução para conseguir alcançar os objetivos propostos, nos itens Objetivo geral- e Objetivos específicos-. A seguir, será apresentada a realização da estrutura proposta no item 3.3. ARQUITETURA DA SOLUÇÃO, seguindo o as atividades descritas no item 3.2. ATIVIDADES METODOLOGICAS.

47 47 4 DESENVOLVIMENTO DA SOLUÇÃO Neste capítulo, será apresentada uma possível solução para atender ao problema encontrado no item 1.1. PROBLEMÁTICA, seguindo as atividades descritas no item 3.2. ATIVIDADE METODOLOGICA e, de acordo com o item 3.3. ARQUITETURA DA SOLUÇÃO, utilizando a metodologia ICONIX. 4.1 METODOLOGIA ICONIX De acordo com Bona (2002, p.60), o ICONIX é um processo simplificado que unifica conjuntos de métodos de orientação a objetos em uma abordagem completa, com o objetivo de dar cobertura ao ciclo de vida., Na compreensão de Silva e Videira (2001, apudbona, 2002, p. 60), eles apresentam o ICONIX como uma metodologia prática, intermediária entre a complexidade do RUP (Rational Unified Process) e a simplicidade do XP (Extreme Programming). Na afirmação de Rosenberg & Scott (1999, apud BONA, 2002, p. 61), a base do ICONIX é responder algumas questões fundamentais sobre o software, Conforme essa afirmação, são utilizados técnicas UML (Unified Modeling Language) que auxiliam para encontrar a melhor resposta. A seguir, são apresentadas as técnicas: (ROSENBERG & SCOTT, 1999, apud BONA, 2002, p. 61), que são: quem são os usuários ou atores do sistema, e o que eles estão tentando fazer, para responder essa questão é elaborado o diagrama de casos de uso; no mundo real (domínio do problema), os objetos e as associações que existem entre eles, para responder essa questão é elaborado o diagrama de classes de alto nível; entender os objetos necessários para cada caso de uso, para responder essa questão é elaborado a análise de robustez; qual a iteração entre os objetos em cada caso de uso, para responder essa questão é elaborado diagrama de sequência;

48 48 como serão manipulados os aspectos de controle, para responder essa questão é elaborado diagrama de estado; como na prática será construído o sistema, para responder essa questão é elaborado o diagrama de classe de baixo nível. Em concordância com (BORILLO, 2000, apud BONA, 2002, p. 61), pode-se destacar três características fundamentais que a metodologia ICONIX apresenta: iterativo e incremental: diversas iterações no momento do desenvolvimento do diagrama de domínio e identificação do diagrama de casos de uso; rastreabilidade (traceability): todos requisitos são referenciados de alguma forma, dentro dos diagramas,identificando o impacto da alteração de um requisito em todos os artefatos; metodologia UML: a metodologia oferece os diagramas de casos de uso, sequência e colaboração e robustez. A seguir,serão apresentado as quatro tarefas/etapas principais da modelagem ICONIX. (ROSENBERG & SCOOT, 1999, apud BONA, 2002, p. 62) Análise de requisitos requisitos, que são: Pode-se visualizar, na figura 15, a seguir, as tarefas que compõem a análise de Figura 15 Análise de requisitos - ICONIX Fonte: Bona(2002, p. 62).

49 49 modelo de domínio: responsável por identificar os objetos, relação de agregação e relação de generalização, entre eles; protótipo: apresentar, se possível, os protótipos de telas de forma rápida, para que seja identificado o modo de navegação entre telas, para que seja possível a maior compreensão do sistema; casos de uso: apresentar os atores que terão ligação com os casos de uso do sistema; pacote: agrupar os casos de uso; associação requisitos: associar requisitos funcionais aos casos de uso e aos objetos de casos de uso, promovendo uma interação entre os diagramas anteriores. (BONA, 2002, p. 62) Análise de projeto preliminar Na figura 16, a seguir, podem-se identificar tarefas que fazem parte da análise de projeto preliminar, que são: Figura 16 Análise de projeto preliminar Fonte: Bona (2002, p. 63). modelo caso de uso: apresentar os fluxos principais, fluxos alternativos e/ou fluxos de exceções dos casos de uso; análise de robustez: apresentar um conjunto de objetos para cada caso de uso;

50 50 diagrama de classe: atualizar o diagrama de classe criado na etapa anterior. (BONA, 2002, p. 63) Projeto Na figura 17, a seguir, podem-se observar as atividades eminentes à etapa de projeto. (BONA, 2002, p. 64), que são: Figura 17 Revisão detalhada do projeto Fonte: Bona (2002, p. 64) diagrama de sequência: responsável por identificar comportamentos do diagrama de casos de uso, assim como as mensagens entre os objetos; diagrama de classe: atualizar o diagrama de classe adicionando o modelo estático; analisar e verificar se o projeto atende a solução proposta.(bona, 2002, p. 64) Implementação Na afirmação de Bona (2002, p. 64): As atividades que dão suporte a tarefa de implementação são: utilizar diagrama de componente, se for necessário para apoiar a fase de desenvolvimento; escrever/gerar o código; realizar testes de unidade e de integração; realizar testes de aceitação do usuário.

51 51 A seguir, será realizada a modelagem e desenvolvimento da solução, com base na metodologia ICONIX, apresentada na sessão anterior. 4.2 PROTÓTIPO DA SOLUÇÃO Nesta sessão será desenvolvido o protótipo da solução propostas, utilizando a metodologia ICONIX, entretanto, não serão apresentados os diagramas de classes e prototipação de telas, por não se tratar de modelagem orientada a objetos Levantamento de requisitos Seguindo a metodologia ICONIX, foram encontrados os seguintes requisitos funcionais para a arquitetura de BI abordada: RF001 - A arquitetura de BI deve conter um banco de dados relacional Descrição: para elaborar a arquitetura de BI será necessário um banco de dados relacional, com dados normalizados. RF002 - A arquitetura de BI deve ter possibilidadede realizar carga, extração e transformação de dados com uma ferramenta ETL Descrição: para enviar os dados do banco relacional para Data Warehouse, será necessário ferramenta ETL, que fará a extração, transformação e carga dos dados. RF003 - A arquitetura de BI deve conter um Data Warehouse DW Descrição: o DW terá, como principal função, a visualização dos dados e a facilitação em consultas. RF004 - A arquitetura de BI deve ter a possibilidade de realizar análise de dados com uma ferramenta front-end OLAP Descrição: a análise realizada no data warehouse será feita por ferramenta OLAP. RF005 - A arquitetura de BI deve apresentar dados da performance entre equipes e entre pessoas referente ao total de tempo estimado e total de tempo realizado

52 52 Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados de performance entre equipes e entre pessoas, referente ao total de tempo estimado e total de tempo realizado. RF006 - A arquitetura de BI deve apresentar dados dos projetos realizados, com o tempo total estimado e tempo total realizado Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados dos projetos realizados, com tempo total estimado e tempo total realizado. RF007 - A arquitetura de BI deve apresentar os dados divididos em dia, mês, ano e semana Descrição: a ferramenta OLAP deverá apresentar, em um relatório,os dados divididos em dia, mês, ano e semana. RF008 - A arquitetura de BI deve apresentar os projetos que tiveram o tempo total realizado próximo ao tempo total estimado Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados de projetos que tiveram tempo total realizado próximo ao tempo total estimado. RF009 - A arquitetura de BI deve apresentar as pessoas que participaram dos projetos e tiveram o tempo total estimado próximo ao tempo total realizado Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados de pessoas que participaram dos projetos e tiveram o tempo total estimado próximo ao tempo total realizado. A seguir, pode-se identificar a figura 18 com os requisitos funcionais levantados.

53 53 Figura 18 Requisitos funcionais Fonte: O autor Casos de uso BI. A seguir,são apresentados os casos de uso elaborado pelo autor para arquitetura de

54 54 Figura 19 Casos de uso Fonte: O autor. arquitetura de BI: A seguir, é apresentadaa definição dos atores envolvidos nos casos de uso da Tabela 1 Definição de atores Ator Definição Administrador Analista de negócio Fonte: O autor. - responsável por fazer a extração, transformação e carga dos dados; - para esse ator são definidos apenas tarefas técnicas, e não exerce nenhuma análise sobre os dados. - responsável por realizar análise dos dados já dentro do data warehouse, com auxílio de ferramenta OLAP; - para esse ator são definidas tarefas de análise do negócio, portanto, não realiza ajustes técnicos na arquitetura de BI.

55 55 Na próxima tabela, são apresentados os casos de usos principais que compõem a arquitetura de BI, a eles, em especial, seus fluxos. Tabela 2 UCE001 Importar dados com ferramenta ETL UCE001 - Importar dados com ferramenta ETL Nome Importar dados com ferramenta ETL Identificador UCE001 O administrador extrai, transforma e carrega os dados no Descrição data warehouse Ator primário Administrador Pré-condição Existir banco de dados relacional 1 - administrador seleciona fonte de dados que deverá ser importada; Fluxo principal 2 - administrador efetua limpeza de dados; 3 - administrador efetua carga de dados no DW. Fluxo alternativo Não Os dados do banco de dados relacional são carregados do Pós-condição DW Regras de negócio Não Fonte: O autor. Tabela 3 UCE003 Criar data warehouse UCE002 - Criar Data Warehouse - DW Nome Criar Data Warehouse - DW Identificador UCE002 Descrição O administrador cria o data warehouse Ator primário Administrador Pré-condição Existir banco de dados relacional 1 - administrador identifica no modelo relacional campos e Fluxo principal tabelas necessárias para utilizar no DW; 2 - administrador cria as tabelas do DW. Fluxo alternativo Não Pós-condição Regras de negócio Fonte: O autor. O DW é criado Não Tabela 4 - UCE003 - Analisar dados comferramenta OLAP UCE003 - Analisar dados comferramenta OLAP Nome Analisar dados comferramenta OLAP Identificador UCE003 Descrição O analista de negócio analisa os dados do DW Ator primário Analista de negócio Pré-condição Existir banco de dados relacional 1 - Analista de negócio conecta ferramenta OLAP no data Fluxo principal warehouse; 2 - Analista de negócio criar as tabelas do DW. Fluxo alternativo Não Pós-condição Os dados são analisados com ferramentas OLAP

56 56 Regras de negócio Fonte: O autor. Não Diagrama de robustez A seguir, é apresentado o diagrama de robustez da arquitetura de BI. Figura 20 Diagrama de robustez Fonte: O autor.

57 Diagrama de sequência arquitetura de BI. Nesta sessão, é apresentado o digrama de sequência dos principais casos de uso da Figura 21 UCE001 diagrama de sequência Fonte: O autor.

58 58 Figura 22 UCE002 diagrama de sequência Fonte: O autor. Figura 23 - UCE003 - diagrama de sequência Fonte: O autor.

59 CONSIDERAÇÕES FINAIS DA MODELAGEM Através do conceito de ICONIX, foi permitido elaborar a modelagem para a arquitetura de BI com base na problemática do trabalho. No próximo capítulo, será descrito sobre o estudo de caso realizado na empresa desenvolvedora de software, assim como a solução encontrada.

60 60 5 ESTUDO DE CASO EMPRESA DESENVOLVEDORA DE SOFTWARE Neste capítulo, será abordado o estudo de caso da empresa desenvolvedora de software, por tanto será apresentado uma possível solução encontrada de como montar a arquitetura de BI para, assim, algumas análises. A seguir, é apresentado o item sobre as ferramentas utilizadas para o planejamento e desenvolvimento do trabalho. 5.1 FERRAMENTAS E TECNOLOGIA As ferramentas utilizadas do pacote Microsoft Office foram Microsoft Excel, Microsoft Visio e Microsoft Word, essas ferramentas foram escolhidas por se tratar das ferramentas que o autor utiliza diariamente, por isso tem experiência e familiaridade na utilização. As ferramentas que merecem destaque do pacote Microsoft Office são Microsoft Excel, porque foi utilizado para verificar se a importação dos dados está correta com relação a integridade dos dados e Microsoft Word que foi o local onde se armazenou a descrição do texto referente ao trabalho. Além do pacote Microsoft Office, foramutilizadas as ferramentas BI Server, Data Integration (Spon), Schema Workbench esaiku, que pertencem a Pentaho Solutions.Pode-se dar ênfase a ferrramenta Data Integration, local em que se realizou-se a extração, transformação e carga referente aos dados coletados sobre os tíquetes de desenvolvimento de software, assim, como a ferramenta Saiku, local em que foram analisados os dados após sua extração, transformação e carga. Como banco de dados relacional foi utilizado o MYSQL, banco de dados responsável por armazenar os dados sem tratamento dos tíquetes que a empresa forneceu para a extração dos dados. Para o DW foi utilizado o banco de dados PostgreSQL, banco de dados em que foi realizada a carga dos dados tratados. A utilização do PostgreSQL sucedeu-se por se tratar do banco de dados em que o autor tem familiaridade e utiliza nos seus trabalhos acadêmicos. Foi utilizada a linguagem SQL (Structured Query Language), linguagem para realizar consultas de análise dos dados, utilizadas nos bancos de dados MYSQL e PostgreSQL.

61 61 O quadro, a seguir, apresenta as tecnologias utilizadas, que o autor utilizou por apresentar domínio sobre as tecnologias. Tabela 5 Tecnologias utilizadas Ferramentas Uso DB Designer Fork Modelagem do Data Warehouse Pentaho Data Integration Exportação e importação de dados, assim como apresentação em relatório. Enterprise Architect Modelagem casos de uso, robustez e sequência. Excel Auxiliar na validação de importação e exportação Banco de dados MYSQL Local em que se encontra os dados no modelo relacional Banco de dados Postgre Local em que se encontra o DW SQL Linguagem utilizada para realizar consultas no banco de dados

62 62 Saiku analitycal Ferramenta para analisar dados através de relatório. Plugin do Data Integration Pentaho. Visio Ferramenta utilizada na modelagem da solução do problema. Windows 7 Sistema operacional que roda todas as aplicações utilizadas. Word Fonte: O autor Ferramenta para realizar edição de textos. 5.2 APRESENTAÇÃO DA ARQUITETURA DE BI Nas sessões, a seguir, será apresentada a arquitetura de BI, back-end e front-end, ou seja, back-end, as tarefas realizadas para construção do BI, extração de dados do modelo banco de dados relacional, transformação dos dados e importação dos dados no DW, assim como a construção do cubo de dados para análises.para front-end, são realizadas as tarefas de análise de dados através de relatórios. (KIMBALL, 2002).

63 A empresa A empresa XXX, atualmente, produz soluções de telefonias e softwares para contact centers com sede na cidade de Florianópolis Santa Catarina. Com aumento da demanda por suas soluções, a empresa XXX começou a ter problemas com relação ao processo de desenvolvimento, com isso,a empresamanifestou interesse em analisar os processos internos de desenvolvimento de software e telefonia para encontrar os pontos de melhora no processo de produção. O controle no processo de desenvolvimento, atualmente, é realizado através do software gerenciador de demandas, que, transformada cada tarefa em tíquetes, ou seja, independentemente do tipo da demanda, é aberto um tíquete que contém descrito a necessidade do cliente para incluir no software. Com isso, foi elaborado uma possível solução de análise de dados, utilizandotécnicas de BI descrita no segundo capítulo, em que são apresentados a seguir Arquitetura de BI: back-end Para ilustrar a montagem da arquitetura back-ende front-end,assim como suas etapas, foi elaborado pelo autor uma imagem que representa as etapas para construção da arquitetura de BI, assim como, ossoftwares utilizados para cada passo. Na próxima figura, é exibido dois atores que serão representados por o autor que executou todos os passos.

64 64 Figura 24 - etapas back-end Fonte: O autor. A primeira tarefa, para realização da montagem da arquitetura de BI, foi extrair os dados do sistema de gerenciamento de demandas da qual a empresa faz uso. Com tudo, as etapas são, realizar a criação do modelo dimensional de acordo com os requisitos coletados, com DB Designer. Executar consultas no banco de dados relacional MYSQL, para recuperar os dados necessários utilizados na ferramentapentaho Data Integration. Com essas consultas montadas, o próximo passo é transformar os dados extraídos, para realizar a carga de dados no DW. Com esses passos concluídos, a próxima tarefa é criar o cubo de dados, com a ferramenta Pentaho Workbench, e validar os dados extraindo-os em planilhas de Excel. Com todas as tarefas de back-endrealizadas, exercida pelo papel do administrador, as tarefas seguintes são exercidas pelo papel do analista, que com auxílio do sistema operacional Windows 7, e a ferramenta Pentaho Saiku, são montados gráficos que exibem as análises geradas. Após realizado as tarefas de back-end e front-end, é realizado a documentação do processo de criação da arquitetura de BI, nas ferramentas Word e Visio, do fabricante Microsoft.

65 65 do banco de dados. A seguir, o modelo de entidade relacionamento referente a esse software,extraído Figura 25 Modelo entidade relacionamento Fonte: O autor.

66 66 A tabela ISSUES representa as demandas criadas no software, contudo ela armazena dados como data de criação (created_on), status do tíquete (status), número do tíquete (id), projeto pertencente (project_id), categoria do tíquete (category_id) e prioridade (priority_id). Na tabela USERS, fica armazenado o usuário responsável por criar o tíquete relacionando com a tabela ISSUES através do campo assigned_to_id. A tabela que armazena informações do status do tíquete é ISSUE_STATUSES, que se relaciona a tabela ISSUES através do status_id. A tabela PROJECTS se relaciona à tabela ISSUES através do project_id.nessa tabela,são armazenados os projetos existentes na empresa. A tabela TIME_ENTRIES é utilizada para armazenar o tempo do tíquete, ou seja, para cada intervenção do usuário no tíquete, é mencionado o tempo corrente.esses dados são armazenados nessa tabela juntamente com o id da tabela ISSUES. Na tabela CUSTOM_VALUES são armazenados dados do tempo estimado de cada tíquete, ou seja, pode-se ter uma demanda estimada pela área de banco de dados da empresa em duas horas, porém o tempo total utilizado é armazenado na tabela TIME_ENTRIES.Essa tabela armazena o id da tabela ISSUES, para que seja encontrada o tempo de cada tíquete estimado. Por último, tem-se a tabela ISSUE_CATEGORIES, referente à categoria do tíquete, ou seja, pode existir um registro na tabela ISSUES que armazena a categoria, como, exemplo, banco de dados. Após realizado a caracterização das tabelas utilizadas para extrair dados, é iniciado a transformação dos dados. A seguir, é apresentado o Data Warehouse, responsável por armazenar os dados transformados. O conceito de DW está descrito, no segundo capítulo, assim, como os conceitos para criação dos modelos dimensionais e também conceitos de criação da tabela fato.

67 67 Figura 26 - Modelo DW Fonte: O autor. Para criação do DW, foi utilizado o software DB Designer, descrito na sessão anterior para modelagem dimensional. A tabela DI_TEMPO são armazenados dados de datas existentes na criação dos tíquetes, ou seja, são recuperados os valores de data de abertura do tíquete presentes no modelo relacional tabela ISSUES campo created_on.esse campo foi divido em dia, mês, ano e semana, para que seja visualizado no relatório. Na tabela DI_PROJETO são armazenados os nomes dos projetos.esses nomes são encontrados no modelo relacional, tabela PROJECTS, no campo name. Na tabela DI_TICKET são armazenados os números de cada tíquete, ou seja, esse campo é preenchido de acordo com a tabela ISSUES, campo id do modelo relacional. Na tabela DI_CATEGORIA são armazenados os nomes das categorias existentes, na tabela ISSUE_CATEGORIES campo name, encontrada no modelo relacional. Na tabela DI_STATUS são armazenados os nomes de cada status referente a tabela ISSUE_STATUSES encontrada no modelo relacional, no campo name. Natabela DI_RESPONSAVEL_AREA são armazenados os nomes e áreas dos responsáveispela criaçãodo tíquete, referente a tabela USERS campo name do modelo relacional, em que no

68 68 mesmo campo foi extraído a área do responsável e nome. Na tabela fato FT_TICKETS, foramreunidas as medidas de tempo total realizado, tempo total estimado, se pertence a release e prioridade de abertura. As informações extraídas das tabelas CUSTOM_VALUES são para cálculos de horas estimadas e para verificar se o tíquete pertence à release, ou não. O tempo total realizado é obtido através da soma das horas realizadas, da tabela TIME_ENTRIES. Por fim, a prioridade é calculada com base no campo PRIORITY_ID da tabela ISSUES. Para criação do modelo dimensional no banco de dados Postgre, exibido na figura 25, foram utilizados scripts SQL na opção de exportar para criação de script SQL, na ferramenta DB Designer, que com o modelo dimensional concluído realiza a criação do arquivo com os comandos na linguagem SQL, para ser executado no banco de dados Postgre. Após a criação do DW, o próximo passo é efetuar a transformação e a carga de dados. Com isso, a seguir, será apresentada a extração de dados realizada na ferramenta Pentaho Kettle. Na carga realizada, na tabela DI_CATEGORIA, foi necessário recuperar os dados da tabela ISSUE_CATEGORIES no campo name, ordenando, em ordem alfabética, os campos e gravando na tabela DI_CATEGORIA. A seguir, a figura ilustra a carga da tabela DI_CATEGORIA na ferramenta Pentaho Kettle.

69 69 Figura 27 - Carga de dados DI_CATEGORIA Fonte: O autor. A carga realizada, na tabela DI_PROJETO, foi com base na tabela PROJECTS, selecionado o campo name, ou seja, o nome do projeto e, após, ordenando em ordem alfabética. A seguir, é apresentada a figura sobre a carga da tabela DI_PROJETO.

70 70 Figura 28 - Carga de dados DI_PROJETO Fonte: O autor. Na carga realizada, na tabela DI_RESPONSAVEL_AREA, é utilizado a tabela USERS, obtendo os campos id e lastname, que tem o significado nome e área do usuário cadastrado no banco de dados. A seguir, é apresentada a figura sobre a carga de dados na tabela DI_RESPONSAVEL_AREA.

71 71 Figura 29 - Carga de dados DI_RESPONSAVEL_AREA Fonte: O autor. Na carga realizada, na tabela DI_STATUS, é utilizada a tabela ISSUE_STATUSES, obtendo o campo name, após, ordenando-a e inserindo na tabela DI_STATUS. A seguir, é apresentadaa figura sobre a carga de dados na tabela DI_STATUS.

72 72 Figura 30 - Carga de dados DI_STATUS Fonte: O autor. A carga, realizada na tabela DI_TEMPO, foi obtida a partir da tabela ISSUES com base no campo created_on, que representa a data de criação do tíquete. Para realizar a carga e separar nos campos dia,mês,ano e semana, foi necessário utilizar as funções do banco de dados MYSQL.Para extrair essas informações, foram utilizadas as funções year(), month(), week() e Day(), ao qual extraí o ano, mês, semana e dia. A seguir, é apresentada a figura sobre a carga de dados da tabela DI_TEMPO.

73 73 Figura 31 - Carga de dados DI_TEMPO Fonte: O autor. A carga de dados, da qual realizada na tabela DI_TICKET, foi obtida a partir da tabela ISSUES com o campo id, foi realizada a extração e ordenação numérica crescente, antes de carregar os dados na tabela DI_TICKET. A seguir, é apresentada a figura da carga de dados da tabela DI_TICKET.

74 74 Figura 32 - Carga de dados DI_TICKET Fonte: O autor. A carga, realizada na tabela fato FT_TICKETS, foi obtida a partir das tabelas DI_CATEGORIA, DI_PROJETO, DI_RESPONSAVEL_AREA, DI_STATUS, DI_TEMPO e DI_TICKET e, também, as tabelas para calcular os campos mencionados anteriormente. Após obter os campos das tabelas dimensão,são realizados agrupamentos dos dados com base nas técnicas de ETL mencionada no segundo capítulo e carregado os dados. A seguir, é apresentada a figura da carga de dados na tabela FT_TICKETS.

75 75 Figura 33 - Carga de dados FT_TICKETS Fonte: O autor. Após concluir a carga de dados no DW, foi realizada a montagem do cubo de dados, seguindo os conceitos apresentados no capítulo dois, sobre OLAP. O cubo de dados apresenta, a seguir, as dimensões de categoria, representado pela tabela DI_CATEGORIA no DW, a dimensão de projeto representado pela tabela DI_PROJETO no DW, a dimensão responsável área, representado pela tabela DI_RESPONSAVEL_AREA no DW, dimensão status, representado pela tabela DI_STATUS no DW, dimensão tempo, representado pela tabela DI_TEMPO no DW e dimensão ticket, representado por a tabela DI_TICKET no DW. Assim, com as dimensões definidas, a tabela fato FT_TICKET representa o assunto analisado. As medidas escolhidas, para analisar o assunto, são tempo total realizado, tempo total estimado, pertence a release e prioridade do tíquete. A seguir, é apresentado o cubo OLAP, assim, como assunto, dimensões e medidas analisadas.

76 76 Figura 34 - Cubo OLAP Fonte: O autor. Após realizada a apresentação da arquitetura de BI back-end, responsável por estruturar o BI internamente, ou seja, implementação a baixo nível da lógica de negócio por o ator administrador, conforme descrito no quarto capítulo, é iniciada a apresentação da arquitetura de BI fron-end, parte reservada para análise dos dados obtidos com a arquitetura de BI back-end. A segunda parte é referente às tarefas atribuídas ao analista de negócio, conforme apresentado no capítulo quarto Arquitetura de BI: front-end Após realizar a parte back-end da arquitetura de BI, é iniciada a próxima etapa de análise de dados, que consiste em verificar o resultado obtido através de relatórios da ferramenta Kettle Saiku. A quantidade de registros no banco de dados relacional encontrada foi de registros, ou seja, cada registro representa uma demanda aberta para resolução de alguma necessidade do cliente ou da empresa, que se denomina de tíquete.

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE Engenharia de Computação Professor: Rosalvo Ferreira de Oliveira Neto OLPT x OLAP Roteiro OLTP Datawarehouse OLAP Operações OLAP Exemplo com Mondrian e Jpivot

Leia mais

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4. SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.1 Armazenamento... 5 4.2 Modelagem... 6 4.3 Metadado... 6 4.4

Leia mais

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago DATA WAREHOUSE Rafael Ervin Hass Raphael Laércio Zago Roteiro Introdução Aplicações Arquitetura Características Desenvolvimento Estudo de Caso Conclusão Introdução O conceito de "data warehousing" data

Leia mais

Tópicos Avançados Business Intelligence. Banco de Dados Prof. Otacílio José Pereira. Unidade 10 Tópicos Avançados Business Inteligence.

Tópicos Avançados Business Intelligence. Banco de Dados Prof. Otacílio José Pereira. Unidade 10 Tópicos Avançados Business Inteligence. Tópicos Avançados Business Intelligence Banco de Dados Prof. Otacílio José Pereira Unidade 10 Tópicos Avançados Business Inteligence Roteiro Introdução Níveis organizacionais na empresa Visão Geral das

Leia mais

Sistemas de Apoio à Decisão (SAD) - Senado

Sistemas de Apoio à Decisão (SAD) - Senado Sistemas de Apoio à Decisão (SAD) - Senado DW OLAP BI Ilka Kawashita Material preparado :Prof. Marcio Vitorino Sumário OLAP Data Warehouse (DW/ETL) Modelagem Multidimensional Data Mining BI - Business

Leia mais

Módulo 2. Definindo Soluções OLAP

Módulo 2. Definindo Soluções OLAP Módulo 2. Definindo Soluções OLAP Objetivos Ao finalizar este módulo o participante: Recordará os conceitos básicos de um sistema OLTP com seus exemplos. Compreenderá as características de um Data Warehouse

Leia mais

Data Warehouse Processos e Arquitetura

Data Warehouse Processos e Arquitetura Data Warehouse - definições: Coleção de dados orientada a assunto, integrada, não volátil e variável em relação ao tempo, que tem por objetivo dar apoio aos processos de tomada de decisão (Inmon, 1997)

Leia mais

Data Warehouse. Debora Marrach Renata Miwa Tsuruda

Data Warehouse. Debora Marrach Renata Miwa Tsuruda Debora Marrach Renata Miwa Tsuruda Agenda Introdução Contexto corporativo Agenda Introdução Contexto corporativo Introdução O conceito de Data Warehouse surgiu da necessidade de integrar dados corporativos

Leia mais

Aplicação A. Aplicação B. Aplicação C. Aplicação D. Aplicação E. Aplicação F. Aplicação A REL 1 REL 2. Aplicação B REL 3.

Aplicação A. Aplicação B. Aplicação C. Aplicação D. Aplicação E. Aplicação F. Aplicação A REL 1 REL 2. Aplicação B REL 3. Sumário Data Warehouse Modelagem Multidimensional. Data Mining BI - Business Inteligence. 1 2 Introdução Aplicações do negócio: constituem as aplicações que dão suporte ao dia a dia do negócio da empresa,

Leia mais

Chapter 3. Análise de Negócios e Visualização de Dados

Chapter 3. Análise de Negócios e Visualização de Dados Chapter 3 Análise de Negócios e Visualização de Dados Objetivos de Aprendizado Descrever a análise de negócios (BA) e sua importância par as organizações Listar e descrever brevemente os principais métodos

Leia mais

5 Estudo de Caso. 5.1. Material selecionado para o estudo de caso

5 Estudo de Caso. 5.1. Material selecionado para o estudo de caso 5 Estudo de Caso De modo a ilustrar a estruturação e representação de conteúdos educacionais segundo a proposta apresentada nesta tese, neste capítulo apresentamos um estudo de caso que apresenta, para

Leia mais

Business Intelligence e ferramentas de suporte

Business Intelligence e ferramentas de suporte O modelo apresentado na figura procura enfatizar dois aspectos: o primeiro é sobre os aplicativos que cobrem os sistemas que são executados baseados no conhecimento do negócio; sendo assim, o SCM faz o

Leia mais

DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP.

DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP. DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP. Eduardo Cristovo de Freitas Aguiar (PIBIC/CNPq), André Luís Andrade

Leia mais

Data Warehouses Uma Introdução

Data Warehouses Uma Introdução Data Warehouses Uma Introdução Alex dos Santos Vieira, Renaldy Pereira Sousa, Ronaldo Ribeiro Goldschmidt 1. Motivação e Conceitos Básicos Com o advento da globalização, a competitividade entre as empresas

Leia mais

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br Data Warehousing Leonardo da Silva Leandro Agenda Conceito Elementos básicos de um DW Arquitetura do DW Top-Down Bottom-Up Distribuído Modelo de Dados Estrela Snowflake Aplicação Conceito Em português:

Leia mais

PLANO DE ENSINO PRÉ-REQUISITOS: ENS

PLANO DE ENSINO PRÉ-REQUISITOS: ENS UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI PLANO DE ENSINO DEPARTAMENTO: DSI Departamento de Sistema de Informação DISCIPLINA: Data Warehouse

Leia mais

Data Warehousing Visão Geral do Processo

Data Warehousing Visão Geral do Processo Data Warehousing Visão Geral do Processo Organizações continuamente coletam dados, informações e conhecimento em níveis cada vez maiores,, e os armazenam em sistemas informatizados O número de usuários

Leia mais

DATA WAREHOUSE. Introdução

DATA WAREHOUSE. Introdução DATA WAREHOUSE Introdução O grande crescimento do ambiente de negócios, médias e grandes empresas armazenam também um alto volume de informações, onde que juntamente com a tecnologia da informação, a correta

Leia mais

Arquitetura física de um Data Warehouse

Arquitetura física de um Data Warehouse É um modo de representar a macroestrutura de, comunicação, processamento e existentes para usuários finais dentro da empresa. Operacionais origem Data / Arquitetura física Serviços Armazenamento de Área

Leia mais

IMPLANTAÇÃO DO DW NA ANVISA

IMPLANTAÇÃO DO DW NA ANVISA IMPLANTAÇÃO DO DW NA ANVISA Bruno Nascimento de Ávila 1 Rodrigo Vitorino Moravia 2 Maria Renata Furtado 3 Viviane Rodrigues Silva 4 RESUMO A tecnologia de Business Intelligenge (BI) ou Inteligência de

Leia mais

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO @ribeirord FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO Rafael D. Ribeiro, M.Sc,PMP. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br Lembrando... Aula 4 1 Lembrando... Aula 4 Sistemas de apoio

Leia mais

Bloco Administrativo

Bloco Administrativo Bloco Administrativo BI Business Intelligence Objetivo O objetivo deste artigo é dar uma visão geral sobre o Módulo Business Intelligence, que se encontra no Bloco Administrativo. Todas informações aqui

Leia mais

Uma estrutura (framework) para o Business Intelligence (BI)

Uma estrutura (framework) para o Business Intelligence (BI) Uma estrutura conceitural para suporteà decisão que combina arquitetura, bancos de dados (ou data warehouse), ferramentas analíticas e aplicações Principais objetivos: Permitir o acesso interativo aos

Leia mais

CONSIDERAÇÕES SOBRE ATIVIDADES DE IDENTIFICAÇÃO, LOCALIZAÇÃO E TRATAMENTO DE DADOS NA CONSTRUÇÃO DE UM DATA WAREHOUSE

CONSIDERAÇÕES SOBRE ATIVIDADES DE IDENTIFICAÇÃO, LOCALIZAÇÃO E TRATAMENTO DE DADOS NA CONSTRUÇÃO DE UM DATA WAREHOUSE CONSIDERAÇÕES SOBRE ATIVIDADES DE IDENTIFICAÇÃO, LOCALIZAÇÃO E TRATAMENTO DE DADOS NA CONSTRUÇÃO DE UM DATA WAREHOUSE Fabio Favaretto Professor adjunto - Programa de Pós Graduação em Engenharia de Produção

Leia mais

Modelando um Data Warehouse GRIMALDO OLIVEIRA

Modelando um Data Warehouse GRIMALDO OLIVEIRA Modelando um Data Warehouse GRIMALDO OLIVEIRA Sobre Grimaldo Grimaldo Oliveira grimaldo_lopes@hotmail.com Formação Mestre em Tecnologias Aplicadas a Educação pela Universidade do Estado da Bahia. Especialização

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Data Warehouses. Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos

Data Warehouses. Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos Data Warehouses Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos Conceitos Básicos Data Warehouse(DW) Banco de Dados voltado para

Leia mais

Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence

Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence Juntamente com o desenvolvimento desses aplicativos surgiram os problemas: & Data Warehouse July Any Rizzo Oswaldo Filho Década de 70: alguns produtos de BI Intensa e exaustiva programação Informação em

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Integração Access-Excel para produzir um sistema de apoio a decisão que simula um Data Warehouse e OLAP

Integração Access-Excel para produzir um sistema de apoio a decisão que simula um Data Warehouse e OLAP Integração Access-Excel para produzir um sistema de apoio a decisão que simula um Data Warehouse e OLAP Wílson Luiz Vinci (Faculdades IPEP) wilson@cnptia.embrapa.br Marcelo Gonçalves Narciso (Embrapa Informática

Leia mais

Planejamento Estratégico de TI. Prof.: Fernando Ascani

Planejamento Estratégico de TI. Prof.: Fernando Ascani Planejamento Estratégico de TI Prof.: Fernando Ascani Data Warehouse - Conceitos Hoje em dia uma organização precisa utilizar toda informação disponível para criar e manter vantagem competitiva. Sai na

Leia mais

Business Intelligence Um enfoque gerencial para a Inteligência do Negócio.Efrain Turban e outros.tradução. Bookman, 2009.

Business Intelligence Um enfoque gerencial para a Inteligência do Negócio.Efrain Turban e outros.tradução. Bookman, 2009. REFERÊNCIAS o o Business Intelligence Um enfoque gerencial para a Inteligência do Negócio.Efrain Turban e outros.tradução. Bookman, 2009. Competição Analítica - Vencendo Através da Nova Ciência Davenport,

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com Sistemas de informação Disciplina: Introdução a SI Noções de sistemas de informação Turma: 01º semestre Prof. Esp. Marcos Morais

Leia mais

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5 Para entender bancos de dados, é útil ter em mente que os elementos de dados que os compõem são divididos em níveis hierárquicos. Esses elementos de dados lógicos constituem os conceitos de dados básicos

Leia mais

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence É um conjunto de conceitos e metodologias que, fazem uso de acontecimentos e sistemas e apoiam a tomada de decisões. Utilização de várias fontes de informação para se definir estratégias de competividade

Leia mais

Curso Data warehouse e Business Intelligence

Curso Data warehouse e Business Intelligence Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

Leia mais

Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS

Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS Sumário Conceitos/Autores chave... 3 1. Introdução... 5 2. OLAP... 6 3. Operações em OLAP... 8 4. Arquiteturas em OLAP...

Leia mais

BUSINESS INTELLIGENCE -Inteligência nos Negócios-

BUSINESS INTELLIGENCE -Inteligência nos Negócios- UNIVERSIDADE SÃO FRANCISCO CENTRO DE CIÊNCIAS JURÍDICAS, HUMANAS E SOCIAIS BUSINESS INTELLIGENCE -Inteligência nos Negócios- Curso: Administração Hab. Sistemas de Informações Disciplina: Gestão de Tecnologia

Leia mais

Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Exercícios OLAP - CESPE Material preparado: Prof. Marcio Vitorino OLAP Material preparado: Prof. Marcio Vitorino Soluções MOLAP promovem maior independência de fornecedores de SGBDs

Leia mais

MANUAL BI- Business Intelligence

MANUAL BI- Business Intelligence 1. VISÃO GERAL 1.1 SISTEMA BI Business Intelligence: Segundo Gartner Group, a maior ameaça das empresas da atualidade é o desconhecimento... O Business Intelligence se empenha em eliminar as dúvidas e

Leia mais

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

Leia mais

Capítulo 1 - A revolução dos dados, da informação e do conhecimento 1 B12 4

Capítulo 1 - A revolução dos dados, da informação e do conhecimento 1 B12 4 Sumário Capítulo 1 - A revolução dos dados, da informação e do conhecimento 1 B12 4 Capítulo 2 - Reputação corporativa e uma nova ordem empresarial 7 Inovação e virtualidade 9 Coopetição 10 Modelos plurais

Leia mais

Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse

Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse Prof. Dr. Oscar Dalfovo Universidade Regional de Blumenau - FURB, Blumenau, Brasil dalfovo@furb.br Prof. Dr. Juarez

Leia mais

BUSINESS INTELLIGENCE BI Aplicado à Gestão das Águas Subterrâneas. Frederico Cláudio Peixinho Flávio Luis de Mello 23 a 26 de Outubro de 2012

BUSINESS INTELLIGENCE BI Aplicado à Gestão das Águas Subterrâneas. Frederico Cláudio Peixinho Flávio Luis de Mello 23 a 26 de Outubro de 2012 XVII Congresso Brasileiro de Águas Subterrâneas Bonito - MT Serviço Geológico do Brasil CPRM BUSINESS INTELLIGENCE BI Aplicado à Gestão das Águas Subterrâneas Frederico Cláudio Peixinho Flávio Luis de

Leia mais

Adriano Maranhão BUSINESS INTELLIGENCE (BI),

Adriano Maranhão BUSINESS INTELLIGENCE (BI), Adriano Maranhão BUSINESS INTELLIGENCE (BI), BUSINESS INTELLIGENCE (BI) O termo Business Intelligence (BI), popularizado por Howard Dresner do Gartner Group, é utilizado para definir sistemas orientados

Leia mais

SAD orientado a DADOS

SAD orientado a DADOS Universidade do Contestado Campus Concórdia Curso de Sistemas de Informação Prof.: Maico Petry SAD orientado a DADOS DISCIPLINA: Sistemas de Apoio a Decisão SAD orientado a dados Utilizam grandes repositórios

Leia mais

Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse

Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse Definição escopo do projeto (departamental, empresarial) Grau de redundância dos dados(ods, data staging) Tipo de usuário alvo (executivos, unidades) Definição do ambiente (relatórios e consultas préestruturadas

Leia mais

MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML

MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML 1 MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML JOANA SCHEEREN Porto Alegre 2009 2 JOANA SCHEEREN MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML Trabalho de Conclusão de Curso

Leia mais

Identificar as mudanças que acontecem na forma e no uso de apoio à decisão em empreendimentos de e-business. Identificar o papel e alternativas de

Identificar as mudanças que acontecem na forma e no uso de apoio à decisão em empreendimentos de e-business. Identificar o papel e alternativas de 1 Identificar as mudanças que acontecem na forma e no uso de apoio à decisão em empreendimentos de e-business. Identificar o papel e alternativas de relatórios dos sistemas de informação gerencial. Descrever

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Introdução a Data Warehousing e OLAP Introdução a Data Warehouse e Modelagem Dimensional Visão

Leia mais

Uma análise multidimensional dos dados estratégicos da empresa usando o recurso OLAP do Microsoft Excel

Uma análise multidimensional dos dados estratégicos da empresa usando o recurso OLAP do Microsoft Excel Uma análise multidimensional dos dados estratégicos da empresa usando o recurso OLAP do Microsoft Excel Carlos Alberto Ferreira Bispo (AFA) cafbispo@siteplanet.com.br Daniela Gibertoni (FATECTQ) daniela@fatectq.com.br

Leia mais

Administração de Sistemas de Informação Gerenciais UNIDADE IV: Fundamentos da Inteligência de Negócios: Gestão da Informação e de Banco de Dados Um banco de dados é um conjunto de arquivos relacionados

Leia mais

Uma aplicação de Data Warehouse para apoiar negócios

Uma aplicação de Data Warehouse para apoiar negócios Uma aplicação de Data Warehouse para apoiar negócios André Vinicius Gouvêa Monteiro Marcos Paulo Oliveira Pinto Rosa Maria E. Moreira da Costa Universidade do Estado do Rio de Janeiro - UERJ IME - Dept

Leia mais

Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹

Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹ Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹ ¹Ciência da Computação Universidade Federal de Itajubá (UNIFEI) MG Brasil

Leia mais

Módulo 5. Implementando Cubos OLAP

Módulo 5. Implementando Cubos OLAP Módulo 5. Implementando Cubos OLAP Objetivos Compreender a importância da manipulação correta da segurança nos dados. Conhecer as operações que podem ser realizadas na consulta de um cubo. Entender o uso

Leia mais

PROPOSTA DE UMA ARQUITETURA PARA CONSTRUÇÃO DE UM DATA WAREHOUSE PARA GESTÃO DA SAÚDE PÚBLICA DE UM MUNICÍPIO DO VALE DO ITAJAÍ

PROPOSTA DE UMA ARQUITETURA PARA CONSTRUÇÃO DE UM DATA WAREHOUSE PARA GESTÃO DA SAÚDE PÚBLICA DE UM MUNICÍPIO DO VALE DO ITAJAÍ PROPOSTA DE UMA ARQUITETURA PARA CONSTRUÇÃO DE UM DATA WAREHOUSE PARA GESTÃO DA SAÚDE PÚBLICA DE UM MUNICÍPIO DO VALE DO ITAJAÍ Renan Felipe dos Santos Prof. Alexander Roberto Valdameri,Orientador ROTEIRO

Leia mais

Percio Alexandre de Oliveira Prof. Maurício Capobianco Lopes - Orientador

Percio Alexandre de Oliveira Prof. Maurício Capobianco Lopes - Orientador Percio Alexandre de Oliveira Prof. Maurício Capobianco Lopes - Orientador Índice Introdução Objetivos Data Warehouse Estrutura Interna Características Principais elementos: ETC, Metadados e Modelagem Dimensional

Leia mais

Interatividade aliada a Análise de Negócios

Interatividade aliada a Análise de Negócios Interatividade aliada a Análise de Negócios Na era digital, a quase totalidade das organizações necessita da análise de seus negócios de forma ágil e segura - relatórios interativos, análise de gráficos,

Leia mais

Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan

Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan Faculdade INED Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan 1 Unidade 4.3 2 1 BI BUSINESS INTELLIGENCE BI CARLOS BARBIERI

Leia mais

BUSINESS INTELLIGENCE Prof. Fabio Purcino

BUSINESS INTELLIGENCE Prof. Fabio Purcino Aula Teste BUSINESS INTELLIGENCE Prof. Fabio Purcino Faça o download desta aula Use um leitor de QR Code Definição Business Intelligence é um conjunto de conceitos e técnicas que buscam extrair conhecimento

Leia mais

Business Intelligence para Computação TítuloForense. Tiago Schettini Batista

Business Intelligence para Computação TítuloForense. Tiago Schettini Batista Business Intelligence para Computação TítuloForense Tiago Schettini Batista Agenda Empresa; Crescimento de Dados; Business Intelligence; Exemplos (CGU, B2T) A empresa Empresa fundada em 2003 especializada

Leia mais

DESMISTIFICANDO O CONCEITO DE ETL

DESMISTIFICANDO O CONCEITO DE ETL DESMISTIFICANDO O CONCEITO DE ETL Fábio Silva Gomes da Gama e Abreu- FSMA Resumo Este artigo aborda os conceitos de ETL (Extract, Transform and Load ou Extração, Transformação e Carga) com o objetivo de

Leia mais

ERP & BI ENTENTENDO A BUSCA CONSTANTE DAS EMPRESAS POR UM SISTEMA QUE FORNEÇA INFORMAÇÕES CONFIÁVEIS PARA TOMADA DE DECISÃO*

ERP & BI ENTENTENDO A BUSCA CONSTANTE DAS EMPRESAS POR UM SISTEMA QUE FORNEÇA INFORMAÇÕES CONFIÁVEIS PARA TOMADA DE DECISÃO* ERP & BI ENTENTENDO A BUSCA CONSTANTE DAS EMPRESAS POR UM SISTEMA QUE FORNEÇA INFORMAÇÕES CONFIÁVEIS PARA TOMADA DE DECISÃO* RESUMO Marilia Costa Machado - UEMG - Unidade Carangola Graciano Leal dos Santos

Leia mais

Conversão de Base de Dados Relacional para Dimensional para Business Intelligence Utilizando Banco de Dados Mysql

Conversão de Base de Dados Relacional para Dimensional para Business Intelligence Utilizando Banco de Dados Mysql Conversão de Base de Dados Relacional para Dimensional para Business Intelligence Utilizando Banco de Dados Mysql Carlos H. Cardoso 1, Roberto D Nebo 1, Luis A. da Silva 1 1 Curso de Tecnologia em Banco

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

TÉCNICAS DE INFORMÁTICA WILLIAN FERREIRA DOS SANTOS

TÉCNICAS DE INFORMÁTICA WILLIAN FERREIRA DOS SANTOS TÉCNICAS DE INFORMÁTICA WILLIAN FERREIRA DOS SANTOS Vimos em nossas aulas anteriores: COMPUTADOR Tipos de computadores Hardware Hardware Processadores (CPU) Memória e armazenamento Dispositivos de E/S

Leia mais

Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados

Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Disciplina: Ferramentaspara Tomadade Decisão Prof.: Fernando Hadad Zaidan Unidade 1.2 1 Conceitos Iniciais Tomada de Decisão, Modelagem

Leia mais

Kimball University: As 10 Regras Essenciais para a Modelagem de Dados Dimensional

Kimball University: As 10 Regras Essenciais para a Modelagem de Dados Dimensional Kimball University: As 10 Regras Essenciais para a Modelagem de Dados Dimensional Margy Ross Presidente Kimball Group Maio de 2009, Intelligent Enterprise.com Tradução livre para a língua portuguesa por

Leia mais

Data Warehouse Granularidade. rogerioaraujo.wordpress.com twitter: @rgildoaraujo - rgildoaraujo@gmail.com 1

Data Warehouse Granularidade. rogerioaraujo.wordpress.com twitter: @rgildoaraujo - rgildoaraujo@gmail.com 1 Data Warehouse Granularidade rogerioaraujo.wordpress.com twitter: @rgildoaraujo - rgildoaraujo@gmail.com 1 Granularidade A granularidade de dados refere-se ao nível de sumarização dos elementos e de detalhe

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Uma Ferramenta Web para BI focada no Gestor de Informação

Uma Ferramenta Web para BI focada no Gestor de Informação Uma Ferramenta Web para BI focada no Gestor de Informação Mikael de Souza Fernandes 1, Gustavo Zanini Kantorski 12 mikael@cpd.ufsm.br, gustavoz@cpd.ufsm.br 1 Curso de Sistemas de Informação, Universidade

Leia mais

Criação e uso da Inteligência e Governança do BI

Criação e uso da Inteligência e Governança do BI Criação e uso da Inteligência e Governança do BI Criação e uso da Inteligência e Governança do BI Governança do BI O processo geral de criação de inteligência começa pela identificação e priorização de

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Business Intelligence

Business Intelligence 1/ 24 Business Intelligence Felipe Ferreira 1 Nossa empresa Jornal O Globo Jornais Populares Parcerias Grupo Folha Grupo Estado 2 1 Fundada em 1925 3100 funcionários 2 Parques Gráficos e SP Globo: 220

Leia mais

UNIVERSIDADE DO SUL DE SANTA CATARINA ALAN JULIANO BARBOSA BUSINESS INTELLIGENCE APLICADO NA MEDICINA PREVENTIVA

UNIVERSIDADE DO SUL DE SANTA CATARINA ALAN JULIANO BARBOSA BUSINESS INTELLIGENCE APLICADO NA MEDICINA PREVENTIVA UNIVERSIDADE DO SUL DE SANTA CATARINA ALAN JULIANO BARBOSA BUSINESS INTELLIGENCE APLICADO NA MEDICINA PREVENTIVA Palhoça 2013 ALAN JULIANO BARBOSA BUSINESS INTELLIGENCE APLICADO NA MEDICINA PREVENTIVA

Leia mais

Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso

Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso Ana Magela Rodriguez Almeida 1, Sandro da Silva Camargo 1 1 Curso Engenharia de Computação Universidade

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Prof. Ronaldo R. Goldschmidt. ronaldo.rgold@gmail.com

Prof. Ronaldo R. Goldschmidt. ronaldo.rgold@gmail.com DATA WAREHOUSES UMA INTRODUÇÃO Prof. Ronaldo R. Goldschmidt ronaldo.rgold@gmail.com 1 DATA WAREHOUSES UMA INTRODUÇÃO Considerações Iniciais Conceitos Básicos Modelagem Multidimensional Projeto de Data

Leia mais

e-business A IBM definiu e-business como: GLOSSÁRIO

e-business A IBM definiu e-business como: GLOSSÁRIO Através do estudo dos sistemas do tipo ERP, foi possível verificar a natureza integradora, abrangente e operacional desta modalidade de sistema. Contudo, faz-se necessário compreender que estas soluções

Leia mais

Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan

Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan Faculdade INED Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan 1 Unidade 4.2 2 1 BI BUSINESS INTELLIGENCE BI CARLOS BARBIERI

Leia mais

Arquiteturas de DW e Abordagens de Implementação. Arquiteturas e Abordagens de Implementação

Arquiteturas de DW e Abordagens de Implementação. Arquiteturas e Abordagens de Implementação Curso de Dwing TecBD-DI PUC-Rio Prof. Rubens Melo Arquiteturas de DW e Abordagens de Implementação Arquiteturas e Abordagens de Implementação Arquitetura adequada é fundamental Infra-estrutura disponível

Leia mais

01/12/2009 BUSINESS INTELLIGENCE. Agenda. Conceito. Segurança da Informação. Histórico Conceito Diferencial Competitivo Investimento.

01/12/2009 BUSINESS INTELLIGENCE. Agenda. Conceito. Segurança da Informação. Histórico Conceito Diferencial Competitivo Investimento. BUSINESS INTELLIGENCE Agenda BI Histórico Conceito Diferencial Competitivo Investimento Segurança da Objetivo Áreas Conceito O conceito de Business Intelligencenão é recente: Fenícios, persas, egípcios

Leia mais

Prova INSS RJ - 2007 cargo: Fiscal de Rendas

Prova INSS RJ - 2007 cargo: Fiscal de Rendas Prova INSS RJ - 2007 cargo: Fiscal de Rendas Material de Apoio de Informática - Prof(a) Ana Lucia 53. Uma rede de microcomputadores acessa os recursos da Internet e utiliza o endereço IP 138.159.0.0/16,

Leia mais

Gerenciamento de Dados e Gestão do Conhecimento

Gerenciamento de Dados e Gestão do Conhecimento ELC1075 Introdução a Sistemas de Informação Gerenciamento de Dados e Gestão do Conhecimento Raul Ceretta Nunes CSI/UFSM Introdução Gerenciando dados A abordagem de banco de dados Sistemas de gerenciamento

Leia mais

OLAP: Características, Arquitetura e Ferramentas

OLAP: Características, Arquitetura e Ferramentas INSTITUTO VIANNA JÚNIOR FACULDADES INTEGRADAS VIANNA JÚNIOR OLAP: Características, Arquitetura e Ferramentas Erika Maria Teixeira Araújo 1 Mônica de Lourdes Souza Batista 2 Teresinha Moreira de Magalhães

Leia mais

PLANO DE ENSINO DO 2º SEMESTRE LETIVO DE 2012

PLANO DE ENSINO DO 2º SEMESTRE LETIVO DE 2012 PLANO DE ENSINO DO 2º SEMESTRE LETIVO DE 2012 Curso: TECNOLOGIA EM GESTÃO COMERCIAL Habilitação: TECNÓLOGO Disciplina: NEGÓCIOS INTELIGENTES (BUSINESS INTELLIGENCE) Período: M V N 4º semestre do Curso

Leia mais

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado)

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) SISTEMA INTERNO INTEGRADO PARA CONTROLE DE TAREFAS INTERNAS DE UMA EMPRESA DE DESENVOLVIMENTO

Leia mais

UNIVERSIDADE FEDERAL DE MINAS GERAIS BACHARELADO EM SISTEMAS DE INFORMAÇÃO

UNIVERSIDADE FEDERAL DE MINAS GERAIS BACHARELADO EM SISTEMAS DE INFORMAÇÃO UNIVERSIDADE FEDERAL DE MINAS GERAIS BACHARELADO EM SISTEMAS DE INFORMAÇÃO Proposta de Formação Complementar: BUSINESS INTELLIGENCE E SUA APLICAÇÃO À GESTÃO Aluno: Yussif Tadeu de Barcelos Solange Teixeira

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS Sumário 1. DIRETRIZES PARA O PROCESSO DE DESENVOLVIMENTO DE PROJETOS DE APLICATIVOS...172 1.1. INTRODUÇÃO...172

Leia mais

Módulo 4: Gerenciamento de Dados

Módulo 4: Gerenciamento de Dados Módulo 4: Gerenciamento de Dados 1 1. CONCEITOS Os dados são um recurso organizacional decisivo que precisa ser administrado como outros importantes ativos das empresas. A maioria das organizações não

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO IMPLEMENTAÇÃO DE UM DATA MART PARA ÁREA COMERCIAL DA HAVAN LOJAS DE DEPARTAMENTOS Área de

Leia mais

Sobre o que falaremos nesta aula?

Sobre o que falaremos nesta aula? Business Intelligence - BI Inteligência de Negócios Prof. Ricardo José Pfitscher Elaborado com base no material de: José Luiz Mendes Gerson Volney Lagmman Introdução Sobre o que falaremos nesta aula? Ferramentas

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

KDD E MINERAÇÃO DE DADOS:

KDD E MINERAÇÃO DE DADOS: KDD E MINERAÇÃO DE DADOS: Revisão em Data Warehouses Prof. Ronaldo R. Goldschmidt ronaldo@de9.ime.eb.br rribeiro@univercidade.br geocities.yahoo.com.br/ronaldo_goldschmidt 1 DATA WAREHOUSES UMA VISÃO GERAL

Leia mais

A importância da. nas Organizações de Saúde

A importância da. nas Organizações de Saúde A importância da Gestão por Informações nas Organizações de Saúde Jorge Antônio Pinheiro Machado Filho Consultor de Negócios www.bmpro.com.br jorge@bmpro.com.br 1. Situação nas Empresas 2. A Importância

Leia mais

Business Intelligence: Desafios e Melhores Práticas

Business Intelligence: Desafios e Melhores Práticas Sucesu RJ - IV Congresso de Inteligência Competitiva Business Intelligence: Desafios e Melhores Práticas Eugenio Pedrosa Petrobras Roteiro Arquitetura de BI Evolução da BI nas Empresas Corporate Performance

Leia mais