Material das videoaulas do módulo 1 - Bootcamp Desenvolvedor BI

Prévia do material em texto

Fundamentos em Inteligência de Negócio
Capítulo 1. Definição e fundamentos de BI
Prof. Daniel Capanema
Aula 1.1. Definição e fundamentos de BI
 Histórico.
 Definição.
 Arquitetura básica.
Nesta aula
 1865: O primeiro uso conhecido do termo “business intelligence”. Richard
Millar Devens descreveu o sucesso de um banqueiro em seu livro
“Cyclopaedia of Commercial and Business Anecdotes”.
 1958: IBM, Hans Peter Luhn: “A capacidade de apreender as inter-relações
dos fatos apresentados de maneira a orientar a ação para um objetivo
desejado”.
 Anos 70 e 80: Crescimento da popularidade dos sistemas de apoio à
decisão (DSS), infraestruturas informáticas que organizam e analisam
dados operacionais.
Histórico
 Década de 1990: Ferramentas de Business Intelligence. O termo e as técnicas se tornam
comercializáveis e atualizadas através do uso de relatórios de processamento em lote.
ERPs.
 2000: Análise preditiva. Aprendizado de máquinas para prever mudanças no futuro do
negócio. Tecnologias da nuvem, comércio eletrônico e as redes sociais introduzem novas
oportunidades para Business Intelligence.
 2010-hoje: Business Intelligence torna-se uma ferramenta padrão para todos, desde
gigantes até PMEs. As aplicações contemporâneas cruzam vários dispositivos e usam
análises visuais para aplicar raciocínio analítico aos dados através de interfaces visuais
interativas.
Histórico
Definição
O que é 
Inteligência 
de Negócios?
 BARBIERE: Business Intelligence representa a habilidade de se estruturar, acessar e
explorar informações, normalmente guardadas em Data Warehouses e Data Marts, com
o objetivo de desenvolver percepções, entendimentos e conhecimentos, os quais podem
produzir um melhor processo de tomada de decisão.
 KIMBALL e ROSS: Business Intelligence é um termo genérico para descrever o
levantamento de informações sobre os ativos internos e externos da organização para
tomar melhores decisões de negócios.
 MOSS e ATRE: O BI não é um produto, nem um sistema. É uma arquitetura e uma
coleção de aplicações e bancos de dados com acesso facilitado aos dados e que provê
suporte à tomada de decisão.
Definição
 Gartner Group: Business Intelligence é definido como a aplicação de
um conjunto de metodologias e tecnologias, como J2EE, DOTNET,
Serviços da Web, XML, Data Warehouse, OLAP, Data Mining,
tecnologias de representação, etc., para melhorar a eficácia das
operações da empresa e apoiar o gerenciamento/decisão para
alcançar vantagens competitivas.
Definição
 As aplicações de BI podem auxiliar em vários segmentos das
organizações, das quais podemos citar:
– Tendências de transformação do mercado;
– Alterações no comportamento de clientes e padrões de consumo;
– Preferências de clientes;
– Recursos das empresas;
– Condições de mercado.
Definição
 De maneira mais ampla, pode-se dividir a arquitetura de BI em três
principais componentes:
– ETL (Extraction, Transformation and Loading);
– Repositório de dados analíticos;
– Camada de apresentação.
Arquitetura básica
Arquitetura básica
 Histórico.
 O que é?
 Arquitetura resumida.
Conclusão
 Data Warehouse.
Próxima aula
Aula 1.2. Data Warehouse
 Características do Data Warehouse.
 Data Marts.
 Estrutura do Data Warehouse.
Nesta aula
 Um Data Warehouse (DW, DWH ou armazém de dados) é um conjunto
de dados produzido para oferecer suporte à tomada de decisões; é
também um repositório de dados atuais e históricos, disponível para
os responsáveis pelas empresas ou instituições.
Introdução
 Orientado por assunto. Os dados são organizados por assunto, como vendas, produtos
ou clientes, e contêm apenas as informações relevantes de suporte à decisão.
 Integrado. A integração está bastante ligada à orientação por assunto. Os Data
Warehouses devem colocar os dados de diferentes fontes em um formato consistente.
 Variável no tempo (serie temporal). Um Data Warehouse mantém dados históricos. Eles
detectam tendências, variações, relações de longo prazo para previsão e comparações, o
que leva à tomada de decisões.
 Não volátil. Após os dados serem inseridos em um Data Warehouse, os usuários não
podem alterar ou atualizá-los.
Características do Data Warehouse
 Um Data Warehouse une bancos de dados de toda uma empresa; já um Data
Mart normalmente é menor e se concentra em um assunto ou departamento
especifico. Um Data Mart é um subconjunto de um Data Warehouse, que
normalmente consiste em uma única área temática (p. ex., marketing,
operações).
Data Marts
Estrutura de um Data Warehouse
 Data Sources: É de onde estaremos buscando, extraindo os dados que serão
utilizados para análise dentro do sistema de BI.
 Data Staging Area: Parte do Data Warehouse responsável pelo
armazenamento e a execução de um conjunto de processos normalmente
denominado como extração, transformação e carga (ETL – extract,
transformation, load) dos dados.
 Data Presentation Area: É onde os dados estão organizados, armazenados e
disponíveis para responder às consultas dos usuários em um formato
dimensional.
Estrutura de um Data Warehouse
 Data Warehouse.
 Data Marts.
 Estrutura resumida.
Conclusão
 Maturidade para BI.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 2. Maturidade para BI
Prof. Daniel Capanema
Aula 2.1. Maturidade para BI
 Maturidade para BI.
 Estágios de maturidade.
Nesta aula
 Métodos de gestão e visão voltados para o passado podem acarretar o
fracasso de um projeto de BI.
 As ferramentas são apenas uma parte do processo, e é preciso o
correto foco na ferramenta e uma cultura voltada para a decisão com
base nas informações e utilização dos recursos disponíveis.
 A maioria dos projetos de BI não obtém sucesso por não ter a
maturidade necessária, muitas vezes resumindo o processo como uma
geração de relatórios.
Introdução
 Moore (2003) define modelo de maturidade como sendo uma
estrutura para caracterizar a evolução de um sistema, de um estado
menos ordenado e menos efetivo, para um estado mais ordenado e
altamente eficaz, o que evidencia que temos graus evolutivos no
processo.
Introdução
 As empresas necessitam, portanto, medir qual seu nível de maturidade
em diversos processos de trabalho para poderem, assim, planejar suas
ações e obter sucesso nos processos de inovação.
 Existem vários modelos para analisar o nível de maturidade de uma
empresa. Nesta disciplina vamos abordar o modelo TDWI, que já é
consolidado e largamente utilizado.
Introdução
Modelo TDWI
 Este estágio é formado por duas fases que estão interligadas:
– Relatórios operacionais: é caracterizada por relatórios obtidos em
sistemas operacionais;
– Spreadmarts: Os próprios usuários usam aplicativos, geralmente planilhas
do Excel, para coletar, tratar, transformar e exibir os dados, ou seja,
realizam a função de um Data Mart ou Data Warehouse.
Estágio 1 – Inexistente
 O golfo é o primeiro obstáculo enfrentado. Desafios:
– Percepções executivas: Não querem gastar. BI = Relatório.
– Financiamento adequado: Financiamento vulnerável.
– Má qualidade dos dados: Superestimar dados de origem.
– Aumento do escopo: Correm atrás do cronograma e acima do orçamento.
– A proliferação de spreadmarts: O maior desafio no golfo são as pessoas.
O Golfo
 Inserção em um ambiente de BI e DW.
 Primeiras ferramentas de BI, principalmente de consultas, relatórios e
ferramentas de processamento analítico (OLAP).
 Alguns usuários começam a usar as ferramentas para analisar
tendências e dados históricos para ajudar a empresa a melhorar os
planos e operações.
 Busca de insights. Como o negócio foi executado no passado?
 Iniciativa de âmbito departamental.
Estágio 2 – Preliminar 
 Trabalho passa a ser mais amplo, saindo de Data Marts não integrados para um
modelo mais consolidado em um único DW, o que gera economia, maior
consistência nas informações utilizadas, maior compreensãoe analise do negócio.
 Utilização de modelo padrão de projeto e desenvolvimento de metodologias que
incorporam as melhores práticas adquiridas com iniciativas anteriores e consultores
externos.
 Cresce o uso do BI entre usuários casuais, que utilizam informações em conjuntos
padrões de relatórios parametrizados ou dashboards criados pelos usuários mais
capacitados.
Estágio 3 – Repetido
 Obstáculo mais amplo e mais profundo do que o golfo. Desafios:
– Volatilidade do negócio: Mudanças estratégicas podem comprometer.
– Padronização: Conciliar termos, definições e regras em diversos Data Marts e DW é
uma dificuldade política.
– Transição para TI corporativa: Dificuldade dos departamentos entregarem suas
soluções estimadas para uma área de TI corporativa.
– Caos de relatórios: Muitos relatórios. Repetidos e desencontrados.
– Evitar inflexibilidade de arquitetura: as soluções de BI têm de se adaptar
continuamente para mudanças.
O Abismo
 Arquitetura unificada: Arquitetura de DW que define o conjunto comum de regras, termos e
métricas compartilhadas entre unidades.
 Totalmente carregado: DW totalmente carregado com todos dados necessários para os
trabalhos.
 Flexível: Os desenvolvedores isolam a arquitetura permitindo fazer mudanças em um
componente sem ter que reescrever outras partes.
 Entrega just-in-time: O DW integra-se com dados em tempo real.
 Gerenciamento de desempenho: scorecards em cascata.
 Análise preditiva: Previsões mais sofisticadas.
 Gestão centralizada: Grupo de gestão da informação que consolida toda a central de
informações das áreas.
Estágio 4 – Gerenciado
 Retorno para as unidades de negócio através de centros de excelência.
– Desenvolvimento federado: Redistribuição de tarefas de desenvolvimento
para as unidades de negócio e departamentos.
– Empresa ampliada: Organizações utilizam BI e DW para oferecer aos
clientes e fornecedores personalização, relatórios interativos, dashboards
e outros serviços de informação. Geração de receitas e vantagens
competitivas com o BI.
Estágio 5 – Otimizado
 Empresas encontram-se em estágios específicos dependendo de sua
maturidade.
 Obstáculos a serem enfrentados para avançar estágios.
Conclusão
 Dimensões do modelo de maturidade.
Próxima aula
Aula 2.2. Dimensões do modelo de maturidade
 As dimensões do modelo de maturidade.
 Forma de avaliação da maturidade.
Nesta aula
 Além dos cinco estágios evolutivos, o modelo TDWI de maturidade
em BI compreende oito dimensões que estão inseridas em cada um
dos cinco estágios. A seguir uma breve abordagem de cada uma das
dimensões.
Introdução
 Refere à amplitude com que a equipe de BI da empresa atua e são
implantados os projetos. Classificações:
– Aplicações pessoais: desenvolvimento para a própria área;
– Departamental local: desenvolvimento para um departamento;
– Departamental empresa: departamento que atende várias unidades;
– Unidade de negócio: todos departamentos de uma unidade;
– Corporativo: para todas ou várias unidades de negócios;
– Intercorporativo: todas as unidades de negócios e mais clientes e fornecedores,
ou seja, ultrapassando os limites da empresa e alcançando uma espécie de BI
colaborativo.
Escopo
 Comprometimento das áreas e dos executivos com o projeto.
– Pode ser o CIO ou um diretor de TI, ou um patrocinador de uma unidade
de negócio/departamento, ou múltiplos patrocinadores oriundos de várias
unidades de negócios.
– Um dos fatores mais importantes na consolidação de uma área de BI.
– É a pessoa que demonstra o grau de comprometimento da empresa com
relação aos resultados obtidos.
Patrocinador
 Qual é a disponibilidade de recursos que a empresa dispõe para um
projeto de BI.
– Com entusiasmo inicial e bom patrocinador, os recursos são mais fáceis no
início, mas tendem a ficar mais difíceis.
– A empresa é avaliada na sua maturidade, através do tipo de orçamento
que dispõe, como orçamento departamental ou de unidade de negócios,
ou orçamento corporativo ou recursos próprios.
Apoio financeiro
 Resultados que um programa de BI proporciona para a empresa através
de valores quantificáveis ou retornos intangíveis, através da visão dos
usuários.
– Irrelevante para as suas funções, com valor relativamente marginal, pois o BI
tangencia suas funções;
– Relevante, pois são impactados pelas ações do BICC (BI Competency Center);
– Crítico ou considerado fator-chave de sucesso, quando dependente em alto
e muito alto grau, respectivamente.
Retorno
 Representa a forma mais usual como as soluções de BI são
implantadas.
– Spreadmarts;
– Data Marts não integrados;
– DW não integrado;
– DW integrado;
– Serviço de BI.
Arquitetura
 Disponibilidade e confiabilidade nos dados como também a facilidade para
acessá-los.
– A acessibilidade dos dados pode ir de alta dificuldade até um nível de alta
acessibilidade;
– A confiabilidade dos dados carregados é também fator importante;
– A qualidade dos dados deverá, cada vez mais, ser considerada como elemento
chave;
– Frequência de atualização das informações e com quais fontes de informações o BI
está sincronizando.
– Avaliação do ETL.
Dados
 Forma como a empresa realiza o desenvolvimento das aplicações de BI. Passa
pelas seguintes graduações:
– Isolado, aplicações ad hoc, sem padrões definidos;
– Aplicações isoladas, porém alinhadas com as definições do BICC;
– Aplicações integradas, usando os processos e as ferramentas padrão;
– Federada, unidades de negócios desenvolvam suas aplicações;
– Nesta dimensão é avaliado o nível de acompanhamento e gerenciamento de
projetos da equipe de desenvolvimento do BI, levando em conta o tempo de
implantação, o número de projetos executados e o grau de padrões de
desenvolvimento e documentação.
Desenvolvimento
 Avalia o produto do programa de BI. Onde os usuários e a empresa
utilizam os dados e informações consumindo o conteúdo, dando a
ideia do grau de intensidade em que é aplicado o BI.
– Pode variar entre a produção de relatórios para consumo organizacional
ou a possibilidade de análise de tendências, ou a monitoração de eventos
de negócios para possibilitar ações proativas, ou fazer previsão de
resultados e modelar planos, e, finalmente, automatizar processos,
incluindo interações com clientes.
– Número de usuários utilizando o sistema.
Entrega
Instruções de valor para cada dimensão
 Dimensões analisadas para definir a maturidade.
Conclusão
 Etapas de um projeto de BI.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 3. Etapas de um projeto de BI
Prof. Daniel Capanema
Aula 3.1.1. Etapas de um projeto de BI (Parte 1)
 Etapas de um projeto de BI.
Nesta aula
Introdução
 Nesta fase são avaliadas as necessidades de negócios que dão origem
ao novo projeto.
 O problema de negócio ou oportunidade de negócio é definido, e uma
solução de BI é proposta. Cada versão do aplicativo de BI deve ser
justificada por custos e deve definir claramente os benefícios de
resolver um problema de negócios ou tirar proveito de uma
oportunidade de negócio.
Justificativa
 Justificativas amplas e genéricas:
– Sistemas de gestão e geração de relatórios são complexos e de difícil manejo,
necessitando de semanas para a entrega de relatórios.
– Os atuais sistemas de consultas contam com o levantamento de dados de forma
manual, devido aos diversos sistemas operacionais.
– Os relatórios não são centralizados e nem todos os colaboradores conseguem
encontrar as informações que necessitam de forma fácil e ágil.
– Os principais indicadores de status do negócio não estão visíveis de forma clara a
auxiliar em uma tomada de decisão estratégica da empresa.
Justificativa
 Retorno financeiro e benefícios de uma solução de BI:
– Aumento da receita de novas vendas a partir da análise de perfis de
clientes.
– Melhor controle das ações de marketing.
– Aumento das vendas para clientes em carteira.
– Melhor controle doscustos.
– Eliminação de produtos com baixa margem.
Justificativa
 Retorno financeiro e benefícios de uma solução de BI:
– Eliminação/Redução do legado dos relatórios.
– Diminuição do tempo para coletar dados e produzir análises.
– Apoio nas ações de marketing e vendas.
– Aumento na venda dos produtos de maior rentabilidade.
– Cruzamento de dados de diversas áreas apresentando-os de forma gráfica
e dinâmica.
Justificativa
 Justifique um projeto de BI identificando os principais benefícios e procure
levantar questões como:
– Por que...?
– E se…?
– Quanto…?
– O que significaria para o negócio se você tivesse…?
– Quanto é… em valores?
 Levante questões e pesquise por número de componentes que podem ser
convertidos em benefícios de negócio.
Justificativa
 São desenvolvidos planos estratégicos e táticos.
 Mudanças no escopo, equipe, orçamento, tecnologia, representantes empresariais e
patrocinadores podem afetar severamente o sucesso de um projeto.
 Planejamento da infraestrutura:
– Infraestrutura técnica, que inclui hardware, software, middleware, sistemas de gerenciamento
de banco de dados, sistemas operacionais, componentes de rede, repositórios de metadados,
utilitários, e assim por diante.
– A infraestrutura não técnica, que inclui padrões de metadados, metodologias, diretrizes,
procedimentos de teste, processos de controle de mudanças, procedimentos para
gerenciamento de problemas, e assim por diante.
Planejamento
 Análises detalhadas do problema de negócio ou da oportunidade de negócio.
 Definir o escopo (tarefa difícil). O desejo de ter tudo instantaneamente precisa
ser restringido. Com o desenvolvimento do projeto os requisitos mudam.
 Qualidade dos dados. Maus hábitos e visão para uma única linha de negócio.
 Prototipagem.
 Mapeamento de metadados.
Análise
 Como justificar um projeto de BI.
 Necessidade de um planejamento.
 Análise em um projeto de BI.
Conclusão
 Continuação: etapas de um projeto de BI.
Próxima aula
Aula 3.1.2. Etapas de um projeto de BI (Parte 2)
 Etapas de um projeto de BI.
Nesta aula
Introdução
 Nesta fase é concebido um produto que resolva o problema do negócio ou permita a
oportunidade de negócio.
 Um ou mais bancos de dados de destino BI armazenará os dados comerciais de forma
detalhada ou agregada, dependendo dos requisitos de relatórios da comunidade
empresarial.
 O processo ETL é o processo mais complicado de todo o projeto de suporte à decisão de
BI. Planejar uma janela de tempo suficiente, pois os dados muitas vezes são de má
qualidade.
 Um repositório de metadados deverá ser concebido, e o design deve atender aos
requisitos do metamodelo lógico.
Design
 Nesta fase é criado o produto, que deve fornecer um retorno sobre o
investimento dentro de um período de tempo predefinido.
– Utilização de ferramentas ETL? Depende do que foi analisado na fase
anterior.
– Desenvolvimento dos aplicativos do protótipo. Pode ser complexo ou nem
tanto.
– Mineração de dados para descobrir informações novas.
– Desenvolvimento do repositório de metadados.
Construção
 Nesta fase é implementado ou vendido o produto finalizado e
verificado se a solução atende.
– Teste e liberação de bancos e aplicativos.
– Treinamentos para aplicativos e metadados.
– Atividades de suporte, manutenção, agendamento e execução de ETL,
monitoramento e outros.
Implantação
 Aprender com projetos anteriores:
– Quaisquer prazos perdidos, excessos de custos, disputas e resoluções de disputa
devem ser examinados, e os ajustes do processo devem ser feitos antes da próxima
versão começar.
– Todas as ferramentas, técnicas, diretrizes e processos que não foram úteis devem
ser reavaliados e ajustados, ou até descartados.
– As etapas do desenvolvimento de um projeto de BI são específicas em cada projeto,
e algumas podem ser realizadas em paralelos ou obterem maior ou menor atenção,
o que é definido pela equipe ou pelo responsável.
Etapas
 Etapas do projeto de BI.
 O fim de uma etapa é o início de outra.
 Aprender com projetos anteriores.
Conclusão
 Equipe de um projeto de BI.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 4. Equipe de um projeto de BI
Prof. Daniel Capanema
Aula 4.1. Equipe de um projeto de BI
 Equipe de um projeto de BI.
 Equipe principal e estendida.
Nesta aula
 Toda equipe de projeto de BI deve ter um conjunto de habilidades
complementares para realizar as atividades. Um projeto de BI possui
dois tipos de equipes, a equipe principal e a equipe estendida.
Introdução
 Time bem organizado e engajado.
 Tomar decisões e liderar.
 100% do tempo dedicado.
 Equipe pequena, quatro ou cinco integrantes:
– Gerente de projeto;
– Representante do lado dos negócios;
– Analista de negócios do departamento de TI (um administrador de dados ou uma pessoa
ligada aos negócios);
– Pessoa técnica do departamento de TI (um analista sênior ou um programador sênior).
Equipe principal
 Administrador de banco de dados: Projetando, carregando, monitorando e
ajustando os bancos de dados de destino do BI.
 Administrador de dados: Realizando análise de dados interorganizacionais, criando
modelos de dados lógicos específicos do projeto e mesclando os modelos de dados
lógicos em um modelo de dados lógicos corporativos.
 Administrador de metadados: Construção ou licenciamento (compra),
aprimoramento, carregamento e manutenção do repositório de metadados.
 Analista de qualidade de dados: Avaliando a qualidade dos dados-fonte e
preparando especificações de limpeza de dados para o processo ETL.
Outros membros da equipe principal
 Arquiteto de infraestrutura: Estabelecer e manter a infraestrutura técnica de BI.
 Desenvolvedor líder de aplicativos: Projetando e supervisionando o
desenvolvimento do aplicativo de acesso e análise (por exemplo, relatórios,
consultas).
 Desenvolvedor líder ETL: Projetando e supervisionando o processo ETL.
 Especialista em assuntos: Fornecer conhecimentos comerciais sobre dados,
processos e requisitos.
 Especialista em mineração de dados: Escolhendo e executando a ferramenta de
mineração de dados.
Outros membros da equipe principal
 Gerente de projeto: Definição, planejamento, coordenação, controle e revisão
de todas as atividades do projeto; rastreamento e relatórios de progresso;
resolução de questões técnicas e comerciais; orientação do time; negociação
com fornecedores, representante de negócios e patrocinador comercial; tem
responsabilidade geral pelo projeto.
 Representante comercial: Participar em sessões de modelagem, fornecer
definições de dados, escrever casos de teste, tomar decisões empresariais,
resolver disputas entre unidades de negócios e melhorar a qualidade de
dados.
Outros membros da equipe principal
 Desenvolvedor de aplicativos: Codificando os programas de relatório, escrevendo
scripts de consulta e desenvolvendo os aplicativos de acesso e análise.
 Suporte de BI (helpdesk): Mentoria e formação da equipe de negócios.
 Patrocinador de negócios: Promovendo a iniciativa de BI e removendo bloqueios
relacionados à equipe de projetos de BI.
 Desenvolvedor ETL: Codificando os programas ETL e preparando as instruções para
a ferramenta ETL.
 Auditor de TI: Determinando os riscos e as exposições do projeto de BI por falta
interna de controles ou forças externas.
Equipe estendida
 Desenvolvedor do repositório de metadados: Codificando os programas de
migração do repositório de metadados para carregar o banco de dados do
repositório de metadados e fornecendo relatórios de metadados.
 Equipe de serviços de rede: Manutenção do ambiente de rede.
 Equipe de operações: Executar os processos para os ciclos ETL, o aplicativo de
acesso e análise e o repositório de metadados.
 Oficial de segurança: Garantir que os requisitos de segurança são definidos e
que os recursos de segurança são testados em todas as ferramentas e bancos
de dados.Equipe estendida
 Stakeholders (outros representantes do negócio ou gerentes de TI): Manipulando
responsabilidades limitadas no projeto de BI, como revisar e ratificar os padrões
interorganizacionais e as regras de negócios que a equipe do projeto de BI usa ou
desenvolve.
 Arquiteto estratégico: Gerenciando a infraestrutura técnica geral para a organização,
incluindo a infraestrutura técnica de BI.
 Equipe de serviços técnicos: Manutenção da infraestrutura de hardware e dos sistemas
operacionais.
 Testadores: Testando os códigos de programação criados pelos desenvolvedores para o
ETL, aplicativos e repositório de metadados.
Equipe estendida
 Administradores de ferramentas: Instalando e mantendo as
ferramentas de desenvolvimento e análise.
 Desenvolvedor Web: Projetando o site e criando as páginas da Web
para exibir relatórios e consultas.
 Webmaster: Configuração do servidor Web e da segurança na Web.
Equipe estendida
 Equipe do projeto.
 Equipe engajada.
Conclusão
 Planejamento de um projeto de BI.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 5. Planejamento de um projeto de BI
Prof. Daniel Capanema
Aula 5.1. Planejamento de um projeto de BI
 Planejamento de um projeto de BI.
Nesta aula
 Os projetos de BI não são como outros projetos, com um conjunto
finito e estático de requisitos de uma pessoa de negócios ou um
departamento.
Introdução
 Temos um bom patrocinador? Temos um patrocinador de negócios de
backup?
 Temos partes interessadas com quem precisamos nos comunicar
regularmente?
 Quanto tempo o representante da empresa compromete com este
projeto? Está atribuído a este projeto em tempo integral, ou estará
disponível somente mediante solicitação?
Envolvimento do negócio
 Recebemos um pedido formal para um projeto de BI?
 Quão detalhados são os requisitos?
 O que foi solicitado para ser entregue?
 Podemos implementar o escopo solicitado, considerando o
cronograma e os recursos disponíveis?
Escopo do projeto
 Já realizamos uma análise custo-benefício?
 Qual é o retorno esperado sobre o investimento (ROI)?
 Em que momento esperamos que o ROI se materialize?
Análise de custo-benefício
 Revisamos nossos componentes de infraestrutura técnica e não
técnica?
 Nossa infraestrutura possui problemas?
 Quais componentes de infraestrutura devemos trabalhar e entregar
como parte do projeto de BI?
– Quais componentes de infraestrutura técnica?
– Quais componentes de infraestrutura não técnica?
A infraestrutura
 Já identificamos os membros da equipe?
 Todos os membros da equipe têm as habilidades necessárias para
desempenhar as responsabilidades de suas funções atribuídas?
 Devemos agendar qualquer treinamento antes do lançamento do
projeto?
 O gerente de projeto é atribuído a este projeto em tempo integral? Ou
tem outras responsabilidades administrativas?
Pessoal e habilidades
 Aspectos a serem analisados para planejar um projeto de BI.
Conclusão
 Gerenciamento do projeto.
 Definição do projeto.
Próxima aula
Aula 5.2. Gerenciamento e definição de um projeto de BI
 Gerenciamento de um projeto de BI.
 Definição de um projeto de BI.
Nesta aula
 Muitas empresas encaram o gerenciamento do projeto como um
relatório administrativo.
 Não fazem planejamento detalhado e acompanhamento diário.
 Querem os aplicativos funcionando rapidamente.
Introdução
 Um bom planejamento leva a testes e ciclos mais curtos.
 Dificilmente um projeto de BI é realizado sem algumas adaptações, os
atrasos são comuns. Pode faltar algum produto, podem haver trocas
de pessoal, podem ter problemas com fornecedores, dentre outros.
 Planejar problemas e atrasos ajuda o gerenciamento.
Introdução
 Descrevendo atividades de gerenciamento de projetos em termos mais
simplistas, o objetivo é responder a quatro questões básicas:
– O que será entregue?
– Quando isso será feito?
– Quanto vai custar?
– Quem vai fazer isso?
Gerenciamento de projetos
 Essas perguntas traduzem, respectivamente, as quatro principais
restrições do projeto de escopo, esforço (tempo), orçamento e
recursos.
Gerenciamento de projetos
 O planejamento de projetos inclui a criação de uma carta de projeto,
que define o projeto em termos de: metas e objetivos, escopo, riscos,
restrições, premissas, procedimentos de controle de mudanças e
procedimentos de gerenciamento de questões.
Definição do Projeto de BI
 Qual o motivo da construção deste aplicativo de BI? Quanta dor (financeira)
esse problema de negócios causa? Quais são os objetivos comerciais
estratégicos? Os objetivos do projeto de BI se enquadram nos objetivos de
negócios estratégicos, ou o projeto é um desejo pessoal de alguém?
 Os objetivos devem ser mensuráveis e relacionar com o ROI esperado.
 O representante de negócios terá que medir a eficácia do aplicativo de BI
entregue e informar ao patrocinador da empresa se o projeto foi bem-
sucedido ou não.
Metas e objetivos
 Nos projetos de BI, o escopo deve ser medido pelo número de
elementos de dados que devem ser extraídos dos sistemas de origem,
transformados, limpos e carregados nos bancos de dados de destino
do BI.
 Concentrar nos dados. Analisar e preparar dados de origem leva muito
mais tempo do que fornecer acesso a dados e permitir a análise de
dados através de relatórios e consultas. Regra 80/20
(dados/funcionalidade).
Escopo do projeto
 Todo projeto está sujeito a alguns riscos, e os riscos são inevitáveis.
 Podem afetar cronograma e resultado do projeto.
 A avaliação de risco deve ser revisada e expandida, se necessário.
 Para cada risco deve-se criar os três planos abaixo:
– Disparadores: são situações que sinalizam um potencial, talvez uma materialização
iminente de um risco.
– Plano de mitigação: especifica quais ações a equipe do projeto pode tomar para
evitar que o risco se materialize.
– Plano de contingência: especifica alternativas caso o risco se materialize.
Riscos de projeto
 Alguns riscos de projetos comuns incluem o seguinte: falta de
compromisso de gestão, perda do patrocinador, cronograma
impensado e irreal, escopo irreal para o cronograma, expectativas
irrealistas, orçamento irreal, equipe não treinada ou indisponível,
mudanças constantes de negócios, gerenciamento de projeto ineficaz,
escalabilidade limitada.
Riscos de projeto
 Todos os projetos estão sujeitos às restrições de projeto mencionadas
anteriormente: escopo, esforço (tempo), orçamento e recursos
(pessoas capazes e disponíveis). Na realidade, existe uma quinta
restrição: a qualidade.
 Problema: qualidade requer esforço (tempo) e nem sempre é dado.
Restrições
Restrições
 Sequência não desejada, mas frequentemente é adotada.
Restrições
 Sequência desejada e que felizmente várias empresas adotam.
 Premissas são hipóteses, condições que assumimos como verdade para
alcançar um objetivo exclusivo. Para os processos de planejamento,
sempre consideramos as premissas como certas, reais e seguras. As
mesmas devem ser precisas e especificas. Todas as premissas geram riscos
ao projeto.
 Premissas importantes devem ter riscos de contrapartida, caso alguma
situação não saia como pensado. Para cada risco de contrapartida,
identifique triggers, um plano de mitigação e um plano de contingência.
Premissas
 Modelo tradicionalista: “A mudança é ruim – os empresários devem
ser responsabilizados por suas decisões”.
 Novo modelo: “Mudança é boa – as pessoas de negócios devem refinar
e melhorar suas decisões”.
 Não basta apenas registrá-las, é preciso gerenciá-las.
 As mudanças afetam as restrições citadas anteriormente, e essas
precisam ser negociadas.
Procedimentos de controle de mudança
 Decisões a serem tomadas quando alguma restrição é afetada:
– Reduzir o escopo atual eliminando alguns dos dados e funcionalidades
originalmente solicitados.
– Estender o prazo.
– Declarar a mudança solicitada inviávelno momento e adiá-la.
– Incorporar a alteração solicitada na próxima versão.
– Eliminar transformações complicadas, verificações e testes, o que afetará
a qualidade do produto.
Procedimentos de controle de mudança
 Aspectos a serem analisados para planejar um projeto de BI.
 Gerenciar riscos.
 Tomar decisões que menos afetarão o projeto.
Conclusão
 Planejamento do projeto de BI.
Próxima aula
Aula 5.3. Dependências e tarefas do projeto de BI
 Tarefas e atividades a serem desenvolvidas.
 Dependências entre tarefas.
 Estimativas.
Nesta aula
 O planejamento não é um processo estático – como são as estimativas
–, e os processos podem e devem mudar com o tempo. Se o processo
não muda, é sinal que não está sendo devidamente gerenciado.
Introdução
 Breve sequência de atividades para um bom planejamento:
– Crie uma estrutura de repartição do trabalho listando atividades, tarefas e
subtarefas.
– Estime as horas de esforço para essas atividades, tarefas e subtarefas.
– Atribua recursos às atividades, tarefas e subtarefas.
– Determine as dependências da tarefa.
– Determine as dependências de recursos.
– Determine o caminho crítico com base nas dependências.
– Crie o plano detalhado do projeto.
Introdução
 Todo projeto é composto por atividades, cada uma com várias tarefas.
 Listar tarefas, principalmente as mais necessárias.
 É impossível lembrar de tudo e também executar tudo: o projeto é
dinâmico.
 O importante é um documento que aceite essas alterações.
 Um bom caminho é dividir o projeto em subprojetos, e em cada
iteração são incluídas novas funcionalidades.
Atividades e tarefas
 Tempo de execução de cada tarefa:
– Histórico: com base em padrões aprendido em outros trabalhos.
– Intuitivo: baseado na intuição e na experiência.
– Fórmula: com base na média de possibilidades, que é calculada da
seguinte forma: [ Melhor_Estimativa + Pior_Estimativa +
(Estimativa_Média * 4)] / 6.
Técnicas de estimativa
 As estimativas de esforço não podem ser concluídas até que as atividades
e tarefas sejam atribuídas, porque as estimativas devem levar em
consideração:
– Habilidades: a capacidade de executar tarefas específicas. O membro da
equipe fez esse tipo de trabalho antes?
– Conhecimentos no assunto: a posse de fatos ou conceitos sobre um assunto
específico. O membro da equipe é um especialista nesta área de negócios?
– Fatores ambientais: atividades administrativas e não relacionadas ao trabalho
como férias, falta de computador, outras atividades, doença, reuniões, etc.
Atribuição de recursos
 Nem todas as atividades e tarefas devem ser realizadas em série,
muitas podem ser realizadas em paralelo, desde que haja pessoal
suficiente. A maioria das ferramentas suporta os seguintes tipos:
Dependências de tarefas
 A falta de pessoal pode reverter rapidamente os benefícios de ter
poucas dependências de tarefas. Por exemplo, tarefas que poderiam
ter sido executadas em paralelo, mas não podem ser atribuídas a
vários membros da equipe devido a uma falta de equipe, devem ser
executadaa em sequência.
Dependências de recursos
 Após identificar as dependências anteriores, use o método do caminho
crítico para descrever as durações das tarefas e atrasos para as que não
estiverem no caminho crítico. Isso fornece a visibilidade necessária para
retribuir recursos ou renegociar as restrições do projeto.
Método do caminho crítico
Horários do projeto
 Depois de determinar tarefas, recursos, dependências e estimativas,
você pode agendar o projeto no calendário. A representação mais
comum e mais familiar de um cronograma do projeto é um gráfico de
Gantt.
Horários do projeto
 Listagem de atividades e tarefas.
 Dependências entre as tarefas.
 Criação do cronograma.
Conclusão
 Sequência de atividades do planejamento.
Próxima aula
Aula 5.4. Atividades para o planejamento de um projeto 
de BI
 Lista de atividades para planejar um bom projeto de BI.
Nesta aula
 As atividades de planejamento do projeto não precisam ser realizadas
linearmente. Abaixo estão descrit brevemente as atividades associadas
ao planejamento de projetos. Tanto as atividades 3 e 4, quanto 6 e 7,
podem ser realizadas simultaneamente.
Introdução
1. Determine os requisitos do projeto. Você já preparou os objetivos
para o projeto e alguns requisitos de alto nível para o escopo
proposto. No entanto, provavelmente não são de detalhes suficientes
para iniciar o processo de planejamento. Como parte da definição do
escopo, reveja e revise os seguintes requisitos: dados, funcionalidade
(relatórios e consultas) e infraestrutura (técnica e não técnica).
Atividades do planejamento
2. Determine a condição dos arquivos de origem e bancos de dados. Você não
pode completar o cronograma do projeto nem se comprometer com uma data
de entrega sem uma boa compreensão da condição dos arquivos de origem e
dos bancos de dados. Leve algum tempo para rever o conteúdo dos dados
desses arquivos e bancos de dados operacionais. Embora você realize análises
detalhadas de dados durante a fase de análise de dados, agora você precisa
obter apenas informações suficientes para fazer um palpite educado sobre o
esforço necessário para a preparação dos dados.
Atividades do planejamento
3. Determine ou revise as estimativas de custo. Estimativas detalhadas
de custos devem incluir custos de hardware e rede, bem como preços
de compra e taxas de manutenção anual para ferramentas. Além
disso, você deve verificar os custos para terceiros, consultores e
treinamento. Um custo mais indireto está associado à curva de
aprendizado para os funcionários da empresa e da TI. Lembre-se de
considerar isso nas estimativas de custo, bem como nas estimativas
de tempo.
Atividades do planejamento
4. Revise a avaliação de risco. Revise e revise a avaliação de risco.
Classifique cada risco em uma escala de 1 a 5 de acordo com a
gravidade de seu impacto no projeto de BI, com 1 indicando baixo
impacto e 5 indicando alto impacto. Da mesma forma, classifique a
probabilidade de materialização de cada risco, com 1 sendo
“provavelmente não acontecerá” e 5 sendo “quase podemos contar
com isso”.
Atividades do planejamento
5. Identifique fatores críticos de sucesso. Um fator de sucesso crítico é
uma condição que deve existir para que o projeto tenha uma grande
chance de sucesso. Alguns fatores de sucesso crítico comuns são um
patrocinador de negócios proativo, envolvimento em tempo integral
de um representante de negócios, orçamentos e horários realistas,
expectativas realistas e uma equipe central com o conjunto de
habilidades certo.
Atividades do planejamento
6. Prepare a carta do projeto. A carta do projeto é semelhante a um
acordo de escopo, um documento de entendimento ou uma
declaração de trabalho. No entanto, a carta do projeto é mais
detalhada do que uma visão geral do projeto que contém apenas uma
breve descrição dos recursos, custos e cronograma. A carta do
projeto é um documento maior, desenvolvido pela equipe principal,
que inclui o representante de negócio. Apresente a carta do projeto e
o plano do projeto ao patrocinador do negócio para aprovação.
Atividades do planejamento
7. Crie um plano de projeto de alto nível. Os planos de projetos
geralmente são apresentados sob a forma de um gráfico de Gantt que
mostra atividades, tarefas, recursos, dependências e esforço
mapeados em um calendário e se possível também outros tipos de
informações e gráficos.
Atividades do planejamento
8. Inicie o projeto. Depois de ter planejado o projeto, atribuído os recursos e
agendado o treinamento, você está pronto para iniciar o projeto. Isso
geralmente é realizado com uma reunião de orientação para toda a equipe (os
principais membros da equipe, bem como os membros da equipe estendida).
O lançamento do projeto também deve incluir a criação de canais de
comunicação (por exemplo, boletins informativos, e-mails, páginas da Web)com o resto da organização para manter as partes interessadas atualizadas
sobre o progresso do projeto.
Atividades do planejamento
 Atividades básicas para elaborar e iniciar um projeto de BI.
Conclusão
 Ciclo analítico da inteligência de negócios.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 6. Ciclo analítico do BI
Prof. Daniel Capanema
Aula 6.1. Ciclo analítico do BI
 O processo iterativo para análise de negócios.
Nesta aula
 Processo iterativo partindo do monitoramento da atividade à identificação
do problema ou oportunidade, determinando ações a serem tomadas e,
por fim, volta ao monitoramento dos resultados dessa ação.
 O ciclo analítico de BI ajuda a entender como os usuários utilizarão os
sistemas de BI e quais as ferramentas a serem oferecidas para extraírem o
máximo dos sistemas.
 Esse ciclo deve ser explicitamente aplicado a cada aplicativo construído.
Introdução
Introdução
 Análise de informações fornecidas pelos sistemas, dados históricos e
outros, fornecidos por meio de dashboards, portais de BI, balanced
scorecards e outras ferramentas de visualização.
 Algumas empresas julgam que este é o fim de uma solução de BI e
param por aqui.
Monitoramento de atividades
 Nessa etapa identificam-se quais são e onde estão os problemas e as
oportunidades a serem exploradas.
 Exceções ao comportamento normal podem tanto ser problemas
como situações extraordinariamente positivas.
 As exceções podem gerar alarmes nos sistemas de BI alertando seus
usuários da condição identificada.
Identificação das exceções
 Busca pela raiz causadora das exceções identificadas.
 Importante integrar ao sistema de inteligência de negócios
ferramentas estatísticas e de mineração de dados.
 Fontes externas, meio ambiente, e outras fontes podem ajudar a evitar
equívocos.
Determinação dos fatores causais
 A partir dos fatores causais identificados e dos dados históricos
registrados no DW, desenvolvem-se alternativas de decisão com a
possibilidade de se analisar o efeito de tal decisão em ocasiões
anteriores.
 O objetivo final é poder realizar simulações dos efeitos oriundos de
uma decisão em um cenário semelhante em ocasiões anteriores.
 As ferramentas mais utilizadas nesse caso são a análise sensitiva, as
simulações de Monte Carlo e as otimizações de busca de metas.
Modelagem de alternativas
 Os resultados devem ser capturados e analisados para um refinamento
contínuo dos processos, regras de negócio e modelos analíticos.
 Para que isso seja possível, pode ser necessário que o DW seja capaz de
acessar a linha operacional ou mesmo alterar os modelos dimensionais ou
criar bancos de acompanhamento de desempenho para que sejam
guardadas as decisões de negócio tomadas e as métricas impactadas por
elas para, então, serem definidas aquelas que tiveram um resultado
satisfatório ou aquelas que não atingiram seus objetivos.
Atuação e acompanhamento dos resultados
 Análise de exceções e tratamento.
Conclusão
 Tipos de soluções de BI.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 7. Tipos de soluções de BI
Prof. Daniel Capanema
Aula 7.1. Tipos de soluções de BI
 Possibilidades de soluções empregadas em projetos de BI.
Nesta aula
 As aplicações de BI podem ser divididas em grupos que correspondem
à forma de acesso e ao tipo de informação fornecida.
 O tipo de relatório está relacionado com o usuário, frequência e valor
da decisão a ser tomada.
Introdução
Introdução
Introdução
Introdução
BI Estratégico BI Tático BI Operacional
Objetivos de negócio
Desenvolver e avaliar os 
objetivos de negócio de 
longo prazo
Gerenciar iniciativas táticas 
para alcançar objetivos 
estratégicos
Monitorar e otimizar 
processos operacionais de 
negócio
Escopo Organizacional
Domínio de negócio 
específico.
Processos de negócio
Usuários
Executivos, analistas de 
negócio
Analistas de negócio, 
gerentes de negócio
Gerentes de negócio, 
usuários operacionais 
(internos e externos), 
processos operacionais
Introdução
BI Estratégico BI Tático BI Operacional
Tempo Meses e anos Diário, semanas, meses
Dentro de um mesmo dia 
a diário
Dados Históricos Históricos
Tempo real, quase em 
tempo real, de baixa 
latência e históricos
Modo de Operação
Centrados em dados, 
direcionado a usuários
Centrados em dados, 
direcionado a usuários
Centrados em processos, 
direcionados a usuários e 
processos
 Presente na maioria das ferramentas de BI. O próprio usuário gera a
informação necessária.
 Usuários avançados, gerentes, conhecimentos de consultas.
 Quatro aspectos principais:
– Formulação de consultas: auxílio com linguagens de consultas.
– Análise e apresentação dos resultados: apresentar os dados com qualidade.
– Experiência do usuário: acesso a metadados, fácil de usar, evitar o uso indevido de
dados.
– Aspectos técnicos: multitarefas, agendamento, importação / exportação.
Consultas de acesso direto
 O sistema deve ter algumas características e recursos para facilitar a
geração da informação:
– Combinar pequenas consultas no sistema final para facilitar a busca.
– Alertas para registros fora do padrão.
– Suporte a OLAP e possibilidade de alteração de consultas geradas.
– Cálculos matemáticos, manipulações, formatações, filtros, etc.
Consultas de acesso direto
 Relatórios muito utilizados devido a facilidade de uso e informação
predeterminada.
 Oferecem formas de padronização como seleção de parâmetros e
filtros.
Relatórios padrão
Relatórios padrão
Relatórios padrão
 Como o nome diz, visa o nível operacional.
 Também conhecido por BI em tempo real. Pode utilizar relatórios de
sistemas operacionais.
 Busca realizar o acompanhamento diário das tarefas operacionais.
 Decisões imediatas de baixa complexidade.
BI Operacional
 Tipos de soluções de BI.
 Estratégicas, táticas e operacionais.
 Todas são importantes.
Conclusão
 Aplicativos analíticos, gestão do conhecimento, inteligência competitiva.
Próxima aula
Aula 7.2. Aplicativos analíticos, gestão do conhecimento, 
inteligência competitiva
 Aplicativos analíticos.
 Importância da gestão do conhecimento e inteligência competitiva nas
empresas.
Nesta aula
 Os aplicativos analíticos são
ferramentas voltadas para
processos específicos.
 São mais complexos que os
relatórios padrão, pois
podem envolver data mining
e aprendizado de máquina.
Aplicativos analíticos
 Conjunto de tecnologias e processos cujo objetivo é apoiar a criação, a
transferência e a aplicação do conhecimento nas organizações.
 Processo para criação, captura, armazenamento, disseminação, uso e proteção
do conhecimento importante para a empresa.
 Objetiva organizar de forma estratégica os conhecimentos dos colaboradores e
os conhecimentos externos, que são fundamentais para o sucesso do negócio.
Gestão do conhecimento
 A gestão de conhecimento é necessária em virtude da existência do conhecimento na
empresa, na mente das pessoas, nos departamentos e nos processos executados.
 A gestão de conhecimento amplia a vantagem competitiva e concorrencial da empresa,
reduz custos com P&D (planejamento e desenvolvimento), geração de novos modelos de
negócio, melhor aproveitamento e desenvolvimento do capital intelectual da empresa,
suporte às tomadas de decisão e melhorias na produção e na prestação de serviços.
Gestão do conhecimento
Captar Reter Desenvolver Compartilhar
 Inteligência competitiva é se antecipar às exigências do mercado.
 Saber utilizar as informações sobre o mercado (cliente, concorrente,
fornecedores) de forma estratégica.
 Não é espionagem, são formas legais de obter informações.
Inteligência competitiva
 Ações:
– Tenha conhecimento do mercado: o mercado vive em constante mudança,
mantenha a empresa atualizada.
– Analise os seus concorrentes: conheça seus concorrentes para saber se posicionar e
antecipar-se para riscos e oportunidades.– Desenvolva o planejamento do negócio: aprenda com iniciativas, erros e acertos
próprios e da concorrência.
– Realinhe e reverta a estratégia: mude o que não deu resultado.
– Faça coleta de dados: faça coleta de dados, mas saiba converter informações em
sabedoria empresarial.
Inteligência competitiva
 Vantagens:
– Amplia a vantagem competitiva da empresa.
– Permite atuar de forma proativa.
– Facilita a obtenção de conhecimento relevante que impacta o
planejamento.
– Ajuda a empresa a se capitalizar.
Inteligência competitiva
 Aplicações analíticas.
 Importância e frutos da gestão do conhecimento e da inteligência
competitiva.
Conclusão
 Mineração de dados.
Próxima aula
Aula 7.3. Mineração de dados
 Mineração de dados.
Nesta aula
Introdução
 Os sistemas de tomada de decisão precisam de boas ferramentas de exploração.
 Como o DW possui bases de dados bem organizadas e consolidadas, as
ferramentas de Data Mining ganharam grande importância e utilidade.
 Poderosa alternativa para as empresas descobrirem novas oportunidades de
negócio e, acima de tudo, traçarem novas estratégias.
 O propósito da análise de dados é descobrir previamente características dos
dados, sejam relacionamentos, dependências ou tendências desconhecidas.
Introdução
 As ferramentas de Data Mining analisam os dados, descobrem
problemas ou oportunidades escondidas nos relacionamentos dos
dados e, então, diagnosticam o comportamento dos negócios.
 Mínima intervenção do usuário, que se dedicará somente a buscar o
conhecimento e produzir mais vantagens competitivas.
Mineração de dados
 As principais categorias das tarefas de mineração de dados são:
– Modelagem preditiva: criação de modelos para variável-alvo como função das
variáveis independentes.
– Análise associativa: descoberta de padrões descritores de características
fortemente associadas nos dados analisados.
– Análise de clusters: identificação de grupos de registros que apresentem uma
similaridade significativa entre si.
– Detecção de anomalias: identificação de registros que apresentem uma
diferença significativa do restante dos dados.
Mineração de dados
Mineração de dados
 As descobertas tornam-se parte da estrutura informacional em que
decisões são formadas.
 A premissa do Data Mining é uma argumentação ativa, isto é, em vez
de o usuário definir o problema, selecionar os dados e as ferramentas
para analisar tais dados, as ferramentas do Data Mining pesquisam
automaticamente os mesmos a procura de anomalias e possíveis
relacionamentos, identificando assim problemas que não tinham sido
identificados pelo usuário.
Mineração de dados
 O apoio do Data Mining na tomada de decisões.
 Descoberta de informações para geração de conhecimento.
Conclusão
 Dashboards e scorecards.
Próxima aula
Aula 7.4. Dashboards e scorecards
 Camada de apresentação por dashboards e scorecards.
Nesta aula
Introdução
 Interfaces de alto nível com forte apelo visual.
 Imagens de leitura e interpretação rápida.
 Indicadores facilitadores de compreensão.
 Painéis que mostram métricas e indicadores importantes para alcançar
objetivos e metas traçadas de forma visual, facilitando a compreensão das
informações geradas.
 É preciso saber o que perguntar para construir um dashboard e conhecer de
forma clara as necessidades da empresa e dos departamentos.
 KPI (indicadores chave de desempenho) são fundamentais para definir os
painéis.
 Vários formatos de exibição são bastante conhecidos, o que agiliza a
compreensão.
Dashboards
Dashboards
 O que deve ser observado em um dashboard:
– Qual informação quero evidenciar?
– Qual a melhor forma para receber a informação?
– Quanto tempo eu demoro para explicar a informação?
– Que decisão eu posso tomar com esta informação?
Dashboards
 De um ponto de vista de alto nível, balanced scorecard (BSC) é tanto
uma medida de desempenho quanto uma metodologia de
gerenciamento que ajuda a traduzir os objetivos e metas financeiras,
de clientes, de processos internos e de aprendizado e crescimento de
uma empresa em um conjunto de iniciativas acionáveis.
 Mensuração dos progressos das empresas rumo às suas metas de
longo prazo, a partir da tradução da estratégia em objetivos,
indicadores, metas e iniciativas estratégicas.
Scorecards
Scorecards – Perspectivas estratégicas
 Para cada perspectiva identificada, devemos definir:
– Objetivos: Definir o que a empresa deseja alcançar em cada perspectiva
estratégica.
– Indicadores: Indicam o desempenho da empresa referente a cada objetivo
definido.
– Metas: Em função dos indicadores, qual o nível esperado de performance
que se deve atingir.
– Projetos estratégicos: As ações, iniciativas e intervenções que devem ser
tomadas para que se atinjam as metas de desempenho determinadas.
Scorecards
Scorecards
 Visualização a partir de dashboards.
 Formulação e utilização de scorecards.
Conclusão
 Modelagem dimensional, tabelas fato e dimensão.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 8. Modelagem multidimensional
Prof. Daniel Capanema
Aula 8.1. Modelagem multidimensional
 Visão multidimensional de dados.
 Tabelas fato e dimensão.
Nesta aula
Introdução
 Imagem global da realidade do negócio.
 Informações em níveis apropriados de detalhes.
 Otimização das consultas.
 Mais intuitiva.
 Modelo relacional
– Usado para identificar relacionamentos entre tabelas.
– Visa remover a redundância de dados.
– Processamento de Transações On-Line (OLTP).
 Modelo dimensional
– Apresenta dados em uma estrutura intuitiva permitindo alta performance de
acesso.
– Organiza dados em tabelas de fatos e dimensões.
– Processamento Analítico On-Line (OLAP).
Dimensional x Relacional
Dimensional x Relacional
cidade bairro
loja lojaDepto depto
ProdDepto
categoria
subCategoria
produto
marca
fornecedor
tipoVenda itemVendido
mês
dia
hora
Dimensional x Relacional
Produto
Marca
Fornecedor
subcategoria
Categoria
depto
tipoVenda
itemVendido
Ano
Mês
Dia
Hora
Cidade
Bairro
Loja
depto
Modelagem dimensional
Modelagem dimensional
Componentes do modelo dimensional 
 Principal tabela do modelo dimensional, na qual medidas numéricas
sobre o desempenho da atividade de negócio são mantidas.
 A maioria dos fatos é numérica e aditiva (fatos podem ser somados).
 Existem fatos não aditivos que não podem ser adicionados:
temperatura, preço, médias em geral.
 Sumarização é obtida por soma, contagem ou cálculo da média.
 Uma linha da tabela de fato corresponde ao valor de uma medida
dentro de algumas dimensões.
Tabela fato
Tabela fato
 Armazena as medidas numéricas do negócio e as chaves das
dimensões (ID das dimensões).
 Na tabela de fato, as chaves das dimensões são FK e juntas formam a
PK do fato.
 Idealmente, medidas são numéricas e aditivas: vendas(R$), lucro(R$),
despesas(R$), quantidades.
Tabela dimensão
 Tabela periférica, menos dados.
 Armazena as descrições do negócio
– É usada como filtros, agrupamentos e rótulos.
– Pode ser compartilhada.
 É normalmente desnormalizada (esquema estrela).
 Atributos das dimensões podem ser organizados em hierarquias:
– Produto (Categoria → Marca → Descrição)
– Loja (Tipo → Endereço → Nome_Loja)
– Tempo (Ano → Mês → Dia_Do_Mês)
 Fato
– Atributos quantitativos sobre o desempenho do negócio em um.
– Fato vendas: a quantidade vendida, o valor da venda, a margem de lucro,
média de venda, etc.
 Dimensão
– Atributos qualitativos sobre os ramos do negócio envolvidos na medida de
desempenho de um determinado fato.
– Dimensão produto: a descrição, o código, o preço, etc.
Tabelas fato x dimensão
 Modelo estrela
– Dimensões desnormalizadas.
 Modelo snowflake
– Dimensões normalizadas.
Modelos estrela e floco de neve
Modelos estrela e floco de neve
 Diferenças e vantagens do modelo dimensional para BI.
 Característicasdas tabelas fato e dimensão.
Conclusão
 Hierarquia das dimensões.
Próxima aula
Aula 8.2. Hierarquia das dimensões
 Hierarquia das dimensões.
 Pontos importantes da modelagem dimensional.
Nesta aula
 Uma dimensão pode ter múltiplas hierarquias, além de outros atributos descritivos.
 Exemplos:
– Para a dimensão Loja
• Geografia física: CEP, cidade, estado, região, país.
• Geografia de vendas: território, região, zona.
• Geografia de distribuição: área primária, região.
– Para a dimensão Produto
• Hierarquia de marcas.
• Hierarquia de categorias.
• Hierarquia de tipo de armazenamento.
Introdução
Hierarquia de dimensões
 As hierarquias não devem ser divididas em tabelas dimensões
diferentes.
 Dimensões correlacionadas devem ser combinadas.
Hierarquia de dimensões
Pontos a destacar
 Medidas aditivas:
– Muito comuns nas tabelas fatos e podem ser somadas ou totalizadas:
• Valor de venda.
• Quantidade de produtos.
 Medidas não aditivas:
• Temperatura.
• Preços unitários.
• Taxas.
– A soma das medidas pode fazer menos sentido do que a aplicação de uma outra função de
agregação
• Média.
• Mínimo ou máximo.
• Desvio padrão.
Pontos a destacar
 Dimensão temporal:
– DW sempre tem dimensões temporais.
– Extrema importância.
– Várias funcionalidades de datas:
• Períodos fiscais.
• Estações do ano.
• Feriados.
• Finais de semana.
• Eventos especiais:
– Carnaval, Páscoa, São João, Natal.
 Dicas:
– Construção do modelo dimensional:
• Análise dos dados do ambiente operacional.
• Levantamento de requisitos das atividades de negócio dos usuários do DM.
– A partir do esquema relacional da base operacional, vários modelos
dimensionais podem ser gerados.
– Identificar as atividades de negócio e modelá-las separadamente.
– Relacionamentos N:M com propriedades numéricas e aditivas geralmente
são mapeados em tabelas fato.
Pontos a destacar
 Mitos:
– Somente dados sumarizados.
– Soluções departamentais.
– Sem foco na empresa, tático mas não estratégico.
– Não integrável.
– Não escalável.
Pontos a destacar
 Hierarquia de dimensões.
 Medidas aditivas e não aditivas.
 Dimensões temporais.
 Dicas e mitos.
Conclusão
 Enterprise Data Warehouse.
 Bus Matrix.
Próxima aula
Aula 8.3. Enterprise Data Warehouse Bus Matrix 
(EDWBM) e projeto dimensional
 Enterprise Data Warehouse Bus Matrix (EDWBM).
 Projeto dimensional.
Nesta aula
 Conjunto de fatos que compartilham um conjunto de dimensões
padronizadas.
 Incremental.
 Independente de banco ou tecnologia.
 Permite que múltiplas equipes de desenvolvimento trabalhem de
maneira independente e assíncrona.
Introdução
Bus Matrix
Bus Matrix
 As dimensões conformadas são o barramento e são determinadas pelo
processo de design dimensional:
– Escolha do processo de negócio.
– Definição da granularidade.
– Identificação das dimensões já contempladas no Enterprise Data
Warehouse Bus.
– Inclusão das dimensões não contempladas no barramento.
– Identificação dos fatos.
 Artefato de análise mais importante do desenvolvimento de um DW.
 Linhas são fatos, e colunas dimensões.
 Possibilita a visualização de quais dimensões merecem atenção
especial por participarem de vários fatos.
Bus Matrix
 O projeto de um modelo dimensional é divido em quatro passos.
 Selecionar o processo de negócio a modelar.
– Um processo é uma atividade de negócio natural da organização que tipicamente é
suportada por um sistema fonte de coleções de dados.
– Exemplos: vendas, compras de matéria-prima, pedidos, expedições, faturamento,
inventário, contas a pagar/receber.
 Declarar o grão do processo de negócio.
– Significa especificar exatamente o que uma linha da tabela fato representa.
– Exemplos: uma linha de um cupom fiscal, um cartão de embarque individual, um nível
diário de estoque de cada produto, um saldo mensal de cada conta bancária.
Projeto dimensional
 Escolher as dimensões que se aplicam a cada linha da tabela de fatos.
– Implica em responder a pergunta: “Como o pessoal do negócio descreve
os dados que resultam do processo de negócio?”
– Exemplos: data, produto, cliente, tipo de transação, status de pedido.
 Identificar os fatos que irão popular cada linha da tabela fato.
– Implica em responder à pergunta: “O que nós estamos medindo?”. Os
fatos candidatos devem ser coerentes com o grão declarado no passo 2.
– Exemplos: quantidade, valor.
Projeto dimensional
 Resista à tentação de simplesmente examinar as fontes de dados
somente: não há substituto para o input dos usuários do negócio.
 Caso exista, use um modelo de dados convencional E-R como ponto de
partida para o trabalho de modelagem dimensional.
– Observe os relacionamentos 1:N existentes. Eles podem sugerir dimensões.
Pontos a destacar
– Observe as entidades fortes. Elas também podem sugerir dimensões.
Observe as entidades que expressam documentos como Nota Fiscal,
Pedido, Ordem de Compra, etc. Elas podem sugerir fatos.
– Observe os relacionamentos M:N. Na sua interseção, podem haver valores
numéricos. Isso sugere fatos.
– Observe os atributos que estarão nas tabelas de dimensões. Analise a
relação de hierarquias entre esses atributos de dimensão. Atente para os
relacionamentos M:N entre eles. Isso pode definir granularidade.
Pontos a destacar
 As tabelas fato, tipicamente, armazenam dados, valores atômicos ou
agregados obtidos a partir destes.
 As medidas das tabelas fato são normalmente aditivas em certas
dimensões (ou em todas).
 As tabelas fato possuem chaves que as conectam às diferentes
dimensões que as circundam. Essa conexão se dá num nível de
granularidade compatível entre elas (fato e dimensão).
Pontos a destacar
 As tabelas dimensão armazenam os valores de filtro, acesso e textos
que caracterizam os dados trabalhados.
 As tabelas fato são normalmente normalizadas (terceira forma normal).
 As tabelas dimensão são normalmente desnormalizadas (segunda
forma normal – esquema estrela).
 A granularidade combinada da tabela fato com a de suas tabelas
dimensão determina o número de linhas das tabelas do projeto.
Pontos a destacar
 A arquitetura EDWBM.
 Projetando um modelo dimensional.
Conclusão
 Operadores.
Próxima aula
Aula 8.4. Operadores
 Operadores em modelos dimensionais.
 OLAP.
Nesta aula
 Em modelos multidimensionais, como o próprio nome sugere, os
dados são organizados em múltiplas dimensões.
 Cada uma delas contém múltiplos níveis de abstração. Esses níveis são,
ainda, definidos pelo conceito de hierarquia.
 Essa organização provê ao usuário uma flexibilidade para observar os
dados a partir de diferentes perspectivas e em diferentes níveis de
detalhe.
Introdução
 Graficamente, esses modelos podem ser representados por meio de
um cubo.
 As operações sobre um cubo de dados nos permitem materializar
diferentes perspectivas (também conhecidas como visões), permitem
consultas e análises interativas sobre dados armazenados.
Introdução
Cubo OLAP
Analisando o cubo OLAP
 São operações para movimentar a visão dos dados ao longo dos níveis
hierárquicos de uma dimensão.
 Drill down ocorre quando o usuário aumenta o nível de detalhe da
informação, diminuindo o nível de granularidade.
 Roll up ocorre quando o usuário aumenta o nível de granularidade,
diminuindo o nível de detalhe da informação.
 Os caminhos de navegação são determinados pelas hierarquias de
dimensão.
Drill down e roll up
Roll up
Drill down
 Drill across: ocorre quando o usuário pula um nível intermediário
dentro de uma mesma dimensão.
– Ex.: o usuário executa um drill across quando ele passar de ano direto para
trimestre ou mês.
 Drill through: ocorre quando um usuário passa de uma informação
contida em uma dimensão para uma outra.
– Ex.: um usuário está na dimensão tempo e, no próximo passo, começa a
analisar a informação por região.
Drill across e drill through
Drill across São operações para realizar navegação por meio dos dados na
visualização de um cubo.
 Slice and dice é o mesmo que filtrar.
 Utilizando as operações slice and dice, conseguimos ver a informação
de ângulos que anteriormente inexistiam.
 Slice é operação que corta o cubo, mas mantém a mesma perspectiva
de visualização dos dados.
 Dice é o slice, porém em mais dimensões.
Slice and dice
Slice
 É o ângulo pelo qual os dados são vistos.
 Na prática, corresponde à modificação das dimensões em um gráfico
ou troca de linhas por colunas em uma tabela.
Pivot
Pivot
 Ranking: classifica determinada informação baseada nos melhores
indicadores.
 Last-week: mostra os valores relacionados à semana anterior tendo
base a semana atual.
 Prior-week: mostra os valores relacionados aos últimos sete dias.
 Year-to-date: com os dados do ano corrente até a data atual.
 Nest-unnest: redução das dimensões.
Outros possíveis operadores
 Operações possíveis de serem realizadas em cubos OLAP.
Conclusão
 Dados informacionais x operacionais.
 Data Warehouses.
 Data Marts.
 Documentação.
Próxima aula
Aula 8.5. Dados informacionais x operacionais, Data 
Warehouses, Data Marts e documentação
 Dados informacionais x operacionais.
 Data Warehouses.
 Data Marts.
 Documentação.
Nesta aula
 Fixação de conceitos.
 OLTP X OLAP.
 DW X DM.
 Importância da documentação.
Introdução
Dados operacionais e dados informacionais
CARACTERÍSTICAS DADOS OPERACIONAIS DADOS INFORMACIONAIS
Conteúdo Valores correntes Valores sumarizados,
calculados, integrados de
várias formas
Organização dos dados Por aplicação / sistema Por assuntos / negócios
Natureza dos dados Dinâmica Estática até o refreshment
dos dados, de tempos em
tempos
Dados operacionais e dados informacionais
CARACTERÍSTICAS DADOS OPERACIONAIS DADOS INFORMACIONAIS
Formato das estruturas Relacional (3FN) Dimensional, simplificado,
próprio para atividades analíticas
Atualização dos dados Atualização campo a campo Acesso granular ou agregado,
normalmente sem update direto
Uso Altamente estruturado em
tabelas, processamento
repetitivo
Estruturado em fatos e
dimensões, com processamento
analítico/preditivo
Tempo de resposta Otimizado para faixas abaixo de 1
segundo
Análises mais complexas, com
tempos de resposta maiores
 Revisão dos conceitos.
 Aplicações do DW e DM.
 Formas de construção.
 Aplicações.
Data Warehouse e Data Mart
Data Warehouse e Data Mart
Data 
Warehouse
Data Mart
vendas
Data Mart
marketing
Data Mart
inventário
Data Mart 
atendimento
 Um Data Warehouse (DW), ou armazém de dados, é um banco de dados com dados temporais
usados para análise e decisões das mais diversas perguntas realizadas por executivos.
 Os dados contidos nos DW são sumarizados, periódicos e descritivos. Com a manipulação
desses dados, os executivos podem tomar decisões baseadas em fatos e não em intuições e
especulações.
 Um Data Warehouse é projetado para garimpar informações escondidas nas montanhas de
dados de uma empresa.
 O banco de dados de um Data Warehouse deve ser projetado para processamento analítico
on-line (OLAP), onde caracteriza-se pela ênfase na performance da recuperação das
informações.
Data Warehouse
 Melhora a qualidade dos dados, criando uma padronização de códigos e descrições e
identificando e corrigindo dados ruins.
 Apresenta as informações da organização de forma consistente.
 Fornece um único modelo de dados para toda a organização, independentemente da
fonte.
 Reestrutura os dados de modo a satisfazer as necessidades dos usuários do negócio.
 Reestrutura os dados para melhorar o desempenho de consulta, mesmo para consultas
analíticas complexas, sem afetar os sistemas em operação.
 Agrega valor às aplicações de negócio operacional, principalmente a gestão de
relacionamento com clientes (CRM).
Data Warehouse – Benefícios
 Um Data Mart é um Sub Data Warehouse, ou seja, um pequeno
armazenamento de dados, que fornece suporte à decisão de um
pequeno grupo de pessoas.
 Os Data Marts atendem às necessidades de unidades específicas de
negócios, ao invés da corporação como um todo.
 Eles podem ser apropriados e gerenciados por pessoal de fora do
departamento de informática das corporações.
Data Mart
 A crescente popularidade dos Data Marts em cima da popularidade dos grandes
sistemas de Data Warehouses corporativos é baseada em bons motivos:
– Os Data Marts têm diminuído drasticamente o custo de implementação e manutenção de
sistemas de apoio às decisões, colocando-os ao alcance de um número muito maior de
corporações;
– Os Data Marts têm o escopo mais limitado e são mais identificados com grupos de
necessidades dos usuários, o que se traduz em esforços/equipes concentrados;
– Os departamentos autônomos e as pequenas unidades de negócios frequentemente
preferem construir o seu próprio sistema de apoio às decisões via Data Marts.
Data Mart – Benefícios
 A diferença entre um DW e um DM basicamente consiste no volume
de dados, abrangência e foco. Enquanto o DW foca na organização
como um todo, os DM’s focam em um determinado departamento ou
conjunto específico de usuário, por exemplo.
 A construção desse armazém pode acontecer de duas formas, cada
abordagem têm seus prós e contras. As circunstâncias e
particularidades de cada projeto é que determinarão qual deles
utilizar.
Data Warehouse x Data Mart
 Construção do DW e especialização dos DMs.
Construção Top-Down
 Construção dos DMs e expansão para o DW.
Construção Bottom-Up
 Na teoria é uma premissa básica para qualquer projeto, mas muitas
vezes não é aplicada.
– Não perceber a real importância.
– Pressão para cumprimento de prazos.
– Cultural da empresa.
Documentação
 Vantagens
– Evitar atritos entre os envolvidos.
– Evitar erros e retrabalho.
– Garantir maior eficiência operacional e gerencial.
– Gestão do conhecimento.
– Comprovação documental diante do cliente.
Documentação
 Dados OLTP e OLAP.
 Revisão de conceitos fundamentais.
 DW e DM.
 Documentação.
Conclusão
 Abordagens para modelagem de aplicações BI.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 9. Abordagens de Bill Inmon e Kimball
Prof. Daniel Capanema
Aula 9.1. Abordagem de Bill Inmon
 Modelagem de DW.
 Inmon x Kimball.
 Características.
Nesta aula
 Uma organização tem à sua escolha um grande conjunto de
ferramentas de design, armazenamento e manutenção, comerciais ou
de software livre, para implementar o DW.
 Nem todas as ferramentas são compatíveis entre si, e nem todas são
apropriadas para a metodologia de desenvolvimento escolhida.
 Apesar do grande universo de escolha nas ferramentas, a modelação
das mesmas está geralmente baseada numa de duas metodologias:
Inmon ou Kimball.
Introdução
Introdução
In
m
o
n
ki
m
b
al
l
 Em 1990, Bill Inmon ganhou o apelido “pai do Data Warehouse”, apresentando
o termo Data Warehouse na publicação Building the Data Warehouse.
 Muito utilizado pelas empresas até surgirem novas abordagens.
 Foi aprimorando o processo, sugerindo – resumidamente – o seguinte:
– Arquitetura lógica para extrair os dados de BDs operacionais dispersos;
– Dados são transformados e organizados temporalmente num único DW;
– Parte desses dados é então extraída para BDs menores, criando BDs
departamentais denominadas Data Mart (DM), onde os utilizadores finais exploram
os dados e criam relatórios.
Abordagem Inmon
 Melhor definição estratégica do projeto.
 DW Corporativo (DWC) modelizado segundo um modelo normalizado:
– Simplificação nos procedimentos de ETL;
– Menores taxas de crescimento do volume de dados.
 Proporciona um recenseamento integral dos sistemas fonte e
conteúdos existentes na organização.
 Desenvolve uma abordagem sistematizada e completa sobre os
processos de integração.
Abordagem Inmon – Vantagens
 Abordagem Top-Down centradanos dados, mais morosa e dispendiosa.
 Maiores custos iniciais em TI.
 Abordagem excessivamente centrada nos dados (todo o processo de desenvolvimento
depende da prévia conclusão do modelo corporativo dos dados:
– Inviabiliza o envolvimento dos utilizadores no projeto;
– Prolonga o período de ausência de resultados;
– Transfere para segundo plano a identificação das reais necessidades de informação dos
utilizadores.
 Modelos normalizados -> pior desempenho analítico.
Abordagem Inmon – Desvantagens
 Abordagens Inmon e Kimball.
 Características da abordagem Bill Inmon.
Conclusão
 Abordagem Kimball.
Próxima aula
Aula 9.2. Abordagem de Kimball
 Características da Abordagem de Kimball.
Nesta aula
 Abordagem posterior à de Inmon, mas que conquista mais adeptos
atualmente.
 Focada na modelagem dimensional que, inclusive, tem o apoio de
Inmon.
 Apresentação da técnica Data Warehouse Bus.
Introdução
“O Data Warehouse é constituído pela união de todos os seus Data Marts”. 
(Kimball 1997)
Introdução
In
m
o
n
k
im
b
a
ll
 Infraestrutura mais adequada às exigências de um SAD.
 DWC modelizados segundo modelo desnormalizado (esquemas estrela):
– Estrutura mais flexível, comportando mais facilmente diante das alterações nos
sistemas fonte;
– Desenvolvimento de modelos mais intuitivos e com melhor desempenho.
 Abordagem iterativa centrada nas necessidades de informação
– Permite antecipar a entrega de resultados.
 Garante o maior envolvimento dos utilizadores.
Abordagem Kimball – Vantagens
 Permite fasear os custos de investimento em infraestrutura.
 Proporciona um melhor time to market (maior ROI).
 Abordagem de implementação totalmente integrada.
Abordagem Kimball – Vantagens
 Dificuldade em definir as dimensões e os fatos.
 Esquemas estrela do DWC -> vertiginoso crescimento do volume de dados
armazenado.
 Conduz à obtenção de procedimentos de ETL, mais complexos:
– Modelos dimensionais requerem operações adicionais de transformação e
agregação dos dados dos sistemas operacionais (usualmente representados em
modelos normalizados);
– Alterações ao nível dos sistemas operacionais implicam alterações em
procedimentos dedicados a diferentes esquemas em estrelas de diferentes
granularidades.
Abordagem Kimball – Desvantagens
 Abordagem Kimball.
 Abordagem mais indicada.
Conclusão
 Ciclo Kimball.
Próxima aula
Aula 9.3. Ciclo Kimball
 Processo para o desenvolvimento de um DW.
Nesta aula
 Diagrama do ciclo de vida de um projeto de BI por Kimball.
Introdução
 Os quatro passos do processo de design Kimball apresentam uma metodologia
própria para o desenvolvimento de DWs. Esta etapa envolve uma aproximação
bottom-up, consistindo na construção de um DM de cada vez, apoiado no
DWB.
 Os quatro passos do processo de design são:
– Selecionar o processo de negócio;
– Definir o grão;
– Escolher as dimensões;
– Identificar as métricas das tabelas de fatos.
Ciclo Kimball – Modelagem
 Atividades operacionais realizadas por sua organização:
– Fazer um pedido, processar uma reivindicação de seguro, registrar alunos para uma aula.
 Os eventos de processos de negócios geram ou capturam métricas de desempenho que
se traduzem em fatos.
 A maioria das tabelas de fatos se concentra nos resultados de um único processo
comercial.
 Escolher o processo é importante, porque define um alvo de design.
 Cada processo comercial corresponde a uma linha na matriz do barramento do data
warehouse da empresa.
Seleção do processo de negócio
 Passo fundamental em um design dimensional.
 O grão estabelece exatamente o que representa uma única linha da tabela de
fatos.
 O grão deve ser declarado antes de escolher dimensões ou fatos, porque cada
dimensão ou fato do candidato deve ser consistente com o grão.
 O grão atômico refere-se ao nível mais baixo no qual os dados são capturados
por um determinado processo comercial, e essa deve ser a abordagem
utilizada.
 Cada grão de tabela de fatos proposto resulta em uma tabela física separada.
Definição do grão
 As dimensões fornecem “quem, o quê, onde, quando, por quê, e como” o
contexto que envolve um evento de processo de negócios.
 As tabelas de dimensões contêm os atributos descritivos usados por
aplicativos de BI para filtrar e agrupar os fatos.
 Com o grão de uma tabela de fatos em mente, todas as dimensões possíveis
podem ser identificadas.
 As tabelas de dimensão às vezes são chamadas de “alma” do data warehouse,
porque contêm pontos de entrada e rótulos descritivos que permitem que o
sistema DW / BI seja alavancado para análise de negócios.
Escolha das dimensões
 Os fatos são as medidas resultantes de um evento de processo de
negócios e quase sempre são numéricas.
 Uma única linha da tabela de fatos tem uma relação de um para um
para um evento de medição conforme descrito pelo grão da tabela de
fato.
 Dentro de uma tabela de fatos, apenas os fatos consistentes com o
grão declarado são permitidos.
Métricas das tabelas de fatos
 O ciclo Kimball.
 Detalhamento da fase de análise e modelagem.
Conclusão
 Quadrante mágico.
Próxima aula
Fundamentos em Inteligência de Negócio
Capítulo 10. Aplicativos de BI
Prof. Daniel Capanema
Aula 10.1. Quadrante mágico dos aplicativos de BI
 O quadrante mágico da Gartner.
Nesta aula
 A Gartner Group é uma empresa de consultoria criada por Gideon Gartner,
em 1979.
 O seu trabalho é criar conhecimento por meio de pesquisas sobre
tecnologias, execução de programas, consultoria, eventos e levantamento
de soluções para que os seus clientes tomem decisões mais assertivas
todos os dias.
 Esses clientes se dividem em empresas e também executivos individuais,
chegando a um total de 10 mil, espalhados em todo o globo.
Introdução
 O quadrante é uma representação gráfica do mercado tecnológico por um
determinado período.
 Define forças dentro de um segmento empresarial, fazendo com que fiquem nítidas
as qualidades e possíveis falhas das empresas mais significativas da área de
tecnologia.
 Apesar disso, a empresa não endossa nenhum fornecedor, produto ou serviço
retratado, nem mesmo os fornecedores classificados como líderes no quadrante.
Seu objetivo final é funcionar exclusivamente como uma ferramenta de pesquisa
para embasar decisões a partir de necessidades específicas de cada negócio.
Quadrante mágico
 De acordo com a Gartner, aquele BI centrado em ferramentas
parrudas, muito técnicas e que apenas funcionários da área de TI
conseguiam desenvolver, já passou do ponto de existência no
mercado.
 A maioria das novas compras são centradas nas plataformas
modernas, visando os usuários de negócios (Self-Service BI), forçando
os fornecedores a adquirirem uma nova perspectiva de mercado e
disponibilizarem ferramentas mais simples e objetivas.
Quadrante mágico
 A matriz apresenta nos relatórios
sempre dois eixos, entenda:
– Na horizontal, é avaliada a visão da
empresa em termos de inovação
tecnológica e abrangência sobre as
necessidades do mercado.
– Na vertical, o relatório traz o quanto as
empresas têm habilidade de executar,
implantar o que prometem.
Quadrante mágico
 Ele é dividido da seguinte forma:
1. Líderes: aqui são colocadas as empresas tecnologicamente mais
avançadas. São aquelas que ditam as regras dentro do seu segmento por
terem uma melhor visão de mercado e capacidade de levar adiante as
suas promessas.
2. Desafiadores: são empresas que estão logo atrás dos líderes. São
companhias com capacidade de execução plena. Entretanto, apenas
possuem uma parcela do mercado.
Quadrante mágico
3. Visionários: nesse ponto temos as empresas mais fortes em pesquisa e
desenvolvimento, verdadeiras visionárias. No entanto, muitas vezes não
possuem a tecnologia – ou simplesmente não são capazes – para executar
o que é prometido.
4. Concorrentes de nicho: as empresas desse quadrante são aquelas que
focam em